starred/asciinema

Fork 0

mirror of https://github.com/asciinema/asciinema.git synced 2026-04-25 07:55:51 +03:00

[GH-ISSUE #516] A format that provides for buffering and seeking #895

New issue

Closed

opened 2026-03-15 10:53:35 +03:00 by kerem · 5 comments

kerem commented

2026-03-15 10:53:35 +03:00

Owner

Originally created by @bkil on GitHub (Jul 9, 2022).
Original GitHub issue: https://github.com/asciinema/asciinema/issues/516

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

Originally created by @bkil on GitHub (Jul 9, 2022). Original GitHub issue: https://github.com/asciinema/asciinema/issues/516 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

kerem closed this issue

2026-03-15 10:53:40 +03:00

kerem commented

2026-03-15 10:53:46 +03:00

Author

Owner

@bkil commented on GitHub (Jul 9, 2022):

@bkil commented on GitHub (Jul 9, 2022): Related: https://github.com/asciinema/discussions/issues/4

kerem commented

2026-03-15 10:53:51 +03:00

Author

Owner

@polarathene commented on GitHub (Jul 23, 2022):

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.

@polarathene commented on GitHub (Jul 23, 2022): 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](https://docs.rs/zstd/latest/zstd/stream/read/struct.Decoder.html). 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.

kerem commented

2026-03-15 10:53:56 +03:00

Author

Owner

@ku1ik commented on GitHub (Apr 16, 2023):

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.

@ku1ik commented on GitHub (Apr 16, 2023): 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.

kerem commented

2026-03-15 10:54:01 +03:00

Author

Owner

@bkil commented on GitHub (Apr 16, 2023):

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.

@bkil commented on GitHub (Apr 16, 2023): Unfortunately, as mentioned [previously](https://github.com/asciinema/discussions/issues/85), 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.

kerem commented

2026-03-15 10:54:07 +03:00

Author

Owner

@ku1ik commented on GitHub (Apr 16, 2023):

See my latest in comment in asciinema/discussions#85 where I tried to address your use case and ideas.

@ku1ik commented on GitHub (Apr 16, 2023): See my latest in comment in asciinema/discussions#85 where I tried to address your use case and ideas.