[Libav-user] http streaming latency depends on frame rate
x.morion.x at gmail.com
Wed Jun 13 01:54:04 CEST 2012
2012/6/10 Camera Man <i.like.privacy.too at gmail.com>:
> What player are you using? Most players (e.g. Windows Media Player or
> anything based on the Windows Media Codec infrastructure) will not play
> until they have buffered a few seconds of data (this can be adjusted, but
> not below 1 second if I recall correctly; the default used to be 5 seconds).
I'm using Silverlight SMF player. It have buffering settings, and I've
tuned it to not to buffer anything.
Also I've tried to stream some low frame rate video from Expression
Encoder (a tool that also can produce live Smooth Streaming video),
and with it the latency doesn't depend on frame rate. So the problem
seems to be on the server side of my application, not on the client
> If you are using ffplay / libav / ffmpeg as the decoder, be aware that by
> default it will use a multithreaded decoder in which each frame is decoded
> by a different thread, where the number of threads is the number of cores;
> This configuration introduces a delay of (number of cores) frames in the
> ffplay/ffmpeg decoding process, regardless of any other buffer - by
> switching to single-threaded mode, you can eliminate this delay.
No, the player is in Silverlight, it doesn't support ffmpeg and libav.
> Further, depending on your encoding settings, there will be a delay of
> (number of reference frames). e.g. I have a camera that puts "number of refs
> = 4" in the stream, despite never using more than 1 ref; as a result, every
> conforming h264 decoder introduces a delay of 4 frames. This number is
> stream dependent and can go as high as 16. If you can control your encoder,
> set it to a low-latency mode (which means no B frames, max reorder=0, and
> only 1 reference frame).
Yes, the encoder is configured to low-latency mode: 1 reference frame,
no B-frames (actually even no P-frames, only I-frames), rc-lookahead =
0, sync-lookahead = 0.
Didn't find "max reorder" option neither in libav, nor in x264 encoder.
More information about the Libav-user