MP4/MPEG to MOV converters that can handle any color depth

[bestobothworlds]

I just got a Wrath of Cortex intro from the web that I would like to run on my LC. It's in MPEG format and I would like to convert it to a Cinepak compressed 4 bit color format to reduce the memory footprint. I also plan to convert a few Mac ads to use as startup movies for both of my 68k based machines. Is there a conversion program for OS9 or OSX (OS9 preferred) that could do this for me?

 

[tomlee59]

Could you say a little more about what the source file is? "MPEG" can mean a lot of very different things...even MP4 is a bit unspecific.

In OS9, you have relatively few options. If you've got something in a QT-readable format, you can use (free!) MoviePlayer 2.5.1 to export to a number of different formats. I've never exported into anything other than MPEG1, but I believe Cinepak is supported out of the box. MJPEG-A and -B are, too, IIRC. These can be attractive for machines like the LC because of their light decode requirements.

If you are willing to consider MPEG1 output, you can use Movie2MPEG (also free). By playing with the resolution/framerate/bitrate options, you may be able to produce a result that satisfactorily balances your filesize targets against quality.

There are many more options in X. The ever-popular ffmpegX is the basic Swiss Army knife of video in X. It's a bit buggy (sometimes maddeningly so), but a bargain at 15 bucks (trialware).

 

[alk]

If you are willing to consider MPEG1 output, you can use Movie2MPEG (also free). By playing with the resolution/framerate/bitrate options, you may be able to produce a result that satisfactorily balances your filesize targets against quality.
There are many more options in X. The ever-popular ffmpegX is the basic Swiss Army knife of video in X. It's a bit buggy (sometimes maddeningly so), but a bargain at 15 bucks (trialware).

MPEG1 cannot be decoded on an LC. Apple only supported MPEG1 playback on the 630/640 and rougly equivalent 5x0 Macs. And then you need to have the PDS MPEG decoder card and the AV-input card. All PowerPC Macs can decode MPEGs in software, of course. But 68ks cannot.

Pretty much the only choice is Cinepak video.

Peace,

Drew

 

[tomlee59]

That's what I get for not thinking carefully. I even knew this.

Doh!



Cinepak it is!

 

[tomlee59]

Btw, if you use MoviePlayer 2.5 for the conversion, you'll want to export to AVI (not to be confused with Divx AVI, although it could do that, too, with the Divx codec installed). That's what you need to choose to transcode into Cinepak.

Allegedly, a fast '040 Mac can handle 320x240 playback of Cinepak video at conventional movie framerates.

 

[JWG Design]

Alk is correct in that 68k Macs cannot decode MPEG-1 video in real-time without a hardware decoder. There is a software decoder that allows conversion from MPEG-1 to Quicktime. It is called Sparkle. It also comes with an MPEG splitter and an MPEG-2 decoder.

> http://www.umich.edu/~archive/mac/graphics/graphicsutil/sparkle2.45.sit.hqx

The conversion won't be fast on an LC, but it should work. MPEG decoding is very processor intensive, and so is Cinepak encoding.

If the video is in color, then leave Cinepak's settings at Millions of Colors (24-bit). Cinepak will not be any more efficient at 8-bit than at 24-bit, and it will dither on playback without a hitch.

You may want to consider decoding MPEG to PhotoJPEG at highest quality. (PhotoJPEG is a great intermediate codec, and it beats havine to decode MPEG for every new conversion.) Then using Movie Player to encode different versions (or samples) with different settings. Apple's Video codec performs well on older Macs, although it is not as efficient as Cinepak.

 

[JWG Design]

If you're going to do the conversion on the LC, this is the procedure:

1. Use MPEG Splitter to split the audio and video into separate files.

2. Open the video file (.m1v) with Sparkle.

3a. File>Save As... to export the video to Quicktime

3b. Set the frame rate to 10 or 15.

3c. Set the codec to None, Component, or PhotoJPEG

4. Use MPEG Audio Coder to decode the audio file (.m1a) to AIFF.

5. Open your QT video file with MoviePlayer.

6. Select all the video then Copy.

