Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
14th April 2019, 18:11 | #1581 | Link |
Registered User
Join Date: Apr 2004
Posts: 1,315
|
Xiph update on one year of AV1 (slides from NAB 2019) [PDF]
https://people.xiph.org/~negge/NAB2019.pdf |
14th April 2019, 22:11 | #1583 | Link |
Registered User
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
|
Much like the name suggests, by splitting the file to be encoded by chunks/segments, each being encoded in a separate instance of the encoder, but each also having the lower parallelism of tile or frame based encoding on top of that.
Its more beneficial for systems like servers, or dual socket workstations with large core counts, where the WPP, tile and frame parallel techniques are not enough on their own to saturate all cores with work. Apparently it has its own problems such as memory consumption and chiefly the time taken to initialise each instance. Also the segments would have to be chosen based on detected scene change otherwise you could have some very obvious bitrate changes visible mid shot. I dont think it is suitable for real time encoding, unless you have a significant time delay on transmission to detect scene changes before carving up a new segment to be encoded possibly? Last edited by soresu; 14th April 2019 at 22:13. |
15th April 2019, 16:58 | #1584 | Link | |
Codec Analysis Expert
Join Date: Feb 2006
Location: Moscow
Posts: 37
|
Quote:
MSU received many requests on the results of announced AV1 participation in comparison. AV1 is quickly being developed, but still too slow to participate in our usual fast-universal-ripping use cases. This is why AV1 was included only in this special report (so as in 2017). Download free PDF report: http://compression.ru/video/codec_co...Q_encoders.pdf This part of the comparison usually releases later because of much lower encoding speed than in other use cases (formal limit was 0.005 fps but actually unlimited). According to only quality scores, the places of the competitors are the following:
You can compare the latest results to the results from out similar comparison in 2017, (Important note: in 2017 we used VBR mode for AV1 encoder, and in 2018 constant QP was used, as VBR was several times slower).
__________________
Annual Video Codecs Comparisons by Lomonosov MSU |
|
16th April 2019, 18:57 | #1585 | Link |
I am maddo saientisto!
Join Date: Aug 2018
Posts: 95
|
Status report!
"MSU preceded me" edition 1st edition: https://forum.doom9.org/showthread.p...49#post1852449 2nd edition: https://forum.doom9.org/showthread.p...87#post1857587 3rd edition: https://forum.doom9.org/showthread.p...75#post1860475 Whatever paragraph I don't repeat here can be assumed to be the same as in the aforementioned post First of all: graphs! Click to enlarge Y axis: chosen metric X axis: bits per pixel 720p: 1080p: BD rates for 720p: Code:
Codecs ladder: | x264 relative: x264 -> svtav1 | x264 -> svtav1 RATE (%) DSNR (dB) | RATE (%) DSNR (dB) MSSSIM -3.28672 0.142426 | MSSSIM -3.28672 0.142426 PSNRHVS -4.36439 0.235114 | PSNRHVS -4.36439 0.235114 HVMAF -7.28468 0.186648 | HVMAF -7.28468 0.186648 ----------------------------|----------------------------- svtav1 -> vp9 | x264 -> vp9 RATE (%) DSNR (dB) | RATE (%) DSNR (dB) MSSSIM -14.9778 0.624669 | MSSSIM -21.5937 1.19737 PSNRHVS -17.0162 0.881864 | PSNRHVS -23.6381 1.70941 HVMAF -17.6481 0.768638 | HVMAF -21.7739 2.36707 ----------------------------|----------------------------- vp9 -> x265 | x264 -> x265 RATE (%) DSNR (dB) | RATE (%) DSNR (dB) MSSSIM -5.14321 0.226527 | MSSSIM -25.8745 1.38639 PSNRHVS -8.41874 0.455384 | PSNRHVS -30.4345 2.09471 HVMAF -13.8727 0.673276 | HVMAF -31.395 3.32434 ----------------------------|----------------------------- x265 -> av1 | x264 -> av1 RATE (%) DSNR (dB) | RATE (%) DSNR (dB) MSSSIM -17.7008 0.800381 | MSSSIM -36.613 2.16722 PSNRHVS -14.1648 0.748597 | PSNRHVS -37.5985 2.80939 HVMAF -12.6967 0.474379 | HVMAF -39.7078 2.87016 Code:
Codecs ladder: | x264 relative: x264 -> svtav1 | x264 -> svtav1 RATE (%) DSNR (dB) | RATE (%) DSNR (dB) MSSSIM -2.03138 0.058404 | MSSSIM -2.03138 0.058404 PSNRHVS 3.95915 -0.147954 | PSNRHVS 3.95915 -0.147954 HVMAF -4.05114 -0.0123967 | HVMAF -4.05114 -0.0123967 -----------------------------|------------------------------ svtav1 -> vp9 | x264 -> vp9 RATE (%) DSNR (dB) | RATE (%) DSNR (dB) MSSSIM -29.5206 1.00448 | MSSSIM -33.7275 1.65389 PSNRHVS -32.951 1.40212 | PSNRHVS -33.0678 2.11895 HVMAF -34.7504 1.33459 | HVMAF -33.0663 3.73028 -----------------------------|------------------------------ vp9 -> x265 | x264 -> x265 RATE (%) DSNR (dB) | RATE (%) DSNR (dB) MSSSIM 6.91124 -0.232017 | MSSSIM -30.515 1.24701 PSNRHVS 2.12517 -0.103003 | PSNRHVS -32.954 1.71647 HVMAF -5.87407 0.106315 | HVMAF -35.0935 3.13962 -----------------------------|------------------------------ x265 -> av1 | x264 -> av1 RATE (%) DSNR (dB) | RATE (%) DSNR (dB) MSSSIM -28.0678 0.994389 | MSSSIM -47.6133 2.2674 PSNRHVS -23.2568 0.966762 | PSNRHVS -45.5839 2.73622 HVMAF -24.6825 0.769329 | HVMAF -50.6976 3.39944 x264 157-2935-545de2f x265 3.0-1-ed72af837053 libvpx-vp9 1.8.0-374-gb758ba795 SVT-AV1 0.0.1-525-5a8b857e libaom 1.0.0-1605-g64a2ffb72 Cmdlines: x264 --preset veryslow --tune ssim --crf 16 -o test.x264.crf16.264 orig.i420.y4m x265 --preset veryslow --tune ssim --crf 16 -o test.x265.crf16.hevc orig.i420.y4m vpxenc --codec=vp9 --frame-parallel=0 --tile-columns=1 --auto-alt-ref=6 --good --cpu-used=0 --tune=psnr --passes=2 --threads=2 --end-usage=q --cq-level=20 --test-decode=fatal --ivf -o test.vp9.cq20.ivf orig.i420.y4m SvtAv1EncApp.exe -i orig.i420.yuv -b test.svtav1.cq20.ivf -w 1280 -h 720 -q 20 -enc-mode 3 -fps-num 24000 -fps-denom 1001 -intra-period 23 aomenc --frame-parallel=0 --tile-columns=1 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --threads=2 --row-mt=1 --end-usage=q --cq-level=20 --test-decode=fatal -o test.av1.cq20.webm orig.i420.y4m VMAF: model used: vmaf_v0.6.1, pooling: harmonic_mean Notes: TearsOfSteel720 and TheFifthElement, two clips in the 720p category, have a vertical resolution incompatible with SvtAv1EncApp (not divisible by 8), so they have been excluded from all measurements this time. Next time they will be padded, all the encodes re-made and quality measurements re-taken. Meanwhile, rav1e has got a nasty bug that makes it bloat encodes, which brings up to 25% BD rate regression, so it has been excluded from this edition. I'll try to post an amendment when the above problems have been fixed. This concludes this report. As always, I'm open to any kind of feedback to improve my comparisons and my encodes. |
16th April 2019, 20:52 | #1586 | Link |
Registered User
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 447
|
Good to see you're not dead - you hadn't logged in for nearly 4 months.
Anyway quick question - since dav1d seems to be pretty much the standard go-to AV1 decoder nowadays, I don't suppose you'd be interested in the possibility of more decoder performance tests? Basically I'm thinking how that Presage Flower video clip you had me test is going to have pretty outdated results regarding AV1's relative CPU software decoding requirements seeing as dav1d is like 50% faster even on CPUs that don't support AVX (I've not yet tested it on CPUs without SSE4.1 and/or SSSE3 however).
__________________
____HTPC____ | __Desktop PC__
2.93GHz Xeon x3470 (4c/8t Nehalem) | 4.5GHz 1.24v dual-core Haswell G3258 Radeon HD5870 | Intel iGPU 2x2GB+2x1GB DDR3-1333 | 4x4GB DDR3-1600 |
16th April 2019, 23:02 | #1587 | Link | |
Registered User
Join Date: Aug 2018
Posts: 18
|
Glad to see this! I'm working on a sub-500Kbps comparison myself for AV1/x264/VP9 (this is to replace GIF with the smallest video that'll play natively in a browser)
Do you know how these new commandline options in ffmpeg affect quality/speed for AV1? Quote:
|
|
17th April 2019, 18:00 | #1588 | Link |
Registered User
Join Date: Jul 2018
Posts: 80
|
1) Comparision of libaom, SVT-AV1 and rav1e for still-image coding on subset1 from derf's collection. JPEG files are also encoded with libjpeg for the reference.
https://github.com/Kagami/av1-bench 2) go-avif comes with handy CLI utility avif. It supports encoding of JPEG and PNG files to AVIF Static 64-bit builds for Windows, macOS and Linux are available at releases page. https://github.com/Kagami/go-avif 3) AVIF (AV1 Still Image File Format) polyfill for the browser https://github.com/Kagami/avif.js demo https://kagami.github.io/avif.js/ |
17th April 2019, 18:15 | #1589 | Link |
Registered User
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 447
|
Any comparisons for lossless AVIF?
__________________
____HTPC____ | __Desktop PC__
2.93GHz Xeon x3470 (4c/8t Nehalem) | 4.5GHz 1.24v dual-core Haswell G3258 Radeon HD5870 | Intel iGPU 2x2GB+2x1GB DDR3-1333 | 4x4GB DDR3-1600 |
17th April 2019, 18:17 | #1590 | Link |
Registered User
Join Date: Jul 2018
Posts: 80
|
Chrome will use dav1d by default for decoding.
Chromium 74 [1] (week of 2019-Apr-23) https://chromium.googlesource.com/ch...abd54d5%5E%21/ |
17th April 2019, 20:54 | #1591 | Link | |
I am maddo saientisto!
Join Date: Aug 2018
Posts: 95
|
I've got you covered... somewhat. My comparison was made with a mix of CG wallpapers and Pixiv anime fanart. Here: https://docs.google.com/spreadsheets...2xX5AWagKn1ak/
The numbers are 3 months old but I don't think they have moved too much. Yup, not ded, but busy Unless dav1d has started adding 10bit asm or has made big improvements in the multithreading department I don't think there'll be much to see w.r.t. improvements against my Presage Flower encode (10bit YUV420P), but you're very welcome to try and prove me wrong of course, benchmarks are always good! Quote:
I'd imagine one would want to leave the CDEF filter on, but I have hardly any idea what most of the others do. Last edited by SmilingWolf; 17th April 2019 at 21:20. |
|
18th April 2019, 00:06 | #1592 | Link | |
Registered User
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 447
|
Quote:
a_cs03.png Gee that file name formatting sure looks familiar... *double checks the contents of "bgimage.xp3"* yup, knew it. Also it's kind of neat that one can access the source pixiv artwork's page with nothing more than just the file name since it's the same set of numbers used in both the file name and in a given artwork's web page URL. Oh derp, I completely forgot about it being 10bit. However, dav1d apparently does scale across multiple CPU threads extremely well.
__________________
____HTPC____ | __Desktop PC__
2.93GHz Xeon x3470 (4c/8t Nehalem) | 4.5GHz 1.24v dual-core Haswell G3258 Radeon HD5870 | Intel iGPU 2x2GB+2x1GB DDR3-1333 | 4x4GB DDR3-1600 |
|
18th April 2019, 00:09 | #1593 | Link | ||
Registered User
Join Date: Aug 2018
Posts: 18
|
Quote:
Quote:
Code:
./ffmpeg -i scene3.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -row-mt 1 -threads 8 -pass 1 -f mp4 -y /dev/null && ./ffmpeg -i scene3.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -row-mt 1 -threads 8 -pass 2 -hide_banner ./av1/av1_200k-none.mp4 ./ffmpeg -i scene3.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-cdef 1 -enable-global-motion 1 -enable-intrabc 1 -row-mt 1 -threads 8 -pass 1 -f mp4 -y /dev/null && ./ffmpeg -i scene3.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-cdef 1 -enable-global-motion 1 -enable-intrabc 1 -row-mt 1 -threads 8 -pass 2 -hide_banner ./av1/av1_200k-all.mp4 ./ffmpeg -i scene3.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-cdef 1 -row-mt 1 -threads 8 -pass 1 -f mp4 -y /dev/null && ./ffmpeg -i scene3.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-cdef 1 -row-mt 1 -threads 8 -pass 2 -hide_banner ./av1/av1_200k-cdef-only.mp4 ./ffmpeg -i scene3.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-global-motion 1 -row-mt 1 -threads 8 -pass 1 -f mp4 -y /dev/null && ./ffmpeg -i scene3.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-global-motion 1 -row-mt 1 -threads 8 -pass 2 -hide_banner ./av1/av1_200k-globmotion-only.mp4 ./ffmpeg -i scene3.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-intrabc 1 -row-mt 1 -threads 8 -pass 1 -f mp4 -y /dev/null && ./ffmpeg -i scene3.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-intrabc 1 -row-mt 1 -threads 8 -pass 2 -hide_banner ./av1/av1_200k-intrabc-only.mp4 |
||
18th April 2019, 02:33 | #1594 | Link |
Registered User
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
|
Wow, I suspected SVT-AV1 to have lower quality, but not so bad as this - it barely seems to pass x264 and is worse at some resolutions and bitrates.
Wasnt rav1e supposed to have passed x264 quality some time ago? If these graphs match to VMAF too, I cant see why Netflix would announce support for SVT-AV1 when they already have a performant VP9 solution which presumably at least matches libvpx quality, if not better with EVE-VP9. |
18th April 2019, 15:24 | #1595 | Link | |
Registered User
Join Date: Jul 2018
Posts: 80
|
Quote:
"SVT-AV1 uses parallelization at several stages of the encoding process." "However, rav1e is written in Rust programming language, whereas an encoder written in C has a much broader base of potential developers." The quality is a matter of time. Introducing SVT-AV1: a scalable open-source AV1 framework by Netflix https://medium.com/netflix-techblog/...k-c726cce3103a Last edited by marcomsousa; 18th April 2019 at 15:46. |
|
18th April 2019, 17:03 | #1596 | Link |
I am maddo saientisto!
Join Date: Aug 2018
Posts: 95
|
Oh it absolutely did, as far back as 4 months ago already.
Unfortunately there's a bug (#1081) that is currently badly damaging the BD rates, so no comparison from me until that's fixed. One of the PRs (#1215) seems promising in that regards, after some ironing out it should bring the encoding efficiency back on track. |
18th April 2019, 18:17 | #1597 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
Nice metrics in those curves are nice, but in reality, is the ability to keep the visual quality good there?
That said, I don't think it's even fair to expect miracles until there's adaptive quantization. I don't think there has been a good encoder without adaptive quantization yet (and psyrdo too possibly?) so if we're just assuming Rav1e won't need it, that might be kind of unwarranted. |
18th April 2019, 18:30 | #1598 | Link | |||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
Quote:
Quote:
Note that "real" encoders get around these issues by using frame-level parallelism. x265 can saturate a good number of cores at 1080p. |
|||
18th April 2019, 18:33 | #1599 | Link | ||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
Quote:
|
||
18th April 2019, 18:45 | #1600 | Link | ||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
VMAF is our least-bad objective metric ever, and keeps on getting better. But like any ML system, it is fundamentally a statistics-driven system that tries to give the same answer given similar data as the data-answer pairs it was trained on. So VMAF isn't going to be great at discriminating between AV1 and VVC artifacts without a lot of double-blind subjective ratings of AV1 and VVC artifacts. This isn't a bug in VMAF; it's just the way that systems like that work. Quote:
And even with HVMAF, keyframe strobing will be hard to notice as it is just one bad frame per GOP. I don't know how many IDR frames VMAF was tested against; lots of codec tests wind up being a single long GOP, or scene-adaptive IDR only. So cases where a shot is longer than the max GOP duration may not have been sampled much. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|