YUV overlay hardware support

SDL Development
1

Hi,
I’ve been using SDL a fair bit for various little projects over the past
few years, but I’ve probably only used a small proportion of it. In
particular, I’ve never tried to use YUV overlays before: I’ve had little
reason, and they seem to be one of the least discussed parts of it.

Now OTOH, I’m considering maybe possibly putting in some Dirac-encoded
FMV sequences in the little game I’m working on. I’ve got roughly the
idea of how I’m supposed to use the overlay functions, from reading the
docs, wiki, and the few other bits of example code that I’ve been able
to find, but I’m left wondering about hardware support:

-I gather that SDL can tell, after creating an overlay, whether or not it
is a hardware accelerated one, and that this will (amongst other things?
I’m not sure) depend on whether the particular YUV format chosen was one
supported directly by the hardware. I understand these should handle both
YUV->RGB translation and(?) scaling, and make a big speed difference, at
least on older machines.

-I also gather that most codecs will probably support some YUV formats
more directly than others. I presume translating from one sampling format
to another is a fair bit of overhead. (Dirac apparently supports planar
4:4:4, 4:2:2, and 4:2:0, although these format names still leave me a bit
mystified)

So anyway, I’m wondering how can I best figure out which YUV formats
(if any) the machine does support directly in hardware? Is it possible?
Would I have to try each type in turn and check the flags? Are there other
requirements to fullfill in order to get hardware overlays? And if there’s
a choice, which ones should I prefer in order to keep things fast? I’d
naively expect that whatever sends least data would be fastest, but maybe
not if downsampling, interleaving, etc adds overhead :stuck_out_tongue: Or maybe that step
is never a speed problem.

As I’d have to make the video sequences as well, I might still not do
it even if the code is simple, but I’d like to find out as much as I can
before I get in way over my head! :smiley: (it could at least make a useful
addition to the wiki anyway)

Many thanks in advance,
-Tom Barnes-Lawrence–
I think I need a new signature

2

Please see the theora example player attached.
It is using SDL overlays for the rendering.
Theora supports 4:2:0 YUV, but doing conversion between different formats is
well documented on the web.
Have a look here:

http://www.fourcc.org/fccyvrgb.php

However, since the only available encoder (for theora) encodes to 4:2:0, I
don’t support any other formats on my vid player.

Anyway, if you’re interested, I have a video player that uses PBOs for the
texture transfers and does the YUV to RGB conversion on the shader.
The result is quite fast, and is only bound by CPU (and the decoding
process).
Once I’ve threaded that separately (which is what I’m working on now), my
player should be good to go.

It renders frames onto textures so you can do lots of nice things with them
afterwards (i.e. post render effects, picture in picture on your scene,
etc.).
In other words, you can just render your vid on a big full screen quad, or
you can render it to any size texture you like and splat it anywhere on your
scene.

Cheers,
Kos> -----Original Message-----

From: sdl-bounces at lists.libsdl.org
[mailto:sdl-bounces at lists.libsdl.org] On Behalf Of Tom Barnes-Lawrence
Sent: 22 May 2007 11:40
To: sdl at lists.libsdl.org
Subject: [SDL] YUV overlay hardware support

Hi,
I’ve been using SDL a fair bit for various little projects
over the past
few years, but I’ve probably only used a small proportion of it. In
particular, I’ve never tried to use YUV overlays before: I’ve
had little
reason, and they seem to be one of the least discussed parts of it.

Now OTOH, I’m considering maybe possibly putting in some
Dirac-encoded
FMV sequences in the little game I’m working on. I’ve got
roughly the
idea of how I’m supposed to use the overlay functions, from
reading the
docs, wiki, and the few other bits of example code that I’ve been able
to find, but I’m left wondering about hardware support:

-I gather that SDL can tell, after creating an overlay,
whether or not it
is a hardware accelerated one, and that this will (amongst
other things?
I’m not sure) depend on whether the particular YUV format
chosen was one
supported directly by the hardware. I understand these should
handle both
YUV->RGB translation and(?) scaling, and make a big speed
difference, at
least on older machines.

-I also gather that most codecs will probably support some YUV formats
more directly than others. I presume translating from one
sampling format
to another is a fair bit of overhead. (Dirac apparently
supports planar
4:4:4, 4:2:2, and 4:2:0, although these format names still
leave me a bit
mystified)

