MP_STE video player for ATari ST(E) tutorial

[moulinaie]

Hi

 

This little video I've made to show some tips in MP_STE.

 

http://youtu.be/3oP-x4rfbHQ

 

And my page to load the software:

 

http://gtello.pagesp....fr/mpste_f.htm (français)

http://gtello.pagesp....fr/mpste_e.htm (english)

 

Guillaume.

[+DarkLord]

This is just way cool.

 

I have to ask though, if it absolutely has to be at least STe level, hardware wise?

 

Couldn't you squeeze something out of a 68030 equipped ST with a maths

coprocessor?

[moulinaie]

This is just way cool.

 

I have to ask though, if it absolutely has to be at least STe level, hardware wise?

 

This works on a ST, but the sound managment takes more time on this machine because of the lack of DMA sound system.

So, even with the FLM conversion, you may not acheive the best frame rate for some animations.

 

MP_STE can use:

- STE DMA sound

- ST Yamaha chip

- some sound cards (MV16, ST Replay 8, ST Replay 16)

 

This setting is available from the main dialog.

 

I've just made the test on my STE and for this particular animation (CAR_RACE), 100% frames displayed.

 

 

Couldn't you squeeze something out of a 68030 equipped ST with a maths

coprocessor?

 

MP_STE can work on a 68030 but limited to the ST(E) resolutions.

The best is to use M_Player, the player I wrote for Falcon/TT that really takes advantage of the 68030, fast ram and enhanced graphic modes up to 16/32 bits.

With the TT, no conversion is requiered, the AVI animation is played perfect.

 

About the FPU coprocessor, no CODEC I use requiere any floating point computation.

 

Guillaume.

[Shredder11]

I downloaded this ages ago but never got around to using it, but wow this has motivated me to do it sooner. I wonder how much video you can cram into a 4MB machine and could you possibly stream from a hard disk?

[moulinaie]

I downloaded this ages ago but never got around to using it, but wow this has motivated me to do it sooner. I wonder how much video you can cram into a 4MB machine and could you possibly stream from a hard disk?

 

Well, the video in itself is not a problem, the images are loaded one by one (stream from hard disk). The limitation comes from the sound that must be processed and loaded before.

But MP_STE, when the sound is too long, offers to lower its quality to fit it in the RAM.

The lower it can is 6.25 KHz in 8 bits mono, this means 6250 bytes per second.

 

Let's say that you only have 3,5MB left: 3670016 : 6250 = 587 sec close to 10 minutes.

 

Guillaume.

[Willsy]

Wow Guillaume! I didn't know you were an ST hacker too! Me also! I'm looking at writing a Forth system for the ST, just so I can practice some 68K (it's been a long long time since I wrote any 68K - 20 years, actually!)

 

I need to stop playing with the TI-99/4A and get busy with the ST

[moulinaie]

Wow Guillaume! I didn't know you were an ST hacker too! Me also! I'm looking at writing a Forth system for the ST, just so I can practice some 68K (it's been a long long time since I wrote any 68K - 20 years, actually!)

 

I need to stop playing with the TI-99/4A and get busy with the ST

 

I also wrote a FORTH interpreter/compiler for the ST...!!

 

Guillaume.

[+DarkLord]

Hmm, just out of (more) curiosity...when I referenced a maths coprocessor, I was already pretty sure

it wasn't being used with Mplayer, so thanks.

 

So a maths coprocessor can't contribute to what Mplayer does, is that correct? Thanks.

[moulinaie]

Hmm, just out of (more) curiosity...when I referenced a maths coprocessor, I was already pretty sure

it wasn't being used with Mplayer, so thanks.

 

So a maths coprocessor can't contribute to what Mplayer does, is that correct? Thanks.

 

Exactly! A Math processor can handle floating point numbers, compute easely sine, cosine, square root, etc... but most video encodings only use integers or binary encoding. The ones that are based on math are MPEG for example. But, I use an integer method do decode it (so an approximation) that is much faster than the floating point routines even with the FPU.

 

Thanks for your interest,

Guillaume.

[oky2000]

Nice little player. Is the sound streamed from disk? Is video streamed from disk?

[moulinaie]

Nice little player. Is the sound streamed from disk? Is video streamed from disk?

 

Yes from disk for the images. But fully loaded for the sound. That's why 4MB is better.

I couldn't imagine to manage both sound and images in streaming with a 8MHz machine.

Well, if it was to replay ATari videos on an Atari this could be done, but I wanted to replay as many formats as possible. So, for example, when you load an AVI file, the sound is 11KHz, 22KHz or 44KHz in either mono or stereo and 8 or 16 bits, sometimes signed, sometimes not..!

Each sound bloc has to be processed to match the DMA requierements: 12,5KHz, 25KHz, 50KHz, only 8 bits signed.

This work on sound would slow down the replay between two images.

 

Guillaume.

[oky2000]

Nice little player. Is the sound streamed from disk? Is video streamed from disk?

 

Yes from disk for the images. But fully loaded for the sound. That's why 4MB is better.

I couldn't imagine to manage both sound and images in streaming with a 8MHz machine.

Well, if it was to replay ATari videos on an Atari this could be done, but I wanted to replay as many formats as possible. So, for example, when you load an AVI file, the sound is 11KHz, 22KHz or 44KHz in either mono or stereo and 8 or 16 bits, sometimes signed, sometimes not..!

Each sound bloc has to be processed to match the DMA requierements: 12,5KHz, 25KHz, 50KHz, only 8 bits signed.

This work on sound would slow down the replay between two images.

 

Guillaume.

 

Ahh you had same problem as I have, how to interleave sound and video streaming from the hard disk on older machines from 1980s

[moulinaie]

 

Ahh you had same problem as I have, how to interleave sound and video streaming from the hard disk on older machines from 1980s

 

Are you working on a video player?

 

On the ST, a french magazine did it with videos on the CD ROM. No compression was used, the images were just screen copies and the sound yet ready to be read with DMA.

So the player only had to "read" data from the disk to memory, filling alternatively two sound buffers: when one was played, the other could be filled from disk. The images too had two buffers, and you just had to swap the physical screen address from one buffer to another.

The advantage was a very simple player running on very slow machines. The problem was the amount of uncompressed data that requiered a CD ROM for storing everything.

 

Guillaume.

[oky2000]

Ahh you had same problem as I have, how to interleave sound and video streaming from the hard disk on older machines from 1980s

 

Are you working on a video player?

 

On the ST, a french magazine did it with videos on the CD ROM. No compression was used, the images were just screen copies and the sound yet ready to be read with DMA.

So the player only had to "read" data from the disk to memory, filling alternatively two sound buffers: when one was played, the other could be filled from disk. The images too had two buffers, and you just had to swap the physical screen address from one buffer to another.

The advantage was a very simple player running on very slow machines. The problem was the amount of uncompressed data that requiered a CD ROM for storing everything.

 

Guillaume.

 

Yes, but from IDE hard disk for Amiga not ST. I was going to do it the same way by loading uncompressed images directly into video memory under DMA and interleaving the sound. I had problems with the sound, couldn't find any advice or algorithms how to interleave it. I was going to load 10 images and 0.40 second sample via double buffering, loading one set of images and sound sample whilst playing the other.

 

Latency is a huge problem for syncing, the more I can buffer the better it is but each screen alone is about 32kb or 40kb for HAM mode.

[moulinaie]

 

Yes, but from IDE hard disk for Amiga not ST. I was going to do it the same way by loading uncompressed images directly into video memory under DMA and interleaving the sound. I had problems with the sound, couldn't find any advice or algorithms how to interleave it. I was going to load 10 images and 0.40 second sample via double buffering, loading one set of images and sound sample whilst playing the other.

 

Latency is a huge problem for syncing, the more I can buffer the better it is but each screen alone is about 32kb or 40kb for HAM mode.

 

So you want to acheive 25 frames per second?

It is close to 800KB /sec for images and a little more for sound. I know that on the ST, 1000 KB/sec is a limit for several disks (the UltraSatan I use for example). THen your project is a good challenge as it pushes that kind of system to the limit!

 

Guillaume.

[+DarkLord]

Are you working on a video player?

 

On the ST, a french magazine did it with videos on the CD ROM. No compression was used, the images were just screen copies and the sound yet ready to be read with DMA.

So the player only had to "read" data from the disk to memory, filling alternatively two sound buffers: when one was played, the other could be filled from disk. The images too had two buffers, and you just had to swap the physical screen address from one buffer to another.

The advantage was a very simple player running on very slow machines. The problem was the amount of uncompressed data that requiered a CD ROM for storing everything.

 

Guillaume.

 

Hmm, but doesn't popular mass storage devices like the Satandisk, Ultrasatan, and easy CDROM availability make this a very viable option now?

 

It would seem that an option for that in Mplayer would make sense, if I'm understanding things correctly. (and forgive me if I'm being naive).

 

Thanks!

[oky2000]

Are you working on a video player?

 

On the ST, a french magazine did it with videos on the CD ROM. No compression was used, the images were just screen copies and the sound yet ready to be read with DMA.

So the player only had to "read" data from the disk to memory, filling alternatively two sound buffers: when one was played, the other could be filled from disk. The images too had two buffers, and you just had to swap the physical screen address from one buffer to another.

The advantage was a very simple player running on very slow machines. The problem was the amount of uncompressed data that requiered a CD ROM for storing everything.

 

Guillaume.

 

Hmm, but doesn't popular mass storage devices like the Satandisk, Ultrasatan, and easy CDROM availability make this a very viable option now?

 

It would seem that an option for that in Mplayer would make sense, if I'm understanding things correctly. (and forgive me if I'm being naive).

 

