(MUI-)MPlayer & Mplayer-GUI on SAM460ex

I use the MPlayer-GUI to select and launch Mplayer on some videos.
Using the same configuration ( the original defaults) , with (Mui) Mplayer in the MPLayer-Gui drawer i get good results on my SAM 440ep
and for the same videos i get always an error message, "Unable to open window"
When i use "playvideo" in fs-screen that works OK on my SAM440ep, but on my SAM460ex i get a black screen
Possible cause ?

@JosDuchIt

"Possible cause ?"

Lack of overlay on your SAM460.

=> use SDL Mplayer from MickJt instead of MUIMplayer

@JosDuchIt

In MPlayer-GUI there is an option somewhere to set MPlayer's display backend. The version of MPlayer that comes with it won't automatically fallback to another backend if overlay isn't available.

Hans

@josdochit

If it indeed overlay problem (in case on your sam460 you use radeonHD), then you can change manually in config files of muimplayer to use cgx driver (or if you able to change command line params for binary on runnin, then just add -vo cgx or vo cgx_wpa or something, check readme)

@Hans

Is it too much hassle to add overlay emulation on radeonHD ? I know you say about other ways, but just mplayers, dvplayer and whatever else which use overlay already done, and its unknown when and if they will be adapted to new ways (if ever), and it can take as usual in amiga world years and years. While adding overlay emulation will fix everything automatically, and if some of authors will ever add another ways of hardware acceleration then good, if nope, then overlay emualtion will still works. But to be honest i have doubts that dvplayer will be fixed soon, or someone will write new driver for mplayers. And even if one of them will be done, users will still have no ability to use another. While emualtion of overlay will cover all problems.

@kas1e

Quote:
Yes, it's too much hassle. It would cost me whole orders of magnitude more time to implement than it would for application developers to update their apps to use the modern replacement: textured video. Updating applications to the new system shouldn't be hard at all. In fact, it should be dead simple for someone who is familiar with video. So simple, that there really won't be any excuse for not updating.

If you think about it for a moment, you'll realise that you're asking me to put large amounts of time and effort in to support an obsolete and inflexible API simply because you think that others will be too lazy to spend a small amount of time (timy, compared to what you're asking me to do) to update their code. This just doesn't make any sense, nor is it fair on me.

These "other ways" as you put it, are superior to hardware overlay in pretty much every way. Other OSes moved on years ago, and we should too.

Hans

@zzd10h
Quote:
In fact i am trying to use smTube which seems to accept only MUI-Mplayer.

As a first step (since MPlayer seems so complex, i do use the MPlayer-Gui which at least i understand (a bit)

@kas1e
I hav this in config file
[code] Write your default config options here!

# you can set up a list of vo with their own options. The one below is what mplayer handles by default.
#vo=cgx_overlay::PLANAR,cgx_wpa
vo=cgx_wpa
cache=8192


# device:unit on which dvd drive is connected.
dvd-device=ide.device:1

# averages audio/video synchronisation delays, and in pratice gives a smoother playback.
autosync=30

# enable screenshot filter-> press s to capture.
#vf=screenshot

# enable menu -> press c to show.
#menu=1

# you can increase ac3 level with this option instead of using -af volume=<gain> that causes more distortion, when using liba52 driver.
#a52volume=10

# for H264 files, it can improve speed by disabling totally or partially loopfilter
#lavdopts=skiploopfilter=all

quiet=1

[/code

This seems to be what you suggest

@Hans
Quote:

Can you explain a bit more? I don't find any "display backend"

@Hans
Quote:

But, there still none and that what users count :(

Dvplayer and mplayer still not updated, and that what matter for users. Sure it can be simple, but we can't be sure Cobra will ever update dvplayer, or someone will ever write new driver for muimplayer, even, if it dead simple. I remember in last 2 years about 5 persons who write me mail like "hey, i want help you to write driver for radeonhd based on compostiing, plz give me os4 version sources, and explain how build it all" => i spend days of my time for, and in end nothing, i even fear now to explain anything to anyone again, as it will ends like this. Amiga realms.

Quote:

Excuses are: lacking of time, lacking of interest, death of authors, family, busines, dead hourse, dead cat, sick of all kinds, crap, stuff => amiga reality. While ppls around can be somehow motivated still.

Quote:

I don't think they will be too lazy, i think they will not have time for it (while you still works drivers), or they simple will just loose whole interst in it. It may take years or forever or never ever. But apps already done, users already use them, and they not have hw accleration (and that what they count when do compare with other oses).

For example even if Cobra say he will do it, i fear it will be done when we will have less user left. Those ones who can make driver for mplayer, also will not make it too because of whatever reassons.

What it mean, than users will not have fast video playback. Even, if new way is way to go (we all agree on it, but amiga realms is here), even if we should move, even if its authors of apps who should updated them, even, if all that you says is right and we agree with. Just we live in realms when we know that all what we have, can be never updated anymore.

But i got your point, you still think it will take not 5 years, but a 2-3 :) Cross the fingers :)

Anyway, maybe bounty will motivate ? For example like "hey users, if you want crappy overlay emulation for radeonhd, collect 2-3 thousands" ?

@All

Is there anyone who want to write that dead-simple-video drivers for mplayer based on that new stuff about which hans told ? I can help with building/compiling/explaining-where-what-code , etc.

zzd10h, maybe you have interest ?

@kas1e

Where is the latest source code of mplayer, I like to have look at it.

@JosDuchIt
"In fact i am trying to use smTube which seems to accept only MUI-Mplayer."

No, believe me, SMTube works far better with SDLMplayer on non overlay system.
I use it every day.
Mail me if you want...

@kas1e
"zzd10h, maybe you have interest ?"
Too much complicated for my little knowledge.

@kas1e

Don't try to counter "laziness" with "lack of time." I don't have any spare time at all right now, and asking me to waste time that I can't afford to waste because others are "lacking of time, lacking of interest" or whatever other excuse there is, quite frankly, disgusting. Expecting someone with even less time than you to do all the work is laziness. If that's other people's attitude, then go badger them to get off their lazy butts and contribute. Stop asking me to pick up the slack and slave away. I can't afford to do this, and it's not fair to even ask that of me.

The answer is NO. Kindly do not ask again.

Hans

@Hans

Quote:
doesn't textured video require a new OpenGL implementation for AOS4? so updated applications would have to wait until HJF is finished with the new 3D stack, or am i missing something?

-- eliyahu

@kas1e

The MPlayer sources i provided have a proper fallback when overlay is not available (in that case, cgx_wpa is used instead).

I assume it doesn't work in the OS4 port because you reused that old p96pip mplayer driver which is buggy in that regard. Like in the cgx_overlay(_gui) driver, it should have a proper preinit function that checks for overlay ability. If it returns false when overlay is not available it gives a chance to mplayer to try another video output driver in the list instead of just failing...

@eliyahu

Quote:
No.

Hans

@Fab

Oh its using the one where the BytesPerRow where calculated instead of read from Picasso96, yes I fixed that issue in a private mplayer version I made from Andrea Palmate (afxgroup) source code.

I think I have posted the fix for that before on the forums.

I can fix that if I can get my hands on Ka1e source code.

@eliyahu

It can be done whit CompositionTags() like I did on Basilisk II, and I'm happy to do it for Kas1e if he does not know how to.

The source code for it is uploaded on OS4Depot.net so anyone can see how its done.

@kas1e

Quote:

I have not asked before and you have not sent any source code to me.

@LiveForit
You can just make radeonhd mplayer driver for that version:
https://code.google.com/p/mplayer-amigaos/

It then can be copy+pasted to muimplayer with no probs (same as i do for p96 overlay driver)

Quote:

Its not my code, i just reuse that one from link a post above. Exactly code of p96_pip driver are here: https://code.google.com/p/mplayer-amig ... unk/src/libvo/vo_p96pip.c

All you need to make new driver, its do the same as done there for vo_p96pip.c for overlay, or for vo_p96.c for plain p96, just with use what need to do to make it all works over compositing. And somewhere in one single file you just add use of new driver and that all (if i remember right its video_out.c). I.e. you make in libvo new vo_compositing.c file, write there all necessary code, and add to video_out.c use of it as done for p96_pip and p96 drivers (that easy, harder part to write driver itself).

You need of course to deal how build it , but i think if you really want to make it, you can deal with them (i just already explain all that boring "how to build" things for few ppls as i say, and nothing come up from it, so i think if one want, he will deal with compiling of it too).

Quote:

In p96_pip.c ? If so, can you upload fixed version and point out what fixed so i can build test version for someone who have problems with automatica detect.

And btw, if you already have build some custom version of mplayer from afxgroup version, you then can build it all already, and can just already start to write radeonhd mplayer driver and make it all works. Then i can just copy+paste it to muimplay as i do for p96_pip driver with no problems.

@Fab
Sad truth, is that when i make port of your mplayer, i specially ask ppls without overlay to test if all works ok and all detects automatically. Those testers says "all is ok". But later i start to read all those moments that on some setups automatic fallback didn't works.

@LiveForIt

Quote:
hoo-ray! that would be outstanding. and worth another donation. :)

if such a version is built, i'd be very interested to see if framerates improve or CPU usage drops for users with RadeonHD cards. i had always associated 'textured video' with OpenGL -- but then again my experience outside of the amiga is mostly linux and solaris.

-- eliyahu