Disappearing "segment done" event?

[Nicolas Dufresne]

Le lundi 27 mai 2013 à 13:26 +0200, Axel Philipsenburg a écrit :

> 
> Short description of a scenario:
> I have multiple independent video sources that I want to extract in
> parts and combine using the video mixer.

That looks like a use case for GNonlin, note that it's not ready yet for
1.0, but we are making good progress.


> 
> The GST_SEGMENT_DONE message on the bus is invoked properly, but from
> that one I can't determine
> which of the video sources finished playing a segment, because the
> message only holds the top level
> pipeline as parent.
> 
> So I thought to try pad probes or pad event functions to react on the
> GST_EVENT_SEGMENT_DONE
> event. I tried to look for it on various pads in the pipeline, but it
> did not show up, although the
> seek event sets GST_SEEK_FLAG_SEGMENT (BTW: If I leave this, I get an
> EOS instead of SEGMENT_DONE
> on the message BUS, so I expect it to be properly passed to the even.).


One thing you need to know about the segment event is that it travels
downstream until it reaches the element that handle the seek (usually a
demuxer). At that point, it is send to the application as a message and
drop the event. This is why you don't see it in you probe. The
SEGMENT_DONE tell you when you can operate a non-flushing seek without
blocking (when you have multiple source, you should probably count
those, and seek when the count match the number of sources). At that
point, there might still be data-flow between the demuxer and the video
mixer. If you want to change the source, you may want to probe for the
EOS message on the video mixer pad.

As said, this is the kind of problem that is being solved by Gnonlin
which is currently being ported and debugged to work in GStreamer 1.0 by
the PiTiVi team (freenode #pitivi).

best regards,
Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130527/642055dd/attachment.html>