Replace Shaka Player with hls.js on web #10
Reference in New Issue
Block a user
No description provided.
Delete Branch "ivan/replace-shaka-with-hlsjs"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Every source railbird-mobile plays is HLS, and the only thing Shaka Player was providing is HLS playback in browsers without native support.
hls.jsdoes that in a fraction of the code.This removes Shaka along with the scaffolding that grew around its async attach/load lifecycle while it was being debugged:
ActionQueuethat serialized every play/pause/seek/volume call behind a 2s timeoutshallowEqualsource comparison pluscurrentSourcestatemakeNewShaka,What is going on, etc.)The video element is now driven directly: set
srcwhen the browser plays HLS natively (Safari/WebKit) or the source isn't HLS at all, and attachhls.jsotherwise. Only fatal hls.js errors are forwarded toonError; the rest are routine recoverable warnings.Dropping the queue restores the original direct
play/pause/seek/setVolumeimplementations.resume()now swallowsplay()rejections, which the queue used to absorb — those are routine whenplay()lands before the manifest is parsed, or when autoplay is denied.The source effect keys on the URI string rather than the source object. Consumers pass
source={{uri}}as a fresh object literal on every render, which is whatshallowEqualwas defending against.Carried forward from the Shaka implementation: the
onSeekCompleteevent andobjectFit: 'fill'.posteris now resolved to a URL string instead of suppressing the type error with@ts-ignore.Dropped: web-side
cropStart/cropEnd, which was implemented with Shaka'splayRangeStart/playRangeEnd. No consumer passes those props, and neither upstream's web player nor this file before Shaka supported them.Net: -245/+92 lines, and the package's only runtime dependency goes from
shaka-player(plus its Yarn patch and 4 transitive deps) tohls.js.Verification
tsc --noEmitandeslintare clean onsrc/Video.web.tsx. The two pre-existingsrc/Video.tsxerrors are present onrailbird-v6unchanged and are untouched here.The web player carried a Shaka Player integration plus the scaffolding built up around it while debugging: an ActionQueue that serialized every play/pause/seek/volume call behind a 2s timeout, a shallowEqual source comparison, and a large amount of debug logging. All of it existed to work around Shaka's async attach/load lifecycle. Every source this fork's consumer plays is HLS, and the only thing Shaka was providing is HLS playback in browsers without native support. hls.js does that in a fraction of the code, so drive the video element directly: set `src` when the browser plays HLS natively (Safari/WebKit) or the source isn't HLS at all, and attach hls.js otherwise. Dropping the queue restores the original direct play/pause/seek/volume implementations. `resume()` now swallows play() rejections, which the queue used to absorb -- these are routine when play() lands before the manifest is parsed or when autoplay is denied. The source effect keys on the URI string rather than the source object. Consumers pass `source={{uri}}` as a fresh object literal every render, which is what shallowEqual was defending against. Carried forward from the Shaka implementation: the onSeekComplete event and objectFit: 'fill'. Also resolves `poster` to a URL string instead of suppressing the type error with @ts-ignore. Dropped: web-side cropStart/cropEnd handling, which was implemented with Shaka's playRangeStart/playRangeEnd. No consumer passes those props, and neither upstream's web player nor this file before Shaka supported them.View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.