Hyperion Entertainment Message Boards

I think to have found the reason why MPlayer (almost the ReAction version) will create that strange white stripes around the video window when you try to watch a video in fullscreen (Video output setted to --> "Default" in MPlayer GUI)

This seems caused by the recent drop shadow functionality introduced in one of the latest OS4 updates, in general i can have the compositing active without any problem, however these 2 specific options related to the drop shadow must be turned off (shadow on windows and shadow on title screen) in order to watch a video with MPlayer without any extra glitch

After some test i'm quite sure that there is a bug somewhere in the drop shadow functionality that create that white stripes ..
Please tester can you check if that solve the problem also on your system ? And if so and if the bug is confirmed can we open a ticket for it ?

Did you mean problem the same and with reaction versinon and with mui version , when overlay mode is used, right ?

If so, how you disable only shadows but keep compositing ? All what i found for now, its in prefs:gui/effects few areas "windows drop shadows" and "screen tittle bar drop shadow" , in which i can't disable shadow, but can set X/Y to 0. And so i do it, save, reboot : and mplayer still show white background instead of black one.

Then i disable compositing, save, reboot, and tryed same video again : background are black.

So, if for sure related to compositing, but i dunno how to disable shadows while compositing is ON. I can raise a BZ on compositing already, but better if you can show what steps (step by step) need to do to have compositing enabled, but disabled shadow and have black background in mplayer.

I never noticed the problem because I use 16 bit screens but I tried some tests to reproduce the problem. I get stripes at the bottom and top of the screen too. I also noticed another problem: I can't change WorkBench screen resolution after playing a video. It seems that MPlayer or MPlayer-GUI is keeping a lock on the WorkBench screen.

kas1e wrote:Did you mean problem the same and with reaction versinon and with mui version , when overlay mode is used, right ?

Sadly not as it seems that MUI version you port handle that in a different way, so even without drop shadow active you will still live with all that strange white stripes, i can say also that on MPlayer MUI version all looks even worse as the stripes are bigger and more invasive--> so problem is bigger aswell even if maybe caused by another thing or another specific option in compositing !

For now i did my test with the Reaction port only, so my thread and all step is more related to that version, i will check later if disabling the entire compositing will cure also the white stripes on the MUI port, however i can say that there is a workaround almost for MPlayer MUI, just changing the aspect ratio for any video to 16:10 and all goes better, of course not the best solution but atleast you will not have these horrible stripes anymore ! ...

(Take note that I always use p96_pip as video driver in MUI MPlayer and overlay is active of course)

kas1e wrote:If so, how you disable only shadows but keep compositing ? All what i found for now, its in prefs:gui/effects few areas "windows drop shadows" and "screen tittle bar drop shadow" , in which i can't disable shadow, but can set X/Y to 0. And so i do it, save, reboot : and mplayer still show white background instead of black one.

Then i disable compositing, save, reboot, and tryed same video again : background are black.

So, if for sure related to compositing, but i dunno how to disable shadows while compositing is ON. I can raise a BZ on compositing already, but better if you can show what steps (step by step) need to do to have compositing enabled, but disabled shadow and have black background in mplayer.

It's easy Roman, just set all the shadow items to 0 --> including X/Y coordinates and so on, border color can still black or any other color you have by default (here default is black and maybe it's black also on your system) so you don't need to change it as it will NOT used if you had ticked at 0 all the others, so in short the only important thing is to be sure that all item options in drop shadow section will be ticked to zero, then any eventual background color for the shadow will be ignored

This should disable any drop shadow functionality from your system but at the same time mantaining the compositing engine active for any other use

@samo79

t's easy Roman, just set all the shadow items to 0 --> including X/Y coordinates and so on,

Yes, that what i already do as i say in previous mail. But in case with mui-mplayer that didn't make any differences, and only disabling of whole compositing make background to be again black, without those strange white parts. Will write BZ to compositing about.

@xenic

I test now on 16bit screen with compositing on/off:
-- with compositing ON/16bit screen: left part of background are black, right part of backgorund are white
-- with compositing OFF/16 bit screen: all black.

So seems its all about compositing, just in 16 bit screens it happens on 50% less.

It seems that MPlayer or MPlayer-GUI is keeping a lock on the WorkBench screen.

Overlay code in the muimplayer i get from reaction version of player (i.e. code which handle overlay on both mplayers are the same), so pretty possible that if there is some bugs, they of course present in both versions (as i change in general nothing in overlay code, only adapt it a bit). There is overlay code of mplayer, you can check this out if you care.

@samo
Btw, did it works on previous updates as it supposed to work ? After which update those problems start ?

kas1e wrote:@samo
Btw, did it works on previous updates as it supposed to work ? After which update those problems start ?

Problem exactly start from AmigaOS 4.1 Update 1, aka since they introduce the drop shadow feature

@kas1e

I test now on 16bit screen with compositing on/off:
-- with compositing ON/16bit screen: left part of background are black, right part of backgorund are white
-- with compositing OFF/16 bit screen: all black.

I think your results might depend on your monitor aspect and MPlayer settings. I just have black borders at the top and bottom of my MPlayer screen in 16bit mode. However, If I change the MPlayer Video Tab "Monitor Aspect" setting to 4x3 instead of default, then the video fills the screen with no top/bottom borders and compositing or drop shadows are not an issue. Try setting the "Monitor Aspect" to match your monitor and see what happens.

Start a video with "Start Paused" selected. Then leave the MPlayer screen open and go back to WorkBench and open Ranger. Go to GUI/Objects in Ranger and check the MPlayer screen settings. It's opening a "LikeWB" screen which means that compositing and dropshadows will be turned on if they are on for WorkBench. Then take a look at the size of window on the MPlayer screen. When the MPLayer/Video "Monitor Aspect" is set to default, the MPlayer window is 1280x960 while the screen size is 1280x1024. If MPlayer uses a backdrop window that is smaller than the screensize then the system will attempt to add dropshadows below the dragbar and the window. My conclusion is that MPlayer should not be using a "LikeWB" window unless it is using a backdrop window that fills the entire screen. I suspect that MPlayer used the "LikeWB" screen before compositing was added to the system because it had no negative effects at that time. Now it probably needs to be changed. However, it probably wouldn't hurt to have someone who has access to the OS4 code and the MPLayer code to see if some changes to OS4 are needed.

kas1e wrote:@samo79

t's easy Roman, just set all the shadow items to 0 --> including X/Y coordinates and so on,

Yes, that what i already do as i say in previous mail. But in case with mui-mplayer that didn't make any differences, and only disabling of whole compositing make background to be again black, without those strange white parts.

Did you also set all five sliders to 0, not only the x/y gadgets?

Best regards,

Niels

@kas1e

So any news then ?
Did you ask devs to fix it (if fixable) or atleast did you open an internal bugreport for this bug ?