x265 HEVC Encoder

[LeXXuz]

Sure flickering is because of sbrc ? I was just talking of a rare theoretical possible situation sbrc may produce...
But if it's because of that, the hysteresis option may help, it's for that case i've made it.

Well I've encoded that particular scene countless times before with all the kinds of settings. This was the first time with sbrc enabled. So I presumed it was the cause. I can give it another go, of course. How do I activate the hysteresis option?

EDIT: Never mind. Found it.

[jpsdr]

You activate hysteresis with : --sbrc-hyst
You activate replace AQ-MODE 1 with 5 with : --sbrc-aq5
Of course, you have to get my build on my github.

Edit : didn't see the edit...

I'm curious about the result.
If it doesn't help, i think i'll forget sbrc. (On the other hand, i've made the hysteresis range totaly "at random", maybe this part needs tunning).
Sometimes things which seem a good idea "on paper" are unfortunately not so good when in practical use...

[LeXXuz]

Looking good so far. Flickering gone. Encoded several films with auto-hyst-aq5 mode of 3.5+57. Will carefully watch them over next days and report back.

Will also do another encode of that one film with 3.5+56 again just to make sure that flickering I saw really was related to the mod and not something else.

[jpsdr]

@LeXXuz
Thanks for the feedback. Waiting your compare with 3.5+56.

Tuning hysteresis is not realy easy. Too big and you'll prevent switch that should have happened, too small and it's useless...
I think (even if version used by LeXXuz may has solved his issue) that the hysteresis range was a little small, so i've made it just a little bigger.
There is a new build avaible.

[Boulder]

M'kay, sbrc was worth a shot. I've seen that flickering now. Unbearable.
Not sure if aq-mode 5 + sbrc would change anything on that.

I guess I will test a little more with just aq-mode 4 and 5 now. aq-mode 3 does improve faint details in very dark scenes slightly where aq-mode 2 fails, even with generous CRF values of 18 and below. The opening scene of Thor (2011) is one of these rare cases where x265 doesn't spend enough bits with aq-mode 1/2 for that scene and the result looks awful. Even CRF 16 with the Very Low preset +rskip and -sao didn't change anything on that.

But I think aq-mode 3 just wastes too much bits in general compared to the other aq-modes. Even clips with no dark scenes at all get much bigger than with mode 2, which I don't quite understand to be honest.

Are your tests done with HDR or SDR sources? I'd be interested in hearing how it works out since mode 1 has been the best general choice for both around CRF 16 (HDR) - 18 (SDR).

[LeXXuz]

Are your tests done with HDR or SDR sources? I'd be interested in hearing how it works out since mode 1 has been the best general choice for both around CRF 16 (HDR) - 18 (SDR).

SDR Blu-ray as source. Mode 1 never convinced me in dark scenes.

[Stereodude]

Is there a general write-up or guidelines somewhere of the pro/cons / what each one excels at for the AQ modes in x265?

[Boulder]

@jpsdr: Would it be beneficial to disable using the dark bias aq-modes for HDR? They might be counter-productive AFAIK.

http://forum.doom9.net/showthread.php?p=1857767#post1857767

So for HDR, the auto switching modes would be 1, 2 and 4 and all modes would be available for SDR.

EDIT: Thinking some more, it might be useful if the value used for the frame could be exported in the CSV log as well. Otherwise a pain to debug :)

[benwaggoner]

@jpsdr: Would it be beneficial to disable using the dark bias aq-modes for HDR? They might be counter-productive AFAIK.

http://forum.doom9.net/showthread.php?p=1857767#post1857767
Yeah, --aq-mode is definitely counterproductive with PQ, which has vastly more code values near black. It'd either raise ABR a bunch with --crf, or reduce quality in midtones and brighter with --bitrate.

So for HDR, the auto switching modes would be 1, 2 and 4 and all modes would be available for SDR.
Makes good sense to me.

EDIT: Thinking some more, it might be useful if the value used for the frame could be exported in the CSV log as well. Otherwise a pain to debug :)
Good idea! ++ on that feature request.

[jpsdr]

@jpsdr: Would it be beneficial to disable using the dark bias aq-modes for HDR? They might be counter-productive AFAIK.


Sorry, i don't know, i'm very new to x265 encodes, i may just have made around 10 encodes. When it takes 10 to 12 days to encode 1h30, it's verryyyyy slow to build experience... ;)
benwaggoner is a lot more suited than me to answer.

I can see how to add on my mod branch version these features request. I must say that i said to myself at almost the begining that having a log of the the edgeIntensity and brightnessIntensity could be very interesting. And if there is the hysteresis, the current choice also. But had no idea how to add this.
No idea yet how to detect HDR/SDR for choosing switching mode, it's probably on some kind of frame property. Adding --sbrc- any idea ? switch.
Will see what if i can do something later, for now, other things to do...

[Boulder]

Sorry, i don't know, i'm very new to x265 encodes, i may just have made around 10 encodes. When it takes 10 to 12 days to encode 1h30, it's verryyyyy slow to build experience... ;)
[b]benwaggoner[\b] is a lot more suited than me to answer.

I can see how to add on my mod branch version these features request. I must say that i said to myself at almost the begining that having a log of the the edgeIntensity and brightnessIntensity could be very interesting. And if there is the hysteresis, the current choice also. But had no idea how to add this.
No idea yet how to detect HDR/SDR for choosing switching mode, it's probably on some kind of frame property. Adding --sbrc- any idea ? switch.
Will see what if i can do something later, for now, other things to do...
The encoder does some detection probably based on the set color primaries, I think it will warn if you don't have --hdr set but set the appropriate values for matrix, transfer and primaries.

Maybe --sbrc-hdr and --sbrc-sdr so anyone can choose to use all modes regardless. Then you wouldn't need to even detect the source characteristics.

And yes, the more you can add to the log, the better :D For example, it's strange that you don't know how many refs are actually used while the information is available in x264. Or CTU/TU sizes etc. which would be useful in tweaking the encoder based on content.

[jpsdr]

Maybe --sbrc-hdr and --sbrc-sdr so anyone can choose to use all modes regardless. Then you wouldn't need to even detect the source characteristics.


Ooohhh. Good one !
:thanks:

[ShortKatz]

Where do I see the flickering you mentioned with --sbrc? I've encoded some 4k HDR movies and SDR movies with the official x265, but I do not see any flickering compared to the source material. I've also encoded lots and lots of movies before with the old --auto-aq patch and did not see any flickering.

[benwaggoner]

The encoder does some detection probably based on the set color primaries, I think it will warn if you don't have --hdr set but set the appropriate values for matrix, transfer and primaries.

Maybe --sbrc-hdr and --sbrc-sdr so anyone can choose to use all modes regardless. Then you wouldn't need to even detect the source characteristics.
We already have --hdr10 and --dolby-vision-profile. Maybe we should have --sdr and --hlg parameters too, so as to unambiguously specify what colorimetry is intended. That could let lots of other filters know how to apply color volume specific optimizations.

And yes, the more you can add to the log, the better :D For example, it's strange that you don't know how many refs are actually used while the information is available in x264. Or CTU/TU sizes etc. which would be useful in tweaking the encoder based on content.
There's a lot of CU block type data if you use --csv-log-level 2. Wow, 94 columns of data. When testing with really low bitrates, I've wound up with a .csv larger than its .hevc

[Boulder]

We already have --hdr10 and --dolby-vision-profile. Maybe we should have --sdr and --hlg parameters too, so as to unambiguously specify what colorimetry is intended. That could let lots of other filters know how to apply color volume specific optimizations.
True, that would be a good shortcut :)


There's a lot of CU block type data if you use --csv-log-level 2. Wow, 94 columns of data. When testing with really low bitrates, I've wound up with a .csv larger than its .hevc
I would like to see basic CTU/TU data in the summary after the encode, it could be blurted out like similar things in x264. Csv is good but always requires some manual work for calculating the average per type etc.

[jpsdr]

So for HDR, the auto switching modes would be 1, 2 and 4 and all modes would be available for SDR.


My mod patched code is :

if (preFrame->m_frameSegment_thrs_edge == SBRC_THRS_LOW)
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_AUTO_VARIANCE : X265_AQ_AUTO_VARIANCE_BIASED;
else
{
if (preFrame->m_param->rc.frameSegment_aq5)
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_EDGE : X265_AQ_EDGE_BIASED;
else
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_EDGE : X265_AQ_EDGE_BIASED_SBRC;
}


How do you see it for HDR ?
Like this ?

if (preFrame->m_frameSegment_thrs_edge == SBRC_THRS_LOW)
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_AUTO_VARIANCE : X265_AQ_AUTO_VARIANCE;
else
{
if (preFrame->m_param->rc.frameSegment_aq5)
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_EDGE : X265_AQ_VARIANCE;
else
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_EDGE : X265_AQ_VARIANCE;
}

[Boulder]

My mod patched code is :

if (preFrame->m_frameSegment_thrs_edge == SBRC_THRS_LOW)
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_AUTO_VARIANCE : X265_AQ_AUTO_VARIANCE_BIASED;
else
{
if (preFrame->m_param->rc.frameSegment_aq5)
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_EDGE : X265_AQ_EDGE_BIASED;
else
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_EDGE : X265_AQ_EDGE_BIASED_SBRC;
}


How do you see it for HDR ?
Like this ?

if (preFrame->m_frameSegment_thrs_edge == SBRC_THRS_LOW)
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_AUTO_VARIANCE : X265_AQ_AUTO_VARIANCE;
else
{
if (preFrame->m_param->rc.frameSegment_aq5)
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_EDGE : X265_AQ_VARIANCE;
else
preFrame->m_frameSegment = (preFrame->m_frameSegment_thrs_bright == SBRC_THRS_HIGH) ? X265_AQ_EDGE : X265_AQ_VARIANCE;
}

Hmm, I believe it's correct if we consult quietvoid's answer here: https://forum.doom9.org/showthread.php?p=1977129#post1977129

Not related to your patch/mod, but how does the encoder decide to start checking for edges? Is there a range of medium brightness which will then trigger that check?

[benwaggoner]

I would like to see basic CTU/TU data in the summary after the encode, it could be blurted out like similar things in x264. Csv is good but always requires some manual work for calculating the average per type etc.
Yeah, I do spend quite a lot of time in Excel analyzing and graphing data from .csv logs.

A --csv-log-level 2 for an hour long episode is 60-70 MB. Saving as .xlsb (Binary workbook) is the smallest Excel file format, and is still 50 MB. Even with 128 GB of RAM and 2x18/36 Xeon CPUs, it still takes seconds to open the document. And it can take 10+ sec to change just one element of a chart.

As I am a multi-spectrum compression nerd, I see that 7z LZMA2 Ultra is able to get it down to 20 MB, only 40% the size as Excel's default Deflate compression. Of course, it's a lot slower to write.

[Boulder]

Can anyone of the resident experts say what is the use case for --rd-refine?

[jpsdr]

Not related to your patch/mod, but how does the encoder decide to start checking for edges? Is there a range of medium brightness which will then trigger that check?

Is this answering your question ?
/* SBRC */
if (preFrame->m_param->rc.frameSegment)
{
int heightL = preFrame->m_lowres.lines;
int widthL = preFrame->m_lowres.width;
pixel *lumaPlane = preFrame->m_lowres.fpelPlane[0];
intptr_t stride = preFrame->m_lowres.lumaStride;
double brightnessIntensity = 0, edgeIntensity = 0;

/* Edge plane computation */
memset(preFrame->m_lowres.lowresEdgePlane, 0, stride * (heightL + (preFrame->m_fencPic->m_lumaMarginY * 2)) * sizeof(pixel));
pixel* lowresEdgePic = preFrame->m_lowres.lowresEdgePlane + preFrame->m_fencPic->m_lumaMarginY * stride + preFrame->m_fencPic->m_lumaMarginX;
computeEdge(lowresEdgePic, lumaPlane, NULL, stride, heightL, widthL, false);

/*Frame edge percentage computation */
edgeIntensity = computeEdgeIntensity(lowresEdgePic, widthL, heightL, stride);

/* Frame Brightness percentage computation */
brightnessIntensity = computeBrightnessIntensity(lumaPlane, widthL, heightL, stride);

If sbrc is enabled, edge computation is always done.

[Boulder]

Is this answering your question ?
/* SBRC */
if (preFrame->m_param->rc.frameSegment)
{
int heightL = preFrame->m_lowres.lines;
int widthL = preFrame->m_lowres.width;
pixel *lumaPlane = preFrame->m_lowres.fpelPlane[0];
intptr_t stride = preFrame->m_lowres.lumaStride;
double brightnessIntensity = 0, edgeIntensity = 0;

/* Edge plane computation */
memset(preFrame->m_lowres.lowresEdgePlane, 0, stride * (heightL + (preFrame->m_fencPic->m_lumaMarginY * 2)) * sizeof(pixel));
pixel* lowresEdgePic = preFrame->m_lowres.lowresEdgePlane + preFrame->m_fencPic->m_lumaMarginY * stride + preFrame->m_fencPic->m_lumaMarginX;
computeEdge(lowresEdgePic, lumaPlane, NULL, stride, heightL, widthL, false);

/*Frame edge percentage computation */
edgeIntensity = computeEdgeIntensity(lowresEdgePic, widthL, heightL, stride);

/* Frame Brightness percentage computation */
brightnessIntensity = computeBrightnessIntensity(lumaPlane, widthL, heightL, stride);

If sbrc is enabled, edge computation is always done.

So there is then later some check to see if the frame should go to the "bright vs. dark" or "edges vs. no edges" path and the proper aq-mode can be selected?


switches the AQ according to thresholds (bright frame = mode 2, otherwise 3. high edge density = mode 4, otherwise mode 1

[quietvoid]

Either way it appears MCW is partially reverting some of the SBRC changes to "improve" it.
Didn't look too deep into it, will update when it's pushed.

Also we're getting an updated histogram scene cut algorithm, it seems.

[Boulder]

Also we're getting an updated histogram scene cut algorithm, it seems.

This could be a good change. I wonder why it was left as it was; totally unfinished and not working at all.

[LeXXuz]

@LeXXuz
Thanks for the feedback. Waiting your compare with 3.5+56.


The second encode was free of flickering as well. Could've been a problem with one of the CUDA prefilters I use. They are picky sometimes. Good thing you were sceptical sbrc being the cause. :o

[jpsdr]

So there is then later some check to see if the frame should go to the "bright vs. dark" or "edges vs. no edges" path and the proper aq-mode can be selected?
Yes, later there is first "edges vs. no edges", and for each of these cases there is "bright vs. dark".
It seems there's been new commits, didn't check them yet.

Edit: commits are only for aarch64, so no need for new build. I thought it was what quietvoid was talking about, but not. Will wait for the MCW sbrc improve, before making any change on it (i was about to see to add --sbrc-hdr, but will wait to see what will change).

[LeXXuz]

Would --frame-threads >1 have any negative impact with --sbrc on quality in CRF mode? I need at least 2 frame-threads to saturate my CPUs with the prefiltering I do. Can't run two encodes at once as it would eat up too much memory.

[LigH]

New upload: x265 3.5+68-536f6a796 (https://www.mediafire.com/file/4ba6yvp79vklgtf/x265_3.5+68-536f6a796.7z/file)

[Windows][GCC 12.2.0][32/32XP/64 bit] 8bit+10bit+12bit

News since v3.5+57:
Improved histogram based scene change detection (--hist-threshold removed); fixed memory leak in SBRC

[ShortKatz]

Either way it appears MCW is partially reverting some of the SBRC changes to "improve" it.
Didn't look too deep into it, will update when it's pushed.

Also we're getting an updated histogram scene cut algorithm, it seems.

They have pushed the scene cut algorithm patches and one sbrc change.

[Boulder]

The new scene cut algorithm seems to be broken as well. I tested it briefly on my Hot Fuzz test clip with 15 scene changes, the "classic" mode detected 10 and the new --hist-scenecut just 6 of them. The old histcut method found 8 scene cuts, part of those different from the new version. The scene cuts are very obvious, clear changes in broad daylight throughout those frames.

[vpupkind]

The new scene cut algorithm seems to be broken as well. I tested it briefly on my Hot Fuzz test clip with 15 scene changes, the "classic" mode detected 10 and the new --hist-scenecut just 6 of them. The old histcut method found 8 scene cuts, part of those different from the new version. The scene cuts are very obvious, clear changes in broad daylight throughout those frames.
Can you please share the sequence?

[Boulder]

Can you please share the sequence?

Sure, here it is: https://drive.google.com/file/d/19cIzFGAocSHYlBNJdZJ08OaQbfBIHUjm/view?usp=share_link

These entries I get for the QP file using StainlessS's tool for detecting scene cuts, I think they are all good and none are missing.

0 I
55 I
87 I
114 I
140 I
193 I
248 I
289 I
345 I
380 I
430 I
462 I
528 I
557 I
582 I
620 I

[LeXXuz]

Would --frame-threads >1 have any negative impact with --sbrc on quality in CRF mode? I need at least 2 frame-threads to saturate my CPUs with the prefiltering I do. Can't run two encodes at once as it would eat up too much memory.

Is this to obvious a question or does nobody know?

[Ashok Kumar Mishra]

Able to decode only 63 frames using ffmpeg. Can you please share the yuv file or the command line used to decode the complete hotfuzz.vc1.
It will be helpful for us to see the performance of histogram-based scene change feature.

[Ashok Kumar Mishra]

Sure, here it is: https://drive.google.com/file/d/19cIzFGAocSHYlBNJdZJ08OaQbfBIHUjm/view?usp=share_link

These entries I get for the QP file using StainlessS's tool for detecting scene cuts, I think they are all good and none are missing.

0 I
55 I
87 I
114 I
140 I
193 I
248 I
289 I
345 I
380 I
430 I
462 I
528 I
557 I
582 I
620 I

Able to decode only 63 frames using ffmpeg. Can you please share the yuv file or the command line used to decode the complete hotfuzz.vc1.
It will be helpful for us to see the performance of histogram-based scene change feature.

[Boulder]

Able to decode only 63 frames using ffmpeg. Can you please share the yuv file or the command line used to decode the complete hotfuzz.vc1.
It will be helpful for us to see the performance of histogram-based scene change feature.

I'm using DGSource with Avisynth to decode the stream, see https://www.rationalqm.us/dgdecnv/dgdecnv.html. I can try other methods when I get back home.

[Boulder]

Able to decode only 63 frames using ffmpeg. Can you please share the yuv file or the command line used to decode the complete hotfuzz.vc1.
It will be helpful for us to see the performance of histogram-based scene change feature.
Please try with this one, looks like ffmpeg doesn't like the VC1 stream cut by DGIndex while demuxing.

https://drive.google.com/file/d/1zNUnmukafWs6JWflxlnbjT2FEeC0K2VS/view?usp=share_link

[jpsdr]

In one of the last commit, they replaced :

x265_log(param, X265_LOG_INFO, "Keyframe min / max / scenecut / edge threshold : %d / %d / %d / %.2lf\n",
param->keyframeMin, param->keyframeMax, param->bHistBasedSceneCut, param->edgeTransitionThreshold);

with

x265_log(param, X265_LOG_INFO, "Keyframe min / max / scenecut : %d / %d / %d / %.2lf\n",
param->keyframeMin, param->keyframeMax, param->bHistBasedSceneCut);

Should not it be this ?

x265_log(param, X265_LOG_INFO, "Keyframe min / max / scenecut : %d / %d / %d\n",
param->keyframeMin, param->keyframeMax, param->bHistBasedSceneCut);

[LigH]

Well spotted, I guess.

There are also cases of copy/paste mistakes printing a default of 0 for a boolean switch. Quality assurance is not their greatest talent.

[Ashok Kumar Mishra]

Please try with this one, looks like ffmpeg doesn't like the VC1 stream cut by DGIndex while demuxing.

https://drive.google.com/file/d/1zNUnmukafWs6JWflxlnbjT2FEeC0K2VS/view?usp=share_link

We decoded the VC1 stream and there are 1192 frames. There is total 13 scenecuts in the video clip.

11 scenecuts in "classic" scenecut method:
5, 55, 112, 279, 333 ,365, 414, 444, 508, 536, 598

13 scenecuts in histogram based scenecut method:
55, 87, 112, 138, 242, 279, 333, 365, 414, 444, 508, 536, 598

[rwill]

We decoded the VC1 stream and there are 1192 frames. There is total 13 scenecuts in the video clip.

11 scenecuts in "classic" scenecut method:
5, 55, 112, 279, 333 ,365, 414, 444, 508, 536, 598

13 scenecuts in histogram based scenecut method:
55, 87, 112, 138, 242, 279, 333, 365, 414, 444, 508, 536, 598

I actually watched the video and counted 16 scenecuts.

[jpsdr]

Well spotted, I guess.


No, just big pure luck. If i saw it it's because this line was in conflict with one of the mod patch of my x256_mod version, and so when with turtoise git i handle the conflict, i saw it, otherwise, i would never realized it....

---------------------

For scencut, it seems that according the video, sometimes new histogram is better, sometimes classic is better.

[Ashok Kumar Mishra]

I actually watched the video and counted 16 scenecuts.

New scenecut method is better compared to classic method in this case.

[Ashok Kumar Mishra]

In one of the last commit, they replaced :

x265_log(param, X265_LOG_INFO, "Keyframe min / max / scenecut / edge threshold : %d / %d / %d / %.2lf\n",
param->keyframeMin, param->keyframeMax, param->bHistBasedSceneCut, param->edgeTransitionThreshold);

with

x265_log(param, X265_LOG_INFO, "Keyframe min / max / scenecut : %d / %d / %d / %.2lf\n",
param->keyframeMin, param->keyframeMax, param->bHistBasedSceneCut);

Should not it be this ?

x265_log(param, X265_LOG_INFO, "Keyframe min / max / scenecut : %d / %d / %d\n",
param->keyframeMin, param->keyframeMax, param->bHistBasedSceneCut);


Thanks for pointing out. Already sent a commit for the above.

[Boulder]

New scenecut method is better compared to classic method in this case.

Please post your command line so I can try to doublecheck. I used a fresh git build (using Media Autobuild Suite) and my normal command line with --hist-scenecut added and got only those 6 scene cuts. I did downscale to 1280x536 though.

There should be 1220 frames.

[Ashok Kumar Mishra]

Please post your command line so I can try to doublecheck. I used a fresh git build (using Media Autobuild Suite) and my normal command line with --hist-scenecut added and got only those 6 scene cuts. I did downscale to 1280x536 though.

There should be 1220 frames.

Below is the command line we used for new scene cut algorithm.

ffmpeg -y -v -10 -i "hotfuzz.mkv" -an -sn -threads 8 -vsync 0 -r 50000/1000 -pix_fmt yuv420p -f rawvideo - | x265 --input - --input-res 1920x1080 --fps 50 --input-depth 8 --input-csp i420 --psnr --ssim --crf 26 --csv HotFuzz_1920x1080_8bit_26_hist-latest.csv --csv-log-level 2 --output HotFuzz_1920x1080_8bit_26_hist-latest.hevc --hist-scenecut

and compared with the default scene cut method (--scenecut 40)

[Boulder]

Below is the command line we used for new scene cut algorithm.

ffmpeg -y -v -10 -i "hotfuzz.mkv" -an -sn -threads 8 -vsync 0 -r 50000/1000 -pix_fmt yuv420p -f rawvideo - | x265 --input - --input-res 1920x1080 --fps 50 --input-depth 8 --input-csp i420 --psnr --ssim --crf 26 --csv HotFuzz_1920x1080_8bit_26_hist-latest.csv --csv-log-level 2 --output HotFuzz_1920x1080_8bit_26_hist-latest.hevc --hist-scenecut

and compared with the default scene cut method (--scenecut 40)

I'm unable to replicate the behaviour. I'm getting the same amount of detected SCs for my and your command line, though I did not set any framerate etc. since it's all autodetected. Besides, you have it wrong there, this is a regular 23.976 fps film source.

Classic detects 114, 193, 289, 345, 380, 430, 528, 557 and 620. Hist-scenecut detects 55, 87, 140, 248, 289. If I crop the borders and downscale to 1280x536, the classic mode misses 5 scenechanges (87, 140, 380, 462 and 582).

The csv log files are here:
https://drive.google.com/file/d/1Gymy3rIJq5GFLULsiumraKp0_E6ml4hA/view?usp=share_link (Classic)
https://drive.google.com/file/d/1umTC4Q1t9MiT0PxDcJOMjxizjVFa0cJ7/view?usp=share_link (same CL as classic but with --hist-scenecut)
https://drive.google.com/file/d/1MHiPNUynUiHrg2jnNDrtqgq2AieG3vCe/view?usp=share_link (the doublecheck)

I'm only loading the source without any cropping etc. in the avs script.

[Ashok Kumar Mishra]

I'm unable to replicate the behaviour. I'm getting the same amount of detected SCs for my and your command line, though I did not set any framerate etc. since it's all autodetected. Besides, you have it wrong there, this is a regular 23.976 fps film source.

Classic detects 114, 193, 289, 345, 380, 430, 528, 557 and 620. Hist-scenecut detects 55, 87, 140, 248, 289. If I crop the borders and downscale to 1280x536, the classic mode misses 5 scenechanges (87, 140, 380, 462 and 582).

The csv log files are here:
https://drive.google.com/file/d/1Gymy3rIJq5GFLULsiumraKp0_E6ml4hA/view?usp=share_link (Classic)
https://drive.google.com/file/d/1umTC4Q1t9MiT0PxDcJOMjxizjVFa0cJ7/view?usp=share_link (same CL as classic but with --hist-scenecut)
https://drive.google.com/file/d/1MHiPNUynUiHrg2jnNDrtqgq2AieG3vCe/view?usp=share_link (the doublecheck)

I'm only loading the source without any cropping etc. in the avs script.

We converted .mkv which you shared into .yuv and there are 1220 frames.

Classic: 10 scenecuts(54, 113, 192, 288, 344, 379, 429, 527, 556, 619)

Histogram: 15 scenecuts(54, 86, 113, 139, 192, 247, 288, 344, 379, 429, 461, 527, 556, 581, 619)

Command line used:

Classic:
x265 --input hotfuzzn.yuv --input-res 1920x1080 --fps 50 --input-depth 8 --input-csp i420 --psnr --ssim --crf 26 --csv HotFuzz_1920x1080_8bit_26_hist.csv --csv-log-level 2 --output HotFuzz_1920x1080_8bit_26_hist.hevc --scenecut 40

Histogram:
x265 --input hotfuzzn.yuv --input-res 1920x1080 --fps 50 --input-depth 8 --input-csp i420 --psnr --ssim --crf 26 --csv HotFuzz_1920x1080_8bit_26_hist.csv --csv-log-level 2 --output HotFuzz_1920x1080_8bit_26_hist.hevc --hist-scenecut

[Boulder]

I think I got it -- please try encoding using the Main10 profile. It will give you very different results compared to Main.

[Ashok Kumar Mishra]

I think I got it -- please try encoding using the Main10 profile. It will give you very different results compared to Main.

It's 8-bit video, so using Main. Is it practical using main 10?

[Boulder]

It's 8-bit video, so using Main. Is it practical using main 10?

Yes. I do all my processing (denoising, resizing, debanding) in 16 bits, then feed that to the encoder and encode with the Main10 profile. No use encoding in 8 bits since pretty much all the current HW decoders support Main10 as well.