x265 HEVC Encoder

[x265_Project]

The reason not to implement assembler optimized routines in 32 bit x265 versions is that it would be a waste of development time. Bit depths >8 would require twice the amount of RAM compared to the 8 bit version (addressing 16 bit even if only 10 or 12 bits precision are relevant), and already the allocated memory for 8 bit depth may be too much to encode 1080p video with a 32 bit build, depending on the complexity (preset).
Contributions are always welcomed, but you're right... the effort to fully optimize the 32 bit version of x265 (8 bit encoding only) is tough to justify. x265 has hundreds of kernels that are SIMD optimized for various instruction sets, and it's a fairly substantial effort (many, many developer man-months).

[brumsky]

Any idea when we might see the 10bit lamda table? I'm dying to give it a try!!

[LigH]

There is light at the end of the tunnel: A patch for 10 and 12 bit lambda tables was proposed in the mailing list. So stay alert, new builds might appear soon™...

[Magik Mark]

[emoji106]


Sent from my iPhone using Tapatalk

[brumsky]

Awesome!!

[benwaggoner]

Interesting, I wonder if this would address the complaints against SAO on this thread, namely that it causes too much blurring.
It's "just" a performance optimization.

[benwaggoner]

The 32bit version of x265 may lack some assembly optimizations that are present in the 64bit version of x265.

The 32bit version would also be more memory constrained, since it would be limited to 2-3 GB of memory... 64 bit versions wouldn't have such limitations.
Beyond the lack of assembly optimization, x64 has double the number of registers as old x86 vanilla.

I'm always startled to find someone still using a 32-bit OS. I think all my systems have been 64-bit since Win 7 came out back in 2009. Living in 4 GB of RAM for video apps was impractical a long time ago. Adobe dropped 32-bit support in their video apps back in 2010. And 64-bit is generally faster and quite a bit more secure. 64-bit software decoders are generally faster than 32-bit versions as well.

I recommend folks upgrade to 64-bit OSes rather than trying to make x265 run better on 32-bit!

[x265_Project]

Haivision was one of the four original commercial sponsors of x265, and four years later, we can finally go public with this! They have been a terrific partner over the years, continually investing in x265 and UHDkit, to push the envelope of what is possible in a software encoder. Both Haivision and MulticoreWare will be demonstrating the latest capabilities of x265 and UHDkit at the NAB show next week.

Haivision to Demonstrate Breakthrough Performance of Live 4K HEVC/H.265 Software Encoding at 2017 NAB Show
http://www.haivision.com/news-events/news/haivision-to-demonstrate-breakthrough-performance-of-live-4k-hevch265-software

[qyot27]

Beyond the lack of assembly optimization, x64 has double the number of registers as old x86 vanilla.

I'm always startled to find someone still using a 32-bit OS. I think all my systems have been 64-bit since Win 7 came out back in 2009. Living in 4 GB of RAM for video apps was impractical a long time ago. Adobe dropped 32-bit support in their video apps back in 2010. And 64-bit is generally faster and quite a bit more secure. 64-bit software decoders are generally faster than 32-bit versions as well.

I recommend folks upgrade to 64-bit OSes rather than trying to make x265 run better on 32-bit!
I don't know how large the market for them really is, but there are plenty of small mini-PCs that still ship with 32-bit versions of Windows because the companies involved don't want to put larger (read: anything over 32GB) internal storage in them, even though they use x86-64 hardware platforms.

And because said machines are likely using 32-bit UEFI (the horror) (https://software.intel.com/en-us/blogs/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems), it's practically impossible to upgrade to 64-bit Windows without replacing the computer entirely. You can still run 64-bit Linux distributions on them (with varying levels of difficulty getting it set up right), since EFI mixed mode has been supported in the Linux kernel since version 3.15 (https://www.phoronix.com/scan.php?page=news_item&px=MTY0OTI).

Personal anecdote time: I'm typing this post out on one such mini-PC (the Quantum Byte, specifically). It's a perfectly capable little machine for casual encoding or media consumption, or mundane office tasks/web browsing, but it's obviously not going to be used for serious encoding tasks. If I really want to squeeze it for performance and 64-bit usage, I did manage to get 64-bit Ubuntu installed to a USB stick and can boot from that when I need to (but running the OS through a USB 2.0 port is not exactly ideal for speed; probably negates all of the benefits 64-bit would've gotten me). It runs on the Atom Z3735F Bay Trail-T/Silvermont platform, so extrapolate whatever speed estimates you can there. It's good enough to bide my time until Coffee Lake arrives and I build something to replace the ancient Coppermine tower I'd been using as my main setup before I got the Byte. Provided Coffee Lake has AVX-512, anyway; there's been conflicting reports about that.

