MP_STE updated with manual

[Moulinaie]

Hi all,

I have been working a bit on MP_STE, (M_PLAYER for the ST(e) computers), and here is version 3.00:
- plays AVI/MOV with sound, FLI/FLC/FLH, GIF, FLM
- can convert animations to the Extended FLM format + sound that is very fast on Atari.

I have started to write the PDF user manual in english.
Everything is on my page:

(français) https://gtello.pagesperso-orange.fr/mpste_f.htm
(english) https://gtello.pagesperso-orange.fr/mpste_e.htm

main_avi.png

Guillaume.

[CiH]

Ooh nice one!

M_Player is an essential piece of software on my Falcon.

I have an STE with oodles of Ultrasatan diskspace so time for a play perhaps.

Thank you for your continued support of the Atari scene.

[AtariCrypt]

Fantastic news Guillaume and a thank you also from me for supporting the Atari

[marss]

Thanks

[Moulinaie]

Ooh nice one!

M_Player is an essential piece of software on my Falcon.

I have an STE with oodles of Ultrasatan diskspace so time for a play perhaps.

Unused space is heresy !


Guillaume.

[Moulinaie]

Fantastic news Guillaume and a thank you also from me for supporting the Atari

Many thanks to you!

I found some other interesting systems, but the TOS environment with its 68k CPU is a real pleasure across the years!

Guillaume.

[TXG/MNX]

Is mplayer written in C or pure asm code ?

[Moulinaie]

Is mplayer written in C or pure asm code ?

Hello,

Both M_PLAYER and MP_STE are written in ASM using ASSEMBLE(Brainstorm).
It's a wonderful and fast SDK.
For example, M_PLAYER has a source of more than 800 kB, and some parts are repeated during compilation with some parameters that vary.
On my old TT, it compiles in 10 seconds.

Guillaume.

[uko]

Both M_PLAYER and MP_STE are written in ASM using ASSEMBLE(Brainstorm).

I really enjoyed ASSEMBLE in the old times. It is few mentioned, I wonder if many developers used it.

[Moulinaie]

Both M_PLAYER and MP_STE are written in ASM using ASSEMBLE(Brainstorm).

I really enjoyed ASSEMBLE in the old times. It is few mentioned, I wonder if many developers used it.

It has good capabilities:
- most of the time you don't have to link, a one pass compiler is enough to generate the PRG
- it can output OBJ files for Pure C
- the debug infos is usable with Pure Debugger
- text effects on the source code (opcodes bold, comments grey, etc)
- inline help with the full instruction set
- very fast

Guillaume.

[MM41]

Thanks Guillaume

[dbsys]

Wow, that's incredible. Thank you!

[MegaSTEarian]

Amazing work, thanks!

[Eero Tamminen]

Amazing indeed!

I noticed that it does not support MPEG, but would small MPEG v1 files be light-weight enough?

I have some old Pov-Ray renders which are in that format, for example this:

heart.zip

[viking272]

I have some old Pov-Ray renders which are in that format, for example this: heart.zip

Windows Media Player can't play that mpeg!

WinMedia Heart Error.jpg

[Eero Tamminen]

I noticed that it does not support MPEG, but would small MPEG v1 files be light-weight enough?

I have some old Pov-Ray renders which are in that format, for example this: heart.zip

I tried converting that 160x128 video to many formats with FFmpeg in Debian stable. Of those, three worked in MP_STE:

Code: Select all

$ ffmpeg -i heart.mpg -vcodec qtrle heart.mov
$ ffmpeg -i heart.mpg -vcodec msvideo1 heart.avi  # CRAM
$ ffmpeg -i heart.mpg heart.gif

Sizes:

• MPEG-1: 16 KiB (original)
• MS-Video 1: 27 KiB
• GIF: 56 KiB
• RLE: 500 KiB

Both RLE (mov) and MS-Video1 (avi) formats had bad rendering artifacts in MP_STE though (latter is attached to next posting).

GIF played fine, and supported looping which makes the animation look good (when running STE with Hatari fast-forward). It was hard to get out of that looping though. MP_STE looped multiple times through the video before it reacted to any keyboard or mouse click to interrupt the looping.

