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 30th November 2019, 02:00   #1961  |  Link
Adonisds
Registered User
 
Join Date: Sep 2018
Posts: 14
Quote:
Originally Posted by Adonisds View Post
No, I'm assuming SDR is done with 8 bits and HDR with 10. Why do you assume people would use 10 bit for SDR? Youtube currently uses 8 bits for SDR AV1.

I'm also assuming that these decoders advertised as 4k60 capable are only capable of that in 8 bits. I would a bit surprised if that was not the case.

So possibly they are not really ready for HDR content. And since AV1 is a codec for a time in the future when HDR could be common, that is dissapointing. I would think that since Netflix is pushing hard for it, at least 10bit 4k24 would be supported.
Looks like I'm wrong in my second assumption, thankfully. At least the WAVE510A decoder does decode 10 bit 4k60

Edit: looks like I also misunderstood what Blue_MiSfit said. He just said decoders should do 10bit, not SDR videos. Well, that was all pointless. But let my mistakes all be public. I'm just gonna go hide in shame.

Last edited by Adonisds; 30th November 2019 at 02:03.
Adonisds is offline   Reply With Quote
Old 1st December 2019, 00:05   #1962  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
All good

10 bit SDR is totally valid, especially in the premium case where source content is at least 10 bit 4:2:2. It's unfortunate that the first wave of hardware HEVC decoders were 8 bit, else all HEVC would be 10 bit today.

We only encode 10 bit HEVC on the service I work on (SDR, HDR10, and Dolby Vision)
Blue_MiSfit is offline   Reply With Quote
Old 1st December 2019, 11:22   #1963  |  Link
NikosD
Registered User
 
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
Anandtech agrees that MediaTek's Dimensity 1000 could be the first consumer mobile SoC to support hardware-decoding of AV1
Quote:
Media encoding capabilities fall in at 4K60, but here the biggest surprise lies in the chipset's support for AV1 video decoding.
As far as we're aware, this make the D1000 the very first consumer mobile SoC to support the format, which is a great leap forward in terms of future-proofing the devices which are based on the new chip.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1)
HEVC decoding benchmarks
H.264 DXVA Benchmarks for all
NikosD is offline   Reply With Quote
Old 4th December 2019, 23:01   #1964  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by soresu View Post
Perhaps he means tone mapping for displaying HDR content on SDR screens?
HDR tone mapping is generally done in the SoC or GPU. It shouldn't impact decoder performance, but might increase battery draw.

Of course, doing 1080p on a phone is nearly placebo for most TV/film content. 4K is beyond overkill for such a small screen.

Generally decoders support the same resolution/fps in all supported bit modes. It's more expensive to go beyond 8-bit, but not in a way that makes it materially cheaper to only support >8-bit at lower resolutions.

Sent from my SM-T837V using Tapatalk
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 5th December 2019, 01:49   #1965  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
isn't 10 bit HEVC still generally better then 8 bit but the difference is very very small?

and the whole story of 8bpp and 16bpp x265. wasn't that an very important part why x264 10 bit was much better thanks to 10 bit bpp instead of 8.
is the 8 bpp x265 even alive?

how does AV1 handle this is this even comparable?

isn't a 8 bit quality pipe absolutely impossible anyway? just the level/RGB conversation pretty much proves it or even the chroma upscale.
huhn is offline   Reply With Quote
Old 5th December 2019, 09:10   #1966  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
I didn't mean to imply that encoding 8 bit content in 10 bit AV1 would be the right thing to do.

I just meant that given premium content almost always being > = 10 bit 4:2:2 it makes sense to preserve 10 bit, especially when picky studios are highly critical of how subtle gradients are handled in their content.

Last edited by Blue_MiSfit; 5th December 2019 at 09:14.
Blue_MiSfit is offline   Reply With Quote
Old 6th December 2019, 02:03   #1967  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Regarding Google working on their own AV1 decoder, I'd imagine this has to do with being the masters of their own destiny so they can use the decoder however they want on Android / anywhere else, free from any potential licensing incompatibility with dav1d.
Blue_MiSfit is offline   Reply With Quote
Old 6th December 2019, 09:23   #1968  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,340
Quote:
Originally Posted by Blue_MiSfit View Post
Regarding Google working on their own AV1 decoder, I'd imagine this has to do with being the masters of their own destiny so they can use the decoder however they want on Android / anywhere else, free from any potential licensing incompatibility with dav1d.
dav1d has one of the most liberal licenses anywhere (2-clause BSD), Android already uses libraries under far stricter licenses.

Nevermind that Chrome already uses dav1d as well, so its not like Google somehow doesn't know about it, or something like that.

The reason is probably some BS politics, and has no logical backing.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 7th December 2019, 02:31   #1969  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Hmm. That's unfortunate, I wonder if we'll ever know the real story here
Blue_MiSfit is offline   Reply With Quote
Old 9th December 2019, 23:23   #1970  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Blue_MiSfit View Post
I didn't mean to imply that encoding 8 bit content in 10 bit AV1 would be the right thing to do.

I just meant that given premium content almost always being > = 10 bit 4:2:2 it makes sense to preserve 10 bit, especially when picky studios are highly critical of how subtle gradients are handled in their content.
Premium content is NOT >=10-bit 4:2:2. 10-bit 4:2:0 is all that anyone is distributing to consumers via streaming and disc. The masters are, certainly, but it's not like those look visually better than distribution codecs at a sufficient bitrate.

Sent from my SM-T837V using Tapatalk
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 9th December 2019, 23:25   #1971  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by huhn View Post
isn't 10 bit HEVC still generally better then 8 bit but the difference is very very small?



and the whole story of 8bpp and 16bpp x265. wasn't that an very important part why x264 10 bit was much better thanks to 10 bit bpp instead of 8.

is the 8 bpp x265 even alive?



how does AV1 handle this is this even comparable?



isn't a 8 bit quality pipe absolutely impossible anyway? just the level/RGB conversation pretty much proves it or even the chroma upscale.
There is a significant but shrinking number of devices, mainly handheld, that support 8-bit HEVC but not 10-bit.

More common is devices with 10-bit decoders that then feed into 8-bit compositors, GPUs, or display controllers.

Sent from my SM-T837V using Tapatalk
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 10th December 2019, 00:52   #1972  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by benwaggoner View Post
Do we have any evidence that 8-bit sources encode better in 10-bit than 8-bit in AV1?
If nothing else, 8b RGB to 10b YUV to 8b RGB is substantially higher quality than 8b YUV to 8b RGB (especially near white and black), and 10b YUV can decode to higher depth RGB wherever the panel supports it. It sure beats having to deband afterward, or drop in a shedload of noise (and bits) to hide banding. Those with 6b RGB panels will continue to wail, because hardware companies refuse to incorporate simple tricks like dithering on budget hardware until they're promoted as a requirement, but that's can't be helped.

It's true that AV1 and HEVC fixed AVC's rather staggering difference in quality between 8- and 10-bit encoding, but there's still some utility if the toolchain wants to keep quality at the forefront.
foxyshadis is offline   Reply With Quote
Old 10th December 2019, 03:07   #1973  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Quote:
Originally Posted by benwaggoner View Post
Premium content is NOT >=10-bit 4:2:2. 10-bit 4:2:0 is all that anyone is distributing to consumers via streaming and disc.
Of course. That's what I said (specifically referencing masters being >= 10 bit)

Last edited by Blue_MiSfit; 10th December 2019 at 03:09.
Blue_MiSfit is offline   Reply With Quote
Old 10th December 2019, 20:29   #1974  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Blue_MiSfit View Post
Of course. That's what I said (specifically referencing masters being >= 10 bit)
Ah, my apologies for the confusion, then.

Sent from my SM-T837V using Tapatalk
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 10th December 2019, 22:44   #1975  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
Quote:
Originally Posted by benwaggoner View Post
There is a significant but shrinking number of devices, mainly handheld, that support 8-bit HEVC but not 10-bit.

