[gst-devel] [SOLVED] Dynamically Recording From a Live Stream & EOS Handling

[Nathanael D. Noblet]

Hello all,

   So over a month ago I posted to the ml a solution to recording from a 
live stream to handle the EOS required by many muxers for mp4/mkv 
formats.  The previous solution worked only if you had only an audio or 
video stream, all 4 different ways at getting it to work would end up 
with blocked threads and it going haywire. Recently I received some help 
from thaytan on IRC that provided the solution...


   Quickly let me draw a rudimentary diagram of the pipeline. Hopefully 
it doesn't get mangled too badly once sent.


          -->video-->tee /--> blah blah --> xvimagesink
rtspsrc /               \--> |---------------------------------|
         \                    |-> inputs --> muxer --> filesink |
          -->audio-->tee /--> |---------------------------------|
                         \--> blah blah --> autoaudiosink

   The basic idea being that the source is split into viewing/listening 
and a recording bin that encoded/muxed to a filesink. In my particular 
case I'm reading mp4 so branched prior to decoding so all I needed to do 
was remux and save.

   Initially the solution was to send a custom event through the 
pipeline. The reason being that if you send EOS to just the recording 
bin it never gets received on the bus call handler since you only get 
those events if *every* element in a complete pipeline receive the 
event, and they don't. It may be useful to think improving this in the 
1.0 plans though I don't know what that entails.

   The issue with sending a custom event down the pipeline to signal 
stopping the recording is a bit of missing code.

http://cgit.freedesktop.org/gstreamer/gstreamer/tree/libs/gst/base/gstbasesrc.c#n1639

I've filed an enhancement bug to see if that can get implemented [1]

Which basically means that my custom event never arrives and I'm in the 
same boat as before... This is where thaytan was a huge help. The 
solution was to build a custom gst bin element which I would have never 
thought of nor had the expertise to do at first.

The idea is to asynchronously block the pads, have the callback send an 
EOS into the custom bin, since the EOS will never make it back to the 
bus call handler in any application, have a _handle_message function 
catch the EOS and signal the application via a custom message. This all 
worked perfectly. I've attached simple code using testsrcs. You will see 
that the video is displayed for longer than the recording. We simulate 
stopping the recording with a g_timeout callback that will block the 
pads and instigate the ending of recording.

I just wanted to make sure this was documented since I found many many 
people looking for solutions similar to this with Google but no solutions.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=635718

Thanks for all the help and gstreamer - its great!
-- 
Nathanael d. Noblet
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: eos-thaytan3.c
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101124/47c7c45f/attachment.txt>