|
|
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
Hi Vaibhav!
This is a bit of a 'blast from the past', but when I went through the
documentation of the framebuffer flags in the V4L2 spec I noticed that the
definition of V4L2_FBUF_CAP_SRC_CHROMAKEY seemed to be wrong.
The definition of V4L2_FBUF_CAP_CHROMAKEY says:
'The device supports clipping by chroma-keying the
images. That is, image pixels replace pixels in the VGA or video
signal only where the latter assume a certain color. Chroma-keying
makes no sense for destructive overlays.'
The definition of V4L2_FBUF_CAP_SRC_CHROMAKEY says:
'The device supports Source Chroma-keying. Framebuffer pixels
with the chroma-key colors are replaced by video pixels, which
is exactly opposite of V4L2_FBUF_CAP_CHROMAKEY.'
As far as I can tell these definitions are really the same. I would expect
that V4L2_FBUF_CAP_SRC_CHROMAKEY was defined as:
'The device supports Source Chroma-keying. Video pixels
with the chroma-key colors are replaced by framebuffer pixels, which
is exactly opposite of V4L2_FBUF_CAP_CHROMAKEY.'
The only driver that implements this is omap_vout.c. So is the mistake
in the documentation or in the driver? I think the documentation is wrong
in this case.
Regards,
Hans
On Tuesday, November 10, 2009 15:45:45 hvaibhav@xxxxxx wrote:
> From: Vaibhav Hiremath <hvaibhav@xxxxxx>
>
>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@xxxxxx>
> ---
> linux/Documentation/DocBook/v4l/videodev2.h.xml | 2 ++
> linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml | 17 +++++++++++++++++
> 2 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml b/linux/Documentation/DocBook/v4l/videodev2.h.xml
> index 9700206..eef7ba4 100644
> --- a/linux/Documentation/DocBook/v4l/videodev2.h.xml
> +++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml
> @@ -565,6 +565,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> {
> #define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010
> #define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
> #define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040
> +#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080
> /* Flags for the 'flags' field. */
> #define V4L2_FBUF_FLAG_PRIMARY 0x0001
> #define V4L2_FBUF_FLAG_OVERLAY 0x0002
> @@ -572,6 +573,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> {
> #define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008
> #define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010
> #define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
> +#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040
>
> struct <link linkend="v4l2-clip">v4l2_clip</link> {
> struct <link linkend="v4l2-rect">v4l2_rect</link> c;
> diff --git a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml
> index f701706..e7dda48 100644
> --- a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml
> +++ b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml
> @@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for destructive overlays.</entry>
> inverted alpha channel of the framebuffer or VGA signal. Alpha
> blending makes no sense for destructive overlays.</entry>
> </row>
> + <row>
> + <entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry>
> + <entry>0x0080</entry>
> + <entry>The device supports Source Chroma-keying. Framebuffer pixels
> +with the chroma-key colors are replaced by video pixels, which is exactly opposite of
> +<constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry>
> + </row>
> </tbody>
> </tgroup>
> </table>
> @@ -411,6 +418,16 @@ images, but with an inverted alpha value. The blend function is:
> output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The
> actual alpha depth depends on the framebuffer pixel format.</entry>
> </row>
> + <row>
> + <entry><constant>V4L2_FBUF_FLAG_SRC_CHROMAKEY</constant></entry>
> + <entry>0x0040</entry>
> + <entry>Use source chroma-keying. The source chroma-key color is
> +determined by the <structfield>chromakey</structfield> field of
> +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref
> +linkend="overlay" /> and <xref linkend="osd" />.
> +Both chroma-keying are mutual exclusive to each other, so same
> +<structfield>chromakey</structfield> field of &v4l2-window; is being used.</entry>
> + </row>
> </tbody>
> </tgroup>
> </table>
>
--
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
|
|