x265 HEVC Encoder

[Loomes]

Could you test these 5 exe's and report back which works and which not?
I am afraid, none of the x265-xx.exe worked in my Windows 10 and crashed instantly. But I found something else: I tried to use directly the libx265 of ffmpeg by
ffmpeg-2018-04-18.exe -i source.mkv -c:v libx265 -x265-params crf=21 -preset slow -pix_fmt yuv420p10le -bsf hevc_mp4toannexb -f rawvideo target.h265
and it also crashed instantly. Then I changed this new ffmpeg-2018-04-18.exe for an older one ffmpeg-2018-03-24.exe and it worked. Then I ran again your x265-xx.exe files with the older ffmpeg-2018-03-24.exe but they all crashed again with
ffmpeg-2018-03-24.exe -i source.mkv -f yuv4mpegpipe - | x265-0.exe --preset slow --crf 21 --y4m - -o target.h265
Even more strange that ffmpeg-2018-04-18.exe works flawlessly on Windows 7 and so the x265-0.exe of your files does (it even claims to make use of AVX512 when it starts). All the other x265-0x.exe crashed immediately on Windows 7.

This is really weird. Let me know if I can provide you any more info of my system or do some more tests.

[Ma]

Thanks for the details. It is quite a riddle.
On Win7 everything is OK, x265-0 should work (all avx512 code is not active), x265-0x should crash.
On Win10 it is interesting -- in your 2 examples it is no '--asm avx512' option. It crashes without avx512 too?
Is something special with your Win10, for example it works in VirtualBox?

[Loomes]

On Win10 it is interesting -- in your 2 examples it is no '--asm avx512' option. It crashes without avx512 too?
Yes, I had --asm avx512 included in the first run and all crashed. Then I had the idea that it's about ffmpeg and let it run without the asm option but well, did not work either.

Is something special with your Win10, for example it works in VirtualBox?
No, not at all. It is Windows 10 Professional 64bit, nothing special about it as far as I know. The system drive has 14GB free space, the drive where x265, ffmpeg etc. is running with 80G free space. As I said, it works fine with the older ffmpeg version or older x265.exe.
Is it possible that there is something special about the 7820x CPU?

[Ma]

Is it possible that there is something special about the 7820x CPU?

It is possible that there are hardware problems -- easiest way to check this out is Prime95 https://www.mersenne.org/download/
If you run this app with button 'Just Stress Testing' it should find memory/CPU problems (in file 'results.txt' should be only [date] and XXX passed! entries).

There was some changes in ffmpeg, so you can test ffmpeg release 3.4.2 -- it should be different approach to thread synchronization.

There was some reports about x265 hangs with pipe input from ffmpeg but it is hard to reproduce -- maybe there is bug in x265 that is not fixed yet.

[Bhavnahari]

My settings then...

--crf 17 --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star
--max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info --no-deblock
--no-sao --no-strong-intra-smoothing --high-tier --refine-inter 3 --refine-intra 4

Of course, display settings are entered too... :)

Warning:
x265 [warning]: Intra refinement requires analysis load, analysis-reuse-level 10, scale factor. Disabling intra refine.
x265 [warning]: Inter refinement requires analysis load, analysis-reuse-level 10, scale factor. Disabling inter refine.

Can it be used with CRF? Or? Some parameters missing?


refine-inter and refine-intra features may be used with any rate control techniques including ABR, CRF and CQP. However, as indicated by the warnings, these features are enabled only for scaled save/load encodes. The "save" run will encode the content of resolution WxH (1920x1080, say) and generate an analysis.dat file. This analysis information is scaled up by the factor and used by the "load" run which works on the content of resolution 2Wx2H (3840x2160, say). Using the analysis information from a low-res encode to encode high-res content will impact the quality of the encode hence we try to minimize the repercussions by incorporating various intra and inter refinement strategies.

Your CLI should be:
HD encode : --crf 17 --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star
--max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier --analysis-save <filename> --analysis-reuse-level 10 --scale-factor 2

UHD encode: -crf 17 --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star
--max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier --analysis-load <filename> --analysis-reuse-level 10 --scale-factor 2 --refine-inter 3 --refine-intra 4

[jlpsvk]

