[BUG] Hybrid/FFmpeg ProRes 4444 12 bit some problem

[Selur]

If i use ProRes444 12bit and check UseRGB, i got black screen preview. No problem with ProRes422 10bit.
I guess problem may be related to all plug-ins that have "UseRGB" option when used with ProRes 12bit and newest FFmpeg development version.

It's probably either a problem with the:
a. the YUV 4:4:4 16bit <> RGB48 conversion
or
b. a problem with the filter to use RGB48

Since:

# Imports
import vapoursynth as vs
# getting Vapoursynth core
core = vs.core
# Loading Plugins
core.std.LoadPlugin(path="I:/Hybrid/64bit/vsfilters/SourceFilter/LSmashSource/vslsmashsource.dll")
# source: 'G:\TestClips&Co\files\ProRes\Test Patterns Resolve 4444 12-bit.mov'
# current color space: YUV444P16, bit depth: 12, resolution: 720x576, fps: 25, color matrix: 709, yuv luminance scale: limited, scanorder: progressive
# Loading G:\TestClips&Co\files\ProRes\Test Patterns Resolve 4444 12-bit.mov using LibavSMASHSource
clip = core.lsmas.LibavSMASHSource(source="G:/TestClips&Co/files/ProRes/Test Patterns Resolve 4444 12-bit.mov")
# making sure input color matrix is set as 709
clip = core.resize.Point(clip, matrix_in_s="709",range_s="limited")
# making sure frame rate is set to 25
clip = core.std.AssumeFPS(clip=clip, fpsnum=25, fpsden=1)
# Setting color range to TV (limited) range.
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=1)
# adjusting color space from YUV444P16 to RGB48 for vsLevels
clip = core.resize.Bicubic(clip=clip, format=vs.RGB48, matrix_in_s="709", range_s="limited")
# Output
clip.set_output()

properly outputs RGB48, seems like it's a limitation or bug in levels.
-> I asked the Vapoursynth developers over at doom9, to figure out whether it's a bug/limitation in the filter or whether Hybrid is doing something wrong.

If source is ProRes 444 12 bit, ProRes 444 is still exported only as 10 bit instead of 12 bit. Or maybe processed as 10 bit and placed inside 12 bit container on render. Is this is an FFmpeg limitation or some bug in Hybrid?

No details there. The Vapoursynth scripts you showed both output YUV444P16.

Encoding without Vapoursynth:

ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -ignore_editlist true -i "G:\TestClips&Co\files\ProRes\Test Patterns Resolve 4444 12-bit.mov" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p12le -strict -1 -vsync 0 -f yuv4mpegpipe - | x265 --input - --output-depth 12 --y4m --profile main444-12 --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --crf 18.00 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --range limited --colormatrix bt709 --output "E:\Temp\2021-07-26@05_29_19_2410_01.265"

seems to feed 12bit to the encoder.

Looking at the output MediaInfo reports:

Writing library                          : x265 3.5+10-82786fccc:[Windows][GCC 10.3.0][64 bit] 10bit

looking at the output or 'x265 --help', it properly reports:

x265 [info]: HEVC encoder version 3.5+10-82786fccc
x265 [info]: build info [Windows][GCC 10.3.0][64 bit] 8bit+10bit+12bit

-> Strange, may be some one over at doom9 knows what's happening there.

Cu Selur