Re: RFC: V4L - Support for video timings at the input/output interface

["Jean-Philippe François" <jp.francois@cynove.com>]

Hans Verkuil a écrit :

>> and so forth. So for a camera that supports pre-defined presets can
>> set the CAP_FIXED_FRAME_RATE capability. So Auto exposure may not
>> be available. If Auto exposure is available, the driver can indicate
>> CAP_VARIABLE_FRAME_RATE. If a driver supports both, then both flags
>> can be set and based on the value of fps can decide which mode to
>> operate on (0/0 - for variable mode, 30/1 - to do 30fps rate).
> 
> Setting up a sensor is rather messy at the moment. You have the
> ENUM_FRAMESIZES and ENUM_FRAMEINTERVALS ioctls that basically give you the
> 'presets' of a sensor. For exposure we have camera controls. Yet we also
> have S_PARM to set the framerate. And to set the resolution we abuse S_FMT.
>
Some sensor are very versatile, and so a preset is just an arbitrary 
resolution. Yet most of the application will be happy with a few preset 
to choose from. I agree that it should be easy to just "set the resolution".

We should have preset, it should still be possible to access all 
capabilities of the sensor. I have not contributed any code, but here 
are some use case that are quite difficult to handle :

* I don't like the presets.
How should I change resolution ?
-VIDIOC_S_FMT ?
-VIDIOC_S_DV_TIMINGS ?

* I use the sensor with another hardware, I can't handle the default 
pixelclock :
-VIDIOC_G/S_DV_TIMINGS seems really handy here. Except I don't necessary
care about / can set the other parameters


* I wan't to change the field of view.
-should I use S_CROP ? But I am not really doing any cropping here, just 
changing the firts row, first column.

* Both the sensor and the hardware provide the cropping capability.
-For example, let's say I want to capture a 800x600 windows in the 
center of a 5 MPixel sensor, and I work with a video port that has 
cropping capabilities.
- solution A : The sensor is configured for a 800x600 capture, and the 
video port takes it all.
-solution B : the sensor is configured for a full field capture (5Mpx), 
and the videoport takes only some part of the data.

Of course solution A is faster, because the sensor does a readout of 
much less data. But with some sensor I will only get solution B.

IMO, S/G_FMT should deal with solution A, and S/G_CROP with solution B.

* Repeat the former point with white balance, exposure, gain, gamma,
rgb2yuv etc...

* "Preview" and "capture mode" ex : MT9D131. I can have the following :
- Full field capture (1600x1200) but 800x600 output
- Full field capture, full resolution output
Ok, this can be handheld with ENUM_FRAME_SIZE
- Windowed 800x600 capture, full resolution output (800x600)
Same resolution, similar or identical framerate.
The possibility to move the window, gives you a very quick zoom 
capability anywhere in the picture.
But it is a PITA with the current API

That is why I think the VIDIOC_S_DV_PRESET is a good idea, when you just 
want to set a standard resolution.
Regarding the custom timings, I think it puts and emphasis on the timing 
  problem, while CMOS sensor has some other interesting parameters.

I am glad I can change pixelclock, but changing the capture windows 
position would be great to !

Should S_FMT be changed ?
This is the format as seen by the application, changing the windows 
position does not change the ouptut format.

Should I use S_CROP ?
See my example with solution A and B. Obviously, solution A is not 
really cropping.

Should it be exposed in a CTRL ?
That is the current solution i am using. Hacking the driver. Of course 
then I move on a new project because my boss does not want me to spend 
time having my change merged upstream. Typical embedded reaction :(

Should we enhance the custom timings RFC proposed by TI to include not 
only timing, but perhaps windows pos, and perhaps skipping/binning as well ?


> I don't think we should use preset for anything else besides just uniquely
> identifying a particular video timing. It is a good idea though to add the
> width, height and fps to struct v4l2_dv_enum_presets. That way apps can
> actually know what the preset resolution and fps is.
> 
> To be honest I don't have any brilliant ideas at the moment on how to solve
> setting sensor timings. 
Neither do I, and I prefer a simple driver I can hack, to a "let's 
expose all messiness to userspace, and let them fill a dozen struct"
At the LPC we have both the UVC maintainer (Laurent
> Pinchart) and the libv4l and gspca developer Hans de Goede present, so we
> should be able to come up with a good solution to this. My knowledge of
> sensors is limited, so I will need help with this.
> 
> Regards,
> 
> 	Hans
>