fstark / macflim

MacFlim flim player source code and utilities
MIT License
90 stars 3 forks source link

Flim won’t open #32

Closed aaronk6 closed 1 year ago

aaronk6 commented 2 years ago

I’ve created a flim with the flimmaker utility from this repository, but it won’t open on my Macintosh SE 1/20.

It will just sit like this and do nothing:

Screen 2

However, the Star Wars Intro from www.macflim.com will play just fine:

Screen 3

I’m on System 6.0.8:

Screen 4

Output from the encoding process on Ubuntu 22.04:

$ ./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --profile se --flim never_gonna_give_you_up.flim --mp4 never_gonna_give_you_up.mp4
[youtube] dQw4w9WgXcQ: Downloading webpage
[youtube] dQw4w9WgXcQ: Downloading android player API JSON
[info] dQw4w9WgXcQ: Downloading 1 format(s): 22
[download] Destination: /tmp/filedeTrZ4
[download] 100% of 64.68MiB in 00:02
[youtube] dQw4w9WgXcQ: Downloading webpage
[download] /tmp/filedeTrZ4 has already been downloaded
[download] 100% of 64.68MiB
Encoding arguments :
--byterate 2500 --fps-ratio 2 --group false --bars true --dither error --error-stability 0.5 --error-algorithm floyd --error-bidi 1 --error-bleed 0.98 --filters g1.6bsc --codec null --codec z32 --codec lines --codec invert --silent false
Read 5301 frames
POSTER INDEX: 1250
**** fps               : 25/2=12.5
**** # of input images : 2651
**** # of movie ticks  : 12725
Encoded 12725 output frames
98.7% of frames are within 1% of the target pixels
98.9% of frames are within 2% of the target pixels
99.1% of frames are within 5% of the target pixels
PROFILE BYTERATE 2500
[libx264 @ 0x55f3f4195b40] non-strictly-monotonic PTS
[mp4 @ 0x55f3f4197a40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1500 >= 1500
Wrote 12725 frames
Removing '/tmp/filedeTrZ4'
[aac @ 0x55f3c1b47880] 2 frames left in the queue on closing

What can I do to make my video play?

Thanks for your amazing work!

fstark commented 1 year ago

Hi, very sorry for the looong time to answer. I should be checking the github more.

You screenshot of MacFlim is Macflim 1.0.

The encoder here is for the new version of macflim (2.0), that you can find in the releases tab (https://github.com/fstark/macflim/releases), or on the http://www.macflim.com/macflim2 website. It supports flim with sound and creates way smaller files than Macflim 1.0

I need to properly release it, and make sure people are not confused.

Can you check and confirm me that your flim works with the latest macflim?

aaronk6 commented 1 year ago

Oh, I totally missed that there is version 2! Definitely going to check that out and report back. I’m sure it will work great :-)

fstark commented 1 year ago

I’m sure it will work great

If it doesn't, report back and we'll make it work. It should supports all 68k macs, from XL to latest Mac IIs. Downside is that there is no window playback anymore, but there is a flim library.

Let me know of any issue you have, no matter how minor. I really want to nail this.

aaronk6 commented 1 year ago

So here’s my update, now that I’ve tried with version 2.0.8 🙂

The demo flim SweetDreams-se.flim is working perfectly.

However, the one that I created myself is having dropouts. Recording below.

https://user-images.githubusercontent.com/446063/184541173-c240c316-8f8e-4feb-a1a1-bd1f26b322ee.MP4

Also, it can’t be stopped since it’s not reacting to mouse clicks anymore.

I created the video with --profile se. Full command:

./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --profile se --flim never_gonna_give_you_up.flim --mp4 never_gonna_give_you_up.mp4

I appreciate your dedication for this project! Great stuff.

Thanks!

fstark commented 1 year ago

Great to see this.

The bytes clearly don't get to the player fast enough. The test are made with an scsi2sd card. I just moved, my computers are still packed. I will see if i can gather the bits and try the vanilla 'se' flim on a real se, but don't hold your breath.

In the meantime:

a) what are you using for mass storage? internal spinning scsi? external SD card (scsi2d, bluscsi, rascsi, other?)

b) You can add the option '--byterate nnn' after the profile one. This limits how many bytes per second are used to store the flim (quality will suffer).

My suggestion:

1) you encode only a part of the content using the '--duration' option, so it doesn't take forever to test.

2) you encode several flims at different byterates (2500 is se, 1500 is plus, your hardware is hopefully somewhere in between). Depending on how difficult it is for you to transfer files, you can encode more or less

./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --cache /tmp/nglyd --profile se --byterate 2200 --duration 10 --flim never_gonna_give_you_up-2200.flim --mp4 never_gonna_give_you_up-2200.mp4

Try the flims on your real hardware, until you get something smooth. You can then do the full duration and check it is smooth.

Flim will probably be ugly, but that's fine

3) Play with the other parameters to get something looking better within the specified byterate. You don't need to iterate with the real hardware anymore, just looking at the mp4 quality is ok. When happy, encode the full flim.

(happy hack: the command line sued to generate a lim file is stored in text at the begining, so use 'head -2 ' to retreive the options you used.)

Post me the byterate that your hardware can achieve, and I will show you a few tradeoff you could do (changing dithering, smoothing, picture size, framerate, etc). It is all a matter of taste after that.

aaronk6 commented 1 year ago

Hi, just briefly:

a) what are you using for mass storage? internal spinning scsi? external SD card (scsi2d, bluscsi, rascsi, other?)

I’m using RaSCSI. Both the SweetDreams-se.flim demo and my own encoded video are on the same storage.

you encode several flims at different byterates (2500 is se, 1500 is plus, your hardware is hopefully somewhere in between). Depending on how difficult it is for you to transfer files, you can encode more or less

Since I’m using RaSCSI, it’s trivial to try lots of different options in a short amount of time. I’ll let you know how it goes!

Thanks a lot!

fstark commented 1 year ago

The encoder for MacFlim2 has been developed against 2 videos: Sweet Dreams first (because is very 80s, and the video is very static) and Gangnam Style second (because it used to be the most popular YT video, so it embodies some "modernity" and it has a lot of rapid movement in it, making it interesting). The goal was to get Sweet Dreams running on a plus, and Gangnam running on a SE30.

I spent many many many dozen of hours optimizing the encoding format and compression using those two flims as reference. The way Annie Lennox stab the table, the detail of the oval dithering that follows or that spinning earth are burnt in my brain, alongside with that stupid horse at 0:27 in Gangnam style (to get it moving right, I had to rewrite most of the encoder and the full m68k assembly code).

So, yeah, them working well is not a surprise :-)

I don't have a RaSCSI, so I cannot check the performance. If it is slower than the SCSI2SD, then we may want to add an option (that would just degrade the byterate).

Another thing I've been playing with in my head is a benchmark mode in MacFlim, so it could help choose the right byterate when the hardware don't match the reference one (SCSI2SD).

Note that I had a couple of issues with fragmentation on a SCSI2SD (as surprising as it sound), but that manifest in general with a single skip. You have them regularly, which screams bandwidth issue...

fstark commented 1 year ago

Also, it can’t be stopped since it’s not reacting to mouse clicks anymore.

