VOGONS


First post, by radiounix

User metadata
Rank Newbie
Rank
Newbie

I've been playing around with early multimedia codecs these last few nights and have gone and mastered a whole bunch of different codecs to different bitrates.

https://drive.google.com/drive/u/0/folders/1Y … cnSBC8cmPTfvDlb

Specifically, I've encoded:
Cinepak
Indeo 3.2
Indeo 4.1
Smacker
Xing Mpeg
TMPGENC Mpeg
Microsoft Video 1 / CRAM

I've targeted both single and double-speed CD-ROM drives, with about 20% padding between the maximum theoretical transfer rate to allow for slow systems and drives. Supposedly, 386s and low-end 486s with no local bus and poorer CD-ROM drives with minimal caching may need as much as a 40% padding. Which would only leave 90 to 100 KB/s of video bandwidth on a single speed drive -- minus another 11KB for 8 bit 11Khz mono sound.

I need to admit, I haven't been able to really test these on vintage hardware properly, as I don't have a CD-ROM or sound card in my retro PC and I have a slow Chips and Tech adapter that's stuck running at an 800x600x256. I'd be interested in knowing if the videos really do stream off a slow CD-ROM. I'd also be interested in hearing your thoughts on these codecs, and on using a 386 to early Pentium PC for video playback in general.

Reply 1 of 6, by radiounix

User metadata
Rank Newbie
Rank
Newbie

Some things I learned doing this:
*Videos were often mastered for 8-bit color, but this is hard to do now. Virtualdub can palletize to 256 colors, but the dither is noisy, unattractive and not anything I've seen in vintage multimedia. There were some tools of the time, such as Debabelizer for Macintosh, that would index the colors in the video, make a custom optimal pallet, and dither the rest. Smacker does do this as it's a 256 color codec. Microsoft's free full version of Video for Windows with vidcap.exe and videdit.exe also can do this, but it's a 16-bit application and throws false lack of memory errors as far back as Windows 98 SE. My understanding is that by 1995 or so many video authors were mastering in high or even true color, and letting computers running at 256 colors dither on the fly.

*These early codecs introduce lots of artifacts even if allowed basically unlimited bandwidth and are very conservative in how much bandwidth they will use if given a high target data rate.

*Cinepak is a good all-around format for video, and was something of a gold standard for CD-ROM delivery targeting later 386s and 486s. It never seemed the best at anything, but it was always acceptable. Rather than tiling, it breaks up into a mosaic when starved. I like how it looks. It's a second generation codec, designed for a faster 386 or a basic 486.

Intel's Indeo was a real surprise. It performs unusually well for a second generation codec. Video was crisp, and it performed better at lower bit-rates than other computationally similar codecs. I think it didn't get used more because it wasn't very portable and PC and Mac encodes weren't cross-compatible. It also needed more processing power to decode, though still within the reach of a 486 or maybe even a fast 386.

Smacker was an unfortunate surprise. Its audio compression introduces terrible noise if set high. It also isn't very bit-efficient and is probably best used on a double-speed or faster drive when trying to play back full motion video. It also will need its own player on an older machine that won't be running -- and that player doesn't offer video scaling. FFMPEG can decode the format on a modern PC, but the codec seems kind of broken and won't always decode.

MPEG wasn't as universally best as I expected. It's a third-generation codec, and is generally much-improved over older codecs, but it has a propensity for heavy quilting which I find objectionable. XINGencoder, which was extremely common back in the day, leaves obvious quilting/mosaic even when given an unreasonably high bitrate. Which honestly, is how I remember MPEG 1 video looking in the 90s -- VHS-like, but with blockiness. TMPGenc exhibits a much better performance, but I can't get XING Player to read TMPGenc's output so I question its compatibility with legacy players. I think Indeo 4.1 performs better than Xing.

Microsoft Video 1 / CRAM is a multimedia potato. It is a first-generation codec, intended originally to deliver 160x120 10 FPS video on a 386sx/16. It needs a very high bit rate to work, and breaks up into a huge quiltwork when it's starved. It might also be useful on a slower 386 with a modern-ish IDE or SCSI CD-ROM drive, especially if you're not trying to do full motion video. I think CRAM was already becoming obsolete as multimedia became huge, by 1994 or so.

And Indeo 2.1 is NOT Indeo 3.2 by another name. It's an older, first-generation codec similar in sophistication to CRAM. I have no means of encoding to it, and Intel themselves never even put out a 32-bit decoder. I have seen amateur footage encoded from VHS, and the resulting videos were appalling.

Reply 3 of 6, by VileR

User metadata
Rank Oldbie
Rank
Oldbie
swaaye wrote on 2020-09-04, 19:33:

Or if FFMPEG could be useful for dithering.

It definitely is - the palettegen and paletteuse filters are pretty much made for exactly that use-case, and they're very tunable.

If you really want to go the extra mile, and need a very particular dithering algorithm which isn't supported by 'paletteuse'... then you could use FFMPEG to break up the video into .png frames, and feed them to something like ImageMagick (which even supports custom ordered-dither patterns, for instance).
A slow and cumbersome process to be sure, but you can't make a very specific omelet without breaking some very specific eggs. 😉

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 4 of 6, by keenmaster486

User metadata
Rank l33t
Rank
l33t

I may be interested in helping with this.

I want to find a codec that works well for streaming or playing videos on ancient web browsers.

I flermmed the plootash just like you asked.

Reply 5 of 6, by Benedikt

User metadata
Rank Member
Rank
Member
VileR wrote on 2020-09-05, 01:36:

If you really want to go the extra mile, and need a very particular dithering algorithm which isn't supported by 'paletteuse'... then you could use FFMPEG to break up the video into .png frames, and feed them to something like ImageMagick (which even supports custom ordered-dither patterns, for instance).
A slow and cumbersome process to be sure, but you can't make a very specific omelet without breaking some very specific eggs. 😉

This looks like a good opportunity to share a couple of links from my bookmarks:

The page Arbitrary-palette positional dithering algorithm introduces a couple of such algorithms and compares them to existing ones, such as the one described in US6606166B1 - Pattern dithering, which is a recently expired Adobe patent on, well, pattern dithering.
The tool scolorq (Spatial Color Quantization) generates better custom palettes for small palette sizes and specific pictures.

Reply 6 of 6, by VileR

User metadata
Rank Oldbie
Rank
Oldbie
Benedikt wrote on 2020-09-05, 09:21:

This looks like a good opportunity to share a couple of links from my bookmarks:

The page Arbitrary-palette positional dithering algorithm introduces a couple of such algorithms and compares them to existing ones, such as the one described in US6606166B1 - Pattern dithering, which is a recently expired Adobe patent on, well, pattern dithering.
The tool scolorq (Spatial Color Quantization) generates better custom palettes for small palette sizes and specific pictures.

As it happens, I had the first one bookmarked myself - bisqwit does some amazing work. 😀 Wasn't aware of scolorq, so thanks for that link. Might come in very handy.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]