Hi >Le vendredi 27 janvier 2023 à 15:34 +0000, John Cox a écrit : >> This is in preparation for attempting to upstream the Rpi H265 decoder >> as these formats are the only ones the hardware can decode to. They are >> a column format rather than a tile format but I've added them to the >> list of tiled formats as that seems the closest match. >> >> V4L2_PIX_FMT_NV12_C128 matches DRM format NV12 with modifier >> DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT(ch) and >> V4L2_PIX_FMT_P030_C128 matches DRM format P030 with the same modifier. > >Cause pixel format matching is hard, P030 matches GStreamer NV12_10LE32, format >also found on Xilinx ZynMP CODECs (but without any modifiers so far). > >This is just for curiosity, was there any software implementation of these >formats made available publicly ? or have they only been tested in conjunction >with an importing HW ? I'm unsure exactly what you are asking here. I don't think that anyone other than RPi/Broadcom has used these formats for anything. I've certainly written code that uses and converts them that has been on my public github and has been used by RPi but I doubt that is what you meant by "Publicly". V4L2_PIX_FMT_NV12_C128 is annoying to use in s/w (though I have written s/w parts of a decoder that use it), V4L2_PIX_FMT_P030_C128 is stupidly annoying to use in s/w and all I've ever written is code to convert it to something more useable. Does that answer the question? >> John Cox (2): >> media: v4l: Add Broadcom sand formats to videodev2.h >> media: v4l: Add documentation for Broadcom sand formats >> >> .../media/v4l/pixfmt-yuv-planar.rst | 192 ++++++++++++++++++ >> include/uapi/linux/videodev2.h | 2 + >> 2 files changed, 194 insertions(+) >>
