Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > (Auto) Gordian Knot

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th February 2008, 14:08   #1  |  Link
girotour
Registered User
 
Join Date: Dec 2002
Posts: 23
AutoGK - Wrong Input PAR (a bug?)

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.
girotour is offline   Reply With Quote
Old 14th February 2008, 15:06   #2  |  Link
Brother John
(schein)heilig
 
Brother John's Avatar
 
Join Date: Jun 2003
Location: Germany
Posts: 512
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.
__________________
Brother John

When lost in BeSweet's options, have a look at the Commandline Reference.
DVD nach MPEG-4 klappt nicht? Verzweifelt? Auf zum Encodingwissen!
Brother John is offline   Reply With Quote
Old 14th February 2008, 21:39   #3  |  Link
girotour
Registered User
 
Join Date: Dec 2002
Posts: 23
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.
girotour is offline   Reply With Quote
Old 15th February 2008, 00:44   #4  |  Link
Brother John
(schein)heilig
 
Brother John's Avatar
 
Join Date: Jun 2003
Location: Germany
Posts: 512
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.
__________________
Brother John

When lost in BeSweet's options, have a look at the Commandline Reference.
DVD nach MPEG-4 klappt nicht? Verzweifelt? Auf zum Encodingwissen!
Brother John is offline   Reply With Quote
Old 15th February 2008, 11:22   #5  |  Link
girotour
Registered User
 
Join Date: Dec 2002
Posts: 23
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.

Code:
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

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

Code:
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

Code:
new_aspect = (float(out_width) / float(out_height)) / fixed_aspect --> 1.(2)
Now "new_aspect" is passed to the autocrop filter

Code:
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

Code:
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.

Last edited by girotour; 15th February 2008 at 13:33.
girotour is offline   Reply With Quote
Old 15th February 2008, 13:53   #6  |  Link
Brother John
(schein)heilig
 
Brother John's Avatar
 
Join Date: Jun 2003
Location: Germany
Posts: 512
16/15 is the generic PAR. That’s different from the ITU/MPEG issue. See here.

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.
__________________
Brother John

When lost in BeSweet's options, have a look at the Commandline Reference.
DVD nach MPEG-4 klappt nicht? Verzweifelt? Auf zum Encodingwissen!
Brother John is offline   Reply With Quote
Old 15th February 2008, 14:42   #7  |  Link
girotour
Registered User
 
Join Date: Dec 2002
Posts: 23
Quote:
Originally Posted by Brother John View Post
16/15 is the generic PAR. That’s different from the ITU/MPEG issue. See here.
Hey, great link! It contains some useful info. Bookmarked!

Quote:
Originally Posted by Brother John View Post
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%).
girotour is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 07:04.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.