GNOME Bugzilla – Bug 764604
decodebin: fail to link to capsfilter when forcing H264 format (1.8 regression)
Last modified: 2018-05-05 16:07:05 UTC
The following pipeline is working with 1.6 but not 1.8: gst-launch-1.0 uridecodebin uri="rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov" ! video/x-h264,stream-format=avc ! fakesink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Progress: (open) Opening Stream Progress: (connect) Connecting to rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov Progress: (open) Retrieving server options Progress: (open) Retrieving media info Progress: (request) SETUP stream 0 Progress: (request) SETUP stream 1 Progress: (open) Opened Stream Setting pipeline to PLAYING ... New clock: GstSystemClock Progress: (request) Sending PLAY request Progress: (request) Sending PLAY request Progress: (request) Sent PLAY request ** (gst-launch-1.0:9118): DEBUG: alloc_len: 36 ** (gst-launch-1.0:9118): DEBUG: alloc_len: 829 WARNING: from element /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0: Delayed linking failed. Additional debug info: ./grammar.y(506): gst_parse_no_more_pads (): /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0: failed delayed linking some pad of GstURIDecodeBin named uridecodebin0 to some pad of GstFakeSink named fakesink0 ^Chandling interrupt. Interrupt: Stopping pipeline ... Execution ended after 0:00:03.718089881 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ...
I didn't know uridecodebin had such feature. It now stop the chain when one of the caps, in uridecodebin match the caps in "caps" property. So to get video/x-h264, I was expecting that you would have to add that to the caps in "caps" property. Anyone have an idea if that was supposed to work ?
Can we get a full 1.6 and 1.8 log? I don't think this should've worked in 1.6 either.
1.6 : https://people.collabora.com/~cassidy/764604-1.6.log 1.8 : https://people.collabora.com/~cassidy/764604-1.8.log
Basically nothing in decodebin/uridecodebin allows to get caps of a capsfilter "downstream" of it (there is no srcpad yet so it's not exactly downstream either). So the stream-format is chosen inside uridecodebin already without considering anything outside of uridecodebin. If anything it (h264parse) could reconfigure the stream-format later, but as you can't even link the uridecodebin srcpad with the capsfilter due to incompatible caps, that also can't happen. Someone would have to go through the logs but my best guess is that the automatically selected stream-format changed.
Ok so the only supported way to do this is: gst-launch-1.0 uridecodebin uri="rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov" caps="video/x-h264,stream-format=avc;audio/mpeg" ! fakesink This one works with 1.6 and 1.8 so we can close as NOTABUG if you agree that's not meant to be supported.
That should also not work. There's nothing in decodebin that would allow h264parse to negotiate a specific stream format, except for the autoplug-query signal as used by playbin for example.
Well it does work. :) If I don't pass the caps property, decodebin plugs the decoder, but it stops at the depayloaders, as expected, if I do. See: https://people.collabora.com/~cassidy/764604-caps.png https://people.collabora.com/~cassidy/764604-nocaps.png
Sure but it would also do that if you do caps="video/x-h264" without a stream format. That it outputs avc is just luck... it could've as well chosen byte-stream and then it would plug the decoder :)
Closing, this is not an issue with our elements, but usage of them