@broadblues

In GUI mode, it starts with the main window only. The other windows are opened on demand. And it can be configured to hide the top/bottom controls as well, so you might not even notice the difference between gui and cli mode, except gui mode offers much more when needed.

@kas1e

It doesn't matter if you use GUIor CLI mode. The mplayer options/arguments will work in both modes.

In fact, i don't see much point in the other Mplayer fork, since it was already based on older MorphOS sources (apart from the buggy cache code using pthreads and p96 video output driver which is contained in a single file and could just be added to this port, anyway).

Last edited by Fab on 24-Oct-2011 at 12:48 PM.

@kas1e

Quote:

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 ?

I'm implementing it since:
- overlay is not yet implemented on RadeonHD drivers (and, according to Hans, overlay implementation has lower priority).
- at the moment, the SDL driver works in full-screen mode only and (might) not support all the features of a native P96 driver (e.g. double buffering for OSD text). So, instead of trying to improve the SDL driver and risk to be unable to implement some features because of limitations of the OS4's SDL port, I prefer to work on a native solution.
- I'd like to learn how to use the P96 API.

Unfortunately the P96PIP driver doesn't automatically switch to SDL in case the screen/window can't be opened, but I'll implement it (and thanks for the idea ;). The non-PIP driver currently opens an empty window as I need to implement the draw_slice() function (on p96_PIP it uses p96PIP_GetTags(), I need to search for its equivalent for a normal P96 screen).

Varthall

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

@kas1e

great work ! wait for public relase..

_________________
--

Amiga x5000 ı o2o ı 4GB RAM ı RadeonRX580 | SBlaster Audigy Fx - AmigaOS4.1 FInal Edition

A1200 sandwich :)

Croatian Amiga portal

@kas1e

Quote:

I think os4-current one mplayer have the latest mplayer-code as well (through that version unreleased, and are on the google-page), so, for you that port will make sense just to compare which one works better from command line (i assume should be almost the same). Also there is no overlay support yet, so, current aos4-one will be better for users who want just command line version.

No, not yet, the codebase alignment with the latest official code will be done as the last step. This way I don't risk to release a version of MPlayer which is based on a 2-3 months old official MPlayer code. I'm thinking to import both the MPlayer and FFMpeg code using Subversion's vendor branching feature.

Varthall

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

@Varthall

So there is much more work still to do on current aos4 version, and while you works on it, it will be cool to have mui-mplayer which works with all the new mplayer code and stuff, just without overlay (so, for RadeonHD users there no reassons to wait for overlay in muimplayer, they anyway will not have it for the year or so imho).

But as i understand Mencoder on google-page are already done and latest one ?

Quote:

Unfortunately the P96PIP driver doesn't automatically switch to SDL in case the screen/window can't be opened, but I'll implement it (and thanks for the idea ;).

So it mean, when use run mplayer, and user not have overlay, then mplayer just crashes badly or just show some black/white/trashed screen ? (omg)

Btw, for the logic of realisation of p96_wpa (or how it will called, i think not WritePixelArray will be used?) , you can just check how Fab do with cgx_wpa (in libvo/), so you can just follow the same logic, just replace on p96 equvalent where is need it.

And imho, better to swithch to non-overlayed p96_driver if overlayed one not opened, and forget about SDL at all and for ever. Or just to cgx_wpa (for now), which can be grabbed from muimplayer.

Last edited by kas1e on 24-Oct-2011 at 01:19 PM.
Last edited by kas1e on 24-Oct-2011 at 01:18 PM.
Last edited by kas1e on 24-Oct-2011 at 01:05 PM.
Last edited by kas1e on 24-Oct-2011 at 12:59 PM.

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

@Fab
Quote:

In fact, i don't see much point in the other Mplayer fork, since it was already based on older MorphOS sources (apart from the buggy cache code using pthreads and p96 video output driver which is contained in a single file and could just be added to this port, anyway).

Of course its better to have just one mplayer, but there is 2 problems:

1. We need one place where it all will be placed. Will you in interest if we will have one SVN page, code of which will mean your latest mplayer + our change + p96 drivers ? Will you in interest if we will just put your latest source code on current SVN, and then works on it ?

2. Overlay. If overlay with mui not possible on 96 (because of what you and itix say), the how we can replace our version if it will mean "no overlay for p96" ?

Through we can add of course some key-swith, to run it from shell and without gui, but just with p96 overlay (as it now).

What you think about ?

Quote:

p96 video output driver which is contained in a single file and could just be added to this port, anywa

You mean some swithch to command line mode to make it works without gui, right ?

Last edited by kas1e on 24-Oct-2011 at 01:14 PM.

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

@kas1e

MPlayer video output design is modular...

