[gst-devel] Handling EOS in a branched pipeline

[Nathanael D. Noblet]

Hello,

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

   So first to describe the simple example pipeline included in the code 
below.

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...
Name: eos_test.c
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101006/26344bc6/attachment.asc>