x265 HEVC Encoder

[jpsdr]

I've allready put everything on it.

[vpupkind]

--multi-pass-opt-rps broken !!!
I have a small clip which can reproduce the issue, this option produces a broken, unplayable h265 stream.
I can give :
- The clip
- The encode script
- The broken encode result
I can put all these data on my FTP server, so any dev can PM me to have the server information to retrieve all of these.

I encountered this issue a few years ago. This option results in different PPS's for different GOPs, which is perfectly legal. If a decoder assumes that PPS does not change, it will end up incorrectly decoding at some point. What did you use to package and decode?

In any case, just try using `hev1` (and not `hvc1`, where just one copy of PPS is stored) packaging in ISO-BMFF, MP4Box is your friend here.
If this doesn't help, just turn it off. It is a very elegant optimization, but not that significant in the grand scheme of things.

[jpsdr]

I'm opening the raw stream with DGIndexNV.

[vpupkind]

I'm opening the raw stream with DGIndexNV.
Can you please share the stream? I can look at it in an analyzer.

[jpsdr]

Thank for that. I've sent you information by PM.
Interested of course by feedback.

[Majorlag]

--multi-pass-opt-rps broken !!!
I have a small clip which can reproduce the issue, this option produces a broken, unplayable h265 stream.
I can give :
- The clip
- The encode script
- The broken encode result
I can put all these data on my FTP server, so any dev can PM me to have the server information to retrieve all of these.

I use --multi-pass-opt-rps with all my encodes. I use it with --multi-pass-opt-analysis --multi-pass-opt-distortion in my command lines, in 2 pass encodes. Don't think those options work correctly in 1 pass encodes since they are specifically for multi pass. I also use mkv containers if that helps.

I have never run into issues since they where introduced awhile back using LigH encoder

[jpsdr]

Didn't have --multi-pass-opt-analysis in my script, tested, didn't change the issue, result stream unplayable.

[Majorlag]

the only other time I have had any issues with playback was my end resolution height was not devisable by minimum of 2, had the wrong crop set which ended in a 1. Have you tried FFVideoSource instead of DGIndexNV to test cpu only decode instead of hardware acceleration decode?

[jpsdr]

If i mux to mkv and play with Mediaplayer Classic Home-Cinema or VLC it still output garbage, if i remove the option everything is fine.
Also, i didn't trig the issue at the begining, i first made tests on a small clip to figure out the options. It's when i encoded the whole movie that the bug trigged. The first 80000 frames where good, and then after a specific scene everything was garbage.
Lucky, the bug is trigged just by extracting a small clip with the scene, don't need the whole movie !
At this point, and with all these elements, for me --multi-pass-opt-rps is broken, period !

[mister_no]

@jpsdr
Do I have to set all 3 options (--sbrc --sbrc-aq5 and --sbrc-hdr) or only --sbrc and --sbrc-hdr with Source HDR?

[vpupkind]

If i mux to mkv and play with Mediaplayer Classic Home-Cinema or VLC it still output garbage, if i remove the option everything is fine.
Also, i didn't trig the issue at the begining, i first made tests on a small clip to figure out the options. It's when i encoded the whole movie that the bug trigged. The first 80000 frames where good, and then after a specific scene everything was garbage.
Lucky, the bug is trigged just by extracting a small clip with the scene, don't need the whole movie !
At this point, and with all these elements, for me --multi-pass-opt-rps is broken, period !
Can you try multiplexing into MPEG-2 TS or `hev1` ISO-BMFF (using MP4Box) and playing this out with VLC?

[jpsdr]

Not before a week, i've started an encode on my PC Video and i have to wait for it to finish.
What have you seen on your side with my file ?

[ShortKatz]

I'm wondering why no one fixes the broken Apple build on M1/M2 architecture. Its broken since 2022-11-02.
https://mailman.videolan.org/pipermail/x265-devel/2022-November/013536.html
https://bitbucket.org/multicoreware/x265_git/issues/623/missing-underscore-for-asm-function-needed
HandBrake has a patch for this issue: https://github.com/HandBrake/HandBrake/blob/master/contrib/x265/P00-darwin-build-fix.patch

[jpsdr]

Finaly i've been able to made some others tests play remuxing, i haven't the bad output with DGIndexNV, but i still have some unexpected "hicup" during the play.

At this point, it realy needs someone who have the proper tools to fully/totaly analyse the result x265 stream to check proper compliancy.

[ShortKatz]

Where can i find it ?
I searched on https://bitbucket.org/multicoreware/x265_git/src/master/ but didn't find anything.

I assume its this one: https://mailman.videolan.org/pipermail/x265-devel/2022-November/013544.html
Does this fix the segfault you are seeing?

[jpsdr]

I personnaly don't have the crash issue, but thanks for the links.
It's just one line, i'll add it for now in my "mod" version and make a new build with it.

[Boulder]

I assume its this one: https://mailman.videolan.org/pipermail/x265-devel/2022-November/013544.html
Does this fix the segfault you are seeing?

I've tested that change and it didn't fix the crash I have. I guess I need to try to find out the exact spot where it happens to get a small sample for debugging.

[jpsdr]

Will wait in that case before new builds, as they took a little time to make...

[Boulder]

I've now got the sample clip, the encoder crashes silently around frame 450 or so if hist-scenecut is enabled.

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

[quietvoid]

I've now got the sample clip, the encoder crashes silently around frame 450 or so if hist-scenecut is enabled.

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

I can't reproduce the crash with the patch.
It crashes with master only.

I'd make sure you patched x265 properly.

[Boulder]

I can't reproduce the crash with the patch.
It crashes with master only.

I'd make sure you patched x265 properly.

I got it now.. I had mistakenly put the custom patch part in the wrong phase of MABS compilation. MABS doesn't seem to give a really verbose log of what happens during compilation so I had no clue :(

And yes, the patched version works on that sample so it looks good for production use :)

[jpsdr]

Ah... Good news, so i'll try today to make builds of my "mod" version.

[jpsdr]

Still about the possibility of --multi-pass-opt-rps broken.
A question from someone investigating on the stream, is the fact of having different PPSs with the same PPS id H265 compliant ?

[rwill]

Still about the possibility of --multi-pass-opt-rps broken.
A question from someone investigating on the stream, is the fact of having different PPSs with the same PPS id H265 compliant ?

Why don't you look this up yourself?

Took me just seconds to find this in 7.4.2.4.2 of the HEVC standard ("Order of VPS, SPS and PPS RBSPs and their activation"):

Any PPS NAL unit containing the value of pps_pic_parameter_set_id for the active PPS RBSP for a coded picture (and consequently
for the layer containing the coded picture) shall have the same content as that of the active PPS RBSP for the coded picture,
unless it follows the last VCL NAL unit of the coded picture and precedes the first VCL NAL unit of another coded picture.

[jpsdr]

Took me just seconds to find this
Because it seems that you, contrary of me, you know what this question was talking about, and where and what to search...

Thanks for the answer.

Edit:
The fact is... My H265 knowlegde is just not enough to understand the answer if it's compliant or not, and so if the stream x265 produced is H265 compliant or not. :(
I would said it's NOT compliant (so in that case a bug in x265), unless...
But i don't know if my stream is in the unless... case.

[jpsdr]

Released new builds of my "mod" version (so, including the histogram cut-scene fix) on my github.

[iAvoe]

Still about the possibility of --multi-pass-opt-rps broken.
A question from someone investigating on the stream, is the fact of having different PPSs with the same PPS id H265 compliant ?

With --opt-qp-pps, --opt-ref-list-length-pps, I have encountered heavy artifact that teared the scene apart as the motion progresses (block and motion residual based), only the beginning still frames were all good. However I'm not very certain if PPSs caused this, as mainwhile I've tried changing from --me star to --me umh and disabled --asm. I don't encode often so this could be just me.

[LigH]

New upload: x265 3.5+70-3177961fb (https://www.mediafire.com/file/3a687fzj9qf06m9/x265_3.5+70-3177961fb.7z/file)

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

News since v3.5+68:
Fix encoder crash with histogram scenecut

[LeXXuz]

I'm kinda lost with this hist-scenecut issue.

Is this relevant for 1080p SDR encodings or only HDR? Is it enabled by default with 3.5+68 and up or not?

[Boulder]

Released new builds of my "mod" version (so, including the histogram cut-scene fix) on my github.

There is the aq-fast-edge patch (https://gist.github.com/noizuy/909ceff9230a24e54073837aaa09e9f7), would it make any sense to incorporate it to SBRC? I suppose the edge detection will always be done in that case so I don't know if the patch fits it straight away.

[Boulder]

I'm kinda lost with this hist-scenecut issue.

Is this relevant for 1080p SDR encodings or only HDR? Is it enabled by default with 3.5+68 and up or not?

--hist-scenecut works for regular HDR (except for my B/W testclip) and for 8-bit SDR encodes.

[jpsdr]

There is the aq-fast-edge patch
I'll see if i can add this to my mod version.

The only warning i would think of it's without blur, the edge detection result/value will change, and so probably change the resulted computed AQ value.
Edges will have more effects, if the actual values of AQ modes are tuned for using the blur edge version results, this may have a negative effect.

[benwaggoner]

I'm kinda lost with this hist-scenecut issue.

Is this relevant for 1080p SDR encodings or only HDR? Is it enabled by default with 3.5+68 and up or not?

Huh, yeah. --hist-scenecut doesn't list its default value, unlike the other parameters. A documentation miss:
--hist-scenecut, --no-hist-scenecut
Indicates that scenecuts need to be detected using luma edge and chroma histograms. --hist-scenecut enables scenecut detection using the histograms and disables the default scene cut algorithm. --no-hist-scenecut disables histogram based scenecut algorithm.

If it is on by default, it would only be in the current Master branch. It is off by default in the current 3.5 release and before.

[quietvoid]

The new --hist-scenecut doesn't have a tunable parameter anymore. There are around 6 hardcoded thresholds for it.
It's also disabled by default.

[iAvoe]

This is an interesting new command line added!

--[no-]mctf Enable GOP based temporal filter.

It was recently changed to --[no-]mcstf.

In my research, mctf builds a lift-scheme network among every GOP, and then creates predict (estimated) & update (residuals) function among the GOP boundary.
The network depth is depending on GOP size, and a decent network must be established on accurate scenecut.
Some of my tests shows performance slowdowns as the memory (16GB) was full (could that be mctf actually stores the whole GOP into RAM?), and film sourced encoding speed from 2.8fps dropped to 0.6fps on a 10700K.

The testing were done with these options:

--mcstf --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 1 --me star --subme 3 --merange 48 --analyze-src-pics --weightb --ref 3 --max-merge 4 --no-open-gop --min-keyint 3 --keyint 312 --fades --bframes 14 --b-adapt 2 --radl 3 --hist-scenecut --constrained-intra --b-intra --crf 21.8 --qpmin 8 --crqpoffs -3 --ipratio 1.2 --pbratio 1.5 --rdoq-level 2 --aq-mode 4 --aq-strength 1 --qg-size 8 --rd 5 --limit-refs 0 --rskip 0 --rect --amp --psy-rd 1.6 --rd-refine --qp-adaptation-range 3 --deblock 0:0 --limit-sao --sao-non-deblock --selective-sao 3 --hash 2 --allow-non-conformance

[benwaggoner]

In my research, mctf builds a lift-scheme network among every GOP, and then creates predict (estimated) & update (residuals) function among the GOP boundary.
The network depth is depending on GOP size, and a decent network must be established on accurate scenecut.
Great description!

Some of my tests shows performance slowdowns as the memory (16GB) was full (could that be mctf actually stores the whole GOP into RAM?), and film sourced encoding speed from 2.8fps dropped to 0.6fps on a 10700K.
Do you mean your machine only has 16 GB of physical RAM? Were you able to determine if the slowdown was due to virtual memory kicking in?

The testing were done with these options:
--mcstf --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 1 --me star --subme 3 --merange 48 --analyze-src-pics --weightb --ref 3 --max-merge 4 --no-open-gop --min-keyint 3 --keyint 312 --fades --bframes 14 --b-adapt 2 --radl 3 --hist-scenecut --constrained-intra --b-intra --crf 21.8 --qpmin 8 --crqpoffs -3 --ipratio 1.2 --pbratio 1.5 --rdoq-level 2 --aq-mode 4 --aq-strength 1 --qg-size 8 --rd 5 --limit-refs 0 --rskip 0 --rect --amp --psy-rd 1.6 --rd-refine --qp-adaptation-range 3 --deblock 0:0 --limit-sao --sao-non-deblock --selective-sao 3 --hash 2 --allow-non-conformance
That's an interesting mix of some unusual parameters that might be triggering some non-standard paths and states. Anime optimized? I'm curious how you came to those settings, and what you were optimizing for.

I can imagine any of bframes >8, radl, and keyint >250 could all trigger some odd combinations that could use extra memory or bypass some optimizations.

A quick check using just --preset slow or slower (your preset is sort of blend of the two, fundamentally) with --mcstf on and off would be less likely to trigger anything odd, and would give a clearer sense of what the typical impact of --mcstf would be.

[jpsdr]

Some of my tests shows performance slowdowns as the memory (16GB) was full (could that be mctf actually stores the whole GOP into RAM?)
mctf disable multi-threading, this is probably the slowdown.

[iAvoe]

Great description!


Do you mean your machine only has 16 GB of physical RAM? Were you able to determine if the slowdown was due to virtual memory kicking in?


That's an interesting mix of some unusual parameters that might be triggering some non-standard paths and states. Anime optimized? I'm curious how you came to those settings, and what you were optimizing for.

I can imagine any of bframes >8, radl, and keyint >250 could all trigger some odd combinations that could use extra memory or bypass some optimizations.

A quick check using just --preset slow or slower (your preset is sort of blend of the two, fundamentally) with --mcstf on / off would be less likely to trigger anything odd, and would give a clearer sense of what the typical impact of --mcstf would be.

I swapped memory sticks (2x16 to 2x8, but both have the same speed & latency) on my PC, the slowdown still kicks in, but 2x8GB kits get to experience more/longer usage spikes.

My theory is that even with film source, you still could get scenes that matches better with anime presets, so the setting still could get extra compression there.

I borrowed x264 settings for --bframes & --keyint, since maintaining longer GOP could result to better compression, but I could be wrong. I wasn't getting into memory usages much, could you elaborate?

I was also unbale to find how much is too much, and I see people testing high values without getting artifacts, so kind of passively accepted them :D

[Boulder]

With grainy content, x265 tends to use plenty of B-frames compared to clean ones. I've always found this a bit odd, and I don't know the reason for the behaviour. Just encode any old crispy B/W movie and it's double digits for the 10 consecutive B-frames stat.

[Boulder]

Something I've noticed while testing --limit-refs and --limit-modes a bit: --no-limit-modes increases the effect of --amp quite a lot, based on what --csv-log-level 2 shows. I'd even say that without --no-limit-modes, it really makes no sense enabling --amp. I don't know if --limit-refs should affect the partition decisions at all, but --limit-refs 1 produced noticably bigger amounts of amp partitions compared to 3 and 0 in this one test of mine.

[Boulder]

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.

Have you had the chance to look at this (adding AQ-mode and that other SBRC related data to the csv log)? I was thinking of maybe doing some peeking on the code this weekend but as I'm not a coder, it takes time :D

[jpsdr]

Not realy, and for the very short glimpse i have made, it doesn't seem easy (or my glimpse was bad). And, unfortunately for you, as it's not a feature i'm interesting on, i'm not realy interesting in spending a lot of time for this...

[Boulder]

Not realy, and for the very short glimpse i have made, it doesn't seem easy (or my glimpse was bad). And, unfortunately for you, as it's not a feature i'm interesting on, i'm not realy interesting in spending a lot of time for this...

Hmm.. I can affect what to write in the csv file, but I cannot figure out how to get the chosen variable value output there :mad:

[benwaggoner]

Something I've noticed while testing --limit-refs and --limit-modes a bit: --no-limit-modes increases the effect of --amp quite a lot, based on what --csv-log-level 2 shows. I'd even say that without --no-limit-modes, it really makes no sense enabling --amp. I don't know if --limit-refs should affect the partition decisions at all, but --limit-refs 1 produced noticably bigger amounts of amp partitions compared to 3 and 0 in this one test of mine.
The behavior certainly makes sense. --limit-modes (and --limit-refs) are early-exit optimizations that less aggressively check --amp and --rect opportunities in order really reduce the speed impact of those modes. Those limits mean that amp and rect will mostly get used where they provide a more obvious benefit. In theory (and apparently practice), while you get fewer of those CU types, the ones you'll get are the ones with the biggest benefit, so the speed/quality tradeoff is better.

When trying to juggle a bunch of settings for optimal quality@perf, it's really a combination of things. I'd generally expect an --amp --rect --limit-modes --limit-refs to yield better net results in less time that just using --amp OR --rect with --no-limit-*. Similarly --tskip without --tskip-fast or --tu-inter- and -intra-depth 4 without --limit-tu 4 can slow things down to much. Better to get 75% of the value of the features in 25% of the time than none of the benefits at all.

These all tend to be pretty content specific (high detail, low noise, sharp edges), so leaving them on by default without --limit* options can waste a whole lot of power & time without material benefit for the majority of GOPs.

[LigH]

Attention:

Patches for a "BBAQ" feature with configuration files are being proposed; prepare for their commitment soon™...

[Boulder]

Attention:

Patches for a "BBAQ" feature with configuration files are being proposed; prepare for their commitment soon™...

I have to ask - what is BBAQ?

[LigH]

It is related to "Scene Cut Aware QP", could not yet spot an explanation for the acronym though...

File containing scenecut-aware-qp mode, window duration and offsets settings required for the masking. Works only with --pass 2

[vpupkind]

It is related to "Scene Cut Aware QP", could not yet spot an explanation for the acronym though...
Bidirectional Boundary Aware Quantization, if I'm not mistaken

[jpsdr]

For those interested, i've made a new build of my mod version.

[LeXXuz]

For those interested, i've made a new build of my mod version.

Always. And thx for the 8bit version btw. :)