no more cropping while watching tv in normal mode? (1 Viewer)

[tourettes]

\MediaPortal\mediaportal\Core\guilib\Geometry.cs -- AdjustForCropping()

if (( Math.Abs( destAspect - sourceAspect ) < 0.001 ))
return;


That's the reason, now someone should find a better fix for the Mantis 1042 issue (some avis are black). Ziphnor maybe?
I'm unable to reproduce the issue here, cropping in normal zoom mode is working fine.

 

[jaobr]

After removing the changes in revision 14671 I for some tv channels and crop
settings get black video. I noted that in mediaportal.log file when this happens
the "PlaneScene: dst" have strange x coordinates (-10,0)-(730,556).

2007-06-26 19:31:32.062500 [Info.][12]: PlaneScene: x, y : 0, 0
2007-06-26 19:31:32.078125 [Info.][12]: PlaneScene: crop T, B : 1, 3
2007-06-26 19:31:32.078125 [Info.][12]: PlaneScene: crop L, R : 3, 3
2007-06-26 19:31:32.078125 [Info.][12]: PlaneScene: video WxH : 720x576
2007-06-26 19:31:32.078125 [Info.][12]: PlaneScene: video AR : 768:576
2007-06-26 19:31:32.078125 [Info.][12]: PlaneScene: screen WxH : 720x556
2007-06-26 19:31:32.078125 [Info.][12]: PlaneScene: AR type : Normal
2007-06-26 19:31:32.078125 [Info.][12]: PlaneScene: PixelRatio : 1
2007-06-26 19:31:32.078125 [Info.][12]: PlaneScene: src : (3,1)-(717,573)
2007-06-26 19:31:32.078125 [Info.][12]: PlaneScene: dst : (-10,0)-(730,556)


This happens when the width is adjusted and get greater than the ScreenWidth.

I've changed the code so when the newWidth > screenwidth the height is
recalculated instead. I dont't know if this is the best way to fix the error but is
solves my problems.


if (heightNeeded > ScreenHeight && strictKeepAspect)
{
//Log.Info("CROPADJUST: NOT ENOUGH HEIGHT, ADJUSTING WIDTH");
rDest.Height = ScreenHeight;
int newWidth = (int)(newDestAspect * rDest.Height);
rDest.Width = newWidth;

if (newWidth > ScreenWidth) // New check for screen width
{
rDest.Width = ScreenWidth;
rDest.Height = (int)(rDest.Width / newDestAspect); ;
}

}
else
{
rDest.Height = heightNeeded;
}

 

[MPUserFromGER]

Hi.

can anyone include the changes from jabor into SVN?

I really would like to have the copping back because using ffdshow instead causes very high CPU usage...

Thanks and best regards,

Andreas

 

[crackerbox]

bump!

 

[ziphnor]

Just to provide a little background here:

Originally Geometry.cs didnt handle cropping at all, i added the code for cropping Geometry.cs in connection with adding the AutoCropper plugin. I did this because the previous handling of cropping would simply crop the source rectangle, but not alter the target rectangle, resulting in some aspect ratio problems if the crop was more than a few pixels (which it frequently is with the autocropper).

I guess i made a mistake in that code ( i suck at geometry causing Mantis issue 1042 (MyVideos: Black Screen on some files in fullscreen Normal-Zoom-Mode), leading to a fix which i guess removed the cropping capabilities in normal mode.

I will take a look at this as soon as i get a chance, but that will be this weekend at the earliest. I wouldnt be surprised if jaobr's addition fixes the problem. It would be just like me to forget to a check like that

 

[and-81]

ziphnor:

If you put jaobr's code in, please re-check it against mantis issue 1042. There was a demo file for issue 1042 on the ftp I believe, which consistently caused the bug pre-fix.

If it brings back the bug then don't keep the change. I believe this current bug is the lesser of two evils.

If it brings back the bug then I think we need one of the dev's to make a big effort and finally get to the bottom of this. That might end up being me, but seeing as it's your code ...

Good luck,

 

[brunoh]

Thank you very much for the updates.

I will be patient as long as I know it has not been forgotten. Luckily my production-machine with a pre 0.2.3RC1 SVN-Version runs stable.

Best of luck, I can imagine that is not easy.

Bruno

 

[ziphnor]

ziphnor:
If you put jaobr's code in, please re-check it against mantis issue 1042. There was a demo file for issue 1042 on the ftp I believe, which consistently caused the bug pre-fix.

Will do. Thank you for pointing that out.

If it brings back the bug then don't keep the change. I believe this current bug is the lesser of two evils.

Agree

If it brings back the bug then I think we need one of the dev's to make a big effort and finally get to the bottom of this. That might end up being me, but seeing as it's your code ...

I will do my best to get to the bottom of it myself. It shouldnt be that complicated, its just a matter of maintaining the ratio between the source and target aspect ratio correctly without accidentally producing negative coordinates . As i mentioned earlier, its just me being geometrically challenged

 

[ziphnor]

Okay, i hope its fixed now.

I adjusted the Normal zoom mode to calculate the source and destination directly based on the aspect ratio of the cropped source, instead of first calculating it based on the the full source aspect and then adjust it.

I also added some sanity checking on the CropSettings.

The changes have been made as of revision 15177 of Mediaportal (the server has nothing to do with this).

I did my best to test it, but i have some unrelated problems with the Test.avi file listed under mantis 1042, so i couldn't use that for testing. If you should encounter a black screen take a look at the entries in your log looking like this:
PlaneScene: src : (3,1)-(717,573)
PlaneScene: dst : (-10,0)-(730,556)

The numbers should all be non-negative, and smaller than the video size / screen size (src / dst respectively).

Just to summarize the current state of the zoom modes in regards to cropping:
The Normal zoom mode will give correct aspect ratios no matter how much you crop. The original zoom mode will ignore cropping entirely, always using the whole video. The rest will compute the destination rectangle based on the full source image, and then apply cropping to the *source* rectangle only, meaning they are not suitable for use with large crop values (they will stretch the image for example).

 

[brunoh]

Hoi ziphnor

Thank you very much. Cropping works here again in normal zoom-mode. I do not have to look at the ugly wide garbage any longer.

I have been away for the weekend, so I have not yet tested much, but sofar it looks good.

Bruno