start/stop recording from live preview+stream

[Tim-Philipp Müller]

On Fri, 2013-09-06 at 03:46 -0700, rashmi wrote:

Hi,

> I have a pipeline 
> v4l2src-->queue-->filtercaps--
>                               \
>                                -->tee-->queue-->TIDmaivideosink(DVI output)
>                                       |
>                                      
> |-->queue-->dmaienc_h264-->rtph264pay-->udpsink(streaming)
> 
> and i wish to initiate and stop recording to this pipeline.
> Recording has turned out to be more tedious .There are 4 approaches I have
> tried out for this:
> 1)First Approach 
> On start recording command
>  A recording bin is created with a event probe attached to it using :
> gst_pad_add_probe (pipedata.vsrcpad,
> GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM,G_CALLBACK(drop_eos_probe),pipeline,
> NULL);
> |----------------------------------------------------------|
> |recording bin                                             |
> |                                                          |
> |   queue-->dmaienc_h264-->qtmux-->filesink                |
> |                                                          |
> |                                                          |
> |----------------------------------------------------------|
>  
> and it is attached to the tee by requesting a pad from it when the start
> command is received.
> On the stop command(send 5 over socket) the bin is unlinked and removed from
> the pipeline.
> The following are the steps involved in it:
> 1)call a stop encoding function
> 2)send EOS to the recording bin  .
> 4)In the event probe callback function unlink the pads and remove the event
> probe
> 5)the recording bin is removed from the pipeline.
> 6)the recording bin is set to null and unref.
> 
> From what I read at the site:
> https:/-add/developer.pidgin.im/ticket/13237 
> A recommended solution is to use event probes.However the above code ended
> up with errors in compiling due to undefined references to probing flags set
> up in gst_pad_add_probe()function.
> according to https://developer.gnome.org/gstreamer/unstable/GstPad.html
> the gst pad events hav eto be explicitly enabled.

Note that the API documentation there is for GStreamer 1.0, and you
might be using the old 0.10, which has slightly different API for this
kind of stuff. This would explain the linking/compile errors anyway.


> 2)Second Approach:
>   tried using gst_pad_set_blocked_async()
> here on start recording:
> 1)create the recording bin
> 2)get static pad to recording bin
> 3)set its state to playing
> 4)add recording bin to pipeline
> 5)get request pad to tee
> 6)link it to recording bin
> 
> In this approach 
> On the stop command 
> The following are the steps involved in it:
> 1)block the tee pad connected to bin using gst_pad_set_blocked_async()
> 2)inside the callback function unlink the tee pad connected to the recording
> bin ghost pad.
> 3)send EOS to the recording bin  .
> 4)unblock the requested tee pad and release it.
> 5)the recording bin is removed from the pipeline.
> 6)the recording bin is set to null and unref.
> 
> The problem with this approach is that the recording works initially for a
> few times .Eventually however the recording hangs at
> gst_pad_set_blocked_async() not calling the blocking callback function as
> expected and the recording bin  fails to get the EOS. Sometimes the
> application crashes with a memory backtrace message(log attched with mail).

Hard to say what the problem is without more info. You shouldn't have to
block the tee source pad here, you should be able to just unlink the tee
srcpad from the recording bin without blocking. (tee should not error
out as long as there is still another pad that's linked.) Then you
should be able to just remove/release the request pad.

Blocking should not be required (but I know it had to be fixed at some
point, so make sure you're using at least the latest 0.10 versions if
you're using 0.10).


> 3)Third Solution:
> 
> As an alternative approach I have also tried not to unref the bins at the
> end and add the same bin to the pipeline the next time recording/capture
> command is received. With this approach I find the
> gst_pad_set_blocked_async() function not calling the callback function and
> the threads remain deadlocked.

In general, I would always create new elements. You might run into
"interesting" bugs if you re-use elements, since very few people do that
systematically. If the blocked_async function is never called, that
usually means there is no data flow. (Or the state is somehow messed up,
maybe you didn't unblock when cleaning up or something?)


> 4) fouth approach
> to the tee element fakesink is attached initially and on user command to
> start recording fakesink is replaced by the recording bin .
> 
> 
> I have also read that blocking a tee element is not necessary and we can
> directly link and unlink elements to tee without affecting the running
> pipeline.Not blocking the tee however has resulted in freezing the entire
> pipeline after a definite no. of times.
> 
> I would be grateful if somebody takes time to go through this.Kindly let me
> know which of these approaches are more feasible.I need to capture images
> too.

You might also want to have a look at the camerabin2 element, which does
things like this (on-the-fly encoding/recording) as well.

0.10 is no longer maintained, so expect limited interest in
investigating this in detail.

 Cheers
  -Tim