5281a6690d
The server could transcode and serve HLS; nothing could play it. Chrome has no native HLS support, so without this the feature existed only for curl. hls.js is the only real option for HLS in Chrome, and it is MIT. It is loaded with a dynamic import, so the ~185 KB gzip is paid only when a transcode actually happens - a direct play, which is the common case, fetches none of it. Safari and iOS play HLS natively, so those get the playlist URL directly and never load the library at all. Three failure paths all fall back to the direct file URL rather than leaving a dead player: hls.js not supported, the dynamic import failing, and a fatal playback error. Transcoding is an optimisation and must never be able to break playback - a file that would have direct-played has to keep working when the encoder or the library is unavailable. The instance is destroyed on source change and on unmount, so seeking between files does not leave encoders or MediaSource objects behind. Verified: pnpm check 0/0, the production build succeeds, and hls.js is emitted as its own lazy chunk rather than folded into the main bundle. Not verified in a browser - there is no automated browser test in this repo, so the actual playback of a transcoded stream is unproven end to end. The server side of that path is verified separately against real hardware.
25 lines
551 B
JSON
25 lines
551 B
JSON
{
|
|
"name": "vellum-web",
|
|
"private": true,
|
|
"version": "0.4.0",
|
|
"type": "module",
|
|
"scripts": {
|
|
"dev": "vite",
|
|
"build": "vite build",
|
|
"preview": "vite preview",
|
|
"check": "svelte-check --tsconfig ./tsconfig.json"
|
|
},
|
|
"dependencies": {
|
|
"epubjs": "^0.3.93",
|
|
"hls.js": "^1.7.3",
|
|
"pdfjs-dist": "^6.4.299"
|
|
},
|
|
"devDependencies": {
|
|
"@sveltejs/vite-plugin-svelte": "^5.0.3",
|
|
"@types/node": "^26.6.5",
|
|
"svelte": "^5.19.0",
|
|
"svelte-check": "^4.1.4",
|
|
"typescript": "^5.7.3",
|
|
"vite": "^6.0.7"
|
|
}
|
|
}
|