hum… BTW, what is YUV Overlay ?
it’s unclear for me…
In simple words: It is a hardware level operation that makes the decoding
and performance of a Video playback (or DVDs) faster. Normally (depending on
the implementation) you may get 10-15% better video playback performance.
YUV are even better/faster than plain overlay (add an extra 5-10%). The
VideoLAN guys are using it, it mostly works with Matrox cards I think (at
least under BeOS ;-).
Eugenia
“Lloyd Dupont” wrote in message
news:mailman.996184566.8105.sdl at libsdl.org…> hum… BTW, what is YUV Overlay ?
it’s unclear for me…
Eugenia Loli-Queru wrote:
In simple words: It is a hardware level operation that makes the decoding
and performance of a Video playback (or DVDs) faster.
thanks for your reply…
… mmhh…
i am not really sure to completly understand. in fact i don’t even know
what
is an overlay.
with your post i guess that yuv overlay is some pixel format used for
video
encoding, but what is (simple) overlay ?
and how to read (a yuv overlay or whatever) it from a file ?
In simple words: It is a hardware level operation that makes the decoding
and performance of a Video playback (or DVDs) faster. Normally (depending on
the implementation) you may get 10-15% better video playback performance.
YUV are even better/faster than plain overlay (add an extra 5-10%). The
VideoLAN guys are using it, it mostly works with Matrox cards I think (at
least under BeOS ;-).“Lloyd Dupont” wrote in message
news:mailman.996184566.8105.sdl at libsdl.org…hum… BTW, what is YUV Overlay ?
I’d want to add that the important feature of YUV overlay is that it does
colorspace conversion without CPU. (If you’re familiar with print think
about RGB->CMYK conversion). In YUV color space Y defines brightness (sort
of) and U&V defines color. If you take a closer look how colors are
defined I think you agree when I say it’s a horrible color space to begin
with.
Why is this kind of color space used then you ask? It’s only because TVs
use it. Otherwise it would be HSV (which would have better image quality
for the same bit depth). However, it’s better than RGB when compressing
image because human eye is poor with colors and cannot tell if we discard
a lot of U&V if Y remains unchanged. Look around net for more information.
Oh, and hardware overlays usually give nice image scaling for free.
- MikkoOn Thu, 26 Jul 2001, Eugenia Loli-Queru wrote:
… mmhh…
i am not really sure to completly understand. in fact i don’t even know
what
is an overlay.
Color space conversion, overlay, and scaling are quite common to appear in
the video accelerating feature list of a graphics card. In video playback
systems, usually, the pixels within the decoded video are still being
represented in YUV (or YCbCr) color space. However, computer monitors only
accept RGB representations. Therefore, color space conversion from YUV (or
YCbCr) to RGB is a required step in the computer video playback system. Note
that the decoded YUV video is located at neither the frontbuffer nor the
backbuffer of the display memory. Instead, it is placed at a position
outside the framebuffers. The mechanism for displaying the decoded YUV video
at a specific position on the screen is named “overlay.” There is one
rectangle with a specific color (color key) in the framebuffer. For the
color key rectangle, the overlay hardware will take out the YUV video,
convert it into RGB video, and, finally, send it to the RAMDAC for display.
More information about the format itself here:
http://www.webartz.com/fourcc/indexyuv.htm
Eugenia
As it’s used for video, no-one should use it in uncompressed format in
file. I have used YUV overlay in YV12 format (check google) to render
images captured from TV-card. Full resolution PAL image is 768x576 and
it’s 25fps. If you consider that (768x768+384x384x2)x25 = 21MB which means
if you don’t compress the stream, it takes 21MB/s. …full CD can hold
almost 31 seconds!
I think you cannot use YUV overlay unless you capture video or display
decoded video format like MPEG[124]. If you generate video on the fly
you’d better use RGB formats, unless you’re doing monocrome only rendering
(I think U&V planes would be too much hasle). By the way, if you wan to do
monocrome rendering you have to set all pixels of Y&V values to the value
of 128 - if you leave them zeroed you get green screen instead.
- MikkoOn Fri, 27 Jul 2001, Lloyd Dupont wrote:
I’d want to add that the important feature of YUV overlay is that it does
and (still) do you know i could read it from a file ???
An overlay is a piece of offscreen memory that is “mapped” to onscreen
memory by the hardware. You write data to the offscreen memory and the
image data appears “magically” in an onscreen area.
The onscreen area is not modified by this magic. It’s like you have two
overhead transparency slides: the bottom one contains your desktop, the
top one contains your overlay window.
The overlay is also contiguous so you don’t need to add offsets between
each scanline of the image. This makes it much faster to transfer image
data to/from main memory and video memory.
Most overlays also let you scale the image. So you might write into the
overlay at 320x200 but display it onscreen at 1024x768. This is a truly
huge win (12x bandwidth savings on the PCI bus).
YUV overlays do colorspace conversions. They convert from YUV format (a
useful format for storing MPEG and JPEG) into RGB format. Doing this on
the main CPU would be very expensive.
YUV overlays are particularly useful for MPEG players.On Fri, Jul 27, 2001 at 12:05:33AM +0200, Lloyd Dupont wrote:
hum… BTW, what is YUV Overlay ?
it’s unclear for me…
–
The more I know about the WIN32 API the more I dislike it. It is complex and
for the most part poorly designed, inconsistent, and poorly documented.
- David Korn
I am working on a low bit-rate video decoder that uses
SDL’s YUV overlay for display output. The problem I
have is video tearing on the output display. The
basic program outline is like this:
SDL_Init(SDL_INIT_VIDEO);
screen = SDL_SetVideoMode(WIDTH, HEIGHT, DEPTH,
SDL_FULLSCREEN | SDL_DOUBLEBUF | SDL_SWSURFACE |
SDL_ANYFORMAT);
overlay = SDL_CreateYUVOverlay(WIDTH, HEIGHT,
SDL_YV12_OVERLAY, screen);
while(1)
{
/* decode next picture */
SDL_LockYUVOverlay(overlay);
/* memcpy yuv data to overlay->pixels[] here */
SDL_UnlockYUVOverlay(overlay);
SDL_DisplayYUVOverlay(overlay,&overlay_rect);
SDL_Flip(screen);
}
From the documentation I have read, using
SDL_DOUBLEBUF with SDL_FULLSCREEN should allow the
output to be free of tearing, provided SDL_Flip() is
used properly. I do have the env vars
SDL_VIDEO_YUV_DIRECT and SDL_VIDEO_YUV_HWACCEL set to
- I am using directx for SDL_VIDEODRIVER. I have
verified that overlay->hw_accel == 1 after
SDL_CreateYUVOverlay. Am I using it correctly? Am I
correct in assuming SDL_LockYUVOverlay() will block if
the flip is not yet complete?
Thanks,
Dan__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
I don’t think it is necessary to call SDL_Flip(). If you have a hardware
YUV overlay, SDL_DisplayYUVOverlay() should be enough to display it on
the screen. Try a single-buffered software surface instead.On Tuesday, June 18, 2002, at 06:26 PM, Dan Wetzel wrote:
SDL_Flip(screen);
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: text/enriched
Size: 350 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020619/a016d82d/attachment.bin
Hi all,
Will the code like following works?
overlay = SDL_CreateYUVOverlay(0, 0, format, surface) //create a 0*0
overlay first
//if there exists picture BufY[wh], BufU[wh/2], BufV[w*h/2].
overlay->pixels[0] = BufY;
overlay->pixels[1] = BufU;
overlay->pixels[2] = BufV;
overlay->pitches[0] = wh;
overlay->pitches[1] = wh/2;
overlay->pitches[2] = w*h/2;
overlay->w = w;
overlay->h = h;
SDL_DisplayYUVOverlay(overlay, rect);
will this code works fine, and display the updated overlay?
Thank you very much!
Regards,
Max