English Amiga Board - View Single Post - Amiga movies possible on stock OCS machine?

Photon · 19 November 2009, 13:45

Well, converting videos to formats that are easier on the CPU is no biggie, and no trick. It's done all the time for PSP, mobile phones etc.

To stream it properly, I think you need to write a custom player. HAM certainly promises the best quality for OCS/ECS. With a 68000 CPU, that leaves only 50% of the CPU memory accesses between vblanks. Losing color depth to say 16 colors would help, but I'd rather shrink the frame size. 288x216 isn't so small.

You need to load the frames, and show the frames. If a compressed format is used, there's very little time to decompress it, even if it's a lossless IFF-anim-like format and using the blitter to blit the changes between frames. If the blitter is used, it will run at 50% and CPU (without fastram) at "1%" for the duration of the bitplane DMA.

Also, you need to load the data, and I'm not so sure SCSI with DMA will allow stutter-free streaming. If IDE is used, CPU does all the loading, and unless you use CPU-based compression it will load to chipmem and could go as low as 300-500KB/s then.

At the above frame size, no compression, 25 fps, that's 46656 bytes/frame or 1.15 MB/s.

So, compression is necessary; the best CF cards load at about 800-900 KB/s with no fastmem. Best bet is something simple that uses the blitter, I think. But it's not 100% certain that 46k can't be loaded to chipmem in two vblanks' time on most controllers.

Reducing chroma a bit and using 16 greyscales as the HAM base colors would help with luma aberrations (at the penalty of introducing some grey pixels, but it would be 'more okay' than anything else I think).

Fastmem would instantly make it much more viable, even uncompressed, on an A1000 and up. But as you know I'm an A500 512k chip/512k slow fetishist...

And then it would be less of a challenge, just shrink framesize until it loads smoothly, sort of.

19 November 2009, 13:45	#57
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,615	Well, converting videos to formats that are easier on the CPU is no biggie, and no trick. It's done all the time for PSP, mobile phones etc. To stream it properly, I think you need to write a custom player. HAM certainly promises the best quality for OCS/ECS. With a 68000 CPU, that leaves only 50% of the CPU memory accesses between vblanks. Losing color depth to say 16 colors would help, but I'd rather shrink the frame size. 288x216 isn't so small. You need to load the frames, and show the frames. If a compressed format is used, there's very little time to decompress it, even if it's a lossless IFF-anim-like format and using the blitter to blit the changes between frames. If the blitter is used, it will run at 50% and CPU (without fastram) at "1%" for the duration of the bitplane DMA. Also, you need to load the data, and I'm not so sure SCSI with DMA will allow stutter-free streaming. If IDE is used, CPU does all the loading, and unless you use CPU-based compression it will load to chipmem and could go as low as 300-500KB/s then. At the above frame size, no compression, 25 fps, that's 46656 bytes/frame or 1.15 MB/s. So, compression is necessary; the best CF cards load at about 800-900 KB/s with no fastmem. Best bet is something simple that uses the blitter, I think. But it's not 100% certain that 46k can't be loaded to chipmem in two vblanks' time on most controllers. Reducing chroma a bit and using 16 greyscales as the HAM base colors would help with luma aberrations (at the penalty of introducing some grey pixels, but it would be 'more okay' than anything else I think). Fastmem would instantly make it much more viable, even uncompressed, on an A1000 and up. But as you know I'm an A500 512k chip/512k slow fetishist... And then it would be less of a challenge, just shrink framesize until it loads smoothly, sort of. Last edited by Photon; 19 November 2009 at 14:00.