[Bug 774600] mpegtsdemux: Pipeline hang on lossy transport stream

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=774600

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t.i.m at zen.co.uk

--- Comment #7 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
This code looks fine to me at first glance. The pad task will take the pad
stream lock when it loops from the started thread, so it will just wait until
the UNLOCK is done here, if needed.

Doesn't look like there are locking order problems with any other locks either.

The paused thread you identify seems to belong to a taskpool, so that need not
indicate anything unusual either, and may just be waiting to be started/used.

The mpegts_base_loop task must be started but then stopped streaming for some
reason. The reason is probably found in the debug log, or you can put some
strategic printfs into the task function, to see if it gets started and pauses
or is never started in the first place.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.