decodebin - static linking of decoder and sink

[Ash 20001]

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. 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

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 · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ash 20001]

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: [hidden email]
To: [hidden email]
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 · http://www.centricular.com
 

_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ash 20001]

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

---

From: [hidden email]
To: [hidden email]
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: [hidden email]
To: [hidden email]
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 · http://www.centricular.com
 

_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Di, 2016-04-26 at 10:07 -0700, Ash 20001 wrote:
> Or more specifically how to statically link decoder to sink via
> decodebin but without waiting for the pad-added signal.

You can't :) The only other option is to statically link a pipeline
yourself without decodebin, e.g.

  appsrc ! yourh264dec ! xvimagesink

That shouldn't make any difference regarding latency though, decodebin
provides you pad-added at latest once the first decoded frame is
available.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ash 20001]

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.

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?

Subject: Re: decodebin - static linking of decoder and sink
From: [hidden email]
To: [hidden email]
Date: Wed, 27 Apr 2016 09:06:01 +0300

On Di, 2016-04-26 at 10:07 -0700, Ash 20001 wrote:
> Or more specifically how to statically link decoder to sink via
> decodebin but without waiting for the pad-added signal.
 
You can't :) The only other option is to statically link a pipeline
yourself without decodebin, e.g.
 
  appsrc ! yourh264dec ! xvimagesink
 
That shouldn't make any difference regarding latency though, decodebin
provides you pad-added at latest once the first decoded frame is
available.
 
-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
 

_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

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.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ash 20001]

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.

Subject: Re: decodebin - static linking of decoder and sink
From: [hidden email]
To: [hidden email]
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.
 
-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
 

_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ash 20001]

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 stream

Debugging info: gstbaseparse.c(1155): gst_base_parse_sink_event_default (): /GstPipeline:pipeline/GstH264Parse:h264parse

Subject: Re: decodebin - static linking of decoder and sink
From: [hidden email]
To: [hidden email]
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.
 
-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
 

_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Di, 2016-04-26 at 23:50 -0700, Ash 20001 wrote:
> I tried the "typefind - appsrc ! typefind ! h264parse ! omx_h264dec !
> xvimagesink", but after submitting frame 2 i get:

Get a debug log and check where the not-negotiated comes from. Most
likely you need at least a videoconvert between decoder and sink.

Also your pipeline graph is *not* from decodebin but from your manual
pipeline.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ash 20001]

I tried adding a videoconvert but it made no difference, will have to get the log tomorrow and let you know.

The pipeline graph was created by "gst-launch-1.0 filesrc location=out.h264 ! h264parse ! decodebin ! xvimagesink". Where out.h264 is a single IFrame.

Subject: Re: decodebin - static linking of decoder and sink
From: [hidden email]
To: [hidden email]
Date: Wed, 27 Apr 2016 09:55:21 +0300

On Di, 2016-04-26 at 23:50 -0700, Ash 20001 wrote:
> I tried the "typefind - appsrc ! typefind ! h264parse ! omx_h264dec !
> xvimagesink", but after submitting frame 2 i get:
 
Get a debug log and check where the not-negotiated comes from. Most
likely you need at least a videoconvert between decoder and sink.
 
Also your pipeline graph is *not* from decodebin but from your manual
pipeline.
 
-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
 

_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ash 20001]

Hi Sebastian,

Here is the pipeline picture from within my C++ app using appsrc where I am trying to statically create pipeline. 

Also attached is the DEBUG log (zipped)...I think the key portion is this:

D/GST_LOG (22134): : (0) > [_0_] 0:00:05.562008914 0xb423b690 DEBUG               GST_CAPS gstpad.c:5034:pre_eventfunc_check:<omx_h264dec:sink> caps video/x-h264, width=(int)1280, height=(int)720, framerate=(fraction)0/1, parsed=(boolean)true, stream-format=(string)avc, alignment=(string)au, level=(string)4, profile=(string)high, codec_data=(buffer)01640028ffe1000b67640028ac34ec05005b9001000468ea438b not accepted

I am not sure why this is not accepted as the sink pad on omx_h264dec says:

  SINK template: 'sink'

    Availability: Always

    Capabilities:

      video/x-h264

                  width: [ 0, 1920 ]

                 height: [ 0, 1088 ]

               maxwidth: [ 0, 1920 ]

              maxheight: [ 0, 1088 ]

              framerate: [ 0/1, 2147483647/1 ]

Subject: Re: decodebin - static linking of decoder and sink
From: [hidden email]
To: [hidden email]
Date: Wed, 27 Apr 2016 09:55:21 +0300

On Di, 2016-04-26 at 23:50 -0700, Ash 20001 wrote:
> I tried the "typefind - appsrc ! typefind ! h264parse ! omx_h264dec !
> xvimagesink", but after submitting frame 2 i get:
 
Get a debug log and check where the not-negotiated comes from. Most
likely you need at least a videoconvert between decoder and sink.
 
Also your pipeline graph is *not* from decodebin but from your manual
pipeline.
 
-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
 

_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Mi, 2016-04-27 at 14:24 -0700, Ash 20001 wrote:

