decodebin - static linking of decoder and sink

Ash 20001 ash20001 at
Tue Apr 26 17:07:23 UTC 2016

Or more specifically how to statically link decoder to sink via decodebin but without waiting for the pad-added signal.

From: ash20001 at
To: gstreamer-devel at
Subject: RE: decodebin - static linking of decoder and sink
Date: Tue, 26 Apr 2016 07:04:38 -0700

The stream is just an elementary H264 stream and I am told that this decoder can handle 1 frame of latency with a special property which I am settings.If the decoder can handle this, how do I do it?

Subject: Re: decodebin - static linking of decoder and sink
From: sebastian at
To: gstreamer-devel at
Date: Tue, 26 Apr 2016 11:16:41 +0300

On Di, 2016-04-26 at 01:11 -0700, Ash 20001 wrote:
> Hello everyone!
> I have a pipeline currently using appsrc ! decodebin ! xvimagesink,
> which processes Raw H264 frames. Problem is I have to feed in at
> least 2 frames of H264 buffers to appsrc before decodebin will emit
> its pad-added signal and link the pads between the decoder (which is
> a HW decoder element) and the xvimagesink. 
> 1. Is there anyway to statically link the decoder and xvimagesink
> pads ahead of time so I don't have to wait for 2 frames before it is
> done?
> 2. Or is there an alternative to minimize the 2 frame latency?
> Ideally I want to push 1 frame and have that render via xvimagesink
> immediately. 
This completely depends on the actual decoder that is used and the
properties of the stream. Most likely your decoder has 2 frames of
latency on the stream you're feeding it, which might be possible to
optimize in this specific decoder or it's an intrinsic property of this
specific stream.
Sebastian Dröge, Centricular Ltd ·

gstreamer-devel mailing list
gstreamer-devel at 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list