[Bug 763711] splitmuxsink: deadlock when one streams doesn't have regular buffers

[GStreamer (GNOME Bugzilla)]

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

Xavier Claessens <xclaesse at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #324300|needs-work                  |none
             status|                            |
 Attachment #324300|0                           |1
        is obsolete|                            |

--- Comment #9 from Xavier Claessens <xclaesse at gmail.com> ---
Created attachment 324383
  --> https://bugzilla.gnome.org/attachment.cgi?id=324383&action=edit
splitmuxsink: Fix occasional deadlock when ending file with subtitle

Deadlock occurs when splitting files if one stream received no buffer during
the first GOP of the next file. That can happen in that scenario for example:
 1) The first GOP of video is collected, it has a duration of 10s.
    max_in_running_time is set to 10s.
 2) Other streams catchup and we receive the first subtitle buffer at ts=0 and
    has a duration of 1min.
 3) We receive the 2nd subtitle buffer with a ts=1min. in_running_time is set
to
    1min. That buffer is blocked in handle_mq_input() because
    max_in_running_time is still 10s.
 4) Since all in_running_time are now > 10s, max_out_running_time is now set to
    10s. That first GOP gets recorded into the file. The muxer pop buffers out
    of the mq, when it tries to pop a 2nd subtitle buffer it blocks because the
    GstDataQueue is empty.
 5) A 2nd GOP of video is collected and has a duration of 10s as well.
    max_in_running_time is now 20s. Since subtitle's in_running_time is already
    1min, that GOP is already complete.
 6) But let's say we overran the max file size, we thus set state to
    SPLITMUX_STATE_ENDING_FILE now. As soon as a buffer with ts > 10s (end of
    previous GOP) arrives in handle_mq_output(), EOS event is sent downstream
    instead. But since the subtitle queue is empty, that's never going to
    happen. Pipeline is now deadlocked.

To fix this situation we have to:
 - Send a dummy event through the queue to wakeup output thread.
 - Update out_running_time to at least max_out_running_time so it sends EOS.
 - Respect time order, so we set out_running_tim=max_in_running_time because
   that's bigger than previous buffer and smaller than next.

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