[Bug 763711] New: [splitmuxsink] deadlock when one streams doesn't have regular buffers
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Mar 15 16:08:05 UTC 2016
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.
More information about the gstreamer-bugs
mailing list