Adding a new video output driver is a matter of touching one file (to declare it) and adding the new video output driver itself (let's say one more file as well, usually).

So, switching to a whole new repository just for this really doesn't make sense, when you can just take this vo_p96pip.c and integrate it in mplayer morphos sources (should be a 5 minutes job).

@kas1e

Quote:

So it mean, when use run mplayer, and user not have overlay, then mplayer just crashes badly or just show some black/white/trashed screen ? (omg)

No it simply and correctly exits printing a message to the console, and I'd rather it did that than try and change to another video mode, you may have a reason not to want it (such as the SDL crashing on exit or you just know it will be too slow or whatever).

@Varthal

Please don't implement an automatic fall back, except perhaps to print a message sugesting an alternative video option. I'm sure it will cause more issues than it solves.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Yep, right. If it exit correctly, then it also fine enough.

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

@broadblues

When not specifying a particular video output, it's nice to try overlay first (if available) and then fallback to other drivers. The fact the SDL mode is crashy on OS4 port is a bit irrelevant. It should either be fixed or removed in favour of a native output driver.

@kas1e

nice initiative. It's nice to see you don't plan to reinvent the wheel

I think you should avoid mixing SDL, wpa, direct rtg mem, and overlay modes. The user will choose the right one, the most I would do would be using wpa one if pip is not possible.

PIP seems to be slightly crap on p96 but I guess you could make it work anyway with p96. Open a pip p96 window. Catch the events and pass them to MUI application. It's not as nice as having a MUI window but I don't think it's so important... you just one to catch a few keypresses, double click, the scroll wheel and little else. The most important part IMHO is fullscreen PIP. PIP on fullscreen is possible and not so difficult.

The mode with the separate pip/overlay window is not bad anyway, you could start with that one you get fullscreen PIP working with events.

If you want to show the gui surrounding the overlay you could make a "hack" and open the overlay window on top of the MUI one with the controls. You could catch events of resizing and moving window to make it appear/dissappear... more or less like nutsaboutamiga described

but please, get rid of SDL or at least avoid mixing it with the rest. If you really insist on mixing code use WPA for windowed modes and PIP for fullscreen with no gui.

I'm sure catching double click and a few keypresses on a PIP window won't give you so much hassle.

Although it would be better and easier if P96 team implemented correct cgx api for overlay.

_________________
The only spanish amiga news web page/club: CUAZ

@Crumb
Quote:

I think you should avoid mixing SDL, wpa, direct rtg mem, and overlay modes. The user will choose the right one, the most I would do would be using wpa one if pip is not possible.

We just port Fab's code, so there is for now everything done by him, without any mess.
We for sure will not worry about SDL if Fab not worry about (because for what we need to use SDL at all, if emulated-cgx, or direct p96 available). SDL on mplayer on os4/mos/aros can be only used because some problems with p96/cgx is present, but, as its something which works fine (and should), then i really dunno for what need SDL at all. Or i miss something ?


Quote:

PIP seems to be slightly crap on p96 but I guess you could make it work anyway with p96. Open a pip p96 window. Catch the events and pass them to MUI application. It's not as nice as having a MUI window but I don't think it's so important... you just one to catch a few keypresses, double click, the scroll wheel and little else. The most important part IMHO is fullscreen PIP. PIP on fullscreen is possible and not so difficult. The mode with the separate pip/overlay window is not bad anyway, you could start with that one you get fullscreen PIP working with events.

I think for now will be better just to add the same p96_overlay driver from current aos4 mplayer, and just when user will want, he will use it from command line without any gui (i.e. p96 overlay = no gui).

Quote:

but please, get rid of SDL or at least avoid mixing it with the rest. If you really insist on mixing code use WPA for windowed modes and PIP for fullscreen with no gui.

I personally not want to add any SDL code to fab's code, which are good enough already.

Quote:

Although it would be better and easier if P96 team implemented correct cgx api for overlay.

One of os4-devs who have access to sources say to me:

Quote:

As far as I can see in the P96 source emulation.library does include all functions of cgxvideo.library and hence should offer the complete set of possibilities. Just try it :)

So it mean cgx_overlay driver will works on os4 too, but, with real overlay or not , no one know (and will it have bugs or not, noone know as well). That all to be tested. And bugs of course can be present, just as for example now, full-screen mode not works for us in cgx_wpa driver , and looks like something wrong with returned modes or kind. Also need to fix now (and i wait when Deniil will come back from work, to annoy him :)) )

Last edited by kas1e on 24-Oct-2011 at 03:59 PM.

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

@all

First version of muimplayer are on os4depot for now (check upload query). In general all works, just no overlay right now.

If you want command line : use it from the shell

If you want GUI: run from the icon (tooltype GUI). If you disable that tooltype, then from the icon it will just ask for the file which need to open.

The advantages over the our current os4 port: newer mplayer code, better structurisation and code itself, mui-gui with all the stuff , better integration of streaming (working over bsdsocket.library directly) and all the other pluses about which know only Fab as he author.

The minus now only one: No overlay. Because of it, in full-screenmode you have no scalling (to avoid slowdowns). Overlay will be implemented pretty soon (i hope).

PS: its is _NECESSARY_ to have update3 minimum. Or, you need MUI from update3, which you can copy on older version of OS and it will works as well. Through, better to just have update3, to avoid any possible problems.

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

@kas1e

Thanks. Will check it out tomorrow. Hope to get some sleep now :)

@kas1e

Well done, again.

Thanks for all your fine work.

@kas1e

Thanks to all involved.

Will test it in about an hour.

_________________
If your nose runs and your feet smell, you're upside down.

@kas1e

Thanks, i will try now !

_________________
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

Thanks mate.

For the moment, MUI-Mplayer is way slower than MPlayer OS4 (Andrea's version).

For the same vide : 65% CPU used with Andrea's Mplayer and 100% used with MUI-Mplayer (lack of overlay must be the cause).

_________________
PowerMac G5 2,7Ghz - 2GB - Radeon 9650 - MorphOS 3.14
AmigaONE X1000, 2GB, Sapphire Radeon HD 7700
FPGA Replay + DB 68060 at 85Mhz

@K-L
Quote:

For the moment, MUI-Mplayer is way slower than MPlayer OS4 (Andrea's version). For the same vide : 65% CPU used with Andrea's Mplayer and 100% used with MUI-Mplayer (lack of overlay must be the cause).

Of course, overlay and stuff :)

Last edited by kas1e on 24-Oct-2011 at 10:41 PM.

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

@K-L

It's mostly due to missing overlay driver, and possibly slower cgx routines as well.
On MorphOS, MPlayer is about 50% faster than the OS4 version when using overlay mode (on pegasos 2).

Last edited by Fab on 24-Oct-2011 at 11:01 PM.