I only see a link to paypal.me/ – it looks as though you did all this yourself.
Thank you for the hint and yes the donate button leads nowhere.Thank you for the hint and yes the donate button leads nowhere. Here I had a typo, it is
I would also like to mention here that I do not intend to profit from this port but simply want to recover the expenses I had myself and of course it motivates me to realise new projects.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
You can do it here but we should follow the forum rules
Arexx commands that are supposed to return values, never return the value which leaves the calling program waiting for a response.
Example using ARexxConsole:
no port > \port mplayer.1 --------------------------------------------------- Found ARexx port name >MPLAYER.1< =================================================== MPLAYER.1> \DIAG --------------------------------------------------- Turning ON diagnostics printouts =================================================== MPLAYER.1> GET_TIME_POS cmd ->GET_TIME_POS --------------------------------------------------- Checking for port_name ->MPLAYER.1 sending ARexx message ARexx message sent, waiting for reply
The reply never comes and the Arexx port seems to be locked up because even performing CTRL-C in the ARexxConsole program is not able to abort the waiting for reply like it should.
This seems to happen for all ARexx commands that are supposed to return a value.
You can do it here but we should follow the forum rules
Arexx commands that are supposed to return values, never return the value which leaves the calling program waiting for a response.
Example using ARexxConsole:
no port > \port mplayer.1 --------------------------------------------------- Found ARexx port name >MPLAYER.1 \DIAG --------------------------------------------------- Turning ON diagnostics printouts =================================================== MPLAYER.1> GET_TIME_POS cmd ->GET_TIME_POS --------------------------------------------------- Checking for port_name ->MPLAYER.1 sending ARexx message ARexx message sent, waiting for reply
The reply never comes and the Arexx port seems to be locked up because even performing CTRL-C in the ARexxConsole program is not able to abort the waiting for reply like it should.
This seems to happen for all ARexx commands that are supposed to return a value.
V-MPlayer is a standalone project and I have not tested it with SimpleSub or other tools, GUIs, or scripts. It is tailored to the V-MPlayerGUI. Nevertheless. Only the basic functions of Arexx were implemented so that the player can be fully controlled via the GUI.
I will take a look at it
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Thanks. Asside from this one ARexx issue, V-MPlayer is working very well with VideoClipper. If this issue is fixed it will be THE player to use.
There is one issue that I see sometimes and that is that the video window will sometimes open showing just an all grey output. (solid grey color.) I think this might be more of a graphics driver issue as I beleive I have seen Emotion have this issue as well. I'll see if I can investigate further later.
I'm using an X1000 with an ATI Radeon 7750 graphics card.
I have also tried V-MPlayer on an A1222p with an RX550 graphis card and it doesn't work. The CPU usage goes to 100% and nothing happens. If you want to try to support the A1222p I can investigate further.
@Maijestro Oh, one last thing today while I'm thinking of it. Could you add something to the version string returned that indicates the version is V-MPlayer. Maybe call it V-Mplayer in the version string. This would allow my programs to not have to rely on the mplayer version number to identify it. That way, if the mplayer version number ever changes, I won't have to update my programs if the version number changes. Thanks
I have just fixed the problem. A new test binary is available — GET_TIME_POS, GET_TIME_LENGTH, GET_PERCENT_POS and GET_VO_FULLSCREEN should now all reply directly without hanging. Could you contact me privately or do you have Discord so
I can send you the test binary?
Let's take this one step at a time. The issues on the A1222 are most likely compiler problems or other SPE related issues, that will probably take some time to investigate and I no longer have such a machine. We should also get the versioning under control. Please get in touch so you can do some tests with the updated build.
I have an Amiga X5040 with a Radeon RX560 graphics card at 2560x1440 resolution. One problem I'm having is that the beginning of the video is sped up, then it slows down before finally stabilizing. The video is in 2160p MP4 H.264 and MP4 H.265.
Test video:
However, with the GUI, there are no problems; it works perfectly in 2160p H.264 and H.265.
It's on par with DV Player, DV Player can't play a 2160p H.265 video (slow motion). Emotion can't play a 2160p H.265 video (slow motion)
@Maijestro Thanks for the quick fix of the ARexx commands!
I have a couple more inputs on the GUI.
First the fonts are to small and I can barely read them with a 1920x1080 resolution and higher.
Second, when I click on the button to bring up the mini GUI, the main GUI is still visible. So both GUI's are displayed. I can iconify the main GUI manually but it would make more sense if it was automatically iconified or close.
It would also be nice if the user could set which GUI was displayed at startup by default. For a lot of cases I like the smaller GUI.
I'll send you a private message with my email and I do visit Amigains.net discord channel as ktadd.
Thanks again. I'm pretty happy about the work on V-Mplayer!
I think you soon will find for yourself that better to switch to reaction based gui and ditch hollywood one. Yes, boring, but you will surely be at this road soon or later. It just current gui is feels not system friendly.
Can you resize it as any other amiga window ? Probably no ? Will it simple use system font size ? Probably not, and for every monitor different resolution it will be always static giving issues. And many many other fundamental things which normal good app should have. You just will find yourself implementing one by one features which reaction based window will give you for free. All you need is saying to AI "Create reaction based window using blablab with blbalal and blblabla" , and then follow wiki.amigaos.net articles of how create guis today. Then on top of reaction based gui you always can use themes if you want "modern" look, just like DvPlayer or AmigaAMP do for example.
Also, did i get it right, that instead of default english it all in german ?:) Not that i fanboy of any country or language, but english were defacto standard for many of us for many years.
I downloaded your archive from OS4depot and it looks like a lot of stuff is missing.
I appreciate it appears your efforts were mainly centered around your Hollywood GUI. Clearly you enjoyed that. Understood.
Honestly, I don't need a GUI. As I mentioned, I have my own means for calling MPlayer. As such, my focus is just on the best MPlayer we can have.
OTOH, it appears you stripped all the CLI functionalities as well as old functional display modes from your port of MPlayer.
Could you please go back and re-constitute all the old code into your new port of MPlayer? ....or add your new va.library code back into the old FULL Mplayer?
At the very least, your MPlayer executable should do everything the last, latest version did plus you additions. Think about all the older NG machines abandonned by the VA-API drivers (XE's, Pegs, 440's etc - the machines that needed it most).
I don't have a VA-API gfx driver yet (still need a Weasel-free way to get one) and ALL of the old display modes need to be maintained in any new MPlayer versions.
BTW, the default tool for all your readme files should be "Multiview", not "Multiviewer". You're on AmigaOS!
The most logical thing, which should have been done earlier, is to take the good work done by Maijestro on his VAAPI driver and simply trasfer it to our standard MPlayer version. It had already been done to include all the features of the old releases scattered throughout version 1.5, which really, we didn't feel the need for another fork.
I think you soon will find for yourself that better to switch to reaction based gui and ditch hollywood one. Yes, boring, but you will surely be at this road soon or later. It just current gui is feels not system friendly.
Can you resize it as any other amiga window ? Probably no ? Will it simple use system font size ? Probably not, and for every monitor different resolution it will be always static giving issues. And many many other fundamental things which normal good app should have. You just will find yourself implementing one by one features which reaction based window will give you for free. All you need is saying to AI "Create reaction based window using blablab with blbalal and blblabla" , and then follow wiki.amigaos.net articles of how create guis today. Then on top of reaction based gui you always can use themes if you want "modern" look, just like DvPlayer or AmigaAMP do for example.
Also, did i get it right, that instead of default english it all in german ?:) Not that i fanboy of any country or language, but english were defacto standard for many of us for many years.
Thanks for the feedback, I appreciate it even if I don't fully agree with all of it.
On the Hollywood GUI vs Reaction: yes, you are right that a Reaction-based GUI would give system integration "for free" — resizable windows, system fonts, theme support. That's a fair point. However, Hollywood was a deliberate choice for this project. It allowed rapid development of a custom look with animated visualizers, a miniplayer, real-time PCM display and other things that would have taken much longer with Reaction. V-MPlayer is a media player first — the visual experience is part of what it is. DvPlayer and AmigaAMP are good examples you mention, but they also look very different from each other, so there's clearly room for different approaches.
That said — the points about scalability and different monitor resolutions are fair criticism. These are real limitations of the current approach and something to address in future versions. I won't pretend otherwise.
On the language: you are correct, the GUI is currently in German. That was my mistake and it is being fixed. English will be the default in the next release.
On the "just tell the AI bla bla" comment: I think that understimates what actually went into this. Yes, AI was used as a tool — just like you might use a compiler, an IDE or a wiki. But someone still had to understand and modify MPlayer C source code for AmigaOS4, debug Hollywood PowerPC crashes that happen because Local variables can't be declared inside If blocks, write a custom real-time PCM visualizer that reads binary data from RAM:, patch af_export to work without mmap() on AmigaOS4, and test everything on real hardware. AI doesn't do any of that on its own. Anyone who has actually tried it knows that "just tell the AI" gets you nowhere without real understanding behind it.
So: some of your criticism is spot on and will be acted on. Some of it is a matter of different design priorities.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
On the "just tell the AI bla bla" comment: I think that understimates what actually went into this
Of course you need to understand what you do even with AI, of course ! But i were under impression you already gain enough experience with amigaos4 and it's coding so can know what-where-how, etc.
But that was only mentioned to help you out, just i am sure (can be wrong of course while being sure) you will soon realize that reaction is the only proper system integration way. But can be wrong, of course. Keep the work up anyway, more the better.
I downloaded your archive from OS4depot and it looks like a lot of stuff is missing.
I appreciate it appears your efforts were mainly centered around your Hollywood GUI. Clearly you enjoyed that. Understood.
Honestly, I don't need a GUI. As I mentioned, I have my own means for calling MPlayer. As such, my focus is just on the best MPlayer we can have.
OTOH, it appears you stripped all the CLI functionalities as well as old functional display modes from your port of MPlayer.
Could you please go back and re-constitute all the old code into your new port of MPlayer? ....or add your new va.library code back into the old FULL Mplayer?
At the very least, your MPlayer executable should do everything the last, latest version did plus you additions. Think about all the older NG machines abandonned by the VA-API drivers (XE's, Pegs, 440's etc - the machines that needed it most).
I don't have a VA-API gfx driver yet (still need a Weasel-free way to get one) and ALL of the old display modes need to be maintained in any new MPlayer versions.
BTW, the default tool for all your readme files should be "Multiview", not "Multiviewer". You're on AmigaOS!
Hi PJS,
I just checked the source and all the AmigaOS4 display modes are present and compiled in:
One thing worth checking: if you have really_quiet in your mplayer.conf, error messages will be suppressed and it may look like something is missing when it actually just failed silently. Try without it first:
MPlayer -really-quiet 0 -vo cgx_wpa video.avi
I also want to be clear about what this port is and what it is not. It was specifically developed for newer AmigaOS4 hardware with VAAPI-capable graphics drivers. It was never intended to replace MPlayer 1.5 or the existing ports. If you are on an XE, Peg, Sam440 or any machine without a VAAPI driver, the older MPlayer versions remain the right tool and should continue to work fine. VAAPI simply cannot work without a VAAPI-capable driver - that is a hardware limitation, not something that can be fixed in MPlayer itself.
I also want to be honest about something: I am not a professional C developer, and my work is not intended to replace the real development effort that went into MPlayer 1.5 by smarkusg and the other AmigaOS4 MPlayer developers. That was serious, skilled work done by experienced people over a long time. What I did was extend an existing solid base with specific additions for modern hardware, using AI as a tool. That is a very different thing and I would not want anyone to think otherwise.
What this port actually adds over MPlayer 1.5: - VAAPI hardware accelerated video output for supported hardware - AV1 decoding via dav1d (not present in MPlayer 1.5) - Various bugfixes in the existing display outputs - Extended audio codec support including Opus
For everything else, MPlayer 1.5 remains perfectly valid and is still the right choice on older hardware.
If a specific mode is not working for you, let me know which one and what happens and I will look into it.
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
