x265 HEVC Encoder

[Z2697]

Originally Posted by LigH

You say? ... My MinGW+GCC workflow calculates version 4.1+54-fa27709.

4.0+77 and 4.1+54 are both "wrong" (but technically correct )
4.0+77 is calculated before the merge of stable to the master, tag is not 4.1 because the tagged commit hasn't been merged to "current branch" where he builds the binary (which probably is master).
4.1+54 is calculated after the merge, tag is correct but the distance is greater than is should be, because release branch and master branch are diverged due to the previously mentioned mistake.

Originally Posted by Ritsuka

By the way, it seems they are committing new changes only to a "Release_4.1" branch, and forgetting about the master branch.

Originally Posted by Z2697

They probably opened release 4.1 branch too early and now they have to push to two branches simultaneously

[LigH]

Their recent code development is remarkable; but their repo mess seriously flaws it.

[MaheshPittala]

The x265 release 4.1 branch was started slightly earlier, requiring patches to be pushed to both the master and release_4.1 branches. As a result, the commit IDs differed between the two branches. When the release/stable branch was merged into master, the commits were treated as new. Using cherry-pick would have been the better solution.

[Z2697]

If you cherry-pick the tagged commit, the new commit hash will also be different, the versioniong cmake code (using git describe) probably won't pick the 4.1 tag.
I think that's just how it goes, no better way to do it.
Just... don't create release branch too early next time, do it right before the real release.

[Joey BoomBats]

Aom Film-Grain characteristics as a SEI message to support Film Grain Synthesis.

This looks like a very useful feature for bit hungry grainy videos.


Has anyone already tested the efficiency improvements of this feature and the visual implications?


Or does anyone know what the command line parameters are?


I see that Handbrake has now included x265 version 4.1 but unfortunately no specific changes have been made to the UI (yet).

[excellentswordfight]

Originally Posted by Joey BoomBats

This looks like a very useful feature for bit hungry grainy videos.


Has anyone already tested the efficiency improvements of this feature and the visual implications?


Or does anyone know what the command line parameters are?


I see that Handbrake has now included x265 version 4.1 but unfortunately no specific changes have been made to the UI (yet).

As far as I can see, this is not a complete built-in feature. The parameter added is "--aom-film-grain", so you need to denoise and create a grain parameter file externally, you then point that parameter to that file so it can be injected in to the SEI.

[tormento]

Has anyone tried --frame-dup with Patman or jpsdr builds?

It doesn't work on my AVX only CPU.

I get:

Video encoding returned exit code: -1073741819 (0xC0000005)

It's unclear what this exit code means, in case it's a Windows system error then it possibly means:

# for decimal -1073741819 / hex 0xc0000005
STATUS_ACCESS_VIOLATION ntstatus.h
# The instruction at 0x%p referenced memory at 0x%p. The
# memory could not be %s.
# as an HRESULT: Severity: FAILURE (1), FACILITY_NULL (0x0), Code 0x5
# for decimal 5 / hex 0x5
ERROR_ACCESS_DENIED winerror.h
# Access is denied.

[jpsdr]

Does the issue also happen with a not modified build ?

[Z2697]

Who uses frame-dup anyways?

It's better to give more details such as the whole command line and the "variant" of the build used to produce that error, and the input spec, etc.

[rwill]

The interesting thing is that if x265 can frame dupe, the way it is implemented anyway, one could also encode the picture at 1 bit or below per CU and not make the stream variable framerate, cause problems with certain muxers and rely on a correct decoder implementation of picture timing SEIs.

So a very useful and bit saving feature they have there, if only it worked.

[Z2697]

Originally Posted by rwill

The interesting thing is that if x265 can frame dupe, the way it is implemented anyway, one could also encode the picture at 1 bit or below per CU and not make the stream variable framerate, cause problems with certain muxers and rely on a correct decoder implementation of picture timing SEIs.

So a very useful and bit saving feature they have there, if only it worked.

Using container output (ffmpeg libx265, or supported in some mods) can have "slightly more usable" result, but yeah, currently the feature is working, I guess, but no software can recognize it. Even the "slightly more usable" container output is not utilizing timing SEIs.
The container output is using timestamps support of the container (VFR), while the picture timing SEIs don't contain actual timestamp, but only a flag indicates the corresponding frame should be doubled or tripled, if the decoder is able to support it the decoded video should still be CFR.

