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. |
16th September 2019, 13:11 | #7022 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
Using the latest VS2019 AVX build (3.1+19-c4b098f) from here: http://msystem.waw.pl/x265/ crashes the encoder in the beginning. Does anyone else have the same issue? I'm using a Ryzen 1800X with AVX2 disabled in the x265 command line.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... Last edited by Boulder; 16th September 2019 at 13:16. |
17th September 2019, 10:26 | #7023 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Quote:
But if SAO detail loss varies somewhat by frame type, only using it on intra stuff might enhance detail with less of a compression efficiency hit than turning it off outright. |
|
18th September 2019, 12:59 | #7024 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,784
|
The media-autobuild suite now introduced experimental support for ccache.
About at the same time, I have issues building a multilib x265 encoder with the manually fiddled build script which usually worked for years already. But building in MABS passes without error. I am not sure if I have too many linking flags which may interfere with either ccache or with the current development state of x265. It fails linking the DLL: Code:
[ 84%] Linking CXX shared library libx265.dll E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x2c): undefined reference to `x265::setupIntrinsicDCT_sse3(x265::EncoderPrimitives&)' E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x39): undefined reference to `x265::setupIntrinsicDCT_ssse3(x265::EncoderPrimitives&)' E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x4f): undefined reference to `x265::setupIntrinsicDCT_sse41(x265::EncoderPrimitives&)' collect2.exe: error: ld returned 1 exit status |
19th September 2019, 06:35 | #7025 | Link |
Registered User
Join Date: May 2015
Posts: 68
|
Is it normal that x265 is about 20% slower on a Zen+ CPU than a Haswell, even though the Zen+ has a higher clock speed? I remember comments here about the AVX2 in AMD being only half as fast (?) as that in Intel, or something to that effect. Could that be the reason? Or could it be that the x265 developers haven't optimized the code for AMD as much as they have for Intel? It is a bit surprising, because this Zen+ architecture is from late 2018, a good few years later than Haswell.
|
19th September 2019, 08:46 | #7026 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
Quote:
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
|
19th September 2019, 16:20 | #7027 | Link | |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
Quote:
Zen+ has a slower implementation of AVX2 than Haswell onwards, but x265 is also optimized for Intel and favors Intel vs AMD. Actually, Intel published a paper along with x265 developers working together for AVX-512 optimizations (Intel-only) but they didn't manage to succeed in this, AVX-512 is so ineffective for x265 that most of the times you have to disable it according to Intel, not me. x265 is an Intel-friendly project but Zen 2 architecture and Ryzen 3000 series managed to be a lot faster in x265 and beat Intel in its own favorite H.265 encoder.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
|
19th September 2019, 20:14 | #7028 | Link |
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
x265.exe 3.2_RC1+1-00d8df1b3bc6
(x64, multilib, GCC 9.2.0, upxed) http://www.mediafire.com/file/k72pa2...b3bc6.rar/file |
21st September 2019, 09:56 | #7034 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,816
|
Improvements in Zen2 architecture are huge!
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
22nd September 2019, 19:02 | #7036 | Link | |
Registered User
Join Date: May 2009
Posts: 331
|
Quote:
https://forum.doom9.org/showthread.php?t=175476 https://www.reddit.com/r/programming...wn_your_cpu_a/ |
|
23rd September 2019, 07:59 | #7037 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
Quote:
Can any of the devs (or anyone else, of course) explain why the combination "umh, umh, star" is clearly the fastest one? Without HME, the star method is clearly faster so I would expect "star, star, star" to be the fastest one with HME.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
24th September 2019, 14:56 | #7038 | Link | |
Registered User
Join Date: Oct 2007
Posts: 385
|
Quote:
Also, HME, is that a good feature to use? Last edited by mini-moose; 24th September 2019 at 16:12. |
|
24th September 2019, 15:22 | #7039 | Link | |
Registered User
Join Date: May 2015
Posts: 68
|
Quote:
Is Star a better method than umh in terms of: 1) Quality 2) Speed 3) Quality and speed I's also like to take this opportunity to point out that there is a dearth of easily understandable documentation for x265. By that, I mean something for dummies like me. There are so many elementary questions that I cannot find answers to, despite all my googling. |
|
24th September 2019, 18:25 | #7040 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
There's something broken in the latest versions, I've now tried two different builds but both have the same problem.
y4m [info]: 1920x1080 fps 24000/1001 i420p16 sar 1:1 unknown frame count raw [info]: output file: f:\temp\captures\testclip.hevc Error: fwrite() call failed when writing frame: 4, plane: 0, errno: 32 Output 22 frames in 1.66 seconds (13.23 fps) This is just by loading the source in a Vapoursynth script and feeding it to x265 with vspipe. Many other clips work just fine. The clip that causes this one can be found here: https://drive.google.com/open?id=1AU...FwqqFfOZLgNr4M x265-3.1+14 works fine.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
|