Alliance for Open Media codecs

[NikosD]

Originally Posted by utack

dav1d is doing well
http://www.jbkempf.com/blog/post/201...-first-release

Dav1d is very fast indeed and although is optimized for AVX2, RyZen manages to be a lot faster than Haswell, albeit Haswell has twice as fast AVX2 implementation.

Scaling to more threads and better hyperthreading implementation along with better clocks (?) for the specific SKUs, probably gave RyZen the clear lead.

[mandarinka]

The Haswell chips they use for testing is a mobile 4C/8T quadcore which probably runs with low clocks (probably some macbook, so...) and the other is a 4C/4T lower-price desktop SKU which is why it will have lower performance than Ryzen. BTW that Ryzen is a hexacore 6C/12T anyway (yay for AMD!).

[littleD]

Wonder how they ran six/eight thread benchmark on 4core/4 thread cpu. If they did, that means decoder has internal switch for thread count. And whats more, single core is underutilized since more CPU threads gives more performance. And since benchmark on 6 core zen gives better results than on 4 thread haswell means AOM decoder they compare to, is highly single threaded. Both decoders have still room to improve anyway.
And. If they compare speed on 12 thread zen this means they compare threading. Global Comparison benchmark shows it.

[utack]

I encoded the full 4096x1714 4K version of Tears of Steel with libaom.
Bitrate of the final file is about 3.5mbit/s, and quality is definitely on a scale of at least "very good".
Have fun looking what aom can do with that little bitrate, or at benchmarking:
https://drive.google.com/drive/folde...uL?usp=sharing

[benwaggoner]

Originally Posted by utack

I encoded the full 4096x1714 4K version of Tears of Steel with libaom.
Bitrate of the final file is about 3.5mbit/s, and quality is definitely on a scale of at least "very good".
Have fun looking what aom can do with that little bitrate, or at benchmarking:
https://drive.google.com/drive/folde...uL?usp=sharing

Wow, what was the encoding time like?

Can you share the command line you used?

[easyfab]

@utack

with my AMD 2700x and libdav1d : 98 fps.

frame=17620 fps= 98 q=-0.0 Lsize=N/A time=00:12:14.16 bitrate=N/A speed=4.09x
video:9223kB audio:412879kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=1003.859s stime=182.547s rtime=179.705s
bench: maxrss=2521828kB

Did you encode with some tiles ? because It only use 40-50% of the CPU.
You should, it encode faster ( use more threads ) and decode also faster .

[SmilingWolf]

Originally Posted by easyfab

Did you encode with some tiles ? because It only use 40-50% of the CPU.
You should, it encode faster ( use more threads ) and decode also faster .

He used row-mt and no tiles. At the moment trying to use both makes aomenc sputter invalid bitstreams.
row-mt can maximise CPU usage at encode time, but as you said the lack of tiles reduces playback performance

[utack]

Originally Posted by benwaggoner

Wow, what was the encoding time like?

A little over 3 days

Originally Posted by benwaggoner

Can you share the command line you used?

Originally Posted by SmilingWolf

He used row-mt and no tiles.

It is in the google drive folder
xz -dc tearsofsteel-4k.y4m.xz | aomenc --cpu-used=4 --row-mt=1 --threads=8 --kf-max-dist=250 --bias-pct=75 --webm -o sk.webm --end-usage=q --aq-mode=1 --cq-level=44 --codec=av1 --passes=2 --pass=2 --fpf=/tmp/fpf -

Originally Posted by SmilingWolf

At the moment trying to use both makes aomenc sputter invalid bitstreams.

It seems to do so in the outro, aom craps out at frame 16xxx and I reported it:
https://bugs.chromium.org/p/aomedia/...detail?id=2262

Originally Posted by SmilingWolf

row-mt can maximise CPU usage at encode time, but as you said the lack of tiles reduces playback performance

Using dav1d for playback with frame parallel decoding works great, and also does not crash when it reaches the "corrupt" frame

[easyfab]

My try with the first 1500 frames @1000kb/s with row-mt + tiles

My 2 pass command line :

7z.exe" x "ToS_1920x800_xdither.7z" -so | aomenc.exe --cpu-used=4 --row-mt=1 --threads=16 --tile-columns=4 --tile-rows=2 --kf-max-dist=250 --bias-pct=75 --webm -o tos.webm --target-bitrate=1000 --codec=av1 --passes=2 --pass=2 --fpf=fpf --limit=1500 -
Pass 2/2 frame 1500/1481 8290530B 2633147 ms 34.18 fpm [ETA unknown]
Pass 2/2 frame 1500/1500 8314991B 44346b/f 1064304b/s 2656175 ms (0.56 fps)

And the result file : https://www.sendspace.com/file/dcf6ii

It seems to decode fine for me.

[SmilingWolf]

Originally Posted by utack

Using dav1d for playback with frame parallel decoding works great, and also does not crash when it reaches the "corrupt" frame

Still, using dav1d and having tiles makes a difference between 30-50% faster decoding on my system using Elecard's Holi Festival 4K clip (tested with ffmpeg, latest libdav1d, -tilethreads 1/2/4).
No reason to give that up IMO