7. Open your AIFF file with MoviePlayer.

8. Hold Option, and choose Edit>Add

9. File>Save As... a reference movie.

10. Export to a new movie with your favorite settings.

At that last step, be sure to resize your movie to the correct aspect ratio. Some MPEG files don't have square pixels, so they'll be too wide (352x240 instead of 320x240).

You might also want to try MPEGdec 3.1.1 to decode the audio to AIFF. It did not work well for me just now, but it might work for you.

> http://www.jwgdesign.com/mpegdec

If you've got a faster Mac, use that instead. No sense in wasting a ton of time for conversion. Just waste a little.

 

[tomlee59]

MpegDec has a minor MP2 playback bug; my guess is that the conversion into AIFF is therefore affected by it as well, which may explain why JWG Design (is that you, Mark?) didn't enjoy success with the conversion.

Until Mark White finds a little free time to debug his wonderful MpegDec, one essential tool for converting among audio formats is SoundApp. It will convert just about anything (including MP2 audio) into AIFF (and a great many other formats) just fine. SoundApp + MoviePlayer 2.5.1 = oodles of low end multimedia goodness. Sparkle is also wonderful because it is the only such tool that will run on machines as old as an '020.

I thank the OP and the other posters for this thread; it got me to go back in time and play around a bit with Cinepak and MJPEG, things I have not done in ages. It's a lot more fun these days, because faster Macs shorten the wait (I remember clicking "Export" and waiting, and waiting, and waiting...). In the quick experiments I ran, MJPEG seemed to produce better-looking output than Cinepak for a given data rate, but YMMV. Certainly if you ever want to edit the output, MJPEG wins (each frame -- field, actually -- is an independent JPEG image, basically). I don't have any experience with PhotoJPEG, but I'm assuming it's similar (time for me to fire off a Google search to get some education).

 

[JWG Design]

To clear things up and avoid confusion... I am not Mark White. I did help Mark with the MpegDec project, but only in small ways -- beta testing, icon design, and web design/hosting.

It's too bad MpegDec has that MP2 bug. (There were screeches and other noises in the AIFF, when I tested it yesterday on my G4 in Classic.) MpegDec seems to be much faster at conversion than MPEG Audio Coder. I had forgotten that SoundApp will do the conversion on 68k Macs -- and quickly, IIRC. Thanks, Norman Franke.

The big trick to Cinepak is keyframes. With MJPEG, every frame is a keyframe and is encoded independently of other frames. With Cinepak, Video, Sorenson, and MPEG codecs, there are keyframes and intraframes. Intraframes only contain data for changes in the frame instead of the whole frame. So... if you set keyframes to "every 15 frames", then it can utilize infraframe compression to more efficiently use the desired data rate. If you encode Cinepak without setting keyframes, it will make every frame a keyframe, then the benefits of intraframe compression get lost -- which is probably why MJPEG looks comparable or better than Cinepak at the same bit rate.

 

[tomlee59]

Well, in my quick test, I used the default setting of a keyframe interval numerically equal to the frame rate (to produce 1 keyframe/sec), in this case, 12. The result was markedly inferior to the MJPEG result at nearly the same bitrate (identical source material). So, my tentative conclusion is that the result has more to do with the particular way in which Cinepak performs its vector quantization (and motion estimation). Since Cinepak was designed for easy decode on CPU-challenged machines, the algorithmic tradeoffs must have been fairly dramatic.

Perhaps by fooling around with the quality slider and target bitrates, etc., (or by using a better Cinepak encoder than the one bundled with MoviePlayer 2.5), I could achieve a very different result.

 

[JWG Design]

Cinepak's motion estimation was best at camera panning, or linear motion. Things like camera zooming do not fair well with Cinepak at low data rates.

Tomlee, you have gotten me curious about this strange phenomenon. I don't understand why Cinepak is performing poorly compared to Motion JPEG (MJPEG). Cinepak is ideally suited for 320x240 at 15fps and roughly 100-300 KB/sec. (video only), although it performs fairly well with some slight variations. For instance, I like to use 320x180, 10fps, 80 KB/sec for my 16x9 web videos.

MPEG-1 is well suited for 352x240 at 30fps, and will produce a better picture than Cinepak, but it is much more processor intensive.

Does your Cinepak test have keyframe strobing, where the keyframes look good, but the frames inbetween look bad? Are your Spatial Quality and Temporal Quality sliders all the way at "Best"? I'm stumped. I'd love to see some samples posted.

 

[JWG Design]

Perhaps by fooling around with the quality slider and target bitrates, etc., (or by using a better Cinepak encoder than the one bundled with MoviePlayer 2.5), I could achieve a very different result.

I don't think the Cinepak codec has changed at all since Quicktime 2.5. MoviePlayer is just the front-end. If you use MoviePak or Cleaner, it still uses Quicktime's Cinepak encoder, but gives you some additional options for changing the video before sending it to the encoder. Some options are variable frame rate (dropping duplicate frames) and adaptive noise reduction. From my experience, using QuickTime Player with QuickTime 7 Pro produces identical results as using MoviePlayer with Quicktime 2.5.

The biggest differences come with changing the data rate. Also, the consensus from long ago was that the Spatial and Temporal Quality should both be set to Best when encoding with Cinepak at a specified data rate. (Hold the Option key down to change the slider to Temporal.)

 

[bestobothworlds]

Instead of converting the MPEG I intended to convert, I decided to convert a video of Bubsy 3D (That one on Youtube with that guy achieving an amazing 24 second record for level 1) to MPEG, take it over to the LC and then convert it to Cinepak. Unfortunately, I couldn't extract the sound using the audio/video splitter. But I did get the video! I'm converting to Cinepak now! But the conversion is taking a LOT longer than I planned. I started converting an hour ago and it's still not finished! I even have my '030 accelerator card turned on! Those people writing the Macworld SECRETS book in 1994 were making a gimungus understatement when they said Cinepak conversion was slow on a 68k. >

 

[bestobothworlds]

Perhaps by fooling around with the quality slider and target bitrates, etc., (or by using a better Cinepak encoder than the one bundled with MoviePlayer 2.5), I could achieve a very different result.

I don't think the Cinepak codec has changed at all since Quicktime 2.5. MoviePlayer is just the front-end. If you use MoviePak or Cleaner, it still uses Quicktime's Cinepak encoder, but gives you some additional options for changing the video before sending it to the encoder. Some options are variable frame rate (dropping duplicate frames) and adaptive noise reduction. From my experience, using QuickTime Player with QuickTime 7 Pro produces identical results as using MoviePlayer with Quicktime 2.5.

The biggest differences come with changing the data rate. Also, the consensus from long ago was that the Spatial and Temporal Quality should both be set to Best when encoding with Cinepak at a specified data rate. (Hold the Option key down to change the slider to Temporal.)

Cinepak never changed at all?

 

[tomlee59]

Yes, it is *very* slow! And if you don't have a lot of ram (and the LC certainly does not), then you've got to use VM, which just makes the suffering that much more intense. But the wondrous thing is that the LC can do this at all.

And I'm sure that I'm not getting the best out of Cinepak that it has to offer -- I'm a definite neophyte wrt Cinepak. I have the quality slider in the middle, for example. I also noticed that the target bitrate has only the loosest correlation with the actual bitrate achieved in the final result, so I'm sure I could do better. Thanks very much for letting me know about the temporal slider. I'll try activating it and playing around some later.

Just fyi, the source file is an excerpt of an XVCD version of Galaxy Quest. Plenty of CGI, fast motion, explosions, zooming and all that, so perhaps it's not surprising that MJPEG does well. I am encouraged to hear that Cinepak can do better than I've been able to get from it, so any additional tips you can offer on how to squeeze the most out of it would be welcome. Its light decode requirements are very attractive to us low-enders!

 

[JWG Design]

Cinepak never changed at all?

