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. |
|
|
Thread Tools | Search this Thread | Display Modes |
6th February 2019, 21:03 | #1121 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
Over-tuning for mean per-frame PSNR tends to result in some strobing, because improving quality of reference frames pays off more than non-reference frames. Dark Shikari had a great blog post about that way back when. |
|
7th February 2019, 19:09 | #1122 | Link |
Registered User
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
|
This is what --auto-alt-ref=1 does; --auto-alt-ref=N for N>1 enables multi-level hierarchical frame ordering, with the number of layers being equal to N. This is known to improve coding efficiency, HEVC/H264 use it also (pyramid frame ordering).
|
7th February 2019, 22:43 | #1124 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
Typical Google - I really wish they would have usable documentation for all of this stuff! Who wants to dig through mailing lists and forum posts to have any idea how to properly do VP9 encoding??
Glad to see libvpx continuing to improve in any case, particularly when it comes to rate control. |
8th February 2019, 00:55 | #1125 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
I wish VP9 had a x265.readthedocs.io equivalent . And a translation guide would be helpful as well. The VPx codecs wind up trying to do the same essential thing as MPEG codecs, but structured differently to get around patents. |
|
17th February 2019, 15:10 | #1126 | Link | |
Member
Join Date: Nov 2002
Posts: 203
|
https://github.com/OpenVisualCloud/SVT-VP9
https://github.com/OpenVisualCloud/SVT-VP9
Quote:
|
|
18th February 2019, 01:03 | #1127 | Link | |
Member
Join Date: Nov 2002
Posts: 203
|
SVT-VP9 Is Intel's Latest Open-Source Video Encoder Yielding High Performance VP9
https://phoronix.com/scan.php?page=n...P9-Open-Source
Quote:
|
|
21st February 2019, 21:07 | #1128 | Link | ||
Registered User
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
|
Quote:
Quote:
[edit] Maybe I'm being unfair in that last comment, bit snarky also, so allow me to re-phrase that. I guess Google would have hoped that if they provide engineering talent, that other community contributors would have done these things that make it more widely useful but aren't necessary for Google internally. Obviously this never happened, but it would make sense from Google's perspective to hope for some more community participation than they've seen. Last edited by Beelzebubu; 21st February 2019 at 21:09. |
||
21st February 2019, 21:26 | #1129 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
|
|
1st March 2019, 00:26 | #1130 | Link |
Registered User
Join Date: Oct 2014
Posts: 268
|
With vpxenc (tried with 1.7.0 and 1.8.0) I get weird rate-control.. 1.7.0 was undershooting quite a bit, 1.8.0 seemed to do better but with the same source and less bitrate it starts to overshoot out of nowhere (by quite a lot).
Code:
vpxenc --cpu-used=9 --good --end-usage=vbr --auto-alt-ref=6 --target-bitrate=6000 --passes=2 --pass=1 (and 2) --aq-mode=1 --row-mt=1 |
2nd March 2019, 06:49 | #1131 | Link | |
Registered User
Join Date: Jan 2019
Posts: 9
|
Quote:
2. Do keep in mind that --auto-alt-ref accepts the full range of integers in [0 .. 6], not only 0/1/6. The benefits of switching from 0 to 1 are usually (most sources, at most resolutions) significantly greater than switching from 1 to any >1 value; higher values such as 6 may provide negligible gains over lower values such 2/3, in which case the speed penalty may become undesirable. As you are already instructing the encoder to be fast with --cpu-used, it's probably a saner option to set --auto-alt-ref to 1. For general-purpose encoding, I'd look at auto-alt-ref 2/3 for cpu-used 1/2 thus reserving the highest possible value of 6 to cpu-used 0. 3. It's redundant to manually specify a --pass, by setting up --passes the encoder can automatically run multi-pass encodings. 4. While --aq-mode 1/2 will occasionally (some sources, at some resolutions) provide better results, accompanied or not by --alt-ref-aq >0, for general-purpose encoding is strongly recommended to disable AQ by setting aq-mode to 0. 5. For general-purpose encoding is recommended to use explicitly --lag-in-frames 25, and also --enable-tpl 1. Properly enabling multithreading in vpxenc/libvpx requires several parameters, not just --row-mt on its own. In addition to setting row-mt to 1, it's needed to set up the tiles too and that can be achieved as it follows: explicitly disable tile rows (--tile-rows 0), and explicitly enable tile columns instead (set --tile-columns to 5/6, 5 is already enough for 99.9999% of encodings; do note that the encoder will automatically use as many horizontal tiles as permitted by the horizontal resolution, i.e. width, of the source. In practical scenarios, the encoder will restrict tile-columns to [0 .. 3] much more often than not because that corresponds to sources up to 16:9 2160p). Lastly, enable explicitly --threads by setting up a high value, for instance 64 (do NOT change --threads according to the number of actual logical cores of the machine used for encoding, set up a high value and the encoder will spawn automatically as many threads as it needs). Wrapping it up, this is how multithreading should be set up for file-based encoding (nota bene, chunk-based encoding is addressed differently): --tile-rows=0 --tile-columns=5 --row-mt=1 --threads=64. The rate control of vpxenc/libvpx is peculiar, to say the least. It works better with quantizers (--end-usage cq/q, plus --cq-level [desired CRF], plus --min-q and/or --max-q [desired QP]) than with bitrates (--end-usage vbr/cbr, plus --target-bitrate, plus --undershoot-pct and/or --overshot-pct, plus --bias-pct). The absolute best results are achieved through chunk-based encoding (i.e. the very way vpxenc was designed to be used), rather than the file-based encoding that would be expected by normal people (a very non-specific alias for consumers). Yes, it's probably fair to state that "rate control in libvpx sucks", as long as it's understood that attempting to achieve strict rate control in file-based encoding will undershoot/overshoot much more often than not especially when using lax parameters (for instance only --target-bitrate on its own, without the other RC tools). Belated disclaimer: my insight of vpxenc/libvpx is purely empirical, gained from using them extensively myself on various sources, at various resolutions, with various parameter sets. Professionals such as Ronald can provide technical insight, if you can actually persuade them to do so. |
|
18th March 2019, 02:57 | #1134 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
The commit log is at https://chromium.googlesource.com/webm/libvpx
|
13th April 2019, 02:04 | #1135 | Link | |
Registered User
Join Date: Aug 2018
Posts: 18
|
I'm getting VMAF score of VP9 video which is less than H.264 at 500Kbps using highest quality settings on each. Anyone encounter this before?
the ffmpeg 2-pass settings for x264 - VMAF score 72.8 Code:
./ffmpeg -i scene1.mp4 -c:v libx264 -an -b:v 500k -filter:v scale=720:-1 -preset placebo -pass 1 -f mp4 -y /dev/null / && ./ffmpeg -i scene1.mp4 -movflags +faststart -pix_fmt yuv420p -c:v libx264 -an -b:v 500k -filter:v scale=720:-1 -pass 2 -preset placebo ./x264/scene1/x264_500k.mp4 Quote:
This seems completely unexpected! I've attached both encoded files below VMAF was then measure with the following command Code:
../../ffmpeg -i vp9_500k.webm -i ../../scene1.mp4 -filter_complex "[0:v]scale=1920x800:flags=bicubic[main];[main][1:v]libvmaf=model_path=/home/kay/vmaf/model/vmaf_v0.6.1.pkl" -f null - >>vmaf-scene1.txt -hide_banner |
|
13th April 2019, 02:52 | #1136 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
something buggy about your vp9 encode , and the frames are not aligned at the end between x264 and vp9 . You didn't upload the immediate source, but both encodes have duplicate frames that aren't in the movie You can decode to uncompressed or lossless I-frame like utvideo and compare them ffmpeg gives warning when encoding the vp9 version too Quote:
|
||
13th April 2019, 15:43 | #1138 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
You can index it with avisynth/vapoursynth, but frames still don't match I suspect he had issues with the immediate source |
|
13th April 2019, 16:13 | #1139 | Link |
Registered User
Join Date: Apr 2018
Posts: 22
|
What is the proper way to multithread in 2019? Is it possible to achieve 100% cpu usage on 8 cores? Also, I read somewhere that frame parallel is not needed anymore. Is that correct?
Last edited by user1085; 13th April 2019 at 16:16. |
14th April 2019, 03:58 | #1140 | Link | |
Registered User
Join Date: Aug 2018
Posts: 18
|
Quote:
72.8 for x264 vs 74.7 for VP9 |
|
Tags |
google, ngov, vp8, vp9, vpx, webm |
|
|