Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A Simple terminal-based video chat – renders in ASCII and has audio

github.com

Post reply on HN
Print view View original

11–20 of 48 posts

Re: Show HN: A Simple terminal-based video chat – renders in ASCII and has audio

#14

Post by emgram769 »

zaroth wrote: post #11

It's almost too high fidelity. Wow. One request - what's the bitrate? (I know it's probably possible to measure in 1 line of shell)

well it is 100x40 in number of characters and there are 10 different characters that can take on one of 256 colors. that's 4000 x (8 (256 colors can be represented in 8 bits) + 4 (10 characters in 4 bits)) = 48Kb per frame, with about 20 fps. so maybe 120 KB/s?

Re: Show HN: A Simple terminal-based video chat – renders in ASCII and has audio

#16

Post by emgram769 »

bwy wrote: post #5

This is awesome! Wonder how it compares with mine (github.com/billyeh/termchat). Would love to share notes with the maker, since audio was something I did not even consider while I was making it. The image processing part is fun, though!

I helped create it at a recent hackathon. the ascii is rendered by calculating the intensity of any given pixel, mapping that intensity to a character based on how much that character fills up space ('@' would be bright and '.' would be dark) and then approximating the color of the pixel to fit within the 256 available

I've noticed your implementation uses websockets, which are built on top of TCP. we used UDP and encapsulated everything is a pretty simple to use (and easily the most well documented part of the project) p2plib.c. the fear was that video and audio can get backed up if we were to use TCP. so audio and video were sent via UDP packets and rendered every time a UDP packet was recieved.

Re: Show HN: A Simple terminal-based video chat – renders in ASCII and has audio

#17

Post by SwellJoe »

qopp wrote: post #10
dangayle wrote: post #6

Wouldn't something like this be easier to encrypt for transmission than normal video? Plus, in the case it comes up, "that ascii representation doesn't look anything like me and you can't prove it was me." I like it.

I think it would actually be "harder" to encrypt since it wouldn't be as compressible as normal video (if you lower the resolution to match). Note you can tunnel arbitrary ports in ssh for data if that's what you're thinking of.

Text is extremely compress-able. Admittedly, this is not common text, and is many "snapshots" of the whole screen, but I believe LZ-based compression would still be extremely effective on this data. The OP above said it can only be one of ten characters, and one of 256 colors, and a 100x40 grid, so it would likely require similar data rates to get this level of quality from a video stream, I would think, since the 10 characters provide more visual information than a simple colored pixel of that size could convey.

Re: Show HN: A Simple terminal-based video chat – renders in ASCII and has audio

#18

Post by dangayle »

jacobparker wrote: post #7
dangayle wrote: post #6

Wouldn't something like this be easier to encrypt for transmission than normal video? Plus, in the case it comes up, "that ascii representation doesn't look anything like me and you can't prove it was me." I like it.

Why would it be any easier to encrypt? It's data just the same. I wouldn't rely on terrible quality video for plausible deniability but if you want to there are of course many ways to make your webcam feed shitty looking.

Easier in the sense of less data, which would make it faster. One of the issues with encrypted video chat is that most implementations have a max amount of people you can chat with because of the computing overhead.

Re: Show HN: A Simple terminal-based video chat – renders in ASCII and has audio

#19

Post by 13 »

emgram769 wrote: post #16
bwy wrote: post #5

This is awesome! Wonder how it compares with mine (github.com/billyeh/termchat). Would love to share notes with the maker, since audio was something I did not even consider while I was making it. The image processing part is fun, though!

I helped create it at a recent hackathon. the ascii is rendered by calculating the intensity of any given pixel, mapping that intensity to a character based on how much that character fills up space ('@' would be bright and '.' would be dark) and then approximating the color of the pixel to fit within the 256 available I've noticed your implementation uses websockets, which are built on top of TCP. we used UDP and en…

You can go a bit further to get significantly higher color depths using ASCII block characters 176, 177, 178. By using the foreground and background ANSI colors and blending them by using these three characters (25%, 50%, 75%) you can achieve some quite realistic images. If you're more interested in resolution, using half block characters like 220 and 223 can allow you to double your vertical resolution at the cost of not being able to use the color trick.
Post reply on HN