Some words about the oldest QuickTime

Since apparently discmaster.textfiles.com ran out of space (because storage is not cheap now thanks to “AI” companies), I have no new formats to be distracted with and have to resort to looking at the old ones.

As we all know, A**le single-handedly invented multimedia and the existence of IFF ANIM (that pre-dates it by a couple of years) should not confuse you. From what I could find, the earliest QuickTime samples can be found on Apple Reference & Presentation Library 8 CD-ROM that was intended for demonstration but not for the consumers. That disc actually contains three flavours of QT MOV: ordinary MOVs that can be decoded without problems, slightly older MOV that looks almost the same but has slightly different format (and features version -1 both in the header and in the metadata strings) and some extremely old files that do not correspond to the usual MOV structure. Those apparently come from the alpha version of QuickTime around year 1990 when it was still known by its code-name after USian artist of Ukrainian origin.

The first glaring difference is that atoms are not strictly nested but may contain some data beforehand. Essentially all atoms that normally have special header atoms have it before the rest. So instead of (pardon my S-expressions)

(moov (mvhd (trak tkhd (mdia mdhd (minf …))))

there is

(moov [moov header data] (trak [trak header data] (mdia [mdia header data] [all codec description data])))

Data structure is flatter too. In release QT version data for the individual tracks is grouped into chunks, so the header describes both the chunks and what tracks use what chunks (and what are frame sizes in the chunk). Here frames are stored as (offset, size) pairs.

From the accompanying decoder I can see it supported raw video, RLE and motion JPEG at the time—fancy vector quantisation codecs came later.

I hope to support it one day but there’s no hurry. Currently I’m more or less done improving NihAV tools and want to add some practical demuxers, muxers (and maybe even impractical encoders like for Indeo 4 or RedHat Ultimotion). And there’s na_eofdec still waiting to collect enough supported formats for its first release (tangential fun fact: recently I’ve added support for Electric Image format there which is mostly a simple RLE but its frames apparently have timestamps in floating-point format like 0.266 or 0.5).

P.S. I’ve also discovered MoviePak QT codec which looks like JPEG variant. Maybe one day when I’ll have nothing better to do I’ll look closer at it, but for now I have no desire to reverse engineer M68k code in unknown format.

2 Responses to “Some words about the oldest QuickTime”

  1. Andrew-R says:

    Well, IFF might be few years earlier, but number of colors you can display on early Amigas was not that great …

    https://eab.abime.net/showthread.php?t=48784
    (discussing video playback on those machines).

    You can do some impressive (considering power available) digitalvideo tricks on later Atari machines, but IMO main point of quicktime was time synchronization (duh), and various editing stuff most players ignore.

    http://gtello.free.fr/mplayere.htm

  2. Kostya says:

    Compared to EGA/VGA with its 6-bit colour depth? At least you could buy three Amigas for a price of one Macintosh II. And they all had M68k inside…

    And here’s what the QuickTime 1.0 document had to say about performance: “On a Macintosh IIcx it will takes approximately 10 seconds to decompress images at 640×480 pixel resolution. The compression speed scales with CPU performance, so on a Macintosh IIfx, the same operation would require approximately 4 seconds.” (for motion JPEG) and “On a Macintosh IIcx it takes half a second to decompress an image at full-screen resolution, and about three seconds to compress the same image. The compression speed scales with CPU performance, so on a Macintosh IIfx compressing a full-screen image requires one second, and decompress time is 1/5 second.” (for RPZA apparently) and only RLE could deliver 30 FPS (on certain content).

    I find it somewhat ironic that while it supported 24-bit content it could not display it in full range anyway. So just call it software version of Video Toaster that lasted for too long. And I agree, MOV has too many features for video mastering/editing that normal players don’t need. No wonder it was adopted by MPEG later.

Leave a Reply