Fix adaptive switching for live playbacks close to the live edge #3017
Comments
|
It's probably fair to say In the short term: It's possible for you to pass your own In the longer term: @tonihei - Probably something to look at as we try and come up with better ABR logic! |
ojw28
changed the title
|
Thank you very much for your reply! For now, I think were just going to limit the seek position explicitly - but we might also keep playing with the parameters and see how that works out... |
|
@tonihei Is there any updates for this enhancement ? I got the same |
ojw28
changed the title
|
@james12695 - Agree this should be classed as a bug rather than an enhancement. Reclassifying accordingly, and we'll take a look over the next week or two. It's possible for you to work around this issue in application code in the meantime (see my "In the short term" further up this post). Thanks! |
|
Thank you for your kind help 😃 |
In live streaming, if the playback position is very close to live edge, the buffered duration will never reach minDurationForQualityIncreaseMs, which prevents switching from ever happening. So we will provide the durationToLiveEdgeUs to AdaptiveTrackSelection in live streaming case, so it can handle this edge case. GitHub: #3017 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=168535969
|
We've pushed a change to |
|
Unfortunately, I am currently unable to even reproduce the original undesired behavior (we had, in the meantime, used I still get 4 second chunks but for some reason I now always get over 10 seconds of buffer very quickly and the quality is switched up accordingly where it previously stayed low. I suspect there were some subtle changes in the streaming configuration... In any case, I am afraid I don't have a setup where I could compare the old |
In live streaming, if the playback position is very close to live edge, the buffered duration will never reach minDurationForQualityIncreaseMs, which prevents switching from ever happening. So we will provide the durationToLiveEdgeUs to AdaptiveTrackSelection in live streaming case, so it can handle this edge case. GitHub: #3017 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=168535969
|
I think we need to tweak this a little more to get it working just right. |
|
Further tweaked in 324339b. |
Problem description
This is mainly a question about ExoPlayer's behavior and maybe a request for best practices in handling this case:
In our app we have both "normal" live streams (Live stream with limited availability) and what we are calling "startover streams", which enable you to watch the current program from the beginning (Live stream with indefinite availability). All are streamed with HLS version 3.
Now, with live streams, we are experiencing the following problem:
We are fixing this now by explicitly setting an initial seek position to seconds 90 of the 120 second live window.
For the startover streams, however, since we want to allow seeking within the whole available portion of the stream we need to make sure we are not getting too close to the live edge - or else the above problem would arise again. Hardcoding a margin of 30 (or maybe 20 or 15) seconds at the end of the stream - i. e. allow seeking only up to
player.getDuration() - 30_000- would probably work but doesn't seem ideal given that it actually depends on things like chunk size, etc.Is there a better way to determine the maximum allowed seek position in streams that are still growing at the end?
Version of ExoPlayer being used
2.4.2
Device(s) and version(s) of Android being used
FireTV - multiple hardware versions
The text was updated successfully, but these errors were encountered: