<div dir="ltr">Maybe the code of the thread titled "Changing filesink location after a mux with many inputs" can help you.<div><br></div><div><a href="http://gstreamer-devel.966125.n4.nabble.com/Changing-filesink-location-after-a-mux-with-many-inputs-td4656116.html">http://gstreamer-devel.966125.n4.nabble.com/Changing-filesink-location-after-a-mux-with-many-inputs-td4656116.html</a><br>

</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><br></div></div></div><div class="gmail_quote">2013/9/6 rashmi <span dir="ltr"><<a href="mailto:rashmi@tatapowersed.com" target="_blank">rashmi@tatapowersed.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have a pipeline<br>
v4l2src-->queue-->filtercaps--<br>
                              \<br>
                               -->tee-->queue-->TIDmaivideosink(DVI output)<br>
                                      |<br>
<br>
|-->queue-->dmaienc_h264-->rtph264pay-->udpsink(streaming)<br>
<br>
and i wish to initiate and stop recording to this pipeline.<br>
Recording has turned out to be more tedious .There are 4 approaches I have<br>
tried out for this:<br>
1)First Approach<br>
On start recording command<br>
 A recording bin is created with a event probe attached to it using :<br>
gst_pad_add_probe (pipedata.vsrcpad,<br>
GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM,G_CALLBACK(drop_eos_probe),pipeline,<br>
NULL);<br>
|----------------------------------------------------------|<br>
|recording bin                                             |<br>
|                                                          |<br>
|   queue-->dmaienc_h264-->qtmux-->filesink                |<br>
|                                                          |<br>
|                                                          |<br>
|----------------------------------------------------------|<br>
<br>
and it is attached to the tee by requesting a pad from it when the start<br>
command is received.<br>
On the stop command(send 5 over socket) the bin is unlinked and removed from<br>
the pipeline.<br>
The following are the steps involved in it:<br>
1)call a stop encoding function<br>
2)send EOS to the recording bin  .<br>
4)In the event probe callback function unlink the pads and remove the event<br>
probe<br>
5)the recording bin is removed from the pipeline.<br>
6)the recording bin is set to null and unref.<br>
<br>
>From what I read at the site:<br>
https:/-add/<a href="http://developer.pidgin.im/ticket/13237" target="_blank">developer.pidgin.im/ticket/13237</a><br>
A recommended solution is to use event probes.However the above code ended<br>
up with errors in compiling due to undefined references to probing flags set<br>
up in gst_pad_add_probe()function.<br>
according to <a href="https://developer.gnome.org/gstreamer/unstable/GstPad.html" target="_blank">https://developer.gnome.org/gstreamer/unstable/GstPad.html</a><br>
the gst pad events hav eto be explicitly enabled.<br>
<br>
2)Second Approach:<br>
  tried using gst_pad_set_blocked_async()<br>
here on start recording:<br>
1)create the recording bin<br>
<div class="im">2)get static pad to recording bin<br>
</div>3)set its state to playing<br>
4)add recording bin to pipeline<br>
<div class="im">5)get request pad to tee<br>
6)link it to recording bin<br>
<br>
</div>In this approach<br>
On the stop command<br>
The following are the steps involved in it:<br>
1)block the tee pad connected to bin using gst_pad_set_blocked_async()<br>
2)inside the callback function unlink the tee pad connected to the recording<br>
bin ghost pad.<br>
3)send EOS to the recording bin  .<br>
4)unblock the requested tee pad and release it.<br>
5)the recording bin is removed from the pipeline.<br>
6)the recording bin is set to null and unref.<br>
<br>
The problem with this approach is that the recording works initially for a<br>
few times .Eventually however the recording hangs at<br>
gst_pad_set_blocked_async() not calling the blocking callback function as<br>
expected and the recording bin  fails to get the EOS. Sometimes the<br>
application crashes with a memory backtrace message(log attched with mail).<br>
<br>
3)Third Solution:<br>
<br>
As an alternative approach I have also tried not to unref the bins at the<br>
end and add the same bin to the pipeline the next time recording/capture<br>
command is received. With this approach I find the<br>
gst_pad_set_blocked_async() function not calling the callback function and<br>
the threads remain deadlocked.<br>
<br>
4) fouth approach<br>
to the tee element fakesink is attached initially and on user command to<br>
start recording fakesink is replaced by the recording bin .<br>
<br>
<br>
I have also read that blocking a tee element is not necessary and we can<br>
directly link and unlink elements to tee without affecting the running<br>
pipeline.Not blocking the tee however has resulted in freezing the entire<br>
pipeline after a definite no. of times.<br>
<br>
I would be grateful if somebody takes time to go through this.Kindly let me<br>
know which of these approaches are more feasible.I need to capture images<br>
too.<br>
If the first approach is suitable,then how can  I go about removing the<br>
compile time errors.<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/start-stop-recording-from-live-preview-stream-tp4661145p4661885.html" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/start-stop-recording-from-live-preview-stream-tp4661145p4661885.html</a><br>


<div class="HOEnZb"><div class="h5">Sent from the GStreamer-devel mailing list archive at Nabble.com.<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</div></div></blockquote></div><br></div></div>