• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

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. 

 
Top