Hi Manjunath, On Tuesday 17 January 2012 07:59:35 Hadli, Manjunath wrote: > On Mon, Jan 02, 2012 at 16:51:06, Laurent Pinchart wrote: > > On Wednesday 28 December 2011 12:16:27 Sakari Ailus wrote: > > > On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote: > > > > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote: > > > > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote: > > > > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote: > > > > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote: > > > > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > > > > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer > > > > > > > > > format frames compressed by A-LAW alogorithm. > > > > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV > > > > > > > > > interleved) only. > > > > > > > > > > > > > > > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@xxxxxx> > > > > > > > > > Cc: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > > > > > > > > --- > > > > > > > > > > > > > > > > > > include/linux/videodev2.h | 6 ++++++ > > > > > > > > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > > > > > > > > > > > > > Could you please also document these formats in > > > > > > > > Documentation/DocBook/media/v4l ? > > > > > > > > > > > > > > I will. Sorry to have missed that out. > > > > > > > > > > > > > > > > diff --git a/include/linux/videodev2.h > > > > > > > > > b/include/linux/videodev2.h index 4b752d5..969112d 100644 > > > > > > > > > --- a/include/linux/videodev2.h > > > > > > > > > +++ b/include/linux/videodev2.h > > > > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > > > > > > > > > > > > > > > > > > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', > > > > > > > > > '2') /* 8 YUV > > > > > > > > > > > > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 > > > > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines > > > > > > > > > y, 1 line uv interleaved */ > > > > > > > > > > > > > > > > > > +/* Chrominance formats */ > > > > > > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' > > > > > > > > > ') /* 8 UV 4:4 */ + > > > > > > > > > > > > > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */ > > > > > > > > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', > > > > > > > > > '2') /* 12 Y/CbCr > > > > > > > > > > > > > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', > > > > > > > > > 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ > > > > > > > > > struct v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 > > > > > > > > > v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* > > > > > > > > > 10bit raw bayer DPCM compressed to 8 bits */ #define > > > > > > > > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') > > > > > > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define > > > > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > > > > > > > > > + > > > > > > > > > > > > > > > > That's not very future-proof, how would you describe > > > > > > > > SGBRG10ALAW8 for instance ? > > > > > > > > > > > > > > > > Maybe it's time to standardize FOURCCs for Bayer new > > > > > > > > formats. We have 4 characters, we could start with 'B' to > > > > > > > > denote Bayer, followed by one character for the order, one > > > > > > > > for the compression, and one for the number of bits. > > > > > > > > > > > > > > I agree. > > > > > > > May be ('B', 'G', 'A', '8') is fine for the above? > > > > > > > > > > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could > > > > > > use 'B', 'g', 'G' and 'R' respectively for the second character. > > > > > > The third character would be 'A' for A-law and 'D' for DPCM, and > > > > > > the fourth character could describe the bus width in bits from 0 > > > > > > to 15 with '0' - '9', 'A' - 'F'. However, I suspect that we will > > > > > > need 16-bit wide busses for raw Bayer at some point, and a 0 > > > > > > width is definitely not useful. We could thus offset the width by > > > > > > some value. > > > > > > > > > > > > This is just a preliminary idea, I'm open to suggestions. > > > > > > > > > > I think it is a very good suggestion that we can go with. > > > > > B : BGGR > > > > > g : GBRG > > > > > G : GRBG > > > > > R : RGGB > > > > > > > > > > and 0-F can signify 1-16. > > > > > > > > Hans, Guennadi, Sakari, any opinion on that as well ? > > > > > > I think four letters simply aren't enough to universally describe a > > > media bus format in a human-readable way. We can aim to that, but we > > > will have to make compromises. > > > > > > For example, DPCM compressed format has two important parameters > > > beyond pixel order and the colour space, the uncompressed depth and > > > the compressed depth. Typically one doesn't compress the data too > > > much, but things like > > > 10-to-6 bits are well possible. > > > > > > Could we use a single letter to tell that a format is both bayer and > > > DPCM compressed? I'd go for 'b'. Raw bayer alaw could be denoted by > > > 'a'. > > > > > > Then raw bayer, GBRG pixel order 10-to-7 bits would be called "bgA7". > > > The same in Alaw would be "agA7". > > > > > > What do you think? > > > > We can't come up with a naming scheme that will handle all possible > > combinations. I'm fine as long as the names we select have some kind of > > structure and handle the raw patterns currently available. I'd still > > like to hear Hans' opinion on this. > > Since we agree that the scheme will not be able to cover the spectrum > In the level of detail which we would like to, I think we should go with > the Above discussed scheme which seems logical. I will send out a detailed > patch With added documentation. Please also see http://www.spinics.net/lists/linux-media/msg43192.html. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html