x265 HEVC Encoder

[benwaggoner]

As I can't summon one thousand people in my room every time I need a reference, is VMAF good enough or there is something better?
If there's a VMAF difference of at least three, that generally indicates a visible quality difference. Differences smaller than that can go either way.

VMAF really can't tell the difference between different --aq-mode and --aq-strength values, so it's not helpful to tune those parameters.

VMAF is also luma only, so chroma issues will go entirely ignored.

[tormento]

VMAF is also luma only, so chroma issues will go entirely ignored.

What do you suggest me, but my eyes?

[benwaggoner]

What do you suggest me, but my eyes?
Someone else's eyes ;)?

The best quality metric available to the public I know of is p1204.3.

Some info: https://streaminglearningcenter.com/blogs/itu-t-p1203-p1204.html

[tormento]

The best quality metric available to the public I know of is p1204.3.
Do you know some working Windows build?

[Blue_MiSfit]

There's a Dockerfile in the reference implementation here:
https://github.com/Telecommunication-Telemedia-Assessment/bitstream_mode3_p1204_3

I'll cut a Docker build for you :)

[Blue_MiSfit]

https://hub.docker.com/repository/docker/dprestegard/bitstream_mode3_p1204_3/general


$ docker run dprestegard/bitstream_mode3_p1204_3:latest
usage: __main__.py [-h] [--result_folder RESULT_FOLDER] [--model MODEL]
[--cpu_count CPU_COUNT]
[--device_type {pc,tv,tablet,mobile}]
[--device_resolution {3840x2160,2560x1440}]
[--viewing_distance {1.5xH,4xH,6xH}]
[--display_size {10,32,37,5.1,5.5,5.8,55,65,75}]
[--tmp TMP] [-d] [-nocached_features] [-q]
video [video ...]
__main__.py: error: the following arguments are required: video


If you're not familiar with Docker, you can just install Docker Desktop on windows and then run

docker run dprestegard/bitstream_mode3_p1204_3:latest

You can pass in files on your local system via a bind mount. It's pretty simple :) https://docs.docker.com/storage/bind-mounts/

[Ritsuka]

Does anyone get random crashes when running on a CPU with heterogeneous cores? I've got some reports of on both Apple Silicon and Intel, but couldn't reproduce anything yet.

[LigH]

You mean something like ARM big.LITTLE (https://en.wikipedia.org/wiki/ARM_big.LITTLE) as used in some mobile devices?

[Ritsuka]

Yes, but that's not only in mobile devices, even an Intel desktop CPU like i9-14900K has got 8 performance cores and 16 efficient cores for example.

[tormento]

I'll cut a Docker build for you :)
I'd prefer to use a "cleaner" solution, i.e. direct exe.

[rwill]

Someone else's eyes ;)?

The best quality metric available to the public I know of is p1204.3.

Some info: https://streaminglearningcenter.com/blogs/itu-t-p1203-p1204.html

Its a "no-reference" model? And this is supposed to be the best? Press X for doubt.

[benwaggoner]

Its a "no-reference" model? And this is supposed to be the best? Press X for doubt.
It has the best subjective correlation for perceptual video quality that I've seen.

Of course, VMAF isn't exactly a video quality metric - it is a video distortion metric. It doesn't try to say if video looks good or not, but how perceptually degraded from the source it will be.

VMAF will rate a very accurate reencode of a very terrible quality source very high, and a pretty accurate reencode of a great looking source lower, even though viewers would say the latter looks much better.

p1204.3 predicts how a viewer would relate the final quality delivered. As viewers don't have a source to compare to, that experience is fundamentally no-reference, so a no-reference metric can make sense.

Quality and distortion metrics each have their place, and which is appropriate is based on what you're trying to accomplish.

That said, I find p1204.3 to be more useful in encoder tuning than VMAF, even though a distortion metric would seem more appropriate.

There has been some interesting early work done combining reference, bitstream, and baseband analysis for further subjective correlation improvements. The nice thing about Machine Learning is that you can throw in whatever base metrics you want to for training as long as you've got a good ground truth data set of subjective ratings.

[benwaggoner]

Do you know some working Windows build?
I don't. It's not something I run locally. It gets done in the Cloud on Linux.

[cubicibo]

Is there any reference post or site providing reference x265 encode parameters for UHD BD?

[LigH]

New upload: x265 3.5+119-68298344c (https://www.mediafire.com/file/cdsh3bjxrem3ilk/x265_3.5+119-68298344c.7z/file)

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

Recent fixes: high bit depth in y4m; lookahead in qp file; min VBV fullness

[LigH]

New upload: x265 3.5+120-7c8a449ff (https://www.mediafire.com/file/0pcbu7pe7n0u87d/x265_3.5+120-7c8a449ff.7z/file)

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

Recent fixes: Qp tuning in SBRC

[FranceBB]

New upload: x265 3.5+120-7c8a449ff (https://www.mediafire.com/file/0pcbu7pe7n0u87d/x265_3.5+120-7c8a449ff.7z/file)

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

Recent fixes: Qp tuning in SBRC

Thanks for the new build.


p1204.3 predicts how a viewer would relate the final quality delivered. As viewers don't have a source to compare to, that experience is fundamentally no-reference, so a no-reference metric can make sense.

Yes absolutely.
I think Tektronix uses something similar in Cerify/Aurora called "PVQ" (Perceptual Video Quality) which analyses the video without any reference and spits out a score.
Too bad Telestream bought them and turned them into a cloud pay-as-you-go thingie with the name Qualify... :(
Recently, I used it to analyze the quality effect on different bitrate controls of two different distribution encodings:

https://i.imgur.com/Qcrpc1t.png
https://i.imgur.com/S7HGKp6.png

the first focuses on keeping the bitrate very still and not making it oscillate, while the second is able to preserve the quality on a more homogenous way across the encode (hence less "steps"). I don't deal much with distribution encodes, but rather content acquisition and I can say that those are generally very useful when it comes to mezzanine files 'cause if a supplier delivers a perfectly valid mezzanine file according to our specs (a rarity, but it happens), I don't have to re-encode it, so I just pass it on to the next step as it gets Loudness Corrected and after that it goes into AutoQC to detect freeze frames, black scenes etc. In this AutoQC step, we perform this kind of PVQ control and if the value is lower than the threshold, it gets flagged.
These days there aren't people eyeballing every piece of content coming through (unfortunately :(), so having a no-reference perceptual video quality control that can spot bad encodes automatically is really important before passing to the playout the actual TX Ready file.


It gets done in the Cloud on Linux.

Yep, same here.


Do you know some working Windows build?

I really hope someone makes a free open source cross platform implementation running either in Avisynth or FFMpeg, but I guess we're gonna have to wait. Unfortunately most PVQ implementations are proprietary and what's worse is that these days everything seems to be running on the cloud with a pay-as-you-go model instead of just buying the license and forgetting about it. I have stuff running on prem for which we bought the license 15+ years ago and never ever broke. Those were one-time transactions and those companies never saw a penny after that. Now that the cloud is "a thing" they see the milking opportunity of getting a constant revenue / influx of cash by charging the customers all the time.


This is also why - despite also being in the cloud - I try to run stuff on my own EC2 on AWS and use open source software, the likes of Avisynth, x26x, the BBC BMX mxf muxer etc. I really hope open source will kick everybody's butt in the long run, but after seeing greedy companies profit from this and plenty of people not donating/contributing to open source projects, it starts to feel like we're losing the battle sometimes... :(

[benwaggoner]

I really hope someone makes a free open source cross platform implementation running either in Avisynth or FFMpeg, but I guess we're gonna have to wait. Unfortunately most PVQ implementations are proprietary and what's worse is that these days everything seems to be running on the cloud with a pay-as-you-go model instead of just buying the license and forgetting about it. I have stuff running on prem for which we bought the license 15+ years ago and never ever broke. Those were one-time transactions and those companies never saw a penny after that. Now that the cloud is "a thing" they see the milking opportunity of getting a constant revenue / influx of cash by charging the customers all the time.

This is also why - despite also being in the cloud - I try to run stuff on my own EC2 on AWS and use open source software, the likes of Avisynth, x26x, the BBC BMX mxf muxer etc. I really hope open source will kick everybody's butt in the long run, but after seeing greedy companies profit from this and plenty of people not donating/contributing to open source projects, it starts to feel like we're losing the battle sometimes... :(
Yeah. Were I actually a developer (I stopped writing code for money in, sheesh, 1995?) I could port the p1204.3 to other platforms. It's open source on GitHub and everything: https://github.com/Telecommunication-Telemedia-Assessment/bitstream_mode3_p1204_3.

I failed to mention that .3 brought "Hybrid Mode 0" which combines both bitstream analysis and decoded pixel analysis for better subjective correlation (and much slower processing).

[Boulder]

Umm.. I don't see why that program wouldn't run on Windows. After all, it's a Python project and exports a JSON file.

[benwaggoner]

Umm.. I don't see why that program wouldn't run on Windows. After all, it's a Python project and exports a JSON file.
See, that's exactly the sort of thing I would realize if I was still a developer :sly:.

[benwaggoner]

x265 v3.6+2

Wow, after three years, a new x265 version is coming!

Some good stuff in there!

https://bitbucket.org/multicoreware/x265_git/commits/aa7f602f7592eddb9d87749be7466da005b556ee

Release Notes
*************

Version 3.6
===========

Release date - 4th April, 2024.

New feature
-----------
1. Segment based Ratecontrol (SBRC) feature
2. Motion-Compensated Spatio-Temporal Filtering
3. Scene-cut aware qp - BBAQ (Bidirectional Boundary Aware Quantization)
4. Histogram-Based Scene Change Detection
5. Film-Grain characteristics as a SEI message to support Film Grain Synthesis(FGS)
6. Add temporal layer implementation(Hierarchical B-frame implementation)

Enhancements to existing features
---------------------------------
1. Added Dolby Vision 8.4 Profile Support

API changes
-----------
1. Add Segment based Ratecontrol(SBRC) feature: "--[no-]sbrc".
2. Add command line parameter for mcstf feature: "--[no-]mctf".
3. Add command line parameters for the scene cut aware qp feature: "--scenecut-aware-qp" and "--masking-strength".
4. Add command line parameters for Histogram-Based Scene Change Detection: "--hist-scenecut".
5. Add film grain characteristics as a SEI message to the bitstream: "--film-grain <filename>"
6. cli: add new option --cra-nal (Force nal type to CRA to all frames expect for the first frame, works only with keyint 1)

Optimizations
---------------------
ARM64 NEON optimizations:- Several time-consuming C functions have been optimized for the targeted platform - aarch64. The overall performance increased by around 20%.
SVE/SVE2 optimizations

Bug fixes
---------
1. Linux bug to utilize all the cores
2. Crash with hist-scenecut build when source resolution is not multiple of minCuSize
3. 32bit and 64bit builds generation for ARM
4. bugs in zonefile feature (Reflect Zonefile Parameters inside Lookahead, extra IDR issue, Avg I Slice QP value issue etc..)
5. Add x86 ASM implementation for subsampling luma
6. Fix for abrladder segfault with load reuse level 1
7. Reorder miniGOP based on temporal layer hierarchy and add support for more B frame
8. Add MacOS aarch64 build support
9. Fix boundary condition issue for Gaussian filter

[tormento]

Wow, after three years, a new x265 version is coming!
Did you find some more extensive descriptions of the new features and where/when to use them?

[Boulder]

Those "new" ones are mostly quite old things already I'm afraid, and nothing really special for normal use cases. They didn't even bother fixing the histogram scene change bug I reported a long time ago.

[jpsdr]

What is the bug ?
Is it "just" a bug description, or is there already a fix but not commited in the release branch ?

[Boulder]

What is the bug ?
Is it "just" a bug description, or is there already a fix but not commited in the release branch ?
No fix whatsoever, not even a single comment in the issue I posted a long time ago.

The feature doesn't work for SDR encoding using the Main10 profile.
https://bitbucket.org/multicoreware/x265_git/issues/626/hist-scenecut-is-broken-for-main10-encodes

And this one is interesting, I'd expect them to be interested in clear quality issues.
https://bitbucket.org/multicoreware/x265_git/issues/561/rskip-2-coupled-with-limit-tu-0-and-ctu-64

[benwaggoner]

Those "new" ones are mostly quite old things already I'm afraid, and nothing really special for normal use cases. They didn't even bother fixing the histogram scene change bug I reported a long time ago.
Perhaps you should try resubmitting your bug before they actually release 3.6? Maybe a reminder could help. There's been quite a lot of turnover at MCW since 3.5.

As for as "new" things, yeah, for people who have been using post 3.5 builds we've had a lot for a while.

There is some general purpose stuff in there that should be broadly helpful:
6. Add temporal layer implementation(Hierarchical B-frame implementation)

Reorder miniGOP based on temporal layer hierarchy and add support for more B frame

And there are always welcome performance improvements, especially for ARM. Apple Silicon was over 2x faster than 3.5 last I benchmarked.

I've not extensively tested all the new stuff around scene cut detection and scene cut aware QP optimization, but if they work decently, those should help quality and compression efficiency a bit.

[benwaggoner]

Did you find some more extensive descriptions of the new features and where/when to use them?
This is it other than reading the comments in the individual commits.

Hopefully we'll get the new stuff added to x265.readthedocs.io before too long.

[Selur]

Hopefully we'll get the new stuff added to x265.readthedocs.io before too long.
100% agree, seems like they get sloppy, before they always added those changed when a new option appeared.

[Barough]

They haven't updated it since 2021.

Sent from my SM-S908B via Tapatalk

[LigH]

New upload: x265 3.6+1-dd1ef69b2 (https://www.mediafire.com/file/n0n1p02or3ncz2u/x265_3.6+1-dd1ef69b2.7z/file)

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

I guess the version numbering might depend on details like the selection of a branch.

[guest]

New upload: x265 3.6+1-dd1ef69b2 (https://www.mediafire.com/file/n0n1p02or3ncz2u/x265_3.6+1-dd1ef69b2.7z/file)

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

I guess the version numbering might depend on details like the selection of a branch.

Well, this is a little confusing, which is the newer ??

x265 v3.6+2
Built on April 04, 2024, GCC 13.2.0

[Barough]

Mine is built from the master branch.

Sent from my SM-S908B via Tapatalk

[FranceBB]

New upload: x265 3.6+1-dd1ef69b2 (https://www.mediafire.com/file/n0n1p02or3ncz2u/x265_3.6+1-dd1ef69b2.7z/file)

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


Thanks, still going strong on XP. :D

https://i.imgur.com/UyYOfgr.png

[vpupkind]

The SBRC feature is still borked, hope they'll fix it eventually.
It tends to increase both bitrate and quality and it is not clear whether there is any benefit from it vs plain giving more bits.

[vpupkind]

No fix whatsoever, not even a single comment in the issue I posted a long time ago.

And this one is interesting, I'd expect them to be interested in clear quality issues.
https://bitbucket.org/multicoreware/x265_git/issues/561/rskip-2-coupled-with-limit-tu-0-and-ctu-64
If I remember correctly, rskip 2 uses edges at the smallest CU's to see if they can be painlessly combined. It is meaningful when you do allow small CUs, so my bet is you won't get much out of the feature if you don't allow at least 16x16 CUs.

[Boulder]

If I remember correctly, rskip 2 uses edges at the smallest CU's to see if they can be painlessly combined. It is meaningful when you do allow small CUs, so my bet is you won't get much out of the feature if you don't allow at least 16x16 CUs.

I've always used at least depth 3 so the encoder has been allowed to use small CUs. Also the issue won't exist with CTU 32 with otherwise the exact same settings, or if you use limit-tu.

[LigH]

Well, this is a little confusing, which is the newer ??

As I wrote: I cannot guarantee for patch numbers being counted correctly, it depends on the selected branch and maybe even the method how the update of the local work copy happens. But the very last commits are usually just a minor detail, like adding a new tag to each branch, which changes nothing in the code.

See https://bitbucket.org/multicoreware/x265_git/commits/

[tormento]

In my local anime community there is a discussion about modern anime material, i.e. not pure line art like Dragon Ball used to be (I named a very well known one to give you an idea).

More and more complex animation techniques are nowadays used, from motion capture to advanced CGI and After Effects sfx. One of the most annoying (at least for me) is the use of fake lower resolution and fake film grain, such as in Mushoku tensei anime.

Ben and others encoding guru: can you please address me to a correct x265 usage to take care of the modern anime standards?

We need to maintain clear lines definition, good background clarity with no banding and, sometimes, deal with resize artifacts (halo and aliasing above all) where multiple resolution on the very same frames doesn’t allow us to have a proper downscale+upscale trick.

There is a lot of old beliefs about disabling SAO, using tune animation values or deblock and so on.

Could someone clarify how x265 has evolved towards those aspects and give me some hints for that material type?

[jpsdr]

Made a build of new version of my custom mod. Also add an AVX LLVM version, don't remember who asked for it...

[tormento]

Made a build of new version of my custom mod. Also add an AVX LLVM version, don't remember who asked for it...
Perhaps I am the only one to still use an AVX only CPU.

Thanks. ;)

P.S: Do you have any idea why the metrics (I look at VMAF, mostly) about your auto-aq and the patman one are so different? I have tried almost any value but the patman one almost always gives better results.

[Boulder]

Various AQ modes do not necessarily increase metric scores. I don't understand why people don't trust their eyes more.

What I sometimes run is SSIMU2 to check if the std dev or worst 5% value changes when adjusting parameters. I don't care much about the actual score.

[FranceBB]

More and more complex animation techniques are nowadays used, from motion capture to advanced CGI and After Effects sfx. One of the most annoying (at least for me) is the use of fake lower resolution and fake film grain

This has unfortunately been coming for a long time and I personally really hate it. I think most of it is driven by a cost factor as they can't afford to spend quite as much as they used to and they therefore try to rely on CGI. I still remember when I fansubbed and encoded Shingeki no Bahamut, the first series, in Italian. It was incredibly well drawn, very sharp edges too when I inverted the kernel of the upscaled BD (DeBilinearResizeMT) and encoded at 720p 4:4:4, but there was one thing that annoyed the hell out of me: the dragon. I mean, everything was manually drawn, all the characters and everything and then there was this huge blatantly computer graphics generated dragon (i.e the Bahamut) that quite astoninglishly was popping out and to hide its computer generated nature what have they done? Well, the oldest trick in the house: put tons of grain on it. I hate it. I understand when movie studios do this, for instance all the very recent Star Wars movie have a lot of grain to cover up the fact that some elements of the spaceships and other things are CGI and that's totally and absolutely fine 'cause you have real characters, real sets, enhanced virtualized sets (i.e they shoot with different cameras with the monitors in the background synced at a multiplier of the framerate of the cameras so that it generates a fake background on which it keeps the field of view, thus extending the set) and then fake computer generated items added in post. In other words, it makes total sense 'cause otherwise it would look plasticky. But for anime? Where nothing is real anyway? Nah. Either do it like Disney where everything is computer drawn with Maya created models which are rigged and then animated or just stick to the good old animation techniques with manually drawn characters, the way animes used to be made. Having something in between as they're doing now is utter nonsense.

[tormento]

Various AQ modes do not necessarily increase metric scores.
I don't have a calibrated monitor, I can't trust my eyes.

[Selur]

btw. how does one create film grain files for x265s '--film-grain' option for a given source?

[modus-ms325c]

This has unfortunately been coming for a long time and I personally really hate it. I think most of it is driven by a cost factor as they can't afford to spend quite as much as they used to and they therefore try to rely on CGI. I still remember when I fansubbed and encoded Shingeki no Bahamut, the first series, in Italian. It was incredibly well drawn, very sharp edges too when I inverted the kernel of the upscaled BD (DeBilinearResizeMT) and encoded at 720p 4:4:4, but there was one thing that annoyed the hell out of me: the dragon. I mean, everything was manually drawn, all the characters and everything and then there was this huge blatantly computer graphics generated dragon (i.e the Bahamut) that quite astoninglishly was popping out and to hide its computer generated nature what have they done? Well, the oldest trick in the house: put tons of grain on it. I hate it. I understand when movie studios do this, for instance all the very recent Star Wars movie have a lot of grain to cover up the fact that some elements of the spaceships and other things are CGI and that's totally and absolutely fine 'cause you have real characters, real sets, enhanced virtualized sets (i.e they shoot with different cameras with the monitors in the background synced at a multiplier of the framerate of the cameras so that it generates a fake background on which it keeps the field of view, thus extending the set) and then fake computer generated items added in post. In other words, it makes total sense 'cause otherwise it would look plasticky. But for anime? Where nothing is real anyway? Nah. Either do it like Disney where everything is computer drawn with Maya created models which are rigged and then animated or just stick to the good old animation techniques with manually drawn characters, the way animes used to be made. Having something in between as they're doing now is utter nonsense.
if well-made hand-drawn dragons are your thing, let me remind you that Dungeon Meshi (the anime adaptation) exists and the way dragons are drawn there (no grain filters used!) easily kicks the ever-living crap out of every anime that tries to do dragons at all
Mushoku Tensei S01E12 has hand-drawn dragon animation (zero grain too) but it looks very stilted and super-poor on top of as well, wouldn't wish that on my worst enemy

[benwaggoner]

I don't have a calibrated monitor, I can't trust my eyes.
As long as your monitor is reasonably close, you can still trust your eyes better than you can trust metrics.

[benwaggoner]

btw. how does one create film grain files for x265s '--film-grain' option for a given source?
Don't look at the man behind the curtain there!

This feature is in preemptive support for players that can decode HEVC with AVFG1 film grain synthesis metadata. It's essentially the FGS component of AV1 made general, with a fix so that grain size is based on grain size in the content, not display resolution.

I don't think that there is anything out yet that can play such a file. The HEVC will decode, but the FGS metadata will be ignored.

[quietvoid]

This feature is in preemptive support for players that can decode HEVC with AVFG1 film grain synthesis metadata. It's essentially the FGS component of AV1 made general, with a fix so that grain size is based on grain size in the content, not display resolution.

No it's not. It's for the H.265 Film grain characteristics SEI message. Or now it's better to reference it as H.274 FGS.

MCW used to have a libfgm repo on Bitbucket but they recently hid everything except x265.
I had forked it a while back: https://github.com/quietvoid/libfgm
It can be used to generate the expected binary file.

[Boulder]

No it's not. It's for the H.265 Film grain characteristics SEI message. Or now it's better to reference it as H.274 FGS.

MCW used to have a libfgm repo on Bitbucket but they recently hid everything except x265.
I had forked it a while back: https://github.com/quietvoid/libfgm
It can be used to generate the expected binary file.

Does the feature work with decoders out of the box, or is it some extension that is not mandatory for compliance?

[quietvoid]

Does the feature work with decoders out of the box, or is it some extension that is not mandatory for compliance?

It's not mandatory as it's SEI.
I don't know of hardware that supports it.

FFmpeg does support it in software, and libplacebo in shaders.