Gerd Knorr wrote:
>
> > I *do* want to know whether it's topfirst or bottomfirst. (i.e., the
> > spatial top/bottom is first in time and thus sequentially first in the
> > JPEG buffer). The first field in this buffer is always the one which was
> > first in time, that's correct.
>
> Exactly this way I understood it.
>
> > The above solution would work fine.
>
> Ok, then I'd leave it as-is.
Let me get this straight before I go completely nuts.
Interlaced is always top field first, temporal order depends on the
video standard.
Sequential is always oldest first (fields stored in transmitted =
temporal order). The app asks for any of V4L2_FIELD_SEQ_TB or
V4L2_FIELD_SEQ_BT and the driver returns whatever applies.
Likewise alternating fields are passed in transmitted = temporal order,
starting with what? One could check V4L2_BUF_FLAG_TOPFIELD/BOTFIELD, but
it seems they're gone.
> > I like this type field a lot! Can this be added to the cropping set/get
> > ioctl()s as well?
>
> Sounds reasonable, done.
I assumed cropping dimensions apply to capture & overlay alike. A type
field allows two sets of cropping parameters in simultaneous
capture/overlay mode. Do you want that? If so, how are the semantics
when the driver supports only one set? If not, why else do we need a
type field?
> > Hmm...
> >
> > I think it's okay to make them behave the same, but S_FMT is really much
> > more complex than TRY_FMT. TRY_FMT should be kept simple. width, height,
> > buffer-type and format, that's really all you need. Would work for both
> > overlay and capture.
>
> I like the idea to use exactly the same struct for TRY_FMT + S_FMT.
> It helps to avoid stupid mistakes. Some application can do a TRY_FMT,
> check the format it got back, and if it is happy with the result it can
> simply pass the same struct to S_FMT and be done with it. No need to
> copy the fields from one struct to another. And we can be sure that we
> havn't forgotten something. For example the application can also return
> which fields it will use if you pass in V4L2_FIELD_ANY ...
Yup, and because v4l2_window is part of the v4l2_format union both
ioctls cover capture w/h/pixfmt as well as overlay x/y/w/h.
> * for S_FBUF I'd like to pass a device instead of a physical address,
> but there seems to be no standard way yet to pass this info between
> kernel + userland ...
Something like PCI bus, device number and function perhaps? The X server
knows that, no question. Other apps, hm.
> * struct tuner: add some type field here too? For radio/tv/...? What
> about tuning analog SAT tv? Should we add something for that? The
> digital stuff I'd leave to the well-established DVB API.
What happened to the tuner/modulator union idea?
> * Documentation: Where will the updated API docs appear on the web?
> I'd like to have some up-to-date URL in the header file when
> submitting stuff to Linus. Or should we also ship that with the
> kernel maybe?
Kernel of course. But in the near future I think it's better somewhere
online, where we can easier correct mistakes, add clarifications,
examples, links etc. What about bytesex.org?
> #define V4L2_MAJOR_VERSION 0
> #define V4L2_MINOR_VERSION 20
1.0 ?
> struct v4l2_jpegcompression
> {
> int quality;
>
> int APPn; /* Number of APP segment to be written,
> * must be 0..15 */
> int APP_len; /* Length of data in JPEG APPn segment */
> char APP_data[60]; /* Data in the JPEG APPn segment. */
>
> int COM_len; /* Length of data in JPEG COM segment */
> char COM_data[60]; /* Data in JPEG COM segment */
>
> __u32 jpeg_markers; /* Which markers should go into the JPEG
> * output. Unless you exactly know what
> * you do, leave them untouched.
> * Inluding less markers will make the
> * resulting code smaller, but there will
> * be fewer aplications which can read it.
> * The presence of the APP and COM marker
> * is influenced by APP_len and COM_len
> * ONLY, not by this property! */
>
> #define V4L2_JPEG_MARKER_DHT (1<<3) /* Define Huffman Tables */
> #define V4L2_JPEG_MARKER_DQT (1<<4) /* Define Quantization Tables */
> #define V4L2_JPEG_MARKER_DRI (1<<5) /* Define Restart Interval */
> #define V4L2_JPEG_MARKER_COM (1<<6) /* Comment segment */
> #define V4L2_JPEG_MARKER_APP (1<<7) /* App segment, driver will
> * allways use APP0 */
> };
Someone please explain this, better yet write the spec. IMHO it's
pointless to add when we don't know how this works, what the purpose is.
> struct v4l2_vbi_format
> {
> __u32 sampling_rate; /* in 1 Hz */
> __u32 offset;
> __u32 samples_per_line;
> __u32 sample_format; /* V4L2_VBI_SF_* */
V4L2_PIX_FMT_*
> __s32 start[2];
> __u32 count[2];
> __u32 flags; /* V4L2_VBI_* */
> __u32 reserved[2]; /* must be zero */
> };
>
> #define VIDIOC_QUERYSTD _IOW ('V', 63, v4l2_std_id)
> #define VIDIOC_TRY_FMT _IOW ('V', 63, struct v4l2_format)
Michael
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
