What is even more annoying is that you can only do a full disable. You can’t disable AC1/VP9 video decode but leave image decode intact.

There are also likely opportunities for additional efficiencies when you make a custom {en,de}coder for your system. I suspect (but haven't confirmed) that the typical Intel/AMD/Nvidia/Apple multi-function media engine isn't just a collection of completely independent encoder/decoder blocks for each codec but a kind of simplified specialized microcoded CPU with a collection of fixed-function blocks which can be shared between different codecs. So it could have blocks that do RGB->YUV conversion, Discrete Cosine Transforms, etc. and you can use the same DCT block for AV1, HEVC, and AVC. Maybe you can also create specialized efficient ways to transfer frames back and forth with the GPU, for sharing cache with the GPU, etc.

I'm guessing this is a distinct region of the chip and not integrated with CPU/GPU since they scale up by replicating those blocks and wouldn't want to redundantly place that hardware. Having it separate also allows a team to work on it independently.

I think the relative size of the media engines is accurate in that slide, so then it comes down to how large the ProRes parts are in other chips. They are probably a couple of the unlabeled regions next to the performance cores in the M1 Pro die shot below, but I don't know which.

https://images.anandtech.com/doci/17019/M1PRO.jpg Taken from: https://www.anandtech.com/show/17024/apple-m1-max-performanc...

Maybe I'm misunderstanding what you're saying, but the slide is of an A17, not an M3 chip.

What you see is that they implement different features with Google obviously wanting the browser to be a full blown OS. So they added things like MIDI support and web pages being able to access the battery.

The problem with many of those features is that they have been shown by researchers to either (a) be insecure or (b) allow web pages to uniquely fingerprint your device. This is obviously an anathema to everything Apple believes in.

[1] https://caniuse.com/?compare=chrome+121,edge+118,safari+17.2...

I don't quite understand the industry push for AV1. I appreciate that it's patent-unencumbered, but it makes very little sense from business perspective, as you still need to support h264 and/or h265 for devices that can't decode av1 in hardware (and let's agree that forcing software decoding for video should be criminal). So you add a third codec variant (across several quality tiers) to your stack, cost per minute (encode, storage) goes up, engineering/QA effort goes up... Where's the value? Hence my original question, is AV1 really that much better to justify all that?

No? You're talking in terms of PC / phone hardware support only. HEVC was first released June 7, 2013. The UHD Blu-ray standard was released less than 3 years later on February 14, 2016 - and it was obvious to everyone in the intervening years that UHD Blu-ray would use HEVC because it needed support for 4k and HDR, both of which HEVC was specifically designed to be compatible with. (Wikipedia says licensing for UHD Blu-ray on the basis of a released spec began in mid 2015.)

This sounds like you might be confusing that MPEG2TS might have something to do with the video encoding instead of it solely being the way the video/audio elementary streams are wrapped together into a single contained format. The transport stream was designed specifically for an unreliable streaming type of delivery vs a steady consistent type of source like reading from a dis[c|k]. There is nothing wrong with using a TS stream for HLS that makes it inferior.

Well, there's now H.266 as well:

* https://en.wikipedia.org/wiki/Versatile_Video_Coding

Really? Muxing generally doesn't require one to decode the actual data - merely shuffle around blocks of data with memcpy() so should be really cheap.

Roku's latest devices to support AV1, so I guess either the price came down, they struck a deal, or Roku just lost to the market pressure after Netflix pushed for AV1 as well.

I don't know how that can be viewed as a good thing.

People used to want to write them because they thought GPU=fast and shaders=GPU, but this is just evidence that almost noone knows how to write a video codec.

Now things like NVENC are even worse in terms of compression. Any GPU accelerated encoder trades compression efficiency for speed. Even x265 with the slowest presets will demolish any GPU encoder in terms of compression, including the MainConcept paid one when it's run in GPU-accelerated mode. This is unfortunately not explained in GUIs like Adobe tools. They just have a checkbox or dropdown to select GPU acceleration, but don't mention that it's not just acceleration - a different algorithm will be used that can't achieve the best compression.

GPU accelerated compression can still be very useful for scenarios where you need speed (e.g. have a deadline) or just don't care about quality (e.g. will publish it only on social media where it will be recompressed anyway). However when you have time to wait and want top quality, the slowest CPU-only code path will always win.

--

[1] One good public resource is the Moscow State University page http://www.compression.ru/video/codec_comparison/index_en.ht... -- They do regular comparisons of various codecs and some results are available for free. A bit in HTML form and more in some of the PDFs. Deeper insights are unfortunately paid.

I concur. The raison d'être for AV1 is (lack of) patent license royalties. These apply to user devices as well as services. Think Google: Android as well as YouTube cost fortunes in AVC/HEVC licenses, so here AV1 makes sense.

On the other hand, Apple sells expensive hardware and has no problem ponying those licenses. Soon after adopting HEVC they doubled down with Dolby Vision which technically adds very little on top of standard HDR features already available in HEVC and AVC but present serious interop problems for device come with shiny Dolby stickers.