# Smpeg/glmovie crawls

**URL:** <https://discourse.libsdl.org/t/smpeg-glmovie-crawls/6980>\
**Category:** SDL Development\
**Created:** [July 2, 2002, 8:15pm UTC](https://discourse.libsdl.org/t/smpeg-glmovie-crawls/6980 "2002-07-02T20:15:01Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Gib\_Bogle](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/d2c977/32.png) [@Gib\_Bogle](https://discourse.libsdl.org/u/Gib_Bogle)\
**Post date:** [July 2, 2002, 8:15pm UTC](https://discourse.libsdl.org/t/smpeg-glmovie-crawls/6980/1 "2002-07-02T20:15:01Z")

</div>

(I’m posting about this here because as far as I know the suggested  
place for raising such issues, smpeg at [lokigames.com](http://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

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [July 2, 2002, 9:50pm UTC](https://discourse.libsdl.org/t/smpeg-glmovie-crawls/6980/2 "2002-07-02T21:50:01Z")

</div>

> 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.

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [July 2, 2002, 9:54pm UTC](https://discourse.libsdl.org/t/smpeg-glmovie-crawls/6980/3 "2002-07-02T21:54:00Z")

</div>

> > 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? 🙂

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

---

<div class="post-metadata">

**Author:** ![Romi\_Kuntsman](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/r/2acd7d/32.png) [@Romi\_Kuntsman](https://discourse.libsdl.org/u/Romi_Kuntsman)\
**Post date:** [July 3, 2002, 9:43am UTC](https://discourse.libsdl.org/t/smpeg-glmovie-crawls/6980/4 "2002-07-03T09:43:00Z")

</div>

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? 🙂
> 
> 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.

---

<div class="post-metadata">

**Author:** ![Paulo\_Pinto](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/p/7cd45c/32.png) [@Paulo\_Pinto](https://discourse.libsdl.org/u/Paulo_Pinto)\
**Post date:** [July 3, 2002, 10:15am UTC](https://discourse.libsdl.org/t/smpeg-glmovie-crawls/6980/5 "2002-07-03T10:15:01Z")

</div>

> 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? 🙂
> > 
> > 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](http://libsdl.org) [mailto:sdl-admin at [libsdl.org](http://libsdl.org)]On Behalf Of  
> Sent: quarta-feira, 3 de Julho de 2002 18:42  
> To: sdl at [libsdl.org](http://libsdl.org)  
> Subject: Re: [SDL] smpeg/glmovie crawls

---

<div class="post-metadata">

**Author:** ![Gib\_Bogle](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/d2c977/32.png) [@Gib\_Bogle](https://discourse.libsdl.org/u/Gib_Bogle)\
**Post date:** [July 3, 2002, 3:10pm UTC](https://discourse.libsdl.org/t/smpeg-glmovie-crawls/6980/6 "2002-07-03T15:10:01Z")

</div>

> 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? 🙂
> > > 
> > > 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 (c) 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](http://libsdl.org)
> 
> > -----Original Message-----  
> > From: sdl-admin at [libsdl.org](http://libsdl.org) [mailto:sdl-admin at [libsdl.org](http://libsdl.org)]On Behalf Of  
> > Sent: quarta-feira, 3 de Julho de 2002 18:42  
> > To: sdl at [libsdl.org](http://libsdl.org)  
> > Subject: Re: [SDL] smpeg/glmovie crawls

---

<div class="post-metadata">

**Author:** ![Loren\_Osborn](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/l/7c8e57/32.png) [@Loren\_Osborn](https://discourse.libsdl.org/u/Loren_Osborn)\
**Post date:** [July 3, 2002, 5:30pm UTC](https://discourse.libsdl.org/t/smpeg-glmovie-crawls/6980/7 "2002-07-03T17:30:02Z")

</div>

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  
> (c) 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://libsdl.org)  
> [http://www.libsdl.org/mailman/listinfo/sdl](http://www.libsdl.org/mailman/listinfo/sdl)

* * *

Do You Yahoo!?  
Sign up for SBC Yahoo! Dial - First Month Free

> **[Currently.com - AT&T Yahoo Email, News, Sports & More](https://currently.att.yahoo.com/)**
>
> Get the latest in news, entertainment, sports, weather and more on Currently.com. Sign up for free email service with AT&T Yahoo Mail.

---

<div class="post-metadata">

**Author:** ![Gib\_Bogle](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/d2c977/32.png) [@Gib\_Bogle](https://discourse.libsdl.org/u/Gib_Bogle)\
**Post date:** [July 4, 2002, 2:28pm UTC](https://discourse.libsdl.org/t/smpeg-glmovie-crawls/6980/8 "2002-07-04T14:28:01Z")

</div>

> 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](http://yahoo.com)\>  
> Subject: RE: [SDL] smpeg/glmovie crawls  
> To: sdl at [libsdl.org](http://libsdl.org)  
> Reply-To: sdl at [libsdl.org](http://libsdl.org)

* * *

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