Ronald Bultje wrote:
>
> > struct v4l2_outputparm
> I must have missed something, what's this for?
Gerd:
> video output (V4L2_CAP_VIDEO_OUTPUT). Was also in the old header file.
Actually nothing terrible important. Suppose you want to play a 15 Hz
stream on tv out. When the driver runs out of data it must repeat the
last frame/field (what else, blank video?) so this could be achieved by
passing frames in real time. But under a general purpose multitasking OS
nothing happens in real time. With this (optional) struct & ioctl one
can determine the effective output frame rate (timeperframe) regardless
how fast or slow you write().
For streaming this is unnecessary. The driver locks to some vertical
sync, in the interrupt routine it checks the first buffer in the full
queue. When its timestamp is >= TOD the frame/field is displayed,
otherwise it repeats the previous frame/field. That's the minimum
requirement anyway. One can start playback with frame/field period
accuracy and stack up any number of buffers to be displayed at any
desired rate.
Potentially this struct could also be used to modify the output process
as its capture counterpart does, e.g. the speed/quality trade-off
mentioned in the spec. But for output up to now only timeperframe is
defined.
> > struct v4l2_crop {
> > enum v4l2_buf_type type;
> > struct v4l2_rect c;
> > };
>
> I'm seeing some problems for cropped capture. For cropping, you
> basically first need to set the capture size/format, since cropping
> depends on the format being used. But after that, if the application
> sets cropping rectangles, the size changes. Is that how it's supposed to
> work (and is the application then supposed to re-request size by G_FMT),
> or is this indeed a problem?
Yes, the capture size can change when there are some scaling
limitations, therefore the app must check the result and may try again.
I think a different approach will add more problems.
> > struct v4l2_enumstd
> > {
> > __u32 index;
> > struct v4l2_standard std;
> > __u32 inputset; /* set of inputs that */
> > /* support this standard */
> > __u32 outputset; /* set of outputs that */
> > /* support this standard */
> > __u32 reserved[2];
> > };
>
> inputset/outputset is just the same as inputs/outputs, or are they a
> bitfield where (1<<x) means that input/output x supports this std?
There are a few things to improve. struct v4l2_standard isn't used
elsewhere anymore (the videodev helper functions don't count), we can
merge that in. Second s/v4l2_enumstd/v4l2_standard following v4l2_input,
v4l2_tuner etc. w/o "enum" in the name. Third I propose to add
.standardset in v4l2_input/v4l2_output and remove the .input/outputset
here. Rationale is that we have the .tuner link and .audioset there too.
This change would root everything in the input/output enum.
Btw in v4l2_enumstd, v4l2_fmtdesc, v4l2_buffer, v4l2_input etc we have
an index field. v4l2_audio, v4l2_tuner, v4l2_frequency etc use different
names for essentially the same thing.
Shouldn't this be more consistent? What about index everywhere to
emphasize the function, or enumeration names (v4l2_audio.audio,
v4l2_input.input) to clarify these are unrelated? Or just
v4l2_enumstd.inputset -> v4l2_input.index; v4l2_input.audioset ->
v4l2_audio.index, v4l2_input.tuner and v4l2_frequency.tuner ->
v4l2_tuner.index etc. you see the pattern.
> I think this is all... I like some of your changes, as I've said before.
> Let's hope this still will make it into 2.5/6.x.
Your word in Linus ear.
Michael
