Clarification on HLS/DASH config. properties in order to reduce lag of Live stream
Hello,
I have a problem with lag/delay
on HLS is almost 60 sec and
while on DASH I've managed to reduce it to 10 seconds.
I'm streaming from Android with GoCoder (or other Android sources) and always using 1 second key frame interval (which I understand is the minimum since it expects an int)
As suggested on these forum posts
How to configure Apple HLS packetization (cupertinostreaming)
How To reduce delay in HLS
HLS From Live Camera
I've tried reducing these HLS settings
but didn't succed in reducing the lag. I only got a choppier and more unreliable experience on a native <video> tag.
The log shows that in spite of these settings I still have a 10 second duration of the chunk (If I'm understanding well what this means)
1- Are there other parameters to set in order to reduce the lag in HLS Live streams? We are aiming at maximum 5-10 seconds
What about the "HTTP Streamers Cupertino Settings"
I tried also with the mpeg dash version (with the bitdash player)
and changed just the
This managed to reduce the lag to 10 seconds, instead of 60
I left the
As changing them created choppy unreliable experiences
2- Are there other parameters to set in order to reduce the lag in DASH Live streams?
3- Am I understanding these properties right?
3.1 - I should see a 5 second lag, instead of a 10 second lag, right?
I know we should take into account other possible lag sources that pile up, but how is it possible that, in the same conditions, if I switch to an RTSP to a flash video player the lag drops down to 3 seconds??
4 - Are MPEG DASH & HLS so much slower? (like 3 times at best?)
5 - what does mpegdashPlaylistChunkCount or cupertinoPlaylistChunkCount actually do?
Thanks in advance for the help and clarifications
I have a problem with lag/delay
on HLS is almost 60 sec and
while on DASH I've managed to reduce it to 10 seconds.
I'm streaming from Android with GoCoder (or other Android sources) and always using 1 second key frame interval (which I understand is the minimum since it expects an int)
As suggested on these forum posts
I've tried reducing these HLS settings
cupertinoChunkDurationTarget to 1000 ms cupertinoMaxChunkCount to 3 (default 10) cupertinoPlaylistChunkCount to 1 (default 3)
but didn't succed in reducing the lag. I only got a choppier and more unreliable experience on a native <video> tag.
The log shows that in spite of these settings I still have a 10 second duration of the chunk (If I'm understanding well what this means)
LiveStreamPacketizerSanJose.endChunkTS[live/_definst_/guide.stream]: Add chunk: id:3 a/v/k:435/181/12 duration:10084
1- Are there other parameters to set in order to reduce the lag in HLS Live streams? We are aiming at maximum 5-10 seconds
What about the "HTTP Streamers Cupertino Settings"
I tried also with the mpeg dash version (with the bitdash player)
and changed just the
mpegdashChunkDurationTarget to 1000 ms (instead of the 10.000 default)
This managed to reduce the lag to 10 seconds, instead of 60
I left the
mpegdashMaxChunkCount default 5 mpegdashPlaylistChunkCount default 5
As changing them created choppy unreliable experiences
2- Are there other parameters to set in order to reduce the lag in DASH Live streams?
3- Am I understanding these properties right?
lag = mpegdashChunkDurationTarget * mpegdashMaxChunkCount
= 1000 ms * 5 = 5000ms = 5 seconds
3.1 - I should see a 5 second lag, instead of a 10 second lag, right?
I know we should take into account other possible lag sources that pile up, but how is it possible that, in the same conditions, if I switch to an RTSP to a flash video player the lag drops down to 3 seconds??
4 - Are MPEG DASH & HLS so much slower? (like 3 times at best?)
5 - what does mpegdashPlaylistChunkCount or cupertinoPlaylistChunkCount actually do?
Thanks in advance for the help and clarifications
Hi,
Unfortunately with HTTP streams that are chunk based there is always going to be more latency than say with RTMP or RTSP. Having very small chunk duration targets is the way to go, but if you go too small then you may get choppy playback. Ensure that the keyframe is a factor of chunk duration target (which if set to 1 is obviously the case). The articles you linked to are really the best source for describing the various properties, and it really is a matter of experimenting with both the encoder and the chunk settings until you find a stable mix, but don't expect to get close to RTMP or RTSP latencies. This delay is not just at the Wowza level but also at the player level as the spec requires a minimum number of chunks before it begins the stream. The HLS RFC is a good place to start if you wish to understand the internals of chunk based HTTP streaming delivery.
Paul
Unfortunately with HTTP streams that are chunk based there is always going to be more latency than say with RTMP or RTSP. Having very small chunk duration targets is the way to go, but if you go too small then you may get choppy playback. Ensure that the keyframe is a factor of chunk duration target (which if set to 1 is obviously the case). The articles you linked to are really the best source for describing the various properties, and it really is a matter of experimenting with both the encoder and the chunk settings until you find a stable mix, but don't expect to get close to RTMP or RTSP latencies. This delay is not just at the Wowza level but also at the player level as the spec requires a minimum number of chunks before it begins the stream. The HLS RFC is a good place to start if you wish to understand the internals of chunk based HTTP streaming delivery.
Paul
Thanks Paul for the clarification.
I'm guessing MPEG Dash has the same problem as HLS and it is "chunk" based, right?
If this is the case, neither HLS nor MPEG Dash will ever get the speeds of an RTMP, right?
... and people say "flash is dead" :) ...
I'm guessing MPEG Dash has the same problem as HLS and it is "chunk" based, right?
If this is the case, neither HLS nor MPEG Dash will ever get the speeds of an RTMP, right?
... and people say "flash is dead" :) ...
Hi,
They are not real-time protocols for sure, and were not designed to be. RTMP and RTSP protocols are real-time by name and by design.
Daren
They are not real-time protocols for sure, and were not designed to be. RTMP and RTSP protocols are real-time by name and by design.
Daren
