03:01 <cone-917> ffmpeg Lynne master:15c03b79d235: hw_base_encode_h264: remove unused AUD unit structure

03:01 <cone-917> ffmpeg Lynne master:4646a74d1e61: lavc/Makefile: only compile hw_base_encode_h264.c when actually needed

06:56 <JEEB> RIP OMX https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30865

06:57 <Lynne> I still remember when OMX got support for AV1 decoding before any other API

06:58 <JEEB> I thought it had not received extensions for newer formats for ages

06:58 <Lynne> not since av1 decode

06:58 <JEEB> that's in my books pretty recent as a format :D

06:58 <Lynne> amd didn't really have much of a choice back then

06:59 <Lynne> vaapi was still sort of controlled by mostly intel I think

06:59 <Lynne> and omx was abandoned enough such that no one cared

07:00 <JEEB> https://registry.khronos.org/OpenMAX-AL/ , but it says last updated in 2011? :D

07:01 <JEEB> but yes, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7596

23:23 <ramiro> haasn: regarding range conversion again, I thought we could convert ranges directly (like an unscaled converter from yuvj to yuv), but I was wrong. you mentioned such an operation would benefit from dithering, so it makes sense to go through the full pipeline. would it make sense to have a simpler special dither + range converter?

23:27 <ramiro> also, I've been trying to understand how the constants from the range conversion functions (like lumRangeFromJpeg_c) were derived, but I'm having a hard time. the coefficients (like 14071) are easy enough, but I can't figure out offsets (like 33561947). they were added in 6bc0c7928a3.

23:27 <ramiro> michaelni: maybe you can shed some light on how these values were obtained? ^^