x265 HEVC Encoder

[Lucius Snow]

I can't split the video source file so I don't think running multiple instances would help :\

[Stereodude]

I can't split the video source file so I don't think running multiple instances would help :\
What file format is the video source? You don't have to split the source video file. You only have to split the encoding of the source video file.

By the way, you could just encode two different video source files at the same time.

[LazyNcoder]

Hey guys, any good and free tool to extract hdr10plus meta tags as json and re use it with x265?
I used quietvoid's hdr10plus_parser tool but it gives me error:
Reading parsed dynamic metadata... thread 'main' panicked at 'assertion failed: `(left == right)`
left: `10`,
right: `9`', src/hdr10plus.rs:324:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Tried it on several sources. Any other tool around here?

[quietvoid]

Hey guys, any good and free tool to extract hdr10plus meta tags as json and re use it with x265?
I used quietvoid's hdr10plus_parser tool but it gives me error:


Tried it on several sources. Any other tool around here?

Make sure to update to 0.2.7. If that doesn't work either, I'll need more info.

[LazyNcoder]

Make sure to update to 0.2.7. If that doesn't work either, I'll need more info.

Yes, tried it with 0.2.5 0.2.6 0.2.7 all was the same.
What info do you need? Let me know. I wanted to PM you about it but seems like it's not available.

[quietvoid]

Yes, tried it with 0.2.5 0.2.6 0.2.7 all was the same.
What info do you need? Let me know. I wanted to PM you about it but seems like it's not available.

I just need a sample (or title) of what you're trying to parse, it's hard to test everything. You can open an issue on Github or PM me here.

[LigH]

@Stereodude: I used to believe that the more threads are working on the same video, the smaller the scope of each thread gets, the less efficient the search for redundant areas will be, which will limit quality. Is that no concern for you?

[Stereodude]

@Stereodude: I used to believe that the more threads are working on the same video, the smaller the scope of each thread gets, the less efficient the search for redundant areas will be, which will limit quality. Is that no concern for you?
:confused: Why do you say that?

I've been using --pools 4 -F 1 for my encodes. Mostly because in prior testing I saw a noticeable quality improvement limiting the simultaneous frames to 1. I limit the pools to 4 mostly because when I set frames to 1 it only uses about 4 threads worth of CPU.

I'm going to retest if -F 1 is still necessary with the latest builds since it seems to have considerably image quality improvements that are leading me to rather different conclusions on my preferred settings vs. the last time I tested over a year ago. I find AQ2 w/ SAO left enabled has a very pleasing look now whereas I previously thought it was terrible. Maybe it's just me...

[fauxreaper]

With less frame-threads and no-wpp, the encode has better quality and uses less bitrate. In my tests, disabling wpp is more effective to quality and bitrate than decreasing frame-threads.

[Stereodude]

Where can I get another 64-bit Windows build of 3.3+1-f94b0d32737d? I already have a HolyWu build made with Clang 9.0.0 and want to compare a behavior I see to a different build of the same x265 version.

[Stereodude]

With less frame-threads and no-wpp, the encode has better quality and uses less bitrate. In my tests, disabling wpp is more effective to quality and bitrate than decreasing frame-threads.
I haven't tried no-wpp yet, but going from 4 frame threads to 1 frame thread makes a dramatic quality difference in my testing. I didn't pay much if any attention to the bitrate. I will give --no-wpp a try.

Edit: --no-wpp really reduces CPU usage and used alone increases the number of frame threads. Killing wpp and holding frame threads to 1 is really slow and uses very little CPU. Encodes would be so slow as to be totally impractical.

[Blue_MiSfit]

I found using 1 frame thread to be necessary to avoid macroblocking in certain edge cases (CBR encoding of 4K HDR content, namely)

[Stereodude]

I found using 1 frame thread to be necessary to avoid macroblocking in certain edge cases (CBR encoding of 4K HDR content, namely)
I've been encoding 1080p and 480p and find using 1 frame thread (vs. 4) and found it makes a big difference in the stability of flat areas vs. the source. 1 is nice and stable, 4 is "nervous" with considerably more noise that not in the source. This is using fairly low CRF's (16 for 1080p / 15.5 for 480p).