[Dclose]

I'm always startled to find someone still using a 32-bit OS. I think all my systems have been 64-bit since Win 7 came out back in 2009. Living in 4 GB of RAM for video apps was impractical a long time ago.
Windows 7 OS uses less than a gb. Encoding mostly relies on CPU. X265 was working great until I wanted to use 10-bit. Windows 7 32-bit works as well for video on my HTPC as it did when I first put it together years ago.

Though the main reason 32-bit 7 is on there is because the TV tuner cards in it don't have a driver that works with 64-bit except 64-bit Vista.

Anyway, can anyone explain when SSIM RD setting is used? Sometimes it kicks in when changing only that setting, and sometimes the file size remains the same. It says it's only used on certain presets. Does x265 have to have a preset selected for SSIM RD to be used at all?

[sneaker_ger]

https://x265.readthedocs.io/en/default/cli.html#cmdoption-ssim-rd
https://x265.readthedocs.io/en/default/presets.html

[benwaggoner]

Windows 7 OS uses less than a gb. Encoding mostly relies on CPU. X265 was working great until I wanted to use 10-bit. Windows 7 32-bit works as well for video on my HTPC as it did when I first put it together years ago.
CPUs run faster in x86-64 than x86-32, due to the doubled registers, even if they have the same asm features. The SIMD registers are doubled too, which can matter a lot.

Though the main reason 32-bit 7 is on there is because the TV tuner cards in it don't have a driver that works with 64-bit except 64-bit Vista.
Driver compatibility is one of the reasons why someone would stick to an old OS. Although the power and time savings from faster encoding would probably pay for a new tuner card quickly.

Anyway, can anyone explain when SSIM RD setting is used? Sometimes it kicks in when changing only that setting, and sometimes the file size remains the same. It says it's only used on certain presets. Does x265 have to have a preset selected for SSIM RD to be used at all?

--ssim-rd only works at --rd 3 or above. See here (http://x265.readthedocs.io/en/default/cli.html#cmdoption-ssim-rd).

--rd 3 is enabled in --preset medium and higher. See here (http://x265.readthedocs.io/en/default/presets.html#presets)(referenced as rdlevel).

ssim-rd is slower, so it definitely wouldn't make sense to use below --preset medium. I'd guess it wouldn't be a decent speed/quality tradeoff until at least --preset slower.

[brumsky]

@BenWaggoner

Based on the name of the paramter --ssim-rd, could one infer this should only be used for SSIM and PSNR tests?

Do you feel --ssim-rd is worth using?

[Dclose]

https://x265.readthedocs.io/en/default/cli.html#cmdoption-ssim-rd
https://x265.readthedocs.io/en/default/presets.html
Yes, those are there. But the preset chart doesn't show SSIM in it. And there's a tune for SSIM, but not SSIM RDO.
CPUs run faster in x86-64 than x86-32, due to the doubled registers, even if they have the same asm features. The SIMD registers are doubled too, which can matter a lot.

Driver compatibility is one of the reasons why someone would stick to an old OS. Although the power and time savings from faster encoding would probably pay for a new tuner card quickly.

On two desktops side by side, Win8.1-64 and Win7-32, both using i7 3770k at the same speed, 8-bit x265 speed has been similar on both of them. Maybe 10% or so slower on the one, but that one also has slower hard drives though I wouldn't think that matters when using high-quality/slow-speed settings in x265.

Using 10-bit x265 is when a huge difference is seen. Around 75% slower.


--ssim-rd only works at --rd 3 or above. See here.

--rd 3 is enabled in --preset medium and higher. See here (referenced as rdlevel).

That first sentence describes it more specifically. Here's why the question came up:

The paragraph for SSIM RDO says SSIM RDO is only used on presets which use RDO 3 and above.

Since presets can change, I've been leaving it on None and set everything manually. I wouldn't think a particular setting requires a preset to be used even when set manually, but when the description says "It only has effect on presets... --rd 3 and above," I raise an eyebrow and wonder.

And speaking of SSIM RDO, I don't know if it has better quality from months ago, but it seems like it.

[benwaggoner]

@BenWaggoner

Based on the name of the paramter --ssim-rdo, could one infer this should only be used for SSIM and PSNR tests?
It is --ssim-rd, not --ssim-rdo

It uses SSIM as a more advanced rate distortion metric than the default, taking longer but ideally improving perceptual quality.

Do you feel --ssim-rdo is worth using?
I'm not clear if it is a universal win in its current implementation. So many parameters to test!

[brumsky]

It is --ssim-rd, not --ssim-rdo

It uses SSIM as a more advanced rate distortion metric than the default, taking longer but ideally improving perceptual quality.


I'm not clear if it is a universal win in its current implementation. So many parameters to test!

That was a typo, I fixed it. ;)

Thanks, I'll test it with my preferred settings and go from there.

[sneaker_ger]

Yes, those are there. But the preset chart doesn't show SSIM in it. And there's a tune for SSIM, but not SSIM RDO.
Well, you tested - to cite you - when it "kicks in" so from that you should be able to deduct the answer.

The paragraph for SSIM RDO says SSIM RDO is only used on presets which use RDO 3 and above.

Since presets can change, I've been leaving it on None and set everything manually. I wouldn't think a particular setting requires a preset to be used even when set manually, but when the description says "It only has effect on presets... --rd 3 and above," I raise an eyebrow and wonder.
Yes, it's poorly documented.
1. Default is disabled. (== --no-ssid-rd)
2. It's not bound to having explicitly set any preset.

[brumsky]

It is --ssim-rd, not --ssim-rdo
I'm not clear if it is a universal win in its current implementation. So many parameters to test!

I just ran a very quick test with my settings which are a mix of very slow and placebo... For some reason my psy-rd was set to 0. Which of course resulted in a much smaller file, 55% smaller, but took about 1 second longer. The encode looks terrible compared to my default settings.

Has anyone else run into this?

[sneaker_ger]

Yes, psy rd is set to 0.0 when ssim-rd is turned on.

If you want to compare quality encode to same bitrate using 2pass encoding. Not surprising if something that uses 55% less bitrate looks worse. No knowledge to be gained from that.

[brumsky]

Yes, psy rd is set to 0.0 when ssim-rd is turned on.

If you want to compare quality encode to same bitrate using 2pass encoding. Not surprising if something that uses 55% less bitrate looks worse. No knowledge to be gained from that.

Why would it disable psy rd?

[benwaggoner]

Why would it disable psy rd?
Psy-rd adjusts QPs down for smoother areas and up for more complex areas of the video. SSIM as a metric weighs error in smoother areas higher than more complex areas, and thus optimize for exactly that sort of thing. Psy-rd + SSIM would likely give some kind of weird race condition.

[x265_Project]

HDR10+ delivers an optimized, high-quality HDR experience to consumers; Amazon Video is the first streaming video service that will implement HDR10+ technology to deliver a new source of high-quality digital video to Prime Video customers around the globe

LAS VEGAS--(BUSINESS WIRE)--Samsung Electronics Co., Ltd. and Amazon Video today announced the introduction of HDR10+, an updated open standard that leverages dynamic metadata to produce enhanced contrast and colors on an expanded range of televisions.

HDR10+ elevates the HDR10 open standard with the addition of Dynamic Tone Mapping. The current HDR10 standard utilizes static metadata that does not change during playback despite scene specific brightness levels. As a result, image quality may not be optimal in some scenes. For example, when a movie’s overall color scheme is very bright but has a few scenes filmed in relatively dim lighting, those scenes will appear significantly darker than what was originally envisioned by the director.

HDR10+ incorporates dynamic metadata that allows a high dynamic range (HDR) TV to adjust brightness levels on a scene-by-scene or even frame-by-frame basis. With the ability to display outstanding contrast with detailed highlights and a richer range of colors, HDR10+ produces images that are much closer to the director’s intent.

All of Samsung’s 2017 UHD TVs, including its premium QLED TV lineup, support HDR10+. In the second half of this year, Samsung’s 2016 UHD TVs will gain HDR10+ support through a firmware update.

“As an advanced HDR10 technology, HDR10+ offers an unparalleled HDR viewing experience — vivid picture, better contrast and accurate colors — that brings HDR video to life,” said Kyoungwon Lim, Vice President of Visual Display Division at Samsung Electronics. “We’re excited to work with world-class industry partners, including Amazon Video, to bring more amazing HDR content directly to our 2017 UHD TVs, including our QLED TV lineup.”

“Together with Samsung, we are excited to offer customers an enhanced viewing experience on a broad range of devices,” said Greg Hart, Vice President of Amazon Video, worldwide. “At Amazon, we are constantly innovating on behalf of customers and are thrilled to be the first streaming service provider to work with Samsung to make HDR10+ available on Prime Video globally later this year.”

The launch of the HDR10+ content continues Samsung’s and Amazon Video’s leadership in the HDR space. With the move to HDR 10+, Amazon Video is the first streaming service provider to begin development of the standard for its audiences. In May 2015, Samsung and Amazon Video brought HDR to the market using the HDR10 open standard, the first in the field. This bold and innovative advancement laid the groundwork for several HDR launches. From Hollywood film studios to global TV manufacturers, HDR10 is the most broadly used HDR standard today.

Samsung has also partnered with other industry leaders to deliver the best HDR10+ content viewing experience by establishing an HDR10+ ecosystem. Previously, Samsung collaborated with Colorfront to improve HDR10+ workflows for creative post-production mastering by using Colorfront’s Transkoder. Samsung also partnered with MulticoreWare to complete the integration of HDR10+ support in the x265 High Efficiency Video Coding (HEVC), which is available for free under an open source license, and is used by many popular commercial encoding system providers including Telestream, Haivision, and Rohde and Schwarz.

About Samsung Electronics Co., Ltd.

Samsung Electronics Co., Ltd. inspires the world and shapes the future with transformative ideas and technologies. The company is redefining the worlds of TVs, smartphones, wearable devices, tablets, digital appliances, network systems, and memory, system LSI and LED solutions. For the latest news, please visit the Samsung Newsroom at news.samsung.com.

About Amazon Video

Amazon Video is a premium on-demand entertainment service that offers customers the greatest choice in what to watch, and how to watch it. Prime Video offers thousands of movies and TV shows, including popular licensed content plus critically-acclaimed and award-winning Amazon Original Series and Movies from Amazon Studios like Transparent, The Man in the High Castle, Love & Friendship and kids series Tumble Leaf, available for unlimited streaming as part of an Amazon Prime membership. Prime Video is also now available to customers in more than 200 countries and territories around the globe at www.primevideo.com.

[Jamaika]

Samsung and Amazon Video Deliver Next Generation HDR Video Experience With HDR10+
How write these colors HDR10+ and HDR10 in the commands for codec x265?

[LigH]

Relax and wait for new parameters in coming CLI builds... I already see proposed patches in the mailing list. But parameters are just half the fun; without matching video material, they don't fulfill a meaning.

[Midzuki]

x265.exe 2.3+40-2c6e6c9c3da7

http://www.mediafire.com/file/iymx3l6rjmyttv4/x265_2.3+40-2c6e6c9c3da7.7z

NOTICE:

[ 75%] Building CXX object encoder/CMakeFiles/encoder.dir/sei.cpp.obj
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp: In member function
'void x265::SEI::write(x265::Bitstream&, const x265::SPS&)':
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp:51:18:
warning: declaration of 'type' shadows a previous local [-Wshadow]
uint32_t type = m_payloadType;
^~~~
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp:41:14: note: shadowed declaration is here
uint32_t type = m_payloadType;
^~~~

[LigH]

I tried to enable Dynamic HDR10 routines for compilation with GCC 6.3.0, but C++11 compatibility is missing in the current CMake scripts. Release postponed...

[nevcairiel]

HDR10+ incorporates dynamic metadata that allows a high dynamic range (HDR) TV to adjust brightness levels on a scene-by-scene or even frame-by-frame basis. With the ability to display outstanding contrast with detailed highlights and a richer range of colors, HDR10+ produces images that are much closer to the director’s intent.

Is this an official HEVC standard, or a proprietary invention by Amazon and Samsung?
Any specifications about the SEI messages, their intepretation, and how to send them to a TV over HDMI (specifically, does this require HDMI 2.1)?

New tech is nice and all, knowing how to use it would be even nicer. :)