More common is devices with 10-bit decoders that then feed into 8-bit compositors, GPUs, or display controllers.
i don't see anything that diminished the benefit of using more bit deep in encoding here.
Quote:
Originally Posted by foxyshadis View Post
If nothing else, 8b RGB to 10b YUV to 8b RGB is substantially higher quality than 8b YUV to 8b RGB (especially near white and black), and 10b YUV can decode to higher depth RGB wherever the panel supports it. It sure beats having to deband afterward, or drop in a shedload of noise (and bits) to hide banding. Those with 6b RGB panels will continue to wail, because hardware companies refuse to incorporate simple tricks like dithering on budget hardware until they're promoted as a requirement, but that's can't be helped.
the fact that AMD supports native 6 bit output with there own dithering which helps a lot of sub optimal screens show the benefit of doing this correctly.
the best panel i have ever tested in term of banding is a 6 bit FRC panel the processing just doesn't add banding on such a "bad" device.

and i totally agree using more bits in encoding to delay the dithering until the end device or at least the presentation of a device is a clear benefit.

just reading about 4:2:2 master is letting me wonder if this is just a bad habit that simple didn't stop instead of 16 RGB or higher even the aged BBB has this as a master and what reason could be there not to do that.
huhn is offline   Reply With Quote
Old 11th December 2019, 01:15   #1976  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
I always figured the 10 bit 4:2:2 thing most likely goes back to SDI / HD-SDI which was traditionally 10 bit 4:2:2. Capturing the full bandwidth of this signal into a file based format in a way that's perceptually lossless was long since considered "good enough" and widely used mezzanine file formats like ProRes do a great job of this - especially relative to the old days of 50-80 Mbps 1080p MPEG-2 service masters.

Given the context of final distribution always being 8 bit 4:2:0 until recently, perceptually lossless 10 bit 4:2:2 was indeed always good enough.

Now that we're doing HDR, 10 bit is mandatory, and 12 or even 16 bit (ProRes 4444 / 4444 XQ or JPEG 2000) is common for source material when encoding for Dolby Vision. Sure, this gets shaped into a 10 bit IPT file but allegedly more of the input can be recovered after Dolby magic.

Studio archival masters are generally 16 bit full range RGB TIFFs or the OpenEXR equivalent (not sure about the specifics of that), and probably DPX for older stuff. Maybe 16 bit lossless JPEG 2000 if the studio is IMF native.

Last edited by Blue_MiSfit; 13th December 2019 at 04:21.
Blue_MiSfit is offline   Reply With Quote
Old 15th December 2019, 16:29   #1977  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
New rav1e build released with 20% speed improvement: https://github.com/xiph/rav1e/releases/tag/p20191215
hajj_3 is offline   Reply With Quote
Old 19th December 2019, 10:25   #1978  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
Rav1e 0.2.0 released, 40-70% faster than than v0.1.0 depending on the encoding settings.

changelog:
Optional serialization/deserialization of the encoding parameters through the feature serialize
Optional cli advanced commands to use it.
The builds are now using the dwarf debug format for the targets that support it, before it was a mixture of dwarf and stabs due to the nasm defaults.
Added a --benchmark hidden flag for the cli for MacOS and Linux.
documentation is now available on docs.rs.
Changes
Segmentation support is now a tunable SpeedSetting and currently it is default off since it can produce desyncs, this does cause a 3% decrease in quality.
Fixes
#1903 - edge-of-frame miscomputation
#1858 - desync on speed 0 and 1 when certain quantizers are selected
Known issues
#1930 - segmentation encoding may cause desync
hajj_3 is offline   Reply With Quote
Old 21st December 2019, 02:01   #1979  |  Link
Mr_Khyron
Member
 
Mr_Khyron's Avatar
 
