Alliance for Open Media codecs

[dapperdan]

I couldn't find any x264 tune ssim encodes, but I did find some x265 tune PSNR that show basically the same pattern. Tuning for PSNR at the expense of Fast SSIM, while other metrics don't really change.

The major difference is that the PSNR tuning seems to help with CB and Cr for x265, not just the Y channel.

Fascinating. So it appears x264 and x265 have their own version of VMAF which is just the combination of PSNR and FastSSIM metrics.

[LigH]

Originally Posted by dapperdan

So it appears x264 and x265 have their own version of VMAF which is just the combination of PSNR and FastSSIM metrics.

That sounds confusing to me. PSNR and SSIM are mainly frame-to-frame metrics, whereas VFAM should also consider motion, thus have a temporal window.

The main metric used in x264 and x265 is the "rate factor", if I'm not completely wrong...

[dapperdan]

I just meant in the sense that VMAF is a fusion of other metrics, including PSNR.

VMAF use fancy statistics to combine them all based how they agreed with subjective measurements but it looks like x264 just combined Fast SSIM and PSNR when they didn't move in opposite directions.

[mzso]

Will SVT-AV1 and rav1e be added to ffmpeg as encoder libraries?
Or is that not possible because of licensing?

[sneaker_ger]

AFAIK there are no licensing issues. Both rav1e and SVT-AV1 have open licences (BSD 2-Clause and BSD+patent). Some patches already seem to exist but it seems aren't fully ready yet (i.e. developers still need to do some work or want to wait a bit more for the respective projects to mature).

[quietvoid]

rav1e is still missing a stable C API for ffmpeg, IIRC.

[TD-Linux]

Originally Posted by mzso

Will SVT-AV1 and rav1e be added to ffmpeg as encoder libraries?
Or is that not possible because of licensing?

For rav1e we are waiting on releasing 0.1. We're down to one blocker bug, so it should be out soon: https://github.com/xiph/rav1e/issues/1636

[TD-Linux]

Originally Posted by dapperdan

Fascinating. So it appears x264 and x265 have their own version of VMAF which is just the combination of PSNR and FastSSIM metrics.

Unfortunately it's impossible to use VMAF directly for RDO because an encoder has to evaluate distortion on very small blocks, down to 8x8 pixels. So the best you can do is come up with something that approximates it.

[LigH]

Just that you mention rav1e ... this week they broke compilation for the x86 target, possibly in an attempt to add assembler optimizations. The developers seem to lack of a cross-compilation environment for x86 (where I am not sure if that specifically means 32 bit code) for automated testing. I discovered that issue during my usual sporadic runs of the media-autobuild suite.

[hajj_3]

dav1d 0.5.0 'Asiatic Cheetah'

The fast and small AV1 decoder, codename 'Asiatic Cheetah'. It supports all the AV1 features and all bitdepths.

0.5.0 brings large improvements in speed on SSSE3 CPU (up to 40% speedup), new speed improvements on AVX-2 (for 4-7%) and ARM64 (up to 10%) and ARM32. It introduces some VSX, SSE2 and SSE4 optimizations.
0.5.0 fixes some minor issues, can export ITU T.35 metadata and improves the player example.

[Kirakishou]

Hi guys. I’m not good at English, sorry for that. Got file [Xrip][Nekopara][OVA_Extra][GB][1080P][AV1_10bit].mp4 from nyaa. Last and several dozen previous build of mpv playback it choppy. x86 and x64 version of mpv.
But mpc-hc 1.8.4.x86 playback it smooth. Only x86 build of mpc-hc 1.8.4, x64 also playback it choppy. And next builds of mpc-hc also playback it choppy. As far as I understand there were some changes in LAV Filters which led to the worst result. Maybe this information will be useful to someone.

[sneaker_ger]

MPC-HC 1.8.4 (LAV v0.73.1) uses libaom for AV1 decoding, 1.8.5 (LAV v0.74) uses dav1d. dav1d isn't optimized for 10 bit AV1 yet and it seems for this particular case and your hardware that libaom is faster (for 8 bit dav1d is much faster). Probably same problem for mpv. As dav1d matures this problem will be solved.