[cojj]

I'm getting file sizes that are 25~50% bigger with the new 10bit lamda table with an identical setting (mostly preset slower).

Is this expected?

[Boulder]

Yes, it's expected. Adjust your CRF accordingly to compensate; as they say, the perceptual quality should be improved at the same bitrate.

[aymanalz]

Has the 10 bit lambda table been incorporated into the latest build? If so, what build number?

[Midzuki]

I tried to enable Dynamic HDR10 routines for compilation with GCC 6.3.0, but C++11 compatibility is missing in the current CMake scripts. Release postponed...

Thanks for the clarification. I stopped reading x265's CMakeLists.txt ages ago... and its readme.rst is no replacement for a (still non-existent) What's-New.txt...
In other words, HDR10 support is disabled by default, and I would never notice that by myself.

Anyway, and FWIW:

make[2]: *** [dynamicHDR10/CMakeFiles/dynamicHDR10.dir/build.make:82: dynamicHDR10/CMakeFiles/dynamicHDR10.dir/json11/json11.cpp.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:147: dynamicHDR10/CMakeFiles/dynamicHDR10.dir/all] Error 2
make: *** [Makefile:117: all] Error 2
cp: cannot stat 'libx265.a': No such file or directory

[Barough]

x265 v2.3+41-6dc49dcff6da (http://www73.zippyshare.com/v/7dBI8NqO/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+41-6dc49dcff6da
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

[nevcairiel]

In other words, HDR10 support is disabled by default, and I would never notice that by myself.

Its only about HDR10+ (not ordinary HDR10), and its a brand new feature which clearly still has issues even building properly everywhere, so it might get enabled by default later.

[need4speed]

Dumb question on encoding 10bit:
Do I need to enable both depth10 AND profile main10?
Sorry but have tried to read all posts and a couple of white papers, this to improve banding and still it's not clear.
Thanks in advance!
So new 10bit table is active in latest builds (.40 and .41)?

[sneaker_ger]

Dumb question on encoding 10bit:
Do I need to enable both depth10 AND profile main10?
If you set output depth to 10 bit it will automatically choose main10 profile. If you have a build that's only compiled for 10 bit you don't have to set anything at all.
Just check the output in MediaInfo and look at the x265 log if you are not sure.

So new 10bit table is active in latest builds (.40 and .41)?
Yes, the new tables for 10 and 12 bit have arrived.

[LigH]

Regarding Dynamic HDR10: It is not enabled by default, but a CMake switch is available. I tried to enable this supporting switch. The resulting errors point at C++11 support not yet being enabled in the MSYS/GCC branch of the make scripts, possibly just forgotten when another preferred compiler of a developer supports it per default.

[x265_Project]

Its only about HDR10+ (not ordinary HDR10), and its a brand new feature which clearly still has issues even building properly everywhere, so it might get enabled by default later.

To get the HDR10+ capability to market more quickly, the developers used Standard Template Libraries. As you noticed, STLs may introduce compiler compatibility issues, so for now, compiling HDR10+ in x265 is off by default. We expect the HDR10+ code to be updated to avoid the use of STLs, so that it can be compiled in x265 by default.

[need4speed]

If you set output depth to 10 bit it will automatically choose main10 profile. If you have a build that's only compiled for 10 bit you don't have to set anything at all.
Just check the output in MediaInfo and look at the x265 log if you are not sure.


Yes, the new tables for 10 and 12 bit have arrived.
Thanks!
Was wondering about 10bits tables because my latest converted file has decreased in terms of size keeping the same crf. Have read it has happened the opposite so wondering how the story was.
Besides with regards of earlier 10bit encoded speed time latest versions seem to be a bit faster, around 2 fps increase in medium preset with some tweaks

Inviato dal mio GT-N7100 utilizzando Tapatalk

[x265_Project]

HDR10 is a static HDR system defined by SMPTE 2084 (Electro Optical Transfer Function, or EOTF) and SMPTE 2086 (HEVC metadata). By static, we mean that the EOTF (the curve that defines how to map color sample values in the HEVC bitstream to luminance levels on the display) is the same for the entire video. Static HDR works, but it isn't ideal because with only 10 bits (1024 values) to map a very wide range of luminance levels, colorists have to pick a single setting that works well on average for the whole title. This means that brighter than average scenes may have regions that are washed out, and darker than average scenes might have regions where it is hard to distinguish what is happening in the shadows.

HDR10+ is a dynamic HDR system defined by the SMPTE 2094-40 standard. It lets colorists adjust the EOTF on a scene-by-scene basis. There are 4 flavors of SMPTE 2094...
•2094-1 –the core definitions document
•2094-10 –[Dolby Vision] metadata for a tone mapping based on the source content characteristics and colorist adjustments.
•2094-20 –[Philips] metadata for a color transform based on a creatively set tone mapping curve and a luminance dependent saturation gain curve.
•2094-30 –[Technicolor] metadata for reference-based color volume remapping, derived from two grades of the same content.
•2094-40 –[Samsung HDR10+] metadata for tone mapping and color saturation based on mastering and target displays peak luminances and content characteristics.

x265's HDR10+ support was contributed by Samsung. It provides the capability to parse a JSON file containing metadata generated by Samsung's tone mapping software. Samsung is working with content creators, color grading software developers and content distributors to enable HDR10+ tone mapping (generating the JSON file).

If you want to know more about Dynamic HDR, I suggest ...
https://www.smpte.org/sites/default/files/2017-01-12-ST-2094-Borg-V2-Handout.pdf
http://www.ste-ca.org/images/STE_Presentation_Apil_2016.pdf
http://set6.tempsite.ws/eventos/palestras/matthew_goldman_set_expo_2016.pdf

[Ma]

Regarding Dynamic HDR10: It is not enabled by default, but a CMake switch is available. I tried to enable this supporting switch. The resulting errors point at C++11 support not yet being enabled in the MSYS/GCC branch of the make scripts, possibly just forgotten when another preferred compiler of a developer supports it per default.

If you change in source/CMakeLists.txt line 190 from
add_definitions(-std=gnu++98)
to
add_definitions(-std=gnu++11)
you can compile x265 with '-DENABLE_DYNAMIC_HDR10=ON'.

I don't know if it make sense only in 10-bit depth or in any bit depth.
Compiled 10-bit x265 with dhdr10 for Windows (64-bit and 32-bit):
www.msystem.waw.pl/x265/x265-10hdr.7z

[brumsky]

Thanks!
Was wondering about 10bits tables because my latest converted file has decreased in terms of size keeping the same crf. Have read it has happened the opposite so wondering how the story was.
Besides with regards of earlier 10bit encoded speed time latest versions seem to be a bit faster, around 2 fps increase in medium preset with some tweaks

Inviato dal mio GT-N7100 utilizzando Tapatalk

I've noticed an increase in speed as well. Much less but I think it is because I use modified placebo settings. Also, files initially seemed to be larger - 2000kbps ish increase.

[Midzuki]

If you change in source/CMakeLists.txt line 190 from
add_definitions(-std=gnu++98)
to
add_definitions(-std=gnu++11)
you can compile x265 with '-DENABLE_DYNAMIC_HDR10=ON'.

I don't know if it make sense only in 10-bit depth or in any bit depth.
Compiled 10-bit x265 with dhdr10 for Windows (64-bit and 32-bit):
www.msystem.waw.pl/x265/x265-10hdr.7z

Many thanks for the info :goodpost:
Now the thing gets compiled.
BUT still with tons of warnings ;)

