@Varthall
Quote:

I understand your frustration with the slow pace of the work on MPlayer, in the last months my free time has been very limited, and unfortunately I cannot estimate how much I'll have in the future, I'm sorry I'm making all of you wait :(

Yeah, the only reasson why i worry about its that our version develops pretty slow :( In general, i think that all what we need now, its just fix crashes on exit (by removing deps on pthreads), and just add full gui (as far as i remember, you say to me in pm that some parts of gui already works ?)

Quote:

Any work on MPlayer is of course welcome, if you wish you can submit any work on the MPlayer SVN, or work on your own. If you decide for the latter, you can check the code of what has been fixed in the meanwhile (basically, for now the vertical sync problem). From my side I'm continuing to work on the port, still no idea about a release date yet though.

In general i think there will be problem to merging everything together. I.e. we need or just choice MUI as gui, or choice reaction as gui , and so it mean we need to replace all the gui code in fab's port. So i think in end of all, if we will have 2 versions it will be good. Just need to make them working fine, and no crashes , and both with full normal gui (gmplayer imho the best one).

Check this out how mui-mplayer works on morphos: screenshot. For me it looks pretty good, and even if aos4 port will have full gui parts , they still will different, and more of it , there will be no those windowses and all fancy gui stuff.. And 2 versions from different authors with different gui its good too :)

But sure, at some stage we need to re-use code of all the possible solutions and make all the best.

Related to vsync problem - dunno, but very possible that mui-mplayer will not have that problem, because it use CGX with all that stuff .. Also as i see our current public ra-mplayer use SDL for everything ?

@Tuxedo
Btw, just to add about non-releasing mui : there is also some moment, that its need some beta-testing before release. For example, when i and deniil was sure that mui have no bugs, then, mui going to beta-testers, and new bugs is founded and fixed.

The one more reasson of not releasing it : Thore still works on it every day, and trying to implement some more fancy stuff. So , i think better still a bit wait , and have better mui (i basically very hope for buttons for lists, as it visually pretty cool, like NList).

Check 2 screen:

plain list without button
nlist

So, maybe our mui for update3 will even have List which looks like Nlist (visually it much much better, and even it clickable, navigatable, sortable and so on).

Last edited by kas1e on 09-Jun-2011 at 09:29 PM.
Last edited by kas1e on 09-Jun-2011 at 09:14 PM.

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

@Varthall

Quote:

Varthall wrote: @kas1e I understand your frustration with the slow pace of the work on MPlayer, in the last months my free time has been very limited, and unfortunately I cannot estimate how much I'll have in the future, I'm sorry I'm making all of you wait :( Any work on MPlayer is of course welcome, if you wish you can submit any work on the MPlayer SVN, or work on your own. If you decide for the latter, you can check the code of what has been fixed in the meanwhile (basically, for now the vertical sync problem). From my side I'm continuing to work on the port, still no idea about a release date yet though.

As kas1e said, I think what is most important to fix or remove the pthreads dependancy because either it crashes (and klicking Kill brings down the machin) or it hangs on a semaphore wasting about 13MB RAM for eah instance (8MB exe + 5MB stack).

IMO: Fix that and release so it at least can be used.

Thinking about it, this only seems to happen when mplayer is executed from ClipDown/getVideo, not from MPlayer-GUI!

This is how I execute it from MPlayer-GUI using CreateNewProc() (where it always seem to work):
NP_CommandName,(long)"MPlayer"},
NP_Arguments,(long)s},
NP_Name,(long)"MPlayer main process"},
NP_Seglist,seg},
NP_FreeSeglist,TRUE},
NP_StackSize,p.istk},
NP_CloseOutput,!outtocon},
NP_CloseError,!outtocon},
NP_Cli,TRUE},
NP_Child,TRUE},
NP_NotifyOnDeathSigTask,NIL},
NP_CurrentDir,cd}, //this is a Lock() on the exe path
NP_HomeDir,hd}, //this is a DupLock on 'cd'
NP_Output,outtocon?IDOS->Output():IDOS->Open("NIL:",MODE_OLDFILE)},
NP_Error,outtocon?IDOS->ErrorOutput():IDOS->Open("NIL:",MODE_OLDFILE)}


Then I have 3 other major annoyances with the current version but they can be worked around for now:

2. A lot of videos fail to align horizontally. Perhaps that is what you meant about the "vertical sync problem". Using SDL output fixes that, but it's slower of course. Sometimes forcing a monitor or video aspect fixes it too. Usually these videos have a less common size it seems.

3. Some wmv files get a lot of green artifacts in them. This does not happen with an older version (MPlayer SVN-r29068-4.2.3) so I have to switch to that version for most wmv files.

4. Sometimes when mplayer is too slow to keep the video up with the audio it looses the audio completely and then gradually slows down to a halt and usually cannot quit after that. Is that also a pthreads problem?? Communication faliure between audio and video tasks..?

A built-in GUI really doesn't have a priority for me, and is also irrelevant with these major bugs still in there, particularily the pthreads problem.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.