muimplayer new version progress

@kas1e

Spasiba, so point 7 is fixed aswell !
I updated the list adding a new point (8) see:

http://www.amigans.net/modules/xforum ... t_id=89019#forumpost89019

@Kas1e

I've made some tests on a Sam440ep o/c at 733 Mhz with M9 Radeon chip.

Here are the results :

MUI-Mplayer Non AltiVec OS4Depot 2011 Release P96_PIP :

BENCHMARKs: VC: 35.842s VO: 13.608s A: 0.000s Sys: 0.380s = 49.830s
BENCHMARK%: VC: 71.9293% VO: 27.3082% A: 0.0000% Sys: 0.7625% = 100.0000%

MUI-Mplayer **Beta6** Non Altivec P96_PIP :

BENCHMARKs: VC: 51.117s VO: 13.516s A: 0.000s Sys: 0.438s = 65.071s
BENCHMARK%: VC: 78.5556% VO: 20.7711% A: 0.0000% Sys: 0.6733% = 100.0000%

Clearly, your new version is slower than the 1st one. Is there anything changed in your code ?

Worse : when trying without any video output and no sound (benchmarking the internal decoding functions), I get these results :

MUI-Mplayer Non Altivec OS4depot 2011 Release :

BENCHMARKs: VC: 36.736s VO: 0.018s A: 0.000s Sys: 0.420s = 37.173s
BENCHMARK%: VC: 98.8230% VO: 0.0474% A: 0.0000% Sys: 1.1297% = 100.0000%

MUI-Mplayer Non AltiVec *Beta 6*:

BENCHMARKs: VC: 53.091s VO: 0.019s A: 0.000s Sys: 0.465s = 53.575s
BENCHMARK%: VC: 99.0970% VO: 0.0353% A: 0.0000% Sys: 0.8677% = 100.0000%

Actually the slowness doesn't come from the video output but from the internal decoding functions.

@KL
dunno why it like this, i didnt touch core. if it also not related to video output.. maybe some 3d party libs i link with, like ffmpeg ones, but dunno if it used for internal decoding.

you 100% compare non-altivec versions ? can ypu put a line for internal check you do, so i can test myself as well ? all previpus betas starting from first the same or it happens since some ?

@Kas1e

No problem.

To test only the decoding engine : mplayer -benchmark -vo null -nosound yourvideo.avi

Since I'm testing on my Sam440, I can assure you that I'm only using the non AltiVec version

Yes, from the 1st Beta it got slower than the OS4Depot Release.

I too guess that it's coming from ffmpeg (which is the decoder). MorphOS users told me during the Amigateries event that newer MPlayer versions are slower than previous ones.

If Fab reads this thread, i could confirm or not.

@K-L

Not really. It very much depends on the codec, some were sped up a great deal too. Regarding H264, i regularly compare it against a test video, and it's only marginally slower in the latest version i released on MorphOS (2% or so...).

@All
Need some discussion about iconify/close gadgets and other gadgets in muimplayer.

Question is: do we need at all close/iconify gadgets in the video windowses at all ? I mean, should't be video output window just have resize gadget and that all ? And then, iconify/close gadgets of gui will worry about video output as well.

I of course can make all video outputs to have close/iconify/depth gadgets, but are they need it at all in video output window ?

My idea just to make iconify/deiconify from main gui to worry about video outputs too (so they will be iconifed/deiconifed all together like one single app). The same as close gadget will be one : in gui, which will close everything at once (as it now), just there will be no misleading close-gadget in video-output window (i.e. same as on all players on all oses where gui not embedded and video output done in separate window).

Dunno through if it ok to do it like this ? I can of course add in every output the same gadgets (close/iconify/depth/resize) , and make close gadget to close only video window, iconify to iconify everything (together with main gui) and so on, but then it kind of illogical : to have close gadget to close only window, but to make iconify to iconify all (making iconify only for video window separately from gui, will broken feel of whole app as standalone, like it will be 2 different apps to control).

In brief, there is imho 2 logical ways:

1. have all gadgets here in video output windowses, but then they all reacts the same as gui ones to make it be the same by feel: close gadget close everything (as it now), and iconify iconify everything too.

2. no gadgets in video outputs at all (same as for example in bsplayer on winxp), just a resize window. No misleading close/iconify buttons (only in gui, which will take care of video output window at the same time as for main gui).

For me way 2 looks better as it will be same as in all modern players on all oses, where video didn't embedded with gui as well as it looks imho more clean.

The way which i basically do not want to go is to have all gadgets in video output windowses, but make them reacts only for video output window (like close for close it only, or like iconify to iconify video output only). As it just make it all looks like we have 2 apps at time with different control.

@kas1e

vote for #2

@kas1e