https://code.videolan.org/videolan/dav1d/issues/216
https://code.videolan.org/videolan/dav1d/issues/78

[benwaggoner]

Originally Posted by TD-Linux

Unfortunately it's impossible to use VMAF directly for RDO because an encoder has to evaluate distortion on very small blocks, down to 8x8 pixels. So the best you can do is come up with something that approximates it.

And VMAF isn't THAT great a metric. Many encoders will do some more sophisticated things internally. particularly around maintaining temporal coherence. VMAF does at least include a lightweight interframe comparison metric, but it doesn't do anything new to figure out how the variation of quality of individual frames impacts the overall viewer experience.

[benwaggoner]

Originally Posted by dapperdan

I couldn't find any x264 tune ssim encodes, but I did find some x265 tune PSNR that show basically the same pattern. Tuning for PSNR at the expense of Fast SSIM, while other metrics don't really change.

The major difference is that the PSNR tuning seems to help with CB and Cr for x265, not just the Y channel.

Well, "help" in the sense that PSNR metrics would improve. --tune psnr reduces the subjective quality of the content at a given bitrate BY optimizing only for improved PSNR scores.

[NikosD]

First commercial AV1 hardware decoder, claimed by Chips&Media and it's called Wave510A.

Can handle 4K60fps AV1 main profile using one core@500MHz and expands to dual core@1000MHz for 8K60fps.
Supports AV1 8bit/10bit up to 8Kx8K and up to 50Mbps

More here:
https://www.anandtech.com/show/15003...av1-decoder-ip

and here:
https://en.chipsnmedia.com/page/product_view/5919

[soresu]

Originally Posted by NikosD

Can handle 4K60fps AV1 main profile using one core@500MHz and expands to dual core@1000MHz for 8K60fps.

I wonder what the power draw for those configurations are.

[benwaggoner]

Originally Posted by NikosD

First commercial AV1 hardware decoder, claimed by Chips&Media and it's called Wave510A.

Can handle 4K60fps AV1 main profile using one core@500MHz and expands to dual core@1000MHz for 8K60fps.
Supports AV1 8bit/10bit up to 8Kx8K and up to 50Mbps

More here:
https://www.anandtech.com/show/15003...av1-decoder-ip

and here:
https://en.chipsnmedia.com/page/product_view/5919

Interesting!

I wish there was some hint on how many transistors this takes, so we could estimate the silicon cost of adding it to a chip. It could be bigger than normal as this is JUST an AV1 decoder, without sharing anything with H.264/HEVC/VP9/etcetera decoders. In a more mature implementation, one would expect an integrated decoder which supports multiple bitstreams. That takes a lot fewer transistors in total that having all those as independent decoders.

400/500 MHz is pretty reasonable, as it can run in a processor in a relatively lower power state for better battery life on long-term content.

I am not a deep SoC guy, so take all above with an appropriately scaled grain of salt.

I'm looking forward to seeing an announcement for the first device with HW AV1 decode. AV1 isn't relevant for premium content until a material portion of customers have devices with HW decoders with integrated HW DRM.

So much hinges on whether the additive cost of AV1 decode will be low enough to be a default in lower cost SoCs in the next year or two. I'm kinda startled how murky that still is as we approach 2020.

[birdie]

Considering the timeline it looks like SnapDragon 865 (or whatever comes after SnapDragon 855) won't support AV1 HW decoding which is a huge bummer.

[soresu]

Originally Posted by birdie

Considering the timeline it looks like SnapDragon 865 (or whatever comes after SnapDragon 855) won't support AV1 HW decoding which is a huge bummer.

Samsung's next chip doesn't have AV1 and they have actually joined AOM, so Qualcomm's conspicuous absence from AOM makes their support for AV1 dubious at best.

[hajj_3]

Leaked Amlogic roadmap showing the Amlogic S905X4, S908X and S805X2 chips that will support AV1. The S905X4 looks to be shipping within the next few months: