x265 HEVC Encoder

[LigH]

Thanks @MeteorRain. As you can see, it worked well; the only change missing, to my knowledge, is adapting FindFF.cmake which had an exception for Win32 which may have meant to handle MSVC only but is not suitable for GCC in MinGW.

[aegisofrime]

Originally Posted by LigH

x265 multilib build script for x86-64 Windows EXE in media-autobuild suite's MSYS2/MinGW64 mintty shell

Configured for media-autobuild suite with ccache enabled. Naming is a bit historical, I have a few similar scripts with different content and architectures (also W32 and W32XP).

Results will remain in /build/x265_git-git/build/msys64_hdr10_ml/8bit in the MABS directory structure. This is for pure git sources from MultiCoreWare, without modifications.

Thanks, cheers! Will give it a whirl

[Stacey Spears]

Been trying to encode HD HDR at 90 Mbps for my upcoming Ultra HD calibration disc. x265 seems to do worse the higher the bitrate you go. I get lots of keyframe pulsing and the artifact shown below, which seems to occur on I-frames. The same content at UHD resolution has much less keyframe pulsing. I have submitted a few reports on bitbucket and the only person to respond is Ben, who does not work for them. Anyone have an ear at Multicoreware that can take a look? Happy to provide the YUV source to them. I am using the latest code (3.5) on Windows.

The I-frames seem to spike while P and B encode at much lower QPs. In fact, the HD encode at 90 Mbps has higher QP spikes than the same content at UHD resolution, which is also using 90 Mbps average and 98 Mbps peak. The bitrate for the HD encode ends up ~58 Mbps after when the 2nd pass finishes.

For some reason this shot has a serious issue. It occurs every time I encode it. One other shot has the same problem. Here is an iPhone video of the artifact in question. If the link does not work, let me know. Not sure what it is about this shot that causes the ugly blocking near the bottom of the frame. This artifact does not show in the UHD version, just HD. Ignore the blown out look, that is Windows tone mapping.



Shot list with notes on which shots have keyframe pulsing. Of these, only shot 47 has keyframe pulsing at UHD resolution. UHD has much more keyframe pulsing if I use the default qpstep value. I have to lower it to 1 to reduce the pulsing to shot 47 only.

This is a cost no object encode where cost is time. Just want the highest quality possible. It is short at ~8-minutes in length. A friend is trying the Sony encoder to see how it turns out. The UHD encode is good overall, except for one shot (Shot 47) with keyframe pulsing. The full enhancement layer of Dolby Vision almost fixes up the pulsing at UHD resolution.

Thank you in advance for any help you can provide.

[LigH]

If it is urgent for you, the best way to contact the developers is via their mailing list; they may read here occasionally, but not guaranteed. Point them to the Link in the top right corner of your post. In any case, a complete command line set will be helpful.

It looks indeed like decoding issues as if the data is corrupt from a specific distance from the start of the frame bitcode, or at least the bitrate control may fail, like spending excess in the beginning and not having any reserve in the end. Here it will be important to know if you set any limiting parameters like VBV.

[Stacey Spears]

Originally Posted by LigH

It looks indeed like decoding issues as if the data is corrupt from a specific distance from the start of the frame bitcode, or at least the bitrate control may fail, like spending excess in the beginning and not having any reserve in the end. Here it will be important to know if you set any limiting parameters like VBV.

Here are the majority of settings:

--frames 11235 --deblock=-2:-2 --frame-threads 1 --no-sao --qpstep 1 --rskip 0 --no-tskip --subme 7 --rd-refine --bframes 3 --b-adapt 0 --aq-mode 2 --no-cutree --input-res 1920x1080 --input-csp i420 --preset placebo --fps 24000/1001 --profile main10 --level-idc 51 --high-tier --no-open-gop --keyint 24 --min-keyint 1 --bitrate 90000 --vbv-maxrate 98000 --vbv-bufsize 99000 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --chromaloc 2 --hrd --aud --sar 1:1 --input-depth 10 --output-depth 10 --uhd-bd --repeat-headers --rc-lookahead 24 --range limited --slices 1

In theory, BD can have vbv-bufsize set to 100000 but x265 does not seem that strict at enforcing and can underflow, so I set to 99000. Same for vbv-maxrate. 100000 is the max, but I find going over 98000 can underflow when trying to mux.

These same settings are used for HD and UHD encodes. Here is the stats file and csv from the 2nd pass. The deer shot starts at frame 877.

[Boulder]

Have you tried running a CRF encode to see if it's the 2-pass rate control acting up? I'm not the expert on VBV related matters, but having the average bitrate so close to the limits could work against you. Or run a third pass and see if it changes anything.

For HDR encodes, you should also set --hdr-opt.

[HD MOVIE SOURCE]

Originally Posted by LigH

If it is urgent for you, the best way to contact the developers is via their mailing list; they may read here occasionally, but not guaranteed. Point them to the Link in the top right corner of your post. In any case, a complete command line set will be helpful.

It looks indeed like decoding issues as if the data is corrupt from a specific distance from the start of the frame bitcode, or at least the bitrate control may fail, like spending excess in the beginning and not having any reserve in the end. Here it will be important to know if you set any limiting parameters like VBV.

Who exactly do you contact about these types issues?

[LigH]

The mailing list address is x265-devel@videolan.org (register at mailman before writing there) ... and they will assign a matching developer internally, I believe.

[Stacey Spears]

Originally Posted by Boulder

Have you tried running a CRF encode to see if it's the 2-pass rate control acting up? I'm not the expert on VBV related matters, but having the average bitrate so close to the limits could work against you. Or run a third pass and see if it changes anything.

For HDR encodes, you should also set --hdr-opt.

I am signaling HDR, I left it off the post to reduce all the settings.

I tried multipass and since I am using the same settings for pass 1 and 2, the extra passes made no difference. e.g. The 1st and middle pass were virtually identical. Based on my testing, the multipass helps if you use faster settings for pass 1.

I tried a lower average and it made no meaningful difference. e.g. I tried making the peak 1.5x and 2x the average.

Have not tired CRF, not sure it will mux on BD.

Thank you for your feedback.

[Stacey Spears]

Originally Posted by LigH

The mailing list address is x265-devel@videolan.org (register at mailman before writing there) ... and they will assign a matching developer internally, I believe.

Thank you. I have gone ahead and sent an email.

[Boulder]

Originally Posted by Stacey Spears

I am signaling HDR, I left it off the post to reduce all the settings.

I tried multipass and since I am using the same settings for pass 1 and 2, the extra passes made no difference. e.g. The 1st and middle pass were virtually identical. Based on my testing, the multipass helps if you use faster settings for pass 1.

I tried a lower average and it made no meaningful difference. e.g. I tried making the peak 1.5x and 2x the average.

Have not tired CRF, not sure it will mux on BD.

Thank you for your feedback.

--hdr-opt is actually not for signalling HDR, it contains some specific HDR-related optimizations

Your results are very interesting, especially that passes 1 and 2 are identical. There definitely should be a somewhat noticable difference, at least I've always seen the average bitrate of the first pass be off from the target. CRF should not cause any muxing problems if you use VBV, it does use the same rate control as a multipass but you just cannot control the final bitrate.

Does that issue occur also with standard settings from a profile, say --slower (with the HDR stuff added)? I know personally that rskip is one weird thing, it can mess things up.

PS. Aq-mode 2 is still crap for high bitrate

[Stacey Spears]

Originally Posted by Boulder

--hdr-opt is actually not for signalling HDR, it contains some specific HDR-related optimizations

Your results are very interesting, especially that passes 1 and 2 are identical. There definitely should be a somewhat noticable difference, at least I've always seen the average bitrate of the first pass be off from the target. CRF should not cause any muxing problems if you use VBV, it does use the same rate control as a multipass but you just cannot control the final bitrate.

Does that issue occur also with standard settings from a profile, say --slower (with the HDR stuff added)? I know personally that rskip is one weird thing, it can mess things up.

PS. Aq-mode 2 is still crap for high bitrate

This is what I removed from the command line to reduce clutter:
--master-display G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(%peak%0000,50) --max-cll "%maxcll%,%maxfall%" --hdr10 --hdr10-opt

hdr10-opt lowers the QP of chroma relative to luma for perceptual reasons.

If I use the slow first pass with identical settings, then pass 1 and the middle pass are virtually identical. The final pass does not change. If I use faster settings for pass 1, then the middle pass does make a difference. If I use the same settings for both passes, the final pass is much better at converging the final bitrate with UHD. If I use a faster first pass, then the final pass comes in 2-3 Mbps lower than the target bitrate. Hope that makes sense. I have tested these more than once as I thought something went wrong.

With CRF, can you still set a peak? I do have the hard limit of 100 Mbps, though if I use > 98, it often won't mux. x265 seems a little slapdash on enforcing VBV constraints, so I always have to leave room for a little slop.

I have used aqmode of 0 and 1 as well. I used the 0 since the QP reported in the CSV is not the QP I was interested in, which is shown in the stats file. I wish I could dump a stats file of the final pass since it contains several different QP values.

I have tried faster, slow and veryslow in addition to placebo.

When I worked on VC1, we always honored the P and B frame delta the users set. e.g. if P delta was set to 1.5 and I was 5, then P would be 6.5. x265 does not seem to work this way. I have I frames with QPs over 20 and then the P and B frames with QP under 10 in the same GOP. It is this situation where the keyframe pulsing rears its ugly head.

I also tried the rc-grain rate control, which was interesting, but did not solve the pulsing issue. It looked promising at first.

I may try breaking the montage into shorter clips and encoding. I do worry about the concat points. I think if I encode the one shot with pulsing, by itself, it encodes fine. Breaking things up does make the Dolby Vision version a bit more complicated. On a side note, the Dolby Vision Full Enhancement layer actually cleans up the keyframe pulsing a lot. However, I am not using Dolby Vision for the HD version. Here is the menu mock-up for the Montage disc. (it is a 3-disc set) We support all HDR formats on Blu-ray and several different nit levels.

Thank you again, I do appreciate all of the feedback.

[Boulder]

Originally Posted by Stacey Spears

With CRF, can you still set a peak? I do have the hard limit of 100 Mbps, though if I use > 98, it often won't mux. x265 seems a little slapdash on enforcing VBV constraints, so I always have to leave room for a little slop.

Yes, VBV can be applied also to CRF encodes.

However, looking at the frame shows something more wrong than any of the usual suspects because the blocking is just at the bottom and not in the whole frame.

When I worked on VC1, we always honored the P and B frame delta the users set. e.g. if P delta was set to 1.5 and I was 5, then P would be 6.5. x265 does not seem to work this way. I have I frames with QPs over 20 and then the P and B frames with QP under 10 in the same GOP. It is this situation where the keyframe pulsing rears its ugly head.

Keyframe pulsing might be fought by lowering the --ipratio and --pbratio values. --tune grain sets them low for this reason I think.

Thank you again, I do appreciate all of the feedback.

No worries Problems like these tickle my brain a bit which is always a plus.

EDIT: and if you like, I can try encoding the source on my system to verify the issue. The whole file is probably way too big, but maybe a scene or two before and after the problemous one could do.

[Blue_MiSfit]

I too am eagerly monitoring this thread Quite fascinating as I've never seen behavior like this with x265 before.

[excellentswordfight]

Originally Posted by Stacey Spears

With CRF, can you still set a peak? I do have the hard limit of 100 Mbps, though if I use > 98, it often won't mux. x265 seems a little slapdash on enforcing VBV constraints, so I always have to leave room for a little slop.

Yes, you can set vbv with crf. Although you might still want to use 2ass abr for your use case, it would still be interesting to see if the issue persists.

Also note that different bd disks support different muxrates, not all will support a 100Mbps video track, and altough I havnt done any Dolby vision authoring from what i can tell from the spec is that the 100Mbps video track limit includes the enhancement layer.

I have tried faster, slow and veryslow in addition to placebo.

I guess that you have also tried more default like settings?

Does the issue persist with something simple like this muxed to an mp4?

--preset slower --hdr10-opt --aq-mode 1 --vbv-maxrate 98000 --vbv-bufsize 98000 --uhd-bd --bitrate 50000 + hdr/color flags

[Stacey Spears]

Originally Posted by Boulder

EDIT: and if you like, I can try encoding the source on my system to verify the issue. The whole file is probably way too big, but maybe a scene or two before and after the problemous one could do.

I will go ahead and share everything so you can test encoding. It gives everyone some more content to test encoders. The moose in shot 23 has been used for 8K vs 4K blind test hosted at WB Labs and presented at HPA/SMPTE. Scott Wilkinson had written about that blind test in the past.

The content was shot on RED Dragon VistaVision and Monstro VistaVision. The camera and lens used are in the shot list. Was graded by Dolby on a Pulsar set to BT.2020 (not P3) mode. Resolve was used for the actual grading. Dolby exported 16-bit EXRs, which preserved the out of gamut colors. Resolve does not color manage wide gamut content very well and the source was far greater than 2020. I used Transkoder to render the various Dolby trim pass versions and to fix the gamut issues from Resolve. I believe Transkoder is 2nd to none in gamut and tone mapping. This was the 1000 nit trim pass render from the 10,000 nit grade. Since the Pulsar is a 4000 nit display, we used scopes to place stuff > 4000 nits and > P3.

For anyone that might have the current disc, this has been re-edited with four shots replaced and others deleted to increase the length of shots. Trying to get a lot of different content into a single demo clip. It was also re-graded to fix some of the gamut and luminance clipping, but still needed Transkoder to fully address the gamut issues.

We also have new Atmos audio, but that is not included since the rights I paid for are on-disc only.

Here are all the files you need.
1. YUV (inside a 7z to reduce the size to 14 GB. When you decompress, it will be ~65 GB or 11235 frames)

2. The bat files. I use two bat files. 01_Encode_HDR_Montage_HD_01000.bat is the file that feeds the main bat file Encode_HDR_Montage_HD_2pass_90.bat. Obviously you will need to tweak the paths. And yes, the MaxCLL is higher than Mastering Display Luminance. Those are the odd specular highlights that go above 1000. Lots of them.

3. The QPFile is set so that I can set chapter points on any shot. For authoring, we have a marker every second that allows the user to switch between the different montage flavors and jump to roughly the same point, which makes it easier to compare.

4. There is some moiré in various shots due to the scaling from UHD2 (7680x4320) to HD. I will re-visit before the final-final encoding. The peacock feather and parrots feathers show the moiré. Looks much better at UHD. In fact, one of the montages is a UHD vs. HD. In that case, I had to scale the HD to UHD and then I do the circular wipe.

5. AnalyzeIt is my YUV viewer. Lots of little tools built-in. (WFM, Vector, Histogram, Pixel Values, etc...) The raw_data is a text file with basic image info so you don't have to manually type in the resolution, color space and FOURCC codes when opening a YUV file. This also opens AVIs and BMPs. I wrote this back in 2004, so please forgive the Win32 UI. It is also a viewer, not a player. It does not scale the image, so you can drag it around inside the viewer. There is a zoom window you can bring up. (alt + z) The highlight feature will show all pixels <16 (or 64 in 10-bit) as green and > 235 (940) as hot pink. It highlights the pixels outside the range AFTER conversion to RGB, not in YUV. You can view any channel, R, G, B, Y, U and V. The histogram can show both YUV and RGB histograms. It is the tool we wrote so we can verify our test patterns. Alt + D will bring up the macroblock widow. (16x16 grid of pixel values) Use the arrow keys to move the cursor around.

6. The shot list with the shots in question called out in column P. (Called HD Encode for some odd reason)

7. The hevc encoded file from the bat file.

Look forward to seeing what people come up with.

We use HTR mode, which allows ~126 Mbps for combined audio and video. Video is still limited to 100 Mbps. When doing Dolby Vision, both layers must fit within the 100 Mbps. This clip is HDR10 only. HTR mode is limited to a % of the disc. e.g. On a BD100, you can use HTR for ~87 GBs of the disc.

Normally I would not share the YUV source, but this is the HD version and it would be nice to get this resolved.

Previously I said cost-no-object, where cost is time. I did try and disable WPP, but that is tad slow!!!! So really not cost-no-object in that regard.

The overall APL of this clip is high, which trips up some tone mapping algorithms. e.g. Windows tone mapping fails miserably trying to tone map. MadVR, on the other hand, handles it like a hot knife through butter. Normally I QC on an LG OLED. Dynamic tone mapping enabled will reduce clipping, but it changes stuff it should not.

You may notice the dropbox folder is named Ben. I originally shared this with Ben Waggoner.

[benwaggoner]

Originally Posted by Stacey Spears

Here are the majority of settings:

--frames 11235 --deblock=-2:-2 --frame-threads 1 --no-sao --qpstep 1 --rskip 0 --no-tskip --subme 7 --rd-refine --bframes 3 --b-adapt 0 --aq-mode 2 --no-cutree --input-res 1920x1080 --input-csp i420 --preset placebo --fps 24000/1001 --profile main10 --level-idc 51 --high-tier --no-open-gop --keyint 24 --min-keyint 1 --bitrate 90000 --vbv-maxrate 98000 --vbv-bufsize 99000 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --chromaloc 2 --hrd --aud --sar 1:1 --input-depth 10 --output-depth 10 --uhd-bd --repeat-headers --rc-lookahead 24 --range limited --slices 1

In theory, BD can have vbv-bufsize set to 100000 but x265 does not seem that strict at enforcing and can underflow, so I set to 99000. Same for vbv-maxrate. 100000 is the max, but I find going over 98000 can underflow when trying to mux.

These same settings are used for HD and UHD encodes. Here is the stats file and csv from the 2nd pass. The deer shot starts at frame 877.

Have you found any value from --subme 7? It's beyond even --preset placebo and I suspect hasn't gotten any real tuning in years.

[Stacey Spears]

Originally Posted by benwaggoner

Have you found any value from --subme 7? It's beyond even --preset placebo and I suspect hasn't gotten any real tuning in years.

On test patterns using a fixed QP, which is what I do for patterns, yes. On motion content with rate control, hard to say.

[benwaggoner]

Originally Posted by Stacey Spears

On test patterns using a fixed QP, which is what I do for patterns, yes. On motion content with rate control, hard to say.

That would make sense.

Just curious - have you tried just --qp to what you want, keeping --vbv-maxrate and --vbv-bufsize without setting bitrate, and changing --aq-mode 0? That should result in a truly fixed QP except for when it would exceed the peak bitrate. With --csv-log-level 2, you can think look at the log file to see if the QP was exceeded at any point.

With test content where encoding time isn't material, you might also try --tskip and perhaps even --cu-lossless. At very high quality/low qp, they can save some bits for very sharp-edged blocks. In special cases, --fades and --frame-dup might help a bit as well.

[Stacey Spears]

Originally Posted by benwaggoner

That would make sense.

Just curious - have you tried just --qp to what you want, keeping --vbv-maxrate and --vbv-bufsize without setting bitrate, and changing --aq-mode 0? That should result in a truly fixed QP except for when it would exceed the peak bitrate. With --csv-log-level 2, you can think look at the log file to see if the QP was exceeded at any point.

With test content where encoding time isn't material, you might also try --tskip and perhaps even --cu-lossless. At very high quality/low qp, they can save some bits for very sharp-edged blocks. In special cases, --fades and --frame-dup might help a bit as well.

tksip made things worse on some synthetic test patterns, which surprised me given that it should help them. To qualify worse, I mean I am encoding all test patterns at QP 0 and they were further away from mathematically lossless than w/o. The pixel values matter on a test pattern, so visually lossless is not enough. tu-inter of 4 also had a negative impact more often than not and that is the default for placebo. I do use cu-lossless for all test patterns.