> Hi Sebastian,
> Here is the pipeline picture from within my C++ app using appsrc
> where I am trying to statically create pipeline. 
> Also attached is the DEBUG log (zipped)...I think the key portion is
> this:
>
> D/GST_LOG (22134): : (0) > [_0_] 0:00:05.562008914 0xb423b690 DEBUG  
>             GST_CAPS
> gstpad.c:5034:pre_eventfunc_check:<omx_h264dec:sink> caps video/x-
> h264, width=(int)1280, height=(int)720, framerate=(fraction)0/1,
> parsed=(boolean)true, stream-format=(string)avc,
> alignment=(string)au, level=(string)4, profile=(string)high,
> codec_data=(buffer)01640028ffe1000b67640028ac34ec05005b9001000468ea43
> 8b not accepted
>
> I am not sure why this is not accepted as the sink pad on omx_h264dec
> says:
>   SINK template: 'sink'
>     Availability: Always
>     Capabilities:
>       video/x-h264
>                   width: [ 0, 1920 ]
>                  height: [ 0, 1088 ]
>                maxwidth: [ 0, 1920 ]
>               maxheight: [ 0, 1088 ]
>               framerate: [ 0/1, 2147483647/1 ]

The caps are missing the maxwidth/maxheight fields. Whatever decoder
you're using there is using non-standard caps fields and as such can't
work with any of the other GStreamer elements out of the box.

You should complain to whoever provided you this decoder.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ash 20001]

Is there an easy way I can fix this? Just add maxwidth/maxheight to the caps?

How does decodebin do it?

Subject: Re: decodebin - static linking of decoder and sink
From: [hidden email]
To: [hidden email]
Date: Thu, 28 Apr 2016 09:25:46 +0300

On Mi, 2016-04-27 at 14:24 -0700, Ash 20001 wrote:

> Hi Sebastian,
> Here is the pipeline picture from within my C++ app using appsrc
> where I am trying to statically create pipeline. 
> Also attached is the DEBUG log (zipped)...I think the key portion is
> this:
> 
> D/GST_LOG (22134): : (0) > [_0_] 0:00:05.562008914 0xb423b690 DEBUG  
>             GST_CAPS
> gstpad.c:5034:pre_eventfunc_check:<omx_h264dec:sink> caps video/x-
> h264, width=(int)1280, height=(int)720, framerate=(fraction)0/1,
> parsed=(boolean)true, stream-format=(string)avc,
> alignment=(string)au, level=(string)4, profile=(string)high,
> codec_data=(buffer)01640028ffe1000b67640028ac34ec05005b9001000468ea43
> 8b not accepted
> 
> I am not sure why this is not accepted as the sink pad on omx_h264dec
> says:
>   SINK template: 'sink'
>     Availability: Always
>     Capabilities:
>       video/x-h264
>                   width: [ 0, 1920 ]
>                  height: [ 0, 1088 ]
>                maxwidth: [ 0, 1920 ]
>               maxheight: [ 0, 1088 ]
>               framerate: [ 0/1, 2147483647/1 ]
 
The caps are missing the maxwidth/maxheight fields. Whatever decoder
you're using there is using non-standard caps fields and as such can't
work with any of the other GStreamer elements out of the box.
 
You should complain to whoever provided you this decoder.
 
-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
 

_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Mi, 2016-04-27 at 23:42 -0700, Ash 20001 wrote:
> Is there an easy way I can fix this? Just add maxwidth/maxheight to
> the caps?
>
> How does decodebin do it?

The capsfilter between parser and decoder in decodebin apparently does
it, but it's wrong that it does :) It should also fail in decodebin.
You can work around that with a capssetter element, but it would be
better to just get this fixed in the decoder.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ash 20001]

Hi Sebastian,

Thank you so much for your help, using the capssetter and specifying max_width, max_height worked to build a static pipeline without decodebin, however as you pointed out earlier I still have the same problem. I have to submit a 2nd frame before anything outputs on the screen. So I am back to square one :).

Subject: Re: decodebin - static linking of decoder and sink
From: [hidden email]
To: [hidden email]
Date: Thu, 28 Apr 2016 09:49:50 +0300

On Mi, 2016-04-27 at 23:42 -0700, Ash 20001 wrote:
> Is there an easy way I can fix this? Just add maxwidth/maxheight to
> the caps?
> 
> How does decodebin do it?
 
The capsfilter between parser and decoder in decodebin apparently does
it, but it's wrong that it does :) It should also fail in decodebin.
You can work around that with a capssetter element, but it would be
better to just get this fixed in the decoder.
 
-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
 

_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-4]

Le mercredi 27 avril 2016 à 09:55 +0300, Sebastian Dröge a écrit :

> On Di, 2016-04-26 at 23:50 -0700, Ash 20001 wrote:
> > I tried the "typefind - appsrc ! typefind ! h264parse ! omx_h264dec
> !
> > xvimagesink", but after submitting frame 2 i get:
>
> Get a debug log and check where the not-negotiated comes from. Most
> likely you need at least a videoconvert between decoder and sink.
>
> Also your pipeline graph is *not* from decodebin but from your manual
> pipeline.

You cannot typefind an h264 AVC stream. Only byte-stream format can be
instrospected (and byte-stream cost 1 frame latency in the parser, as
you need to wait for the next start-code before you submit the first
one). Instead, set caps property on appsrc correctly.

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-4]

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: [hidden email]
To: [hidden email]
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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-deve

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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: [hidden email]
To: [hidden email]
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: [hidden email]
To: [hidden email]
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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-deve

_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-4]

Le dimanche 01 mai 2016 à 18:55 -0700, Ash 20001 a écrit :
> 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.

Ok then, I do trust the zerolatency tuning. You are better to dig into
gst-omx code. It might hardcode an extra latency buffer. Otherwise,
check how the latency is calculated there and it could help you fix
your OMX compoment.

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel