RE: [RFC] Adding new ioctl for transparency color keying

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

 




> -----Original Message-----
> From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx]
> Sent: Tuesday, January 27, 2009 3:21 PM
> To: Shah, Hardik
> Cc: linux-media@xxxxxxxxxxxxxxx; video4linux-list@xxxxxxxxxx
> Subject: Re: [RFC] Adding new ioctl for transparency color keying
> 
> Hi Hardik,
> 
> On Thursday 22 January 2009 05:57:18 Shah, Hardik wrote:
> > Hi,
> > OMAP class of device supports transparency color keying.  Color keying
> > can be source color keying or destination color keying.
> 
> Can it be both as well?
> 
> > OMAP3 has three pipelines one graphics plane and two video planes.  Any
> > of these pipelines can go to either the TV or LCD.
> >
> > The destination transparency color key value defines the encoded pixels
> > in the graphics layer to become transparent and display the underlying
> > video pixels. While the source transparency key value defines the encoded
> > pixels in the video layer to become transparent and display the
> > underlying graphics pixels.  This color keying works only if the video
> > and graphics planes are on the same output like TV or LCD and images of
> > both the pipelines overlapped.
> >
> > I propose to have the one ioctl to set the encoded pixel value and type
> > of color keying source and destination.  Also we should have the CID to
> > enable/disable the color keying functionality.
> >
> > Please let us know your opinions/comments.
> 
> Destination color keying is already available through the S_FBUF and S_FMT
> ioctls. Selecting source color keying can easily be added to S_FBUF, but
> setting the actual chromakey is harder. The logical place would be the
> v4l2_pix_format struct, but that is already full. I guess we should make a
> new control to set the source chromakey. It's not ideal, but it prevents
> duplicating existing functionality.
> 
[Shah, Hardik] Hi Hans,
This has nothing to do with the frame buffer.  Transparency key is a hardware provided feature.  Driver has just to give the color code and whether it wants the source color keying or destination color keying.  Hardware will automatically make the color code transparent so that the below layer color will be seen. So I don't think so that S_FBUF is suitable for this kind of feature. And this will automatically take effect if the graphics pipeline is on the same output device as the video pipeline.  

Regards,
Hardik Shah 
> Regards,
> 
> 	Hans
> 
> --
> Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
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