-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve support for low-latency DASH live streams #4904
Comments
Hi @ojw28 When playing CMAF close to live edge, segments will be downloaded when it's not complete. This makes defaultDandwidthMeter underestimate bandwidth as it's estimation logic is (segment size) / (elapsed time), and eventually exoplayer will drop video quality. Do you have any plan to implement bandwidth estimation logic for CMAF? |
We'll look into supporting low-latency live streaming techniques soon. The problem you mention is one of things that need to be solved. We'll post this issue once we have better support for low-latency DASH streams. |
We published our design doc on our webpage - open for comments! |
It will be great to have this support for live streams - is there any update on the planned timeline for delivery of these feature?? |
We moved this feature a bit further down our priority list and will probably only get around to finish the started work later this year. Please subscribe to this issue to see any updates. Thanks. |
Issue: #4904 PiperOrigin-RevId: 336838559
Issue: #4904 PiperOrigin-RevId: 336839370
Issue: #4904 PiperOrigin-RevId: 336839908
Use default implementation otherwise and forward chosen implementation to internal player. Issue: #4904 PiperOrigin-RevId: 336840530
Issue: #4904 PiperOrigin-RevId: 336841049
Issue: #4904 PiperOrigin-RevId: 336841791
This allows a LoadControl to start playback earlier if the target live offset is very low. Issue: #4904 PiperOrigin-RevId: 336863824
Issue: #4904 PiperOrigin-RevId: 337046645
Issue: #4904 PiperOrigin-RevId: 337047518
Issue: #4904 PiperOrigin-RevId: 337048010
The available duration used a "live edge" that was calculated in the previous iteration and was thus quite old. Also it also used the end of the last available segment, but the actually available duration for buffering needs to be clamped to the current live edge for low-latency streams. Issue: #4904 PiperOrigin-RevId: 337812621
The current caluclation was comparing Unix time with period time. Fix it by always comparing against period time. Issue: #4904 PiperOrigin-RevId: 338235754
Issue: #4904 PiperOrigin-RevId: 338249499
Issue: #4904 PiperOrigin-RevId: 338669087
This allows the user and the media to define bounds in which the live offset can vary. Issue: #4904 PiperOrigin-RevId: 339214605
Issue: #4904 PiperOrigin-RevId: 339215091
In order to ensure we can update the values for new manifests but still use the user provided override, we need to save the original and the updated MediaItem seperately. And in order to incorporate the existing logic for the min/max supported live offset, which we already use to correct the target offset, also move both places together so that all the adjustment happens in one place. Logical adjustments to the previous min/max supported live offset: - Use the user-provided MediaItem values if set - Use the newly parsed ServiceDescription values if available. - Limit the minimum to 0 if the current time is in the window and we can assume to have low-latency stream. - Add minBufferTime from the manifest to ensure we don't reduce the live offset below this value. Issue: #4904 PiperOrigin-RevId: 339452816
Issue: #4904 PiperOrigin-RevId: 340653126
Issue: #4904 PiperOrigin-RevId: 340654178
To check what is safely possible we keep track of the live offset corresponding to the buffered duration and only deecrease the target offset to a safe margin from the buffered duration. Also, while still possible (i.e. while the actual offset is larger than the safe margin), we increase the target offset to the safe margin to avoid rebuffers to start with. Issue: #4904 PiperOrigin-RevId: 341396492
Closing this feature request as it's fully implemented and will be released in 2.13.0. |
Hi! I tested and received latency around 3-4 sec! That is good! But, i tested with high speed connection. I'm interesting in ABR manager and LL playback. Did you develop "Trial-and-error approaches" or "Falling back using the playback speed control to get a new bandwidth estimate in regular intervals" technics mentioned in design doc ? |
@RamilGabdrakhmanov None of the two approaches actually. Playback will automatically fall back if the network speed isn't sufficient, so we will get new bandwidth estimates for slower networks and the player can switch down to a lower quality. But there is currently no mechanism to check whether switching up to a better quality is possible. We just rely on the bandwidth measurements we get from non-latency segments. For example we get some bandwidth estimate at the beginning of playback, which allows to start (or to quickly adapt) to a better quality if possible. But if your conditions improve considerably in the middle of playback while we are only loading low-latency segments, the player wouldn't notice at the moment. |
Thank you! That is clear |
We have no immediate plans to develop or implement a more advanced algorithm for this. It's also worth noting that we need to be careful to not over-specialize our approach here as it needs to work for all kinds of live streams with unknown combinations of bitrates etc. |
This issue tracks allowing playback of DASH live streams with lower latency (i.e. closer to the live edge). It's spun out from #4839. See in particular: #4839 (comment) which lists some items, although I'm not promising they're all correct! The referenced patch may also be helpful as a guide.
The text was updated successfully, but these errors were encountered: