Smpeg/glmovie crawls

(I’m posting about this here because as far as I know the suggested
place for raising such issues, smpeg at lokigames.com, doesn’t exist any
more. Please correct me if I’m wrong about this.)

I’m trying to find out why glmovie plays an mpg file at about 1 fps,
while plaympeg plays it at the right speed, about 30 fps. As far as I
can tell from a quick glance both programs use the same smpeg library
functions, but glmovie does more GL stuff with glTexSubImage2D(). A
quick check shows that the function glmovie_draw() is only using 5 ms
(fast graphics card), so the problem must lie on the smpeg side, with
the reading/decoding of the frame that is passed to glmovie_draw().

I looked at MPEGvideo.cpp, and tried defining TIME_MPEG, which causes
the frames to be read as fast as possible. plaympeg then reports 177
frames in 0.58 sec (307 fps), while glmovie reports 177 frames in 1.51
sec (117 fps). I’m not sure why these rates should differ, but in any
case they are very fast. With plaympeg I see the video at high speed,
while in most cases glmovie just shows a blank screen, although on one
occasion I saw the last couple of frames (in this case the time was 2.6
sec).

It almost looks like a thread timing issue, but why should glmovie
differ from plaympeg in this regard?

Any suggestions?

Gib–

Gib Bogle @Gib_Bogle
1/44 Arthur St Tel: (64-9) 525-6878
Ellerslie, N.Z. Fax: (64-9) 525-6878

It almost looks like a thread timing issue, but why should glmovie
differ from plaympeg in this regard?

Are you sure you aren’t in software Mesa?

–ryan.

It almost looks like a thread timing issue, but why should glmovie
differ from plaympeg in this regard?

Are you sure you aren’t in software Mesa?

It might also be the apparent threading issue with glmovie that was
discussed earlier. Anybody brave enough to dig into glmovie and smpeg
and figure out the right way to do it? :slight_smile:

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Sam Lantinga wrote:

It almost looks like a thread timing issue, but why should glmovie
differ from plaympeg in this regard?

Are you sure you aren’t in software Mesa?

It might also be the apparent threading issue with glmovie that was
discussed earlier. Anybody brave enough to dig into glmovie and smpeg
and figure out the right way to do it? :slight_smile:

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

This is a threading issue indeed.
In the Delphi port of glMovie, it doesn’t even work with threads at all,
but when glmpeg_update() is in the main loop it works just fine!

It appears that OpenGL already contains lot’s of “invalid command” error
in it’s queue when glmpeg_update() is called from the seperate thread
(unlike from the main thread). Maybe OpenGL doesn’t really like threads
(as it is a state machine), or that SMPEG does some stuff that mess up
stuff in OpenGL…

RK.

Romi Kuntsman

Sam Lantinga wrote:

It almost looks like a thread timing issue, but why should glmovie
differ from plaympeg in this regard?

Are you sure you aren’t in software Mesa?

It might also be the apparent threading issue with glmovie that was
discussed earlier. Anybody brave enough to dig into glmovie
and smpeg
and figure out the right way to do it? :slight_smile:

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

This is a threading issue indeed.
In the Delphi port of glMovie, it doesn’t even work with
threads at all,
but when glmpeg_update() is in the main loop it works just fine!

It appears that OpenGL already contains lot’s of “invalid
command” error
in it’s queue when glmpeg_update() is called from the seperate thread
(unlike from the main thread). Maybe OpenGL doesn’t really
like threads
(as it is a state machine), or that SMPEG does some stuff
that mess up
stuff in OpenGL…

OpenGL doesn’t support threads. You must use a rendering
context per thread.

Paulo Pinto> -----Original Message-----

From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Sent: quarta-feira, 3 de Julho de 2002 18:42
To: sdl at libsdl.org
Subject: Re: [SDL] smpeg/glmovie crawls

Message: 29

Romi Kuntsman

Sam Lantinga wrote:

It almost looks like a thread timing issue, but why should glmovie
differ from plaympeg in this regard?

Are you sure you aren’t in software Mesa?

It might also be the apparent threading issue with glmovie that was
discussed earlier. Anybody brave enough to dig into glmovie
and smpeg
and figure out the right way to do it? :slight_smile:

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

This is a threading issue indeed.
In the Delphi port of glMovie, it doesn’t even work with
threads at all,
but when glmpeg_update() is in the main loop it works just fine!

It appears that OpenGL already contains lot’s of “invalid
command” error
in it’s queue when glmpeg_update() is called from the seperate thread
(unlike from the main thread). Maybe OpenGL doesn’t really
like threads
(as it is a state machine), or that SMPEG does some stuff
that mess up
stuff in OpenGL…

OpenGL doesn’t support threads. You must use a rendering
context per thread.

There are two issues involved here, which may or may not stem from the
same basic cause:

  1. The callback to do the OpenGL drawing doesn’t work, and the draw
    function has to be in the main thread.
  2. With the draw function in the main thread, performance is abysmal.

As far as I know, the only OpenGL functions used are in the draw
function, which is executing at a great rate, taking only 5 ms.
Therefore the performance problem seems unrelated to OpenGL. The
problem is that the draw function is repeatedly drawing the same frame,
since the frame is not getting updated - an smpeg problem.

I am willing to accept Sam’s invitation, and delve into this. This
might not achieve the desired result though, because I (a) have no C++
experience (b) have no game programming experience © have virtually no
thread programming experience and (d) am over 50. So don’t hold your
breath. One thing - it is bound to be educational.

Gib> From: “Paulo Pinto”

To:
Subject: RE: [SDL] smpeg/glmovie crawls
Date: Wed, 3 Jul 2002 18:21:25 +0100
Reply-To: sdl at libsdl.org

-----Original Message-----
From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Sent: quarta-feira, 3 de Julho de 2002 18:42
To: sdl at libsdl.org
Subject: Re: [SDL] smpeg/glmovie crawls

Are you perhaps using SDL_mixer?

There is a problem if you don’t tell smpeg that it’s
supposed to use SDL_mixer… it’s trying to sync with
the audio, but unless it’s configured properly, it
doensn’t know if/when the audio is playing…

look in : smpeg-0.4.3/README.SDL_mixer

that might help…

-Loren

— Gib Bogle wrote:>

There are two issues involved here, which may or may
not stem from the
same basic cause:

  1. The callback to do the OpenGL drawing doesn’t
    work, and the draw
    function has to be in the main thread.
  2. With the draw function in the main thread,
    performance is abysmal.

As far as I know, the only OpenGL functions used are
in the draw
function, which is executing at a great rate, taking
only 5 ms.
Therefore the performance problem seems unrelated to
OpenGL. The
problem is that the draw function is repeatedly
drawing the same frame,
since the frame is not getting updated - an smpeg
problem.

I am willing to accept Sam’s invitation, and delve
into this. This
might not achieve the desired result though, because
I (a) have no C++
experience (b) have no game programming experience
© have virtually no
thread programming experience and (d) am over 50.
So don’t hold your
breath. One thing - it is bound to be educational.

Gib


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

Message: 9

Are you perhaps using SDL_mixer?

There is a problem if you don’t tell smpeg that it’s
supposed to use SDL_mixer… it’s trying to sync with
the audio, but unless it’s configured properly, it
doensn’t know if/when the audio is playing…

look in : smpeg-0.4.3/README.SDL_mixer

that might help…

No, I’m not using SDL_mixer. But I believe the problem is in the sync
area. In one run successive calls to timeSync() took 25, 57, 88, 126,
157, … ms, i.e. the nth call takes about n*30 ms. Could this be
related to the fact that the mpg file has no audio? I hope to nail this
soon.

Gib> Date: Wed, 3 Jul 2002 17:29:00 -0700 (PDT)

From: Loren Osborn <linux_dr at yahoo.com>
Subject: RE: [SDL] smpeg/glmovie crawls
To: sdl at libsdl.org
Reply-To: sdl at libsdl.org


Gib Bogle @Gib_Bogle
1/44 Arthur St Tel: (64-9) 525-6878
Ellerslie, N.Z. Fax: (64-9) 525-6878