asciicast realtime live broadcast

[daixtr]

I request (if possible) for asciicast to able to broadcast in live realtime our asciicast terminal session. If this is not possible, i like to hear why. Thanks.

[ku1ik]

Yes, this is planned. No ETA yet, but it will be probably added in 1.1 or 1.2.

[daixtr]

i am curious, ... would you be using libssh or libssh2?

[daixtr]

oh.. i think, your client is python.. so i'm not sure if my previous question makes sense.. but thanks.

[noisy]

+1 to this idea!

[asquelt]

this would make possible to use asciinema as terminal cctv (aka session logging) :+1:

[fulldecent]

Here is the start of a work plan for this issue.

• [ ] asciinema rec when run without arguments:
  • [ ] Immediately print the server published URL, e.g. https://asciinema.org/a/333393
  • [ ] Start streaming the json to server (no "incremental" json format is required)
  • [ ] When done, again print the server published URL
  • [ ] Maybe add --no-live option which does not stream to the server, but live stream should be default
• [x] asciinema play no changes whatsoever are required
• [ ] asciinema-player
  • [ ] Allow incremental read of input JSON file
  • [ ] Add new "loading" ("buffering"?) graphic for when reading the file hangs
• [ ] asciinema.org
  • [ ] Allow incremental file upload
  • [ ] Allow incremental file download
  • [ ] Include "live" icon when playing a cast that is still uploading
  • [ ] Include "live" section under the EXPLORE heading at https://asciinema.org/browse?order=popularity

Additionally, some further add-on work might be warranted after this is done. I am listing it here for fun, but this should be outside the scope of this issue and will need new issues if anyone is interested.

• [ ] Show count of people watching a live stream
• [ ] Allow comments and discussion on a live cast, just like Periscope

[metasoarous]

OMG! This is amazing! Would love to see this!

I teach a bioinformatics class at Fred Hutch Cancer Research Center, and would love to have my helper live stream their screen so attendees could debug more effectively (projector screen generally taken up with slides, and we found switching between slides and terminal troublesome).

I mention the cancer research thing because I am absolutely trying to guilt you into helping me teach biologists how to analyze their data more effectively so we can cure cancer. No pressure or anything though ;-)

[gpollo]

@metasoarous While this is an awesome feature that asciinema needs. You can still setup something like: attendees ssh to a user on a computer and connect to a readonly tmux session with the -r flag. The helper can then edit live and everyone gets the modifications. While this is not bullet proof and someone can easily connects to the session without the readonly flag, I still think this is an okay alternative while we wait for this feature ;)

[metasoarous]

Oooo... guilt-trip ricochet...

We actually learn tmux in the class already actually, so it's not too far-fetched to imagine doing that. But it is certainly quite a bit of extra setup and I've found for folks new to tech it's best to minimize as much of that incidental complexity as possible. Having them hit a link (or better an embed on the class homepage) would be gold. Of course, I respect that the bullet points above constitute no small amount of work :-) In any case, I'm mostly just trying to lend encouragement and motivation. Wish I had the bandwidth to help (especially since cljs) :-)

[ku1ik]

Part of the work on live streaming is already done - the web player can now play from Websocket stream. I'm working on the server part now (serving persistent connections etc).

[metasoarous]

Wonderful! Great to hear. You are saving lives, good sir.

[thecotne]

also i want to mention that someone (and me too) may want this stream self hosted like replacing gitlab-ci with this for example while having it private and not published to website

[romatthe]

Just checking if there has been any progress on this? This is absolutely not a life-or-death feature for me, I've just got a couple of cool ideas to play around with should this feature ever get implemented :wink:

[dreness]

+1, looking forward to this :)

[dlnetworks]

+1!

[jvaubourg]

What's the state of this feature request? Something secure to stream a terminal over http should be great!

[luismqueral]

+1 I have a few projects that would be perfect for a feature like this! @sickill is there an update to this?

[vlada79]

+1!

[kristianlm]

I'd love to see this feature in asciinema! I have some ideas, but I haven't used asciinema a lot, so sorry if this is just noise. @fulldecent, you mention

(no "incremental" json format is required)

Does that mean the full recording JSON object gets replaced on each change?

I miss being able to use my recordings on disk in a "live stream" fashion. As you know, the current format can't support live-streams in itself because the entire recording needs to be serialized as a complete JSON object. So how invasive is it to split it into multiple JSON objects?

Going from this:

~ ➤ asciinema rec /tmp/f -c 'echo test 1 ; sleep 1 ; echo test 2' ; cat /tmp/f
~ Asciicast recording started.
~ Hit Ctrl-D or type "exit" to finish.
test 1
test 2
~ Asciicast recording finished.
{
  "version": 1,
  "width": 319,
  "height": 79,
  "duration": 1.007464,
  "command": "echo test 1 ; sleep 1 ; echo test 2",
  "title": null,
  "env": {
    "TERM": "xterm-256color",
    "SHELL": "/usr/bin/fish"
  },
  "stdout": [
    [
      0.005883,
      "test 1\r\n"
    ],
    [
      1.001344,
      "test 2\r\n"
    ]
  ]
}

