4 ms·
Their business is joining meetings from 7 different platforms (Zoom, Meet, WebEx, etc.) and capturing the video. They don't have control of the incoming video
by dmazzoni 2y ago
Their business is joining meetings from 7 different platforms (Zoom, Meet, WebEx, etc.) and capturing the video.
They don't have control of the incoming video format.
They don't even have access to the incoming video data, because they're not using an API. They're joining the meeting using a real browser, and capturing the video.
Is it an ugly hack? Maybe. But it's also a pretty robust one, because they're not dependent on an API that might break or reverse-engineering a protocol that might change. They're a bit dependent on the frontend, but that changes rarely and it's super easy to adapt when it does change.
- lostmsu 2y agoEven in this case it is non-sensical. Dunno about Linux, but on Windows you'd just feed the GPU window surface into a GPU hardware encoder via a shared texture with basically 0 data transmission, and get a compressed stream out.
- h4ck_th3_pl4n3t 2y agoI'm not sure you understood what I meant. They are in control of the bot server that joins with the headless chrome client. They can use the CDP protocol to use the screencast API to write the recorded video stream to filesystem/disk, and then they can literally just run ffmpeg on that on-disk-on-server file and stream it somewhere else. But instead they decided to use websockets to send it from that bot client to their own backend API, transmitting the raw pixels as either a raw blob or base64 encoded data, each frame, not encoded anyhow. And that is where the huge waste in bandwidth comes from. (The article hints to this in a lot of places)
- yencabulator 2y agoThey are doing e.g. transcriptions live as the stream happens, not writing a file and batch processing later.