Versatile Video Coding (VVC) / H.266: HEVC successor [Archive] - Page 7

FranceBB

23rd July 2020, 21:46

It could be a characteristic of a genius.

Dark Shikari was a genius indeed, whether that particular thing is the characteristic of geniuses, I don't know...
Perhaps... I just hope he/she is happy with his/her choice...

I think rule 15 applies here.

Yeah, sorry for derailing the topic, I didn't mean to.
Now, back on topic and back to VVC:

Based on the three slides I posted What I am seeing is AV1 using higher bitrate to achieve slightly better results. In terms of similar bitrate overall VVC is still ~10 to 20% better.

It is, the higher score is limited to the high bitrates, however they're not so unthinkable if you consider real world scenarios, which leads me to the question: why? Was it because of some fine details that were averaged/blurred out in VVC and were not in AV1? Was it because of grain retention? I mean, a screenshot of scores doesn't tell us much...
Anyway, the last time I encoded a test sample with the reference encoder was in December 2018, perhaps it's time for me to encode something again and compare it with other codecs this time. I'll try to put something together next week... maybe... unless I'm too overwhelmed with other things that my colleagues keep assigning me...

Blue_MiSfit

23rd July 2020, 22:16

ksec

24th July 2020, 02:23

Thank you for quickly getting back on topic. My takeaway is that no ill will was intended, and that we all have the utmost respect for D_S and wish her the best :)

Let's all please be respectful to each other. Thank you.

Thanks for the correction, my apology if I have offended anyone. Utmost Respect to DS and from the bottom of my heart I wish her all the best.

It is, the higher score is limited to the high bitrates,

Well I wouldn't call 1.5Mbps high bitrate. :D Let wait until VVC settle down and get a production encoder to play around before we make a judgement. Reference Encoder are really only good for compliance.

I am also noticing quite a bit of activity over at MC-IF. So lets hope we have more news soon.

Edit: Pool Administrator Selected by 2020 or Early 2021 before they talk about licensing terms. :/

Mosu

1st August 2020, 22:01

foxyshadis

2nd August 2020, 14:47

I read that the VVC/h.266 standard was finalized in July. Great. But is it actually available for purchase yet? I wasn't able to find it, neither on the ISO website, nor on the IEC or ITU-T websites. But I find each of those somewhat confusing to navigate; it's perfectly possible that I simply missed them.

If the standard's not available for purchase yet, any idea when it will be (roughly)?

