Beta 3 of MPlayer from Joerg with p96_pip: BENCHMARKs: VC: 36.848s VO: 4.853s A: 0.000s Sys: 0.755s = 42.456s BENCHMARK%: VC: 86.7918% VO: 11.4308% A: 0.0000% Sys: 1.7775% = 100.0000%
Beta 9 of MUI MPlayer from kas1e with p96_pip: BENCHMARKs: VC: 51.120s VO: 12.343s A: 0.000s Sys: 0.500s = 63.963s BENCHMARK%: VC: 79.9214% VO: 19.2973% A: 0.0000% Sys: 0.7812% = 100.0000%
Would be nice, but that's impossible. There may be small differences because of the different MPlayer versions and compiler options, but the VC speeds can't be that different because of it. I'm only working on the VO, nothing else. Looks like you are using something like "lavdopts fast=1:skiploopfilter=all" in conf/mplayer.conf when using my version but not when using Roman's.
Would be nice, but that's impossible. There may be small differences because of the different MPlayer versions and compiler options, but the VC speeds can't be that different because of it. I'm only working on the VO, nothing else. Looks like you are using something like "lavdopts fast=1:skiploopfilter=all" in conf/mplayer.conf when using my version but not when using Roman's.
You right for sure, I am also surprised for such difference ! I searched now and it was because i copied your exe in the same directory of the LiveForIt archive, and in that config settings he use: skiploopfilter=all so my test was affected by that ..
Edit: Infact now results are completely different, see the old post
It's a bug in libSDL, it crashes in the SDL_SYS_CreateThread() function.
Ok undestand, Roman recently fixed an unrelated issue in SDL, if you have an idea of how to fix this one i think you can report your SDL problem to him
As we are here still also another long standing bug in sound, this one was present also in the original version from afxgroup
In menu: Audio Option --> Mute
Doesn't work
That and the "Stay on Top" menu can only work if the ARexx support is built in, but I didn't add it to my MPlayer version. I'll remove the menu items which depend on ARexx. My new vo_pip.c is based on the old vo_p96_pip.c I implemented for Andrea's MPlayer 1.0-pre8, I don't use any code from the code.google.com MPlayer, the only exception in beta5 was ao_sdl.c and that may be the reason it doesn't work correctly, I'll switch back to the original MPlayer version.
That and the "Stay on Top" menu can only work if the ARexx support is built in, but I didn't add it to my MPlayer version.
Ok, so that means the "mute" problem in the old version from afxgroup was caused by a bug in his ARexx implementation ?
Quote:
I don't use any code from the code.google.com MPlayer
But do you plan to do so at some point or atleast commit/merge your changes in Google site ? Current code in Google already have all the missing parts you might need and that parts were present in the old version from Andrea but not yet on yours (double click for fullscreen, drag&drop, ARexx etc..)
Quote:
the only exception in beta5 was ao_sdl.c and that may be the reason it doesn't work correctly, I'll switch back to the original MPlayer version.
Instead of SDL (that it's also broken now) do you think it will be possible to use the AHI code from the kas1e version ?
Current code in Google already have all the missing parts you might need
Except for MPlayer itself I wont reimplement my pip vo for the old MPlayer version there.
Quote:
Instead of SDL (that it's also broken now) do you think it will be possible to use the AHI code from the kas1e version ?
I can't use anything from the code.google.com MPlayer or any other old MPlayer port as long as they aren't updated to the to the current MPlayer version, using the rest of the old code with a current MPlayer version will very likely cause even more problems than using the code.google.com ao_sdl did.
If you are using the os4depot.net SDL and ao_sdl works in your MPlayer versions it's obviously the other way round
os4depot version of libsdl are old. Last one are on code.google and should be used 100%, there was some necessary bugs fixed. I use it with all my ports, and also for sdl output in muimplayer (together with SDL files from latest official mplayer sources) and everything works, and no crashes in terms of sound.
Quote:
I can't use anything from the code.google.com MPlayer or any other old MPlayer port as long as they aren't updated to the to the current MPlayer version, using the rest of the old code with a current MPlayer version will very likely cause even more problems than using the code.google.com ao_sdl did.
ahi_dev output will works without problems with any version (at least i tested with few). I can test and with latest one, but i assume that all make no sense to worry about sdl fixes, or about ahi addon. Just skip all those suggestions imho, as all what we need its your new vo_p96_pip.c shared somewhere (does not matter where and how), so i from my side can just implemnt it to muimplayer with no probs.
Or, if you want to check it with sound, just grab ahi_dev.c , it will works for sure with any mplayer version. At least, the fact that i use sdl sound output files (sdl_common.c and ao_sdl.c) , from mplayer sources of 04.04.2014, that mean the way of handling sound outputs are the same and didn't changed, so ahi_dev from google code can be used (basically, that ahi_dev is not "from google code", but its from morphos version of mplayer, liveforit just for some reassons submit it on google code).
@samo
Quote:
Apart the new p96 driver, do you think it will be possible to update to the new r37148 revision code (updated by Joerg) to be use directly into your current MUI port ?
Maybe it's possible that using a recent version some problems related to the corrupted video will be "auto-fixed"...
Yep, probably core can be updated later. But i feel demotivated now, because liveforit didn't share vo_comp, in which i was in interest, and because of what i share with him fixed cgx_wpa. Probably we need someone else (again and again) who can make vo_comp and 100% share code.
And btw, imho don't throw on joerg all possible bugs from everywhere, we lucky that he works on vo_p96pip.c improvements, and cleary you should't expect new mplayer with every possible addon in it. Later you will ask him to write gui ?:) Let's just wait when he done with p96 overlay drivers, and be in hope he will share that with us, by any of ways, and there will be no stop factors to share code.
And, sadly, we seems will not have vo_comp.c sources, so probably if someone want to see muimplayer with it, we need someone else who will make it and normally share what he do. Damn, the same and the same again and again. Probably 120 version of mplayer is better :)
@Joerg Will you in interst to make vo_comp.c , but with 100% sharing of code ? (we can make some bounty, etc).
Edited by kas1e on 2014/4/20 16:21:27 Edited by kas1e on 2014/4/20 16:28:43 Edited by kas1e on 2014/4/20 16:30:30
but i assume that all make no sense to worry about sdl fixes, or about ahi addon. Just skip all those suggestions imho, as all what we need its your new vo_p96_pip.c shared somewhere
Quote:
And btw, imho don't throw on joerg all possible bugs from everywhere, we lucky that he works on vo_p96pip.c improvements, and cleary you should't expect new mplayer with every possible addon in it. Later you will ask him to write gui ?:)
Yeah that's true, i ask him only considering the current situation, but i know that theorically we wouldn't have any need of an entire new (full) version from him but just his updated components..
2 versions (at max) would be more than enough imho, your separated MUI port AND the afxgroup one (that could be just replaced with a final merged based release containing the latest modifications of both forks of LiveForIt and Joerg)
This in an ideal world of course ..
Quote:
Yep, probably core can be updated later. But i feel demotivated now, because liveforit didn't share vo_comp, in which i was in interest, and because of what i share with him fixed cgx_wpa. Probably we need someone else (again and again) who can make vo_comp and 100% share code.
Quote:
Probably 120 version of mplayer is better :)
Argg hope not, It would be better to just convince them to share their source