>Le jeudi 09 février 2023 à 18:21 +0000, John Cox a écrit : >> 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? > >Well, whatever you have and you can share a link to would be nice, it does help >reviewing your doc. But I think I understand what it is from your doc so far, so >nothing to worry about. There are more files including arvm7 & v8 neon converters but this has C converters out of sand8/30 to YUV420/NV12/VUV420P10: https://github.com/jc-kynesim/rpi-ffmpeg/blob/test/5.1.2/main/libavutil/rpi_sand_fns.c which should give you what you need. V4L2_PIX_FMT_NV12_C128 = AV_PIX_FMT_RPI4_8, V4L2_PIX_FMT_P030_C128 = AV_PIX_FMT_RPI4_10. Ignore code referencing AV_PIX_FMT_SAND64_10, that format is now obsolete (10 bits in 16, so 64 pixels per col) and was only used by the Pi3 gpu assisted H265 s/w decode. >As a side note, for boards that are readily available in KernelCI, I often >implement slow path converter in GStreamer so we can run it through fluster and >catch any regressions. It is very minimal regression tests simply using what ITU >made publicly available. Oh absolutely. Whilst I admit I haven't done proper fate integration (yet) I do run a test script against all the ITU conformance streams (+ a few others that had bad cases missed by ITU) on a regular basis. Regards John Cox >> > > 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(+) >> > >
