Video encoding for playback on 68k macs

corgski

Well-known member
a.k.a. cursing ffmpeg and deciphering ICCVID.DLL while dreaming of building a youtube proxy

Here's what I have so far, using a 15 second test clip and cinepak compression

ffmpeg's implementation of cinepak is far too slow to be usable for on the fly conversion, running at approximately 0,2x realtime. That said, I documented my working configuration here: https://welcometomacintosh.neocities.org/notes.html

Mencoder's VfW wrapper doesn't implement core features of the VfW API which results in the Radius Cinepak codec shipped with windows creating unreasonably large files. I submitted a bug report about the lack of quality selection, but will need to submit another about the inability to specify a target bitrate and forced keyframes, as what I've discovered depends on all of those features.

So, using virtualdub on windows 10 I got to work fuzzing out the radius cinepak codec.

All the files I've created are named in the following manner q(n)k(n)b(n).avi where q(n) is a quality from 0-100, k(n) is keyframe every (n) frames, and b(n) is target bitrate in kbps. Interestingly, none of these numbers are actually correlated to what they supposedly stand for.

First off, if k is 100 or less, q has no effect whatsoever on the video and a lower b paradoxically raises the filesize by a few kB. A lower k value will also increase filesize by a few kB unless it's k=0 at which point it produces a massive file.

However, at k=101, q starts to mean something. q=0 produces a file that is an order of magnitude smaller than q=100. Values between 0 and 100 then scale the filesize and resulting video quality like you'd expect. b meanwhile no longer affects the file size or video quality whatsoever.

Why it doesn't use the requested quality value unless keyframes are spaced 101 or more frames apart is a mystery to me.

Here's a link to all the videos for comparison.

https://drive.google.com/drive/folders/1XYrTXgbMETGJ4fx2CBvUGFiSxmOSB0-Z?usp=sharing


 

 
Last edited by a moderator:

superpete

Well-known member
Hi there

I've done a bit of work on a transcoding youtube proxy - https://github.com/pgodwin/68kTube/

There's a tool in there for calling Quicktime under Windows to handle Cinepak and Sorrenson encoding. 

I've mostly been focused on getting things working as best as possible with FFMPEG as I'd love to run everything under Linux. 

One thing i've noted is that Quicktime under 68K is a fickle beast. Some things (like OpenMovieFromUrl API calls) just don't seem to exist. Which is why I've pivoted to just something that'll work under Netscape 2 with the Quicktime plugins. 

Let me know if you have any questions!

Edit - some learnings:

 - adpcm_ima_qt seems to crash on 68K

 - ffmpegs +faststart option doesn't work properly on older versions of Quicktime (ie v3 or v4 under netscape). The proxy I have ends up patching it up after ffmpeg is finished. 

 - sorrenson is another options. ffmpeg has support but it is slow! the quicktime encoder is faster.

 - I *think* 68K Quicktime has h261 and possibly h263 codec support which might be useful at low-end resolutions. I need to retest this - it may only be available as part of the video conferencing tools. Encoding speed for these codecs is excellent!

mencoder seems to have at least partial support for quicktime codecs (*.qtx) too. I haven't worked out how to use it yet. Sorrenson, road pizza and other quicktime only codecs might open up that way. 

 
Last edited by a moderator:

superpete

Well-known member
Just checked the source to MPlayer. Looks like only decoding via qtx is implemented :(

Interestingly, I think they batched some of the DLLs so that they no longer have hard coded paths. Which would make a "portable" quicktime a possibility. 

 

pl212

Well-known member
ffmpeg's implementation of cinepak is far too slow to be usable for on the fly conversion, running at approximately 0,2x realtime
Checking back in on this thread in 2024 -- it's interesting that whatever ffmpeg is trying to do with cinepak runs about 10x slower on a M1 Max than a 2013 iMac Pro (12-core Xeon, which has pretty impressively crummy single-core performance.)

Appreciate the details folks have discovered and shared about the issues here, including ffmpeg's ima4 audio codec incompatibility.
 

LaPorta

Well-known member
Now I may be totally out of line here, but for this sort of thing…why not just get a newer Mac?
 

superpete

Well-known member
Checking back in on this thread in 2024 -- it's interesting that whatever ffmpeg is trying to do with cinepak runs about 10x slower on a M1 Max than a 2013 iMac Pro (12-core Xeon, which has pretty impressively crummy single-core performance.)

Appreciate the details folks have discovered and shared about the issues here, including ffmpeg's ima4 audio codec incompatibility.
Since the last discussion, ffmpeg added a road pizza encoder.
 
Top