I tuess all the CPU is used by the SCSI subsystem and the display code, hence the busy wait loop (https://github.com/fstark/macflim/blob/main/macsrc/Playback.c#L182) is only executed once per block.

Keep the mouse button pressed until that lag and keep pressing. It should abort.

I added Bug #34 to see if I can do something (an issue is that the keys are only checked when there is nothing else to do, to keep as much as CPU power for the playback).

fstark commented 1 year ago

Btw, if you want to easily compare various encoding results (graphically), you can use a script like:

fred@Fred-Linux:~/Development/macflim$ cat make-grid.sh 
#!/bin/sh
./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --cache /tmp/nglyd --profile se --byterate 2500 --fps-ratio 2 --duration 30 --flim output1.flim --mp4 output1.mp4 --dither error --watermark "2500 2 e"
./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --cache /tmp/nglyd --profile se --byterate 1500 --fps-ratio 2 --duration 30 --flim output2.flim --mp4 output2.mp4 --dither error --watermark "1500 2 e"
./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --cache /tmp/nglyd --profile se --byterate 1500 --fps-ratio 3 --duration 30 --flim output3.flim --mp4 output3.mp4 --dither error --watermark "1500 3 e"
./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --cache /tmp/nglyd --profile se --byterate 1500 --fps-ratio 2 --duration 30 --flim output4.flim --mp4 output4.mp4 --dither ordered --filters g1.6k10bsc --watermark "1500 32 g1.6k10bsc o"
ffmpeg -y -i output1.mp4 -i output2.mp4 -i output3.mp4 -i output4.mp4 -filter_complex "[0:v][1:v]hstack=inputs=2[top]; [2:v][3:v]hstack=inputs=2[bottom]; [top][bottom]vstack=inputs=2[v]" -map "[v]" grid.mp4

This will generate an grid.mp4 file (without sound), with 4 rendering of your flim.

Note I added the g1.6k10bsc filter in the 4th example to darken a bit the image for the ordered dithering, so there isn't the noise on the left and right side (distracting and eating bandwidth).

Top-left is the 2500 bytes/frame that cannot be played. The 3 others are 1500 bytes/frame. Top-right is just 1500 bytes/frame, same parameters. Bottom left have the framerate reduced to 8.3 fps. Bottom right keeps framerate but uses an ordered error encoding (simlar to mac plus).

Those are just example, when you have found the byterate you can use, that's an easy way to compare.

There are many other parameters we can tweak, but it is difficult to get a nice image at low bitrate with this video because a) the original is not very clean, b) there are horizontal pannings and c) there are full background gradient changes.

aaronk6 commented 1 year ago

Keep the mouse button pressed until that lag and keep pressing. It should abort.

Yes, that works!

Thanks for the hint regarding the grid. That’s quite helpful.

I did some testing and even with the following options I’m still seeing (short) dropouts:

./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --duration 15 --cache /tmp/nglyd \
  --profile se --fps-ratio 3 --byterate 1500 --flim nggyp-1500-fps3.flim

The only one that worked smoothly so far is with the default plus profile:

./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --duration 15 --cache /tmp/nglyd \
  --profile plus --flim nggyp-plus.flim

I’ll keep testing!

aaronk6 commented 1 year ago

I’ve just encoded the full duration with the default plus profile and then it actually has dropouts (they appear after 15 seconds which is why I haven’t noticed them in the tests before).

aaronk6 commented 1 year ago

The following two are working and make the full video playable (both use a very low byterate of 1200):

./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --cache /tmp/nglyd \
  --profile plus --filters g1.6k10bsc --byterate 1200 --flim nggyp-plus-g1-1200.flim

./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --cache /tmp/nglyd \
  --profile se --byterate 1200 --flim nggyp-se-1200.flim

In both cases, increasing the byterate to 1300 introduces the dropouts again, so I think I have found the sweet spot. I guess that supports your theory that it’s bandwidth-related.

I also found out that the Sweet Dreams demo for the SE actually also has dropouts (just not at the beginning which is why I hadn’t noticed earlier).

A benchmark mode would actually be very handy!

I’ll try with SCSI2SD next to see if it’s actually RaSCSI being slow, or something else.

fstark commented 1 year ago

(Sorry again for the late comment)

It does sound like the RaSCSI. I tested again on a real SE with the SCSI2SD 5.2 and all the encoding I showed were working.

I also have a BluSCSI, I will see if I can unpack it and do some tests.

I need to buy a RaSCSI for checking (and maybe there is something I could do in software to mitigate? [seems unplausible]).

Which version of the RaSCSI do you have?

aaronk6 commented 1 year ago

I tested again on a real SE with the SCSI2SD 5.2 and all the encoding I showed were working.

That’s good, I also have SCSI2SD version 5.2. I’ll try that soon and let you know how it goes!

I need to buy a RaSCSI for checking (and maybe there is something I could do in software to mitigate? [seems unplausible]).

I ordered mine from https://samplerspa.de/produkt/rascsi-adapter-board/ (no soldering required).

Which version of the RaSCSI do you have?

The hardware version is 2.4a, the software is 22.5.2.

aaronk6 commented 1 year ago

Success! 🎉 The video that I had encoded with the default SE profile is now working perfectly (using SCSI2SD 5.2).

./flimmaker https://www.youtube.com/watch?v=dQw4w9WgXcQ --profile se \
  --flim never_gonna_give_you_up.flim --mp4 never_gonna_give_you_up.mp4