x265 HEVC Encoder

[microchip8]

@Archimondro

no help on pirated content. Read the rules!

[Archimondro]

@froggy1 Not illegal where i live, but ok.

[benwaggoner]

If I have an m2ts file with 2 layers and HDR10 PLUS Dolby Vision but the TV only recognizes HDR10, is there a way to force Dolby Vision somehow?
Wow, a lot of Dolby Vision questions!

First off, there aren't any extant Dolby Vision titles that use HDR10 as a base layer. The two modes you'll see in streaming or discs today are:

SDR base layer + enhancement layer + dynamic metadata
Non-backwards compatible base layer + dynamic metadata

The enhancement layer is quarter res of the base layer, so a 2160p title would have a 1080p base layer.

The non-backwards compatible base layer dynamically shifts the code values to make maximal use of the 10-bit space, and is in ICtCp. Playing it back as itself would be very trippy, but sub VideoCD quality.

In both cases, the layers and metadata are combined to render a 12-bit ICtCp frame. From there it gets tone mapped to the actual display's characteristics using yet more metadata. Lots of science and tricks go into the playback process, including dynamic backlight control for non-OLED displays.

As far as reusing or reencoding these streams, that would require a LOT of tooling. There's a lot of metadata (both for rendering out the source to the intermediate space, and then rendering from that to the current display) that needs to get transferred correctly for DoVi playback. And you'd need to be able to feed that content back into a DoVi player.

Reencoding is going to be even more fraught. By default DoVi uses ICtCp instead of Y'CbCr color space; that's what the non-backwards compatible stream is in. And for dual layer, the enhancement layer is its own thing that doesn't look like natural images at all. So reencoding using traditional psychovisual tuning may result in...issues.

Dolby Vision has a whole lot of other modes, some implemented in shipping devices, some not. But AFAIK everything available to consumers today uses one of the above.

If 12-bit decoders become broadly available in CE devices someday (NVidia starting with Pascal is the only thing I know of doing it today), then DoVi could just use 12-bit ICtCp + playback metadata, which would make for simpler implementations. The content would already be in the intermediate format, leaving the (highly complex) tone mapping to display stage.

I don't know if anything particularly interesting or useful could be done with DoVi today without licensing the Dolby Vision SDK.

[benwaggoner]

Yeah well but it doesnt. MKVToolNix shows 2 streams one with 4k and one with 1080p. Ofc thats not really accurate cause MKVToolNix doesnt support Dolby Vision but both standards are there. The TV doesnt play the m2ts.

So I have to convert the m2ts to mkv which THEN only seems to support HDR10.

As an example this one: http://4kmedia.org/lg-dolby-vision-uhd-4k-demo/

Once I've used MKVToolNix, the Dolby Vision is gone

Is there at least a way to see if I am using Dolby Vision or not? The TS and the MKV files look pretty much the same in MediaInfo for example. But one has DV the other doesnt....
Per my previous post, it is extremely unlikely that any existing open-source tools would be able to preserve all the required DoVi metadata. I haven't heard about a MKV mapping for DoVi. A whole lot of spec would need to be available for both the muxing and the playback for this work, even running on an app where there is an OS-level DoVi decoder and display tone mapper.

[SeeMoreDigital]

Wow, a lot of Dolby Vision questions!
Indeed... Perhaps they would be better merged into one topic ;)

[d3rd3vil]

Thank you very much benwaggoner for the detailed information. Its interesting and YET disappointing its thats difficult meaning no Dolby Vision for us noses soon :( Cant be helped aparently.

At least Dolby itself could release a DV software that would be nice :)

[benwaggoner]

Thank you very much benwaggoner for the detailed information. Its interesting and YET disappointing its thats difficult meaning no Dolby Vision for us noses soon :( Cant be helped aparently.

At least Dolby itself could release a DV software that would be nice :)
Dolby Vision is a quite complex set of technologies. In essence,


