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. |
17th October 2018, 13:37 | #1141 | Link | |
Registered User
Join Date: Sep 2018
Posts: 14
|
Quote:
|
|
17th October 2018, 17:32 | #1142 | Link |
Registered User
Join Date: May 2002
Posts: 95
|
Yes, you have to take in consideration that even if the bitrate is quite stable you can can have a bad distribution of it. I found that in vp9 if you limit the maximun quantification between 24-38 the overall quality is boosted without much variation on final bitrate/size (max value to be used depends of bitrate and resolution), basically you prevent the encoding rate control to be fucked sometimes with its corresponding drop in quality.
Last edited by Phanton_13; 17th October 2018 at 17:37. |
17th October 2018, 19:51 | #1143 | Link | |||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
Netflix is also going from H.264 to VP9/AV1, so they don't need to beat or even meet HEVC quality to get a worthwhile improvement, of course. Netflix IS using HEVC for all UHD and HDR encoding AFAIK. I'm not sure where VP9 versus H.264 quality stands today. I'm running an encoding challenge, and would love to have someone provide best-effort VP9 and even AV1 samples for comparison. https://forum.doom9.org/showthread.php?t=175776 Quote:
Getting good multithreading into AV1 is going to be really important, since time to market matters for a lot of content. Being able to encode something 8x faster on 16 cores probably doesn't matter for Netflix or YouTube given their chunking and lack of day-after-broadcast content. But it's critical for other markets, and essential for live encoding. Some of the VP9 and AV1 comparisons with x264 and x265 were artificially limited to 1-2 cores. Which makes sense if optimizing for absolute volume of minutes encoded, but understates the speed advantages of x26? for latency-critical tasks. Quote:
...and will also reveal how much of the apparent detail in film comes from the grain. Older films, particularly, look really soft without the grain, and often just don't have much spatial detail. But don't underestimate the challenge of the removing grain part; parameterizing it and then reconstructing it on playback are the easy parts. It's way more feasible now than 12 years ago, but it isn't trivial of something that can run 100% automated without messing up sometimes. Unfortunately production workflows put in film grain much earlier than the encoding stage, so it's already baked in way before it gets to an encoder. |
|||
17th October 2018, 22:29 | #1144 | Link | |
Member
Join Date: Nov 2002
Posts: 203
|
http://www.socionext.com/en/pr/sn_pr20180831_01e.pdf
Quote:
|
|
17th October 2018, 23:16 | #1145 | Link | |
Registered User
Join Date: Apr 2018
Posts: 63
|
Quote:
http://screenshotcomparison.com/comparison/122531 Biggest difference is in the river if you ask me It is probably even more important when pushing the bitrate even lower in a scene like this |
|
17th October 2018, 23:55 | #1146 | Link | |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
Quote:
I can't recall the specifics, but I do recall some sort of overview on bandwidth statistics, showing that some large percentage of worldwide bandwidth is Netflix. Grain = bandwidth!
__________________
http://www.7-zip.org/ |
|
18th October 2018, 01:08 | #1147 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Yeah, I'll get on that once I wean the industry off 24p .
Quote:
This is one reason we need to forever push the boundaries of compression efficiency. Once we get to transparent compression quality, we need to keep making the required bandwidth to reach that ever lower. Over my 25 years doing digital video, we've seen ~20% improvement every year in the bandwidth required to achieve a given level of quality. Decent 1080p today takes fewer bits than ugly 320x176 did back in 1995. |
|
18th October 2018, 01:13 | #1148 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
ASICs and even GPU-based compression was left behind with HEVC; there are so many different tools a modern codec can use (>2x more in AV1 than HEVC), and GPU's aren't great at the tight inner loops and rapid mode determination required to get good use out of a modern bitstream. Fast individual cores with strong SIMD and L1/2/3 cache run rings around hardware that best works with a one way waterfall cascade of operations. And CABAC is all about having a few very fast cores. That needs to be done on CPU. Heck, lots of HW-on-GPU and ASIC encoders don't even have good B-frame support. |
|
18th October 2018, 01:17 | #1149 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
|
|
20th October 2018, 17:37 | #1150 | Link | ||
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
According to the Wiki (https://en.wikipedia.org/wiki/AV1#Profiles)
av1 high profile should support 4:2:0 with 8bit and 10bit, but: Code:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p -vsync 0 -f yuv4mpegpipe - | aomenc --passes=1 --pass=1 --target-bitrate=1500 --end-usage=vbr --profile=1 --cpu-used=3 --undershoot-pct=0 --overshoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=1 --arnr-maxframes=7 --arnr-strength=5 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tune-content=default --tile-columns=0 --tile-rows=0 --min-gf-interval=0 --max-gf-interval=0 --threads=2 --width=640 --height=352 --i420 --input-bit-depth=8 --bit-depth=8 --row-mt=0 --cdf-update-mode=1 -o "E:\Temp\18_13_01_6710_01.ivf" - Code:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | aomenc --passes=1 --pass=1 --target-bitrate=1500 --end-usage=vbr --profile=1 --cpu-used=3 --undershoot-pct=0 --overshoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=1 --arnr-maxframes=7 --arnr-strength=5 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tune-content=default --tile-columns=0 --tile-rows=0 --min-gf-interval=0 --max-gf-interval=0 --threads=2 --width=640 --height=352 --i420 --input-bit-depth=10 --bit-depth=10 --row-mt=0 --cdf-update-mode=1 -o "E:\Temp\18_14_27_4610_01.ivf" - Quote:
Code:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p -vsync 0 -f yuv4mpegpipe - | aomenc --passes=1 --pass=1 --target-bitrate=1500 --end-usage=vbr --profile=2 --cpu-used=3 --undershoot-pct=0 --overshoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=1 --arnr-maxframes=7 --arnr-strength=5 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tune-content=default --tile-columns=0 --tile-rows=0 --min-gf-interval=0 --max-gf-interval=0 --threads=2 --width=640 --height=352 --i420 --input-bit-depth=8 --bit-depth=8 --row-mt=0 --cdf-update-mode=1 -o "E:\Temp\18_16_01_5510_01.ivf" - Code:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | aomenc --passes=1 --pass=1 --target-bitrate=1500 --end-usage=vbr --profile=2 --cpu-used=3 --undershoot-pct=0 --overshoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=1 --arnr-maxframes=7 --arnr-strength=5 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tune-content=default --tile-columns=0 --tile-rows=0 --min-gf-interval=0 --max-gf-interval=0 --threads=2 --width=640 --height=352 --i420 --input-bit-depth=10 --bit-depth=10 --row-mt=0 --cdf-update-mode=1 -o "E:\Temp\18_16_44_1810_01.ivf" - Quote:
From the looks of it: Main at least supports:
-> is the wiki wrong of is this a missing feature or bug in aomenc? Some reliably info would be nice. (using: av1 - AOMedia Project AV1 Encoder 1.0.0-810-gc9c806a80) Cu Selur |
||
20th October 2018, 17:50 | #1151 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
The spec is slightly vague when it comes to this, but even if it would be technically allowed to encode a lower format in a higher profile, you should never do that. There is absolutely no reason to. It'll just screw everything over.
The only thing the profile controls is chroma/bitdepth, there are no other variables, so pick the one appropriate for your content and don't do anything else. A very strict reading of the spec might even forbid this, ie. Section 6.4.1 (General sequence header OBU semantics) has a table with allowed features per profile, and it has no "backwards" notes. So I'll go with that. Its not allowed.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 20th October 2018 at 17:57. |
20th October 2018, 18:29 | #1152 | Link | |||
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
Looking at https://aomediacodec.github.io/av1-spec/av1-spec.pdf
Quote:
Thus how I understand it: Main should support:
Where as aomenc reports: Quote:
Quote:
Looking at 6.4.1 I agree with you it should be:
Cu Selur |
|||
20th October 2018, 20:17 | #1153 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
I think they don't want to have one format in different profiles. If I go by what you say I would have the choice to encode 4:2:0 10 bit as either Main or Professional.
So I think this is correct: Main should support: Monochrome at 8bit and 10bit 4:2:0 at 8bit and 10bit High should support: 4:4:4 at 8bit and 10bit and Professional should support Monochrome at 12 bit 4:2:0 at 12 bit 4:2:2 at 8bit, 10bit and 12bit 4:4:4 at 12bit Last edited by sneaker_ger; 20th October 2018 at 20:28. |
20th October 2018, 20:30 | #1154 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Btw: MkvToolNix 28.0.0 now with finalized support for AV1 reading/writing in mkv/webm.
|
20th October 2018, 21:22 | #1155 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Quote:
The actual rules are in Section 6.4.1 like I said in my previous post (currently page 112) 6.4.1. General sequence header OBU semantics seq_profile specifies the features that can be used in the coded video sequence. Code:
seq_profile Bit depth Monochrome support Chroma subsampling 0 8 or 10 Yes YUV 4:2:0 1 8 or 10 No YUV 4:4:4 2 8 or 10 Yes YUV 4:2:2 2 12 Yes YUV 4:2:0, YUV 4:2:2, YUV 4:4:4 aomenc seems to behave just fine. Wikipedia is wrong (what else is new?) And as said before, there is no sane reason to ever want to do that.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 20th October 2018 at 21:24. |
|
20th October 2018, 23:21 | #1157 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
That just makes the table look very weird on Wikipedia though, and it also doesn't communicate the limitations of encoding 4:2:0 or 4:4:4 in the professional profile correctly (although the text before it does, but reading pfff)
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
21st October 2018, 09:54 | #1158 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Ok, table corrected (again ) and cleaned. Hope it sticks...
Though I'm still wondering about the decoder levels that are allegedly required. Can't find anything about that in the specs. Level 2.2 doesn't even seem to be defined yet. I removed it for now. Last edited by sneaker_ger; 21st October 2018 at 09:58. |
21st October 2018, 10:05 | #1159 | Link |
I am maddo saientisto!
Join Date: Aug 2018
Posts: 95
|
32/64bits binaries:
av1-1.0.0-811-g68baec84b: https://mega.nz/#!w4Y2AawR!T4zzPbckJ...MhmHr536z_btCM |
23rd October 2018, 00:11 | #1160 | Link | |
Registered User
Join Date: Apr 2004
Posts: 1,315
|
Quote:
https://mattgadient.com/x264-vs-x265...-vp9-examples/ https://mattgadient.com/results-enco...rake-x264x265/ Interesting news. it's astonishing to see Machine Learning in coding field. New version of Opus audio codec uses ML. Quality gains are more than significant. Now speech/audio detector has a human-level intelligence. https://hub.packtpub.com/opus-1-3-a-...lly-available/ https://opus-codec.org/ I can't imagine what can be done with AV1 in future. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|