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

tourettes

Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    \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

    Portal Member
    November 6, 2006
    22
    5
    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

    MP Donator
  • Premium Supporter
  • July 31, 2006
    403
    3
    Germany
    Home Country
    Germany Germany
    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
     

    ziphnor

    Retired Team Member
  • Premium Supporter
  • August 4, 2005
    755
    13
    Copenhagen
    Home Country
    Denmark Denmark
    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

    Retired Team Member
  • Premium Supporter
  • March 7, 2005
    2,257
    183
    Melbourne
    Home Country
    Australia Australia
    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

    Portal Pro
    August 8, 2004
    82
    2
    Home Country
    Switzerland Switzerland
    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

    Retired Team Member
  • Premium Supporter
  • August 4, 2005
    755
    13
    Copenhagen
    Home Country
    Denmark Denmark
    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

    Retired Team Member
  • Premium Supporter
  • August 4, 2005
    755
    13
    Copenhagen
    Home Country
    Denmark Denmark
    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

    Portal Pro
    August 8, 2004
    82
    2
    Home Country
    Switzerland Switzerland
    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
     

    Users who are viewing this thread

    Top Bottom