Re: v4l2 api

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



>    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.

IMHO the field order should simply specified in the specs (see also
Michaels comment).

> > struct v4l2_pix_format
> > {
> > #if 0
> > /* FIXME: specify ITU-R 601, ... here ??? */
> >         __u32   colorspace;

>    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?

I'd make that a enum, not #defines, but its bascially the same.

> > 	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.

Why?

> > 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?

Hmm, bttv implements it this way ...

	v4l2_video_std_construct(&s, bttv_tvnorms[btv->tvnorm].v4l2_id);
	parm->parm.capture.timeperframe = v4l2_video_std_tpf(&s);

... which clearly indicates it is indeed redundant.  At least for TV
cards, what about usb webcams?

>  Also, it would be better to
>  do the numerator/denominator thing here too, no?

Probably (unless we drop it anyway ...)

  Gerd

-- 
You can't please everybody.  And usually if you _try_ to please
everybody, the end result is one big mess.
				-- Linus Torvalds, 2002-04-20





[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