Re: RFC: V4L - Support for video timings at the input/output interface
On Mon, Sep 14, 2009 at 3:51 PM, Karicheri, Muralidharan m-kariche...@ti.com wrote: RFC: V4L - Support for video timings at the input/output interface Thanks to Hans Verkuil for his initial proposal and feedbacks to help write this RFC. Version : 1.0 Background --- Currently v4l2 specification supports capturing video frames from TV signals using tuners (input type V4L2_INPUT_TYPE_TUNER) and baseband TV signals (V4L2_INPUT_TYPE_CAMERA) and sensors. Similarly on the output side, the signals could be TV signal (V4L2_OUTPUT_TYPE_MODULATOR), baseband TV signal (V4L2_OUTPUT_TYPE_ANALOG) or hybrid analog VGA overlay (V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY) which output from a graphics card and then use chromakeying to replace part of the picture with the video. V4L2_OUTPUT_TYPE_ANALOG V4L2_INPUT_TYPE_CAMERA are for analog interfaces that includes composite, S-Video and VGA (for output only). Note that even though VGA is a supported output, we don't have anyway to set the standard or timing on the output. Standard ids are only defined for TVs using v4l2_std_id and a set of bit masks defined for analog TV standards. Today we have a wide variety of different interfaces available to transmit/receive video or graphics content between source device and destination device. Following are some of the interfaces used in addition to the ones described in the v4l2 specification. Component analog input/output interface - ED/HD video DVI - Digital only, ANALOG only, DVI integrated that support Digital and Analog; Dual Link - Where second data link is used for higher bandwidth SDI - Serial digital interface standardized by SMPTE HDMI - HD video and Audio DisplayPort - digital audio/video interconnect by VESA V4L2 specification currently defined NTSC/PAL/SECAM (all variants) standards for describing the timing of the signal transmitted over these interfaces. Even though the specification defined ANALOG output type for VGA, there are no ways to set the timings used for output to VGA or LCD display monitors. Some of the proprietary implementations used existing standards IOCTL, VIDIOC_S_STD, to set these timings over these interfaces. For example, TI has Video Processing Back End (VPBE) on various media SOCs (Eg, DM6446, DM355 etc) that can output signal for Analog TV and VGA interfaces (using Digital LCD port) and support timing for displaying SD and HD videos (1080i, 1080p and 720p) as well as over VGA interface to a CRT or LCD display monitor. So we need to enhance the v4l2 specification to allow applications to set these timings in the capture or output devices. This RFC proposes to add new IOCTLs for setting/getting timings over the different interfaces described above and freeze the the use of existing standards IOCTL and standards IDs for analog TVs only. Timings --- The timing at the analog or digital interface that are not covered by the v4l2_std_id can be defined using a set of preset timings that are used by the hardware where these timings are predefined or by a set of timing values which can be configured at the hardware to generate the signal expected at the interface. The former will be used for hardware like TVP7002/THS8200 which specifies preset timing required for output HD video such 1080i50/60, 720p50/60 etc. The latter can be used for hardware that require configuration of frame timing such as front porch, hsync length, vsync length, pixel clock etc. For example the earlier mentioned TI SOCs has a Digital LCD port that can be configured to output different timing values expected by LCD Display monitors. The proposal seems good, given that v4l2 supports output (input) devices, it was kind of strange that v4l2 didnt have a way to setup custom timings on such devices, even so i have some concerns. For the output device and timings, there's already an API which supports that on the kernel, the FB API. The framebuffer system can be seen as an independent system but with some intersection with the v4l2 output device. Some of the differences are modedb, timings, bitblt acceleration, EDID handling, even a video output switcher via sysfs, etc and some of the them are now needed for v4l. Also the FB API suffers on other areas, like YUV planes (as the depth definitions doesnt support that), chroma key, etc (this are handled by private ioctls on some fb drivers). Also the DRM people is adding support for KMS (kernel mode setting) which also uses a timing definition for that and EDID handling. So, from a kernel developer/application developer POV, this is a mess. We have three different API for the same devices/tasks. IMO this RFC is a good thing, but we need a way to stabilize the kernel graphics area somehow, maybe share this RFC among the other subsystems (fb, drm)? Regards Preset timings (defined by VESA, SMPTE or BT.656/BT.1120 or others) can be defined by the following structure:-
RE: RFC: V4L - Support for video timings at the input/output interface
Jean-Philippe François,
Component analog input/output interface - ED/HD video
DVI - Digital only, ANALOG only, DVI integrated that support Digital and
Analog; Dual Link - Where second data link is used for higher
bandwidth
SDI - Serial digital interface standardized by SMPTE
HDMI - HD video and Audio
DisplayPort - digital audio/video interconnect by VESA
I would like to say that all capture devices are not necessary used in a
video chain or video system.
When it comes to machine vision, resolution and image quality can be
more interesting than timings.
I will postpone the discussion to your next point...
snip ---
/* timing data values specified by various standards such as BT.1120,
BT.656 etc. */
/* bt.656/bt.1120 timing data */
struct v4l2_bt_timings {
__u32 interlaced;
__u64 pixelclock;
__u32 width, height;
__u32 polarities;
__u32 hfrontporch, hsync, htotal;
__u32 vfrontporch, vsync, vtotal;
/* timings for bottom frame for interlaced formats */
__u32 il_vtotal;
__u32 reserved[16];
};
interlaced - Interlaced or progressive. use following values:-
#define V4L2_DV_INTERLACED 0
#define V4L2_DV_PROGRESSIVE1
pixelclock - expressed in HZ. So for 74.25MHz, use 7425.
width - number of pixels in horizontal direction
height - number of lines in vertical direction
polarities - Bit mask for following polarities to begin with
#define V4L2_DV_VSYNC_POS_POL0x1
#define V4L2_DV_VSYNC_NEG_POL0x2
#define V4L2_DV_HSYNC_POS_POL0x3
#define V4L2_DV_HSYNC_NEG_POL0x4
hfrontporch,hsync, and htotal for horizontal direction and
vfrontporch,vsync, and vtotal for vertical direction. il_vtotal is the
number of vertical lines for interlaced video for bottom field.
To define a particular timing type, following enum is used:-
enum v4l2_dv_timings_type {
V4L2_DV_BT_656_1120,
};
This will allow adding new timing types in the future.
Let's say we have a CMOS sensor, with a driver implementing this various
timings, because the driver writer was video oriented.
Now here comes another person, who is interested in another set of
features :
width,
height
col_start
row_start
And he wants autoexposure and don't care about the framerate.
How does he extends the driver ?
Is there a way to set the resolution without going through a standard.
What should he do ?
Add another timing_type ?
Yes. I realized that the RFC doesn't address the camera requirement.
I am using MT9T031/MT9T001/MT9P031 in my response below because that is
what I am familiar with. In these sensors there are two mode of operation,
continuous mode and Snapshot mode.
The video timing is relevant to continuous mode where the rows and columns
are read out along with pixel clock, hsync and vsync signals to the output bus.
So video timing is quite relevant here. Even though there are no
input interface for this similar to video decoders, the output timing to
the bus is still based the settings for row size, column size, blanking
interval etc. In TI's internal release, we have following parameters
for sensor driver as a static table for each of the resolution frames
output to bus. We maintain following values for a given resolution and fps
column_size, row_size, h_blank, v_blank, shutter_width, row_addr_mode,
col_addr_mode, row_start, col_start etc
So when a particular resolution capture is set by user, driver will configure
sensor with these values (done using S_STD currently).
In the MT9T031 driver available in v4l2 sub system today, my understanding is
that some of these values are taken from S_FMT such as width (column_size),
height (row_size). row_start and col_start comes form S_CROP. Some of these
values are fixed such as h_blank and v_blank. So I think Hans proposal will
work to support both these cases.
Also there are sensors that can support BT timing as well. So these will be
able to use preset or dv_timigs.
Based on the feedback so far, So I propose to make following
additions/modifications to the RFC. we define following capabilities:-
case 1) Analog TVs at input/output
add following capability flag for existing v4l2_std_id,
#define V4L2_IO_CAP_STD 0x0001
This way application knows driver supports standard STD ids for NTSC/PAL/SECAM
case 2) Video timings presets at output/input
To support preset add following capability flag.
#define V4L2_IO_CAP_PRESETS 0x0002
struct v4l2_dv_preset {
__u32 preset;
__u32 reserved[4];
};
case 3) Camera where frame rate changes with exposure where frame_rate
is fixed (pre-defined in the driver). Both these needs frame size (width and
height). In former case frame rate is based on other factors such as exposure,
shutter width etc.
To support camera timing that can be based on width, height, frame rate add
following capability flag:-
/* where only width and height can be assured, but not frame rate */
#define V4L2_IO_CAP_FRAME_SIZE 0x0004
/*
RE: RFC: V4L - Support for video timings at the input/output interface
Hans,
I was busy with some of the merge work and also some other issues.
So this delayed response...
Thanks for your work on this!
You are most welcome !
Where preset is one of the following values:-
#defineV4L2_DV_CUSTOM0x
#define V4L2_DV_480I59_94 0x0001
#define V4L2_DV_480I600x0002
#define V4L2_DV_480P23_9760x0003
#define V4L2_DV_480P240x0004
#define V4L2_DV_480P29_97 0x0005
#define V4L2_DV_480P300x0006
#define V4L2_DV_576I500x0007
#define V4L2_DV_576P250x0008
#define V4L2_DV_576P500x0009
#define V4L2_DV_720P23_9760x000A
#define V4L2_DV_720P240x000B
#define V4L2_DV_720P250x000C
#define V4L2_DV_720P29_97 0x000C
I need to correct this and below for value.
#define V4L2_DV_720P300x000D
#define V4L2_DV_720P500x000E
#define V4L2_DV_720P59_94 0x000F
#define V4L2_DV_720P600x0010
#define V4L2_DV_1080I50 0x0011
#define V4L2_DV_1080I59_940x0012
#define V4L2_DV_1080I60 0x0013
#define V4L2_DV_1080P23_976 0x0014
#define V4L2_DV_1080P24 0x0015
#define V4L2_DV_1080P25 0x0016
#define V4L2_DV_1080P29_970x0017
#define V4L2_DV_1080P30 0x0018
#define V4L2_DV_1080P60 0x0019
where capabilities are:-
#define V4L2_SUPPORTS_PRESETS0x0001
#define V4L2_SUPPORTS_CUSTOM_TIMINGS 0x0002
Rather than use 'SUPPORTS' we should rename it as 'IO_CAP'. That's more in
line with the existing naming conventions.
I also suggest adding V4L2_IO_CAP_STD if the regular S_STD is supported.
This will require going through the code and adding it, although we can
probably also set these caps in v4l2-ioctl automatically.
Ok.
For setting custom timing at the device, following structure is used
which defines the complete set of timing values required at the input and
output interface:-
/* timing data values specified by various standards such as BT.1120,
BT.656 etc. */
/* bt.656/bt.1120 timing data */
struct v4l2_bt_timings {
__u32 interlaced;
__u64 pixelclock;
__u32 width, height;
__u32 polarities;
__u32 hfrontporch, hsync, htotal;
__u32 vfrontporch, vsync, vtotal;
/* timings for bottom frame for interlaced formats */
__u32 il_vtotal;
__u32 reserved[16];
};
interlaced - Interlaced or progressive. use following values:-
#define V4L2_DV_INTERLACED 0
#define V4L2_DV_PROGRESSIVE1
pixelclock - expressed in HZ. So for 74.25MHz, use 7425.
width - number of pixels in horizontal direction
height - number of lines in vertical direction
polarities - Bit mask for following polarities to begin with
#define V4L2_DV_VSYNC_POS_POL0x1
#define V4L2_DV_VSYNC_NEG_POL0x2
#define V4L2_DV_HSYNC_POS_POL0x3
#define V4L2_DV_HSYNC_NEG_POL0x4
Why have separate pos and neg bits? Also, bitmask defines should define the
actual mask, not the bit numbers.
Oops! That was your original comment. Need to change these to masks.
as
#define V4L2_DV_VSYNC_POS_POL0x0001
#define V4L2_DV_VSYNC_NEG_POL0x0002
#define V4L2_DV_HSYNC_POS_POL0x0004
#define V4L2_DV_HSYNC_NEG_POL0x0008
Here is your comment earlier...
==
pixelclock - expressed in HZ. So for 74.25MHz, use 7425.
width - number of pixels in horizontal direction
height - number of lines in vertical direction
polarities - Bit mask for following polarities to begin with
#define V4L2_DV_VSYNC_POL0x1
#define V4L2_DV_HSYNC_POL0x2
I suggest a name like V4L2_DV_VSYNC_POS_POL 0x1 to signify that this sets
positive polarity.
=
Open issues
---
1.How to handle an HDMI transmitter? It can be put in two different
modes: DVI compatible
or HDMI compatible. Some of the choices are
a) enumerate them as two different outputs when enumerating.
b) adding a status bit on the input.
c) change it using a control
The same is also true for a receiver, BTW. They usually can detect whether
the
input is in HDMI or DVI mode.
2. Detecting whether there is an analog or digital signal on an DVI-I
input:
a) add new status field value for v4l2_input ?
#define V4L2_IN_ST_DVI_ANALOG_DETECTED0x1000
#define V4L2_IN_ST_DVI_DITIGITAL_DETECTED 0x2000
Typo: DIGITAL.
Ok.
I don't think this has to be DVI specific. Just 'ST_DETECTED_ANALOG' and
ST_DETECTED_DIGITAL' should be sufficient and it is more general as well.
Ok
3. Detecting an EDID.
a) adding a status field in v4l2_output and two new ioctls that
RE: RFC: V4L - Support for video timings at the input/output interface
Hi, 6. HDMI requires additional investigation. HDMI defines a whole bunch of infoframe fields. Most of these can probably be exported as controls?? Is HDMI audio handled by alsa? 7. how does this interface/co-exist with something like DSS2 on the omap3? who will own e.g. HDMI setup, DSS2 or V4L2? I still don't know what DSS2 is capable of doing. Will DSS2 work with v4l2 sub devices? If so, this RFC applies. I think DSS2 uses its own interface to integrate a encoder device. Besides it uses (I believe) sysfs to change the standards at the output. So I don't have an answer to your question. I will let DSS2 owner to respond. Murali -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: V4L - Support for video timings at the input/output interface
On Wednesday 16 September 2009 23:04:42 Karicheri, Muralidharan wrote:
Hans,
I was busy with some of the merge work and also some other issues.
So this delayed response...
Thanks for your work on this!
You are most welcome !
snip
pixelclock - expressed in HZ. So for 74.25MHz, use 7425.
width - number of pixels in horizontal direction
height - number of lines in vertical direction
polarities - Bit mask for following polarities to begin with
#define V4L2_DV_VSYNC_POS_POL0x1
#define V4L2_DV_VSYNC_NEG_POL0x2
#define V4L2_DV_HSYNC_POS_POL0x3
#define V4L2_DV_HSYNC_NEG_POL0x4
Why have separate pos and neg bits? Also, bitmask defines should define the
actual mask, not the bit numbers.
Oops! That was your original comment. Need to change these to masks.
as
#define V4L2_DV_VSYNC_POS_POL0x0001
#define V4L2_DV_VSYNC_NEG_POL0x0002
#define V4L2_DV_HSYNC_POS_POL0x0004
#define V4L2_DV_HSYNC_NEG_POL0x0008
Sorry, but why the NEG_POL masks? This is sufficient:
#define V4L2_DV_VSYNC_POS_POL0x0001
#define V4L2_DV_HSYNC_POS_POL0x0002
If you don't set the bit then the polarity is negative (0 bitvalue, so
negative).
7. How to use S_DV_TIMINGS to setup a sensor.
Sensors can be setup either using the full DV_TIMINGS functionality (e.g.
pixelclock, porches, sync width, etc.) or with a subset only: width,
height,
frame period. The latter can already be setup with S_PARM (but do we
want
that? S_PARM is very, very ugly). I am thinking of creating a new
DV_TIMINGS
type for this with just width, height and frame period.
But this leads to another complication: how to tell the user which
timings
type to use? Easiest way is to use the capabilities field:
CAP_BT_TIMINGS,
CAP_FRAME_TIMINGS. Of course, this limits the number of possible timings
we can define. The alternative is to add yet another field that contains
the actual timings type. But I think this is overkill.
How about adding two capability flag - CAP_FIXED_FRAME_RATE and
CAP_VARIABLE_FRAME_RATE? and change preset type to
struct v4l2_dv_preset {
__u32 preset;
v4l2_fract fps;
__u32 reserved[4];
};
Where preset can be just referring a resolution and scan type.
#define V4L2_DV_720X480P 0x0001
#define V4L2_DV_640X480P 0x0002
#define V4L2_DV_720X576P 0x0003
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.
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. 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
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: V4L - Support for video timings at the input/output interface
Hi Murali,
Thanks for your work on this!
See below for a few notes I made.
On Monday 14 September 2009 15:51:28 Karicheri, Muralidharan wrote:
RFC: V4L - Support for video timings at the input/output interface
Thanks to Hans Verkuil for his initial proposal and feedbacks to help write
this RFC.
Version : 1.0
Background
---
Currently v4l2 specification supports capturing video frames from TV signals
using tuners (input type V4L2_INPUT_TYPE_TUNER) and baseband TV signals
(V4L2_INPUT_TYPE_CAMERA) and sensors. Similarly on the output side, the
signals could be TV signal (V4L2_OUTPUT_TYPE_MODULATOR), baseband TV signal
(V4L2_OUTPUT_TYPE_ANALOG) or hybrid analog VGA overlay
(V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY) which output from a graphics card and
then use chromakeying to replace part of the picture with the video.
V4L2_OUTPUT_TYPE_ANALOG V4L2_INPUT_TYPE_CAMERA are for analog interfaces
that includes composite, S-Video and VGA (for output only). Note that even
though VGA is a supported output, we don't have anyway to set the standard or
timing on the output. Standard ids are only defined for TVs using
v4l2_std_id and a set of bit masks defined for analog TV standards.
Today we have a wide variety of different interfaces available to
transmit/receive video or graphics content between source device and
destination device. Following are some of the interfaces used in addition to
the ones described in the v4l2 specification.
Component analog input/output interface - ED/HD video
DVI - Digital only, ANALOG only, DVI integrated that support Digital and
Analog; Dual Link - Where second data link is used for higher
bandwidth
SDI - Serial digital interface standardized by SMPTE
HDMI - HD video and Audio
DisplayPort - digital audio/video interconnect by VESA
V4L2 specification currently defined NTSC/PAL/SECAM (all variants) standards
for describing the timing of the signal transmitted over these interfaces.
Even though the specification defined ANALOG output type for VGA, there are
no ways to set the timings used for output to VGA or LCD display monitors.
Some of the proprietary implementations used existing standards IOCTL,
VIDIOC_S_STD, to set these timings over these interfaces.
For example, TI has Video Processing Back End (VPBE) on various media SOCs
(Eg, DM6446, DM355 etc) that can output signal for Analog TV and VGA
interfaces (using Digital LCD port) and support timing for displaying SD and
HD videos (1080i, 1080p and 720p) as well as over VGA interface to a CRT or
LCD display monitor. So we need to enhance the v4l2 specification to allow
applications to set these timings in the capture or output devices. This RFC
proposes to add new IOCTLs for setting/getting timings over the different
interfaces described above and freeze the the use of existing standards
IOCTL and standards IDs for analog TVs only.
Timings
---
The timing at the analog or digital interface that are not covered by the
v4l2_std_id can be defined using a set of preset timings that are used by the
hardware where these timings are predefined or by a set of timing values
which can be configured at the hardware to generate the signal expected at
the interface. The former will be used for hardware like TVP7002/THS8200
which specifies preset timing required for output HD video such 1080i50/60,
720p50/60 etc. The latter can be used for hardware that require configuration
of frame timing such as front porch, hsync length, vsync length, pixel clock
etc. For example the earlier mentioned TI SOCs has a Digital LCD port that
can be configured to output different timing values expected by LCD Display
monitors.
Preset timings (defined by VESA, SMPTE or BT.656/BT.1120 or others) can be
defined by the following structure:-
struct v4l2_dv_preset {
__u32 preset;
__u32 reserved[4];
};
Where preset is one of the following values:-
#define V4L2_DV_CUSTOM0x
#define V4L2_DV_480I59_94 0x0001
#define V4L2_DV_480I600x0002
#define V4L2_DV_480P23_9760x0003
#define V4L2_DV_480P240x0004
#define V4L2_DV_480P29_97 0x0005
#define V4L2_DV_480P300x0006
#define V4L2_DV_576I500x0007
#define V4L2_DV_576P250x0008
#define V4L2_DV_576P500x0009
#define V4L2_DV_720P23_9760x000A
#define V4L2_DV_720P240x000B
#define V4L2_DV_720P250x000C
#define V4L2_DV_720P29_97 0x000C
#define V4L2_DV_720P300x000D
#define V4L2_DV_720P500x000E
#define V4L2_DV_720P59_94 0x000F
#define V4L2_DV_720P600x0010
#define V4L2_DV_1080I50 0x0011
#define V4L2_DV_1080I59_940x0012
#define V4L2_DV_1080I60
Re: RFC: V4L - Support for video timings at the input/output interface
Karicheri, Muralidharan wrote: snip Open issues --- 1.How to handle an HDMI transmitter? It can be put in two different modes: DVI compatible or HDMI compatible. Some of the choices are a) enumerate them as two different outputs when enumerating. b) adding a status bit on the input. c) change it using a control 2. Detecting whether there is an analog or digital signal on an DVI-I input: a) add new status field value for v4l2_input ? #define V4L2_IN_ST_DVI_ANALOG_DETECTED0x1000 #define V4L2_IN_ST_DVI_DITIGITAL_DETECTED 0x2000 3. Detecting an EDID. a) adding a status field in v4l2_output and two new ioctls that can set the EDID for an input or retrieve it for an output. It should also be added as an input/output capability. 4. ATSC bits in v4l2_std_id: how are they used? Are they used at all for that matter? 6. HDMI requires additional investigation. HDMI defines a whole bunch of infoframe fields. Most of these can probably be exported as controls?? Is HDMI audio handled by alsa? 7. how does this interface/co-exist with something like DSS2 on the omap3? who will own e.g. HDMI setup, DSS2 or V4L2? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: V4L - Support for video timings at the input/output interface
Karicheri, Muralidharan a écrit :
RFC: V4L - Support for video timings at the input/output interface
Thanks to Hans Verkuil for his initial proposal and feedbacks to help write
this RFC.
Version : 1.0
Thank you for this work.
I have a few questions, regarding the other parameters or existing control.
Background
---
Currently v4l2 specification supports capturing video frames from TV signals
using tuners (input type V4L2_INPUT_TYPE_TUNER) and baseband TV signals
(V4L2_INPUT_TYPE_CAMERA) and sensors. Similarly on the output side, the signals
could be TV signal (V4L2_OUTPUT_TYPE_MODULATOR), baseband TV signal
(V4L2_OUTPUT_TYPE_ANALOG) or hybrid analog VGA overlay
(V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY) which output from a graphics card and
then use chromakeying to replace part of the picture with the video.
V4L2_OUTPUT_TYPE_ANALOG V4L2_INPUT_TYPE_CAMERA are for analog interfaces that
includes composite, S-Video and VGA (for output only). Note that even though VGA is
a supported output, we don't have anyway to set the standard or timing on the
output. Standard ids are only defined for TVs using
v4l2_std_id and a set of bit masks defined for analog TV standards.
Today we have a wide variety of different interfaces available to
transmit/receive video or graphics content between source device and
destination device. Following are some of the interfaces used in addition to
the ones described in the v4l2 specification.
Component analog input/output interface - ED/HD video
DVI - Digital only, ANALOG only, DVI integrated that support Digital and
Analog; Dual Link - Where second data link is used for higher
bandwidth
SDI - Serial digital interface standardized by SMPTE
HDMI - HD video and Audio
DisplayPort - digital audio/video interconnect by VESA
I would like to say that all capture devices are not necessary used in a
video chain or video system.
When it comes to machine vision, resolution and image quality can be
more interesting than timings.
snip ---
/* timing data values specified by various standards such as BT.1120, BT.656
etc. */
/* bt.656/bt.1120 timing data */
struct v4l2_bt_timings {
__u32 interlaced;
__u64 pixelclock;
__u32 width, height;
__u32 polarities;
__u32 hfrontporch, hsync, htotal;
__u32 vfrontporch, vsync, vtotal;
/* timings for bottom frame for interlaced formats */
__u32 il_vtotal;
__u32 reserved[16];
};
interlaced - Interlaced or progressive. use following values:-
#define V4L2_DV_INTERLACED 0
#define V4L2_DV_PROGRESSIVE1
pixelclock - expressed in HZ. So for 74.25MHz, use 7425.
width - number of pixels in horizontal direction
height - number of lines in vertical direction
polarities - Bit mask for following polarities to begin with
#define V4L2_DV_VSYNC_POS_POL0x1
#define V4L2_DV_VSYNC_NEG_POL0x2
#define V4L2_DV_HSYNC_POS_POL0x3
#define V4L2_DV_HSYNC_NEG_POL0x4
hfrontporch,hsync, and htotal for horizontal direction and vfrontporch,vsync, and vtotal for vertical direction. il_vtotal is the number of vertical lines for interlaced video for bottom field.
To define a particular timing type, following enum is used:-
enum v4l2_dv_timings_type {
V4L2_DV_BT_656_1120,
};
This will allow adding new timing types in the future.
Let's say we have a CMOS sensor, with a driver implementing this various
timings, because the driver writer was video oriented.
Now here comes another person, who is interested in another set of
features :
width,
height
col_start
row_start
And he wants autoexposure and don't care about the framerate.
How does he extends the driver ?
Is there a way to set the resolution without going through a standard.
What should he do ?
Add another timing_type ?
Use the S_FMT, G_FMT, TRY_FMT ioctl ?
But then what happens when one does a G_DV_TIMINGS ?
Should a new v4l2_dv_timings_type be defined ?
But it is not a timing we are talking about, it is a geometry.
CMOS sensor presents overlapping feature sets :
Resolution + timing is one.
Resolution + windows position + exposure is another.
Resolution + zoom level is yet another
Let's say a driver is written using the VIDIOC_S/G_DV_TIMINGS.
It should be easy to use the same driver with S/G_FMT or S/G_CROP, even
if it leads to a format you can't describe with VIDIOC_S/G_DV_TIMINGS.
I mean, we are heading to a situation where you can set :
hfrontporch, vfrontporch, htotal, vtotal.
But if you want to set :
row_start, col_start, shutter_width, bining or decimation, you have to
write some custom control.
Now if you look at video capture port and cmos sensor :
- video capture hardware cares about polarities, interlacing, and
pixelcount. They don't care about hfrontporch htotal, as long as it is
over some minimum value.
- CMOS sensor gives you custom size and windows position, bining and
skipping, shutter width.
They give some control over vsync. but not always.
This timings might be interesting
