x265 HEVC Encoder

[FranceBB]

If it's 60fps with many dups, you may wanna decimate it using a frameserver first.
I would use something like this in Avisynth:

tdecimate(mode=2, rate=30)

change "rate" according to the original frame-rate of your source.

Then, you said that "it tends to exceed the bits per second budget".
I assume you mean that it requires too much bitrate than the one you are trying to keep as maximum.
If that's the case, I would increase the reframe parameter and a few other things, but beware that it's gonna be more resource intensive to both encode and decode.
Try with --ref 16 --me esa --subme 11

[Jamaika]

How to get around this?
api.cpp:491:1: error: jump to label 'fail' [-fpermissive]
fail:
^~~~
In file included from api.cpp:24:
common.h:225:18: note: from here
goto fail; \

[Ma]

Easiest solution:
before building x265 please execute
export CXXFLAGS="-fpermissive"

[alex1399]

After some suggestions and a fast review of x265 documents, quick conclusion comes out for the x265 encoder parameters.
My boss will reject those that are not heuristic methods so trivial trimming frame is not option.

keyint = 10*frame-rate. Long distance key-frames are best for Still frames, based on frame-rate without affecting decoder side too much. Default is 250.
scenecut = 30. Scene-cut detection is less aggressive to ignore some ghosting / blending scene. Default is 40.
rc-lookahead = 0.8*frame-rate. Add some more lookahead for frame-type decision. Default is 20.

Rest of the options i.e., bframes, ref and many motion prediction would be based on the presets by default. Feel free to give your comments about those custom options and or de-noising (mostly from high-bit-depth to 8-bit-depth dithering) or de-ghosting stuffs?

[kento]

I just wish to thank everyone for the hard work and the suggestions made through the years !

[uneedme]

remove --aq-motion and try again

ooh cheers,

I will have another try...

(just cant logon the forum dont know why)



From current processing, it is sure aq-motion cause the Chaos......But Why. Is this experimental param still Buggy?

[foxyshadis]

After some suggestions and a fast review of x265 documents, quick conclusion comes out for the x265 encoder parameters.
My boss will reject those that are not heuristic methods so trivial trimming frame is not option.

keyint = 10*frame-rate. Long distance key-frames are best for Still frames, based on frame-rate without affecting decoder side too much. Default is 250.
scenecut = 30. Scene-cut detection is less aggressive to ignore some ghosting / blending scene. Default is 40.
rc-lookahead = 0.8*frame-rate. Add some more lookahead for frame-type decision. Default is 20.

Rest of the options i.e., bframes, ref and many motion prediction would be based on the presets by default. Feel free to give your comments about those custom options and or de-noising (mostly from high-bit-depth to 8-bit-depth dithering) or de-ghosting stuffs?

If you have a bit-budget, in any way, shape, or form, then you need to turn on VBV. You're only exceeding it because you didn't set up VBV correctly. If you're consistently exceeding it throughout the whole video, you can either raise the profile (longer encoding, bit of a crapshoot on how much it lowers bitrate) or raise the crf (guaranteed bitrate and quality reduction).

B-frames aren't set by the profile, only the tune, so setting them manually to a higher value is a solid option, but after 3 b-frames the value falls off enormously. (Except in certain classes of animation.)

[alex1399]

Increasing bframes with those duplicated frames doesn't help at all, maybe. Might require more experiments under the PSNR tunes to figure out. The hierarchy stuffs in x265 is quite abstract, so left those for presets.

VBV seems to be great if videos would be publicly released on air in advance. On the contrary, increasing qcomp and qpstep provide something better in motion view.

[katzenjoghurt]

https://media.giphy.com/media/4Td3vJgrjPKO0mOGMe/giphy.gif (https://imgbb.com/)

Sources:
https://www2.pic-upload.de/img/35671437/encoding_original.png
https://www2.pic-upload.de/img/35671439/encoding_x265.png

Slider Comparison Tool Link:
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=1cd634b2-8dcc-11e8-b263-0edaf8f81e27

Hey community!

Hm... I feel something's funky with my settings but I don't know what.
SOMETIMES the encodings come out with a bit washed out colors.
It especially seems to happen in darker scenes...
See the gif above.

For most movies it seems to not happen at all.

What is it and how can I detect / prevent it?

I used Staxrip with these encoding settings:

short:

--crf 22 --tune grain --profile main10 --output-depth 10 --rskip --qcomp 0.8 --no-open-gop --sar 12:11 --no-deblock --no-strong-intra-smoothing


detailed settings:

Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 13 min
Bit rate : 6 416 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.129
Stream size : 6.00 GiB (77%)
Writing library : x265 2.8+40-0106f9f2f867:[Windows][GCC 7.3.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=192702 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / radl=0 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / no-deblock / no-sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=22.0 / qcomp=0.80 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=64 / rc-grain / qpmax=69 / qpmin=0 / const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei
Default : Yes
Forced : No


Someone mentioned that washed out colors may be caused by a too low bitrate... but hum... I don't see much of a difference when rising it.

[Atak_Snajpera]

gif in 256 colors is a bad way to demonstrate your issue.

[katzenjoghurt]

gif in 256 colors is a bad way to demonstrate your issue.

It visualizes the point: The warm face color turns grayish.

Added the sources to the original posting.

[Selur]

looking at it in Firefox at 200% on a HP 5k z27q with a Geforce GTX 1070t, I see the color change around the eye, but sure what is causing this.

[WhatZit]

...
colorprim=2 / transfer=2 / colormatrix=2
...

There's a lot we don't know about your source, such as its bitdepth, frame size, encoder family, or colour tagging.

A conversion from any of those source states could introduce colour-shifting depending entirely on what specific process you're using, especially rounding errors when resizing or denoising, or even a bad source decoder. Heaps of variables.

However, given that your MediaInfo dump of the x265 encode shows "unknown" for all of the colour characteristics, I'd start my investigation there.

[jd17]

Hm... I feel something's funky with my settings but I don't know what.
SOMETIMES the encodings come out with a bit washed out colors.
It especially seems to happen in darker scenes...
See the gif above.

Without knowing all the details already requested by others, I can at least offer a suspicion:

Assumption:
Your source is 8bit and you encode to 10bit.
If that is the case, what you see is most likely not an issue with your encode, but rather the decoder.
I stumbled over this a while back - I could only see the issue on my PC, but not when I watched the videos on my TV (clean 10bit decoding chain).

I think this was already discussed somewhere here on doom9 as well. :)

[katzenjoghurt]

Hi jd17! :)

OMG! You are right!!
It's an 8bit source.

Tried a bit around and compared it against a main 8bit encoding and the problem was gone. (Using StaxRip's comparison tool)

I then opened the 8bit and the main10 10bit file in VLC and... again no washed out colors.

So the issue seems to be related to StaxRip's screen comparison tool.


Thx a lot, Sherlock! :thanks:

[LigH]

I remember people putting two media players side by side, wondering about color differences ... but they set up the media player to use the Hardware Overlay renderer. Which can have different color controls, compared to the desktop. And can only be used by one player. The other player must then select an alternative desktop-contained renderer.

One renderer in the overlay, the other in the desktop: in this case, color differences are no surprise.

[alex1399]

If you have a bit-budget, in any way, shape, or form, then you need to turn on VBV. You're only exceeding it because you didn't set up VBV correctly. If you're consistently exceeding it throughout the whole video, you can either raise the profile (longer encoding, bit of a crapshoot on how much it lowers bitrate) or raise the crf (guaranteed bitrate and quality reduction).

OK, I found the culprit of the encoding process. The frame numbers of encoded video reported by ffprobe is one more than the original video material. In 2-pass encoding, the -f null - in the first pass encoding seems to bypass vsync detection and provide a invalid analysis for the coming second pass encoding which has a duplicated frame at the start.

If the -f null - in the first pass encoding is replaced by any dummy output, both output of the first pass encoding and the second pass encoding will have the same duplicated frame and the analysis is valid.

Is it possible to log only these error(warning) into txt file during the batch process, so I could read it when I'm back to screen?

[LigH]

VSync (Vertical Retrace Synchronisation) is related to a video monitor, a synchronism between monitor and video frame rate ... you probably mean audio/video synchronism. Whatever it means in detail, this will be an issue related to ffmpeg; x265 (as a separate encoder, or as the core library) processes video only and can only rely on the sequence of input frames. If the ffmpeg core serves a duplicate frame, blame ffmpeg.

[alex1399]

I'm sorry that confusing, the audio/video sync stuffs that ffmpeg names not the monitor sync stuffs. Does x265 itself have any mechanic to log out error, for example, somebody purposely use a different video at the second pass encoding to do something wrong?

[LigH]

If x265 uses a statistics file in a 2nd pass which is based on analyzing a different movie in the 1st pass, then it is possible that just the bitrate distribution is not optimal; if you have additional VBV restrictions, it might happen that they fail; if they have a different number of frames, the mismatch may be discovered in the end; but in general, just the quality may vary unexpectedly. There are no security measures to match statistics file and video source (which would be nearly impossible anyway if it comes out of a pipe). Your only workarounds I can imagine right now:

a) let the 1st pass create an output file too;
b) ignore audio during video encoding to avoid this issue if it is not in sync in the source file, always process audio separately, and multiplex it to the final video only

In any case, x265 is not to be blamed.

[alex1399]

The second pass encoding just use the slice-type order from the first pass encoding where the first pass intently encodes video A and the second pass intently encodes video B respectively. Both video A and B have the same frame-rate, resolution and amount of frames. the slice-type order is checked by ffprobe -show_frames.

Before I closed the paused batch window during the weekend, it shows something like "[warning]: specified frame type (*) at **** is not compatible with keyframe interval" and "[error]: slice=I but 2pass stats say B", never mind. Now a dummy output is assigned for the first past encoding output.

During debug mode, to record the PSNR statics, options tune PSNR for x265, psnr stats_file for ffmpeg, and move stats_file SomeGenericNameNum are mixed in the batch process. If the result is promising, then the debug stuffs will be canceled and use the default tuning for the rest of the videos.

A bonus demonstration of the mad Adam from RWBY V5E2 for the encoding misplacement
https://i.imgur.com/b6wmHFz.jpg

[alex1399]

No VBV restrictions right now. Just trying to simulate how could those videos badly up-sampled and up-scaled and low-bit-depth to high-bit-depth / high-bit-depth to low-bit-depth conversion back and forth. Now I feel disgusting about those superfluous 10-bit-depth video which was encoded from 8-bit-depth raw source.

A problematic USB stick is fine to reproduce binary corruption / missing in poor network to observe blocking artifacts. --gop-lookahead value larger than --min-keyint value is great on letting x265 produces more noise. Hard-coded artifacts from --dithering and --deblock that make things look not natural : a little subjective. And so on.

[FranceBB]

Now I feel disgusting about those superfluous 10-bit-depth video which was encoded from 8-bit-depth raw source.

Actually, it makes sense to encode in 10bit starting from an 8bit source. I know that if there's banding already in the 8bit source, there's gonna be banding in the 10bit encode as well, but if I had to deband an 8bit source, I wouldn't encode it back to 8bit unless I really need to. Besides, Main10 is the "de-facto" standard and is widely compatible with players (unlike H.264 High10 that wasn't very supported).

[MeteorRain]

Now I feel disgusting about those superfluous 10-bit-depth video which was encoded from 8-bit-depth raw source.

Have you ever taken the internal bit-depth / precision loss into consideration? IIRC 8-bit HEVC uses 8-bit internal processing which will effectively reduce the bit-depth to lower than 8-bit. (Correct me if I'm outdated)

Take math as an example. The area of a circle of 4.5, computing in 1-digit after point internal precision is 4.5 * 4.5 -> 20.2, then 20.2 * pi -> 62.6. However computing in 2-digit internal precision gives you 63.58 which is much closer to the real number 63.61725015. Totally different result.

[Asmodian]

That was true in AVC but HEVC uses a high bitdepth for most of the math internally, for all output bitdepths, but it is still a good idea to always encode to 10 bit HEVC.

[MeteorRain]

That was true in AVC but HEVC uses a high bitdepth for most of the math internally, for all output bitdepths

My memory says that, but I did a quick search and couldn't find anything saying x265 is using high bitdepth for internal precision. So not very certain about that part.

[Boulder]

I also recall reading somewhere that internally everything happens in 16-bit precision.

[Barough]

x265 v2.8+56-613074c6714f (http://www.mediafire.com/file/fd532su2k80zbxv/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[foxyshadis]

My memory says that, but I did a quick search and couldn't find anything saying x265 is using high bitdepth for internal precision. So not very certain about that part.

The spec absolutely hates being clear about things mere mortals like to know, but there are a few points: All dct transform processing is from -2^15 to 2^15 (7.4.3.2.2), meaning signed 16-bit. That's about it, though; for purposes of processing they're immediately scaled to bitdepth, and reference prediction & filtering are performed in the bit-depth of the encode. (8.5.3-4 & 8.7.2 has much of the gory details.)

[alex1399]

Thanks for everybody's input. To provide an additional reason why lossless x265 is superior, Video A and B are presented for a trivial scheme : interweave.
First, interweave both video; Second, select and mux the even frame; third, compare it under PSNR measure.

Video A: https://www5.zippyshare.com/v/uVQP4Ccc/file.html
Video B: https://www87.zippyshare.com/v/pkkl1Eph/file.html

x265 crf 0 interweave scheme
ffmpeg -i in.y4m -i out.y4m -filter_complex framepack=frameseq -c:v libx265 -crf 0 output.mp4
ffmpeg -i output.mp4 -vf select=mod(n\,2) -r 24000/1001 -c:v libx265 -crf 0 output1.mp4
ffmpeg -i output1.mp4 -i out.y4m -lavfi psnr=stats_file=psnr.csv -f null -

x265 lossless interweave scheme
ffmpeg -i in.y4m -i out.y4m -filter_complex framepack=frameseq -c:v libx265 lossless=1 output.mp4
ffmpeg -i output.mp4 -vf select=mod(n\,2) -r 24000/1001 -c:v libx265 -x265-params lossless=1 output1.mp4
ffmpeg -i output1.mp4 -i out.y4m -lavfi psnr=stats_file=psnr.csv -f null -

raw lossless interweave scheme
ffmpeg -i in.y4m -i out.y4m -filter_complex framepack=frameseq -f yuv4mpegpipe output.y4m
ffmpeg -i output.y4m -vf select=mod(n\,2) -r 24000/1001 -f yuv4mpegpipe output1.y4m
ffmpeg -i output1.y4m -i out.y4m -lavfi psnr=stats_file=psnr.csv -f null -

A mean-square-error of 0.00 but PSNR of non-inf is quite surprised me in the crf=0 x265 scheme.
Maybe there exists some bit-exact-accuracy options I didn't activate for x265, but crf=0 is definitely not lossless.

Out of topic
x264 crf 0 interweave scheme
ffmpeg -i in.y4m -i out.y4m -filter_complex framepack=frameseq -c:v libx264 -crf 0 output.mp4
ffmpeg -i output.mp4 -vf select=mod(n\,2) -r 24000/1001 -c:v libx264 -crf 0 output1.mp4
ffmpeg -i output1.mp4 -i out.y4m -lavfi psnr=stats_file=psnr.csv -f null -

[Boulder]

--crf 0 is not meant to be lossless.

[sneaker_ger]

It is for 8 bit x264. I suspect the error is not in libx264, maybe ffmpeg muxing/demuxing. Either way this has nothing to do with x265. Please move to a new thread or better yet report on ffmpeg bug tracker.

[alex1399]

If x265 is fine, I'm fine. Just messing around to seek some ordinary mistakes that common people will make during encoding process. Those rare conditions are not bugs, maybe.

[K.i.N.G]

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:
https://i.imgur.com/Nm3l7L2.png

[Boulder]

--qg-size could be something to look at. Lowering it will cause the bitrate to rise though.

[K.i.N.G]

--qg-size could be something to look at. Lowering it will cause the bitrate to rise though.

Thank you, I've lowered it to 16 and will report back when its finished.

I can live with 'slight' bitrate increases (which is perfectly understandable).

[LigH]

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.

[K.i.N.G]

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?)...

[Boulder]

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.

[foxyshadis]

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:
https://i.imgur.com/Nm3l7L2.png

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.

[alex1399]

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.

[K.i.N.G]

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...

[Boulder]

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?

[K.i.N.G]

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...

[LigH]

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> (https://x265.readthedocs.io/en/default/cli.html?highlight=qcomp#cmdoption-qcomp)
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.

[Wolfberry]

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.

[LigH]

x265 2.8+57-eea92165b035 (https://www.mediafire.com/file/h0au8vvwnq2tj5w/x265_2.8%2B57-eea92165b035.7z)

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

[Magik Mark]

I'm getting this error since v2.8 + 49 in Staxrip:

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

[LigH]

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 (https://bitbucket.org/multicoreware/x265/commits/e2759ae31c3638518d4a6358a884f569efae1298):
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...

[Magik Mark]

Thanks LigH for the thoughts. I have been getting my build from here:

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

VS 2017 AVX 2