USS Clueless - MPEG conversions
     
     
 

Stardate 20021226.0127

(Captain's log): I was spending some time today, just for the heck of it, experimenting with a program called "FlaskMPG" which allows you to convert segments of DVDs into other formats. When I use it to encode into Indeo 5.10 for the output, it always crashes when a conversion completes, which is something of a pain. And while Indeo 5.1 is a good codec, I wanted to see what I could do with the new MPEG 4 format. It uses a much more sophisticated way of encoding than MPEG 2, which is what's used on DVDs, and you can get a hell of a lot more compression with little loss of quality, at the expense of a vast increase in the compute cost. It wasn't really practical to use these algorithms until recently because CPUs weren't really fast enough.

But they damned well are now. I have a workstation based on two 2.4 GHz Xeons, and I was using FlaskMPG with DivX 5.02, and it turns out that DivX takes advantage of SMP. With both CPUs fully pegged, I was converting full resolution video at approximately real-time speeds on encoding. Depending on what I was doing, it encoded at anything from 25 to 35 frames per second. Playback consumes about 40% of one of the two CPUs.

When I first kicked it in to convert a sample, I thought something was wrong because it had finished so rapidly. I had been experimenting with the built-in MPEG2 codec in FlaskMPG, and not only did it convert at only about 4 frames per second, but it also produced truly mammoth files and it wasn't using the second CPU, and it quite evidently wasn't using SSE2.

So kick in code which was actually optimized for the P4 which knows about SMP, and the difference was quite startling.

But I still have to figure out how to make FlaskMPG handle audio the right way, and I'm not sure what I'm doing wrong. A 5 minute clip with 16-bit stereo sound ended up being an 85 megabyte file, which seemed too large to me. So I tried converting it without audio and it ended up being 25 megabytes. 8 bit mono sound boosts it to 39M; and 16-bit mono to 53M. How in hell can the audio take more space than the video?

While I have the ability to choose any of a large number of video codecs, it only lets me choose "PCM" for audio encoding, and the PCM codec really sucks. (Grumble). Of course, when you're using free software you don't have any right to complain, but there's an audio codec in DivX, and at the very least I should be able to select MP3 (one would think). So I have to spend some time googling and see if I can figure out why it is that no other audio codecs appear as choices. One possibility that occurs to me which I'll have to check is that I was feeding it 48 kilobit audio, and I bet that I have to tell it to resample to 44.1 kilobit to access anything else. Wanna bet? (pause while the Captain goes and tries it...)

And sure enough, when I change the audio sample rate, I am presented with a list of choices. Problem is I don't know what any of them mean, and I don't know how common any of them are. Most of them look like telephony codecs, which is not exactly ideal for movies. (CCITT A-law, CCITT u-law, GSM 6.10, IMA ADPCM, Microsoft ADPCM, and Voxware Metasound. No sign of MP3 or Frauenhofer or anything like that.)

So I just tried one of the Voxware choices, and the resulting file is the same size as one with no audio, and the player fatals when trying to play it. Rats.

I do not want my video file to have audio that sounds like a cell phone. Not acceptable. (Oh well, it's late, and I'll see what I can figure out tomorrow.)

Update: So with the installation of Vidomi (thanks, David) and the Radium MP3 codec (thanks, Urijah) and suddenly it's all a lot better. Now there's only 4MB difference between sound and no-sound in that 5-minute clip I was experimenting with. Much better...


include   +force_include   -force_exclude

 
 
 

Main:
normal
long
no graphics