Back a while I tried to implement a MP4 demuxer, and I can kind of relate to that. The mdat box is sometimes an opaque blob and you need to parse the codec framing to split packets (fMP4 helps with this a bit), each codec has its own set of boxes, and the specs for each of them are paywalled...
Matroska/WebM is so much simpler and easier to parse, you can essentially abstract it away in a JSON-like DOM (obviously without loading 1GB of data into memory) and just get what you want, it's great.
ReferenceSource is the code from the Windows framework and I'm pretty sure it should be considered deprecated at this point. The runtime and core libraries are now at https://github.com/dotnet/runtime, kinda weird that this is not directly linked in the home page repo.
It really saddens me that their post was removed from r/Minecraft, for crediting a server by including its IP address for literally one second in the video.
In general yes, the "community mod" concept has been mostly dead for a very long time and major communities are in general run by by zealots with ideology and/or financial interest.
At least one can find niche communities with healthy discussion/debate as primary interest.
Soon to be official policy based on their statements at the moderator convention:
"I want our users, user-users and moderator users, to make money on reddit. Specifically, I want them to make money from other users. And so we need to have business models where users are paying money to other users or to subreddits. I would like subreddits to have the ability to be businesses. We have a lot of subreddits that are kind of trying to do this, but the platform just doesn't support it."
It's especially weird becuase in the last year or two reddit has cranked their capricious and opaque moderation up to 11-- it would be suicidal to base your livelihood on that platform where you could be shut off at an instant and without recourse just due to a false report campaign from a competitor, troll, or extortionist.
One fast way to do palette reduction is by using a 16-bit RGB565 lookup table filled with all the closest colors relative to each entry index, then you can replace each pixel in the image using just a few bitwise ops and one array access.
I went a different way, converting each pixel to its LAB color space values to find the optimal palette for the image (based on preference arguments), then afterwards measuring each pixel against the palette colors to find the two closest colors before deciding which of those two colors to pick based on a distance propensity weighting against the semi-random number assigned to that pixel.
Coming up with highly efficient algorithms (for anything!) is not my strongest skill. Neither is trying to explain them.
It seems that the exact opposite problem (phi elimination / translating out of SSA form) is rarely discussed in depth, especially in introductory material.
From what I've seen, most compilers rely on the register allocator to deal with this problem (which makes total sense), or just don't bother at all and instead keep SSA in "conventional" form.
But the problem isn't really that difficult. In Sreedhar/Boissinot et al.'s paper (which btw has a typo in the copy sequentialization algorithm), the idea is quite simple: create copies for each phi argument, plus an additional copy for the phi result, then coalesce those copies to the same variable if their live-ranges don't intersect. The devil is on the details of course, and it just takes a lot more effort to implement compared to the text book construction algorithm.
From my research, it seems like SDF is a best suited for game engines to use for text, especially non-UI text (that may appear at arbitrary sizes), as it is a fast, space-efficient, and easily scalable approximation.
Unfortunately, SDF tends to lose precision at corners, making it less good for text-oriented applications. It does seem like multi-channel SDF improves on the corner precision issues (as highlighted by the repo you linked to), but in a terminal, we don't frequently need to render text at different scales, so not sure there is much benefit. (If a user changes font sizes, we can clear out and rebuild the atlas sufficiently quickly.)
That said, I could borrow some ideas from MSDF to improve on space efficiency by encoding the three different offset variants into separate color channels at the same atlas location, reducing size of the atlas itself as well as the hashmap used to look up atlas position from glyph ID and whatnot.
There's also the chroma subsampling issue. With the standard 4:2:0 ratios, you'll get half the resolution for the two chroma channels, and if I'm not mistaken, they are more aggressively quantized.
It would be better to use YUV/YCbCr directly instead of RGB.
I've seen a lot of Spotify downloaders using librespot and similar. An interesting exception is Soggfy, which just hooks and dumps the ogg files from the Spotify client.
Matroska/WebM is so much simpler and easier to parse, you can essentially abstract it away in a JSON-like DOM (obviously without loading 1GB of data into memory) and just get what you want, it's great.