Thus:

1. Code which processes untrusted input

2. Code written in unsafe languages like C or C++

3. Code that runs without a sandbox

So ffmpeg should be sandboxed, same as the network code and GPU process are sandboxed.

Of course when I search on DDG I only get "wow the fast inverse square root"

It just means that visible or IR light (What are they using?) won't leak through walls the way Wi-Fi does. Depending on how wide the beam is and exactly how it all works, it _might_ still leak out of windows and under doors. But it's not like someone casually wardriving outside your house will get as much as they would from Wi-Fi, I would think.

The most primitive version is just launching one process per request, piping the HTTP request into stdin, and piping the response out of stdout.

It works, but you can imagine the startup latency is rough and it takes a lot of resources.

There are faster variations that try to reduce the overhead. Ironically FaaS is sort of a rebirth of CGI

Stuff like static, film grain, particles like snow or rain, those all suck up bits from the same encoding budget.

"Why Snow and Confetti Ruin YouTube Video Quality" by Tom Scott probably explains it nicer than I can https://www.youtube.com/watch?v=r6Rp-uo6HmI&pp=ygUaYnJlYWtpb...

This could be a problem for video game streaming, and it could affect the artistic decisions a game studio makes - Drawing a billion tiny particles on a local GPU will look crisp and cool, but asking a hardware encoder to encode those for consumer Internet (or phone Internet) might be too much. I think streamers have run into this problem already.

Sine and cosine waves have a property that you can approximate a signal by just taking the dot product with these basis functions to get a list of coefficients, and then you multiply those coefficients with the basis functions to get the original signal back. Not all functions are basis functions.

You can see that the upper-left one is all white, that's the "DC" (Direct Current) basis. As you go right and down, they increase in frequency.

So the encoder gets all the coefficients and then it quantizes the high-frequency ones to save bits. That's why JPEGs often have ringing / rippling artifacts where an edge will be sharp but have waves coming out on either side.

If you quantize the coefficients enough, then some of those bottom-right ones end up quantizing to zero. So JPEG encoders run a lossless compression step on the coefficients to squish all the zeroes and small values together. You can crunch a JPEG smaller by replacing this lossless compression with a newer algorithm.

And the decoder just inflates those coefficients and multiplies them by the same basis functions to get the bitmap back.

There's details I don't understand in the middle like loop filters and de-blocking filters to hide the 8x8 block artifacts, but the heart of it is just "take a dot product with these functions to encode, multiply those dots with the same functions to decode".

Like, I understand FFTs and DCTs. But the explanation for how to construct filters in software is pathetic.

I looked at the code for VCVRack but could not understand it. It's already optimized for SIMD, processing 4 signals at once, which didn't help readability. (I'm sure it's very fast though)

I don't mind it much. I don't have great social skills but I don't mind answering simple questions. If someone is insulted by simple questions, they're probably gonna be a bad mentor to junior devs, right?