Watch movies on ST

[ppera]

I don't know has it someone tried, but I little experienced with converting and playing video (movie) on Atari ST.

 

 

http://www.ppest.org/atari/movpst.php

 

It is 25MB long, and has 1 minute uncompressed video (just rared to faster DL), without sound.

With program DISP1500.PRG it will play smooth animation in Steem, at 25 fps.

Of course, run it in low-res.

 

Used Virtual Dub, AVISynth, PSP Pro to convert video to 16 color bitmaps, then with special program it is converted to raw Atari ST bitmaps with palette (32032 bytes per frame).

Edited February 2, 2007 by ppera

[ggn]

Well....

 

I don't know how to put this, but...

 

http://perso.orange.fr/didierm/index-e.htm

 

http://perso.orange.fr/gtello/mplayere.htm

 

Better ask next time before spending time for nothing...

[Curt Vendel]

While its true there was an existing movie player, the guy had the interest and put in the time to make something on his own, hardly something that should be called spending time for nothing...

 

Atariage is about helping and encouraging others, not berating them and putting them down dude, come on.

 

 

 

 

Curt

 

Well....

 

I don't know how to put this, but...

 

http://perso.orange.fr/didierm/index-e.htm

 

http://perso.orange.fr/gtello/mplayere.htm

 

Better ask next time before spending time for nothing...

[ppera]

Well....

 

I don't know how to put this, but...

 

http://perso.orange.fr/didierm/index-e.htm

 

http://perso.orange.fr/gtello/mplayere.htm

 

Better ask next time before spending time for nothing...

 

Thank you very much for 'kind' words mister...

 

Better look next time things . Your links are for SW not usable on ordinary ST machines.

 

I made it for my own fun and curiosity - too see how it will look and how smooth playback can be.

If some others find it interesting, then my post did it's purpose.

What was purpose of your reply?

[ggn]

Thank you very much for 'kind' words mister...

 

Think nothing of it

 

Better look next time things . Your links are for SW not usable on ordinary ST machines.

 

You are quite wrong as I've actually seen a quicktime video of about 160x100 resolution with sound reaching about 10fps using mplayer

 

I made it for my own fun and curiosity - too see how it will look and how smooth playback can be.

If some others find it interesting, then my post did it's purpose.

What was purpose of your reply?

 

Well, let's just say that I'm a little bit miffed that your program wiped clean my winxp partition including all data in it while imaging a disk. I could be that. Dunno. I'll let you know. Mister.

[Atari-Jess]

I love how you try to blame it on his program.

You're nuts, there is no way this could have done it.

 

The program at fault is the one that made the image

don't think you can get away blaming him for your mistake.

 

And honestly, how it "wiped clean" (by this I interpret format or damaged)

that whole partition I find it very strange. Something must have

happened to the harddisk such as latent damage, or a power spike

or perahsp even a virus or malware.

 

Making a disk image though? I'll believe it if you can give me evidence.

[ppera]

Ah. Wiped XP partition...

 

And what it has with this thread?

 

Can moderators delete this personal attacks?

(Btw. he talks still about mplayer, but not says on what it runs...)

 

Just to note that very uncareful user can really delete his main partition with drimg.

There are warnings in manual, extra warning by accessing disks over 2GB. So if someone deleted his

Win partition let blame himself. Or it was really some failure in system.

[ggn]

Ah. Wiped XP partition...

 

And what it has with this thread?

 

Nothing. You asked, I answered.

 

(Btw. he talks still about mplayer, but not says on what it runs...)

Plain ste, 4mb, floppy drive. BTW I like your use of 3rd person here.

 

Just to note that very uncareful user can really delete his main partition with drimg.

There are warnings in manual, extra warning by accessing disks over 2GB. So if someone deleted his

Win partition let blame himself. Or it was really some failure in system.

 

Oh, so it is not fair to warn everybody yourslef. Fine. Thank you very much. I just won't use your program again. Fair?

Edited January 30, 2007 by ggn

[ppera]

Brief Webpage with another, shorter clip:

 

http://www.ppest.org/atari/movpst.php

[krupkaj]

It is interesting. What about adding the sound? It should not be a problem on STE using the DMA.

[ppera]

It is interesting. What about adding the sound? It should not be a problem on STE using the DMA.

 

 

I will look for sound - is not something what I programmed ever.

8-bit mono sampling should not take much data transfer rate.

Unfortunatelly, I don't have STe, so can it try only in emulators.

 

Added cartoon clip, what looks far best...

Edited February 2, 2007 by ppera

[ppera]

I made version with audio for STE.

It would be good that STE owners test it on their machines.

Will work good only with faster hard disk/interface. Data transfer rate must be at least 850KB/sec.

 

http://www.ppest.org/atari/movpst.php

[coze]

interesting ! so this works on STe (68000)? how is the quality ?

 

there's the HAMP player for Amiga, which plays HAM converted movies ...

 

http://www.youtube.com/watch?v=O2k3fh_I5JQ

[Dal_1978]

interesting ! so this works on STe (68000)? how is the quality ?

 

there's the HAMP player for Amiga, which plays HAM converted movies ...

 

http://www.youtube.com/watch?v=O2k3fh_I5JQ

 

Now that is impressive - there can be no denying!

[OldAtarian]

Well....

 

I don't know how to put this, but...

 

http://perso.orange.fr/didierm/index-e.htm

 

http://perso.orange.fr/gtello/mplayere.htm

 

Better ask next time before spending time for nothing...

 

Is English your first language? mPlayer REQUIRES a 68030 or faster processor. That leaves out all ST, STe, and Mega machines, in other words, most of the TOS compatibles in existence. Your assertion that you could possibly be running it on a standard STe is BULL.

 

It's funny how you think an 8mhz CPU is actually capable of decoding video on the fly. I had a DVD decoder card in my 80mhz 486 machine because it couldn't do video on it's own and that's a helluva lot faster than an 8mhz ST.

 

 

"It requieres a 68030 (mini) and a 256 colors display:

 

* TT and Falcon with or without a graphic card.

* machines running Aranym with a 15 bits display mini.

* clones as the Hades or Milan."

 

I think the author of the program knows what it runs on and what it doesn't run on.

Edited November 30, 2010 by OldAtarian

[The Usotsuki]

Almost sounds like 8088 Corruption. And as for what I think of ggn in this thread, I won't go there.

[The_Laird]

Almost sounds like 8088 Corruption. And as for what I think of ggn in this thread, I won't go there.

 

GGN and his buddies already have somewhat of a reputation so its nothing unusual i can asure you!

[kool kitty89]

Don't forget about the Mega CD (Sega CD) video. All catering to 150 kB/s or ~172 kB/s (not sure how many videos used mode 2 data) and 8-bit PCM audio (usually mono 22 or 32 kHz -not sure if any uses compression but all is 8-bit output -must be formatted to sign-magnitude data though as the Ricoh PCM sound chip only uses that).

The video really pushing both 68ks and using the cell by cell color optimization would push beyond what a vanilla ST is capable off (and codecs using cinepak-like compression taking advantage of the hardware tilemap/character based graphics), but there's a fair amount of uncompressed 16 color stuff as well, and that would directly correspond to the ST (9-bit RGB). Plus, in the practical sense the dual 68ks won't be going full bore anyway as the CD's 68k has to manage CD-ROM data streaming/caching (no dedicated MCU for that) and the MD's CPU is halted during vblank DMA (the VDP can only load VRAM during vblank with the CPU halted so the more decompressed data being updated, the more time the CPU spends halted).

 

