x265 HEVC Encoder

[LigH]

https://bitbucket.org/multicoreware/x265/commits/ = abandoned Mercurial repository. Obsolete.

https://bitbucket.org/multicoreware/x265_git/commits/ = current git repository. Use only now.

[nakTT]

https://bitbucket.org/multicoreware/x265/commits/ = abandoned Mercurial repository. Obsolete.

https://bitbucket.org/multicoreware/x265_git/commits/ = current git repository. Use only now.
Why did they abandoned it?

Btw, thanks for the info. No wonder there was no updates since 30th of May.

[filler56789]

Why did they abandoned it?

Because BitBucket decided to drop Mercurial -_-

[LigH]

It was announced half a year ago (https://forum.doom9.org/showthread.php?p=1898474#post1898474) so we all could adapt in time.

[K.i.N.G]

rskip off is probably worse. I think that --rskip 2 causes less recursion skips than --rskip 1 so in that sense, totally disabling skips would cause more issues.

You are probably using the default aq-mode (2), which is worse in my opinion. It sometimes caused the ugly floating macroblocks in flat areas, and I cannot stand those so I'd test also --aq-mode 1 to make sure it's not the issue there.

I also suggest removing --no-strong-intra-smoothing, there were some tests showing that the details are retained better that way.

Lower rskip values actually improved the results (at least with this issue/artifact).

Setting --aq-mode 1 also helps quite a bit!

So now I'm testing with aq-mode 1, rskip 2 with rskip-edge-threshold 0.03 and re-enabled strong-intra-smoothing.

So far its looking promessing... Thank you for these suggestions!
I have several problematic sources to re-encode and that's going to take a few weeks(!). So, it will take quite some time before I can tell for sure that it fixed the issue, but its looking good so far.

[nakTT]

Because BitBucket decided to drop Mercurial -_-

It was announced half a year ago (https://forum.doom9.org/showthread.php?p=1898474#post1898474) so we all could adapt in time.
I see. Thank for the clarification.

[fauxreaper]

https://bitbucket.org/multicoreware/x265/issues is gone and https://bitbucket.org/multicoreware/x265_git don't have an issue tracker.

[jlpsvk]

even latest x265 still encodes few frames less with hdr10+ metadata.. :(

[onekmilesbehind]

@jlpsvk have you tried using patman's 3.4+6 build from 5/30? HDR10+ was still working for me with that using the JSON sidecar file. At least if it works there, that gives you an idea of where things may have broken.

[Barough]

x265 v3.4+15-g45f1d01f8 (http://www.mediafire.com/file/y24vk81lrfdu8tm/x265-3.4+15-g45f1d01f8_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)


https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[BobbyBoberton]

Lower rskip values actually improved the results (at least with this issue/artifact).

Setting --aq-mode 1 also helps quite a bit!

So now I'm testing with aq-mode 1, rskip 2 with rskip-edge-threshold 0.03 and re-enabled strong-intra-smoothing.

So far its looking promessing... Thank you for these suggestions!
I have several problematic sources to re-encode and that's going to take a few weeks(!). So, it will take quite some time before I can tell for sure that it fixed the issue, but its looking good so far.

I find rskip 2 with hevc-aq mode enabled and rskip-edge-skip-threshold 5 to give very good results for me for both SDR and HDR content.

Just my experience

[LigH]

https://bitbucket.org/multicoreware/x265/issues is gone and https://bitbucket.org/multicoreware/x265_git don't have an issue tracker.

All that remains seems to be the mailing list: x265-devel@videolan.org (https://mailman.videolan.org/listinfo/x265-devel)

[Boulder]

All that remains seems to be the mailing list: x265-devel@videolan.org (https://mailman.videolan.org/listinfo/x265-devel)

Easy to get rid of the silly users reporting errors by not using an issue tracker :D

[jlpsvk]

@jlpsvk have you tried using patman's 3.4+6 build from 5/30? HDR10+ was still working for me with that using the JSON sidecar file. At least if it works there, that gives you an idea of where things may have broken.

will give it a try. :) but it's not a problem, that hdr10+ encoding is not working... it just does not throw out the same number of frames, as source.. :(

[LeXXuz]

Following a recent discussion I had with someone:

Is it still recommended to crop/resize videos to a mod-16 resolution?

I remember this was always recommended long time ago with MPEG2/MPEG4-ASP encoders.
I know 1080p isn't mod-16 either but after cropping I still either over- or undercrop to get a mod-16 resolution. Someone told me that wouldn't be necessary with x.265 and even x.264 anymore as long as it is mod-2 at least. :confused:

[LigH]

Vintage graphic cards used to suffer some performance loss when the output of the video player did not match some memory address boundaries. This era should be over.

Regarding encoding, it doesn't matter so much anymore. A modulo 2 may be necessary due to Chroma Subsampling 4:2:0. A modulo 4 is possibly a recommendable target regarding performance (related to partitions). But modern encoders and video formats allow encoding to dimensions not fitting macroblock (or coding unit) boundaries by encoding the video at the next larger boundary, repeating or mirroring some content, and carrying a crop rectangle telling the decoder to omit the rest. This may typically happen for 1080 encodes being stored with a height of 1088 and being cropped back to 1080 during playback, automatically.

PS: ITU standard = theory documents in upper case with dot (H.264), encoder implementation = practical software in lower case without dot (x264).

[LeXXuz]

Thanks for that explanation LigH :thanks:

So all left to worry about may be some of my Avisynth filters.

[Magik Mark]

Did you increase the maximum cache size? When I switched back to Avisynth+, I noticed that I had to increase it to over 10GB for UHD things, otherwise everything would just stall. I think I now have it at 16GB just in case. Also the new caching method in Avs+ 3.6.1 helped me.

Hi!

How do you increase the cache size?
Is there a table or formula in order to determine the optimum size? I do 1080p and 2160p

Thanks

[Boulder]

I use these lines to setup the cache:
SetMemoryMax(20480)
SetCacheMode(1)

To avoid having to put them in every script, I have them saved in the plugins folder as an .avsi file so it's autoloaded whenever Avs+ is used.
I don't think there is a special formula, the required amount depends on your script and the resolution. 20GB should be more than enough, it's just a safe maximum value which will never be exceeded in my use.

[Magik Mark]

I use these lines to setup the cache:
SetMemoryMax(20480)
SetCacheMode(1)

To avoid having to put them in every script, I have them saved in the plugins folder as an .avsi file so it's autoloaded whenever Avs+ is used.
I don't think there is a special formula, the required amount depends on your script and the resolution. 20GB should be more than enough, it's just a safe maximum value which will never be exceeded in my use.

I use StaxRIP. Do you happen to know how this is implemented?

[Boulder]

It's probably using the Avisynth+ default values. If the program uses a standard Avs+ installation, you can save the avsi file to its plugins folder and it's autoloaded from there. The path is usually C:\Program Files\Avisynth+\plugins64.

[Magik Mark]

It's probably using the Avisynth+ default values. If the program uses a standard Avs+ installation, you can save the avsi file to its plugins folder and it's autoloaded from there. The path is usually C:\Program Files\Avisynth+\plugins64.Alright then will give it a try.

What file name shall I use?

Sent from my SM-G988B using Tapatalk

[LigH]

Doesn't matter much. AviSynth+ will try to load all DLL and AVSI files from there. So, how about: defaults.avsi or similar...

[Magik Mark]

Thanks a lot!

Will experiment soon

Sent from my SM-G988B using Tapatalk

[Magik Mark]

Whats the difference between hevc-aq and aq-mode? Do I have to turn off one of them when encoding?

Which one is better to use?

[jlpsvk]

@jlpsvk have you tried using patman's 3.4+6 build from 5/30? HDR10+ was still working for me with that using the JSON sidecar file. At least if it works there, that gives you an idea of where things may have broken.

no go... the result still the same... :(

source has 171176 frames, encode has 171171 frames...

without HDR10+ metadata, encode has 171176 frames...

[Greenhorn]

Whats the difference between hevc-aq and aq-mode? Do I have to turn off one of them when encoding?

Which one is better to use?

hevc-aq, confusingly, is just another mode of AQ (adaptive quantization) that gets its own option instead of being added to the same list as the others. There's a even third option, aq-motion, which also gets its own option.

General consensus seems to be that hevc-aq and aq-motion are both sort of experimental features. I know there's at least one user here who really like hevc-aq, though. I'd just note that in CRF mode, hevc-aq will lower bitrates really drastically-- enough to affect visual quality in my experience. It's possible still more efficient than the other aq-modes if you lower your CRF to compensate, but just don't set blindly, is what I guess I'm saying.

[charliebaby]

X265 3.4+15-g45f1
VS 2019 GCC 10.2
http://www.mediafire.com/file/ho3b7exg7w9n6qd/x265-3.4+15.rar/file

[benwaggoner]

hevc-aq, confusingly, is just another mode of AQ (adaptive quantization) that gets its own option instead of being added to the same list as the others. There's a even third option, aq-motion, which also gets its own option.
AQ needs some refactoring, for sure!
aq-mode 3=2 with low luma bias. hevc-aq is really aq-mode 5, and should map to that.

I'd suggest some ala:

--aq-method for 0, 1, 2, 4, and hevc-aq mapping to 0-4.
A seperate --aq-dark so we could apply the low luma offset to any method.
And ideally an --aq-dark-strength to control that offset.


General consensus seems to be that hevc-aq and aq-motion are both sort of experimental features.
Aq-motion is a lot more experimental than hevc-aq, and I've not heard anyone suggest it'd be appropriate to have on by default. HEVC-AQ is a lot more mature at this point, althogh newer.

The concept of having motion impact AQ is quite straightforward and of obvious benefit, but getting an actual psycho-visually tuned algorithm implemented is...complex. Especially since other things in x265 are also responding to motion and need to be considered.

I know there's at least one user here who really like hevc-aq, though. I'd just note that in CRF mode, hevc-aq will lower bitrates really drastically-- enough to affect visual quality in my experience. It's possible still more efficient than the other aq-modes if you lower your CRF to compensate, but just don't set blindly, is what I guess I'm saying.
Given aq's influence on ABR, testing aq parameters at a given CRF isn't efficient. I strongly recommend testing with 2-pass VBR so we can really see bang for the bit. Once the most efficient aq parameters are figured out for the given scenario, then the right CRF can be determined.

[LeXXuz]

I could use some advice to reduce banding on my x265 encodes.

I've noticed on many newer movies (with little to no noise) banding appears on my x265 encodes in difference to the source H.264 video from Blu-ray.

I expected encodes with --crf 16 --aq-mode 3 --no-sao --output-depth 10 on the "slower" preset to be more transparent regarding the source video.

However, banding occurs especially in dark backgrounds like underwater scenes, night skies and such.

My intend is to do this without any additional AVS filters to leave the source video as 'untouched' as possible.

From your experience are there any tweaks I can use to force x265 to (obviously) spend more bits into these scenes?

[microchip8]

I could use some advice to reduce banding on my x265 encodes.

I've noticed on many newer movies (with little to no noise) banding appears on my x265 encodes in difference to the source H.264 video from Blu-ray.

I expected encodes with --crf 16 --aq-mode 3 --no-sao --output-depth 10 on the "slower" preset to be more transparent regarding the source video.

However, banding occurs especially in dark backgrounds like underwater scenes, night skies and such.

My intend is to do this without any additional AVS filters to leave the source video as 'untouched' as possible.

From your experience are there any tweaks I can use to force x265 to (obviously) spend more bits into these scenes?

Try increasing psy-rd and psy-rdoq. Something like 3 for psy-rd and 15 for psy-rdoq. Also, aq-mode 1 seems better than the other aq modes

[excellentswordfight]

I could use some advice to reduce banding on my x265 encodes.

I've noticed on many newer movies (with little to no noise) banding appears on my x265 encodes in difference to the source H.264 video from Blu-ray.

I expected encodes with --crf 16 --aq-mode 3 --no-sao --output-depth 10 on the "slower" preset to be more transparent regarding the source video.

However, banding occurs especially in dark backgrounds like underwater scenes, night skies and such.

My intend is to do this without any additional AVS filters to leave the source video as 'untouched' as possible.

From your experience are there any tweaks I can use to force x265 to (obviously) spend more bits into these scenes?
I would recommend the same thing as froggy1, try aq-mode 1.

Generally I use aq-mode 1, 2 & 3 for low, medium & high compression targets. Aq-mode 1 seems to work best for visually lossless goals while 3 is better for highly compressed encodes.

[Barough]

x265 v3.4+18-g8718641e5 (http://www.mediafire.com/file/qn5am9a43uyiw7r/x265-3.4+18-g8718641e5_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[LeXXuz]

I would recommend the same thing as froggy1, try aq-mode 1.


That confuses me a little. Isn't aq-mode 3 supposed to work better on dark scenes? :confused:

[microchip8]

That confuses me a little. Isn't aq-mode 3 supposed to work better on dark scenes? :confused:

In theory. In practice, not really. It sucks up bitrate and can make the image worse

[LeXXuz]

Try increasing psy-rd and psy-rdoq. Something like 3 for psy-rd and 15 for psy-rdoq. Also, aq-mode 1 seems better than the other aq modes

I would recommend the same thing as froggy1, try aq-mode 1.

Generally I use aq-mode 1, 2 & 3 for low, medium & high compression targets. Aq-mode 1 seems to work best for visually lossless goals while 3 is better for highly compressed encodes.


Thank you guys. I will try out those settings. :)

[LigH]

NASM 2.15.03 (MSYS2/MinGW) throws a huge amount of macro warnings.

Just a list of warnings for one file (there were so many, it left my console window's line buffer):

[ 18%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/loopfilter.asm.obj
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1243: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1243: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1243: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1364: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1364: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1364: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1494: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1494: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1494: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1614: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1614: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1614: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1869: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1869: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1869: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1955: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1955: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1955: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here

[LigH]

Will this be another case of "warnings to be silenced by legacy parameter", or is it a hint to a more serious issue?

[MasterNobody]

Will this be another case of "warnings to be silenced by legacy parameter", or is it a hint to a more serious issue?

It is hint that they should update x264asm (x86inc.asm):
x86inc: Fix warnings when using nasm 2.15 (https://code.videolan.org/videolan/x264/-/commit/22fcbe12046b7d6ed7af5d7a47258f1f2ebd56c1)
Fix compilation with nasm 2.15 (https://code.videolan.org/videolan/x264/-/commit/d78c1e83a1a9d34857eb53294282b3fbca3aba18)

[LigH]

:thanks:

No reply to the mailing list, though...

[Rousseau]

Is it possible to do a partial crf encode using an analysis-save/load file ? Is there a way to specify the proper start frame in the analysis.dat file? The seek function doesn't appear to work.

[charliebaby]

x265-3.4+20-g06c5

VS 2019 GCC 10.2 = http://www.mediafire.com/file/dbdh0lvpxghd63w/x265-3.4+20-g06c5.rar/file

[benwaggoner]

Is it possible to do a partial crf encode using an analysis-save/load file ? Is there a way to specify the proper start frame in the analysis.dat file? The seek function doesn't appear to work.
I'm not sure what a "partial CRF" file would be. But you can run a CRF encode using analysis-load.

[Rousseau]

I'm not sure what a "partial CRF" file would be. But you can run a CRF encode using analysis-load.

What I mean is, if I did a partial encode but was interrupted by a crash, could I resume the encode where I left off in a new file (to merge later) so I wouldn't have to re-encode the whole thing. I've done this with crf encodes before but with the analysis file it's like a 2-pass encode. I tried ignoring the analysis file but then my bitrate seems to be cut in half. :confused: I thought --seek might work but it seems to have no effect.

[benwaggoner]

What I mean is, if I did a partial encode but was interrupted by a crash, could I resume the encode where I left off in a new file (to merge later) so I wouldn't have to re-encode the whole thing. I've done this with crf encodes before but with the analysis file it's like a 2-pass encode. I tried ignoring the analysis file but then my bitrate seems to be cut in half. :confused: I thought --seek might work but it seems to have no effect.
I think it should work in theory, but there could be a bug. But --seek and --frames do work; that's how doing chunked encode works. Best to use --chunk-start as well to get VBV tracking more accurately at the start.

[Barough]

x265 v3.4+22-ga988fbbac (http://www.mediafire.com/file/u515zgaovxwo5s9/x265-3.4+22-ga988fbbac_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[ghostshadow]

Hello, i have HEVC encoder version 3.4+10-g7a640a2c1
build info [Windows][MSVC 1926][64 bit] 10bit,
but I wanted to install one of the latest version (34+12, 34+20)and with these versions I have this error "x265-10b: unrecognized option `--max-qp-delta' "
Here are the parameters used : --ref 4 --scenecut-aware-qp --scenecut-window 500 --max-qp-delta 10 --no-cu-lossless

I am in 2 pass encoding.
Please Help me

[Greenhorn]

Hello, i have HEVC encoder version 3.4+10-g7a640a2c1
build info [Windows][MSVC 1926][64 bit] 10bit,
but I wanted to install one of the latest version (34+12, 34+20)and with these versions I have this error "x265-10b: unrecognized option `--max-qp-delta' "
Here are the parameters used : --ref 4 --scenecut-aware-qp --scenecut-window 500 --max-qp-delta 10 --no-cu-lossless

I am in 2 pass encoding.
Please Help me

It appears to have been split into two options: --qp-delta-ref and --qp-delta-nonref. The first is for REFERENCED p/b frames and defaults to 5.0, while the second is for NON-REFERENCED p/b frames and defaults to 6.5.

This is present in the CLI encoder's documentation, but not on x265.readthedocs.io; 3.4+20 (and all versions after 3.4+4) are development builds, rather than release. (Even if the difference between the two is usually kinda small.)

[ghostshadow]

It appears to have been split into two options: --qp-delta-ref and --qp-delta-nonref. The first is for REFERENCED p/b frames and defaults to 5.0, while the second is for NON-REFERENCED p/b frames and defaults to 6.5.

This is present in the CLI encoder's documentation, but not on x265.readthedocs.io; 3.4+20 (and all versions after 3.4+4) are development builds, rather than release. (Even if the difference between the two is usually kinda small.)

Thank you very much

[jlpsvk]

ok.. seriously there's a problem with x265 and HDR10+ encoding...

tried another HDR10+ encode... source has 195593 frames, encode has 195585. Without HDR10+ (only HDR10) encode has 195593. It's clearly problem of x265, as with nVidia and Intel's encoders, using the same HDR10+ metadata file, output has right number of frames.