decodebin - static linking of decoder and sink

[Ash 20001]

i am using zerolatency preset in x264. i can try the other profile you mentioned but software ffmpeg decode is able to decode frame by frame with no latency.

Subject: Re: decodebin - static linking of decoder and sink
From: nicolas.dufresne at gmail.com
To: gstreamer-devel at lists.freedesktop.org
Date: Sun, 1 May 2016 11:26:56 -0400



Le mardi 26 avril 2016 à 23:40 -0700, Ash 20001 a écrit :Here is the pipeline graph when using decodebin. It contains all the information you ask below.It is properly parsed NAL units, raw h264 elementary stream.

I see that you are using High profile. Are you sure you have properly disabled B-Frames (frame reordering) in your encoder ? That would introduce latency that cannot be removed. Another way around (to make things simple) could be to force your encoder into producing constrained-baseline or baseline, where B-Frames don't exist.


Subject: Re: decodebin - static linking of decoder and sink
From: sebastian at centricular.com
To: gstreamer-devel at lists.freedesktop.org
Date: Wed, 27 Apr 2016 09:34:40 +0300

On Di, 2016-04-26 at 23:27 -0700, Ash 20001 wrote:
> I've tried to do it statically like you suggested but I can never get
> it working (it always fails with non-negotiated stream). I have a
> pipeline graph of what decodebin creates but I can't convert that to
> a static pipeline successfully.
 
Try inserting a typefind between your appsrc and the decoder, and also
a h264parse after the typefind and before the decoder. The need for
them completely depends on what kind of data and how you provide to the
appsrc.
 
What format and how are you providing it to appsrc? h264 byte-stream or
avc? Properly parsed into NAL units or AUs per buffer or just random
chunks of bytes?
 
> But as you said it doesn't make any difference regarding latency.
> Right now it takes two frames before I get the pad-added signal from
> decodebin, not one frame. I guess this means the problem is in the
> decoder itself?
 
If there is a "problem" at all, maybe this are just the inherent
limitations of the stream.
 
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-deve
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160501/bf4fefcf/attachment.html>