Though even for the uncompressed 16 color stuff you've got the benefit of DMA audio and the blitter (embedded in the CD's ASIC) with hardware 16-color packed pixel bitmap to MD tilemap conversion on the fly. (on the ST you wouldn't have to deal with character graphics though -but for compressed video you might consider using packed pixel converted to planar on the fly if you had enough resource, or the Blitter of the MEGA/STe)

There's rudimentary cinepak-like (tiled/vector quantized) lossy schemes that could be used and a few MCD games do that rather than using the tilemap and added use of 4 subpalettes per frame with the main example being Rebel Assault. (some short clips seem to use buffered uncompressed animation while most is rather heavily artifacted compressed video)

And beyond that there's lossless compression to consider be it full frame or in addition to lossy compression (ie pack the tiles together losslessly compressed, unpack them and assemble them to the final image -be it using hardware character modes or in the ST or some MCD games using blitting ot software blitting). For full-frame lossless compression, using pattern dithering and heavier posterization would tend to aid in higher compression ratios. (pure posterization would probably be best for something as rudimentary as RLE though you could encode video as dithered pairs treated as 8-bit packed pixels and decode that to 4-bit planar, or maybe it would be less resource intensive to treat it as dithered 2-bit pixel pairs in 4 planes decompressed and decoded to 4 dithered 1-bit planes -the pseudo 8bpp method would give the best compression though, and other options for better lossless schemes with more CPU resoruce and/or a blitter)

 

For a vanilla 8 MHz ST you'd be stuck with software decompression and software blitting with 9-bit RGB and hacking the YM2149 for PCM playback. (probably at 4 kHz) Plain full-frame 16 color animation using simple RLE with images preprocessed to best cater to RLE while still looking decent might be a good route along with audio pre-converted to YM format with corresponding routines to decode that to play on the YM rather than using full 8-bit PCM interpreted to YM on the fly. (depending how you formatted it, you might be able to reasonably convert the audio to 4-bit words then decoded and interpreted to the proper commands with the proper timing for the YM, though maybe more than that if you wanted optimal quality depending on the effective linear resolution being used -at 4 kHz you wouldn't have much use for 8-bit PCM though and at that rate a 5-bit linear range is almost indistinguishable from 8-bit, though if you could manage higher rates that would change and by 8 kHz you'd have a 6-bit linear range being preferable but the more you push that, the less CPU resource you have for video decoding)

For the video you'd definitely want to optimize 16 colors per frame and if you weren't doing RLE compression, you'd probably want to apply optimal dithering as well. (if no compression at all, some nice error diffusion dithering would be best, but with many lossless schemes you might be better off using pattern dithering -and again using chunky pixels for any such case would be preferable if you had the CPU resource -let alone a MEGA with a blitter to help with that)

Then you have tile based lossy techniques to build up the frame from a group of tiles that may be repeated and with planar graphics you could also vary color depth from the bottom 2/4/8 colors rather than using 4-bits for every cell. (though that's more attractive if lossless compression isn't used as well, or if you didn't bother to use chunky pixels to optimized lossless compression but plain per-bitplane lossless compression, and with no lossless compression you could use any sort of dithering pattern you wanted)

 

Without a blitter you'd need to use the CPU to assemble the cells as such, though assuming they're all 8x8 cells, that shouldn't be too bad.

And for fixed bitrate like CD-ROM (or floppy) you'd want to keep that in mind as well.

 

Going up to the STe you've got hardware DMA audio and a blitter to help out and with the MSTE you've got a 16 MHz CPU as well, so in the latter case it would probably be fairly realistic to say that MCD-like video and audio would be relatively practical aside from games using the character capabilities of the VDP on the MD. (you'd have other advantages though like 12-bit RGB, plain double buffering rather than having to cater to VDP updates, etc) And for all cases you could at least count on similar screen sizes and framerates to all the MCD stuff.

 

 

Going back to the most primitive options you could have totally uncompressed audio and video catering to the 1985 520ST and in such a case you might end up with things like the Wolf Team FMV (Time Gal, Road Avenger, Cobra Command, etc), or Sonic CD, Tenka Fabu, Keio Flying Squadron, night trap or sewer shark -the last 2 without color clash but fewer colors (ideally with much better dithering as well) and poorer quality audio to cater to the ST's practical limitations. (maybe 8 kHz, probably closer to 4 kHz on the conservative side)

 

And before even getting into stuff like RLE you could simply use double wide and/or tall pixels and/or skipping every other line or pixel, so simple forms of scaling with the gaps offering primitive antialising (more or less) but not necessarily being preferable. (the first section of Dune's FMV intro uses vertical and horizontal gaps every other pixel for the VGA PC version, and double wide pixels -in 16 colors- skipping every other scanline on the Sega CD)

 

In all such uncompressed cases it's a trade between resolution and framerate (screen size being optionally large or small depending on use of rudimentary scaling). It would be reasonable to do 160x120 at 15 FPS at a 1x CD bitrate with a reasonable amount left over for low quality audio, or other resolutions at other sizes and simialr framerates with or without scaling, or dropping to ~8 FPS (choppy but what a lot of Japanese FMV did) you could go up to things like 224x160 or other sizes using spacing/doubled pixels. (or middleground like 10 or 12 FPS -10 FPS would be friendly for both PAL and NTSC as integer divisions of the refresh rate and is the lowest framerate that doesn't seem too choppy for a fair amount of video -so 160x176 at 10 FPS might be OK) Wirehead for example uses 10 FPS video. (and one of the few full-screen FMV games on the MCD at 256x224 using the lower resolution mode that most FMV used)

 

 

 

I could post a bunch of examples of screenshots and relavent youtube links if anyone's interested, but most of it's pretty easy to search for if you just pop in the titles I mentioned. (Novastorm is one of the better examples of -I think purely lossless- compressed 16 color FMV and I think Soul Star's intro may be pure 16 color stuff as well -not sure if Silpheed's backgrounds and cutscenes use pure lossless compressed 16 color video but it might- while the best looking tiled FMV would be among cases like Batman and Robin or Road Rash -among a few other late gen FMV titles like Lodestar or Wirehead, and then some nices cases of really well optimzied animated video with Dragon's Lair and Space Ace using very nice error diffusion dithering and per tile palette optimization with almost no noticeable clash at 12 FPS 288x192 video -lossless I think- with the 2nd background used for still backdrops -not sure if it's purely lossless or not though)

 

 

 

Again, in a general sense the MSTE could probably manage audio and video quality fairly competitive with the best video on the MCD with some trade-offs in color optimization. (the gap would be a bit more in favor of the MCD had developers used shadow -or even highlight- to a significant extent or dual-layer video in general, but that seems to have been avoided for various reasons without pushing for optimal ways to exploit that) The first compressed FMV with decent framerates and larger screen sizes appeared in 1993 with games like Dracula Unleashed and Ground Zero Texas.

Edited December 1, 2010 by kool kitty89