Thanks!

 

As an example I have a 7200RPM parallel ATA hard drive which alone is as fast as a new SATA notebook hard drive but the limiting factor is interface speeds for older machines. 1mb/sec true transfer speed may not be possible on an old Amiga IDE interface even though the drive can do much more in a Windows laptop.

 

It will be interesting to do it, first I will try it from RAM in an emulator (set too cycle exact speed).

[moulinaie]

 

Hmm, but doesn't popular mass storage devices like the Satandisk, Ultrasatan, and easy CDROM availability make this a very viable option now?

 

It would seem that an option for that in Mplayer would make sense, if I'm understanding things correctly. (and forgive me if I'm being naive).

 

Thanks!

 

Yes, the modern storage make this possible.

(Satan disk no: 128KB/sec is too low..!! see my test on the page: http://gtello.pagesperso-orange.fr/satan.htm)

And the CD ROM is not so easy to have on a simple ST(E) because the Interface is rare.

 

Guillaume.

[moulinaie]

 

As an example I have a 7200RPM parallel ATA hard drive which alone is as fast as a new SATA notebook hard drive but the limiting factor is interface speeds for older machines. 1mb/sec true transfer speed may not be possible on an old Amiga IDE interface even though the drive can do much more in a Windows laptop.

 

It will be interesting to do it, first I will try it from RAM in an emulator (set too cycle exact speed).

 

If you have a benchmark program, you can yet test the speed of the IDE disk and see what is the theorical limit before trying to program something impossible.

I know that on the STE I need to reduce the frame rate to 12 or even 8 fps sometimes (depending on the number of pixels and the compression complexity).

 

Guillaume.

[+DarkLord]

Yes, the modern storage make this possible.

(Satan disk no: 128KB/sec is too low..!! see my test on the page: http://gtello.pagesp...ge.fr/satan.htm)

And the CD ROM is not so easy to have on a simple ST(E) because the Interface is rare.

 

Guillaume.

 

Okay, I followed your link. So it looks like the Ultrasatan would be possible then.

 

Hmm, why are the QuickTime animations so slow on the US vs the FLM - is that

because the FLMs are optimized for Atari and QuickTime has to have extra work

down with it?

 

Thanks!

[moulinaie]

Yes, the modern storage make this possible.

(Satan disk no: 128KB/sec is too low..!! see my test on the page: http://gtello.pagesp...ge.fr/satan.htm)

And the CD ROM is not so easy to have on a simple ST(E) because the Interface is rare.

 

Guillaume.

 

Okay, I followed your link. So it looks like the Ultrasatan would be possible then.

 

Hmm, why are the QuickTime animations so slow on the US vs the FLM - is that

because the FLMs are optimized for Atari and QuickTime has to have extra work

down with it?

 

Thanks!

 

QuickTime animations use the encoding of the Mac graphic system, and yes, it's different from the Atari. Most of all, on the Mac, the 256 colors or 65536 colors came rapidely. We don't have that on the ST.

But even in 16 colors, encodings differs: on the Mac: one byte for two consecutive pixels of 4 bits each, on the Atari, the four bits of each pixel are separated in four different planes. So this is a long work for each frame.

 

Using the FLM is simple as the uncompression is made directly in video RAM. This means that you don't have to copy a buffer for each prepared frame, and that only pixels that change are rewritten.

 

Guillaume.

[+DarkLord]

 

QuickTime animations use the encoding of the Mac graphic system, and yes, it's different from the Atari. Most of all, on the Mac, the 256 colors or 65536 colors came rapidely. We don't have that on the ST.

But even in 16 colors, encodings differs: on the Mac: one byte for two consecutive pixels of 4 bits each, on the Atari, the four bits of each pixel are separated in four different planes. So this is a long work for each frame.

 

Using the FLM is simple as the uncompression is made directly in video RAM. This means that you don't have to copy a buffer for each prepared frame, and that only pixels that change are rewritten.

 

Guillaume.

 

Hmm, so if I wanted to expend the time and energy, and just for the "because I can" factor, I could convert an entire movie, put it on a multi-gig SD card via an Ultrasatan, and play it back from there? That would be kinda cool.

 

Thanks for the explanations - seriously good reading here!

[oky2000]

As an example I have a 7200RPM parallel ATA hard drive which alone is as fast as a new SATA notebook hard drive but the limiting factor is interface speeds for older machines. 1mb/sec true transfer speed may not be possible on an old Amiga IDE interface even though the drive can do much more in a Windows laptop.

 

It will be interesting to do it, first I will try it from RAM in an emulator (set too cycle exact speed).

 

If you have a benchmark program, you can yet test the speed of the IDE disk and see what is the theorical limit before trying to program something impossible.

I know that on the STE I need to reduce the frame rate to 12 or even 8 fps sometimes (depending on the number of pixels and the compression complexity).

 

Guillaume.

 

Limiting factor is the DMA bus speed and also the unbuffered IDE interface speeds really, it is hovering around the 1mb/sec mark and I was going to do 16:9 or 2.35:1 size clips to get it down to 320x180 or 320x150 etc so it should be OK. 7200RPM drives have much lower seek times though which also helps (every little helps at this level!)

[moulinaie]

 

Limiting factor is the DMA bus speed and also the unbuffered IDE interface speeds really, it is hovering around the 1mb/sec mark and I was going to do 16:9 or 2.35:1 size clips to get it down to 320x180 or 320x150 etc so it should be OK. 7200RPM drives have much lower seek times though which also helps (every little helps at this level!)

 

With a continuous reading, the "seek delay" has no effect if your file is not broken into little pieces (IMHO)

320x150 looks a good solution (600KB/sec for 25 frames/sec).

Let us know when the project advances.

 

Guillaume.

[oky2000]

Limiting factor is the DMA bus speed and also the unbuffered IDE interface speeds really, it is hovering around the 1mb/sec mark and I was going to do 16:9 or 2.35:1 size clips to get it down to 320x180 or 320x150 etc so it should be OK. 7200RPM drives have much lower seek times though which also helps (every little helps at this level!)

 

With a continuous reading, the "seek delay" has no effect if your file is not broken into little pieces (IMHO)

320x150 looks a good solution (600KB/sec for 25 frames/sec).

Let us know when the project advances.

 

Guillaume.

 

But the "movie player" was to initially be just loading in raw uncompressed images in sequence for tweaking of the best performance via how many frames to load in advance in one go under DMA. Ditto with lots of 0.4 second or 0.2 second sound sample files.

 

Didn't want seek time to discourage me at alpha code stage you see

 

Once I was happy with performance I would have used a single file and read in 320kb (32kb x 10 for say 10 frames) then ??kb for 0.4 second of sound for those 10 frames in one go and dump it into chip memory. Would then use the code to hit sound chip with DMA playback on channels 1-3 or 2-4 (sort of double buffering for sound...you have 4 channels to play with so overlay them to minimize any crackling due to silent setup time for next 0.4 second sample playback to initiate) at a time from the file so seek time not an issue.

 

Just writing that gives me more ideas actually. Maybe I could do it with 160kb at a time and 20kb of sample data for 5 frames and 0.2 second of sample time. Doubling this up for double buffering gives you 360kb. As screen memory will just point to an address I don't need any more and as all the addresses are fixed for each bank of 5 frames of movie I can save a lot of code. At most two procedures and a controlling procedure, I think the compiled code should be fine to run even on a 512kb chipram machine.

 

This is side tracking me from my Buck Rogers game now