MPlayer is an older media player that was never designed to work with modern GPU decoding APIs. It was always decoding video on the CPU, which on a PowerPC machine like the AmigaOne X5000 is quite slow for anything above 720p.
...
Quote:
We modified MPlayer to create a hardware device context through FFmpeg, which opens a connection to the RX580's video decoder. We then patched the video pipeline so that decoded frames stay on the GPU as VA surfaces instead of being copied back to system memory. Finally we connected those GPU surfaces directly to the VA-API video output so the GPU also handles the color conversion and scaling to the screen.
Not sure if that's relevant at all, but you could have updated the FFplay AmigaOS 4.x port instead of the MPlayer port. Both are based in large parts on FFmpeg. FFPlay has much less features for sure compered to MPlayer, but it might have been much be easier to port than MPlayer, especially for the VA-API parts.
FFPLAY/FFMPEG 8.1 has already been fully ported, and I have been working on it for three weeks. Unfortunately, I have failed to get Vaapi running so far. Additionally, FFplay is heavily dependent on SDL2, and our SDL2 cannot handle Vaapi. Therefore, a native output must be implemented here as well. For MPlayer/FFMPEG, many patches and native outputs like CGX, Comp/Compu_yuv2, WPA, and P96_Pipe already exist. For Vaapi in MPlayer, we used the WPA output as a template and added the missing elements, which worked right away. Of course, we now know how it's done and can apply this to FFPLAY/FFMPEG 8.1, but I am still not 100% sure if it will work. There were very large changes between FFMPEG API 7.1 and 8.1 that might make it impossible. For now, I am focusing on what I have with MPlayer and FFMPEG version 7.1. MPlayer/Vaapi is far from finished; the next steps are AHI support and further optimizations. I am also looking at the skin system for a proper user interface. However, the build itself is currently very stable.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
NinjaCyborg wrote:Did you statically link ffmpeg or is it the Emotion version?
It has nothing in common with Emotion or DVPlayer. Emotion/DVPlayer use FFmpeg 4.x, which is now very outdated. In contrast, MPlayer 2026 SVN utilizes FFmpeg 7.1.4.
@all
In the meantime, I have implemented a "fallback" mechanism since not all video formats support VAAPI hardware acceleration (e.g., MPEG). For this, I chose "Comp_Yuv2," which is one of our best native output methods. If a format not supported by VAAPI is called, the fallback takes effect. Also, a quick note: nothing is optimized yet, and there is a lot of debug output, which currently makes it a bit slower.
We got hardware accelerated video decoding working in MPlayer on AmigaOS4 with the Radeon RX580 GPU.
Is the RX580 just the only gfx card it was tested on so far, or is there any reason why it doesn't work on other gfx cards? Both the RadeonHD.chip (maybe V5 only, not V3) and the RadeonRX.chip drivers should support the VA-API (va.library) for most of their supported gfx cards.
At the moment, I have only tested it on an RX580, which is why I specified it that way, but it should work just as well on all RX graphics cards. I am not sure about the HD cards. I don't have any other test systems available, so this needs to be tested.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
We got hardware accelerated video decoding working in MPlayer on AmigaOS4 with the Radeon RX580 GPU.
MPlayer is an older media player that was never designed to work with modern GPU decoding APIs. It was always decoding video on the CPU, which on a PowerPC machine like the AmigaOne X5000 is quite slow for anything above 720p.
The RX580 supports VA-API hardware decoding, which means the GPU can decode H.264 and HEVC video much faster and with far less CPU usage. The challenge was that MPlayer's codebase predates the modern FFmpeg hardware decoding API, so we had to bridge the gap between the two.
We modified MPlayer to create a hardware device context through FFmpeg, which opens a connection to the RX580's video decoder. We then patched the video pipeline so that decoded frames stay on the GPU as VA surfaces instead of being copied back to system memory. Finally we connected those GPU surfaces directly to the VA-API video output so the GPU also handles the color conversion and scaling to the screen.
The result is that 4K H.264 video now plays at around 23% CPU usage on the AmigaOne X5000, where before it would have been completely impossible.
Next up is optimization. There are still some smaller issues to work through, but the biggest hurdle is already behind us.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Does SDL2/3 already support VAAPI on OS4? I'm just asking because I've run into major issues; I've been trying to port FFPlay with the VAAPI SDK for a while now, but everything I've tried has failed.
A new renderer for Vulkan might also be cool; the Vulkan OS4 SDK is available in the OS4Depot.
Thanks anyway for your tireless work on SDL2/3.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
As always, great summary, and thank you very much for it. I’ve missed a lot since I’m really busy right now.
I didn’t know that ScummVM worked well on the A1222+—there weren’t any specific fixes for it, except that I compiled it with Clib4, which might include adjustments for the A1222+.
So, of course, I’m happy to hear this good news. Thanks, buddy.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
I'd be more interested if there are any serious problems that makes it unusable with latest QEMU or if it's any better than the SM502 driver (apart from allowing 32 bit modes).
Here are a few numbers for you: the ATI VGA driver is faster than the SM502 in most areas. That’s certainly a result of the 32-bit mode. Thanks again.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
On a black background/“boot logo,” you can also see it depending on the monitor. The square is gray and the entire background is black. After restarting, you can see the mouse pointer instead of the square. It’s displayed correctly, but it shouldn’t be there. As I mentioned, there’s nothing significant affecting how it works. It’s behaving strangely, which is why I let you know
Thanks for confirming that. Since you're using a different, very bright startup logo, it's clearly visible. It doesn't affect the driver's functionality, but it doesn't match the original and shouldn't be like that.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
balaton wrote:@Maijestro I don't see that even in your screen shot so maybe it's only with host side hw cursor. I think your monitor icon is likely ignored as I found it has to match the driver name so it should be Radeon with CMPLENGTH=6 (I have no idea where 17 came from when you did not even enter that many chars in BOARDNAME). Is your ScreenMode prefs an Enhancer replacement? With the default one 24 bit mode did not show up for me but it as I said it should not be used anyway.
When I look at the screenshot you posted on my computer, you can clearly see the square in the top left corner. When I use my phone, you can’t see it, but trust me, it’s there.
As for the monitor settings, yeah, you might be right—I’ve installed a few enhancer software programs, so the board settings might have been created there. What would happen if I delete the monitor I created? Would AmigaOS 4.1 create a new one on its own when I reboot? You can also see that in the Screen Mode preferences, there’s nothing about ATI-VGA—just the settings for the board.
Otherwise, I could probably copy the original monitor settings for ati from AmigaOS 4.1 Final Edition, which might also work and would match the AmigaOS 4.1 standard.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Tested with Qemu 9.x—I'm not exactly sure which version I'm using. It works very well. The 24-bit mode seems to be a bit broken, but that's not a problem. What we want is 32-bit
Since you tried with older than QEMU 11.0 this does not matter unless you can reproduce with latest QEMU but how did you even test 24bit mode? If a 32bit mode is available it does not even show up for me in ScreenMode prefs, I can only force it by disabling 32 bit. But maybe if you edit the monitor icon and disable DDC and manually add modes you can get that. In any case 24 bit mode does not have fill accelerated (limitation of real ATI VGA too) so it's not recommended to use and 32 bit mode is preferred.
I just double-checked: I'm using Qemu 10.2.1. The only thing I did was replace the ati-vga driver in Kickstart.zip. As for AmigaOS 4.1, I didn't create a new board in Sys:Devs/Monitors/—it was already there and was created by AmigaOS 4.1 itself using the SM501 driver.
The problem, as @smarkusg also describes, also exists on macOS and appears immediately upon booting and in the boot log in the top-left corner.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
balaton wrote:QEMU v11.0.0 is released. I've updated my page (link in signature), see News section where you might find something useful for somebody.
Tested with Qemu 9.x—I'm not exactly sure which version I'm using. It works very well. The 24-bit mode seems to be a bit broken, but that's not a problem. What we want is 32-bit
Great work, my friend
As @smarkusg reports, there’s still an issue with the AmigaOS 4.1 boot logo in the top left corner; it looks like a cursor problem. Still, it’s already very usable for a first version, and I’m very happy that QEMU/PEG2 can finally use 32-bit screens. Great.
P.S. If you need any help testing or further developing this driver, just let me know.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Thank you for your feedback. I was able to fix a few things:
- BUG FIX: Fixed GUI scale crash — switching the scale in full-screen mode no longer causes the “Surface::transBlitFrom: bytesPerPixel must be 1, 2, 4” error and program termination (3bpp surfaces are now correctly converted to 32-bit)
- BUG FIX: GUI Scale default set to 100% on first launch — GUI is now fully functional on first start without a config file
- BUG FIX: False “Unknown Level 9 game or version” detection fixed — games like Necronomicon no longer show a spurious Level 9 entry in the game list. The root cause was a logic error in the Level 9 scanner (present in all ScummVM platforms) which has been corrected.
And don’t worry about the first launch—it’s intended to work this way. ScummVM starts up very quickly the first time and then creates the paths, so you should simply configure your GUI settings on the first launch. Close ScummVM, restart it, and then add your games. However, I can also fix this problem very easily by passing a .ini file to ScummVM with a minimal configuration. You can also copy your own saved ScummVM.ini file into the Progdir directory before the first start; that should work as well, and you won’t have to let ScummVM re-read everything from scratch.
The new build is already available in the upload on os4depot, feel free to test it.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Thanks to @smarkusg for providing me with the source code for Fliudsynth-Sans-Glib, I immediately implemented it to ScummVM, and yes, it works great with the right soundfont.
You’ll like it, and on my X5000 and another beta tester, it works really well without putting a heavy load on the CPU for ScummVM. I’m trying to finish the final build of ScummVM 2026.2.0 this weekend.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Thanks for the feedback. With the next upcoming version, Might and Magic 1 should now work for you as well; the MM/MM1 and XEEN plugins are already included, but only XEEN was enabled—I’ve now done the same with the MM Engine.
Massive optimizations were made for 2.0, including font and GUI caching; I removed many incorrectly set paths, and in some cases, searches were performed in different locations, with everything being scanned and loaded multiple times, which unnecessarily slowed down startup. A side effect of this is that ScummVM now needs to be started once during the first use; here, you simply set your desired GUI settings. Close ScummVM and restart it; from then on, everything will be found correctly and can be used.
"Unknown Level 9 game or version (v3)"
I'm not quite sure what it is yet, and yes, I've come across it before, but I suspect it only happens when you don't use the original game files. I'll look into it further, but the games can still be played.
This weekend, I'll release an updated version that includes native CAMD support via Camd.library for the MT32 as a device.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Swisso wrote:@Maijestro thankyou for v6.2.0 your work is much appreciated. i have noticed a couple of differences from your previous version, Mass ad doesnt appear to find any files at all and the pointer for workbench does not reappear after clicking on windowed game. is this a configuration issue? because previous version did not have this prob.
Start ScummVM once to initialize everything, then close ScummVM. From now on, you can use ScummVM normally and add your games.
You can release the mouse pointer with CTRL + M; (PC Keyboard)it should only be locked within the engines.
Please also read the attached README file.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
ScummVM fullscreen window opens behind the Workbench. Root cause:
SDL2 opens the window with WFLG_BACKDROP on the WB screen when running at desktop resolution (1920x1080). Backdrop windows are always behind all other windows by design. The AmigaOS4 compositor ignores all attempts to bring the window to front.
What we tried: SDL_RaiseWindow ignored by compositor. SDL_AMIGAOS4_FORCE_FRONT 1 sets 1920x1080 but stays behind. IIntuition->ScreenToFront after SDL_SetWindowFullscreen (Path B) never reached. IIntuition->ScreenToFront after SDL_CreateWindow (Path A) crashes. WA_StayTop via engineInit() crashes, and SDL2 source confirms it cannot be set after window creation. strings on original lib shows no FORCE_FRONT or ScreenToFront.
The following was used original SDK lib: libSDL2-2.30_gl4es.so (4.3MB) from /opt/ppc-amigaos/ppc-amigaos/SDK/local/clib4/lib/ — this contains gl4es and is the only one that makes OpenGL work correctly.
Nothing is working. ScummVM does go into full-screen mode, but it always stays behind the Workbench. I can see this clearly because I can bring everything back to the front using ALT + N. I've been stuck on this for three days now and just can't seem to find a solution. If there's anything else I can try, please let me know.
Edited by Maijestro on 2026/4/6 18:07:32
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
The Ultima plugin still doesn't work for Ultima VI. The Raziel version did and the plugin is a larger size. Just seems a bit strange that the newer version appears to be half the size and doesn't work. (No suitable plugin found)
Could never get Eye of The Beholder to work on the older version but could Eye of The Beholder II.
Neither work on this latest version. EOBI not recognised when trying to add it and EOBII is added but again, no suitable plugin found.
Cheers
I'll upload the new build in 1–2 days; it includes a lot of improvements, and yes, Ultima and Ultima 8 will work as well. I've also added the EOB engine, but I've had to retest it. Please be patient a little longer.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