refine-inter and refine-intra features may be used with any rate control techniques including ABR, CRF and CQP. However, as indicated by the warnings, these features are enabled only for scaled save/load encodes. The "save" run will encode the content of resolution WxH (1920x1080, say) and generate an analysis.dat file. This analysis information is scaled up by the factor and used by the "load" run which works on the content of resolution 2Wx2H (3840x2160, say). Using the analysis information from a low-res encode to encode high-res content will impact the quality of the encode hence we try to minimize the repercussions by incorporating various intra and inter refinement strategies.

Your CLI should be:
HD encode : --crf 17 --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star
--max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier --analysis-save <filename> --analysis-reuse-level 10 --scale-factor 2

UHD encode: -crf 17 --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star
--max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier --analysis-load <filename> --analysis-reuse-level 10 --scale-factor 2 --refine-inter 3 --refine-intra 4

Thanks!!! So it won't downscale and upscale video? Only stats? Right? :) So it's better for retain quality/details or not? :)

[Boulder]

When watching some x265 encoded content on my TV, I can see very, very thin greyish vertical lines in scenes that are almost or completely black. Is this due to slice boundaries?

[foxyshadis]

When watching some x265 encoded content on my TV, I can see very, very thin greyish vertical lines in scenes that are almost or completely black. Is this due to slice boundaries?

That'd more likely be tile boundaries. Definitely sounds like a decoder bug.

[Boulder]

(I did some more testing and I cannot see the strips if lookahead-slices was disabled (vertical resolution less than 720).) EDIT: tested with existing encodes - couldn't replicate this with the latest x265 using the same source.

This is how it looks on the TV and on my display, a snippet from the upper left corner (seriously exaggerated by getting the brightness real high):

https://imgur.com/a/gO45OYB

I recall seeing this also with x264 encoded videos. Different decoders have been used, on the computer it's the NVIDIA GPU and on the TV it's whatever is on Apple TV 4K - VideoToolBox I think.

EDIT: this older clip shows the thing at the start, turn up the brightness to see it: https://drive.google.com/open?id=1uibj4uJdaZAMf_Vvu8b7A0ob9nqtJKa2

[jlpsvk]

just an addition to x265 AVX-512 problems... :)

ASRock X299 OC Formula + i9-7940X + Win10 x64 ... no crashing... AVX512 working flawlessly. :)

Binary from here (compiled in VS2017):
http://msystem.waw.pl/x265/x265-2.7+340-aa91024_vs2017.7z

[Bhavnahari]

Thanks!!! So it won't downscale and upscale video? Only stats? Right? :) So it's better for retain quality/details or not? :)

The input video used to generate the analysis file(stats) in "save" encode must be the downscaled version of the video used to encode "load", x265 scales only the analysis data, not the input video.

The refinement techniques are to improve the speed of the encode with similar quality when compared to encoding the high-res video without any prior analysis information. Among the different refinement levels, --refine-inter 3 --refine-intra 4 gives the best quality retention.

[Loomes]

ASRock X299 OC Formula + i9-7940X + Win10 x64 ... no crashing... AVX512 working flawlessly. :)
Good for you ;P
What is your command line? Are you using ffmpeg?

[jlpsvk]

Good for you ;P
What is your command line? Are you using ffmpeg?

No... x265 ... 5 instances at once (RipBot264 Distr. encoding) to penetrate all cores at 100%. :)

My current command line:
--profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star
--max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info
--no-deblock --no-sao --no-strong-intra-smoothing --high-tier --asm avx512

[LigH]

No... x265 ... 5 instances at once (RipBot264 Distr. encoding) to penetrate all cores at 100%. :)

This requires a powerful fan ... :cool:

https://technabob.com/blog/wp-content/uploads/2009/04/computer-fan-1.jpg

[jlpsvk]

This requires a powerful fan ... :cool:

Nope... Noctua NH-D15 keeping it at 63 degrees. :)

[Loomes]

Nope... Noctua NH-D15 keeping it at 63 degrees. :)
That's great but what is your frequency and your AVX offset? Because that's what makes the heat.

[jlpsvk]

That's great but what is your frequency and your AVX offset? Because that's what makes the heat.

All 14 cores running at 3.7GHz (instead of 3.1 stock).

[RieGo]

All 14 cores running at 3.7GHz (instead of 3.1 stock).

