adding filesrc inputs dinamycally to videomixer

[Lautaro Woites]

2014/1/19 Sebastian Dröge <sebastian at centricular.com>

> 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.
>
>
I reduced the example and I seen that if I use fakesink as the pipeline's
sink the QOS events are not sent.
Also if I use some combinations of    mixer ! someencoder ! somemuxer!
filesink as the pipeline's sink the QOS events are not sent.
So I think that the videomixer is not the problem. I think the xvimagesink
is sending the QOS events and
the mixer is only forwarding them.

Do you want me to upload the example anyway?

One more question about this, why the xvimagesink is sending QOS events?
The CPU is idle and I put queues before every mixer's
sink pad and after the mixer's src pad.

P.D: sorry if I made you think that there was a bug :(

Thanks a lot for your answers.



> --
> Sebastian Dröge, Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
>
> _______________________________________________
> 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/20140120/d4318e0d/attachment.html>