Join Date: Nov 2002
Posts: 203
SVT-AV1 0.8 is out
https://github.com/OpenVisualCloud/S...ses/tag/v0.8.0
Quote:
x Preset Optimizations
x Single-core execution memory optimization [-lp 1 -lad 0]
x Rate estimation update enhancements
x On / off flags for feature run-time switching
x Auto-max partitioning algorithm support
x Multi-pass partitioning depth support
x Remove deprecated RC mode 1 and shifter RC mode 2 and mode 3 to mode 1 and mode 2 respectively
x Update cost calculation for CDEF Filtering
x Intra-Inter compound for 10-bit
x Eigth-pel optimization
x AVX512 Optimizations
x AVX2 Optimizations
Mr_Khyron is offline   Reply With Quote
Old 24th December 2019, 18:25   #1980  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 95
Status report!
"Padoru padoru!" 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
4th edition: https://forum.doom9.org/showthread.p...39#post1871939
5th edition: https://www.reddit.com/r/AV1/comment..._half_edition/
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 -> rav1e               | x264 -> rav1e
        RATE (%) DSNR (dB)  |         RATE (%) DSNR (dB)
 MSSSIM -23.2215 1.01158    |  MSSSIM -23.2215 1.01158
PSNRHVS -24.4172 1.36951    | PSNRHVS -24.4172 1.36951
  HVMAF -15.8889 1.38478    |   HVMAF -15.8889 1.38478
----------------------------|----------------------------
rav1e -> svtav1             | x264 -> svtav1
        RATE (%) DSNR (dB)  |         RATE (%) DSNR (dB)
 MSSSIM -5.56998 0.20639    |  MSSSIM -28.4361 1.23111
PSNRHVS -6.41119 0.290801   | PSNRHVS -30.1248 1.65609
  HVMAF -15.6008 1.20241    |   HVMAF -29.5127 2.45437
----------------------------|----------------------------
svtav1 -> vp9               | x264 -> vp9
        RATE (%) DSNR (dB)  |         RATE (%) DSNR (dB)
 MSSSIM  4.20075 -0.151838  |  MSSSIM -25.2711 1.10719
PSNRHVS  4.84265 -0.215506  | PSNRHVS -26.5998 1.48648
  HVMAF -1.42341 -0.19208   |   HVMAF -29.8597 2.33372
----------------------------|----------------------------
vp9 -> x265                 | x264 -> x265
        RATE (%) DSNR (dB)  |         RATE (%) DSNR (dB)
 MSSSIM -1.31186 0.0508852  |  MSSSIM -26.3349 1.18403
PSNRHVS -5.36837 0.2586     | PSNRHVS -30.5296 1.7606
  HVMAF -1.84033 0.341593   |   HVMAF -30.9904 2.59114
----------------------------|----------------------------
x265 -> av1                 | x264 -> av1
        RATE (%) DSNR (dB)  |         RATE (%) DSNR (dB)
 MSSSIM -23.2948 0.961133   |  MSSSIM -43.3907 2.06939
PSNRHVS -18.5938 0.914589   | PSNRHVS -43.484 2.58526
  HVMAF -19.3808 1.25801    |   HVMAF -44.4219 3.59302
BD rates for 1080p:
Code:
Codecs ladder:              | x264 relative:
x264 -> rav1e               | x264 -> rav1e
        RATE (%) DSNR (dB)  |         RATE (%) DSNR (dB)
 MSSSIM -32.2826 1.19743    |  MSSSIM -32.2826 1.19743
PSNRHVS -30.8004 1.43869    | PSNRHVS -30.8004 1.43869
  HVMAF -24.0161 1.68074    |   HVMAF -24.0161 1.68074
----------------------------|----------------------------
rav1e -> svtav1             | x264 -> svtav1
        RATE (%) DSNR (dB)  |         RATE (%) DSNR (dB)
 MSSSIM -7.09315 0.212708   |  MSSSIM -37.5209 1.44372
PSNRHVS -6.91838 0.253513   | PSNRHVS -36.0074 1.70477
  HVMAF -14.4798 1.05647    |   HVMAF -34.513 2.60239
----------------------------|----------------------------
svtav1 -> vp9               | x264 -> vp9
        RATE (%) DSNR (dB)  |         RATE (%) DSNR (dB)
 MSSSIM  1.75731 -0.0570674 |  MSSSIM -36.6065 1.39502
PSNRHVS  0.61474 -0.0275689 | PSNRHVS -35.7951 1.68578
  HVMAF -5.87037  0.0512821 |   HVMAF -38.5344 2.64173
