Alliance for Open Media codecs

[TD-Linux]

What's the difference between deltaq and AQ in aomenc? Deltaq changes the quantizer of the frames, and AQ changes the quantizers of the blocks within the frames, or am i completely wrong?

Deltaq is at superblock granularity, whereas "AQ" uses segment support which is down to 4x4 granularity. The two bitstream features are sorta redundant but their coding is optimized for different uses - Deltaq was designed for sub-frame rate targeting, and segments are more for mbtree/psy purposes.

[Tommy Carrot]

Deltaq is at superblock granularity, whereas "AQ" uses segment support which is down to 4x4 granularity. The two bitstream features are sorta redundant but their coding is optimized for different uses - Deltaq was designed for sub-frame rate targeting, and segments are more for mbtree/psy purposes.
Thanks for the explanation.

[hajj_3]

vlc 3.0.7 is out, not sure how to check what version of dav1d it uses though.

[birdie]

vlc 3.0.7 is out, not sure how to check what version of dav1d it uses though.

It's been using dav1d since 3.0.5.

[hajj_3]

It's been using dav1d since 3.0.5.

yes, but i wanted to know what version of dav1d v3.0.7 is using.

[birdie]

yes, but i wanted to know what version of dav1d v3.0.7 is using.

0.3.1

[vidschlub]

At this time shouldn't we consider AV1 a failure and move on to newer codecs, e.g AV2?


It doesn't have fast enough decoders to decode on mobile at 1080p on most devices (>80%).
It still doesn't have encoders which are anywhere fast enough to be usable by mere mortals.
Its hardware adoption is not there - the spec was finalized almost half a year ago, and AV1 is nowhere to be seen in Zen 2.0 (Ryzen 3000), Radeon RDNA 5700 or Intel Ice Lake. No word on its decoding acceleration even in the recently announced Arm's Cortex-A77/Mali-G77.




I find your comment extremely surprising considering your join date of 2006. I would expect such a comment from a newbie.


Unless the entirety of the developer and encoding community are lying to me, what is occurring with AV1 is absolutely par the norm for new codecs.
265 is still a dog to encode without a reasonable monster of a PC. How will an even more compressed, newer codec, that's open (and therefore can't break terrible patents) begin to compete only 6 months in?

The only thing that AV1 has going for it, is it's openness and the hope that /so many players/ throwing themselves at the problem, will slowly address the performance issues.

None the less, it's been 6 months. You're not going to see this getting hardware acceleration for at least 6 more months on any devices.

I suspect it'll be ubiquitous at best case scenario of 3 years. (more experienced members, welcome to correct me)

[vidschlub]

Encoders are no longer being made for this crowd. The primary design goal is massive-scale cloud encoding for YouTube, Netflix, Amazon, and everyone else that fits the encode-once, download hundreds of thousands of times scenario.

In such a scenario, even the slowest encoder is acceptable if it saves enough bytes.

In that scenario, VP9 also didn't fail. It gets used for a lot of content on the web.

It never even began to occur to me that one day, my personal local library, would never be in AV1 format.

Yet here you are outlining exactly why it is very unlikely to and it kind of blows me away, you're totally correct.

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.

[sneaker_ger]

Probability of seeing AV1 decoding in Turing refresh?

[nevcairiel]

Probability of seeing AV1 decoding in Turing refresh?

None.

[NikosD]

nVidia and AMD (possibly Intel for Gen11 iGPUs) could add in drivers a hybrid decoding approach of AV1 using the GPU itself (shaders) but not ASIC yet.

[birdie]

I find your comment extremely surprising considering your join date of 2006. I would expect such a comment from a newbie.

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.

[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-ecosystem-update-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]

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]

If only Youtube had like .. multiple .. videos coming in daily. Then they could encode them simultaneously on a single CPU each. :devil: (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.

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.


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.

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]

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]

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]

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 (https://github.com/xiph/rav1e/tree/master/src/x86), 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-05-av1-codec-streaming-processing-hevc-vvc: no source videos, no codecs version, nothing.

[soresu]

Weird results from BBC: https://www.bbc.co.uk/rd/blog/2019-05-av1-codec-streaming-processing-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]

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.

[`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]

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-blog/behind-the-scenes-of-av1-at-vimeo-a2115973314b

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

[unpause]

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]

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]

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-room/news-releases/item/realtek-launches-worldwide-first-4k-uhd-set-top-box-soc-rtd1311-integrating-av1-video-decoder-and-multiple-cas-functions

[EwoutH]

Press release: https://www.realtek.com/en/press-room/news-releases/item/realtek-launches-worldwide-first-4k-uhd-set-top-box-soc-rtd1311-integrating-av1-video-decoder-and-multiple-cas-functions (Realtek Launches Worldwide First 4K UHD Set-top Box SoC (RTD1311), Integrating AV1 Video Decoder)

[soresu]

Faster than I expected for a hardware ASIC release, with HDMI 2.1 support no less - though HDMI 2.1 is obviously overkill for 4K60p video, the release doesn't say anything about higher than 4K support.

[hajj_3]

Press release: https://www.realtek.com/en/press-room/news-releases/item/realtek-launches-worldwide-first-4k-uhd-set-top-box-soc-rtd1311-integrating-av1-video-decoder-and-multiple-cas-functions (Realtek Launches Worldwide First 4K UHD Set-top Box SoC (RTD1311), Integrating AV1 Video Decoder)

nice to see but realtek charges a lot more for their chips than amlogic, allwinner, huawei, mediatek and rockchip which is why cheap android tv boxes don't use them.

[IgorC]

https://www.reddit.com/r/AV1/comments/bt7l7a/svtav1_now_offers_higher_quality_than_x264_x265/

Everybody compares AV1 to VP9 on 8 bits for both.

What about VP9 10 bits?
It makes also sense to compare AV1 8 bits vs VP9 10 bits.

VP9 10 bits has several advantages over AV1 8 bits at this moment:

Significantly faster encoding
Significantly faster decoding
Hardware support
Should has ~10-20% better compression than VP9 8 bits (not that far from AV1’s 25-30%)


It makes sense to employ VP9 10 bits at least for 2-3 years more until a final jump to AV1. It will give additional time for AV1 to develop better encoders and decoders.

Well, Google and Netflix already use VP9 10 bits for their HDR content but SDR could benefit as well.

Plus VP9 benefits a LOT from 10 bits because it suffers from blocking and banding not less than H.264 as it indicates here https://sonnati.wordpress.com/2016/06/17/does-vp9-deserve-attention-part-ii/

[soresu]

Always interesting to hear about AI/ML tidbits related to video encoding, the Visionular speaker at the Big Apple Video conference (26th June) has this in her summary:

"Finally, we will introduce certain AI+codec techniques that could provide certain novel coding tools leveraging the use of deep learning for the next AOM standard, possibly AV2."

[dapperdan]

I think this paper covers one such proposal for AV2 and has the speaker as an author:

https://link.springer.com/chapter/10.1007/978-3-319-94361-9_18

Couldn't quickly find a public version, but the citations took me to this which I think was another technique discussed:

https://arxiv.org/pdf/1804.09291

[foxyshadis]

Reminds me of NNEDI, both in that there can be surprising visual gains and in that it will require enormous CPU & GPU power just to decode.

But isn't discussion of AV2 getting way off topic? We have an entire forum for discussing new and potential codecs, this thread is just getting more polluted and useless every week.

[benwaggoner]

https://www.reddit.com/r/AV1/comments/bt7l7a/svtav1_now_offers_higher_quality_than_x264_x265/

Everybody compares AV1 to VP9 on 8 bits for both.

What about VP9 10 bits?
It makes also sense to compare AV1 8 bits vs VP9 10 bits.
Why not compare AV1 10-bit vs. VP9 10-bit?

The barriers to using 10-bit seem pretty similar in both cases, namely longer encoding time, lack of 10-bit sources or processing chains (getting much better), reliance on good dithering in display system, somewhat slower SW decode, and rarer HW decode support.

AFAIK, no one is planning any 8-bit only AV1 decoders, so 10-bit might be able to be used by default more often with AV1 if HW decoders become dominant. SW decoders need more optimization for 10-bit to make it competitive for higher resolutions.

I expect 10-bit to become generally mainstream as it is required for HDR, and we're near or past the tipping point where the majority of new video consumption devices support at least HDR-10.

[IgorC]

Of course You can compare AV1 and VP9 both 10bits.

My main point was not very disruptive move from VP9 8 bits to VP9 10 bits as a short term strategy (2-3 years).

Let’s put some numbers. My i7 notebook uses 20-25% of CPU during Youtube 1080p@60fps (VP9 8 bits). If it was VP9 10 bits that would be 5-7% additional CPU usage. Still pretty acceptable.
Now AV1 8 bits consumes whooping 60% at that resolution and framerate (and that with the last version of dav1d). While my notebook still can play it but a fan noise and overall slowness are quite annoying.
Let alone AV1 10 bits. Dav1d hasn’t any 10 bits code yet and it will take some time to get fast 10 bits decoding and/or hardware acceleration. My notebook gets very hot and drops a few frames here and there with near 100% CPU load with AV1 10 bits on 1080p@60. Also my another notebook with Kaby Lake i7 already has VP9 8-/ 10- bits hardware acceleration. So why not?

VP9 8 bits suffers from strong blocking and banding in dark areas and tones in my experience with Youtube and mobile Netflix videos. While VP9 10 bits can handle it very well with a little extra CPU overhead.

[benwaggoner]

Of course You can compare AV1 and VP9 both 10bits.

My main point was not very disruptive move from VP9 8 bits to VP9 10 bits as a short term strategy (2-3 years).

Let’s put some numbers. My i7 notebook uses 20-25% of CPU during Youtube 1080p@60fps (VP9 8 bits). If it was VP9 10 bits that would be 5-7% additional CPU usage. Still pretty acceptable.
Now AV1 8 bits consumes whooping 60% at that resolution and framerate (and that with the last version of dav1d). While my notebook still can play it but a fan noise and overall slowness are quite annoying.
Let alone AV1 10 bits. Dav1d hasn’t any 10 bits code yet and it will take some time to get fast 10 bits decoding and/or hardware acceleration. My notebook gets very hot and drops a few frames here and there with near 100% CPU load with AV1 10 bits on 1080p@60. Also my another notebook with Kaby Lake i7 already has VP9 8-/ 10- bits hardware acceleration. So why not?

VP9 8 bits suffers from strong blocking and banding in dark areas and tones in my experience with Youtube and mobile Netflix videos. While VP9 10 bits can handle it very well with a little extra CPU overhead.
Well the obvious NOW strategy is to keep using H.264 or HEVC, which have broad HW decoder support, and not use CPU at all. x264 properly tuned is at least as good as VP9 for lots of real world content.

I don't see any software decoder solution becoming mainstream, since we have more than good enough HW codec options now.

Fingers crossed that all AV1 HW decoders include 10-bit support. It would be great to have a codec out there where >8-bit support is guaranteed.

[IgorC]

Well the obvious NOW strategy is to keep using H.264 or HEVC
Yeah, nice try. :p

But fortunately Google and Netflix don't think so.
Both make a major accent on VP9 and AV1.

Cheers.

[Quikee]

Fingers crossed that all AV1 HW decoders include 10-bit support. It would be great to have a codec out there where >8-bit support is guaranteed.

There are 3 AV1 profiles (Main, High and Professional) and all define a mandatory 10-bit support. From that I think it's a good chance there will be HW 10-bit support from the beginning. Of course HW manufacturers still can disappoint.

VP9 has 10-bit support only from profile 2 on, where profile 0 and 1 are 8-bit only, which is why 10-bit HW support is less common.

[soresu]

AFAIK, no one is planning any 8-bit only AV1 decoders, so 10-bit might be able to be used by default more often with AV1 if HW decoders become dominant. SW decoders need more optimization for 10-bit to make it competitive for higher resolutions.

True enough, but the libaom decoder isn't nearly as well optimised as dav1d at present, and even the dav1d devs seem to be completely ignoring 10 bit optimisation while they concentrate on getting 8 bit working well across at least x86 SSSE3/SSE4/AVX2, and ARM NEON SIMD targets.

I'd say that the progress so far is pretty incredible for such a young codec, decoder and encoder wise.

From what I remember it also took a while for the OpenHEVC decoder library to get optimised, and they weren't concentrating on mobile nearly as much as the AV1 groups seem to be - though the increased core counts and IPC of current ARM implementations may have influenced that focus to some degree.

[nevcairiel]

the dav1d devs seem to be completely ignoring 10 bit optimisation while they concentrate on getting 8 bit working well across at least x86 SSSE3/SSE4/AVX2, and ARM NEON SIMD targets.

10-bit isn't being "ignored", 8-bit was quite simply a much higher priority since content with that is actually available to the public since YouTube started shipping it, while 10-bit is not. And there is only so many hours in a day.

Work on 10-bit has started now, but due to the nature of the beast, SIMD stuff cannot be easily ported from 8-bit to 10-bit, so its a lot of work still.

[dapperdan]

Lots of interesting talks at the Big Apple Video event (that's Apple as in New York, not Mac Os X):

Probably the most interesting for this group is the second half of Ronald Bultje's talk which covers his Eve-AV1 encoder and some conparisons with other codec and encoders:

https://vimeo.com/344663992

But lots of other interesting stuff from other speakers too if you click through to the channel to see the full list.

I'll also mention this one from Cisco as it's got a kind of boring sounding title but had some interesting stuff around complexity Vs speed in AV1 after the live demos.


https://vimeo.com/344366650

[mandarinka]

I wonder how much does VMAF really speak about visual quality and compression efficiency while keeping detail (as opposed to the usual issue with metrics, the "blur more for maximum PSNR/SSIM" effect), seeing how in those slides, *everything* except Rav1e and x264 is shown as matching or outdoing x265. Well, I guess there's already the usual assertion/claim that x265 = lipvpx-vp9 that raises questions. :rolleyes: I always stop wondering at that point in these presentations...

[dapperdan]

My theory is that the people hired for the subjective tests that underly the objective stats or that vote VP9 as very slightly better than x265 in the MSU tests on subjectify.us have a different notion of quality than the kind of person who is interested in codecs for their own sake.

Like, I read a paper recently where someone was applying their grain synthesis approach to HEVC and the subjective tests they did to prove it worked showed they could get basically all the subjective benefit by just doing the noise removal step and not bothering to add the grain back in, something that could be done by any encoder, for any codec (and I'm guessing this makes up part of the secret sauce of some encoders).

But I guess someone who said they could get a massive increase in subjective quality via the Psy optimisation of basically blurring the input would get some pushback on that view in some quarters, even with subjective tests to back it up.

Link to the paper. It seems at higher qualities the people saw the added grain as a defect rather than a quality improvement (though still a statistical tie mostly).

https://arxiv.org/abs/1904.11754

[soresu]

Having watched some (but not all) the BAV presentations - I know that AV1 is currently not ideal for running a battery of tests at short notice, but did they really need to use such outdated versions of competing codecs?

Im pretty sure that the x265 build was from January, and the libaom build from february in one of them.

Maybe I'm missing something and those builds were picked for stability?

[Blue_MiSfit]

Great talk from Ronald. If only I had the time to do an evaluation of Eve_AV1