Thanks for detailed rapport. I did have some problems after some changes in vo_comp, so I decided to simplify, I think you might find that it does not gray out if you resize the window, anyway I think I have fixed it now.
As for your over-scan screen issue I don't know what this is, but I think it should work the same. should not be any difference between a over scan screen and a normal screen, I will look at it, and try to understand what goes on, but I expect this to be a OS bug.
Edited by LiveForIt on 2014/5/22 13:35:19
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
ddni : I don't think so. AHI-DEV should be the best.
When using MPlayer-GUI with LiveForIt-Mplayer 5.1, when I quit a video the GUI doesn't work normally.
Formerly, when stopping a video, the STOP button went grey and the START button became active agin. This is no more the case and the START button stays inactive even when the video is stopped.
So we can only play one video with MPlayer-GUI. When closin the GUI, we then get an AREXX message regarding a child process or something like that.
It's been a long time since I have not made any tests but I had few free time, sorry
The AREXX implementation was wrong in Mplayer, MPlayer was sending error codes instead of returning normal results, the GUI has not caught up with the change and need to be fixed as well.
It should be easy for Danial add features like vertical slider for things like volume now.
Now RC will be 0 on success, and RC -3 if command is not found, results will be text string that's a numbers or text, the string most not be freed by the ARexx client (Mplayer GUI).
Danial can check if the Result is NULL or not, if the Result is NULL then its the old mplayer abusing RC and RC2, if its not NULL then its the newer LiveForIt-Mplayer.
and so he most use sscanf( ptr -> Result "%d",&rc) on numbers, and just copy the result from ptr->Result if its text.
The fix was needed because RC codes =>20, breaks ARexx scripts, and so you can execute more then one Arexx command.
Edited by LiveForIt on 2014/5/22 20:43:50 Edited by LiveForIt on 2014/5/22 20:44:21 Edited by LiveForIt on 2014/5/22 20:50:15 Edited by LiveForIt on 2014/5/22 20:56:06 Edited by LiveForIt on 2014/5/22 21:02:15 Edited by LiveForIt on 2014/5/22 21:05:06 Edited by LiveForIt on 2014/5/22 21:09:19 Edited by LiveForIt on 2014/5/22 21:10:05
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
I get that issue with mplayer gui too. There is a menu option in the gui to say mplayer crashed on me. This resets the gui and allows another video to be played.
You can add the AREXX scripts included to AmiDock or a subdocky as a workaround
Mplayer is no longer is a solo player, it can cause some problem if you open more then one mplayer as the AREXX port is numbered. “mplayer.1” “mplayer.2” and so on.
Mplayer gui will always talk with mplayer.1
Edited by LiveForIt on 2014/5/22 21:42:18 Edited by LiveForIt on 2014/5/22 21:43:18
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Some French Sam460 users with Radeon HD have reported that when playing a movie, when they move the window many times on the WB, the video disappear (is shrinked actually).
Now RC will be 0 on success, and RC -3 if command is not found, results will be text string that's a numbers or text, the string most not be freed by the ARexx client (Mplayer GUI).
PLease use the proper values as defined in the arexx headers, function not found should generally be an RC of 20! (certainly it is from arexx.class)
#define RC_OK 0L /* success */ #define RC_WARN 5L /* warning only */ #define RC_ERROR 10L /* something's wrong */ #define RC_FATAL 20L /* complete or severe failure */
Quote:
Danial can check if the Result is NULL or not, if the Result is NULL then its the old mplayer abusing RC and RC2, if its not NULL then its the newer LiveForIt-Mplayer.
and so he most use sscanf( ptr -> Result "%d",&rc) on numbers, and just copy the result from ptr->Result if its text.
The fix was needed because RC codes =>20, breaks ARexx scripts, and so you can execute more then one Arexx command.
What are you talking about?
There are two results in an arexx message
msg->rm_Result1
indicates error status 0 is sucess > 0 is error or warn condition
and msg->rm_Result2
if rm_Result1 is 0 then rm_Result2 id a string (if present) and if rm_Result1 is not 0 then it's an error number.
If that's is what you meant but explained badly then fair enough, but otherwise you will be breaking working programs that can send ARexx commands (incluidein scripting languages like REXX itself or python).
It's also the message sending application (the GUI in this case) resposibilty to free the all the argstrings *and* the result2 if present. (test for Result1 is not NULL ofcourse incase RC2 is a number not a string).
Maybe you ought to arexx.class so that you get this stuff right?
indicates error status 0 is success > 0 is error or warn condition
and msg->rm_Result2
if rm_Result1 is 0 then rm_Result2 id a string (if present) and if rm_Result1 is not 0 then it's an error number.
MPlayer uses “struct ARexxCmd *cmd“
struct ARexxCmd
{
STRPTR ac_Name; /* Command name */
UWORD ac_ID; /* Unique ID */
/* NOTE: The function pointed to by ac_Func() will be called
* with parameters in CPU registers. Register usage
* is as follows:
*
* VOID ac_Func(struct ARexxCmd * cmd, struct RexxMsg * rm)
* A0 A1
*/
VOID (*ac_Func)();
STRPTR ac_ArgTemplate; /* DOS-style argument template */
ULONG ac_Flags; /* Unused, make NULL */
ULONG *ac_ArgList; /* Result of ReadArgs() */
LONG ac_RC; /* Primary result */
LONG ac_RC2; /* Secondary result */
STRPTR ac_Result; /* RESULT variable */
};
this is what Autodocs says:
ac_RC (int32)
Primary result, the RC variable. Also causes the RC2
variable to return and will cause RESULT to NOT be set.
ac_RC2 (int32)
Secondary result, the RC2 variable. This will not be set
unless RC is non-zero.
ac_Result (STRPTR)
RESULT variable, this should be a string. If you want to
return a number you will have to convert it to a string
first. This string will not be set if RC is non-zero.
So docs says is that ac_RC2 should not be set unless ac_RC is set (>0).
This how interpreted how the RC/RC2 codes worked after reading the autodocs.
Errors = ac_RC and ac_RC2. Result = ac_Result
if ac_RC >0 then ac_RC2 gives more detailed error code.
so there for I return ac_RC=0, ac_RC2=0 and ac_Result = AREXXRESULT; where AREXXRESULT is text string with the result.
I tested that it worked only whit AREXX scripts to see that they did not fail, and that it returned correct values.
Quote:
If that's is what you meant but explained badly then fair enough, but otherwise you will be breaking working programs that can send ARexx commands (include scripting languages like AREXX itself or python).
It was breaking AREXX scripting, they who worked on mplayer before used RC to return the mplayer command id, so when mplayer command id was 20 or more the scripts failed.
the First thing i tried was to just set RC = 0, and use RC2. I do not remember way it did not work, but I guess it did not, as I changed it.
Quote:
but otherwise you will be breaking working programs that can send ARexx commands
It's not my fault that Mplayer and MplayerGUI was useing RC/RC2 codes in a undocumented way. All other AREXX programs should work, that follow the autodocs guidelines should work perfect.
Edited by LiveForIt on 2014/5/24 8:43:35 Edited by LiveForIt on 2014/5/24 8:46:05 Edited by LiveForIt on 2014/5/24 8:46:44 Edited by LiveForIt on 2014/5/24 8:53:33 Edited by LiveForIt on 2014/5/24 9:12:16 Edited by LiveForIt on 2014/5/24 9:23:22
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
I inherited that, if I were writing it today then I would make it 20, but the important point is that >10 which triggers an error which arexx has to deal with (the script can set a handler or just fail depending level of sophistication).
Quote:
MPlayer uses struct ARexxCmd *cmd
That's a high level structure, so you must be using an api like arexx.class to return it then? Which are you using?
Quote:
This how interpreted how the RC/RC2 codes worked after reading the autodocs.
Error = ac_RC ? ac_RC : ac_RC2;
basically if ac_RC was 0 then error code ac_RC2 was used.
so there for I return ac_RC=0, ac_RC2=0 and ac_Result = AREXXRESULT; where AREXXRESULT is text string with the result.
I tested that worked only whit AREXX scripts to see that they did not fail, and that it returned correct values.
Okay it depends a little on your command set but it should work something like this:
say you have a command 'PLAY' with template FILE
scripts sends
'PLAYME'
wrong command set ac_RC = 20 (if your using arexx.class it wil do that for you)
scruipt sends
'PLAY FILENAME "foo"'
wrong template set ac_RC = 10 (again arexx.class does that you don't even see the command was sent).
'PLAY FILE "foo"'
write template but foo does not exist.
set ac_RC = 5 (warn an that something didn't go as planned) and RC2 to a more informative error code to say what went wrong (the mplayer error code perhaps or some custom code)
'PLAY FILE "foo"'
all went swimmingly and "foo" is playing
ac_RC = 0 and ac_Result to whatever info PLAY might return on sucess as a string (framecount time resolution whatever is relavent).
A script would then test RC (or rm_Result1 if a C program) and act accordingly.
Quote:
It was breaking AREXX scripting, they who worked on mplayer before used RC to return the mplayer command id, so when mplayer command id was 20 or more the scripts failed.
That does sound wrong, but ofcourse a script can set the failat value (via the pragma command IIRC) and a handler for errors.
Weird : when benchmarking, the CPU is at 50% and not 100% so the video is not played at full speed and so the benchmark is not acurate (of course it is the fastest when playing a video).
Same behaviour (only 50% CPU used so the benchmark is not acurate)
Regading the bug with Sam460 and Radeon HD, reverting to 4.2 doesn't show the bug so it was introduced with 5.1. Since I have no 460 I cannot test (doesn't happen on X1000 obviously).
ARGB looks to be the winner on all systems and graphic cards, I got some conflicting results when first switched to ARGB, that's way I added RGB support as option.
Its really strange that P96 is in fact slower then comp, on the other hand it gains nothing from AltiVec its just vanilla assembler code whit out any AltiVec optimization code.
I don't know if FFMPG can be used on the vo_P96_pip, but if it can you might see some improvements from AltiVec.
Quote:
Weird : when benchmarking, the CPU is at 50% and not 100% so the video is not played at full speed and so the benchmark is not acurate (of course it is the fastest when playing a video).
Well its a good thing if its not 100%, as then your mouse/keyboard and so will not work. p96_pip uses vsync so max speed is around 60fps, I guess.
I guess we need a novsync option to check.
Anyway I don't know what task pri mplayer runs at, but it might possible increase it a tiny bit.
Edited by LiveForIt on 2014/5/24 10:06:51
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
P96_PIP is the fastest of course but when benchmarking it doesn't use the whole CPU power but only 50% of it. When benchamrking it should use all the power available otherwise the benchmark will be wrong (it works like that woth any other version of MPlayer)
When benchmarking with vo comp, the CPU is always at 100% without any limit.
Maybe it's due, like you say, to a vsync limit (is this what prevents tearing ?).
Luckily, when playing a video, P96_PIP is the fastest video output with the less CPU demanding.
When benchmarking with vo comp, the CPU is always at 100% without any limit.
vo_comp does not have vsync.
I don't know if this is the issue or not, but i think its what it is. Anyway you will get drop in cpu load because your not decoding and playing audio.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
LiveForIt : no it's actually vsync which prevents from benchmarking p96_pip (limited to 60 FPS).
When benchmarking there won't be any drop in CPU usage since we are benchmarking and the video will be played as fast as it can without audio and use the whole CPU power to acheive this.
The is the principle of benchmarking.
The only way to benchmark p96_pip with vsync is to benchmark a huge video which already eats up all the CPU resources.
No difference (I get the same results as with 5.1) using novsync option. P96_PIP still stays in sync (60 FPS).
For comp I get the same results too.
Anyway, it's not that important since it works (it's just we cannot benchmark correctly). P96_PIP from Joerg still allows benchmarking by the way. I hope he releases it soon
Edited : testing with -vo comp I've found that if I add -vsync in Mplayer option, I do not get anymore tearing with compositing (and benchmarking gives the exact same behaviour as with P96_PIP)
Comp whit out vsync run faster here, then comp with vsync, it should be the same with p96_pip, I don't have time check what goes on today, I might look at it some other day.
Edited by LiveForIt on 2014/5/25 20:48:13
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
