Alliance for Open Media codecs

[dapperdan]

I believe that is the niche that rav1e is aiming for.

And if Apple adopts AV1 and it becomes ubiquitous then then I think it'll have been a good move for the focus to have shifted from VP9, even if it means VP9 becomes a bit of a lost generation.

There's been some suggestion that SVT-AV1 has already passed libvpx for the "encode a single video on a single machine" case, while still having room to improve further.

[Mr_Khyron]

https://www.singhkays.com/blog/av1-e...date-may-2019/

Table of Contents

• SVT-AV1 is making strides!
• Android Q gets AV1 support
• Firefox 67 release makes AV1 decoding default on all desktop platforms
• Visionular Aurora AV1 codec claims it’s faster and better than x265
• BBC compares AV1 & VVC
• Amphion Semiconductor Hardware decoder

[Mystery Keeper]

Originally Posted by birdie

When I was writing that comment I was thinking about VP9. Aside from YouTube/Netflix you'd consider this codec a failure. The scene doesn't use it. Doom9 users don't really use it. It's become a great codec for content delivery. It's not really used anywhere else.

It's kinda strange we have projects like x264/x265 for patent encumbered H.264/H.265 codecs, yet nothing like that for VP9/AV1.

Are you kidding? I'm using VP9 and loving it!

[benwaggoner]

Originally Posted by sneaker_ger

If only Youtube had like .. multiple .. videos coming in daily. Then they could encode them simultaneously on a single CPU each. (And serve AVC or fast setting VP9/AV1 until they are done.)
You could do a fast first pass for scenechange detection and vbv estimation and send the chunks along with that info.

Yeah, something like that would work. It's more overhead, of course, and reduces total throughput. But that's what I'd do if I was trying to get good quality out of what are essentially spot instances.

Originally Posted by nevcairiel

This is not something any streaming service does though, so why should they invest into developing stuff for a goal they don't even need?
Its just how it goes. And for UHD Blu-ray discs, they can just throw massive bitrates at it to solve any such issues.

Streaming services for premium content do target really high quality, and most of the time at the top bitrate you won't see visible artifacts.

It's the user-generated content world where you see a visible quality ceiling. The sources aren't as good, and the economics for how many MIPS/pixel and how many Mbps to spend yield more conservative choice.

Also there is a big political motivation to use of non-MPEG codecs by some of the biggest UGC platforms, even when it doesn't make strict economic sense.

Originally Posted by vidschlub

AV1 /at scale/ when a video is being watched upwards of 500 times a week, makes so much more sense. Those encode times will eventually pay for themselves.

That's the hope of AV1. At this point H.264 has very mature encoders, so quality @ bitrate @ speed of AV1 and VP9 really don't offer any substantial improvements, and there are quality regressions versus x264 for some content types.

Originally Posted by birdie

When I was writing that comment I was thinking about VP9. Aside from YouTube/Netflix you'd consider this codec a failure. The scene doesn't use it. Doom9 users don't really use it. It's become a great codec for content delivery. It's not really used anywhere else.

It's kinda strange we have projects like x264/x265 for patent encumbered H.264/H.265 codecs, yet nothing like that for VP9/AV1.

Yeah, it's a chicken-and-egg thing. Because the market assumes that MPEG codecs are going to be widely used, a lot of people start building commercial codecs while the spec is still being finalized.

Also, the MPEG reference encoders just aren't useful for production due to speed and features. The vp* and AV1 series get a sort of hybrid reference/production encoder. It's "good enough" so people haven't bothered with ground-up new encoders. And specs haven't been close to MPEG quality before AV1.

And we can't discount the unique impact of x264. Legions of video pirates competing on making the best looking files as small as possible as quickly as possible to post to torrent sites meant lots of eyeballs on a very wide range of source content; much more diverse than typical encoder test content libraries. Dozens of people deep diving on tunings instead of a handful. Lots of eyeballs on every new beta to see what's different.

x264 just got good in ways that might be impossible to ever replicate. HEVC is close enough to H.264 that things like CRF and psychovisual tuning worked well enough to refine from. And x264 set a high bar that commercial encoder vendors had to strive to beat.

VP9 never had that kind of interest. AV1 is certainly showing much more competition in commercial encoders already than any vp* codec ever did.

[soresu]

Originally Posted by birdie

It's kinda strange we have projects like x264/x265 for patent encumbered H.264/H.265 codecs, yet nothing like that for VP9/AV1.

rav1e is basically the x264 of AV1 in terms of a community or free software driven project, time will tell if it gets even remotely as much traction as x264 did early on.
Its also as much of a successor to the Theora project, which also had On2 lineage stemming from VP3 being open sourced. For such a limited base codec, they managed to get a lot out of Theora (Ptalabvorm) before VP8 made it redundant for web video.

x265 on the other hand was never truly a successor to x264 in terms of community from what I've seen - it was driven by MultiCoreWare from the get go, and controlled by them rather than community (don't quote me there).

I'd also say rav1e is also kind of a test to see if a production codec can be viable if written in Rust, I think its the first?

[soresu]

Originally Posted by benwaggoner

VP9 never had that kind of interest. AV1 is certainly showing much more competition in commercial encoders already than any vp* codec ever did.

I think the open development process has alot to do with that interest and competition, it helps to get the whole thing going during the standardisation part, and not after.
The fact that it doesn't belong to one singular company helps too I think (like AC3/AC4/DTS). For all the reach of Youtube, noone wants to suffer with their bottom line because Google decided to make a change in codecs.

I think even H264 and H265 would not have prevailed so well without a similar development process - albeit one more encumbered with patent jockeying and so forth.

[`Orum]

Originally Posted by soresu

I'd also say rav1e is also kind of a test to see if a production codec can be viable if written in Rust, I think its the first?

Large parts of it are in assembly, and I can only see that trend continuing as they improve compression efficiency while trying to avoid sacrificing encoding speed.

While I'd love to see this become the "next x264," I'm not going to hold my breath. Far too many of the best encoders now are not free and especially not open source.

[birdie]

Weird results from BBC: https://www.bbc.co.uk/rd/blog/2019-0...ssing-hevc-vvc: no source videos, no codecs version, nothing.

[soresu]

Originally Posted by birdie

Weird results from BBC: https://www.bbc.co.uk/rd/blog/2019-0...ssing-hevc-vvc: no source videos, no codecs version, nothing.

It's not weird, they have a stake in VVC - so unfortunately they seem to be pushing a FUD angle against the nascent, standardised AV1 in an attempt to make VVC look better.

I'd hoped for better from the BBC considering the quality of their iPlayer platform. As it is, from these barely veiled attacks I'm in doubt that they will use AV1 at all.

Has anyone tried using SVT-AV1 on AMD hardware yet, especially Threadripper 16-32 cores? I'm curious to see how far Intel specific optimisations gimp AMD performance.

[`Orum]

Originally Posted by soresu

Has anyone tried using SVT-AV1 on AMD hardware yet, especially Threadripper 16-32 cores? I'm curious to see how far Intel specific optimisations gimp AMD performance.

I don't have a threadripper but I can test on a R7 1700 when I get home, if that interests you.

As for the "Intel specific" optimizations, that could help or hurt on AMD, but at the very least they seem to use Visual Studio instead of icl (which is really more "AMD specific degradation" than "Intel specific optimization").

Edit: Does anyone have a binary available? It seems to require VS 2017 or 2019, and I won't install those while I have 2015 installed. Alternatively I can use their release, but it's several weeks old and a very active project.

[HolyWu]

Originally Posted by `Orum

Edit: Does anyone have a binary available? It seems to require VS 2017 or 2019, and I won't install those while I have 2015 installed. Alternatively I can use their release, but it's several weeks old and a very active project.

https://ci.appveyor.com/project/Open...1186/artifacts

[`Orum]

Alright, here are some numbers on my R7 1700. Source was a 1080p BD I had handy. Options were: -q 30 -n 1000 -i stdin -w 1920 -h 1080 -enc-mode 4

Total Frames            Frame Rate              Byte Count              Bitrate
        1000            30.00 fps                  5734937              1376.38 kbps

Channel 1
Average Speed:          1.853 fps
Total Encoding Time:    539574 ms
Total Execution Time:   541517 ms
Average Latency:        47668 ms
Max Latency:            64363 ms
Encoder finished

[iwod]

Originally Posted by soresu

It's not weird, they have a stake in VVC - so unfortunately they seem to be pushing a FUD angle against the nascent, standardised AV1 in an attempt to make VVC look better.

I'd hoped for better from the BBC considering the quality of their iPlayer platform. As it is, from these barely veiled attacks I'm in doubt that they will use AV1 at all.

Has anyone tried using SVT-AV1 on AMD hardware yet, especially Threadripper 16-32 cores? I'm curious to see how far Intel specific optimisations gimp AMD performance.

