x265 HEVC Encoder

[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]

Originally Posted by jpsdr

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.

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]

Originally Posted by LigH

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]

Originally Posted by tormento

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]

Originally Posted by Z2697

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!

[LigH]

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

[rwill]

Originally Posted by Z2697

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]

Originally Posted by rwill

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]

Originally Posted by 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

Any news on x266?

[LigH]

Not in this thread. See here instead.

[birdie]

Originally Posted by LigH

Not in this thread. See here 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.