[gst-devel] Handling EOS in a branched pipeline
Nathanael D. Noblet
nathanael at gnat.ca
Wed Oct 6 20:29:48 CEST 2010
Thanks to the help of the IRC I have a solution to EOS handling I was
struggling with and thought I would send the issues/solutions to the
list so they could be indexed and thus search-able by Google and friends.
In my case, I have a video source (rtsp but didn't really matter
really) which is being viewed via xvimagesink. I wanted to be able to
cause a user initiated recording at any given time during viewing. So
for me I have a gtk app with a 'start/stop recording' button, and an
independent 'start/stop viewing' button. The issue was that when saving
the recording the many muxers require an EOS to be received to write out
the index so that players can seek. In the case of an mp4 container it
won't play, in the case of a mkv container it will play but without
So first to describe the simple example pipeline included in the code
videotestsrc -> timer overlay
-> tee:src0 -> xvimagesink
-> tee:src1 -> recording bin
recording bin is simply queue->ffenc_mpeg4->muxer->filesink.
I've ignored audio for the test code but the issue should be about the same.
So when a user initiates the end of a recording we need to send an EOS
down the recording bin and then catch it to remove the recording bin.
You won't get the EOS message passed to the bus handler unless *all*
elements within the entire pipeline have received/posted an EOS. So
sending the EOS does nothing if you do
gst_element_send_event(recording_bin, gst_event_new_eos()); It sends but
you never catch it and thus can't disconnect the recording bin. If you
send the EOS down the entire pipeline then the viewer will disconnect
and poof there goes the application.
There are two ways to solve this. Camerabin from what I can gather puts
a pad event probe on their viewer element/bin and simply discards it so
that it never kills the viewer.
The other way is how I've demonstrated in the attached code. This is
mainly due to help from both __tim and wtay in irc so I take nearly no
credit for this now working.
Send the eos event to the recording bin sink pad, and have an eos event
probe attached to the muxer src, or the filesink sink pad. When your
event probe gets the eos, block the tee source pad, disconnect
everything and remove it from the pipeline.
For the case of this example, nothing is user initiated and I leave it
up to whoever uses code like this to determine when an EOS is sent by
the user vs sent by an actual EOS such as the stream becoming
disconnected or in the videotestsrc num-buffers ending.
If any of this explanation isn't clear let me know.
In hindsight it would be very nice if the gstreamer developers could add
the ability for a bin to process the EOS messages and post it to the bus
when they've completed it, independently of any pipeline they may be
contained within. I realize this is an open source project and should
provide a patch to back up my request, however at the moment I'm far
from knowledgeable enough to dig into gstreamer internals. I just put it
in here as a gentle request.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the gstreamer-devel