Alliance for Open Media codecs

[Zebulon84]

From what I understand, the main point of AV1 is to have a good royalty free codec. Why associate it with an audio codec that require licensing like xHE-AAC, when an equivalent royalty free codec like opus exist ?
Compatibility is not an issue, as nothing is compatible with AV1 today, so you can just add both together.

[IgorC]

Originally Posted by benwaggoner

xHE-AAC is really very good and going to be widely adopted in the mobile ecosystem.

???

xHE-AAC, Opus, HEVC and VP9 were all standarized at the same time.

VP9, HEVC and Opus were adopted in many applications.

xHE-AAC? Name me one functional encoder. 6 years and counting.
No market for its licensing (Opus did it), awfully late and too little.
xHE-AAC is dead.

[benwaggoner]

Originally Posted by mzso

@benwaggoner
Well, I for one don't care at all about <100kbps crappines whatever the codec may be.

You may not. But if you are in rural India on a 2G network, you would care a LOT. And have a lot of company.

Or, if you are in a subway, or on airport WiFi.

[Nintendo Maniac 64]

Hey, has anyone tried decoding AV1 on a CPU that lacks AVX and seeing what the resulting CPU utilization is? (for reference, even the newest 2c/4t Coffee lake Pentiums lack AVX) I'm starting to wonder if my Xeon's under-utilization is due to the fact that my CPU completely predates AVX...

I know that a similar thing happened in the past where VP9 had some heavy optimizations for SSSE3 (I don't believe this is the case anymore) which resulted in something like a 2.5x performance gain simply by having SSSE3 support (which wasn't present on AMD CPUs until 2011).

[MoSal]

Originally Posted by Nintendo Maniac 64

Hey, has anyone tried decoding AV1 on a CPU that lacks AVX and seeing what the resulting CPU utilization is? (for reference, even the newest 2c/4t Coffee lake Pentiums lack AVX) I'm starting to wonder if my Xeon's under-utilization is due to the fact that my CPU completely predates AVX...

I know this doesn't exactly answer your question, but I profiled the decoder with an AVX2-capable CPU, and while there are hot AVX2 optimized functions (namely the ones called by av1_make_inter_predictor), a lot of (currently) hot functions are still implemented in C (e.g. av1_read_coeffs_txb and od_ec_decode_cdf_q15). So the decoder is still not well-optimized SIMD-wise, regardless of the instruction set.

Everyone will probably end up using ffav1 anyway, so this shouldn't really matter.

[lvqcl]

Originally Posted by MoSal

Everyone will probably end up using ffav1 anyway

From Video Dev Days 2018 (September 22):

Dav1d: a fast new AV1 decoder

Dav1d is Dav1d.

[LigH]

Nice ... another alternative to aomenc, similar to rav1e (by team Xiph), here by team VideoLAN.
_

Oops: decoder.

[mandarinka]

Originally Posted by TD-Linux

I plan to add debugging options exactly for the purpose of getting feedback from users - the first obvious thing to add is the internal cdef-dist parameters to tune them. That said, they will remain debug options - for example, we may change how cdef-dist works internally when we find a better way to do it, and that will break the options. If you find a combination of debug options that looks better, I'd rather you report it as a bug and we use that information to change the defaults.

I don't think that's going to be viable. The point of tweakability is that the changes taht improve one source don't improve all sources. I would be surprised if one set of magic numbers were ideal for all content. And likewise, even beyond that objective factor, people have different ideas about how should the video look and that requires ability to change settings too and again precludes one specific setting from being ideal for everything.

Hmmm, makes me think... Doom9 has this in its forum rules: "There is no best".
It's not a straightforward "video truth" (heh), but the reason behind it most likely has a connection exactly with this case. In video processing/compression, you usually don't have an absolute correct and final answer that is true always, regardless of context. Personally I agree with it that there is not one best aq-strength, psy-rdo, crf and so on. IMHO it's going to happen with Rav1e options too.

[Selur]

Since when feeding 10bit yv12 with profile I get:

Profile 2 bit-depth < 10 requires 4:2:2 color format

I got a small question:
What color sampling and bit depth combinations are supported in which profile when using aomenc?

Cu Selur

[nevcairiel]

You should be using Profile 0 (Main) for 10-bit 4:2:0 for maximum compatibility.

The general AV1 rules are pretty simple:
Main Profile (0) is 8/10-bit 4:2:0 or Monochrome (4:0:0)
High Profile (1) is 8/10-bit 4:2:0, 4:4:4, Monochrome
Professional Profile (2) is 8/10/12-bit, 4:2:0, 4:2:2, 4:4:4, Monochrome

I would assume that the encoder follows the same rules - and judging by that message it even enforces the "use the lowest profile possible" suggestion?
I don't know right off the top of my head if the profiles actually influence anything else beyond the bitdepth/chroma, but I don't think so, which gives you little to no reason to use a higher profile when you don't need its chroma/bitdepth extensions.

[foxyshadis]

Originally Posted by marcomsousa

I like more the second round testing at lower data rates and this comment:

