you mean posting a SEGMENT_DONE message or pushing a NEWSEGMENT event? mad is never driving a pipeline based so it should not post segment messages. It's segment handling is pretty broken otherwise.

I think it's "eating" the new-segment events, or (?) trying to repost them later. I have problems with that when trying to do an initial flush seek using pad-blocking. 

As it was discussed on the mailing list, pad-blocking lets the new-segment events pass through. To counter that, I'm "eating" the first new-segment event on a pad-probe in a higher-level parent bin. But the first new-segment never comes for mad, contrary to other plugins I'm trying it with. 

Will inspect it. 

Created attachment 66364 [details] [review]
Moves the new-segment handling before pad alloc

So, the problems seems to be, that mad is pad-allocing a buffer before it sends a new-segment event. As the pad-alloc triggers the (possible) pad-block, it gives a false impression that the data is arriving on the pad before the new-segment event. 

I'm not sure if this is a bug or an acceptable behaviour. However, other plugins always seem to send a new-segment before they alloc a buffer (block the pad). I think that for consistency reasons mad should behave the same. 

Patch attached. It moves the (possible) new-segment sending before the pad-allocing.

 

yep, first the segment, then the pad block. Need to write down the rules once they are all figured out.

 2006-06-17  Tim-Philipp Müller  <tim at centricular dot net>

        Patch by: Michael Dominic K.  < mdk at mdk org pl>

        * ext/mad/gstmad.c: (gst_mad_chain):
          Send newsegment event before calling
          gst_pad_alloc_buffer_and_set_caps(), makes mad behave better
          in connection with pad blocking (#342594). While we're at it,
          do some minor clean-ups.

There wasn't a reason why this hasn't been applied, was there? :)