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 25th February 2019, 05:12   #6761  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,009
It's not weird when you consider that Windows Server 2003 is subject to the same problem that Windows XP faces: the error is almost definitely coming from x265 expecting modern Windows APIs (read: NUMA). The 'not a valid x86 application' error doesn't occur when the assembly is wrong (in that case it would crash and throw a SIGILL), it occurs when you try to run 64-bit programs on 32-bit OSes (which in this case it's not; the executable and dll are standard 32-bit PE32) or other similar OS incompatibilities.

https://bitbucket.org/multicoreware/...eLists.txt-443
qyot27 is offline   Reply With Quote
Old 26th February 2019, 08:31   #6762  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 76
Hm.
Could it be that zones are broken in AU+7?
StaxRip crashes away for me with zones defined. AU+3 still worked.
(I'm using the VS 2019 Preview 3 AVX2 AU+7 build from http://msystem.waw.pl/x265/)
katzenjoghurt is offline   Reply With Quote
Old 26th February 2019, 10:20   #6763  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
Quote:
Originally Posted by katzenjoghurt View Post
Could it be that zones are broken in AU+7?
StaxRip crashes away for me with zones defined. AU+3 still worked.
Yes, it could. Second suspect is commit Integrate SVT-HEVC encoder to x265 (first suspect was innocent)

Proposed fix is (it is only technical change, I totally don't understand x265_copy_params function):
Code:
diff -r cb3e172a5f51 source/common/param.cpp
--- a/source/common/param.cpp	Tue Feb 19 20:20:35 2019 +0530
+++ b/source/common/param.cpp	Tue Feb 26 16:16:16 2019 +0100
@@ -2240,16 +2240,7 @@
     dst->rc.zoneCount = src->rc.zoneCount;
     dst->rc.zonefileCount = src->rc.zonefileCount;
 
-    if (src->rc.zones)
-    {
-        dst->rc.zones->startFrame = src->rc.zones->startFrame;
-        dst->rc.zones->endFrame = src->rc.zones->endFrame;
-        dst->rc.zones->bForceQp = src->rc.zones->bForceQp;
-        dst->rc.zones->qp = src->rc.zones->qp;
-        dst->rc.zones->bitrateFactor = src->rc.zones->bitrateFactor;
-    }
-    else
-        dst->rc.zones = NULL;
+    dst->rc.zones = src->rc.zones;
 
     if (src->rc.lambdaFileName) dst->rc.lambdaFileName = strdup(src->rc.lambdaFileName);
     else dst->rc.lambdaFileName = NULL;
Could you test if it helps? (compiled gcc 8.3 binary with this patch: test-Au7.7z)

Last edited by Ma; 26th February 2019 at 15:28.
Ma is offline   Reply With Quote
Old 26th February 2019, 12:48   #6764  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 76
Thx Ma... I'll try your version out as soon as I'm back from work (in 6 hours).

AU+7 crashed for me for two videos when I tried it out this morning just by setting
--zones 1,100,b=1.3

No crash any more after I replaced the exe with an older AU+3 version.
katzenjoghurt is offline   Reply With Quote
Old 26th February 2019, 13:02   #6765  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
Thanks for the info. The prime suspect is innocent (I am able to reproduce the problem) -- please ignore the patch and binary to test. We should investigate the problem further...
Ma is offline   Reply With Quote
Old 26th February 2019, 17:08   #6766  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
In x265 version 3.0_Au+5 there is new function x265_copy_params which I don't know what problem solves -- for sure it create new problems (zones for example).

My question is: if we remove x265_copy_params function and go back to old code (memcpy) is there something wrong? I've attached patch that revert changes with x265_copy_params function (maybe instead of patching this function it is better to remove it).
Attached Files
File Type: txt x265.patch.txt (16.1 KB, 20 views)
Ma is offline   Reply With Quote
Old 26th February 2019, 17:25   #6767  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 713
Quote:
Originally Posted by Boulder View Post
Has anyone else noticed how the bitrate shown during the encoding phase and the final bitrate differ from each other quite a lot sometimes? Yesterday I happened to be watching an 70000-frame encode finish and at the last frames, the average bitrate was ~6800 kbps. When the encode finished, the final bitrate was suddenly over 7100 kbps.
Happens to me too, even with a bigger deltas possibly (not sure, I use higher rates generally).
mandarinka is offline   Reply With Quote
Old 26th February 2019, 19:23   #6768  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 76
Hi Ma,

I fear I can't be of help finding an answer to your question but thanks a lot for looking into it! *thumbsup*

Last edited by katzenjoghurt; 26th February 2019 at 19:25.
katzenjoghurt is offline   Reply With Quote
Old 27th February 2019, 04:36   #6769  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 517
Quote:
Originally Posted by Wolfberry View Post
The only difference between Au+7 and Au+3 are SVT-HEVC (not enabled in the build you use) and the zone fix in linux (which probably breaks staxrip) (need to investigate further)

@FranceBB New test build Not Set SSE4.2
This one works, however I can't encode anything higher than 8bit (if I try to use Main10 it reverts back to the default bit-depth).
I remember that I had this kind of issue when I tried to compile x265 x86 with Visual Studio (I never managed to get 10bit and 12bit builds for x86 out of Visual Studio).

I tried now with a longer test, but encoding at 8bit this time, letting x265 calculate the average speed for me and feeding it with a 16bit uncompressed clip:

- GCC 8.2 SSE4.2

6.19fps

- Wolfberry not SSE4.2

6.14fps

- GCC 9 Preview SSE4.2

6.11fps

- LigH

6.22fps


However, encoding at 8bit and comparing different compilers shows different results, 'cause for 8bit x265 there are manually written intrinsics by x265 developers.
The interesting part is with 10bit for which there aren't manually written intrinsics, so it's up to the compiler to optimize the plain C++ code as much as possible, that's why I was testing them with Main10 in my previous test.
For the 8bit, apparently, GCC9 is still slower than GCC8, your build without targeting SSE4.2 is somewhere in-between and the one made by LigH is faster than mine for whatever reason.
But again, for 8bit there are manually written intrinsics, so I can't really test the effectiveness of compilers.
__________________
Broadcast Encoder

Last edited by FranceBB; 27th February 2019 at 04:40.
FranceBB is offline   Reply With Quote
Old 28th February 2019, 09:23   #6770  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
@katzenjoghurt
In new binaries from http://msystem.waw.pl/x265/ (ver. 3.0_Au+8) zones are working.

Now I must do some work for living but at the weekend I should look into this bug closer and prepare proper patch that works with SVT_HEVC too.
Ma is offline   Reply With Quote
Old 28th February 2019, 16:11   #6771  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,812
x265 3.0 Au+8-31ab7e09a3b5 (MSYS2, MinGW32 + GCC 7.4.0 / MinGW64 + GCC 8.3.0)

New 64-bit GCC 8.3.0, and zone issues should be fixed
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 28th February 2019, 18:58   #6772  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 76
Quote:
Originally Posted by Ma View Post
@katzenjoghurt
In new binaries from http://msystem.waw.pl/x265/ (ver. 3.0_Au+8) zones are working.

Now I must do some work for living but at the weekend I should look into this bug closer and prepare proper patch that works with SVT_HEVC too.
Yes! Wonderful! ... works like a charm for me again.
Immediately tried it out this morning but had to get to work as well (really quick) and was running out of time to post about it.

Thank you, Ma.

Last edited by katzenjoghurt; 28th February 2019 at 19:14.
katzenjoghurt is offline   Reply With Quote
Old 5th March 2019, 15:31   #6773  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 307
x265 v3.0_Au+9-2abd2a1909a4 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit-GCC v7.4.0 / 64bit-GCC v8.3.0)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 5th March 2019, 16:02   #6774  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 836
↑ @Barough: many for the new build
filler56789 is offline   Reply With Quote
Old 10th March 2019, 15:59   #6775  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 307
x265 v3.0_Au+14-c7e5878bdd31 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit-GCC v7.4.0 / 64bit-GCC v8.3.0)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 13th March 2019, 13:48   #6776  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,812
x265 3.0 Au+14-c7e5878bdd31 (MSYS2, MinGW32 + GCC 7.4.0 / MinGW64 + GCC 8.3.0)

3 flavours:
  • "Win32XP" (XP compatibility enabled, should disable NUMA support)
  • "Win32" (XP compatibility disabled, NUMA support should be enabled in Win7+)
  • "Win64"

AVX2 for normFactor and ssimDistortion
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 30th March 2019, 04:50   #6777  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 836
x265.exe 3.0_Au+16-0018ca1ca42f

(GCC 7.4.0, 64-bits, multilib)

http://www.mediafire.com/file/gtr4eh...018ca1ca42f.7z
filler56789 is offline   Reply With Quote
Old 14th April 2019, 21:19   #6778  |  Link
Forteen88
Herr
 
Join Date: Apr 2009
Location: North Europe
Posts: 331
@Wolfberry. You're not releasing a ICC19-compile of x265 anymore?
Forteen88 is offline   Reply With Quote
Old Today, 06:22   #6779  |  Link
Wolfberry
Helenium(Easter)
 
Wolfberry's Avatar
 
Join Date: Aug 2017
Location: Hsinchu, Taiwan
Posts: 94
x265-3.0_Au+21-bac0e1acb874-win64-multilib

Code:
x265 [info]: build info [Windows][GCC 8.3.1][64 bit] 8bit+10bit+12bit
x265 [info]: (libavcodec  58.51.100)
x265 [info]: (libavformat 58.27.102)
x265 [info]: (libavutil   56.26.100)
x265 [info]: (lsmash       2.16.1)
Compiled with LAVF & LSMASH support, patches from msg7086.
__________________
Monochrome Anomaly
Wolfberry 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:19.


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