[FFmpeg-user] -tune zerolatency has no effect with libx264

[Andy Furniss]

Moritz Barsnick wrote:
> On Wed, Jan 07, 2015 at 00:32:51 +0000, Andy Furniss wrote:
>> https://trac.ffmpeg.org/wiki/StreamingGuide
>>
>> use -tune zerolatency but it has no effect for me, also tested with
>> -b:v ...
>
> I'm by no means an x264 expert, but the encoder tuning may not be
> the only thing to take into consideration:
>
> http://stackoverflow.com/a/20244541 "What you want to do for low
> latency encode is to use CBR, and set the VBV buffer to the size of
> one frame, exactly. This enables a special VBV calculation, if you
> look in the x264 source."
>
> Technical details are here:
> http://x264dev.multimedia.cx/archives/249 and it does sound as if you
> need to do stuff in addition to the "-tune" parameter: "Because with
> –tune zerolatency, single-frame VBV, and intra refresh, x264 can
> achieve end-to-end latency (not including transport) of under 10
> milliseconds for an 800×600 video stream."

Thanks.

It seems that I can get -tune zerolatency to make a difference, but
unlike what is said in the wiki it doesn't help startup latency which is
what I was initially looking at.

The solution is easy I guess keyint=XX, though it still seems to take
longer than it should for a stream to start - maybe ts demuxer.

The "no iframes" –intra-refresh option in comment 10 of the blog is
still terrible for startup latency - one version of mpv would timeout
and give up.

I am glad I haven't really got to get this working :-)

I am lagged to start with I guess usb compression or something.

Players add more to cache udp - possible packet loss without cache
(taking ages for pic to recover without low keyint)

Then there's sound ugh = much more lag and sync issues.

I seem to be in fail mode today, libfdk_aac -profile:a aac_eld seemed to
be a good way to go, but it errors without the fdk latm option - which
then causes mpegts to fail as it doesn't seem to want latm input :-)