Correct AR From 720 To 576

[Master Yoda]

Just playing around with re-encoding some movie and game trailers from 264 to dvd, the demuxing and encoding I'm fine with I just have a query about getting the AR correct. For example if the trailer is 1280x528 what's a good way to go about encoding it correctly ?

I tried this, but it seems a tab off

Addborders(0,96,0,96)
Spline16Resize(720,480)

Fitcd gave me this which seems ok but crops some of the picture off

Spline16Resize(720,368,12,0,1256,528)
AddBorders(0,56,0,56)

Fitcd seems to crop a bit off of 1280x720 and 544 as well.

Is there a way I can resize these down without cropping so I keep the complete image and so the AR is correct?

[mgh]

spline16resize(720,352)
addborders(0,64,0,64)
and encode as a 16:9 DVD
FitCD gives you same figures if you select anamorphic for destination

[Guest]

Consider your 1280x528 trailer.

If the width is going to 720, then the height goes proportionally:

528 * (720/1280) = 297 ~= 296

So you need 480 - 296 of black bars -> 184.

Divide by two for the borders -> 92.

So:

Spline16Resize(720,296)
AddBorders(0,92,0,92)

Or go anamorphic as mgh suggests.

[Master Yoda]

I will be encoding the dvd 16.9 anamorphic, I had anamorphic selected in Fitcd and got
LanczosResize(720,368,0,0,1280,528)
AddBorders(0,56,0,56)

with no cropping selected and

LanczosResize(720,368,12,0,1256,528)
AddBorders(0,56,0,56)

with accurate selected

So any difference between no cropping and accurate about from the obvious of losing a bit of the picture due to cropping.

[SeeMoreDigital]

1280 ÷ 528 gives a movie aspect ratio of 2.4242424242:1

As we all know, DVD's are not encoded using square pixel image frame sizes. However if they were and you wanted to encode to PAL (ITU spec excepted), then: -

1024 ÷ 2.4242 = 422 vertical pixels. So the top and bottom black mattes (aka: borders) need to be: -

576 - 422 = 154 ÷ 2 = 77 pixels.

By contrast, if you wanted to encode to NTSC (ITU spec excepted), then: -

853.33(recurring) ÷ 2.4242 = 352 vertical pixels. So the top and bottom black mattes (aka: borders) need to be: -

480 - 352 = 128 ÷ 2 = 64 pixels.

[rkalwaitis]

So technically if you did an auto crop, cropping in multiples of 16 Then technically using the cropping information I could autoresize to a AR of my choice. Perferrably one close to the video after cropping. This would help to keep a sharper image. Ive been looking for an autoresizer function or plugin, with no success. But you all definately have the knowledge to write a function for it.

[Master Yoda]

1280 ÷ 528 gives a movie aspect ratio of 2.4242424242:1

As we all know, DVD's are not encoded using square pixel image frame sizes. However if they were and you wanted to encode to PAL (ITU spec excepted), then: -

1024 ÷ 2.4242 = 422 vertical pixels. So the top and bottom black mattes (aka: borders) need to be: -

576 - 422 = 154 ÷ 2 = 77 pixels.

By contrast, if you wanted to encode to NTSC (ITU spec excepted), then: -

853.33(recurring) ÷ 2.4242 = 352 vertical pixels. So the top and bottom black mattes (aka: borders) need to be: -

480 - 352 = 128 ÷ 2 = 64 pixels.

Got to ask where did you get the 1024 and 853 from? would I use this same method for other AR like if the trailer is 1280x544 so the dvd encode would be 720x362 with 59 top and bottom.

This would then give me the correct AR when encoded anamorphic?

[poisondeathray]

Got to ask where did you get the 1024 and 853 from?

A 16:9 PAL DVD displays as 1024x576

A 16:9 NTSC DVD displays as 853x480

[SeeMoreDigital]

Got to ask where did you get the 1024 and 853 from? When you play an PAL 16:9 anamorphic DVD, the "non-square" pixel width of 720 is displayed at a "square" pixel width of 1024.

Like-wise, when you play an NTSC 16:9 anamorphic DVD, the "non-square" pixel width of 720 is displayed at a "square" pixel width of 853.


would I use this same method for other AR like if the trailer is 1280x544 so the dvd encode would be 720x362 with 59 top and bottom.

This would then give me the correct AR when encoded anamorphic?Yep.... That's correct

[Master Yoda]

When you play an PAL 16:9 anamorphic DVD, the "non-square" pixel width of 720 is displayed at a "square" pixel width of 1024.

Like-wise, when you play an NTSC 16:9 anamorphic DVD, the "non-square" pixel width of 720 is displayed at a "square" pixel width of 853.


OK.

1280 ÷ 544 gives a movie aspect ratio of 1.88235:1. Lets call it 1.88:1

For a PAL DVD: -

1024 ÷ 1.88 = 544 vertical pixels. So the top and bottom black mattes (aka: borders) need to be: -

576 - 544 = 32 ÷ 2 = 16 pixels.


For an NTSC DVD: -

853 ÷ 1.88 = 354 vertical pixels. So the top and bottom black mattes (aka: borders) need to be: -

480 - 354 = 126 ÷ 2 = 63 pixels.

Sorry to be picky but every time I do 1280 divided by 544 on a calculator I get 2.3529 rather than 1.88.

Either way resizing any of these trailers down I would use the calculation you have used correct?

If the trailer is also 1280x720 which is 1.777777 if my calculation was correct I wouldn't need any borders when going to 720x480 ntsc and 720x576 pal.

One last question if I may, if its 1280x528 which is 2.4242 could I first resize it to 1242x528 first to make it 2.35? or would this look off then?

say in the scrip I went
Spline16Resize(1242,528)
Spline16Resize(*,*)
Addborders(*,*,*,*)

Thanks for the help so far.

[SeeMoreDigital]

Sorry to be picky but every time I do 1280 divided by 544 on a calculator I get 2.3529 rather than 1.88.Sorry, my mistake.... I was multi-tasking :o

Either way resizing any of these trailers down I would use the calculation you have used correct?

If the trailer is also 1280x720 which is 1.777777 if my calculation was correct I wouldn't need any borders when going to 720x480 ntsc and 720x576 pal.Yep, that's correct

One last question if I may, if its 1280x528 which is 2.4242 could I first resize it to 1242x528 first to make it 2.35? or would this look off then?Personally, I would not re-size a 2.42:1 image to 2.35:1


Cheers

[Master Yoda]

Sorry, my mistake.... I was multi-tasking :o

