FAST Video Buffer

SDL Development
1

Hello there. I have a question. I am writing a program that plays
videos. I have started writing the video buffer using SDL, but I have
found that I can only refresh a 720*540 screen at ~650fps on a
Celeron300A at 450 with a Millenium. Granded I only need 30fps. So here
go my questions.

Is my number limited by the number of times that my video card can
refresh?

Will SDL take advantage of any hardware acceleration that is avilable?

Will SDL take advantage of DRI in X4.0?

Does SDL take advantage of the XvideoExtension?

If SDL wont take advantage of the harware, how easy would I be to
include video acceleration.

I have seen SMPEG and know that SDL is fast enough to render the video
and decode the video and sound at the same time. It gets out of sync,
but it isn’t finished yet and that is easlily worked on.

To sum these all up I get to one big question. Is SDL the best library
to use? Or should I use some lower API? Should I write connections to
each video card that I want to have acceleration. Is there some
documentation for DRI that I can look at? And where is it? Is there
some ducumentation on the new extensions in the X4.0 library (i.e. DRI)?

Benjamin Meyer

2

Is my number limited by the number of times that my video card can
refresh?

You mean your monitor refresh rate? Yes.

Will SDL take advantage of any hardware acceleration that is avilable?

Yes.

Will SDL take advantage of DRI in X4.0?

DRI is a 3D rendering infrastructure, and SDL will take advantage of it
through it’s GL code.

Does SDL take advantage of the XvideoExtension?

Not yet, but I plan to add support for it soon. The XvideoExtension only
supports one video card as far as I know right now.

To sum these all up I get to one big question. Is SDL the best library
to use?

I think so, but I’m biased, and I also know what I want SDL to do in the
future. I want SDL to provide hardware acceleration of YUV surfaces, when
available, as well as stretching at some point.

Again, right now SDL just provides RGB surfaces and hardware acceleration
of non-stretched blits. You can use SDL’s OpenGL support to take advantage
of hardware accelerated stretching and smoothing, etc, but only on 3D video
cards.

If you want to take advantage of cards that actually do MPEG decoding in
hardware (the ATI Rage 128, for one), then you’ll have to talk to the
manufacturer directly to get the register specs for the card and write
a driver yourself.

Or should I use some lower API? Should I write connections to
each video card that I want to have acceleration. Is there some
documentation for DRI that I can look at? And where is it? Is there
some ducumentation on the new extensions in the X4.0 library (i.e. DRI)?

As far as I know, DRI is just a wire (no wire?) protocol for 3D transactions.
You probably want to use OpenGL if you’re interested in that.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

3

Sam Lantinga wrote:

Does SDL take advantage of the XvideoExtension?

Not yet, but I plan to add support for it soon. The
XvideoExtension only
supports one video card as far as I know right now.

I’m fairly certain that more will follow pretty soon. The one’s supported
now is Matrox G200/G400 and I’ve heard that Nvidia cards (atleast
TNT/TNT2/GeForce) will be supported soon.

I want SDL to provide hardware acceleration of YUV
surfaces, when available, as well as stretching at some point.

YUV and Xv would be very nice. Any timeframe? A couple of weeks? Months? A
year?

Mattias Blomqvist

4

YUV and Xv would be very nice. Any timeframe? A couple of weeks? Months? A
year?

Probably a couple of months. The longest part of this is that I would want
a software fallback if the XvImage extension isn’t supported. I don’t know
in general how to convert YUV surfaces to RGB, yet.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

5

Sam Lantinga wrote:

YUV and Xv would be very nice. Any timeframe? A couple of weeks? Months? A
year?

Probably a couple of months. The longest part of this is that I would want
a software fallback if the XvImage extension isn’t supported. I don’t know
in general how to convert YUV surfaces to RGB, yet.

If it would speed up the development I’d be more than happy to code the
fallback raw conversion routines for the most common YUV formats. I have
made a conversion routine from a nonstandard YUV format to RGB24 so i’m
quite familiar with it. I could do them in both c for general use and
optimized in x86 asm with mmx. But keep in mind that its a very
computational heavy task and will be quite slow in software (especially
if there’s no mmx available).

Mattias Blomqvist

6

If it would speed up the development I’d be more than happy to code the
fallback raw conversion routines for the most common YUV formats. I have
made a conversion routine from a nonstandard YUV format to RGB24 so i’m
quite familiar with it. I could do them in both c for general use and
optimized in x86 asm with mmx. But keep in mind that its a very
computational heavy task and will be quite slow in software (especially
if there’s no mmx available).

That would be great.
We’ll need software (C and MMX) fallbacks for YUV formats to any general
surface. Special optimized cases should be available for RGB565, RGB555,
and 32-bit ARGB8888 ABGR8888

