AutoGK - Wrong Input PAR (a bug?)

[girotour]

I think I've found a little bug in AutoGK regarding the Input PAR setting (the parameter which, in avs file, is called "fixed_aspect").

The source file I'm trying to convert is an MPEG2 file recorded from the sat. It has the following characteristics:

Resolution: 704x576
PAR: PAL non anamorphic (4:3)

This means that the input PAR should be 16/15 = 1.067 if you don't follow the ITU resize method or 128/117 = 1.094 if you follow it.

Now, it seems that AutoGK doesn't use any of these two values. It simply "stretches" the horizontal width to 768 px setting the PAR to 768/704 = 1.091.

So, the resulting file will be a little bit stretched (+2% horizontally) than the original one.

[Brother John]

AutoGK uses the PAR values defined in MPEG-4. They differ slightly from the ITU values. This is common practice for MPEG-4 encodings. In fact I have never seen any tool using the exact ITU values (even if they call it “ITU”).

PAL 4:3 = 12/11
PAL 16:9 = 16/11
NTSC 4:3 = 10/11
NTSC 16:9 = 40/33

AutoGK is correct because 704 * 12/11 = 768. It’s nothing to worry about, though. Because of enforcing mod16 resolutions you don’t get an absolutely accurate AR anyway.

[girotour]

Hi Brother John and thank you for your answer.
Leaving the mod16 problem alone for a moment, I don't understand why to use the MPEG-4 PAR when the input stream is not an MPEG-4 stream and it doesn't use that kind of PAR.
I remember that with the old (and glorious :)) Gordian Knot it was possible to set the input PAR to "PAL non anamorphic 4/3" and, in that case, the values used were actually:

16/15 without "ITU option" checked
128/117 with "ITU option" checked.

[Brother John]

Oh, yes, shit, you’re right! *shocked* And I though for years GK used MPEG-4 PAR!

Why MPEG defined values different form ITU, well, that’s a question you’ll have to ask MPEG.

And why use them?

For resized PAR 1:1 output:
Really no good reason not to use exact ITU figures. But mod16 makes the question an academic one.

For non-resized anamorphic MPEG-4:
– Anything but the four default values above are an out-of-the-way custom PAR as far as the MPEG-4 bitstream ist concerned. Probably a minor issue, if at all.
– ASP can’t store most of the exact ITU PARs (except PAL 4:3) because of a bitstream limitation.
– H.264 doesn’t have this problem.

[girotour]

Hi Brother John.
Sorry, but I don't think my question is simply academic.
I'll try to show, with a real example, how the "wrong" input PAR will produce a wrong result which could be avoided using the "right" input PAR.

I've this MPEG2 file whose resolution is 704x576 and whose original PAR is 16/15.
For the output resolution I choose a fixed width of 640 px and, since I prefer not to use the automatic crop feature of AGK, I manually set the crop to:

threshold=0
left=2
right=2
top=4
bottom=12

Now, let's take a look, step by step, at the .avs file produced by AGK.

cropclip = autocrop(movie,mode=0,wmultof=4,hmultof=4,samples=10,aspect=0,threshold=0,samplestartframe=0,
leftadd=2,rightadd=2,topadd=4,bottomadd=12)
fixed_aspect = 1.09090909090909

With these parameters, AGK computes the following

c_width = width(cropclip) --> 700
c_height = round(height(cropclip) / fixed_aspect) --> 513
input_par = float(c_width)/float(c_height) --> 1.(364522417153996101)

then

out_width = 640
out_height = round(float(out_width) / input_par) --> 469
hmod = out_height - (floor(out_height / 16 ) * 16) --> 5
out_height = (hmod > 4) ? (out_height + (16 - hmod)) : (out_height - hmod) --> 480

and finally

new_aspect = (float(out_width) / float(out_height)) / fixed_aspect --> 1.(2)

Now "new_aspect" is passed to the autocrop filter

autocrop(movie,mode=0,wmultof=4,hmultof=4,samples=10,aspect=new_aspect,threshold=0,samplestartframe=0,
leftadd=2,rightadd=2,topadd=4,bottomadd=12)

which produces an output stream whose resolution is 684x560.

So, just to summarize, I started with a resolution of 704x576 which should be cropped to 700x560, but, with this "new_aspect" has been cropped to 684x560.

Scaling it to out_width x out_height (in this case 640x480) will produce a file which is horizontally stretched.

(684 * (16 / 15)) / 560 = 1.30(285714)
640 / 480 = 1.(3)

Now, let's try the same example with the "right" PAR

fixed_aspect = 1.0666666666666666666666666666667 --> 16/15
c_width = width(cropclip) --> 700
c_height = round(height(cropclip) / fixed_aspect) --> 525
input_par = float(c_width)/float(c_height) --> 1.(3)
out_width = 640
out_height = round(float(out_width) / input_par) --> 480
hmod = out_height - (floor(out_height / 16 ) * 16) --> 0 (i.e. "mod16" will not introduce any error)
out_height = (hmod > 4) ? (out_height + (16 - hmod)) : (out_height - hmod) --> 480
new_aspect = (float(out_width) / float(out_height)) / fixed_aspect --> 1.25

When this "new_aspect" is passed to the autocrop filter, it produces an output stream whose resolution is 700x560.

Scaling it to out_width x out_height (in this case 640x480) will produce a file which perfectly matches the original ratio.

(700 * (16 / 15)) / 560 = 1.(3)
640 / 480 = 1.(3)

This is the reason why I think that AGK should use the original PAR instead of the MPEG-4 one.

[Brother John]

16/15 is the generic PAR. That’s different from the ITU/MPEG issue. See here (http://forum.doom9.org/showpost.php?p=1058927&postcount=11).

You said you set manual crop values. Then autocrop shouldn’t be in the script at all. I’m not familiar enough with AGK to judge this, but it’s definitely unrelated to PAR.

Let’s calculate: After cropping you have 700×560 with a PAL 4:3 PAR.

ITU
playback width: 700 * 128/117 = 765,81
scaled res: 640×468
apply mod16: 640×464

MPEG-4
playback width: 700 * 12/11 = 763,64
scaled res: 640×469,33
apply mod16: 640×464

Generic
playback width: 700 * 16/15 = 746,67
scaled res: 640×480
apply mod16: 640×480

You can see the ITU/MPEG difference is irrelevant. Iirc there’s an option in AutoGK to switch between generic PAR and ITU/MPEG PAR.

[girotour]

16/15 is the generic PAR. That’s different from the ITU/MPEG issue. See here (http://forum.doom9.org/showpost.php?p=1058927&postcount=11).
Hey, great link! It contains some useful info. Bookmarked! :)

You said you set manual crop values. Then autocrop shouldn’t be in the script at all. I’m not familiar enough with AGK to judge this, but it’s definitely unrelated to PAR.
I agree with you, but this is the script that AGK produces.
It is related with the PAR only because the variable "fixed_aspect" (which contains the PAR value) is the base to calculate the variable "new_aspect" which is used by autocrop (I don't exactly know how and why since it should only crop black borders).
And autocrop, depending on the value of "new_aspect", produces output streams with different resolutions (in my example with the "wrong" PAR, the resolution was 684x560 which means an error of about 2.3%).