What I think the AV1 initiative neglects as a way of spreading their tech would be giving away a great open implementation of an encoder. x265 and x264 spread their respective codecs all over the internet through pirated content, which forced adoption. The fact that you can play .mkv files almost anywhere now is a testament to that.

There's 3 that I know of,

libaom https://aomedia.googlesource.com/aom, the reference implementation.

https://gitlab.com/AOMediaCodec/SVT-AV1 - from the Alliance for Open Media, which Intel is deeply involved with and is spending a lot of time optimising.

https://github.com/xiph/rav1e - written in rust, also subject to a lot of optimising. It's not complete coverage of all features, intended to be used for places where libaom is too slow.

I have used x265 fairly easily to encode a 4K Bluray. None of the AV1 options seem to have the required performance (both quality and encoding speed) and ease of use.

SVT-AV1 has been both faster and higher quality than x265 for awhile now though? For ease of use, you can just use ffmpeg, or one of the many CLIs or GUIs that support AV1 (preferably either Av1an for CLI, or a gui that uses it under the hood eg. nmkoder).

https://i.imgur.com/hHs2qz9.png

This is false, relative to x265, there is some preset which provides both faster encoding and higher "quality", iso-bitrate, across the whole gamut of x265 settings, and I believe x264 as well, although I am not entirely sure about what is available at the extreme inefficient/fast end (the usefulness of which is questionable).

Also dav1d

Actually no, dav1d is a decoder

I think backing companies like Google and Netflix don't care about that. They need hardware decoding support in phones and TVs, and they will serve av1 from their platforms and save a lot of money. It might become the dominant codec without you even noticing it.

Sure, but I meant that hardware support is implemented if vendors are forced to support something -- such as user downloaded files.

Netflix will serve both av1, h265 and h264, so my TV doesn't have to implement av1 support.

HW vendors have already/are implementing AV1 because they were on the big consortium and the industry is a bit more grown up now.

AV1 is a big compromise between a bunch of vendors. It is definitely the future, the powers that be have already decreed this, but these things move slowly.

Couldn’t they reuse the tensor cores that are shipped in every device at this point? There are already lots of papers on compressing images using deep learning, I don’t see any reason why the companies couldn’t make a video standard that relies on that hardware.

having a hardware encoder and decoder on a device is super useful for streaming content of that device. Not sure I would want to use other compute for that, that compute is much better used doing CV on the video stream :)

Why do you think so? Those tensor processors are actually already optimized for video processing: all of the complex postprocessing in the iPhone camera app is done by the tensor cores inside the M1 chip. I wouldn't be suprised if it would already far be able outperform the mentioned codecs, but of course it needs lots of software development that can only be done by the big companies.

A codec it’s static, almost not changing at all over a decade. This allow you to implement it as a single purpose hardware which is orders of magnitude more efficient and fast than code running in a multipurpose chip, tensor or not.

For things that evolve fast, as deep learning, an programmable chip is the right choice.

The iPhone doesn't yet use M1. Besides, post-processing a video is one thing, encoding is completely different. What Apple does with the neural processing is most likely the analysis of the content, not the "editing".

In something like a mobile device, every watt counts. If it takes more energy to decode video on the tensor cores than it does to have a dedicated hardware block, you keep the hardware video decoder.

AFAICT AV1 is just a significantly more complex byte stream to create vs h264, especially if you want that byte stream to be meaningfully more compact than h265 created with x265 @ slow. x265 @ slow was already pretty time consuming[1][2]. And x265 itself had a hard time against x264 for years too[3]. So it may not be that the AV1 initiative is neglecting the public encoders and more that the math and algorithms for computing an AV1 byte stream really are that difficult.

[1] https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/ (this is x265 medium, but it has a nice gui)

[2] I ran a test 1080P encodes using x264 and x265 slow both CRF 20 via handbrake on my m1 MacBook Air and got ~20FPS, and ~4.4FPS for x264 and x265 slow respectively. On my i7-1165G7 NUC I ran the same test but directly invoked FFmpeg and got ~16FPS and ~4FPS for x264 and x265 slow respectively.

[3] This is just a short debate on reddit as an example https://www.reddit.com/r/DataHoarder/comments/lx41cx/x264_vs...

No, OS support for H.264 happened because the industry wanted more efficient codecs, and it didn't have much competition at the time. H.265 and AV1 are both competing to replace H.264 and so far neither have a clear lead.

There is an open source AV1 encoder implementation available: https://github.com/AOMediaCodec/SVT-AV1

Yeah, in this era of mobile device dominance i think hardware decoding is key. Suspect Apple will add it then suddenly the Android SoC folks will suddenly consider it a priority and not before.

Apple won't add it; they traditionally ignore free codecs, and even if they implement them, it is so limited, so it is usable only in the narrow situation, where it is required (see Opus, for example).

On the PC side, decoding is supported by Intel (since Tiger Lake), Nvidia (since 30x0) and AMD (since RDNA2). On the mobile side, it is supported by bunch of mobile chip vendors, like Mediatek or Samsung; so you can have an android device that does support AV1 already; on OS-side it is supported since Android 10. Vendors like Amlogic also support it, so settopboxes are also covered.

