x265 HEVC Encoder

[iwod]

I cant believe it has been 4 - 5 years since x265 first appeared on Doom9! And I cant believe I had to wait all these years for wide spread support and uses, starting with Apple. God I am Old!

Anyway, I wanted to ask, how far is x265 being developed in terms of Video Quality? Are we in the late stage of development where we are focusing on encoding speed and shouldn't expect any more dramatic improvement in Video Quality? Pretty much like x264 in 2011 onwards.

[LigH]

More or less ... unfortunately there are still some quality issues to be investigated: Some people believe that detail retention could be improved (which is mainly an issue for smaller frame dimensions), and there are cases where tiny image elements are dragged away by motion (notorious example: Star Wars intro, star scroller).

[Motenai Yoda]

...starting with Apple. God I am Old!
starting with who?
HEVC has "wide spread support and uses" since years, s5 was the first smartphone with hevc hw decode capability as most of nowdays smartphones/tablets, Windows 10 has an integrate HEVC support (but only hw based), a lot of tvs can play even 10bit HEVC 4K HDR video/stream

this apple marketing piss me off when even my father's p8 lite can play a hevc file!!!

[stax76]

Does x264 --no-cabac fit into any of the tab page names that are used in the staxrip x265 GUI?

https://github.com/stax76/staxrip#x265-encoder-options

I'm re-implementing the x264 GUI, in the nvenc GUI I've put cabac to the 'Other' page, maybe there is a better fit.

[iwod]

starting with who?
HEVC has "wide spread support and uses" since years, s5 was the first smartphone with hevc hw decode capability as most of nowdays smartphones/tablets, Windows 10 has an integrate HEVC support (but only hw based), a lot of tvs can play even 10bit HEVC 4K HDR video/stream

this apple marketing piss me off when even my father's p8 lite can play a hevc file!!!

Ok.

Because of the way it works, most Android could play HEVC due to Software decoding. But not everyone will play it smoothly, due to the lacking single thread performance and hardware decode.
Not "Every" Samsung Phone or Tablet has HEVC hardware Decode. Namely their own SoC. Although most Qualcomm SoC should have by default.
Not every manufacture would have hardware decode by default EVEN if it is present on the SoC, because of patents licensing. And happens in certain countries.
And of coz there is a difference between FULL hardware decode and partial hardware decode.


Now name me a few big Network, services providers that are using HEVC for broadcasting or streaming? Purely for the numbers, there is more HEVC hardware decode capable product sold in China then US + EU + Japan combined. And yet most of their Streaming networks still aren't on HEVC. ( Actually not entirely true now in 2017 for China )
And which of these Network, has a FULL catalog of options available in HEVC. Not Amazon, Not Netflix, Not BBC, and heck the most common BT movie and shows are still on H.264 and not on HEVC. And this is the same in China.

May be i should have said "Ending" with Apple. Now the world could finally moves towards HEVC. ;)

[Motenai Yoda]

I didn't wrote that all products supports hevc, but most of them since years, also even most low budget phones like huawei p8 lite or samsung grand prime can easely hw decode a 720p 8bit, IIRC all tvs on sale in Germany, France and Italy should have a t2 decoder with hevc support, intel igpus from haswell (hw accelerated, from skylake full 8/10bit hw), nvidia gpus since gtx 960 and xbox one too.

You ask for some network? Netflix and Amazon streams 4k hevc to their subscribers, and PB lists me a lot of movies/series in hevc (405026)
UHD BD format rely on HEVC

but now apple with its 100 milions iphone 6s/7 will change everything, sure

[x265_Project]

FYI - Kavitha and Santhoshini are 2 of our developers. As they mentioned, we'll work on improving the documentation for all of x265's analysis load/save/optimization features.

[GhostAFRippEr]

x265 Where can I add HDR ?

[sneaker_ger]

http://x265.readthedocs.io/en/default/cli.html#vui-video-usability-information-options

You can use those options to add the necessary flags. Actual creation of HDR content has to be done outside of x265.

[LigH]

