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 :-)
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
