Jump to content

Just released: MacFlim, the impracticable Vintage Video player for Compact Macs


Recommended Posts

On 4/1/2021 at 5:56 AM, rplacd said:

I think the usual "I did it" demoscene demo video for full-motion video is Bad Apple – here's Bad Apple on an 8088 clone with a SoundBlaster card, a C64. You could be the first to get one running on a 68k compact Mac!

 

Well, I understand why they would use this, it will compress extremely well and enable all sort of cool encoding hacks. However, MacFlim is about dithering, so that's not the best target. I mean, MacFlim doesn't care about what is display as I don't compress, so this would run no problem.

 

That said, I was looking at some video for a dirty trick that I want to do with another computer, and this seems to be the perfect video!

Link to post
Share on other sites
  • Replies 56
  • Created
  • Last Reply

Top Posters In This Topic

22 hours ago, Crutch said:

It works!  (Option click actually did it for me.)  Brilliant! The Star Wars clip is sensational.  Also the app generally is really well done with the various features, Tips at startup, etc ... so cool.  The dithering is spectacular.  Amazing work!

 

Yep, Option. I coded it, you think I should know :-)

 

I tried to match a classic Mac app feel as much as possible, there are a few bugs left and right, but I'm happy you get that feeling. It still need additional polish and bug fixes.

 

The Star War clips was the first clip I ran, and the one that shows the app the best. It starts slow and unimpressive, and then the planet appears, then the spaceships, etc, etc.

 

First video of first playback on real hardware.

(if you need to ask, the wine was a Chateauneuf du Pape 2016)

 

And the encoding is pretty good: I means, I got flagged by the youtube contentid system for the MacFlim release video due to the Star Wars extract :-)

 

22 hours ago, Crutch said:

(I think the Xceed card bumps up rowBytes to something huge like 1024, even in 1-bit mode, to “make room” in case you later increase the pixel depth ... in 8-bit mode it changes the screen resolution to 512x341 so that old apps that assume 512x342 = black&white won’t deprive us of lovely grayscale.) 

 

I don't know if the 512x341 thing is genius or disguting. Could be both...

 

Link to post
Share on other sites
  • 68kMLA Supporter

I was watching the Death Star clip again and had an idea for a simple enhancement that would add a lot of fun and be easier than sound - subtitles. You could just add relevant strings with timestamps to the Flim file and srcOr the text (user choice of font of course) over the bottom of the frame at the indicated time for a second or two. You’d want to make it flicker free of course, might cost you one fps for the double buffering of just the portion under the text. Or you could simplify and just add a white stripe at the bottom for the subtitles ... but you probably thought of this already :) 
 

My wire loves Chateauneuf du Pape, a fine choice! We visited there once before we were married ... lovely place

Link to post
Share on other sites

I'm looking forward to making some home flims! In the meantime, I'm curious to know what part of the playback takes up the most CPU time --- is it the decoding, the blitting, or something else? Have you got this optimised to the hilt already, or could you squeeze out more performance if you wanted to?

 

"Like a bottle of Châteauneuf-du-Pape / I'm fine like wine when I start to rap"

Link to post
Share on other sites
On 4/1/2021 at 7:05 AM, fstark said:

 

Don't know yet. I'll try over the week-end to see how it runs on a plus with emulated HD20... If it runs acceptably, I will put a directly downloadable image so people can play with it easily.

I put the Buster Keaton sample on my Mac Plus 4MB via FloppyEmu - full screen didn't run fast enough even at lower quality - the first few frames burst out and then probably down to 1fps or lower. At low quality and windowed mode it would burst a bunch of frames no problem, chug a bit and repeat...This is assuming I've got everything set up right - either way, very cool, maybe I need an SD2SCSI now :)

 

https://youtu.be/iUyZ5-cKl-E

Link to post
Share on other sites
20 hours ago, yugen said:

on my Mac Plus 4MB via FloppyEmu

 

If you were trying to play the video files directly off the Floppy Emu then that would be why you got bad performance. I copied the files to my internal SCSI2SD and they worked great. Despite all its great features the Floppy Emu is not capable of very high transfer speeds. 

Link to post
Share on other sites

I can confirm it runs perfectly on a Classic II. Seems to get the same FPS that your SE/30 does. Also tested it on my LC475 and, after setting to B&W it runs great. Super cool project!

 

Can you describe the file format you've developed?

Link to post
Share on other sites
20 hours ago, yugen said:

I put the Buster Keaton sample on my Mac Plus 4MB via FloppyEmu - full screen didn't run fast enough even at lower quality - the first few frames burst out and then probably down to 1fps or lower. At low quality and windowed mode it would burst a bunch of frames no problem, chug a bit and repeat...This is assuming I've got everything set up right - either way, very cool, maybe I need an SD2SCSI now :)

 

https://youtu.be/iUyZ5-cKl-E

Yes, I found the same thing :

 

In your video, you can sometimes see the frame upating. It means it takes more than one VBL to display the image, ie: the CPU has been interrupted by the hardware during the blitting. I don't think there is any hope. 

 

 

Link to post
Share on other sites
Posted (edited)
20 hours ago, Andy said:

Can you describe the file format you've developed?

It is shamefully trivial:

 

    struct
    {
        //    Flim header
        OSType type;    //    'flim'
        char filler1;    //    '\r'
        char filler2;    //    '\n'
        char v0;        //    '0'
        char v1;        //    '1'
        char filler3;    //    '\r'
        char filler4;    //    '\n'
        short stream_count;

        struct
        {
            short type;
            short sub_type;
            short width;
            short height;
            short fps;
            short fps2;
            long frame_count;
            long offset;
            long size;
        }    stream[8];
    }    header;
 

stream_count = number of streams

 

type = 0, for video

subtype = 0, for silent

(width, height) are (512,342) or (256,171)

(fps,fps2) is the target fps, with fps is the int part, fps2 the fract part*65536 (ie: only (24,0) or (12,0) for now). Fractional part is there to support slideshows.

frame_count is the number of frames in the stream. I expect this number to be /2 is the fps is 12 (ie: this is the real number of frames in the file)

offset is the offset to the encoded data.

size is the size of the data aka: (width*height/8*frame_count)

 

The content itself is just the frames one after another, uncompressed.

 

The code more or less expect the streams to be "compatible", ie: to represent the same movie. It is also hardcoded to the specific sizes and framerate to describe the UI (ie: HD == 512x342, etc). Code works better with 4 streams, but I'll fix the defects until it can work on any of the 4 arbitrary subsets. Oh, and the code expects the framecount to be a multiple of 20.

 

Don't start to write tools around the format, I promise I'll try to release the C++ encoder over the week-end. Ok ? :-)

 

Edited by fstark
forgot to say it should be multiple of 20
Link to post
Share on other sites

The original version used compression

21 hours ago, stepleton said:

I'm looking forward to making some home flims! In the meantime, I'm curious to know what part of the playback takes up the most CPU time --- is it the decoding, the blitting, or something else? Have you got this optimised to the hilt already, or could you squeeze out more performance if you wanted to?

 

 

The disk read, because it reads from the hardwars and writes the whole data to memory. The other part just blits the same data, which, by definition, is less work.

 

I had nasty ideas to speed up, like reading directly from the disk into the framebuffer. But it would not work on non 512x342x1bit machines (which works, contrary to what the humorous error message you get says). And PBRead seems to have a fixed overhead too, which is why I read by 20 frames. I also suspect filesystem shenanigans, which I could workaround by directly accessing the disk, which would mean that a full partition would need to be allocated to MacFlim, which would be super user-hostile...

 

A better path is compression, to lower the amount of data to transfert (it would also help when/if I can get my hands on a network card so I could do a streaming version). The first version of the encoder did compress, by xoring successive frames and using packbits on the result (using PackBits as it is a ROM routine, and ROM executes faster on old Macs.). Unfortunately, video doesn't care what your average compression rate is, only what your worst case is, and in or case, the worst case is really bad (because the data has high frequency and error dithering, by definition, have low regularity). A sequence at around 50% gray level with some luminosity change is enough to completely kill the compression and make the flim unsmooth. So, I dropped that code and went to full frame, so I could at least have something to show.

 

What could work but is difficuly (because I used something similar on a still unreleased project) is to tweak the dithering algorithm so it produces images that are less close to the original, but that compress better (ie: creating regularities for the compressor). That would be akin lossy compression, and I am still trying to find how to approach this.

 

An alternative "simpler" version would be drop frames when the compression is bad *in the source data itself*, ie, a high-level version would be giving a budget byte count for say 1sec of video, and having the encoder decrease the local framerate until it fits the budget. This would guarantee that disk reads are quick enough. I find this an interesting twist on the bitrate of modern compressor (diminushing the framerate to meet the bitrate). However, it would also mean I would need to rewrite basically the full application, as it doesn't expect *at all* variations in the framerate.

Link to post
Share on other sites

Many thanks. Awesome work although I cannot get 5.1 surround working on my Mac Plus :-) Just kidding...

 

I am able to get around 10 frames/sec in both sd and hd. I think the bottleneck in my setup is the scsi2sd. Its activity led is constantly on. I have tried with both 6.0.8 and 7.5.5 with same results. Does anyone know if playing with scsi2sd settings can increase read/write performace?

 

Thanks

 

 

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)
On 4/2/2021 at 5:30 AM, fstark said:

which would mean that a full partition would need to be allocated to MacFlim, which would be super user-hostile...

 

short videos being distributed on specially-formatted floppies is incredibly alternate-reality-late-1980s; it's almost a plausible technology

Edited by cheesestraws
Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)
23 hours ago, Andrew said:

I am able to get around 10 frames/sec in both sd and hd. I think the bottleneck in my setup is the scsi2sd. Its activity led is constantly on. I have tried with both 6.0.8 and 7.5.5 with same results. Does anyone know if playing with scsi2sd settings can increase read/write performace?

 

For what it’s worth the SCSI2SD access light is on about 50% of the time (on for about half a second, off for about half a second) even on my SE/30 (albeit at the full frame rate).  I wouldn’t guess any SCSI2SD settings are the issue ... I’d think you are probably running up against the bandwidth of your SCSI bus on a Plus?

Edited by Crutch
Link to post
Share on other sites
23 hours ago, Andrew said:

I am able to get around 10 frames/sec in both sd and hd. I think the bottleneck in my setup is the scsi2sd. Its activity led is constantly on. I have tried with both 6.0.8 and 7.5.5 with same results. Does anyone know if playing with scsi2sd settings can increase read/write performace?

 

 

 

 

If you have a plus, this is all you are going to get currently. I get 21fps on a SE/30, and 10 fps on a plus, with a SCSI2SD 5.2. I guess a SCSI2SD 6 may get a bit more, but on the plus I would be surprised if we can get anything betterwith the current approach.

 

Link to post
Share on other sites

@stepleton Are you me?

 

I mean, first you are awesome!

 

Second, I have a Lisa 2 here, and running MacFlim it on it was one of my goals -- unfortunately, I need the internal floppy drive to boot the Mac environment, and I don't know how to connect both the FloppyEmu in HD20 mode and the floppy. I was looking into it yesterday, but you did beat me to it!

 

That profile hard drive emulator is *exactly* what I need. Who do I need to kill to get my hands on one?

 

Third, rickroll is *the* video I used a lot for debugging (first was Star Wars, then Adrian Digital Basement, then Never Gonna Give You Up, but decided against any such joke until I get the sound working...

 

 

Link to post
Share on other sites
On 4/1/2021 at 5:56 AM, rplacd said:

Hey, well done! That's a beautiful hack :)

I think the usual "I did it" demoscene demo video for full-motion video is Bad Apple – here's Bad Apple on an 8088 clone with a SoundBlaster card, a C64. You could be the first to get one running on a 68k compact Mac!

 

Ok, other people asked for it, so I give up:

 

 

You can get the flim from http://www.macflim.com/#badapple ...

Link to post
Share on other sites

@fstark

Amazing work!

I’ve not tested it yet but am instead reading through your GitHub page. Specifically, the “Can you walk me in the process of creating my own flim?” section is what I am eyeing now. For those creative right-brain folks who eschew the MacOS Terminal, I assume we can skip most of those initial text commands by just using a user-friendly app like FCPX to generate a grayscale MP4 at 512x342 resolution with 24fps?  Then we can start using the dreaded Terminal commands beginning at the “Extract all the grayscale images” section?

 

By the way, on your web page I see you added only 3 of the 4 SCSI to SD products on your web page. You may wish to also add MacSD too. It’s fresh in my mind because I’m in the middle of a video review.

Link to post
Share on other sites
  • 68kMLA Supporter
23 hours ago, fstark said:

 

Ok, other people asked for it, so I give up:

Haha, I'm sorry it came to that! It's beautiful. Hope too many other people didn't bug you...

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...