x264enc bitrate adjustment latency

[Nicolas Dufresne]

Le jeudi 12 mai 2022 à 17:02 +0100, Samuel Hurst a écrit :
> Hello Nicolas,
> 
> On 11/05/2022 19:18, Nicolas Dufresne via gstreamer-devel wrote:
> > Le mercredi 11 mai 2022 à 14:43 +0100, Samuel Hurst via gstreamer-devel a
> > écrit :
> > > 
> > > [snip]
> > > 
> > > videotestsrc horizontal-speed=10 ! \
> > >     video/x-raw,format=NV12,width=1920,height=1080,framerate=25/1 ! \
> > >     x264enc bitrate=10000 speed-preset=ultrafast \
> > >       tune=zerolatency+fastdecode ! \
> > >     queue ! \
> > 
> > This queue will fill in, causing high latency as you observe. Sets is-live=1 on
> > videotestsrc, configure that queue to be smaller.
> > 
> > >     avdec_h264 ! \
> > >     queue ! \
> > >     fpsdisplaysink
> 
> Thanks for offering the suggestion. I've retested with videotestsrc 
> is-live=1, as well as configuring the queue to have a hard limit of a 
> single buffer, as well as removing it entirely, but it doesn't seem to 
> have made a substantial difference, as there's still a definite lag to 
> the setting of the new bitrate parameter and the buffer sizes trending 
> towards a smaller size.
> 
> https://www.dropbox.com/s/mfwnnwpu05awkid/x264-buffer-bitrate-test-is-live-no-queues-10mb-to-8mb.png?dl=0
> 
> Surely the queue size shouldn't have made much difference, as I'm 
> measuring the bitrate at the x264enc src pad with gst-shark, so I'd have 
> seen the instantaneous output of the encoder, before the queue starts to 
> fill up with buffers?

I don't know, I haven't validate that tracer from gst-shark. They should submit
it upstream, so we can review it ;-D

Its possible the bitrate adapter in x264 uses a large window size for bitrate
control (larger window allow for more parallel processing). Perhaps you can ask
on their mailing list ?

> 
> Best regards,
> -Sam