AGABlaster - New CDXL Player Released

[apex]

Originally Posted by movec

Alternatively, when I type agablaster <TAB>, Amiga OS 3.9 brings up a file requester, then I click the file and it plays the video. Not exactly as you describe it, but close.

I did not mean the player. I mean the convert process to get a working video. This must be simplified, then a wide use of your player is sure.

[movec]

Originally Posted by Zarnal

Hello,

I've tried encoding in ham8 a video with Win10/Ubuntu but an error appears only in ham modes (see picture below). In my VM under Linux Mint on same conditions, all is ok ( but its very too slow on my very old PC + VM ). I don't understand. Do you have an idea ? Thank You.

This turned out to be a bit complicated to figure out. However, HAM conversion works in the Win 10 Ubuntu terminal now. You only need to install the additional package xvfb and upgrade to agaconv 0.9.5.4.

[movec]

Hi guys, agaconv 0.9.5.4 (with a few tweaks in the script and ham_convert) is available:

* HAM conversion also works in a Windows 10 Ubuntu Terminal now
* Improved HAM conversion speed with ham_convert 1.6.2 beta

https://mschordan.github.io/amiga/agaconv.html

[thairacerjp]

nice work Markus , I will do a try later, always good to see it's better and better, do you think one day we could have a gui interface ?

[Akiko]

I hope someone can do a tutorial on how to use the converter on Linux otherwise it's probably over my head.

Might there come a GUI for this software sometime?

[Samurai_Crow]

If there's a Linux version I can whip up a GUI in Hollywood for all architectures. It will be big for a simple GUI though.

[BigD]

Originally Posted by apex

This software is impressive, but still a bit to tricky. A one click tool with some temples could make this to a standard player for real Amigas.

This could lead to better FMV in Classic games am I right? Roll up Cypron Studios to allow a port of 'State of War' (sequel to Naplam in all but name) with all the FMV video goodness!

[movec]

Originally Posted by Samurai_Crow

If there's a Linux version I can whip up a GUI in Hollywood for all architectures. It will be big for a simple GUI though.

Hollywood would be interesting because it's cross platform, so that could be a good fit.

Yes, there is a Linux version and it's all open-source.

The AGAConv script uses 3 programs:

• ffmpeg: available for many architectures.
• ham_convert: a java program, only required for HAM conversions (it already comes with a GUI but only for picture conversions).
• agaconv-encode (a C++ program which needs to be compiled for the respective architecture. It does not require any additional libraries.

The Linux version is available on the AGAConv website.
https://mschordan.github.io/amiga/agaconv.html

A MorphOS port is available on aminet (ppc-MorphOS port):
https://aminet.net/package/gfx/conv/AGAConv.lha

[Samurai_Crow]

I'll have to give them a look.

EDIT

FFMPlay is already implemented for Hollywood in the form of the AVCodec plugin. Maybe I could see about converting AGAConv to an Animation Saver plugin for Hollywood also. It would be nice to convert Hollywood presentations to CDXL. That only leaves HAM_Convert. I'll still have to look into that.

EDIT2

HAM_Convert is not open-source or at least I wasn't able to find the Java Source by Googling. It only has the bytecode in the Jar file that I could find.

EDIT3

Hollywood may already have HAM conversion support in its runtime library so maybe it'll work without HAM_Convert.

Update4

SInce Hollywood has Video Loader plugin format but not a Video Saver plugin format, my video outputting visions may have to take a detour. It's still possible to do but no standardized way to do it.

[movec]

Originally Posted by Samurai_Crow

I'll have to give them a look.
FFMPlay is already implemented for Hollywood in the form of the AVCodec plugin. Maybe I could see about converting AGAConv to an Animation Saver plugin for Hollywood also. It would be nice to convert Hollywood presentations to CDXL. That only leaves HAM_Convert. I'll still have to look into that.

agaconv (script) invokes those 3 programs as commands. My idea was that you do the same, but with a GUI, replacing the agaconv script. Hollywood has in it's DOS library an Execute feature. That should allow to replicate the same behavior as agaconv script, just with a GUI? (I only read the docs, no idea if this works).

https://www.hollywood-mal.com/docs/pdf/hollywood.pdf
Section 25.15 Execute

Originally Posted by Samurai_Crow

HAM_Convert is not open-source or at least I wasn't able to find the Java Source by Googling. It only has the bytecode in the Jar file that I could find.

Yes, ham_convert, is freeware but not open-source.
I should have said: everything I wrote is open-source (the agaonv script and aagaconv-encode)

However, ham_convert is optional. For generating AGA videos it's not necessary. So there is a path that is pure open-source.

Originally Posted by Samurai_Crow

Hollywood may already have HAM conversion support in its runtime library so maybe it'll work without HAM_Convert.

That's interesting, but see below.

Originally Posted by Samurai_Crow

SInce Hollywood has Video Loader plugin format but not a Video Saver plugin format, my video outputting visions may have to take a detour. It's still possible to do but no standardized way to do it.

You need to invoke agaconv-encode, otherwise you wouldn't get 24-bit AGA/HAM8 CDXL videos. So if Hollywood's Execute feature works the way I think it does, this could be a way to do it with Hollywood?

[Samurai_Crow]

I guess that's the only way to do it for now. The C++ standard template library is poorly supported on Amiga platforms but it might be only executable on MorphOS, PC, Mac and Linux otherwise. I should first see if it recompiles on Bebbo's GCC 6.5 cross compiler for Classic Amiga architectures.

[gsoravil]

Movec,

I do hope you read this as these are likely very small, easy tweaks that could make a huge difference.

I'm from USA and have been following this project since January (and playing with the tools on and off a lot). First off, TRULY AMAZING WORK! You have brought back a lot of excitement to my A1200.

The version I started on was impressive (0.9.70). The updates you've done this year have been seriously helpful - especially the agaconv updates. Note, as I write this I am up-to-date on both AGABlaster (player) and agaconv (converter).

I have played with both NTSC and PAL playback on both x70 and x71 but in both cases I run into an issue that is much more problematic for me on NTSC -- the video is just too far right on NTSC. I believe this is likely an easy fix for you. Overall I really need just a couple things to make this whole project near perfect to me...some (likely easy to code) additional parameters to AGABlaster (player):

1. Ability to set an actual value/offset for horizontal position. I don't care if it's limited to certain values you need for memory offset (e.g. 0, 32, 64, etc.) I just need SOMETHING.
2. Less important but desired: same thing for vertical (to be fair, the vertical centering you added is close to what I would choose)
3. As important as #1 - PAL command line option. You have an NTSC override but no PAL override (as far as I can tell).

Additionally, I think (long term) you might want to consider some low-hanging fruit like NOFILTER for shutting off the audio filter (and FILTER to turn it back on) and things like that.

I am more than happy to help in any way I can, but these few (assumed to be easy) tweaks would make such a huge difference to me personally that I'd nearly call it "v1.0". If you would like me to give you feedback into ideal values for horizontal offset on NTSC I can do that. I also have access to PVMs for critical assessment if desired.

(On a side-note that is probably more work to fix and I would definitely not worry about is that --MAX-COLORS=4 does not work for me on agaconv, though I'm not sure if anyone really cares. I was just experimenting with various amounts of bit planes. Seriously, I don't care if that's ever fixed. Just pointing it out in case you are tracking any "someday I might fix this" stuff.)

Thank you for all the hard work!!
Greg

[movec]

Originally Posted by gsoravil

Movec,
I'm from USA and have been following this project since January (and playing with the tools on and off a lot). First off, TRULY AMAZING WORK! You have brought back a lot of excitement to my A1200.

Thanks!

Originally Posted by gsoravil

I have played with both NTSC and PAL playback on both x70 and x71 but in both cases I run into an issue that is much more problematic for me on NTSC -- the video is just too far right on NTSC. I believe this is likely an easy fix for you. Overall I really need just a couple things to make this whole project near perfect to me...some (likely easy to code) additional parameters to AGABlaster (player):

How far off is it exactly? I am using it on a PAL and the emulator shows it correctly in NTSC (using NTSC mode in the emulator). What monitor setup are you using?

Originally Posted by gsoravil

1. Ability to set an actual value/offset for horizontal position. I don't care if it's limited to certain values you need for memory offset (e.g. 0, 32, 64, etc.) I just need SOMETHING.

I will look into this. The X-values are actually all precomputed for all 3 graphics modes in a lookup table, but it should be possible to allow to tweak them with an option. However, I am definitely interested what values work for you.

Originally Posted by gsoravil

2. Less important but desired: same thing for vertical (to be fair, the vertical centering you added is close to what I would choose)

There are two options. You can turn centering off, and you can set an absolute Y-offset:

NOCENTER turns off y-centering (it starts at the beginning of the screen then)
YOFFSET=VALUE sets an absolute Y-offset (the value can also be negative)

Both options can be combined.

Originally Posted by gsoravil

3. As important as #1 - PAL command line option. You have an NTSC override but no PAL override (as far as I can tell).

I will add a PAL option in the next version.

Originally Posted by gsoravil

Additionally, I think (long term) you might want to consider some low-hanging fruit like NOFILTER for shutting off the audio filter (and FILTER to turn it back on) and things like that.

What filter? Which filter can be turned on/off and how? The next version will have a mute-button, but I guess you mean something else here?

Originally Posted by gsoravil

I am more than happy to help in any way I can, but these few (assumed to be easy) tweaks would make such a huge difference to me personally that I'd nearly call it "v1.0". If you would like me to give you feedback into ideal values for horizontal offset on NTSC I can do that. I also have access to PVMs for critical assessment if desired.

What's PVM? We may need it though

Originally Posted by gsoravil

(On a side-note that is probably more work to fix and I would definitely not worry about is that --MAX-COLORS=4 does not work for me on agaconv, though I'm not sure if anyone really cares. I was just experimenting with various amounts of bit planes. Seriously, I don't care if that's ever fixed. Just pointing it out in case you are tracking any "someday I might fix this" stuff.)

What exactly do you mean with "not working"? Does it just look bad? It reduces the total number of colors by 2, one color register is reserved for the background color, and an additional one because of a bug in ffmpeg's PNG encoding. Hence, if you specify 4, you actually get only 2 colors.

PS: agaconv-encode already has an option for not using an additional background color, but the script always selects one. I can add this as an option in the script, but such videos will only work on AGA systems then (using the AGA Blank Border feature, which is on by default in agablaster).

[gsoravil]

Originally Posted by movec

Thanks!
How far off is it exactly? I am using it on a PAL and the emulator shows it correctly in NTSC (using NTSC mode in the emulator). What monitor setup are you using?

Mostly I'm using a Commodore 1802 monitor, via an RGB to S-Video adapter but I have the same problem via RGB on multiple Sony PVMs as well as with an LCD and via capture board. In all cases this is with a physical 1200 running in NTSC modes. It is far enough off that I have to max the horizontal control on the monitor to just barely get the right edge of the video on the screen (with still a huge left margin visible).

I posted in the "Bad Apple Amiga Version" thread here on EAB yesterday with a link to a captured video I did (you really should check it out - it's a great showcase for the amazing work you've done). In it you can see how it's skewed right. Please remember that some of the black border that's visible on the capture would be part of the CRT overscan area (i.e. cut off on the CRT). Here's my browser's URL for that thread, hopefully it will work:
http://eab.abime.net/showthread.php?...blaster&page=9
I will cut/paste the post to the end of this reply as well just in case.

Originally Posted by movec

I will look into this. The X-values are actually all precomputed for all 3 graphics modes in a lookup table, but it should be possible to allow to tweak them with an option. However, I am definitely interested what values work for you.

That would be amazing. I am a programmer myself and I am really trying to give feedback that is useful while also hopefully being minimal work to implement.

Originally Posted by movec

There are two options. You can turn centering off, and you can set an absolute Y-offset:

NOCENTER turns off y-centering (it starts at the beginning of the screen then)
YOFFSET=VALUE sets an absolute Y-offset (the value can also be negative)

Both options can be combined.

I must have missed the YOFFSET note. I apologize for that. Thank you.

Originally Posted by movec

I will add a PAL option in the next version.

Thank you!

Originally Posted by movec

What filter? Which filter can be turned on/off and how? The next version will have a mute-button, but I guess you mean something else here?

I am referring to the Paula audio filter. If you check out my Bad Apple video you'll see me use degrader to turn it off before I run agaBlaster.

Originally Posted by movec

What's PVM? We may need it though

PVM is a popular series of Sony broadcast-grade CRT monitors that a lot of people are using for 15KHz display for CRT/TV era sources like consoles and early computers. I picked up most of mine via eBay during US broadcasters' transition from CRT to LCD.

The reason I mention the PVMs is because as broadcast grade they are an ideal reference tool for determining the correct X and Y values according to North American NTSC broadcast standards.

On a side note, the PVMs are also PAL capable - not just NTSC (even though this discussion so far is about NTSC).

Originally Posted by movec

What exactly do you mean with "not working"? Does it just look bad? It reduces the total number of colors by 2, one color register is reserved for the background color, and an additional one because of a bug in ffmpeg's PNG encoding. Hence, if you specify 4, you actually get only 2 colors.

PS: agaconv-encode already has an option for not using an additional background color, but the script always selects one. I can add this as an option in the script, but such videos will only work on AGA systems then (using the AGA Blank Border feature, which is on by default in agablaster).

I did notice that in the docs. This is why I tried four colors (2 bit planes). I am not highly concerned about the last color, but it might be worth considering this option down the road. If I was in your shoes I wouldn't invest time in it at this moment. I would just make a note for "someday, maybe".

What I meant is that if I try to use 4 colors agaconv ends up in error and never does the conversion. I didn't try different modes but the failure was with the palette selection step (ham conversion?) I think. I can revisit this, try more options, and get you better detail (such as "does it have issues in all modes?" and "what step was it at?"). Note I am using the latest tools in all cases. To be honest, I was trying this because I was trying to test out maximum frame rate in SuperHires.

Here's the cut/paste from the "Bad Apple Amiga Version" post I did that showcases AGABlaster:

Originally Posted by gsoravil

I just stumbled across this thread. I was working on this Sunday night. I also was jealous of the Atari ST version. Operative phrase is "was jealous".

First off, for reference I consider this the definitive version to aspire to:
[ Show youtube player ]

With that said, I present my personal solution, Hi-Res (640) mode, full screen, 30fps, 28KHz stereo digi. Captured from real hardware:
[ Show youtube player ]

(Currently "unlisted" but publically accessible. I am friends with Anthony of Guru Meditation and may have him post it to that channel if he's interested.)

It is powered by creative use of the latest of Movec's agaconv/AGABlaster toolchain. TBH, this was an experiment that I didn't expect to work. (At least not at 30fps without dropped frames.) Most notably I reduced it to four bitplanes (16 colors) and if I remember right I used ehb mode.

The fact that this is an extension of using one of Commodore's own patents just puts even more salt on the wounds of their demise. To be fair, there was no way we would have had storage this fast or large in 1992.

I would happily make more videos about the process and my setup if so desired. Questions and feedback welcome (or comment on the YouTube video page itself).

Greg

Thank you Movec!!

[movec]

Originally Posted by gsoravil

Most notably I reduced it to four bitplanes (16 colors) and if I remember right I used ehb mode.

Those experiments are fun to see! If you have large surfaces with the same color, turning off dithering may give a better picture quality (you can try option --ff-dither=none). HAM+EHB conversion always triggers the use of ham_convert, the other modes are using ffmpeg by default.

EHB/HAM6/HAM8 should ignore any color settings (they always use a fixed number of bit planes).

All other modes use a variable number of colors/bitplanes per frame. Hence, parts of a video with a lower color count will also have a lower number of bitplanes/data used.

Also note, Lace is not supported, therefore the maximum height is 256+overscan.

You can use ./agaconv-encode --cdxl-info CDXLFILE to dump the content of the first frame header of a generated cdxl video (I will add to agablaster to print some more of that info as well).

For convenience, Agaconv encodes the frequency into the video. You don't need to set it on the command line for agaconv generated cdxl files - the FR option is mostly there for standard cdxl files which don't have any frequency info.

Regarding speed, in Lores mode you can also hit F2/F3 (this also loads different values into screen registers). It uses a copper effect to duplicate the picture, but it also switches into Hires/SuperHires mode. For that reason this also shows how the higher resolution modes impact FPS while reading the same amount of data from disk.

[gsoravil]

Originally Posted by movec

Those experiments are fun to see!

Thanks! I'm definitely enjoying using and experimenting with these programs!

Originally Posted by movec

If you have large surfaces with the same color, turning off dithering may give a better picture quality (you can try option --ff-dither=none). HAM+EHB conversion always triggers the use of ham_convert, the other modes are using ffmpeg by default.

EHB/HAM6/HAM8 should ignore any color settings (they always use a fixed number of bit planes).

All other modes use a variable number of colors/bitplanes per frame. Hence, parts of a video with a lower color count will also have a lower number of bitplanes/data used.

Also note, Lace is not supported, therefore the maximum height is 256+overscan.

Regarding speed, in Lores mode you can also hit F2/F3 (this also loads different values into screen registers). It uses a copper effect to duplicate the picture, but it also switches into Hires/SuperHires mode. For that reason this also shows how the higher resolution modes impact FPS while reading the same amount of data from disk.

All good points! The HAM vs bitplanes point you make is especially relevant to me. I will spend more time exploring and learning the conversion options.

I've now removed the "480" height reference in my YouTube video description.

I feel inspired by the knowledge on the bitplanes and the vertical resolution. Now I want to re-do some of my attempts.

Originally Posted by movec

You can use ./agaconv-encode --cdxl-info CDXLFILE to dump the content of the first frame header of a generated cdxl video (I will add to agablaster to print some more of that info as well).

I will give that a try. That's a great idea to have the additional stats from agablaster. I ended up using the HAM8 mode mostly due to the results when I initially played around with the various Zoraia samples and liking that one the best at the time. I definitely need to revisit all the encoding options.

Originally Posted by movec

For convenience, Agaconv encodes the frequency into the video. You don't need to set it on the command line for agaconv generated cdxl files - the FR option is mostly there for standard cdxl files which don't have any frequency info.

That's a nice touch and nice to know. I got in the habit of using FR=because initially I only had the Zoraia samples to play with and I was trying to find what my performance limits were. I must have also remembered that old CDXLs needed the parameter.

Clearly I need to re-read all the doc info now that I am using the latest tools as it appears there are several things I had read early on but forgot about.

Thanks for the feedback and help movec!

Greg

[gsoravil]

Hi all!

I don't know how long it will stay up, but I just uploaded to YouTube an OVERSCAN video using AGABlaster with smooth video and high quality audio...

skip to 3 minutes if you want to ignore my rambling...
[ Show youtube player ]

Thoughts anyone? I'm stoked. (I might have another minor feature request for Markus)

Greg

[nikosidis]

That is looking great!! It is just stock A1200 CPU, 68020? It is NTSC?

[TroyWilkins]

Originally Posted by nikosidis

That is looking great!! It is just stock A1200 CPU, 68020? It is NTSC?

I was wondering much the same thing, Fast RAM? CPU upgrade? Or just the standard 2MB Chip RAM and 14MHz 68ec020?

[esel]

Wow Looks great!