You can buy the draft at ISO/IEC DIS 23090-3 (https://www.iso.org/standard/73022.html). It's not yet granted full ISO approval status, so it's not shown in browsing. Note that buying the draft doesn't entitle you to the final standard, which is incredibly annoying.

Edit: For more fun, the JVET site (https://jvet.hhi.fraunhofer.de/) has been taken down, too.

Mosu

2nd August 2020, 15:05

Thanks. I think I'll wait for the final, then.

olduser217

7th August 2020, 09:17

The latest draft (not final) can be found at http://phenix.it-sudparis.eu/jvet/
Choose the June 2020 meeting, document S2001.

amayra

11th August 2020, 22:50

i refuse to touch anything not Royalty-free when it come to codec

birdie

13th August 2020, 16:29

i refuse to touch anything not Royalty-free when it come to codec

It's not clear why you feel entitled to share your opinion in this topic. If you refuse to touch anything not totally opensource/free, then what are you doing in this topic?

benwaggoner

13th August 2020, 20:18

@ksec... very interesting results. H.266 did way better than x264 and x265 at both low and high bitrates. It was also better than VP9 as we expected, but it couldn't quite get a grip on AV1 at high bitrates. I wonder whether it's because AV1 encoders have been available for quite some time now and are more mature than the H.266 reference encoder or if it's due to the codec standard/implementation itself...
I guess some other tests will have to be done to evaluate this, but judging from the first data, we're definitely heading in the right direction. Let's wait an see.
It's really hard to say without seeing the specifics of the test parameters. As a reference encoder, the VVC VTM won't have much psychovisual tuning while libaom has gotten quite a lot. Also libaom has gotten a lot of VMAF tuning, so we should expect its VMAF scores to somewhat outperform its actual subjective quality. Also, VMAF isn't a sensitive instrument comparing at high quality and bitrates. Only MOS testing has been usefully informative at looking at efficiency of near-transparent quality.

Speed doesn't mean much either, as libaom has gotten lots of performance tuning. The libvpx/libaom codecs are sort of weird combinations of reference encoders and production encoders.

Have reference encoders ever been integrated into ffmpeg? I mean, I might be wrong, but I don't really remember any of them...
I guess we're gonna have to wait for x266 work to begin before we'll see anything in ffmpeg...
Yeah, reference decoders are typically too slow for practical use, and carry a ton of complexity as they support ALL the features of the bitstream, not those in targeting Profiles and Levels. Practical decoders start by focusing on a practical subset of features, optimizing those, and then adding optimization of more features once the basics get done. For example, AV1 decoders got fast at 8-bit decode before they spent much time on 10-bit.

benwaggoner

13th August 2020, 20:29

Thanks for the reply. I actually aware of the she part. It's just that the last time i heard of him working on anything was when DS was still a he thus the reason for using he instead of she. Anyway, i wish her well.
She was definitely active in consulting and licensing during and after her transition. She remained quite active in development well after her participation in public discussions had tapered off.

As a side point, best practice is to refer to someone as having been their current gender retroactively, as someone's internal identity is very often established well before their public identity conforms to that.

Other than this new VVC, I also hope the developer can squeeze some more juice out of the current x265. Do you think there are still much potential in x265, especially with regard to efficiency improvement?
Compression efficiency? Sure, there's plenty of room to keep optimizing. Even MPEG-2 has seen material improvements over the last few years, and HEVC has SO many.

Beamr has demonstrated some very promising improvements over x265. I bet the ABR required for a given MOS in HEVC can drop another 40-50% over the next decade, given how many tools there are an how much flexibility there is to apply them. Moore's Law gives us more MIPs/pixel every year. The whole field of applying AI/ML to improving encoding is still new, and promises some really big improvements. There are whole approaches to interframe tuning that are only just being poked at today.

I'd expect we're ~2 years out from the best VVC production encoders being materially better than the best HEVC encoders in quality @ bitrate @ perf.

hajj_3

14th August 2020, 16:01

VTM v10.0 is out, large changelog: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/releases/VTM-10.0

amayra

23rd August 2020, 18:38

It's not clear why you feel entitled to share your opinion in this topic. If you refuse to touch anything not totally opensource/free, then what are you doing in this topic?

why you feel entitled to comment about my opinion in this topic ?

Audionut

24th August 2020, 03:16

Well, generally the discussion should be relevant and move the topic forward.

Irrelevant personal opinions, while valid, add nothing of value to the community. And that is what doom9 is, a community, not your personal opinion space.

LigH

25th August 2020, 15:05

New upload: VTM Encoder Version 10.0 [Windows][GCC 10.2.0][64 bit] (http://www.mediafire.com/file/f31a8ee4107g8c3/VVCSoftware_VTM-10.0_16bc143c.7z/file) 16bc143c

soresu

2nd September 2020, 02:14

For me the big surprise is the AV1 MPEG-4.

I have to agree with this - it's very odd that all Yotube AV1 videos are encapsulated in MP4 rather than webm/mkv.

Blue_MiSfit

2nd September 2020, 02:51

I'm sure YouTube is doing this for a good reason. I wouldn't be surprised if this is because the tooling surrounding fragmented MP4 is vastly more widespread than the tooling surrounding MKV, especially on the client side. While it's possible to deliver content using MPEG DASH and WebM segments, this isn't something most players support, so almost nobody does it. I'm only aware of YouTube ever having done this.

fMP4 is widely used in both DASH and HLS now, and is getting more and more widespread device support. Also factor in that when encrypting content it's desirable to have fMP4 with AES-CBCS encryption so you can take advantage of Widevine, PlayReady, and FairPlay all from a single set of files (delivered via DASH or HLS as clients prefer).

All of that is possible with fMP4, in a way that's broadly compatible. I don't think the same can be said for WebM.

MP4 is a good container format, and it's the way forward for all scalable video delivery to customers (except for ultra low latency cases where RTP / WebRTC are still better suited). We have all the new contribution protocols like SRT and RIST, and all the new "SDI replacement" protocols like NDI to handle the professional content production cases for live too :)

benwaggoner

2nd September 2020, 17:32

I have to agree with this - it's very odd that all Yotube AV1 videos are encapsulated in MP4 rather than webm/mkv.
Why WOULD it be in MKV? It's not like MKV is better engineered or something, or handles scenarios that MPEG-4 can't.

I think the practical difference is the .mkv extension only gets opened by players who can handle the rich elements, so a too-simple player doesn't even try. Which is a valid reason to use it when trying to package up a whole media experience into a single file for download.

In the adaptive streaming world, things like subtitles and alternate languages are handled with URLs to specific files in the manifest, so only the needed assets for a given session need to get downloaded.

Jamaika

3rd September 2020, 17:59

I don't know how it is in the US, but in the EU popularization and lack improvement MP4 codec is justified by company patents and legal acts RODO or ACTA2. New codec AV1 in mp4 - ok, but codec description is limited and archaic. Is the description recommended for processed video? Not recommended.
Card payments were reluctantly introduced in logistics in the era of KV. And it turned out that nobody don't want to pay in the KV era. GPS in the movie, money and crazy vacations. It's tax proof on the tray. What youtube or facebook?
The MKV container is considered by many companies as a pirate that has ruined DVD / Bluray. Great that it has extra subtitles, other functions. Unfortunately, it is for amateur programs.
What will the MP5 be like? I have no illusions as a layman. The MP5 will be an even more encrypted container for fast tracking by security systems.
Will MKV contain MPEG5 container under VVC ??? How should I know, but it probably won't be free.

birdie

8th September 2020, 14:55

News: x266 is already in development (https://multicorewareinc.com/x266-a-state-of-the-art-open-source-code-for-vvc-encoding-by-multicoreware-inc/):

MulticoreWare announces the formation of x266 consortium and development of an open source code for VVC encoding is already underway. Similarly, MulticoreWare’s x265 consortium led the development of the open source code x265 for HEVC based encoding and become the mmost widely used HEVC encoding software.

Application areas of x266 will include encoding High Definition(HD) and Ultra High Definition(UHD- 4K and 8K) video for broadcasting, live streaming, Over The Top(OTT) video distribution, Adaptive Bit Rate(ABR) streaming, video storage and archiving, surveillance, screen content sharing, video teleconferencing, video games, eSports, immersive media such as 360-degree video, Virtual Reality (VR) etc.

x266 will be able to encode video with Standard, High Dynamic Range and Wide Color Gamut. It will also offer a user flexibility to trade-off speed of encoding with coding efficiency. Initial version of the x266 software will support single layer coding of 10 bits video with 4:2:0 chroma format. More advanced versions will support multilayer coding, higher than 10 bits depth video and higher than 4:2:0 chroma formats.

Greenhorn

12th September 2020, 23:34

Jamaika

13th September 2020, 05:31

non-reference (?) VVC implementation by Fraunhofer HHI:

https://github.com/fraunhoferhhi/vvenc

Seems to be in a very early state.

Offers a simple encoder with 4 presets and one tuning option, and multithreading, but no screen-content features, together with a complex encoder which seems to be a re-implementation of the VTM.
Thanks for the info. Does this library have any JVETVVC history? Threads added.

Edit:
Added encoder VVEncoderApp.exe:
VVEncoderApp.exe --preset medium -i 111.yuv -s 1280x720 -t 4 -b 3000 -o str.266
Strange. Encoder isn't compatibile with Elecard StreamEye 4.5.974.
Time consuming coding problem. The encoder and decoder have to be created separately.
I don't know can user create any GOP?
https://www.sendspace.com/file/tjn6vy

hajj_3

16th September 2020, 09:42

There is a test transmission on a european satellite for a VVC broadcast: https://www.digitalbitrate.com/dtv.php?mux=11973&pid=7249&live=69&sec=0&lang=en

Jamaika

21st September 2020, 05:36

I've been using GPAC MPEG4 very little lately. I noticed that 'initial tests for VVC support' has been added under OPENVVC.
I wonder. Will VVC be possible to import into MPEG4 container or become MPEG5 container?
https://github.com/gpac/gpac/commit/a85373de5769e347f1f572938b87924b47e2ba3e

FranceBB

21st September 2020, 06:34

There is a test transmission on a european satellite for a VVC broadcast: https://www.digitalbitrate.com/dtv.php?mux=11973&pid=7249&live=69&sec=0&lang=en

Yep.
Astra 2E (28.2 ° E) tp. 14 (11.973 GHz, pol. V, SR: 31000, FEC: 9/10; DVB-S2 / 8PSK)

It was an 8K H.266 VVC 20.55 Mbit/s before.
Together with the audio channels it seems to be 27 Mbit/s now, though.

Doesn't look bad: 8K VVC Screenshot (https://i.imgur.com/ziXGue4.jpg)

I mean, sure, if you take a look at low lights like in this part, there's a lot of noise in both luma and chroma:

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

And in other parts, everything looks blurry and averaged out, but still, we're talking about 20-27 Mbit/s for an 8K stream, so it's not really bad.

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

As a matter of fact, broadcasting 8K contents at around 25 Mbit/s in H.266 VVC just like we're doing for 4K contents in H.265 HEVC at the very same bitrate would be a huge achievement.
Besides, I would totally prefer a blurry approach compared to a blocky one; after all, blocking is immediately noticeable by human eyes, while blurring is kinda not.
It looks like H.266 VVC continued with the same approach H.265 HEVC had and improved from there:

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

(Remember that those last screenshots are parts of an 8K frame)

LigH

21st September 2020, 08:56

Right, other codecs might have to flatten out noise a lot more to achieve this bppf ratio. May look even less obvious in motion.

benwaggoner

21st September 2020, 19:14

Right, other codecs might have to flatten out noise a lot more to achieve this bppf ratio. May look even less obvious in motion.
And the psychovisual value of a pixel at 8K is very, very different than at 1080p. Different kinds of visual distortion will have different impacts at such different pixel density. For example, dithering-like artifacts are going to be essentially invisible at 8K, since small-moderate differences between individual pixels are effectively invisible.

xooyoozoo

4th October 2020, 22:51

non-reference (?) VVC implementation by Fraunhofer HHI:

https://github.com/fraunhoferhhi/vvenc

Seems to be in a very early state.

Offers a simple encoder with 4 presets and one tuning option, and multithreading, but no screen-content features, together with a complex encoder which seems to be a re-implementation of the VTM.

They have a whitepaper (https://www.hhi.fraunhofer.de/fileadmin/Departments/VCA/MC/VVC/VVEnc-v0.1-v1.pdf) with a few more details.

The most relevant performance graph:
https://i.imgur.com/W7BS2ZC.png

The higher quality modes are still a magnitude too slow, but it's nice to see a (more) performant encoder that matches reference quality.

If they add scene-change detection and rate-control, the project becomes an almost-useable enthusiast encoder. :)

benwaggoner

5th October 2020, 21:49

The higher quality modes are still a magnitude too slow, but it's nice to see a (more) performant encoder that matches reference quality.

If they add scene-change detection and rate-control, the project becomes an almost-useable enthusiast encoder. :)
Wow, that would be an incredible accomplishment this early in a codec's history.

A huge but rarely discussed advantage of the MPEG line of codecs is that each generation is heavily based on the previous one. So it's relatively straightforward to take an existing encoder and add some of the tools of the next one to get a compliant bitstream of reasonable quality. Not easy in absolute terms by any means, but relatively easy compared to building an encoder for a new codec without high-quality encoders to start with.

Back in the streaming wars, this was also a big reason why RealVideo and Windows Media codecs were able to come out with improvements so rapidly. Newer versions used the prior encoder as the basis, with new tools added. Being closed source and software only made compatibility a lot easier too, of course.

H.264 was the first time an open standards based approach demonstrated a huge advantage over proprietary codecs, a testament to the effectiveness of having many experts and stakeholders collaborating together.

hajj_3

21st October 2020, 23:33

VTM 10.2 is out: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/releases

LigH

17th November 2020, 09:27

New upload: VTM Encoder Version 10.2 [Windows][GCC 10.2.0][64 bit] (https://www.mediafire.com/file/wy07e2whnhoa577/VVCSoftware_VTM-10.2_ec4bb116.7z/file) ec4bb116

Rusyn

8th December 2020, 23:30

Hi, I am working on the latest version of VTM for VVC (10.2). I would like to know how many percent of a given frame is encoded using the affine transform. I assume that to figure it out, I need to know the total number of encoded macroblocks, and then how many of them were encoded using the affine transform, but I have no idea what lines of code in which encoder / decoder .cpp files I should add / modify. I would be grateful for any suggestions / tips. Thank you in advance

FranceBB

9th December 2020, 13:51

ffmpeg.exe -i "AVS Script.avs" -strict -1 -an -f yuv4mpegpipe -vf scale=848:480:in_color_matrix=bt709:in_range=limited:out_color_matrix=bt709:out_range=limited,format=yuv420p 111.yuv
| encoder.exe -i 111.yuv -b "raw_video.vvc" -wdt 848 -hgt 480 --Profile=auto --Level=5.1 --Tier=main --FramesToBeEncoded=150
--FrameRate=30000/1001 --InputBitDepth=8 --OutputBitDepth=8 --InternalBitDepth=8
--InputChromaFormat=420 --ProgressiveSource
--IntraPeriod=-1 --GOPSize=4 --TargetBitrate=25000
--CTUSize=32 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32
--MaxTTLumaISlice=32 --MaxTTChromaISlice=32
--MaxTTNonISlice=32 --Log2MaxTbSize=5
--ConformanceWindowMode=0 --SEIDecodedPictureHash=3
--BitstreamFile=vvc.bitsteam

pause

Output:

Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given

How can I set the reference picture sets? --ref doesn't clearly work and I can't find anything in the documentation

LigH

9th December 2020, 15:08

As this seems to be a question specific to x266, it might better be asked in the x266 VVC Encoder (https://forum.doom9.org/showthread.php?p=1922993) thread. This one is rather generic or related to the Fraunhofer HHI reference.

I just even learned that x266 is already available...

Or not? Do you refer to the work of chenm001 who is not related to Multicoreware? Ooh, horay for trademarks.

FranceBB

9th December 2020, 15:57

Ah, no, no, sorry (I made a mistake and pasted something I shouldn't have pasted), now I'm referring to the VTM reference encoder by Fraunhofer, the one Jamaika has been posting about all the time.
But yeah, there are a lot of weird naming conventions out there right now, it's a bit of a mess.
And... no, x266 by Multicoreware isn't publicly available yet.
Still, my issue is that I get

Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given

however I specified the correct GOP with a size of 4 and I set the --IntraPeriod to -1 which means automatic, so it should be ok.
I also took care of the CTU size and made sure that all the Slices were the same (so at least equal or less than it) and I set --Log2MaxTbSize to be less than 6, as suggested.
Still, it's complaining again. Why?
Besides, I think it should really allow default settings to go through rather than throwing errors all the time.
I mean, if someone doesn't specify anything, it throws an error 'cause it wants things to be specified.
If someone specifies them wrong, it doesn't clearly work, however there's very little documentation (at least, that's what I've found).
It's a bit of a pain to work with it, honestly...

mikahawkins1

9th December 2020, 16:33

It is pretty good when it comes to decoding.

quietvoid

9th December 2020, 16:33

I'm not sure a GOP with size 4 is gonna work, at least vvenc only allows 16 and 32.
The VTM example config files as well.

FranceBB

9th December 2020, 17:22

I'm not sure a GOP with size 4 is gonna work, at least vvenc only allows 16 and 32.
The VTM example config files as well.

I set it to 16 and 32. Same thing happens. I mean, I get the very same error message.

quietvoid

9th December 2020, 17:29

Okay, so it's back to having to specify the whole GOP structure. I can reproduce the same error when removing all the Frame lines.
In config files, it refers to this: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/blob/master/cfg/encoder_randomaccess_vtm.cfg#L20-51

I don't know if they can be specified by command line :)

Jamaika

9th December 2020, 22:25

Output:

Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given
You aren't using correct codec. This one is experimental and for setting only GOP = 16 or 32 in config.
You should use the vvenc and vvdec with multithread versions.
however I specified the correct GOP with a size of 4 and I set the --IntraPeriod to -1 which means automatic, so it should be ok.
I also took care of the CTU size and made sure that all the Slices were the same (so at least equal or less than it) and I set --Log2MaxTbSize to be less than 6, as suggested.
Still, it's complaining again. Why?
Besides, I think it should really allow default settings to go through rather than throwing errors all the time.
I mean, if someone doesn't specify anything, it throws an error 'cause it wants things to be specified.
If someone specifies them wrong, it doesn't clearly work, however there's very little documentation (at least, that's what I've found).
It's a bit of a pain to work with it, honestly....
These were the settings for screenshot at GOP = 1. Then you can skip config.

FranceBB

11th December 2020, 10:16

You aren't using correct codec. This one is experimental and for setting only GOP = 16 or 32 in config.
You should use the vvenc and vvdec with multithread versions.

These were the settings for screenshot at GOP = 1. Then you can skip config.

Where can I find the stable multithreaded one, then?

Jamaika

11th December 2020, 10:27

https://github.com/fraunhoferhhi/vvdec
https://github.com/fraunhoferhhi/vvenc
plus my fix
I have added codecs and compilation issues in my threads

FranceBB

11th December 2020, 22:52

https://github.com/fraunhoferhhi/vvdec
https://github.com/fraunhoferhhi/vvenc
plus my fix
I have added codecs and compilation issues in my threads

Thanks!
Last question: from what I see it's still uncompressed .yuv input file only, so I assume a -f yuv4mpegpipe - | from FFMpeg wouldn't work, right?

hajj_3

12th December 2020, 12:56

Does anyone know whether an open source optimised VVC software decoder is being made by anyone?

birdie

13th December 2020, 09:37

Does anyone know whether an open source optimised VVC software decoder is being made by anyone?

I'm quite sure many companies are already developing coders and decoders behind closed doors but in terms of open source support/solutions it's been dead quiet except for an encoder from Multicoreware which was announced several months ago.

Sharp meanwhile has announced a real time decoder for up to 8K VVC streams: https://global.sharp/corporate/news/201204-a.html I've tried to dig deeper but it looks like the corporation is averse to open source ;-)

birdie

13th December 2020, 10:37

Speaking of the reference encoder, vvcenc, it's already quite fast without tons of hand-written optimizations/assembly: https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/How-Does-VVC-Measure-Up-Right-Now-144235.aspx

Looks like when it gets properly optimized it'll be a lot faster than aomenc (though now the reference AV1 encoder is SVT-AV1 which I haven't yet accepted as its quality is quite poor IMO).

Marsu42

14th December 2020, 21:51

Looks like when it gets properly optimized it'll be a lot faster than aomenc

That shouldn't be a surprise, should it?

Afafik av1 ist a "simply try everything" encoder, because patented mpeg fast prediction tools aren't included.

So even if vvc has added complexity vs hevc vs avc, it should be still more tuned for fast encoding - while av1 is designed to avoid patents and tuned for either "quality doesn't matter" video calls or "cost doesn't matter' encoding by streaming providers.

foxyshadis

17th December 2020, 04:48

That shouldn't be a surprise, should it?

Afafik av1 ist a "simply try everything" encoder, because patented mpeg fast prediction tools aren't included.

So even if vvc has added complexity vs hevc vs avc, it should be still more tuned for fast encoding - while av1 is designed to avoid patents and tuned for either "quality doesn't matter" video calls or "cost doesn't matter' encoding by streaming providers.

I think it's more that AV1 followed a similar trajectory as the messy H.264/AVC spec process, with lots of freewheeling tools and an unmaintainable, unoptimizable codebase. JM was a joke for many years, but with a surprising amount of work it got much better despite not having a market; eventually the HM (H.265/HEVC) used its base to graft new tools on instead of starting from scratch, and H.266/VVC is doing the same with an even more mature and optimized base. What that also means is that you aren't going to see the kinds of staggering differences between JM and an x264 anymore.

AV1 threw out lots of baby with the bathwater in trying for a total do-over of codec development, instead of just building off of VP9, because it ended up so different. (Not the VP9 was any peach.) Other AV1 implementations have tons of freedom to do much better, which is both better and unfortunate. A future AV2 will have the benefit of whatever portion of aom's code and optimizations are reusable. It's not like AV1 finalized pie in the sky proposals, though; just like every MPEG process, there was a painful period of cutting them down to what met a size and performance budget, and that's a huge part of why the final spec was so delayed.

But also, AV1 didn't benefit from the large number of experienced chip designers who weigh in on all MPEG proposals regarding baking it into transistor budgets. C'est la vie.