Closed Chipcraft closed 2 months ago
The phenomenon appears to be hardware agnostic, the same effect occurs when the Vulkan filter device is AMD Hawk Point instead of Intel DG2.
[libplacebo @ 0000022e5adba3c0] Initialized libplacebo v6.338.0-64-g34e019bf (API v342)
[graph 0 input from stream 0:0 @ 0000022e75c54ec0] w:3840 h:2160 pixfmt:yuv420p10le tb:1/1200000 fr:24000/1001 sar:1/1 csp:bt2020nc range:tv
[libplacebo @ 0000022e5adba3c0] Imported vulkan device properties:
[libplacebo @ 0000022e5adba3c0] Device Name: Radeon 7
[libplacebo @ 0000022e5adba3c0] Device ID: 1002:15bf
[libplacebo @ 0000022e5adba3c0] Device UUID: 00:00:00:00:0D:00:00:00:00:00:00:00:00:00:00:00
[libplacebo @ 0000022e5adba3c0] Driver version: 80011b
[libplacebo @ 0000022e5adba3c0] API version: 1.3.262
[libplacebo @ 0000022e5adba3c0] Restricting API version to 1.3.0... new version 1.3.0
[libplacebo @ 0000022e5adba3c0] Memory heaps supported by device:
[libplacebo @ 0000022e5adba3c0] 0: flags 0x3 size 256M
[libplacebo @ 0000022e5adba3c0] 1: flags 0x0 size 15G
[libplacebo @ 0000022e5adba3c0] 2: flags 0x3 size 256M
[libplacebo @ 0000022e5adba3c0] Memory summary: 0 used 0 res 0 alloc, efficiency 100.00%, utilization 100.00%, max page: 64M
[libplacebo @ 0000022e5adba3c0] shaderc SPIR-V version 1.6 rev 1
[libplacebo @ 0000022e5adba3c0] Initialized SPIR-V compiler 'shaderc'
[libplacebo @ 0000022e5adba3c0] GPU information:
[libplacebo @ 0000022e5adba3c0] GLSL version: 450 (vulkan)
[libplacebo @ 0000022e5adba3c0] max_shmem_size: 32768
[libplacebo @ 0000022e5adba3c0] max_group_threads: 1024
[libplacebo @ 0000022e5adba3c0] max_group_size[0]: 1024
[libplacebo @ 0000022e5adba3c0] max_group_size[1]: 1024
[libplacebo @ 0000022e5adba3c0] max_group_size[2]: 1024
[libplacebo @ 0000022e5adba3c0] subgroup_size: 64
[libplacebo @ 0000022e5adba3c0] min_gather_offset: -32
[libplacebo @ 0000022e5adba3c0] max_gather_offset: 31
[libplacebo @ 0000022e5adba3c0] Limits:
[libplacebo @ 0000022e5adba3c0] thread_safe: 1
[libplacebo @ 0000022e5adba3c0] callbacks: 1
[libplacebo @ 0000022e5adba3c0] max_buf_size: 16438525952
[libplacebo @ 0000022e5adba3c0] max_ubo_size: 4294967295
[libplacebo @ 0000022e5adba3c0] max_ssbo_size: 4294967295
[libplacebo @ 0000022e5adba3c0] max_vbo_size: 268435456
[libplacebo @ 0000022e5adba3c0] max_mapped_size: 16438525952
[libplacebo @ 0000022e5adba3c0] max_buffer_texels: 4294967295
[libplacebo @ 0000022e5adba3c0] align_host_ptr: 4096
[libplacebo @ 0000022e5adba3c0] host_cached: 1
[libplacebo @ 0000022e5adba3c0] max_tex_1d_dim: 16384
[libplacebo @ 0000022e5adba3c0] max_tex_2d_dim: 16384
[libplacebo @ 0000022e5adba3c0] max_tex_3d_dim: 8192
[libplacebo @ 0000022e5adba3c0] blittable_1d_3d: 1
[libplacebo @ 0000022e5adba3c0] buf_transfer: 1
[libplacebo @ 0000022e5adba3c0] align_tex_xfer_pitch: 1
[libplacebo @ 0000022e5adba3c0] align_tex_xfer_offset: 4
[libplacebo @ 0000022e5adba3c0] max_variable_comps: 0
[libplacebo @ 0000022e5adba3c0] max_constants: 18446744073709551615
[libplacebo @ 0000022e5adba3c0] max_pushc_size: 128
[libplacebo @ 0000022e5adba3c0] align_vertex_stride: 1
[libplacebo @ 0000022e5adba3c0] max_dispatch[0]: 4294967295
[libplacebo @ 0000022e5adba3c0] max_dispatch[1]: 65535
[libplacebo @ 0000022e5adba3c0] max_dispatch[2]: 65535
[libplacebo @ 0000022e5adba3c0] fragment_queues: 1
[libplacebo @ 0000022e5adba3c0] compute_queues: 2
[libplacebo @ 0000022e5adba3c0] External API interop:
[libplacebo @ 0000022e5adba3c0] UUID: 00:00:00:00:0D:00:00:00:00:00:00:00:00:00:00:00
[libplacebo @ 0000022e5adba3c0] PCI: 0000:0d:00:0
[libplacebo @ 0000022e5adba3c0] buf export caps: 0x6
[libplacebo @ 0000022e5adba3c0] buf import caps: 0x16
[libplacebo @ 0000022e5adba3c0] tex export caps: 0x6
[libplacebo @ 0000022e5adba3c0] tex import caps: 0x16
[libplacebo @ 0000022e5adba3c0] sync export caps: 0x6
[libplacebo @ 0000022e5adba3c0] sync import caps: 0x0
[libplacebo @ 0000022e5adba3c0] Spent 11.836 ms allocating slab
[libplacebo @ 0000022e5adba3c0] Spent 72.801 ms translating SPIR-V
[libplacebo @ 0000022e5adba3c0] Spent 31.582 ms allocating slab
[libplacebo @ 0000022e5adba3c0] Spent 41.416 ms translating SPIR-V
[libplacebo @ 0000022e5adba3c0] Spent 10.844 ms generating shader LUT
[libplacebo @ 0000022e5adba3c0] Dithering to 10 bit depth
Does it happen for e.g. yuv420p
, or just the 10-bit formats?
Need to verify it using other samples however, it does not seem to affect 420P or even the 420P10 as long as it is SDR content (bt. 709).
After testing on a different source, there is definitely a difference with 420P input as well.
Placebo (Crop):
https://www.nle-chipcraft.com/Git/CobraPLC.png
LAV (Crop):
can you show me where the ycbcr -> RGB conversation code is there are already 3 colorspace i found and none had them in them AFAIK.
mpdn had a similar issue and i want to check a number.
Sorry, I'm still trying to get around to this; I should have the time later this week.
You can find the colormatrix generation code here: https://github.com/haasn/libplacebo/blob/master/src/colorspace.c#L1412
With test cases here: https://github.com/haasn/libplacebo/blob/master/src/tests/colorspace.c
Probably the simplest place to start would be to add more unit tests with hard-coded reference matrices, e.g. https://github.com/haasn/libplacebo/blob/master/src/tests/colorspace.c#L201
But, I highly suspect that the actual color matrices are correct, and the issue comes from someplace else.
It would be easier also if you could reproduce the problem on a static test pattern with known YCbCr values, such as smptebars
https://forum.doom9.org/showthread.php?p=1713449#post1713449 https://github.com/haasn/libplacebo/blob/master/src/colorspace.c#L1514C9-L1514C35 line 1514 cmid = 128 / 256. * scale; if this is about this according to the paper at hand it should be 255 this is to high for me if this even references to that. the other scale stuff is the usual 8 int mx 10 int max and 12 int max not 100000000.
i grab a ire test pattern later. the one i created on the fast has a general tint. well what ever maybe i'm lucky.
scale = (1LL << bit_depth) / ((1LL << bit_depth) - 1.0)
cmid = 128 / 256. * scale
So for 8-bit we have:
scale = 256 / 255
cmid = 128 / 256 * scale
= 128 / 256 * 256 / 255
= 128 / 255
Edit: Nvm, I see; the issue is about 128 vs 127.5? But that is clearly not the case here, as we use 128, not 127.5.
Furthermore, vo_gpu
uses the exact same color matrices, so it shouldn't be a source of differences between vo_gpu
and vo_gpu_next
don't waste your time to explain yourself to me. i just remember someone very competent had a similar issue.
There seems to be a physical difference with the two pictures.
Used the minimum crop of 2 pix. to ensure that a crop of zero won't be optimized into a NOP.
LAV:
ffmpeg -init_hw_device vulkan -f lavfi -i smptebars=size=3840x2160 -vf crop=3840:2158:0:1 -frames:v 1 -pix_fmt rgb48be -compression_level 9 smpte-lav.png
ffmpeg -init_hw_device vulkan -f lavfi -i smptehdbars=size=3840x2160 -vf crop=3840:2158:0:1 -frames:v 1 -pix_fmt rgb48be -compression_level 9 smptehd-lav.png
Placebo:
ffmpeg -init_hw_device vulkan -f lavfi -i smptebars=size=3840x2160 -vf libplacebo=crop_w=3840:crop_h=2158:crop_x=0:crop_y=1:w=3840:h=2158 -frames:v 1 -pix_fmt rgb48be -compression_level 9 smpte-plc.png
ffmpeg -init_hw_device vulkan -f lavfi -i smptehdbars=size=3840x2160 -vf libplacebo=crop_w=3840:crop_h=2158:crop_x=0:crop_y=1:w=3840:h=2158 -frames:v 1 -pix_fmt rgb48be -compression_level 9 smptehd-plc.png
My own testing:
ffmpeg -sws_flags +accurate_rnd+bitexact -f lavfi -i smptebars -vframes 1 -pix_fmt rgb48be smptebars-swscale.png
ffmpeg -f lavfi -i smptebars -vf zscale,format=gbrap16 -vframes 1 -pix_fmt rgb48be smptebars-zscale.png
ffmpeg -init_hw_device vulkan -f lavfi -i smptebars -vf libplacebo,format=rgba64 -vframes 1 -pix_fmt rgb48be smptebars-placebo.png
So, zscale and libplacebo are a near match here (the difference is about 2^-12, which is below the human perceptibility threshold), and swscale is significantly different from both.
Using the exact numbers taken from the BT.601 specification, courtesy of https://en.wikipedia.org/wiki/YCbCr#ITU-R_BT.601_conversion, and plugging in the actual 8-bit source YCbCr value (162, 44, 142
), I get:
y = 162
cb = 44
cr = 142
(rd, gd, bd) = (yrgb + crr, yrgb - 0.114/0.587 * cbb - 0.299/0.587 * crr, yrgb + cbb)
where yrgb = 255/219 * (y - 16)
crr = 255/224 * 1.402 * (cr - 128)
cbb = 255/224 * 1.772 * (cb - 128)
This is the MSE of each approach, versus the reference computation:
So we can see that swscale is the least accurate here. Intuitively, this is what we should expect - swscale uses exclusively 16-bit integer math, libplacebo uses 32-bit floating point math, and zscale probably uses a mix of 64-bit float math (for matrices) and 16-bit lookup tables.
I could find no bug in libplacebo when comparing the output of smptebars
directly on 8-bit input values. So I suspect that the issue in the original post, which is far more dramatic than that, comes from someplace else. At the very least, this demonstrates that the color matrices in libplacebo are correct.
I tried repeating the same test with yuv420p10
input instead of yuv420p
, just adding an extra -vf format=yuv420p10
to the beginning of the filter chain for each:
Same pattern - swscale differs (in this case by about 2^-8, a noticeable amount), zscale and libplacebo match.
Edit: My invocation was correct, I forgot to specify h=238
, so I was doing scaling. This was going through the full linearization/sigmoidization path, which has limited precision. Disabling sigmoidization, or fixing the height expression, makes it instead output the far more reasonable value 11253.
Trying to recreate your original sample exactly:
ffmpeg -v verbose -sws_flags +full_chroma_int+full_chroma_inp+accurate_rnd+bitexact -f lavfi -i smptebars -vf setparams=colorspace=bt2020nc:color_primaries=bt2020,crop=320:238:0:1,format=p010le -vframes 1 -pix_fmt yuv420p10 -strict -1 lavfi-crop.y4m
ffmpeg -init_hw_device vulkan -v verbose -sws_flags +full_chroma_int+full_chroma_inp+accurate_rnd+bitexact -f lavfi -i smptebars -vf setparams=colorspace=bt2020nc:color_primaries=bt2020,libplacebo=crop_h=238:crop_y=1,format=p010le -vframes 1 -pix_fmt yuv420p10 -strict -1 placebo-crop.y4m
Extracting Y/Cb/Cr planes from each:
for P in y u v; ffmpeg -i lavfi-crop.y4m -vf extractplanes=$P lavfi-$P.png
I get these raw Y/Cb/Cr values:
Since none of the above operations should have modified the actual underlying YCbCr input value, we can use the original input as reference, which corresponds to 16-bit values (41472, 11264, 36352)
This gives us an MSE of:
So something fishy is definitely going on here. I will try eliminating parameters until we identify the root cause.
@Chipcraft can you share more details about the original input file? Maybe a log with -v debug
would be more helpful.
ffmpeg -init_hw_device vulkan -i Input_BL.h265 -bsf:v hevc_metadata=chroma_sample_loc_type=2 -vf libplacebo=crop_w=3840:crop_h=1600:w=3840:h=1600 -c:v hevc_qsv -preset veryslow -scenario archive -profile:v main10 -level:v 51 -tier high -global_quality 14 -flags +cgop -g 120 -pix_fmt p010le -loglevel -frames:v 1 verbose Placebo_Out.h265
my next idea was to run a black clipping test file with video-output-levels=limited and disable dithering. to see if it adds an tint here to where it technically kinda is lossless. but gpu-next does ignore such a flag for screenshots and using full screen also didn't work because it just clips btb.
edit: did a lot more tests mostly with different dithering and limited range: gpu doesn't care about dithering when making screenshots... making this very hard to test. limited range no dither and 6 bit and hell broke loose the error can be very very big with these settings
fbo-format=rgba32f full range 6 bit no dither option defined make is very hard to see the difference on a histogram:
Input: Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9] // HDR10 BL
Greenish happens to dovi, not other things about ycbcr or rgb.
default vf=format:dolbyvision=no
Greenish happens to dovi, not other things about ycbcr or rgb.
@Chipcraft's file is not dovi
Yes, it is the base layer only.
Looking at frames in Resolve, any idea why G would in fact be the only one intact, while R and B are the ones with the differences?
libplacebo
lavfilter
I you look closely, the green channel is also very slightly off, but in the opposite direction.
Considering the green channel is usually the luma channel minus the red and blue offsets (times some small-ish scaling factor), this makes perfect sense.
So wait, could you clarify, @Chipcraft, is this a DV profile 5 source file?
So wait, could you clarify, @Chipcraft, is this a DV profile 5 source file?
The movie itself has P7 FEL however, libplacebo is only used on the base level bitstream (no EL or RPU). The EL is on a separate file at this point, not even in the same container. Also, "apply_dolbyvision" 0/1 obviously makes no difference here, I've checked that as well.
Here is another sample. The source is 8K yuv420p10le(tv, bt2020nc/bt2020/smpte2084) AV1. From here: https://www.youtube.com/watch?v=OdYsO1FAFQk
Here is one frame extracted (copy) from it (I frame at 00:02:55); https://nle-chipcraft.com/Git/Georgia/Georgia_1F.obu
An encode, with crop done by lavfilters: https://nle-chipcraft.com/Git/Georgia/Georgia_LAV.mkv
ffmpeg -init_hw_device vulkan -i Georgia_1F.obu -bsf:v hevc_metadata=chroma_sample_loc_type=2 -vf crop=7680:4316:0:2 -c:v hevc_qsv -preset veryslow -scenario archive -global_quality 14 -profile:v main10 -level:v 61 -tier high -flags +cgop -g 120 -pix_fmt p010le -loglevel debug Georgia_LAV.mkv
An encode, with crop done by libplacebo: https://nle-chipcraft.com/Git/Georgia/Georgia_PLC.mkv
ffmpeg -init_hw_device vulkan -i Georgia_1F.obu -bsf:v hevc_metadata=chroma_sample_loc_type=2 -vf libplacebo=crop_w=7680:crop_h=4316:crop_x=0:crop_y=2:w=7680:h=4316 -c:v hevc_qsv -preset veryslow -scenario archive -global_quality 14 -profile:v main10 -level:v 61 -tier high -flags +cgop -g 120 -pix_fmt p010le -loglevel debug Georgia_PLC.mkv
btw, since when is there a free version of DaVinci Resolve?
here is ire 30 and ire 10 from the AVS HD 709 - Blu-ray & MP4 Calibration: these are from calman apl they agreed on IRE 50. gpu and madVR agreed more but also not fully. because the ycbcr-RGB conversation stuff seems perfectly fine maybe level conversion? errors in normalization to 1?
i could switch to the native presentation mode of displaycal instead of madTPG for verification.
screens have been taking after long waiting times because my oled is very very unstable.
I knew it was a fool's errand however, decided to test anyways.
@haasn
Would it be correct to assume that using "libplacebo=format=yuv420p10le" on an input, that is already in yuv420p10le format would result in either a bit-exact output, or at the very least something with a difference below the limit of the human perception?
Even in this case, the output from libplacebo features the same exact issue, as the previous test cases.
ffmpeg -init_hw_device vulkan -s 3840x2160 -r 24000/1001 -pix_fmt yuv420p10le -i Source.yuv -c:v rawvideo -strict -1 -loglevel debug Out-NOP.yuv 2>Out-NOP.txt
ffmpeg -init_hw_device vulkan -s 3840x2160 -r 24000/1001 -pix_fmt yuv420p10le -i Source.yuv -vf libplacebo=format=yuv420p10le -c:v rawvideo -strict -1 -loglevel debug Out-PLC.yuv 2>Out-PLC.txt
i found something that will not explain a colroshift but is oddly different.
the ire 10 03-10% Gray.mp4 is a mix of 24 and 25 on madVR or with color dithering a 25 24 25, 24 25 24, and very rare others on mpv it is 90-95% 24 and a rare 25. ire should be 255/10 so it should be a mix of 25 and 26 not? or 219/10+16=37.9.
so time for video-output-levels=limited madVR limited madVR ~90% 38 10% 37 still to low if the file is really ire 10 and my math is worth anything. mpv 37 no dither noise nothing.
so either the file is bad and has a static 37 and madVR is magickly making it 37.1 or there is something going on here.
only screengrabs have been used not screenshot functions. no scaling only chroma no filter just nothing.
edit: more accurate measurement using only the 250x250 cantered pixels and infranview:
2.19x10+16 = 37.9 2.55x10 = 25.5 madVR madVR limited range the image is 37 with some rare 38 in there so in infranview 37.11. 100/219x21.11 is roughly IRE 9.639 madVR full range the image is a 50/50 24 and 25 so in infranview 24.52. 100/255x24.52 is 9.615 so madVR has an error of 0.034 or 0.249% (((100/9.615)x9.639-100)
mpv: mpv limited range is 100 37 even in infranview. 100/219x21 = 9.589 mpv full range is 90/10 24 and 25 so in infranview 24.10. ire 9.451 that's an error of 0.138 or 1.460% (((100/9.451)x9.589-100)
my best guess is it doesn't dither with limited range output creating this massive error and the file is Y 37.
Passing either RGBA or BGRA pixel formats through libplacebo's "format" results in a bit-exact output however, that is not the case with either YUV420P or YUV420P10 (and potentially others).
ffmpeg -init_hw_device vulkan -i PLC_Test\Input\RGBA.png -vf libplacebo=format=rgba PLC_Test\Output\RGBA.png
ffmpeg -init_hw_device vulkan -i PLC_Test\Input\BGRA.bmp -vf libplacebo=format=bgra PLC_Test\Output\BGRA.bmp
Meanwhile, for YUV420P or YUV420P10 inputs, the "-vf libplacebo=format=yuv420p" or "-vf libplacebo=format=yuv420p10" introduces the green tint in the output.
Also, introduced a third filter for testing purposes: VPP_QSV.
The output from VPP_QSV (Crop) results in a bit-exact output with LAV.
LAV (Crop):
ffmpeg -c:v libdav1d -i Georgia_1F.obu -frames:v 1 -update 1 -bsf:v hevc_metadata=chroma_sample_loc_type=2 -vf crop=7680:4316:0:2 -c:v hevc_qsv -preset veryslow -scenario archive -profile:v main10 -level:v 61 -tier high -global_quality 14 -pix_fmt p010le -flags +cgop -g 120 LAV.h265
libplacebo (Crop):
ffmpeg -init_hw_device vulkan -c:v libdav1d -i Georgia_1F.obu -frames:v 1 -update 1 -bsf:v hevc_metadata=chroma_sample_loc_type=2 -vf libplacebo=crop_w=7680:crop_h=4316:crop_x=0:crop_y=2:w=7680:h=4316 -c:v hevc_qsv -preset veryslow -scenario archive -profile:v main10 -level:v 61 -tier high -global_quality 14 -pix_fmt p010le -flags +cgop -g 120 PLC.h265
VPP_QSV (Crop):
ffmpeg -hwaccel qsv -hwaccel_output_format qsv -c:v libdav1d -i Georgia_1F.obu -bsf:v hevc_metadata=chroma_sample_loc_type=2 -frames:v 1 -update 1 -vf vpp_qsv=cw=7680:ch=4316:cx=0:cy=2 -c:v hevc_qsv -preset veryslow -scenario archive -profile:v main10 -level:v 61 -tier high -global_quality 14 -pix_fmt p010le -flags +cgop -g 120 VPP.h265
Would it be correct to assume that using "libplacebo=format=yuv420p10le" on an input, that is already in yuv420p10le format would result in either a bit-exact output, or at the very least something with a difference below the limit of the human perception?
No, libplacebo uses a fully RGB internal pipeline, so both input/output to yuv420p will require conversion (upscaling, downscaling, YCbCr<->RGB)..
an error in chroma scaling could create such an error couldn't it?
an error in chroma scaling could create such an error couldn't it?
Indeed. Maybe something you can try is comparing:
To see which of these combinations are affected
an error in chroma scaling could create such an error couldn't it?
Indeed. Maybe something you can try is comparing:
- yuv420p input, rgba output
- yuv444p input, rgba output
- rgba input, yuv420p output
- rgba input, yuv444p output
To see which of these combinations are affected
that leaves rgb conversation but that looked good on paper.
does libplacebo do RGB full/limited directly or always one and then level correct them? meaning it's so unlikely but the level conversation? it's maybe done twice in this yuv420p -> yuv420p workflow or not at all.
@haasn
The issue appears to be related to the height of the input frame.
The RGB to YUV output is in line with LAV as long as the frame height is < 577 pixels.
RGB 55AAFFh to YUV420P
Input height 576 pixels:
LAV Y = 94h U = B2h V = 55h
libplacebo
Y = 94/95h U = B1/B2h V = 54/55h
Input height >= 577 pixels:
LAV Y = 94h U = B2h V = 55h
libplacebo Y = 97/98h U = AD/AEh V = 57/58h
EDIT: I suppose this is not the issue here. But a bit weird the output differing from the other two filters (LAV & e.g., VPP_QSV).
if no meta data is provided it may guess bt 601 instead of bt 709
if no meta data is provided it may guess bt 601 instead of bt 709
Output from the RGB-to-YUV conversion is identical regardless of the flagged colorspace, primaries, transfer and range in FFMpeg. It only changes depending on the resolution (i.e., <= 576 height and >= 577).
ffmpeg -init_hw_device vulkan -i Input\577.png -c:v rawvideo -vf libplacebo=format=yuv420p10le -strict -1 577_None-PLC.yuv
ffmpeg -init_hw_device vulkan -i Input\577.png -colorspace bt2020nc -color_primaries bt2020 -color_trc smpte2084 -color_range limited -c:v rawvideo -vf libplacebo=format=yuv420p10le -strict -1 577_2020-PLC.yuv
They both produce an identical output.
On latest FFmpeg master, YUV space and range are auto-negotiated, but color primaries and TRC are not yet. I'm working on that (tm).
So your command does nothing, because vf_libplacebo does not know about what tags you're setting "downstream".
but what does libplacebo guess differently between pal resolution and bigger than pal resolution? so we may get closer to the reason of this problem?
@haasn
Found the issue. It is something in the YUV420P10LE <> P010LE conversion, which is causing the observed shift in the colors. In case of LAV, the packing-unpacking process is lossless, whereas with libplacebo it is not. The issue seems to be amplified further, when a libplacebo P010LE encoded source is unpacked by LAV (see PLC_Decompress.yuv). Unpacking P010LE to YUV420P10LE "within" libplacebo isn't lossless either however, the produced difference appears to be smaller (see PLC_Decompress-2.yuv).
LAV
ffmpeg -init_hw_device vulkan -i Georgia_1F.obu -c:v rawvideo -pix_fmt yuv420p10le -strict -1 LAV_Reference.yuv
ffmpeg -init_hw_device vulkan -i Georgia_1F.obu -c:v rawvideo -pix_fmt p010le -strict -1 LAV_Packed.yuv
ffmpeg -init_hw_device vulkan -s 7680x4320 -pix_fmt p010le -i LAV_Packed.yuv -c:v rawvideo -pix_fmt yuv420p10le -strict -1 LAV_Decompress.yuv
"LAV_Reference.yuv" and "LAV_Decompress.yuv" are a bit-exact match.
libplacebo
ffmpeg -init_hw_device vulkan -i Georgia_1F.obu -c:v rawvideo -vf libplacebo=format=yuv420p10le -strict -1 PLC_Reference.yuv
ffmpeg -init_hw_device vulkan -i Georgia_1F.obu -c:v rawvideo -vf libplacebo=format=p010le -strict -1 PLC_Packed.yuv
ffmpeg -init_hw_device vulkan -s 7680x4320 -pix_fmt p010le -i PLC_Packed.yuv -c:v rawvideo -pix_fmt yuv420p10le -strict -1 PLC_Decompress.yuv
ffmpeg -init_hw_device vulkan -s 7680x4320 -pix_fmt p010le -i PLC_Packed.yuv -c:v rawvideo -vf libplacebo=format=yuv420p10le -strict -1 PLC_Decompress-2.yuv
Not only neither the "PLC_Decompress.yuv" or the "PLC_Decompress-2.yuv" are a bit-exact match with the "PLC_Reference.yuv", but also the "PLC_Decompress.yuv" and "PLC_Decompress-2.yuv" differ between each other.
The encoded output between the "PLC_Packed.yuv" and "PLC_Decompress.yuv" are a bit-exact match. Meanwhile, the output from "PLC_Decompress-2.yuv" source still illustrates the issue, however the difference is smaller than with "PLC_Packed.yuv" / "PLC_Decompress.yuv".
Outputs
Source ($\color[RGB]{0,100,0} OK$ ,"Georgia_1F.obu"): https://nle-chipcraft.com/Git/PlaceboShift/Source.png
LAV ($\color[RGB]{0,100,0} OK$ , "Reference" / "Packed" / "Decompress"): https://nle-chipcraft.com/Git/PlaceboShift/LAV_Any.png
libplacebo ($\color[RGB]{0,100,0} OK$ , "Reference"): https://nle-chipcraft.com/Git/PlaceboShift/PLC_Reference.png
libplacebo ($\color[RGB]{255,0,0} FAIL$ , "Packed" / "Decompress"): https://nle-chipcraft.com/Git/PlaceboShift/PLC_Packed.png
libplacebo ($\color[RGB]{255,140,0} FAIL$, "Decompress-2"): https://nle-chipcraft.com/Git/PlaceboShift/PLC_Decompress-2.png
Closing as an assumed "won't fix", since it has been six months without anything being done.
Libplacebo filtering causes the output image to feature a greenish tint. In this case, libplacebo was used for cropping. Otherwise the same workflow, using lavfilter crop-filter instead of libplacebo does not illustrate this behavior.
Input: Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9] // HDR10 BL
libplacebo (master) - 34e019bfedaa5a64f268d8f9263db352c0a8f67f ffmpeg (master) - https://github.com/FFmpeg/FFmpeg/commit/34a47b97de9d90a28ead36ca200f6a19a08ce2df
Command w/ libplacebo:
ffmpeg -init_hw_device vulkan -i Input_BL.h265 -bsf:v hevc_metadata=chroma_sample_loc_type=2 -vf libplacebo=crop_w=3840:crop_h=1600:w=3840:h=1600 -c:v hevc_qsv -preset veryslow -scenario archive -profile:v main10 -level:v 51 -tier high -global_quality 14 -flags +cgop -g 120 -pix_fmt p010le -loglevel verbose Placebo_Out.h265
Command w/ lavfilter:
ffmpeg -init_hw_device vulkan -i Input_BL.h265 -bsf:v hevc_metadata=chroma_sample_loc_type=2 -vf crop=3840:1600:0:280 -c:v hevc_qsv -preset veryslow -scenario archive -profile:v main10 -level:v 51 -tier high -global_quality 14 -flags +cgop -g 120 -pix_fmt p010le -loglevel verbose Lavfilter_Out.h265