Alliance for Open Media codecs

[nevcairiel]

The spec is slightly vague when it comes to this, but even if it would be technically allowed to encode a lower format in a higher profile, you should never do that. There is absolutely no reason to. It'll just screw everything over.
The only thing the profile controls is chroma/bitdepth, there are no other variables, so pick the one appropriate for your content and don't do anything else.

A very strict reading of the spec might even forbid this, ie. Section 6.4.1 (General sequence header OBU semantics) has a table with allowed features per profile, and it has no "backwards" notes.
So I'll go with that. Its not allowed.

[Selur]

Looking at https://aomediacodec.github.io/av1-spec/av1-spec.pdf
The Main profile supports YUV 4:2:0 or monochrome bitstreams with bit depth equal to 8 or 10.
The High profile further adds support for 4:4:4 bitstreams with the same bit depth constraints.
Finally, the Professional profile extends support over the High profile to also bitstreams with bit depth equal to 12, and also adds support for the 4:2:2 video format.
at page 635 of 665
Thus how I understand it:
Main should support:

4:2:0 at 8bit and 10bit

High should support:

4:2:0 at 8bit and 10bit
4:4:4 at 8bit and 10bit

and Professional should support

4:2:0 at 8bit, 10bit and 12bit
4:2:2 at 8bit, 10bit and 12bit
4:4:4 at 8bit, 10bit and 12bit


Where as aomenc reports:
Profile 1 requires 4:4:4 color format
and
Profile 2 bit-depth < 10 requires 4:2:2 color format
from the looks of it aomenc has a bug here.

Looking at 6.4.1 I agree with you it should be:

Main:

4:0:0 with 8bit
4:2:0 with 8 and 10 bit

High:

4:4:4 with 8 and 10 bit

Professional:

4:0:0 with 8, 10, 12 bit
4:2:0 with 12bit
4:2:2 with 8, 10, 12 bit
4:4:4 with 8, 10, 12 bit



Cu Selur

[sneaker_ger]

I think they don't want to have one format in different profiles. If I go by what you say I would have the choice to encode 4:2:0 10 bit as either Main or Professional.

So I think this is correct:
Main should support:
Monochrome at 8bit and 10bit
4:2:0 at 8bit and 10bit

High should support:
4:4:4 at 8bit and 10bit

and Professional should support
Monochrome at 12 bit
4:2:0 at 12 bit
4:2:2 at 8bit, 10bit and 12bit
4:4:4 at 12bit

[sneaker_ger]

Btw: MkvToolNix (https://forum.doom9.org/showpost.php?p=1854553&postcount=131) 28.0.0 now with finalized support for AV1 reading/writing in mkv/webm.

[nevcairiel]

Looking at https://aomediacodec.github.io/av1-spec/av1-spec.pdf

at page 635 of 665


Annex A is not really restricting the bitstream, its just naming the profiles.

The actual rules are in Section 6.4.1 like I said in my previous post (currently page 112)

6.4.1. General sequence header OBU semantics
seq_profile specifies the features that can be used in the coded video sequence.

seq_profile Bit depth Monochrome support Chroma subsampling
0 8 or 10 Yes YUV 4:2:0
1 8 or 10 No YUV 4:4:4
2 8 or 10 Yes YUV 4:2:2
2 12 Yes YUV 4:2:0, YUV 4:2:2, YUV 4:4:4


This table defines the bitstream rules. As stated there, its not allowed.
aomenc seems to behave just fine. Wikipedia is wrong (what else is new?)

And as said before, there is no sane reason to ever want to do that.

[sneaker_ger]

Wikipedia is wrong
Liar! :devil:

[nevcairiel]

That just makes the table look very weird on Wikipedia though, and it also doesn't communicate the limitations of encoding 4:2:0 or 4:4:4 in the professional profile correctly (although the text before it does, but reading pfff)

[sneaker_ger]

Ok, table corrected (again :( ) and cleaned. Hope it sticks...

Though I'm still wondering about the decoder levels that are allegedly required. Can't find anything about that in the specs. Level 2.2 doesn't even seem to be defined yet. I removed it for now.

[SmilingWolf]

32/64bits binaries:
av1-1.0.0-811-g68baec84b: https://mega.nz/#!w4Y2AawR!T4zzPbckJmJI02cEKsfxQ5hUhbFg0MhmHr536z_btCM

[IgorC]

HEVC eliminates most of the 10-bit advantage over 8-bit that H.264 had. If the source doesn’t have banding, you don’t get much new banding even at lower bitrates. I think AV1 should have ballpark similar improvements.

But yeah, it would be great if the “Main” profile for future codecs always supported at least 10-bit. That’s required for HDR, which is quickly becoming mainstream. It’s not like the SoC or GOU vendors are developing 8-bit only decoders anymore, even if some display pipelines are 8-bit RGB. But 10-bit 64-960 4:2:0 Y’CbCr makes for better 0-255 RGB 4:4:4 anyway.
I guess You're right. x265 doesn't suffer that much from banding as VP9 does.
https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/
https://mattgadient.com/results-encoding-8-bit-video-at-81012-bit-in-handbrake-x264x265/


Interesting news. it's astonishing to see Machine Learning in coding field.
New version of Opus audio codec uses ML. Quality gains are more than significant. Now speech/audio detector has a human-level intelligence. :eek:
https://hub.packtpub.com/opus-1-3-a-popular-foss-audio-codec-with-machine-learning-and-vr-support-is-now-generally-available/

https://opus-codec.org/

I can't imagine what can be done with AV1 in future.

[marcomsousa]

Mozilla released today Firefox 63

Firefox 63 adds an AV1 decoder (it's disabled by default).


To try AV1:

Update your stable Firefox (installer (http://ftp.mozilla.org/pub/firefox/releases/63.0/))
Enable AV1: about:config?filter=media.av1.enabled pass the alert message and enable av1 then restart Firefox
Go to the YouTube TestTube page (https://www.youtube.com/testtube).
Select "Prefer AV1 for SD" or "Always Prefer AV1" to get the desired AV1 resolution. Note that at higher resolutions, AV1 is more likely to experience playback performance issues on some devices.
Try playing YouTube clips from the AV1 Beta Launch Playlist (https://www.youtube.com/playlist?list=PLyqf6gJt7KuHBmeVzZteZUlNUQAVLwrZS).
Confirm the codec av01 in "Stats for nerds".

[hajj_3]

Firefox 64 Beta is out, which i think enables AV1 by default.

UPDATE: I don't think it is enabled by default, this video won't play: http://video.1ko.ch/codec-comparison/videos/av1-2018-06_550.webm

[Pushman]

https://www.bunkus.org/blog/

Here is MKVToolNix v28.0.0: the first release to support AV1 in its finalized form. mkvmerge can read it from Matroska/WebM, MP4, IVF container files and from raw OBU streams. mkvextract will extract it to IVF files. Apart from that a couple of bugs were fixed and usabitliy enhancements made.

New features and enhancements for AV1:


mkvmerge: AV1 parser: updated the code for the finalized AV1 bitstream specification. Part of the implementation of #2261.
mkvmerge: AV1 packetizer: updated the code for the finalized AV1-in-Matroska & WebM mapping specification. Part of the implementation of #2261.
mkvmerge: AV1 support: the `--engage enable_av1` option has been removed again. Part of the implementation of #2261.
mkvmerge: MP4 reader: added support for AV1. Part of the implementation of #2261.
mkvextract: added support for extracting AV1 to IVF. Part of the implementation of #2261.

[Mosu]

Btw: MkvToolNix (https://forum.doom9.org/showpost.php?p=1854553&postcount=131) 28.0.0 now with finalized support for AV1 reading/writing in mkv/webm.

https://www.bunkus.org/blog/

Note that the sequence header parser code in mkvmerge v28 was buggy (https://gitlab.com/mbunkus/mkvtoolnix/issues/2410). Those issues have been fixed since. If you want to use mkvmerge/MKVToolNix for AV1, you should use the latest continuous builds (Windows (https://mkvtoolnix.download/windows/continuous/), Linux AppImage (https://mkvtoolnix.download/appimage/continuous/)) instead.

[PatchWorKs]

Hi everyone, I'm trying to understand how to obtain the better quality/speed/size for FHD/3 (aka 360p or, more precisely, 640x*) resolution videos @ 1 Mbps.

Since AV1 (but other codecs too) supports multiple bitdepth do you suggest to use 12 ?
About chroma: choosing 444 instead of 420 could help to obtain better quality ?

Thanks in advice for anyone can help.

[alex1399]

Apply moderate De-grain, De-noise, Sharpen and more would help the visual quality. Some encode enhancer (forum.videohelp.com/threads/389555) have friendly GUI to work around if you have video card.

[M4ST3R]

Mozilla released today Firefox 63

Firefox 63 adds an AV1 decoder (it's disabled by default).


To try AV1:

Update your stable Firefox (installer (http://ftp.mozilla.org/pub/firefox/releases/63.0/))
Enable AV1: about:config?filter=media.av1.enabled pass the alert message and enable av1 then restart Firefox
Go to the YouTube TestTube page (https://www.youtube.com/testtube).
Select "Prefer AV1 for SD" or "Always Prefer AV1" to get the desired AV1 resolution. Note that at higher resolutions, AV1 is more likely to experience playback performance issues on some devices.
Try playing YouTube clips from the AV1 Beta Launch Playlist (https://www.youtube.com/playlist?list=PLyqf6gJt7KuHBmeVzZteZUlNUQAVLwrZS).
Confirm the codec av01 in "Stats for nerds".


It doesn't work me. The youtube testtube page says the AV1 codec is not available in my browser yet.
I use firefox 63 and I have enabled media.av1.enabled

[benwaggoner]

Hi everyone, I'm trying to understand how to obtain the better quality/speed/size for FHD/3 (aka 360p or, more precisely, 640x*) resolution videos @ 1 Mbps.

Since AV1 (but other codecs too) supports multiple bitdepth do you suggest to use 12 ?
Higher will make encoding and decoding slower. I wouldn’t use >8-bit unless working with a source that is >8-bit with >8-bit detail.

About chroma: choosing 444 instead of 420 could help to obtain better quality ?
444 gives you 24-bit per pixel instead of 12-bit. Making some naive assumptions, one could expect that to double encoding and decoding time. And most progressive content is totally fine with 4:2:0 sub sampling. The exception is if you have very sharp edges between saturated colors. Like sharply rendered red text on a green background. Natural images are almost always great with 4:2:0.

Also, VBR 1 Mbps at 640x360 isn’t a very challenging bitrate; H.264 can do quite well for lots of content at that bitrate, and HEVC can do well at significantly lower. Heck, I could do a nice WMV VC-1 in those constraints a decade ago. Doing encoding tuning at a bitrate where things look good is a lot harder since subtle improvements or degradations might not be visible. Using a bitrate where it’s never going to look great makes the impact of changes more visible and more meaningful. Making mediocre quality significantly better is where differences in encoders really matter.

FWIW. I’m able to get mediocre 1920x800 out of HEVC at 1 Mbps. That’s 1/9th the bits per pixel as 1 Mbps at 640x360.

An “interesting” bitrate to compare 640x360 natural image content at would be more in the 200-500 Kbps range for VBR. If you’re doing a constant bitrate encode, higher can make sense. I’m not sure how accurate CBR rate control is in AV1, though. VP3-9 weren’t ever any good at VBV compliance.




Sent from my iPad using Tapatalk

[lvqcl]

It doesn't work me. The youtube testtube page says the AV1 codec is not available in my browser yet.
I use firefox 63 and I have enabled media.av1.enabled

32-bit Firefox or 64-bit one?

[Mystery Keeper]

Works for me. Sad thing is: the uploaded videos are uploaded in inferior formats so far. Re-coding into AV1 doesn't make them better. The first video I watched had color banding. But no DCT artifacts.

[marcomsousa]

The commit libaom-v1.0.0-820-g4c118dc5e enables by default CONFIG_LOWBITDEPTH=1, 8bit content optimized codepaths.

[PatchWorKs]

Higher will make encoding and decoding slower. I wouldnÂ’t use >8-bit unless working with a source that is >8-bit with >8-bit detail.
Yes, but - as you probably know - more bits results in better compression...

Anyway source is AVC 264 FHD 8bits 4:2:0

444 gives you 24-bit per pixel instead of 12-bit. Making some naive assumptions, one could expect that to double encoding and decoding time. And most progressive content is totally fine with 4:2:0 sub sampling. The exception is if you have very sharp edges between saturated colors. Like sharply rendered red text on a green background. Natural images are almost always great with 4:2:0.
Yes, I made some tests @444 and encoded videos seems - to me- less contrasted/colorful (more natural ?)...

Also, VBR 1 Mbps at 640x360 isnÂ’t a very challenging bitrate; H.264 can do quite well for lots of content at that bitrate, and HEVC can do well at significantly lower. Heck, I could do a nice WMV VC-1 in those constraints a decade ago. Doing encoding tuning at a bitrate where things look good is a lot harder since subtle improvements or degradations might not be visible. Using a bitrate where itÂ’s never going to look great makes the impact of changes more visible and more meaningful. Making mediocre quality significantly better is where differences in encoders really matter.
Well, the challenge is to stay under 1Gb for 2hrs of stream (audio+video) preserving quality.
Anyway I'll try @ 750Kbps to understand if it's possible to obtain acceptable results.

FWIW. IÂ’m able to get mediocre 1920x800 out of HEVC at 1 Mbps. ThatÂ’s 1/9th the bits per pixel as 1 Mbps at 640x360.

An “interesting” bitrate to compare 640x360 natural image content at would be more in the 200-500 Kbps range for VBR. If you’re doing a constant bitrate encode, higher can make sense. I’m not sure how accurate CBR rate control is in AV1, though. VP3-9 weren’t ever any good at VBV compliance.
I'm testing "realtime" quality encoding, so VBR is not allowed.

Here's the FFMPEG commandline I've used to test VP9:
ffmpeg.exe
-y
-hwaccel auto
-i "<source_filename>"
-c:v libvpx-vp9
-pix_fmt yuv444p12le
-cpu-used 5
-r 30
-g 90
-quality realtime
-speed 7
-threads 4
-row-mt 1
-tile-columns 1
-frame-parallel 0
-qmin 4
-qmax 48
-b:v 1M
-maxrate 1M
-bufsize 1M
-sws_flags lanczos
-vf "crop=<parm>,scale=iw/3:ih/3"
-sn
-an
-f webm "<output>_VP9.webm"
This performs between 30 and 50fps (depending on source complexity) on i3-4160 testing machine.

[utack]

the past ~2 weeks libaom has been producing files for me it can't decode any more, a few frames into the stream it dies and never recovers
Failed to decode frame: Corrupt frame detected
Additional information: Failed to decode tile data

dav1d is not dying, but shows a lot of blocky colorful artifarcts in many GOPs
Is that happening to everyone else or did i find a rare bug in my build proccess or encoder settings?

[Selur]

Is that happening to everyone else or did i find a rare bug in my build proccess or encoder settings?
Encoded a bunch of files last week with with up-to-date builds of aomenc and rav1e and had no problem.

[SmilingWolf]

the past ~2 weeks libaom has been producing files for me it can't decode any more, a few frames into the stream it dies and never recovers

dav1d is not dying, but shows a lot of blocky colorful artifarcts in many GOPs
Is that happening to everyone else or did i find a rare bug in my build proccess or encoder settings?

If you're using more than one slice and more than one thread, you've just met my old friend BUG 2054 (https://bugs.chromium.org/p/aomedia/issues/detail?id=2054)
So far I have reached the conclusion it happens (but not always!) when forcing the encoder to use columns with the width of 2 superblocks (128 pixels). Doesn't happen when the columns have a width of 256 pixels or more on the same file with all the other settings being the same.
I have been doing single threaded encodes for weeks because of this.

[hajj_3]

MPC-BE beta 1.5.3 v4106 has been released which supports AV1: https://sourceforge.net/projects/mpcbe/files/MPC-BE/Release%20builds/1.5.2/MPC-BE.1.5.2.x64-installer.zip/download

[utack]

If you're using more than one slice and more than one thread, you've just met my old friend BUG 2054 (https://bugs.chromium.org/p/aomedia/issues/detail?id=2054)


That might be it. Or the 10bit pipeline.
I switched to 8bit and no "threads" option and that works for now.

[benwaggoner]

Yes, but - as you probably know - more bits results in better compression...

Anyway source is AVC 264 FHD 8bits 4:2:0


Yes, I made some tests @444 and encoded videos seems - to me- less contrasted/colorful (more natural ?)...
There REALLY shouldn’t be any value in using more chroma sub samples than the source! Unless you are downscaling in the same operation. A 720p 4:2:0 source’s chroma samples would be 4:4:4 at 360p.

You might want to try some kind of blind test, though. You shouldn’t see more color or more contrast with more samples. You might see sharper edges between areas of strong color. For example, with ClearType text, which plays all sorts of RGB 444 subpixel tricks that don’t translate well to even other LCD panels, let along different color spaces.

(Pro tip for doing screen recording; disable chroma subpixel rendering for text. Otherwise it can look unpredictably funky on different displays).

[Revan654]

1. With Rav1e anyone know what type -r Reconstruction takes (Boolean, String, Int, etc...) and what it actually does. I can not find any info on it and the help menu is blank for that option.

2. This has been likely asked a dozen times over, Whats the main reason why aomenc is slower compared to other encoders out there?

I'm just starting to research AV1.

[marcomsousa]

2. This has been likely asked a dozen times over, Whats the main reason why aomenc is slower compared to other encoders out there?


libaom it was developed for research purposes during AV1 design.
Isn't optimized for speed, only to be a good reference encoder/decoder
Almost all other encoder, the reference encoder isn't fast enough.
That's why there are 3º parties implementation of the same codecs dav1d (https://code.videolan.org/videolan/dav1d) and rav1e (https://github.com/xiph/rav1e)
Now that the AV1 design is finished, the reference encoder (https://aomedia.googlesource.com/aom/+log/master) is now optimizing there code for speed.
We need to wait until there are hardware acceleration (for decoding 4k/8k UHD) (2, 3 years to be mainstream)
New codecs are (always) more complex that the codecs before.
New codecs that are releasing now are too much complex for todays CPU, but they are designed to be using mainstream in future CPU 3 years from now.
Before AV1 became mainstream, AOM was to begin working in AV2, that will me more complex that AV1, and will be design to CPU released 7 or 8 years from now.
Increase the complex is the only way to produce better quality with less space. And that is ok if the hardware continues to improve over time..

[LigH]

New uploads: (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

AOM v1.0.0-864-g351711076 (https://www.mediafire.com/file/lpgb984xqh79733/aom_v1.0.0-864-g351711076.7z)
now with TPL model (RDO modulation based on frame temporal dependency) and block based denoiser

rav1e 0.1.0 (7492fc5 / 2018-11-01) (https://www.mediafire.com/file/p33yn56lvruc2nz/rav1e_0.1.0_2018-11-01_7492fc5.7z)

dav1d 0.0.1 (287ba91 / 2018-11-02) (https://www.mediafire.com/file/k8tzk89944xvmx9/dav1d_0.0.1_2018-11-02_287ba91.7z)

[Mjpeg]

Report from a 1 day meeting on future codecs, h264 through VVC.

http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/At-the-Battle-of-the-Codecs-Answers-on-AV1-HEVC-and-VP9-128213.aspx

The most interesting quote is from a Youtube encoding engineer that AV1 encoding time is down to 16x slower vs. VP9, so that's a nice performance trend (no doubt giving up some % of quality). What's important (as benwaggoner always says) is what quality@perf tradeoffs are available.

[benwaggoner]

Report from a 1 day meeting on future codecs, h264 through VVC.

http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/At-the-Battle-of-the-Codecs-Answers-on-AV1-HEVC-and-VP9-128213.aspx

The most interesting quote is from a Youtube encoding engineer that AV1 encoding time is down to 16x slower vs. VP9, so that's a nice performance trend (no doubt giving up some % of quality). What's important (as benwaggoner always says) is what quality@perf tradeoffs are available.
Yeah, YouTube is sort of a special case for encoding. Given how much content they get and the average views/upload, economically they’re going to spend fewer MIPS/pixel than for premium content. And they do their stuff (last I heard) single-threaded on unused-at-that-moment Google servers, ala a spot instance. Which is why libvpx never got a lot of multithreading, nor were the VPx series of bitstream vetted for parallelizability.

Flip side is no one expects spectacular quality from YouTube. It’s free. So even though video game captures always look terrible (lots of high frequency sharp edges...), that’s what people are used to and so they don’t really think about it any more. So YouTube can experiment a lot at how to make good-enough quality fast, which is a different direction from a lot of other folks, and a very useful one in encoder development.

It can be a good starting point for live encoders, although a YouTube can handle some content taking 3x longer to encode than other content due to complexity.

HEVC and AV1 have great tools for making text and video game footage a LOT better. But they are also pretty expensive to add to normal mode detection, so lot of heuristics to figure out when to use them are important.

[Mjpeg]

I'm all for AV1 encoders getting faster, but of course on an absolute scale it's pretty slow still, spending a lot of CPU for all that efficiency.

I always figured live-encoding would be quite a wait, although the official framing of AV! always mentions that live-stream/chat was an important case they had thought about.

So anyway I find a talk by Nathan Egge of Mozilla

Most of the slides look familiar but there's a claim about live encoding I had not seen before.

https://people.xiph.org/~negge/AVIF2018.pdf

page 55:

rav1e Live Encoding
Shown at IBC in Sept 2018
● 640x480 @ 30 fps
● Single tile / thread
● Simplified feature set

I guess one sign of AV1 progress will be when someone posts a link here to an AV1 webcam.

[SmilingWolf]

32/64bits binaries (GCC 8.2):
av1-1.0.0-877-ge5761e020: https://mega.nz/#!1sgl3QrB!x6F6SfLzz6smB9wJlfczj3y9z1TcBvWZ-IMSzZukIWs

A long standing multithreading bug has been fixed tonight, so here's a new build
Cc @utack

[v0lt]

A long standing multithreading bug has been fixed tonight, so here's a new build
I still don’t see aomenc.exe using more than one thread.

[SmilingWolf]

It won't by default. Tile columns, rows and threads count are all set to 0.
You have to give at least --tile-columns=1 (and/or --tile-rows=1) --threads=2 to have it use multithreading.

[LigH]

32 bit GCC 8.2? ... Does it exist for Windows? MSYS2 did not yet solve internal compiling errors, I believe.

[SmilingWolf]

I'm cross compiling from a linux VM. Made it easier to switch between compiler versions back when I was investigating the optimization related bug, then the bug was worked around and the environment stuck.
Silver lining, I'm not stuck with an outdated compiler and I don't have to manage my own MSYS2 package.

[Clare]

It won't by default. Tile columns, rows and threads count are all set to 0.
You have to give at least --tile-columns=1 (and/or --tile-rows=1) --threads=2 to have it use multithreading.

Just use --row-mt=1 instead of tiles, it maxes out all my threads.

[SmilingWolf]

What does your command line look like? So far I've been unable to make row-mt work myself

My tries so far:
this one generates invalid bitstream:
../../bin8/aomenc --frame-parallel=0 --tile-columns=2 --tile-rows=2 --row-mt=1 --threads=4 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --end-usage=q --cq-level=40 --test-decode=fatal -o test.av1.cq40.webm orig.i420.y4m
Pass 1/2 frame 480/481 92352B 1539b/f 36899b/s 17849 ms (26.89 fps)
Pass 2/2 frame 19/0 0B 17871 ms 1.06 fps [ETA unknown] 2423FFailed to decode frame 2 in stream 0: Corrupt frame detected
Failed to decode tile data

This one works but uses only 12-13% (one core) of my 4c/8t CPU:
../../bin8/aomenc --frame-parallel=0 --tile-columns=2 --tile-rows=2 --row-mt=1 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --end-usage=q --cq-level=40 --test-decode=fatal -o test.av1.cq40.webm orig.i420.y4m
Pass 1/2 frame 480/481 92352B 1539b/f 36899b/s 18130 ms (26.47 fps)
Pass 2/2 frame 16/0 0B 18152 ms 52.88 fpm [ETA unknown]

[v0lt]

It won't by default. Tile columns, rows and threads count are all set to 0.
You have to give at least --tile-columns=1 (and/or --tile-rows=1) --threads=2 to have it use multithreading.
I always ask 4 threads, but it never worked.
aomenc --codec=av1 --cq-level=20 --threads=4

Added:
I do not understand what are the columns and rows in this context. If a codec divides a frame into identical independent cells, it is unclear how it can effectively compress in a multi-thread mode.

[SmilingWolf]

Tile columns (click to enlarge):
https://thumb.ibb.co/jYeVnf/Screenshot-2.png (https://ibb.co/jYeVnf)

The frame is divided in N (10 in my case) columns of equal width.
Each column in indipendent, so every thread can indipendently work on a tile.
Using tile columns (and/or rows) makes decoding faster too, because each tile can be decoded by a separate thread, making playback way smoother

You command line doesn't show any multithreading because you only have a single big tile, which is being worked on by thread 0, leaving threads 1,2,3 with nothing to do.

[v0lt]

@SmilingWolf
In this case, the video stream received in the multi-thread mode can be worse than the one-thread mode (with the same bitrate of course). Because motion prediction algorithms will not be able to work effectively.

Added:
I also noticed that some files are decoded by 2 threads, while others are always in single-threaded mode. This is strange, because It is not clear how this will affect hardware decoding.

[SmilingWolf]

@SmilingWolf
In this case, the video stream received in the multi-thread mode can be worse than the one-thread mode (with the same bitrate of course). Because motion prediction algorithms will not be able to work effectively.
Indeed tile columns affect compression efficiency. However it is also the only way to have threaded decoding and the only way to have smooth 1080p decoding back when I began testing (far before my registration on doom9). Well, at least it was before dav1d, which seems to be using a couple different parallelization techniques.
I'll be running a couple of simple test encodes and decodes and report back some numbers.

Added:
I also noticed that some files are decoded by 2 threads, while others are always in single-threaded mode.
Do you have any samples? Files coming from YouTube perhaps? I'd like to inspect them. I know at least some of the first videos they put online in the AV1 test playlist used a single tile column, which forced single threaded decoding in anything using libaom (e.g. Firefox, Chrome, FFMpeg)

[v0lt]

@SmilingWolf
As far as I remember, streams obtained using rav1e v1.0.116 were decoded in single-threaded mode. But samples from elecard.com loaded at least 2 cores.
Now it is difficult for me to recheck it, because the decoder in the player works faster than before.

[SmilingWolf]

Alright, rav1e doesn't support tiles yet, so every frame is a single big column
I'll inspect the Elecard samples ASAP.

Meanwhile my encodes are finishing up, so I'll post size, quality and decoding time differences when they're done

[SmilingWolf]

The clip used is the F.Y.C one I described some pages ago (http://forum.doom9.org/showthread.php?p=1852449#post1852449)

aomenc/aomdec: 1.0.0-877-ge5761e020
dav1d: 0.0.1 e0c3186

Quality and sizes:
Sizes:
test.av1.cq20.tc0.ivf: 5956739
test.av1.cq20.tc2.ivf: 6001827 +0.75%
test.av1.cq20.tc6.ivf: 6091937 +2.22%

PSNR-HVS-M:
test.av1.cq20.tc0.ivf: 43.192
test.av1.cq20.tc2.ivf: 43.1736 -0.04%
test.av1.cq20.tc6.ivf: 43.1489 -0.10%

MS-SSIM:
test.av1.cq20.tc0.ivf: 26.5095
test.av1.cq20.tc2.ivf: 26.4895 -0.07%
test.av1.cq20.tc6.ivf: 26.467 -0.15%

Decoding:
# aomdec --threads=8 --progress -o /dev/null test.av1.cq20.tc0.ivf
480 decoded frames in 4660361 us (103.00 fps)

# aomdec --threads=8 --progress -o /dev/null test.av1.cq20.tc2.ivf
480 decoded frames in 3365067 us (142.64 fps) +27,79%

# aomdec --threads=8 --progress -o /dev/null test.av1.cq20.tc6.ivf
480 decoded frames in 3267103 us (146.92 fps) +29,89%

# time dav1d -i test.av1.cq20.tc0.ivf -o /dev/null --muxer yuv4mpeg2 -q --framethreads 8 --tilethreads 4
480 decoded frames in 1997 ms (240,36 fps)

# time dav1d -i test.av1.cq20.tc2.ivf -o /dev/null --muxer yuv4mpeg2 -q --framethreads 8 --tilethreads 4
480 decoded frames in 1747 ms (274,75 fps) +12,51%

# time dav1d -i test.av1.cq20.tc6.ivf -o /dev/null --muxer yuv4mpeg2 -q --framethreads 8 --tilethreads 4
480 decoded frames in 1763 ms (272,26 fps) +11,71%

TC 0 means one single column (whole frame)
TC 2 generates 4 columns
TC 6 generates 10 columns
I write they "generate" N columns because there's an upper limit to how many columns fit in a given horizontal resolution, TC 6 implies an actual max of 2^6=64 columns and I use it as a catch all to generate as many columns as possible for my clips.

So the take aways from all this:

for very negligible quality and size differences you can get up to 30% faster decoding performances on 720p. I'd expect it to be even more noticeable on higher resolutions;
dav1d is now faster than libaom;
interestingly, dav1d gave slightly better results with less columns on this particular clip. This might warrant more thorough investigation in the future.


Also, RE: Elecard clips:
they use tile columns (5 for the 720p clips, 10 for the HD clips), so that's why the player used more than one core on those

[Mr_Khyron]

ffmpeg -hide_banner -t 60 -c:v libdav1d -threads 16 -tilethreads 4 -i Stream2_AV1_4K_22.7mbps.webm -benchmark -f null -
[libdav1d @ 000001ec27984180] libdav1d bd747b1
Input #0, matroska,webm, from 'Stream2_AV1_4K_22.7mbps.webm':
Metadata:
encoder : libwebm-0.2.1.0
Duration: 00:02:24.12, start: 0.000000, bitrate: 22728 kb/s
Stream #0:0(eng): Video: av1 (Main), yuv420p(tv), 3840x2160, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 1k tbc (default)
[libdav1d @ 000001ec27a66b80] libdav1d bd747b1
Stream mapping:
Stream #0:0 -> #0:0 (av1 (libdav1d) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf58.22.100
Stream #0:0(eng): Video: wrapped_avframe, yuv420p, 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc (default)
Metadata:
encoder : Lavc58.39.100 wrapped_avframe
frame= 1500 fps= 77 q=-0.0 Lsize=N/A time=00:01:00.00 bitrate=N/A speed=3.09x
video:785kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=228.359s stime=38.609s rtime=19.687s
bench: maxrss=2776212kB
I tried bencmarking with ffmpeg 4.2
from 16fps with libaom to 77fps with Dav1d

[Clare]

What does your command line look like? So far I've been unable to make row-mt work myself

My tries so far:
this one generates invalid bitstream:
../../bin8/aomenc --frame-parallel=0 --tile-columns=2 --tile-rows=2 --row-mt=1 --threads=4 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --end-usage=q --cq-level=40 --test-decode=fatal -o test.av1.cq40.webm orig.i420.y4m
Pass 1/2 frame 480/481 92352B 1539b/f 36899b/s 17849 ms (26.89 fps)
Pass 2/2 frame 19/0 0B 17871 ms 1.06 fps [ETA unknown] 2423FFailed to decode frame 2 in stream 0: Corrupt frame detected
Failed to decode tile data

This one works but uses only 12-13% (one core) of my 4c/8t CPU:
../../bin8/aomenc --frame-parallel=0 --tile-columns=2 --tile-rows=2 --row-mt=1 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --end-usage=q --cq-level=40 --test-decode=fatal -o test.av1.cq40.webm orig.i420.y4m
Pass 1/2 frame 480/481 92352B 1539b/f 36899b/s 18130 ms (26.47 fps)
Pass 2/2 frame 16/0 0B 18152 ms 52.88 fpm [ETA unknown]

aomenc -v --threads=8 --cpu-used=4 --row-mt=1 --lag-in-frames=25 --auto-alt-ref=1--passes=2 --pass=2 --bit-depth=10 --input-bit-depth=10 --end-usage=q --cq-level=28 -o Chimera_DCI4k2398p_HDR_P3PQ.ivf Chimera_DCI4k2398p_HDR_P3PQ.y4m