so no AVX512 offset?

i got really weird results while using avx512 and x265:
A) temps don't really go much higher while using avx512, at least on my system
B) AVX512 offset almost doesn't make a difference. i had same performance on 12x 100MHz difference in offset

[Asmodian]

Are you sure you are using AVX-512 and not bottlenecked by something else? I could notice even 2x offset (200 MHz), not hugely significant but a reproducible decrease in performance. Temperatures weren't much, if any, higher for me, running AVX2 or AVX512.

If you use something like hwinfo do you notice any cores running at the offset multiplier?

[Ma]

Are you using ffmpeg?

In case that the bug is in ffmpeg instead of x265, you can test ffmpeg binaries compiled by VS2015 -- ffmpeg-20180424.7z (http://msystem.waw.pl/x265/ffmpeg-20180424.7z) (without any libs, only for decoding video). I've added also ffmpeg compiled by GCC 7 and GCC 8 with only '-O2' optimize option instead of default '-O3 -fno-tree-vectorize'.

In my Win10/i7 8700 all 3 ffmpeg binaries works (and current Zeranoe builds also works).

[Loomes]

In case that the bug is in ffmpeg instead of x265, you can test ffmpeg binaries compiled by VS2015 -- ffmpeg-20180424.7z (http://msystem.waw.pl/x265/ffmpeg-20180424.7z) (without any libs, only for decoding video). I've added also ffmpeg compiled by GCC 7 and GCC 8 with only '-O2' optimize option instead of default '-O3 -fno-tree-vectorize'
Thanks a lot, I will do some more tests at the weekend. I have a feeling that it's not x265 or ffmpeg but that there's something wrong with my system. At least my Win10 install is rather fresh, almost vanilla and from an ISO directly downloaded from the Microsoft site. Well, I'll find out!

[sdml]

Am I correct that all *-refine-* features useful only for multi-pass scenarios?

[microchip8]

Am I correct that all *-refine-* features useful only for multi-pass scenarios?

rd-refine works in crf too

[Boulder]

I'm a bit confused as Bhavnahari stated that "refine-inter and refine-intra features may be used with any rate control techniques including ABR, CRF and CQP". Why would you do a 2-step encode in CRF mode to utilize the refining? Shouldn't a normal CRF encode already bring all the quality you can get from your settings with the least amount of time spent on encoding or analysing?

[Asmodian]

I believe the point is to do much of the analysis on a lower resolution video, then reuse that analysis with the higher resolution while still doing some refinement to fine tune the analysis for the full resolution. This gives a speed boost while also not lowering the quality too much, like simply using the analysis done on the low resolution video directly would.

I am not sure I would do this, but then I tend to run far up the quality/speed curve, e.g. preset veryslow with a few extra options that slow it down even more. It would be interesting to see the speed and quality impacts from using this method compared to slower or faster presets and/or other options.

[WhatZit]

I believe the point is to do much of the analysis on a lower resolution video, then reuse that analysis with the higher resolution while still doing some refinement to fine tune the analysis for the full resolution.

Basically correct. The idea is to "Analyse once, encode many".

Many of the recent CLI functions added to x265 are there to suit the demands of professional broadcast/OTT content providers, who may wish to create multiple resolution and bitrate copies of any one source.

The practical consumer application of this particular "reuse" functionality would be very niche.

[jlpsvk]

so no AVX512 offset?

i got really weird results while using avx512 and x265:
A) temps don't really go much higher while using avx512, at least on my system
B) AVX512 offset almost doesn't make a difference. i had same performance on 12x 100MHz difference in offset

probably Intel is OC-ing itself as it has good thermal conditions. :) temps with AVX-512 are bit lower in fact on my system. :)

[jlpsvk]

x265 crashing on "2nd pass"... (--profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star --max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier --analysis-load c:\stats.dat --analysis-reuse-level 10 --scale-factor 2 --refine-inter 3 --refine-intra 4 --asm avx512)

x265 [warning]: specified frame type (5) at 2091 is not compatible with keyframe interval

any suggestion? :(

[Selur]

wild guess: still got free space on c: ? (iirc analysis files etc can get really large)

[LigH]

And: Write access rights in the root of C:? Better use a secondary drive for video processing.

[jlpsvk]

wild guess: still got free space on c: ? (iirc analysis files etc can get really large)

yeah... 600GB free on C: SSD. :) It's happening in the second phase, READ, when the stats are reading... :) First, 1080p encode, with writing stats is OK. :(

