pastilhasandClaude Opus 5
7732ca1da5
a live transcode has no length and no byte ranges, so the progressive mp4 the player used could not be seeked — a scrub restarted ffmpeg at a new offset. jellyfin's own HLS playlist is VOD and spans the whole runtime, so seeking it is a segment request. hls.js is checked in rather than installed. installs are frozen so that adding a package is a reviewed act, and a committed file also has no install-time hook, which is the vector the 2026-08-04 npm worm used. provenance, hashes and the update recipe are in vendor/README.md; the tarball sha512 matches the registry's published integrity. the sidecar now overrides VideoBitrate and MaxWidth on the TranscodingUrl jellyfin hands back, for the same reason progressivePath computes them: jellyfin resolves that bitrate from MaxStreamingBitrate (~119 Mbit, the ceiling that exists to let a stream copy through) and sets no width, which asks a CPU-only container to encode 4K. safari is deliberately not given the m3u8 — segment URIs are relative and would not carry the ?token=, and it cannot set an Authorization header the way hls.js can. progressive stays as the fallback for any browser without MSE. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
9 lines
293 B
Plaintext
9 lines
293 B
Plaintext
node_modules
|
|
dist
|
|
runtime-scripts
|
|
*.min.js
|
|
|
|
# Vendored third-party sources — reformatting them would destroy the diff against upstream,
|
|
# which is the only thing that makes a checked-in library reviewable. See the README beside it.
|
|
src/workspaces/officerdev/src/apps/Jellyfin/vendor/hls.mjs
|