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.



                                       

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Nathanael D. Noblet]

So after having gotten that test example to work I tried to integrate it
into my real application. It fails to function properly. I've modified
the test example to include an audio stream which demonstrates the
problem. I would really appreciate help on figuring out why when I add
the audio stream my calls to gst_pad_set_blocked() block and don't
return... You can see the two behaviours by compiling one with
INCLUDE_AUDIO defined, and the other without. You'll see that you get an
output.mp4 which contains a few seconds of the test, and the viewer
continues for some time longer. However with the audio enabled it
blocks, the viewer pauses and just generally doesn't function properly...

Any ideas would be *very* much appreciated.

--
Nathanael d. Noblet

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel