[GH-ISSUE #70] Decouple terminal recording from asciinema.org #667

Closed
opened 2026-03-15 07:43:01 +03:00 by kerem · 43 comments
Owner

Originally created by @ku1ik on GitHub (Aug 11, 2014).
Original GitHub issue: https://github.com/asciinema/asciinema/issues/70

Recording should not be tied to asciinema.org.

You should be able to:

  • record to a local file with asciinema rec <filename>,
  • replay locally (in a terminal) from files with asciinema play <filename>,
  • replay locally (in a terminal) from URLs with asciinema play <url>,
  • instruct player on asciinema.org to play from external URL?

This is a prerequisite for #49, it is in fact a simpler version of it.

Saving/sharing/replaying from a local file means we have to decide on the data format.

Requirements for data format:

  • should include raw stdout data with frame timing + (initial) width/height of the terminal window
  • should be easy to parse and process for asciinema and external tools
  • should allow live streaming
  • should be easy to read/parse by js player itself (so you can point js player directly to URL containing recording in this format)
  • the format should be versioned

Option 1: use current format used by asciinema.org

zip file with custom extension (like .asciicast for ex), including 3 files:

  • meta.json - with metadata like width/height of terminal, title, etc
  • stdout - raw stdout bytes,
  • stdout.timing - timing information.

Current implementation uses these 3 files when uploading the recording to asciinema.org.
This however isn't really compatible with live streaming idea and doesn't address all the requirements above.

Option 2: new JSON based format

With frames inlined, to be used when persisted:

{
  version: 1,
  width: 80,
  height: 24,
  frames: [<frame>, <frame>, <frame>...]
}

With frames delegated to an URL, to be used when streaming:

{
  version: 1,
  width: 80,
  height: 24,
  frames_url: "https://....." or "ws://....."
}

frames_url is a URL to streaming endpoint, either http or websocket.

Format of the single frame:

JSON isn't suited to store arbitrary binary data in strings and raw stdout output contains lots of non-printable bytes so we should encode them. Base64 or encoding each byte in hex or utf would do.

[1.234, "bHMgLWxhIC8="]

or

{ delay: 1.234, data: "bHMgLWxhIC8=" }

Streaming endpoint(s) could be implemented to spit out each new frame in a separate line.

Originally created by @ku1ik on GitHub (Aug 11, 2014). Original GitHub issue: https://github.com/asciinema/asciinema/issues/70 Recording should not be tied to asciinema.org. You should be able to: - record to a local file with `asciinema rec <filename>`, - replay locally (in a terminal) from files with `asciinema play <filename>`, - replay locally (in a terminal) from URLs with `asciinema play <url>`, - instruct player on asciinema.org to play from external URL? This is a prerequisite for #49, it is in fact a simpler version of it. Saving/sharing/replaying from a local file means we have to decide on the data format. **Requirements for data format:** - should include raw stdout data with frame timing + (initial) width/height of the terminal window - should be easy to parse and process for `asciinema` and external tools - should allow live streaming - should be easy to read/parse by js player itself (so you can point js player directly to URL containing recording in this format) - the format should be versioned **Option 1: use current format used by asciinema.org** zip file with custom extension (like `.asciicast` for ex), including 3 files: - `meta.json` - with metadata like width/height of terminal, title, etc - `stdout` - raw stdout bytes, - `stdout.timing` - timing information. Current implementation uses these 3 files when uploading the recording to asciinema.org. This however isn't really compatible with live streaming idea and doesn't address all the requirements above. **Option 2: new JSON based format** With frames inlined, to be used when persisted: ``` { version: 1, width: 80, height: 24, frames: [<frame>, <frame>, <frame>...] } ``` With frames delegated to an URL, to be used when streaming: ``` { version: 1, width: 80, height: 24, frames_url: "https://....." or "ws://....." } ``` `frames_url` is a URL to streaming endpoint, either http or websocket. Format of the single frame: JSON isn't suited to store arbitrary binary data in strings and raw stdout output contains lots of non-printable bytes so we should encode them. Base64 or encoding each byte in hex or utf would do. ``` [1.234, "bHMgLWxhIC8="] ``` or ``` { delay: 1.234, data: "bHMgLWxhIC8=" } ``` Streaming endpoint(s) could be implemented to spit out each new frame in a separate line.
kerem closed this issue 2026-03-15 07:43:06 +03:00
Author
Owner

@choucavalier commented on GitHub (Oct 26, 2014):

What's up? When will we be able to keep our records local and use them from our side?

<!-- gh-comment-id:60524903 --> @choucavalier commented on GitHub (Oct 26, 2014): What's up? When will we be able to keep our records local and use them from our side?
Author
Owner

@ku1ik commented on GitHub (Dec 19, 2014):

@toogy once it's ready ;)

<!-- gh-comment-id:67670037 --> @ku1ik commented on GitHub (Dec 19, 2014): @toogy once it's ready ;)
Author
Owner

@crosbymichael commented on GitHub (Dec 19, 2014):

The json objects with base64 seem to work well and is very simple to implement in go as the marshaler handles encoding []byte to base64 if needed.

<!-- gh-comment-id:67682640 --> @crosbymichael commented on GitHub (Dec 19, 2014): The json objects with base64 seem to work well and is very simple to implement in go as the marshaler handles encoding `[]byte` to base64 if needed.
Author
Owner

@muescha commented on GitHub (Dec 19, 2014):

For editing base64 is not good.

It hides the content :(

One requirement should be: content is readable and if i make diffs the i should see which typo i fixed in a version.

Plain text instead of base54 is my priority.

<!-- gh-comment-id:67696476 --> @muescha commented on GitHub (Dec 19, 2014): For editing base64 is not good. It hides the content :( One requirement should be: content is readable and if i make diffs the i should see which typo i fixed in a version. Plain text instead of base54 is my priority.
Author
Owner

@muescha commented on GitHub (Dec 19, 2014):

For editing base64 is not good.

It hides the content :(

One requirement should be: content is readable and if i make diffs the i should see which typo i fixed in a version.

Plain text instead of base54 is my priority.

<!-- gh-comment-id:67696476 --> @muescha commented on GitHub (Dec 19, 2014): For editing base64 is not good. It hides the content :( One requirement should be: content is readable and if i make diffs the i should see which typo i fixed in a version. Plain text instead of base54 is my priority.
Author
Owner

@muescha commented on GitHub (Dec 19, 2014):

Non printable bytes should encoded as human readable commands.

<!-- gh-comment-id:67696854 --> @muescha commented on GitHub (Dec 19, 2014): Non printable bytes should encoded as human readable commands.
Author
Owner

@PragTob commented on GitHub (Dec 19, 2014):

Just FYI, there is a branch on my fork where I already went through the work that files get saved locally and extracted all the ruby files from the web app that were used for post processing: https://github.com/PragTob/asciinema/commits/save-files-locally

I don't have time right now to adjust it to all the requirements listed here, but it could be a starting point. We used it successfully in a project like this :)

<!-- gh-comment-id:67708583 --> @PragTob commented on GitHub (Dec 19, 2014): Just FYI, there is a branch on my fork where I already went through the work that files get saved locally and extracted all the ruby files from the web app that were used for post processing: https://github.com/PragTob/asciinema/commits/save-files-locally I don't have time right now to adjust it to all the requirements listed here, but it could be a starting point. We used it successfully in a project like this :)
Author
Owner

@ku1ik commented on GitHub (Jan 26, 2015):

@muescha I understand this concern. However, it's important that this file is easily readable by javascript. The obvious choice for file format here is JSON. Now, if JSON allowed control characters (range 0x00-0x1F) we could easily store the data directly in JSON strings, ie: "foo\x09bar\x1b[1mbooold\x1b[0m". Unfortunatelly, while Javascript does allow storing both printable characters and control characters in its strings, JSON doesn't (you get parsing error with any decent parser).

I don't really want to create additional, human readable abstraction over control characters, it feels like an unnecessary complication with benefits which don't really justify it. Anyway, I'm happy to discuss all alternatives.

<!-- gh-comment-id:71443955 --> @ku1ik commented on GitHub (Jan 26, 2015): @muescha I understand this concern. However, it's important that this file is easily readable by javascript. The obvious choice for file format here is JSON. Now, if JSON allowed control characters (range 0x00-0x1F) we could easily store the data directly in JSON strings, ie: `"foo\x09bar\x1b[1mbooold\x1b[0m"`. Unfortunatelly, while Javascript does allow storing both printable characters and control characters in its strings, JSON doesn't (you get parsing error with any decent parser). I don't really want to create additional, human readable abstraction over control characters, it feels like an unnecessary complication with benefits which don't really justify it. Anyway, I'm happy to discuss all alternatives.
Author
Owner

@ku1ik commented on GitHub (Jan 26, 2015):

I did a bit more research. I was partially wrong. I did some tests, and looked at JSON format RFC. It seems you cannot encode control characters in JSON string directly (raw byte) or as "\x09", but you can do it by specifying Unicode codepoint value as "\u0009".

It means that this should be possible: "foo\u0009bar\u001b[1mbooold\u001b[0m"

<!-- gh-comment-id:71446680 --> @ku1ik commented on GitHub (Jan 26, 2015): I did a bit more research. I was partially wrong. I did some tests, and looked at JSON format RFC. It seems you cannot encode control characters in JSON string directly (raw byte) or as `"\x09"`, but you can do it by specifying Unicode codepoint value as `"\u0009"`. It means that this should be possible: `"foo\u0009bar\u001b[1mbooold\u001b[0m"`
Author
Owner

@muescha commented on GitHub (Jan 26, 2015):

the idea behind humand readable commands is to edit the json and fix errors/typos or remove sensitive data from recordings.

example how it can be done:

data: {
  { text: "foo" },
  { cmd: "tab" },
  { text: "bar" },
  { cmd: "start_bold" },
  { text: "booold"}.
  { cmd: "end_bold" },
  { cmd: "new_line" },
  { cmd: "move_right" }
}
<!-- gh-comment-id:71481684 --> @muescha commented on GitHub (Jan 26, 2015): the idea behind humand readable commands is to edit the json and fix errors/typos or remove sensitive data from recordings. example how it can be done: ``` data: { { text: "foo" }, { cmd: "tab" }, { text: "bar" }, { cmd: "start_bold" }, { text: "booold"}. { cmd: "end_bold" }, { cmd: "new_line" }, { cmd: "move_right" } } ```
Author
Owner

@ku1ik commented on GitHub (Jan 26, 2015):

@muescha I understand it, sure. However...

To achieve what you described the recorder would need to include a complete and correct ANSI parser. See here for more details: http://www.vt100.net/emu/dec_ansi_parser . Basically, a terminal is a state machine where the meaning of every byte printed to stdout can change between states. You cannot just assume that 0x09 is "tab", because 0x09 can also mean "put" action in "DCS passthrough" state (as seen on this diagram http://www.vt100.net/emu/vt500_parser.png).

I think the best we can get here is to keep the data in UTF-8 encoded string, with every non-printable character encoded as \u1234. For example:

[
  [ 0.123, "foo\u0009bar\u001b[1mbooold\u001b[0m" ],
  [ 2.345, "bar baz\u000aqux quux" ],
  ...
]
<!-- gh-comment-id:71487013 --> @ku1ik commented on GitHub (Jan 26, 2015): @muescha I understand it, sure. However... To achieve what you described the recorder would need to include a complete and correct ANSI parser. See here for more details: http://www.vt100.net/emu/dec_ansi_parser . Basically, a terminal is a state machine where the meaning of every byte printed to stdout can change between states. You cannot just assume that `0x09` is "tab", because `0x09` can also mean "put" action in "DCS passthrough" state (as seen on this diagram http://www.vt100.net/emu/vt500_parser.png). I think the best we can get here is to keep the data in UTF-8 encoded string, with every non-printable character encoded as `\u1234`. For example: ``` JSON [ [ 0.123, "foo\u0009bar\u001b[1mbooold\u001b[0m" ], [ 2.345, "bar baz\u000aqux quux" ], ... ] ```
Author
Owner

@hai-nguyen-van commented on GitHub (Feb 14, 2015):

+1 👍

<!-- gh-comment-id:74385596 --> @hai-nguyen-van commented on GitHub (Feb 14, 2015): +1 :+1:
Author
Owner

@dave-tucker commented on GitHub (Feb 17, 2015):

👍 I'd like to see this functionality.

<!-- gh-comment-id:74684806 --> @dave-tucker commented on GitHub (Feb 17, 2015): :+1: I'd like to see this functionality.
Author
Owner

@ku1ik commented on GitHub (Feb 24, 2015):

Recording and replaying from local files has been implemented in #80. I need to document the new file format and update asciinema.org code to accept it. Then we should have a new release soon.

<!-- gh-comment-id:75796259 --> @ku1ik commented on GitHub (Feb 24, 2015): Recording and replaying from local files has been implemented in #80. I need to document the new file format and update asciinema.org code to accept it. Then we should have a new release soon.
Author
Owner

@hai-nguyen-van commented on GitHub (Feb 24, 2015):

@sickill Thanks

<!-- gh-comment-id:75867977 --> @hai-nguyen-van commented on GitHub (Feb 24, 2015): @sickill Thanks
Author
Owner

@hai-nguyen-van commented on GitHub (Feb 24, 2015):

@sickill Thanks

<!-- gh-comment-id:75867977 --> @hai-nguyen-van commented on GitHub (Feb 24, 2015): @sickill Thanks
Author
Owner

@ku1ik commented on GitHub (Mar 2, 2015):

Hey! Please help testing 1.0.0.rc1: https://github.com/asciinema/asciinema-cli/releases/tag/v1.0.0.rc1

<!-- gh-comment-id:76808801 --> @ku1ik commented on GitHub (Mar 2, 2015): Hey! Please help testing 1.0.0.rc1: https://github.com/asciinema/asciinema-cli/releases/tag/v1.0.0.rc1
Author
Owner

@cmoulliard commented on GitHub (Mar 4, 2015):

I have done some tests with the release 1.0.0.rc1 and that looks great. I have one additional question : Would it be possible to upload the asciinema record not on asciinema.org web site but on our own web server ? Is it possible ?

<!-- gh-comment-id:77167565 --> @cmoulliard commented on GitHub (Mar 4, 2015): I have done some tests with the release 1.0.0.rc1 and that looks great. I have one additional question : Would it be possible to upload the asciinema record not on asciinema.org web site but on our own web server ? Is it possible ?
Author
Owner

@choucavalier commented on GitHub (Mar 4, 2015):

@cmoulliard 👍

<!-- gh-comment-id:77252274 --> @choucavalier commented on GitHub (Mar 4, 2015): @cmoulliard :+1:
Author
Owner

@ku1ik commented on GitHub (Mar 5, 2015):

@cmoulliard thanks for testing.

Re uploading to other place than asciinema.org:

You can set up your own asciinema site and point the recorder to it as described here in FAQ: https://asciinema.org/docs/faq

<!-- gh-comment-id:77383417 --> @ku1ik commented on GitHub (Mar 5, 2015): @cmoulliard thanks for testing. Re uploading to other place than asciinema.org: You can set up your own asciinema site and point the recorder to it as described here in FAQ: https://asciinema.org/docs/faq
Author
Owner

@cmoulliard commented on GitHub (Mar 9, 2015):

@sickill I have done a test using locally on my machine a Python SimpleHTTPServer but I get a error '501' during HTML post communication :

dabouhost:~/Temp/asciinema-test$ ASCIINEMA_API_URL=http://localhost:3000 asciinema rec
~ Current terminal size is 202x41.
~ It may be too big to be properly replayed on smaller screens.
~ You can now resize it. Press <Enter> to start recording.

~ Asciicast recording started.
~ Hit Ctrl-D or type "exit" to finish.
bash-3.2$ echo "Hello"
Hello
bash-3.2$ exit
~ Asciicast recording finished.
~ Press <Enter> to upload, <Ctrl-C> to cancel.

127.0.0.1 - - [09/Mar/2015 09:13:19] code 501, message Unsupported method ('POST')
127.0.0.1 - - [09/Mar/2015 09:13:19] "POST /api/asciicasts HTTP/1.1" 501 -
~ Upload failed, asciicast saved at /var/folders/y5/2w4wn71500q3x4747r0g5bhm0000gn/T/asciicast-520170546
~ Retry later by executing: asciinema upload /var/folders/y5/2w4wn71500q3x4747r0g5bhm0000gn/T/asciicast-520170546
Error: HTTP status: 501 Unsupported method ('POST')

The json file is well created at the location indicated but I suspect that SimpleHTTPServer of Python does not support HTTP POST. Can you make some recommendations please ?

<!-- gh-comment-id:77814571 --> @cmoulliard commented on GitHub (Mar 9, 2015): @sickill I have done a test using locally on my machine a Python SimpleHTTPServer but I get a error '501' during HTML post communication : ``` dabouhost:~/Temp/asciinema-test$ ASCIINEMA_API_URL=http://localhost:3000 asciinema rec ~ Current terminal size is 202x41. ~ It may be too big to be properly replayed on smaller screens. ~ You can now resize it. Press <Enter> to start recording. ~ Asciicast recording started. ~ Hit Ctrl-D or type "exit" to finish. bash-3.2$ echo "Hello" Hello bash-3.2$ exit ~ Asciicast recording finished. ~ Press <Enter> to upload, <Ctrl-C> to cancel. 127.0.0.1 - - [09/Mar/2015 09:13:19] code 501, message Unsupported method ('POST') 127.0.0.1 - - [09/Mar/2015 09:13:19] "POST /api/asciicasts HTTP/1.1" 501 - ~ Upload failed, asciicast saved at /var/folders/y5/2w4wn71500q3x4747r0g5bhm0000gn/T/asciicast-520170546 ~ Retry later by executing: asciinema upload /var/folders/y5/2w4wn71500q3x4747r0g5bhm0000gn/T/asciicast-520170546 Error: HTTP status: 501 Unsupported method ('POST') ``` The json file is well created at the location indicated but I suspect that SimpleHTTPServer of Python does not support HTTP POST. Can you make some recommendations please ?
Author
Owner

@ku1ik commented on GitHub (Mar 9, 2015):

@cmoulliard it's not possible to use any HTTP server to accept asciicasts. You need your own instance of asciinema website. This repository contains the code of the website+API: https://github.com/asciinema/asciinema.org

<!-- gh-comment-id:77817450 --> @ku1ik commented on GitHub (Mar 9, 2015): @cmoulliard it's not possible to use any HTTP server to accept asciicasts. You need your own instance of asciinema website. This repository contains the code of the website+API: https://github.com/asciinema/asciinema.org
Author
Owner

@ku1ik commented on GitHub (Mar 9, 2015):

@cmoulliard it's not possible to use any HTTP server to accept asciicasts. You need your own instance of asciinema website. This repository contains the code of the website+API: https://github.com/asciinema/asciinema.org

<!-- gh-comment-id:77817450 --> @ku1ik commented on GitHub (Mar 9, 2015): @cmoulliard it's not possible to use any HTTP server to accept asciicasts. You need your own instance of asciinema website. This repository contains the code of the website+API: https://github.com/asciinema/asciinema.org
Author
Owner

@cmoulliard commented on GitHub (Mar 9, 2015):

Thx. Should be good to mention that into the FAQ. Is it possible to provide a skeleton of the web project that we could run locally as I suppose that we only need one HTML file + css + javascripts if we would like to integrate asciinema into our own web server ?

<!-- gh-comment-id:77820680 --> @cmoulliard commented on GitHub (Mar 9, 2015): Thx. Should be good to mention that into the FAQ. Is it possible to provide a skeleton of the web project that we could run locally as I suppose that we only need one HTML file + css + javascripts if we would like to integrate asciinema into our own web server ?
Author
Owner

@ku1ik commented on GitHub (Mar 9, 2015):

I'll update FAQ, thanks.

Currently hmlt+js+css wouldn't be sufficient as the recording is being preprocessed after it is uploaded to the website. It's being converted to the simple format that is easy to understand for the JS player.

I plan to update the player so it can directly play asciicasts without a need for any preprocessing. It will be possible then to just have a simple html+js+css combo to host the recordings on your own site, just as you imagined.

<!-- gh-comment-id:77821243 --> @ku1ik commented on GitHub (Mar 9, 2015): I'll update FAQ, thanks. Currently hmlt+js+css wouldn't be sufficient as the recording is being preprocessed after it is uploaded to the website. It's being converted to the simple format that is easy to understand for the JS player. I plan to update the player so it can directly play asciicasts without a need for any preprocessing. It will be possible then to just have a simple html+js+css combo to host the recordings on your own site, just as you imagined.
Author
Owner

@cmoulliard commented on GitHub (Mar 9, 2015):

Thx. Excellent news. Great project indeed.

<!-- gh-comment-id:77821690 --> @cmoulliard commented on GitHub (Mar 9, 2015): Thx. Excellent news. Great project indeed.
Author
Owner

@choucavalier commented on GitHub (Mar 9, 2015):

@sickill: that would be so great 👍

<!-- gh-comment-id:77825265 --> @choucavalier commented on GitHub (Mar 9, 2015): @sickill: that would be so great :+1:
Author
Owner

@ku1ik commented on GitHub (Mar 12, 2015):

1.0 has just been released with local recording support.

<!-- gh-comment-id:78538420 --> @ku1ik commented on GitHub (Mar 12, 2015): 1.0 has just been released with local recording support.
Author
Owner

@cmoulliard commented on GitHub (Mar 12, 2015):

I have done a test but I don't see how I could generate static content for a local web server.

BTW, the help command of asciinema player is not really verbose :

~/Downloads/asciinema-1.0.0-darwin-amd64$ asciinema play -h
Usage of play:
~/Downloads/asciinema-1.0.0-darwin-amd64$ asciinema upload -h
Usage of upload:
<!-- gh-comment-id:78554108 --> @cmoulliard commented on GitHub (Mar 12, 2015): I have done a test but I don't see how I could generate static content for a local web server. BTW, the help command of `asciinema player` is not really verbose : ``` ~/Downloads/asciinema-1.0.0-darwin-amd64$ asciinema play -h Usage of play: ~/Downloads/asciinema-1.0.0-darwin-amd64$ asciinema upload -h Usage of upload: ```
Author
Owner

@ku1ik commented on GitHub (Mar 12, 2015):

@cmoulliard this doesn't look like 1.0. Can you check asciinema --version ?

<!-- gh-comment-id:78554782 --> @ku1ik commented on GitHub (Mar 12, 2015): @cmoulliard this doesn't look like 1.0. Can you check `asciinema --version` ?
Author
Owner

@ku1ik commented on GitHub (Mar 12, 2015):

@cmoulliard this doesn't look like 1.0. Can you check asciinema --version ?

<!-- gh-comment-id:78554782 --> @ku1ik commented on GitHub (Mar 12, 2015): @cmoulliard this doesn't look like 1.0. Can you check `asciinema --version` ?
Author
Owner

@cmoulliard commented on GitHub (Mar 12, 2015):

Here is the version :
~/Downloads/asciinema-1.0.0-darwin-amd64$ ./asciinema --version
asciinema 1.0.0-062ba8a

<!-- gh-comment-id:78621428 --> @cmoulliard commented on GitHub (Mar 12, 2015): Here is the version : ~/Downloads/asciinema-1.0.0-darwin-amd64$ ./asciinema --version asciinema 1.0.0-062ba8a
Author
Owner

@cmoulliard commented on GitHub (Mar 13, 2015):

Is it the latest version ? If this is the case, there is a problem to display the help messages and we can't generate content for local HTTP Server

<!-- gh-comment-id:78977275 --> @cmoulliard commented on GitHub (Mar 13, 2015): Is it the latest version ? If this is the case, there is a problem to display the help messages and we can't generate content for local HTTP Server
Author
Owner

@ku1ik commented on GitHub (Mar 14, 2015):

You used asciinema play -h and then ./asciinema --version. Note the difference: ./

Is it possible that you have 0.9.9 installed in your PATH?

<!-- gh-comment-id:80712908 --> @ku1ik commented on GitHub (Mar 14, 2015): You used `asciinema play -h` and then `./asciinema --version`. Note the difference: `./` Is it possible that you have 0.9.9 installed in your PATH?
Author
Owner

@cmoulliard commented on GitHub (Mar 15, 2015):

Version tested is : ./asciinema --version --> asciinema 1.0.0-062ba8a
Nevertheless, we have discussed the possibility to upload a video/*.json
file to our own web site but this feature is not there as we can't only
upload yo asciinema.org

On Sat, Mar 14, 2015 at 9:39 PM, Marcin Kulik notifications@github.com
wrote:

You used asciinema play -h and then ./asciinema --version. Note the
difference: ./

Is it possible that you have 0.9.9 installed in your PATH?


Reply to this email directly or view it on GitHub
https://github.com/asciinema/asciinema/issues/70#issuecomment-80712908.

Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog : http://cmoulliard.github.io

<!-- gh-comment-id:81171413 --> @cmoulliard commented on GitHub (Mar 15, 2015): Version tested is : ./asciinema --version --> asciinema 1.0.0-062ba8a Nevertheless, we have discussed the possibility to upload a video/*.json file to our own web site but this feature is not there as we can't only upload yo asciinema.org On Sat, Mar 14, 2015 at 9:39 PM, Marcin Kulik notifications@github.com wrote: > You used asciinema play -h and then ./asciinema --version. Note the > difference: ./ > > Is it possible that you have 0.9.9 installed in your PATH? > > — > Reply to this email directly or view it on GitHub > https://github.com/asciinema/asciinema/issues/70#issuecomment-80712908. ## Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
Author
Owner

@ku1ik commented on GitHub (Mar 15, 2015):

See here: https://github.com/asciinema/asciinema/issues/70#issuecomment-77817450

You can set ASCIINEMA_API_URL env var (as described in FAQ on the site) , or set it in configuration file (see Configuration section in readme).

<!-- gh-comment-id:81174458 --> @ku1ik commented on GitHub (Mar 15, 2015): See here: https://github.com/asciinema/asciinema/issues/70#issuecomment-77817450 You can set ASCIINEMA_API_URL env var (as described in FAQ on the site) , or set it in configuration file (see Configuration section in readme).
Author
Owner

@cmoulliard commented on GitHub (Mar 16, 2015):

Question: In one of your comments, you have mentioned that "It will be possible then to just have a simple html+js+css combo to host the recordings on your own site, just as you imagined." Is this feature available now ?

<!-- gh-comment-id:81461393 --> @cmoulliard commented on GitHub (Mar 16, 2015): Question: In one of your comments, you have mentioned that "It will be possible then to just have a simple html+js+css combo to host the recordings on your own site, just as you imagined." Is this feature available now ?
Author
Owner

@ku1ik commented on GitHub (Mar 16, 2015):

Ah, yes. I should have been more clear on that, sorry. I plan to do that in the future, but it's not available yet.

<!-- gh-comment-id:81753987 --> @ku1ik commented on GitHub (Mar 16, 2015): Ah, yes. I should have been more clear on that, sorry. I plan to do that in the future, but it's not available yet.
Author
Owner

@ku1ik commented on GitHub (Mar 16, 2015):

Ah, yes. I should have been more clear on that, sorry. I plan to do that in the future, but it's not available yet.

<!-- gh-comment-id:81753987 --> @ku1ik commented on GitHub (Mar 16, 2015): Ah, yes. I should have been more clear on that, sorry. I plan to do that in the future, but it's not available yet.
Author
Owner

@cmoulliard commented on GitHub (Mar 16, 2015):

This is what you develop here ? https://github.com/asciinema/asciinema-player

<!-- gh-comment-id:81758100 --> @cmoulliard commented on GitHub (Mar 16, 2015): This is what you develop here ? https://github.com/asciinema/asciinema-player
Author
Owner

@cmoulliard commented on GitHub (Mar 16, 2015):

But this project does not support the same json format as you proposed with asciinema 1.0 ...

<!-- gh-comment-id:81801490 --> @cmoulliard commented on GitHub (Mar 16, 2015): But this project does not support the same json format as you proposed with asciinema 1.0 ...
Author
Owner

@cmoulliard commented on GitHub (Mar 16, 2015):

The projects is almost done excepted that code "asciinema player" and "ascinema player js" should be aligned to support the same json format

I have done a small modification to already pass as parameter the json file recorded by asciinema

<script>
 /* Example of url : http://localhost:8000/?video=demo.json */
  var video = GetURLParameter("video");
  var source = new asciinema.HttpArraySource(video, 1);

 /*
  * Extract parameters from URL
  */
  function GetURLParameter(sParam) {

      var sPageURL = window.location.search.substring(1);
      var sURLVariables = sPageURL.split('&');

      for (var i = 0; i < sURLVariables.length; i++) {

        var sParameterName = sURLVariables[i].split('=');
        if (sParameterName[0] == sParam) {
            return sParameterName[1].replace(/\/$/g,'');
        }
      }
  }
    asciinema.Player({ autoPlay: false, movie: movie }),
    document.getElementById('player-container')
  );
</script>
<!-- gh-comment-id:81803507 --> @cmoulliard commented on GitHub (Mar 16, 2015): The projects is almost done excepted that code "asciinema player" and "ascinema player js" should be aligned to support the same json format I have done a small modification to already pass as parameter the json file recorded by asciinema ``` <script> /* Example of url : http://localhost:8000/?video=demo.json */ var video = GetURLParameter("video"); var source = new asciinema.HttpArraySource(video, 1); /* * Extract parameters from URL */ function GetURLParameter(sParam) { var sPageURL = window.location.search.substring(1); var sURLVariables = sPageURL.split('&'); for (var i = 0; i < sURLVariables.length; i++) { var sParameterName = sURLVariables[i].split('='); if (sParameterName[0] == sParam) { return sParameterName[1].replace(/\/$/g,''); } } } asciinema.Player({ autoPlay: false, movie: movie }), document.getElementById('player-container') ); </script> ```
Author
Owner

@ku1ik commented on GitHub (Mar 16, 2015):

The JS player expects preprocessed data and it doesn't support new asciicast format directly. asciinema.org is converting this new json format into the simple format that is readable by the player.

I'll be working on updating the player to support new format directly. Once it's done the code you proposed will work indeed.

<!-- gh-comment-id:81908352 --> @ku1ik commented on GitHub (Mar 16, 2015): The JS player expects preprocessed data and it doesn't support new asciicast format directly. asciinema.org is converting this new json format into the simple format that is readable by the player. I'll be working on updating the player to support new format directly. Once it's done the code you proposed will work indeed.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/asciinema#667
No description provided.