Regarding the va.library error with -vo comp: I was not able to reproduce this.
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.
Regarding the va.library error with -vo comp: I was not able to reproduce this.
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.
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!
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Re: MPlayer v1.5 and your work - that is an issue, IMHO. You are doing more than just adding VAAPI. You are advancing the overall functionality of MPlayer and I would suggest it would be a lot more valuable to our little community to plow as much of that back into a single source tree rather than spawning you own crippled (VA.lib ONLY) branch.
"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.
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)
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
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
Exactly, this was one of the main goals of our 1.5 release, along with of course fixing further bugs and adding more features where possible
Quote:
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.
Yes, these new features should certainly be integrated and it is a task that needs to be done with meticulous care, VAAPI is certainly essential and would complete the project
More updates to follow — please keep testing and reporting!
I can tell you one thing after checking “https://github.com/Maijestro/mplayer/releases/tag/v306-beta” The problem with uploading this file for testing was that the bare executable file “mplayer_vaapi_hw_v306_stripped” was incorrect. As I assume, @TSK, when reporting the issue as a regular user and running the command “mplayer_vaapi_hw_v306_stripped,” doesn’t need to know about video outputs. They just run the command with the target file “video.” Your output settings are just a mess. You have duplicate video outputs. It’s possible you were using AI prompts where it asked you various questions—you reported the issues to it, and it gave you nonsense answers.
4.RAM Disk:> mplayer_vaapi_hw_v306_stripped -vo help
MPlayer SVN-r38685-FFmpeg7.1.4-AmigaOS4 (C) 2000-2026 MPlayer Team
Available video output drivers:
vaapi VA-API hardware accelerated video output
comp_yuv2 Composition, yuv420p, direct rendering, has a thread for video output
sdl SDL YUV/RGB/BGR renderer (SDL v1.1.7+ only!)
sdl SDL YUV/RGB/BGR renderer (SDL v1.1.7+ only!)
p96_pip Picasso96 overlay
comp_yuv2 Composition, yuv420p, direct rendering, has a thread for video output
comp_yuv Composition, yuv420p, direct rendering
comp Composition, R8G8B8
wpa Graphics.library / WritePixelArray (no window scaling)
vaapi VA-API hardware accelerated video output
amiga AmigaOS P96 video output
null Null video output
mpegpes MPEG-PES file
yuv4mpeg yuv4mpeg output for mjpegtools
png PNG file
jpeg JPEG file
tga Targa output
pnm PPM/PGM/PGMYUV file
md5sum md5sum of each frame
Here is the order of video outputs determined based on priority and in the absence of a configuration file. I don't know what else might be wrong, but I don't even check that… Checking code packed with artificial intelligence is a waste of time
You were right, and I really appreciate you taking the time to analyse this so carefully and report it.
Here is what happened: when we added the AmigaOS4-specific driver block, vaapi, comp_yuv2 and sdl were already listed earlier in the generic driver list without any platform guard. This caused them to be registered twice on AmigaOS4. The code has now been cleaned up and each driver appears exactly once in the correct order.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
MPlayer Binary: - Fixed -vo option being ignored when VAAPI was active (affected X1000 with HD7750 and other cards without VAAPI support) - Fixed va.library being opened even when a software video output was requested (-vo comp, -vo sdl etc.) - Fixed duplicate video output drivers appearing in -vo help - Corrected video output driver priority order - OSD CPU optimisation: draw_osd() no longer runs every frame, CPU usage at 4K H.264 reduced to 5-8% with osdlevel=0 - Fixed font path resolution for subtitles on AmigaOS4 (PROGDIR: prefix) - README now available as AmigaGuide in English and German
GUI: - Real-time audio visualizer now reads PCM data from RAM: instead of T: for faster access and lower disk I/O - New visualizer modes: Rings (concentric colour rings) and Bounce Bars replacing the previous Fire and Tunnel effects - Viz tab: Fire and Tunnel replaced with Rings and Bounce Bars - Radio streaming: va.library and af_export are no longer loaded during radio playback, significantly reducing CPU usage - Radio tab CPU usage during streaming reduced from ~20% to ~3% - Radio tab: loading bar no longer restarts when switching tabs and returning - Radio tab: ON AIR blinking dot only appears after the stream is connected - Radio tab: BoingBall is now always static (animated only during intro) - Media tab: when streaming radio, station name and LIVE indicator with blinking dot are shown, all other animations are static - Media tab: 500ms timer during radio streaming instead of 50ms, significantly reducing idle CPU load - Viz tab: ON AIR bar and status line no longer shown when switching from radio tab to viz tab - Pause: CPU usage significantly reduced when playback is paused - Intro animation: switching tabs during the animation now immediately completes it instead of resuming on return - Miniplayer: progress bar and elapsed time now count correctly when switching between miniplayer and main window during radio streams - Window size: last used size is now saved and restored on next start - Language: English is now the default language - Version number in Settings tab updated to v1.1 - GUI now supports Tooltypes: setting MINI=1 opens only the Miniplayer on startup, Open button added for file selection
The main focus of this release was the GUI. There were too many unnecessary animations running in the background causing extra CPU load.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
There no words if my version is old or if there is other issue, so i updated to latest version and it works. But, still, IMHO, when one simple want to open local file, amisslmaster.libary for sure shouldn't be need it. It's should be opened only when one want to stream.
GUI resizing works now, yeah. Just a little cosmetic issue that when you resize, the window for a some time fully black, and only then things redraws.
Also i find the GUI not support RMB mouse, that expected ? I know Hollywood support it for sure, to have those usual OpenFile, About, Quit, with tasty AISS icons.
Also, probably when you hit button for v-player mini, the "max" version should disappear, until you back it from mini ?
ps. is there any slide so to move over the videos ? or only left/right keys ?
There no words if my version is old or if there is other issue, so i updated to latest version and it works. But, still, IMHO, when one simple want to open local file, amisslmaster.libary for sure shouldn't be need it. It's should be opened only when one want to stream.
GUI resizing works now, yeah. Just a little cosmetic issue that when you resize, the window for a some time fully black, and only then things redraws.
Also i find the GUI not support RMB mouse, that expected ? I know Hollywood support it for sure, to have those usual OpenFile, About, Quit, with tasty AISS icons.
Also, probably when you hit button for v-player mini, the "max" version should disappear, until you back it from mini ?
ps. is there any slide so to move over the videos ? or only left/right keys ?
The AmissL thing is a fair point — it should definitely not be required just to open a local file. I will try to fix that so it only gets loaded when you actually want to stream something. Honestly I am not sure yet where exactly it gets triggered right now, and I have not updated any libs on my end either, so it is a bit of a mystery still. But we will figure it out. And yes, the error message was not helpful at all, that will be clearer too.
The black window during resize — yes, I have seen that myself and it has been bugging me too. Honestly I have not managed to fix it properly yet, but I will keep trying.
RMB context menu is a nice idea, very Amiga-style with AISS icons. Will look into that.
Hiding the main window when switching to the mini player — totally makes sense, good catch, will do that.
And the seek bar — yes, right now it is just a display. Clicking to seek is on the list.
Thanks again, this kind of feedback is exactly what I need!
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
I'm having trouble playing YouTube videos; the audio skips and the video stutters at certain points.
I used your YT.cfg file, Maijestro, and I tried several times with it. I get either 818p or 272p video.
I did manage to get a 1080p video, but it's choppy.
I'm using MickJT's ffmpeg version 8.0 and ffplay version 7.0.
YT.rexx is the OS4depot version.
Hey, I use YT.rexx too, but exclusively with V-MPlayer — no ffplay or ffmpeg. And it works fine for me.
If you are using YT.rexx you should keep ffplay and ffmpeg completely out of the config — that can cause problems and is probably exactly what is happening here.
The stuttering and the weird resolutions (818p, 272p) sound like a misconfigured YT.cfg to me. I would start looking there.
V-MPlayer uses VAAPI directly for hardware decoding, that makes a huge difference at 1080p. ffplay and ffmpeg do not have that and fall back to CPU decoding — which AmigaOS4 simply cannot handle smoothly at 1080p.
I can share my YT.cfg on OS4Welt if that helps — there were also a few small tweaks in the latest version that might make a difference.
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
