Hello Newsgroup,
I try to realize a streaming video application using SDL. There are two Threads to achieve this: one Thread is reading image data from a video device attached to a ieee1394 port to store the data in memory. A second Thread continuously reads this image data from memory and shows it on the Screen. The two Threads are synchronized using a Mutex.
In a first step I implemented this behaviour using glutIdleFunc() with a reference to my own function containing a simple glDrawPixels(). The achieved performance is ok.
In a second step I implemented the same behaviour using SDL with Doublebuffer enabled. Therefore I created my own Thread (in contrast to the glut internal Thread) doing the same glDrawPixles() followed by a SDL_GL_SwapBuffers(). In this case the performance is very bad and I am wondering about the reason for this.
Are there any OpenGL configurations made by SDL which aren’t default configurations for OpenGL/Glut ? Can anybody give me some hints where to have a look at (other SDL functions, further readings, work arounds, etc.) ?
Thanks in advance,
Alex
I got some questions about your test:
Are you using SDL_DOUBLEBUF or SDL_GL_DOUBLEBUFFER ?
Are you using SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1) ?
Are you using SDL_HWSURFACE or SDL_SWSURFACE ?
Are you using SDL_HWACCEL ?
What depth are you using, 16 or 32 ?
And, last but not least:
Why are you not using SDL_BlitSurface instead of drawing individual pixels ?
Alexander Block wrote:> Hello Newsgroup,
I try to realize a streaming video application using SDL. There are
two Threads to achieve this: one Thread is reading image data from a
video device attached to a ieee1394 port to store the data in memory.
A second Thread continuously reads this image data from memory and
shows it on the Screen. The two Threads are synchronized using a Mutex.
In a first step I implemented this behaviour using glutIdleFunc() with
a reference to my own function containing a simple glDrawPixels(). The
achieved performance is ok.
In a second step I implemented the same behaviour using SDL with
Doublebuffer enabled. Therefore I created my own Thread (in contrast
to the glut internal Thread) doing the same glDrawPixles() followed by
a SDL_GL_SwapBuffers(). In this case the performance is very bad and I
am wondering about the reason for this.
Are there any OpenGL configurations made by SDL which aren’t default
configurations for OpenGL/Glut ? Can anybody give me some hints where
to have a look at (other SDL functions, further readings, work
arounds, etc.) ?
Thanks in advance,
Alex
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hi !
I am using
SDL_HWSURFACE | SDL_HWPALETTE | SDL_NOFRAME | SDL_ANYFORMAT |
SDL_HWACCEL | SDL_OPENGL | SDL_OPENGLBLIT
( SDL_OPENGL and SDL_OPENGLBLIT isn’t set when using SDL_BlitSurface )
The doublebuffer is set using SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER,
1 ) and the depth is 32.
I don’t use SDL_BlitSurface because:
- The performance isn’t much better
- I only have direct pixel access to RGB surfaces (not BGR, BGRA, YUV,
etc. - as I have using glDrawPixels)
I am thinking about a bad implementation of my Threads.
Alex
Eduardo Costa schrieb:> I got some questions about your test:
Are you using SDL_DOUBLEBUF or SDL_GL_DOUBLEBUFFER ?
Are you using SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1) ?
Are you using SDL_HWSURFACE or SDL_SWSURFACE ?
Are you using SDL_HWACCEL ?
What depth are you using, 16 or 32 ?
And, last but not least:
Why are you not using SDL_BlitSurface instead of drawing individual
pixels ?
Well, the problem can be your threads. Some misuse of them have made a
lot of programs run slower around the SDL community… Including some of
my own programs… 
Anyway, I don’t agree when you say SDL surfaces can’t handle BGR, BGRA
and YUV. BGR and BGRA surfaces can be created using your own pixel
format with the apropriate masks. The pixel area can be RGB, GRB, BRG,
or whatever, and SDL will handle the translation to screen format. I
haven’t played with YUV, but I guess the overlay support can handle
something like that.
Alexander Block wrote:> Hi !
I am using
SDL_HWSURFACE | SDL_HWPALETTE | SDL_NOFRAME | SDL_ANYFORMAT |
SDL_HWACCEL | SDL_OPENGL | SDL_OPENGLBLIT
( SDL_OPENGL and SDL_OPENGLBLIT isn’t set when using SDL_BlitSurface )
The doublebuffer is set using SDL_GL_SetAttribute(
SDL_GL_DOUBLEBUFFER, 1 ) and the depth is 32.
I don’t use SDL_BlitSurface because:
- The performance isn’t much better
- I only have direct pixel access to RGB surfaces (not BGR, BGRA,
YUV, etc. - as I have using glDrawPixels)
I am thinking about a bad implementation of my Threads.
Alex
In addition to the mutex you have, consider the following:
1.) Try using a semaphore to signal when a new image is ready
i.) This will prevent unnecessary blitting and keeps resources from
being over used.
ii.) Use non-blocking semaphores where possible / where applicable
- One doesn’t always want to block on by Wait-ing on a
semaphore. For example, there might be events you’d want to handle while
you’re waiting for a sempahore in the same thread main loop.
- If you use non-blocking semaphore calls with a loop that
could potentially be very tight, consider using #2 to keep the thread
from consuming too many CPU cycles.
2.) Yield the threads when they are done with one iteration
i.) On Linux, use sched_yeild;
ii.) On Windows use SwitchToThread;
iii.) SDL_Delay(0) or SDL_Delay(1) might achieve the same result
- These will/should prevent tight loops from freezing up your
program / hindering performance.
I’ve done similar applications (from V4L -> SDL) and have had great
performance from the SDL library.
During the development of the program I ran into issues where
performance was bad due to tight looping in other threads; this not
being the first time I had experienced this problem.
Hope this helps.
~ Philip D. S. Thoren
Alexander Block wrote:>Hello Newsgroup,
I try to realize a streaming video application using SDL. There are two Threads to achieve this: one Thread is reading image data from a video device attached to a ieee1394 port to store the data in memory. A second Thread continuously reads this image data from memory and shows it on the Screen. The two Threads are synchronized using a Mutex.
In a first step I implemented this behaviour using glutIdleFunc() with a reference to my own function containing a simple glDrawPixels(). The achieved performance is ok.
In a second step I implemented the same behaviour using SDL with Doublebuffer enabled. Therefore I created my own Thread (in contrast to the glut internal Thread) doing the same glDrawPixles() followed by a SDL_GL_SwapBuffers(). In this case the performance is very bad and I am wondering about the reason for this.
Are there any OpenGL configurations made by SDL which aren’t default configurations for OpenGL/Glut ? Can anybody give me some hints where to have a look at (other SDL functions, further readings, work arounds, etc.) ?
Thanks in advance,
Alex
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
E3-I: This message has been scanned for viruses and dangerous content by UML’s antivirus scanning services.
–
:vsplit vimrulez.txt i vimrulez :w :q
Thank you for your hints, I will try to change my implementation.
Philip D.S. Thoren schrieb:>
In addition to the mutex you have, consider the following:
1.) Try using a semaphore to signal when a new image is ready
i.) This will prevent unnecessary blitting and keeps resources from
being over used.
ii.) Use non-blocking semaphores where possible / where applicable
- One doesn’t always want to block on by Wait-ing on a
semaphore. For example, there might be events you’d want to handle
while you’re waiting for a sempahore in the same thread main loop.
- If you use non-blocking semaphore calls with a loop that
could potentially be very tight, consider using #2 to keep the thread
from consuming too many CPU cycles.
2.) Yield the threads when they are done with one iteration
i.) On Linux, use sched_yeild;
ii.) On Windows use SwitchToThread;
iii.) SDL_Delay(0) or SDL_Delay(1) might achieve the same result
- These will/should prevent tight loops from freezing up your
program / hindering performance.
I’ve done similar applications (from V4L -> SDL) and have had great
performance from the SDL library.
During the development of the program I ran into issues where
performance was bad due to tight looping in other threads; this not
being the first time I had experienced this problem.
Hope this helps.
~ Philip D. S. Thoren
As you can see in another reply I got some hints concerning the Thread
programming. I will try to improve my implementation.
I think my knowledge about SDL (and also OpenGL) is not good enough and
there is a lot I have to learn in the future. Perhaps I didn’t read the
documentation of SDL deep enough in order to understand how to handle
different pixel formats without the need of conversions to the SDL pixel
format. Does there exist any other documentation or examples that I can
use as a source to close my knowledge gap? Which parts of the SDL
documentation should I read again in detail?
Alex
Eduardo Costa schrieb:> Well, the problem can be your threads. Some misuse of them have made a
lot of programs run slower around the SDL community… Including some
of my own programs…
Anyway, I don’t agree when you say SDL surfaces can’t handle BGR, BGRA
and YUV. BGR and BGRA surfaces can be created using your own pixel
format with the apropriate masks. The pixel area can be RGB, GRB, BRG,
or whatever, and SDL will handle the translation to screen format. I
haven’t played with YUV, but I guess the overlay support can handle
something like that.
Hi !
Your hints have been very useful and now my implementation just works
fine. It doesn’t matter if I am using OpenGL or SDL directly (with
SDL_BlitSurface) - the recognizable results are the same.
Thank you all for your help,
best regards,
Alex
Philip D.S. Thoren schrieb:>
In addition to the mutex you have, consider the following:
1.) Try using a semaphore to signal when a new image is ready
i.) This will prevent unnecessary blitting and keeps resources from
being over used.
ii.) Use non-blocking semaphores where possible / where applicable
- One doesn’t always want to block on by Wait-ing on a
semaphore. For example, there might be events you’d want to handle
while you’re waiting for a sempahore in the same thread main loop.
- If you use non-blocking semaphore calls with a loop that
could potentially be very tight, consider using #2 to keep the thread
from consuming too many CPU cycles.
2.) Yield the threads when they are done with one iteration
i.) On Linux, use sched_yeild;
ii.) On Windows use SwitchToThread;
iii.) SDL_Delay(0) or SDL_Delay(1) might achieve the same result
- These will/should prevent tight loops from freezing up your
program / hindering performance.
I’ve done similar applications (from V4L -> SDL) and have had great
performance from the SDL library.
During the development of the program I ran into issues where
performance was bad due to tight looping in other threads; this not
being the first time I had experienced this problem.
Hope this helps.
~ Philip D. S. Thoren
Okay, I think I might know what problem you might be having. I’ve only read
the first post, though, so forgive me if I’ve missed something. I also had a
problem where GLUT was faster than SDL. After many times asking for help and
weeding through my code, I finally found the help I needed in a four year old
post I found on Google. You want to know what it was? Make sure you call
glFinish(); before SDL_GL_SwapBuffers();. That’s it, that’s what was causing
all my problems! Until then I had only been using glFlush(); and thought
everything was handled, but I guess not. Ah, c’est la vie.–
Duncan “Bojangles” Domingue
-I cna ytpe 300 wrods pre mniute
Duncan Domingue wrote:
Make sure you call glFinish(); before SDL_GL_SwapBuffers();. That’s it, that’s what was causing
all my problems! Until then I had only been using glFlush()
I actually get worse performance calling glFinish before the
swapbuffers-command. I guess due to the fact, that an extra call has to
be made. Curious, since glutSwapBuffers does an glFinish-call by itself.
Regards,
\Mikkel Gjoel
Duncan Domingue wrote:
Make sure you call glFinish(); before SDL_GL_SwapBuffers();.
That’s it, that’s what was causing all my problems! Until then I
had only been using glFlush()
I actually get worse performance calling glFinish before the
swapbuffers-command. I guess due to the fact, that an extra call
has to be made.
In the general case, that’s what I’d expect. On any properly optimized
accelerated OpenGL setup, SwapBuffers is an asynchronous operation,
so unless you’ve caught up with the accelerator and/or page flipping,
it usually returns very quickly.
Now, if you call glFinish(), you eliminate the chance of CPU/GPU
parallel execution, and effectively hard-sync your application with
the GPU. That is, when the GPU is working, your CPU is not, and
possibly vice versa. (The latter happens if your application has a
great deal of work to do each frame before it seriously starts
pumping polygons.)
Curious, since glutSwapBuffers does an
glFinish-call by itself.
That’s still interesting, though. Maybe something goes wrong if you
call it twice… Or maybe glutSwapBuffers has some work to do before
it calls glFinish()?
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 11 January 2004 19.10, Mikkel Gj?l wrote:
Hi,
is it possible to have the source code of this software
that uses SDL to perform streaming video ? I’m moving
the first step in SDL and it would be appreciated.
Thanks,–
Giuseppe Torelli