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 666517 - Frequent deadlock while discovering a MPEG TS file
Frequent deadlock while discovering a MPEG TS file
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal major
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-12-19 13:57 UTC by Vincent Penquerc'h
Modified: 2012-01-23 18:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
backtrace (10.03 KB, text/x-log)
2012-01-12 11:08 UTC, Vincent Penquerc'h
Details

Description Vincent Penquerc'h 2011-12-19 13:57:50 UTC
gst-discoverer-0.10 sample_h264_heaac.ts

This hangs more often than not. There is a deadlock between a blocked pad, and basetransform sending delayed events from its _chain function.

File is at http://www.dsc.ufcg.edu.br/~cezane/sample_h264_heaac.ts (test case from https://bugzilla.gnome.org/show_bug.cgi?id=596772).
Comment 1 Vincent Penquerc'h 2012-01-12 11:05:54 UTC
On another (MPEG TS) file, I got a hang as well, but that's with a data buffer being blocked, rather than a delayed event.
Comment 2 Vincent Penquerc'h 2012-01-12 11:08:18 UTC
Created attachment 205071 [details]
backtrace
Comment 3 Vincent Penquerc'h 2012-01-12 11:33:18 UTC
And trying enough times, it also happens with playbin2 on these files, just less often.
Comment 4 Vincent Penquerc'h 2012-01-12 11:55:10 UTC
Sadly introduced by:

commit f1a4791f7419b5b3e07f0cf5dc0877e26152956f
Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Date:   Mon Nov 28 15:10:39 2011 +0000

    mpegdemux: Try to add all streams early
    
    This will allow us to signal no-more-pads to avoid hitting
    the decodebin2 overrun.
Comment 5 Vincent Penquerc'h 2012-01-12 12:47:02 UTC
When adding streams early, a sane looking stream can be added, but there might be no data coming through for that stream. This will leave the pad blocking waiting for its first buffer on the far end.

Before the patch, pads are added only when data comes through. This means subtitles can be missing (though caps checking can sort these), and of course one could wait a long time for low bitrate streams such as audio only ones.

Now need to think about it to work out what's the best way to fix. Maybe removing A/V pads for which no data was seen after some time, but that sounds so hackish :(
Comment 6 Vincent Penquerc'h 2012-01-23 17:53:01 UTC
Disabled for now, not sure what the right fix is.

commit cf74b0bc76106d77bea1a346becc158740d4fdd5
Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Date:   Mon Jan 23 17:47:45 2012 +0000

    mpegtsdemux: fix frequent deadlock demuxing MPEG TS
    
    A previous patch to add streams early to fix playback of
    low bitrate streams causes frequent deadlock of a nature
    I'm at loss how to fix.
    I'm not certain whether it's a bug in decodebin2, or in
    that mpegtsdemux patch.
    Since it causes a major regression, let it be disabled for now.