Re: Re: v4l2 api

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



  Cool.  Comments:

> /*
>  *	E N U M S
>  */
> enum v4l2_field {
> 	V4L2_FIELD_ANY        = 0, /* driver can choose from none,
> 				      top, bottom, interlaced
> 				      depending on whatever it thinks
> 				      is approximate ... */
> 	V4L2_FIELD_NONE       = 1, /* this device has no fields ... */
> 	V4L2_FIELD_TOP        = 2, /* top field only */
> 	V4L2_FIELD_BOTTOM     = 3, /* bottom field only */
> 	V4L2_FIELD_INTERLACED = 4, /* both fields interlaced */
> 	V4L2_FIELD_SEQUENTIAL = 5, /* both fields sequential into one
> 				      buffer */
> 	V4L2_FIELD_ALTERNATE  = 6, /* both fields alternating into
> 				      separate buffers */
> };

  1. Again I'll mention Ronald Bultje's comment that if a card provides
frames as V4L2_FIELD_INTERLACED, it should also be able to say
top-field-first or bottom-field first.

> struct v4l2_pix_format
> {
> 	__u32         	 width;
> 	__u32	         height;
> 	__u32	         pixelformat;
> 	enum v4l2_field  field;
> 	__u32            bytesperline;	/* for padding, zero if unused */
> 	__u32         	 sizeimage;
> #if 0
> /* FIXME: specify ITU-R 601, ... here ??? */
>         __u32   colorspace;
> #endif
> 	__u32	priv;		/* private data, depends on pixelformat */
> };

  2. Doing a general colourspace definition is dangerous, IMHO, so I
like the idea of having a bunch of #defines, like with the video
standard.  It will make things easier.  Having a way to detect the
broken bt878 extents would kick!  Comments on this as a start?

/* 601 transfer with oldschool chromaticities. */
#define V4L2_COLORSPACE_SMPTE170M     0x000001

/* I know this is used in some PAL areas I think. */
#define V4L2_COLORSPACE_SMPTE240M     0x000002

/* HD and modern captures. */
#define V4L2_COLORSPACE_REC709        0x000004

/* Be able to detect the broken BT878 extents. */
#define V4L2_COLORSPACE_BT878         0x000008

/* These should be useful.  Assume 601 extents. */
#define V4L2_COLORSPACE_470_SYSTEM_M  0x000010
#define V4L2_COLORSPACE_470_SYSTEM_BG 0x000020

/* I know there will be cameras that send this.  So, this is
 * unspecified chromaticities and full 0-255 on each of the Y'CbCr
 * components
 */
#define V4L2_COLORSPACE_JPEG          0x000040

/* For RGB colourspaces, this is probably a good start. */
#define V4L2_COLORSPACE_SRGB          0x000080

> struct v4l2_buffer
> {
> 	int			index;
> 	enum v4l2_buf_type      type;
> 	__u32			offset;
> 	__u32			length;
> 	__u32			bytesused;
> 	__u32			flags;
> 	enum v4l2_field		field;
> 	struct timeval		timestamp;
> 	struct v4l2_timecode	timecode;
> 	__u32			sequence;
> 	__u32			reserved[3];
> };

  3. You give one timestamp per buffer.  It would be really awesome to
get, for an interlaced buffer, the timestamp of each field, rather than
being forced to use ALTERNATE.

> struct v4l2_captureparm
> {
> 	__u32		capability;	/*  Supported modes */
> 	__u32		capturemode;	/*  Current mode */
> 	unsigned long	timeperframe;	/*  Time per frame in .1us units */
> 	__u32		extendedmode;	/*  Driver-specific extensions */
> 	__u32           readbuffers;    /*  # of buffers for read */
> 	__u32		reserved[4];
> };
> /*  Flags for 'capability' and 'capturemode' fields */
> #define V4L2_MODE_HIGHQUALITY	0x0001	/*  High quality imaging mode */
> #define V4L2_CAP_TIMEPERFRAME	0x1000	/*  timeperframe field is supported */

  4.  I don't understand 'timeperframe'.  We already have v4l2_standard,
shouldn't it just be retrieved from that?  Also, it would be better to
do the numerator/denominator thing here too, no?

-- 
Billy Biggs
vektor@xxxxxxxxxxxx





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux