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 26th February 2019, 20:23   #6761  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 128
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 20:25.
katzenjoghurt is offline   Reply With Quote
Old 27th February 2019, 05:36   #6762  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
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.

Last edited by FranceBB; 27th February 2019 at 05:40.
FranceBB is online now   Reply With Quote
Old 28th February 2019, 10:23   #6763  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
@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, 17:11   #6764  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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, 19:58   #6765  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 128
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 20:14.
katzenjoghurt is offline   Reply With Quote
Old 5th March 2019, 16:31   #6766  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
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, 17:02   #6767  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
↑ @Barough: many for the new build
filler56789 is offline   Reply With Quote
Old 10th March 2019, 16:59   #6768  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
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, 14:48   #6769  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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, 05:50   #6770  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
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   #6771  |  Link
Forteen88
Herr
 
Join Date: Apr 2009
Location: North Europe
Posts: 556
@Wolfberry. You're not releasing a ICC19-compile of x265 anymore?
Forteen88 is offline   Reply With Quote
Old 21st April 2019, 09:13   #6772  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by Wolfberry View Post
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.
Your build doesn't work on 64-bit Windows 7, it simply crashes
filler56789 is offline   Reply With Quote
Old 21st April 2019, 11:26   #6773  |  Link
lvqcl
Registered User
 
Join Date: Aug 2015
Posts: 293
Quote:
Originally Posted by filler56789 View Post
Your build doesn't work on 64-bit Windows 7, it simply crashes
I suspect that the problem is not an OS. Probably your CPU doesn't support AVX (or AVX2?), and this build requires it for some reason.
lvqcl is offline   Reply With Quote
Old 21st April 2019, 15:40   #6774  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by Wolfberry View Post
Yeah, that build requires AVX.

New build

Code:
x265 [info]: HEVC encoder version 3.0_Au+21-bac0e1acb874
x265 [info]: build info [Windows][GCC 8.3.1][64 bit] 8bit+10bit+12bit
x265 [info]: (libavcodec  58.52.100)
x265 [info]: (libavformat 58.27.103)
x265 [info]: (libavutil   56.26.100)
x265 [info]: (lsmash       2.16.1)
I'm using march=core2 for this build (I use --with-arch=core2 when configuring gcc), so it should work for most people, but no guarantee as I don't have a spare machine to test.
Thanks for the compatible build

It is somewhat bloated because of the additional stuff, but I compressed it with upx and now it has a healthy weight.

Last edited by filler56789; 21st April 2019 at 16:58. Reason: damn typos :-/
filler56789 is offline   Reply With Quote
Old 25th April 2019, 18:52   #6775  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
How does one get rid of the "onion gradient" artifacts of x265? In the sample images, they are apparent in the character's forehead and also in the purplish stripe near his hair (zoom a bit to see both better). The bitrate of the encodes is ~6900 kbps.

x264


x265, aq-mode 1


x265, aq-mode 2


Some base settings of the x265 encode:
Code:
--deblock -2:-1 --no-strong-intra-smoothing --cbqpoffs -3 --crqpoffs -3 --subme 3 --merange 24 --no-sao --no-rect --qcomp 0.7 --rd 6 --rd-refine
--aq-mode 1/aq-mode 2 --aq-strength 0.9 --ctu 16 --max-tu-size 8 --qg-size 16 --tu-inter-depth 2 --tu-intra-depth 2 --limit-tu 1 --limit-refs 3
--max-merge 2 --ref 5 --bframes 10
The x264 settings are pretty much --preset veryslow --tune film --no-fast-pskip --no-dct-decimate --deblock -2:-1 --qcomp 0.7.
__________________
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 26th April 2019, 10:02   #6776  |  Link
mini-moose
Registered User
 
