With low enough resolution, framerate and bitrate, you can get a quality stream without significant encoding artifacts compared to any other codec. It is in production right now and has been for a while.

The tradeoff CPU / bandwidth is quite advantageous in situations like this. And no, AV1 HW encoders cannot usually be used, they are not designed for a tight bitrate control or realtime communications like software encoding is usually.

I remember watching Akira, some DBZ movies, Evangelion, Vision of Escaflowne, Armitage III and many others!

While it's not without faults (services do not always support alternative authentication which may support foreigners having the right to live in the country), it has been quite reliable for so many years.

So just to say, you can have successful alternatives to a government controlled system as many actors may decide it is quite valuable to develop and maintain such a system and that it aligns with their interest, and then have it become a de-facto standard.

And you would sign your files, which get verified by the integrity platform and allow you to authenticate with the servers securely.

In some other cases, I've used a pattern where I used a symlink to folders. The symlink is created, resolved or updated atomically, and all I need is eventual consistency.

That last case was to manage several APT repository indices. The indices were constantly updated to publish new testing or unstable releases of software and machines in the fleet were regularly fetching the repository index. The APT protocol and structure being a bit "dumb" (for better or worse) requires you to fetch files (many of them) in the reverse order they are created, which leads to obvious issues like the signature is updated only after the list of files is updated, or the list of files is created only after the list of packages is created.

Long story short, each update would create a new folder that's consistent, and a symlink points to the last created folder (to atomically replace the folder as it was not possible to swap them), and a small HTTP server would initiate a server side session when the first file is fetched and only return files from the same index list, and everything is eventually consistent, and we never get APT complaining about having signature or hash mismatches. The pivotal component was indeed the atomicity of having a symlink to deal with it, as the Java implementation didn't have access to a more modern "openat" syscall, relative to a specific folder.

Since Teams is using the very old H264 codec and Meet is using VP8 or VP9 depending on the context, it's possible you also had some other issues with bad decoding (usually done in software, but occasionally by the hardware).

Overall, it shouldn't be representative of the experience on Meet that I've seen, even from all the bug reports I've read.

But since each product in some different domains had to actively enable those optimizations for themselves, they were occasionally forgotten, and I found a few in the app I worked for (but not directly on).

And for video streaming, AV1 is becoming increasingly used on Youtube and Netflix for example ( https://aomedia.org/av1-adoption-showcase/netflix-story/ )/.

It is used a lot more for people who don't have to worry too much about licensing at scale, such as pirate content or local streaming (quite often backed by an OS wide license). Doing a quick search on various pirate content search engine, I can see a lot of AV1 content now, so it'll eventually get more popular!

Each new codec to support is adding a lot of complexity to the stack (negotiation issues, SFU implementation, quality tuning, dealing with non conformant implementations...), so it's never quite as easy as toggling a switch to enable them.

But also, HW encoding of some codecs is not always of great quality and doesn't support the advanced features required for RTC, so the CPU encoding code-path is sometimes even forced! While it doesn't necessarily apply to HEVC as you'd need a license for it (and almost all apps rely on the system having one), it's happening for VP9 or AV1 occasionally more frequently.

What do you do if you use a compiler or linker that doesn't use the same command line parameters as they are written in the pc file? What do you do when different packages you depend on have conflicting options, for example one depending against different C or C++ language versions?

It's fine in a limited and closed environment, it does not work for proper distribution, and your Bazel rules prove it as it is not working in all environments clearly. It does not work with MSVC style flags, or handles include files well (hh, hxx...). Not saying it can't be fixed, but that's just a very limited integration, which proves the point of having a better format for tool consumption.

And you're not the only one who has worked in a FAANG company around and dealt with large and complex build graphs. But for the most part, FAANGs don't all care about consuming pkg-config files, most will just rewrite the build files for Blaze / Bazel (or Buck2 from what I've heard). Very few people want to consume binary archives as you can't rebuild with the new flavor of the week toolchain and use new compiler optimizations, or proper LTO etc.

There's is a new standard that is being developed by some industry experts that is aiming to address this called CPS. You can read the documentation on the website: https://cps-org.github.io/cps/ . There's a section with some examples as to why they are trying to fix and how.

It's simple, with proper tooling, you know exactly the dependencies, so you know which test depend on the affected files and can run those tests, the rest shouldn't be impacted. And that tooling exists. It's not the one you may be using, but it exists, and not just in FAANG.