You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 12, 2019. It is now read-only.
We have progress events coming from mediaSegmentRequest that is quite handy. We should leverage that data in that event to decide when to abort a segment request and trigger a rendition switch.
Acceptance Criteria
Implement the feature
Test it using bandwidth simulator
Do a managed release
How
Improves ABR -
Start up time should improve in low bandwidth scenarios
Ability to respond to catastrophic bandwidth drops should improve
Should lower rebuffering stats (time and count)
Listen for progress events and judge the ability for the player to complete the request in a reasonable time
We currently have a hard-timeout. That should be unnecessary in this new world. It might make sense to keep it in the event that progress events are not sent or if they don't contain the kind of data that would allow us to make decisions.
We need to update the bandwidth property and trigger the bandwidthchange if we decide to abort because otherwise playlist selection doesn't run
Notes
Bandwidth starts off REALLY low on requests
The bandwidth simulator DOES simulate progress events (you are welcome)
The text was updated successfully, but these errors were encountered:
We have progress events coming from
mediaSegmentRequest
that is quite handy. We should leverage that data in that event to decide when to abort a segment request and trigger a rendition switch.Acceptance Criteria
How
bandwidth
property and trigger thebandwidthchange
if we decide to abort because otherwise playlist selection doesn't runNotes
The text was updated successfully, but these errors were encountered: