Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > VP9 and AV1

Reply
 
Thread Tools Search this Thread Display Modes
Old 20th June 2019, 23:55   #1741  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by IgorC View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 21st June 2019, 01:19   #1742  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,315
Quote:
Originally Posted by benwaggoner View Post
Well the obvious NOW strategy is to keep using H.264 or HEVC
Yeah, nice try.

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

Cheers.
IgorC is offline   Reply With Quote
Old 21st June 2019, 04:46   #1743  |  Link
Quikee
Registered User
 
Join Date: Jan 2006
Posts: 41
Quote:
Originally Posted by benwaggoner View Post
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.
Quikee is offline   Reply With Quote
Old 22nd June 2019, 07:51   #1744  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
Quote:
Originally Posted by benwaggoner View Post
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.
soresu is offline   Reply With Quote
Old 22nd June 2019, 08:22   #1745  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by soresu View Post
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 27th June 2019, 09:09   #1746  |  Link
dapperdan
Registered User
 
Join Date: Aug 2009
Posts: 201
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:



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.


dapperdan is offline   Reply With Quote
Old 27th June 2019, 17:03   #1747  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
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. I always stop wondering at that point in these presentations...

Last edited by mandarinka; 27th June 2019 at 17:12.
mandarinka is offline   Reply With Quote
Old 27th June 2019, 19:12   #1748  |  Link
dapperdan
Registered User
 
Join Date: Aug 2009
Posts: 201
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

Last edited by dapperdan; 27th June 2019 at 19:52.
dapperdan is offline   Reply With Quote
Old 28th June 2019, 16:29   #1749  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
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?
soresu is offline   Reply With Quote
Old 28th June 2019, 22:31   #1750  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Great talk from Ronald. If only I had the time to do an evaluation of Eve_AV1
Blue_MiSfit is offline   Reply With Quote
Old 29th June 2019, 15:21   #1751  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
I noticed that several talks mentioned rav1e, but none directly covered it

Was I missing a video, or did the Mozilla/Xiph rav1e guys not get a talk at BAV?
soresu is offline   Reply With Quote
Old 30th June 2019, 11:23   #1752  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
Twitch's AV1 deployment roadmap (from Big Apple Video 2019)

birdie is offline   Reply With Quote
Old 1st July 2019, 17:33   #1753  |  Link
Beelzebubu
Registered User
 
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
Quote:
Originally Posted by soresu View Post
I noticed that several talks mentioned rav1e, but none directly covered it

Was I missing a video, or did the Mozilla/Xiph rav1e guys not get a talk at BAV?
I believe that because the conference was organized by Vimeo/Mozilla, who just announced a partnership around rav1e, they wanted to prevent a potential conflict of interest in talk selection and decided to not give a talk on it.
Beelzebubu is offline   Reply With Quote
Old 1st July 2019, 17:41   #1754  |  Link
Beelzebubu
Registered User
 
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
Quote:
Originally Posted by soresu View Post
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?
The builds used in the were:
  • rav1e c68d68c6fa80dabf5e4ed9b379f090572eb43d96 (Mon Jun 3 2019)
  • libaom a385cc44e15833f56de45bbbc1cc6c474751ac9f (Wed Apr 24 2019)
  • x264 5493be84cdccecee613236c31b1e3227681ce428 (Thu Mar 14 2019)
  • x265 12522:10decf67c077 (Fri Jun 07 2019)
  • SVT-AV1 6fd564611bdb48a2a6d2c7b90a91b4b1bdbe74b9 (Mon Jun 10 2019)
  • libvpx f836d8ba87dcba437228580fe65afe151ccf7659 (Thu Apr 25 2019)

So basically - ignoring x264 for a second (which is pretty mature/stable) - some from late April and some from early June, none from January or February.
Beelzebubu is offline   Reply With Quote
Old 1st July 2019, 19:30   #1755  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
Ah, must have misread the presentation then, easier for me to read from slides than video - still the position of rav1e seems odd, it shows on graphs to be still hovering around x264 - I could have sworn it passed x264 months ago, and then nothing has been said since despite all the work commits being merged into it.

Is it still suffering that regression from awhile ago?

"I believe that because the conference was organized by Vimeo/Mozilla, who just announced a partnership around rav1e, they wanted to prevent a potential conflict of interest in talk selection and decided to not give a talk on it."

Yes that makes sense, just seemed a little odd, like going to WWDC and getting nothing from Apple - still they got a lot of mentions from the presenters in any case.

Last edited by soresu; 1st July 2019 at 19:40.
soresu is offline   Reply With Quote
Old 1st July 2019, 21:55   #1756  |  Link
TD-Linux
Registered User
 
Join Date: Aug 2015
Posts: 34
The rav1e stats are correct. We still fall behind on high bitrate VMAF - most likely due to that being more sensitive to activity masking (aq) which is still in progress by s_p.

The multithreading performance is limited by a serialization point of the loop filters between frames (by far the slowest part of rav1e right now). There's some outstanding PRs to make it better, e.g. https://github.com/xiph/rav1e/pull/1396
TD-Linux is offline   Reply With Quote
Old 1st July 2019, 22:02   #1757  |  Link
dapperdan
Registered User
 
Join Date: Aug 2009
Posts: 201
The Visionular talk from Zoe Liu used builds from Jan and Feb.

I think the x265 release used was the last stable release so that doesn't seem too crazy. You could easily cry foul if someone used a non stable git commit and it performed worse than expected due to hitting a bug.

It's also worth bearing in mind that that was basically the same talk as given at the Agora.io thing, so some people tour these things around for a while, it's not ridiculous for them to reuse slides and not have something fresh for every talk they give. Fairly certain I'd seen the NGCodec talk slides before too.
dapperdan is offline   Reply With Quote
Old 2nd July 2019, 17:53   #1758  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Beelzebubu View Post
The builds used:
  • rav1e c68d68c6fa80dabf5e4ed9b379f090572eb43d96 (Mon Jun 3 2019)
  • libaom a385cc44e15833f56de45bbbc1cc6c474751ac9f (Wed Apr 24 2019)
  • x264 5493be84cdccecee613236c31b1e3227681ce428 (Thu Mar 14 2019)
  • x265 12522:10decf67c077 (Fri Jun 07 2019)
  • SVT-AV1 6fd564611bdb48a2a6d2c7b90a91b4b1bdbe74b9 (Mon Jun 10 2019)
  • libvpx f836d8ba87dcba437228580fe65afe151ccf7659 (Thu Apr 25 2019)
Are the actual command line parameters used documented somewhere?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 2nd July 2019, 18:11   #1759  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by mandarinka View Post
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. I always stop wondering at that point in these presentations...
VMAF is the least-bad objective metric we've ever had, but it's still far from perfect.

Also, VMAF isn't static. Netflix comes out with new ML models that will give different (and more accurate) scores compared to older models. It can be estimated for mobile, 1080p, or UHD devices. The scores vary based on the resolution of comparison (720p tested at 720p will deliver higher scores than 720p tested at 1080p, compared to 1080p encoding). And it is a per-frame metric, and how to aggregate per-frame scores into an overall clip quality is an unanswered question. Using a harmonic mean helps, but even that is probably only useful for <20 second durations. A single VMAF score for a whole movie or episode could indicate highly variable quality or highly consistent quality.

None of this is a diss on VMAF. Netflix did what they set out to do well, put a huge amount of effort into it, and made reasonable design decisions. But like all metrics, it measures what it is designed to measure, not what we wish it measured .

I've seen VMAF do a poor job of detecting:
  • Banding in gradients
  • Detail in low luma
  • Adaptive quantization improvements
  • Artifacts in encoders/formats that weren't included in the VMAF training set
  • Differences between two pretty high quality encodes.

And it doesn't do HDR at all. It used to not do UHD, but does now.

Another problem with a popular metric is that developers start tuning for that metric instead of what the metric is supposed to measure (subjective quality in this case). When developers start tuning for metrics over eyes, the correlation of that metric to subjective quality actually gets WORSE. So, for an encoder like libaom that got tuning based on VMAF ratings, we'd expect that its VMAF scores would be higher relative to actual subjective quality than for encoders that weren't tuned that were. But it'll be better than ones tuned for PSNR, like the vp? series.

Not that tuning for VMAF is a bad strategy. But it does result in less meaningful VMAF scores.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 2nd July 2019, 18:17   #1760  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by dapperdan View Post
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.
These are double-blind tests; the people doing it just compare two encodes.

That said, I've not seen any study demonstrating better subjective quality from a well-tuned libpvx encode versus a well-tuned x265 encode, using the same bitrate @ time.

Quote:
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).
This opens up the interesting question of no-reference quality versus creative intent. Someone just looking at a clip without grain might think it looks great. But if the creators meant there to be grain, than the output isn't accurate. That's something that some studies might not rate. And if customers dislike grain, they might rate the encoded version higher than the source!

Quote:
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.
Well, that is what adaptive quantization is all about, really. Put the artifacts where they are less painful, and used the saved bits where they'll provide the most visible improvements.

There are similar debates about TV's default "vivid" mode. Some people claim to like it, even though what's displayed in manifestly wrong on many axes.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:09.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.