Hacker News Reader

Comment by KronisLV | Hacker News Reader

> AV1 fixed a structural problem in the ecosystem at the time, but the work isn’t finished. Video demand keeps rising, and the next generation of open codecs must remain competitive.

> AOMedia is working on the upcoming release of AV2. It will feature meaningfully better compression than AV1, much higher efficiency for screen/graphical content, alpha channel support, and more.

That's all nice and good, but please make AV1 as widespread as H264, so that I can just import it in every editing program as well instead of having Adobe Premiere Pro complain about not knowing what that format is (well, I personally prefer DaVinci Resolve, but my editor is on Adobe). But yeah, I think that AV1 is great but would like support for it across the board, on every device (hardware decoding and encoding) as well as Kdenlive and Resolve and all the other editors and everything on the software side.

View on HN

Some Sony TV's only hardware accelerate AV1 content through streaming services, and not through Blueray and USB...

Right now, I have a drive filled with H264 content that I can hook up to any old hotel TV and play back. It's gonna be a while before I switch to AV1. And is H264 by now largely out of patent anyway?

> And is H264 by now largely out of patent anyway?

Almost for the AVC High profile - WikiMedia track all the known patents here: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...

It's all about hardware support really. AV1 is pretty new (2018), give it some time. E. g. Nvidia supports decoding since 3xxx generation, and encoding only since 4xxx generation.

I still vividly remember what a clusterfk was H264 support on mobile devices just ten years ago, circa 2010-2015. AVC spec was published in 2003, High Profiles standardised in 2005, universally supported only since ~2015. I personally had a 2011 Tegra 2 tablet which did support H264, but didn't support high profiles.

Why does Adobe need HW support?

Rendering out at high quality takes quite a bit of processing, so it helps to have GPU / HW Enc support.

Are you aware that you are barking up the wrong tree? AOMedia already made AV1 a free and open standard, if Adobe does not want to do an engineer's afternoon worth of work to link a C library into their executable, then that's on their head, not AOMedia's.

Less of a plea with AOMedia (it's not like they can't work on AV2 when AV1 is out there but doesn't have full adoption), and more at the industry as a whole - otherwise we'll still see H264 be widespread by 2030 and onwards because there's not enough interest in modern codecs even when they don't have licensing bullshit going on.

It's only royalty free from AOM, it doesn't mean it isn't patent encumbered. I know several companies that are claiming AV1 violates their patents and they want money if you use it.

tbf AOMedia doesnt really make this call. The steam deck for example doesn't do AV1 natively. It could, but Valve has so far decided not to implement it. I dont know how many other devices and systems that could do AV1 but don't do it exist, but to get this level of support, we really need to pressure these companies.

AdobeWebM is adding AV1 support for webm files in premiere and after effects btw. It already has vp9 and 8 support! But yeah I'm hoping it becomes ubiquitous in the future.

What is AdobeWebM and why is it taking more than adding the lib to their CMake?

AdobeWebM is a plug-in to support webm for after effects and premiere and media encoder and etc. And yeah adding AV1 support is almost as simple as adding a lib to cmake but once you start looking into hardware acceleration things get trickier quickly. For the most part the core plug-in is easy enough, parse the matroska/mkv/webm file, read keyframes positions etc, seek and decode frame packets from the stream.

You shouldn't be editing in long-GOP codecs anyway.

Shouldn't will only ever be enforced when it can't be. There's a lot of editing that doesn't require a lot of reverse playback which is where long-GOP really falls down to the point it is worth the slight pain in session vs length of delaying session starting for I-frame transcoding

The real killer of NLEs[0] is variable framerate. Long GOPs just give you higher playhead latencies, but it's still possible[1] for the NLE to actually edit video in such a state. Your computer has to be fast enough or it'll be miserable, but in contrast, variable framerate footage will immediately cause audio desync.

Of course, this distinction is moot, since I've yet to see a (consumer) video source that provides fixed framerate footage. If anyone wants to explain why, I'm all ears. As a result, I habitually re-encode everything before taking it into a video editor as a precaution, and once you're doing that then capping the GOP length is a no-brainer.

[0] Non-linear editor. If you're wondering what a linear editor is, please watch https://www.youtube.com/watch?v=AEMdmnNbCZA

[1] It's actually possible to do lossless editing at GOP boundaries, though I don't know if any NLEs would try doing this.

For linear editing, it could also be this:

https://www.youtube.com/watch?v=_cnQv8JCsX4

It's how I got started, indeed by watching this programme when it was on telly.

Reply on news.ycombinator.com