And they are also part of the Open Media Alliance. So we now consider anything that is better than AV1 as FUD?

[dapperdan]

https://medium.com/vimeo-engineering...o-a2115973314b

Vimeo adopting AV1, specifically the rav1e encoder with an explicit wish to make it the new x264.

[unpause]

Originally Posted by `Orum

Alright, here are some numbers on my R7 1700. Source was a 1080p BD I had handy. Options were: -q 30 -n 1000 -i stdin -w 1920 -h 1080 -enc-mode 4

Using the same options I got the following results on an R7 2700X. Ubuntu 19.04, release mode built from HEAD (5fd69642f40655d2ec7ac6ffb8cb2c678650e1e7):

SUMMARY --------------------------------- Channel 1  --------------------------------
Total Frames		Frame Rate		Byte Count		Bitrate
        1000		30.00 fps		  13116427		3147.94 kbps


Channel 1
Average Speed:		2.653 fps
Total Encoding Time:	376893 ms
Total Execution Time:	378036 ms
Average Latency:	33390 ms
Max Latency:		47422 ms
Encoder finished

[soresu]

Originally Posted by iwod

And they are also part of the Open Media Alliance. So we now consider anything that is better than AV1 as FUD?

I actually live in the UK, have friends that have worked for the BBC, and I personally consider their motives to be suspect here - joining the AOM is by no means any guarantee that they did so with good intentions at that point, or at any point since, any more than nVidia's presence in the Khronos standards body guarantees their good intentions towards future efforts with OpenCL.

I'm not saying that AV1/libaom are without their failings, but the graphs in the blog articles seem to show worst case scenario numbers for AV1 from what I've seen from other sources in the past (including here), while showing only improvement for VVC - the only positive thing they can write is that AV1/libaom has gotten much faster since their last test.

The best I can say is that they are being somewhat disingenuous towards AOM's efforts thus far, though their potential patent stake in VVC causes me to lean towards a more nefarious angle on the matter.

I would add that I don't in any way believe that VVC or MPEG codecs are intrinsically bad, in fact as an avid follower of ML/AI tech in media I am quite interested to see how it performs once implemented.
It is the vortex of financial incentives that churn around MPEG efforts that has me reaching for my FUD colored glasses.

[mandarinka]

And you think the companies like Google with vested interest in VP9/AV1 have no incentive to astroturf or paint their product in better light and competing in worse than is fair?

Actually, it might be open source enthusiasts and evangelists that volunteer/vigilante/follow these things as a hobby and not as a job/living that are the worst offenders with FUD ("Fear, uncertainty and doubt") or untrue claims, because companies are actually somewhat afraid of being held accountable.
These folks probably often don't even get they do something dishonest or if they do, they think it's fine because "we are the good guys" (no, principles should hold for everybody.). Even if we put apart more controversial fields for sake of not starting offotpic flame... good example is for example the twitter/phoronix forums marketing of the Raptor Engineering (Power9 vendor) that routinely uses strongly dishonest FUD against x86 to sell their stuff to paranoid people as a company that does it, libreboot as non-profit people that do it and then the general fandom of this free hardware(firmware) movements as general internet people that then perpetuate it further. You could probably find a lot of that blinded hypocrisy here too.

[MoSal]

No need for multi-paragraph comments arguing who is FUDing who (old-style FUDing is a tired tactic anyway).

BBC R&D (not necessarily representative of everyone in the organization) provided zero info that would allow anyone to replicate their results, let alone analyzing and arguing their usefulness. Period.

[soresu]

Originally Posted by mandarinka

And you think the companies like Google with vested interest in VP9/AV1 have no incentive to astroturf or paint their product in better light and competing in worse than is fair?

I think that's a false equivalency, AV1 and VP9 are a means to an end for Google, Netflix, Cisco etc - the end being pushing more video for a given bandwidth without being encumbered by uncertainty fostered by divergent patent pools, as happened with HEVC (and I absolutely believe it will happen again with VVC given time).

The end may not be 'just' patent royalties for all MPEG members, but it will certainly be a top consideration for most of them.

The difference is actually in the product wording you mentioned:
For Google and the other AOM content creators, the product is the content and increased access created by the codecs existence.
For MPEG members, the product is the codec itself.

Obviously that oversimplifies the matter somewhat, but I think that represents the main gist of it.

[bstrobl]

First SoC launched by Realtek: https://www.realtek.com/en/press-roo...-cas-functions