download the new version for iphoneColorConsole 6.88

output 'pmode-sao-tskip-r1-test.hevc' -frames 3000 -y4m -įfmpeg.exe -i 'Script.avs' -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe vbv-bufsize 160000 -vbv-maxrate 160000 -aud -hdr10 -hdr10-opt -range limited -colorprim bt2020 -transfer smpte2084 -colormatrix bt2020nc 6 -aq-mode 2 -aq-strength 1.0 -ipratio 1.3 -pbratio 1.2 pmode -bframes 16 -qg-size 32 -frame-threads 4 -ref 6 -limit-refs 1 -merange 57 -no-amp -tskip -tskip-fast -limit-modes -no-open-gop -hrd Here were the commands ran, I just used one of my recent tests so I could do a comparisonĪvs2yuv.exe 'Script.avs' - | 'x265.exe' -D 10 -crf 10.5 -profile main10 -level-idc 5.1 -high-tier -preset placebo -input-depth 16 -cu-lossless

Here they are tonemapped for better comparison of the changes: Here's a comparison between the normal avs2yuv pipe I was using, and then your ffmpeg pipe from above: )įinally got around to trying this, after tracking down some 32-bit ffmpeg builds (the 64-bit builds try to load 64-bit AviSynth+ and 64-bit plugins, threw me for a loop momentarily)īut it's drastically altering the colors when running the same exact x265 commands So, the chroma location is wrong, hence the 'bleeding'.įfmpeg.exe -i 'AVS Script.avs' -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe -y4m -ditherįollowed by the rest of your x265 command line? This should solve the chroma bleeding problem. Your input is an AVS Script from what I see, which handles 4:2:0 Type 1 but not 4:2:0 Type2! Chroma bleeding is actually really weird, it shouldn't really happen and I think I know why it's happening to you!

Download the new version for iphoneColorConsole 6.88