You should focus your tests on the data rates at which your video will most likely be deployed. At this point, H.264 and any newer codec should produce near perfect quality at 6 Mbps, making that data rate irrelevant for forward-looking testing. HEVC and VP9 take the near perfect quality level down to between 3.5Mbps to 4Mbps, and AV1 and future codecs should bring this down into the 2Mbps to 3.5Mbps range.

The bias of this comment is obvious: This is targeting the little-to-no-grain FHD segment. Grain is basically an uncompressible random number generator, the only only way out is tons of bitrate or FGM. People are going to hate on AV1 the same way they hate on HEVC because it won't store film grain efficiently, since neither codec is even remotely targeting that.

[foxyshadis]

Originally Posted by mzso

@benwaggoner
Well, I for one don't care at all about <100kbps crappines whatever the codec may be.

It has nothing to do with only being good at crap bitrates, and everything to do with having one codec that can go from 8kbps to 500kbps without compromise, the one codec to replace them all. That is the siren call of Opus, and that is the promise of xHE-AAC, although it hasn't exactly been realized yet. IMHO it's still better to have two heavyweights that are better than everything else out there, because it keeps the pressure on to keep improving.

Originally Posted by IgorC

???

xHE-AAC, Opus, HEVC and VP9 were all standarized at the same time.

VP9, HEVC and Opus were adopted in many applications.

xHE-AAC? Name me one functional encoder. 6 years and counting.
No market for its licensing (Opus did it), awfully late and too little.
xHE-AAC is dead.

Spotify has been using it all year at the 24kbps point, and they're working on moving it up the stack. Android 9 has made it mandatory. (Android 5 made Opus mandatory.)

[Mr_Khyron]

Originally Posted by lvqcl

From Video Dev Days 2018 (September 22):

Dav1d: a fast new AV1 decoder
Ronald Bultje is making the decoder?!!

So we will have the worlds fastest AV1 decoder soon
https://blogs.gnome.org/rbultje/2014...decoder-ffvp9/

[IgorC]

Originally Posted by foxyshadis

Spotify has been using it all year at the 24kbps point, and they're working on moving it up the stack. Android 9 has made it mandatory. (Android 5 made Opus mandatory.)

Spotify uses HE-AAC for lowest bitrate mode, not xHE-AAC.
As for the rest of bitrates they use Vorbis and LC-AAC. There is no quality benefit from xHE/HE-AAC codec at higher rates. Add to it that Vorbis is free and LC-AAC patents will expire in 2 years.
https://support.spotify.com/us/using...ity-streaming/

Originally Posted by foxyshadis

Android 9 has made it mandatory.

That's a decoder. There is still no any encoder (and it won't be)
Remember MPEG surround format? It's 11 years old ... with zero adoption. xHE-AAC goes a same road with its 6 years of 'unadoption'. After MP3 and (HE)AAC none of a new mpeg audio format has seen any meaningful adoption.

[marcomsousa]

ffmpeg 2018-09-13 zeranoe build

ffmpeg -threads 4 -i 1080.mp4  -benchmark -f null -
ffmpeg version N-91943-g1b98bfb932
[libaom-av1 @ 000001e19c898940] 1.0.0-507-g5d963cb57

frame= 1736 fps= 19 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=0.637x
bench: utime=88.703s stime=0.938s rtime=90.919s
bench: maxrss=233580kB

ffmpeg 2018-09-16 zeranoe build

ffmpeg -threads 4 -i 1080.mp4  -benchmark -f null -
ffmpeg version N-91961-g5109c38162
[libaom-av1 @ 000001b015cfd8c0] 1.0.0-590-g6fa400604

frame= 1736 fps= 34 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=1.15x
bench: utime=100.594s stime=2.812s rtime=50.395s
bench: maxrss=274472kB

The new ffmpeg builds with a newer libaom-av1 improves performance a lot (like SmilingWolf said)

[iwod]

Originally Posted by IgorC

Add to it that Vorbis is free and LC-AAC patents will expire in 2 years.

Any links? The only thing I got was from Wikimedia

https://phabricator.wikimedia.org/T166025

Which state LC-AAC to be patents free in 2018! This is big news.

[mzso]

Originally Posted by iwod

Any links? The only thing I got was from Wikimedia

https://phabricator.wikimedia.org/T166025

Which state LC-AAC to be patents free in 2018! This is big news.

Why? Because around no-one cares about it by now?

[LigH]

In general, generalizations are wrong... "no-one" is a strong assumption without proof over the whole population of earth using technology compatible to LC-AAC already (e.g. iTunes).

If you don't care about AAC, it's your choice. But don't assume about anyone else.

[Blue_MiSfit]

Let's try to keep discussion focused on AV1, guys

[marcomsousa]

Originally Posted by Blue_MiSfit

Let's try to keep discussion focused on AV1, guys

Can doom9 promote AV1 and give an sub-forum like for HEVC?

So we can have more specialized threads:

AV1

• Software adoptions
• HW compatible
• libaom
• Rav1e
• Dav1d
• Tune with parametres
• 10bit and 12bit
• Quality compare
• Performance compare
• Custom Builds
• Containers
• Etc...