To something like this:

~ ➤ asciinema rec /tmp/f -c 'echo test 1 ; sleep 1 ; echo test 2' ; cat /tmp/f
~ Asciicast recording started.
~ Hit Ctrl-D or type "exit" to finish.
test 1
test 2
~ Asciicast recording finished.
{
  "version": 2,
  "width": 319,
  "height": 79,
  "duration": 1.007464,
  "command": "echo test 1 ; sleep 1 ; echo test 2",
  "title": null,
  "env": {
    "TERM": "xterm-256color",
    "SHELL": "/usr/bin/fish"
  }
}
[0.005883, "test 1\r\n"]
[1.001344, "test 2\r\n"]
{"end":true}

Would allow live recordings without any special tooling. A host could send his recording live like this:

➤ touch live.asciinema
➤ tail -f live.asciinema | nc example.com 3003
➤ asciinema rec /tmp/live.asciinema

And a client could watch with nc -l -p 3003 | asciinema play -.

For the web, recordings could be served from disk and Chunked transfer encoding could be used for transferring incomplete/live files. Now, in the eyes of curl, a live recording is no different from a finished one:

➤ curl http://host/recording.asciinema | asciinema play -

I don't know how difficult it is to work with Chunked transfer encoding in your javascript player. It shouldn't be more complicated than WebSockets, though.

While it's never fun to change the on-disk-format, it would make streaming a "first class citizen" in asciinema. And may require less special attention from the tooling around, and it certainly makes it possible to deal with live streams from outside of asciinema, which is currently not the case.

I don't know how intrusive any of this would be on your codebase, though!

[kristianlm]

Just like I though - ignore me! :) Everything is covered in #196. Glad to know we're on the same page, at least :)

[lufte]

@sickill commented on Jul 27, 2016 Part of the work on live streaming is already done - the web player can now play from Websocket stream. I'm working on the server part now (serving persistent connections etc).

Hi, is there any documentation on how to do this with the web player? Assumming we code our own server.

Thanks.

[Immortalin]

We replicated this at KloudTrader using gotty and screen: https://github.com/yudai/gotty/pull/209/files

Throw in a NAT puncher like Ngrok and you get terminal live stream.

Considering spinning this into a service if anyone's interested.

[lufte]

I ended up using shellinabox and tmux, I guess it's pretty similar to your solution there :)

[marcotrosi]

this issue is from 2015. any updates when this feature would be available?

[kolayne]

Good day, everyone!

I was thinking of having the feature to live cast my terminal over a local network (i.e. using the machine with the terminal as a server). So, firstly, I would like to know if it is consistent with the view of other users and developers/maintainers (@sickill), or is there some conceptual problem about that.

Secondly, I would like to have advise from someone more experienced in all that networking thing: if I decide to work on that, what kind of way should I use to communicate between recorder and players? Would it be good to use something as low-level as sockets? Is there a higher-level protocol for transferring text, where I need not worry about clients connecting/disconnecting and all the lowest-level stuff? Should I stick to something HTTP-compatible (maybe so that the code can be reused when implementing casting through asciinema.org)? Please, share your suggestions!

Thank you in advance.

[kolayne]

At first I thought using websockets would be a good idea as it is not super low-level and the code could've been reused for the implementation of broadcasting through the server, but then I noticed asciinema does not have any dependencies, and this feature probably is not one you would want to first introduce them. But the only suitable way I know with the standard python is the sockets built-in library. Is it an appropriate tool for this kind of task?

[gpollo]

@kolayne, you should probably use a standard RPC library (Cap'n Proto, gRPC, etc.). You get a nicer interface, support many languages and is easier to maintain. Using low level socket manually and then building the protocol on top of it will most likely be a maintenance burden later.

[kolayne]

@gpollo, thank you for your reply!

There is, however, one more problem that I forgot to mention above (in fact, I only noticed it a few days ago, I didn't know about it when writing the previous comment): asciinema is pure-python and doesn't have any external dependencies. And, as the maintainer does not answer so far, I only get to guess, but if I was him, I don't think I would be happy to introduce the first project dependency for this (non-core) kind of feature.

I guess, a way to go is to make this an optional dependency, and only enable this feature if the corresponding libraries are installed... But that still breaks that nice "asciinema works without dependencies!" thing.

Anyway, are you aware of anything higher-level than pure sockets, that is supported in the python standard library?

[gpollo]

@kolayne, I'm not the maintainer, but I do believe an optional dependency is 100% the way to go. Adding a dependency should not prevent a feature from being implemented, especially if it can be optional. Doing it with low-level socket or a pure Python implementation will be reinventing the wheel at some point.