Hacker News Reader

Comment by mihaic | Hacker News Reader

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.

View on HN

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.

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.

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".

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

Reply on news.ycombinator.com