I'm fairly certain that the version Apple includes in Quicktime has not changed. Apple licensed the technology from Supermac, the makers of VideoSpigot capture cards. I guess Supermac was aquired by Radius, which subsequently went out of business. At some point CTI must have purchased the rights to Cinepak, either from Supermac or Radius. About seven years ago, I tested the CinepakPro Toolkit (the only way to use the CinepakPro codec), but I wasn't too impressed. I thought that MovieCleaner (now Cleaner) had better features.

Furthermore, the sample videos are not even appropriate for Cinepak. Cinepak, like JPEG, works best for photographic content.

 

[tomlee59]

Well, I spent whatever free moments I had today to launch a series of transcoding experiments. And even at max quality, Cinepak loses to MJPEG at equivalent bitrates. In all cases, the source clips were NTSC VCD (352x240), 24fps. The output clips were 10fps, 12fps and 15fps, all at the same resolution as the source. Keyframes were kept at a constant one per second. The target output bitrate was 700kb/s (chosen so that one might fit a ~2hour movie on a single CD).

One source clip was from Galaxy Quest, as mentioned previously. Another was a comedy bit from Brian Regan. In both cases, Cinepak produced output that was markedly inferior to MJPEG, in the not expert opinion of every single one of my coworkers.

Aside from very noticeable motion artifacts, Cinepak also seems to truncate the color space so much that human faces can have a comic-book appearance at times, depending on what else is going on in the scene. From reading what others have found in the course of more detailed experimentation than I've run so far, this is a very typical result.

So, in the absence of additional guidance on what, if anything, I'm doing wrong, I conclude more firmly than before that Cinepak simply produces output inferior to MJPEG, at least for these framerates/bitrates. That's not the same as declaring it useless, however. As mentioned already, the light decode requirement makes Cinepak very attractive for video on machines that otherwise can barely handle browsing, for instance.

Btw, the encode speed for Cinepak was 2x slower than for the MJPEG cases, so Cinepak appears to be very asymmetrical in its encode-decode requirements. On a 300MHz G3, a 4.3 minute Cinepak clip took over 2 hours to encode! I shudder to imagine how long it will take that LC to finish its job. Wow! It might take a day or more!

 

[bestobothworlds]

Well, I spent whatever free moments I had today to launch a series of transcoding experiments. And even at max quality, Cinepak loses to MJPEG at equivalent bitrates. In all cases, the source clips were NTSC VCD (352x240), 24fps. The output clips were 10fps, 12fps and 15fps, all at the same resolution as the source. Keyframes were kept at a constant one per second. The target output bitrate was 700kb/s (chosen so that one might fit a ~2hour movie on a single CD).
One source clip was from Galaxy Quest, as mentioned previously. Another was a comedy bit from Brian Regan. In both cases, Cinepak produced output that was markedly inferior to MJPEG, in the not expert opinion of every single one of my coworkers.

Aside from very noticeable motion artifacts, Cinepak also seems to truncate the color space so much that human faces can have a comic-book appearance at times, depending on what else is going on in the scene. From reading what others have found in the course of more detailed experimentation than I've run so far, this is a very typical result.

So, in the absence of additional guidance on what, if anything, I'm doing wrong, I conclude more firmly than before that Cinepak simply produces output inferior to MJPEG, at least for these framerates/bitrates. That's not the same as declaring it useless, however. As mentioned already, the light decode requirement makes Cinepak very attractive for video on machines that otherwise can barely handle browsing, for instance.

Btw, the encode speed for Cinepak was 2x slower than for the MJPEG cases, so Cinepak appears to be very asymmetrical in its encode-decode requirements. On a 300MHz G3, a 4.3 minute Cinepak clip took over 2 hours to encode! I shudder to imagine how long it will take that LC to finish its job. Wow! It might take a day or more!

So let me get this straight. You're saying Motion jpeg is as small if not smaller than Cinepak, compresses twice as fast and still has better quality video? Dang, why didn't people choose this over Cinepak?
Well, maybe It's because of the decode requirements. Did you say they were higher than Cinepak?

 

[JWG Design]

I just created a new thread for the Cinepak vs. Motion-JPEG discussion, since it seems better categorized as a Software topic.

> http://68kmla.org/forums/viewtopic.php?p=11816

John