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.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th March 2017, 12:16   #5021  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by Ma View Post
VS 2017 with options /GS- /GL (at least).
Quote:
Originally Posted by Sagittaire View Post
I make little comparison with ICC, GCC 7.0 and VS 2017: VS 2017 seem produce better speed for x265.
So far that's at least two different doom9'ers who have confirmed Visual Studio 2017 is the way to go.

Need a third one to confirm the trend.

Anyone else?
pingfr is offline   Reply With Quote
Old 18th March 2017, 13:51   #5022  |  Link
NikosD
Registered User
 
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,337
Quote:
Originally Posted by pingfr View Post
Need a third one to confirm the trend.

Anyone else?
There is a third one here:
http://forum.doom9.org/showthread.php?p=1800781
__________________
Win 10 x64 (17134.1) - Core i3-4170/ iGPU HD 4400 (v.4835)
HEVC decoding benchmarks
H.264 DXVA Benchmarks for all
NikosD is offline   Reply With Quote
Old 18th March 2017, 14:09   #5023  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
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.
CruNcher is offline   Reply With Quote
Old 18th March 2017, 14:21   #5024  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by NikosD View Post
Thanks for pointing that out.

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?
pingfr is offline   Reply With Quote
Old 18th March 2017, 14:28   #5025  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,300
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.
__________________

German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 18th March 2017, 14:28   #5026  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
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.
CruNcher is offline   Reply With Quote
Old 18th March 2017, 18:14   #5027  |  Link
pingfr
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.
pingfr is offline   Reply With Quote
Old 18th March 2017, 21:34   #5028  |  Link
pingfr
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.
pingfr is offline   Reply With Quote
Old 18th March 2017, 21:38   #5029  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,424
Quote:
Originally Posted by pingfr View Post
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.

I think it is better to cite percentage improvements rather than raw fps deltas, since the base fps can vary so widely.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Instant Video

My Compression Book

Amazon Instant Video is hiring! PM me if you're interested.
benwaggoner is offline   Reply With Quote
Old 18th March 2017, 22:39   #5030  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by benwaggoner View Post
I think it is better to cite percentage improvements rather than raw fps deltas, since the base fps can vary so widely.
Yes but still can anyone run the tests and run them with --preset placebo as well?
pingfr is offline   Reply With Quote
Old 19th March 2017, 01:52   #5031  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,235
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?
burfadel is offline   Reply With Quote
Old 19th March 2017, 09:47   #5032  |  Link
Shevach
Video compressionist
 
Join Date: Jun 2009
Location: Israel
Posts: 115
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)?
Shevach is offline   Reply With Quote
Old 19th March 2017, 12:19   #5033  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,239
Quote:
Originally Posted by Shevach View Post
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)?
min/max_display_mastering_luminance describe the display which was used to master this content, not the content itself.
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
nevcairiel is offline   Reply With Quote
Old 19th March 2017, 12:31   #5034  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
Quote:
Originally Posted by nevcairiel View Post
min/max_display_mastering_luminance describe the display which was used to master this content, not the content itself.
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.
Like this ?

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.
CruNcher is offline   Reply With Quote
Old 19th March 2017, 14:01   #5035  |  Link
Shevach
Video compressionist
 
Join Date: Jun 2009
Location: Israel
Posts: 115
Quote:
Originally Posted by nevcairiel View Post
min/max_display_mastering_luminance describe the display which was used to master this content, not the content itself.
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.
Thanks for a prompt reply. Frankly speaking i meant both min/max_display_mastering_luminance (signaled in MasteringDisplayColorVolume SEI) and MaxCLL/MaxFall (signaled in Content Light Level SEI).
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.
Shevach is offline   Reply With Quote
Old 20th March 2017, 04:39   #5036  |  Link
pradeeprama
Registered User
 
Join Date: Sep 2015
Posts: 46
Quote:
Originally Posted by LigH View Post
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.
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
pradeeprama is offline   Reply With Quote
Old 20th March 2017, 23:27   #5037  |  Link
jairovital
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"
Talking with its author, Stax76, he said that since it works with x264, probably x265 could be the cause of problem, once we need to implement an avifile/avisynth/vapoursynth reader. "All of Rigaya's hardware encoders have direct support for avs and vpy, x264, so it supports at least avs".

I suspected avs2pipemod was the cause of problem, but it seems not.

Greetings from me and Stax76.
jairovital is offline   Reply With Quote
Old 21st March 2017, 05:32   #5038  |  Link
need4speed
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
need4speed is offline   Reply With Quote
Old 21st March 2017, 06:32   #5039  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 279
@need4speed
It's only available for 8bit encoding atm.

Sent from my Samsung Galaxy S7 edge via Tapatalk
Barough is offline   Reply With Quote
Old 21st March 2017, 09:35   #5040  |  Link
need4speed
Registered User
 
Join Date: May 2002
Location: Milan, Italy
Posts: 79
Quote:
Originally Posted by Barough View Post
@need4speed
It's only available for 8bit encoding atm.

Sent from my Samsung Galaxy S7 edge via Tapatalk
Thanks, just for confirmation: do not need to point to any external table, correct?


Inviato dal mio GT-N7100 utilizzando Tapatalk
need4speed is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 20:45.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.