[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

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel