←back to thread

WebSockets cost us $1M on our AWS bill

(www.recall.ai)
261 points tosh | 3 comments | 06 Nov 24 18:50 UTC | HN request time: 0s | source
Show context
cogman10 ◴[06 Nov 24 20:07 UTC] No.42068537[source]▶
This is such a weird way to do things.

Here they have a nicely compressed stream of video data, so they take that stream and... decode it. But they aren't processing the decoded data at the source of the decode, so instead they forward that decoded data, uncompressed(!!), to a different location for processing. Surprisingly, they find out that moving uncompressed video data from one location to another is expensive. So, they compress it later (Don't worry, using a GPU!)

At so many levels this is just WTF. Why not forward the compressed video stream? Why not decompress it where you are processing it instead of in the browser? Why are you writing it without any attempt at compression? Even if you want lossless compression there are well known and fast algorithms like flv1 for that purpose.

Just weird.

replies(4): >>42068622 #>>42068813 #>>42069256 #>>42070259 #
rozap ◴[06 Nov 24 20:27 UTC] No.42068813[source]▶
Really strange. I wonder why they omitted this. Usually you'd leave it compressed until the last possible moment.
replies(1): >>42069220 #
1. dylan604 ◴[06 Nov 24 20:55 UTC] No.42069220[source]▶
> Usually you'd leave it compressed until the last possible moment.

Context matters? As someone working in production/post, we want to keep it uncompressed until the last possible moment. At least as far as no more compression than how it was acquired.

replies(1): >>42069663 #
2. DrammBA ◴[06 Nov 24 21:25 UTC] No.42069663[source]▶
> Context matters?

It does, but you just removed all context from their comment and introduced a completely different context (video production/post) for seemingly no reason.

Going back to the original context, which is grabbing a compressed video stream from a headless browser, the correct approach to handle that compressed stream is to leave it compressed until the last possible moment.

replies(1): >>42070110 #
3. pavlov ◴[06 Nov 24 21:57 UTC] No.42070110[source]▶
Since they aim to support every meeting platform, they don’t necessarily even have the codecs. Platforms like Zoom can and do use custom video formats within their web clients.

With that constraint, letting a full browser engine decode and composite the participant streams is the only option. And it definitely is an expensive way to do it.