After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 327825 - [matroskamux] Matroska muxer deadlock
[matroskamux] Matroska muxer deadlock
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal major
: 0.10.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-01-20 10:10 UTC by Michal Benes
Modified: 2006-01-23 10:46 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch fixing matroska deadlock. (6.14 KB, patch)
2006-01-20 10:13 UTC, Michal Benes 		committed Details | Review

Description Michal Benes 2006-01-20 10:10:55 UTC 
In the situation that matroska muxer is writing a buffer that already has EOS on collectpads, it is not assured that at least one buffer is popped in collectpads. This is a big problem especially near the end of stream, where matroska mux will not detect EOS correctly. I do not know how this could work for me so long....
Comment 1 Michal Benes 2006-01-20 10:13:53 UTC 
Created attachment 57713 [details] [review]
Patch fixing matroska deadlock.

This is really a nasty problem, please could this patch be rewieved soon?
Comment 2 Tim-Philipp Müller 2006-01-23 10:46:24 UTC 
Thanks, applied to CVS with one minor modification: on EOS, the flow return value to be used is GST_FLOW_UNEXPECTED (admittedly not very intuitive):


2006-01-23  Michal Benes  <michal dot benes at xeris dot cz>

        * gst/matroska/matroska-mux.c: (gst_matroska_mux_best_pad),
        (gst_matroska_mux_write_data), (gst_matroska_mux_collected):
          Fix possible deadlock in matroska muxer (#327825).


Now what would be really neat is a small test case for this ... :)