FWIW: I disabled HDR10+ only for the 8-bit section in my new multilib building script.

[need4speed]

I've noticed an increase in speed as well. Much less but I think it is because I use modified placebo settings. Also, files initially seemed to be larger - 2000kbps ish increase.
Trying another session right now. Will get back but at the moment confirming the bitrate is lower than before, same everything

Inviato dal mio GT-N7100 utilizzando Tapatalk

[Midzuki]

Hmmm, commit 7f77e66 says:

compilation fix in dhdr10

However GCC 6.3.0 still returns TONS of warnings.
Also, CMakeLists.txt hasn't been fixed.

[x265_Project]

Unless you are encoding content that has been mastered with Samsung's tone mapping system, and you have the JSON file with the HDR metadata, you don't need to build x265 with this feature. You'll get errors if you're not using the same compiler that this feature was targeted to. I'll ask our development team to clarify which compilers are supported by this feature today.

[Midzuki]

Unless you are encoding content that has been mastered with Samsung's tone mapping system, and you have the JSON file with the HDR metadata, you don't need to build x265 with this feature. You'll get errors if you're not using the same compiler that this feature was targeted to. I'll ask our development team to clarify which compilers are supported by this feature today.

Actually, the warnings have nothing to do with the Dynamic HDR support. The quote below is only a tiny sample of what I am talking about.

