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. |
![]() |
#6481 | Link | |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 3,472
|
Quote:
I have seen visible and measurable value from ref 6, bframes 16, and tskip at <150 Kbps. Of course, using a lot of MIPS/pixel isn’t nearly so painful at low frame sizes and bitrates. |
|
![]() |
![]() |
![]() |
#6482 | Link | ||
Registered User
Join Date: May 2009
Posts: 184
|
Quote:
But in x264 it's :- Quote:
So it seems to me that --subme in x265 is as per --subme 1-5 in x264. And the RD stuff of x264 --subme 6-11 is branched off into it's own thing in x265 with selectable RDO levels, rd-refine as a separate option etc. |
||
![]() |
![]() |
![]() |
#6483 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,328
|
x265 2.9+4-471726d3a046
fixes: rowStat computation in const-vbv; memory reset size in dynamic-refine; linking issue on non x86 platform |
![]() |
![]() |
![]() |
#6484 | Link | |
Registered User
Join Date: Aug 2014
Posts: 50
|
Quote:
1) imo, if you care about things that move, (and picture quality in general), you have to use sub-motion pixel subme 7. 5 is good, and is as low as I ever set that even on files I'm trying to finish fast, but 5 is easily visually inferior to 7 imo. 7 of course takes longer to encode though. I'm usually around CRF 22-23 (with nearly all quality settings turned on). It probably has lesser effect at CRF 18. Last edited by Dclose; 4th November 2018 at 19:36. |
|
![]() |
![]() |
![]() |
#6485 | Link |
Registered User
Join Date: May 2009
Posts: 184
|
For 2-pass encodes, I normally use a custom faster 1st pass command line which is the same as my slow 2nd pass just with RDO level and subme turned down to level 2, --me dia, --early-skip and --fast-intra.
But I've been testing using identical command lines for both passes and using --multi-pass-opt-analysis instead which speeds up the 2nd pass considerably to the point where a complete 2-pass encode is almost the same speed as my usual approach. Which should technically yield the higher quality final result? Is there any potential harm to using --multi-pass-opt-analysis? |
![]() |
![]() |
![]() |
#6486 | Link | |
Registered User
Join Date: Jul 2016
Posts: 12
|
Quote:
I understand that if your NOT turning down --RDO, --me and other settings then it should produce better results since it will spend more time on those settings in first pass. The --mulit-pass options are great in reusing the values obtained in the first pass to increase the speed of the second pass. |
|
![]() |
![]() |
![]() |
#6487 | Link |
Registered User
Join Date: Oct 2018
Posts: 1
|
How does lambda and lambda2 tables work in hevc?
Hi,
I have some sample tabels for lamda2 and I generated a table of lambda based on it. This is the address of my sample https://mailman.videolan.org/piperma...ch/010936.html The second table is not related with its formula (lambda2 = 0.038 * pow(0.234, QP)) is there any document or information that explains lambda and lambda2 tables and relations? Many thanks |
![]() |
![]() |
![]() |
#6488 | Link |
Registered User
Join Date: Jul 2015
Posts: 777
|
Problems with metric VMAF.
After many hours, I managed to adjust the items VMAF. The new addition even recalculates something. Read input model (libsvm) at ./vmaf_rb_v0.6.2/vmaf_rb_v0.6.2.pkl.model ... … Initialize storage arrays... Extract atom features... frame: 0, adm: 0.986, adm_num: 792.386, adm_den: 803.249, adm_num_scale0: 102.293, adm_den_scale0: 105.547, adm_num_scale1: 148.311, adm_den_scale1: 151.745, adm_num_scale2: 230.474, adm_den_scale2: 232.816, adm_num_scale3: 311.307, adm_den_scale3: 313.141, motion: 0.000, motion2: 0.000, vif_num_scale0: 3201540.000, vif_den_scale0: 4265149.500, vif_num_scale1: 915769.438, vif_den_scale1: 973015.313, vif_num_scale2: 237178.438, vif_den_scale2: 244942.781, vif_num_scale3: 62793.887, vif_den_scale3: 64002.453, vif: 0.796, Generate final features (including derived atom features)... Normalize features, SVM regression, denormalize score, clip... frame: 0, adm2: 0.986477, adm_scale0: 0.969174, adm_scale1: 0.977376, adm_scale2: 0.989942, adm_scale3: 0.994142, motion: 0.000000, vif_scale0: 0.750628, vif_scale1: 0.941167, vif_scale2: 0.968301, vif_scale3: 0.981117, vif: 0.796321, motion2: 0.000000, Exec FPS: 2.742952 VMAF score (mean) = 100.000000 x265 [info]: frame I: 1, Avg QP:23.64 kb/s: 5696.20 x265 [info]: frame P: 2, Avg QP:29.09 kb/s: 874.10 x265 [info]: frame B: 7, Avg QP:35.33 kb/s: 204.03 x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0% x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0% x265 [info]: consecutive B-frames: 33.3% 0.0% 0.0% 33.3% 33.3% 0.0% 0.0% 0.0% 0.0% However, how to use it? So many ads on the forum. static const x265_vmaf_commondata vcd_yuv420p[] = { { (char *)"yuv420p", (char *)"./vmaf_rb_v0.6.2/vmaf_rb_v0.6.2.pkl", (char *)"vmaf_yuv%04d.json", (char *)"json", 0, 1, 1, 0, 0, 0, 0, (char *)"mean", 0, 3, 1 } }; The first two items are obvious. They concern the color of subsampling and the version VMAF. Due to the fact that I chose version 0.6.2, the last item 'enable_conf_interval' must be included. Then, the recording items metric VMAF in the files json or xml. These are the next two positions from the left. Here are the problems. First of all, I don't know why the program doesn't save all parameters in one file. Secondly, I can't force a program to save json/xml files one after another to the number of processed frames. (vmaf_yuv%04d) { "version":"1.3.7", "params":{ "model":"", "scaledWidth":1920, "scaledHeight":1080, "subsample":3 }, "metrics":[ "adm2", "bagging", "ci95_high", "ci95_low", "motion2", "stddev", "vif_scale0", "vif_scale1", "vif_scale2", "vif_scale3", "vmaf" ], "frames":[ { "frameNum":0, "metrics":{ "adm2":0.98648, "bagging":99.62585, "ci95_high":100.0, "ci95_low":98.12069, "motion2":0.0, "stddev":0.7394500000000001, "vif_scale0":0.75063, "vif_scale1":0.94117, "vif_scale2":0.9683, "vif_scale3":0.98112, "vmaf":100.0 } } ] } Next, what is the items 'disable_clip' and 'enable_transform' for? The next four items phone_model, psnr, ssim, ms_ssim should be turned off. Choice of data processing method Choosing the number of cores. In my case, zero. Problem with the color n_subsample parameter. For BPG, once there are three for YUV, once there should be one for the alpha color. The instruction is five. Ok, I created x265 files with VMAF and without: - The X265 VMAF codec doesn't work with FFmpeg. av_interleaved_write_frame(): Broken pipe No more output streams to write to, finishing. Error writing trailer of pipe:: Broken pipe Code:
ffmpeg.exe -loglevel verbose -i Untitled.mp4 -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=bt709:in_range=limited:out_color_matrix=bt709:out_range=limited,format=yuv420p -strict -1 - | x265_081012bit_hdr_vmaf.exe --y4m --input-csp i420 --input-depth 8 --output-depth 8 --preset veryslow --crf 28 --fps 25.000 --keyint 50 --info --no-open-gop --colormatrix bt709 --colorprim bt709 --transfer bt709 --limit-ref 0 --range limited --recon 111.yuv --output 111.h265 - In the description: -r/--recon <filename> Reconstructed raw image YUV or Y4M output file name - Strange, the x265 vmaf itself works, but it isn't known whether the codec should have an output file or not? Assuming he has. This file does not differ in content from the recon file. In addition, these files don't differ from x265 files without VMAF. I don't have a concept for what it is and what is the recon file for? Last edited by Jamaika; 19th November 2018 at 12:04. |
![]() |
![]() |
![]() |
#6489 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,328
|
The "recon" feature writes a YUV or Y4M raw video file that contains the reconstructed video which has been decoded right after encoding it, so you can compare the compression results with the original source (assuming it was a YUV or Y4M file too) without calling an additional decoder. It is available independently of VMAF functions linked into x265 – which may still be possible only under Linux, I believe; are you sure your Windows build contains any VMAF comparison code? The build script source\CMakeLists.txt contains the check clearly in a "if(UNIX)" block.
|
![]() |
![]() |
![]() |
#6490 | Link | |
Registered User
Join Date: Jul 2015
Posts: 777
|
Quote:
https://www.sendspace.com/file/r90y0d Probably it can also be created in MSVC. Last edited by Jamaika; 19th November 2018 at 11:57. |
|
![]() |
![]() |
![]() |
#6491 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 362
|
x265 v2.9+8-27d8424c799d (32 & 64-bit 8/10/12bit Multilib Windows Binaries)
Code:
https://bitbucket.org/multicoreware/x265/commits/branch/stable |
![]() |
![]() |
![]() |
#6494 | Link | |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,328
|
--qcomp <float>
Quote:
IIRC, if you could decrease it to 0.0, the encoder would try its best to keep a constant bitrate (CBR), which would cause a very varying amount of quality loss (I might be wrong here, for x265, though). Increasing it to 1.0 instead would cause a constant quantization which would not take advantage of the possible ways to spare bitrate in scenes where convenient quality preservation could already be achieved with less bitrate, at a coarser quantization than the target. You may increase this value a little (e.g. towards 0.8) when you notice that there is too much loss of precision in areas with very little detail, e.g. darkness and smooth ramps, especially in cases when your target bitrate is rather low. On the other hand, there may be other (psycho-visual) options to let the encoder not spare too much bitrate. |
|
![]() |
![]() |
![]() |
#6496 | Link |
Registered User
Join Date: Feb 2015
Posts: 325
|
Test platform: Win10 64-bit home, i7 8700 + be quiet pure rock, 16 GB RAM DDR4 @ 3866
Command line (only 8-bit encoding): x265 --no-asm --crf 20 ../Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m w.hevc Results in fps (encoding speed, mean value from 2 runs): 8.98 fps -- ICC AVX2 8.41 fps -- GCC 9.0 AVX2 ucrt 7.36 fps -- GCC 8.2 AVX2 7.34 fps -- GCC 8.2 AVX2 ucrt 7.12 fps -- GCC 7.3 AVX2 ucrt 7.11 fps -- GCC 6.5 AVX2 ucrt 6.30 fps -- GCC 5.5 AVX2 ucrt 5.93 fps -- GCC 8.2 generic Barough build 5.57 fps -- GCC 4.9.4 AVX2 ucrt 5.06 fps -- VS 2017 AVX2 4.89 fps -- VS 2015 AVX2 4.72 fps -- GCC 4.8.5 AVX2 ucrt ucrt means Universal CRT (it is replacement for msvcrt.dll) Results with asm was 29 up to 30 fps for all contenders (full results in screen.txt). ICC 19 is clear winner, GCC 9 in second place. VS 2017/2015 without asm are really slow (but with asm are good/the best). |
![]() |
![]() |
![]() |
#6498 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Germany
Posts: 1,236
|
Quote:
I knew that Intel Parallel Studio (and its compiler) was good, but what surprises me is that GCC has become better and better. Visual Studio used to be good for AVX2, while GCC used to be better for SSE2/SSSE3/SSE4.1, but perhaps things have changed and GCC now totally outperforms Visual Studio.
__________________
Broadcast Encoder Avisynth memes Videotek - Audacity XP LUT Collection - FFAStrans SafeColorLimiter - AAA |
|
![]() |
![]() |
![]() |
#6499 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,043
|
Do keep in mind that these tests are absolutely disjunct from reality. Noone is going to run something like x265 without ASM, so for any real-world use these numbers are meaningless.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
![]() |
![]() |
![]() |
#6500 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Germany
Posts: 1,236
|
Quote:
Still, in an ideal world, compilers would be able to produce optimized assembly code as fast as manually-written intrinsics, so there's no need to manually write them. Unfortunately, that's still an utopia. Anyway, for 10/12bit x265 on x86 32bit systems (for which there aren't manually written intrinsics available and builds rely on compiler optimization only), compilers "speed tests" are kinda useful. ^_^
__________________
Broadcast Encoder Avisynth memes Videotek - Audacity XP LUT Collection - FFAStrans SafeColorLimiter - AAA |
|
![]() |
![]() |
![]() |
Thread Tools | Search this Thread |
Display Modes | |
|
|