Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Improve support for low-latency DASH live streams #4904

Closed
ojw28 opened this issue Oct 3, 2018 · 10 comments
Closed

Improve support for low-latency DASH live streams #4904

ojw28 opened this issue Oct 3, 2018 · 10 comments
Assignees
@tonihei
Labels
enhancement

Comments

@ojw28
Copy link
Contributor

ojw28 commented Oct 3, 2018

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.
@ojw28 ojw28 self-assigned this Oct 3, 2018
@ojw28 ojw28 mentioned this issue Oct 3, 2018
Closed
@AquilesCanta AquilesCanta mentioned this issue Oct 25, 2018
Closed
@tonihei tonihei mentioned this issue Mar 18, 2019
Closed
@jyiu-harmonicinc
Copy link

Hi @ojw28

When playing CMAF close to live edge, segments will be downloaded when it's not complete.
Therefore, time to download whole segment is likely to be duration of segment.

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?

@tonihei tonihei assigned tonihei and unassigned ojw28 Jul 8, 2019
@tonihei
Copy link
Collaborator

tonihei commented Jul 8, 2019

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.

@tonihei tonihei mentioned this issue Jul 16, 2019
Closed
@tonihei
Copy link
Collaborator

tonihei commented Sep 19, 2019

We published our design doc on our webpage - open for comments!

@julianD77
Copy link

It will be great to have this support for live streams - is there any update on the planned timeline for delivery of these feature??

@tonihei
Copy link
Collaborator

tonihei commented Apr 30, 2020

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.

kim-vde pushed a commit that referenced this issue Oct 13, 2020
@christosts @kim-vde
Parse ServiceDescription from DASH manifest
ed87332 
Issue: #4904
PiperOrigin-RevId: 336838559
kim-vde pushed a commit that referenced this issue Oct 13, 2020
@christosts @kim-vde
Add live configuration to MediaItem
13f1f3b 
Issue: #4904
PiperOrigin-RevId: 336839370
kim-vde pushed a commit that referenced this issue Oct 13, 2020
@christosts @kim-vde
Add LivePlaybackSpeedControl interface and default implementation.
867d27f 
Issue: #4904
PiperOrigin-RevId: 336839908
kim-vde pushed a commit that referenced this issue Oct 13, 2020
@christosts @kim-vde
Allow to configure custom LivePlaybackSpeedControl in player builders.
0756f30 
Use default implementation otherwise and forward chosen implementation to
internal player.

Issue: #4904
PiperOrigin-RevId: 336840530
kim-vde pushed a commit that referenced this issue Oct 13, 2020
@christosts @kim-vde
Allow to set live properties on DefaultMediaSourceFactory
0959858 
Issue: #4904
PiperOrigin-RevId: 336841049
kim-vde pushed a commit that referenced this issue Oct 13, 2020
@christosts @kim-vde
Allow speed adjustments close to 1f in SonicAudioProcessor
76b7f76 
Issue: #4904
PiperOrigin-RevId: 336841791
kim-vde pushed a commit that referenced this issue Oct 13, 2020
@christosts @kim-vde
Add targetLiveOffsetUs parameter to LoadControl.shouldStartPlayback
8fdadad 
This allows a LoadControl to start playback earlier if the target
live offset is very low.

Issue: #4904
PiperOrigin-RevId: 336863824
ojw28 pushed a commit that referenced this issue Oct 17, 2020
@christosts @ojw28
Use low latency properties in DashMediaSource
41b58d5 
Issue: #4904
PiperOrigin-RevId: 337046645
ojw28 pushed a commit that referenced this issue Oct 17, 2020
@christosts @ojw28
Improve FakeClock and AutoAdvancingFakeClock
f00584b 
Issue: #4904
PiperOrigin-RevId: 337047518
ojw28 pushed a commit that referenced this issue Oct 17, 2020
@christosts @ojw28
Integrate playback speed control in ExoPlayerImplInternal
c4b346e 
Issue: #4904
PiperOrigin-RevId: 337048010
ojw28 pushed a commit that referenced this issue Oct 20, 2020
@tonihei @ojw28
Fix calculation of available duration in DefaultDashChunkSource
3c68261 
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
ojw28 pushed a commit that referenced this issue Oct 21, 2020
@tonihei @ojw28
Fix calculation for isSegmentAvailableAtFullNetworkSpeed.
057771a 
The current caluclation was comparing Unix time with period time.
Fix it by always comparing against period time.

Issue: #4904
PiperOrigin-RevId: 338235754
ojw28 pushed a commit that referenced this issue Oct 21, 2020
@christosts @ojw28
HlsMediaSourceTest: rename dashMediaItem to hlsMediaItem
a21eb77 
Issue: #4904
PiperOrigin-RevId: 338249499
ojw28 pushed a commit that referenced this issue Nov 2, 2020
@christosts @ojw28
Minor Javadoc fix.
1887983 
Issue: #4904
PiperOrigin-RevId: 338669087
ojw28 pushed a commit that referenced this issue Nov 2, 2020
@tonihei @ojw28
Add min/max live offset to MediaItem.LiveConfiguration.
e571936 
This allows the user and the media to define bounds in which the live offset
can vary.

Issue: #4904
PiperOrigin-RevId: 339214605
ojw28 pushed a commit that referenced this issue Nov 2, 2020
@tonihei @ojw28
Parse min/max live offset from ServiceDescription.
aee7e60 
Issue: #4904
PiperOrigin-RevId: 339215091
ojw28 pushed a commit that referenced this issue Nov 2, 2020
@tonihei @ojw28
Set min/max supported live offset in DashMediaSource.
aab6aef 
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
andrewlewis pushed a commit that referenced this issue Nov 6, 2020
@tonihei @andrewlewis
Limit target buffer to media configured min/max values.
2416d99 
Issue: #4904
PiperOrigin-RevId: 340653126
andrewlewis pushed a commit that referenced this issue Nov 6, 2020
@tonihei @andrewlewis
Increase target live offset when rebuffering.
effbc22 
Issue: #4904
PiperOrigin-RevId: 340654178
kim-vde pushed a commit that referenced this issue Nov 11, 2020
@tonihei @kim-vde
Decrease target live offset if safely possible.
86ae7eb 
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
ojw28 pushed a commit that referenced this issue Dec 23, 2020
@tonihei @ojw28
Add release notes for low-latency features.
ab4c92e 
Issue: #4904
Issue: #5011
PiperOrigin-RevId: 348655288
@tonihei
Copy link
Collaborator

tonihei commented Jan 4, 2021

Closing this feature request as it's fully implemented and will be released in 2.13.0.

@tonihei tonihei closed this as completed Jan 4, 2021
@RamilGabdrakhmanov
Copy link

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