OESF Portal | OESF Forum | OESF Wiki | LinuxPDA | #planetgemini chat on matrix.org | #gemini-pda chat on Freenode | #zaurus and #alarmz chat on Freenode | ELSI (coming soon) | Ibiblio


Welcome Guest ( Log In | Register )

Reply to this topicStart new topic
> A Note About Libmpeg2 Support In Scummvm, unless you want to really mod ScummVM...
post Feb 28 2006, 02:27 AM
Post #1

Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928

I have been playing with ScummVM 8.2 on OpenBSD and it works pretty well especially when SDL and scummvm are built with xscale optimisations.

I would, however, have liked to have the video support working well on Broken Sword 2 and have had this built into various test attempts on PDAXROM, Cacko and OpenBSD in the past and all have yielded extremely poor performance. I assumed that this was due to video bitrate of the provided mpeg2 files so when I found instructions yesterday (on the pocketscumm site) on how to re-encode these files I did so and found... it was still darned slow.

I then took a good look at libmpeg2 (also built with xscale optimisation) to see if there was any floating point stuff that could be optimised and I found that it actually comes with a player.

Running the player against these files produces perfect video, however, when run through ScummVM you get about 1 frame every 2 seconds.

Finally I took a look at ScummVM and found that ScummVM calls the render code from libmpeg2 and renders it internally to a buffer that it draws with a routine called drawYUV. It also attempts to time music playback against the frames that it emits to the display and introduces frame skip to attempt to synchronise music against video (in Sword2 the sound and video come from seperate files). This isn't a great way of doing this for a few reasons.

i. The libmpeg2 library still has to render all the frames anyway because mpeg2 uses a key frame and incremental update mechanism for rendering individual frames - non key frames therefore require incremental changes from the last key frame. So the hard work of mpeg2 rendering has been done already, all ScummVM is skipping is its output of the frames.

ii. In most X server implementations on the Zaurus the display is handled by a Shadow Frame buffer since the natural screen orientation is portrait. This means that libmpeg2 is rendering a frame to a buffer, the drawYUV command is rendering to shadow buffer and finally the X server renders the shadow frame buffer to the display.. this is a lot of information to pump out frame by frame (many buffer copies here per frame)

So unless somebody fancies rejigging ScummVM radically in the area of video playback don't expect to get these video cutscenes at a reasonable frame rate.

Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:


RSS Lo-Fi Version Time is now: 19th June 2018 - 03:23 PM