| Message ID | 20230127153415.83126-1-jc@kynesim.co.uk (mailing list archive) |
|---|---|
| Headers | show |
| Series | media: v4l: Add Broadcom sand format to the list of V4L formats | expand |
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 ? > > 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(+) >
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(+) >>
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. 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. > > > > 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(+) > > >
>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(+) >> > >