RFC: Changes to preset handling

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

 



There has been some discussion recently regarding the preset API:

http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg33774.html

The current presets are:

#define         V4L2_DV_INVALID         0
#define         V4L2_DV_480P59_94       1 /* BT.1362 */
#define         V4L2_DV_576P50          2 /* BT.1362 */
#define         V4L2_DV_720P24          3 /* SMPTE 296M */
#define         V4L2_DV_720P25          4 /* SMPTE 296M */
#define         V4L2_DV_720P30          5 /* SMPTE 296M */
#define         V4L2_DV_720P50          6 /* SMPTE 296M */
#define         V4L2_DV_720P59_94       7 /* SMPTE 274M */
#define         V4L2_DV_720P60          8 /* SMPTE 274M/296M */
#define         V4L2_DV_1080I29_97      9 /* BT.1120/ SMPTE 274M */
#define         V4L2_DV_1080I30         10 /* BT.1120/ SMPTE 274M */
#define         V4L2_DV_1080I25         11 /* BT.1120 */
#define         V4L2_DV_1080I50         12 /* SMPTE 296M */
#define         V4L2_DV_1080I60         13 /* SMPTE 296M */
#define         V4L2_DV_1080P24         14 /* SMPTE 296M */
#define         V4L2_DV_1080P25         15 /* SMPTE 296M */
#define         V4L2_DV_1080P30         16 /* SMPTE 296M */
#define         V4L2_DV_1080P50         17 /* BT.1120 */
#define         V4L2_DV_1080P60         18 /* BT.1120 */

One thing that needs to change is that the comments should refer to the
CEA-861 standard since all these presets are from that document. The other
thing is that the macros should contain the name of the standard and the
exact resolution. This allows for adding presets from other standards
such as the VESA DMT standard.

The proposed list of presets would look like this:

#define         V4L2_DV_INVALID                    0
#define         V4L2_DV_CEA861_720X480P59_94       1 /* CEA-861, VIC 2, 3 */
#define         V4L2_DV_480P59_94       V4L2_DV_CEA861_720X480P59_94
#define         V4L2_DV_CEA861_720X576P50          2 /* CEA-861, VIC 17, 18 */
#define         V4L2_DV_576P50          V4L2_DV_CEA861_720X576P50
#define         V4L2_DV_CEA861_1280X720P24         3 /* CEA-861, VIC 60 */
#define         V4L2_DV_720P24          V4L2_DV_CEA861_1280X720P24
...
#define         V4L2_DV_CEA861_1280X720P59_94      7 /* CEA-861, VIC 4 */
#define         V4L2_DV_720P59_94       V4L2_DV_CEA861_1280X720P59_94
#define         V4L2_DV_CEA861_1280X720P60         8 /* CEA-861, VIC 4 */
#define         V4L2_DV_720P60          V4L2_DV_CEA861_1280X720P60
...

The old names become aliases to the new ones.

I would also like to reserve the range 1-65535 for the CEA presets, so a comment
is needed for this.

The other part that needs to be extended is struct v4l2_dv_enum_presets. Currently
this returns a human readable description of the format and the width and height.

What is missing is the fps or frame period and a flags field that can tell whether
this is an interlaced or progressive format.

So I propose to extend the struct as follows:

struct v4l2_dv_enum_preset {
        __u32   index;
        __u32   preset;
        __u8    name[32]; /* Name of the preset timing */
        __u32   width;
        __u32   height;
        struct v4l2_fract fps;
        __u32   flags;
        __u32   reserved[1];
};

#define V4L2_DV_ENUM_FL_INTERLACED (1 << 0)

What is better: that the v4l2_fract represents frames-per-second or that it represents
time-per-frame? G/S_PARM uses the latter, but I find the first more logical.

Another thing that is missing in VIDIOC_ENUM_DV_PRESETS is that you cannot put in a
specific preset and get back this information. Instead it is index based. This is fine
when you want to enumerate all available presets, but it is annoying when you want to
find the specifics one particular preset.

I propose that we define a specific index value (e.g. 0x80000000) that will let the
driver return the information about the preset instead (or -EINVAL if the preset is
not supported by the driver). So:

#define V4L2_DV_ENUM_USE_PRESET 0x80000000

A separate issue is how to handle calculated modes based on the VESA GTF and CVT
standards. For a video transmitter the VIDIOC_S_DV_TIMINGS can be used, although
the application has to do the calculations. For video receiving things are much
more complex. This needs more research. There are several possibilities, but it
isn't clear which works best. Some experimentation is needed, but due to vacations
this will have to be postponed.

Comment?

	Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux