Hello everybody,
I am searching a library for display movies in SDL program. In Google I
found SMPEG, but I read in http://freshmeat.net/projects/smpeg/ this: last
update in 26 Feb 2002. Near 9 years without any update.
Is SMPEG stopped?. Is actually in another site?. Or… actually for display
movies I need to use another library?.
Thanks
P.D: sorry my english. Read english is a little difficult but write is very
hard. I am spanish.
Hi,
I might be mistaken, but I suggest you have a look at ffmpeg. I’m sure
someone else here will correct me if that isn’t the best (or even an
applicable) choice.
Good luck!
ChristianOn Sun, Jan 9, 2011 at 12:05 PM, Altair Linux wrote:
Hello everybody,
I am searching a library for display movies in SDL program. In Google I
found SMPEG, but I read in http://freshmeat.net/projects/smpeg/ this: last
update in 26 Feb 2002. Near 9 years without any update.Is SMPEG stopped?. Is actually in another site?. Or… actually for display
movies I need to use another library?.Thanks
P.D: sorry my english. Read english is a little difficult but write is very
hard. I am spanish.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I managed to get libVLC working pretty easily based on the SDL example on their webpage:
http://wiki.videolan.org/LibVLC_SampleCode_SDL
I find it pretty nice unless you’re trying to compile for embedded systems.
ffmpeg has a very LARGE set of files. If you want a simple to use and small
interface the SMPEG is a good choice.
Unfortunately SMPEG does NOT work with SDL 1.3, so if you are planning on
using SDL 1.3 you are out of luck.
KenFrom: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Christian Leger
Sent: Sunday, January 09, 2011 11:24 AM
To: SDL Development List
Subject: Re: [SDL] About SMPEG library
Hi,
I might be mistaken, but I suggest you have a look at ffmpeg. I’m sure
someone else here will correct me if that isn’t the best (or even an
applicable) choice.
Good luck!
Christian
On Sun, Jan 9, 2011 at 12:05 PM, Altair Linux wrote:
Hello everybody,
I am searching a library for display movies in SDL program. In Google I
found SMPEG, but I read in http://freshmeat.net/projects/smpeg/ this: last
update in 26 Feb 2002. Near 9 years without any update.
Is SMPEG stopped?. Is actually in another site?. Or… actually for display
movies I need to use another library?.
Thanks
P.D: sorry my english. Read english is a little difficult but write is very
hard. I am spanish.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Yes, I only want reproduce videos in a SDL Surface.
I know that one way is to fetch individual frames from the video, applying
them as a texture to something, while synchronously playing video. But does
anyone know if the output of another application can be used to fill a
texture? Using compiz maybe, but not necessarily? I’ve always wondered about
things like being able to display the contents of a web browser’s window in
a video game, but never even heard hints as to how to do this.
Any information about this would be greatly appreciated.
ChristianOn Sun, Jan 9, 2011 at 5:32 PM, Altair Linux wrote:
Yes, I only want reproduce videos in a SDL Surface.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Message: 3
Message-ID:
? ? ? ?<AANLkTik_KxLAzfZX+9gJvz2KKdGiN2gcWZJuLE9KBAtf at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”I know that one way is to fetch individual frames from the video, applying
them as a texture to something, while synchronously playing video. But does
anyone know if the output of another application can be used to fill a
texture? Using compiz maybe, but not necessarily? I’ve always wondered about
things like being able to display the contents of a web browser’s window in
a video game, but never even heard hints as to how to do this.Any information about this would be greatly appreciated.
Christian
Fetch the frame to some specific point in memory (you can supply
it, or the library can supply it, it normally won’t matter which), and
store the data (such as size and color depth) that SDL needs somewhere
that’s associated with that memory.
Build an SDL Surface, using the SDL_CreateRGBSurfaceFrom() function.
Convert the surface to a texture, etc. At this point you can
release the frame, since the texture will have it’s own copy.
This technique will work on anything that you can get into memory in a
‘raw’ format (e.g., data streams, files, etc.). If SDL was designed
for it, then you could theoretically even use this to stream one
program’s display window to another program, which could then display
it in a 3-d scene (imagine a 3rd-person shooter game that let you also
play text-based games on text-prompt consoles throughout the game).
Warning! Different formats arrange their pixels in different orders,
so it’s possible that the movie will appear reversed (as if seen
through a mirror) or rotated (or both). Therefor, you should include
enough interactivity to rotate and/or mirror the default display
behavior movie while it’s playing.> Date: Sun, 9 Jan 2011 17:41:09 -0500
From: Christian Leger <chrism.leger at gmail.com>
To: SDL Development List
Subject: Re: [SDL] About SMPEG library
Fetch the frame to some specific point in memory (you can supply
it, or the library can supply it, it normally won’t matter which), and
store the data (such as size and color depth) that SDL needs somewhere
that’s associated with that memory.Build an SDL Surface, using the SDL_CreateRGBSurfaceFrom() function.
Convert the surface to a texture, etc. At this point you can
release the frame, since the texture will have it’s own copy.
Yeah, you could do that, but that’s a huge amount of memory churn, and would
probably consume tons of CPU. I wouldn’t be surprised if it noticeably lagged
the system for high resolution videos. Is there any native SDL-level support
for video in 1.3?>----- Original Message ----
From: Jared Maddox
Subject: Re: [SDL] About SMPEG library
For video, you’re probably better off passing screen->pixels and
screen->pitch to the decoder to render each frame, then draw your
stuff on top if necessary. No blits that way, just rendering the
video.
Pretty sure that’s what’s happening with the LibVLC code josebagar
linked to earlier ( libVLC SampleCode SDL - VideoLAN Wiki ).On 11 January 2011 17:45, Mason Wheeler wrote:
Yeah, you could do that, but that’s a huge amount of memory churn, and would
probably consume tons of CPU. ?I wouldn’t be surprised if it noticeably lagged
the system for high resolution videos. ?Is there any native SDL-level support
for video in 1.3?
Mason Wheeler wrote:
Fetch the frame to some specific point in memory (you can supply
it, or the library can supply it, it normally won’t matter which), and
store the data (such as size and color depth) that SDL needs somewhere
that’s associated with that memory.Build an SDL Surface, using the SDL_CreateRGBSurfaceFrom() function.
Convert the surface to a texture, etc. At this point you can
release the frame, since the texture will have it’s own copy.Yeah, you could do that, but that’s a huge amount of memory churn, and would
probably consume tons of CPU. I wouldn’t be surprised if it noticeably lagged
the system for high resolution videos. Is there any native SDL-level support
for video in 1.3?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I agree with you although it is hard to get around it; and there is not.> > ----- Original Message ----
From: Jared Maddox
Subject: Re: [SDL] About SMPEG library
EM3 Nathaniel Fries, U.S. Navy
Jared Maddox wrote:
Fetch the frame to some specific point in memory (you can supply
it, or the library can supply it, it normally won’t matter which), and
store the data (such as size and color depth) that SDL needs somewhere
that’s associated with that memory.Build an SDL Surface, using the SDL_CreateRGBSurfaceFrom() function.
Convert the surface to a texture, etc. At this point you can
release the frame, since the texture will have it’s own copy.
It makes a huge difference; allocating that much memory each frame is ridiculous. If the library does not either use a static memory field or allow you to supply your own (just keep re-using it), then don’t use it.
Ideally, you should build the SDL_Surface first using the pixel format that the library will output to. The size of each frame will not change, so then you just feed the pixels field into the library function that fetches the next frame. This not only prevents needing to build an SDL_Surface each frame; but also prevents SDL from needing to allocate pixel memory to copy the pixels to. A double win. If it doesn’t output to a pixel format available to SDL; I don’t think you could use it anyway (without converting yourself).
This is the part that unfortunately can’t be optimized into complete negligibility (besides the actual conversion portion) with simple memory reuse. Some GPUs take forever to upload pixel data. You should use multiple textures, and have the next frame ready to go as soon as the current frame is rendered for the first time; maybe even before. Hopefully this will prevent skips.
of course, this is just the most optimal method I could think of. Maybe there’s better ways.------------------------
EM3 Nathaniel Fries, U.S. Navy
To Mason, Kenneth and Nathaniel:
You need to go read the last remark in
http://wiki.libsdl.org/moin.cgi/SDL_CreateRGBSurfaceFrom?highlight=(\bCategorySurface\b)|(CategoryEnum)|(CategoryStruct)
SDL_CreateRGBSurfaceFrom DOES NOT create a copy of the pixel data.
Thus, the most generic algorithm that follows this formula is the one
I described. Also, note that I was very generic when talking about
memory management; in cases where the application supplies the memory
to the decoder, I would allocate space for the frame once and just
keep reusing it, but since the original poster didn’t specify a movie
format I couldn’t really make any assumptions about how the memory
would be handled.> Message: 3
Date: Tue, 11 Jan 2011 14:45:57 -0800 (PST)
From: Mason Wheeler
To: SDL Development List
Subject: Re: [SDL] About SMPEG library
Message-ID: <400500.98714.qm at web161206.mail.bf1.yahoo.com>
Content-Type: text/plain; charset=us-asciiYeah, you could do that, but that’s a huge amount of memory churn, and would
probably consume tons of CPU. ?I wouldn’t be surprised if it noticeably lagged
the system for high resolution videos. ?Is there any native SDL-level support
for video in 1.3?
There isn’t too much inherent memory churn in the algorithm that I
posted that’s actually avoidable.
When I talk about releasing the frame, I’m specifically talking about
informing decoder libraries that do their own memory management that a
particular frame is no longer needed (if allowed to do it myself, I
would only allocate the memory once per movie play-through, but some
libraries may not work that way).
In some cases you won’t need to allocate a new surface for each frame,
but unless you’re willing to alter read-only members of the surface
there will be some formats that you’ll need to allocate a new surface
for (in most frames, those formats only encode the pixels that have
changed).
If the hardware you’re targeting doesn’t support a GPU then you’ll be
better off avoiding the surface-to-texture copy by rendering the
surface directly to the window, but I don’t think SDL 1.3 actually
supports this.
To put it another way, unless you’re willing to write a decoder that
you can run ON a GPU, any built-in support that SDL might have for
playing movies would follow the BASICS of the algorithm that I posted.
Message: 4
Date: Tue, 11 Jan 2011 18:49:35 -0500
From: Kenneth Bull
To: SDL Development List
Subject: Re: [SDL] About SMPEG library
Message-ID:
? ? ? ?<AANLkTi=yZk+yjT+B38tQeEJtMdRj9sEhHyg4ijrQw4QS at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1For video, you’re probably better off passing screen->pixels and
screen->pitch to the decoder to render each frame, then draw your
stuff on top if necessary. ?No blits that way, just rendering the
video.
Outside of the surface-to-texture transition, there aren’t any
INHERENT blits with the algorithm I described, because that particular
SDL function uses the pixel data that you provide it instead of
allocating some itself. That’s why I said to release the frame AFTER
you generate the texture (particularly since you have no idea what the
decoder will do with that memory if the decoder originally allocated
it). I suspect that the function was originally created for precisely
this sort of scenario (either that, or images embedded in your
executable).
Message: 7
Date: Tue, 11 Jan 2011 16:38:18 -0800
From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] About SMPEG library
Message-ID: <1294792698.m2f.26549 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”
- It makes a huge difference; allocating that much
memory each frame is ridiculous. If the library does not
either use a static memory field or allow you to supply
your own (just keep re-using it), then don’t use it.
I didn’t actually say anything about memory management, just ‘frame’
management. One of the things I was considering when I wrote that post
was the possibility that the decoder would keep reusing the same block
of memory for each and every frame. If I was writing an application
with a decoder library that allowed the caller to supply the memory,
then I would allocate the memory once and just keep reusing it while
the video was playing. However, since this is an implementation detail
that will change from library to library I choose not to mention it.
- Ideally, you should build the SDL_Surface first using
the pixel format that the library will output to.
Some libraries may choose to allocate their own memory, in which case
your code has to copy the pixel data. The method I described doesn’t
involve this unneeded copying, and is therefor roughly optimal in more
cases.
The size of each frame will not change,
As I best recall, some data formats use key frames like normal, but
then have other, smaller frames that only contain the pixels that have
actually changed (I recall something about MPEG4 being one of these).
Of course, if you aren’t using one of these formats then you’ll have
some extra optimization possibilities, since you can potentially just
have new frames decoded into the space used by the old one while not
fiddling around with any other structure members.
so then you just feed the pixels field into the library
function that fetches the next frame.
Only works with libraries that allow you to provide the memory yourself.
This not only prevents needing to build an SDL_Surface
each frame; but also prevents SDL from needing to
allocate pixel memory to copy the pixels to.
In SDL 1.2 the SDL_CreateRGBSurfaceFrom() function DOESN’T allocate
pixel data for the surface because it stores the pointer that you
provide into the surface structure, and according to the documentation
that hasn’t changed in SDL 1.3. Thus, at most you’re creating a
surface structure each frame, and if you can get SDL to use a
memory-pooling allocator (perhaps by replacing your malloc with one?
How does SDL allocate memory?) then you normally won’t even be making
a context switch.
- This is the part that unfortunately can’t be optimized
into complete negligibility (besides the actual
conversion portion) with simple memory reuse. Some GPUs
take forever to upload pixel data.
This is where the formats that use ‘dirty pixel’ techniques come in
handy: less data to move.
You should use multiple textures, and have the next
frame ready to go as soon as the current frame is
rendered for the first time; maybe even before.
Hopefully this will prevent skips.
That was one of the things that I was aiming for with the algorithm.
To Mason, Kenneth and Nathaniel:
You need to go read the last remark in
http://wiki.libsdl.org/moin.cgi/SDL_CreateRGBSurfaceFrom?highlight=(\bCategorySurface\b)|(CategoryEnum)|(CategoryStruct)
SDL_CreateRGBSurfaceFrom DOES NOT create a copy of the pixel data.
Thus, the most generic algorithm that follows this formula is the one
I described. Also, note that I was very generic when talking about
memory management; in cases where the application supplies the memory
to the decoder, I would allocate space for the frame once and just
keep reusing it, but since the original poster didn’t specify a movie
format I couldn’t really make any assumptions about how the memory
would be handled.
You still need to get the data onto the screen, which means blitting
from your surface to the screen. You cannot use
SDL_CreateRGBSurfaceFrom to turn a buffer in memory into a hardware
surface. What I suggested is that you render directly to the screen
to save yourself a blit.
Message: 3
Yeah, you could do that, but that’s a huge amount of memory churn, and would
probably consume tons of CPU. ?I wouldn’t be surprised if it noticeably lagged
the system for high resolution videos. ?Is there any native SDL-level support
for video in 1.3?
There isn’t too much inherent memory churn in the algorithm that I
posted that’s actually avoidable.When I talk about releasing the frame, I’m specifically talking about
informing decoder libraries that do their own memory management that a
particular frame is no longer needed (if allowed to do it myself, I
would only allocate the memory once per movie play-through, but some
libraries may not work that way).
Then you do not use those libraries.
In some cases you won’t need to allocate a new surface for each frame,
but unless you’re willing to alter read-only members of the surface
there will be some formats that you’ll need to allocate a new surface
for (in most frames, those formats only encode the pixels that have
changed).
With those formats, you would use a back buffer and a front buffer.
On each frame you read from the back buffer and write to the front
buffer, then swap when you’re done. You do not allocate a new buffer.
Odds are you won’t even need to do that. If only the modified pixels
are recorded, then you just write the new pixels over the old ones.
That can be done directly to the screen. The only problem is when
something overwrites your window, but that’s fixed whenever the
encoder hits an I-frame.
The only time you need two buffers is when the algorithm requires you
to calculate a new pixel value based on data to the left or above in
the previous frame (assuming you’re working top down, left to right).
If the hardware you’re targeting doesn’t support a GPU then you’ll be
better off avoiding the surface-to-texture copy by rendering the
surface directly to the window, but I don’t think SDL 1.3 actually
supports this.
SDL 1.3 still supports the old surface API, which does support this.
SDL_RenderWritePixels can be used to copy from an SDL_Surface or some
other memory buffer to the screen if you’re really determined to do it
your way.
Message: 4
For video, you’re probably better off passing screen->pixels and
screen->pitch to the decoder to render each frame, then draw your
stuff on top if necessary. ?No blits that way, just rendering the
video.
Outside of the surface-to-texture transition, there aren’t any
INHERENT blits with the algorithm I described, because that particular
SDL function uses the pixel data that you provide it instead of
allocating some itself. That’s why I said to release the frame AFTER
you generate the texture (particularly since you have no idea what the
decoder will do with that memory if the decoder originally allocated
it). I suspect that the function was originally created for precisely
this sort of scenario (either that, or images embedded in your
executable).
Again, you still have to get your data onto the screen, and any
decoder that doesn’t let you use your own buffer is junk.On 12 January 2011 00:32, Jared Maddox wrote:
Date: Tue, 11 Jan 2011 14:45:57 -0800 (PST)
From: Mason Wheeler
Date: Tue, 11 Jan 2011 18:49:35 -0500
From: Kenneth Bull <@Kenneth_Bull>
You still need to get the data onto the screen, which means blitting
from your surface to the screen. You cannot use
SDL_CreateRGBSurfaceFrom to turn a buffer in memory into a hardware
surface.
Hardware surfaces no longer exist in SDL 1.3.
What I suggested is that you render directly to the screen
to save yourself a blit.
Drawing directly to the screen causes flicker, and is therefore a very
bad idea. Drawing directly to the back buffer is more sensible, but
still not supported in SDL 1.3.On 1/12/2011 05:31, Kenneth Bull wrote:
–
Rainer Deyke - rainerd at eldwood.com
You still need to get the data onto the screen, which means blitting
from your surface to the screen. You cannot use
SDL_CreateRGBSurfaceFrom to turn a buffer in memory into a hardware
surface.Hardware surfaces no longer exist in SDL 1.3.
Yeah they do, they’re just called “textures” now. 
…which makes me think. Is there any way to accomplish this, or at least to
simplify it, using SDL_UpdateTexture?>----- Original Message ----
From: Rainer Deyke
Subject: Re: [SDL] About SMPEG library
On 1/12/2011 05:31, Kenneth Bull wrote:
SMPEG does NOT support SDL 1.3 textures. I for one could use a simple API
like SMPEG to draw animation movies at various locations on the screen for
the iPhone. The iPhone API (not SDL) only supports full-screen movies.
Has anyone gotten SMPEG to work with SDL 1.3?
Ken> ----- Original Message -----
From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Mason Wheeler
Sent: Wednesday, January 12, 2011 9:56 PM
To: SDL Development List
Subject: Re: [SDL] About SMPEG library----- Original Message ----
From: Rainer Deyke
Subject: Re: [SDL] About SMPEG libraryOn 1/12/2011 05:31, Kenneth Bull wrote:
You still need to get the data onto the screen, which means blitting
from your surface to the screen. You cannot use
SDL_CreateRGBSurfaceFrom to turn a buffer in memory into a hardware
surface.Hardware surfaces no longer exist in SDL 1.3.
Yeah they do, they’re just called “textures” now.
…which makes me think. Is there any way to accomplish this, or at least
to
simplify it, using SDL_UpdateTexture?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I just built SMPEG against SDL 1.3 and successfully played a video…
svn co svn://svn.icculus.org/smpeg/trunk smpeg
cd smpeg
sh autogen.sh
./configure --disable-video-callback-thread
make
./plaympeg foo.mpg
I did have a problem with the video in a separate thread though, since the
renderer was OpenGL and I didn’t make the context current for that thread.
See ya!On Wed, Jan 12, 2011 at 8:07 PM, Ken Rogoway wrote:
SMPEG does NOT support SDL 1.3 textures. I for one could use a simple API
like SMPEG to draw animation movies at various locations on the screen for
the iPhone. The iPhone API (not SDL) only supports full-screen movies.Has anyone gotten SMPEG to work with SDL 1.3?
Ken
-----Original Message-----
From: sdl-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org]
On
Behalf Of Mason Wheeler
Sent: Wednesday, January 12, 2011 9:56 PM
To: SDL Development List
Subject: Re: [SDL] About SMPEG library----- Original Message ----
From: Rainer Deyke
Subject: Re: [SDL] About SMPEG libraryOn 1/12/2011 05:31, Kenneth Bull wrote:
You still need to get the data onto the screen, which means blitting
from your surface to the screen. You cannot use
SDL_CreateRGBSurfaceFrom to turn a buffer in memory into a hardware
surface.Hardware surfaces no longer exist in SDL 1.3.
Yeah they do, they’re just called “textures” now.
…which makes me think. Is there any way to accomplish this, or at least
to
simplify it, using SDL_UpdateTexture?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Sam,
This is great news. Was this using SDL_Texture and the SDL_Renderer? Or
the 1.2 legacy support?
KenFrom: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Sam Lantinga
Sent: Thursday, January 13, 2011 1:00 AM
To: SDL Development List
Subject: Re: [SDL] About SMPEG library
I just built SMPEG against SDL 1.3 and successfully played a video…
svn co svn://svn.icculus.org/smpeg/trunk smpeg
cd smpeg
sh autogen.sh
./configure --disable-video-callback-thread
make
./plaympeg foo.mpg
I did have a problem with the video in a separate thread though, since the
renderer was OpenGL and I didn’t make the context current for that thread.
See ya!
On Wed, Jan 12, 2011 at 8:07 PM, Ken Rogoway wrote:
SMPEG does NOT support SDL 1.3 textures. I for one could use a simple API
like SMPEG to draw animation movies at various locations on the screen for
the iPhone. The iPhone API (not SDL) only supports full-screen movies.
Has anyone gotten SMPEG to work with SDL 1.3?
Ken
----- Original Message -----
From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] OnBehalf Of Mason Wheeler
Sent: Wednesday, January 12, 2011 9:56 PM
To: SDL Development List
Subject: Re: [SDL] About SMPEG library----- Original Message ----
From: Rainer Deyke
Subject: Re: [SDL] About SMPEG libraryOn 1/12/2011 05:31, Kenneth Bull wrote:
You still need to get the data onto the screen, which means blitting
from your surface to the screen. You cannot use
SDL_CreateRGBSurfaceFrom to turn a buffer in memory into a hardware
surface.Hardware surfaces no longer exist in SDL 1.3.
Yeah they do, they’re just called “textures” now.
…which makes me think. Is there any way to accomplish this, or at least
to
simplify it, using SDL_UpdateTexture?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
This was with the 1.2 legacy support. There’s nothing preventing it from
being rewritten with textures directly, but there’s no great advantage
either. All the legacy support is in SDL_compat.c, and you’ll see there
isn’t that much to the YUV overlay support.
See ya!On Wed, Jan 12, 2011 at 11:05 PM, Ken Rogoway wrote:
Sam,
This is great news. Was this using SDL_Texture and the SDL_Renderer? Or
the 1.2 legacy support?Ken
From: sdl-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org]
*On Behalf Of *Sam Lantinga
Sent: Thursday, January 13, 2011 1:00 AMTo: SDL Development List
Subject: Re: [SDL] About SMPEG libraryI just built SMPEG against SDL 1.3 and successfully played a video…
svn co svn://svn.icculus.org/smpeg/trunk smpeg
cd smpeg
sh autogen.sh
./configure --disable-video-callback-thread
make
./plaympeg foo.mpgI did have a problem with the video in a separate thread though, since the
renderer was OpenGL and I didn’t make the context current for that thread.See ya!
On Wed, Jan 12, 2011 at 8:07 PM, Ken Rogoway wrote:
SMPEG does NOT support SDL 1.3 textures. I for one could use a simple API
like SMPEG to draw animation movies at various locations on the screen for
the iPhone. The iPhone API (not SDL) only supports full-screen movies.Has anyone gotten SMPEG to work with SDL 1.3?
Ken
-----Original Message-----
From: sdl-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org]
OnBehalf Of Mason Wheeler
Sent: Wednesday, January 12, 2011 9:56 PM
To: SDL Development List
Subject: Re: [SDL] About SMPEG library----- Original Message ----
From: Rainer Deyke
Subject: Re: [SDL] About SMPEG libraryOn 1/12/2011 05:31, Kenneth Bull wrote:
You still need to get the data onto the screen, which means blitting
from your surface to the screen. You cannot use
SDL_CreateRGBSurfaceFrom to turn a buffer in memory into a hardware
surface.Hardware surfaces no longer exist in SDL 1.3.
Yeah they do, they’re just called “textures” now.
…which makes me think. Is there any way to accomplish this, or at least
to
simplify it, using SDL_UpdateTexture?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Yes, but can you mix both in an application? If I have my app that uses
the new way of rendering in SDL 1.3, can I also use the 1.2 legacy functions
to draw on top? I didn’t think that would work since you render to a
SDL_Surface with the legacy code and you render to a SDL_Window using
SDL_Render_Copy with SDL 1.3.
If an app wants to take full advantage of SDL 1.3, it should use SDL 1.3
rendering functions, correct?
KenFrom: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Sam Lantinga
Sent: Thursday, January 13, 2011 1:12 AM
To: SDL Development List
Subject: Re: [SDL] About SMPEG library
This was with the 1.2 legacy support. There’s nothing preventing it from
being rewritten with textures directly, but there’s no great advantage
either. All the legacy support is in SDL_compat.c, and you’ll see there
isn’t that much to the YUV overlay support.
See ya!
On Wed, Jan 12, 2011 at 11:05 PM, Ken Rogoway wrote:
Sam,
This is great news. Was this using SDL_Texture and the SDL_Renderer? Or
the 1.2 legacy support?
Ken
From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Sam Lantinga
Sent: Thursday, January 13, 2011 1:00 AM
To: SDL Development List
Subject: Re: [SDL] About SMPEG library
I just built SMPEG against SDL 1.3 and successfully played a video…
svn co svn://svn.icculus.org/smpeg/trunk smpeg
cd smpeg
sh autogen.sh
./configure --disable-video-callback-thread
make
./plaympeg foo.mpg
I did have a problem with the video in a separate thread though, since the
renderer was OpenGL and I didn’t make the context current for that thread.
See ya!
On Wed, Jan 12, 2011 at 8:07 PM, Ken Rogoway wrote:
SMPEG does NOT support SDL 1.3 textures. I for one could use a simple API
like SMPEG to draw animation movies at various locations on the screen for
the iPhone. The iPhone API (not SDL) only supports full-screen movies.
Has anyone gotten SMPEG to work with SDL 1.3?
Ken
----- Original Message -----
From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] OnBehalf Of Mason Wheeler
Sent: Wednesday, January 12, 2011 9:56 PM
To: SDL Development List
Subject: Re: [SDL] About SMPEG library----- Original Message ----
From: Rainer Deyke
Subject: Re: [SDL] About SMPEG libraryOn 1/12/2011 05:31, Kenneth Bull wrote:
You still need to get the data onto the screen, which means blitting
from your surface to the screen. You cannot use
SDL_CreateRGBSurfaceFrom to turn a buffer in memory into a hardware
surface.Hardware surfaces no longer exist in SDL 1.3.
Yeah they do, they’re just called “textures” now.
…which makes me think. Is there any way to accomplish this, or at least
to
simplify it, using SDL_UpdateTexture?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC