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 666583 - matroskademux: too many bus messages in streamable mode
matroskademux: too many bus messages in streamable mode
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal enhancement
: 0.10.31
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2011-12-20 11:40 UTC by Nicola
Modified: 2012-02-15 23:46 UTC
See Also:
GNOME target: ---
GNOME version: ---

Patch for the demuxer (1.89 KB, patch)
2012-01-28 10:25 UTC, Nicola
committed Details | Review

Description Nicola 2011-12-20 11:40:04 UTC
Please try a pipeline such this:

gst-launch -e -v v4l2src ! jpegenc ! matroskamux streamable=true ! filesink location=/tmp/test.mkv

and then play the produced file with something like this:

gst-launch -m filesrc location=/tmp/test.mkv ! matroskademux ! jpegdec ! xvimagesink

for each frame you'll see a new message on the bus:

"matroskademux0" (duration): GstMessageDuration, format=(GstFormat)GST_FORMAT_TIME, duration=(gint64)-1;

maybe this make sense only if something changed, maybe this message could be posted only the first time and not for every frame to reduce resource usage
Comment 1 Nicola 2011-12-20 13:06:21 UTC
In my use case these bus messages are useless I simply ignore them, maybe we could do one of the following:

1) add a new property, for example post-duration-messages as boolean, default true, an user could set to false to avoid all these messages
2) store the last sended duration and send it again only if there is a variation

the relevant code seems here for the demuxer:

and here for the parser:

please advice, I would like to send a patch,

Comment 2 Vincent Penquerc'h 2012-01-17 15:56:04 UTC
Also seen with something a bit simpler:

gst-launch -e -v videotestsrc num-buffers=32 ! jpegenc ! matroskamux  ! fakesink

New segment events are generated continuously.

The code above is the demuxer, but there may be similar code in the muxer. I guess duration should be only emitted if changed (your option 2), except maybe the first time (so we can emit an unknown duration, which may be better for the client, to know the duration is unknown, rather than not to know it may or may not be known. If you see what I mean).
Comment 3 Nicola 2012-01-28 10:25:14 UTC
Created attachment 206314 [details] [review]
Patch for the demuxer

This patch avoid to post a new messages such this:

GstMessageDuration, format=(GstFormat)GST_FORMAT_TIME, duration=(gint64)-1

for every frame, the message is posted only the first time.

I don't know if we can have invalid duration, and then valid duration in the same file, seems demux->invalid_duration is not set to FALSE when a valid duration is found, maybe we can add this too (after line 1955 add a line demux->invalid_duration = FALSE;).Based on the files I have this case doesn't happen.

If you like this solution I can do something similar for the parser too and then look at the newsegment question in the muxer,

Comment 4 Nicola 2012-01-28 22:02:16 UTC
the parser is not affected by this bug so the patch for the demuxer should be enough, please review

for the newsegment events they are generated in ebml-write.c there is code like this:

if (GST_BUFFER_OFFSET (buf) != ebml->last_pos) {
      gst_ebml_writer_send_new_segment_event (ebml, GST_BUFFER_OFFSET (buf));

I don't know if this is right

Comment 5 Vincent Penquerc'h 2012-01-31 17:26:58 UTC
Looking at this code, it does seems right.
Needs further investigation as to why there are continuous disconts, and why duration ends up at -1.
Comment 6 Nicola 2012-01-31 17:38:50 UTC
In my case duration is -1 since I'm using streamable=true, for the continous newsegment they seems not related to streamable=true
Comment 7 Nicola 2012-01-31 23:25:23 UTC
If I correctly understand the code the disconts are caused by gst_ebml_write_seek that reset ebml->pos and so GST_BUFFER_OFFSET calculated as:

GST_BUFFER_OFFSET (buf) = ebml->pos - data_size;

is different from ebml->last_pos and a new segment event is sended based on code reported in comment 4,

however this is related to the muxer, my the patch is for the demuxer,

Comment 8 Nicola 2012-02-01 07:02:39 UTC
I did a simple patch that keep the diff between last_pos and pos in gst_ebml_write_seek something like this:

ebml->pos_diff = ebml->last_pos -pos;

and then changed 

if (GST_BUFFER_OFFSET (buf) != ebml->last_pos) {


if (GST_BUFFER_OFFSET (buf) != (ebml->last_pos-ebml->pos_diff))

this way no continous newsegment event are generated but the result file contain errors (ebmlread ebml-read.c:148:gst_ebml_peek_id_length:<matroskademux0> Invalid EBML ID size tag (0x0) at position 368489 (0x59f69)), probably the muxer is ok as is, someone with in deep matroskamux knowledge should advice
Comment 9 Vincent Penquerc'h 2012-02-01 11:25:29 UTC
IIRC it think the code was already doing that keeping track (maybe incorrectly ?)

Looking at the patch, it seems that if the duration changes validly, thew new duration will not be sent as a message, is that right ? I see only a single place where the duration message is sent here.
Now it may be that it is impossible for duration to become known partway through in Matroska...
Comment 10 Nicola 2012-02-01 11:51:37 UTC
The actual matroskademux send bus messages only for invalid duration and not for valid duration, the patch avoid to send these messages for each frame and send the message only the first time. Probably the goal of the original code is to notify only when the duration is invalid so an application can react to this in some way.

If you want I can do another patch that send on the bus the duration when it become valid (actually matroskamux does't do this at all) and send another message when it become invalid and so on. However I cannot reproduce this behaviour with any of my test files, generally I have invalid duration is the file is muxed in streamable mode and valid duration when it is muxed without streamable=true no mixed cases (I don't know if they are possible)
Comment 11 Nicola 2012-02-06 07:34:22 UTC
any chance to see the demuxer patch pushed before the next release?
Comment 12 Vincent Penquerc'h 2012-02-06 10:25:33 UTC
Looks OK, tested to work, and pushed with minor message fix and removal of an unrelated indentation hunk.