Index: [thread] [date] [subject] [author]
  From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: 06 Nov 1999 19:59:44 +0100

Re: yuyv reprentation in ggi

Jan Kneschke <jan@kneschke.de> writes:

> currently i try to find a way to set up a YUV-crossblit in ggi. GGI has no
> support for it yet. neither a GT_YUV422 nor a abstract and fitting
> pixel-model. 
> ggi_pixel_format only supports buffers that can be accessed by a shift-mask.
> YUV422 is a common color-format most often used by tv-cards, mpeg-movies and
> the like. two pixels are represented by 4 bytes:
> 
> Y1U1Y2V1Y3U2Y4V2....
> | | | |
> 
> Y1, U1 and V1 is the first pixel.
> Y2, U1 and V1 is the second pixel.
> and so on.
> 
> ok. this one can be implented in ggi. i don't know, but i'm sure it can be
> done. the next one is trickier.
> 
> YUV411:
> 
> Y1U1Y2U2.......
> YaV1YbV2......
> 
> U and V are transmitted in two lines. GGI can't handle this.
> 
> but hey, as far as i know accelerated color-space conversion is most often
>  done YUV422(packed) -> RGB, so lets try to get this one defined.
> 
> one solution could be the conversion from YUV422(packed) to YUV422(planar)
> were you seperate the components into 3 buffers (Y1Y2Y3Y4)(V1V2)(U1U2) like
> those bit-plane modes. but this wont give us the directbuffer a currently
> need for ggitv.
> 
> all i want is a visual i can crossblit to another visual. the source would
> be YUV422 and the destination a KGI(con)-visual that converts YUV422->RGB in
> hardware. 
> 
> has someone a idea how intergrate it in ggi ??

The answer is simple: forget everything about crossblit and YUV-visuals.

Visuals are heavy-weight objects, and should never be used for
images, pixmaps or video-streams.

Things like this belong in the yet-to-be-written LibGBLIT extension.
It will handle blitting images in all kinds of formats, including
YUV and other colorspaces, with hardware acceleration if available,
from both main-memory (via AGP or DMA when available) and on-board
memory.

You are welcome to come up with an initial framework for this
extension. Just remember to keep it simple, but flexible, in the
beginning. Then we'll expand it as necessary later.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se


Index: [thread] [date] [subject] [author]