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.

 

Go Back   Doom9's Forum > Video Encoding > VP9 and AV1

Reply
 
Thread Tools Search this Thread Display Modes
Old 14th April 2019, 18:11   #1581  |  Link
IgorC
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
IgorC is offline   Reply With Quote
Old 14th April 2019, 18:43   #1582  |  Link
user1085
Registered User
 
Join Date: Apr 2018
Posts: 22
Quote:
Originally Posted by soresu View Post
Seems that rav1e is prioritising chunked/segment encoding early on to maximise parallelism, they just opened a new project list to target specific tasks. Link here.
How does chunked/segment encoding work?
user1085 is offline   Reply With Quote
Old 14th April 2019, 22:11   #1583  |  Link
soresu
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.
soresu is offline   Reply With Quote
Old 15th April 2019, 16:58   #1584  |  Link
Dyomich
Codec Analysis Expert
 
Join Date: Feb 2006
Location: Moscow
Posts: 37
Quote:
Originally Posted by dapperdan View Post
MSU HEVC/AV1/VP9 encoding test results:


http://compression.ru/video/codec_comparison/hevc_2018/
dapperdan, thank you for the link. Here is more information about the results:

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:
  1. AV1
  2. VP9, x265 and sz265
  3. sz264 and x264
On the speed-quality chart there are four Pareto-optimal participants: AV1, VP9, x264, and SIF Encoder:



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).
Dyomich is offline   Reply With Quote
Old 16th April 2019, 18:57   #1585  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
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
BD rates for 1080p:
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
Encoders:
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.
SmilingWolf is offline   Reply With Quote
Old 16th April 2019, 20:52   #1586  |  Link
Nintendo Maniac 64
Registered User
 
Nintendo Maniac 64's Avatar
 
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 447
Quote:
Originally Posted by SmilingWolf View Post
Status report!
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       
Nintendo Maniac 64 is offline   Reply With Quote
Old 16th April 2019, 23:02   #1587  |  Link
singhkays
Registered User
 
Join Date: Aug 2018
Posts: 18
Quote:
Originally Posted by SmilingWolf View Post
Status report!
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:
enable_cdef, enable_global_motion, and intrabc
https://git.ffmpeg.org/gitweb/ffmpeg...99c7c89526d1d6
singhkays is offline   Reply With Quote
Old 17th April 2019, 18:00   #1588  |  Link
marcomsousa
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/
__________________
AV1 win64 VS2019 builds
Last build here
marcomsousa is offline   Reply With Quote
Old 17th April 2019, 18:15   #1589  |  Link
Nintendo Maniac 64
Registered User
 
Nintendo Maniac 64's Avatar
 
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       
Nintendo Maniac 64 is offline   Reply With Quote
Old 17th April 2019, 18:17   #1590  |  Link
marcomsousa
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/
__________________
AV1 win64 VS2019 builds
Last build here
marcomsousa is offline   Reply With Quote
Old 17th April 2019, 20:54   #1591  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 95
Quote:
Originally Posted by Nintendo Maniac 64 View Post
Any comparisons for lossless AVIF?
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:
Originally Posted by singhkays View Post
Do you know how these new commandline options in ffmpeg affect quality/speed for AV1?
https://git.ffmpeg.org/gitweb/ffmpeg...99c7c89526d1d6
I never tested any of that flags with the exception of frame_parallel, which I always set to 0 (disabled).
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.
SmilingWolf is offline   Reply With Quote
Old 18th April 2019, 00:06   #1592  |  Link
Nintendo Maniac 64
Registered User
 
Nintendo Maniac 64's Avatar
 
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 447
Quote:
Originally Posted by SmilingWolf View Post
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/
a30.png
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.


Quote:
Originally Posted by SmilingWolf View Post
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)
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       
Nintendo Maniac 64 is offline   Reply With Quote
Old 18th April 2019, 00:09   #1593  |  Link
singhkays
Registered User
 
Join Date: Aug 2018
Posts: 18
Quote:
Originally Posted by SmilingWolf View Post

I never tested any of that flags with the exception of frame_parallel, which I always set to 0 (disabled).
I'd imagine one would want to leave the CDEF filter on, but I have hardly any idea what most of the others do.
Actually, after I posted I found more info in the AV1 paper here https://jmvalin.ca/papers/AV1_tools.pdf