Fair enough, think we have all done that at one point or another.

Personally, I would not re-size a 2.42:1 image to 2.35:1 Personal preference or it can be done but looks off key.

Thanks for all your help, will keep that calculation in a notepad for future reference and so I don't forget it.

[2Bdecided]

When you play an PAL 16:9 anamorphic DVD, the "non-square" pixel width of 720 is displayed at a "square" pixel width of 1024.

Like-wise, when you play an NTSC 16:9 anamorphic DVD, the "non-square" pixel width of 720 is displayed at a "square" pixel width of 853.Both true statements - but only because software players are stupid. Strictly speaking 1024 (and 853ish) are the equivalents of 704, not 720.

Cheers,
David.

[Master Yoda]

Both true statements - but only because software players are stupid. Strictly speaking 1024 (and 853ish) are the equivalents of 704, not 720.

Cheers,
David.

So if that's the case what's the 720 equivalents.

[SeeMoreDigital]

So if that's the case what's the 720 equivalents.Don't worry about it...

In the early day of DVD, the displayed video image rarely exceeded 704 pixels. On a CRT TV you were unable to see the 8 pixels of black (to the left and right of the image) due to over-scan.

Nowadays, the displayed video image occupies all 720 pixels. Which is good news for people viewing DVD's on a PC or HDMI enabled flat panel TV (featuring an over-scan disabling option).

[2Bdecided]

It's got nothing to do with overscan.

At the present time, the wikipedia article on this is excellent...
http://en.wikipedia.org/wiki/Pixel_aspect_ratio

...and the BBC website is fairly clear too...
http://www.bbc.co.uk/commissioning/tvbranding/picturesize.shtml
...though you could debate the exact pixel aspect ratio used for all these calculations.


I believe 1.09211775878 (i.e. (575/702)*(4/3) = 1150/1053) is exact.
I think 1.09 (recurring) (i.e. (576/704)*(4/3) = 12/11) is good enough, and it makes a lot of sense to use it!
I think the very common 1.094017094 (recurring) (i.e. (576/702)*(4/3) = 128/117) makes no sense, because it includes two non-existent half lines in the calculation to get that result.


None of these let 720 pixels be the full image width. A pixel aspect ratio of 16/15 does, but that was just invented by some lazy/ignorant computer programmer and adopted by other lazy/ignorant computer programmers. It simply can't work over an analogue connection - and at the time this was introduced, no one in the home had any digital connections into their TVs, so it's basically a bastard/broken standard. It has no justification.

I'll admit lots of high profile companies are using this approach, and I don't know how HDMI really handles either, but I like 704 better...!

Cheers,
David.

[SeeMoreDigital]

It simply can't work over an analogue connection - and at the time this was introduced, no one in the home had any digital connections into their TVs, so it's basically a bastard/broken standard. It has no justification.It would be nice to think that the PAR values were calculated with the future in mind..... Either-way they are justifiable in the digital world. The PAR values work perfectly.... Anyway, passing and processing video via analogue is "so last century" ;)

[2Bdecided]

The PAR values work perfectlyYou're breaking a well respected rule: "Make things as simple as possible, but not simpler" (after Einstein).

Treating the full 720 pixels as representing the defined aspect ratio is certainly "simple", but it's not even "justifiable in the digital world" - SDI, Rec.601, and most other digital standards don't support this.

Real video cameras in-use in studios throughout the world don't support this.

You can sit on a PC and go "la la la - fingers in ears - this is the true PAR value" if you like - but the cameras taking the pictures are using a different PAR value!


In truth, I think the industry is confused, and probably doesn't care. I think you can find cameras and format converters working to both standards... but only one of them is correct! ;)

Cheers,
David.

[Alex_ander]

The PAR values work perfectly....
The plurality of PAR values derived from clear numbers by different experts for different cases of their lives gives a good lesson: never use PAR numbers for calculations of pixel numbers for DVD (at conversion some file). All necessary and correct data is contained in original/target AR and final standard pixel storage numbers. One usually knows original displayed AR of the material + which part of the image represents it in original file (even if it has wrong proportions for some reason). The final horizontal resizing number for active image part will be 704 (close enough to ITU's 702, if to follow its broadcasting recs) with/without 8+8 pillars, and the vertical active part completely depends on original DAR: if it is standard 4:3 or 16:9 (for anamorphic target), then vertical pixel number should be 576/480, otherwise taken from evident proportions + borders (still without any PAR mythology involved, simply and more safe). If correct DAR of original image is non-standard or unknown, one has to define it experimentally for critical scenes - again without any help from that imaginary PAR thing.

[SeeMoreDigital]

At the end of the day, all any of us are attempting to do is match our sources "movie aspect ratio" when generating anamorphic encodes.....

So I'm interested to know how you guys would deal with this 720x576 MPEG-2 DVD source: -

http://rapidshare.de/files/45659450/MPEG-2_720x576.mpg.html

[smok3]

2Bdecided, good post, but practically in broadcast you have to play safe (to save time, which is always an issue...), so basically fully-filled 720x576 digital file makes most sense here, it will survive all kind of weird switchers and stuff,

a lot of file formats also have non-existent support for 704 version (matrox mjpeg comes to my mind).

Also when conversions are needed most not-so-experienced broadcasters will make at least half-correct conversion to say square pixels format (for web),

cropping away 8 pixels on each side is just way too much to expect (this is from my experience at least, i'am sure things are different somewhere else...)

[2Bdecided]

@smok3,

I understand that "time saving" is a good motive.

The BBC works with (and broadcasts) 720, not always fully filled. They crop 16 pixels from all four sides for iPlayer (web) to avoid any nastiness being visible.

Some UK broadcasters crop to 704 for digital broadcast, simply for slightly increased efficiency.


@SMD,

If I come across fully filled 720, I (like everyone else) do not know what the real PAR is. I'll do whatever is convenient. If there are ~704 active pixels with borders either side (not necessarily equal borders) then I can be more sure what the real PAR is, and know exactly what to do.

Cheers,
David.

[SeeMoreDigital]

If I come across fully filled 720, I (like everyone else) do not know what the real PAR is. I'll do whatever is convenient. If there are ~704 active pixels with borders either side (not necessarily equal borders) then I can be more sure what the real PAR is, and know exactly what to do.When it comes to generating anamorphic encodes from anamorphic sources, as long as the displayed images look the same shape during playback, you don't actually need to know what the "real" movie aspect ratio is!

[Master Yoda]

Interesting read. According to that BBC link 2Bdecided gave when converting to 720x576 1050 should be used rather than 1024, so out of curiosity what would 720x480 be? would adding 26 to 853 to give 879 be correct or is that 26 for 720x576 only. Any way when encoding theses files as long as it looks correct the AR that is I'm happy, can't stand watching something with fat or thin images.

[Alex_ander]

Whatever BBC graphic designers do, using any 'PAR' numbers seems to be waste of time at best. To make correct resizing for a menu picture in ITU understanding, it is quite enough to first crop the source 4:3 or 16:9 image file applying 702/720 coefficient for defining pixel numbers, then simply resize the result to 720x576. E.g. instead of 1024x576 image the source image file for menu should be horizontally 1024x720/702=~1050 (BBC managed to finally get the same result after 7 calculation acts involving 4-digit fractional numbers for 'square/non-square' conversions). Then an ITU-loyal DVD player will produce standard DVD AR calculated at 702 pixel border. In case of video material you don't need that adjustment since you don't want to stretch image towards blanking interval, simply keep it within 704 horizontally at resizing (with or without 8 pixel borders).

[SeeMoreDigital]

...so out of curiosity what would 720x480 be? would adding 26 to 853 to give 879 be correct or is that 26 for 720x576 only. Any way when encoding theses files as long as it looks correct the AR that is I'm happy, can't stand watching something with fat or thin images.Take your choice: -NTSC (720x480) Output

Non ITU 4:3 - 720 x 8: 9 = 640.00
Non ITU 16:9 - 720 x 32: 27 = 853.33

ITU Std 4:3 - 720 x 10: 11 = 654.54
ITU Std 16:9 - 720 x 40: 33 = 872.72

ITU Exact 4:3 - 720 x 72: 79 = 656.2025316
ITU Exact 16:9 - 720 x 96: 79 = 874.9367089

BBC Std 4:3 - 720 x 41: 45 = 656.00
BBC Std 16:9 - 720 x 175: 144 = 875.00

THX Disc 4:3 - 720 x 9: 10 = 648.00
THX Disc 16:9 - 720 x 217:180 = 868.00

[2Bdecided]

@Master Yoda,

The differences we're talking about here are hard to spot. If you compare the most different ones side-by-side you can see a difference, but without a comparison none are so "bad" that you'd watch them on their own and immediately think "this is wrong".

I think this is what you're asking for...

Nearest convenient digital value to exact analogue standard

"PAL" 4x3
PAR = 12/11 = 1.09 recurring
704 x 576 = 768 x 576 square pixel
720 x 576 = 786 x 576 square pixel

"PAL" 16x9
PAR = 16/11 = 1.45 recurring
704 x 576 = 1024 x 576 square pixel
720 x 576 = 1048 x 576 square pixel

"NTSC" 4x3
PAR = 10/11 = 0.90 recurring
704 x 480 = 640 x 480 square pixel (*or 704 x 528)
720 x 480 = 654 x 480 square pixel (*or 720 x 528)

"NTSC” 16x9
PAR = 40/33 = 1.21 recurring
704 x 480 = 854 x 480 square pixel
720 x 480 = 872 x 480 square pixel

Note: All values rounded to nearest mod(2) value. Rounded values are less than 1 pixel away from their exact ITU analogue and digital values. (EDIT: except the last one, where 872 is closer to digital, 874 is closer to ITU analogue, and 870 is closer to SMPTE analogue - take your pick!)

* - All the square pixel resolutions convert to square pixels by changing the width while maintaining the height. For "square pixel" NTSC 4x3 this give a lower resolution (640x480) than the standard (non-square pixel) video resolution (704x480). The 704x528 alternative is useful for maintaining the full resolution, but includes a vertical resize which is non-trivial for interlaced video.


As discussed in another thread, the 704 ones are easier to flag correctly (i.e. specifying the display aspect ratio is easy because the content should fill the display exactly) and are treated more consistently (i.e. PC software players and stand-alone DVD players both treat it correctly), but the 720 ones are now more widely used (most 16x9 commercial DVDs).


At the end of the day, you have to guess whether 704 or 720 pixels are equivalent to the aspect ratio:


If it was originally encoded so that 704 is equivalent to the aspect ratio, then 720 expands to 872 (some people round it the other way to 874 - that's nearly as good).
It it was encoded so that 720 is equivalent to the aspect ratio, then 720 simply expands to 854 (853.3333 if you like).


I've attached a table of calculations for all the options that I think are defensible. It's just too complicated if you ask me!

There's another website (with a good discussion and semi-sensible numbers) here:
http://www.btinternet.com/~perrybits/pages/AspectRatios.htm

The wikipedia article is still fine (though I'd ignore the Rec.601 PAL values):
http://en.wikipedia.org/wiki/Pixel_aspect_ratio

Hope this helps.

Cheers,
David.

[halsboss]

Just wondering if, pragmatically, this table might be of use to dummies like me, based on http://www.pcdoctor-guide.com/wordpress/?page_id=1634 ... eg Say for an NTSC 2.35:1 clip to be displayed on DVD under 16:9, then under 4 in the table below, resize to 720x363 and then add black bars to size 59 to the top and 58 to the bottom, then encode with HCenc as 16:9 ... ?

resizeWidth = 720
resizeHeight = 363
lanczos4resize(resizeWidth,resizeHeight).LimitedSharpenFaster(smode=4,strength=100)
BBtop=59
BBbot=58
AddBorders(0,BBtop,0,BBbot,$000000)

1.A.R. 4x3 PAL BB Top BB Bot
1.33:1 720 x 576 0 0
1.66:1 720 x 461 58 57
1.78:1 720 x 430 73 73
1.85:1 720 x 414 81 81
2.35:1 720 x 326 125 125

2.A.R. 16x9 PAL BB Top BB Bot
1.33:1 538 x 576 0 0
1.66:1 671 x 576 0 0
1.78:1 720 x 576 0 0
1.85:1 720 x 554 11 11
2.35:1 720 x 436 70 70

3.A.R. 4x3 NTSC BB Top BB Bot
1.33:1 720 x 480 0 0
1.66:1 720 x 384 48 48
1.78:1 720 x 358 61 61
1.85:1 720 x 345 68 67
2.35:1 720 x 271 105 104

4.A.R. 16x9 NTSC BB Top BB Bot
1.33:1 538 x 480 0 0
1.66:1 671 x 480 0 0
1.78:1 720 x 480 0 0
1.85:1 720 x 461 10 9
2.35:1 720 x 363 59 58

[2Bdecided]

I'm not convinced by those. For one thing they're all based on the "wrong" 720 value*, but for another, the first one I cross-checked was wrong!

If 720x576 is 4x3 (1.3333:1), then 16x9 (1.7778:1) will be 720x432 - they have it as 720x430.

Not very significant, but not right.

FWIW I think if you have a clip with an arbitrary aspect ratio, the easier way of dealing with it is this. You know the source width, you know the source height, and hopefully you know the source PAR (e.g. 1 for square pixel encodes).

Pick a destination width (e.g. 704), and grab the destination PAR from my post (there's only 4 to choose from for a width of 704). Then:

destination_height = destination_width * (destination_PAR/source_PAR) * (source_height/source_width)
which is exactly the same as...
destination_height = destination_width*destination_PAR*source_height/(source_PAR*source_width)

I'd make the result mod(2) (i.e. round to the nearest even number) and resize to that.

You need two equal black bars top and bottom - just subtract your mod(2) destination_height from 576 ("PAL") or 480 ("NTSC") and divide by 2.

I feel an AVIsynth script coming on...!

Cheers,
David.

P.S. * - (and for 4x3 PAL in the UK at least, it's definitively wrong - there's almost no 4x3 content with 720 active pixels - 4x3 content almost always uses the correct ITU "704" related PAR)

[2Bdecided]

Here you go:

# Script to change picture size and aspect ratio (with optional cropping)
# David Robinson, March 2009.
# This script is provided as-is, no guarrantee.
# Free for non-commercial use. Please share any (useful!) changes / corrections.

# Uncomment one line from each section (by deleting the # at the start of the line)

# Note: this script enforces mod(2) on cropping and resizing - might not be happy if source is not mod(2)


# start with some source, e.g.
avisource("my_video.avi")


# ==================================================
# Get Source Dimensions (DO NOT CHANGE THIS PART)
sX=width(last) # get source width
sY=height(last) # get source height


# ==================================================
# Set Source PAR
# --> uncomment ONE of the following sPAR lines...

# Square pixels (1920x1080, 1280x720, 1024x576, 768x576, 853x480, 640x480, 320x240 etc)
sPAR=1.0

# HDV (1440x1080 widescreen):
# sPAR=4.0/3.0

# SD video with 704 real pixels:

# "PAL" 4x3
# sPAR=12.0/11.0

# "PAL" 16x9
# sPAR=16.0/11.0

# "NTSC" 4x3
# sPAR=10.0/11.0

# "NTSC” 16x9
# sPAR=40.0/33.0

# SD video with 720 real pixels:

# "PAL" 4x3
# sPAR=16.0/15.0

# "PAL" 16x9
# sPAR=64.0/45.0

# "NTSC" 4x3
# sPAR=8.0/9.0

# "NTSC” 16x9
# sPAR=32.0/27.0


# ==================================================
# Set Destination width
# --> uncomment ONE of the following dX lines, or add your own

dX=704 # SD 704 pixels
# dX=720 # SD 720 pixels
# dX=1280 # HD 1280x720 pixels
# dX=1920 # HD 1920x1080 pixels


# ==================================================
# Set Destination height
# --> uncomment ONE of the following dX lines, or add your own

dY=480 # SD "NTSC"
# dY=576 # SD "PAL"
# dY=720 # HD 1280x720 pixels
# dY=1080 # HD 1920x1080 pixels


# ==================================================
# Set Destination PAR
# --> uncomment ONE of the following dPAR lines...

# Square pixels (1920x1080, 1280x720, 1024x576, 768x576, 853x480, 640x480, 320x240 etc)
dPAR=1.0

# HDV (1440x1080 widescreen):
# dPAR=4.0/3.0

# SD video with 704 pixels:

# "PAL" 4x3
# dPAR=12.0/11.0

# "PAL" 16x9
# dPAR=16.0/11.0

# "NTSC" 4x3
# dPAR=10.0/11.0

# "NTSC” 16x9
# dPAR=40.0/33.0

# SD video with 720 pixels:

# "PAL" 4x3
# dPAR=16.0/15.0

# "PAL" 16x9
# dPAR=64.0/45.0

# "NTSC" 4x3
# dPAR=8.0/9.0

# "NTSC” 16x9
# dPAR=32.0/27.0


# ==================================================
# OPTIONAL cropping of source to arbitrary aspect ratio - calculation

# Define variable to prevent a crash (DO NOT CHANGE THIS LINE):
cs=1.0

# --> uncomment ONE of the following cS lines (or add your own) if you want to crop...

# crop to 4x3:
# cS=4.0/3.0

# crop to 14x9:
# cS=14.0/9.0

# crop to 16x9:
# cS=16.0/9.0

# Calculate cropped image size:
cX=(sY/sPAR)*cS
cY=(sX*sPAR)/cS

# Check which side to crop:
cX = (cY>sY) ? cX : sX
cY = (cY>sY) ? sY : cY

# Calculate crop values for sides and top
Xc=round((sX-cX)/4.0)*2
Yc=round((sY-cY)/4.0)*2


# ==================================================
# OPTIONAL cropping of source to arbitrary aspect ratio - cropping
# --> uncomment the next line to do the actual crop:
# crop(Xc,Yc,-Xc,-Yc)


# ==================================================
# Get cropped Source Dimensions (DO NOT CHANGE THIS PART)
sX=width(last) # get source width
sY=height(last) # get source height


# ==================================================
# calculation (DO NOT CHANGE THIS PART):
cdY=dX*(dPAR/sPAR)*(float(sY)/float(sX))
cdX=dY*(sPAR/dPAR)*(float(sX)/float(sY))

# Force mod2:
cdX = round(cdX/2.0)*2
cdY = round(cdY/2.0)*2

# Pick which dimension to shrink...
# This is what it would look like in BASIC:
# if cdY>dY then adX=cdX; adY=dY
# else adX=dX; adY=cdY;

# This is the same in AVIsynth:
adX = (cdY>dY) ? cdX : dX
adY = (cdY>dY) ? dY : cdY

# Calculate padding:
pX = (cdY>dY) ? dX-cdX : 0
pY = (cdY>dY) ? 0 : dY-cdY


# ==================================================
# Perform actual resize
spline36resize(adX,adY)


# ==================================================
# Add borders
addborders(pX/2,pY/2,pX/2,pY/2)


# END

It has all the options, including the 720 ones that I consider "wrong"!

It enforces mod(2) sizes in several places, so non-mod(2) resolutions won't work.

Cheers,
David.

[Alex_ander]

(Apart from the 720 number), the value 363 for image height used by halsboss from that table, is correct (without final rounding for mpeg encode). It doesn't depend on source/destination PAR or width storage numbers (e.g. the result will be the same in case of SVCD, or DVB width) since horizontally picture in DVD mpeg is controlled by AR flag only. Here's how to calculate image height without higher algebra and secondary numbers.

Width/480=C16/9 (1) - anamorphic 16:9
Width/NewHeight=C2.35 (2) - letterboxed
Width here is the final resize value, common for both anamorphic 16:9 and letterboxed 2.35:1 (e.g. 704 for ITU compliance).
C is some proportionality coefficient, evidently the same in both cases.

Dividing (1) by (2):
NewHeight/480=16/(9x2.35)
or:
NewHeight=16x480/(9x2.35)=363
(note: neither C, nor Width is needed for calculation, they are reduced)
After rounding to 364 and using 704 width (close to ITU number for standard TV line sampling) this gives:

LanczosResize(704,364).AddBorders(8,56,8,60)

[2Bdecided]

That looks simpler, but it assumes you know the correct aspect ratio of the original. Which, in turn, assumes you know the width, height, and correct PAR of the original. And that the source will fill the width of the destination (i.e. it's letterboxing, not pillarboxing). And that you don't want to crop.


I usually do what you're suggesting. Or at least, in most specific situations, I usually make assumptions and do the job in one line.

However, the script I posted was for a general situation without assumptions. It saves having to think - uncomment the appropriate lines. It's overkill for simple situations, though it will always work (I think ;) ).

Cheers,
David.

[halsboss]

Hey, great info. Say, for a clip which mediainfo gives this characteristic
Width : 640 pixels
Height : 272 pixels
Pixel aspect ratio : 1.000
Display aspect ratio : 2.35
and the target is display on a 16:9 widescreen TV via NTSC anamorphic DVD (16:9) then, Aledx_ander's method effectively yields
LanczosResize(704,364).AddBorders(8,56,8,60)
and David's effectively yields
sX=640 # get source width
sY=272 # get source height
sPAR=1.0
dX=704 # SD 704 pixels
dY=480 # SD "NTSC"
# "NTSC” 16x9 704 pixels
dPAR=40.0/33.0
cdY=dX*(dPAR/sPAR)*(float(sY)/float(sX))
cdX=dY*(sPAR/dPAR)*(float(sX)/float(sY))
cdX = round(cdX/2.0)*2
cdY = round(cdY/2.0)*2
adX = (cdY>dY) ? cdX : dX
adY = (cdY>dY) ? dY : cdY
pX = (cdY>dY) ? dX-cdX : 0
pY = (cdY>dY) ? 0 : dY-cdY
spline36resize(adX,adY)
addborders(pX/2,pY/2,pX/2,pY/2) which excel calcs out as
sx sy spar dpar
640 272 1.000 1.212121212
dx dy
704 480
cdx cdy
931.7647059 362.6666667
cdx cdy ROUNDED
932 362
adx ady
704 362
px py px/2 py/2
0 118 0 59
spline36resize(704,362)
addborders(0,59,0,59)

[halsboss]

Assuming a square pixel source it seems the results appear close to the same and to the table ? Another place drifting from muxers and ratios into this question also advised along the lines :-
(a) MPEG encoding will work better with mod8 or mod16 sizes. Resizing to 704x360 (mod8) or 704x368 (mod16) will compress better than 704x363.
(b) keeping the video aligned on a mod8 or mod16 boundary will work better (ie make the black borders start/end on a mod 8/16 boundary) ...
(c) avoid using odd (as in even vs odd) values on the top or left when adding borders. Odd values will cause additional blurring of the chroma channels.
I guess the quick-ref table could be recalculated and/or the script updated, to take (a)/(b)/(c) into account if "close enough" is the objective ?

[2Bdecided]

halsboss - thanks for that. Regarding point (c) I'd forgotten to make px/2 and py/2 mod2 - I meant to, as it's vital IMO. A one pixel offset is much less important than scrambling the colour planes.

Regarding points (a) and (b), in my script, the user selects the output size. I could force it to be mod16, but I'm not sure that would be helpful...

I'm all for mod16 where possible, and thankfully most of the standard SD resolutions are mod16:

576 x 1024/768/720/704/528/352
480 x 720/704/640/528/352


These ones aren't:

576 x 540/360
480 x 854/853/540/360

... and TBH it's "only" 854/853x480 that's really common out of these non-mod16 ones. 540 and 854/853 aren't even mod8.

I'd still use 854x480 though. Remember that 1920x1080 isn't mod16, and people don't avoid that. Also 640x360 isn't mod16, but is widely used. I know they're mod8, but AFAIK mod8 still means 8 extra (dummy) pixels get encoded.

Cheers,
David.

[halsboss]

Oh. Well, just for the record then, the adjusted quick-ref spreadsheet with the new calcs :-
MOD8 :-
align to mod8 boundaries using ROUNDDOWN using ROUNDUP
for 4:3 PAL display
AR X Y orig Y Bbtop Bbbot Y Bbtop Bbbot
1.33 720/704 576 576 0 0 576 0 0
1.66 720/704 461 456 56 64 464 56 56
1.78 720/704 430 424 72 80 432 72 72
1.85 720/704 414 408 80 88 416 80 80
2.35 720/704 326 320 128 128 328 120 128

for 16:9 PAL display
AR X Y orig Y Bbtop Bbbot Y Bbtop Bbbot
1.33 538 576 576 0 0 576 0 0
1.66 671 576 576 0 0 576 0 0
1.78 720/704 576 576 0 0 576 0 0
1.85 720/704 554 552 8 16 560 8 8
2.35 720/704 436 432 72 72 440 64 72

for 4:3 NTSC display
AR X Y orig Y Bbtop Bbbot Y Bbtop Bbbot
1.33 720/704 480 480 0 0 480 0 0
1.66 720/704 384 384 48 48 384 48 48
1.78 720/704 358 352 64 64 360 56 64
1.85 720/704 345 344 64 72 352 64 64
2.35 720/704 271 264 104 112 272 104 104

for 16:9 NTSC display
AR X Y orig Y Bbtop Bbbot Y Bbtop Bbbot
1.33 538 480 480 0 0 480 0 0
1.66 671 480 480 0 0 480 0 0
1.78 720/704 480 480 0 0 480 0 0
1.85 720/704 461 456 8 16 464 8 8
2.35 720/704 363 360 56 64 368 56 56

MOD16 :-
align to mod16 boundaries using ROUNDDOWN using ROUNDUP
for 4:3 PAL display
AR X Y orig Y Bbtop Bbbot Y Bbtop Bbbot
1.33 720/704 576 576 0 0 576 0 0
1.66 720/704 461 448 64 64 464 48 64
1.78 720/704 430 416 80 80 432 64 80
1.85 720/704 414 400 80 96 416 80 80
2.35 720/704 326 320 128 128 336 112 128

for 16:9 PAL display
AR X Y orig Y Bbtop Bbbot Y Bbtop Bbbot
1.33 538 576 576 0 0 576 0 0
1.66 671 576 576 0 0 576 0 0
1.78 720/704 576 576 0 0 576 0 0
1.85 720/704 554 544 16 16 560 0 16
2.35 720/704 436 432 64 80 448 64 64

for 4:3 NTSC display
AR X Y orig Y Bbtop Bbbot Y Bbtop Bbbot
1.33 720/704 480 480 0 0 480 0 0
1.66 720/704 384 384 48 48 384 48 48
1.78 720/704 358 352 64 64 368 48 64
1.85 720/704 345 336 64 80 352 64 64
2.35 720/704 271 256 112 112 272 96 112

for 16:9 NTSC display
AR X Y orig Y Bbtop Bbbot Y Bbtop Bbbot
1.33 538 480 480 0 0 480 0 0
1.66 671 480 480 0 0 480 0 0
1.78 720/704 480 480 0 0 480 0 0
1.85 720/704 461 448 16 16 464 0 16
2.35 720/704 363 352 64 64 368 48 64

Thankyou for the clarifications !

[2Bdecided]

That's a good table.

btw (and I don't think it's genuinely useful, but I'll mention it anyway) if you're going to keep the black bars at chroma channel DCT boundaries, I think it all needs to be mod16. I wouldn't bother myself.

I've changed my script to give you the choice of respecting mod2 (properly now!), or completely ignoring it (e.g. when using RGB, and/or when encoding 853x480 for example - I wouldn't do either, but just in case). I've added a few more pre-set resolutions too.

# Script to change picture size and aspect ratio (with optional cropping)
# David Robinson, March 2009. Version 2
# This script is provided as-is, no guarantee.
# Free for non-commercial use. Please share any (useful!) changes / corrections.


# ==================================================
# Uncomment one line from each section (by deleting the # at the start of the line)


# start with some source, e.g.
avisource("my_video.avi")


# ==================================================
# Force mod2 (even) widths and heights at all stages of calculation:
# DO NOT CHANGE THIS PART unless you know what you are doing
# If using YUY2 or YV12 data, some operations (e.g. crop) will crash with
# non-mod2 (odd) widths (and heights for YV12). Others will work but blur
# the colour.
# If using RGB data, any integer width and height is allowed. However, most
# codecs work with YV12 internally, and converting to/from RGB is not lossless
# so if possible avoid conversion _and_ stick to mod2 values.
# This script forces mod2 values throughout by default.
# Change "true" to "false" in the next two lines to remove this restriction:
force_mod2_width=true # default = true
force_mod2_height=true # default = true


# ==================================================
# Get Source Dimensions (DO NOT CHANGE THIS PART)
sX=width(last) # get source width
sY=height(last) # get source height


# ==================================================
# Set Source PAR
# --> uncomment ONE of the following sPAR lines...

# Square pixels (1920x1080, 1280x720, 1024x576, 768x576, 853x480, 640x480, 320x240 etc)
sPAR=1.0

# HDV (1440x1080 widescreen):
# sPAR=4.0/3.0

# SD video with 704 real pixels:

# "PAL" 4x3
# sPAR=12.0/11.0

# "PAL" 16x9
# sPAR=16.0/11.0

# "NTSC" 4x3
# sPAR=10.0/11.0

# "NTSC” 16x9
# sPAR=40.0/33.0

# SD video with 720 real pixels:

# "PAL" 4x3
# sPAR=16.0/15.0

# "PAL" 16x9
# sPAR=64.0/45.0

# "NTSC" 4x3
# sPAR=8.0/9.0

# "NTSC” 16x9
# sPAR=32.0/27.0


# ==================================================
# Set Destination width
# --> uncomment ONE of the following dX lines, or add your own

dX=704 # SD 704 pixels
# dX=720 # SD 720 pixels
# dX=1280 # HD 1280x720
# dX=1920 # HD 1920x1080

# dX=640 # PC 640x480
# dX=853 # PC 853x480
# dX=854 # PC 854x480

# dX=768 # PC 768x576
# dX=1024 # PC 1024x576


# ==================================================
# Set Destination height
# --> uncomment ONE of the following dX lines, or add your own

dY=480 # SD "NTSC" etc
# dY=576 # SD "PAL" etc
# dY=720 # HD 1280x720 pixels
# dY=1080 # HD 1920x1080 pixels


# ==================================================
# Set Destination PAR
# --> uncomment ONE of the following dPAR lines...

# Square pixels (1920x1080, 1280x720, 1024x576, 768x576, 853x480, 640x480, 320x240 etc)
dPAR=1.0

# HDV (1440x1080 widescreen):
# dPAR=4.0/3.0

# SD video with 704 pixels:

# "PAL" 4x3
# dPAR=12.0/11.0

# "PAL" 16x9
# dPAR=16.0/11.0

# "NTSC" 4x3
# dPAR=10.0/11.0

# "NTSC” 16x9
# dPAR=40.0/33.0

# SD video with 720 pixels:

# "PAL" 4x3
# dPAR=16.0/15.0

# "PAL" 16x9
# dPAR=64.0/45.0

# "NTSC" 4x3
# dPAR=8.0/9.0

# "NTSC” 16x9
# dPAR=32.0/27.0


# ==================================================
# OPTIONAL cropping of source to arbitrary aspect ratio - calculation

# Define variable to prevent a crash (DO NOT CHANGE THIS LINE):
cs=1.0

# --> uncomment ONE of the following cS lines (or add your own) if you want to crop...

# crop to 4x3 (1.333):
# cS=4.0/3.0

# crop to 3x2 (1.500):
# cS=3.0/2.0

# crop to 14x9 (1.556):
# cS=14.0/9.0

# crop to 15x9 (1.667):
# cS=15.0/9.0

# crop to 16x9 (1.778):
# cS=16.0/9.0

# crop to 1.85:
# cS=1.85

# crop to 2.20:
# cS=2.20

# crop to 2.35:
# cS=2.35

# crop to 2.39:
# cS=2.39


# ==================================================
# Crop calculation (DO NOT CHANGE THIS PART):

# Calculate cropped image size:
cX=(sY/sPAR)*cS
cY=(sX*sPAR)/cS

# Check which side to crop:
cX = (cY>sY) ? cX : sX
cY = (cY>sY) ? sY : cY

# Calculate crop values for sides and top
Xc = (force_mod2_width==true) ? round((sX-cX)/4.0)*2 : round((sX-cX)/2.0)
Yc = (force_mod2_height==true) ? round((sY-cY)/4.0)*2 : round((sY-cY)/2.0)


# ==================================================
# OPTIONAL cropping of source to arbitrary aspect ratio - cropping
# --> uncomment the next line to do the actual crop:
# crop(Xc,Yc,-Xc,-Yc)


# ==================================================
# Get cropped Source Dimensions (DO NOT CHANGE THIS PART)
sX=width(last) # get source width
sY=height(last) # get source height


# ==================================================
# calculation (DO NOT CHANGE THIS PART):

# Force mod2 for destination
dX = (force_mod2_width==true) ? round(dX/2.0)*2 : round(dX)
dY = (force_mod2_height==true) ? round(dY/2.0)*2 : round(dY)

# Calculate new active image size
cdY=dX*(dPAR/sPAR)*(float(sY)/float(sX))
cdX=dY*(sPAR/dPAR)*(float(sX)/float(sY))

# Force mod2 active image size:
cdX = (force_mod2_width==true) ? round(cdX/2.0)*2 : round(cdX)
cdY = (force_mod2_height==true) ? round(cdY/2.0)*2 : round(cdY)

# Pick which dimension to shrink...
adX = (cdY>dY) ? cdX : dX
adY = (cdY>dY) ? dY : cdY

# Calculate borders:
bX = (cdY>dY) ? dX-cdX : 0
bY = (cdY>dY) ? 0 : dY-cdY

# Force mod2 borders:
bLEFT = (force_mod2_width==true) ? floor(bX/4.0)*2 : floor(bX/2.0)
bRIGHT = (force_mod2_width==true) ? ceil(bX/4.0)*2 : ceil(bX/2.0)
bTOP = (force_mod2_height==true) ? floor(bY/4.0)*2 : floor(bY/2.0)
bBOTTOM = (force_mod2_height==true) ? ceil(bY/4.0)*2 : ceil(bY/2.0)

# ==================================================
# Optional: Remove jagged lines from output using smart interpolation
# If you are upscaling (e.g. SD to HD) and the result has jagged lines, try this:
# Get NNEDI and uncomment the following line (warning: slow!):
# NNEDI(field=0, dh=true).turnright.NNEDI(field=0, dh=true).turnleft


# ==================================================
# Perform actual resize
spline36resize(adX,adY)

# Optional: If you want to try different resizers, Google for
# "resize avisynth" to find alternatives to the "spline36resize" above


# ==================================================
# Add borders (DO NOT CHANGE THIS PART)
addborders(bLEFT,bTOP,bRIGHT,bBOTTOM)


# END

It can do some useful stuff - e.g. start with HDV (anamorphic HD), optionally crop it to whatever you want (4x3, 14x9, 2.35:1 super widescreen etc etc), and add appropriate borders for SD PAL, NTSC, or any PC square pixel resolution.

To state the obvious, if your source is interlaced, deinterlace it before you use this script to change the height.

Cheers,
David.

[Alex_ander]

@halsboss
The rounded numbers in that table are OK, but I wonder what method did the original author use (in case of 363 the number was correct, but some other numbers look strange before rounding). For example, the often used PAL height number for letteboxing 16:9 image (known to be exactly 432 and mod16). In the table we see first 430, 424 and finally you rounded it to 432. Using my suggestion for calculations, that number comes directly:

NewHeight=576xOuterDAR/InnerDAR=576x(4:3)/(16:9)=432

The approach works for pillarboxing as well. In this case height is fixed (480 or 576) and NewWidth is calculated from 704 + DAR numbers. The only thing to remember here is that the smaller number should be in numerator:

NewWidth=704xInnerDAR/OuterDAR, for example - pillarboxing a 4:3 image on 16:9 display:
NewWidth=704x(4:3)/(16:9)=528

I'm sure PAR numbers are redundant in calculations.

[2Bdecided]

I'm sure PAR numbers are redundant in calculations.If you know the DAR and width and height (I think assuming that one of them is unchanged is equivalent to "knowing" it), this must be correct - since this known information would be sufficient to calculate the PAR anyway. As you've shown, it all cancels out.


If you have 720 pixels where 704 pixels define the aspect ratio (i.e. "correct" PAR) and you want to pillarbox, then this isn't easy because the DAR of all 720 pixels is something weird - in this case it's easier to crop to 704* and then you know the DAR is 4x3 or 16x9, and you can proceed with your method. Thankfully letterboxing is more common, and here 720 vs 704 doesn't interfere with the vertical resize.

Cheers,
David.

* - you could use my script to keep the extra pixels if required, or to crop them. It works properly both ways.

[rack04]

Along these same lines. If I have a 1920x800 trailer that I want to resize to 1280x720 for compliant AVCHD playback would I use the following script?

LoadPlugin("C:\Program Files\DGAVCIndex\DGAVCDecode.dll")
AVCSource("C:\Personal\Videos\500 Days of Summer-output.dga")
crop( 2, 0, -2, 0)
Spline64Resize(1280,528)
AddBorders(0,96,0,96)

[2Bdecided]

It would work (I assume you have a good reason for cropping?).

I'm almost tempted to test the effect of sticking with mod16 for this (vs using non-mod16 values).

Cheers,
David.

[Master Yoda]

Wow, who knew such a small question could create such an informative thread. That's a nice table for quick reference from halsboss, I'm guessing on the ones where the ratio is 1.33 and 1.66 for 16.9 where x is 538 and 671 borders are needed on the left and right side. mod16 does this mean a multiple of 16?

[Alex_ander]

If you know the DAR and width and height (I think assuming that one of them is unchanged is equivalent to "knowing" it), this must be correct - since this known information would be sufficient to calculate the PAR anyway.
This is not limited to conversion within the same file type.
I meant you needn't know width and height of original image (active part of it) or PAR of its file type. All is needed for calculations is DAR for which it was shot or prepared. It can be either standard (like 16:9) or non-standard if somebody cropped it (if unknown then DAR should be estimated experimentally). If it has any borders, it can be cropped and resized to numbers calculated using (its DAR+target file pixel numbers and known standard DAR flag).

If you have 720 pixels where 704 pixels define the aspect ratio (i.e. "correct" PAR) and you want to pillarbox, then this isn't easy because the DAR of all 720 pixels is something weird

I can't see a problem with 720. If 704 corresponds to vertical edges of 16:9 image, the 704x576 part of the stored image fills the screen (and the active part is shown with correct AR if calculated from 704 number), the part corresponding to excessive stored pixels goes to line blanking interval of restored (e.g. analog) video signal (by ITU, with 13.5MHz standard sampling frequency) and is not shown even without overscanning. In both cases of calculation between 16:9 and 4:3 the letterboxed/pillarboxed image is 3/4 of full frame in one of dimensions. In case of 2.35 within 16:9 the exact ratio is slightely (1%) different, but 3/4 (easy-to-remember number) can also be used since the result will be finally rounded to the same (mod4 or mod8) number.

[Alex_ander]

P.S.
I seem to understand now what you said about cropping to 704. In case of NTSC the visible edge in fresh TV capture doesn't coincide with 702 mark and stretches to 711. So yes, it's necessary to crop it to 704 in the very beginning to be able to use any method based on known DAR for visible part.

[Mug Funky]

just to complicate matters slightly, it might be worth adding that on BVM monitors with the SDI option (or even via component), the entire 720 pixel width is shown in underscan mode. when this signal is looped through an analog tape deck (such as a betacam SP deck for those who still have a use for such a thing), the extra pixels are "pillarboxed", keeping the picture in the same place.

[2Bdecided]

P.S.
I seem to understand now what you said about cropping to 704. In case of NTSC the visible edge in fresh TV capture doesn't coincide with 702 mark and stretches to 711.Analogue NTSC is supposed to be 711x485, though CC on line 23 ensures that the picture is never really that heigh. Since most of us are limited to a height of 480 in the digital realm, 704x480 is the biggest real 4x3 image we can have, but 720x480 contains more of the width of the original 4x3 image.

just to complicate matters slightly, it might be worth adding that on BVM monitors with the SDI option (or even via component), the entire 720 pixel width is shown in underscan mode. when this signal is looped through an analog tape deck (such as a betacam SP deck for those who still have a use for such a thing), the extra pixels are "pillarboxed", keeping the picture in the same place.I don't think that complicates things - that's exactly what should happen. 720 pixels are (by design) longer than the standard active line length in both PAL and NTSC analogue video. You can't keep them all when going via an analogue stage (unless it's non-standard).

The only problem is if you use the "wrong" interpretation of 720 - i.e. that it's the full 4x3 or 16x9 area. Try sending that by analogue and you have slightly less width than 4x3 or 16x9 left. Whereas the "correct" interpretation of 720 - i.e. that it's wider than the full 4x3 or 16x9 area - lets you send it via analogue without touching the actual 4x3 or 16x9 image sitting within it. 'Tis the whole point! ;)

Cheers,
David.

[halsboss]

Thankyou again. I'm sorry the table isn't right, don't know why. Just lost the .xls when restoring the system after a crash in which my primary LAN port h/w died. Anyway, have resolved to use 2Bdecided script with specific-case PAR=1.0 respecting mod2 and not worry about mod16 boundaries. Life gets easier.

[2Bdecided]

I've been trying to look at the effect of using / not using mod16 values for the position of the black bar / image boundaries.

I started with 1440x1080 HDV deinterlaced with tgmc.

The destination was 704x576 4x3 SD PAL, so the active area is 704x432 (which itself is mod 16 anyway).

Using 25fps progressive content (generated via selectevery(2,0) from 50p), I tried encoding four different variations: mod2, mod4, mod8 and mod16 borders.

With HCenc 0.23, Q5 no maximum, the results were as expected:

mod16 = 4738kbps
mod8 = 4813kbps
mod4 = 4890kbps
mod2 = 4895kbps


There's no obvious visual difference (except that the mod2 version really is in the middle of the screen, while the mod16 version clearly isn't!). I tried moving the mod16 and mod2 versions down by an extra 16 pixels (i.e. 16 pixels more black at the top, and 16 pixels less black at the bottom), and it made no (i.e. zero) difference to the bitrate.

Using 25fps interlaced content (generated using assumetff().separatefields().selectevery(4,0,3).weave() from 50p), the differences were similar, though bizarrely mod4 had the highest bitrate (6719kbps), and mod16 still the lowest (6596kbps). Doesn't interlacing eat up bitrate?! (Other than interlacing, it was exactly the same source content).

By softening the picture vertically (which I believe is necessarily for interlaced displays) before the interlacing step, the hard image/letterbox boundaries were also smoothed, and the mod16 advantage disappeared (as you might expect):

mod16 = 6378kbps
mod8 = 6363kbps
mod4 = 6388kbps
mod2 = 6382kbps



Here's the result that I don't understand: x264. I used the 25fps progressive versions in MeGUI, unconstrained balanced Q17. The results were:

mod16 = 3307kbps
mod8 = 3235kbps
mod4 = 3258kbps
mod2 = 3239kbps

I tried pushing the mod16 and mod2 versions down by 16 pixels, and got almost (but not exactly) the same bitrates (e.g. 3309kbps).

I don't understand this result at all.


Finally, I tried the 25fps progressive version with HCenc at 1Mbps (2-pass VBR). Terrible (completely unusable) picture quality. Both mod16 and mod2 maintained a sharp image/letterbox border, but the mod2 version had visible ringing just within the image, while the mod16 version did not. To be fair, the image had far bigger problems!


So, my conclusion is that I don't understand what's happening with x264 here, but that mod16 gives a small advantage with HCenc.

I don't think it's worth it. Not having the image in the centre of the screen with mod16 is annoying, whereas the advantage in quality/bitrate at usable bitrates isn't significant (IMO, YMMV!).

Cheers,
David.

[halsboss]

OK, nice job. Reinforces that I should use the script with confidence in "close enough" mode.

[sneaker_ger]

Here's the result that I don't understand: x264. I used the 25fps progressive versions in MeGUI, unconstrained balanced Q17. The results were:

mod16 = 3307kbps
mod8 = 3235kbps
mod4 = 3258kbps
mod2 = 3239kbps

I tried pushing the mod16 and mod2 versions down by 16 pixels, and got almost (but not exactly) the same bitrates (e.g. 3309kbps).

I don't understand this result at all.

I've read somewhere on this board that black borders make the CRF mode behave differently. But I can't find the post right now. Using non-mod16 resolutions is IIRC like using black borders since the encoder padds it. To test the different resolutions you'd have to use a constant quantizer.
Not sure about this, though. :confused: