Additional notes on Beetle’s Tutorial for Aniplayer video encoding.
Ho there eagerly awaiting Low Res fans, it’s time for some more article reading related fun with some educational tips thrown in. In my token nod to the latter part of our mission, here’s some of my observations made after I followed Beetle’s excellent tutorial from last issue. As you may recall he was sharing his hard-won secrets about converting movie files to allow them to play without stuttering or stopping on Didier Mequignon’s Aniplayer program.
Beetle’s tutorial was written mostly for the benefit of those of us using very high-end Falcons, with some fairly specific tips about getting the best trade-off between the original movie and an end-product which would still have a reasonable quality and play back comfortably on the CT60 family.
Now I didn’t follow the exactly specified steps with his suggested example movie file. Instead for my first attempt, I broke from the tutorial in two important respects.
Firstly, the choice of film, as I decided to make the first attempt from one of my own ill-advised ‘home movies’. In this case it was the compilation of my bits recorded from the Sundown 2010 demo party. A report for which is elsewhere in this issue.
Secondly, I decided to try converting for a different level of Atari hardware. At the end of his article, Beetle threw in some useful suggestions about converting a movie file to play on a standard unexpanded Falcon. I opted for something in between the CT60 and the bog standard machine, namely the Centurbo 2 (CT2) accelerated Falcon.
The CT2 series, just to remind you, adds a 50 Mhz 68030 CPU, up to 64 MB Fast RAM, with DSP clocked from 32 to 50 Mhz and bus speed boosted from 16 to 25 Mhz offering an option for enhanced truecolor resolution. So it has sheer processor grunt somewhat better than the baseline machine but still quite low compared to the CT60 and it also has enhanced data bus speed. I opted for an in-between size to go with the in-between hardware, converting my original 640 x 480 resolution source file to something more suitable for my choice of target hardware.
Here are some notes about the movie file which was created from following Beetle’s tutorial. Much of this information being taken from Aniplayer itself of course 🙂
On-Screen Size 240 x 180 pixels (actually 240 x 176)
Played at 16 frames per second, frame skip enabled on Aniplayer
Key frame interval = 0
Number of frames – 9575
File size – 98825858 KB
Length of movie playback – 6 minutes, 23 seconds
Audio 16 bit mono at 16390 Hz with APCM compression
The movie played back pretty faithfully in the recommended non-GEM windowed mode with no noticeable time lag and only the occasional hint of slowdown on the audio. The windowed mode was a slightly different story with an increased playback time at 9 minutes and 58 seconds. This is quite a difference from 6 minutes 23 seconds. I didn’t really notice any major video slowdown but the audio slowed noticeably when onscreen traffic was busy and started to distort very slightly.
The intensity of CPU usage varied when running the sample movie in windowed mode. This went from 25 percent as a base, settling around the middle between 66 and 83 percent, but sometimes going up to 91 or 100 percent. And before you ask, of course the DSP was enabled! So it is possible to run this type of file windowed on a CT2 machine but still better to play back in non-GEM mode.
In non-GEM mode, the 240 x 176 resolution offered a reasonable quality playback, a little bit compromised with some degradation of video quality, but not fatally so. In fact I think that added to the overall charm when combined with what is properly a retro platform. The onscreen viewing window for non-GEM display was a reasonable size, with subtitling still legible. This confirms to me that the 240 x 180 size is an acceptable compromise for CT2 and similar specified Falcons.
Other observations and points of interest.
The size of the movie file is hefty. In this case it works out at around 12-15 megabytes per minute of onscreen footage. There is no reduction over the file size of the source material in spite of the big screen resolution drop. This suggests that a less fierce compression method is being used to give Aniplayer a fighting change of depacking it with limited CPU power. (Limited when compared with a modern machine of course.) Can someone who knows what they are talking about confirm this?
Never mind, one thing that has got abundant and cheap these days is bulk storage.
The created movie file tended to crash fatally on the Windows version of the Videolan VLC player. This really killed that program, freezing or locking up completely and needing to delve into the program manager to unblock the application. This made me very nervous in case I’d somehow missed something important from the tutorial and I’d just created a ruined and useless file. The Mac version of VLC was alright with it though, and more importantly, Aniplayer was completely happy with it!
* Further note. This issue went away once I upgraded my older version of VLC player.
I decided to go that extra unnecessary step and see how this movie managed on a 16 mhz Falcon. Beetle recommended a video mode of 160 x 80 with audio set at 16390 Hz when porting movies for the baseline machine. Well I would charitably say that a valiant attempt was made by Aniplayer. The soundtrack and video playback could be described as ‘languorous’ or on opiates, but we got there in the end, at about 10 minutes and 24 seconds. But it didn’t drop anything, played back completely and still performed a lot better than an unconverted movie would have on a CT60.
* Further note – I’m finding out new things all the time here. I converted an ultra widescreen movie trailer for Deathly Hallows to a somewhat letterboxed 240 x 80 pixel format, audio as before, and this played back just fine with no slowdown on a 16 mhz Falcon. Which is as far as you can push that one, I guess?
Hey, now we’re here and going wildly out of context, let’s see how it did on Aranym. My version of Aranym is for a Power PC Mac. That is without the super turbo native processor mode to fudge the speed issue. This offers a semi-realistic 68040 environment to play with.
I say semi-realistic as it demanded between 50 and 66 percent of the CPU. You can tell this is still a work in progress as sound quality via the emulated DSP was severely compromised. It was both slower with a fair bit of distortion and forced high pitch as if force fed helium. So I don’t fancy that one again, thanks very much.
*Further further observations, made some time later*
Thus suitably equipped, I tried my movie porting magic on a number of other short films close to my heart. I’m gratified to say that results there were generally fine but with one or two caveats.
1. When I converted the ‘Outline 2009 from above’ movie, I seemed to get reasonable video playback but very slow sound. This may have been down to me playing around with the sound settings, so I’m inclined to blame that one on user inattention.
2. A couple of movies suffered from noticeable artifacting or black speckles on screen after dropping down to a lower resolution. These were taken from a low quality source though, so this just might be a case of choosing your subject matter carefully, or going through with it anyway and to hell with the consequences.
I hope this article adds some extra value to the already excellent work done by Beetle for the previous issue of Low Res Mag. The tutorial proved to be easy to adapt according to taste and hardware levels. I’m certainly going to go through my collection to see what else can be ported. Not to mention I might get around to doing some specifically for CT60 as well soon 🙂
CiH for Low Res Mag, Nov/Dec 2010.