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

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 763711
           Summary: [splitmuxsink] deadlock when one streams doesn't have
                    regular buffers
    Classification: Platform
           Product: GStreamer
           Version: unspecified
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: xclaesse at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

I am recording audio+video+subtitles into small matroska files. For doing that
I have a splitmuxsink and matroskamux.

 - splitmuxsink calculates the size of buffers entering its multiqueue, using a
blocking pad prob on each input pads. Once the threshold is reached the state
becomes SPLITMUX_STATE_ENDING_FILE and all input threads wait for EOS to reach
the bus. It sends EOS event downstream as soon as downstream unblocks to take
the next buffer from the queue.

 - matroskamux has a GstCollectPads which won't deliver any buffer to the
matroska muxer until there is at least one buffer queued on every pads.

This results in a deadlock if the file size threshold is reached before the
first subtitle buffer arrives. In that case the GstCollectPads is blocked
waiting for all its pads to have queued packets, but the splutmuxsink blocked
its input because threshold has been reached so even if a subtitle arrives
later it won't reach the collect pads.

I can reproduce that deadlock in my application but it does lots of more
complicated stuff. I could work on writing a more minimal test case if needed.
I have no idea what would be the proper fix.

Note that, even without splitmuxsink, if I understand correctly how
GstCollectPads works, it means that muxing a matroska with few subtitles could
result in huge memory usage, since it's going to queue video buffers until it
gets a subtitle... Imagine a movie that has a long periods with nobody
speaking...

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