←back to thread

362 points tosh | 1 comments | | HN request time: 0.381s | source
Show context
cogman10 ◴[] 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(5): >>42068622 #>>42068813 #>>42069256 #>>42070259 #>>42074207 #
1. dmazzoni ◴[] No.42074207[source]
> Here they have a nicely compressed stream of video data

But they don't.

They support 7 different meeting providers (Zoom, Meet, WebEx, ...), none of which have an API that give you access to the compressed video stream.

In theory, you could try to reverse-engineer each protocol...but then your product could break for potentially days or weeks anytime one of those companies decides to change their protocol - vs web scraping, where if it breaks they can probably fix it in 15 minutes.

Their solution is inefficient, but robust. And that's ultimately a more monetizable product.