<html> <head> <style></style></head> <body class='hmmessage'><div dir='ltr'>Here is the pipeline graph when using decodebin. It contains all the information you ask below.<div>It is properly parsed NAL units, raw h264 elementary stream.<br><div><br><div><br><div>Subject: Re: decodebin - static linking of decoder and sink<br>From: sebastian@centricular.com<br>To: gstreamer-devel@lists.freedesktop.org<br>Date: Wed, 27 Apr 2016 09:34:40 +0300<br><br><pre>On Di, 2016-04-26 at 23:27 -0700, Ash 20001 wrote:<br>> I've tried to do it statically like you suggested but I can never get<br>> it working (it always fails with non-negotiated stream). I have a<br>> pipeline graph of what decodebin creates but I can't convert that to<br>> a static pipeline successfully.<br> <br>Try inserting a typefind between your appsrc and the decoder, and also<br>a h264parse after the typefind and before the decoder. The need for<br>them completely depends on what kind of data and how you provide to the<br>appsrc.<br> <br>What format and how are you providing it to appsrc? h264 byte-stream or<br>avc? Properly parsed into NAL units or AUs per buffer or just random<br>chunks of bytes?<br> <br>> But as you said it doesn't make any difference regarding latency.<br>> Right now it takes two frames before I get the pad-added signal from<br>> decodebin, not one frame. I guess this means the problem is in the<br>> decoder itself?<br> <br>If there is a "problem" at all, maybe this are just the inherent<br>limitations of the stream.<br> <br>-- <br>Sebastian Dröge, Centricular Ltd · <a href="http://www.centricular.com" target="_blank">http://www.centricular.com</a><br> <br></pre><br>_______________________________________________ gstreamer-devel mailing list gstreamer-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</div></div></div></div> </div></body> </html>