----------------------------|----------------------------
vp9 -> x265                 | x264 -> x265
        RATE (%) DSNR (dB)  |         RATE (%) DSNR (dB)
 MSSSIM 9.95155  -0.292103  |  MSSSIM -30.4864 1.15663
PSNRHVS 4.66281  -0.165867  | PSNRHVS -32.9136 1.56443
  HVMAF 5.65708  -0.054123  |   HVMAF -34.5119 2.53192
----------------------------|----------------------------
x265 -> av1                 | x264 -> av1
        RATE (%) DSNR (dB)  |         RATE (%) DSNR (dB)
 MSSSIM -31.9542 1.15077    |  MSSSIM -52.2509 2.19044
PSNRHVS -26.5316 1.11388    | PSNRHVS -50.3241 2.54395
  HVMAF -22.5904 1.34136    |   HVMAF -49.1759 3.58479
Encoders:
x264 158-2984-3759fcb
x265 3.2-7-37648fca915b
libvpx-vp9 1.8.2-23-g50d1a4aa7
rav1e 0.2.0-32-g350ac84
SVT-AV1 0.8.0-5303-0952998d
libaom 1.0.0-60-g3e421b069

Cmdlines:
Code:
echo -n "16 19 22 26 29 32" | xargs -d " " -n 1 -P 1 -I {} x264 --preset veryslow --tune ssim --crf {} -o test.x264.crf{}.264 orig.i420.y4m
echo -n "16 20 23 27 30 34" | xargs -d " " -n 1 -P 1 -I {} x265 --preset veryslow --tune ssim --crf {} -o test.x265.crf{}.hevc orig.i420.y4m
echo -n "12 21 30 38 47 56" | xargs -d " " -n 1 -P 6 -I {} vpxenc --codec=vp9 --frame-parallel=0 --tile-columns=0 --auto-alt-ref=6 --good --cpu-used=0 --tune=psnr --passes=2 --threads=1 --end-usage=q --cq-level={} --test-decode=fatal --ivf -o test.vp9.cq{}.ivf orig.i420.y4m
echo -n "030 056 082 108 134 160" | xargs -d " " -n1 -P6 -I {} rav1e -o test.rav1e.cq{}.ivf --quantizer {} -s 5 --tune Psychovisual orig.i420.y4m
echo -n "13 21 29 37 45 53" | xargs -d " " -n1 -P1 -I{} SvtAv1EncApp.exe -i orig.i420.yuv -b test.svtav1.cq{}.ivf -w 1280 -h 720 -q {} -scm 0 -enc-mode 8 -fps-num 24000 -fps-denom 1001 -intra-period 47 -output-stat-file fp_stats{}.stat -enc-mode-2p 3
echo -n "13 21 29 37 45 53" | xargs -d " " -n1 -P1 -I{} SvtAv1EncApp.exe -i orig.i420.yuv -b test.svtav1.cq{}.ivf -w 1280 -h 720 -q {} -scm 0 -enc-mode 3 -fps-num 24000 -fps-denom 1001 -intra-period 47 -input-stat-file fp_stats{}.stat
echo -n "12 21 30 38 47 56" | xargs -d " " -n 1 -P 3 -I {} aomenc --frame-parallel=0 --tile-columns=0 --auto-alt-ref=1 --cpu-used=3 --passes=2 --threads=2 --row-mt=1 --end-usage=q --cq-level={} -o test.av1.cq{}.webm orig.i420.y4m
VMAF: model used: vmaf_b_v0.6.3, pooling: harmonic_mean, bagging score (arithmetic mean of 21 models' scores)
Start-to-end times:
x264: 0 hours, 34 minutes and 58 seconds
x265: 4 hours, 13 minutes and 57 seconds
libvpx-vp9: 3 hours, 17 minutes and 52
rav1e: 9 hours, 8 minutes and 25 seconds
SVT-AV1: 5 hours, 6 minutes and 13 seconds
libaom: 7 hours, 26 minutes and 5 seconds

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
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 10:25.


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