-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
feat(HLS): Optimization of LL-HLS with byterange #5319
feat(HLS): Optimization of LL-HLS with byterange #5319
Conversation
Incremental code coverage: 91.55% |
e8316c6
to
b43b39f
Compare
I've read through, but haven't yet understood the change. I'll need more time. Also, JFYI, Monday is a holiday for Google in the US. |
@joeyparrish What this change does is that LL-HLS byterange is processed in the same way that it is done in LL-DASH. With this we achieve more efficiency according to the Akamai paper and what has been tested by me. |
if (this.config_.lowLatencyMode && isReadableStreamSupported && isMP4 && | ||
this.manifest_.type != shaka.media.ManifestParser.HLS) { | ||
(this.manifest_.type != shaka.media.ManifestParser.HLS || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Say, it occurs to me. This assumes that a manifest that isn't HLS is DASH, based on the comment above.
But we now have the constant of shaka.media.ManifestParser.MSS
. Is this behavior supported by MSS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this would work for MSS live (in the future)
This solution is based on https://www.akamai.com/blog/performance/-using-ll-hls-with-byte-range-addressing-to-achieve-interoperabi