x265 HEVC Encoder

[benwaggoner]

Originally Posted by rwill

The keyframe pulsing at frame ~600 is caused because x265 is too afraid to pump bits into the I-Frames, so they are encoded with a really high quantizer in comparison to the surrounding frames. Likely related to VBV settings.

If you're having IDR/i QP issues, you should try:
--hist-scenecut
--scenecut-aware-qp

Both have parameters for fine tuning

And using a qpfile to specify a low QP for that frame should work as well.

And, possibly, since you are using Closed GOP
--radl 2

[Boulder]

Originally Posted by Stacey Spears

Dumb question, can pass 3 use --slow-firstpass? It does not throw a warning if I include it. Just not sure if it actually does anything for pass 3.

I think it does nothing because it's not pass number 1.

Originally Posted by benwaggoner

If you're having IDR/i QP issues, you should try:
--hist-scenecut
--scenecut-aware-qp

Unfortunately at least --hist-scenecut is not good at all. They just left it half finished.

[benwaggoner]

Originally Posted by Boulder

I think it does nothing because it's not pass number 1.

Unfortunately at least --hist-scenecut is not good at all. They just left it half finished.

I thought it was improved in 4.5.

+1. Improved hist-based scene cut algorithm: Reduces false positives by leveraging motion and scene transition info.
+2. Support for RADL pictures at IDR scene cuts: Improves coding efficiency with no significant impact on performance.
+3. Bidirectional scene cut aware Frame Quantizer Selection: Saves bits than forward masking with no noticeable perceptual quality difference.

I've not thoroughly tested the 4.5 version, though.

[quietvoid]

No, the "improvements" they did (back in July 2020) made it much worse and the threshold is practically useless now.

[Stacey Spears]

Originally Posted by Boulder

I think it does nothing because it's not pass number 1.



Unfortunately at least --hist-scenecut is not good at all. They just left it half finished.

I tracked it down. If you call pass 3 with --multi-pass-opt-analysis then the pass 3 stats is 100% identical to pass 1 stats. I guess I misunderstood the warning in the log file.

x265 [warning]: --multi-pass-opt-analysis doesn't support refining analysis through multiple-passes; it only reuses analysis from the second-to-last pass to the last pass. Disabling reading

I had assumed the warning meant it was not going to use "multi-pass-opt-analysis", but the "disabling reading" comment might mean that it is not reading the pass 1 file, which is why pass 3 file is just do over.

[Stacey Spears]

Originally Posted by benwaggoner

And using a qpfile to specify a low QP for that frame should work as well.

This is one of the first things I tried. It basically ignored the QPs I specified for the I frames. You can see in the stats I set the value, but it still coded with high QPs. I don't know if I tried to raise the P and B frames QP. I may give that a shot.

What does RADL do? The docs don't say much.

I have kicked off a 3pass with the UHD 1000 nit tonight. Here is the bat file I am using for this encode test.

[Boulder]

Originally Posted by quietvoid

No, the "improvements" they did (back in July 2020) made it much worse and the threshold is practically useless now.

Yes, I think we both did test the improvements and found out that it's basically not working at all. And then it was just left as it is.

[Stacey Spears]

Here is the Sony encode. It does not have the keyframe pulsing artifacts or the blocking on the deer shot. It ended up ~29 Mbps.

[Stacey Spears]

Originally Posted by benwaggoner

And using a qpfile to specify a low QP for that frame should work as well.

And, possibly, since you are using Closed GOP
--radl 2

I tried RADL2, did not help. It did raise the QP of two B frames at the start of each GOP.

I was able to raise the P and B frame QPs, which in turn lowered the I frame QPs using the QP file.

I am testing to see if open-gop can be used on BD. The encode from Sony looks like it was open gop or at least the MUX said it was. I made a change to the --uhd-bd flag to force open gop and will test mux it shortly.

Edit: Open GOP does mux. I guess the question is, why did they disable Open GOP when you enable --ud-bd? Sony seems to be using Open GOP for their UHD BD encodes. I am going to re-encode the UHD version with Open GOP enabled.

[excellentswordfight]

Originally Posted by Stacey Spears

I tried RADL2, did not help. It did raise the QP of two B frames at the start of each GOP.

I was able to raise the P and B frame QPs, which in turn lowered the I frame QPs using the QP file.

I am testing to see if open-gop can be used on BD. The encode from Sony looks like it was open gop or at least the MUX said it was. I made a change to the --uhd-bd flag to force open gop and will test mux it shortly.

Edit: Open GOP does mux. I guess the question is, why did they disable Open GOP when you enable --ud-bd? Sony seems to be using Open GOP for their UHD BD encodes. I am going to re-encode the UHD version with Open GOP enabled.

Looks like the spec doesnt mandate closed or open gop, both should be viable.

Section 3.2

https://web.archive.org/web/20160605...per_150724.pdf

edit. Getting the same issue here with your source, and the issue persist even with open-gop (skipping uhd-bd preset and setting the other settings manually except for closed gop). And the issue is gone using crf mode...

[Stacey Spears]

Originally Posted by excellentswordfight

Looks like the spec doesnt mandate closed or open gop, both should be viable.

Section 3.2

https://web.archive.org/web/20160605...per_150724.pdf

edit. Getting the same issue here with your source, and the issue persist even with open-gop (skipping uhd-bd preset and setting the other settings manually except for closed gop). And the issue is gone using crf mode...

I have gone ahead and modified x265 to honor the open-gop settings for BD. I did a test mux and it worked. I also confirmed that another facility encodes all of their UHD BDs using open gop with the Sony encoder.

The Sony encode I provided earlier used 8 slices, which is what they use for UHD. They re-encoded with 4 slices and also adjusted the quant table to preserve more high frequency detail. It bumped the bitrate 10 Mbps. I will share it after I QC.

I am doing a 3-pass right now. Once pass 3 (2nd pass) is complete, I will probably create a QP file, from the stats file, to push up the P and B frame QPs for the shots with keyframe pulsing and then re-start pass 1 using the new QP file.

In a short test earlier, it looked like the open gop helped with the keyframe pulsing in the fence shot.

It does seem like x265 over spends on P and B frames, at least on this content. The shots are mostly static in terms of motion.

I wish someone would implement segment re-encoding, then I could fix the shots a little more easily.

[benwaggoner]

Originally Posted by Stacey Spears

I have gone ahead and modified x265 to honor the open-gop settings for BD. I did a test mux and it worked. I also confirmed that another facility encodes all of their UHD BDs using open gop with the Sony encoder.

The Sony encode I provided earlier used 8 slices, which is what they use for UHD. They re-encoded with 4 slices and also adjusted the quant table to preserve more high frequency detail. It bumped the bitrate 10 Mbps. I will share it after I QC.

I am doing a 3-pass right now. Once pass 3 (2nd pass) is complete, I will probably create a QP file, from the stats file, to push up the P and B frame QPs for the shots with keyframe pulsing and then re-start pass 1 using the new QP file.

Wow, doesn't this increasingly feel like authoring VC-1 HD-DVD/BD titles circa 2006 ?

In a short test earlier, it looked like the open gop helped with the keyframe pulsing in the fence shot.

I hope your open GOP fix makes it into the main branch! This is exactly the sort of thing Open GOP is supposed to help. And it matters all the more with short GOPs like this (1 sec) since most IDRs won't align with cuts. Open GOP is better than RADL.

It does seem like x265 over spends on P and B frames, at least on this content. The shots are mostly static in terms of motion.

You could potentially play with --ipratio and --pbratio there.

I wish someone would implement segment re-encoding, then I could fix the shots a little more easily.

I think it is actually possible with x265 if you don't mind appending in mp4box or something.
You'd use --seek and --frames to set in/out points, and set --chunk-start and --chunk-end to expand that range by a few GOPs to get VBV state to match.

If it's a --pass 2 or 3, I'm not sure if the --chunk parameters are needed; maybe VBV state of the initial state works.

It seems sufficiently advanced encoding often winds up replicating PEP, eh?

[Stacey Spears]

Originally Posted by benwaggoner

Wow, doesn't this increasingly feel like authoring VC-1 HD-DVD/BD titles circa 2006 ?


I hope your open GOP fix makes it into the main branch! This is exactly the sort of thing Open GOP is supposed to help. And it matters all the more with short GOPs like this (1 sec) since most IDRs won't align with cuts. Open GOP is better than RADL.


You could potentially play with --ipratio and --pbratio there.


I think it is actually possible with x265 if you don't mind appending in mp4box or something.
You'd use --seek and --frames to set in/out points, and set --chunk-start and --chunk-end to expand that range by a few GOPs to get VBV state to match.

If it's a --pass 2 or 3, I'm not sure if the --chunk parameters are needed; maybe VBV state of the initial state works.

It seems sufficiently advanced encoding often winds up replicating PEP, eh?

I tried setting ipratio and pbratio to higher values like 2.0, as a test, but it still ends up lowering P and B while maintaining the high I frame QPs on the same shots.

For the short comings of VC1, PEP had some great segment re-encoding capabilities.

You can use the concat flag (don't recall the exact name off hand) in x265 to split the clip up. I know someone who does this to break the movie into chunks for parallel encoding ala PEP. But for an 8-minute video, seems odd to break-up even further.

I need to do some testing with the encode on a few BD players to make sure there is not a playback issue. I wish I knew why they disabled it. Could have been confusion about it being supported OR to work around a player issue.

I made a change where I could use the zones file to set --qpmax, but when I used the feature, no I frames were inserted for the rest of the encode, and I have not gotten around to debugging it. I was going to set a qpmax on the GOPs where the I frames went higher. Nothing like brute force!

[benwaggoner]

Originally Posted by Stacey Spears

I tried setting ipratio and pbratio to higher values like 2.0, as a test, but it still ends up lowering P and B while maintaining the high I frame QPs on the same shots.

For the short comings of VC1, PEP had some great segment re-encoding capabilities.

You can use the concat flag (don't recall the exact name off hand) in x265 to split the clip up. I know someone who does this to break the movie into chunks for parallel encoding ala PEP. But for an 8-minute video, seems odd to break-up even further.

I need to do some testing with the encode on a few BD players to make sure there is not a playback issue. I wish I knew why they disabled it. Could have been confusion about it being supported OR to work around a player issue.

I made a change where I could use the zones file to set --qpmax, but when I used the feature, no I frames were inserted for the rest of the encode, and I have not gotten around to debugging it. I was going to set a qpmax on the GOPs where the I frames went higher. Nothing like brute force!

I used to have an Excel script that would take x264 per-frame console output (like the x265 .csv files) and turn that into a qpfile. The main use was to determine optimal IDR placement in a first pass and synchronize that across different ABR bitrates.

It'd be easier to implement that with .csv, and then you could tweak each frame's type and qp for each frame.

[Stacey Spears]

Originally Posted by benwaggoner

I used to have an Excel script that would take x264 per-frame console output (like the x265 .csv files) and turn that into a qpfile. The main use was to determine optimal IDR placement in a first pass and synchronize that across different ABR bitrates.

It'd be easier to implement that with .csv, and then you could tweak each frame's type and qp for each frame.

I have a python script that you run against the stats file to dump out the frame types and QPs if you like. This is used to encode the Dolby Vision enhancement layer since they need the same frame types across the two layers.

I need to write a tool that will dump the QPs on any hevc file. We wrote a tool recently that allows us to move the SEI from one hevc file to another. I use this to move the SL-HDR2 SEI messages from the file Philips modified to a re-encoded file. This way Philips does not have to reprocess the clip for me. They have done it twice already, now they don't have to.

[Selur]

using:

x265 --input - --output-depth 10 --y4m --profile main10 --hme --hme-search star,hex,full --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --crf 18.00 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --range limited --colormatrix bt470bg --output "E:\Temp\2021-05-02@15_19_28_0110_01.265"

resulted in sei:

cpuid=1111039 / frame-threads=4 / numa-pools=16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=640x352 / interlace=0 / total-frames=0 / 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=25 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / 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=2 / dynamic-rd=0.00 / ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=0 / limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / sao / no-sao-non-deblock / rd=6 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.50 / psy-rdoq=10.00 / rd-refine / no-lossless / cbqpoffs=-2 / crqpoffs=-2 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=0.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=5 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass

-> is it a bug that "no-hme" is shown or am I missing something ?

Cu Selur

[benwaggoner]

It does seem like a bug, but you can check by looking at the output of hme on/off and verify that there are differences in output and encoding time. Visual differences with HME are most likely encoding very noisy content at 4K, as the first 960x540 analysis will have averaged out lots of the noise and have picked out the underlying features a lot better.

[Stacey Spears]

Originally Posted by benwaggoner

And using a qpfile to specify a low QP for that frame should work as well.

So far using a QPFile to raise the QP of the P and B frames seems to be working well. For the UHD version, one shot needed it and I am also using it for two other shots where the I frame QP value is 3-6 higher than P and B. These additional shots had pulsing in the HD version.

The end result is running 4.75 passes for each encode. I have 12 versions to encode this way.

1. Encode to passes and stop the 2nd pass (really pass 3 for the stats file) after it finishes the last shot in question.
2. create the QP File. I use the pass 3 stats file since its QPs are closer to final than the pass 1 stats file.
3. Encode three passes using the QP File.

Will be running a mux test today with the Atmos audio just to confirm this will actually work in the end.

For the shot with visible pulsing, I am rounding the pass 3 QP and then adding 3 to it. For the other two shots, I am rounding and then adding 1.

At this point I can only assume the x265 devs are busy on x266.

Edit: It muxed.

[benwaggoner]

Originally Posted by Stacey Spears

So far using a QPFile to raise the QP of the P and B frames seems to be working well. For the UHD version, one shot needed it and I am also using it for two other shots where the I frame QP value is 3-6 higher than P and B. These additional shots had pulsing in the HD version.

The end result is running 4.75 passes for each encode. I have 12 versions to encode this way.

1. Encode to passes and stop the 2nd pass (really pass 3 for the stats file) after it finishes the last shot in question.
2. create the QP File. I use the pass 3 stats file since its QPs are closer to final than the pass 1 stats file.
3. Encode three passes using the QP File.

Will be running a mux test today with the Atmos audio just to confirm this will actually work in the end.

For the shot with visible pulsing, I am rounding the pass 3 QP and then adding 3 to it. For the other two shots, I am rounding and then adding 1.

At this point I can only assume the x265 devs are busy on x266.

Edit: It muxed.

I'm glad it muxed! But yikes, that sounds painful.

If you're having to do so many versions, perhaps --abr-ladder could be helpful?

[Stacey Spears]

Originally Posted by benwaggoner

I'm glad it muxed! But yikes, that sounds painful.

If you're having to do so many versions, perhaps --abr-ladder could be helpful?

Isn't --abr-ladder more for layered encodes in the streaming scenario?

3 of 12 are done so far. I currently have the next three running their initial two pass to figure out what to use for the qp file. This is for a single project, so not the end of the world. If I were a streaming service, this would not be practical. The real solution is for someone to debug the issue and figure out why the rate control is opting for low P and B QPs with high I QPs. Perhaps I should see if I can get MSU to use the content for future CODEC shootouts.

BTW, off topic, is it true that Blue Star has closed many locations in Portland? So sad if true!