Vidiot

All I wanted to do was convert some clips… I’ve collected a number of little bits of video over the years, but they’re sometimes a bit of a pain to deal with. They’re in a zillion different formats, have to be played back on the computer, are often too small on the monitor and don’t look good when blown up to full screen, and need something a bit faster than my 400 MHz Linux box anyway. (The other, faster one’s often in XP for games.)

Fortunately there’s an easy solution: Video CDs! Simply convert everything to MPEG files, burn them to CD, and I can play them on my DVD player instead.

It turns out that video is a bit more complex than I had anticipated…

The first and most obvious problem is that there aren’t really many user-friendly tools for manipulating video on Linux; nothing anywhere close to something like Final Cut Pro, at least. Most of the GUI tools are for fairly simple tasks like splicing clips, and for format conversion, encoding, and such you have to go to the command line tools. That’s fine, I’m certainly no stranger to the command line.

After finally installing all of the packages that were related to video processing, I had the programs I needed. 86 of them, to be exact. Where the hell do I start??? Fortunately, MPlayer comes with a shell script, ‘mencvcd’, that would go through all the steps necessary to do what I wanted, automatically invoking all of the video utilities with all the appropriate parameters.

Except it didn’t work. Debugging the script to find out just what went wrong revaled that it basically does the following:

• Takes the video file and decodes it into separate streams, one for the raw video frames in YUV format and another for the audio track, in WAV format.
• Scales the video stream in order to match the standard VCD resolution of 352×240.
• Feeds the video stream to mpeg2enc to encode it as an MPEG-1 stream, again matching VCD specs.
• Encodes the audio as an MP2 file.
• Merges the video and audio streams back together into a single file, usable as a VCD track.

The last step of merging the streams back together was the point of failure, due to a change in how some parameters were parsed, and that was easily fixed.

Except that didn’t work either. The ‘mplex’ program that does the merging often complained about “too many buffer underflows” and would fail to generate a complete MPEG file. Well that doesn’t do me any good… So, I investigated other options, and had it use the ‘tcmplex’ program instead. It does the same thing, but didn’t complain, so everything finally seemed fine. I could now take any video file, turn it into an MPEG file, and burn it to a VCD.

With the major problems out of the way, it was time to tinker. There were little tweaks to learn about for improving the quality of the final output. Things like applying noise removal, blanking widescreen bars for a more compressible true black, various arcane settings for the MPEG encoder, etc. The final output actually looks pretty decent, with little or none of the blockiness you usually see in MPEG-1 video. Adding all this extra tuning slows the process down quite a bit; it takes about an hour of real time for every four minutes of video converted this way. Fortunately this system has a lot of otherwise idle time to spare…

There was still one minor problem, though: the audio and the video didn’t seem to be entirely in sync. It was usually unnoticable since I was primarily encoding animation, where lip movements and such often don’t sync up perfectly anyway, but it was a bit more obvious in certain scenes with movement or action. The multiplexer allows you to specify an offset between the audio and the video to get them back into sync, but that required experimenting with various values for each video, which was a pain in the rear.

Another problem was that the frame rates weren’t technically VCD compliant. My video capture card ^{er second, but to be compliant the output stream has to be either 29.97 or 23.976 frames per second. A parameter could be set to mark it as 29.97 instead of 30, but then the audio and video would drift apart slightly while playing. Another step would be required to drop frames to make the frame rate match properly, but the mencvcd script didn’t already do that.}

Annoyed by these problems I finally decided to check out the main ‘transcode’ program from the package that tcmplex came from in the first place. I’m still experimenting with it, but it looks promising so far. It doesn’t seem to have the audio/video sync problem that the use of MPlayer did (MPlayer appears to be sensitive to CPU speed, even when it’s just dumping the data to files and not actually displaying the video) and it can easily compensate for the 30/29.97 frame rate difference.

I also discovered that I could get ‘mplex’ to work without complaining if I used the standard ‘VCD’ profile instead of ‘user VCD’ (the mencvcd script would try and use the latter). The streams generated by mplex and tcmplex are roughly the same size, but ‘vcdimager’ complains about having to pad the stream generated by ‘tcmplex’, so I feel safer going back to ‘mplex’ again.

So, now I’ve basically completely switched the packages around. Instead of using MPlayer with ‘tcmplex’, I’m using ‘transcode’ with ‘mplex’. :-P Whatever gets the job done though.

And in the end it turns out that my DVD player can’t play VCDs burned onto a CD-R anyway, and CD-RWs are iffy; they play, but with video and audio glitches. Oh well, when I get a replacement I’ll make sure it can.

And all I wanted to do was convert some clips…

(Although it would be nice to get the whole process down to ‘push the magic button and it makes what you want’ it’s a bit too complex for that, but scripts can help out a lot. If you’re interested, here is a wrapper script I’m using with ‘transcode’ in order to simplify the process a bit more. Makes it a bit easier to deal with the umpteen zillion options available when doing a plain VCD encode.)

1. As an aside, the video capture card I have can actually record directly to a VCD-compatible MPEG stream, but I choose not to. Why? Because the quality of the resulting stream is *awful*, likely due to the real-time encoder it has to use. I get much better results if I record using its high-quality mode and then go through the ‘transcode’ steps to convert it down to the VCD bitrate instead.