Quote:

Yes we need a close gadget into the video window, because (an example) what about if one decide to use or (re)compile an MPlayer version without any GUI ?

The same regarding the depth gadget, in any case that 2 gadgets are needed for sure and imho they are not redundant even if we might have another one into the GUI

The zoom gadget is indeed the most needed there (in video win) as it can be placed only there !
So at the end even this one should be included (altrough now it's doesn't seems to work correctly in MUI MPlayer, but this is another story..)

So at the end the only thing to valuate carefully might be the iconify one, in my opinion you can put it in video window and also mantain the other one in GUI, the important is that both gadget will react in the same way, so regardless of which iconify gadget you pressed you should have the same result (all iconified: video window and GUI window)

But in alternative if users prefer you might remove the iconify gadget from the video windows and use the iconify gadget of the GUI to iconify both

(This might be the best solution acceptable for everyone and every taste)

Quote:

Yep this of course should be consistent, all drivers should have the same type of gadgets in video window, and all gadgets should react exactly the same in any driver output

@kas1e

On My PegII MuiMplayer b6 work good but if i select SDL play an Mkv and press pause on the guy the system freeze.

This dont become on P96_pip

@samo
Quote:

Fab's code will be not in repo as he don't want it, so that not point. I will commit changes which are "ok" for everything, not those ones which mui-mplayer-only.

Quote:

Check bsplayer on winxp (or any other player). They didn't have close gadgets (or any gadgets) at all in video outputs and all feels ok and logical.

Quote:

As you read it is last thing i want to do. I want to remove them all, and try to see if there enough ppls who say ok for that :) Its just crappy extra work to deal with all of them, add unnecessary checks in all the places and double (and/or split) the work they do.

@tsolm
Check afxgroup's mplayer and liveforit one with sdl on that video: it probably will be the same , and if is it, then sdl driver problem.

@kas1e

Quote:

Did you mean like that ? http://silverxtcdragon.homestead.com/files/FreezingBSPlayer.jpg

Well that's orrible imho and neither standard at all, how about if i need to highlight an object that still in background of the video window ?
In this case we would need a depth gadget for that don't you ?

The zoom gadget is needed too because having that you can enlarge the window at the max dimention of your screen, conversely you can only have two states: real fullscreen and window mode only (atleast you decided to resize it manually all the time)

Quote:

No extra work at all, we already have all the gadgets and all of them are working already, the only one you might remove (and this can be the real extra work as it doesn't work properly now) is the iconify one .. well just remove that one and that's done!

Quote:

Yes.

Quote:

I like it.

Quote:

You just make window active by clicking on it, as usual. I personally never use depth gadget, as it quite long procedure to got window you need, its much easy to do it via clicking and activating it (same as on all other desktops).


Quote:

I already make iconify works for both windowses at one time (thanks to Thore), that one is no problem now. Problem for me is close gadget , which when stays on video window looks like "close me only". And then, it close everything. But, if make close gadget to close only video window, then, have iconify be iconified everything kind of broken whole logic. That why i think about removing all gadgets to avoid misleading.

If have all gadgets here in video window, they all should reacts the same by logic (or for video window only, which is suck, or for everything, which is ok). But then, close gadget which close everything, kind of suck as well, as user expect only video window to be closed. And , if make it like this, then logic borks again : close for only close window, but iconify for iconify everything. But making all gadgets reacts only for video window, split whole programm on 2 parts. And thats again why i think about removing all gadgets.

From all of this come to make it like this: have all gadgets, but:

-- close gadget close only video window.
-- iconify gadget iconify everything (does not matter if it pressed in mplayer gui, in mplayer menu, or in video output)
-- depth/resize as before.

But dunno, i don't like it.

@All
Anyone else ? Ideas/opinions and stuff

@samo79 Quote:
I agree, that would be horrible. Please at least have a title bar with a depth gadget. No need for iconify gadget, although I personally see no harm either.

One reason for depth gadget: AmigaOS is not like other common desktop OSes, in that the active window is NOT always the front-most window. Therefore clicking on the window will NOT bring it forward, thus we need the depth gadget.

@ChrisH

Yes, we need a title bar in order to move the window on the WB

Otherwise, I'm like Kas1e : I hate that when I press the close button on the video window it closes the whole program.

@kas1e

Quote:

Yes of course i'm with you on that, close gadget in video window should close the video window only, not the entire player
But in meantime good that you fix the iconify to make both iconify gadgets 100% consistent to each others

So now we might have two eventual solutions:

1 - Found a method to solve the problem you have with the close gadget in video window (but it seems at the end you don't like so mutch this solution and indeed thinking more i start to understand you point of view!)

2 - Just eliminate the close gadget from the video window but mantaining all the other gadgets on that (and they all already works)

In the event you will applicate the point 2 we might have that final result:

1 - In GUI window: The close gadget that will close all
2 - In video window 3 gadgets only:

a) Iconify gadget (when pressed with iconify video window and GUI window)
b) depth gadget (with move in background or foreground the video window)
c) zoom gadget (will increase the window at max size)

