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 308633 - Matroska muxer always fails
Matroska muxer always fails
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other Linux
: Normal normal
: 0.8.11
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-06-22 10:27 UTC by Michal Benes
Modified: 2005-07-01 17:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Michal Benes 2005-06-22 10:27:09 UTC 
Running
gst-launch-0.8 sinesrc ! matroskamux ! filesink location=t.mkv
ends with
RUNNING pipeline ...
ERROR: from element /pipeline0/matroskamux0: Could not multiplex stream.
Additional debug info:
matroska-mux.c(1136): gst_matroska_mux_loop: /pipeline0/matroskamux0:
No data
Execution ended after 1 iterations (sum 64911000 ns, average 64911000 ns, min
64911000 ns, max 64911000 ns).


Tested with CVS version
Comment 1 Michal Benes 2005-06-22 11:23:23 UTC 
I have found the source of the bug:
gst_matroska_mux_prepare_data (mux) is called in the _loop function
before
gst_matroska_mux_start (mux);

The problem is that gst_matroska_mux_prepare_data assumes that
mux->sink[i].track->num is > 0 for at least one sink pad but the track nums are
set to valid numbers only in gst_matroska_mux_start.

One solution would be to remove the test 
mux->sink[i].track->num > 0
from 
gst_matroska_mux_prepare_data
This should be OK since there is still test 
GST_PAD_IS_USABLE (mux->sink[i].track->pad) 
and all usable pads will get track->num later in gst_matroska_mux_start
Comment 2 Ronald Bultje 2005-06-30 11:08:48 UTC 
Yes, good point. Will apply after release.
Comment 3 Ronald Bultje 2005-07-01 17:22:47 UTC 
Applied, thanks.