So anyway, I’m wondering how can I best figure out which
YUV formats
(if any) the machine does support directly in hardware? Is
it possible?
Would I have to try each type in turn and check the flags?
Are there other
requirements to fullfill in order to get hardware overlays?
And if there’s
a choice, which ones should I prefer in order to keep things fast? I’d
naively expect that whatever sends least data would be
fastest, but maybe
not if downsampling, interleaving, etc adds overhead :stuck_out_tongue: Or
maybe that step
is never a speed problem.

As I’d have to make the video sequences as well, I might
still not do
it even if the code is simple, but I’d like to find out as
much as I can
before I get in way over my head! :smiley: (it could at least make a useful
addition to the wiki anyway)

Many thanks in advance,
-Tom Barnes-Lawrence

I think I need a new signature

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-------------- next part --------------
A non-text attachment was scrubbed…
Name: player_example.c
Type: application/octet-stream
Size: 23126 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070522/af865e0c/attachment.obj

3

Ahem…there’s a bit of a scary legal thing at the top of that file I
attached :wink:
I’m pretty sure under the BSD-style license I should be ok to "distribute"
this file, but in any event, it’s probably best to download the player from
here:

http://www.theora.org/

It’s in the “example” dir of the libtheora package.

Cheers,
Kos> -----Original Message-----

From: sdl-bounces at lists.libsdl.org
[mailto:sdl-bounces at lists.libsdl.org] On Behalf Of Kostas Kostiadis
Sent: 22 May 2007 12:24
To: 'A list for developers using the SDL library. (includes
SDL-announce)'
Subject: Re: [SDL] YUV overlay hardware support

Please see the theora example player attached.
It is using SDL overlays for the rendering.
Theora supports 4:2:0 YUV, but doing conversion between
different formats is
well documented on the web.
Have a look here:

http://www.fourcc.org/fccyvrgb.php

However, since the only available encoder (for theora)
encodes to 4:2:0, I
don’t support any other formats on my vid player.

Anyway, if you’re interested, I have a video player that uses
PBOs for the
texture transfers and does the YUV to RGB conversion on the shader.
The result is quite fast, and is only bound by CPU (and the decoding
process).
Once I’ve threaded that separately (which is what I’m working
on now), my
player should be good to go.

It renders frames onto textures so you can do lots of nice
things with them
afterwards (i.e. post render effects, picture in picture on
your scene,
etc.).
In other words, you can just render your vid on a big full
screen quad, or
you can render it to any size texture you like and splat it
anywhere on your
scene.

Cheers,
Kos

-----Original Message-----
From: sdl-bounces at lists.libsdl.org
[mailto:sdl-bounces at lists.libsdl.org] On Behalf Of Tom
Barnes-Lawrence
Sent: 22 May 2007 11:40
To: sdl at lists.libsdl.org
Subject: [SDL] YUV overlay hardware support

Hi,
I’ve been using SDL a fair bit for various little projects
over the past
few years, but I’ve probably only used a small proportion of it. In
particular, I’ve never tried to use YUV overlays before: I’ve
had little
reason, and they seem to be one of the least discussed parts of it.

Now OTOH, I’m considering maybe possibly putting in some
Dirac-encoded
FMV sequences in the little game I’m working on. I’ve got
roughly the
idea of how I’m supposed to use the overlay functions, from
reading the
docs, wiki, and the few other bits of example code that
I’ve been able
to find, but I’m left wondering about hardware support:

-I gather that SDL can tell, after creating an overlay,
whether or not it
is a hardware accelerated one, and that this will (amongst
other things?
I’m not sure) depend on whether the particular YUV format
chosen was one
supported directly by the hardware. I understand these should
handle both
YUV->RGB translation and(?) scaling, and make a big speed
difference, at
least on older machines.

-I also gather that most codecs will probably support some
YUV formats
more directly than others. I presume translating from one
sampling format
to another is a fair bit of overhead. (Dirac apparently
supports planar
4:4:4, 4:2:2, and 4:2:0, although these format names still
leave me a bit
mystified)

So anyway, I’m wondering how can I best figure out which
YUV formats
(if any) the machine does support directly in hardware? Is
it possible?
Would I have to try each type in turn and check the flags?
Are there other
requirements to fullfill in order to get hardware overlays?
And if there’s
a choice, which ones should I prefer in order to keep
things fast? I’d
naively expect that whatever sends least data would be
fastest, but maybe
not if downsampling, interleaving, etc adds overhead :stuck_out_tongue: Or
maybe that step
is never a speed problem.

As I’d have to make the video sequences as well, I might
still not do
it even if the code is simple, but I’d like to find out as
much as I can
before I get in way over my head! :smiley: (it could at least
make a useful
addition to the wiki anyway)

Many thanks in advance,
-Tom Barnes-Lawrence

I think I need a new signature

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org