(I may have gotten a new computer. I may be installing PC/GEOS\\Breadbox Ensemble on my little unisys box right now.)

And it plays podcasts. Or at least it plays this specific

More pictures to come.

It has an Ethernet card in it. And I think I can get drivers working for that.

So now the plan is to get networking working, and then get it connected to my raspberry pi comms box.

I'll drop a few dozen game folders on the comms box and ftp or wget them on to the Unisys.

Once I've got all that done, I'll do a breakdown/walk through video. I might add some overlays and effects from my Amiga, I might not.

Once I have the video finished, I'm going to look in to the video equivalent of a (which, in this case, might be an svcd? Or maybe just an xvid file.)

I wonder if I could get it to do video playback...

Goddamn it. Now I gotta find out what is the highest bitrate video that a pentium will play. (that sentence is wrong, but I'm too far past that thought in my head to figure out how to fix it.)

Looks like my most likely options for video playback on a 486 or early pentium are smacker, cinepack, and mpeg-1.

There are some other less promising formats, too. Mv-1 and ideo being the only others I can remember.

I'm really curious about smacker and cinepack compression vs fidelity vs playback speed.

I know what mpeg-1/vcds look like (in terms of quality, playback requirements, and file size) but not the others.

I guess I will also need to look at vorple or whatever the new non-patent encumbered hvec competitor is called, for use on modern PCs.

(Because I'm going to end up self hosting, so you're going to deal with tiny video files.)

So AV1 looks like the solution for video on modern machines.

Smacker or cinepack seem the most likely for older machines.

Do any of you have any experience with smacker encoding?

I'm encoding a film with Smacker now and the first thing I'm noticing is that it is SLOW. I'm 23 minutes in, and so far it is still analyzing the video, and has not started the conversion yet.

It also appears to be missing some features that I would expect it to have (specifying color depth, for example, or output resolution.)

Also, my new projector arrived and is wonderfully sharp and vibrant and I can't wait to try it with full sunshine so I can see if it solves my problem.

It just gave me an estimate! It popped up and said that it'll take more than 8 hours to finish this encoding.

On my i7.

So... I guess this is what you would call asymmetric compression, in that it takes a ton of time and effort to encode in order to take very little time and effort to decode.

Estimate keeps climbing. More than 10 hours now.

If this produces watchable video, I guess that's fine? This is just a ridiculous vanity project, so it doesn't really need to be sustainable.

Nice! If those estimates are accurate, this is a big improvement over even hvec.

I bet encoding times are super long, but I'll find out for sure next week.

@ajroach42 Yes. :p Encoding times last I tried were absolutely horrid (like, ~5fps for 1080p24 on a 16-core Opteron and not much different on a more modern quad-core i7).

That was ffmpeg + libaom, though - apparently rav1e is the fast-but-not-yet-fully-efficient one.

@ajroach42 What are you using to encode? With ffmpeg, all you have to do is add '-threads 0' and it'll use all the cores. Or just use the number of cores you want to in the place of '0'. I'm pretty sure ffmpeg will decide SMK, but I'm not sure about encoding. Meaning, since a lot of modern players use ffmpeg (ffplay), you may not need multiple formats.


1) ffmpeg doesn't encode SMK.

2) "since a lot of modern players use ffmpeg, you may not need multiple formats" ?

@TheOuterLinux Oh, I missed a thing.

I'm using rad tools smack it btuton. That's the official smacker encoder.

@ajroach42 You should be able to play SMK files with mplayer and therefore MPV, VLC, ffplay, and most other players out there. If that's the case, why export to multiple formats? And maybe not encode, but ffmpeg should be able to decode. However, colors can be off on older formats. I tried converting an FLI animation I made with AnimatorAKA and it gets the colors wrong, even with -vf format=pal8.

@TheOuterLinux Ah, thanks for the clarification.

The reason I'd export to a format other than smacker is because smacker videos are massive and ugly compared to a modern format.

Give me a second, I'll show you what I mean.

@TheOuterLinux This is a rip of Broadcast news I did from DVD. Ripped to MPEG-2 and then converted to Divx and Smacker.

One image is from a 700 MB divx AVI, the other from an 800 MB Smacker file. The smaller divx file looks and sounds better.

Divx is not as good as modern codecs like h265 or av1. I should be able to get the same quality at half the file size or less with a newer codec.

@ajroach42 Oh ok. Did you ever see the post I made about fitting a 20 minute video onto a floppy? Uses vp9 and opus though... ... and looks horrible and sounds like Cylons, but I did it. I also have a write up on my site about doing it to a 46 minute video in the Muse section.

@TheOuterLinux Checking it out now, that's super neat.

What I want to accomplish here is to set a baseline for "acceptable" video, and then find the lowest powered machine that can play that back.

Baseline quality is hard to quantify, but you know it when you see/hear it. Baseline bitrate would be about 120KBps max.

The combination of "has to look okay" with "no more than 120KBps" and "should play back on a pentium" is looking like a Pick Two kind of scenario.


I suspect part of what you're seeing is also the impact of _not_ using hardware features that cater specifically to the newer codecs.

Video chatting is a core use-case for so many people. There's going to be hardware features somewhere to facilitate the process, and -- regardless of the OS -- there will be drivers that know exactly how to use them.


The fact that this is all happening in software is 100% part of the speed problem, but I have other non-HW accelerated encoders that are much faster.

This appears to just be slow, and probably the actual bottleneck is that the file it's analyzing is on a USB drive. I'll try it again from the internal SSD later.

RAM use is flat, and the processor hasn't spiked over 15% load, so it's clearly not optimized for multiple cores, either.

Sign in to participate in the conversation
R E T R O  S O C I A L

A social network for the 19A0s.