starred/asciinema

Fork 0

mirror of https://github.com/asciinema/asciinema.git synced 2026-04-25 16:05:52 +03:00

[GH-ISSUE #351] [ Feature Request ] seek to location #839

New issue

Closed

opened 2026-03-15 10:41:09 +03:00 by kerem · 6 comments

kerem commented

2026-03-15 10:41:09 +03:00

Owner

Originally created by @cyc115 on GitHub (Apr 10, 2019).
Original GitHub issue: https://github.com/asciinema/asciinema/issues/351

For a long recording it would be nice to be able to seek to

a location in time
a location that has string that matches a given string or regex.

This makes it easy to navigate a large recording for the purpose of record keeping without having to parse through the cat output.

Originally created by @cyc115 on GitHub (Apr 10, 2019). Original GitHub issue: https://github.com/asciinema/asciinema/issues/351 For a long recording it would be nice to be able to seek to - a location in time - a location that has string that matches a given string or regex. This makes it easy to navigate a large recording for the purpose of record keeping without having to parse through the `cat` output.

kerem closed this issue

2026-03-15 10:41:14 +03:00

kerem commented

2026-03-15 10:41:20 +03:00

Author

Owner

@ku1ik commented on GitHub (Sep 8, 2019):

That sounds useful but poses a big challenge on usability/UI of it. Since asciinema is "transparent" to terminal, in a sense that it doesn't draw any extra UI elements, I'm not sure how one would use the suggested feature.

Maybe breakpoints feature (#341) could be useful for this?

@ku1ik commented on GitHub (Sep 8, 2019): That sounds useful but poses a big challenge on usability/UI of it. Since asciinema is "transparent" to terminal, in a sense that it doesn't draw any extra UI elements, I'm not sure how one would use the suggested feature. Maybe breakpoints feature (#341) could be useful for this?

kerem commented

2026-03-15 10:41:25 +03:00

Author

Owner

@ju-sh commented on GitHub (Feb 11, 2020):

I wonder how seek is being implemented when the session is played for the recordings hosted at the asciiema website? As in https://asciinema.org/a/113463?autoplay=1

Maybe the recordings are first converted to some other video format?

@ju-sh commented on GitHub (Feb 11, 2020): I wonder how seek is being implemented when the session is played for the recordings hosted at the asciiema website? As in https://asciinema.org/a/113463?autoplay=1 Maybe the recordings are first converted to some other video format?

kerem commented

2026-03-15 10:41:30 +03:00

Author

Owner

@cyc115 commented on GitHub (Jun 12, 2020):

The recorded cast files are plaintext and each output lines are timestamped so seeking should be doable with the native format. We could have hotkeys to fast forward / go back x seconds and a more precise "seek to" functionality that pauses the playback and draws a UI on top of the (paused) recording to let us seek to location.

@cyc115 commented on GitHub (Jun 12, 2020): The recorded cast files are plaintext and each output lines are timestamped so seeking should be doable with the native format. We could have hotkeys to fast forward / go back x seconds and a more precise "seek to" functionality that pauses the playback and draws a UI on top of the (paused) recording to let us seek to location.

kerem commented

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

Author

Owner

@psdon commented on GitHub (Sep 10, 2021):

this would be useful, any updates on this? Or anyone is working?

@psdon commented on GitHub (Sep 10, 2021): this would be useful, any updates on this? Or anyone is working?

kerem commented

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

Author

Owner

@saulius-krasuckas commented on GitHub (Dec 25, 2021):

ping

@saulius-krasuckas commented on GitHub (Dec 25, 2021): ping

kerem commented

2026-03-15 10:41:45 +03:00

Author

Owner

@ku1ik commented on GitHub (Dec 25, 2021):

What you're looking for is something a combo of ttyrec + ipbt provides:

Conventional ttyrec players are little more than a loop
interspersing sleep(2) with write(2); it's easy to pause and
fast-forward, and a particularly advanced player might be able to
rewind by noticing screen clears and using them as marker points
(since replay can be restarted reasonably safely from a screen
clear), but precision single-step backward and forward motion is
entirely beyond such an application.

ipbt works by embedding a terminal emulator: it is essentially a
derivative work of the PuTTY code base. The input file is read in
full and run through the internal terminal emulator, and the
resulting screen states are saved in an internal movie array in such
a way that any screen state (`frame') can be retrieved efficiently.
Once this is done, the player application simply displays a sequence
of frames using libncurses; the user can perform the usual pause and
speed adjustment operations, but can also jump to an arbitrary frame
number and move backwards as well as forwards.

To have the rewind (seek-back) functionality in asciinema cli we'd need to implement it the same way as ipbt does - by embedding a terminal emulator. This is not planned, it's beyond the scope of the cli at the moment.

Implementing seek-forward only would be rather straightforward, but then the feature would feel half-baked for the end user so I'm hesitant to add it.

@ku1ik commented on GitHub (Dec 25, 2021): What you're looking for is something a combo of ttyrec + [ipbt](https://www.chiark.greenend.org.uk/~sgtatham/ipbt/) provides: > Conventional ttyrec players are little more than a loop interspersing sleep(2) with write(2); it's easy to pause and fast-forward, and a particularly advanced player might be able to rewind by noticing screen clears and using them as marker points (since replay can be restarted reasonably safely from a screen clear), but precision single-step backward and forward motion is entirely beyond such an application. > > ipbt works by embedding a terminal emulator: it is essentially a derivative work of the PuTTY code base. The input file is read in full and run through the internal terminal emulator, and the resulting screen states are saved in an internal movie array in such a way that any screen state (`frame') can be retrieved efficiently. Once this is done, the player application simply displays a sequence of frames using libncurses; the user can perform the usual pause and speed adjustment operations, but can also jump to an arbitrary frame number and move backwards as well as forwards. To have the rewind (seek-back) functionality in asciinema cli we'd need to implement it the same way as ipbt does - by embedding a terminal emulator. This is not planned, it's beyond the scope of the cli at the moment. Implementing seek-forward only would be rather straightforward, but then the feature would feel half-baked for the end user so I'm hesitant to add it.