Quote:
Intra Block Copy: AV1 allows its intra coder to refer backto previously reconstructed blocks in the same frame, in a mannersimilar to how inter coder refers to blocks from previous frames.It can be very beneficial for screen content videos which typicallycontain repeated textures, patterns and characters in the same frame.Specifically, a new prediction mode named IntraBC is introduced, andwill copy a reconstructed block in the current frame as prediction. Thelocation of the reference block is specified by a displacement vector ina way similar to motion vector compression in motion compensation.Displacement vectors are in whole pixels for the luma plane, andmay refer to half-pel positions on corresponding chrominance planes,where bilinear filtering is applied for sub-pel interpolation.

Warped Motion Compensation: Warped motion models areexplored in AV1 by enabling two affine prediction modes, globaland local warped motion compensation [10]. The global motiontool is meant for handling camera motions, and allows conveyingmotion models explicitly at the frame level for the motion betweena current frame and any of its reference

Constrained Directional Enhancement Filter (CDEF): CDEFis a detail-preserving deringing filter designed to be applied afterdeblocking that works by estimating edge directions followed byapplying a non-separable non-linear low-pass directional filter of size5×5 with 12 non-zero weights [14]. To avoid extra signaling, thedecoder computes the direction per 8×8 block using a normative fastsearch algorithm that minimizes the quadratic error from a perfectdirectional pattern
I tested out these options with the following CLI however, I saw no change in the average bitrate of the output file, speed of encoding or any difference in VMAF scores of different files.

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
singhkays is offline   Reply With Quote
Old 18th April 2019, 02:33   #1594  |  Link
soresu
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.
soresu is offline   Reply With Quote
Old 18th April 2019, 15:24   #1595  |  Link
marcomsousa
Registered User
 
Join Date: Jul 2018
Posts: 80
Quote:
Originally Posted by soresu View Post
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.
Netflix choose SVT-AV1 because of architecture, language and how scalable it is.

"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
__________________
AV1 win64 VS2019 builds
Last build here

Last edited by marcomsousa; 18th April 2019 at 15:46.
marcomsousa is offline   Reply With Quote
Old 18th April 2019, 17:03   #1596  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 95
Quote:
Originally Posted by soresu View Post
Wasnt rav1e supposed to have passed x264 quality some time ago?
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.
SmilingWolf is offline   Reply With Quote
Old 18th April 2019, 18:17   #1597  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
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.
mandarinka is offline   Reply With Quote
Old 18th April 2019, 18:30   #1598  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by soresu View Post
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.
This isn't too bad if you use >>10 second chunks. Not how YouTube does it, but more common common for premium content

Quote:
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.
This is the bigger problem. Beyond scene changes, ensuring VBV compliance at splice points requires either very conservative rate control near splice points, or risk out of comformance spikes. This isn't a huge deal with SW decoders (although a bitrate spike will likely result in dropped frames in a complex high motion scene where dropped frames are most visible). But it can be a serious issue with HW decoders; either they can't handle existing content, or the die size and cost has to increase to handle out-of-spec streams. This was a big deal ~10 years ago when x264 didn't enforce levels requirement, and a 1080p flagged as Level 4.0 could still have 9 reference frames and break decoders.

Quote:
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?
Best-case, latency increases by max chunk duration. So you get into quality/latency tradeoffs. Definitely not feasible for videoconferencing!

Note that "real" encoders get around these issues by using frame-level parallelism. x265 can saturate a good number of cores at 1080p.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is online now   Reply With Quote
Old 18th April 2019, 18:33   #1599  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by marcomsousa View Post
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
VMAF isn't a still image metric. Has anyone run a correlation for VMAF against subjective testing for still images? If not, I wouldn't trust it as a metric for this use case. Nor PSNR or SSIM.

Quote:
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
With PNG in there, wouldn't we be comparing YUV<>RGB?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is online now   Reply With Quote
Old 18th April 2019, 18:45   #1600  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by mandarinka View Post
Nice metrics in those curves are nice, but in reality, is the ability to keep the visual quality good there?
Since libaom's encoding was tuned with VMAF, we'd expect it to have a higher VMAF at any given subjective quality than other encoders that weren't tuned against it. There have been several papers that have shown HEVC or VVC's reference encoders delivering subjectively superior quality than AV1 even when VMAF predicts AV1 will look better.

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:
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.
Right, and VMAF is insensitive to lots of adaptive quant psychovisual optimizations. For example, it doesn't do a good job of picking up on gradients or banding in darker scenes, for example. I'm guessing they didn't have a lot of variations of adaptive quant modes in their test set, so VMAF didn't get trained to distinguish between them.

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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is online now   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:12.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.