After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 767102 - decodebin: hits ASSERT with H264 byte-stream as input
decodebin: hits ASSERT with H264 byte-stream as input
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal blocker
: 1.9.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 764948
Blocks:
 
 
Reported: 2016-06-01 11:44 UTC by Philippe Normand
Modified: 2016-06-02 08:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
decodebin contents before the assert (49.84 KB, image/png)
2016-06-01 13:37 UTC, Philippe Normand
  Details
decodebin: Create a new decode element with the parser/convert capsfilter if there is a multiqueue after the parser (2.71 KB, patch)
2016-06-01 13:56 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Philippe Normand 2016-06-01 11:44:08 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.
Comment 1 Philippe Normand 2016-06-01 13:37:48 UTC
Created attachment 328887 [details]
decodebin contents before the assert
Comment 2 Philippe Normand 2016-06-01 13:41:00 UTC
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.
Comment 3 Sebastian Dröge (slomo) 2016-06-01 13:41:12 UTC
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 :)
Comment 4 Sebastian Dröge (slomo) 2016-06-01 13:42:06 UTC
(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.
Comment 5 Sebastian Dröge (slomo) 2016-06-01 13:46:12 UTC
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 :)
Comment 6 Sebastian Dröge (slomo) 2016-06-01 13:56:51 UTC
Created attachment 328889 [details] [review]
decodebin: Create a new decode element with the parser/convert capsfilter if there is a multiqueue after the parser
Comment 7 Sebastian Dröge (slomo) 2016-06-01 13:57:16 UTC
Untested, please test :)
Comment 8 Philippe Normand 2016-06-01 13:59:02 UTC
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
Comment 9 Philippe Normand 2016-06-01 14:00:43 UTC
(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 10 Sebastian Dröge (slomo) 2016-06-01 14:04:50 UTC
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
Comment 11 Sebastian Dröge (slomo) 2016-06-02 08:20:05 UTC
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