[Discussion] New Feature: Display Aspect Ratio

[cipher]

I just compiled the latest cvs, and saw this new feature. I recalled it being discussed a little bit on the mailing-list.

So everyone, what do you think about it? Bring it on! :D

[mf]

I can only say: FINALLY :p.

[unixfs]

I tested it encoding with mencoder and when I specified pal43
the final A/R was 1.02.
using ext:4:3 it came out as 1.09
I don't really understand how it's supposed to work.
can someone explain, please?

P.S. mplayer is already able to correctly read those fields,
it's been working correctly with libavcodec encodes for years.

[sysKin]

Originally posted by unixfs
I tested it encoding with mencoder and when I specified pal43
the final A/R was 1.02.
using ext:4:3 it came out as 1.09
I don't really understand how it's supposed to work.
can someone explain, please?In mencoder, you are setting PAR not AR. PAR is pixel aspect ratio - describes the shape of each pixel. Accoriding to the standard, "pal43" means PAR of 12:11.

In VfW's gui, PAR is calculated on-the-fly using given AR and picture resolution. IMHO it should have been done better - but GUI sucks in so many places that this part blends in ;)

Radek

[Koepi]

Ouch.

[bond]

i wanted to say that the 3ivx guys already found a way that:
1) is not container related of course (ie can be used in avi (works with the m$ splitter for example))
2) can already be played back in dshow (no need for mplayer or so)

try the following:
1) encode with the 3ivx vfw codec (by using the PAR option) to avi
2) when playing this avi, the set par will not be displayed
3) mux this avi to mp4
4) mux this mp4 to avi
5) play the resulting avi in dshow and enjoy the correct par

btw according to shitowax steps 3-4 can be left out if the codec would write the info directly during encoding

[shitowax]

Naughty naughty bond =)

[bond]

naughty by nature :D

[sysKin]

This sounds very good indeed.
Originally posted by bond
1) is not container related of course (ie can be used in avi (works with the m$ splitter for example))
Does it mean that it can be used in ogm too, if I'd mux to ogm instead of avi in step 4 ?
2) can already be played back in dshow (no need for mplayer or so)3vix's dshow? If yes, what do I do to add this feature to XviD's dshow? :)

Radek

[bond]

Originally posted by sysKin
This sounds very good indeed.well i already wrote about it on irc but i simply got ignored :p

Does it mean that it can be used in ogm too, if I'd mux to ogm instead of avi in step 4 ?hm i didnt try it, but i think it has something to do with how the 3ivx mp4 muxer and than the splitter treats the info
but as i wrote it should be also possible to write this info directly into .avi during encoding (or with an own muxing app)

[sillKotscha]

glad to see that all of you are so happy about this feature... but it's the end of my horizon. What is the advantage out of it. I can't image any for my personal use - but as I said, sometimes I still have a deep lack of knowledge!!

thanks in advance

Sill

[olnima]

same with my horizon... :-)

maybe anybody could explain the Display-Aspect Ratio settings for those who are capturing videos directly (1-pass) using xvid and play them on a pc with the xvid decoder (koepis PreBeta3) on mediaplayerclassic or on a Standalone DVD-Player.

Thank You

Olnima

[unixfs]

For me it's useful because it permits to crop unwanted black borders
and encode without resizing (which usually introduces artefacts such as
excessive fading) keeping the original A/R .

[sysKin]

I have to admit I can't imagine me using it either. If I really wanted to do any AR stuff I'd start using matroska... but anyway, it's there, have fun everyone ;D

Radek

[bond]

it would be much more fun, if we could use it directly with the avi created by the xvid codec :p

edit: damn it seems that the nero video decoder already supports this :eek:
good stuff

[plazz2000]

Looks like this feature has been removed already. (it's not in gam3r's Dec18th build anyway...)

[olnima]

@plazzz: it has now it's own register-page and is still there. :)

Thanks to gamr for the instantbuilds.

Olnima

[Th3-S4int]

Can somebody explain me how that Feature works and for what it helps?

[bond]

anamorphic encoding (so using this ar feature to resize during playback (only in mplayer or with the nerovideodecoder fitler atm)) only makes sense when you dont use any resize filter when transcoding from dvd!

[Assault]

@ bond

Hmm....I don't know if that's true. AFAIK the human eye is more sensitive to vertical than to horizontal resolution. That means it is possible to get a better quality when you use a SMALLER horizontal but a BIGGER vertical resolution(you won't notice the loss of the horizontal res but you will notice the gain of increasing the vertical res). So IMHO using a PAR different than 1 can also make sense when you donwscale your resolution because you haven't enough bits.

Assault

[celtic_druid]

Also works with VLC, I guess it would work on XBMP to.

[Neo Neko]

Originally posted by olnima
same with my horizon... :-)

maybe anybody could explain the Display-Aspect Ratio settings for those who are capturing videos directly (1-pass) using xvid and play them on a pc with the xvid decoder (koepis PreBeta3) on mediaplayerclassic or on a Standalone DVD-Player.

Thank You

Olnima

Basically all DVD are not encoded to a 1:1 ratio. In NTSC land whether you get the crappy full screen DVD version or the propper widescreen version the video on the disc is 720x480. Things are similar in PAL land only slightly different numbers. What does this mean? It means that the video on the disc is neither 4:3 or 16:9 even though those are the two most common aspect ratios I have found. Also if you are familliar with SVCD or some of the varriant VCD formats they basically never use a 1:1. So when you encode DVD you either have to increase the verticle resolution and waste bits, or decrease the resolution and loose quality. But with this you have a 3rd option. Encode at the exact same resolution And have it resize automatically on playback. The best solution avalible. Even though Xvid did not support this before all my TV captures encoded to Xvid are 480x480. 640x480 really is a waste.

Which causes me to then ask this. Syskin would it be possible to get a utility even a simple CLI to rewrite the Xvid headers in AVI to contain the AR?????? Puuuuuuuuuuuuuleeeeeeeeeeeese?! Sure I can and do resize with ffdshow dynamically. Heck I can put em in Matroska and use Matroska's AR feature. But this would be soooooooooooooooooo nice.

[HarryM]

Originally posted by Assault
@ bond

Hmm....I don't know if that's true. AFAIK the human eye is more sensitive to vertical than to horizontal resolution. That means it is possible to get a better quality when you use a SMALLER horizontal but a BIGGER vertical resolution(you won't notice the loss of the horizontal res but you will notice the gain of increasing the vertical res). So IMHO using a PAR different than 1 can also make sense when you donwscale your resolution because you haven't enough bits.

Assault

Exactly. In GordianKnot I tolerate ARdif at 0-0,3% better, don't negative.

[olnima]

@ALL, especially @Neo Neko:

Thanks a lot for your explanations.

Olnima

[bond]

Originally posted by Assault
Hmm....I don't know if that's true. AFAIK the human eye is more sensitive to vertical than to horizontal resolution. That means it is possible to get a better quality when you use a SMALLER horizontal but a BIGGER vertical resolution(you won't notice the loss of the horizontal res but you will notice the gain of increasing the vertical res). So IMHO using a PAR different than 1 can also make sense when you donwscale your resolution because you haven't enough bits.hm yes, interesting thoughts

any other opinions/experiences on wheter anamorhpic resize makes sense when downsizing to lower resolutions?

Originally posted by Neo Neko
Which causes me to then ask this. Syskin would it be possible to get a utility even a simple CLI to rewrite the Xvid headers in AVI to contain the AR?i already asked alexnoe to add something like that in avimux-gui, but he doesnt really seem to be interested

[KpeX]

Originally posted by bond
any other opinions/experiences on wheter anamorhpic resize makes sense when downsizing to lower resolutions?
I've done a few Matroska anamorphic experiments, and anamorphic does make a big compressibility difference at lower resolutions. For example, for many movies, encoding at 480x272 (or 512, 544, etc.) with a display size of 640x272 can often increase the compressibility enough to fit an encode on 1 CD that would normally be 2. Visually, the smaller resolution resized to 640x272 looks identical to my eyes (detail preservation, etc.).

[bond]

hm sounds really interesting :)

lets say our non-anamorphic res would be 640x256

than we would have two possibilities to think about when doing anamorphic imho:
1) 448x256 which has the same height as non-anamorhpic and will result in 640x256 during playback, but with a better compressibility
2) 512x304 which has a little bit less overall pixels than the non-anamorphic encode (163840 vs. 155648) which will have ~ the same compressiblity as the non-anamorph, but will result in a higher playback res (768x304)

i guess we will not come around doing some testing to find out which of these 3 ways will be the best quality-wise (perhaps psnr is ok in this case?)

[Soulhunter]

i guess we will not come around doing some testing to find out which of these 3 ways will be the best quality-wise (perhaps psnr is ok in this case?)
Already thought about making the PSNR test in fullscreen resolution... ???

I mean... Passing the source and all different encodes through Avisynth with a fullscreen resize (f.e. Lanczos->1024x576), and using this a AVS as input for the PSNR test !!!

Bye

[bond]

it should be possible by using dshowsource in avisynth with a filter graph that resizes the pic to the right ar

[symonjfox]

You forgot that many many DVB channels, broadcast @ strange resolutions (352, 544, 704)*576 Anamorphic.

I use to record stuff from DVB channels, but I always have to downsize to smaller resolution.

Instead using the AR flag, I can Capture, transcode and watch in full quality video (with no manual operations).

Another advantage, I can keep interlaced material as it is, because if I have to downsize vertical resolution for getting 1:1 AR, the fields generate interlacing artifacts (or I have to drastically go down to 288, or use Deinterlacers).

[bond]

ok here some findings for anamorphic+downsize:

i compared a non-ana 640x256 (matrix same as doom9 uses) with a 448x256 anamorphic encode (gets 640x256 when stretched) same settings, same bitrate

as a result i have to say, it really depends on how the anamorhpic picture gets resized:
1) when i put it into .mp4 or .mkv and decode with either 3ivx or ffdshow (with the overlay mixer option ticked), which means the renderer resizes, the quality is clearly worse than the 640x256 encode
2) if i let ffdshow do the ar correction internally (bicubic resize) the quality is ~ the same as the non-anamorph encode
only a zoomed frame-by-frame comparison (with avscompare) shows that the anamorphic encode has little less details then the non-ana one

of course i only did a small test, maybe someone else has different results?


symonjfox,
in your signature i see you are waiting for anamorphic support in mp4, its already possible with 3ivx (check out my faq)

[Teegedeck]

IMHO encoding 'inversely' anamorphic can only be justified if the source is so badly compressible that it would result in blocking if you encoded it normally. Probably it is best suited for 4:3 encodes. And it is probably a very good and more inobstrusive alternative to noise-filtering and softening.

Other than that, I prefer a DVD-style anamorphic encoding (for movies and the like) over a normal one, even if the quants are bit higher.

[symonjfox]

Originally posted by bond
symonjfox,
in your signature i see you are waiting for anamorphic support in mp4, its already possible with 3ivx (check out my faq)
I have to say: my signature is the same from more than 1 year! I wrote that to push some programmer to fully implement the AR setting in MPEG4 under windows (knowing about ffmpeg and direct show issues about AR ...). It's just a kind of provocation, just to see if somebody is able to implement it ... ;)

If I could program, I do it by myself, but I'm very far from being able to program such applications ... :(

[Stux]

Originally posted by bond
anamorphic encoding (so using this ar feature to resize during playback (only in mplayer or with the nerovideodecoder fitler atm)) only makes sense when you dont use any resize filter when transcoding from dvd!

As long as XviD is using MPEG-4 Visual PAR (and I assume it is) this should also work with 3ivx, as long as the stream is converted to an MP4 first

[Assault]

Happy New Year to you all!!!

@ Stux

A little bit OT:

As you know very much about mpeg4 you can perhaps answer my question.
AFAIK a PAL 16/9 anamorphic DVD is resized during playback from 720x576 to 1024x576. That would mean that the PAL 16/9 PAR is 1024/720=64/45=1,42222222. But (I think) all PAR implementations I've seen use a PAR of 16/11 for PAL 16/9. That is 1,45454545. Is there any reason for that small difference? Or is 16/11 only an approximation and 64/45 is actual right? Thanks.

Assault

[JustusJonas]

mhh i was wondering if the directshow filter will be changed so it will forward the info in/from VIDEINFOHEADER2 to the renderer or at which point the resizing is done... i came across an xvid in matroska file encoded anamorphic with 0.9.2 but the decoder is swallowing that information about the AR...

so any plans for the dshow part or is that something completly different and i'm talking just foobar?

[evade]

I like this feature! It works beautifully for me in mplayer and On my XBOX with xbox media center (which incorporates mplayer). Here is the command I have been using with 16:9 ntsc matirial:


cat *.vob | \
mencoder -o /dev/null -ovc xvid \
-xvidencopts pass=1:quant_type=mpeg:trellis:chroma_me:vhq=4:max_bframes=2:\
bquant_ratio=150:bquant_offset=75:bf_threshold=0:par=ext:par_width=237:par_height=200 \
-vf crop=720:468:0:4 -aid 128 -oac mp3lame -lameopts preset=128 -

cat *.vob | \
mencoder -o Movie.avi -ovc xvid \
-xvidencopts pass=2:bitrate=1550:quant_type=mpeg:trellis:chroma_me:vhq=4:max_bframes=2:\
bquant_ratio=150:bquant_offset=75:bf_threshold=0:par=ext:par_width=237:par_height=200 \
-vf crop=720:468:0:4 -aid 128 -oac mp3lame -lameopts preset=128 -

[mikeX]

i don't understand much about aspect ratios yet so sorry if i sound really stupid, but:

what is the purpose of this new aspect ratio feature if it's just wasted on a 'general purpose container' (quoting the xvid vfw gui)
can anyone give me an example of a non general purpose container and, say, where it's used?

also, i made a few tests, focusing mostly on the AR feature of the matroska container, but some weird stuff came up: http://forum.doom9.org/showthread.php?s=&postid=420772#post420772

[Koepi]

It gets used if directshow framework isn't used from any container, just do as I wrote somewhere else already:

use mplayer or vlcplayer, both have windows ports available.

In DirectShow, NeroDigital and 3ivx (sorry if I forgot some other DSF capable of doing that) can resize according to the PAR in the bitstream.

Regards
Koepi

[bond]

i hope syskin didnt drop the idea of adding that possibility to the xvid decoder too :(

[mikeX]

thanx koepi!

i was gonna try out mplayer on linux sooner or later, just can't reboot right now ;)

ps: sorry for missing out on the answer the first time ;)

[Koepi]

No need to boot linux, just head for one of the plenty win32 compiles:

http://mplayer.sunset-utopia.homeip.net/

or official builds:

http://www2.mplayerhq.hu/MPlayer/releases/win32-beta/

Just extract the thing to a new directory, hit your AR file with the right mouse button, choose "open with", then "different program..." and there search for your mplayer binary.

Regards
Koepi

[mikeX]

well i guess double thanks :D

edit:::
well, some feedback at last, thanks to koepi

letting mplayer speak for itself:
1: PAL anamorphic source 16:9 --> lanczos(480,384) --> xvid(16:9 PAL):
**********************************************************************
MPlayer 1.0pre3-3.2.3 (C) 2000-2003 MPlayer Team

CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino 1608 MHz (Family: 6, Stepping: 2)
Detected cache-line size is 64 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled with Runtime CPU Detection - WARNING - this is not optimal!
To get best performance, recompile MPlayer with --disable-runtime-cpudetection.
Reading config file /usr/local/etc/mplayer/mplayer.confReading config file E:/mplayer/mplayer/config
Reading E:/mplayer/mplayer/codecs.conf: Reading /usr/local/etc/mplayer/codecs.conf: Using built-in default codecs.conf.
c:/windows/fonts/arial.ttf doesn't look like a font description, ignoring
Using usleep() timing
Input config file E:/mplayer/mplayer/input.conf parsed: 53 binds

Playing l:\wod\wod-ps-custom6-2.avi.
AVI file format detected.
AVI_NI: No audio stream found -> no sound.
AVI: No audio stream found -> no sound.
VIDEO: [XVID] 480x384 12bpp 25.000 fps 754.9 kbps (92.2 kbyte/s)
Clip info:
Software: VirtualDubMod 1.5.10.1 (build 2407/release)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm:ffmpeg (FFmpeg MPEG-4)
==========================================================================
Audio: no sound
Starting playback...
VDec: vo config request - 480 x 384 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.82:1 - prescaling to correct movie aspect.
SwScaler: using unscaled Planar YV12 -> BGR 24-bit special converter
VO: [gl2] 480x384 => 698x384 BGR 24-bit
[gl2] OpenGL Driver Information:
vendor: NVIDIA Corporation,
renderer GeForce4 Ti 4200 with AGP8X/AGP/SSE/3DNOW!,
version 1.4.0
[gl2] You have OpenGL >= 1.2 capable drivers, GOOD (16bpp and BGR is ok!)
[gl2] Creating 1x1 textures of size 512x512 ...
[gl2] antialiasing off
[gl2] bilinear linear
[gl2] Using image_bpp=24, image_bytes=3, isBGR=1,
gl_bitmap_format=GL_BGR, gl_bitmap_type=GL_UNSIGNED_BYTE,
gl_alignment=8, rgb_size=24 (8,8,8), a_sz=0,
gl_internal_format=GL_RGB8
[gl2] Creating 1x1 textures of size 512x512 ...
[gl2] antialiasing off
[gl2] bilinear linear
[gl2] Using image_bpp=24, image_bytes=3, isBGR=1,
gl_bitmap_format=GL_BGR, gl_bitmap_type=GL_UNSIGNED_BYTE,
gl_alignment=8, rgb_size=24 (8,8,8), a_sz=0,
gl_internal_format=GL_RGB8


Exiting... (End of file)
**********************************************************************


2: xvid(16:9 PAL) --> mkv [mkvmerge] 16:9 -->
**********************************************************************
MPlayer 1.0pre3-3.2.3 (C) 2000-2003 MPlayer Team

CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino 1464 MHz (Family: 6, Stepping: 2)
Detected cache-line size is 64 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled with Runtime CPU Detection - WARNING - this is not optimal!
To get best performance, recompile MPlayer with --disable-runtime-cpudetection.
Reading config file /usr/local/etc/mplayer/mplayer.confReading config file E:/mplayer/mplayer/config
Reading E:/mplayer/mplayer/codecs.conf: Reading /usr/local/etc/mplayer/codecs.conf: Using built-in default codecs.conf.
c:/windows/fonts/arial.ttf doesn't look like a font description, ignoring
Using usleep() timing
Input config file E:/mplayer/mplayer/input.conf parsed: 53 binds

Playing l:\wod\wod-ps-custom6-2.mkv.
[mkv] Track ID 1: video (V_MS/VFW/FOURCC), -vid 0
[mkv] Will play video track 1
[mkv] No audio track found/wanted.
Matroska file format detected.
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm:ffmpeg (FFmpeg MPEG-4)
==========================================================================
Audio: no sound
Starting playback...
VDec: vo config request - 480 x 384 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
SwScaler: using unscaled Planar YV12 -> BGR 24-bit special converter
VO: [gl2] 480x384 => 684x384 BGR 24-bit
[gl2] OpenGL Driver Information:
vendor: NVIDIA Corporation,
renderer GeForce4 Ti 4200 with AGP8X/AGP/SSE/3DNOW!,
version 1.4.0
[gl2] You have OpenGL >= 1.2 capable drivers, GOOD (16bpp and BGR is ok!)
[gl2] Creating 1x1 textures of size 512x512 ...
[gl2] antialiasing off
[gl2] bilinear linear
[gl2] Using image_bpp=24, image_bytes=3, isBGR=1,
gl_bitmap_format=GL_BGR, gl_bitmap_type=GL_UNSIGNED_BYTE,
gl_alignment=8, rgb_size=24 (8,8,8), a_sz=0,
gl_internal_format=GL_RGB8
[gl2] Creating 1x1 textures of size 512x512 ...
[gl2] antialiasing off
[gl2] bilinear linear
[gl2] Using image_bpp=24, image_bytes=3, isBGR=1,
gl_bitmap_format=GL_BGR, gl_bitmap_type=GL_UNSIGNED_BYTE,
gl_alignment=8, rgb_size=24 (8,8,8), a_sz=0,
gl_internal_format=GL_RGB8

Exiting... (Quit)
**********************************

u can see that matroska uses 64/45 for the 16:9 conversion whereas xvid 16/11 --- why is that really? Assault mentioned something similar too
also the container seems to have the final word as to the actual resolution

as for the quality:
i was previously experimenting with that clip using:
crop(14,8,696,564)
bicubicResize(624,352,0,0.5)
fluxsmooth(7,7)
undot()

with a b/p*f ratio of about 138

now i only need:
crop(0,8,0,-8)
lanczosresize(480,384)

getting b/p*f 164 according to gspot 2.21

visualy the second encoding is better (at least to my eyes) AND less noisy despite the sharper resize filter & the absence of denoisers

so i can only say: NICE job xvid team :D

edit: i forgot to say that when i don't set an aspect ratio for matroska the video plays @ 480x384

[Stux]

Originally posted by Assault
Happy New Year to you all!!!

@ Stux

A little bit OT:

As you know very much about mpeg4 you can perhaps answer my question.
AFAIK a PAL 16/9 anamorphic DVD is resized during playback from 720x576 to 1024x576. That would mean that the PAL 16/9 PAR is 1024/720=64/45=1,42222222. But (I think) all PAR implementations I've seen use a PAR of 16/11 for PAL 16/9. That is 1,45454545. Is there any reason for that small difference? Or is 16/11 only an approximation and 64/45 is actual right? Thanks.

Assault

The total scaled up size is based on the ITU PARs, which are not exactly equal to what people think of as 4:3 or 16:9

The MPEG-4 PARs then seem to be a rough approximation of the ideal PARs, rather than custom-coding standard PARs like PAL 16:9, most implementations use the defined par_code which might not be perfect, but it is defined.

Unfortunately, I don't bother remembering the actual numbers ;)

My point is that "AFAIK a PAL 16/9 anamorphic DVD is resized during playback from 720x576 to 1024x576" is a wrong assumption, the true numbers are probably closer to 1050x576, of course this doesn't mean that your DVD Player will necessarily use the correct numbers, many video programmers (including DVD Player programmers) also don't understand AR ;).

The dirty secret: http://www.uwasa.fi/~f76998/video/conversion/

[Assault]

@ Stux

Thank you very much for the explanation (and for the link as well ;)). :)

Assault

[chilledoutuk]

ok heres a reply i wrote in reply to somone on the vidomi forum you might find it useful.

If you are encoding from PAL DVD source as you seem to be indicating there are 2 types of picture aspect ratios used 4:3 and 16:9 both anamorphic.

for films with aspects that don’t fit to these ratios black bars are used this is known as letterboxing.

first thing you have to do is take 1.85:1 aspect and forget it forever its not needed as with the picture aspect of either 16:9 or 4:3 we have all we need.

You said that the film aspect was 1.85:1 if this is the case you should have black bars at the top and the bottom of the screen on a 16:9 anamorphic frame.

The aspect you quoted is only slightly different from 1.78:1(16:9) so the black bars will be quite thin if the aspect you quoted is correct.

Anyways back to the point lets prove how Marty knew what he was doing.

If you’re going to crop black bars for instance from the video sequence then you will instantly change the Aspect ratio of that frame.

Because of this you have to convert the Picture aspect ratio to what is known as a Pixel aspect ratio. (This must be done with the source video's resolutions)

Pixel Aspect Ratio or Par for short is the ratio between the width and the height of individual pixels from an anamorhicaly resized video sequence.

the formulae I have devised to calculate the par is as follows.

Par = (VR x AR)/HR

VR = Vertical resolution of source video
HR = Horizontal resolution of source video
AR = Aspect ratio (ie 16/9 ~ 1.7

For PAL 16:9 video:-

Par = (576 x 1.7/720
= 1.424

The pixel aspect ratio for 16:9 PAL DVD's is constant as is 4:3 PAL DVD's therefore they only need to be calculated once. (Assuming PAL DVD standards are kept to!!)

now you said you only cropped the sides thus reducing the size of the source frame to 696x576 this will change the aspect ratio of the final video but do not fear as with the par we can now calculate the new aspect ratio from this.

Once we have calculated the new final aspect ratio we can use this to calculate the vertical resolution from any Horizontal resolution.

Ok let’s calculate the new AR after it has been cropped.

AR = (Par x HRC)/VRC

HRC = Horizontal resolution after cropping
VRC = Vertical resolution after cropping
AR = Aspect Ratio
Par = Pixel Aspect Ratio

Therefore

AR = (1.424 x 696)/576
AR ~ 1.72

By simply dividing any horizontal resolution by the new AR we can find the vertical resolution.

592/1.72 = 344

from this i can conclude that vidomi scales better than anything else around as it chose closest resolution divisible by 8 if it were set to use resolutions divisible by 16 then it would have used 336 or 352.

Oh by the way for best codec performance stick to resolutions divisible by 16 according to divxnetworks, dudes on doom9 and me.

[zulu]

Nice explanation! :)

Another quick and easy way to get the new AR for a cropped video is to use gknot for cropping. The respective AR is calculated while cropping and displayed in the Crop groupbox.

[AgeOfPanic]

How should I input this new AR in the codec before encoding. I tried encoding a cropped source before and I just selected 16:9 under Picture Aspect Ratio. Should I use 716:536 instead (the AR of the source) and should it be under Pixel Aspect Ratio or Picture Aspect Ratio?

[mikeX]

You'd be better off setting the picture AR at 16:9 (for a 16:9 dvd)

Giving it the picture AR of your cropped source is like giving a pixel AR of 1:1 and makes no sence for an anamorphically encoded source (such as an anamorpic 16:9 DVD)

you can also calculate the pixel AR of your cropped source and give that as an option
(assuming your example was for an anamorpic 16:9 PAL DVD you have 536*16/9 =~ 952, 952/716 = pixel AR = 119/67)

but that's more trouble for the same result

[jerryct]

Hello,

----
Neo Neko: Syskin would it be possible to get a utility even a simple CLI to rewrite the Xvid headers in AVI to contain the AR?
----

i want to know, wether it is possible to add the AR information to old xvid encodes without reencoding (maybe with a hexeditor).

do i have to edit the bi(X/Y)PixelPerMeter values?

----
Syskin: ... I was kinda keeping it secret to avoid any extra confusion, and questions like "how can I change existing avi" for which I have no answer
----

maybe in the meantime there is an answer?!

jerry