Allow mid-download cancellation for faster adaptive switches.

[shalin186]

Hi,

I have a following question about changing the bit-rate in HLS stream.

With the current exoplayer implementation, if client has great bandwidth improvement then it will take effect only after the buffered duration of the video is played. Because chunks are always downloaded in the increasing sequence at the end of the buffer.

I know that I can reduce the buffer size but that's not how I want to solve the problem.

I have made some changes to start downloading the improved bit-rate chunk which is 2 chunks away from the currently playing chunk.
So for example,
Chunk Duration: 2 seconds
Currently Playing Chunk : Number 5
At this moment we see bandwidth improvement
So I start downloading chunk number 7 at new bit-rate.
And in this case, the client will see improved quality starting chunk number 7 itself which is less than 4 seconds away. And all that work fine.

Here's the problem I am facing:

When I start downloading new chunk (number 7 in the example) at higher bit-rate, exoplayer turns on splicing and it removes all the old chunk samples at old bit-rate. For example, I had 15 chunks in buffer (Chunk number 5 to chunk number 19), then all of them will be discarded.
In my case, I want to have a flexibility of choosing between new chunk and old chunk. Meaning, if new chunk at new bit-rate is downloaded in time, I want to play them but if not, I don't want to get into buffering situations since I could have just played old chunks at old bit-rate which were already downloaded before.
simply, disabling splicing doesn't work in this case.

I hope I am able to explain my problem properly.
Basically, I am trying to be aggressive with bit-rate change but at the same time, I don't want to get into playback buffering for the chunks which were already downloaded but sadly discarded :(
Could you suggest what possible things I could try so that I can keep multiple chunks at same timestamps and then choose them with more freedom?

Thanks a lot in advance.
Shalin

[lioun1729]

I agree this point when we want to increase quality fast for QoE

But in other sight, I think pre-buffering is efficient because it can prevent causing buffer underflow when the network varies very fast and dynamic

If we use more short buffering scheme or deleting bufferred segment for next high quality, we can experience many rebuffering and unstable behavior of player

How about you?

I think this issue's point is very good but its deployment will be quite hard in real

[shalin186]

Hello, I see that the issue was labeled as enhancement about 6 months back. Could some one tell me if this enhancement will be implemented in near future?

[AquilesCanta]

Hi @shalin186, we have been looking at ways to improve our ABR algorithm but I doubt any improvements will be released this quarter, unfortunately. I think a good first step would be allowing better customization of buffering, discarding and mid-download canceling.

[ojw28]

We now generate a better initial bitrate estimate based on the device's current network type and country, and also carry bitrate estimates over from one playback to the next by default. This should mitigate this issue in most cases. Should we close this issue?

[tonihei]

This enhancement seems to be specifically about mid-download cancellations to allow faster adaptation. That's something we might want to support in the future. I'll rename the issue title.

[tonihei]

This is now supported for HLS (with PR #7244), but not yet for DASH or SmoothStreaming.