AGABlaster - New CDXL Player Released

[movec]

Originally Posted by Nobby_UK

Could only get one CDXL to play properly:
= moveback3.xl on Demo1_1r72

The rest either show half screen (interlaced ?)
with very slow sound or just give error messages

Regarding the speed: the videos might be encoded with a higher audio frequency than the usual default. Just set a higher frequency, e.g. FR=20000
Then it will play faster. You need to guess what it is because this info isn't in the video.

Regarding the half screen: maybe it's a Hires video? Use the additional option HIRES. This will switch AGABlaster into Hires mode.

Regarding the failing ones, I looked through your screen shots:
The first one is a HAM8 video. That's not a standard CDXL, that's some extension, therefore this doesn't work. And there are 1820 bytes that aren't necessary, therefore it's reported as inconsistent.
The 3rd one is a HAM6 but there are 24 bytes more than necessary.
None of these videos are standard CDXL videos.

They might have used some rules for padding each frame (and I could add support for this), but I need some frames of those videos. I don't know where the padding actually is.

If you chop off the first 200K (about 10 frames), and make them available I could look into it (the last frame can be incomplete). The reported numbers all make sense, but in each frame of them are some additional unnecessary bytes it seems.

[iXien]

Originally Posted by movec

Add the following option: FMODE=0
Does this work? You will see a message on the screen after exiting the player.
Which message do you see without this additional option?

Video works with the FMODE=0 option

Sadly, it's too slow on a 68000/7Mhz and crashes after the first minute (maybe a buffer problem?)

[Nobby_UK]

FR=25000 sounds OK
HIRES is OK if only quarter screen

FYI... the XL Script for it is:
CD0:c/cdgsxl CD0:kak.cdxl sdbl ham dosxl blit xlspeed 150 multipal lmbabort nopointer lores patchopenwb

[movec]

Originally Posted by iXien

Video works with the FMODE=0 option

Sadly, it's too slow on a 68000/7Mhz and crashes after the first minute (maybe a buffer problem?)

Are you aware of any other cdxl player that can play this video on your Amiga? Which Amiga is it? How much chip memory?

What do you mean with "too slow"? I would expect a 68000 to be way too slow, but does the sound play ok? I don't know the video, you may need to specify a higher frequency with FR=15000 (or whatever sounds right).

[iXien]

Originally Posted by movec

Are you aware of any other cdxl player that can play this video on your Amiga? Which Amiga is it? How much chip memory?

What do you mean with "too slow"? I would expect a 68000 to be way too slow, but does the sound play ok? I don't know the video, you may need to specify a higher frequency with FR=15000 (or whatever sounds right).

As I mentionned previously, my config : 68000/7Mhz, 2Mb Chip-RAM, 8Mb Fast-RAM, Full-ECS, KS2.04, Workbench 2.10, 32Gb Compact Flash PFS3DS formatted. The partition used to play the file can read up to 3,7Mb/s

To be honest, as your player is called AGA-player, it's the last one I tried on an ECS Amiga All the other ones need 68020 and at least KS3.0.

Using HV format playing files with HAMNew.run, I can play videos up to 320x240/12fps with sound 22050hz/Stereo/8bits without any glitsch.

But as CDXL was created for the CDTV, I was expecting to easily play CDXL files in a third of the screen. Maybe there are two much fps in this AB Tower Assault intro conversion?

To answer your question, sound is good. When I say it's slow, it was not the good word, maybe better to say it twitches to maintain synchronized sound and video and after 30 seconds or at best one minute, it freezes.

[jotd]

I converted a mp4 to a 256-wide video 256 colors 12 fps. With the emulator it's really good, but on real CD32 hardware from CD it freezes after a few frames. Probably CD access which is too slow (2x).

[movec]

Originally Posted by jotd

I converted a mp4 to a 256-wide video 256 colors 12 fps. With the emulator it's really good, but on real CD32 hardware from CD it freezes after a few frames. Probably CD access which is too slow (2x).

With a 2x CD-ROM you have 300 KB/s max. If you have 256x204 (with 8 planes), then one video frame has 52224 bytes, with 12 FPS you need 626688/s, but you only have 300 KB, hence at best you can get around 5 FPS (+ sound).

Try the following additional options: FB=15 CFD=12 STATS
It should "run" then and show the FPS.

[movec]

Originally Posted by iXien

As I mentionned previously, my config : 68000/7Mhz, 2Mb Chip-RAM, 8Mb Fast-RAM, Full-ECS, KS2.04, Workbench 2.10, 32Gb Compact Flash PFS3DS formatted. The partition used to play the file can read up to 3,7Mb/s

To be honest, as your player is called AGA-player, it's the last one I tried on an ECS Amiga All the other ones need 68020 and at least KS3.0.

