Hacker Newsnew | past | comments | ask | show | jobs | submit | smalltorch's commentslogin

This is Cinema.

what's involved in transcoding a video to this custom codec?


There isn't actually any custom video transcoding or preprocessing involved at all! It plays standard format videos (like stock .mp4, .mkv, or .webm) natively, completely on the fly. It spins up a background thread using libmpv which decodes the standard video file and hands me raw RGB frames in memory. The custom engine then takes those frames and heavily downsamples them using a Box Filter. Then it maps each 2x4 "pixel" block into its exact corresponding UTF-8 Braille character representation.

Very cool. What does the example in your repo look like regularly? Would give a good representation as a side by side.

On average, How much data per second would the stream be?


"If privacy is outlawed, only outlaws will have privacy"

I like that statement.


There's also a application called deflock that lets you map them easy

Yes, that's the submission we're commenting on ;)

Haha. I meant an Android application. The website doesn't let you submit. The app makes it easy to submit.

For anyone following 1.1.5 now has support for group calls. Now use terminalphone as a dedicated relay. All users connect to the relay and the messages will be broadcasted to everyone in the group.

A mobile relay should be able to handle 3-5 users nicely. A dedicated machine with a stable connection should be preferred.

You can act as the relay and caller by running two instances, you will need to change your socks port of the second instance so that you can have two addresses.

Relay does not need to have the shared secret, it is simply forwarding payloads, and broadcasting connected client counts.


Very cool.

Take notes other AI companies. This is a totally fine line to draw and it's not even that high bar.

Dont allow systems to be built with your AI that automate mass surveillance or automate kill decisions.


The disappointing this is someone _will_ do it, you know it’s going to happen.

Someone? You say it like it's unknown that OpenAI got the contract

I meant in the general sense - you could have all the major players take a moral stance and say “no” but someone would say yes eventually.

> Dont allow systems to be built with your AI

those systems will be built regardless. That type of boycott being asked from companies is essentially asking companies to not make profit where there's profit to be made, when those doing the asking is not also taking in any sacrifices for this boycott.

Instead of asking companies to be altruistic, those wanting such systems to be illegal should be using the civic system we have today to make it so - yes, this costs effort, resources and time. Like all hard things.


The thing is, other companies can pick up that slack. Heck even distillation attacks against claude can be used to create such models

With the price of tokens I think mass surveillance with AI is not a realistic use case.

There already is a mass surveillance. Presumably most electronic communication is monitored. I guess LLMs can likely do a somewhat better job but probably not worth the cost for the marginal benefit over existing technologies?

Similarly for "Terminators" or other AI killing machines... Isn't it cheaper to use a human? We have autonomous weapons already, like cruise missiles... Other than the movies what does a reality with LLMs pulling triggers look like? Cars are also "killing machines" and we're letting computers drive them...

Unfortunately if these things do start making sense for whatever reason they're probably going to happen. Private companies in general have no way to prevent their technology from being used for "defense" applications. Once that genie is out of the bottle it's not going back in.


> With the price of tokens I think mass surveillance with AI is not a realistic use case.

Congratulations, today you're one of the lucky 10,000: https://en.wikipedia.org/wiki/Sentient_(intelligence_analysi...


Having a human in the loop for automated kill decisions is such a low bar. Is there something more to it?

I'm glad anthropic stood their ground. Is this suppose to look bad on the company or something?

This looks terrible for the trump administration I hope other platforms follow suit. Using AI for automated mass surveillance is not winning the ai race.


This would be a great improvement and I'm going to look into how to implement!

The most obvious path is just integrating the authorized clients Tor has already built in. A way to export these keys efficiently to your intended recipient.


I am totally interested in a 2kbs encoding if that's possible. I didn't think opus could encode below 6. Making this as slim as possible is definitely what I'm aiming for. Really though the latency basically all coming from Tor.

Someone also suggested that you can configure Tor to take only one hop. You loose anonimity but gain speed right away. May be something to look into as optional setting.

I also learned today I can pipe direct binary without encoding base64. This will chop overhead right away. I didn't think it was possible to pipe through bash but I was using the wrong command.

I do plan to continue to optimize that's great feedback thanks!


When I started prototyping it's started as full duplex. I was up for the challenge and wanted to understand why this already didn't really exist.

It ended up being awful. A standard real time call your able to interject and talk over someone and this works because of the low latency. The other person can stop talking and the conversation still flows.

The latency from Tor just makes it awkward to the point that you have to almost relearn how to have a conversation since by the time your interjecting and they hear the interjection, a whole 6 seconds may have passed and they may already be on a whole other train of thought. Walkie talkie architecture just forces you to listen and digest the message, think, respond.

There are two layers of encryption here. Tor, which already is encrypting the data, and locally via openssl before transmit.

I have 21 ciphers programed in from the openSSL library. There's a lot more available in the library but these are supposedly the strongest. The cipher used is not secret so while in the call you can see your cipher, and the remote cipher real time.

The authentication is resting entirely in the users lap. It's up to them how to come up with key exchange.

For me, I would be comfortable enough knowing the other side is who I think it is by the simple fact that audio is passing through. Establishing a connection once in person is most ideal.

Because the .onion is derived on device, an attacker can't just forge that. You need also need the private key for a connection to be established.

Let's say an attacker copies the directory from one of the endpoints and has the private key now and can launch tor under your static address. Well, because the additional shared secret is encrypted with another password known only to the user it's useless. The other side will not be receiving forged audio because of this barrier. They may get as far as being in a call, but no audio is going to be played back because the shared secret was successful protected. Even if you pass your message to the attacker, decryption will fail and nothing will pass.

Directly after sending, we run rm -f on $raw_file, $opus_file, $enc_file.

Audio is recived to /audio folder. After audio is decrypted and played we run rm -f $enc_file, $dec_file. There is only a split second that it lives on disk until it's gone.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: