[Bug 738416] decodebin: Fix autoplugging of parser elements

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Oct 20 05:08:26 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=738416
  GStreamer | gst-plugins-base | git

--- Comment #9 from sreerenj <bsreerenj at gmail.com> 2014-10-20 12:08:24 UTC ---
(In reply to comment #8)
> It makes debugging from our side more difficult though. We wouldn't have to
> only ask about which decoder people are using, but also about the parsers.
> 
> In any case, for this to be acceptable
> - make a GST_DEBUG_OBJECT() in decodebin if there is more than one parser

Okay, make sense.

> - prefer Parser/Converter over plain Parser

Okay, But had a feeling that this will add one more overhead with out having
any advantage in 99% of the usecases (normal use cases).

> - only plug one parser in a chain for the same format, i.e. allow multiple
> parsers if somewhere the caps have changed from the first to the second parser.

previous comment again,,

> I think an elegant way of doing that is by just not plugging multiple parsers
> in a row, but if the previous element is not a parser just add one again if
> needed

This shouldn't work since we are not just adding extra parsers but extra
capsfilters also. So the previous element won't be be parser.
Basically every second parser in the system will cause two additions "one
parser+ one capsfilter".


I have caps comparions too in my local machine. Still need some more fixes. But
i have removed all caps comparisons from the patch because had a feeling that
it is unnecessary. Adding all those comparisons just to make a generalization.
Do we really need it? :) .. 
Anyway it seems like you are too instinct on that,, I will add those too ;)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list