(MUI-)MPlayer & Mplayer-GUI on SAM460ex

@kas1e

is this the correct source code?
did not find any wpa_cgx or mui inside the code.

https://code.google.com/p/mplayer-amigaos/source/list

last change to the source code was in Sep 16, 2011.

maybe I need to login to get the newest version?

I need the newest version if I'm going to integrate the composition stuff whit MUIMplayer.

@LiveForIt

No, this Google page holds the "Reaction" version only (the one originally developed by Andrea Palmatè) + a merge for a more recent trunk from the MPlayer repository

The MUI version is different and the code are not here (is a direct port of the MorphOS version), however the OS4 version of the MUI port share the same p96_pip driver and so on, so in any case you can work on it and then eventually use the same code in both versions

Read this post: http://www.amigans.net/modules/xforum ... t_id=88802#forumpost88802

http://www.amigaworld.net/modules/new ... wmode=flat&order=0#727292 (and my comments on post #71)

Try here: http://fabportnawak.free.fr/mplayer/src/

@samo79

He was looking for cgx_wpa though. ahi_dev isn't in the "reaction" version either (why is it called that? There's no GUI afaik, just an AREXX port).

@LiveForIt
As samo and mick point out , that version on google-code its that old afxgroup's one , while mui-mplayer its direct port of morphos version from Fab , and as mick point there sources: http://fabportnawak.free.fr/mplayer/src/ . They of course didn't have aos4 deps to make it works on os4, but that not matter, as you can do everything with google-code version, and that way will be better, as both version will have new driver then.

Afxgroup's version (that one which on google-code), have only 2 mplayer drivers if i remember right: p96pip and added few years ago (so not avail in the builds on os4depot or whatever) pure p96 driver to make it works without overlay. But it didn't containt cgx_wpa driver, which, containt fab's mplayer. All i do, is just grab and copy+paste p96_pip driver from google-code version, to fab's one (with very minor changes, just to make it works).

In other words, google-code version do not have cgx_wpa mplayer driver and have just 2 p96_pip(overlay) and p96 (no overlay), while muimplayer port have cgx_wpa (original which come from morphos) and p96_pip (my copy+paste from google-code version). Of course, i can also add to muimplayer pure p96 driver too, but that will make no big since imho (or very a little).

In turn all of this mean that what i say before: you just can build google-code version, implement there radeonhd-compositing driver, and once it will works and users will test it , i can just copy+paste it to muimplayer too with no probs.

Also , as i say, do not build altivec version now. You will have troubles and burnouts. Build firstly general version and make radeonhd driver for, lately you can worry about anything you want, just i already can copy+paste your driver code to muimplayer as well.

Quote:

? But i show you already before:

Quote:

But better show your linking errors (all of them).

@Mick
ahi_dev just one more sound driver:
Quote:

Its all of course can be merged for good later: i.e.
1). cgx_wpa video driver added to code-google version
2). ahi_dev audio driver added to code-google version
3). p96 pure audio driver adeed to muimplayer port
4). when radeonhd video driver done added to both too.

Its pretty easy , and in general copy+paste. Just i don't worry about google-code version, as there wasn't any work done by anyone on it recently, so why bother.

@kas1e

All the did have is solved, I have moved on.

The problem whit this code that its broken, now I most fix stuff that I think you already have fixed.

Be nice if all the fixes and improvements where committed to google code.

@LiveForit
Quote:

What code exactly broken ? I didn't fix anything in fab's version, i just port what he do already (with some minor changes in mui code, process creations, adding of p96_pip code and few small bits not related to fixing of anything).

Is your binary already runs and works ?

@kas1e

Arexx macros not working, the p96pip driver is full of reaction stuff that is not found. (well I'm on X1000 now so don't need to fix that now)

Undefined symbols in amigaos_stuff.c

@Liveforit
Quote:

You mean binary still not ready and didn't links ?

What you mean by "p96 pip driver is full of reaction stuff that is not found" ? If something didn't found in code, then binary can't be linked.

Quote:

What you mean ?

In other words, did binary works already for you in pure p96 mode ? If so, you already can start to make radeonhd driver. All other problems can be fixed later.

Quote:

So binary still not links. Then post all your unresolved errors for linking (all of them)

@kas1e

nope I'm fixing the code, to make it compile.

@liveforit

There you can found my modified p96_pip, cgx_wpa, cgx_common and video_out which i use for muimplayer port:

http://kas1e.mikendezign.com/temp/muimplayer/

I.e. in video_out.c you just add your new driver (check amigaos4 ifdefs in that video_out.c), and create something like vo_compositing.c where wrote your driver. Later, you just can test it by adding in command line something like "-vo compositing" to test how it all works.

Logic are quite easy, just driver itself need it.

@kas1e

Here is the changes I made to make it compile

EDIT: tooooo long lines... don't try to use this diff as patch.

@LiveForIt

Now just link it and let's start with driver :) Probably only what need to check is how mplayer do actual blit (by lines, or by blocks, or whatever), and then think how to put it in best way to compositingtags (If i remember right from previous tests rendering done by lines)

@kas1e

The afxgroup version includes also an SDL backend, you can try it in MPlayerGUI -->Tab Video --> Video output --> "sdl (video through SDL)"
Of course it's slow, but it works...

@LiveForIt

Do you obtained the access to upload your fix/modifications in google site ?
If so maybe later we will able to recompile directly also the afxgroup version

@samo79

Not yet.

@LiveForIt

Maybe that sort of info will help you for making vo_compositing driver (i got some hints from Hans when ask him how better to do things)

As mplayer seems do rendering in lines (and seems we can't expect pure blit call to substitute with composition), then suggestion is to render the lines to an off-screen bitmap, and then do the compositetags() call once the frame is ready. There must be an "end-of-frame" signal somewhere (i do not know where, but probably somewhere in those files i upload), or you wouldn't be able to flip the buffer with a double-buffered screen/overlay-window.

If there is no blit call anywhere, then it can mean that its writing each line straight into the window (which sounds like a recipe for tearing and difficulty with RastPort clipping).

Probably you may want to try to play with cgx_wpa.c driver (see there BackFill_func() ) as well, if you will find p96 ones hard to understand.

Also (but i think you know it already as you already works with, but just in case), there is example of how to use CompositeTags() directly on a window from salas00:

http://os4coding.net/forum/using-comp ... -show-images#comment-1848

Hope that helps.

@kas1e

Yes I'm looking at the VO_WPA_CGX and the VO_SDL, I have not yet decided, just need to do more testing, it just take a lot of time every time I need to fix some thing.

The Makefile is not extrinsically efficient, compiles far too many .o files.

I'm trying to get VO_WPA_CGX to compile now.
Yes the p96 is one has too mutch stuff.

@LiveForIt
You will need of course make some little changes anyway to make vo_cgx_wpa.c compiles for google-code version :

1. add to makefile that file
2. just grab my one which already have aos4 ifdefs/changes where need it
3. add it to video_out.c as i do (check my video_out.c)

Probably may need some other changes like includes/name of functions (maybe adding/removing of use_inline will need it). But should be more or less easy.

But what for sure, is that use vo_wpa_cgx.c driver as base test, as it clean, simple, small, better structured and better commented (in compare with p96 drives), so should be easy to get the logic of how drivers works.

@Varthall
Is pure p96 driver code supposed to work already ? I just read in commit 21 its "pliminary" , so probably just copy+paste of pip code without much changes ? I tried to add it to muimplayer, but as i see draw_alpha() is not implemented at all and probably that why i have grey window there when trying to use pure p96 driver.

@kas1e

Whit WPA version I have no problem playing 720p, whit the SDL version my system is too slow.
So I think its going to be the CGX_WPA, that will be the one to hack to make new video output driver for mplayer.

@LiveForIt
Quote:

So you have added cgx_wpa to google-code version and it works ? That good, at least we at starting point :) Btw, will be good if you can get acccess from Varti to do commits , and add there all your fixes + that fab's cgx_wpa with my fixes , as more drivers in all mplayer versions - the better.

Quote:

Yep, at least on that one ppls who wrote me before tries to do it. SDL layer there for sure not need it and only make it all slower and compilcated.

Will be pretty interesting to see how in end speed will be on some old radeons like 9250. I.e. to compare overlay driver speed, and compositing driver speed. In theory compositing should be about the same as overlay by speed if do everything right imho.

And, i also fear there will be needs to deals with different formats and do all that manual conversion of some bits ..

@kas1e

Quote:

Yes, this is a Altivec enabled version, so that might have some thing to do whit it. CPU load is 74% to 90% normally around 85% on X1000.

Right now its buggy as hell, press any key on the keyboard and it dies whit DSI error, and don't let the movie finish, because then it also crashes.

Quote:

If not I might create my own Google code project.

Quote:

Better if every thing is in one place whit all fixes.

I don't know about you, but I hate having to work whit cross compilers and having to move files around, its more efficient to be able to test it at once, I think.

http://www.auby.no/files/video_tests/

Tested whit the harry potter 720p test video.