HAM Video Variants - FS-UAE vs Real Amiga Hardware

[movec]

Hi guys,

I've created a video with 5 different HAM variants (+ 8-bit sound), 4 run on my real Amiga (4000/060) just fine, the very last (version 5), is not fast enough on my real Amiga, but runs fine in FS-UAE 2.8.3 (in 4000/040 mode). The video shows HAM6/HAM8, with a shared color palette and with multiple color palettes (one per frame) in lores (4 versions), and one version in hires. My guess is that FS-UAE doesn't model certain aspects of the Amiga bus sytems and IO systems that's why version 5 shows a different behavior. It didn't run that well in older UAE versions, but with FS-UAE 2.8.3 this appears to work better now (or too good, depends on how one sees it).

FS-UAE runs in full-screen mode. The nice side-effect is that you can run converted HD videos this way in the Emulator (e.g. converted to 320x256), but when stretched it all comes out right (with correct ratios) again.

Here is the recorded FS-UAE session, in case you want to see it (from artefact-rich to very good) :
[ Show youtube player ]

For version 5 (hires with 8-bit sound) I also created the full-length video:
[ Show youtube player ]

I hope to find time to look into what can be done with my CD32

cheers!

[E-Penguin]

Impressive!

It just occurred to me that HAM is a form of run length encoding, or at least close to it.

[robinsonb5]

Very cool! Can the real Amiga cope with Hires if you drop from HAM8 to HAM6, I wonder?

[Pyromania]

Kool, thanx for taking the time to do this.

[movec]

Originally Posted by robinsonb5

Very cool! Can the real Amiga cope with Hires if you drop from HAM8 to HAM6, I wonder?

Intersting idea. I think it would be close to what is possible considering only memory bandwidth. Although I don't think that it would look better than some "Copper-stretched" HAM8 hires, it would be interesting to see whether it is fast enough.

[movec]

Originally Posted by E-Penguin

Impressive!

It just occurred to me that HAM is a form of run length encoding, or at least close to it.

Yeah, the longer one looks at HAM, the more ideas come up what it is!

My variants are 1) a lossy 24-bit picture compression format with hardware decoder 2) the HAM pixel data is an instruction sequence with 4 different instructions; 3) it's an extended fancy planar mode.

[E-Penguin]

I'd argue that, for a given pallet, it is lossless. There's loss going from 24-bit to whatever HAM pallet you've chosen though.

I find it amazing what 20+ year old hardware can do. The Amigas were such well designed machines for their day.

[alpine9000]

There was a bug in older UAE versions where ham6 on emulated AGA hardware would display an incorrect palettte.

I know it's fixed in recent winuae vertsions, I assume the latest FS-UAE includes the fix.

[robinsonb5]

Originally Posted by movec

Yeah, the longer one looks at HAM, the more ideas come up what it is!

My variants are 1) a lossy 24-bit picture compression format with hardware decoder 2) the HAM pixel data is an instruction sequence with 4 different instructions; 3) it's an extended fancy planar mode.

I tend to think of it as a form of delta encoding - but it's certainly very interesting.

I wonder, too, what could be achieved in HAM6, by carrying forward errors from each frame to the next when encoding, to introduce a temporal dithering element. (Assuming you're not already doing that?)

[roondar]

Wonderful results there. The palette-per-frame options are great quality, regardless of OCS or AGA. The HAM-8 hires version looks more or less identical to the original

I wonder how these would play on less powerful hardware, like an AGA machine with 68030 or maybe an ECS machine with 68030/68040?

[saimon69]

Originally Posted by roondar

I wonder how these would play on less powerful hardware, like an AGA machine with 68030 or maybe an ECS machine with 68030/68040?

I used to render 3D animations on my old 1200 and a friend of mine used to render animations on its 500 and Hard disk, so i could easily say that 25FPS on less than a 060 is a dream; however a 12/15FPS is in my opinion fully in the capabilities of a base 1200.
What bothers me is the weight of those animations; if we envision some practical use - for an opening movie or cut scenes in a game in example - it cannot be around 700 megabytes for three minutes; some form of codec might be needed that is viable for the target platform.

[movec]

Originally Posted by E-Penguin

There's loss going from 24-bit to whatever HAM pallet you've chosen though.

Yes, that's how I see it too.

[movec]

Originally Posted by robinsonb5

I wonder, too, what could be achieved in HAM6, by carrying forward errors from each frame to the next when encoding, to introduce a temporal dithering element. (Assuming you're not already doing that?)

I applied dithering on each frame (with multiple palettes), but not temporal. The dithering certainly improves it.

[movec]

Originally Posted by movec

Hi guys,
I've created a video with 5 different HAM variants (+ 8-bit sound), ..., The video shows HAM6/HAM8, with a shared color palette and with multiple color palettes (one per frame) in lores (4 versions), and one version in hires.

I just found out that one of the tools that I used for converting the pictures, png2ilbm, doesn't support HAM and the generated frames in versions V3-V5 in this video are actually "only" AGA8 frames! Hence, there might be even more possible (png2ilbm does an awesome job in converting to AGA though). Versions V1 and V2 are indeed HAM videos.

[emufan]

missed that post

which tool did you use to compile the anim? wavetracer or moloch's fantasia - the windows version?

btw, i still recommend xnview and the libquant dither algorithm - bit slow but gives excellent results.

[movec]

Originally Posted by emufan

missed that post

which tool did you use to compile the anim? wavetracer or moloch's fantasia - the windows version?

btw, i still recommend xnview and the libquant dither algorithm - bit slow but gives excellent results.

Hi emufan, I use ffmpeg to extract the frames, png2ilbm to convert the frames to AGA iff pictures, and animconvert to encode the sequence of iff files into an anim file. Then I use my own converter tool (editanim) to inject the sound into the anim file (turning it into an AnimFX sound anim file). I do all the conversion on Linux (animconvert runs in the Amiga emulator).

With png2ilbm I also do dithering. Dithering makes a great difference; png2ilbm is available for many platforms (including Amiga):
http://oscomp.hu/?games/s/png2ilbm

In particular, with png2ilbm you can also force the background color to be black in all frames. It's a detail, but unlike all the CDXL workarounds with black frames around the video etc. the videos I generate work out of the box (otherwise you get flashing backgrounds if the video is not covering the entire screen). I am looking for excellent looking&sounding results, but I am willing to compromise on everything else. However, I am also interested in playing videos on my CD32 (most likely with a CDXL-ish format reading directly from the CD ROM).

The key to good quality of AGA videos on the original Amiga hardware is to have different color palettes per frame, but this also complicates any compression.

The ANIM format compresses most frames only by about 1-8% in these videos. The reason for this low compression ratio is also the different color palettes per frame. The ANIM players also have a significant overhead in decompressing the videos. For these kinds of videos the ANIM format doesn't pay off, but the AnimFX player is most flexible and supports sound. That's the only reason why I am generating ANIM files.

The CDXL player 'cdgsxl' is too slow @25 FPS on my A4000 with the blit option (in PIO4 mode). Without the blit option it is "fast enough" to play the video at 25 FPS in lores, but has a lot of flicker (in other words it doesn't work).

The other option is the RiVA mpeg player. But so far I couldn't find any ffmpeg conversion setting where the RiVA player is fast enough @ 25 FPS on my A4000/60 and it looks at least somewhat as good as the AGA videos I generate. The sound works great, but it is skipping too many frames. However, I didn't spend much time on this one, there might be a way to get better results. I also have a Picasso IV.

BTW, just for the fun of it, I am also looking into writing my own player

[pandy71]

ffmpeg can create files with CLUT (CLUT can be computed for whole video sequence or independently for every frame as separate step) and ffmpeg quality is not bad.
https://ffmpeg.org/ffmpeg-filters.html#palettegen
https://ffmpeg.org/ffmpeg-filters.html#paletteuse

[emufan]

@movec: some valuable infos, thanks. if you have something to test, just announce it
@pandy71: this is cool, have to test that too. thnx

[movec]

Originally Posted by emufan

@movec: some valuable infos, thanks. if you have something to test, just announce it
@pandy71: this is cool, have to test that too. thnx

After that discussion I was wondering what the total number of different colors in such a video actually is and implemented the computation of those colors - just uploaded a new AGA8 video, with the color count in it, 380,000+ colors!

[ Show youtube player ]

[matthey]

Originally Posted by movec

After that discussion I was wondering what the total number of different colors in such a video actually is and implemented the computation of those colors - just uploaded a new AGA8 video, with the color count in it, 380,000+ colors!

It looks and sound great, especially for the resolution, but the file is big at 493MB for 3 minutes. You need AGA, a fast CPU (>=68040?), fast drive interface (3+ MB/s?) and a large drive. There are probably fewer than 5% of active Amiga owners who could play the video on real hardware. HAM8 video may have been good for fast and easy low compression decoding years ago but it is primitive with the CPU performance and video encoding technology of today.