As in case with mui-owb, i just start some thread where will post all the info about current progress and put all the info.

So, in brief, we have build with Deniil today AROS-version of mplayer (thanks to Deadwood who help with boring with aros-specific configure-files) which just the version from 2008 (3 years old) from Fab (I.e. deadwood 3 year ago just port fab's version at this time). Lately mplayer code itself was updated, but gui are 3 years old.

Why we not port latest fab's version which just few months old ? We port it, but start to have some strange problems, which point us out on some random memory trashing, we spend 2 days with Deniil to understand it, i annoy fab a lot (like i the first days with muiowb). Crashes was random, stacktrace was broken (i.e. no stacktrace) , everything points on some strange "68k cross calls".

For example at running we have NULL for some objects, on other run are not. If we comment one part or another, its just randomly reacts. So, i think better to start from AROS port (just to be sure, that we not mess something in porting code), and just to know, will AROS port have the same problem on aos4 after porting, or not.

So, with help of deadwood, we build today aros version, and, how sadly it was : bugs was the same.

Then we remove all optimisation, add debugging info , and so, stack-trace start to be more or less fine, and we found, that roots of the problem was : sucking DoSuperNew (about which fab say to me yesterday).

But what is was a bit suprising, is that i already add on linking stage our aos4deps.a library , which we use for MUIOWB, which, have inside DoSuperNew.

The problem was because of we do not declare any prototype for DoSuperNew in the sources of mplayer , and so, compiler by default just make it as INT , and throug all params over stack, while our one are :

Quote:

Object * VARAGS68k DoSuperNew(blablalblab)

Without that proto, linker by default make it as INT, and then, even if we have "right" DoSuperNew in the aos4deps.a , it was ####ed, and in end all possible random erros and crashes.

And end of all , we have port of mui-mplyaer which 1.5 years old, and reported from AROS, here is 2 screenshots:

screen1
screen2

What we will do in terms of mplayer for now:

Compile latests Fab's code and fix all the bugs in the mplayer itself. If there will be some problems, then will fix 1.5years old port from aros, fix some small bugs (a very small ones) and realease.

Last edited by kas1e on 22-Oct-2011 at 07:50 PM.
Last edited by kas1e on 22-Oct-2011 at 07:48 PM.
Last edited by kas1e on 22-Oct-2011 at 06:58 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Good work That'll be another key piece of software that almost every OS4 user will appreciate!

_________________
RobTheNerd.com | InstallerGen | SMBMounter | Atoms-X

And there is screenshot from the latest available fab's sources: goodshit

So, now its matter of fixing of mplayer code itself (whih i mess of course) and then alpha for testing, and after adding p96/pip and stuff.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Looks great and quite finished already, nice stuff mate

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@kas1e

Looking good. Keep up the good work.

_________________
I'm an antique. Don't light my fuse

Just for the record, that's how it looks like when using the cgx_overlay_gui driver:

http://fabportnawak.free.fr/mplayer/MPlayer.png (some things changed since this old screenshot from 2008, but it gives an idea).

Looks good :) keep up the good work :)

@all_who_know

While i do not understand how all that overlay stuff done at all, maybe someone to know, if it possible that our CGX emulation (which done over P96) can in the same way emulate a CGX overlay ? I mean thereotically its just should be matter of CGX-overlay->P96-overlay and should works. The question is: if it done by our CGX emulation, or can we do some code, which will use CGX overlay and have it working on our P96 ?

Of course, in end we can get the sources from our current aos4-mplayer, and create a p96_overlay_gui driver , but of course better to do as small as possible changes in original fab's code.

@fab
Btw, did overlay in mui-mplayer need only for puttin gui to the main window, or overlay will be used and for putting gui to main window, and for overall speedup ?

Varthall also says something about p96-pip stuff, like its something different that overlay, and we need to add that as well. Did cgx have it too ? (cgx-pip or kind)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

No, no, PIP is how overlay is called under Picasso96. What I meant is that I'm working on a non-PIP driver.

Varthall

_________________
AmigaOne XE - AmigaOS 4.1 - Freescale 7457 1GHz - 1GB ram

@Varthall

Quote:

No, no, PIP is how overlay is called under Picasso96. What I meant is that I'm working on a non-PIP driver.

So, you works on something which we have on mui-mplayer for now, and which called "cgx_wpa" driver, right ? I.e. that driver use WritePixelArrays and stuff , but you want to do the same but for P96, via P96 fucntions , right ?

What the reassons for ? Because our current mplayer switchs to SDL when no overlay/pip available ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Overlay setup is different in CGX and P96.

* In CGX you create an overlay context and attach it to your window. So you can dynamically add, modify and remove overlay feature in runtime to any of your windows.

* In P96, you dont create an overlay context but open a PIP window using P96 API calls. In PIP window overlay is static -- you can not modify, disable nor enable it at run time. It is there until you close your PIP window again.

