decodebin - static linking of decoder and sink
ash20001 at hotmail.com
Wed Apr 27 06:50:47 UTC 2016
I tried the "typefind - appsrc ! typefind ! h264parse ! omx_h264dec ! xvimagesink",but after submitting frame 2 i get:
Error Internal data flow error.Debugging info: gstbasesrc.c(2963): gst_base_src_loop (): /GstPipeline:pipeline/GstAppSrc:appsrc:streaming task paused, reason not-negotiated (-4)Error No valid frames found before end of streamDebugging info: gstbaseparse.c(1155): gst_base_parse_sink_event_default (): /GstPipeline:pipeline/GstH264Parse:h264parse
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
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.
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel