Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support to keep downloaded chunks whenever seeking playing HLS content #1995

Closed
HyowonHwang opened this issue Oct 26, 2016 · 4 comments
Closed
Labels

Comments

@HyowonHwang
Copy link

I have tried to seek operation of HLS contents on demo app.(2.0.4)

It seems like downloaded chunks are abandoned.
Unlike, playing DASH and Smooth Streaming contents.

Could you look into to support keep downloaded chunks buffer when seeking while HLS contents, please?

@ojw28
Copy link
Contributor

ojw28 commented Oct 27, 2016

We abandoned plans to do this for HLS simply because it's significantly harder to get it right when dealing with TS chunks in HLS than it is when dealing with FMP4 chunks in DASH.

If you want optimal performance you should consider switching to DASH, since it's a much better thought out standard. For HLS, I think the best support we'll be providing here is to enhance our on-disk caching support, which at least means the player only has to hit the disk (and therefore will re-buffer extremely quickly) rather than the network. This enhancement is tracked in #420.

@ojw28 ojw28 closed this as completed Oct 27, 2016
@ojw28 ojw28 added the question label Oct 27, 2016
@HyowonHwang
Copy link
Author

Appreciate for answer.

What if this feature supports on normal HLS contents except live streaming?
Is that also harder to support?

Thanks,
Hyowon

@ojw28
Copy link
Contributor

ojw28 commented Oct 27, 2016

It's possible, but it is harder to support than in the DASH and SmoothStreaming cases.

HLS is fundamentally less efficient and harder to deal with (e.g. through use of MPEG-TS [normally], muxed streams [normally], lack of key-frames at the start of chunks [common], multiple separate playlist files [always] and ambiguities in the spec that cause difficulties when performing stream switching [dependent on HLS version]).

We're primarily focusing performance optimization on DASH. We endeavour to provide a robust HLS implementation, but we're unlikely to focus a large effort on optimizations it. Providers who really value delivering optimal performance are moving to DASH anyway (albeit on various timelines).

@HyowonHwang
Copy link
Author

Appreciate for kind answer.

I agreed what your are pointing like meeting standards and going forward to DASH support.
But a lot of current services are using HLS and it as base delivery format due to cost of switching infra.
BTW, I will try to work on-disk caching that you noticed.
Thanks for your support.

@google google locked and limited conversation to collaborators Jun 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants