x265 HEVC Encoder

[ksm]

We have released a new version (v4.0) of x265. You can download the x265 tarball from our downloads page ( https://bitbucket.org/multicoreware/x265_git/downloads/ ).

[LigH]

:thanks:

People will surely start building binaries right away...
Especially the media-autobuild suite makes it pretty easy for the Windows platform.

[madmax3308]

Thanks!

[LigH]

New upload: x265 4.0+4-29d59cb (https://www.mediafire.com/file/klopqt7ecgsgsbw/x265_4.0+4-29d59cb.7z/file)

[Windows][GCC 14.2.0][32b/32b~XP/64b/64b+MV] 8bit+10bit+12bit

Please note: From version 4.0 on I will build all variants without MultiView support so that they may still work without explicit --input parameter, except for a 64 bit build which has it explicitly enabled.

[Guest]

New upload: x265 4.0+4-29d59cb (https://www.mediafire.com/file/x7djosnm3qlf29t/x265_4.0+4-29d59cb.7z/file)

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

I just wanted to let you know that I've figured out a workaround to get these new builds working in RipBot264.

God only knows how long it'll take the dev to implement the change :(

[Z2697]

I just wanted to let you know that I've figured out a workaround to get these new builds working in RipBot264.

God only knows how long it'll take the dev to implement the change :)

What is problem, and the change?

[LigH]

Probably like in this post (https://forum.doom9.org/showthread.php?p=2006886#post2006886).

[Guest]

Probably like in this post (https://forum.doom9.org/showthread.php?p=2006886#post2006886).

Almost...Wishbringer was VERY close, but didn't he say that it still didn't work ??

[LigH]

It is a manual edit, so it works easily for one job but would be very annoying for a distributed batch.

Why are you hiding your solution from the rest of the world?

[LigH]

I changed my x265 v4.0+4 archive (https://forum.doom9.org/showthread.php?p=2006909#post2006909).

Please note: From version 4.0 on I will build all variants without MultiView support so that they may still work without explicit --input parameter, except for a 64 bit build which has it explicitly enabled.

[Wishbringer]

Problem solved, Atak_Snajpera updated RB and also x265 in his updates. But thanks anyway for your workaround @LigH.

[LigH]

There may be others with similar issues...

[LigH]

x265cli.cpp, lines 808 ff.:
#if !ENABLE_MULTIVIEW
if (optind < argc && !inputfn[0])
inputfn[0] = argv[optind++];
#endif
I assumed that if MV-HEVC is disabled in compilation options, interpreting the last parameter as input filename (if there was no --input parameter yet) is enabled, as it used to work before introducing MV-HEVC.

But it doesn't seem to work in my recently compiled v4.0+4.

[Z2697]

So do I.

I've made an encode with a version build with llvm.
Then I've made an encode with a version build with gcc.
File were of different sizes.
But... to be sure, i redo the exact same encode with the gcc build version. Third file, third different size...
So, even with the exact same exe, running twice the exact same encode didn't even produce bit identical files, as they even are not of the same size. Of course, difference is small (around 2kB~4kB for a 20MB file).

For speed, thanks for the offer, but i will not be doing more testing.

I tested your parameters, In this particular case it's vbv that caused this phenomenon. But I didn't go further (since the vbv option is the first one in your command line after those basic stuff)

[LigH]

Wondering if the cause might be wrong parameters in a cmake cache, I rebuilt my binaries. But they turned out to be the same, that was not the reason.

Now I reported it to x265_git issue 954 (https://bitbucket.org/multicoreware/x265_git/issues/954/x265cli-simple-input-parameter-does-not).

If any competent programmer here could have a look, that would be very appreciated.

[ksm]

Thank you for bringing up these issues to our attention. We are working on fixing all of these issues and once done we will release a minor version. Thanks

[LigH]

While you are at it:

Help messages are not formatted well in new features, sometimes missing manual line breaks which happen randomly in long lines, I remember I spotted typos and strange grammar...

[tormento]

Is possible to write / overwrite encoding library or other fields in a hevc file?

I mean, after it's been created.

[LigH]

Regarding the specifications (in theory): Encoder library and options are metadata, pure text. They can be omitted by an encoder or removed later. Header fields describing the content (e.g. colorimetry flags, aspect ratio) can be edited with special tools (which may take care of checksums, if any exist). They just need to exist and be known ... I do remember that a patcher for raw H.264 (AVC) video streams exists. And I read that ffmpeg can be used to alter some metadata in video streams.

In other words: It is absolutely possible that software can exist which is able to patch H.265 metadata. It may even exist already. I just can't tell you a specific tool, besides ffmpeg.

[tormento]

Regarding the specifications
Recent versions of ffmpeg can write/delete AVC metadata and delete HEVC metadata only.

Any help is welcome.

[LigH]

In case of despair, use a "hex editor" to overwrite the human-readable text meta info about the encoder and its options.

[Z2697]

Recent versions of ffmpeg can write/delete AVC metadata and delete HEVC metadata only.

Any help is welcome.

What exactly are you trying to modify?

[tormento]

What exactly are you trying to modify?
I need to put some "watermark" directly in hevc file metadata, so that muxing won't change or tamper it.

[LigH]

Well, you can certainly use a hex editor to patch that text byte by byte. It is for (tech-literate) humans to casually read, not for software to rely on.

[Z2697]

HEX editor is definitely gonna work but same for anyone that's tech-literate enough if they want to remove it.

If you don't want to do that hex editing you can mess with the version.cmake or param.cpp to change how the version string is generated or how the SEI is "printed".

Or.......... you can use the x265 parameter --nalu-file to insert a custom SEI message but I never used it, I can't guarantee that it'll work, plus good luck for any of your viewers can find this easter egg (if it's only important to yourself then this is no problem)
Alright, I tested it and it works, it looks like you can insert SEI message at any frame from the help msg but I can only get it working at the frame 0.
An example of nalu-file:
0 PREFIX 39/5 VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4=

[tormento]

Patman released ICC builds on his repo (https://github.com/Patman86/x265-Mod-by-Patman/releases)!

:thanks:

[LigH]

@Z2697: Is that Base64 encoding or similar? ... Ah, yes, obviously. Woof!

[rwill]

Or.......... you can use the x265 parameter --nalu-file to insert a custom SEI message but I never used it, I can't guarantee that it'll work, plus good luck for any of your viewers can find this easter egg (if it's only important to yourself then this is no problem)
Alright, I tested it and it works, it looks like you can insert SEI message at any frame from the help msg but I can only get it working at the frame 0.
An example of nalu-file:

Your example seems to be missing the 16 bytes uuid_iso_iec_11578 at the start of the unregistered SEI payload. I suggest creating a hopefully unique 16 byte UUID using some generator and use that for each of your so inserted SEIs.

[Z2697]

Your example seems to be missing the 16 bytes uuid_iso_iec_11578 at the start of the unregistered SEI payload. I suggest creating a hopefully unique 16 byte UUID using some generator and use that for each of your so inserted SEIs.

Judging by the resulting bitstream, x265 handles that.

And LigH, yes it's base64.

[birdie]

Thank you for bringing up these issues to our attention. We are working on fixing all of these issues and once done we will release a minor version. Thanks

Any news on x266?

[LigH]

Not in this thread. See here (https://forum.doom9.org/showthread.php?t=181816) instead.

[birdie]

Not in this thread. See here (https://forum.doom9.org/showthread.php?t=181816) instead.

For visibility and transparency I'm asking a new MulticoreWare account that has no messages in other threads.

I hope you can forgive me.

[LigH]

Of course, understood :)

I was just mentioning the existence of a specific thread.

[tormento]

Seems that there is a strange issue (https://github.com/Patman86/x265-Mod-by-Patman/issues/21) with x265.

I'd like to hear your thoughts too.

[benwaggoner]

Any news on x266?
I didn't hear anything about x266 specifically at IBC. There were a number of companies with live VVC encoders they were demonstrating, up to 8Kp60.

[LigH]

A few more patches are being proposed. Next to several crash and bug fixes (e.g. the left-over filename as input if multiview is disabled), also this:
Add Aom film grain characteristics as SEI message to the bitstream

Available: probably soon™

[Boulder]

A few more patches are being proposed. Next to several crash and bug fixes (e.g. the left-over filename as input if multiview is disabled), also this:


Available: probably soon™

I wonder if the FGS table which aomenc or svt-av1 use can be applied. And if any hardware decoder can use it, it would be a killer functionality if the common Amlogic chips used in Android boxes supported this.

[Jamaika]

The warmings for C++23 are interesting.
sao.cpp: In member function 'void x265::SAO::rdoSaoUnitCu(x265::SAOParam*, int, int, int)':
sao.cpp:1242:66: warning: arithmetic between different enumeration types 'x265::SAO::<unnamed enum>' and 'x265::SAOType' is deprecated [-Wdeprecated-enum-enum-conversion]
1242 | X265_CHECK(sizeof(PerPlane) == (sizeof(int32_t) * (NUM_PLANE * MAX_NUM_SAO_TYPE * MAX_NUM_SAO_CLASS)), "Found Padding space in struct PerPlane");
| ~~~~~~~~~~^~~~~~~~~~~~~~~~~~
common.h:113:37: note: in definition of macro 'X265_CHECK'
113 | #define X265_CHECK(expr, ...) if (!(expr)) { \
| ^~~~
frameencoder.cpp: In member function 'virtual void x265_10bit::FrameEncoder::processRowEncoder(int, x265_10bit::ThreadLocalData&, int)':
frameencoder.cpp:1748:16: warning: '++' expression of 'volatile'-qualified type is deprecated [-Wvolatile]
1748 | curRow.completed++;
| ~~~~~~~^~~~~~~~~

[LigH]

I wonder if the FGS table which aomenc or svt-av1 use can be applied.

Just a very brief look: it tries to open a "film grain characteristics binary file".

[Boulder]

Just a very brief look: it tries to open a "film grain characteristics binary file".

I'm hoping that their "binary file" just means an input file. The film grain table is pure ASCII, and peeking at the proposed patch, looks like the structure could be the same as there.

[Z2697]

No, it's not the pure ASCII film grain table. (I applied the patch and tried it)

Although I dislike the film grain synthesis feature I'm still curious to try but I just have no idea how to get a film grain charastistic data that x265 will accept, that's sad, a little bit.
Heck, the AV1 league just made it basically one-click and have fun.

[Z2697]

I just saw this issue
https://bitbucket.org/multicoreware/x265_git/issues/612/faulty-commit-value-on-compiled-binaries

I don't really remember my bb account and I don't want to create a new one. Since one of the participants, Barough, is here I think I'll post here (is MrB also Barough or just coincidence)
The x265 version is not wrong, it's just that it uses the latest commit hash, and if you use media-autobuild_suite to build x265, it adds one patch here (https://github.com/m-ab-s/media-autobuild_suite/blob/00ef1d393bf2e3f74c9e6470f4a89bc52db68470/build/media-suite_compile.sh#L1717) and that makes the latest commit hash to change.
If you don't want it to interfere x265 versioning you can actually skip that patch, but you will need to rebuild x265 when gcc updates according to the commit message in that patch.

[LigH]

I asked about the same issue in the x265-devel mailing list. Then I learned it is not a good place to ask anymore. (At least when you are not one of the developers yourself and don't want to propose patches?)

Your explanation about additional patches adding to the checksum sounds credible to me.

[tormento]

I have a question about qpfile. I started using them since DGIndexNV began to output it in the format:

frame I -1

What the last -1 stands for? I have looked at the x265 reference but that value remains unknown to me.

[LigH]

x265 documentation: qpfile (https://x265.readthedocs.io/en/master/cli.html#cmdoption-qpfile)

Not explicitly mentioned, but this:
Specifying QP (integer) is optional, and if specified they are clamped within the encoder to qpmin/qpmax.
IIRC, an omitted or invalid value means that you specify only the GOP frame type, but let the encoder decide the quantization.

[tormento]

Not explicitly mentioned, but this
So, -1 has to be considered invalid and I can simply omit it or it has some effect on actual QP?

Unfortunately, I can’t understand this topic in a clear way.

[LigH]

"Specifying QP (integer) is optional" means you can omit that parameter, only specify frame number and frame type. And that should be more obvious than using a -1 value...

[Barough]

I just saw this issue
https://bitbucket.org/multicoreware/x265_git/issues/612/faulty-commit-value-on-compiled-binaries

I don't really remember my bb account and I don't want to create a new one. Since one of the participants, Barough, is here I think I'll post here (is MrB also Barough or just coincidence)
The x265 version is not wrong, it's just that it uses the latest commit hash, and if you use media-autobuild_suite to build x265, it adds one patch here (https://github.com/m-ab-s/media-autobuild_suite/blob/00ef1d393bf2e3f74c9e6470f4a89bc52db68470/build/media-suite_compile.sh#L1717) and that makes the latest commit hash to change.
If you don't want it to interfere you can actually skip that patch, but you will need to rebuild x265 when gcc updates according to the commit message in that patch.

Nah, im not MrB.

So we have to get that m-ab-s patch removed and the m-ab-s compiled x265 binaries will be up to par with the default x265 versioning that MCW shows or have i missunderstood it.

[LigH]

If it still compiles without that 0001-cmake-split-absolute-library-paths-to-L-and-l.patch, then probably yes.

I'll test if compiling fails without...

[Z2697]

Nah, im not MrB.

So we have to get that m-ab-s patch removed and the m-ab-s compiled x265 binaries will be up to par with the default x265 versioning that MCW shows or have i missunderstood it.

Remove / comment out that line in the compile script will be OK