That's already supported, a parser or demuxer is a "decoder" for the missing plugin framework. totem and friends already ask for demuxers/parsers if they're required.

What's the use case that doesn't work yet for you? (Note: missing plugin installation is broken in many cases with decodebin2/uridecodebin/playbin2)

> That's already supported, a parser or demuxer is a "decoder" for the missing
> plugin framework. totem and friends already ask for demuxers/parsers if they're
> required.

Well, you can't really explicitly ask for a 'parser' (or, more generally, something matching certain element factory klass details). Also, some distros might just not put parsers with a rank < MARGINAL into their database.

My use case is that I need to grab parsers for remuxing in Transmageddon. Don't think there is a way for me to do that unless I can set up a system which grabs both the decoder and parser in one go, pretending to want do decode a format?

You could use decodebin2 and set the caps property to "audio/mpeg,parsed=true", etc so it will continue to autoplug elements when there's some kind of parsed output. But this requires to know all possible parsed caps and that the parsers have a rank >= MARGINAL so it's not really a solution.

Another possibility would be to ask for specific elements if you know them by name but that's a bit limited too ;)

And then you could write a "parsebin" that works like decodebin but stops when the output is "parsed".


All this still has the problem that the current missing plugin messages don't see a difference between decoders and parsers. So if you ask for decoder-audio/mpeg,mpegversion=1 you could get a parser but you could also get a decoder (which you don't want). So there should be a new message, etc for parsers/demuxers too I guess... What do you think Tim?

> All this still has the problem that the current missing plugin messages don't
> see a difference between decoders and parsers. So if you ask for
> decoder-audio/mpeg,mpegversion=1 you could get a parser but you could also get
> a decoder (which you don't want). So there should be a new message, etc for
> parsers/demuxers too I guess... What do you think Tim?

I think there's a valid use case here. Options I can think of:

a) just declare that distros are supposed to install all available elements that match the caps when asked for a decoder, including elements with a rank <MARGINAL. This might be what many do anyway. This approach has at least two user interface problems though, namely 1) that the dialog says that you're asking for a decoder whereas you are asking for a parser, and 2) if distros are supposed to consider elements <MARGINAL, then in a playback scenario you might end up with a situation where a decoder is missing, and the UI shows that it installed a 'decoder' of some sort with rank <MARGINAL, but then playback still doesn't work. Distros might currently avoid this situation by not listing decoders for ranks <MARGINAL.

b) add a specific missing-element message for parsers

c) add a more generic missing-element message that would allow apps to request elements via 1) element factory klass details, 2) input caps (optional) and 3) output caps (optional). Ultimately (0.11) most of the other cases can be replaced with this then. Distros will love this of course (not).


I don't see why we'd need a special message for 'demuxer' as well, I think treating it as a decoder works well and a given caps format is either a container or not, there's no ambiguity, is there? (I might add some helper functions that return flags for a given caps, like if it's a container, if it's parsable, if it's audio, etc., also see bug #549111).

Sebastian that doesn't work actually. Doing it with playbin2/uridecodebin doesn't work as I tried. It was my original plan for how to ensure parsed output when I did remuxing, but Wim told me at GUADEC that he hadn't supported it yet and wasn't sure how to support it with the caps property. Ask Wim for details.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/23.