x265 HEVC Encoder

[benwaggoner]

Originally Posted by Greenhorn

It appears to have been split into two options: --qp-delta-ref and --qp-delta-nonref. The first is for REFERENCED p/b frames and defaults to 5.0, while the second is for NON-REFERENCED p/b frames and defaults to 6.5.

This is present in the CLI encoder's documentation, but not on x265.readthedocs.io; 3.4+20 (and all versions after 3.4+4) are development builds, rather than release. (Even if the difference between the two is usually kinda small.)

This seems like a good feature to have. Spending fewer bits on non-reference frames in order to spend more on reference frames so they provide better predictors for the frames they reference is a key feature of good rate control.

We already have that in the ip and pb ratios. But with HEVC you can have non-referenced blocks in all frame types.

Getting it tuned so there isn't any thresholding (visible seams when a contiguous area has some reference and some non-reference blocks) is the tricky part with such things.

[birdie]

They've migrated to a new repo and pretty much all the old open issues have been lost in transition. Sigh.

[benwaggoner]

Originally Posted by birdie

They've migrated to a new repo and pretty much all the old open issues have been lost in transition. Sigh.

Well, we should go back and add new repros for bugs that still exist. I hope some of the older ones have gotten fixed in the backgroud.

[Majorlag]

Originally Posted by jlpsvk

ok.. seriously there's a problem with x265 and HDR10+ encoding...

tried another HDR10+ encode... source has 195593 frames, encode has 195585. Without HDR10+ (only HDR10) encode has 195593. It's clearly problem of x265, as with nVidia and Intel's encoders, using the same HDR10+ metadata file, output has right number of frames.

How are you feeding x265, hopefully with a frame accurate frame server?

What frame server are you using AviSynth+ or VaporSynth? Also which indexer are you using? I tend to get better consistent results with FFMSIndex. To many failed encodes with L-SMASH Works indexer.

Have you tried removing all x265 custom parameters and just use defaults with just hdr10+ options to eliminate any conflicting parameters?

[Barough]

x265 v3.4+24-g6ed1c24a2 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[jlpsvk]

Originally Posted by Majorlag

How are you feeding x265, hopefully with a frame accurate frame server?

What frame server are you using AviSynth+ or VaporSynth? Also which indexer are you using? I tend to get better consistent results with FFMSIndex. To many failed encodes with L-SMASH Works indexer.

Have you tried removing all x265 custom parameters and just use defaults with just hdr10+ options to eliminate any conflicting parameters?

no matter what i try. still the same result, staxrip, ripbot264, command line.... still the same... with the same setting but just without dhdr, encoded frame number is identical to source

as soon as i use GPU encoder (intel or nvidia), encode is fine.

[benwaggoner]

Originally Posted by jlpsvk

no matter what i try. still the same result, staxrip, ripbot264, command line.... still the same... with the same setting but just without dhdr, encoded frame number is identical to source

as soon as i use GPU encoder (intel or nvidia), encode is fine.

Check your JSON file, and see if it has a different number of frames than your source or something. Or if the final frames that are cut off have all have the same metadata. My wild guess is that x265 is cutting off frames that it doesn't have metadata for, or unique metadata for. Which would be a bug.

[jlpsvk]

Originally Posted by benwaggoner

Check your JSON file, and see if it has a different number of frames than your source or something. Or if the final frames that are cut off have all have the same metadata. My wild guess is that x265 is cutting off frames that it doesn't have metadata for, or unique metadata for. Which would be a bug.

when using JSON for encode with intel or nvidia, everything is OK.... so i excluded wrong JSON.. i also tried with different movies and the results are the same.

[Barough]

x265 v3.4+26-ga82c6c7a7 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[filler56789]

OK, I was bored, so I compiled x265.exe 3.4+30-g6722fce.

GIT command-line:

git clone --single-branch --branch Release_3.5 --depth 128 https://bitbucket.org/multicoreware/x265_git.git

Changes since commit ga82c6c7a7:
https://bitbucket.org/multicoreware/...it/commits/all

Download:
http://www.mediafire.com/file/8n5bnn...722fce.7z/file

[benwaggoner]

And wow, this thread went three weeks without a post.

I see from the git that we're getting x265 3.5 features checked in.

[markiemarcus]

Originally Posted by benwaggoner

AQ needs some refactoring, for sure!
aq-mode 3=2 with low luma bias. hevc-aq is really aq-mode 5, and should map to that.

Aq-motion is a lot more experimental than hevc-aq, and I've not heard anyone suggest it'd be appropriate to have on by default. HEVC-AQ is a lot more mature at this point, althogh newer.

Yes the mapping is a little confusing! Also that Aq strength has no impact on hevc-aq could probably be better clarified.

I must say though, HEVC-AQ is by far my preferred method of encoding animation in instances with selective sao 0-2. The other aq modes typically produce more noise around dark lines. Even with 2 pass encodes and checking aq-strength in steps of 0.05, I haven't been able to replicate hevc-aq's results in this area with any of the other aq modes. There's also something about having RD greater than 4 and b-intra enabled that really seems to helps with this too. Slow though, but you can make compromises in other areas. Rect for instance seems to achieve nothing or very little. Tskip works well.

How have you found aq mode 4? With grainier or more detailed content, I'm finding the results extremely encouraging. Seems to fare well on flat areas with grain, especially in high motion.

[vpupkind]

hevc-aq and aq mode 4 are different: hevc-aq is based on quartile variance, while aq mode 4 is based on variance of edges

[markiemarcus]

Originally Posted by vpupkind

hevc-aq and aq mode 4 are different: hevc-aq is based on quartile variance, while aq mode 4 is based on variance of edges

Very obviously so based on the results alone. Aq mode 4 is actually a fair bit slower too.

They both seem quite mature to me; but it's definitely very much source dependent. HEVC-AQ for instance I've had less than ideal results with live action, but it's rather good and my preferred mode with animation.

[vpupkind]

Originally Posted by markiemarcus

Aq mode 4 is actually a fair bit slower too.

AQ4, histogram-based scenecut, and rskip 2 all depend on an edge detection pre-pass.

[markiemarcus]

Originally Posted by vpupkind

AQ4, histogram-based scenecut, and rskip 2 all depend on an edge detection pre-pass.

Ah that explains a lot.

[quietvoid]

I've created a new issue for the previously mentioned x265 HDR10+ crashes: https://bitbucket.org/multicoreware/...en-using-hdr10
If someone knows a bit around the code, it might be simple to fix.
Otherwise I hope it reaches someone over at MCW.

[jlpsvk]

Originally Posted by quietvoid

I've created a new issue for the previously mentioned x265 HDR10+ crashes: https://bitbucket.org/multicoreware/...en-using-hdr10
If someone knows a bit around the code, it might be simple to fix.
Otherwise I hope it reaches someone over at MCW.

Hail to quietvoid!!!

[LigH]

I'm getting buried under NASM warnings for over a month now... patching them out like in x264 is not good enough for x265. They seem to need experienced contributors.

[filler56789]

https://bitbucket.org/multicoreware/...-with-nasm-215

so the problem is 3 months old already -_-

I keep using nasm 2.14, but I know the users of MABS have to use what MABS gives them :-/