Starts with 12-bit Y'CtCp PQ 2020 HDR content, typically 4000 nits peak and using the P3 subset of color volume.
Plus creative intent metadata where a colorist indicates what parts of what frames are important to preserve on displays that are less than 4000 nit P3 (like blue sky or bright sky)
Encodes it into one or two lower precision layers with metadata so it can be decoded with existing HW decoders
On a device, decodes and then reverses the 1/2 layer coding to the native 12-bit Y'CtCp color space
Then uses information about the particulars of the display it is being played back, combined with the creative intent metadata, to determine the optional way to map the 4000 nit P3 into whatever the display is capable of, so the sky comes out in the right mix of bright and blue
And some even more complex pixel mapping and metadata stuff to make it work over HDMI


This isn't a simple incremental technology, but a complex set of interlocking technologies that need to get implemented together to be useful.

If one already has DoVi elementary streams and wants to play them back on a device that's enabled with DoVi playback, that seems potentially feasible as a pure muxing project. But even then there is a whole lot of metadata that needs to be handled correctly. I don't know of any open-source muxers are capable of this. Not that I've tried personally.

[LigH]

Trying to switch from MSYS (XhmikosR) to MSYS2 (MABS); it's not so simple, using separate runs in MinGW32 and MinGW64 as workaround for now to avoid patching the cross compilation toolchain file.

