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:

http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/matroska/matroska-demux.c#n3501

and here for the parser:

http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/matroska/matroska-parse.c#n2058

please advice, I would like to send a patch,

Nicola

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).

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,

Nicola

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));
      GST_BUFFER_FLAG_SET (buf, GST_BUFFER_FLAG_DISCONT);
    }

I don't know if this is right

Nicola

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.

In my case duration is -1 since I'm using streamable=true, for the continous newsegment they seems not related to streamable=true

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,

Nicola

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) {

in

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

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...

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)

any chance to see the demuxer patch pushed before the next release?

Looks OK, tested to work, and pushed with minor message fix and removal of an unrelated indentation hunk.