mbox series

[0/2] media: v4l: Add Broadcom sand format to the list of V4L formats

Message ID 20230127153415.83126-1-jc@kynesim.co.uk
Headers show
Series media: v4l: Add Broadcom sand format to the list of V4L formats | expand

Message

John Cox Jan. 27, 2023, 3:34 p.m. UTC
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.

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(+)

Comments

Nicolas Dufresne Feb. 9, 2023, 5:56 p.m. UTC | #1
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(+)
>
John Cox Feb. 9, 2023, 6:21 p.m. UTC | #2
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(+)
>>