Quote:

Point 2 might be a good compromise between our 2 ideas

@samo
i can build some test driver of few versions:

1. titlebar + depth gadget only
2. titlebar + iconify/resize/depth gadgets
3. all as 2 , but + close gadget
3a. close gadget which close all (as it now)
3b. close gadget which close only video window

so we can see what cleaner/better

@K-L

I have some relief, as probably i found that your benchmarks are a bit false.

As you say you use "mplayer -benchmark -vo null -nosound yourvideo.avi", which if you didn't have progdir:conf/cofnig will be taken with printing of numbers to console, which slowdown benchmarking. The problems is "-quite" option which you miss.

So, you probably test some versions just from ram: or something without config file , and another ones fully unpacked with conf files in progdir and co.

I.e. that how it prints to console if you have conf file (or provide "-quiet" option in comamnd line):

Quote:

See, there nothing betwen VO: line and BENCHMARK. And now, if we put binary to ram (or anywhere) and we not specifcy "-quiet" to command line (as probably you do):


Quote:

See those values after VO: string, with V: => those are realtime if you didn't specify "-quiet" by config or in command line.

On my simple video, its just differences between 14% and 23%. So probably that what make you worry.

And in end of all, i do proper tests of everything (aos4 release from os4depot, aos4 beta6, and latest morphos version) , and results are:

line to test:

Quote:

beta6 no altivec:
BENCHMARKs: VC: 13.414s VO: 0.020s A: 0.000s Sys: 1.129s = 14.562s
BENCHMARK%: VC: 92.1110% VO: 0.1381% A: 0.0000% Sys: 7.7509% = 100.0000%

release from os4depot no-altivec
BENCHMARKs: VC: 13.579s VO: 0.022s A: 0.000s Sys: 1.055s = 14.655s
BENCHMARK%: VC: 92.6551% VO: 0.1471% A: 0.0000% Sys: 7.1978% = 100.0000%

Morphos latest mplayer no-altivec (by-adding -noaltivec)
BENCHMARKs: VC: 13.369s VO: 0.021s A: 0.000s Sys: 0.874s = 14.264s
BENCHMARK%: VC: 93.7259% VO: 0.1496% A: 0.0000% Sys: 6.1245% = 100.0000%

So, as you can see, speed are 1:1 the same and between os4 versions, and its the same on morphos too.

In sake of test i even do check altivec versions of os4release from os4depot, and current morphos one, and:

os4release altivec:
BENCHMARKs: VC: 10.771s VO: 0.023s A: 0.000s Sys: 1.030s = 11.823s
BENCHMARK%: VC: 91.0960% VO: 0.1911% A: 0.0000% Sys: 8.7128% = 100.0000%


latest morphos release altivec
BENCHMARKs: VC: 10.924s VO: 0.021s A: 0.000s Sys: 0.863s = 11.809s
BENCHMARK%: VC: 92.5100% VO: 0.1798% A: 0.0000% Sys: 7.3103% = 100.0000%

So, bottom line is: use -quite for test. As well as everything the same betwen all releases on os4, and its the same by speed as on morphos.

Of course, i leave some "maybe wtf its not that", but plz, retest it all. As on my HW everything as it should be. But i thinks is it, because i change nothing in core, as well as ffmpeg libs are used the same (i rechecked, and they builds/links right inside of mplayer, so they the same and for release version, and for new betas).

ps. afxgroup/liveforit mplayers seems by default in "quite" mode, so that can explain difference also. In other words, for every tests you do (that include all your pervious benchmarks thread) , use "-quite" option in command line to avoid any mistakes.

@kas1e

Ok, I'll reissue all my tests tonight and come back to you

But for information, all my MPlayer versions are in the same drawer (they just have different names) and I test them all by the same way with the same video in the same drawer too.

@K-L
At least that only one explain , because if it all same on my HW, then only moon phase can be if not that. Or maybe some other options enabled/disabled. Just in sake of truth, also do those tests in ram, with only binary, just with "-quite" added (so we will skip then all possible config-files problems, etc).

@kas1e

A bit OT considering that you are working on something else, but in MUI MPlayer did you tried the option: Video/Window dimention ?

In that menu we have:

- Ignore --> default
- 50%
- 100%
- 200%

I tried to select another on the fly (when a video is running) but it doesn't seems to work (atleast nothing change for what i can see)
It's normal or is there somethings broken on it ?