@ddni

Not my style..but thanks

I tested V-Mplayer (on X1000+RadeonHD), the first video I tested worked nicely, there was some slow downs occasionally. But then I tested another video and that had grey window/screen consuming the most of the CPU. The debug output was flooded with:

RadeonHD (0): Wait done 3331562 on ring 3 timed out. GPU busy
RadeonHD (0): Ring 3 hung. Performing a GPU reset
RadeonHD (0): Wait done 3333921 on ring 3 timed out. GPU busy
RadeonHD (0): Wait done 3333921 on ring 3 timed out. GPU busy
... (endlessly)

I put a NVMe card/device to the X1000 but boot process hang after displaying some RadeonHD info (on debug). I booted also on another partition which has that device driver made the other guy some time ago and the same result, the boot process hangs.

Sorry no, but order off Amazon and return if no good?

@LyleHaze

Thanks for the basic info!
I checked on line and there are so many adaptors to guess from..

Any more hints to a name that has been tested working?

Thanks in advance,

Michael

@pjs
Quote:"Only" 2 branches is still much better than it used to be
When I was still working on MPlayer there were at least 4 different branches: afxgroup MPlayer, liveforit MPlayer, mickjt MPlayer any my MPlayer versions (mostly "amiga" and "p96_pip" VO implementation/changes only), not to mention completely different ones like the MorphOS port (most of a MorphOS CGFX VO can run with the P96 CGFX emulation on AmigaOS as well)...
AFAIK everything from the previous 4, or more, AmigaOS MPlayer versions/ports was merged into a single one in the current MPlayer 1.5 port, and combining everything from MPlayer 1.5 and V-MPlayer into a single version would be a good idea, but only after everything was tested successfully and there are no regressions at all. That requires a lot of beta testing.
Using AI can make coding much easier, but until now IHMO it still adds more bugs than experienced human developers would usually do, and therefore needs more proof reading of the sources and beta testing than traditional software development required.

@afxgroup
Quote:In case there are GCC distributions with missing "specs" file (why?) you can use, store it (the internal defaults of the GCC executable you are using) to the appropriate path (sorry, I don't remember where it is, or should be, and it might be a different path in different versions of GCC) and use that as a start:
You can change anything there you want, add additional C libraries, change the default C library, etc.

@ktaddQuote:

https://github.com/Maijestro/mplayer/releases/tag/v306-beta

Fixed subtitle rendering: libass video filter (vf_ass) now correctly included
Fixed -vo option being ignored when VAAPI was active
Fixed font path resolution on AmigaOS4 (PROGDIR: prefix)
Software video outputs (comp_yuv, comp_yuv2, cgx_wpa) now correctly disable VAAPI hwdec

Note: A valid subfont.ttf must be placed in the conf directory of V-MPlayer.

@all

Just a quick update on where V-MPlayer is heading.

We are gradually bringing all the features that are present in MPlayer 1.5 into V-MPlayer. Everything will always be released together as a combined package, because there are also users who love the Hollywood GUI — and that GUI has been significantly extended and optimized.

Window resizing now works the way you would expect it to, with the content scaling natively. Fonts are now rendered via the GPU which looks much better. Some animations that ran after startup have been removed and are now static. On my X5000 the GUI uses only 1-2% CPU at idle and feels very smooth.

More updates to follow — please keep testing and reporting!

@Gregor


gpt partition table is not supported by mounter.library.kmod

as far as I know.. its only RDB and MBR, unless gpt is handled internally in driver, this won't work..

clearly a system wide implementation is far better, then a per driver implementation. is not gpt made for bitlocker?

@samo79
Quote:
I'm available for testing.

Double post, plz remove

@smarkusg

Of course, I'm currently abroad and can't do any meaningful test, but nothing stops us from trying to recompile our release with VAAPI

@Maijestro
Quote:
I was able to verify that -vo option does not work on my X1000 with an HD7750 graphics card. I sent you an email with a verbose log that show it recognized the -vo comp_yuv command on the command line but still tried to use the vaapi driver.

@walkero

Thanks for the update!

Hello everyone!

Now it's published... my first video on YouTube.

https://www.youtube.com/watch?v=8u7mPa5R5kQ

This is a teaser video for the Infinite Icons and upcoming Infinite Icons 1.5 icon pack for Amiga OS4, OS3.2 and AmiKit 12 & X13.

Turn on the speakers and enjoy a performance of Isidor's brilliant song Cruising At Lightspeed from his new album Stellarix which

you can by here:

https://isidorbobinec.bandcamp.com/album/stellarix

The video was made with love for Amiga, enjoy!

By the way, the release date for Infinite Icons 1.5 is

shown at the end of the video.

Please leave a comment and review on YouTube 😊

@pjs


Thank you for your detailed feedback, I appreciate it.

Regarding the va.library error with -vo comp: I was not able to reproduce this. I just tested V-MPlayer under QEMU (which has no VAAPI hardware at all) using -vo comp both via CLI and through the GUI, and it works perfectly fine without any va.library error. The va.library is only touched when -vo vaapi is actually used.

Could you please check your mplayer.conf? If you have vo=vaapi set there, it might be overriding your -vo comp argument. Also please make sure you are actually running the V-MPlayer binary and not a different MPlayer build.

Regarding the comparison with MPlayer 1.5: I want to make it clear that V-MPlayer is NOT based on the official MPlayer 1.5 release. The foundation is the official MPlayer SVN trunk at revision 38685 (svn://svn.mplayerhq.hu/mplayer/trunk), combined with the AmigaOS4 patches from smarkusg and FFmpeg 7.1.4. Significant parts had to be adapted and rewritten to make the various video and audio outputs work at all. A direct comparison with MPlayer 1.5 is therefore not accurate - it is a completely different codebase.

Regarding your suggestion to merge changes back into the main tree: I understand your point and agree that improvements like AV1, Opus and the bugfixes could benefit all users. However V-MPlayer was developed as a focused project specifically for VAAPI hardware, and maintaining two separate development paths simultaneously is not something I can commit to right now. The full patch against SVN r38685 is available on GitHub, so anyone who wants to pick up specific parts for the main tree is very welcome to do so.

@walkero
thank you for this!
It is much easier produce SPE code with clib4.

As joerg said, you can create a "specs" file and change the default crt you want to use. And the specs file is different in any gcc version

@walkero

Mmm... three subversions of any GCC version compiled to default newlib, clib2 and clib4.
Later a script to choose the default one.

Fast and silly, ..what do you think about?

@graff

You mean that Hyperion takes responsibility of clib2?

Clib2 master branch is not updated for the last 5 years, and the development branch for the last 11 months. The last time I compiled the development branch, around November-December 2025, this was not even working under OS4. Not even a hello world worked, which was reported by me back then.

I like that you try to find a logical explanation, and you might be right. Let's not exclude that sometimes decisions are made based on personal preferences and not on facts.


@flash

Unfortunately, this is not that easy because it would require gcc recompilation. You see, if the mcrt is missing, gcc adds it by default, and to change that you need to compile gcc to work like that.

Of course, we could make this happen, or even remove any other libc from gcc, and make our life easier, but we, as AmigaLabs, like to provide choices and freedom to the developers, and not exclude anything.