A format that provides for buffering and seeking
bkil opened this issue · comments
When hosting larger recordings and thinking about reducing hosting costs, we might want to minimize bandwidth use by optionally not downloading the whole recording within the browser before playback.
It has been shown that on video sharing portals, users usually watch the initial few seconds of a long recording and then seek into random places (to peek into what sections look like) before watching the whole thing (or just navigating away).
To implement this, larger files could also be stored sliced per section (see asciinema/discussions#99) or per approximately fixed sized chunks (64 kB?), each beginning with a full state restoration to allow seeking. The recording data file could include an index in the beginning with a list of URLs for each part (for separate files, preferred) or offsets (in case of HTTP range requests - non-cacheable).
See also asciinema/discussions#85
Related: asciinema/discussions#4
Per my suggestion of looking into zstd with a trained dictionary as an additional optimization in asciinema/discussions#85 , if you leverage WASM for browser usage, you could perhaps use zstd in the browser and it's streaming capability? (assuming that's compatible with nostd if using Rust)
I don't have much experience with such, but you can see a streaming API available already here for zstd. That is compatible with providing a dictionary, and provides some extra methods to the Read trait.
You should be able to leverage that to only retrieve the initial stream, and then seek to where you want while managing a buffer.
Average recording size on asciinema.org is 154kb uncompressed (average of 468092 uploads). Then, when served to the browser it's sent gzipped. asciicasts compress super well, to roughly 7% of original file size with gzip. This means that on average the browser fetches 11kb of data to play full recording.
Given above I don't think it makes sense to complicate the format and/or implementation of the server and the player.
Unfortunately, as mentioned previously, it took quite some fiddling with curseofwar to fit a playthrough under 5MB.
I know that I'm pushing the limit and it's much less if all you do is list the contents of a directory or watch package installation scroll by.
Although, in my opinion, just for those trivial, static use cases, people could just as well publish static markdown documents about the given installation process with preformatted blocks fulfilling the role of screenshots. I always considered asciinema & co to serve more complicated use cases such as action footage.
See my latest in comment in asciinema/discussions#85 where I tried to address your use case and ideas.