adding filesrc inputs dinamycally to videomixer
Lautaro Woites
lauchapc87 at gmail.com
Thu Jan 16 12:57:25 PST 2014
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?
> If you want to adjust the running time manually by intercepting the
> segment events it should in theory work if you add the running time when
> the videomixer pad was added to segment.base. Just overriding any
> previous value there will break synchronisation.
>
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.
> If you get problems with QoS you should check what videomixer calculates
> as running time for the buffers on the new pad and if they are what you
> expect. If not debug if the segments received in videomixer are what you
> expect and the buffer timestamps too.
Also check the code of gst_segment_to_running_time() to understand how
> this translation works, or see draft-synchronization.txt in the
> GStreamer design documents.
>
>
Thanks! I will read it.
Thank you again for your time!
> --
> 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/20140116/043718c7/attachment.html>
More information about the gstreamer-devel
mailing list