............

NOTICE:

[ 75%] Building CXX object encoder/CMakeFiles/encoder.dir/sei.cpp.obj
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp: In member function
'void x265::SEI::write(x265::Bitstream&, const x265::SPS&)':
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp:51:18:
warning: declaration of 'type' shadows a previous local [-Wshadow]
uint32_t type = m_payloadType;
^~~~
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp:41:14: note: shadowed declaration is here
uint32_t type = m_payloadType;
^~~~

[x265_Project]

Actually, the warnings have nothing to do with the Dynamic HDR support. The quote below is only a tiny sample of what I am talking about.
Sorry Midzuki! There were a few messages about building x265 with Dynamic HDR turned on. I thought you were trying this also.

[benwaggoner]

Is this an official HEVC standard, or a proprietary invention by Amazon and Samsung?
Any specifications about the SEI messages, their intepretation, and how to send them to a TV over HDMI (specifically, does this require HDMI 2.1)?

New tech is nice and all, knowing how to use it would be even nicer. :)
It is SMPTE standard 2094-40.

Generating the metadata is pretty complex, and that's not in x265. Colorfront's Transkoder product can generate the data from a source file. x265 supports incorporating the metadata into an encoded HDR-10 HEVC bitstream.

[nevcairiel]

It is SMPTE standard 2094-40.

Generating the metadata is pretty complex, and that's not in x265. Colorfront's Transkoder product can generate the data from a source file. x265 supports incorporating the metadata into an encoded HDR-10 HEVC bitstream.

I'm not interested in generating the data, just consuming it to various degrees, possibly to transmit it to a TV through HDMI down the line, have to at least try to keep PCs able to use those new formats.
For transmission, thats apprently in CTA-861-G (ie. the HDMI 2.0/2.1 standard), perhaps some software features can be supported on older HDMI interfaces by firmware updates (like dynamic metadata).

[benwaggoner]

I'm not interested in generating the data, just consuming it to various degrees, possibly to transmit it to a TV through HDMI down the line, have to at least try to keep PCs able to use those new formats.
For transmission, thats apprently in CTA-861-G (ie. the HDMI 2.0/2.1 standard), perhaps some software features can be supported on older HDMI interfaces by firmware updates (like dynamic metadata).
I'm not sure exactly how transport over HDMI will work and with what requirements. So far all the demonstrations have been on devices with integrated screens.