Join Date: Oct 2007
Posts: 385
Quote:
Originally Posted by Boulder View Post
How does one get rid of the "onion gradient" artifacts of x265? In the sample images, they are apparent in the character's forehead and also in the purplish stripe near his hair (zoom a bit to see both better).
Maybe post a source cap too.
mini-moose is offline   Reply With Quote
Old 26th April 2019, 16:46   #6777  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Boulder View Post
How does one get rid of the "onion gradient" artifacts of x265? In the sample images, they are apparent in the character's forehead and also in the purplish stripe near his hair (zoom a bit to see both better).

Some base settings of the x265 encode:
Code:
--deblock -2:-1 --no-strong-intra-smoothing --cbqpoffs -3 --crqpoffs -3 --subme 3 --merange 24 --no-sao --no-rect --qcomp 0.7 --rd 6 --rd-refine
--aq-mode 1/aq-mode 2 --aq-strength 0.9 --ctu 16 --max-tu-size 8 --qg-size 16 --tu-inter-depth 2 --tu-intra-depth 2 --limit-tu 1 --limit-refs 3
--max-merge 2 --ref 5 --bframes 10
The x264 settings are pretty much --preset veryslow --tune film --no-fast-pskip --no-dct-decimate --deblock -2:-1 --qcomp 0.7.
You are doing some weird settings in there which may have combinatorial effects. Can you try just --preset slower and see how that turns out?

A 8x8 max tu is pretty unusual, and those are also big chroma offsets which can suck bits away from luma. What are the goals of these settings, and how tdid you come to them?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 27th April 2019, 10:01   #6778  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
I got you the original clip here. I basically did a very slight MDegrain and then downscaled to 1280x720 using a very sharp Bicubic and fed to the encoders.

https://drive.google.com/open?id=1Qm...9NZavzXFTSkGIr

My x265 settings are based on frame-by-frame comparisons that I made several times. A small CTU and TU size look better (least distortion compared to the original image) with 720p encodes. For 1080p, I would use one notch higher values (also based on my tests). The chroma offsets don't change the bitrate much in CRF mode so the difference in 2-pass shouldn't also be big. Besides, x264 already does a similar thing by default.

EDIT: does anyone else have problems with topic notifications? I don't get any emails at all from any thread I've subscribed to.
__________________
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 27th April 2019, 10:54   #6779  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 322
Quote:
Originally Posted by Boulder View Post
I got you the original clip here. I basically did a very slight MDegrain and then downscaled to 1280x720 using a very sharp Bicubic and fed to the encoders.

https://drive.google.com/open?id=1Qm...9NZavzXFTSkGIr

My x265 settings are based on frame-by-frame comparisons that I made several times. A small CTU and TU size look better (least distortion compared to the original image) with 720p encodes. For 1080p, I would use one notch higher values (also based on my tests). The chroma offsets don't change the bitrate much in CRF mode so the difference in 2-pass shouldn't also be big. Besides, x264 already does a similar thing by default.

EDIT: does anyone else have problems with topic notifications? I don't get any emails at all from any thread I've subscribed to.
Dont seem to be an "general" issue with x265. Did a re-encode of your sample and I didnt get an gradiant issue, and overall I think x265 did a better job. I think benwaggoner is right, its your settings thats causing it.

x264 2pass @ 5Mbps, veryslow tune film


x265 2pass @ 5Mbps, slow, --no-sao --no-strong-intra-smoothing --deblock -1:-1

Last edited by excellentswordfight; 27th April 2019 at 11:00.
excellentswordfight is offline   Reply With Quote
Old 27th April 2019, 18:59   #6780  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by excellentswordfight View Post
Dont seem to be an "general" issue with x265. Did a re-encode of your sample and I didnt get an gradiant issue, and overall I think x265 did a better job. I think benwaggoner is right, its your settings thats causing it.
Thanks, that's exactly what I was looking for since I was experimenting a lot with aq-strength and the psy options to try to figure out what is wrong but was clearly looking in the wrong place.

I did some more testing now that I found those troublesome frames (it seems they evaded me when I pinpointed my go-to settings a long time ago), and using CTU 32 makes the onionize effect go away. I also left max-tu-size and qg-size at their defaults since things looked good.
__________________
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
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 15:54.


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