You can not use PIP in MUI applications because MUI calls intuition.library/OpenWindowTags(), to use PIP you would have to call Picasso96.library/P96_PIPOpenTags(). CGX overlay can be used in MUI applications because overlay can be added dynamically to your UI elements to any x/y coord with any width/height you wish. This is also reason why it is so difficult have overlay support in SDL with P96 because technically you must reopen SDL window when defining overlay.

If P96 provides cgxvideo.library emulation then there should be no problem using CGX overlay API in OS4 or other P96 systems. If not, then it is just impossible.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Did you just mean in other words, that with Mui-Mplayer we can't add P96's overlay, and the only chance for us, its to make (if we not have) cgxvideo.library emulation ?

And did you mean that its unpossible with P96 overlay, to put all those gui buttons to the window itself in mui-mplayer (as fab do with cgx) ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Yes, that is what I mean. With MUI MPlayer you can not use P96's overlay. It just is impossible use P96's overlay in MUI windows.

It is also impossible include MUI buttons to PIP window

The best you could have is view video in separate PIP window and MUI toolbar in another.
Only Hyperion can create cgxvideo.library wrapper, so unless they have done it you are out of luck.

Last edited by itix on 23-Oct-2011 at 11:08 AM.
Last edited by itix on 23-Oct-2011 at 11:07 AM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

At least we can have the same as it now on screenshots, just the window where is video going will be overlayed. That is ok too i think.

Through, i know that AfxGroup added lately some initial gui to the aos4-mplayer (of course reaction one, but interesting if it was with plain surface, or with overlayed somehow).

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

While I can't refer to software that uses CGX overlay and works in OS4 (although that shouldn't be hard to find), cgxvideo.library is indeed found by version and I don't think it's just so cgx calls would work at all..

_________________
: AmigaOneXE (unmod.) 750FX/512 MB +stuff & AmigaOS 4.(0|1)
: A1200/68060&96MB/SCSI/EM1200-Voodoo3 & OS 3.5
: A500/1MB
: Pegasos (ff) 512 MB & MorphOS
Praise seitan.

@Thematic

Quote:

While I can't refer to software that uses CGX overlay and works in OS4 (although that shouldn't be hard to find), cgxvideo.library is indeed found by version and I don't think it's just so cgx calls would work at all..

Yeah, plain CGX emulation are works (it uses by mui-owb , current mui-mplayer on os4 also use plain cgx+wpa, lunapaint port from aros also uses plain cgx). But i am do not know about overlay.

As far as i know, we have cybergaphics.library inside of the p96 emulation. I.e. we not have it as library, but we can open it from the code via OpenLibrary/IFace and it works. So for now (while no one from devs can comment on it), i think that:

-- plain cgx api are emulated for sure by p96 (and cybergraphics.library in the memory)
-- cgxvideo.library also present, which should then works and emulate cgx's overlay ? Did it come with aos4 default distrib ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

cgxvideo.library is loaded from "emulation.library", and seems like it was there already in 4.0 (if not the prerelease).

_________________
: AmigaOneXE (unmod.) 750FX/512 MB +stuff & AmigaOS 4.(0|1)
: A1200/68060&96MB/SCSI/EM1200-Voodoo3 & OS 3.5
: A500/1MB
: Pegasos (ff) 512 MB & MorphOS
Praise seitan.

@Thematic

Interesting. I also found this about cgxvideo.library:

Quote:

cgxvideo.library allows you to use gfx card's video overlay features in your applications. This library is part of the CyberGraphX V3/V4 package. As of now, only the CyberVision64/3D graphics board supports video overlay features.

So, i assume that if that library present, then it can be present only for overlay purposes.

The next question is: if library present and then it mean we can use cgx_overlay , did it will be real overlay, or will be just emulated one which will be in end something like "no real overlay , but software emulation" ?:)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

It should be easy to find out. Write small test app using cgx overlay and if it works with 0% cpu usage you have got real overlay there.

If not, you can always ask OS4 developers to implement more MorphOS API functionality there =P

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix
Quote:

It should be easy to find out. Write small test app using cgx overlay and if it works with 0% cpu usage you have got real overlay there.

Imho should be not small-test-app (or it will be even with software-overlay 0% of cpu). Need something massive like video plaing or kind (right ? i not so understand what can be done via overlay to see if it real one, if not the video playing).


Quote:

If not, you can always ask OS4 developers to implement more MorphOS API functionality there =P

Haha :)

Btw, you say that without cgxvideo.library will be unpossible to make buttons in the mui window, just because p96 not allow adding of overlay in realtime and so on, but, cgxvideo.library for sure works over P96 (even if it just software emulation of overlay), so, it still can be done via p96 (even without cgxvideo.library), right ?

Last edited by kas1e on 23-Oct-2011 at 03:04 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites