The setting's device makes every video preview: on the file's own machine
when it is there (the hub tells it by header), else on the device's machine,
which reads the file through the hub by a one-file token, and the preview is
kept in the file's machine's own cache (PUT /api/files/thumb, refused if the
file changed). Images and covers stay on the file's machine's CPU. If the
device's machine can't, the file's makes it as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tonemap_vaapi refuses HLG, and the hardware path never honoured a rotation
(ffmpeg's autorotate is for frames in memory). HDR10 is still tone-mapped,
on the card and, failing that, in software before the upload.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every video plays YouTube's way: hls.js reads the connection and picks the
quality, or one is picked by hand, or Original plays the file as it is. The
qualities (a ladder by size, H.264) are made on the fly in 3 s pieces from
wherever the viewer seeks, one ffmpeg per play, paused when far enough ahead.
360 videos open in a look-around view (drag, pinch or scroll to zoom from
8 to 300 degrees, phone motion).
Settings -> Transcode device picks the machine and device that makes them,
for every machine's files: a machine transcoding another's file reads it
through the hub by a token for that one file. Replaces the codec/size picker
and the single-quality re-encoder.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A re-encode's playlist is now the whole film on a fixed 4 s grid. A segment
that isn't on disk and isn't coming soon moves the encode there; runs stop
short of segments already made, and gaps are filled after. Every run is cut
the same way (-ss, -output_ts_offset start+10, frag_discont), so segments
from different runs join. Repackaging keeps its growing playlist.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Found by walking every handler and the UI with odd inputs, then a battery of requests
against the live hub. Fixed:
- A save over the 8 MiB cap was cut short in place: the file was truncated, then the
first 8 MiB written, and the caller told 204. Now the body is read whole first and a
body over the cap is a 413 with the file untouched.
- A link to a file showed the link's own time; now the file's, so the row reads right
and the preview key follows the file.
- Reading a link to nothing answered 200 with an empty body (the open failed after the
headers in root mode); now a 404 that names the target.
- A play request with an unknown codec or size was answered by inspecting the file
first, so an audio-only file said "no video stream" instead of what was wrong; the
choice is checked before any work, and is a 400.
- A stream that ended in failure was handed back to the next identical request for ten
minutes; a failed one is now dropped and a fresh one made.
- A player that left while its stream was still finding a first segment made the loop
try the next recipe; it stops. A stream closed mid-start is not started again.
- Ending a root-mode ffmpeg could wait forever: the daemon cannot signal root's
processes, so the wait is bounded and the helper's own grace does the rest.
- A page going away (a phone closing the tab) releases its stream by a beacon, rather
than ten minutes later by the sweeper.
- The path box resolves like a shell — relative to the folder shown, . and .. applied,
trailing slashes dropped — in the tab and in the Move picker, with a test. A typed path
that is a file opens it; a remembered folder that is gone falls back to / once.
- A dropped folder arrived as a nameless empty file; it is refused with a word. The
upload toast counts what was actually uploaded.
- The viewer names a device, pipe or socket, and a dangling link, instead of calling
them binary files.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The viewer tries the file as it is first. When the browser gives up — Safari and an MKV,
HEVC without a hardware decoder — or on a tap, a picker: codec (H.264, HEVC, AV1, or the
original codec repackaged) and size (original, 1080p, 720p, 480p), each codec labelled
with the engine this machine would use. POST /api/files/play runs ffmpeg into an HLS
event playlist of fragmented-MP4 segments under <data dir>/transcode/<id>/; Safari plays
HLS itself and everything else goes through hls.js, loaded only then. The recipes are
tried best first: a card on the bus before the integrated GPU, decoding on the same card
before decoding on the CPU and uploading, the software encoders last; a recipe that
produces no first segment is dropped for the next. The seekable range grows as ffmpeg
gets ahead; status says how far. Streams are reused for the same request, closed when
the player goes, swept after ten idle minutes, and the folder is emptied at start. Root
mode runs ffmpeg as root through a helper that ends when the daemon lets go of it.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
