@K-L

"noref" is actually a typo. I corrected it in the config in 1.0.1, it's supposed to be "nonref" and skips more frames.

@ddni

It's quite possible that the reason it's keeping up is because of skiploopfilter=all which degrades the quality of the video a bit. Thanks for your compliment though :)

@benny

Thanks.

I've not looked at or touched that part of the code before, but yeah it seems wrong. I'll take a closer look later on.

@shadowsun

My own computer is a Sam440ep-Flex 800mhz with a Radeon 9250. I'm curious if LiveForIt-MPlayer 6.5.7 is working for you.

Can't remember if it was you or someone else who gave me that input.conf. You'd prefer up/down to be 1 minute increments? I'm open to changing that in input.conf

It's a different input.conf, so that's probably why. Seems like up/down is +1/-1 and left/right is -10/+10.

I was going to download it from https://www.rarlab.com/rar_add.htm

Edit: Unfortunately it uses a lot of functions not in our SDK, such as swprintf.

I've uploaded a release candidate of 1.0.1 to sendspace and linked it in post #1.

I've had a report that the altivec version is crashing when opening the About window and moving the video window around the screen (especially with p96_pip). Can someone else test this please? Thanks in advance.

Edit: Specifically MP4 videos with AAC audio. Crash apparently happens with LiveForIt-MPlayer 6.5.7 also. Interesting.

Edit 2: It may just be one specific video with this issue, and not related to p96_pip at all.

I'll have a look at the latest open source UnRAR and see if it can be easily ported.

@Raziel

For some reason I thought there was a difference between 1 and 2 Runs. You can use Run >T:PID program >T:Out.txt and the process ID will output to T:PID, return to shell when T:PID has been written (no delay needed) and T:Out.txt will contain the output from the program. You won't know when the program has finished running though. PIPE: might come in handy if it makes ReadLn() wait until there's new data.

@Raziel

A line like "Run <>NIL: Run >T:PID program" is going to need a very small delay before you read T:PID, because it's going to exit to shell first before T:PID has been written. I haven't tried it in an AmigaDOS script myself, but that's probably the issue.

It'll probably work if you used T:PID instead of PIPE:PID

It was sort of a joke answer anyway. It might work, but looks unprofessional :)

The Run command will give you the process number of the command it's running, so "Run >T:PID programhere" will send the process number to T:PID, although you probably want to run the server and return to shell, hence "Run <>NIL: Run >T:PID programhere"

Edit: I don't know what I was thinking with two Runs 1 is sufficient.

Message sent.

@samo79

I have the source. I'll take a look, but there might be reasons why it's not working properly, and to "fix" it could cause other problems.

Do you have IRC, FB or Skype?

Easy!

Run <>NIL: Run >PIPE:PID programhere

Break "`rx "Open(A,'PIPE:PID','R');SAY Strip(Word(ReadLn(A),2),,']');Close(A)"`"

*cough*

@samo79

I guess that's why it was disabled! Perhaps I'll leave the option available but have it off by default (I know you're saying it's like that already, but it's behaving differently for me).

@Tuxedo and @Severin

The latest binaries in post #1 won't complain about HOME anymore. I uploaded them yesterday so I think you were using an old one. HOME and MPLAYER_HOME aren't used at all.

As for the video being corrupt at the bottom, it could be because of me suppressing an error that would normally stop the video from playing. Does -vo comp_yuv, -vo comp or -vo sdl play the video OK? Let me know, and if it still doesn't look correct in -vo sdl, I'll download it from the link you provided.

Edit: I think this is a p96_pip issue. Will look into it.

It seems like I still need to have altivec functions disabled in ao_ahi_dev2 for some people. Out of curiosity, what soundcard are you using, and what frequency/channel settings in AHI?

Regarding the benchmarks, I don't understand why they'd be different from OS4Depot to now if you're using -nosound. When you were testing the latest beta, were you using the same config file? If "conf/config" is not present, you won't get the same results as the OS4Depot release. (Edit: Looks like this was the case)

@Plexus

A bug report really needs to be more detailed if you want any hope of a fix, and I need to know if it performs any worse than LiveForIt-MPlayer 6.5.7. All you've done is compared mine to Emotion, but not to any other version of mplayer.

By the way, if you edit the config, change the typo from "noref" to "nonref", uncomment that line, and comment the previous skiploopfilter line, you might then have better results? :) Maybe?

@Plexus

All I care is that it works at least as well as LiveForIt-MPlayer 6.5.7 :)

Check post #25 regarding the screenshot stuff.

@samo79

Ahh you mean when you right-click? I'm out of the house at the moment but I can check that later. Don't worry about reporting the other stuff to Denill just yet.

@samo79

Hi,

Check my edit above. Found the cause of the version prob.

Pause option is working fine here. I know if there's 100% cpu usage, there could be issues sending/receiving AREXX signals. Or if you're trying to compete with the GUI by pressing space in the window and making the GUI get confused.

Which checkbox? "Start paused"? That's the only checkbox I see. I'm not the author of the GUI though.

@samo79

That's where I was looking too. Interesting that it's fine here with the same version of MPlayer-GUI.

The Stay on Top functionality for p96_pip has been commented out. I'll ask why first before I enable it again.

Edit: Found the issue. MPlayer-GUI doesn't clear the line properly when switching binaries. So that must mean you're loading up MPlayer-GUI that has a version of mplayer with a longer version line, then switching over to my binary with a shorter version line.