x265 HEVC Encoder

[Ma]

Thanks for samples! They are not similar to BigBuckBunny.

[Gser]

I'm encoding HDR footage so I need to set max luma but I'm getting this error message

x265 [warning]: extra unused command arguments given <--max-luma=4000>

It defaults to 1000.

[Boulder]

Try --max-luma 4000.

[Gser]

Originally Posted by Boulder

Try --max-luma 4000.

Thanks that worked, funny how some commands work with "=" and others don't.

Also the command seems to have no effect, it is still showing max: 1000 cd/m2.

Setting min luma to 0.0050 also doesn't work, I'm guessing because the parameter is an integer.

[sneaker_ger]

--max-luma is for clipping input. It is usually not needed for HDR. You probably want to use the max/min luminance of "master-display". (4000 is very high. Haven't seen such samples yet. Is this plausible for your source?)

[Gser]

Originally Posted by sneaker_ger

--max-luma is for clipping input. It is usually not needed for HDR. You probably want to use the max/min luminance of "master-display". (4000 is very high. Haven't seen such samples yet. Is this plausible for your source?)

Yes indeed it was mastered on a Dolby pulsar screen and it says so in the media information. This is the standard for Netflix or at least that's what I've been told. 4000 nits is also standard for Dolby vision. It works fine now just changed L(10000000,0) to L(40000000,5000).

[Midzuki]

x265.exe 2.7+8-613d9f443769

remove maxCTU size restriction in scaled save/load encodes

analysis: Introduce refine-intra level 4

use MV from analysis-save encode as MVP in load mode for refine-inter levels

Add max-ausize-factor option to control the maximum AU size defined in specification

Add reorderedPts to x265_picture to signal the reordered pts value of each picture in encode order.
Also shared the reordered pts value when analysis load is done by disabling lookahead.

https://forum.videohelp.com/threads/...50#post2513850

[LigH]

#metoo

x265 2.7+8-613d9f443769

[brumsky]

Generally speaking, what has a greater effect on fine detail retention --tu-inter-depth or subme? It's for anime and I'm currently using --tu-inter-depth 4 subme 3 and --limit-tu 3. Would I get better results by upping subme and droping limit-tu to 4? Trying to find the best size\quality.

[Majorlag]

Originally Posted by brumsky

Generally speaking, what has a greater effect on fine detail retention --tu-inter-depth or subme? It's for anime and I'm currently using --tu-inter-depth 4 subme 3 and --limit-tu 3. Would I get better results by upping subme and droping limit-tu to 4? Trying to find the best size\quality.

The first part of your question asks what has better detail retention. the higher --subme value, the higher chance of fine detail retention. --tu-inter-depth does not effect detail retention as I understand it.

--tu-inter-depth is for compression or size. It is how much compression to shoot for. higher value, try to compress more. --limit-tu value effects how long to spend on compression target of --tu-inter-depth.

Hopefully I have read the command line options correctly. Try these set of options to see if they help you, it is what I use for anime "--qcomp 0.8 --rc-lookahead 30 --rc-grain --me 2 --subme 4 --no-strong-intra-smoothing --no-sao"

[Barough]

x265 v2.7+12-98e48e8dd6ab (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[brumsky]

Originally Posted by Majorlag

The first part of your question asks what has better detail retention. the higher --subme value, the higher chance of fine detail retention. --tu-inter-depth does not effect detail retention as I understand it.

--tu-inter-depth is for compression or size. It is how much compression to shoot for. higher value, try to compress more. --limit-tu value effects how long to spend on compression target of --tu-inter-depth.

Hopefully I have read the command line options correctly. Try these set of options to see if they help you, it is what I use for anime "--qcomp 0.8 --rc-lookahead 30 --rc-grain --me 2 --subme 4 --no-strong-intra-smoothing --no-sao"

Thanks for the info! It does help and makes sense! I'll give some of those settings a try as well. I read a different thread where BenWaggner mentioned using --tskip and --tskip-fast with good results with anime. I've read the description a few times and can't quiet figure out what exactly it is skipping... any tips on those?

[Asmodian]

The residual, the difference between the predicted image and the original image, is coded after a DCT-like transformation, except with tskip this transformation can be skipped. The encoder compares the size of the coded block after the transformation to its size without a transformation and picks whichever is smaller. As a speed boost tskip fast does not compare the size after skipping the transformation at all the possible block size combinations, only a good subset of them.

[LigH]

x265 2.7+12-98e48e8dd6ab

   --refine-intra <0..4>         Enable intra refinement for encode that uses analysis-load.
...
                                    - 4 : Re-evaluate all intra blocks, does not reuse data from save encode.

   --[no-]dynamic-refine         Dynamically changes refine-inter level for each CU. Default disabled

   --[no-]idr-recovery-sei      Emit recovery point infor SEI at each IDR frame

[Barough]

x265 v2.7+15-b9f5b5d7bf95 (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[enctac]

Problem about x265 2.7+17 and L-SMASH r1459/r1450

L-SMASH : https://github.com/l-smash/l-smash
r1459 binary : http://www.mediafire.com/file/b7w5m1...9_20180310.zip

x265 2.7+14-d7c26df32fae:[Windows][MSVC 1913][64 bit] 8bit+10bit+12bit
x265 2.7+17-2e370d98c806:[Windows][MSVC 1913][64 bit] 8bit+10bit+12bit

sample.avs
#---
ColorBarsHD(1280,720).Trim(0,500).ConvertToYV12()
ShowFrameNumber(scroll=true,size=128)
#---

ffmpeg.exe -i sample.avs -f yuv4mpegpipe - | x265.exe --y4m - --pass 1 --bitrate 1000 -o sample.265
ffmpeg.exe -i sample.avs -f yuv4mpegpipe - | x265.exe --y4m - --pass 2 --bitrate 1000 -o sample.265

muxer.exe -i "sample.265"?fps=30000/1001 -o sample.mp4

Result

x265 2.7+14 -> No problem.

x265 2.7+17 -> muxer.exe freeze or crash.

Which is wrong ? x265 ? or L-SMASH ?

[LigH]

Let's check the last 3 commits ... which may be the most probable: 5be53f0 (Clean up SEI::write function)? Sounds like it changed the output in important values.

[Sp00kyFox]

edit: seems the artifacts were caused by aq-motion. qg-size 8 just counteracts that but the default qg-size 32 without aq-motion actually looks better.
https://mega.nz/#F!DMYT2ICb!4aufAuilmDJAn-Bj-Gzcpg
__________

original post:
about the qg-size discussion. a friend of mine recently asked me about some artifacts he noticed with his x265 encodings. turned out the default qg-size was the culprit.

--qg-size <64|32|16|8>
Enable adaptive quantization for sub-CTUs. This parameter specifies the minimum CU size at which QP can be adjusted, ie. Quantization Group size. Allowed range of values are 64, 32, 16, 8 provided this falls within the inclusive range [maxCUSize, minCUSize].

from what I understand a lower qg-size allows the adaptive quantization to better adjust itself to small details. so why even use a higher value than the lowest one possible? at least for HD resolutions or lower it seems essential to simply set it to 8 to avoid artifacts that can appear otherwise. without being familiar with the parameters of the encoder people would be tempted to just increase their crf value instead.

here check out this scene. source is included if you wanna experiment yourself with it.
link removed

this is the general commandline I used. the different clips only differ at the chosen qg-size value, see the file names for that.

--preset slow --crf 23 --profile main10 --no-sao --aq-motion

after the first scene cut focus on the two guys walking back to their truck. notice the artifact corona that surrounds them. qg-size 8 pretty much fixes it. this also slightly increased the bitrate. so I'm not saying that using --qg-size 8 improves quality at the same file size. but when using crf it might be useful to do that to avoid artifacts you otherwise would need to generally lower crf for.

I suppose the default value is set to 32 instead because the codec is designed for 4k content in mind where it's probably useful to avoid a subblock adaptation at the lowest level due to details being larger.

what's your opinion on this?

[Motenai Yoda]

coz all was 32x based at early development stages

[brumsky]

Is it possible to use a UHD HDR source to create an HD SDR encode? I ask because I'm having issues with the encode being desaturated due to the HDR source and BT2020.

How can I convert the color palette and convert to SDR?