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. |
18th March 2017, 13:51 | #5021 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
There is a third one here:
http://forum.doom9.org/showthread.php?p=1800781
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
18th March 2017, 14:09 | #5022 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
It might be true indeed for Windows not for anything else and also only if those test have been done properly.
Though it might be even only true for a specific ntoskrnl and scheduling also when we talk about milliseconds so their could be even a difference between Windows Vista/7/8 to 10. But it is even with the Posix Layer pretty normal that Microsoft optimizes for Windows entirely and doesn't fight so much as GCC devs have to fight finding the right balance
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 Last edited by CruNcher; 18th March 2017 at 14:20. |
18th March 2017, 14:21 | #5023 | Link | |
Registered User
Join Date: May 2015
Posts: 185
|
Quote:
However: Minimum CPU arch: none, SSSE3, AVX and AVX2 is for C++ compile option – x265 source code is divided into C++ and asm parts. Asm code determine CPU type at runtime, C++ code needs information about CPU type at compile time. It means that if you have CPU with AVX extension, you can use all binaries except AVX2 (which hangs at encoding on AVX-CPU). You can determine your CPU arch by executing x265 with option -V, for example: So a Sandy Bridge or Ivy Bridge user cannot or rather should not use AVX2 built binaries? Is that correct? |
|
18th March 2017, 14:28 | #5024 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,783
|
Correct: If your CPU does not support AVX2, you should not use a build compiled with options where AVX2 support is already assumed for the C++ parts of the code. It may crash somewhere due to unsupported opcodes or wrong assumptions about register widths.
|
18th March 2017, 14:28 | #5025 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
PS: Im really heavily interested to see a compare of x265 on Nano Server vs Server Core and Full Core
so fully headless without all the different reviewers overhead in place, those results can only be trusted very partially that we see here now being talked about especially on Windows Consumer OS.
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 Last edited by CruNcher; 18th March 2017 at 14:51. |
18th March 2017, 18:14 | #5026 | Link |
Registered User
Join Date: May 2015
Posts: 185
|
x265vs.exe --preset ultrafast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit encoded 600 frames in 6.06s (98.96 fps), 777.30 kb/s, Avg QP:35.01 x265gcc.exe --preset ultrafast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit encoded 600 frames in 6.11s (98.15 fps), 777.30 kb/s, Avg QP:35.01 0.81 fps delta. x265vs.exe --preset veryfast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit encoded 600 frames in 10.56s (56.81 fps), 892.48 kb/s, Avg QP:34.54 x265gcc.exe --preset veryfast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit encoded 600 frames in 10.71s (56.04 fps), 892.48 kb/s, Avg QP:34.54 0.77 fps delta. x265vs.exe --preset fast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit encoded 600 frames in 15.90s (37.74 fps), 933.94 kb/s, Avg QP:34.47 x265gcc.exe --preset fast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit encoded 600 frames in 16.16s (37.13 fps), 933.94 kb/s, Avg QP:34.47 0.61 fps delta. x265vs.exe --preset medium Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit encoded 600 frames in 25.89s (23.17 fps), 1098.05 kb/s, Avg QP:34.03 x265gcc.exe --preset medium Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit encoded 600 frames in 26.29s (22.82 fps), 1098.05 kb/s, Avg QP:34.03 0.35 fps delta. x265vs.exe --preset slow Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit encoded 600 frames in 47.79s (12.55 fps), 1101.31 kb/s, Avg QP:34.17 x265gcc.exe --preset slow Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit encoded 600 frames in 48.57s (12.35 fps), 1101.31 kb/s, Avg QP:34.17 0.20 fps delta. x265vs.exe --preset slower Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit encoded 600 frames in 134.03s (4.48 fps), 1175.77 kb/s, Avg QP:34.14 x265gcc.exe --preset slower Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit encoded 600 frames in 135.53s (4.43 fps), 1175.77 kb/s, Avg QP:34.14 0.05 fps delta. x265vs.exe --preset veryslow Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit encoded 600 frames in 222.69s (2.69 fps), 1183.63 kb/s, Avg QP:34.11 x265gcc.exe --preset veryslow Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit encoded 600 frames in 235.91s (2.54 fps), 1183.63 kb/s, Avg QP:34.11 0.15 fps delta. The differences are subtle as the preset "increases" but yes, it's there. I guess at this point, everything "counts". Maybe it was a one-time occurence but it appears --preset veryslow benefits the most from the improvements. Will require extended tests. PS: Tests were done on an i7-6700 (non K/non overclocked) 4c/8t@3.7GHz running Windows 10. Last edited by pingfr; 18th March 2017 at 18:28. |
18th March 2017, 21:34 | #5027 | Link |
Registered User
Join Date: May 2015
Posts: 185
|
This is a weird experiment but getting the same results again:
When using a VS compiled x265 against a GCC compiled x265, if running --preset veryslow, I'm getting a 0.14 fps to 0.15 fps speed delta compared to using a "lesser aggressive" preset such as --preset slower and an almost equal delta while using preset --slow. If this is confirmed using other source materials, it implies --preset veryslow has similar benefits to using --preset slow but an increased yield quality. That is, if you can stand and cope with the slow fps crunching overall. Would be good if anyone can run the same tests. |
18th March 2017, 21:38 | #5028 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
I think it is better to cite percentage improvements rather than raw fps deltas, since the base fps can vary so widely. |
|
19th March 2017, 01:52 | #5030 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
Jusr curious, is SAO improvements being looked in to? It's something which usually subjectively seems better turned off, which I realise shouldn't be the case. I have suspected in the past it may be because it is too strong?
|
19th March 2017, 09:47 | #5031 | Link |
Video compressionist
Join Date: Jun 2009
Location: Israel
Posts: 126
|
Question on mastering_display_colour_volume SEI.
From several posts where mastering_display_colour_volume SEI explained (e.g https://www.linkedin.com/pulse/hdr-1...carlos-carmona ) i can infer that the parameters max_display_mastering_luminance and min_display_mastering_luminance have to be calculated from input yuv-file or from 16/12 bit RGB TIFF. The algorithm is specified in a SMPTE document. Here is my question. x265 encoding (unless it is lossless) makes original frames and reconstructed ones to different. Hence, max_display_mastering_luminance and min_display_mastering_luminance may be incorrect on decoder's side (and hence on display's side). My question, should i re-compute max_display_mastering_luminance and min_display_mastering_luminance from reconstructed images or remain these parameters intact after encoding (i.e. remain them 'as-is' as computed from input raw data)? |
19th March 2017, 12:19 | #5032 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
Quote:
What you probably meant is MaxFALL and MaxCLL? In any case, the overall luminance of the image should not change from a lossy encoding (and even if it did, it would be miniscule changes at worst), so using the value you calculated on the original frames is fine.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
|
19th March 2017, 12:31 | #5033 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
Quote:
https://forum.doom9.org/showpost.php...&postcount=207 also some user here showed something similar with x265 output results where the entire lighting seem to have changed perceptually both are 10->8 bit conversion results Though i guess it's just that Intel is more efficient with it's chroma handling that lets it look like more pixels responsible for the indirect lighting where captured in the end and better preserved so overall a higher perceptual visible compression efficiency in the HDR space compared to Nvidia, or they just prefer to give chroma a higher per frame distribution priority to look closer to the source in HDR. or just a better 10->8 bit conversion origin uknown As you can clearly see the distribution differs and Nvidia seems to be psy wise investing into other parts then Intel does, quiete fascinating to see this without needing to measure the difference AMD and Nvidia seem pretty identical in their output only Intel differs on this specific part
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 Last edited by CruNcher; 19th March 2017 at 13:35. |
|
19th March 2017, 14:01 | #5034 | Link | |
Video compressionist
Join Date: Jun 2009
Location: Israel
Posts: 126
|
Quote:
What's about MaxCll? After encoding this value might be different from that obtained from source yuv or tiff. In my opinion, lossy encoding may cause non-negligible changes in min/max_display_mastering_luminance and MaxFall/MaxCll. Why? If a quantization rounding offset is less 0.5 in an encoder then reconstructed pixels tend to be smaller (leakage of energy). If the quantization rounding offset is above 0.5 then an opposite effect takes place. The quantization rounding offset is like a pump which either inhale or exhale "energy". Consequently, after encoding MaxFall/MaxCll may differ from those in the original file. |
|
20th March 2017, 04:39 | #5035 | Link |
Registered User
Join Date: Sep 2015
Posts: 48
|
x265 queries the CPU for what generation of SIMD it supports (AVX2, AVX, SSE4, MMX) at run-time and links the asm routines for the highest generation supported. So it shouldn't matter which generation you built on as long as it is x86.
Last edited by pradeeprama; 20th March 2017 at 09:04. Reason: Factual error |
20th March 2017, 23:27 | #5036 | Link |
Registered User
Join Date: Sep 2010
Posts: 2
|
I'm having problem with non English filename using StxRip on Windows 7 64, Codepage 1252/850.
Running avs2pipemod64.exe (version 1.1.1 - Aug 2016) it gives: Code:
avs2pipemod[error]: Import: couldn't open "B:\Programas\StaxRipTemp\S� corro_temp\S� corro.x265 - MKV - Super Low 26 - AAC - 22050 Hz.avs" I suspected avs2pipemod was the cause of problem, but it seems not. Greetings from me and Stax76. |
21st March 2017, 05:32 | #5037 | Link |
Registered User
Join Date: May 2002
Location: Milan, Italy
Posts: 79
|
Thanks for all the new efforts but one thing is not clear to me: is new table already fully implemented or just 8-bit? On all versions starting from?
Thanks Inviato dal mio GT-N7100 utilizzando Tapatalk |
21st March 2017, 06:32 | #5038 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
@need4speed
It's only available for 8bit encoding atm. Sent from my Samsung Galaxy S7 edge via Tapatalk
__________________
Do NOT re-post any of my Mediafire links. Download & re-host the content(s) if you want to share it somewhere else. |
|
|