Optimize in-buffer seeking for HLS #551
Comments
|
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. |
|
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). |
|
@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. |
|
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)? |
|
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. |
|
I still have this problem when seek backward or forward. both Dash and hls. I use demo V 1.5.2 |
|
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. |
I think the concept of a sparse track might need formalizing in Format at some point. We should probably do a similar thing with sparse tracks in ExtractorSampleSource as well. WDYT? Issue: #551 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=120530195
Pull more logic up to HlsSampleSource. Somewhat regretfully, this also backs out the optimization work done toward the ref'd issue. I think that's one for another time perhaps... Issue: #551 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=123417413
|
How about this issue? @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. |
Also move to using an array to hold the SampleQueues, as we've moved to doing in ExtractorMediaPeriod. Issue: #551 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=161972990
|
In-buffer seeking is now optimized to the same extent as DASH. |
When playing media files, I seek to a position, the buffered data will be cleaned and buffer again from the new position seeked to.
The text was updated successfully, but these errors were encountered: