dhobsd / castty Goto Github PK

Improve the look and feel of the player, especially on mobile devices (phones, tablets). Accessible themes for xterm.js would be nice, too (especially ones to support non-xterm color schemes).

It would be nice to have some runtime encoding of audio -- especially for larger recordings. This would also be basically required before we could make castty support live casts. I'd prefer to use some library for this, and preferably one that can support output for all browsers.

This would also allow us to specify multiple output formats to get multiple files for wider browser support.

Different terminals have different settings, and it can be odd for someone using a 16-color terminal to have their colors misinterpreted by something assuming xterm colors. Mostly this would just be styling colors to match various terminals. Then castty could detect what kind of terminal it was running in (using $TERM) and feed that info to the player, which could auto-choose the theme.

Themes related to accessibility would also be nice.

Need to bisect to figure out what caused this. (It was working after the conversion to libsoundio). Also in general, we should be turning off recording entirely when this happens. That would make it easier to implement, too.

It would be very helpful if you could tag the source and create a release. This would enable distributions to work with releases and allow then to easier keep track of changes.

Thanks

Restoring the terminal with just tcsetattr and TIOCSWINWZ seems to still leave the terminal in a weird state. Instead, I think we really need to read the termcap entry for the terminal we're using and restore based on that.

I don't really see this as a bug, resizing window probably ends up looking confusing during playback. But it should probably be handled in a nice way.

There's still work ongoing for this at asciinema/asciinema#196, but this will need to be done.

After a certain point, seeking seems to break in long videos. Need to debug and fix -- I suspect this is due to something like how duration is calculated vs how the seek is updated.

Re: #4, etc., can it be confirmed that min.js contains all of:

• jQuery
• rangeslider.js
• xterm.js

(from the README) in the minimize form? What versions of the components were used? How that file can be (re)produced?

It would be nice to have some kind of TUI for castty to allow various levels of recording control and configuration at runtime. This would probably be using e.g. http://www.leonerd.org.uk/code/libtickit/ and http://www.leonerd.org.uk/code/libvterm/.

When the C portion was forked, ttyrec had an "append" mode, but this was broken when it was made to output JS. Adding an append mode might be useful, and shouldn't be too hard.

I managed to compile with make command on Macbook pro Catalina latest

I had to change from lame_encode_buffer_ieee_float to lame_encode_buffer_float in writter-lame.c as it was not compiling.

I use the command:
./castty record -d 'BuiltInMicrophoneDevice' -a audio2.mp3 -m

But how I can stop the recording? I can only stopping it by force close from Activity Monitor.

And I can not hear anything in the recorded file..

Devices:
cotfas@192-168-0-146 src % ./castty record -l
Available input devices:
0: Boom2Device, 48000Hz, format: 'float 32-bit LE'
castty record -d 'Boom2Engine:0' -a audio.raw
1: MacBook Pro Microphone, 44100Hz, format: 'float 32-bit LE'
castty record -d 'BuiltInMicrophoneDevice' -a audio.raw
cotfas@192-168-0-146 src %

Tried with both devices..

This makes the JS output smaller, but will also require a change in the player.

Right now unicode does not appear to survive the recording and playback, it would be nice to have this working to allow for internationalization among other things.

In #35, support for v2 rewinds the output file to insert some duration information at the end. This works, but is potentially fragile. Rework this to write a header to a new file and merge in the output at exit.

When multiple audio devices have the same name, it is impossible to select anything but the first of them.

A proof of concept for a solution would be
this patch, which will also allow you to specify an index with -d - although it would also make sense to have a separate option for that, to prevent confusion if a device has an integer as its name.

As an educator, I'd like to be able to advertise the concept of creating animations from the terminal. Thus, I like to link to https://github.com/topics/terminal-recording instead of collecting several tool links.

How about castty joins the small club and also adds the topic terminal-recording to this repo?

Add the ability to pause a recording. This would immediately stop reading new audio and terminal events, and would continue adding new events with no delay from the pause point.

When exiting castty with audio recording enabled I get a stacktrace following a pulseaudio assertion failure:

pa_write() failed while trying to wake up the mainloop: Broken pipe
                                                                   pa_write() failed while trying to wake up the mainloop: Broken pipe
                                     pa_write() failed while trying to wake up the mainloop: Broken pipe
       pa_write() failed while trying to wake up the mainloop: Broken pipe
                                                                          Assertion 'pa_close(fds[0]) == 0' failed at pulsecore/core-util.c:2625, function pa_close_pipe(). Aborting.

Process -303538095 got signal 6
	at faultaddr: 0x55c9ede86051 errno: 21961 code: 1662301864
Backtrace:

./src/castty(+0x2c80) [0x55c9ec40cc80]
/usr/lib/libpthread.so.0(+0x11080) [0x7fef63750080]
/usr/lib/libc.so.6(gsignal+0xcf) [0x7fef6315d04f]
/usr/lib/libc.so.6(abort+0x16a) [0x7fef6315e47a]
/usr/lib/pulseaudio/libpulsecommon-10.0.so(pa_close_pipe+0x85) [0x7fef61a7b645]
/usr/lib/libpulse.so.0(pa_mainloop_free+0x42) [0x7fef62cb6602]
/usr/lib/libpulse.so.0(pa_threaded_mainloop_free+0x3d) [0x7fef62cc61bd]
/usr/lib/libsoundio.so.1(+0xd359) [0x7fef63969359]
/usr/lib/libsoundio.so.1(soundio_disconnect+0x30) [0x7fef63963950]
/usr/lib/libsoundio.so.1(soundio_destroy+0x1c) [0x7fef63963b0c]
./src/castty(+0x4ff5) [0x55c9ec40eff5]
./src/castty(+0x5fe9) [0x55c9ec40ffe9]
./src/castty(main+0x520) [0x55c9ec40dcb7]
/usr/lib/libc.so.6(__libc_start_main+0xf1) [0x7fef6314a291]
./src/castty(+0x2b2a) [0x55c9ec40cb2a]

./src/castty(+0x4ff5) is ./src/audio.c:472

If I pause the recording mid-way, and then exit, there is no backtrace (log is clear too).

This is on archlinux x86_64 with:

• libsoundio 1.1.0
• libpulse 10.0
• glibc 2.24
• gcc (GCC) 6.3.1 20170109

I really only use OS X for this, so that'll probably get done first. It would be nice to have actual volume and input controls for different host APIs. (Also, it'd probably be nice to ask folks how they want to record when we pick the audio device.)

Initially this could be a thing that works while paused, if adding a runtime TUI is too difficult.

Add an ability to do a live-cast to castty and its player. Castty would also record the broadcast.

After a quick bisect, I have found that 87e0d2c has introduced some compilation errors. Namely:

castty.c: In function ‘setup_sighandlers’:
castty.c:218:15: error: incompatible types when assigning to type ‘__sigset_t {aka struct <anonymous>}’ from type ‘int’
  chld.sa_mask = 0;
               ^
castty.c:224:16: error: incompatible types when assigning to type ‘__sigset_t {aka struct <anonymous>}’ from type ‘int’
  crash.sa_mask = 0;
                ^
castty.c:237:16: error: incompatible types when assigning to type ‘__sigset_t {aka struct <anonymous>}’ from type ‘int’
  winch.sa_mask = 0;
                ^

Building on:

• linux x86_64
• gcc (GCC) 6.3.1 20170109
• glibc 2.24

I haven't looked into it yet but I'm adding this issue just to track progress.

And an ability to mute microphone during recording. PortAudio doesn't provide this functionality. Instead, we can probably write zeroes for each frame instead of what we would have recorded.

When seeking backwards, we have to replay the whole cast from the beginning because of the terminal codes. This isn't so bad for recordings that are just a couple minutes long, but I imagine there's noticeable seek latency on longer recordings.

Probably this would involve the player creating keyframes as it goes such that it has a place to restore from.