<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/19 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 class=""><div class="h5">On Do, 2014-01-16 at 18:57 -0200, Lautaro Woites wrote:<br>
> 2014/1/15 Sebastian Dröge <<a href="mailto:sebastian@centricular.com">sebastian@centricular.com</a>><br>
><br>
> > 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<br>
> > 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<br>
> > from<br>
> > > the app. (Seeing the logs the videomixer receives the two segment<br>
> > events).<br>
> > > The other way was to replace de event on the GstPadProbeInfo on the<br>
> > probe.<br>
> ><br>
> > 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>
> ><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<br>
> 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<br>
> works!!!!<br>
><br>
> Why the videomixer is sending QOS events upstream? Viewing the logs I read<br>
> that the buffers arrives to late (I compared log's message time  with<br>
> mixer's mesage) but I've tried to set the pad offset to a value greater<br>
> than the current_running_time and the QOS still arriving to the decoder.<br>
> Also I've tried to pause the pipe before adding the new input and then play<br>
> it again.<br>
><br>
> Is it a good idea to drop the QOS events on the decoder's src pad?<br>
<br>
</div></div>No :)<br>
<br>
Can you file a bug at <a href="http://bugzilla.gnome.org" target="_blank">http://bugzilla.gnome.org</a> with a test case? I<br>
assume this happens because of the QoS translation that happens in<br>
videomixer. It might not handle the offsets properly yet.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><br></div>I reduced the example and I seen that if I use fakesink as the pipeline's sink the QOS events are not sent.<br>Also if I use some combinations of    mixer ! someencoder ! somemuxer! filesink as the pipeline's sink the QOS events are not sent.<br>
So I think that the videomixer is not the problem. I think the xvimagesink is sending the QOS events and<br>the mixer is only forwarding them.<br><br>Do you want me to upload the example anyway?<br><br></div><div class="gmail_quote">
One more question about this, why the xvimagesink is sending QOS events? The CPU is idle and I put queues before every mixer's<br>sink pad and after the mixer's src pad. <br></div><div class="gmail_quote"><br>P.D: sorry if I made you think that there was a bug :(<div>
<br></div><div>Thanks a lot for your answers.<br></div><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"><div class=""><div class="h5">

--<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>
</div></div><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>
<br></blockquote></div><br></div></div>