<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/15 Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Di, 2014-01-14 at 17:41 -0200, Lautaro Woites wrote:<br>
> Hi people,<br>
><br>
> I'm trying to add inputs to videomixer from filesrc dynamically.<br>
> I have a videotestsrc as background (with is-live=TRUE).<br>
> When I want to add a new input I create a bin with<br>
> filesrc, decodebin, videorate and videoconvert.<br>
> Then I request a pad on the mixer and I link it to the bin.<br>
><br>
> It works  OK but not as I need. Every time I add a new input to the mixer<br>
> the video file start from the current running time and not from the<br>
> beginning as I expected.<br>
><br>
> I've tried to replace the first SEGMENT event at the decodebin src pad with<br>
> a pad probe and replace it with a new event where start=0 and end=-1. But<br>
> it seems to not make any difference.<br>
> Also I've tried to replace the segment with a new one where the<br>
> segment.base=<running_time_from_the_pipeline>, but the pipeline freezes.<br>
> The log shows that the new videomixer:sink receives the segment event and<br>
> then both mixer's sinks sent a qos event.<br>
><br>
> I've tried two ways for replace the segment event, the first one was to<br>
> drop the first event(returning GST_PAD_PROBE_DROP) and send a new one from<br>
> the app. (Seeing the logs the videomixer receives the two segment events).<br>
> The other way was to replace de event on the GstPadProbeInfo on the probe.<br>
<br>
</div>Easier would probably be to adjust the pad offsets on the new pads, i.e.<br>
using gst_pad_set_offset(). Note that this only works for positive<br>
offsets currently (which is what you want), unless you use 1.2.3 (or<br>
latest 1.2 branch or git master branch).<br>
<br></blockquote><div><br>Thank you very very match Sebastian!<br>I  set the offset on the pad and the result was that the video played for 1 second and then dissapeared (because the arrival of EOS to the pad).<br>The log shows me that the decoder was dropping frames because QOS events.<br>

So now I'm dropping the QOS events at decoder's src pad and finally it works!!!!<br><br></div>Why the videomixer is sending QOS events upstream? Viewing the logs I read that the buffers arrives to late (I compared log's message time  with mixer's mesage) but I've tried to set the pad offset to a value greater than the current_running_time and the QOS still arriving to the decoder. Also I've tried to pause the pipe before adding the new input and then play it again.<br>
<br>Is it a good idea to drop the QOS events on the decoder's src pad?<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


If you want to adjust the running time manually by intercepting the<br>
segment events it should in theory work if you add the running time when<br>
the videomixer pad was added to segment.base. Just overriding any<br>
previous value there will break synchronisation.<br></blockquote><div> </div>I've tried this approach too and I have QOS on the decoder, ignoring it like on the previous approach it didn't work. The videotestsrc plays normally but, the new input plays for a second and then freezes. Then periodically updates one frame. The update period seems to be the running_time when I added the new input.<div>
 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you get problems with QoS you should check what videomixer calculates<br>
as running time for the buffers on the new pad and if they are what you<br>
expect. If not debug if the segments received in videomixer are what you<br>
expect and the buffer timestamps too.
  </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also check the code of gst_segment_to_running_time() to understand how<br>
this translation works, or see draft-synchronization.txt in the<br>
GStreamer design documents.<br>
<span><font color="#888888"><br></font></span></blockquote><div> </div><div>Thanks! I will read it.<br></div><div> </div><div><br></div><div>Thank you again for your time!<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><font color="#888888">
--<br>
Sebastian Dröge, Centricular Ltd - <a href="http://www.centricular.com" target="_blank">http://www.centricular.com</a><br>
Expertise, Straight from the Source<br>
</font></span><br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">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>
<br></blockquote></div><br></div></div>