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. |
31st July 2018, 04:56 | #6241 | Link | |
Registered User
Join Date: Jun 2018
Posts: 56
|
Quote:
The options are --preset slower --tune psnr --profile main --ctu 32 --keyint 600 --scenecut 30 --rc-lookahead 48 --bframes 16 --qg-size 16 --pass * --qpstep 10 --range limited Note that --tune psnr is removed in advance. |
|
31st July 2018, 08:15 | #6242 | Link | |
Registered User
Join Date: Aug 2009
Posts: 90
|
Quote:
Maybe I should try actually raising it even more to 0.8 It's not really noticable on my monitor, but when viewed on a 65" oled I got a bit annoyed by it... Even with 1080p encodes with average bitrates around 7000 I still notice it sometimes. I can't speak for anyone else, but to me it looks very ugly and in some cases it is really noticible. Also, not related to this (i think), when encoding HDR content with x265 it seems as if the adaptive algorithms don't take the tonemapping/different contrast handling of HDR footage into account? What i mean is that when you play HDR content on a non-HDR display, it looks really flat and it seems to me this is how the footage gets analyzed by x265's CRF/VBR which results in an out of balance preservation of detail in flat areas. When the encoded footage is played back on a HDR screen, I get the impression there is more loss in detail in low contrast areas than usual... I hope you guys understand what I mean? It's like x265 doesnt take the contrast adjustments of HDR content into account. Already started a separate thread about this, but maybe I should've posted this here aswell... Last edited by K.i.N.G; 31st July 2018 at 08:30. |
|
31st July 2018, 09:32 | #6243 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
This is a bit strange. When you raise qcomp, the bitrate gets substantially higher with CRF mode. Shouldn't it be the opposite?
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
31st July 2018, 09:53 | #6245 | Link | |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
From Xvid I remember a "quantizer curve compression", there it changed the quantizer distribution character. I believe it is still true to some extent for x265. From the official documentation:
Command line options: --qcomp <float> Quote:
|
|
31st July 2018, 10:00 | #6246 | Link | |
Helenium(Easter)
Join Date: Aug 2017
Location: Hsinchu, Taiwan
Posts: 99
|
Quote:
__________________
Monochrome Anomaly |
|
31st July 2018, 15:39 | #6247 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
x265 2.8+57-eea92165b035
Enhance VBV lookahead of RADL pictures (and a few more small building and API fixes) |
31st July 2018, 23:52 | #6248 | Link | |
Registered User
Join Date: Dec 2014
Posts: 666
|
I'm getting this error since v2.8 + 49 in Staxrip:
Quote:
__________________
Asus ProArt Z790 - 13th Gen Intel i9 - RTX 3080 - DDR5 64GB Predator - LG OLED C9 - Yamaha A3030 - Windows 11 x64 - PotPlayerr - Lav - MadVR |
|
1st August 2018, 00:01 | #6249 | Link | |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Most interesting here: There are placeholders for pointers and strings in a format string which are not interpreted as if preceded by a %. I would suspect issues with string functions.
Where did you get these x265 builds from, which compiler did they use? (e.g. run "x265 -V" in a console, that should reveal used compilers, or additional format string failures) There was a patch e2759ae: Quote:
Last edited by LigH; 1st August 2018 at 00:06. |
|
1st August 2018, 00:49 | #6250 | Link |
Registered User
Join Date: Dec 2014
Posts: 666
|
Thanks LigH for the thoughts. I have been getting my build from here:
http://msystem.waw.pl/x265/ VS 2017 AVX 2
__________________
Asus ProArt Z790 - 13th Gen Intel i9 - RTX 3080 - DDR5 64GB Predator - LG OLED C9 - Yamaha A3030 - Windows 11 x64 - PotPlayerr - Lav - MadVR |
1st August 2018, 09:30 | #6251 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Please compare with my latest 2.8+57 and previous 2.8+47 (GCC 7.3.0, generic) and Barough's 2.8+56.
And please try to execute the encodes directly in a console window, to avoid mixing up error messages from x265 with error messages from StaxRip. Last edited by LigH; 1st August 2018 at 09:51. |
1st August 2018, 23:41 | #6253 | Link | |
Registered User
Join Date: Dec 2014
Posts: 666
|
Quote:
Thanks for helping out. First of all I'm not familiar with with "console window". I exclusively encode using staxrip. I have noticed that build 47 below exhibits no problem at all. This made me think that the problem lies with new or modified switches. Unfortunately, the author of staxrip called-in quit, so no help from him at all
__________________
Asus ProArt Z790 - 13th Gen Intel i9 - RTX 3080 - DDR5 64GB Predator - LG OLED C9 - Yamaha A3030 - Windows 11 x64 - PotPlayerr - Lav - MadVR |
|
2nd August 2018, 07:49 | #6254 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Yes, stax76 is not so active anymore. To use x265 in a more frequently updated GUI, which also allows more customization, I'd suggest MeGUI.
It will also be important to know your CPU. Does it support AVX2 at all? And it is interesting to know when x265 crashes. Immediately after starting an encoding job, or after calculating for a while? The log in MeGUI is more verbose here. It would report all of its output, including the CPU ID part. |
3rd August 2018, 20:42 | #6255 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
I've tried to reproduce the problem (but no hangs):
Code:
ffmpeg -i ../original.mkv -v warning -f yuv4mpegpipe - | x265-49 --y4m - --bitrate 1500 --pass 1 --ssim-rd --aq-mode 3 --pools 28 NUL y4m [info]: 1920x1080 fps 24000/1001 i420p8 sar 1:1 unknown frame count raw [info]: output file: NUL x265 [info]: HEVC encoder version 2.8+49-5d34bbf671f7 x265 [info]: build info [Windows][MSVC 1900][64 bit] 10bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 x265 [info]: Main 10 profile, Level-4 (Main tier) x265 [info]: Thread pool created using 28 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 4 / wpp(17 rows) x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2 x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0 x265 [info]: References / ref-limit cu / depth : 3 / on / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress : ABR-1500 kbps / 0.60 x265 [info]: tools: rd=3 ssim-rd rskip signhide tmvp strong-intra-smoothing x265 [info]: tools: lslices=6 deblock sao stats-write x265 [info]: frame I: 11, Avg QP:24.83 kb/s: 18638.87 x265 [info]: frame P: 349, Avg QP:26.64 kb/s: 4358.80 x265 [info]: frame B: 1173, Avg QP:32.98 kb/s: 431.42 x265 [info]: Weighted P-Frames: Y:20.3% UV:9.7% x265 [info]: consecutive B-frames: 3.9% 1.1% 12.5% 30.3% 52.2% encoded 1533 frames in 64.16s (23.89 fps), 1456.17 kb/s, Avg QP:31.48 Could you confirm that 2.8+47 works, 2.8+49 hangs, and what with version 2.8+48 -- please download only 10-bit VS2015 AVX2 builds (2.8+47, 2.8+48 and 2.8+49) and report back which works and which not: www.msystem.waw.pl/x265/test.7z |
5th August 2018, 15:26 | #6256 | Link |
Registered User
Join Date: Feb 2007
Posts: 128
|
Just replaced x265 in Staxrip with LigH's 2.8+57 version.
No error yet. (Current encoding seems to be a bit sluggish but need to observe further - it could very well just be movie related) I'm using StaxRip 1.7.0.6 from https://github.com/stax76/staxrip/bl...r/changelog.md. |
6th August 2018, 04:02 | #6257 | Link |
Registered User
Join Date: Dec 2014
Posts: 666
|
Ma & LigH,
Found the error in 2pass encoding: Multipass analysis refinement along with multipass rate control Multipass refinement of qp based on distortion data If these two are deactivated everything is ok Maybe the syntax has changed?
__________________
Asus ProArt Z790 - 13th Gen Intel i9 - RTX 3080 - DDR5 64GB Predator - LG OLED C9 - Yamaha A3030 - Windows 11 x64 - PotPlayerr - Lav - MadVR |
6th August 2018, 08:54 | #6258 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
Thanks for the info!
It looks like a bug in x265. You could/should find exact commit that hangs, for example 2.8+47 works/2.8+48 hangs or 2.8+48 works/2.8+49 hangs. And find in StaxRip log x265 command line and copy it in this thread. |
6th August 2018, 11:11 | #6260 | Link |
Registered User
Join Date: Sep 2017
Posts: 18
|
@x265_Project it seems that you would be the only one who can answer my question, since it's becoming complex and I believe the answer can be very long... please have a look(In HEVC, only QP=4 is truly lossless quantization... what about 0~3?): forum.doom9.org/showthread.php?t=175638
|
|
|