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 24th March 2017, 09:17   #5061  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 46
Quote:
Originally Posted by pingfr View Post
Thanks for making that table re-cycling the data I pasted a few days ago, glad it served a purpose.

Although it is missing the placebo preset.

I just can't be bothered waiting 45 minutes to run each placebo encodes.
You could run the placebo encodes on a very short clip, maybe trimmed from your original clip.
aymanalz is offline   Reply With Quote
Old 24th March 2017, 10:06   #5062  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,715
Quote:
Originally Posted by aymanalz View Post
Isn't that the relevant metric? By what percent one is faster than the other?
Its the same metric, just a different way to express it.
Declaring GCC to be the reference at 100%, then this gives you the numbers above for VS2017 - easy enough to read the increases out of.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 24th March 2017, 12:05   #5063  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by nevcairiel View Post
Its the same metric, just a different way to express it.
Declaring GCC to be the reference at 100%, then this gives you the numbers above for VS2017 - easy enough to read the increases out of.
Regardless a 5.91% speed increase is nothing to be "ashamed of".
pingfr is offline   Reply With Quote
Old 25th March 2017, 02:45   #5064  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 386
Quote:
Originally Posted by LigH View Post
Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.



With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.
I agree on this. Generally MSVC builds is consistently better. I have been comparing the performance for every new release of x265 and found this to be true.
nakTT is offline   Reply With Quote
Old 25th March 2017, 09:04   #5065  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,836
I decided to keep building with GCC still, I believe that an advantage of <2% is no reason to abandon it, and furthermore, installing Visual Studio seens to be much more elaborate than using an MSYS environment, just for this small task and nothing else...

But I don't mind other people publishing MSVC builds. More choice!
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 25th March 2017, 11:53   #5066  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
Please dont freaking forget the compiler is Windows only GCC has to be Multiplatform that is a different bread to crunch entirely, in balancing and overall performance on every Posix OS and different ARCHs running on them.
__________________
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; 25th March 2017 at 11:56.
CruNcher is offline   Reply With Quote
Old 25th March 2017, 12:10   #5067  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
The speed comparison of different x265 builds is not so simple.
Let's say that we want compare speed of encoding file "Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m" at preset medium to 8-bit hevc (like in pingfr test, but only for preset medium).

There are many CPUs on the world, so we compare encoding speed with different '--asm' levels (from false [= --no-asm] to AVX).
gcc63s2 means GCC 6.3 build that works on SSE2 CPU (which is 'none' for Win64)
gcc70s3 means GCC 7.0 build for SSSE3 CPUs and better
gcc70s4 means GCC 7.0 build for SSE4.1 CPUs and better
vs2017a1 means VS 2017 build for AVX CPUs and better.
(There are no AVX2 builds -- my CPU is only with AVX.)

Relative encoding speed on Win7 64-bit, i5 3450S, RAM DDR3 1600:
Code:
 --asm= | false .|. SSE2 .| SSSE3 .| SSE4.1 | AVX
--------|--------|----------------------------------
gcc63s2 |100.00% |100.00% |100.00% |100.00% |100.00%
gcc70s2	| +4.63% | +4.12% | +4.81% | +0.56% | +0.61%
gcc70s3	| +8.47% | +5.14% | +5.74% | +0.04% | +0.14%
gcc70s4	|+11.57% | +8.06% | +6.90% | +0.16% | -0.42%
vs2017s2|-19.66% |-21.68% |-30.75% | +1.07% | +0.87%
vs2017a1|-18.77% |-20.90% |-29.68% | +2.48% | +2.45%
Some remarks:
1) gcc70s4 build is the fastest with '--no-asm' option but is the slowest with '--asm=avx' option.

2) VS 2017 builds are very slow on CPUs <= SSSE3, the switch is on SSE4.1 level.

3) GCC 7.0 builds are a little bit faster than GCC 6.3 builds.

4) My i5 3450S is surprisingly slower than pingfr's i7 6700 -- 12.34 fps to 23.17 fps.

5) The speed difference from '--asm=sse4' to '--asm=avx' is minimal (12.30 fps to 12.34 fps; full data in attachment).
Attached Files
File Type: txt screen.txt (50.6 KB, 7 views)
File Type: txt t.bat.txt (212 Bytes, 16 views)
Ma is offline   Reply With Quote
Old 25th March 2017, 12:20   #5068  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,477
Quote:
Originally Posted by LigH View Post
I decided to keep building with GCC still, I believe that an advantage of <2% is no reason to abandon it, and furthermore, installing Visual Studio seens to be much more elaborate than using an MSYS environment, just for this small task and nothing else...

But I don't mind other people publishing MSVC builds. More choice!
I second that. Visual Studio is a nightmare, tons of bloat in the registry and needless services. It's okay and a must-have for professional programmers, but I am not a professional programmer, I'm just a not-so-advanced ordinary user.

@Ma:
many thanks for the useful post

That's exactly what I was thinking, but I didn't have any empirical evidence
Midzuki is offline   Reply With Quote
Old 25th March 2017, 13:53   #5069  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by Ma View Post
4) My i5 3450S is surprisingly slower than pingfr's i7 6700 -- 12.34 fps to 23.17 fps.
And why would this be "surprising" at any rates? You're comparing an i7 against an i5 and furthermore a CPU from the 6th generation against one from the 3rd generation which furthermore is an "S" CPU targeted at semi-embedded low-power users?

Unless I missed something here...

Even though, the point I was trying to make a few days ago regarding these tests was that for "some obscure" reasons --preset veryslow was giving us the biggest increase when switching from a GCC build to a VS2017 build compared to a supposedly much faster (but therefore having less optimized settings) preset such as --preset medium and that is where things needed further investigations.
pingfr is offline   Reply With Quote
Old 25th March 2017, 13:54   #5070  |  Link
shinchiro
Registered User
 
Join Date: Feb 2012
Posts: 46
@Ma thanks for the detailed test. btw the gcc is built with posix or win32 threads?
shinchiro is offline   Reply With Quote
Old 25th March 2017, 14:22   #5071  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
Quote:
Originally Posted by pingfr View Post
And why would this be "surprising" at any rates? You're comparing an i7 against an i5 and furthermore a CPU from the 6th generation against one from the 3rd generation which furthermore is an "S" CPU targeted at semi-embedded low-power users?
There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.

@shinchiro: win32 threads
Ma is offline   Reply With Quote
Old 25th March 2017, 14:50   #5072  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by Ma View Post
There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.
Okay I see.

Also some benchmarks have been somewhat leaked regarding a 3.6GHz upcoming AMD Ryzen with... 16 cores. So you might want to hold your breath a little longer before buying a newer CPU.
pingfr is offline   Reply With Quote
Old 25th March 2017, 15:26   #5073  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
Quote:
Originally Posted by Ma View Post
There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.

@shinchiro: win32 threads
More impressive it becomes if you look @ it Realtime doing the Decoding instead of the Encoding which is harder to grasp visually
__________________
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; 25th March 2017 at 15:29.
CruNcher is offline   Reply With Quote
Old 25th March 2017, 16:12   #5074  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Quote:
Originally Posted by CruNcher View Post
More impressive it becomes if you look @ it Realtime doing the Decoding instead of the Encoding which is harder to grasp visually
Me no understanderino you.
pingfr is offline   Reply With Quote
Old 25th March 2017, 16:50   #5075  |  Link
easyfab
Registered User
 
Join Date: Jan 2002
Posts: 327
@Ma could you test this build https://www.sendspace.com/file/biunt6

GCC 6.3 but fprofile with my i2600k

Last edited by easyfab; 25th March 2017 at 16:57.
easyfab is offline   Reply With Quote
Old 25th March 2017, 16:55   #5076  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,836
@ easyfab:

Look how to avoid an unnecessary full-quote...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 25th March 2017, 17:57   #5077  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
Quote:
Originally Posted by easyfab View Post
@Ma could you test this build https://www.sendspace.com/file/biunt6

GCC 6.3 but fprofile with my i2600k
normal GCC 6.3 = 100%
Code:
 --asm=	|SSSE3	|SSE4.1	|AVX
gcc63s2	|100.00%|100.00%|100.00%
gcc70s2	| +5.00%| +0.54%| +0.83%
gcc63pr	|-36.29%| +1.89%| +1.46%
vs2017s2|-30.60%| +0.99%| +0.87%
At SSSE3 level your profiled version is very slow but it is OK -- when you profile the functions that are not executed are compiled for minimize size.

At SSE4.1 level you speed-up +1.89% to normal GCC 6.3 build -- it is better than VS 2017 build (but a bit slower than VS 2017 AVX build). So it is the fastest version that you can execute.
Attached Files
File Type: txt screen2.txt (20.3 KB, 9 views)
Ma is offline   Reply With Quote
Old 25th March 2017, 18:06   #5078  |  Link
easyfab
Registered User
 
Join Date: Jan 2002
Posts: 327
@Ma Thanks for the report

I will try with GCC 7 to see if it better.
easyfab is offline   Reply With Quote
Old 25th March 2017, 19:33   #5079  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,531
Does x265 have framerate-aware ratecontrol like x264 does?

http://git.videolan.org/gitweb.cgi?p...f05ad1f861a855

I was just wondering if I should run into material that needs to be encoded at double framerate. Many concerts are encoded as interlaced and I use QTGMC on them to get high quality progressive output at double framerate.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 25th March 2017, 19:37   #5080  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,374
Yes. (But I don't think you can supply timecodes to the CLI for VFR.)
sneaker_ger 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:02.


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