RFC V4L2 additions required for full cx23415 OSD and YUV support
Version 0.1
(Really, it's the last RFC. I promise. :-)
The Conexant cx23415 MPEG encoder/decoder features an On-Screen Display
framebuffer. It is able to overlay the image of the framebuffer on top
of the MPEG or YUV decoder output. The sizes and positions of the OSD
and the MPEG/YUV output do not have to match, it is for example
possible to have the OSD in one corner and the MPEG output in another
corner.
However, the usual case is that the OSD 'covers' the MPEG window.
If the OSD is turned off, then only the MPEG is visible. If it is on,
then the OSD hides the MPEG output (except for the parts outside the
OSD area).
The OSD has three methods of making the MPEG visible: a global alpha
setting, local alpha values (ARGB) or a chromakey. These three methods
can all be used at the same time, and can also be selectively activated
or deactivated.
A complicating matter is the YUV decoder: there are two methods of YUV
decoding: the first is by writing raw YUV frames to the output videoX
device. In this mode it works the same as MPEG output and the
functionality is limited to what the firmware supports. The second
method is by passing a YUV frame to the driver using an ioctl: with
this API the firmware is by-passed and the decoder is programmed
directly: this method lets you have more control with respect to
interlacing and progressive output.
This last method is used by the X driver for the Xv extension: it allows
for efficient playback of raw YUV from e.g. an MPEG4 software decoder.
However, this last method also locks the OSD framebuffer and the YUV
output window together: the OSD overlays the YUV window precisely.
The OSD framebuffer itself is implemented as a standard linux
framebuffer device and as such is out of scope for this API discussion.
In order to support the overlay functionality of the OSD however, some
v4l API extensions are needed. These changes are described below.
1) The current V4L2_BUF_TYPE_VIDEO_OVERLAY is a capture overlay, so a
new V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY is needed to support an output
overlay. It follows that a new capability flag
V4L2_CAP_VIDEO_OUTPUT_OVERLAY is also required. From the point of view
of ivtv the overlay is of the type V4L2_FBUF_CAP_EXTERNOVERLAY, and so
it will set that capability.
2) struct v4l2_window needs an extra field: __u8 global_alpha. This
allows setting the global alpha value (0-255) for an overlay. A value
of 0 makes the framebuffer transparent so it shows the MPEG or YUV
output, a value of 255 makes the framebuffer fully opaque so you only
see the framebuffer contents.
3) struct framebuffer changes: two new capabilities:
V4L2_FBUF_CAP_GLOBAL_ALPHA and V4L2_FBUF_CAP_LOCAL_ALPHA. Also two
framebuffer flags: V4L2_FBUF_FLAG_GLOBAL_ALPHA and
V4L2_FBUF_FLAG_LOCAL_ALPHA.
4) The YUV decoder (at least the version that by-passes the firmware)
requires some additional interlaced options for the v4l2_field enum
that can be set with VIDIOC_S_FMT: V4L2_FIELD_INTERLACED_TB and
V4L2_FIELD_INTERLACED_BT.
Images contain both fields, interleaved line by line. The top field is
stored first. In the case of V4L2_FIELD_INTERLACED_TB the top field is
transmitted first, in the case of V4L2_FIELD_INTERLACED_BT the bottom
field is transmitted first.
Apparently NTSC DVDs are inconsistent in their field order, so with
these enums it is possible to transmit them in the correct order,
independent of the chosen TV standard.
This concludes this RFC. Comments are welcome!
Regards,
Hans Verkuil
_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