[LigH]

Where can I get another 64-bit Windows build of 3.3+1-f94b0d32737d? I already have a HolyWu build made with Clang 9.0.0 and want to compare a behavior I see to a different build of the same x265 version.

Using the media-autobuild suite (https://github.com/m-ab-s/media-autobuild_suite) you can compile them yourself, with either clang or GCC.

You may find binaries of the same source state, either with git hash (starting with a g) or with Mercurial hash, but they are equivalent even though hash and increment are not the same (Mercurial counts merges, git doesn't). I switched to git as soon as Multicoreware announced that Bitbucket will drop Mercurial support during this year.

x265 3.3+1-g396395b2b (http://www.mediafire.com/file/gtrc6wzf1gofi9o/x265_3.3%252B1-g396395b2b.7z/file) (GCC 9.2.0)

[Stereodude]

With less frame-threads and no-wpp, the encode has better quality and uses less bitrate. In my tests, disabling wpp is more effective to quality and bitrate than decreasing frame-threads.
So I tried --no-wpp and did not duplicate your finding on my test clip (first 14943 frames of Oblivion). On encodes that ended up at 400MB they were all within 650kB of each other. FWIW, the clip using -F 1 with wpp was the smallest of the permutations I tried.

Here are the common options I used for all 4 encodes:
--crf 16.0 -p veryslow --aq-strength 1.15 --vbv-maxrate 40000 --vbv-bufsize 40000 --level 5.1 --keyint 120 --open-gop -D 10 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1

On the visual quality I didn't find any improvement from turning wpp off. In contrast it was worse because the frame threads are >1. wpp on with 1 frame thread looked the best of them. wpp off with only 1 frame thread is so excruciatingly slow I would consider it totally unusable. It would have taken days to compress the test sample with those options so I did not run it.

Lastly, after reading up on wpp and how x265 makes the number of wpp rows I don't really see why it would noticeably degrade the image quality. Doesn't it select the number of rows based on the vertical resolution of the video max CU size? So if your CU can be as large as 64 pixels and your video is 1080 pixels tall it will do 17 rows which is basically 1080/64. What's the problem with that method?

[Stereodude]

Using the media-autobuild suite (https://github.com/m-ab-s/media-autobuild_suite) you can compile them yourself, with either clang or GCC.

You may find binaries of the same source state, either with git hash (starting with a g) or with Mercurial hash, but they are equivalent even though hash and increment are not the same (Mercurial counts merges, git doesn't). I switched to git as soon as Multicoreware announced that Bitbucket will drop Mercurial support during this year.

x265 3.3+1-g396395b2b (http://www.mediafire.com/file/gtrc6wzf1gofi9o/x265_3.3%252B1-g396395b2b.7z/file) (GCC 9.2.0)
Thanks. I found a [Windows][MSVC 1916][64 bit] build online of it that I'm testing now. I will try the one you linked next as another data point, but the test can take over 24 hours to run while I wait to see if I get and crashes.

[Boulder]

Does anyone have any sample clips of this big difference between -F 1 and 4? I just tested on a rather noisy clip and visibly they look the same. The average bitrate was almost the same as well, in fact F 2-4 all produced the same size. I think it could be different with clean clips as frame threads should affect references.

[Stereodude]

Does anyone have any sample clips of this big difference between -F 1 and 4? I just tested on a rather noisy clip and visibly they look the same. The average bitrate was almost the same as well, in fact F 2-4 all produced the same size. I think it could be different with clean clips as frame threads should affect references.
You want the source or the output? BTW, I've not found much difference in the resulting file size.

[Blue_MiSfit]

I don't have a sample I can share unfortunately.

I found explosive macroblocking for a few frames a time, and only very rarely (only on specific content and encoding settings).

[Boulder]

You want the source or the output? BTW, I've not found much difference in the resulting file size.

The output would be interesting to see in case I run into similar issues.

EDIT: And of course, it would be best if you could file a bug report for MultiCoreWare as this could also be a bug.

[LigH]

If you need common samples to compare, try Derf's collection at xiph.org (https://media.xiph.org/video/derf/), there is a variety of material (Y4M) with different kinds of codec annoyances.

My favorites: crowd_run / ducks_take_off / in_to_tree / park_joy / parkrun / pedestrian_area / riverbed / sintel_trailer

And if you need a longer playtime: the footage of "Tears of Steel" (https://media.xiph.org/tearsofsteel/)

[Lucius Snow]

What file format is the video source? You don't have to split the source video file. You only have to split the encoding of the source video file.

By the way, you could just encode two different video source files at the same time.
ProRes 4:2:2 HQ or 4:4:4:4 in UHD.

But I don't have two different files to encode at the same time. Only one, fast.

[Stereodude]

ProRes 4:2:2 HQ or 4:4:4:4 in UHD.

But I don't have two different files to encode at the same time. Only one, fast.
Are you using AVIsynth, or how are you getting the file into x265 to be encoded?

[Atak_Snajpera]

ProRes 4:2:2 HQ or 4:4:4:4 in UHD.

But I don't have two different files to encode at the same time. Only one, fast.

How about this?
https://i.postimg.cc/Vk7yzLZN/client.png
Spliting is fully automated. Just fire and forget.

[Lucius Snow]

I use the command line with ffmpeg / x265.

Interesting this RipBot64 thing. Never tried. I'll have a look. Thanks.

EDIT: Well, finally no, just the indexing process at startup takes too much time.

[Andouille]

How about this?
https://i.postimg.cc/Vk7yzLZN/client.png
Spliting is fully automated. Just fire and forget.


Distributed encoding/file spliting should NOT be used for 2pass/filesize target.(your pic seems to be)
Only for quality encoding.

[Blue_MiSfit]

To be fair, distributed multi-pass encoding is a thing.

It's hard to get right and there absolutely are trade-offs, but it can be done.

[Atak_Snajpera]

Distributed encoding/file spliting should NOT be used for 2pass/filesize target.(your pic seems to be)
Only for quality encoding.

I analyze stat file from first pass and then adjust bitrate for each chunk(more complex chunk gets higher bitrate while less complex gets lower). If you use large for example 10 min chunk then you do not have to worry about quality.

[Zebulon84]

Can (or could) RipBot do that automatically ?

[filler56789]

x265.exe 3.3+7-d769bc8e8cde

(x64, multilib, GCC 8.4.0)

Add aarch64 support - Part 1
This patch add some common assembly optimization function for aarch64 platform. These function won't work until the patch Part 2 is merged.

Add aarch64 support - Part 2
This patch adds aarch64 build & compile support. This patch must be merged after the Part 1.

Fix: segmentation fault for hist-scenecut option
fixes plane size calculation for chroma planes using source resolution and not padded resolution.

http://www.mediafire.com/file/2oj8wnp7k4t89dj/x265_3.3%252B7-d769bc8e8cde.rar/file

[Mzvasturbo]

Hi i changed some settings in x265 and for 4k HDR content i came very close to the slow preset quality with 2-3 times faster speed and around 30% smaller file.
here you can check the pictures. https://www.dropbox.com/sh/yabmid1mduiiibm/AAApMWJCziIeyNBMPUI5otsna?dl=0
CRF 17 hdr10-opt was used in both rips.

[filler56789]

x265.exe 3.3+12-00b686782ad0
(GCC 9.3.0, x64, multilib)

Latest changes:

1) Fix: clis in regression txt file.

1. corrects file naming convention.
2. updates deprecated rskip clis options.

2) zone: Enable strict VBV conformance for zone encode as per requirement

3) - Fixes mismatch in BufferRate with dynamic zone reconfiguration when bufferrate varies for each zone
- Logs UnclippedBufferFillFinal into csv when csvloglevel greater than 1

4) Add option to get global maxrate.

This global maxrate can be used for HRD signaling.

5) zone: Remove unnessary conditions on zone reconfig

This commit
- Removes unnessary conditions on zone reconfig
- Fixes crash with dynamic zone reconfig

http://www.mediafire.com/file/nm3997494f2nq9v/x265_3.3%252B12-00b686782ad0.rar/file

[jlpsvk]

Hi i changed some settings in x265 and for 4k HDR content i came very close to the slow preset quality with 2-3 times faster speed and around 30% smaller file.
here you can check the pictures. https://www.dropbox.com/sh/yabmid1mduiiibm/AAApMWJCziIeyNBMPUI5otsna?dl=0
CRF 17 hdr10-opt was used in both rips.
whats your command line???

[Mzvasturbo]

Other settings are from default medium preset this are the changed ones
--crf 17 --level-idc 5.1 --output-depth 10 --rdoq-level 2 --cu-lossless --aq-mode 4 --max-merge 3 --rc-lookahead 25 --lookahead-slices 4 --ref 4 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --range limited --max-cll "xxx,xxx" --hdr --hdr-opt --repeat-headers --hrd --aud --deblock -1:-1 --no-strong-intra-smoothing

[filler56789]

x265.exe 3.3+19-1d2f556

http://msystem.waw.pl/x265/

Changes after commit 00b6867:

https://bitbucket.org/multicoreware/x265/commits/all

[Barough]

x265 v3.3+17-gdf2ac512d (http://www.mediafire.com/file/q8q29en789g0heh/x265-3.3%252B17-gdf2ac512d_Win_GCC930.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.3.0)
https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[LazyNcoder]

x265.exe 3.3+19-1d2f556

http://msystem.waw.pl/x265/

Changes after commit 00b6867:

https://bitbucket.org/multicoreware/x265/commits/all

Tried the VS 2015/2019 AVX build and it gives me error:

x265 [info]: HEVC encoder version 3.3+19-1d2f556ffb12
x265 [info]: build info [Windows][MSVC 1900][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [error]: internalBitDepth must match compiled bit depth
x265 [error]: x265_encoder_open() failed for Enc,
x265 [error]: Failure generating stream headers 0
Error: fwrite() call failed when writing frame: 1, plane: 0, errno: 32
Output 34 frames in 24.73 seconds (1.37 fps)


x265 v3.3+17-gdf2ac512d (http://www.mediafire.com/file/q8q29en789g0heh/x265-3.3%252B17-gdf2ac512d_Win_GCC930.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.3.0)
https://bitbucket.org/multicoreware/x265_git/commits/branch/master

It's same with this one.
But it's OK with 3.3+10-g08d8

[Forteen88]

LazyNcoder, yeah, I had error in the program "Simple x264 Launcher v2" (set to 10-bit encode) with x265.exe from x265-3.3+19-1d2f556_gcc100-AVX2.7z, but when I instead used x265-10b.exe it worked fine!

With old x265-3.3+10 x265.exe worked in "Simple x264 Launcher v2".

[Patman]

Tried the VS 2015/2019 AVX build and it gives me error:

x265 [info]: HEVC encoder version 3.3+19-1d2f556ffb12
x265 [info]: build info [Windows][MSVC 1900][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [error]: internalBitDepth must match compiled bit depth
x265 [error]: x265_encoder_open() failed for Enc,
x265 [error]: Failure generating stream headers 0
Error: fwrite() call failed when writing frame: 1, plane: 0, errno: 32
Output 34 frames in 24.73 seconds (1.37 fps)



There is an error in the source code. I also compiled x265-3.3+17 and got the same error. I'll report it to the devs.

EDIT:

I compiled a x265-3.3+15 build and that version works. I would like to compile a x265-3.3+16 build and it's not possible. I've opened an issue (https://bitbucket.org/multicoreware/x265/issues/539/error-when-starting-encode ). I use the x265_git as source.

[benwaggoner]

Is there any documentation anywhere on this exciting new feature?

ABR-ladder settings
--abr-ladder <file> File containing config settings required for the generation of ABR-ladder

With scaling also added as a new feature, I presume the file would be a list of resolutions and bitrates at a minimum. But I don't see the syntax documented anywhere yet.

[Blue_MiSfit]

Interesting! They've had this kind of functionality in UHDKit for awhile (commercially productized x265 with lots of neat pro features) so maybe they're bringing some of the features into the open source world :)

Analysis re-use is a huge deal when implemented correctly (especially for UHD). I wonder if that's part of this!

[benwaggoner]

Interesting! They've had this kind of functionality in UHDKit for awhile (commercially productized x265 with lots of neat pro features) so maybe they're bringing some of the features into the open source world :)

Analysis re-use is a huge deal when implemented correctly (especially for UHD). I wonder if that's part of this!
Yeah, 2-3x speedups for a bitrate ladder are quite achievable via shared motion search and other analysis. Definite improvement in quality @ perf (although time to encode the single most complex output stream will be increased, typically).

[benwaggoner]

Silly me, there is help text in the code:

+.. option:: --abr-ladder <filename>
+ File containing the encoder configurations to generate ABR ladder.
+ The format of each line is:
+
+ **<encID:reuse-level:refID> <CLI>**
+
+ where, encID indicates the unique name given to the encode, refID indicates
+ the name of the encode from which analysis info has to be re-used ( set to 'nil'
+ if analysis reuse isn't preferred ), and reuse-level indicates the level ( :option:`--analysis-load-reuse-level`)
+ at which analysis info has to be reused.
+
+ A sample config file is available in `the downloads page <https://bitbucket.org/multicoreware/x265/downloads/Sample_ABR_ladder_config>`_
+
+ Default: Disabled ( Conventional single encode generation ). Experimental feature.
+
+ **CLI ONLY**

[benwaggoner]

And the sample config file.

Seems pretty straightforward. The "base" stream uses nil for the analysis file, and they chain from the previous one on up the ladder. It presumes a ladder of scaled sources.

A lot of cruft comes from using a .yuv file and needing to specify all the color space stuff for each line. Plus calculating PSNR and SSIM and saving those to a log file.

I'm not sure how the --scale-factor parameter is derived, but the rule seems to be 0 if the analysis file is the same resolution, otherwise 2.

Now that there is a scaling algorithm, an obvious extension would be to allow the scaling to take place within x265 so a single source can be used.

Also, it isn't clear at all if these would be encoded in parallel versus serially. I'm guessing serially as it doesn't say otherwise (in contrast to UHDKit, which can already do its own scaling and parallel encoding).

[360p:0:nil] --input 640x360_5994fps_8bit_420p.yuv --input-res 640x360 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 145 --ssim --psnr --csv 0.csv --csv-log-level 2 -o 0.hevc --cutree --scale-factor 0
[432p:1:360p] --input 768x432_5994fps_8bit_420p.yuv --input-res 768x432 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 300 --ssim --psnr --csv 1.csv --csv-log-level 2 -o 1.hevc --cutree --scale-factor 0
[540p1:1:432p] --input 960x540_5994fps_8bit_420p.yuv --input-res 960x540 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 600 --ssim --psnr --csv 2.csv --csv-log-level 2 -o 2.hevc --cutree --scale-factor 0
[540p2:10:540p1] --input 960x540_5994fps_8bit_420p.yuv --input-res 960x540 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 900 --ssim --psnr --csv 3.csv --csv-log-level 2 -o 3.hevc --cutree --scale-factor 0
[540p3:10:540p2] --input 960x540_5994fps_8bit_420p.yuv --input-res 960x540 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 1600 --ssim --psnr --csv 4.csv --csv-log-level 2 -o 4.hevc --cutree --scale-factor 0
[720p1:10:360p] --input 1280x720_5994fps_8bit_420p.yuv --input-res 1280x720 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 2400 --ssim --psnr --csv 5.csv --csv-log-level 2 -o 5.hevc --cutree --scale-factor 2
[720p2:10:720p1] --input 1280x720_5994fps_8bit_420p.yuv --input-res 1280x720 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 3400 --ssim --psnr --csv 6.csv --csv-log-level 2 -o 6.hevc --cutree --scale-factor 0
[1080p1:10:540p3] --input 1920x1080_5994fps_8bit_420p.yuv --input-res 1920x1080 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 4500 --ssim --psnr --csv 7.csv --csv-log-level 2 -o 7.hevc --cutree --scale-factor 2
[1080p2:10:1080p1] --input 1920x1080_5994fps_8bit_420p.yuv --input-res 1920x1080 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 5800 --ssim --psnr --csv 8.csv --csv-log-level 2 -o 8.hevc --cutree --scale-factor 0
[1440p:10:720p2] --input 2560x1440_5994fps_8bit_420p.yuv --input-res 2560x1440 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 8100 --ssim --psnr --csv 9.csv --csv-log-level 2 -o 9.hevc --cutree --scale-factor 2
[2160p1:10:1080p2] --input 3840x2160_5994fps_8bit_420p.yuv --input-res 3840x2160 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 11600 --ssim --psnr --csv 10.csv --csv-log-level 2 -o 10.hevc --cutree --scale-factor 2
[2160p2:10:2160p1] --input 3840x2160_5994fps_8bit_420p.yuv --input-res 3840x2160 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 16800 --ssim --psnr --csv 11.csv --csv-log-level 2 -o 11.hevc --cutree --scale-factor 0

[vpupkind]

And the sample config file.

Seems pretty straightforward. The "base" stream uses nil for the analysis file, and they chain from the previous one on up the ladder. It presumes a ladder of scaled sources.

A lot of cruft comes from using a .yuv file and needing to specify all the color space stuff for each line. Plus calculating PSNR and SSIM and saving those to a log file.

I'm not sure how the --scale-factor parameter is derived, but the rule seems to be 0 if the analysis file is the same resolution, otherwise 2.

Now that there is a scaling algorithm, an obvious extension would be to allow the scaling to take place within x265 so a single source can be used.

Also, it isn't clear at all if these would be encoded in parallel versus serially. I'm guessing serially as it doesn't say otherwise (in contrast to UHDKit, which can already do its own scaling and parallel encoding).
...

The analysis reuse done there depends on whether the analysis-save resolution is a power-of-two multiple of the analysis-load resolution. If the resolutions are same or power-of-two, things like motion vectors and RQT are used as predictors. If not, only frame types are reused in order to maintain IDR alignment in variable duration GOPs.

The older x265 implementation back in 2018 used to be serial (i.e., analysis-save encode had to complete before analysis-load encode starts). This version is closer to parallel -- you only need to finish a number of lower-resolution frames to start encoding at a higher resolution.

The older serial implementation gave us about 2.4x speedup on 4K predicted from 1080p vs "standalone" 4K. I don't have results on the new one yet.

[Blue_MiSfit]

Fascinating stuff! Thanks for sharing

[_kermit]

color primaries

I just re-encoded using this:
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)"

Now I noticed that the original file and the encoded one have different values in the primaries:

Original:
Mastering display color primaries : R: x=0.708000 y=0.292000, G: x=0.170000 y=0.797000, B: x=0.131000 y=0.046000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0001 cd/m2, max: 1000.0000 cd/m2

New:
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0001 cd/m2, max: 1000.0000 cd/m2

Does that mean anything or is this bad?

-roland

[filler56789]

I've opened an issue (https://bitbucket.org/multicoreware/x265/issues/539/error-when-starting-encode ). I use the x265_git as source.

And the problem hasn't been fixed yet :scared:

Just wondering how and why they (MCW) approve the commits without testing the commits...

[Patman]

And the problem hasn't been fixed yet :scared:

Just wondering how and why they (MCW) approve the commits without testing the commits...

I can't understand the logic ... Compiling till 3.3 + 15 works without problems and the exe-file works, but after adding abr options and encoder this error is present. So far no response to my issue report.

[jlpsvk]

color primaries

I just re-encoded using this:
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)"

Now I noticed that the original file and the encoded one have different values in the primaries:

Original:
Mastering display color primaries : R: x=0.708000 y=0.292000, G: x=0.170000 y=0.797000, B: x=0.131000 y=0.046000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0001 cd/m2, max: 1000.0000 cd/m2

New:
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0001 cd/m2, max: 1000.0000 cd/m2

Does that mean anything or is this bad?

-roland

yes... it is bad... you need to enter correct values to to source... read the x265 documentation...

--master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" are correct values for your source