Alliance for Open Media codecs

[Tommy Carrot]

I think it's still intra only.
Nah, it definitely has inter frames, and some basic motion compensation. It doesnt have deblocking filter, b-frames and many other features yet, and the quality is not very good, but it has improved a lot in the last few days. The encoding speed is getting slower though, in the slower speed settings it's getting close to aomenc level, and they still need to keep adding a lot of new features to the encoder.

[olduser217]

It's wrong to call the frame. This is additional information for the GOP sequence. It could simply be added to the first frame and you would not have to invent the unseen frames.

Hi, what do you mean by "It's wrong to call the frame"?
This is NOT just simply an "additional information for the GOP sequence". The data of the non-display frame is there and the decoder has to spend time to decode that like a normal frame, except it doesn't display it.

And what do you mean by "It could simply be added to the first frame"?
I didn't invent the frame, it was encoded by VP9 encoder of libvpx.

[v0lt]

This is NOT just simply an "additional information for the GOP sequence". The data of the non-display frame is there and the decoder has to spend time to decode that like a normal frame, except it doesn't display it.
This is additional information for the GOP sequence that needs to be decoded. Calling it frames is wrong.

[v0lt]

I have a problem with the rav1e encoder. The resulting IVF files play poorly in ffplay and mpv. I can not convert these frames to MKV using ffmpeg or mkvtoolnix.
My IVF AV1 files (https://cloud.mail.ru/home/AV1/).

[Mosu]

The mapping for AV1 in Matroska hasn't been finalized yet. Therefore you cannot convert IVF to Matroska, and even if you could, the resulting files would be invalid.

[LigH]

Hi, what do you mean by "It's wrong to call the frame"?

I believe v0lt dropped an 'm': "It's wrong to call them frame".

And as we are just discussing little details:

Besides WebM and IVF (funny to discover it is based on a legacy container known as "Indeo Video Format"), aomenc also can create "OBU" (Open Bitstream Units); am I right that this format is more similar to the one of raw AVC?

[olduser217]

This is additional information for the GOP sequence that needs to be decoded. Calling it frames is wrong.

I do not agree about this.
Even though these frames are not going to be displayed, they definitely need to be decoded as a frame, stored and take up memory space of a frame in the decoded picture buffer as a reference frame for future frame decoding.

Even the requirement of Youtube mentions that the decoding frame rate can be higher than displaying frame rate, which implying that these "additional information" are exact frame(s).

Anyway, there is no point arguing about this, if your implementation can ignore the performance required to encode/decode these "additional information".

[nevcairiel]

Besides WebM and IVF (funny to discover it is based on a legacy container known as "Indeo Video Format"), aomenc also can create "OBU" (Open Bitstream Units); am I right that this format is more similar to the one of raw AVC?

OBU is the AV1 name for "NALU" (ie. the generic name for every high level element of a bitstream), it does not indicate a specific storage format. You cannot really store AV1 without a container, much like VP9. Thats why IVF exists, an extremely no-frills container serving as a "raw" format, since pure "raw" is not something you should do.

[Mosu]

Besides WebM and IVF (funny to discover it is based on a legacy container known as "Indeo Video Format"), aomenc also can create…

Just to make this very clear: the WebM aomenc produces is not valid. As I said before, the mapping for AV1 in Matroska & WebM hasn't been finalized yet, and what aomenc produces is definitely not going to be what the specs will say how it should be.

[Aleksoid1978]

Hello all. Can somebody build static .lib(for me need only AV1 decoder) x86/x64 version.
I want try add to MPC-BE/ffmpeg library.

[clsid]

I previously used this for mingw build of decoder lib:
rm -rf CmakeCache.txt CMakeFiles
cmake.exe ..\aom -G "MSYS Makefiles" -DCMAKE_AR="C:\msys64\mingw64\bin\x86_64-w64-mingw32-gcc-ar.exe" -DCMAKE_TOOLCHAIN_FILE="..\aom\build\cmake\toolchains\x86_64-mingw-gcc.cmake" -DCONFIG_LOWBITDEPTH=1 -DCONFIG_AV1_ENCODER=0 -DCONFIG_LIBYUV=0 -DCONFIG_WEBM_IO=0 -DENABLE_DOCS=0 -DENABLE_EXAMPLES=0 -DENABLE_TOOLS=0 -DENABLE_TESTS=0 -DENABLE_TESTDATA=0
make
But imho it is too early to include in the player. There is not even (demo) content available yet.

[Aleksoid1978]

I try - but cmake show me error about avx2 and exit. Maybe it's because my CPU don't support AVX2.

[clsid]

Mine doesn't either. Works here with CMake 3.10.2. Haven't tried newer versions.

[MoSal]

I have a problem with the rav1e encoder. The resulting IVF files play poorly in ffplay and mpv.

rav1e still uses a libaom snapshot from February. That is, the output is not yet compatible with the final AV1 specification.

Edit: this is outdated info.

[v0lt]

rav1e still uses a libaom snapshot from February. That is, the output is not yet compatible with the final AV1 specification.
This is unexpected for me. I spent a lot of time using it. :(

[magistral]

rav1e still uses a libaom snapshot from February. That is, the output is not yet compatible with the final AV1 specification.

rav1e has been compliant for almost a month now. See https://github.com/xiph/rav1e/pull/404

[MoSal]

rav1e has been compliant for almost a month now. See https://github.com/xiph/rav1e/pull/404

Ouch. I was looking at the wrong branch.

[IgorC]

I suppose you don't happen to have a graph on speed improvement?
No, I don't have it.

See here https://forum.doom9.org/showpost.php?p=1849845&postcount=855

[TD-Linux]

We have a very experimental option called "--tune psychovisual" that uses a different distortion metric. I'd be interested if anyone wants to compare. It's still relatively untested at the moment.

[benwaggoner]

rav1e improves quite fast
https://twitter.com/fg118942/status/1033280738869706752
It's interesting the comparison is just versus x264/4 using --preset slower. Even at --preset placebo they'd still be way faster than current AV1 implementations. A fairer comparison versus x265 would look more like:

--preset placebo --subme 7 --cu-lossless --tskip --bframes 16 --no-wpp

Which would still be faster than libaom, and would make more exhaustive use of HEVC's features. At very low bitrates, maybe another 10-15% reduction in bits @ quality versus slower.

Quality @ Speed is the name of the game here, and comparisons at orders of magnitude different speed aren't that applicable to estimating real-world advantages of different bitstream formats.

(not a diss at the OP; that data might have been useful for an internal comparison for just posting to Twitter. I just want to warn against premature optimism based on Excel RD plots).

[mandarinka]

We have a very experimental option called "--tune psychovisual" that uses a different distortion metric. I'd be interested if anyone wants to compare. It's still relatively untested at the moment.

Most users probably aren't routinely compiling stuff, are there (Windows) builds of Rav1e available from somebody to test with ?

[Tommy Carrot]

Most users probably aren't routinely compiling stuff, are there (Windows) builds of Rav1e available from somebody to test with ?
Here:
rav1e now has automatic Windows builds via Appveyor. To get the latest build, go to this page:

https://ci.appveyor.com/project/tdaede/rav1e/history

Click the latest build labeled with "master", then click Artifacts to download the executable. I'll wire up a better interface for some at this point.

[hajj_3]

chrome 69 was supposed to add av1 decoding support (which could be enabled using about:flags) however they removed it a week or so ago. If you were wondering why the newly released v69 didn't have it now you know why. I'm pretty sure it will be in v70, though probably disabled by default.

[marcomsousa]

chrome 63 was supposed to add av1 decoding support (which could be enabled using about:flags) however they removed it a week or so ago. If you were wondering why the newly released v63 didn't have it now you know why. I'm pretty sure it will be in v64, though probably disabled by default.

Google release today Chrome 69.

Chrome 69 adds an AV1 decoder to Chrome Desktop stable (Windows, Mac, Linux, ChromeOS) based on the official bitstream specification. At this time, support is limited to "Main" profile 0 and does not include encoding capabilities. The supported container is ISO-BMFF (MP4). To enable this feature use the chrome://flags/#enable-av1-decoder flag.
source (https://developers.google.com/web/updates/2018/08/chrome-69-media-updates)

At this moment it's planing be enabled by default in Chrome v70 (https://www.chromestatus.com/features/5729898442260480).

[sneaker_ger]

I don't have that setting in Chrome 69.0.3497.81 (stable).

[mzso]

chrome 63 was supposed to add av1 decoding support (which could be enabled using about:flags) however they removed it a week or so ago. If you were wondering why the newly released v63 didn't have it now you know why. I'm pretty sure it will be in v64, though probably disabled by default.

Chrome 63 was released last year. And 64 in January.
Google release today Chrome 69.

Chrome 69 adds an AV1 decoder to Chrome Desktop stable (Windows, Mac, Linux, ChromeOS) based on the official bitstream specification. At this time, support is limited to "Main" profile 0 and does not include encoding capabilities. The supported container is ISO-BMFF (MP4). To enable this feature use the chrome://flags/#enable-av1-decoder flag.

At this moment it's planing be enabled by default in Chrome v70. https://www.chromestatus.com/features/5729898442260480

So I guess the encoder will be usable enough in six weeks for youtube beta testing at least.

[mandarinka]

We have a very experimental option called "--tune psychovisual" that uses a different distortion metric. I'd be interested if anyone wants to compare. It's still relatively untested at the moment.

Hmm, only a short test because I ran into time issues but it seems psychovisual tune doesn't on its own prevent the blocking/banding (and texture/noise smoothing/blurring) in areas like sky or other flat regions. But it does seem to help on some noisier/dirtier textures though I can't say it would make the whole picture strictly better. Sometimes it keeps some grain where psnr drops it all, but only sometimes, elsewhere it removes everything just as "well" as psnr. Since it does do something though, I guess it might be useful down the road?

I did not get those "super weird lines" shown in the github issue thread, but I think some similar stripe artifacts do appear in smaller degree too (some transform basis function showing?).

Here are some example images: http://imgbox.com/g/l1gKciGNMk I tested it on a bluray sample I had for other purposes, 1985 animation (remaster with some noise reduction. Chroma noise has been temporally filtered by me earlier). I don't normally deal with live action footage so I have to leave that to others. The sample is a mashup of dunno, 15 scenes, 910 frames total. Lossless encode is about 500 megabytes in case anybody wants to take a look.

I noticed that rav1e at the default speed setting had about the same performance/thread as x265 settings I used for testing before (though that was at much higher bitrate than what I received now), so I decided to use the exact same CLI except for 2-pass to make a comparison clip. So these are not x265 default settings, note.

x265_2.6+2.exe - --input-depth 8 --input-res 1440x1080 --fps 24000/1001 --preset slower --output-depth 10 --ctu 32 --max-tu-size 16 --bitrate 4200 --pass 1 --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 3 --subme 5 --merange 92 --amp --rect --ref 6 --weightb --weightp --keyint 300 --min-keyint 1 --bframes 8 --aq-mode 1 --aq-strength 1.0 --rd 5 --psy-rd 1.6 --psy-rdoq 8.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 5 --qcomp 0.70 --no-strong-intra-smoothing --no-limit-modes --limit-refs 0 --limit-tu 0 --frame-threads 1 --no-wpp --deblock -2:-2 --qg-size 8 --pbratio 1.2 --no-cutree --cu-lossless --lookahead-slices 1 --sar 1:1 --range limited --chromaloc 0 --colormatrix bt709 --no-rskip --rd-refine --cbqpoffs -2 --crqpoffs -2 -o hevc-test.hevc
(this got 4146 kbps on second pass)

Rav1e commandlines:
rav1e.exe --speed 3 --quantizer 70 --tune Psnr dump.y4m -o psnr.ivf (got ~4200 kbps)
rav1e.exe --speed 3 --quantizer 75 --tune Psychovisual dump.y4m -o psy.ivf (got ~4270 kbps)

binary used: https://ci.appveyor.com/project/tdaede/rav1e/build/1.0.195/artifacts

[mandarinka]

Also, may I have some suggestions? I realize that Rav1e is very early in development (I guess no more can be expected from encoders under the age of 2 years and/or supporting adaptive quantization and such important features).
However, there are some changes that I think could be useful to do even at this early stage.

1) there is a general lack of configurable settings and I heard some rumor that this might actually be somewhat a policy (like the nonexistent user-facing configurabiltiy in Theora?) and not just effect of being early in development.
This is an unfortunate position IMHO. x264/x265 have shown that configurability actually adds to both performance and quality because people can tweak settings. No defaults can be good for everybody.
In addition, the it's the configurability that allows testers to actually test the encoder. You can't even get feedback about your default internal tuning if random people can't test it against different set of parameters.
For example, with things like the psychovisual tuning you requested testing off, it would be useful to be able to test what changing the strength does (whether more is better or less is better, where's an apparent sweetspot, whether it is different depending on content etc...)

Things like aq-strenth, psychovisual bias settings, ratecontrol parameters like qcompress, these things absolutely have to be user-configurable in a serious encoder. Anything that has some quality-compression balance effect too, or just about any compression tool that is a bonus for compression but not always - or when there are cases where it hurts and people will want to disable it. All encoders/formats have tools like that (hello there SAO) and I don't think there are reasons for AV1 (rav1e) to be completely different. If you bar access to these parameters, you handicap the encoder by leaving compression performance potential locked away. You should strive to sell what you got, like x264/x265 does, not keep it in the vault.

Even if you disagree with all of the above, you should think about it form the PR point of view. I'm not the only person feeling like this, so exposing the parameters to users will make your encoder more attractive to users even if you think it's useless...

2) a smaller thing: there is very little feedback given by the commandline encoder. A FPS counter probably isn't completely important, but there is one thing that really would help with testing, and that is a achieved bitrate being reported at the end. I was rather suprised Rav1e didn't report this, because I wanted to encode a comparison clip with 2pass with another encoder and this is rather complicating. I have to figure it out based on filesize but the output's already in a container that has some unknown overhead... I used bitrate calculator like in 2006 but note that those generally only have 1 second precision, which is not very exact for short testing samples.

[MoSal]

I don't have that setting in Chrome 69.0.3497.81 (stable).

Is it Chrome? or a Chromium distribution package?

[marcomsousa]

It seems that AV1 has disable in M69 by Google in last minute (https://bugs.chromium.org/p/chromium/issues/detail?id=866522)

But in official docs it's still there Source (https://developers.google.com/web/updates/2018/08/chrome-69-media-updates)

[sneaker_ger]

Is it Chrome? or a Chromium distribution package?
Chrome from Google on Windows 7 x64, not Chromium.

[marcomsousa]

I ask information to Google and they said that the AV1 note in the media update (https://developers.google.com/web/updates/2018/08/chrome-69-media-updates) is an error.

They pulled AV1 support in M69 as there were late changes made to the MP4 specification (https://aomediacodec.github.io/av1-isobmff/).
The spec has been finalized by AOM (http://aomedia.org/), so they have moved launch scheduling to M70 (https://www.chromestatus.com/features/5729898442260480).

This pull request (https://github.com/AOMediaCodec/av1-isobmff/pull/99) in MP4 specification repository suggests that will be finalized soon.

[birdie]

AV1 support is to be reenabled in Chrome 70.

[marcomsousa]

The AV1 MP4 specification (https://aomediacodec.github.io/av1-isobmff/) was finalized yesterday.

[Mr_Khyron]

Youtube has started to encode videos to AV1 :cool:
https://www.youtube.com/watch?v=F1B9Fk_SgI0
https://i.imgur.com/nBcUsqa.png
You must have youtube-dl (2018-09-10) (https://github.com/rg3/youtube-dl/commit/25d110be30b92f785617140b0617a73d8eec5f7b)

[ChaosKing]

And you can download it like this youtube-dl.exe -f 396 https://www.youtube.com/watch?v=F1B9Fk_SgI0

[marcomsousa]

And you can download it like this youtube-dl.exe -f 396 https://www.youtube.com/watch?v=F1B9Fk_SgI0


1080p
Interesting to compare this 3 formats

AV1 - 33.37MiB
youtube-dl.exe -f 399 https://www.youtube.com/watch?v=F1B9Fk_SgI0
VP9 - 42.30MiB
youtube-dl.exe -f 248 https://www.youtube.com/watch?v=F1B9Fk_SgI0
AVC1/H.264 - 41.34MiB
youtube-dl.exe -f 137 https://www.youtube.com/watch?v=F1B9Fk_SgI0

[sneaker_ger]

Thx. ffmpeg can decode/play it already. Interesting that it's not webm. (I know it was said mkv/webm binding isn't final yet.)

[mzso]

Youtube has started to encode videos to AV1 :cool:
https://www.youtube.com/watch?v=F1B9Fk_SgI0
https://i.imgur.com/nBcUsqa.png
You must have youtube-dl (2018-09-10) (https://github.com/rg3/youtube-dl/commit/25d110be30b92f785617140b0617a73d8eec5f7b)

Why is the format identifier so messed up? "av01.0.05M.08" and such. On second look AVC is messed up also.

And it only goes up to 480p?

[MoSal]

And it only goes up to 480p?

Higher resolutions are probably still encoding ;)

[nevcairiel]

Why is the format identifier so messed up? "av01.0.05M.08" and such. On second look AVC is messed up also.

Thats not messed up, thats the codec parameters string as the MP4 specification, its used for immediate profile/level recognition without having to parse the file.

https://aomediacodec.github.io/av1-isobmff/#codecsparam

av1, Main Profile (0), Level 3.1 (05), Main Tier (M), 8 bit (08)

[marcomsousa]

Thx. ffmpeg can decode/play it already. Interesting that it's not webm. (I know it was said mkv/webm binding isn't final yet.)
You can also decode/play with Chrome 70 DEV (via chrome://flags/)
Chrome/Firefox don't add any features that can be incompatible in the future.

Why is the format identifier so messed up? "av01.0.05M.08" and such.
mp4 codecs param (https://aomediacodec.github.io/av1-isobmff/#codecsparam)

And it only goes up to 480p?
It's beginning encoding videos with AV1 as a testing or to push the standard.
It's too expensive encoding all videos at this moment, maybe it's better waiting 1 year (with custom capable encoding hardware).

[mzso]

Thats not messed up, thats the codec parameters string as the MP4 specification, its used for immediate profile/level recognition without having to parse the file.

https://aomediacodec.github.io/av1-isobmff/#codecsparam

av1, Main Profile (0), Level 3.1 (05), Main Tier (M), 8 bit (08)

Ah, okay.

So, is LAV holding back support until some sort of wider adoption of AV1 is accomplished?

It's beginning encoding videos with AV1 as a testing or to push the standard.
It's too expensive encoding all videos at this moment, maybe it's better waiting 1 year (with custom capable encoding hardware).

I didn't suggest that YT should start converting all videos. But converting all resolutions makes sense, for the few that are encoded.

[benwaggoner]

(with custom capable encoding hardware).
The era of HW encoders is behind us. HEVC was too complex to do with ASIC or even with GPU pixel shaders. Encoding with modern complex codecs like AV1 is going to be CPU, and maybe FPGA.

[olduser217]

The era of HW encoders is behind us. HEVC was too complex to do with ASIC or even with GPU pixel shaders. Encoding with modern complex codecs like AV1 is going to be CPU, and maybe FPGA.

I think there are currently some mobile SOCs or surveillance SOCs that support 4K HEVC encoding with hardware accelerator.

[foxyshadis]

Youtube has started to encode videos to AV1 :cool:
https://www.youtube.com/watch?v=F1B9Fk_SgI0
https://i.imgur.com/nBcUsqa.png
You must have youtube-dl (2018-09-10) (https://github.com/rg3/youtube-dl/commit/25d110be30b92f785617140b0617a73d8eec5f7b)

Holy cow, as soon as the extensions get support I'm going to be downloading everything both ways and testing. Hopefully AV1 broad release lives up to its promise.

[SmilingWolf]

Hi y'all!

So, since I keep finding more (https://bugs.chromium.org/p/aomedia/issues/detail?id=2055) and more (https://bugs.chromium.org/p/aomedia/issues/detail?id=2145) alignment-related bugs that only show up on GCC 8.2, but not on 7.3 (compiler's fault? aomedia's fault? Who knows <rant>they have barely gotten any attention despite the community's effort and the fact they involve common configurations and major compiler releases</rant>) I decided to just go for it and build a GCC 7.3 cross compilation VM

Builds specs:
GCC 7.3, 64bits only, statically linked, secure api enabled, so no Win XP support
lbd binaries have been compiled with -DCONFIG_LOWBITDEPTH=1
hbd binaries have been compiled with -DCONFIG_LOWBITDEPTH=0
Use the former for all your 8bits needs since they are considerably faster (https://bugs.chromium.org/p/aomedia/issues/detail?id=2062), the latter for 10-12bits

av1-1.0.0-541-g7d447f5b0: https://mega.nz/#!0wxmgCqS!vBuViCEA7xiLQwl9X1bjVCa9MXoMKv1MubYI0lJnluI

[Pushman]

It is in HD now:

https://i.imgur.com/0oDgonL.png

[LigH]

@SmilingWolf: I'll keep an eye on it, as soon as MABS passes in both branches again. But for now, there is a greater evil (https://github.com/jb-alvarado/media-autobuild_suite/issues/914) breaking the building of ffmpeg. If the API for AV1 was ever "frozen", it seems to melt already.

And yes, I shared one of the issues of GCC 8.2.0 creating unaligned RAM access when vector optimization is enabled, several weeks ago, and apart from adding more CC's, not much happened about it.

[SmilingWolf]

@SmilingWolf: I'll keep an eye on it, as soon as MABS passes in both branches again. But for now, there is a greater evil (https://github.com/jb-alvarado/media-autobuild_suite/issues/914) breaking the building of ffmpeg. If the API for AV1 was ever "frozen", it seems to melt already.

Well TBF they froze the bitstream and released a "stable" version 1.0, such issues are to be expected when using an old and moving codebase that needs some cleaning up after many different iterations.
Shouldn't take much more than removing lines 741-744 from libavcodec/libaomenc.c (https://ffmpeg.org/doxygen/trunk/libaomenc_8c_source.html)
This one's on FFMPEG, and will probably be fixed in a day or so

What bothers me much more is the same as the second part of your post, the inertia over months-long periods of time in the AOM tracker

And yes, I shared one of the issues of GCC 8.2.0 creating unaligned RAM access when vector optimization is enabled, several weeks ago, and apart from adding more CC's, not much happened about it.
Regarding this, they are evaluating (https://bugs.chromium.org/p/aomedia/issues/detail?id=2055#c14) using the patch I suggested in comment 8 as a short term fix. BUT now it can't be tested with GCC 8.2 on master, because there is another couple of access violations of various nature happening at different optimization levels because of (as far as I've been able to test) some unholy interaction between GCC 8.2 and AVX code

Side note: unaligned memory access is fine AS LONG AS the ASM instructions emitted take into account memory could be unaligned. In this instance GCC 8.2 -O3 emits instructions that expect memory to be aligned to a 16-byte boundary (movdqa and movaps), while GCC 8.2 -O3 -fno-tree-slp-vectorize emits instructions fit for unaligned memory access (movdqu and movups)

My advice is to stay on GCC 7.3 for AV1 for the time being. I found the laptop I was using back in june to build A/V stuff with an old toolchain, if you want I can zip it up and upload