GNOME Bugzilla – Bug 767102
decodebin: hits ASSERT with H264 byte-stream as input
Last modified: 2016-06-02 08:21:56 UTC
+++ This bug was initially created as a clone of Bug #764948 +++ I have a custom src element which is a bin storing 2 appsrc elements. When the first appsrc element exposes its src pad and the bin propagates this pad, it triggers the pad-added decodebin signal and the following assert is hit. ** ERROR:gstdecodebin2.c:1746:analyze_new_pad: assertion failed: (chain->elements != NULL) SIGNAL [6] at address 0xc53! Reverting the chain->demuxer = TRUE change in 2b536467154ed672be8b49a9681693607723cc60 prevents the assert to hit. I'll try to dump the pipeline graph before the crash happens.
Created attachment 328887 [details] decodebin contents before the assert
Sometimes the assert is triggered when the other pad of my src element is exposed first. So this isn't really specific to H264. When the assert hits the chain->demuxer and chain->adaptive_demuxer fields are both equal to FALSE. I'm a bit confused because what the patch does is setting demuxer to TRUE, so it seems it's later on set to FALSE again.
So what would happen here is that we have a parser/converter that is the first element of a chain (that is, the element before the multiqueue... and chain->elements == NULL). It didn't happen in Vivia's use case because the parser there was just a parser (mpegaudioparse), but you now have h264parse. The problem is that you get a raw h264 stream directly into decodebin (the parser is the first element) and use-buffering=TRUE, so we add a multiqueue after the parser to be able to emit BUFFERING messages. Should be reproducible like that quite easily. We just need to understand what to do about the assertion :)
(In reply to Philippe Normand from comment #2) > When the assert hits the chain->demuxer and chain->adaptive_demuxer fields > are both equal to FALSE. I'm a bit confused because what the patch does is > setting demuxer to TRUE, so it seems it's later on set to FALSE again. There are two chains here: one that ends in the h264parse/multiqueue, and then another that starts at the multiqueue. The second is where the assertion is hit AFAIU.
Instead of inserting the capsfilter for the parser/converter into the same decode element as the parser (we can't, it's already linked to the multiqueue), here we should probably add a first decode element that only contains the capsfilter. Which will probably then break other assumptions of the code :)
Created attachment 328889 [details] [review] decodebin: Create a new decode element with the parser/convert capsfilter if there is a multiqueue after the parser
Untested, please test :)
Easy to reproduce indeed. I'll try your patch now :) gst-launch-1.0 filesrc location=raw.h264 ! "video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, level=(string)1.3, profile=(string)main, width=(int)320, height=(int)240, framerate=(fraction) 2500/83, pixel-aspect-ratio=(fraction)1/1, parsed=(boolean)true" ! decodebin use-buffering=TRUE ! fakesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ** ERROR:gstdecodebin2.c:1749:analyze_new_pad: assertion failed: (chain->elements != NULL) Aborted
(In reply to Sebastian Dröge (slomo) from comment #6) > Created attachment 328889 [details] [review] [review] > decodebin: Create a new decode element with the parser/convert capsfilter if > there is a multiqueue after the parser Works \o/
Comment on attachment 328889 [details] [review] decodebin: Create a new decode element with the parser/convert capsfilter if there is a multiqueue after the parser I wonder what else it breaks :) Only one way to find out. Will merge later
Attachment 328889 [details] pushed as 17d0499 - decodebin: Create a new decode element with the parser/convert capsfilter if there is a multiqueue after the parser