diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-08-17 02:16:17 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-08-17 02:16:17 +0200 |
| commit | f5c4c058aa7e91fbdbbdd8cf34042535a05df433 (patch) | |
| tree | 7100fbb9a51e26827169d3e2a018bd0b26322b24 /packaging/systemd | |
| parent | 3f74fcc3515cd461f9fdd8d95a9d80aee67e1e58 (diff) | |
| download | meshbay-f5c4c058aa7e91fbdbbdd8cf34042535a05df433.tar.gz | |
feat(hub): move about in a film, and pick it up where it was left
Clicking the scrubber now restarts the stream there. A seek inside what is
already buffered never reaches the node. Dragging is debounced at 350 ms,
because `seeking` fires continuously and each one acted on kills an ffmpeg and
spawns another.
`SourceBuffer.mode` changes from 'sequence' to 'segments', and each stream sets
`timestampOffset` to where the node says it started — otherwise a stream
beginning at forty minutes is buffered at zero and the scrubber lies about
everything. Proved in Chrome before any of it was written: abort, remove, offset
600, append, and playback resumes at 600 with `readyState` 4.
A seek makes the buffer discontinuous, and everything reading `buffered` then
has to mean a particular range. "The last one" stops being "the one playing":
the read-ahead would report a full buffer across a gap while the player starves,
and the eviction would take out everything between the first range and the
playhead, including what is showing. Both work from the range around the
playhead now. `reinitAt` also clears the buffer outright rather than keeping two
ranges, and calls `abort()` first — ffmpeg was killed mid-fragment, so the
parser holds half of one and the next header would land on top of it.
The position is kept in localStorage, per file: no protocol, no storage anyone
else has to keep, and nothing new learns what you watch. Not below thirty
seconds, not past 97% of the film, and a pill offers the beginning back.
Two things this had to get right and did not at first, both found by running it
rather than reading it. Between asking for a seek and its `stream_init`,
everything on the channel belongs to the film being left — same file, so
`file_id` cannot separate them, but ordering can. And a segment that arrived is
no longer in flight whatever is then done with it: discarding one before
decrementing the window leaked a slot every time, and `reinitAt` is
asynchronous, so a whole window could arrive while it waited. The player then
believed eight segments were in flight, granted nothing further, and the node
waited for credit that could not come — a race, which is why the same seek
worked twice and hung on the third.
Diffstat (limited to 'packaging/systemd')
0 files changed, 0 insertions, 0 deletions