x265 2.4+75-80c23559084c (GCC 6.3.0) (https://www.mediafire.com/file/lxh7odjv4v5ial5/x265_2.4%2B75-80c23559084c.GCC630.7z)
x265 2.4+75-80c23559084c (GCC 7.1.0) (https://www.mediafire.com/file/9irj6iurcva2cec/x265_2.4%2B75-80c23559084c.GCC710.7z)

mostly improvements for SEA integral calculations with AVX2 assembly; some tidy-up.

Note: make directive "ENABLE_DYNAMIC_HDR10" is now renamed to "ENABLE_HDR10_PLUS"

Attention: New archive structure! (May change next time again, it feels bloated already... what to omit, what to keep?)
_

libhdr10plus.dll — separate DLL to handle Dynamic HDR10+ definitions in JSON format (possibly to be used by a custom application, used in parallel to a libx265.dll?)

libx265_main.dll — DLL with 8 bit precision x265 encoder core, to be used by a custom application or another x265 CLI, Dynamic HDR10+ support disabled
libx265_main10.dll — DLL with 10 bit precision x265 encoder core, to be used by a custom application or another x265 CLI, Dynamic HDR10+ support disabled
libx265_main12.dll — DLL with 12 bit precision x265 encoder core, to be used by a custom application or another x265 CLI, Dynamic HDR10+ support disabled
libx265.dll — multi-library DLL with 8+10+12 bit precision x265 encoder cores, to be used by a custom application, Dynamic HDR10+ support disabled

x265_main.exe — CLI application with 8 bit precision x265 encoder core (can use DLLs with different precisions), Dynamic HDR10+ support disabled
x265_main10.exe — CLI application with 10 bit precision x265 encoder core (can use DLLs with different precisions), Dynamic HDR10+ support disabled
x265_main12.exe — CLI application with 12 bit precision x265 encoder core (can use DLLs with different precisions), Dynamic HDR10+ support disabled
x265_ml.exe — multi-library CLI application with 8+10+12 bit precision x265 encoder cores (needs no other DLLs), Dynamic HDR10+ support disabled

HDR10plus\libx265.dll — multi-library DLL with 8+10+12 bit precision x265 encoder cores, to be used by a custom application, Dynamic HDR10+ support enabled
HDR10plus\x265_ml.exe — multi-library CLI application with 8+10+12 bit precision x265 encoder cores (needs no other DLLs), Dynamic HDR10+ support enabled
_

I don't see any reference to the libhdr10plus.dll in any x265 CLI or DLL when built with Dynamic HDR10+ disabled, so I doubt that they will be able to support it simply because the libhdr10plus.dll resides in the same directory (similar to supporting a core with different precision); I guess that if you want Dynamic HDR10+ to be supported, you have to use an enabled build, but then it will already contain the code, so there is no obvious need for that separate DLL, at least for [lib]x265; maybe for a custom application handling both tasks separately.

I did not yet try to discover if it is possible to build a mostly dynamically linked package with Dynamic HDR10+ support, consisting of one CLI and all the rest as DLLs, with the libhdr10plus.dll still separated... I would assume that its code would be included in the CLI or DLLs at least once, if not everywhere.

As a GUI author using any x265 CLI, I assume you would prefer using only the HDR10plus\x265_ml.exe (All-In-One build) as x265.exe called by your GUI.

[Midzuki]

x265.exe 2.4+87-5f2330bdb8fa

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

[LigH]

x265 2.4+87-5f2330bdb8fa (GCC 6.3.0) (https://www.mediafire.com/file/9xkdqecw3qtu0o2/x265_2.4%2B87-5f2330bdb8fa.GCC630.7z)
x265 2.4+87-5f2330bdb8fa (GCC 7.1.0) (https://www.mediafire.com/file/v7xdauig5gozxu4/x265_2.4%2B87-5f2330bdb8fa.GCC710.7z)

merge with stable; several renames, optimizations, refinements... most obvious CLI changes:

--analysis-reuse-mode <string|int> save - Dump analysis info into file, load - Load analysis buffers from the file. Default 0
--analysis-reuse-file <filename> Specify file name used for either dumping or reading analysis data. Deault x265_analysis.dat
--analysis-reuse-level <1..10> Level of analysis reuse indicates amount of info stored/reused in save/load mode, 1:least..10:most. Default 5

--[no-]refine-mv Enable mv refinement for load mode. Default disabled

--[no-]const-vbv Enable consistent vbv. turned on with tune grain. Default disabled

[Atak_Snajpera]

As a GUI author using any x265 CLI, I assume you would prefer using only the HDR10plus\x265_ml.exe (All-In-One build) as x265.exe called by your GUI.
Yeah. Single executable makes more sense for GUI maker like me.

[stax76]

less is sometimes more...

[pradeeprama]

I don't see any reference to the libhdr10plus.dll in any x265 CLI or DLL when built with Dynamic HDR10+ disabled, so I doubt that they will be able to support it simply because the libhdr10plus.dll resides in the same directory (similar to supporting a core with different precision); I guess that if you want Dynamic HDR10+ to be supported, you have to use an enabled build, but then it will already contain the code, so there is no obvious need for that separate DLL, at least for [lib]x265; maybe for a custom application handling both tasks separately.



We've enabled exporting libhdr10plus.dll in case any application integrator wants to use the functions exported by this library (which enable parsing json files that contain creative intent meta-data for the SMPTR-2094-40) in their own video library.

By default, libx265 already integrates this code natively when HDR10PLUS is enabled in Cmake, to avoid extra library dependence. When disabled, the options --dhdr10-info, and --dhdr10-plus won't work.

Hope this clarifies things.

[LigH]

So I have to ask: Does anyone here need anything more than the "All-in-one" EXE? If not, I will release only that regularly in the future. Alternative files by request only (e.g. a library for GUIs like Avidemux).

[stax76]

All-in-one sounds good.

[Magik Mark]

Can somebody confirm my finding:

Using +87 in --multi* causes a lot of blocking in 2pass 10bit x265. Video is unwatchable. No problem before +87

[Magik Mark]

How do I use the --analysis-reuse *?

If I use "Save", When and how do i use the "Load"? In 2nd pass?

[Ma]

Can somebody confirm my finding:

Using +87 in --multi* causes a lot of blocking in 2pass 10bit x265. Video is unwatchable. No problem before +87

Yes, see issue #354 https://bitbucket.org/multicoreware/x265/issues/354/patch-69f316d001b5-breaks-2pass-encoding
--------------------------------
Now 2pass encoding is fixed (from ver. 2.4+89).

[Barough]

x265 v2.4+89-fa076d29d619 (http://ge.tt/6jKmxYl2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.4+89-fa076d29d619
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

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

[Midzuki]

x265.exe 2.4+93-ef8dfbb70dd6

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2490163&viewfull=1#post2490163

[Magik Mark]

Guys,

Can you explain the difference between --analysis vs --multipass?

Both are trying to eliminate the work redundancy on multi pass encoding. Why not just have one command for this?

[LigH]

The mysteries of

http://kestas.kuliukas.com/MultiPass/leeloo_multipass.jpg

--[no-]multi-pass-opt-analysis (http://x265.readthedocs.io/en/default/cli.html#cmdoption-multi-pass-opt-analysis)
--[no-]multi-pass-opt-distortion (http://x265.readthedocs.io/en/default/cli.html#cmdoption-multi-pass-opt-distortion)

Multipass {analysis refinement|refinement of qp} cannot be enabled when ‘analysis-save/analysis-load’ option is enabled and both will be disabled when enabled together.

--analysis-reuse-mode <string|int> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-mode)
--analysis-reuse-file <filename> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-file)
--analysis-reuse-level <1..10> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-level)

I guess that using an analysis file supersedes several on-the-fly internal calculations a refinement would have used with fixed values not meant to be changed further... I wonder how deep you have to understand the principles of operation in the encoder core, to understand the relations between these two groups of options. You may probably have to be able to read and understand the C sources, at least.

I see the analysis file use rather as a kind of debugging and optimization tool for running dozens of encodings and comparing a lot of statistics, rather than speeding up a casual user's movie conversion.

[Magik Mark]

Thanks LigH.

It is really difficult to understand these things especially for ordinary folks like me. How I wish someone can explain these through images. I think that is more comprehensible for everyone

[Barough]

x265 v2.4+96-58b4fa89c42d (http://ge.tt/3FD54al2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.4+96-58b4fa89c42d
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

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

[x265_Project]

The mysteries of
...
--analysis-reuse-mode <string|int> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-mode)
--analysis-reuse-file <filename> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-file)
--analysis-reuse-level <1..10> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-level)

Analysis reuse provides the basic framework for more advanced solutions that we are building on top of / around x265 (in UHDkit). I don't want to go into more detail about all of the use-cases, as we've seen our competition already attempting to our methods. The basic idea is to produce solutions that run faster (for live encoding scenarios) and more computationally efficient (for offline encoding scenarios). These modes are not going to provide any benefit to anyone today who is just using x265 alone. They won't produce higher quality.

[LigH]

x265 2.4+96-58b4fa89c42d (https://www.mediafire.com/file/fk1tj49fs44rc21/x265_2.4%2B96-58b4fa89c42d.7z) (GCC 7.1.0, Win32+Win64, AIO EXE+DLL only)

merge with stable; several fixes and tweaks

renamed / changed / new CLI options:

--analysis-reuse-mode <string|int> save - Dump analysis info into file, load - Load analysis buffers from the file. Default 0
--analysis-reuse-file <filename> Specify file name used for either dumping or reading analysis data. Deault x265_analysis.dat
--analysis-reuse-level <1..10> Level of analysis reuse indicates amount of info stored/reused in save/load mode, 1:least..10:most. Default 5

--refine-intra <int> Enable intra refinement for load mode. Default 0

--[no-]const-vbv Enable consistent vbv. turned on with tune grain. Default disabled

[Midzuki]

x265.exe 2.4+97-006c75cf822e

Aruna Matheswaran committed 006c75c
2017-06-22

Allocate frame threads based on available pool threads

This patch decides #frame-threads based on #pool-threads available. If pools not
specified, #frame-threads will be decided based on detected #CPU-threads.

This patch also decreases #frame-threads allocated for #pool-threads in the
interval (15 - 31) and (>= 32) as there is high run to run variation in bitrate
and SSIM with higher frame threads.With this reduction in #frame-threads there
is ~3-4 % drop in fps with little SSIM improvement for #pool-threads (15 - 31)
and no significant change in performance for #pool-threads (>= 32).


https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2490727&viewfull=1#post2490727

[pingfr]

x265.exe 2.4+97-006c75cf822e

Aruna Matheswaran committed 006c75c
2017-06-22

Allocate frame threads based on available pool threads

This patch decides #frame-threads based on #pool-threads available. If pools not
specified, #frame-threads will be decided based on detected #CPU-threads.

This patch also decreases #frame-threads allocated for #pool-threads in the
interval (15 - 31) and (>= 32) as there is high run to run variation in bitrate
and SSIM with higher frame threads.With this reduction in #frame-threads there
is ~3-4 % drop in fps with little SSIM improvement for #pool-threads (15 - 31)
and no significant change in performance for #pool-threads (>= 32).


https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2490727&viewfull=1#post2490727

If this is what I think it is, this should tremendously help encoding faster on high-end dedicated servers? Thinking of a SMP machine with like 60 cores, 120 threads, etc?

[LigH]

The maximum number of threads will still be somewhat limited, due to a limited bitfield width of the core mask. Furthermore, too many threads for one encoder instance don't make sense, will be inefficient because each thread will only "see" a small part of the frame, and the thread sync overhead rises. With a huge number of physical cores, running several instances of the encoder in parallel on a subset of cores each is much more efficient (quality / speed).

I guess this patch will support the execution of several instances, each limited to a subset of cores, by allocating threads based on the limited amount of cores in each separate pool, as if there was only a CPU with fewer cores, thus avoiding too many threads in the sum of all instances.

[sneaker_ger]

Did we read the same text?
With this reduction in #frame-threads there
is ~3-4 % drop in fps with little SSIM improvement for #pool-threads (15 - 31)
and no significant change in performance for #pool-threads (>= 32).
To me it means:
15 - 31 threads: 3% to 4% slower
>= 32 threads: +/- 0%

[LigH]

Pradeep's patch review note before committing was: "The improvements in quality seem to justify the change."

Quite imaginable to me: Fewer threads reduce the speed a bit, but increase the quality. And beyond a threshold of threads, saturation effects of the thread management may be the bottleneck, I guess.

[Barough]

x265 v2.4+99-3160e1a0cc5f (http://ge.tt/4bMFkhl2) (MSYS/MinGW, GCC 7.1.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 : HEVC encoder version 2.4+99-3160e1a0cc5f
x265 [info]: build info [Windows][GCC 7.1.0][32/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

[I]Merge with default; prep for v2.5

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

[pingfr]

Pradeep's patch review note before committing was: "The improvements in quality seem to justify the change."

Quite imaginable to me: Fewer threads reduce the speed a bit, but increase the quality. And beyond a threshold of threads, saturation effects of the thread management may be the bottleneck, I guess.

In layman's terms, does that implies this patch merged in not only increases encoding speed but the overall resulting quality as well or am I getting confused here? :o

[nevcairiel]

In layman's terms, does that implies this patch merged in not only increases encoding speed but the overall resulting quality as well or am I getting confused here? :o

It slows down speed for some thread/core configurations but increases quality.

[pingfr]

So quality increase (visual subjectivity is subjective) at equal bitrate pre-patch but at a 3-4% speed decrease cost, correct?

[burfadel]

Depending on configuration. Actual difference also includes any filters used. The figures aren't given as 'you will receive', if figures weren't given people would be questioning how much.

[LigH]

Let me explain more verbosely how I imagine that. (If I am wrong, don't hesitate to correct me. Understanding x265 frame threading constraints (http://x265.readthedocs.io/en/default/threading.html#frame-threading) is hard.)

Let's imagine you have a dual socket mainboard, each of your two CPU's has 16 cores (maybe logical due to HT). So the whole system will report 32 cores overall.

You decide to run two instances of x265 at the same time, each with a thread pool of 16, to run distinctly on either CPU.

Before this patch, the number of frame threads depended on the number of cores in the whole system, so it was calculated in relation to the number 32.

After this patch, the number of frame threads will depend on the capacity of each separate thread pool, thus be calculated in relation to the number 16. In addition, it reduces them a bit more, as the developers discovered that even fewer threads in this range, compared to the previous calculation of the optimal number, has an advantage.

Of course this means fewer frame threads. That will slow down the calculation a bit. But before, x265 may have been less efficient, because it spawned too many threads for the limited pool (causing more synchronization overhead than necessary) and with a smaller scope each ("seeing" less of the whole neighborhood of the currently encoded slice, finding less candidates to reduce redundancy).

After this patch, the number of frame threads will match the size of the limited thread pool better, there is less thread synchronization, and each frame thread can have a wider scope, encoding more efficiently by finding better inter-coding candidates in a further distance. (At least the second half of this statement may be misunderstood.)
_

P.S. - a quote from the docs:

Over-allocating frame threads can be very counter-productive. They each allocate a large amount of memory and because of the limited number of CTU rows and the reference lag, you generally get limited benefit from adding frame encoders beyond the auto-detected count, and often the extra frame encoders reduce performance.

Doesn't really explain the reason for a potential quality limitation due to over-allocation, though...

[Sagittaire]

x264 and x265 coding are really problematic with new CPU with multiple core like "threadripper" or "skylake-X". x264 and x265 are unable to make encoding at 100% for CPU charge for 2K or even for 4K with 16C/32T or more.

@ x265 team

Not possible to create a new encoding mode in x265 with multiple instance for better threading compatibility?

Use for exemple high lookahead buffer for make frame type decision and open new instance coding at each new Iframe (will be IDR).

This mode imply certainely high frame buffer but if you have "threadripper" or "skylake-X" CPU, you must have at least 16 GB for RAM or more.

This mode imply just Closed GOP and perhaps short GOP (60 frames maximum) to minimize frame buffer.

[pingfr]

Use for exemple high lookahead buffer for make frame type decision and open new instance coding at each new Iframe (will be IDR).

This mode imply certainement high frame buffer but if you have "threadripper" or "skylake-X" CPU, you must have at least 16 GB for RAM or more.

This mode imply just Closed GOP and perhaps short GOP (60 frames maximum) to minimize frame buffer.

Got 512GB of RAM here, should be fine. :devil:

[x265_Project]

x264 and x265 coding are really problematic with new CPU with multiple core like "threadripper" or "skylake-X". x264 and x265 are unable to make encoding at 100% for CPU charge for 2K or even for 4K with 16C/32T or more.

@ x265 team

Not possible to create a new encoding mode in x265 with multiple instance for better threading compatibility?

Use for exemple high lookahead buffer for make frame type decision and open new instance coding at each new Iframe (will be IDR).

This mode imply certainely high frame buffer but if you have "threadripper" or "skylake-X" CPU, you must have at least 16 GB for RAM or more.

This mode imply just Closed GOP and perhaps short GOP (60 frames maximum) to minimize frame buffer.
For a single instance of x265, we are limited in the # of threads we can use at any one time due to the serial nature of video encoding. For 4K encoding you should be able to utilize at least 20 threads efficiently. To increase parallelism, you can increase the number of frame threads, but this can affect rate control (although if you are using CRF rate control and you aren't using VBV, you shouldn't have any problem). You can also use --pme and/or --pmode. These functions will definitely increase CPU utilization, but they are not work-efficient (you won't see an increase in FPS that correlates with the increase in CPU utilization).

We have a commercial product called UHDkit that can run multiple x264 or x265 instances, in order to get more performance under different circumstances. As you know, x265 is free for anyone who can comply with the terms of the GPL v2 license. This includes large web video services, who don't distribute x265 (they distribute video). UHDkit is our value-added solution designed as an incentive for commercial customers to come to us to get a commercial license, which means they go from being free-riders on the x265 open source project to being sponsors of the project, which means we can hire more developers to improve x265 for everyone. The features in UHDkit are features that only commercial users would need, like the ability to produce multiple bit/quality rate tiers from a single video file twice as efficiently as doing unique encodes, or the ability to do live 4K 60P 10 bit encoding on a many-core (dual socket) server. Of course, anyone can run multiple instances of x265 on a single machine by themselves, but it wouldn't be easy to match the performance optimization features, or the other value-added features in UHDkit.

[Atak_Snajpera]

High core count on AMD/Intel cpus is not a problem if you are RipBot264 user. All you need to do is activate distributed encoding mode with some servers.
http://i.cubeupload.com/bFnBKC.png
This way you can easily saturate even dual AMD EPYC 7601 cpus (64C/128T) with just 1080p footage.

[x265_Project]

High core count on AMD/Intel cpus is not a problem if you are RipBot264 user. All you need to do is activate distributed encoding mode with some servers.
This way you can easily saturate even dual AMD EPYC 7601 cpus (64C/128T) with just 1080p footage.
Is it open source? If you call x264 or x265, you need to comply with the GPL v2, and make your source code available under the GPL v2. This is a good thing, as others can contribute to help make it even better.

[jd17]

May I ask a question to the x265 devs here?

Why is --sao enabled by default?
We recently discussed this in another thread...

As the other thread is about high quality encodes, I thought --sao might be beneficial at low bitrates...
So I encoded my sample at 400 kbit/s, default settings, no tune. Once default, once with --no-sao.

Even at this extremely low bitrate I see no real benefit of --sao.
At high bitrates however, nobody seems to like --sao, because it adds a lot of blur.

The savings with a CRF also seem minor, considering this is such a big quality impact...


So, what is the reason for --sao by default?
Am I just missing something or would you consider --no-sao as default? :)

[littlepox]

May I ask a question to the x265 devs here?

Why is --sao enabled by default?
We recently discussed this in another thread...

As the other thread is about high quality encodes, I thought --sao might be beneficial at low bitrates...
So I encoded my sample at 400 kbit/s, default settings, no tune. Once default, once with --no-sao.

Even at this extremely low bitrate I see no real benefit of --sao.
At high bitrates however, nobody seems to like --sao, because it adds a lot of blur.

The savings with a CRF also seem minor, considering this is such a big quality impact...


So, what is the reason for --sao by default?
Am I just missing something or would you consider --no-sao as default? :)

I think they will remove it once they are pressured by AV1 or something so that the boss demand them to increase the compression efficiency by 20% in the next release.

[LigH]

There are surely cases where SAO makes sense to reduce complexity. Mostly in UHD resolutions where looking at tiny details from a larger distance is less important than looking at small video dimensions close-up, where a pixel still makes an important detail, in relation.

[jd17]

Could someone help me out here?:
https://forum.doom9.org/showthread.php?p=1811483#post1811483

I would mainly like to know what exactly --hdr-opt actually does.
It does come with a bitrate saving, so far so good, but is there a (negative) impact on quality? If so, what kind of impact?

I don't see an immediate degradation in that demo video, but it might not be well suited to make out the difference...

[LigH]

Most of all, it tells the encoder to expect high dynamic range, and to adapt internal value ranges to characteristics of specific displays.

It is pretty useless for conversion of "usual video" without a high bit depth already in the original video source. If you don't know what "color primaries" mean, don't attempt to use it.

[x265_Project]

Could someone help me out here?:
https://forum.doom9.org/showthread.php?p=1811483#post1811483

I would mainly like to know what exactly --hdr-opt actually does.
It does come with a bitrate saving, so far so good, but is there a (negative) impact on quality? If so, what kind of impact?

I don't see an immediate degradation in that demo video, but it might not be well suited to make out the difference...

An MPEG study group looked at the question of whether the HEVC standard needed to be revised in order to optimize encoding of HDR content. People had noticed quality issues in certain places, and so this group looked at what was needed to avoid those issues. They found that no change was needed to the HEVC standard, but they issued some recommendations. --hdr-opt implements these recommendations. It's like a special type of adaptive quantization, which looks at the brightness level of each block of video. It improves encoding quality and efficiency for HDR content. Don't try to use it if you aren't encoding High Dynamic Range content.