Paul Hagstrom's Web Presence Home Courses Past Courses Linguistics Etc.

MPEG, VCD, Digital Video, and Mac OS X.

NEWS September 15, 2002: Despite my best intentions, I just haven't had time to update this page or even play with VCD creation at all for about a year. Given that, I am (reluctantly) going to just declare this page officially obsolete. Many new solutions have arrived since summer 2001, and lots of people have been working on and with new GUI front-ends to solve some of the problems that existed back in summer 2001.

Where do I go from here? Here are a couple of places I'd go to see what's going on now.

  • VCDhelp Mac forum. This is the best place to get up-to-date and to get questions answered. If you haven't been here before, go here first.
  • ffmpegX: Major has put together a very nice front end to several encoding utilites to make a very complete-looking and simple to use solution for encoding for VCD. There isn't much in the way of documentation, but check on the VCDhelp Mac forum (which Major moderates) for discussion. His note to me read: "I developed a GUI to mpeg2enc, [...] not just a GUI as it handles Quicktime input & muxing and SVCD authoring, all automatically. So you finally get one button SVCD, including letterboxing etc." It sounds very promising.
  • RNC's (S)VCD creation page: Ross has put together some nice GUI front-ends for the unix tools discussed here which automate much of the process of creating VCDs. Without much firsthand experience with either program, it appears the ffmpegX might be simpler to use, but both allow you to do much of what you need with almost no actual compiling.
  • fink: Fink is a package manager for Mac OS X philosophically similar to Redhat Package Manager, allowing you to benefit in a simple and transparent way from the porting efforts that others have made. It handles version checking, dependencies, downloading, patching, compiling, installing, all basically without having to deal with any of the nitty-gritty details. At the time of this writing, there are issues with fink under Mac OS X 10.2 but the fink team is working hard to repair them.

I have left the rest of the page basically untouched in the interest of the historical archive and in case I ever do get a chance to come back and organize and update it.

Over the summer (that's summer 2001), I spent some time exploring digital video options, in particular the creation of Video CDs and variants (SVCD, XVCD). Being a Mac user is not an advantage in this domain, since most everything out there seems to be either for Windows or for Linux. I'm putting this page together partly just to keep track of my own notes, as they are becoming unwieldy to keep in my head.

A quick note about how to read this page: The onset of the academic year has pretty nearly stopped this project in its tracks as I have many more important things I need to do. Someday I'll organize and update this page. For now, the main part of current relevance is the "A working path to (S)(X)VCD", which at least seems to work. The rest are notes of varying degrees of currency, which if you're as into this project as I was when I wrote them, you might find half-useful. If you have time on your hands and try some of this out and have suggestions about how to improve the compilation process, etc., please send them along to me at

Table of contents:


Some applications that run only under Mac OS 9 or Classic, and notes thereupon. Very incomplete.

  • VCDgear. Basic translation/repair utility. Chris Frank reports that you can use VCDgear's .mpg->.mpg option to create an XVCD with Toast. I haven't tested this really, but Tony Jacobs reports that he's had some success although it seems to depend on how the original MPEG-1 file was encoded somewhat. The procedure is to acquire an MPEG-1 file with your favorite bitrate above 1150 (e.g., encode one), convert it with VCDgear's .mpg->.mpg with the "Toast-ready" and "Force sector read size to 2324" boxes checked, drop it on Toast set to VideoCD, and burn the XVCD.
  • Cleaner 5 (commercial). So far, only a Classic application, but it seems to run ok in the background of Mac OS X. The opinion seems to be pretty much unanimous in the Mac encoding world that Cleaner 5 generates the best-looking encodings, but that it's also pretty slow, even with the MPEG charger add-on. Like all commercial MPEG programs, it's frighteningly expensive. Lots of options are available, can produce Toast-friendly output. Update: Cleaner, formerly of Terran, formerly of Meda 100, is now owned by Discreet. There's an update which claims to be OS X compatible, but is getting some bad reviews on versiontracker, in part because it seems to break OS 9 compatibility. When this seems resolved, I'll move it out of the Classic section.

Carbon applications

Some applications that can run happily under Mac OS X, with actual interfaces, and commentary.

  • BBDemux. Carbon port of the bbdemux component of BBTools. Separates the audio and video streams from an MPEG stream or VOB file.
  • MacMPEG2Decoder. Decodes MPEG-2 video streams into Quicktime movies. Useful if you want to make a VCD from an MPEG-2 steam, which you'll have to re-encode into MPEG-1.
  • MPEG2Converter. Also decodes MPEG-2 video streams into Quitcktime movies.
  • MAC3dec. Decodes AC3 audio files into AIFF files.
  • Movie2MPEG (Carbon). Based on the original non-Carbon program. Encodes Quicktime movies to MPEG-1. Also has an Altivec-enhanced version.
    • My experience with this program hasn't been very positive so far. It's free, but it's a little bit slow and flaky so far, and Toast doesn't seem to like the output it generates, whether or not you check "Toast" in the encoding options. I don't have any quality opinions at the moment.

OS X GUI front ends

Things are finally progressing to the point that some front ends are available for the command-line programs. Soon, hopefully, this whole web page will be obsolete.

  • vcdtoolsX. Front end for vcdimager, vcdXrip, and toastXAimager. See also the SVCD tutorial put together by the author. There's no such thing as too many tutorials.

Mac OS X and the terminal

The idea: Now that we have Mac OS X, we have access to quite a number of command-line programs that have been prepared and tested under various flavors of unix. Because there are so many unices (among other reasons), the standard way to use this software is to download the source code (generally released under the GNU public license) and compile it yourself into "binary executables" that run on your machine. This makes it at least possible to get ahold of programs originally written for Sun workstations and run them flawlessly on the Mac. The trick is that there are variations between unix implementations, and sometimes it requires a little bit of tweaking to get things to compile properly.

What you are reading: This is basically me transcribing my notes on how to get things to compile, based on trial and error and a copious amount of web-diving. Suggestions are welcome, thanks to those who have already sent some, including Chris Frank.

Initial setup: There are some preliminary steps to take when setting yourself up to compile things under Mac OS X. The standard location for user-installed (i.e. non-system) software is in the /usr/local/bin directory, which does not even exist on the base-install of Mac OS X. Another thing is that the C compiler which is distributed with Mac OS X, while it actually is, fundamentally, the GNU C compiler (gcc), it has been non-canonically named cc. To make it as simple as possible to get things going, here are a couple of things to start with:

  • Install the Developers Tools from the Developers Tools CD.
  • Know your root password or be sure you are logged in as a user with Administrator privileges. There are two ways to execute commands that need "root" privileges (which includes everything that attempts to copy things into /usr/local/...). One is to type su (stands for "superuser") from the terminal command line, which will ask for your root password and then grant you full access to do anything at all to your machine (including completely destroying the operating system if you aren't careful). When finished doing the things that require root access, type exit to return to your previous identity. You can tell if you are operating as root by whether the prompt in the terminal window ends in # (you are root) or not (you are you). Another option is to type sudo <command> where <command> is what you want to execute with root privileges. You will be asked for a password; this password is not your root password, but your user password (assumes that you have Administrator privileges). The single command will be executed with root privileges, but your identity will not be changed.
  • You may have to "enable root access" which you can do with the NetInfo application in your Utilities folder.
  • With root access, do the following:
    • mkdir -p /usr/local/bin
    • mkdir -p /usr/local/lib
    • mkdir -p /usr/local/share/aclocal
      (these create directories where user-installed programs often go)
    • ln -s /usr/bin/cc /usr/local/bin/gcc
      (this step fools scripts that want to use a compiler called gcc to use Apple's renamed cc instead)
    • Open this link in a new window, select all and copy.
    • emacs /usr/include/dlfcn.h
      (this will create a new file)
    • Paste
    • Type Ctrl-X, type Ctrl-C, type y.
    • emacs ~/.cshrc
    • Assuming this file does not already contain this, copy setenv PATH /usr/local/bin:${PATH} into this file.
    • Type Ctrl-X, type Ctrl-C, type y.
  • Close your terminal window and open another one.

Notes on paths and locations: I think that because the "standard" /usr/local hierarchy doesn't exist, it isn't automatically searched (which is why I suggested adding it to .cshrc) but I might be wrong; it may already be hiding on a search path. I discovered at one point, reading this page about installing XFree86 that if you look in /usr/share/init/tcsh you will find some system-wide initialization files for the Terminal. These can be overridden by the .cshrc file, I guess, which is why my way worked. If you are interested, you can read what's at the link there. I gather that it is sometimes not considered a good idea to install your stuff into /usr/local. Fink, for example, uses /sw by default. If you opt to install somewhere else, you will want to add this directory to your path by adding it to .cshrc.

Port distributions: There are a couple of systems out there now which can help you get simple access to programs other people have already ported to Mac OS X; in a sense, like this page, but automatic. One which I have used is fink. Fink is a set of utilities to automate the compilation process and to keep up-to-date on what ports have been done or updated. Installation is pretty straightforward (some details are given below a couple of sections down), and after that is done, you can type fink list at the command line to see what packages are available, and you can type fink install <package> to install <package> onto your computer. This will cause the system to download the source, apply any patches necessary to get it to compile, compile it, and install it. By default, fink installs things into directories under /sw. This might require adding directories to your search paths, I'll try to note where I had to make changes that relate to this. Another place to find pre-compiled ports are the GNU Darwin page (under packages, where you can download the precompiled binaries, but generally not the source; I have not experimented with the automated parts of this system), and at the Mac OS X GNU ports page (where things are distributed as Mac OS X install packages installed with the standard installer).

Making: To use these packages, you will generally download a "tarball" (a file with .tar.gz suffix or a .tgz suffix, which is a compressed directory). Stuffit Expander is perfectly capable of unpacking these, and I usually do it this way to avoid accidentally throwing dozens of files in the directory I downloaded it in. Once you've unpacked it into its own folder, you can get set to compile it by opening the terminal and getting yourself into the proper directory (cd changes directories). A lot of packages come with an automated installation process. This generally involves running a program called "configure" which tries to guess the properties of your system and set up the compilation properly. Because Mac OS X is fairly new on the scene, some of the auto-configure scripts don't know what to do. If you see a file called configure in the directory, you might want to start by doing this: cp /usr/share/libtool/config.* . -- don't forget that last period (it means copy into the current directory)! This will update the "system guessing" script to make it Mac OS X-aware. Then, the standard procedure is to type ./configure (that's period-slash-configure) and then make (compiles the program using the script set in the file called Makefile), and make install (which moves the binaries, libraries, documentation into /usr/local generally). If you type make clean, this will often delete all of the intermediate "object" files generated during the compile (saving disk space, since you won't need them anymore after linking). Also, when configure checks your system, it will often log its progress and results; if things don't work, you can often read the config.log file to get the details on where it went wrong. There is also a file called config.cache that configure often uses to cache the results of its tests (making a second run of configure quite a bit faster), but if you have played with the options, you may want to rm config.cache in order to make the next run of configure do everything over. Modern versions of configure allow you to set options; you can try ./configure --help to list configuration options.

Endianness: One of the places where the Mac differs from a lot of other machines out there is that it is "big endian" instead of "little endian", which has to do with the order that the bytes come in (in the machine code) for larger numbers. Many packages are smart enough about this to set this properly themselves, but it is a good place to look if you are having trouble getting a program to work. I have never actually had to change anything so far in this respect, but it's something to keep an eye on.

A working path to (S)(X)VCD

These instructions are in a state of flux right now! I am trying to update the instructions to work with the newer version of mjpegtools which Chris Frank has contributed to fink. However, I am no longer clear on the usage details. I hope to fix them up soon. However, I still have the previous version of this section around, which refers to the older version of mjpegtools and did at least work.

Note: Chris Frank alerted me that mjpegtools is now in (the unstable branch of) the fink packages, which is great news. As I type this, version 1.5 is available and 1.6.0-beta2 is reportedly in the works. Some changes have been made to the library requirements; I've tweaked the instructions here to reflect the new information. Among the changes since I last compiled it are that quicktime4linux is no longer used and libdv is used instead. It seems that libdv needs xfree86, unfortunately, so you could be in for a long install.

These instructions rely heavily on the (wonderfully useful!) fink package distribution system. What fink does is basically download the source code, apply necessary patches, compile, and install the packages, so you will be building everything from scratch (hence it will take time). I have at least run through the steps to compile the apps, but I may have missed a step, so if you try it and have trouble and figure out how to fix it let me know. Please note that I am not actively working on this at the moment, so I will not be very good tech support.

  • Install the Developers Tools for Mac OS X. The Developers Tools come on a CD with Mac OS X, and the most recent versions can be acquired at for ADC members. The type of membership needed to download the update is free I'm pretty sure (I don't remember paying anything), although you need to register.
  • Install fink.
    • Go to the fink download page and download it (I tested this with fink 0.3.2a). There is a binary installer available, which installs using the standard OS X package installer, and this is the simplest method. There are also instructions for how to build and install it yourself from the source code, if you so desire. My own path to fink 0.3.2a involved installing the binary for a previous version with the OS X installer and then updating with the source, but I assume just starting with the binary package installer won't cause any real trouble. Follow any instructions you are given.
  • The packages we need are already available via fink, but we need to reassign two packages to "stable" from "unstable" (at some point in the near future, this will presumably no longer be necessary, as this package will become stable). If you wish to build vcdimager yourself, check Chris Frank's web site for his patch files. Otherwise, we'll install it via fink, since vcdimager is there now.
  • Enter the Terminal.
  • To do this, you will need to to set fink to use CVS updates (at least I had to). So if you have not already done so, type fink selfupdate-cvs and follow the instructions, answering yes to using CVS versions. Then, bring yourself up to date with fink update-all and we can proceed. If you just installed fink, this shouldn't take too long. If you've been using fink before it might take longer, since it will probably cause several recompiles.
  • You may have to gain root privileges (using su, or sudo, see above) to do the next two steps:
  • cp /sw/fink/dists/unstable/main/finkinfo/sound/mjpegtools* /sw/fink/dists/stable/main/finkinfo/sound
  • cp /sw/fink/dists/unstable/main/finkinfo/sound/libdv-* /sw/fink/dists/stable/main/finkinfo/sound
    • This is the currently approved method for installing an unstable package. I have no idea why mjpegtools and libdv are in the sound directory, but there it is.
  • We're now ready to do the big installation of everything we need. You can do each step separately, or you can cram it all onto one line. Note: if you have already used fink to install one of these you can omit it, or not; fink will not re-compile something that you already have the most recent version of (as long as you used fink to install it originally). Do the following:
    • fink install mjpegtools vcdimager
      Once this starts (after you have approved the installation of the supporting packages), you may want to go make yourself several sandwiches or go see a movie or something. If you have not installed xfree86, then you will need to. For this, I picked (when asked which installation of xfee86 to use) xfree86-base. The other options are primarily for use if you installed xfree86 previously. To actually use xfree86, you willl also need to install xfree86-server. You can add that to the command line above or separately do fink install xfree86-server once the mjpegtools compile is done.
    • The mjpegtools package used to come with mkvcd/mksvcd scripts, which require installing bash (see below). From what I hear, they may no longer be in the newer version, so I'm not quite sure anymore how to use mjpegtools. :( This is as far as I am right now. The stuff below refers to a previous version of mjpegtools.
  • One more thing that needs to be installed is bash. This is not as yet available via fink. You can download an installer package from Softrak (go to the website, search for bash, download the disk image, run the installer). It will install into /usr/local/bash, the readme instructs you how to make a link to it. Follow the instructions. We need this to run the scripts from mjpegtools. Addendum: Rik Goyton recently informed me that bash is now available from fink, but even if you install it this way, you still need to make a symbolic link from /bin/bash to the place where bash is actually installed. The following command worked for him (executed after bash is installed, so that the bash scripts can find the interpreter):
    • sudo ln -s /sw/bin/bash /bin/bash
  • Finally, we need to edit the mjpegtools scripts to point to the right place on your hard drive for its components (this is necessary because fink installs things into the /sw directory but many programs look for support programs in /usr/local). This is where we will be editing mkvcd/mksvcd (which may not exist in this newest version; these instructions are left from mjpegtools 1.41).
    • sudo emacs /sw/bin/mksvcd
    • Use arrows to move down to the line which reads
      and change it to
    • Hit Ctrl-X, hit Ctrl-C, hit y.
    • sudo emacs /sw/bin/mkvcd
      (Note: That's different from the previous filename: This is mkvcd, previous was mksvcd.)
    • Use arrows to move down to the line which reads
      and change it to
    • Hit Ctrl-X, hit Ctrl-C, hit y.
  • And you're done! Just to be sure, close your terminal window and open a new one.
  • You should now be able to do this:
    • To make an SVCD:
      • Have a Quicktime movie in this format (re-export it from the Quicktime Player if you need to):
        None, Stereo, 44.1 kHz, 16 bits Motion JPEG A, 720 x 480, Movie FPS: 29.97. Note: For PAL SVCD, use 720 x 576 at 25 fps (thanks to Rik Goyton for pointing this out). Addendum: New requirements (now that we're using libdv) are an AVI file with DV-NTSC video compression and 44.1k/16bit/stereo uncompressed audio.
      • mksvcd -h -S
      • vcdxgen -t svcd -o svcd.xml *.mpg
        (or replace *.mpg with MyGreatMovie.mpg, or whatever)
      • vcdxbuild --cdrdao-file=MyGreatMovie svcd.xml
      • Burn the .img files (skip the *_pause.img files) in Toast using Toast's Multitrack XA mode.
      • Note: I haven't personally tested this yet.
    • To make a VCD:
      • Have a Quicktime movie in this format (re-export it from the Quicktime Player if you need to. I found that I had to re-export a movie I had in 320x240 format, but perhaps we can find a way around that, since probably yuvscale is capable of scaling the movie itself):
        None, Stereo, 44.1 kHz, 16 bits Motion JPEG A, 352 x 240, Movie FPS: 29.97
      • mkvcd -h -V
      • vcdxgen -t vcd2 -o vcd.xml *.mpg
        (or replace *.mpg with MyGreatMovie.mpg, or whatever)
      • vcdxbuild --cdrdao-file=MyGreatMovie vcd.xml
      • Burn the .img files (skip the *_pause.img files) in Toast using Toast's Multitrack XA mode.
      • Note: Chris Frank reported to me that he's had trouble making VCDs this way, indicating that the bit rate doesn't get properly limited. I haven't tested this personally either, but I've seen it work up to the burning stage.
      • FWIW, on my first test, I encoded a 352x240 1:17 movie (2315 frames) this way and it took about an hour (!) to reach the pre-burning stage on my 400Mhz 384MB G3 Graphite iMac DV/SE (while I did other things like edit this file, so it was probably not running at maximum speed). Not great.
      • Incidentally, I hacked together a front-end to the ffmpeg MPEG1 encoder and tried it out on a 10 second movie file and it got about 5:1 speed (took about a minute), which seems much more promising. I don't think the output was as good, but it might be adequate. I'll try to run some real tests on longer clips and compare them on my DVD player. If the ffmpeg hack works, I'll post it as an alternate route, though right now it's really a horrible hack.

Specific compilation notes

Below are links to useful (or useful-looking) programs I've so far found with source that could in principle be compiled. My two video sources record in MJPEG (320x240, from a USB device) and DV (full-size, from a Firewire device), and I'm hoping to find a path all the way to .iso files (MPEG encoding, VCD filesystem creation, iso file creation) through command-line utilities that can run "nicely" in the background while I do my real work. :) Chris Frank sent me a very useful set of notes with suggestions on how to get various of these packages to compile. I have incorporated his suggestions here where I've tested them.


Compiles cleanly

Takes MPEG streams and creates bin/cue files with the correct VCD or SVCD file structures.
  • There is a precompiled Mac OS X binary file available from the FTP site for the "bleeding-edge" as yet unstable version which requires no compilation. I once downloaded it and ran it, but I have not tested it in any thorough way.
  • Version 1.6.2 is the latest stable version, and I was able to compile this without trouble. It has an auto-configurator, so all you need to do is type ./configure, then make, then make install. When I compiled, I got a warning about an integer type in one file, which might spell trouble down the road. Testing on this hasn't been done.
  • Note: The most up-to-date versions of vcdimager appear to be able to output whole tracks that do not need to be run through the binchunking step, but can be just dropped into Toast. There has been some discussion on the vcdhelp forum about it, which has some instructions. These versions have still not been declared "stable", but if it works, it'll be nice not to have to go through the bchunk step, particularly since the bchunk step may not be too reliable (see section on bchunk below).

Provides the ability to use dynamically linked libraries. Used by other packages.

  • Available as an installer package here.
  • Available via fink


available via fink.

Compression library used by other packages. I believe quicktime4linux and/or mjpegtools make use of this.

Probably the easiest way to get this is via fink. fink install zlib.

Should compile with a simple ./configure, make, make install.


available via fink.

Graphics access library for PNG files. I believe quicktime4linux and/or mjpegtools make use of this.

Probably the easiest way to get this is via fink. fink install libpng.

To compile (thanks to Chris Frank):

  • cp scripts/makefile.sunos makefile
  • change the following in makefile:
    • line 9: un-comment ZLIBLIB=/usr/local/lib
    • line 10: un-comment ZLIBINC=/usr/local/include
    • line 11: comment out ZLIBLIB=../zlib
    • line 12 comment out ZLIBINC=../zlib
  • make
  • make install


binaries available for a previous version.

available via fink.

Library required for MJPEGTools. You can get the binaries from GNU-Darwin. That's what I did after I failed to get it to compile, but I've now installed it via fink.which can also help to keep it up to date). fink install glib. Also installs dlcompat.

  • To get it to compile (thanks to Chris Frank):
    • cp /usr/share/libtool/config.* .
    • ./configure --enable-shared=no
    • modify glib.h:
      • line 1307: change
        #elif defined (__GNUC__)
        #elif defined (__GNUC__) && !defined(__APPLE__)
    • make
    • make install

I found another source for this on Softrak, which claims to be ported to Darwin to cleanly compile. Sadly, however, it seems to have vanished. More eventually.


Compiles cleanly

available via fink.

Probably the easiest way to get this is via fink. fink install libjpeg.

This is required for several other things. I had to get it from a mirror. You want the jpegsrc.v6b file.

  • Compiling it is straightforward, but the libraries need to be put in the right place. Become root (su), and mkdir /usr/local/lib and mkdir /usr/local/includes if they don't already exit, then exit. Unpack the tarball, ./configure, make, su, make install, make install-lib, exit. You will also need to update the symbol table, so cd /usr/local/lib, su, ranlib -s jpeglib.a, exit.

Appears to compile with modifications.

Handles files in libmovtar format, used by other packages, including MJPEG tools.

To compile (thanks to Chris Frank, I made a couple of additions). This will not compile the whole package, but it should compile enough for the use of MJPEGtools. It seemed to work for me.

  • Modify movtar.c (line 43) and tar.c (line 19):
  • change
    #include <linux/types.h>
    #if !defined(__APPLE__)
    #include <linux/types.h>
  • ./configure --disable-glibtest
    If you finked everything, ./configure --disable-glibtest --libdir=/sw/lib
  • make -k
  • cp libmovtar.a /usr/local/lib
  • ranlib /usr/local/lib/libmovtar.a
  • cp movtar.h /usr/local/include
  • cp movtar-config /usr/local/bin
  • cp movtar.m4 /usr/local/share
  • chmod 755 /usr/local/bin/movtar-config

version 1.4 is out now, and the instructions are in transition from 1.3 to 1.4. The 1.3 instructions are retained for reference, 1.4 additions/revisions are noted.

Appears to compile with modifications.

An unpromising name, but it sounds like it might be useful in reading .mov files.

To get it to compile (thanks to Chris Frank; I've tried various tweaks and variations on CF's original suggestions. Any parts that don't work or are horrible violations of unix etiquette are no doubt my contributions).

  • edit Makefile:
    • line 121: change ar rcs ... to ar rc ...
    • line 122: comment out the g++ --shared ... line by putting # at the beginning.
    • 1.4: These lines are now 157 and 158. I think the g++ line was already commented out, actually, I should double-check.
    • 1.4: Between 1.3 and 1.4 the option for --no-firewire has been removed from configure. To simulate --no-firewire mode, we need to comment out lines 143 to 147 in Makefile and remove the trailing \ from line 142 (that is, we remove all of the object files in libraw1394).
  • edit configure:
    • line 38: remove -malign-loops=2 -malign-jumps=2 -malign-functions=2 -march=i486
    • line 38: If using fink, you may need to change /usr/local/include to /sw/include
  • edit libdv/parse.c:
    • line 43: change
      #define vlc_trace(format,args...)
      #if defined(__APPLE__)
      static void vlc_trace(const gchar *format,...) {;}
      #define vlc_trace(format,args...)
    • line 343: add
      #if defined(__APPLE__)
      gint b;
    • 1.4: now line 48, 454
  • 1.4: edit libdv/audio.c lines 90 and 180: change
    #ifdef __GNUC__
    #if defined(__GNUC__) && !defined(__APPLE__)
  • 1.4: edit libdv/vlc.c: Change blank line 27 to the following:
    #undef __GNUC__
    Note: This is probably a hideous crime, but there are enough instances of #ifdef __GNUC__ that this just seemed faster than changing each one individually.
  • ./configure --no-firewire --no-mmx
    1.4: Just ./configure --no-mmx.
  • make
  • cp libquicktime.a /usr/local/lib
    1.4: cp Darwin/libquicktime.a /usr/local/lib
  • ranlib /usr/local/lib/libquicktime.a
  • cp codecs.h private.h quicktime.h /usr/local/include
    1.4: cp codecs.h qtprivate.h quicktime.h /usr/local/include
  • 1.4: As of now, it looks like quicktime4linux-1.4 has compiled correctly.
MJPEG tools.

Approaching compilability asymptotically; we're nearly there, but it doesn't yet quite know how to use quicktime.

Requires a bunch of other packages to be installed; compiling this one is basically the goal. It appears that it works.

To compile (contributed by Chris Frank, annotated by me):

  • This will require a patch. Save this file as mjpegtools.diff in the source directory once you've unpacked it. Updated Aug 27, 2001.
  • cp /usr/share/libtool/config.* .
    (note: don't forget the trailing period)
  • ln -s ../quicktime4linux-1.3 quicktime
    (Note 1: this requires that you've got the quicktime4linux source directory in the same directory as your mjpegtools source directory and that you've compiled quicktime4linux first. Note 2: If you compiled quicktime4linux-1.4 instead, obviously you want to change "1.3" to "1.4" in this command).
  • CF's suggestion:
    LIBS="-lz" ./configure --with-quicktime=`pwd`/quicktime --disable-glibtest
    but this didn't work for me; what I think he was going for can be done this way, I think (I also added /sw/lib as a directory to look for libraries):
    setenv LIBS "-lz -L/sw -L/sw/lib"
    ./configure --with-quicktime=`pwd`/quicktime --disable-glibtest

  • Note: Configure reports that quicktime playback/record is not enabled. This is almost certainly a fatal problem. The rest of the stuff below this may be moot, and may also be obsoleted by the new mjpegtools.diff file. Obviously if it appears to already have been done, there's no need to do it again.
  • Add the following to the end of config.h:
    • #if defined(WORDS_BIGENDIAN)
      #define bswap_16(x) \
      ((((x) >> 8) & 0xff) | (((x) & 0xff) << 8))
      #define bswap_32(x) \
      ((((x) & 0xff000000) >> 24) | (((x) & 0x00ff0000) >> 8) | \
      (((x) & 0x0000ff00) << 8) | (((x) & 0x000000ff) << 24))
      #define bswap_16(x) (x)
      #define bswap_32(x) (x)
  • Edit Makefile:
    • Line 97: remove mjpeg from SUBDIRS
  • Edit lavtools/Makefile:
    • Line 109: remove lavplay lavrec lavvideo xlav testrec yuvplay from bin_PROGRAMS
    • I also had to edit line 21 to change prefix to /sw instead of /usr/local in order for it to be able to find my libjpeg because I used fink to get libjpeg. One downside of this is that I suspect this causes some of the binaries to get installed into /sw.
  • patch -p1 < mjpegtools.diff
    With the current version of mjpegtools.diff, this must be run from the parent directory, the directory which contains mjpegtools-1.4.1.
  • make
  • If you want to avoid putting things into /sw instead of /usr/local and if I'm right about my prefix change, you may want to re-edit lavtools/Makefile to change prefix back to /usr/local.
  • make install
  • cp scripts/lav2mpeg /usr/local/bin
    • This last step sets up a script that serves as a front end to the other mpeg-related tools. It is a bash shell script, though, and bash is not automatically included with Mac OS X. You can download an installer package from Softrak, search for bash. Download the disk image, run the installer. It will install into /usr/local/bash, the readme instructs you how to make a link to it.


Compiles cleanly, but only seems to work by fiddling with the cue file.

Binchunker for converting bin/cue files to iso files.
  • This program compiles without much hassle. Download the tarball and extract it. Be sure you've set up the link to gcc. Then, make. I had more luck installing this manually; cp bchunk /usr/local/bin, cp bchunk.1 /usr/local/man/man1, chmod 755 /usr/local/bin/bchunk.
  • To use it, type bchunk -v file.bin file.cue outbase, and it will create .iso files based on the filename outbase up to the number of tracks in the cue file. The -v flag gives you a little bit more info on what it is doing.
  • My first attempt didn't quite work, despite the clean compile. It appeared to be doing this (as if it were supposed to): skipping the first 24 bytes of each block and writing the last 2048, leaving us with an actual block size in the .iso file of 2048, as far as I can see. Comparing the output of bchunk to the output of Fireburner, I found that if you alter the cue file and change "MODE2/2352" to something else, like "MXDE2/2352" and run bchunk, you will wind up with two iso files (actually .ugh files, because it doesn't understand the format) that match the Fireburner .iso files, except that there's an extra 2352 bytes at the end of the first one. If we want to exactly match the Fireburner files, we could cut off the last 2352 bytes off the first file (at least in this particular case).
  • It turns out that you can burn the .ugh files using Toast (as ISO files), and the resulting disc appears to work. I've tested only on one tiny VCD (encoded as MPEG-1, vcdimaged, and bchunked, then Toasted), but that one test worked.


Binary files available.

Mac OS X port available via GNU-Darwin ports page. This contains two programs, vcdmplex and mkvcdfs which (as their names clearly indicate) multiplex a MPEG-1 stream and make a VCD filesystem (I believe mkvcdfs is effectively obsoleted by VCDimager). I haven't been able to locate the source.


Compiles with tweaking.

An MPEG-1/2 encoder which claims to be high-quality. It turns out to need libjpg, so compile or install that first. This, like most of the encoders, seems to take movies where each frame is in its own file (which seems very inconvenient), in either Targa or PPM format. To make it compile:
  • Modify Makefile so that it refers to cc instead of gcc, and eliminate everything presently in the DEFS line and replace with -DDISABLE_V4L (disables Linux-specific support). Also remove the last line of object files (containing input/preproc_v4l.o, input/preproc_v4l_sglstep.o, and input/remote.o). Removed the object files from ARCH_OBJS (since we don't want MMX support) and VIS_LIBS(whatever they were, we don't want them).
  • Be sure the JPEG library is installed.
  • It seems to choke on the status reporting code at the very end of, so comment out lines 980 to 986 (before double usertime; and before delete preproc;, respectively). We have another user interface problem in control/, as it calls nanosleep which we don't seem to have defined. My workaround was to comment out the for loop containing the call to nanosleep and adding the line usleep(100000); //0.1s in its stead. This will probably knock out a) appropriate signal handling, and b) some of the user feedback. Maybe later I can try to get this back in.
  • The end compile is far from warning-free; it's not clear if it's going to work, but it did compile, and ./sampeg yielded the help screen.
The next step before real testing can begin is to find a way to convert movies to frame files in PPM or Targa format, apparently


Almost compiles, with tweaking.

Claims to be fast, but it seems to be highly Linux-ized. Has a streaming and an encoding component, though I only care about the encoding component. Also seems to have a TiVO-like setup for recording video from a digitizer at predetermined times, but I have no idea how portable that will be. Probably not very, since it will need to have access to some kind of video in, and Mac OS X options seem a little underdeveloped in that area. Of primary interest to me are the library files, which contain the encoders and file-management routines; perhaps I can just put my own front-end on based on the apiexample program. Comes with an API example for MPEG encoding, but requires a YUV-style input I believe.
  • I have not succeeded in making it compile, but I believe I have gotten close. I believe I have gotten the libraries to compile, and maybe even the main program, it just won't link properly yet. Note that I have suggested setting up a couple of dummy interfaces with NULL as the address, and this is probably dangerous. Unless the program is smart about checking for this, this could send the program off into hyperspace. I may want to reconsider this before I do any serious testing, either creating dummy procedures (so at least the calls don't go out into hyperspace) or eliminating the dependencies on them. My plan right now is to just make it compile. Below is the procedure I used to get as far as I did, starting with libavcodec, then libav, and then finally the main programs.
  • Edit the libavcodec/Makefile and change gcc to cc. Remove the CONFIG_MMX definition at the top. Change the "rcs" options for ar to "rc" and add the line ranlib -s $@ underneath the ar command (to build the library symbol table).
  • Comment out the call to emms() in line 437 of libavcodec/motion_est.c.
  • In libvcodec/mpeg12.c, there is a debugging macro which takes an indefinite number of parameters and this causes the compiler to choke. My workaround was to edit mpeg12.c and remove all the lines involving dprintf.
  • In libavcodec/mpeg12data.h, it seems that whatever compiler was used to build this originally allowed things which cc does not. Edit mpeg12data.h and go down to about line 290, where table_mb_ptype and table_mb_btype are defined. The problem seems to be that the bitwise OR that the author relied on isn't translated by the compiler, and so it freaks out. The workaround I came up with was just to "unroll" the ORs manually. Hopefully, I didn't make any mistakes. I ended up with this:
    • static const UINT8 table_mb_ptype[32][2] = { {0,0}, {3,5}, {1,2}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0}, {1,3}, {0,0}, {1,1}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0}, {1,6}, {1,5}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0}, {2,5}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0} };
    • static const UINT8 table_mb_btype[32][2] = { {0,0}, {3,5}, {0,0}, {0,0}, {2,3}, {0,0}, {3,3}, {0,0}, {2,4}, {0,0}, {3,4}, {0,0}, {2,2}, {0,0}, {3,2}, {0,0}, {0,0}, {1,6}, {0,0}, {0,0}, {0,0}, {0,0}, {2,6}, {0,0}, {0,0}, {0,0}, {3,6}, {0,0}, {0,0}, {0,0}, {2,5}, {0,0} };
  • You should now be able to make in libavcodec. If you want to see it run a test, type ./apiexample. You could probably stop here if you wanted to just use the codec.
  • Edit the libav/Makefile and change gcc to cc. Change the "rcs" options for ar to "rc" and add the line ranlib -s $@ underneath the ar command (to build the library symbol table).
  • libav/mpeg.c and libav/avio.c make use of an error code that only seems to be defined in Linux. I added #define ENODATA 61 up near the top of each file.
  • libav/aviobuf.c includes getopt.h, which I don't have, but it seemed unnecessary. I commented it out.
  • grab.c and audio.c cause all kinds of trouble; these are interfaces that make use of Linux hardware support, I believe. I opted to just remove this code, but this will cause a linking error later unless you dummy up the interfaces (which might be dangerous, but it gets it to compile). I created two files, fakeaudio.c and fakegrab.c, which have #include <stdlib.h> and #include "avformat.h" and then the codec definitions from the bottom of grab.c and audio.c with the procedure names changed to NULL. I also included the definition of v4l_device from grab.c in fakegrab.c, and the definition of audio_device in fakeaudio.c from audio.c. Then I changed the Makefile to use fakegrab.c and fakeaudio.c instead of grab.c and audio.c. Maybe at some point this can be reintroduced with support for Mac devices?
  • You should now be able to make in libav.
  • ffmpeg.c includes sys/poll.h but for no purpose I can see. I commented it out.
  • The error which has got me stumped is that at this point the linker can't find __mh_execute_header, and I don't know what this means. It's a reserved word documented in the man page for ld. Quite mysterious.

Once you have mjpegtools compiled, you get for free a program (yuvscaler) which can provide the YUV input. I modified apiexample.c to take YUV input from the stdin (instead of just creating a dummy image) and tried running it on a real 10 second movie and it took about a minute to compress the video. This is much faster than the mjpegtools encoder, but there's a big question about whether a) the quality will be acceptable, and b) whether it will properly sync if embedded in the mjpegtools method. Note too that yuvscaler can do a certain amount of noise reduction, which might be helpful. Experimentation is needed.


Library for handling DV format files, used by other things.

So far, I've not gotten it to compile. Here's what I've tried:

  • Because it wants access to some piece of glib or gtk+ and because I finked them, I did setenv PKG_CONFIG_PATH /sw/lib/pkgconfig first.
  • Then ./configure
  • To get this to work I had to download a newer version of pkgconfig. I think.
  • This is where I stopped, after about 5 minutes of work. I have a short attention span and I'm hungry.
MPEG2_Movie. Claims to be fast, no serious attempt to compile it yet. It is from the same people as quicktime4linux but this looks much more linux-reliant. It looks like it would be nice to have running, but it also looks like it will take quite a bit of tweaking.
mpeg2vidcodec_1.2. Kind of the official example MPEG encoder.
  • I believe I've gotten this to compile, but I've forgotten the details. Like most of the encoders out there, it seems to want as input a YUV-style file. It may also not be that fast, but I haven't even gotten to that stage yet.

Video input

  • Eskape MyVideo. I have this USB input device, although in retrospect, I think I would have been better off with MyTV if I were going to stick to USB (as it is, I went for the Firewire solution, Formac Studio, instead). Being USB it can't go too fast, but it can get full-size (340x240) full-speed (30fps) video from a television source. Also has a video-out option that allows mirroring over USB, which would be nice for those of us with iBooks that have no other video-out option -- except that it is very slow and holds up your system. The drivers have been released for Mac OS X, though they are still in alpha testing as I write this.
  • Formac Studio. The Studio is a device that can receive S-video and composite input and provide DV-encoded video over Firewire to the Mac. It's a big step up from the USB devices, which are highly limited by the maximum available bandwidth of USB. It costs a little more than the USB devices, but it is reasonably affordable. The selling point for me was that the Studio also has a built-in TV tuner (as well as an FM tuner, though I doubt I'll ever use it), meaning you can capture video straight off the coaxial cable. The Studio works fine under Mac OS X, and now has TV tuning software as well. I have one, but I am still in the experimentation stage. I found that iMovie under MacOS X can see it fine and captures DV as it should. When I capture under MacOS 9.2.1, I have some interlacing issues that I haven't been able to resolve yet, and the current theory at Formac tech support is that it is a hardware issue. Still hoping.
  • Eskape MyTV. Like MyVideo except without the output option, but with a coaxial input and a built-in tuner, allowing grabbing straight off the cable. Up to 320x240 at 30fps, good enough for VCD.
  • ATI XCLAIM-TV USB edition. This appears to be like MyTV but cheaper. ATI recently announced that it was shipping, but nobody has it, and MacMall told me October 2001 was when they really expect it. MacWarehouse told me they expect it around August 30 2001. Update (Aug 23 2001): ATI now shows it "in stock" in their online store. I wasn't able to find any definitive answer as to how fast it can go. The user manual, which you can download off ATI's site, hints that you can get 320x240 at 30fps, but never makes any outright statements. People seem to be somewhat unhappy with ATI's previous products and customer support too, although perhaps ATI has turned around.
  • Dazzle Hollywood-DV bridge. I was on the fence between this and the Formac Studio, and I ended up getting the Studio. The Hollywood-DV bridge is a Firewire device that converts video signals to DV format (just like the Studio) and is a little bit cheaper than the Studio, but the Studio won for me because it has a TV tuner. Plus, I have gotten the impression that there are a lot of complaints from users about various things, although the professional reviews are generally quite positive.
  • USB Instant DVD from APS looks somewhat promising (and could "moot" this whole page in a way if the quality is good enough and the parameters are tweakable enough); it is a USB hardware MPEG-encoder for under $300 that can reportedly compress MPEG1 or MPEG2 realtime and send the result over the USB wire (which the bandwidth limitation on USB is big enough to handle). It isn't yet announced for the Mac. Write to ADS to support the creation of Mac drivers; we know they make Mac products (like USB Instant Video), so it should be within their capability to make USB Instant DVD cross-platform.
  • USB MPEG2 encoder for the Mac. I have no information about this other than the web site. Costs about 3x more than the USB Instant DVD, though, at last check.

Some paths to (S)(X)VCD

The path in principle...

  • This is what I expect the path will look like (see also "Usage notes" above):
    • Encode the captured .mov file to MPEG(1/2) with whatever utility produces the best quality fast. This might require a pre-step (or two) to convert the .mov file into a format the encoder can read (e.g., .mov to AVI, AVI to YUV).
    • If necessary (probably necessary for S(X)VCD), multiplex the elementary streams into a system stream (TMPGenc under emulation, mplex or vcdmplex for MPEG-1, what for MPEG-2?)
    • Create the (S(X))VCD file system, producing a bin/cue pair (VCDimager).
    • Convert the bin/cue files to iso files (FireBurner under emulation, bchunk?).
    • Burn an XA multitrack CD with Toast using the .iso files from the previous step.

When I've been successful in making an (S)(X)VCD, I've...

  • Dragged the .mov file produced by my capture application straight into Toast, set on VideoCD. This causes the movie to be MPEG-1 encoded in a format Toast likes (saving the MPEG-1 file for later, too), and then you can burn without trouble. Reasonably fast, quite straightforward.
    • The problem is, you can only make standard VCDs this way (you can't pump up the bitrate for better quality on an XVCD, nor can you MPEG-2 encode for an S(X)VCD). I experimented a little bit with hacking the Toast Video CD Support extension, but I didn't get anywhere in the end, although there may be some hope that it's possible.
    • The speed is pretty good compared to other encoders, and you can send Toast to the background to do its business while you are doing other things. The end result doesn't look as good as Cleaner's output, probably in part because (AFAIK) there is no video noise-reduction done in Toast's encoder.
  • Encoded the .mov file to MPEG-1 using Cleaner 5 with the Video CD compatible setting on (set to Toast), then dragged the resulting .mpg file to Toast, set on VideoCD.
    • This was the nicest-looking and slowest-encoding result so far. Still limits you to VCD bitrates (Toast won't accept anything else in VideoCD mode, and Cleaner won't let you change the bitrate if Video CD compatible is checked, except through explotation of a bug described below). Cleaner is nicely un-intrusive, though, so you can proceed to use your computer as usual while the encoding is happening.
  • Encoded the .mov file to MPEG-1 using M.Pack with Toast-ready setting, then dragged the resulting .mpg file to Toast, set on VideoCD.
    • Lightning-fast encoding, but the video quality was terrible. Not really a viable option.
  • Various things involving VirtualPC and TMPEGenc, which look good and seem to me to take an eternity in emulation.

Some things I've tried that didn't work...

  • Encoded the .mov file to MPEG-1 using Movie2MPEG, but then Toast wouldn't take it. Plus, it was slow.
  • Chris Frank reported that he had been able to create an XVCD by simply encoding an MPEG-1 movie (at a bitrate higher than 1150) using your favorite method (which for me would be Cleaner probably) and then running it through VCDGear (.mpg->.mpg) with the Toast-ready setting on, then dropping the resulting movie on Toast set to VideoCD. Apparently, Toast doesn't notice the pumped-up bitrate, and will happily burn your XVCD. I tried this once (I didn't fiddle with it much) and the resulting XVCD didn't play on my Apex 500w, though. Maybe others will have better luck.
  • Attempted to make an SXVCD with a 320x240 image, and my DVD player put it in the upper left corner -- apparently, I need to scale up the 320x240 to 480x480 just to convert it properly, which is sort of saddening.
  • A recent thread on the VCDhelp Mac video forum describes a way you can use a bug in Cleaner to fool Toast into accepting a higher bitrate MPEG file. In the encoding parameters, turn off "VCD compatible", then change the encoding bitrate so that, instead of specifying a number, it limits the resulting file to a set size (say, 600MB), and then go back and re-enable "VCD compatible" (and perhaps also choosing Toast, although Toast Titanium can also take Whitebook format MPEG files -- I have only tried this with the Toast setting). When Cleaner is done, it will have produced an MPEG file with whatever bitrate was appropriate to limit the size of the file to the size you set, but which you can drop on Toast in VideoCD mode and happily burn. I tested this a couple of times, and the first time I set the size too high for my short movie and produced an absurdly high bitrate that my DVD player couldn't handle -- moral: compute the size limit based on the duration of your movie. When I tried it with lower size limits, I found that when I played it on my Apex 500w, the picture would start hesitating right away and lag seriously behind the audio, even when I took it down to about 1600 bits/sec, which is so close to 1150 that it seems no longer worth the trouble. My guess at this point is that this method is never going to work right (at least on my Apex player), and eventually updates of Cleaner will eliminate the crucial bug we'd be relying on anyway. This might work on some players, but the Apex 500w is quite liberal in its ability to play nonstandard formats, so I wouldn't hold out much hope that other players can do it either.

Other good sources of information out there

  • RNC's instructions for (S)VCD creation. A much less cluttered view of how to do this stuff. A great alternative to this page!
  • VCDhelp The definitive VCD-related information site, very active, very good. Just not very Mac-oriented (although there is a Mac forum that is worth reading).
  • Lukifer's DVD Tools This is a good collection of links to various Mac-style video-related tools. Kind of like this page, except that Lukifer has limited himself to things that have and interface and actually work. Plus, it's got a nicer layout.
  • VCD software list. A list kind of like this one, but from a Linux user.
  • An SVCD tutorial for the Mac. Choose SVCD from the top pop-up menu. One guy's path to SVCD, involves Cleaner 5 (or M.Pack), VirtualPC, TMPGenc, VCDimager, FireBurner, and Toast. Hopefully, we can use bchunk instead of FireBurner, and VCDimager's Mac OS X binary instead, although I'm not sure yet where to get a working MPEG-2 multiplexer to replace the TMPGenc step.
  • Another SVCD tutorial put together by the of vcdtoolsX.
  • And another SVCD tutorial. In French. Uses M.Pack, TMPGenc (under emulation), VCDToolsX, Toast.
  • A little SVCD/VCD on Mac mailing list/bbs on Yahoo. So far the membership is a bit small, but it might grow.
  • Linux VCD tools page has some links to various programs.
  • Postforum. A set of Mac-centered fora, generally narrowly focused on specific products and not terribly active, but there is some useful information there.
  • DV format overview. This is a small presentation covering the DV stream format in enough detail to get an idea of what it might take to convert from DV to other formats.

Most recent edit: September 15, 2002 12:51 PM

[Home] [Courses] [Past courses] [Linguistics] [Etc.]