BTW, just to be clear, using row-mt does NOT automatically introduce tiling. Using AOMAnalyzer to take a look at the clip confirms that every frame is just one big tile. There are no columns nor rows

@easyfab:
That's interesting, that it decodes properly. It used to croak in the first couple frames for me (http://forum.doom9.org/showthread.ph...31#post1856831)
Maybe it has been fixed and it flew under my radar. Guess I'll check now
EDIT: Holysmoly you're right, mixing tiles, threads and row-mt together has been fixed!

[easyfab]

for me ( 16 threads cpu ) without tiles, row-mt alone is more than 2x slower ( only use 4/6 threads / cpu usage 10-20 % ) less than 20 fpm.
with row-mt + tiles it use all threads ( cpu usage 50-60% ) and give 34 fpm on TOS 1500 first frames . I'm ok to loose a bit quality with tiles to gain 2x speed.

[SmilingWolf]

We share the same opinion. The tradeoffs are vastly in favour of tiling

[julius666]

Originally Posted by easyfab

My try with the first 1500 frames @1000kb/s with row-mt + tiles

My 2 pass command line :

7z.exe" x "ToS_1920x800_xdither.7z" -so | aomenc.exe --cpu-used=4 --row-mt=1 --threads=16 --tile-columns=4 --tile-rows=2 --kf-max-dist=250 --bias-pct=75 --webm -o tos.webm --target-bitrate=1000 --codec=av1 --passes=2 --pass=2 --fpf=fpf --limit=1500 -
Pass 2/2 frame 1500/1481 8290530B 2633147 ms 34.18 fpm [ETA unknown]
Pass 2/2 frame 1500/1500 8314991B 44346b/f 1064304b/s 2656175 ms (0.56 fps)

And the result file : https://www.sendspace.com/file/dcf6ii

It seems to decode fine for me.

Wow, this looks incredibly good! And it plays smoothly on my old Thinkpad X230, which is actually the worst (AV1-capable) HW I have access to atm.
This is almost unbelievable given the codec's infancy.

[Nintendo Maniac 64]

Originally Posted by julius666

it plays smoothly on my old Thinkpad X230

Are you playing this back with dav1d or libaom?

[julius666]

Originally Posted by Nintendo Maniac 64

Are you playing this back with dav1d or libaom?

I tried it with the latest mpv on Arch Linux. It uses libaom by default:

[vd] Codec list:
[vd]     libaom-av1 (av1) - libaom AV1
[vd] Opening decoder libaom-av1
[vd] No hardware decoding requested.
[vd] Using software decoding.
[vd] Detected 4 logical cores.
[vd] Requesting 5 threads for decoding.
[ffmpeg/video] libaom-av1: 1.0.0
[vd] Selected codec: libaom-av1 (libaom AV1)

[mandarinka]

I see nobody talking about it here, yet, but it seems Google or some other members decided to "unfreeze" the bitstream, there will by the look of it be an incompatible AV1.1.0 revision.
Supposedly it's mostly driven by requests of hardware implementers which wanted to restrict the format a bit in some places.

It looks like hardware might only implement AV1.1.0 mostly, not AV1.0? (This is a bit speculative, maybe there will be exceptions).

Current AV1.0 decoders will support the more restricted AV1.1.0 streams but new (hardware) decoders targetting AV1.1.0 won't be compatible with AV1.0 video. Rather messy, IMHO they should have just delayed the codec finalization and do it properly the first time around, instead of this, but I guess politics prevailed.

There's remarkable silence about it, but I guess it's not the best news so they don't want to brag about it too much until it's final (not sure if the decision is set in stone already).

[utack]

Originally Posted by mandarinka

Supposedly it's mostly driven by requests of hardware implementers which wanted to restrict the format a bit in some places.
.

Even worse that it seems to be about tiles.
These should have never been implemented in a new codec the first place, it is just a lazy workaround because libaom sucks at frame parallel encoding and decoding.
rav1e and dav1d won't need them

[SmilingWolf]

Ronald Bultje commented on frame parallelism being a bad thing for VP9, so not much of a surprise it was turned off by default in AV1/libaom
Tiles help with decoding, do I have to re-link my tests every time this stuff is brought up?

The proposed changes to tile width management only had to be set in stone, all I know is that they have been the de-facto standard in the libaom codebase since at least this summer, when I first began encoding 1080p clips.
EDIT: looks like I was thinking about something else in these regards, nevermind

And since we're talking about this, why at least not link the to the source of the news?
https://www.reddit.com/r/AV1/comment...lude_breaking/

[nevcairiel]

Originally Posted by SmilingWolf

Tiles help with decoding, do I have to re-link my tests every time this stuff is brought up?

That may be true, but you can make the same argument for a lot of things. That alone does not necessarily justify a feature thats generally rather annoying, and generally considered a remnant of the past.

In any case, at the current point in time, AV 1.0 bitstreams will just eventually vanish, and AV 1.1 will be the actual standard people use. Outside of tech demos, AV1 is generally unused still.
And with knowing this change is here, noone is going to adopt it now until this is cleared up and "final" again.

[mandarinka]

I can't tell how correct it is, but this was an interesting read: https://codecs.multimedia.cx/2018/12...cal-about-av1/
Author is a former libav/ffmpeg developer if you don't remember his name.