i’m working on a very complex multi-media player, using SDL for video
output. therefore it is hard to produce a testcase, that mirrors my
project with all that threads.
i know it would be easier for you to help me with having a testcase, but
it’s impossible.
i wrote a simple test case, but there everything went fine, so i think
it’s a problem of my app. rather than a SDL problem, but hey - you are
the ones who know much more about SDL and its implementions and i hope,
someone has a clue to help me.
i run my app mostly under windows nt 4.0 (but the error is also occurs
on win2k).
my problem:
i create a SDL_Surface and afterwards a YUVOverlay. and i do some
blitting into this overlay.
after quiting the SDL (without freeing neither the overlay nor the
surface), the Window is still visible and causes a seg fault, when it
gets the focus or a mouse event or the like (this is not astonishing,
because SDL has freed all its memory).
i debugged the SDL_Quit() call a bit an came to the WINAPI call
DestroyWindow(SDL_Window), which returns with the error code 5
(ERROR_ACCESS_DENIED).
the ‘window handle’ (SDL_Window) is the same that CreateWindow() created.
so. does anybody know, what i do between creating the window and closing
it, that makes me lose the access??
i have about 7 threads running, but creating the window and closing it
is done in the same.
Make sure that you’re doing all your SDL video calls from the same
thread. SDL video (and often the underlying APIs) is not threadsafe.
A concept that SMPEG itself violates. If you want to do SMPEG along
with any other concurrent use of SDL (like displaying a movie in part
of the screen and something else elsewhere), you’re hosed because
SMPEG creates a separate thread to display the movie.
Make sure that you’re doing all your SDL video calls from the same
thread. SDL video (and often the underlying APIs) is not threadsafe.
A concept that SMPEG itself violates. If you want to do SMPEG along
with any other concurrent use of SDL (like displaying a movie in part
of the screen and something else elsewhere), you’re hosed because
SMPEG creates a separate thread to display the movie.
Yep, and it’s been well tested to work with exactly that set of calls
in exactly that context, as long as you use the lock functions corretly.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
A concept that SMPEG itself violates. If you want to do SMPEG along
with any other concurrent use of SDL (like displaying a movie in part
of the screen and something else elsewhere), you’re hosed because
SMPEG creates a separate thread to display the movie.
Yep, and it’s been well tested to work with exactly that set of calls
in exactly that context, as long as you use the lock functions corretly.
Coincidentally, I’d like to start collecting complaints and requests
regarding SMPEG, so that development of the library can begin to restart,
post-Loki. I have a few things I’d like to enhance/correct, and I’m sure
others, do, too.
If people could either subscribe to the mailing list (blank email to
smpeg-subscribe at icculus.org) or just email me directly (and I’ll pass them
on to the list minus your email address), I’d appreciate it.
I was thinking about using SMPEG in my (commercial) product and was talking
to the folks here about the LGPL as I am not familiar yet with open source
stuff…
Seems I will keep using DirectShow/QuickTime as in this particular case I
need it only for Windows anyways. But while evaluating it, I found, SMPEG
would require three more things to compete with DirectShow, for example:
A more generalized way to work with it, not bound to SDL. Here is a
snippet of my discussion with Rafael about this:
I do not care at all. As mentioned, the ‘huge’ difference is to use
different Surface structures and such stuff. Nobody will benefit from
this
I disagree. The smart way to do what you think needs to be done would
be to generalize the surface structures so that it would work with
both SDL and with your mysterious proprietary library. That would be a
great benefit to the community. It removes SMPEG’s absolute dependency
on SDL, and allows people to plug and play backend display engines at
will, if, for instance, they wished to make an MPEG player that would go
straight to the Linux SVGA framebuffer, to SVGAlib, or straight to
DirectX surfaces, or whatever else.
This is a great idea. If I decide to use SMPEG, I will do exactly this.
If SMPEG is intended to be SDL based only, then this would be wasted effort
of course.
There should be something like an explicit fullscreen mode like
DirectShow and to some extent QuickTime support it. This means that you call
something like a GoIntoFullScreenMode() and this function takes over all
control and returns when certain conditions apply, for example a keystroke.
What happens here is, that hardware acceleration - if available - takes
place to display the movie fullscreen. DirectShow does this by bypassing the
graphics buffer in some way, using overlays, which makes the MPEGs run
smooth even in 1280x1024 resolutions on pretty slow PCs (like my
Celeron-466). This could be pretty much work though and I personally am not
familiar with this yet (besides using it). But the result is really
impressive… (Actually this brings me to the conclusion that there is a
lack of a really cool video library for Linux.)
The performance should be enhanced. Compared to QuickTime and especially
DirectShow, it is pretty slow. But maybe this is not necessary if most
people use it for low resolution MPEGs or on fast PCs. Would be a waste of
energy then.
Best regards,
Mario Knezovic
mario.knezovic at SPAMISCRAPbonespark.com,
Please remove my opinion on spam to email me ;-)> ----- Original Message -----
From: icculus@icculus.org (Ryan C. Gordon)
Newsgroups: loki.open-source.sdl
To:
Sent: Friday, February 08, 2002 7:38 AM
Subject: [SDL] SMPEG complaints, requests, and enhancements.
A concept that SMPEG itself violates. If you want to do SMPEG along
with any other concurrent use of SDL (like displaying a movie in part
of the screen and something else elsewhere), you’re hosed because
SMPEG creates a separate thread to display the movie.
Yep, and it’s been well tested to work with exactly that set of calls
in exactly that context, as long as you use the lock functions corretly.
Coincidentally, I’d like to start collecting complaints and requests
regarding SMPEG, so that development of the library can begin to restart,
post-Loki. I have a few things I’d like to enhance/correct, and I’m sure
others, do, too.
If people could either subscribe to the mailing list (blank email to
smpeg-subscribe at icculus.org) or just email me directly (and I’ll pass them
on to the list minus your email address), I’d appreciate it.
Seems I will keep using DirectShow/QuickTime as in this particular case I
need it only for Windows anyways. But while evaluating it, I found, SMPEG
would require three more things to compete with DirectShow, for example:
[snip]
I’ve got these written down, and will see how to address them once I get
the ball rolling with SMPEG development again. Thankya.
There should be something like an explicit fullscreen mode like
DirectShow and to some extent QuickTime support it. This means that you call
something like a GoIntoFullScreenMode() and this function takes over all
control and returns when certain conditions apply, for example a keystroke.
What happens here is, that hardware acceleration - if available - takes
place to display the movie fullscreen. DirectShow does this by bypassing the
graphics buffer in some way, using overlays, which makes the MPEGs run
smooth even in 1280x1024 resolutions on pretty slow PCs (like my
Celeron-466).
In actual fact, SDL provides this and SMPEG takes advantage of it.
It works on Windows using the YUV overlay surface type, and also on Linux
using the XVideo extension.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
i have been using smpeg, but has to change few things. I wrote code, that
is some impuls dependent so i had to change frame rate by it. There’s an
piece of code in the Renderfarame function that has to be rewriten, otherwise
it skips somehow frames (sometimes 30 frames). And it always takes a lot of
time to find next frame(few secs!) So i rewrote it little bit (i know nothing
about mpeg, just used piece of other function of smpeg). I could send it, if
someone interested.
the other think is: I want API as DirectShow has. For example: when i use
single buffer, and call renderframe, then it calls UpdateRect (or i’m wrong ?).
Is really smpeg calling updaterect after Renderframe ? I couldn’t figure out
how use double buffer with smpeg. I could see just black screen when i tried
it. I don’t tell this problems are not result of my ignorancy :).
Is directshow really that much faster ? When i tried it last, it was about
the same speed ( after 2xspeedup it didn’t want to be faster:) ). My video
was (345x280 or something like this).
what do you use for playing vids under linux anyway? libmpeg2 - it seems to
me that it has compicated API. (you have to deal with vo library).
There should be something like an explicit fullscreen mode like
DirectShow and to some extent QuickTime support it. This means that you
call
something like a GoIntoFullScreenMode() and this function takes over all
control and returns when certain conditions apply, for example a
keystroke.
What happens here is, that hardware acceleration - if available - takes
place to display the movie fullscreen. DirectShow does this by bypassing
the
graphics buffer in some way, using overlays, which makes the MPEGs run
smooth even in 1280x1024 resolutions on pretty slow PCs (like my
Celeron-466).
In actual fact, SDL provides this and SMPEG takes advantage of it.
It works on Windows using the YUV overlay surface type, and also on Linux
using the XVideo extension.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Wow, true.
I was searching for ‘fullscreen’ and only found the parameter of the same
name in the sample player, which only sets the application to fullscreen
mode, but the actual size of the video does not change.
Well, then probably it is mostly the documentation that needs to be enhanced
