Optimize in-buffer seeking for HLS

[brinliu]

When playing media files, I seek to a position, the buffered data will be cleaned and buffer again from the new position seeked to.

[Arqu]

There are a couple reasons why it is currently like that, for one it is currently not implemented in that way, two if the stream variant has changed and you seek back it was not in memory in the first place and so it fails. Also when seeking the decoder has to find the first iframe before that moment so it attempts to load that chunk to find it.

However you can make seeking work more suited to your case by enabling cache support like I did therefore chunks will be cached and when requested will be more or less instantly loaded from the disk and the playback starts without a hit on the bandwidth. However I still haven't managed to select the cached variant to play until a better segment is loaded but that can be done too.

[ojw28]

Seeking forward into the buffer will retain the buffered data where possible in the DASH, SmoothStreaming and ExtractorSampleSource cases (the only case where it's not possible is if you're seeking less than one key-frame forward in one or more of the enabled tracks).

For HLS this optimisation is harder to pull off correctly due to additional complexity around having to splice overlapping sample queues when switching variants. This is a result of a shortcoming in the HLS specification. Hence we haven't tried to do this yet (there's a TODO in HlsSampleSource, but it's relatively low priority for us).

[brinliu]

@ojw28 Thanks a lot for your reply. Though you mentioned it's low priority, I still want to know if any schedule about this. This is very important on android for the origin MediaPlayer doesn't support buffering when playing HLS.

[ojw28]

Why is this very important? The player can just build up a buffer by requesting the data again? Or are you talking about something different (e.g. the ability to seek in live streams)?

[brinliu]

I mean that, the ExoPlayer maybe is the best player for HLS on Android. For origin MediaPlayer, we can't get the buffer progress. So the developers maybe choice the Exoplayer for playing HLS. But ,when the users want to seek to some position, the buffered data will be lost.

[siavashabdoli]

I still have this problem when seek backward or forward. both Dash and hls. I use demo V 1.5.2

[ojw28]

Note: We will be optimizing forward seeking for HLS so that it matches what we're able to do for DASH and SmoothStreaming in 2.x.

[zhuyifan2013]

How about this issue? @ojw28

[ojw28]

We abandoned plans to optimize this for now. It turned out to be pretty non-trivial. If you're concerned with optimal playback behavior then you should really be using DASH rather than HLS.