start/stop recording from live preview+stream

Angel Martin amartin at vicomtech.org
Wed Sep 18 02:52:07 PDT 2013


Maybe the code of the thread titled "Changing filesink location after a mux
with many inputs" can help you.

http://gstreamer-devel.966125.n4.nabble.com/Changing-filesink-location-after-a-mux-with-many-inputs-td4656116.html


2013/9/6 rashmi <rashmi at tatapowersed.com>

> 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.
>
> 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).
>
> 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.
>
> 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.
> If the first approach is suitable,then how can  I go about removing the
> compile time errors.
>
>
>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/start-stop-recording-from-live-preview-stream-tp4661145p4661885.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130918/13be14d7/attachment-0001.html>


More information about the gstreamer-devel mailing list