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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux