[gstreamer-bugs] [Bug 557763] New: [mpegtsmux] Deadlock @ EOS due to interleaving mechanism

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=557763

  GStreamer | gst-plugins-bad | Ver: HEAD CVS
           Summary: [mpegtsmux] Deadlock @ EOS due to interleaving mechanism
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: vanista at gmail.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Please describe the problem:
A deadlock occurs in certain conditions in the new mpegtsmux. The problem
existed in the original flutsmux also.

There is a flaw in the interleaving mechanism where the collect pads can pass
EOS flushing and the mux still keep a queued buffer, resulting in the mux not
issuing the EOS event and the pipeline deadlocking.



Steps to reproduce:
gst-launch-0.10 mpegtsmux name=mux ! fakesink audiotestsrc num-buffers=1 ! lame
! queue ! mux.sink_0 videotestsrc num-buffers=1 ! ffenc_mpeg2video ! queue !
mux.sink_1

Actual results:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
[deadlocked]


Expected results:
Muxer issues EOS on its source pad and pipeline terminates properly.

Does this happen every time?
Yes its systematic, I think it occurs when audio and video have their EOS at
the same moment in the stream time line. This is not a race condition issue.

Other information:
I've compared the code with the avimux and noticed an obvious difference. The
avimux, for its interleaving purpose, only peeks at the collect pads until the
oldest (or most suitable) stream is identified. Then when a stream is sure to
be handled, a buffer is poped from the pad.

In the mpegtsmux, streams each have a tracking structure with a GstBuffer
pointer to keep the reference of all poped data. This is obviously to reduce
the overhead of accessing the collect pads, however it screws up the collect
mechanism for EOS handling.

I have a patch to propose a fix. Its probably not the best solution but I
didn't want to rewrite the whole function.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=557763.