[Bug 759470] input-selector: add mode that waits for keyframe before switching inputs

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Dec 18 10:28:37 PST 2015


https://bugzilla.gnome.org/show_bug.cgi?id=759470

--- Comment #14 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Tapas Kumar Kundu from comment #13)
> (In reply to Thiago Sousa Santos from comment #12)
> > 
> > If you switch the pad immediately you will stop pushing buffers on the old
> > pad and downstream will receive no buffers until you get a keyframe, so yes.
> > You get a stall just like it happens today. You need to current active pad
> > to keep pushing buffers until the one you want to activate gets a keyframe.
> > 
> > 
> > No, you will store some state that will mean that you are switching on the
> > next keyframe and that will happen in the _chain() function once a non delta
> > buffer arrives.
> > 
> 
> I really appreicate your help on this. So I will set a flag whenever
> set_active_pad is called. chain function will check for this flag and if the
> flag is set then it will try to detect keyframe on to-be-activeted-pad .
> When keyframe comes for to-be-activated-pad, chain function will signal
> set_active_pad() function to actually set active pad. 
> 
> One question:
> Are chain function and set_active_pad run by two different threads ?

The set_active_pad() is called by the application thread because it is called
from set_property(), the _chain() function is called from the streaming thread
(a thread internal to the pipeline and created by gstreamer).

For your change you will likely have to call the set_active_pad() from the
chain function, there is no problem with that as long as you pay attention to
proper locking/mutex.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list