Apple is even a governing member of the alliance behind AV1 (https://en.wikipedia.org/wiki/Alliance_for_Open_Media), so the case could be different than with previous free codecs.

Apple didn't care about free codecs before H.265 for the same reason ISO and Leonardo Chiariglione didn't: "the best codecs require big $$$ to research and competitive royalty-free codecs will stifle innovation by not sending money back to researchers"[0]. The ISO business model was to not care about patents as long as everyone agreed to charge FRAND rates, so they could just pick the best technology and rely on their creators' patent royalties to fund research. For Apple, they don't care about the cost, as long as the codec is suitable to implement in iPhones.

That business model broke once Velos Media and Access Advance realized they could game the system by offering a handful of net-implementer companies severely reduced patent rates if they agreed to license their patents or, better yet, pull out of MPEG-LA entirely. The end result is that companies have to license significant portions of H.265 multiple times from three different patent pools... and most people who are even remotely cost-sensitive just aren't bothering with it at all and are sticking with H.264 or moving to AV1.

Apple has yet to implement AV1 in hardware, which makes using the codec exclusively a non-starter as they have a very dim opinion of software decoders. I imagine they joined AOM to either hedge some bets or extract leverage from H.265/H.266 patent owners. The thing is that their business absolutely does not require the existence of a viable royalty-free codec, unlike Google's, which does. We'll know if Apple's actually decided to join the Free video party if they actually ship an AV1 decoder in their silicon.

[0] Leonardo is very vocally opposed to AOM's lack-of-a-business-model, see:

https://blog.chiariglione.org/a-crisis-the-causes-and-a-solu...

https://blog.chiariglione.org/a-future-without-mpeg/

https://blog.chiariglione.org/revisiting-the-patents-in-stan...

If you're wondering, he's the former chair of MPEG, before ISO decided to cut up MPEG into a bunch of different pieces and more or less left him without a job. He's salty about that too: https://blog.chiariglione.org/iso/

A14 supports AV1 decode. Qualcomm is criminal in this case.

No raspberry pi support?

Qualcomm (a major holder of mpeg patents) recently announced AV1 support in their future chips.

They were the last holdout among Android vendors.

The Broadcasting industry has definitely sided with VVC. So 8K broadcast will likely be using VVC along with possibly LCEVC [1] as announced by the Brazilian SBTVD standard.

The AV1 question is harder to answer. One could argue VP9 is good enough and a few more years before it reach 100% VP9 hardware decoding on Smartphone. Of course Google could force the usage of AV1 in the future if they slowly phaseout VP9 video and only support AV1 on Youtube, while using H.264 as baseline. Qualcomm should have AV1 decoding on Snapdragon by late 2022 / 2023. Mediatek are starting to roll AV1 decoding as well. No timeline on encoding and generally speaking I dont expect any mobile hardware vendor to use AV1 encoding in the near future.

Even to this day I still do not believe Apple will support AV1 decode, at least not until Google forced the AV1 usage. That is a very contrarian view not just on HN but generally on the internet. But recent news with MPEGLA and AccessAdvance might have change things bit.

[1] vhttps://en.wikipedia.org/wiki/LCEVC

> Even to this day I still do not believe Apple will support AV1 decode, at least not until Google forced the AV1 usage.

Even though they joined AOM four years ago:

* https://venturebeat.com/2018/01/04/3-reasons-apple-just-join...

* https://appleinsider.com/articles/18/01/04/apple-joins-allia...

* https://bitmovin.com/apple-joins-av1-codec-consortium/

* https://www.streamingmedia.com/Articles/ReadArticle.aspx?Art...

They were somehow a founding member of AOM 12 months after the announcement because someone "add" their "name" on the list and only found out by a CNET journalist. And four years later AOM still dont have permission to use the official Apple logo on that page. Compared to previous HEVC and VVC showing where Apple logo were officially presented.

Doesn't inspire a lot of confidence to say the least.

The only recent changes were Apple's name somehow disappeared in both AccessAdvance and MPEGLA list.

Apple is also on the Blu-ray board of directors but AFAIK have never supported either playback or mastering of Blu-ray in any of it's products.

Isn't their non-support more a consequence of the fact that they haven't shipped a single product with an optical drive since 2012? Like, you can obviously plug a $100 external Blu-Ray writer into any of their computers, but I think between the competition with their own digital distribution platform and the "bag of hurt" that is DRM nonsense, I can understand them not being interested in explicitly supporting it but still caring about the direction that it takes since they are a media and devices company, and the decisions made there impact them.

> but still caring about the direction that it takes since they are a media and devices company, and the decisions made there impact them.

Agreed, but with a sinister connotation.

While I am absolutely not accusing Apple of it, let's not forget that all companies want the inside track on any tech that could threaten profits, and may join these organizations to guide them away from decisions that are not in the companies' interests.

Presumably those conflicts of interest would be well understood by everyone at the table, and the other companies with a heavier stake on the devices side (Panasonic, Pioneer, Sony, etc) would hold Apple accountable for any obvious attempts to sabotage the standard.

Look at Microsoft's membership in Khronos and Google's membership in W3C for examples of this counterbalance not exactly working.

They're also a member of Khronos which oversees things like OpenGL and Vulkan, but they deprecated the former and never implemented the latter.