adding filesrc inputs dinamycally to videomixer

[Sebastian Dröge]

On Do, 2014-01-16 at 18:57 -0200, Lautaro Woites wrote:
> 2014/1/15 Sebastian Dröge <sebastian at centricular.com>
> 
> > On Di, 2014-01-14 at 17:41 -0200, Lautaro Woites wrote:
> > > Hi people,
> > >
> > > I'm trying to add inputs to videomixer from filesrc dynamically.
> > > I have a videotestsrc as background (with is-live=TRUE).
> > > When I want to add a new input I create a bin with
> > > filesrc, decodebin, videorate and videoconvert.
> > > Then I request a pad on the mixer and I link it to the bin.
> > >
> > > It works  OK but not as I need. Every time I add a new input to the mixer
> > > the video file start from the current running time and not from the
> > > beginning as I expected.
> > >
> > > I've tried to replace the first SEGMENT event at the decodebin src pad
> > with
> > > a pad probe and replace it with a new event where start=0 and end=-1. But
> > > it seems to not make any difference.
> > > Also I've tried to replace the segment with a new one where the
> > > segment.base=<running_time_from_the_pipeline>, but the pipeline freezes.
> > > The log shows that the new videomixer:sink receives the segment event and
> > > then both mixer's sinks sent a qos event.
> > >
> > > I've tried two ways for replace the segment event, the first one was to
> > > drop the first event(returning GST_PAD_PROBE_DROP) and send a new one
> > from
> > > the app. (Seeing the logs the videomixer receives the two segment
> > events).
> > > The other way was to replace de event on the GstPadProbeInfo on the
> > probe.
> >
> > Easier would probably be to adjust the pad offsets on the new pads, i.e.
> > using gst_pad_set_offset(). Note that this only works for positive
> > offsets currently (which is what you want), unless you use 1.2.3 (or
> > latest 1.2 branch or git master branch).
> >
> >
> Thank you very very match Sebastian!
> 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).
> The log shows me that the decoder was dropping frames because QOS events.
> So now I'm dropping the QOS events at decoder's src pad and finally it
> works!!!!
> 
> 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.
> 
> Is it a good idea to drop the QOS events on the decoder's src pad?

No :)

Can you file a bug at http://bugzilla.gnome.org with a test case? I
assume this happens because of the QoS translation that happens in
videomixer. It might not handle the offsets properly yet.

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140119/7d235c48/attachment-0001.pgp>