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. |
30th November 2019, 02:00 | #1961 | Link | |
Registered User
Join Date: Sep 2018
Posts: 14
|
Quote:
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. |
|
1st December 2019, 00:05 | #1962 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
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) |
1st December 2019, 11:22 | #1963 | Link | |
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:
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
|
4th December 2019, 23:01 | #1964 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
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 |
|
5th December 2019, 01:49 | #1965 | Link |
Registered User
Join Date: Oct 2012
Posts: 7,925
|
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. |
5th December 2019, 09:10 | #1966 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
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. |
6th December 2019, 02:03 | #1967 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
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.
|
6th December 2019, 09:23 | #1968 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Quote:
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 |
|
9th December 2019, 23:23 | #1970 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
Sent from my SM-T837V using Tapatalk |
|
9th December 2019, 23:25 | #1971 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
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 |
|
10th December 2019, 00:52 | #1972 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
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. |
|
10th December 2019, 22:44 | #1975 | Link | ||
Registered User
Join Date: Oct 2012
Posts: 7,925
|
Quote:
Quote:
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. |
||
11th December 2019, 01:15 | #1976 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
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. |
15th December 2019, 16:29 | #1977 | Link |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
New rav1e build released with 20% speed improvement: https://github.com/xiph/rav1e/releases/tag/p20191215
|
19th December 2019, 10:25 | #1978 | Link |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
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 |
21st December 2019, 02:01 | #1979 | Link | |
Member
Join Date: Nov 2002
Posts: 203
|
SVT-AV1 0.8 is out
https://github.com/OpenVisualCloud/S...ses/tag/v0.8.0 Quote:
|
|
24th December 2019, 18:25 | #1980 | Link |
I am maddo saientisto!
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 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 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) 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. |
|
|