02:22 <Lynne> elenril: could you check into what the issue is with segfaulting when setting the avclass pointer between the main decode context and the vulkan context?

06:00 <rajivharlalka> is there some tool which can help me verify rgb<->yuv value conversion for 10bit pixels.

06:02 <JEEB> there's no single conversion, so if you don't trust your own code then you need to look for a library that already does all of the H.273 (matrix, primaries, transfer, range, chroma location) values you require. if you are trying to verify someone else's code against your code, then the base values are in H.273.

06:05 <rajivharlalka> JEEB: I just want to verify my code as the output doesn't match with the expected value, so was looking where might the issue be. was using the BT2020 conversion values.

06:06 <JEEB> (also do understand that BT.1886 EOTF handling does include screen black/white level stuff which depending on the library may or may not be done - f.ex. zimg doesn't do this while libplacebo does it as otherwise the image gets changed)

06:07 <rajivharlalka> to verify the conversion I was trying to do rgb->yuv and then the same yuv->rgb using this conversion formula: https://usercontent.irccloud-cdn.com/file/NrB8nkXi/image.png

06:08 <rajivharlalka> and was expecting something similar to input image, leaving some room for approximated values

06:09 <JEEB> oh, so they finally officially killed this off https://www.phoronix.com/news/Intel-Discontinues-SVT-HEVC

06:10 <JEEB> it was really lagging behind API-wise compared to SVT-AV1, so for quite a while it was clear that was not of interest

06:15 <JEEB> rajivharlalka: see H.273 for actual formulas and references to where they are based on

06:17 <JEEB> that also helps keep you specific on which steps you are dealing with (matrix coefficients, primaries, transfer, color range etc). zimg for example if you only specify matrix on non-RGB side will just do matrix coefficient application

06:20 <rajivharlalka> got it, would take a look there

06:21 <JEEB> (ok, I was not 100% correct - zimg will also do limited to full range when just the matrix is defined since RGB is generally not limited range)

06:23 <JEEB> (and since RGB is not subsampled, chroma subsampling of course gets upscaled to 4:4:4)

06:25 <rajivharlalka> yeah, am forcing the subsampling to be 444 using the pix_fmt to handle that.

07:56 <rajivharlalka> In HLG EOTF/OOTF, I see there is a part where after the OOTF is applied RGB_D it is multiplied by L_peak, L_black in different factor, is there a way I could get those variables in ffmpeg?

08:09 <JEEB> rajivharlalka: it's not related to the content but instead a parameter of the display output that you are aiming at. so it would be an AVOption of your module. technically I think the mastering display color volume side data could be utilized as some sort of guesstimate (since your display is not the same as the mastering display most likely), but not sure if I would recommend for that.

08:26 <rajivharlalka> Ah, so what I get is that L_peak must be the max luminance of the display model and similarly L_black to be the luminance for black color on the same model, and hence cannot be calculated as such.

11:40 <cone-320> ffmpeg Martin Storsjö master:cfe0a36352f5: libswscale: aarch64: Fix the indentation of some macro invocations

12:29 <elenril> Lynne: didn't mkver look at it already?

13:44 <Lynne> no, that patch tried to get rid of the context, and you mentioned you would take a look at doing it properly