x265 2.5+27-0e168bdeb48b (https://www.mediafire.com/file/kt6nbpcyathtypy/x265_2.5%2B27-0e168bdeb48b.7z) (GCC 7.2.0)

[Barough]

x265 v2.5+31-df2de6ea407d (http://www38.zippyshare.com/v/3TcWZa0E/file.html) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.5+31-df2de6ea407d
x265 [info]: build info [Windows][GCC 7.2.0][32/64 bit] 8bit+10bit+12bit


https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

x265 2.5+31-df2de6ea407d (http://www.mediafire.com/file/312jxn7145vbbco/x265_2.5%2B31-df2de6ea407d.7z)

Support for more monochrome video source formats; plus a few fixed nits.

[LigH]

Support for Visual Studio 2017 will probably be available soon.

No reply to my request for MSYS2 yet, though.

[Barough]

Visual Studio 2017 build folders have been added now
https://bitbucket.org/multicoreware/x265/commits/0bc372b7ca7847f8e85b9f407dfdd336073dbb8d?at=default

[Midzuki]

No reply to my request for MSYS2 yet, though.

Regarding https://www.mail-archive.com/x265-devel@videolan.org/msg10362.html

my piece of advice is,
if you want to use MSYS2, then use the real, the standalone MSYS2 itself, not the Media Autobuild Suite --- at least if your only goal is keep compiling x265.exe.

FWIW, the GCC packages provided by Nev and redistributed by XhmikosR can be used without modifications in the mingw32 directory of an MSYS2 environment, so that updating the "all-in-one" x265.exe building script (i.e., makemulti.sh) would be unnecessary. But as I said, I'm talking about a "normal" MSYS2 environment, because I really don't know what the MABS thing actually does. Also, this question: if you manage to make MSYS2 do exactly what MSYS1 does, regarding the "fully-automated" compilation of x265.exe, ¿then what is the point of the upgrade? :confused:

[LigH]

I see it as an advantage that MABS uses pacman as package manager to keep its MSYS2 environment up to date automatically each time you run it. Apart from that, the media tools compilation script is based on a pretty generic MSYS2 environment and installs additional packages for those tools which need extras. That means, chances are good that all the tools required to build x265 are more recent than waiting for any other person uploading a package and manually exchanging files (in fact, only overwriting or adding, but not removing outdated ones, which a package manager will do instead).

As I already wrote, I discovered that I am not able to run the MSYS script provided by Multicoreware in the MSYS2 environment which gets installed by MABS from official package sources. The differences are in the presence of cross compilation twins of GCC applications, which are used when Win64 flavours of x265 should be built in a MinGW32 environment. The differences are:

toolchain-x86_64-w64-mingw32.cmake
SET(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres)
SET(CMAKE_RANLIB x86_64-w64-mingw32-ranlib)
SET(CMAKE_ASM_YASM_COMPILER yasm)

In XhmikosR's MSYS environment, several binaries named "x86_64-w64-mingw32-*.exe" do exist, more than binaries named "i686-w64-mingw32-*.exe"; they all are missing in the directory msys64/mingw32/bin of MABS. I have no knowledge about the nature of these files. I wonder if they belong to a "GNU C++ cross-compilation package" which MABS does not need because MABS uses separate MinGW32 and MinGW64 system branches to build matching binaries natively.

If one knew that they are indeed the mirrored binaries of the opposite MinGW bitness, I guess one could add symbolic links to each opposite MinGW branch, enabling an optional cross-compilation of either the Win64 build of x265 using MinGW32 compilers (analogue to the behaviour in the current MSYS scripts) or the Win32 build of x265 using MinGW64 compilers (possibly preferred for more efficiency).

But if they differ in their functionality (e.g. have to be aware of building a binary not matching the native bitness of the environment), then they may have to get installed at least once manually into the MSYS2 system, hoping that the MABS updater will keep them up to date just along with the packages MABS needs, simply because pacman will find updates for these cross-compilation packages as well.

[nevcairiel]

if you want to use MSYS2, then use the real, the standalone MSYS2 itself, not the Media Autobuild Suite

Thats what I do, just use plain vanilla MSYS2 for the shell, and my own compiler package (https://files.1f0.de/mingw/) extracted somewhere in PATH, and stuff just works like it did before with MSYS1. Native 32-bit compilers and 64-bit "cross" compilers (not really cross compilers, but they have the prefix).
Stuff like MABS is just way too annoying to handle.

[LigH]

But why waste twice the space with two separate MSYS2 environments (one automatically updated by MABS which I still occasionally use to build everything, and the other manually updated on demand but only specifically used to build x265)?

If the MSYS scripts provided by Multicorecare generally work in MSYS2 too, then all I need to know is why some cross-compilation GCC binaries are missing, and how to add them in a way that pacman is aware of them, to possibly update them along.
__

P.S.:

Apparently (https://stackoverflow.com/questions/39422894/mingw-x86-64-w64-mingw32-gcc-not-found) I would need to install MinGW-w64 (http://mingw-w64.org/) as cross-compilation package...

[Midzuki]

First of all, one really should forget the auto-update mania.
Updating for the sake of updating is pointless: if the system works, there is no need to fix it.

When I switched to MSYS2 many moons ago I used pacman only for downloading the missing stuff, EXCEPT the MinGW_w64+GCC packages. In the beginning I used the archives provided by Nev, but later I learned how to compile (and organize) the compilers themselves =)

IMHO the point of MSYS2 is *simplicity*:
build 32-bit binaries through mingw32,
build 64-bit binaries through mingw64, case closed :)

[LigH]

Well, okay ... so my "workaround" will become my habit.

[nevcairiel]

But why waste twice the space with two separate MSYS2 environments (one automatically updated by MABS which I still occasionally use to build everything, and the other manually updated on demand but only specifically used to build x265)?


Why indeed. I build everything just fine with my manual environment. :)

[mandarinka]

Apparently x265 can be up to 5% faster on AMD Ryzens if it doesn't use AVX2: link (https://forums.anandtech.com/threads/intel-skylake-kaby-lake.2428363/page-662#post-39149633) (RZN = Ryzen, CFL = Coffee Lake, SKL-X = Skylake-X)

Can we get some change to CPU detection/dispatcher that would make x265 not use AVX2 assembly on Zen cores? (this also hapens on Excavator) AFAIK.

I know I can override the autodetection in commandline, but it should really be done by default, because most people aren't going to know about this, plus it gets more iffy for GUI/frontend users.

[LigH]

I would suspect that the optimum may not be disabling it completely, but restricting it to specific thread pools ... just a wild guess, uneducated.

[jaiden190]

Hello. First time post here. I am trying to get HDR working. I Compiled a 10bit ffmpeg.exe and I can get everything else like bt.2020 to work. But I can't seem to get the metadata for the -master-display to work. Comes up with Unrecognized option 'master-display' when I start.

Bit of a nub with this. Any help would be appreciated.

[LigH]

Which version of x265 do you use? And do you prepend it with a double dash?

--master-display <string> SMPTE ST 2086 master display color volume info SEI (HDR)
format: G(x,y)B(x,y)R(x,y)WP(x,y)L(max,min)

is present in x265 v2.5, but I would not immediately know when it was introduced. Probably before v2.0 already.

Oh, wait, you said ffmpeg. So, it would be a part of

-x265-params <string> E..V.... set the x265 configuration using a :-separated list of key=value parameters

ffmpeg does not expose all x265 parameters as ffmpeg native parameters, only those which are quite common, especially common among several encoders.

[jaiden190]

Which version of x265 do you use? And do you prepend it with a double dash?

--master-display <string> SMPTE ST 2086 master display color volume info SEI (HDR)
format: G(x,y)B(x,y)R(x,y)WP(x,y)L(max,min)

is present in x265 v2.5, but I would not immediately know when it was introduced. Probably before v2.0 already.

Oh, wait, you said ffmpeg. So, it would be a part of

-x265-params <string> E..V.... set the x265 configuration using a :-separated list of key=value parameters

ffmpeg does not expose all x265 parameters as ffmpeg native parameters, only those which are quite common, especially common among several encoders.


I compiled it with media-autobuild_suite-master. I assume it gets the latest x265.

double dash has the same error.

-max-cll "1000,400" has the same problem also.

[LigH]

Once again: Did you try putting it into -x265-params (with a syntax like: -x265-params master-display=string:max-cll=1000,400 etc.) for ffmpeg?

[jaiden190]

Once again: Did you try putting it into -x265-params (with a syntax like: -x265-params master-display=string:max-cll=1000,400 etc.) for ffmpeg?

ahhh sorry about that. Didn't read you correctly.

Im getting somewhere now. I no longer get the Unrecognized option error now but when I run it i get this instead.

"Unable to find a suitable output format for 'G(0.265000,0.690000)B(0.150000,0.060000)R(0.680000,0.320000)WP(0.312700,0.329000)L(1000,1)'
G(0.265000,0.690000)B(0.150000,0.060000)R(0.680000,0.320000)WP(0.312700,0.329000)L(1000,1): Invalid argument"


this is what I am using.
x265-params -master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"

[microchip8]

ahhh sorry about that. Didn't read you correctly.

Im getting somewhere now. I no longer get the Unrecognized option error now but when I run it i get this instead.

"Unable to find a suitable output format for 'G(0.265000,0.690000)B(0.150000,0.060000)R(0.680000,0.320000)WP(0.312700,0.329000)L(1000,1)'
G(0.265000,0.690000)B(0.150000,0.060000)R(0.680000,0.320000)WP(0.312700,0.329000)L(1000,1): Invalid argument"


this is what I am using.
x265-params -master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"

it should be...

x265-params master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"

[jaiden190]

it should be...

x265-params master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"

ahhhhh thats it. I have only really used handbrake GUI. Not used to CLI. Thank you both for your help.

[LigH]

One more thought regarding MSYS2 ... MABS seems to be able to switch from the MinGW32 to the MinGW64 environment. Once I discover how it does that, I may be able to fully automate my own x265-only build script to generate one after another, each using the native compiler bitness.

[Barough]

x265 v2.5+33-6a310b24c6a2 (http://www81.zippyshare.com/v/eL7yBYrw/file.html) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[_kermit]

Hi,

CRF has obviously a direct influence on the Bitrate and therefor on the Quality.

but is guess the assumption is correct that:

- the slower the preset, the higher the Bitrate?
- using "--tune grain" also increases the Bitrate?

How big is the influence on those two?

if those two increase Bitrate, would it be feasible to increase CRF to a higher value while preserving the Quality and use a faster preset and skip --tune grain which could also speed up the encoding?

Basically I'll aks because I usually use CRF 22, "slower" and --tune grain, which is kind of slow of course and I'm wondering if there is an good alternative to that but faster?

cheers, roland

[Boulder]

--tune grain increases the need for bitrate. When I started using x265 as a replacement for x264, I just used --tune grain --preset slower and various CRF values to find out the spot where the visual quality is good enough for me to not notice degrading while watching. For what it's worth, I now use CRF 21.8 for my 720p encodes. I have cherry picked some items from the even slower presets though.

In x264, a slower preset usually means a lower bitrate with the same CRF.

[excellentswordfight]

--tune grain increases the need for bitrate. When I started using x265 as a replacement for x264, I just used --tune grain --preset slower and various CRF values to find out the spot where the visual quality is good enough for me to not notice degrading while watching. For what it's worth, I now use CRF 21.8 for my 720p encodes. I have cherry picked some items from the even slower presets though.

In x264, a slower preset usually means a lower bitrate with the same CRF.
One could think that it would work like that in x265, that it hit's the same quality (since it's crf) at a lower bitrate. But from what i've seen it's the other way arround, I get almost half the bitrate at preset fast compared to slow. The faster presets probably skips alot of fine detail retention.


Basically I'll aks because I usually use CRF 22, "slower" and --tune grain, which is kind of slow of course and I'm wondering if there is an good alternative to that but faster?

cheers, roland
Try to compare it to crf18, preset slow and --no-sao. No sao doesnt hurt speed and helps with detail retention at higher bitrates (and hurt overall image quality at lower). Should be 3-4x as fast, there will ofc be tradeoffs in compression (it doesn't just waste all that time).

[LoRd_MuldeR]

Hi,

CRF has obviously a direct influence on the Bitrate and therefor on the Quality.

but is guess the assumption is correct that:

- the slower the preset, the higher the Bitrate?
- using "--tune grain" also increases the Bitrate?

How big is the influence on those two?

if those two increase Bitrate, would it be feasible to increase CRF to a higher value while preserving the Quality and use a faster preset and skip --tune grain which could also speed up the encoding?

Basically I'll aks because I usually use CRF 22, "slower" and --tune grain, which is kind of slow of course and I'm wondering if there is an good alternative to that but faster?

cheers, roland

You should not expect that the same CRF value still gives the same (approximately) quality after influential settings - especially the Preset/Tune - have been changed.

All you really know is that:

The same CRF value gives the same (approximately) quality for different sources, as long as no other settings are changed.
Using a slower preset improves the "quality per bit" ratio. Conversely, using a faster preset hurts the "quality per bit" ratio. But, in both cases, the absolute bitrate - at a fixed CRF value - may change more or less arbitrarily.


Or, in other words, when influential settings - especially the Preset/Tune - are changed, then the "meaning" of CRF values (in terms of resulting quality) can change as well!

Therefore, I would suggest to first pick the slowest Preset that you are willing to accept (in terms of encoding time). Then, while sticking with the chosen Preset, find the highest CRF value that still gives satisfying quality....

(And for testing Tune options, you should use 2-Pass mode, so that you get a "fair" comparison of files with identical average bitrates. Visually comparing files of different average bitartrates is misleading!)

[_kermit]

One could think that it would work like that in x265, that it hit's the same quality (since it's crf) at a lower bitrate. But from what i've seen it's the other way arround, I get almost half the bitrate at preset fast compared to slow. The faster presets probably skips alot of fine detail retention.


Try to compare it to crf18, preset slow and --no-sao. No sao doesnt hurt speed and helps with detail retention at higher bitrates (and hurt overall image quality at lower). Should be 3-4x as fast, there will ofc be tradeoffs in compression (it doesn't just waste all that time).

my bad, I already use "slow", not slower. so I guess that wouldn't make a difference, but using CRF 18 certainly increases size a lot.
But does "slower" make it 3-4 times slower?

[_kermit]

You should not expect that the same CRF value still gives the same (approximately) quality after influential settings - especially the Preset/Tune - have been changed.

All you really know is that:

The same CRF value gives the same (approximately) quality for different sources, as long as no other settings are changed.
Using a slower preset improves the "quality per bit" ratio. Conversely, using a faster preset hurts the "quality per bit" ratio. But, in both cases, the absolute bitrate - at a fixed CRF value - may change more or less arbitrarily.


Or, in other words, when influential settings - especially the Preset/Tune - are changed, then the "meaning" of CRF values (in terms of resulting quality) can change as well!

Therefore, I would suggest to first pick the slowest Preset that you are willing to accept (in terms of encoding time). Then, while sticking with the chosen Preset, find the highest CRF value that still gives satisfying quality....

(And for testing Tune options, you should use 2-Pass mode, so that you get a "fair" comparison of files with identical average bitrates. Visually comparing files of different average bitartrates is misleading!)

alright. so far CRF 22 worked pretty well while using slow and grain.
So, if I skip grain, which costs a lot of time, I would either need to lower CRF (to what?) or use a slower preset (in my case "slower")?

Skipping "grain" may speed up encoding, "slower" would slow it down again and using a lower CRF improves Quality, compensating for the changes?

BTW: I already use --no-sao.

And that is applicable to 1080p and UHD?

[LoRd_MuldeR]

alright. so far CRF 22 worked pretty well while using slow and grain.
So, if I skip grain, which costs a lot of time, I would either need to lower CRF (to what?) or use a slower preset (in my case "slower")?

Skipping "grain" may speed up encoding, "slower" would slow it down again and using a lower CRF improves Quality, compensating for the changes?

BTW: I already use --no-sao.

And that is applicable to 1080p and UHD?

IMO, you should first decide what is the slowest Preset you are willing to use, in terms of encoding time. Then stick with that in the following.

Secondly, decide wether to use "--tune grain" or not. This can only be decided visually. And visual comparison requires both files to be compared to have exactly the same average bitrate - otherwise your visual comparison would be "unfair" and therefore meaningless/misleading. So, do two 2-Pass encodes - one with option "--tune grain" and one without it. And be sure to pick the same target average bitrate for both encodes. Also, the chosen target average bitrate for these 2-Pass encodes needs to be "reasonable", which means that it should be in the same range that your final encodes will be as well (i.e. the target average bitartrate should neither be unrealistically low, nor unrealistically high). Furthermore, you need to do this test with a source that represents the kind of stuff you are going to encode. Use the two resulting encodes to decide, visually, whether you prefer "--tune grain" or not. Then stick with that in the following.

Finally, now that you have decided the Preset and Tune, go figure out the highest possible CRF value that still gives satisfying result, quality-wise. Again this needs to be done visually, with an appropriate source, or a set of sources...

[_kermit]

IMO, you should first decide what is the slowest Preset you are willing to use, in terms of encoding time. Then stick with that in the following.

Secondly, decide wether to use "--tune grain" or not. This can only be decided visually. And visual comparison requires both files to be compared to have exactly the same average bitrate - otherwise your visual comparison would be "unfair" and therefore meaningless/misleading. So, do two 2-Pass encodes - one with option "--tune grain" and one without it. And be sure to pick the same target average bitrate for both encodes. Also, the chosen target average bitrate for these 2-Pass encodes needs to be "reasonable", which means that it should be in the same range that your final encodes will be as well (i.e. the target average bitartrate should neither be unrealistically low, nor unrealistically high). Furthermore, you need to do this test with a source that represents the kind of stuff you are going to encode. Use the two resulting encodes to decide, visually, whether you prefer "--tune grain" or not. Then stick with that in the following.

Finally, now that you have decided the Preset and Tune, go figure out the highest possible CRF value that still gives satisfying result, quality-wise. Again this needs to be done visually, with an appropriate source, or a set of sources...

thanks!

[excellentswordfight]

my bad, I already use "slow", not slower. so I guess that wouldn't make a difference, but using CRF 18 certainly increases size a lot.
But does "slower" make it 3-4 times slower?
Slower together with tune grain is that much slower yes, or atleast if the source is of very high quality/detailed/grainy.

I use slow, no-sao, crf18 for 1080p and crf22 for UHD. This is my sweetspot for compression/speed ratio. It doesnt give me visually lossless encodes (which i wouldnt use x265 for anyway), but they are most definitely transparent under normal viewing conditions. I found that for 1080p crf22 without tune grain isnt enough to keep fine details on grainy/detailed sources, but that crf18 with only no-sao is close enough.

LoRd_MuldeR is giving you a very good base for doing tests that will lead you to your sweetspot.

[Boulder]

--tune grain disables recursion skip which makes things really slow. I forgot to mention that I use --rskip to re-enable it, I've not seen any side effects for doing that.

[_kermit]

Slower together with tune grain is that much slower yes, or atleast if the source is of very high quality/detailed/grainy.

I use slow, no-sao, crf18 for 1080p and crf22 for UHD. This is my sweetspot for compression/speed ratio. It doesnt give me visually lossless encodes (which i wouldnt use x265 for anyway), but they are most definitely transparent under normal viewing conditions. I found that for 1080p crf22 without tune grain isnt enough to keep fine details on grainy/detailed sources, but that crf18 with only no-sao is close enough.

LoRd_MuldeR is giving you a very good base for doing tests that will lead you to your sweetspot.

grain on 1080p is actually ok, it's UHD were it gets really slow and I might use rskip as mentioned.
We have similar Settings, so I guess I'm good as Long as I can Speed up uhd a bit also.

[_kermit]

--tune grain disables recursion skip which makes things really slow. I forgot to mention that I use --rskip to re-enable it, I've not seen any side effects for doing that.

that's a good tip. thanks.

[Midzuki]

x265.exe 2.5+37-aa9649a2aa8c

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2501168#post2501168

[LigH]

Version 2.5+38 will introduce a new parameter pair to "denote VBV emptiness after inserting all the frames into it".

This enables basic support for chunk-parallel encoding where each segment can specify the starting and ending state of the VBV buffer so that VBV compliance can be maintained when chunks are independently encoded and stitched together.

Release withheld due to a cosmetic issue in the produced help text (missing line breaks).

[LigH]

x265 2.5+47-6a882a9300c2 (https://www.mediafire.com/file/5q3fbi4taakcs19/x265_2.5%2B47-6a882a9300c2.7z)

Speed-ups, API changes, more internal analysis features, new CLI parameters:

--vbv-end <float> Final VBV buffer emptiness (fraction of bufsize or in kbits). Default 0 (disabled)
--vbv-end-fr-adj <float> Frame from which qp has to be adjusted to achieve final decode buffer emptiness. Default 0
--lowpass-dct Use low-pass subband dct approximation. Default disabled
--refine-mv-type <string> Reuse MV information received through API call. Supported option is avc. Default disabled - 0

Docs: refine-mv-type (http://x265.readthedocs.io/en/default/cli.html?highlight=refine-mv-type#cmdoption-refine-mv-type), vbv-end (http://x265.readthedocs.io/en/default/cli.html?highlight=vbv-end#cmdoption-vbv-end)

[Magik Mark]

Thanks for the new switches.

I was just wondering what could be a good value for these switches in order to optimize my encoding? Does it have any prerequisites?

[x265_Project]

Thanks for the new switches.

I was just wondering what could be a good value for these switches in order to optimize my encoding? Does it have any prerequisites?
None of these are likely to help you.
--vbv-end
--vbv-end-fr-adj
are only useful for companies who want to do segmented encoding

--lowpass-dct has potential to speed up encoding for faster presets, but it was just contributed (thank you!), and we haven't had a chance to run the experiments that will help us understand where and when it makes sense to use in terms of speed vs. efficiency.
--refine-mv-type <string> is only useful for 2 pass encoding where the first encoder is different than x265... like, a hardware encoder that can do a lower efficiency, but fast first pass. This won't help anyone doing x265 software encodes. This is all still highly developmental.

[Selur]

@MagikMark:
As far as I see:
'vbv-end' is only useful if you want to stitch together multiple encodes and 'vbv-end-fr-adj' requires the use of '--frames' when used with pipe input so that x265 does know the frame count of the input.
'lowpas-dct' is only for those in the need for speed and quality isn't your concern. ('Empirical analysis shows marginal loss in compression and performance gains up to 10%, paticularly at moderate bit-rates.' see: https://x265.readthedocs.io/en/latest/cli.html?highlight=lowpass%20dc#cmdoption-lowpass-dct)
'refine-mv-type' <- not sure how to use this and when this could really help, see: http://x265.readthedocs.io/en/latest/cli.html?highlight=refine-mv-type#cmdoption-refine-mv-type
-> you probably don't want to use these values at all :)


Cu Selur

Ps.: x265_Project was faster :)

[LigH]

A recent API change made libx265 temporarily incompatible with e.g. ffmpeg calling it in C convention; a patch converting C++ style to C style is submitted in the mailing list but not yet commited to the repo...

[Blue_MiSfit]

What's the usefulness of these new VBV params when you're doing segment encoding?