Created attachment 204524 [details] [review]
resindvd: use decodebin2 so needed parsers are plugged

This won't work because decodebin2 can't switch decoders on the fly (yet) when the codec changes (e.g. AC3 to DTS). IIRC this was the only reason why autoconvert was used here.

oh.. damn..

I guess we only really need this for video, so I suppose in theory we could build a different pipeline for audio vs video subbin, although that is a bit more ugly than what I would have hoped for.

Or you implement renegotiation in decodebin2 but that will be almost impossible in 0.10 and quite some work in 0.11. But by this the autoplug-* signals of decodebin2 could be proxied by resndvd and could then be used by uridecodebin and playbin2 to allow better selection of the correct decoders.


You'll probably need parsers for the audio and video case though...

You could create a GstBin subclass that internally plugs parser ! videodecoder with two ghostpads ;-)

(In reply to comment #4)
> Or you implement renegotiation in decodebin2 but that will be almost impossible
> in 0.10 and quite some work in 0.11. But by this the autoplug-* signals of
> decodebin2 could be proxied by resndvd and could then be used by uridecodebin
> and playbin2 to allow better selection of the correct decoders.

That sounds like the more correct solution, although not sure how feasible it is in the short term (0.10)..

I wonder about a simpler hack.. just detect caps changing and re-create the decodebin2 within resndvd?

> You'll probably need parsers for the audio and video case though...

it would be a good thing to allow for parsers on audio side too..  although cpu and neon are good enough these days that the overhead of dealing with a dsp usually outweighs the benefit of offload.  And just sticking with the sw decode elements (I guess gst-ffmpeg ends up handling most of the audio) seems to work for now without parsers.

(In reply to comment #6)
> (In reply to comment #4)
> > Or you implement renegotiation in decodebin2 but that will be almost impossible
> > in 0.10 and quite some work in 0.11. But by this the autoplug-* signals of
> > decodebin2 could be proxied by resndvd and could then be used by uridecodebin
> > and playbin2 to allow better selection of the correct decoders.
> 
> That sounds like the more correct solution, although not sure how feasible it
> is in the short term (0.10)..
> 
> I wonder about a simpler hack.. just detect caps changing and re-create the
> decodebin2 within resndvd?

You will still have the same problem in 0.10, i.e. you need to make sure to get the correct segments configured in all elements inside decodebin2. That's the hard part, just recreating everything inside decodebin2 could be done quite fast.

> > You'll probably need parsers for the audio and video case though...
> 
> it would be a good thing to allow for parsers on audio side too..  although cpu
> and neon are good enough these days that the overhead of dealing with a dsp
> usually outweighs the benefit of offload.  And just sticking with the sw decode
> elements (I guess gst-ffmpeg ends up handling most of the audio) seems to work
> for now without parsers.

Not all software decoders can handle unparsed input

What was the goal of all this again?

Subsequent to this bug, resindvdbin started adding mpegvideoparse (hard coded) in front of the video decoder. It still doesn't use any parsers in front of the audio decoders though, so things only work when the audio decoders don't need a parser.

decodebin3 should be able to handle input format changes, retitling accordingly.

Out of curiosity, audio packets coming out of psdemux should always be framed though, no? It might just not be 1 packet per buffer but N packets per buffer, right? Or is the framing not mandatory?

I don't think there's any requirement that the elementary stream be stored in MPEG-PS PACKs in any sensible packetisation - but yes, they'll have start code markers if that's what you mean.

-- 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-bad/issues/55.