Even if it's working properly, both encode and decode side, the use case is still extremely limited.

[tormento]

Originally Posted by Z2697

Who uses frame-dup anyways?

Anime. Mostly old ones.

Originally Posted by jpsdr

Does the issue also happen with a not modified build ?

Tried this and it works but I don't know if it honors --frame-dup flag.

[Z2697]

Originally Posted by tormento

Anime. Mostly old ones.

You shouldn't.

To have a better understanding of what this feature means: this feature removes frames based on PSNR thresholding, and signal picture timing SEIs to keep the correct... picture timing... yeah... which no commonly available decoder can recognize.

It also requires VBV and HRD. Since no everyday decoder can recognize the timing SEIs the picture timing will be incorrect if any frame(s) are removed.
If you don't see any incorrect timing,
1) You didn't notice it.
2) You didn't enable the required VBV and HRD.
3) Your video didn't have any frames above the threshold.

Even if it works as it should, the PSNR thresholding is not ideal to begin with, and the bits saved with removing near identical frames are, well, did you know picture timing SEIs cost bits?

[jpsdr]

Does it work on CPU with more than AVX only ?

[Patman]

The reason for the error is the direct support of AVS and VPY scripts (MOD). However, if you use the pipe methods, the encode works. It seems that x265 requires the Y4M or YUV formatfor this case.

[jpsdr]

That's odd, i'm almost sure i used frame-dup on avs scripts with a moded version, during my first attempts of trying to do x265 encodes, before giving up using it because of all the issues i encountered, reasons Z2697 described.
My guess was it could be because of the multiview add, but it was wrong it seems.

[Leo 69]

Does anyone know how to use the new --aom-film-grain feature in the latest x265 encoders (I'm using 4.1+54)? I tried it and it fails each time with either .tbl or even .txt for film grain files. Here's the command:

--crf 18.5 --preset veryslow --output-depth 10 --aom-film-grain grain.tbl

And I always get this error:

x265 [error]: Failed to open Aom film grain characteristics binary file grain.tbl

For grain.txt file the error is the same. Does anyone know how to fix this? Or rather, did anyone manage to make this new feature work at all?

[Z2697]

Originally Posted by Leo 69

Does anyone know how to use the new --aom-film-grain feature in the latest x265 encoders (I'm using 4.1+54)? I tried it and it fails each time with either .tbl or even .txt for film grain files. Here's the command:

--crf 18.5 --preset veryslow --output-depth 10 --aom-film-grain grain.tbl

And I always get this error:

x265 [error]: Failed to open Aom film grain characteristics binary file grain.tbl

For grain.txt file the error is the same. Does anyone know how to fix this? Or rather, did anyone manage to make this new feature work at all?

I think it expects "raw" SEI payload, just guessing, haven't tried to understand it, and probably never will because I don't think it's (I'm referring to all the current implementations of FGS features) a useful feature, until it's much more improved.

[benwaggoner]

Originally Posted by rwill

The interesting thing is that if x265 can frame dupe, the way it is implemented anyway, one could also encode the picture at 1 bit or below per CU and not make the stream variable framerate, cause problems with certain muxers and rely on a correct decoder implementation of picture timing SEIs.

So a very useful and bit saving feature they have there, if only it worked.

Yeah, if only it worked! I've never been able to get a single frame to duplicate as documented, even with some pretty extreme settings. I've not tried in a 4.x build, but don't recall any patches for that part.

Maybe it only works in 2-pass or something?

[benwaggoner]

Originally Posted by Z2697

I think it expects "raw" SEI payload, just guessing, haven't tried to understand it, and probably never will because I don't think it's (I'm referring to all the current implementations of FGS features) a useful feature, until it's much more improved.

The tool is reasonably useful with the proper tools; there just aren't any good open source ones currently. The hardest part is the degrain-and-parameterize before encoding.

The rendering has some challenges with repeated patterns, due to the "drunken walk" nature of selecting a random 32x32 block out of a 64x64 block: pixels near the middle are much more heavily sampled than those near the edge. I so wish computer science degrees required some basic statistics! I work with a lot of engineers who are whizzes at linear algebra, but go blank when I ask "is that statistically significant?"