Stats file 27GB big. :)

[LigH]

Well, it's not completely impossible that encoding in AVX-512 mode might create a different output. But probably hard to confirm...

[jlpsvk]

Well, it's not completely impossible that encoding in AVX-512 mode might create a different output. But probably hard to confirm...

first phase was created using AVX-512 too... tried READ phase without it, result is the same. Probably will try to use first without also. :(

[divxmaster]

As a follow up to my post a few months ago re spectre/meltdown patching and its influence on x265 encoding fps,
(where I found on my skylake quad it made virtually no difference),
I have now test my haswell system (4770k) with the microsoft microcode updates release two days ago (KB4091663 for 1703 I am running).

The latest KB patches the microcode for spectre variant two (branch target injection), at boot time only. GRC's Inspectre shows my system is now fully patched.
This latest KB DOES affect throughput fps. I have seen a drop of about 2.5%. Not a big deal luckily. I will just adjust my conservative OC
from 4.1ghz to 4.2ghz. (which is +2.5%).

Cheers,
Divxmaster

[jlpsvk]

first phase was created using AVX-512 too... tried READ phase without it, result is the same. Probably will try to use first without also. :(

So... stats write encode (I am not writing here mastering display, options), spline36 downsized from 3840x1600 to 1920x800:
--crf 17 --keyint 240 --min-keyint 24 --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star --max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier --analysis-save c:\stats.dat --analysis-reuse-level 10 --scale-factor 2 --no-cutree

Stats read encode at full 3840x1600:
--crf 17 --keyint 240 --min-keyint 24 --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star --max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier --analysis-load c:\stats.dat --analysis-reuse-level 10 --scale-factor 2 --refine-inter 3 --refine-intra 4 --no-cutree

With or withou AVX-512, result is the same. :(

[LigH]

x265 2.7+346-69aafa6d70ad (https://www.mediafire.com/file/lh0hdw3w5y3tx8f/x265_2.7%2B346-69aafa6d70ad.7z) (stable merge)

AVX-512 cleanups and a few nits (getting a RC soon?)

[pradeeprama]

As a follow up to my post a few months ago re spectre/meltdown patching and its influence on x265 encoding fps,
(where I found on my skylake quad it made virtually no difference),
I have now test my haswell system (4770k) with the microsoft microcode updates release two days ago (KB4091663 for 1703 I am running).

The latest KB patches the microcode for spectre variant two (branch target injection), at boot time only. GRC's Inspectre shows my system is now fully patched.
This latest KB DOES affect throughput fps. I have seen a drop of about 2.5%. Not a big deal luckily. I will just adjust my conservative OC
from 4.1ghz to 4.2ghz. (which is +2.5%).

Cheers,
Divxmaster

Thanks for that. I typically classify any performance difference under 5% (in either direction) as noise when measured on a real system... so I suppose it is fair to say that Specrte and Meltdown don't affect us. This is not surprising as we barely make syscalls that require escalated privileges, which is where these bugs kick-in and safe guard!

[pradeeprama]

So... stats write encode (I am not writing here mastering display, options), spline36 downsized from 3840x1600 to 1920x800:
--crf 17 --keyint 240 --min-keyint 24 --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star --max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier --analysis-save c:\stats.dat --analysis-reuse-level 10 --scale-factor 2 --no-cutree

Stats read encode at full 3840x1600:
--crf 17 --keyint 240 --min-keyint 24 --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star --max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier --analysis-load c:\stats.dat --analysis-reuse-level 10 --scale-factor 2 --refine-inter 3 --refine-intra 4 --no-cutree

With or withou AVX-512, result is the same. :(

What CPU are you using?

[jlpsvk]

What CPU are you using?

Core i9-7940X

[Barough]

x265 v2.7+348-0968a46d6ba4 (http://www.mediafire.com/file/bw8wawdyapz7uit/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[LigH]

x265 2.7+348-0968a46d6ba4 (https://www.mediafire.com/file/x3pkf15m8h5zl1f/x265_2.7%2B348-0968a46d6ba4.7z)

fixes a build error on Mac and a calculation bug in scalefactor 0

[Selur]

Does anyone see where my mistake is?

I'm trying to convert a 8bit pc range clip to 10bit x265 using:
ffmpeg -y -threads 8 -i "C:\Users\Selur\Desktop\Color Range Test.MOV" -map 0:0 -an -sn -vsync 0 -strict -1 -pix_fmt yuv420p10le -f yuv4mpegpipe - | x265 --input - --output-depth 10 --y4m --profile main10 --no-open-gop --crf 18.00 --range full --colormatrix bt470bg --output "H:\Temp\x265.265"
Problem is the output histogram is compressed, see: https://s14.postimg.cc/pq865qnfj/compare.png
Uploaded the source to my google drive as Color Range Test.MOV (https://drive.google.com/drive/folders/0B_WxUS1XGCPASUZibG5XZkRfeTg?usp=sharing).

for the comparision I used:
# Imports
import vapoursynth as vs
core = vs.get_core()
# Loading Plugins
core.std.LoadPlugin(path="G:/Hybrid/64bit/vsfilters/SourceFilter/LSmashSource/vslsmashsource.dll")


# Loading H:\Output\Color Range Test.MOV using LibavSMASHSource
clip = core.lsmas.LibavSMASHSource(source="H:/Output/Color Range Test.MOV")
# making sure input color matrix is set as 470bg
clip = core.resize.Point(clip, matrix_in_s="470bg")
# making sure frame rate is set to 30000/1001
clip = core.std.AssumeFPS(clip, fpsnum=30000, fpsden=1001)
# Making sure input color range is set to PC (full) range.
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=0)
clip = core.text.Text(clip=clip, text="Original")
clip = core.hist.Levels(clip=clip)

clip2 = core.lsmas.LWLibavSource(source="H:/Temp/x265.265", format="YUV420P10", cache=0)
# making sure input color matrix is set as 470bg
clip2 = core.resize.Point(clip2, matrix_in_s="470bg")
# making sure frame rate is set to 30000/1001
clip2 = core.std.AssumeFPS(clip2, fpsnum=30000, fpsden=1001)
# Making sure input color range is set to PC (full) range.
clip2 = core.std.SetFrameProp(clip=clip2, prop="_ColorRange", intval=0)
clip2 = core.text.Text(clip=clip2, text="x265")
# adjusting output color from: YUV420P8 to YUV420P10
clip2 = core.resize.Bicubic(clip=clip2, format=vs.YUV420P8)
clip2 = core.hist.Levels(clip=clip2)


clip = core.std.StackHorizontal([clip, clip2])
# Output
clip.set_output()

My guess is that I need to change the ffmpeg call, but I don't see where.

Cu Selur

Ps.: Adding '-color_range 2' to the ffmpeg call doesn't help either.

[sneaker_ger]

As you say this has nothing to do with x265.

You could try to "trick" ffmpeg by pretending the input was limited range.
-vf zscale=rangein=limited:range=limited -pix_fmt yuv420p10le

Maybe someone with more ffmpeg knowledge knows a "proper" solution ...

[Selur]

As you say this has nothing to do with x265.
That is what I guessed, not sure whether ffmpeg does something wrong or x265 has some problem with y4m output or ffmpeg.

You could try to "trick" ffmpeg by pretending the input was limited range.
-vf zscale=rangein=limited:range=limited -pix_fmt yuv420p10le
That still changes the luma histogram. (https://s31.postimg.cc/tnpvy7cq3/compare2.png)
using:
-vf zscale=rangein=full:range=full
is better, but there are still some changes. (https://s31.postimg.cc/9hmdzaehn/compare3.png)

Maybe someone with more ffmpeg knowledge knows a "proper" solution ...
I hope so. :)

Cu Selur

[poisondeathray]

maybe there is a bug with full range ?

waveform/histograms only match if you use lossless (even compared to low crf like --crf 8, where you 'd only expect tiny differences) , regardless if you use vapoursynth input or ffmpeg scaling with rawvideo pipe

crf8 - waveform is compressed

ffmpeg -i "Color Range Test.MOV" -vf scale=iw:ih:in_range=pc:out_range=pc,format=yuv420p10le -f rawvideo - | x265_10bit.exe --fps 30000/1001 --input-res 1280x720 --input-depth 10 --output-depth 10 --input-csp i420 --crf 8.00 --range full --colormatrix smpte170m -o rawpipe_x265crf8.265 -


--lossless works with ffmpeg rawvideo pipe

ffmpeg -i "Color Range Test.MOV" -vf scale=iw:ih:in_range=pc:out_range=pc,format=yuv420p10le -f rawvideo - | x265_10bit.exe --fps 30000/1001 --input-res 1280x720 --input-depth 10 --output-depth 10 --input-csp i420 --lossless --range full --colormatrix smpte170m -o rawpipe_x265lossless.265 -



vspipe y4m --crf 8 waveform is compressed

vspipe --y4m 1.vpy - | x265_10bit.exe --y4m --crf 8.00 --colormatrix smpte170m --range full -o vs_x265.265 -



vspipe y4m --lossless waveform is ok

vspipe --y4m 1.vpy - | x265_10bit.exe --y4m --lossless --colormatrix smpte170m --range full -o vs_x265_lossless.265 -


vpy input

clip = core.lsmas.LibavSMASHSource(r'F:\Color Range Test.MOV')
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P10)
clip.set_output()

[Selur]

waveform/histograms only match if you use lossless (even compared to low crf like --crf 8, where you 'd only expect tiny differences) , regardless if you use vapoursynth input or ffmpeg scaling with rawvideo pipe
I understand some small changes like when using '-vf zscale=rangein=full:range=full' and my lines from above might be a side effect of the video compression, but the compression of the histogram really looks like either a bug in x265 or all the other tools.

Cu Selur

[Ma]

I'm trying to convert a 8bit pc range clip to 10bit x265 using:
ffmpeg [...] -f yuv4mpegpipe - | x265 [...]

yuv4mpegpipe is for limited range only. Please use raw video for full range.

[poisondeathray]

I understand some small changes like when using '-vf zscale=rangein=full:range=full' and my lines from above might be a side effect of the video compression, but the compression of the histogram really looks like either a bug in x265 or all the other tools.



I agree . That's why I used crf 8, you'd expect only tiny tiny difference, not that large. It looks like CbCr are affected too

It affects x264 too . vs rawpipe too instead of y4m for fun

vspipe 1.vpy - | x264_10bit --demuxer raw --input-csp i420 --input-depth 10 --input-res 1280x720 --fps 30000/1001 --crf 8.00 --colormatrix smpte170m --input-range pc --range pc -o vs_raw_x264.264 -


But if it was a toolchain problem, you'd expect lossless to exhibit the same problem

Something is up...

[jlpsvk]

ok. x265 devs. what is the command line to output uhd bd compliant stream?

[Jamaika]

yuv4mpegpipe is for limited range only. Please use raw video for full range.
Never heard about it. A few threads further users advise against the use of rawvideo.

I test conveters:
ffmpeg_080518.exe -i "Color Range Test.MOV" -f yuv4mpegpipe -vf scale=1280:720:in_color_matrix=470bg:in_range=full:out_color_matrix=470bg:out_range=full,format=yuv420p10,lutyuv=val:val:val -strict -1 - |
x264-10bit.exe --demuxer y4m --muxer mp4 --input-csp i420 --input-depth 10 --input-range pc --output-csp i420 --threads 4 --preset veryslow --tune grain --crf 28 --fps 29.970 --keyint 60 --nal-hrd none
--colormatrix bt470bg --colorprim bt709 --transfer bt709 --range pc
--output "x264_420p10le_crf28_1.mp4" -
x264-10bit_2851.exe --muxer mp4 --input-csp i420 --input-depth 8 --input-range pc --output-csp i420 --threads 4 --preset veryslow --tune grain --crf 28 --fps 29.970 --keyint 60 --nal-hrd none
--colormatrix bt470bg --colorprim bt709 --transfer bt709 --range pc
--output "x264_420p10le_crf28_2.mp4" "Color Range Test.MOV"
bpgenc_0.9.8.exe -v -b 10 -f 420 -c ycbcr_bt709 -e x265 -m 9 -q 28 -o x265_420p10le_crf28.bpg rgba.png

Result of the test:
1)bad range,
2)bad range, no latest version 10bit 2901 (2018),
3)good.

Conclusion:
For me, the problem is in BT470bg.