Monthly Archives: August 2010

Museum of Multimedia Software, Part 2

This installment includes a bunch of old, discontinued Adobe software as well as some Flash-related mutlimedia software.

Screen Time for Flash Screen Saver Factory
“Create High Impact Screen Savers Using Macromedia Flash.”



Requirements include Windows 3.1, 95 or NT 3.5.1. A 486 computer is required to play the resulting screensavers which are Flash projectors using Macromedia Flash 3.0.

Monster Interactive Instant GUI 2 Continue reading

Museum of Multimedia Software, Part 1

Many years ago, I found a boneyard of old software, much of it related to the creation and processing of multimedia. I was permitted to liberate anything of my choosing from this cache. This is the same pile where I found this Apple QuickTime format spec as well as this perfect form factor floppy disc box. So I have been sitting on the stuff for awhile.

I thought I might get the chance to study it a bit more closely one day. But now I’m interested in getting rid of it. Before I do, it’s more or less traditional for me to photograph it and post it on one blog or another. Also, if you know of any software collection groups who would be interested in taking this stuff off my hands, do let me know.

As usual, click a picture for a much larger image.

Paracomp FilmMaker
This is easily the most distinctive piece in this collection and it’s easy to see why– the software is packaged in a film cannister. Still sealed, and I don’t have a good reason to open it now.



“The Professional Animation/Presentation Program for the Macintosh.” No copyright date on the packaging, though the front does mention a 1990 award. System requirements: Mac OS 6.0.5, 5 MB RAM, 32-bit QuickDraw, math coprocessor.

Strata VideoShop Continue reading

Sorenson Video 3 For Posterity

On a recent dumpster dive, I procured a complete, never-been-opened copy of Sorenson Video 3 Professional Edition Compressor for Windows. And because I’m me, I thought it would be interesting to document it here:



Not opened until now, anyway:



I chuckled at the thought that I might open the user manual and find the complete data stream format listed therein. As expected, the guide offers a broad overview of video compression concepts (lossy vs. lossless, inter/intraframes, that kind of thing) and goes on to describe general guidelines for compressing different types of data. Then there is the feature reference. There are standard features and professional features (the latter includes things like bidirectional prediction, masking, and watermarking).

I was hoping to figure out how to encode some video with this software. But I think I need full Quicktime Pro in order to do that. If you’re interested, here’s the user manual in PDF format: Sorenson Video 3 User Guide (626 Kbytes). Here’s an interesting claim from the chapter on audio compression:

Most movies are made up of two parts, video and audio. Historically, the video portion of a digital movie was so large that the audio was only a minor piece of the puzzle. However, with Sorenson Video’s excellent compression capabilities it is possible to create a file where audio is the largest portion.

I know it’s possible to do that, but is it really recommended? I’m sure I have some samples in my vast repository where this is the case but it still doesn’t strike me as optimal for network delivery.

New FATE Test Coverage System

I’ve been feeling a bit scattered for the last week since I was fired from my volunteer position as the FFmpeg QA manager, wondering if there is anything I should attempt to do with the project. It can’t be denied that the new system is working well. But one area I’ve wondered about is test coverage.

Under my old regime I tracked test coverage as a wiki page which was a highly flawed method– tedious and error-prone. There are those 2 adjectives again– tedious and error-prone; whenever I see those, I search for automation methods. I think that might be more plausible thanks to the new FATE’s tighter integration with the FFmpeg build system.

I don’t think anyone is working on this problem so I wanted to toss out a brainstorm:

  1. First, run ‘ffmpeg -formats’, ‘ffmpeg -codecs’, etc. and parse the output to collect a list of all the features (full list: -formats, -codecs, -bsfs, -protocols, -filters, -pix_fmts). Transform these lists into a standardized list of features, e.g., "DEVSD ffvhuff Huffyuv FFmpeg variant" represents features ‘decode-video-ffvhuff’, ‘encode-video-ffvhuff’, ‘ffvhuff-horizband’, and ‘ffvhuff-dr1’.
  2. Next, tag each individual test spec with the features that it exercises. E.g., test ‘fate-vqa-cc’ exercises features ‘demux-wsvqa’, ‘decode-video-vqavideo’, and ‘decode-audio-adpcm_ima_ws’.
  3. Finally, compare the data from parts 1 and 2. Print a list of all the features that are not exercised in FATE.

I think a lot of this could be implemented at the GNU make level. Then again, I’m no expert on GNU make syntax so I may be overestimating its capabilities. Or there might be simpler ways to automatically track test coverage stats based on the improved testing infrastructure.