Cropping and resizing Backdraft

[quake74]

Hi all, I just bought Backdraft (here in Italy, so PAL) and here are the first few lines of the d2v generated


DGIndexProjectFile11
4
G:\backdraft\VTS_01_1.VOB
G:\backdraft\VTS_01_2.VOB
G:\backdraft\VTS_01_3.VOB
G:\backdraft\VTS_01_4.VOB

Stream_Type=1
MPEG_Type=2
iDCT_Algorithm=3
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=4:3
Picture_Size=720x576
Field_Operation=0
Frame_Rate=25000
Location=0,0,3,BD2F9


Both MeGUI and Staxrip suggest cropping 100 lines at the top and the bottom, which gives me 768/(576-200)=2.04 (yes, it's wider than a 16:9 and the dvd isn't even anamorphic). Staxrip suggests using 608x288 while MeGUI (the avisynth script creator) suggests 608x336 (megui says it's a 4:3 PAL). Why such a big difference of aspect ratios? Why not 608x304?

Edit: FYI, AutoGK chose 432x224.

[berrinam]

Why such a big difference of aspect ratios?I don't know about StaxRip, but MeGUI is overly restrictive when it comes to Aspect Ratios and suggesting a resolution. It will round your true aspect ratio (which you claim is 2.04) to the closest of 1.0, 1.33 (4:3), 1.66, 1.78 (16:9), 1.85 and 2.35. While this is good in some situations, as it will trade a small aspect error for a full-screen display, this can cause problems if the true aspect ratio is too unusual, as it is in your situation.

People generally say that a 5% aspect error is the limit of acceptability, so I will modify MeGUI's behavior to check if this limit is exceeded, in which case it will follow the 'ITU resizing' method, which maintains AR perfectly at the cost of possibly unusual resolutions.

Why not 608x304?Perhaps because a mod32 resolution is preferable to a mod16? Just guessing, though -- no idea, really.

[berrinam]

http://forum.doom9.org/showthread.php?p=813022#post813022
MeGUI now defaults to ITU resizing if the aspect error is exceeded. Using this, testing an input aspect ratio of 2.04 and horizontal resolution of 608 does indeed suggest 608x304.

[GodofaGap]

I think it is noteworthy that StaxRip suggested to correct resolution here. ITU defines an active picture size of 702x576 for PAL. So for AR = 4:3 and a frame size of 720x576 the corrected square pixel resolution should be 788x576 (not 768x576). This results in AR after cropping of 788/376 = 2.096 and using 608 as width would give you a frame size of 608x290 which becomes 608x288 to make it mod16.

Of course this only holds if you follow ITU to the letter. :)

[quake74]

I think it is noteworthy that StaxRip suggested to correct resolution here.

Well, if we are following mod16 then 608x304 is the "correct" one. BTW, I don't know what ITU resizing is, but it looks to me like another can of worms like command line vs VFW so I will just enjoy my ignorance ;) And I will download the latest MeGUI berrinam, thanks.

[GodofaGap]

No, 608x290 is the correct resolution for your video (ITU-wise). If you make that mod16 the height should be rounded down to 288.

[stax76]

Well, if we are following mod16 then 608x304 is the "correct" one.

608x288 -> AR Error = -0.77
608x304 -> AR Error = 4.75

StaxRip detects and calculates this correct, you can test it easiliy using Gordian Knot.

[berrinam]

ITU defines an active picture size of 702x576 for PAL.
...
Of course this only holds if you follow ITU to the letter. :)
Aaah, I see. I misunderstood what ITU resizing was -- I just assumed it meant exact calculations of the size (the 'common sense' method), as opposed to rounding to fit the standard screen sizes, as MeGUI did. Turns out there is more to it than I realised.

I remember that Doom9 said he didn't want ITU resizing in MeGUI. I don't know why, but I'll just leave it how it is at the moment. I have not noticed any aspect ratio problems in my encodes, but perhaps MeGUI has been doing it wrong all along. I might look into ITU resizing a bit more in the future.

[GodofaGap]

Well, using your resize method you would get 608x304, so the error is under 5% as you mentioned earlier. In any case, certainly not worth it to worry sick about. :)

[stax76]

5% might not be so small and there might be other error sources that might add to this error like a crappy player. StaxRip pulls the red card if it's more then 2% off but I really can't tell where it starts to get critical because I never made a test or didn't read anything about it. Fixing the error with cropping or at least partly is quite popular however.

[quake74]

608x288 -> AR Error = -0.77
608x304 -> AR Error = 4.75

StaxRip detects and calculates this correct, you can test it easiliy using Gordian Knot.

:confused: Maybe I calculate the AR error in a different way, but if the original is 2.04 and 608/288=2.11 and 608/304=2 the absolute difference is smaller to 2 rather than to 2.11. If I did my calculations correcly, 2.11 is 3.4% larger than 2.04 and 2 is 1.96% smaller than 2.04. :confused:

[GodofaGap]

quake74: I explained how the AR should be calculated via ITU standards in my first post. The "ITU"-AR = 2.096, not 2.04.

[quake74]

quake74: I explained how the AR should be calculated via ITU standards in my first post. The "ITU"-AR = 2.096, not 2.04.

Yes, you're quite right :) Thanks!