Using HV format playing files with HAMNew.run, I can play videos up to 320x240/12fps with sound 22050hz/Stereo/8bits without any glitsch.

But as CDXL was created for the CDTV, I was expecting to easily play CDXL files in a third of the screen. Maybe there are two much fps in this AB Tower Assault intro conversion?

To answer your question, sound is good. When I say it's slow, it was not the good word, maybe better to say it twitches to maintain synchronized sound and video and after 30 seconds or at best one minute, it freezes.

Use the additional options: FMODE=0 FB=15 CFD=12 STATS, it should work then. What FPS does it report?

[amigang]

nice to see

[jotd]

I ended up with 8fps and 64 colors. Works fine on the real machine, since it respects the famous 300kb/s thanks for this solution (I encoded the video using the new encoder on Windows / Ubuntu subsystem)

[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.

[movec]

Originally Posted by jotd

I ended up with 8fps and 64 colors. Works fine on the real machine, since it respects the famous 300kb/s thanks for this solution (I encoded the video using the new encoder on Windows / Ubuntu subsystem)

You are the very first one running it on a stock CD32 I am aware of, so that's good to know. With 64 colors you are using 6 planes. With half the height (assuming I add y-upscaling, to duplicate each line) you would get around 16 fps (with your video), and then adding 2 more planes to get 256 colors could give around 12-13 fps I guess. Alternatively you could also try another width, but more colors. A width of 128,192,256,320 gives the best frame rate on a CD32 (and any other AGA system).
Did you use any of the additional command line options?

[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.

Since it runs on one of your machines, but not the other, there seems to be something different with the installations.

After ffmpeg has been run (that's the very first step) there have to be png files in the created working (=temp) directory. Are there png files in this directory? It starts with prefix "tmp-"...
If there are no png files, then there is nothing to do for ham_convert, and then agaconv cannot find any iff files (which is the error message you get).

You may also want to check that Java is installed and that ham_convert can be run (it's in the installation instructions for 0.9.5 but was not required for 0.9.4 and is only relevant for ham conversions). But if it's missing this should create an error message.

There are 3 lines with EXECUTING: ... Those are the 3 invocations of the tools. You can also copy&paste each of them and rerun each stage manually.

HAM conversion: After ffmpeg is run, you should see the png files. After ham_convert is run you should see the iff files. And after agaconv_encode is run, you should see the CDXL file.
Default AGA8 conversion: After ffmpeg is run you should see the png files, and then it directly invokes agaconv_encode to generate the CDXL file.

The HAM conversion takes a lot longer, but it benefits from parallelism, the more cores you have the faster it is.

Note that if the conversion succeeds it will remove all intermediate files. If you want to keep all the png/iff files then use option --no-cleanup.
If an error occurs then the tmp directory is not removed.

[nikosidis]

Thank you for this I converted a couple of videos with Linux, Peppermint. Plays nice on my 68030.

[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.

[nikosidis]

About AutoCropy. I tried it and I was thinking it removed the black bars so the video became 4:3 but I guess it is not for that? Looking at the files after using it I think it went from 1920*1080 to 1920*1072

[movec]

Originally Posted by nikosidis

Thank you for this I converted a couple of videos with Linux, Peppermint. Plays nice on my 68030.

Awesome!

[movec]

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.

Isn't it possible to configure Amiga OS to click a file and invoke an application with the selected file as argument?


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.

[movec]

Originally Posted by nikosidis

About AutoCropy. I tried it and I was thinking it removed the black bars so the video became 4:3 but I guess it is not for that? Looking at the files after using it I think it went from 1920*1080 to 1920*1072

It did exactly what it's supposed to do, it crops the top/bottom black bars (it doesn't crop anything left/right). In your case only a super-tiny one of 4 at top and 4 at the bottom (I guess). The top/bottom black bars come with many videos that have top/bottom black stripes/bars because the original video has a different aspect ratio.

Cropping left/right bars can be done as well, but are those black in your video? However, the following line should do that:
ffmpeg -i MYVIDEO.mp4 -filter:v "crop=in_w-484:1080" -c:a copy MY_CROPPED_VIDEO.mp4
This crops it to 1436x1080.

That's a fixed crop size. In contrast, the trick with autocropy is that it automatically figures out the height of those black bars at top and bottom (they can be different depending on the original video's aspect ratio) and removes them.

Note there is also the agaconv option --scale-factor=NUM. This allows to adjust the video aspect ratio, such that it displays correctly on your respective monitor setup. If it doesn't look "too wrong" don't mind, but if the height appears too small, that's the easiest way to adjust it. It keeps the width (option --width) fixed and scales the y-axis to meet the provided scale-factor.

[nikosidis]

movec: Thank you for the explanation and the job you are doing on this.