PS. What would be the best FFmpeg encoding options to use for MP_STE?

[Eero Tamminen]

Windows Media Player can't play that mpeg!

Not supporting MPEG-1 seems a bit odd, but here's the same file in MS Video 1 format (again zipped so that forum does not reject it):

heart.zip

[viking272]

Ah my deault player is the Microsoft Films and TV player, which can't play MPG/AVI ... However, MS Media Player does work for both the MPG and AVI.
Sorry for bring Windoze into this conversation

[Moulinaie]

Amazing indeed!

I noticed that it does not support MPEG, but would small MPEG v1 files be light-weight enough?

I have some old Pov-Ray renders which are in that format, for example this: heart.zip

Hello !

Thanks for using MP_STE!

Here is what I did :

With M_PLAYER I can open your HEAR.MPG file and turn it into a AVI RLE8.
Then with MP_STE I can convert this AVI into a color FLM that is smoothly replayed by the player. Even on a real STE.

I give you the files...

Guillaume.

[Eero Tamminen]

With M_PLAYER I can open your HEAR.MPG file and turn it into a AVI RLE8.
Then with MP_STE I can convert this AVI into a color FLM that is smoothly replayed by the player. Even on a real STE.

Thanks, they play smooth indeed, and RLE sizes are much smaller than with FFmpeg! (I guess FFmpeg RLE format has too many bits)

That video is supposed to be played with looping. Can M_PLAYER conversion specify that the video should be looped, or could looping option be added to MP_STE?

FLM version also had some odd artifacts on the left side of the video.

[Moulinaie]

Thanks, they play smooth indeed, and RLE sizes are much smaller than with FFmpeg! (I guess FFmpeg RLE format has too many bits)

That video is supposed to be played with looping. Can M_PLAYER conversion specify that the video should be looped, or could looping option be added to MP_STE?

FLM version also had some odd artifacts on the left side of the video.

Maybe FFmpeg FLE is in 24 bits...!

For repetition: on the main panel of MP_STE, you have a "R" button in the upper right corner. If you enable it, then the video repeats.

I didn't see the problems on the left side of the video. Is it with a real STE? An emulator? I'll try o reproduce this.

Guillaume.

[Eero Tamminen]

Maybe FFmpeg FLE is in 24 bits...!

Yeah, that's what I was thinking.

For repetition: on the main panel of MP_STE, you have a "R" button in the upper right corner. If you enable it, then the video repeats.

Ah, that's nice. Looping works fine, thanks!

I didn't see the problems on the left side of the video. Is it with a real STE? An emulator? I'll try o reproduce this.

Latest Hatari Git version. I think it's clearly a video conversion artifact, not related to playback:

grab0001.png

Maybe there's some issue e.g. with M_PLAYER dither matrix content e.g. wrapping in the conversion?

PS. When I tested the repeat / looping option, I did notice something that is a playback issue (rather than conversion one). One every loop, there's a single frame where drawing glitches, the heart shows partly black (it happens when heart is growing, not when the video repeats from beginning). How the glitching frame looks like, can differ a bit, sometimes there's a large black square in the middle of the heart, sometimes lower part of it is missing:

grab0005.png

It looks like Vsync() / page-flipping on a larger update of the image happened at wrong time, before the update was complete.

[Moulinaie]

PS. When I tested the repeat / looping option, I did notice something that is a playback issue (rather than conversion one). One every loop, there's a single frame where drawing glitches, the heart shows partly black (it happens when heart is growing, not when the video repeats from beginning). How the glitching frame looks like, can differ a bit, sometimes there's a large black square in the middle of the heart, sometimes lower part of it is missing:
grab0005.png

It looks like Vsync() / page-flipping on a larger update of the image happened at wrong time, before the update was complete.

When repeating, the buffer is cleared at every start, and sure... I don't use Vsync(), so the screen can be redrawing the lower part as MP_STE is clearing it !

Oops...

Guillaume

[Eero Tamminen]

As STE is unlikely to be able to reach FPS set in the video itself, and even in many videos that is likely to be lower than Atari update freq, I do not think using Vsync would be slowing replay noticeably.