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 30th July 2018, 13:31   #6241  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,935
A value of 64 was only recommended for UHD material and has caused known over-blurring issues in the history of x265; I am not sure if they were completely fixed. 32 used to be a default; 16 may even be a bit pessimistic.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 30th July 2018, 13:41   #6242  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 71
Quote:
Originally Posted by LigH View Post
A value of 64 was only recommended for UHD material and has caused known over-blurring issues in the history of x265; I am not sure if they were completely fixed. 32 used to be a default; 16 may even be a bit pessimistic.
Its an UHD source
I tried a value of 16 to see if its better (would've tried 32 afterwards to see if its good enough).

Anyway, setting it to 16 made the artifacts smaller and thus a bit less obvious, but they still annoy me...

Right now I'm doing an encode with strong intra smoothing to see if that maybe helps...

Going to try an higher AQ strength after that but I'm affraid that's going to boost the bit rate a bit too much since it also affects areas that are already good enough (if im not mistaken?)...
K.i.N.G is offline   Reply With Quote
Old 30th July 2018, 13:52   #6243  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,595
Quote:
Originally Posted by LigH View Post
A value of 64 was only recommended for UHD material and has caused known over-blurring issues in the history of x265; I am not sure if they were completely fixed. 32 used to be a default; 16 may even be a bit pessimistic.
I started using 16 after I switched to --ctu 32.
__________________
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 31st July 2018, 03:36   #6244  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,413
Quote:
Originally Posted by K.i.N.G View Post
I really like x265 but I seem to be unable to get rid of linear smearing/stretching artifacts when there are fast moving objects in a scene.
Is there a specific parameter targeted at improving this, without increasing the bit rate in other areas (those are fine)?

My settings are:
--crf 17 --preset veryslow --profile main10 --level-idc 5 --output-depth 10 --psy-rdoq 4 --aq-mode 3 --qg-size 64 --qcomp 0.7 --subme 5 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --max-cll "457,179" --hdr --hdr-opt --deblock -1:-1 --no-sao --no-strong-intra-smoothing

example:
The only way to get x265 to retain detail/grain in absolutely all circumstances is --tune grain combined with enough bitrate to not starve it. That will massively change but the bitrate and distribution of your entire movie, not a first choice if you're happy with the rest.

I noticed you raised qcomp to 0.7 from the default 0.6, effectively telling x265, "I want fast-motion and difficult-to-compress scenes compressed harder than usual." Was there a specific reason for raising it?

Lastly, are you sure you're not fixating on three frames that in motion will be utterly unnoticeable everyone who actually watches? It's a very common ailment when you go down the rabbit hole of settings. You have to balance frame analysis, especially in "fast moving objects" scenes, with real-life watching of a whole whole scene.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis is offline   Reply With Quote
Old 31st July 2018, 04:56   #6245  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 50
Quote:
Originally Posted by alex1399 View Post
I've got some 60fps video materials with wrongly encoded frame-rate which has lots of duplicated frames.
OK, seems like I underestimated the benefit from cranking up --bframes. Provides 5% bit-rate reduction with the same quality.
The options are
--preset slower --tune psnr --profile main --ctu 32 --keyint 600 --scenecut 30 --rc-lookahead 48 --bframes 16 --qg-size 16 --pass * --qpstep 10 --range limited

Note that --tune psnr is removed in advance.
alex1399 is offline   Reply With Quote
Old 31st July 2018, 08:15   #6246  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 71
Quote:
Originally Posted by foxyshadis View Post
The only way to get x265 to retain detail/grain in absolutely all circumstances is --tune grain combined with enough bitrate to not starve it. That will massively change but the bitrate and distribution of your entire movie, not a first choice if you're happy with the rest.

I noticed you raised qcomp to 0.7 from the default 0.6, effectively telling x265, "I want fast-motion and difficult-to-compress scenes compressed harder than usual." Was there a specific reason for raising it?

Lastly, are you sure you're not fixating on three frames that in motion will be utterly unnoticeable everyone who actually watches? It's a very common ailment when you go down the rabbit hole of settings. You have to balance frame analysis, especially in "fast moving objects" scenes, with real-life watching of a whole whole scene.
Well I mentioned it is specifically a fast moving scenes/objects I am having trouble with...
Maybe I should try actually raising it even more to 0.8

It's not really noticable on my monitor, but when viewed on a 65" oled I got a bit annoyed by it...

Even with 1080p encodes with average bitrates around 7000 I still notice it sometimes.
I can't speak for anyone else, but to me it looks very ugly and in some cases it is really noticible.


Also, not related to this (i think), when encoding HDR content with x265 it seems as if the adaptive algorithms don't take the tonemapping/different contrast handling of HDR footage into account?
What i mean is that when you play HDR content on a non-HDR display, it looks really flat and it seems to me this is how the footage gets analyzed by x265's CRF/VBR which results in an out of balance preservation of detail in flat areas.
When the encoded footage is played back on a HDR screen, I get the impression there is more loss in detail in low contrast areas than usual...
I hope you guys understand what I mean? It's like x265 doesnt take the contrast adjustments of HDR content into account.
Already started a separate thread about this, but maybe I should've posted this here aswell...

Last edited by K.i.N.G; 31st July 2018 at 08:30.
K.i.N.G is offline   Reply With Quote
Old 31st July 2018, 09:32   #6247  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,595
Quote:
Originally Posted by foxyshadis View Post
I noticed you raised qcomp to 0.7 from the default 0.6, effectively telling x265, "I want fast-motion and difficult-to-compress scenes compressed harder than usual."
This is a bit strange. When you raise qcomp, the bitrate gets substantially higher with CRF mode. Shouldn't it be the opposite?
__________________
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 31st July 2018, 09:50   #6248  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 71
Oh damn, i miss-read... so qcomp compresses harder?
But that also makes no sense to me since it does indeed result in higher bit rates (at same CRF) and improves quality concerning my fast motion artifacts issue...
K.i.N.G is offline   Reply With Quote
Old 31st July 2018, 09:53   #6249  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,935
From Xvid I remember a "quantizer curve compression", there it changed the quantizer distribution character. I believe it is still true to some extent for x265. From the official documentation:

Command line options: --qcomp <float>
Quote:
qComp sets the quantizer curve compression factor. It weights the frame quantizer based on the complexity of residual (measured by lookahead). Default value is 0.6. Increasing it to 1 will effectively generate CQP
CQP doesn't care about the complexity = degree of details in a quantized unit; frame parts with higher complexity will probably survive a coarser quantization better than parts with less details, banding will become more obvious where it is not cut by an edge or covered by a pattern.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 31st July 2018, 10:00   #6250  |  Link
Wolfberry
Helenium(Easter)
 
Wolfberry's Avatar
 
Join Date: Aug 2017
Location: Hsinchu, Taiwan
Posts: 99
Quote:
Originally Posted by Wolfberry View Post
qcomp trades off the number of bits allocated to "expensive" high-motion versus "cheap" low-motion frames. At one extreme, qcomp=0 aims for true constant bitrate (CBR). Typically this would make high-motion scenes look completely awful, while low-motion scenes would probably look absolutely perfect, but would also use many times more bitrate than they would need in order to look merely excellent. At the other extreme, qcomp=1 achieves nearly constant quantization parameter (CQP). Constant QP does not look bad, but most people think it is more reasonable to shave some bitrate off of the extremely expensive scenes (where the loss of quality is not as noticeable) and reallocate it to the scenes that are easier to encode at excellent quality.
A higher qcomp will allow distributing more bits to high-motion scenes, thus making them look better.
__________________
Monochrome Anomaly
Wolfberry is offline   Reply With Quote
Old 31st July 2018, 15:39   #6251  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,935
x265 2.8+57-eea92165b035

Enhance VBV lookahead of RADL pictures (and a few more small building and API fixes)
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 31st July 2018, 23:52   #6252  |  Link
Magik Mark
Registered User
 
Join Date: Dec 2014
Posts: 541
I'm getting this error since v2.8 + 49 in Staxrip:

Quote:
Error Video encoding using x265 2.8+56 (1.7.0.6)

Video encoding using x265 2.8+56 failed with exit code: -1073741819 (0xC0000005)

The exit code might be a system error code: The instruction at 0xp referenced memory at 0xp. The memory could not be s.

StaxRip.Proc.Start() in D:\Projekte\VS\VB\StaxRip\General\Proc.vb:line 338
at StaxRip.x265Enc.Encode(String passName, String commandLine, ProcessPriorityClass priority) in D:\Projekte\VS\VB\StaxRip\Encoding\x265Enc.vb:line 65
at StaxRip.x265Enc.Encode() in D:\Projekte\VS\VB\StaxRip\Encoding\x265Enc.vb:line 42
at StaxRip.GlobalClass.ProcessVideo() in D:\Projekte\VS\VB\StaxRip\General\GlobalClass.vb:line 225
at System.Threading.Tasks.Parallel.<>c__DisplayClass4_0.<Invoke>b__0()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at StaxRip.GlobalClass.ProcessJob(String jobPath) in D:\Projekte\VS\VB\StaxRip\General\GlobalClass.vb:line 137
Not sure if this is the result in changes in the switches
__________________
Asus X99 Sabertooth - Xeon E5 2695 - Asus Strix GTX 960 4G - DDR4 16GB Predator - Pioneer KRP 600M (isf calibrated) - Yamaha A3030 - Windows 10 x64 - Kodi with DSplayer - Lav - MadVR - XYsubtitle
Magik Mark is offline   Reply With Quote
Old 1st August 2018, 00:01   #6253  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,935
Most interesting here: There are placeholders for pointers and strings in a format string which are not interpreted as if preceded by a %. I would suspect issues with string functions.

Where did you get these x265 builds from, which compiler did they use? (e.g. run "x265 -V" in a console, that should reveal used compilers, or additional format string failures)

There was a patch e2759ae:
Quote:
dhdr: Replace the header "string" with its C++ equivalent <cstring> to fix build failures.
It looks a bit compiler dependent to me. But I am no expert regarding C++ compilers...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 1st August 2018 at 00:06.
LigH is offline   Reply With Quote
Old 1st August 2018, 00:49   #6254  |  Link
Magik Mark
Registered User
 
Join Date: Dec 2014
Posts: 541
Thanks LigH for the thoughts. I have been getting my build from here:

http://msystem.waw.pl/x265/

VS 2017 AVX 2
__________________
Asus X99 Sabertooth - Xeon E5 2695 - Asus Strix GTX 960 4G - DDR4 16GB Predator - Pioneer KRP 600M (isf calibrated) - Yamaha A3030 - Windows 10 x64 - Kodi with DSplayer - Lav - MadVR - XYsubtitle
Magik Mark is offline   Reply With Quote
Old 1st August 2018, 09:30   #6255  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,935
Please compare with my latest 2.8+57 and previous 2.8+47 (GCC 7.3.0, generic) and Barough's 2.8+56.

And please try to execute the encodes directly in a console window, to avoid mixing up error messages from x265 with error messages from StaxRip.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 1st August 2018 at 09:51.
LigH is offline   Reply With Quote
Old 1st August 2018, 20:35   #6256  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 701
Quote:
Originally Posted by Wolfberry View Post
A higher qcomp will allow distributing more bits to high-motion scenes, thus making them look better.
A lower qcomp will limit ditributing bits to high-motion scenes, allowing to assign them to low-motion scenes whose you notice more a quality loss
__________________
powered by Google Translator
Motenai Yoda is offline   Reply With Quote
Old 1st August 2018, 23:41   #6257  |  Link
Magik Mark
Registered User
 
Join Date: Dec 2014
Posts: 541
Quote:
Originally Posted by LigH View Post
Please compare with my latest 2.8+57 and previous 2.8+47 (GCC 7.3.0, generic) and Barough's 2.8+56.

And please try to execute the encodes directly in a console window, to avoid mixing up error messages from x265 with error messages from StaxRip.
Hi Ligh!

Thanks for helping out. First of all I'm not familiar with with "console window". I exclusively encode using staxrip. I have noticed that build 47 below exhibits no problem at all. This made me think that the problem lies with new or modified switches. Unfortunately, the author of staxrip called-in quit, so no help from him at all
__________________
Asus X99 Sabertooth - Xeon E5 2695 - Asus Strix GTX 960 4G - DDR4 16GB Predator - Pioneer KRP 600M (isf calibrated) - Yamaha A3030 - Windows 10 x64 - Kodi with DSplayer - Lav - MadVR - XYsubtitle
Magik Mark is offline   Reply With Quote
Old 2nd August 2018, 07:49   #6258  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,935
Yes, stax76 is not so active anymore. To use x265 in a more frequently updated GUI, which also allows more customization, I'd suggest MeGUI.

It will also be important to know your CPU. Does it support AVX2 at all? And it is interesting to know when x265 crashes. Immediately after starting an encoding job, or after calculating for a while? The log in MeGUI is more verbose here. It would report all of its output, including the CPU ID part.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 3rd August 2018, 20:42   #6259  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 325
Quote:
Originally Posted by Magik Mark View Post
I'm getting this error since v2.8 + 49 in Staxrip:
I've tried to reproduce the problem (but no hangs):
Code:
ffmpeg -i ../original.mkv -v warning -f yuv4mpegpipe - | x265-49 --y4m - --bitrate 1500 --pass 1 --ssim-rd --aq-mode 3 --pools 28 NUL
y4m  [info]: 1920x1080 fps 24000/1001 i420p8 sar 1:1 unknown frame count
raw  [info]: output file: NUL
x265 [info]: HEVC encoder version 2.8+49-5d34bbf671f7
x265 [info]: build info [Windows][MSVC 1900][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 28 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 4 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : ABR-1500 kbps / 0.60
x265 [info]: tools: rd=3 ssim-rd rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao stats-write
x265 [info]: frame I:     11, Avg QP:24.83  kb/s: 18638.87
x265 [info]: frame P:    349, Avg QP:26.64  kb/s: 4358.80
x265 [info]: frame B:   1173, Avg QP:32.98  kb/s: 431.42
x265 [info]: Weighted P-Frames: Y:20.3% UV:9.7%
x265 [info]: consecutive B-frames: 3.9% 1.1% 12.5% 30.3% 52.2%

encoded 1533 frames in 64.16s (23.89 fps), 1456.17 kb/s, Avg QP:31.48
If I understood you correctly: 2.8+47 works, 28+49 hangs at beginning, this might be problem with x265 initialization. There are no new switches from 2.8+47 to 2.8+49.

Could you confirm that 2.8+47 works, 2.8+49 hangs, and what with version 2.8+48 -- please download only 10-bit VS2015 AVX2 builds (2.8+47, 2.8+48 and 2.8+49) and report back which works and which not: www.msystem.waw.pl/x265/test.7z
Ma is offline   Reply With Quote
Old 5th August 2018, 15:26   #6260  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 85
Just replaced x265 in Staxrip with LigH's 2.8+57 version.
No error yet.

(Current encoding seems to be a bit sluggish but need to observe further - it could very well just be movie related)


I'm using StaxRip 1.7.0.6 from https://github.com/stax76/staxrip/bl...r/changelog.md.
katzenjoghurt 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 02:33.


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