GNOME Bugzilla – Bug 734220
decodebin/uridecodebin/playbin support multiple srcpads in a parser
Last modified: 2018-05-05 15:22:07 UTC
Seperated bug from https://bugzilla.gnome.org/show_bug.cgi?id=704881 As Mr Sebastian Dröge said, ------------------------------------------------------------------------------- However for adding multiple srcpads to a parser there are changes necessary in decodebin: 1) decodebin needs to detect these multi-srcpad parsers still as parsers (thus use the capsfilter hack for its main srcpad, but only for that) and additionally detect them as demuxers (thus use the multiqueue after all srcpads). 2) decodebin/uridecodebin/playbin need support for late pads. That is pads that are added after no-more-pads (or after multiqueue overrun, which is handled like no-more-pads). These should be included in the current stream group instead of being ignored. This shouldn't be too difficult but might break some assumptions in a few places.
Created attachment 282640 [details] [review] change is_demuxer_element judgement
Comment on attachment 282640 [details] [review] change is_demuxer_element judgement This is not correct. Not every video parser can have multiple srcpads, and you still need to handle the parsers as parsers elsewhere in the decodebin code. This patch would break conversion of stream formats for example. If you look elsewhere in decodebin you will see some parser specific code that still must be called for this. Maybe there should be a separate demuxer element for extracting the ancilliary data instead of putting it into the parser? Might be an easier solution
(In reply to comment #2) > (From update of attachment 282640 [details] [review]) > This is not correct. Not every video parser can have multiple srcpads, and you > still need to handle the parsers as parsers elsewhere in the decodebin code. > This patch would break conversion of stream formats for example. > > If you look elsewhere in decodebin you will see some parser specific code that > still must be called for this. > I started implementing a dynamic-parser handling that is similar to the demuxer, except that the no-more-pads signaling is ignored. It seems to work and is quite simple. > > Maybe there should be a separate demuxer element for extracting the ancilliary > data instead of putting it into the parser? Might be an easier solution Seems more elegant, but: 1) Will likely replicate parsing code in 2 elements 2) Autoplugging and avoiding loops will add extra complexity to decodebin
Thiago could you please upload your patch for the dynamic-parser handling
This is not really needed anymore considering that any element (including parsers) can add CC as meta on streams.