Hey Daniel, does Hermes support this yet?

Thanks!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

7

Sam Lantinga wrote:

That would be great.
We’ll need software (C and MMX) fallbacks for YUV formats to any general
surface. Special optimized cases should be available for RGB565, RGB555,
and 32-bit ARGB8888 ABGR8888

Hey Daniel, does Hermes support this yet?

Hermes 1.3.1 doesn’t but I remember Christian writing something about
integrating YUV <-> RGB conversion to the API. That was a long time ago
and now that he doesn’t have any time left for Hermes (that’s the reason
we maintain it now) I doubt he will integrate it himself. If I remember
right 1.3.0 was originally planned as a big change in the API but then
he dropped his plans and we added the stuff we needed to the existing
1.2.6 and released 1.3.0. I will ask Christian whether he has some code
lying on his HD that could be used. I guess adding YUV support to
Hermes’ API shouldn’t be too hard…–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

8

Sam Lantinga wrote:

That would be great.
We’ll need software (C and MMX) fallbacks for YUV formats to any general
surface. Special optimized cases should be available for RGB565, RGB555,
and 32-bit ARGB8888 ABGR8888

Ok. RGB32 (RGB0, BGR0, 0RGB and 0BGR) and RGB24 will be easiest and
fastest. As for RGB565 and RGB555 it will be slower because extra
cpu-cycles must be used to pack it.
As for ARGB8888 and ABGR8888. How does the alpha bit work? The equations
I have to get R, G and B from a combination of Y, U and V says nothing
about alpha-values. So, please point me to info about what the alpha
value does. Should i discuss this on another list or anywhere else than
here? Where should I send code?

Mattias Blomqvist

9

I believe you will find that alpha is alpha, any way you look at it.
This value is identical for RGB or YUV, so with alpha you have RGBA and
YUVA. The only question about alpha is what is the most transparent,
the low or high number. This shouldn’t matter in the internal code
because it will be identical to what SDL already uses.

Jamie

Mattias Blomqvist wrote:>

Sam Lantinga wrote:

That would be great.
We’ll need software (C and MMX) fallbacks for YUV formats to any general
surface. Special optimized cases should be available for RGB565, RGB555,
and 32-bit ARGB8888 ABGR8888

Ok. RGB32 (RGB0, BGR0, 0RGB and 0BGR) and RGB24 will be easiest and
fastest. As for RGB565 and RGB555 it will be slower because extra
cpu-cycles must be used to pack it.
As for ARGB8888 and ABGR8888. How does the alpha bit work? The equations
I have to get R, G and B from a combination of Y, U and V says nothing
about alpha-values. So, please point me to info about what the alpha
value does. Should i discuss this on another list or anywhere else than
here? Where should I send code?

Mattias Blomqvist

10

James M Best wrote:

I believe you will find that alpha is alpha, any way you look at it.
This value is identical for RGB or YUV, so with alpha you have RGBA and
YUVA. The only question about alpha is what is the most transparent,
the low or high number. This shouldn’t matter in the internal code
because it will be identical to what SDL already uses.

Ahh… That explains it. Anyway. That makes it very hard to produce ARGB
or RGBA or whatever that have a alpha-part in it since there is no
alpha-values defined in any of the yuv-standards.

Mattias Blomqvist

11

Sam Lantinga wrote:

That would be great.
We’ll need software (C and MMX) fallbacks for YUV formats to any general
surface. Special optimized cases should be available for RGB565, RGB555,
and 32-bit ARGB8888 ABGR8888

As for ARGB8888 and ABGR8888. How does the alpha bit work?

No worries, just use RGB0, BGR0, 0RGB, and 0BGR
We can worry about alpha later if needed.

Where should I send code?

Send it to me: slouken at devolution.com

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

12

Sam Lantinga wrote:

Will SDL take advantage of any hardware acceleration that is avilable?

Yes.

You should be fair here and note that it is more precisely “any hardware
acceleration that is available to the program”. The same SDL code on the
same machine can be much faster on Windows than in Linux (even with
XFree86 4.0, but it makes things better).

Will SDL take advantage of DRI in X4.0?

DRI is a 3D rendering infrastructure, and SDL will take advantage of it
through it’s GL code.

DRI is a rendering infrastructure that has no special preference to 3D
or 2D. All of the code that currently uses it is OpenGL 3D drivers. It
could conceivably be used for 2D work.

One question: why are 2D OpenGL functions so slow? They’re not used
very often so they are not worked on? Poor excuse if that’s the case…–
Pierre Phaneuf
Systems Exorcist