AGABlaster - New CDXL Player Released

[mfilos]

Don't get me wrong mate! I really LOVE AGABlaster and I know it doesn't offer any compression which is totally fine.
It's just like using an avi file compared with an divx :P

Thanks for your work mate. It's gladly appreciated

[movec]

Overscan Update for AGAConv and AGABlaster released

AGAConv 1.0.2 released
- generates overscan videos for 384, 704, and 1344 width.
- fixed Hires/Superhires flag in auto screen-mode
AGAConv website: https://cutt.ly/AGAConv

AGABlaster 0.9.92 released
- Supports overscan for 384, 704, 1344 width.
- Improved error reporting for some unsupported combinations of resolution and FMODE in hires/superhires modes
AGABlaster website: https://cutt.ly/AGABlaster

[sovenyimre]

Hello.
I have similar interests using videos in Amiga. I have created a simple program that can be used to reduce the final size of videos considerably and is not too complicated. Lossy but not compressed. Combined with Agablasterr+ham converter, the result would be wonderful. I also released the code.

[movec]

Originally Posted by sovenyimre

Hello.
I have similar interests using videos in Amiga. I have created a simple program that can be used to reduce the final size of videos considerably and is not too complicated. Lossy but not compressed. Combined with Agablasterr+ham converter, the result would be wonderful. I also released the code.

Are you referring to your Amos Anim Player?

[sovenyimre]

Originally Posted by movec

Are you referring to your Amos Anim Player?

Yes, that would be the one... But not the player... The Reducer program.
I've always been interested in how these things work, but at the code level, I got stuck in Amos, so my resources are quite limited.... so I make my own fun by just manipulating the images, as this is how I can help achieve my goal.
Not easy to handle Ham6 in that way but that is the one ECS can display and the logic is simple and it could be used in different modes , on lower or higher bitplanes too.
Thought I'd point this out so others could use it too. Compared to cdxl videos, the delta code of anim5 reduces the amount of data by half on average, which with my own programs help to go down a further halves (and quality is still good enough), so even weaker machines would be able to read such a small amount of data. I thought that if Amos could almost capable with this task, it could also be an incentive for the number of experts at a higher level.

[movec]

Originally Posted by sovenyimre

Yes, that would be the one... But not the player... The Reducer program.
I've always been interested in how these things work, but at the code level, I got stuck in Amos, so my resources are quite limited.... so I make my own fun by just manipulating the images, as this is how I can help achieve my goal.
Not easy to handle Ham6 in that way but that is the one ECS can display and the logic is simple and it could be used in different modes , on lower or higher bitplanes too.
Thought I'd point this out so others could use it too. Compared to cdxl videos, the delta code of anim5 reduces the amount of data by half on average, which with my own programs help to go down a further halves (and quality is still good enough), so even weaker machines would be able to read such a small amount of data. I thought that if Amos could almost capable with this task, it could also be an incentive for the number of experts at a higher level.

I originally used Anim files. The very first video in the AGABlaster youtube channel is an anim7 video [ Show youtube player ]
Anim files support 24-bit AGA colors out of the box, that's why I started with those. Agaconv was originally an anim-edit tool (e.g. for injecting the DPAN chunk and setting the playrate in the anim file). Nice to see you are having fun with Anim files!

AGABlaster adapts to the speed of an Amiga system by skipping frames on disk. This way it gets the best possible framerate on a given system. It should never stutter, and keep a steady (possibly lowered) framerate. This is straight-forward with CDXL files, but with Anim files this is not possible in this way because all frames are delta encoded with respect to the previous frame. That's why AGABlaster became a CDXL player (also allowing to jump forward/backward 10 secs in the video etc.)

[movec]

Hello everyone,

AGAConv 1.0.3 released
- bugfix for OCS 12-bit color palette
- changed --std-cdxl option to keep 24-bit color palette with AGA color modes.

AGAConv website: https://cutt.ly/AGAConv

Cheers!

[SusiTerry]

I have an Amiga 3000 with Workbench 3.1 and whenever I play anything the picture is corrupted.
I have no GPU or accelerator board and I used the latest version.

I used these settings:

sudo ./agaconv.sh nyancat.mp4 nyancat.cdxl --fps=12 --color-mode=ham6 --width=360 --audio-mode=mono --frequency=11025 --std-cdxl --dither=none

[ Show youtube player ]

[movec]

Originally Posted by SusiTerry

I have an Amiga 3000 with Workbench 3.1 and whenever I play anything the picture is corrupted.
I have no GPU or accelerator board and I used the latest version.

I used these settings:

sudo ./agaconv.sh nyancat.mp4 nyancat.cdxl --fps=12 --color-mode=ham6 --width=360 --audio-mode=mono --frequency=11025 --std-cdxl --dither=none

[ Show youtube player ]

Thanks for providing the video. This looks like the OCS issue.

This problem is fixed in the latest version 1.0.3, just upgrade to the latest version 1.0.3, and this should work.

From your command line it looks like you are using a very old version with the agaconv.sh bash script, 0.9.7? The newest version is a single executable, there is no separate script anymore.
run: agaconv --version (this should print "agaconv version 1.0.3") if you have the newest version installed.

Go to https://cutt.ly/AGAConv and follow the instructions on how to install the newest AGAConv version.

[SusiTerry]

updated it, still all messed up. do I update/reinstall anything on the amiga?

[movec]

Originally Posted by SusiTerry

updated it, still all messed up. do I update/reinstall anything on the amiga?

when you run on the amiga "agablaster version"
what does it print?

[emiespo]

Hi, I'm also having an issue with AgaConv, it seems that conversions to standard CDXL always fail (version is 1.0.3, I managed to compile it under MacOS after tweaking a couple of things).

With the video from the examples in the docs, I get this error (the same error also happens with another video I was actually trying to convert):

agaconv testvideo.mp4 testvideo.cdxl --std-cdxl --width=1920 --frequency=11025 --audio-mode=mono --screen-mode=unspecified
Adjusted frequency from 11025 to 10944 (Standard CDXL).
Conversion started.
Converting video file "testvideo.mp4"
Running external tool ffmpeg (extracting audio data)
Running external tool ffmpeg (extracting frames as PNG files)
Running internal CDXL encoder (fps: 24, frequency:10944, audio mode: mono)
Error 101: Standard CDXL: frame size of 2074853 is not 32bit aligned. This can reduce I/O speed by up to 50%. Not generating CDXL file.
Suggestion: slightly adjust video video aspect with --adjust-aspect=1.01. Alternatively, do not use option --std-cdxl, custom CDXL uses 32bit padding to avoid this problem.
Exiting.

Tried with --adjust-aspect=1.01 - different frame size, but still resulting as an odd number, so failing.

Any ideas? Not using --std-cdxl seems to work, but I need something compatible with OCS

EDIT: I also tried on a Linux box, where it compiled without the need for any tweaks (simil-Debian distro), and get the same error.

[Samurai_Crow]

As an aside, with a width of 1920, I don't think AGA could handle it. What scan rate and horizontal sync is needed?

By the way, the sound frequency could also be a culprit. You need an even number of samples per frame.

Edit:
Other ideas involve the fact that the maximum auto-scrolling resolution on OCS is 1024 and you run out of Chip RAM long before that.

HAM mode doesn't support resolutions higher than 320+overscan on screen nor does extra halfbrite mode on OCS.

High resolutions of 640+overscan run at a maximum palette depth of 16 colors (or greyscales) on OCS.

Why OCS?

[emiespo]

Originally Posted by Samurai_Crow

As an aside, with a width of 1920, I don't think AGA could handle it. What scan rate and horizontal sync is needed?

That's not for AGA, it's in the official docs as a test video that can be converted and played back on a PC (VLC handles cdxl video - not audio though, ffplay apparently handles both, but I haven't tried it).

Originally Posted by Samurai_Crow

By the way, the sound frequency could also be a culprit. You need an even number of samples per frame.

The video that I am trying to convert, which is not the test one in full-hd, worked perfectly in HAM6 (although I had to download hamconv for it). To me it looks more like a bug, don't see why the content wouldn't just be padded nor how could it not be an even number (the resolution used is 320, which is 4 times 4 times 4 times 5 alone, stereo audio also uses 2 8-bit samples, so no way the data used for one frame should come back as an odd number of bytes).

Originally Posted by Samurai_Crow

Edit:
Other ideas involve the fact that the maximum auto-scrolling resolution on OCS is 1024 and you run out of Chip RAM long before that.

Why OCS?

I was just reporting an issue and to do so I used the example provided on the official website, scroll down to where it says ffmpeg's ffplay CDXL mode (on multiple platforms)

Why OCS? I'm writing a CDXL engine for games.
As a personal challenge I'm using OCS + 1.3 to see whether the OS can handle it (spoiler: it can, but syncing audio/video is a bit of a challenge and I might just bang the hardware more)

The video I'm interested in, is being converted at 320 x 240, 12fps and a frequency of 11025. As mentioned this works very well with HAM, so I was simply reporting a small issue.

@movec: I have fixed a few issues here and there and added basic support for Mac OS X, I'm happy to make a fork on Github and raise a merge-request (before I do this, I quickly had to add a CC flag to the makefile that I might want to fix properly).

[movec]

Originally Posted by emiespo

Hi, I'm also having an issue with AgaConv, it seems that conversions to standard CDXL always fail (version is 1.0.3, I managed to compile it under MacOS after tweaking a couple of things).

With the video from the examples in the docs, I get this error (the same error also happens with another video I was actually trying to convert):

agaconv testvideo.mp4 testvideo.cdxl --std-cdxl --width=1920 --frequency=11025 --audio-mode=mono --screen-mode=unspecified
Adjusted frequency from 11025 to 10944 (Standard CDXL).
Conversion started.
Converting video file "testvideo.mp4"
Running external tool ffmpeg (extracting audio data)
Running external tool ffmpeg (extracting frames as PNG files)
Running internal CDXL encoder (fps: 24, frequency:10944, audio mode: mono)
Error 101: Standard CDXL: frame size of 2074853 is not 32bit aligned. This can reduce I/O speed by up to 50%. Not generating CDXL file.
Suggestion: slightly adjust video video aspect with --adjust-aspect=1.01. Alternatively, do not use option --std-cdxl, custom CDXL uses 32bit padding to avoid this problem.
Exiting.

Tried with --adjust-aspect=1.01 - different frame size, but still resulting as an odd number, so failing.

Any ideas? Not using --std-cdxl seems to work, but I need something compatible with OCS

EDIT: I also tried on a Linux box, where it compiled without the need for any tweaks (simil-Debian distro), and get the same error.

The instructions say: don't use option --std-cdxl. This is the best solution. It has nothing to do with OCS or AGA, it simply properly pads the frames and it might create frames of different size, but that's OK and agablaster can handle it. The 32bit alignment is to ensure proper speed of IO devices (which may or may not be beneficial on your system).


In general, the --std-cdxl option is a backward compatibility option for older CDXL players that can only handle frames of equal size. That's actually not a limitation of CDXL but a limitation of older players. AGABlaster can play CDXL files with any frame size, which allows for reduced CDXL size in cases where frames require less planes, a simple form of compression.

[movec]

Originally Posted by emiespo

The video that I am trying to convert, which is not the test one in full-hd, worked perfectly in HAM6 (although I had to download hamconv for it). To me it looks more like a bug, don't see why the content wouldn't just be padded nor how could it not be an even number (the resolution used is 320, which is 4 times 4 times 4 times 5 alone, stereo audio also uses 2 8-bit samples, so no way the data used for one frame should come back as an odd number of bytes).

As the output shows, the selected audio mode is 'mono', however, that's not the issue. AGABlaster adjusts the frequency to ensure even sized chunks, but this doesn't mean it's also 32bit aligned (a multiple of 4). The error message is correct.
Note that --std-cdxl chooses 'mono' audio mode. Simply don't use the option, then all adjustments are done to get best possible performance and minimum data size (by removing empty planes) and stereo is also default.

Originally Posted by emiespo

@movec: I have fixed a few issues here and there and added basic support for Mac OS X, I'm happy to make a fork on Github and raise a merge-request (before I do this, I quickly had to add a CC flag to the makefile that I might want to fix properly).

The code is pure C++17. There should be no issues to fix. If you find issues, please report them as bugs.

Changes required to compile on Mac OS X are probably best done in a separate makefile. Note that there is a "OSLayer" class. This could be implemented for OSX to store the default config file in the right location on OSX, but the provided version is sufficient for user-defined config files also on MacOS X (and any other OS).

[movec]

Originally Posted by emiespo

Hi, I'm also having an issue with AgaConv, it seems that conversions to standard CDXL always fail (version is 1.0.3, I managed to compile it under MacOS after tweaking a couple of things).

With the video from the examples in the docs, I get this error (the same error also happens with another video I was actually trying to convert):

You are right, there is indeed a bug! --std-cdxl does not set an internal flag to fill up the color palette. There exists a command line flag to explicitly set this internal flag (see below).

agaconv testvideo.mp4 testvideo.cdxl --std-cdxl --width=1920 --frequency=11025 --audio-mode=mono --screen-mode=unspecified
--force-color-depth=12 --fixed-planes

This is the command that you used but with two added options:
--force-color-depth=12 is necessary to get 12-bit colors (by default it generates 24 bit colors when --screen-mode=unspecified. Otherwise this option is not necessary).
--fixed-planes (that's the temporary workaround option, because --std-cdxl should set this flag).

I will release an update soon, until then if you want to use the --std-cdxl option you also need to add --fixed-planes. Without option --std-cdxl you get an (optimized) custom CDXL file that AGABlaster can also play.

[Glen M]

Quick question, I've not used AGABlaster for a while but encoded a few new music videos using agaconv, downloaded the latest AGABlaster and while the video plays and looks great, the audio occasionally sounds as if its doubled up, like there is a weird echo in it.

I didn't run agaconv with any switches just agaconv video.mp4 video.cdxl. Is there any simple way to fix this rather than recoding everything?

[movec]

Originally Posted by Glen M

Quick question, I've not used AGABlaster for a while but encoded a few new music videos using agaconv, downloaded the latest AGABlaster and while the video plays and looks great, the audio occasionally sounds as if its doubled up, like there is a weird echo in it.

I didn't run agaconv with any switches just agaconv video.mp4 video.cdxl. Is there any simple way to fix this rather than recoding everything?

I have never heard of such an audio echo effect. That's actually not easy to produce.

Does this remain if you mute and unmute the video? m-key
Does this remain if you turn the hardware filter on/off? f-key
Do you get this behavior on a real Amiga or in an emulator? Can you upload one of those videos somewhere such that I can try to reproduce this effect?

[emiespo]

Originally Posted by movec

You are right, there is indeed a bug! --std-cdxl does not set an internal flag to fill up the color palette. There exists a command line flag to explicitly set this internal flag (see below).

agaconv testvideo.mp4 testvideo.cdxl --std-cdxl --width=1920 --frequency=11025 --audio-mode=mono --screen-mode=unspecified
--force-color-depth=12 --fixed-planes

This is the command that you used but with two added options:
--force-color-depth=12 is necessary to get 12-bit colors (by default it generates 24 bit colors when --screen-mode=unspecified. Otherwise this option is not necessary).
--fixed-planes (that's the temporary workaround option, because --std-cdxl should set this flag).

I will release an update soon, until then if you want to use the --std-cdxl option you also need to add --fixed-planes. Without option --std-cdxl you get an (optimized) custom CDXL file that AGABlaster can also play.

Hi! Sorry missed updates on this thread. That makes sense, I was really wondering how it could've made odd length frames

As I said, I'm writing my own CDXL engine to both understand how it works, and make games out of it. Once it will be in a decent state, I plan to release it as open-source, so other people can possibly make / port more games to the Amiga. There's a Java UI that allows to define the boring bits of logic / moves, etc.

So I can certainly cope with custom CDXLs, although initially to be sure my player was behaving correctly I was also testing with standard CDXLs found online.

My ultimate goal is to also add some RLE compression to the format, as with good quality and 12fps, it goes well beyond the DMA capacity of a CDTV (or even a CD32, but on a 68020 the CPU should be able to compensate). I think using optimised asm, a 68000 with fast-ram should be able to cope with it.

For now happy to have async.io and leverage on the DMA of a standard SCSI controller. The target machine is OCS 68000 + some DMA controller (~ 600kb/sec in chip-memory for a 320x200xham6 screen).

Second topic: in order to compile Agaconv on MacOS, I had to add a OSLayer class for it + fix a couple of minor things (compiler on MacOS was complaining about missing includes). Will try to make a patch / bug / merge request next week if I got time.

Cheers
Thanks!