UPDATE: auto-RESIZE/deinterlace "xvid.ax" filter

[minolta]

UPDATE: Auto-resize now works!!!

@everybody:

DOWNLOAD: xvid.ax (http://www.public.iastate.edu/~chadspen/xvid.ax)

This filter allows your xvid clips to be auto-deinterlaced and auto-resized. It does this by simply reporting the internal mpeg-4 interlace and aspect-ratio flags to video renderer on-the-fly.

To install, simply copy the new filter to your xvid installation folder, usually:
copy xvid.ax c:\windows\system32\xvid.ax

NOTE 1:
May work only with Windows XP. Actual resize and deinterlacing is performed by video renderer (VMR7 or VMR9). If your application (MPC, WMP, Zoom, BSPlayer, etc.) turns off renderer's resize/deinterlace features then don't expect much. Defaults of WMP and MPC appear okay (forcing MPC to use VMR7/VMR9 causes problems).

NOTE 2:
If interlaced video is juddery then probably field order problem (xvid encoder always assumes bff). Force swapping field parity in registry with:
HKEY_CURRENT_USER\Software\GNU\XviD\SwapFieldParity = 1

NOTE 3:
Video may only resize after being paused/stopped (espec. w/ MPC). This is the same behavior with *.wmv files so not really a bug.

@xvid developers:

First, I am not a regular xvid contributor. This is just a quick hack of xvid-1.0.1 sources. I'm well aware that xvid's dshow filter has little focus since great projects like libavcodec exist (ffdshow, vlc, mplayer, etc.). This hack was in response to my experience with Microsoft's WMV9 which uses VideoInfoHeader2 to auto-deinterlace and auto-resize:

http://www.microsoft.com/whdc/devic...VA/default.mspx
http://www.ati.com/companyinfo/press/2000/4332.html
http://www.osr.com/ddk/graphics/dxvaguide_2087.htm

My hope is that developers are interested and will commit this style of auto-deinterlace/resize to the main project. It isn't very many lines of code, and its a feature that advanced users have always wanted. Here's the diff-files from v1.0.1 if interested:

xvid-1.0.1-auto-diff.zip (http://www.public.iastate.edu/~chadspen/xvid-1.0.1-auto-diff.zip)

-Minolta

[minolta]

Wow, talking to a brick wall sure is fun. Just kidding...maybe everyone here only encodes hollywood movies? For those brave enough to try the decoder out, here's some sample clips for comparison (sorry about the crappy content):

rl-i.avi (http://www.public.iastate.edu/~chadspen/rl-i.avi)
rl-p.avi (http://www.public.iastate.edu/~chadspen/rl-p.avi)
rl-pd.avi (http://www.public.iastate.edu/~chadspen/rl-pd.avi)

First clip is 60i, second is 30p, and last is 60p. All encoded with constant quality of Q=4. As we all know, xvid is not terribly efficient when it comes to interlaced, but this scene is quite high motion. If the 60i clip is not deinterlaced then try it with WMP (my default renderer in MPC does not obey interlaced flags).
-Minolta

p.s.
Unfortunately, it seems xvid cannot decode interlaced divx5 clips (in my tests anyway).

[Moitah]

Originally posted by minolta
Wow, talking to a brick wall sure is fun. Just kidding...maybe everyone here only encodes hollywood movies?I tried it on a concert, DVD source with dancing and fast camera pans. Looks pretty good :).

The output is double frame rate (i.e. 59.94 for NTSC) and half vertical resolution, correct?

Is there a field order flag stored in the bitstream? If so, I could possibly add a way to edit it in MPEG4 Modifier (http://forum.doom9.org/showthread.php?s=&threadid=78050).

[minolta]

Yep, double fps and resized vert (bob-deinterlace). With newer video cards you might even get hardware assisted 3d-adaptive or motion-based deinterlacing (see above links), but I wouldn't bet on it.

I determined 'interlace' and 'field order' using xvid structures in 'decoder.h'. The way I have it coded, these parameters can freely change on-the-fly (not that it'll ever happen).

typedef struct
{
...
int interlacing;
uint32_t top_field_first;
uint32_t alternate_vertical_scan;

int aspect_ratio;
int par_width;
int par_height;
...
}
DECODER;

In my experience, the 'top_field_first' parameter was always zero. It would certainly be very cool if it could be changed, but I know nothing about mp4 structure. FYI, the 'par_width' and 'par_height' parameters do indeed coorespond to internal aspect ratio.
-Minolta

[pogo stick]

Originally posted by minolta
Wow, talking to a brick wall sure is fun.
Don't be upset. I think that's because not many people are interested in encoding of interlaced video. I am not. But I'm sure if you 'teach' XviD decoder how to use aspect ratio from video file (like ffdshow do), there will be more interested people. This is one of the 'wanted' features, I guess.

edit: I changed my mind. Now I’m into interlaced encoding on interlaced video. Minolta convinced me :).

[SeeMoreDigital]

Personally I would not mind a 'script-less tool' that could convert 60fps (from 720p sources) to 30fps!

Any suggestions?

[WaryWolf]

Originally posted by pogo stick
Don't be upset. I think that's because not many people are interested in encoding of interlaced video. I am not. But I'm sure if you 'teach' XviD decoder how to use aspect ratio from video file (like ffdshow do), there will be more interested people. This is one of the 'wanted' features, I guess.

using Vegas Video to downsample clips gives a nice motion blur, but it costs $600, and i forgot what that is in pounds :(

but in the avisynth usage or development forum, there was a thread on downsampling and motion blur, if you'd be interested.

[minolta]

@pogo stick

if i have time, i'll try the auto-resize again. i've read something that makes it sound easy, but we'll see.

@SeeMoreDigital

sounds like you want a better mpeg2 transcoder...

-Minolta

[Koepi]

minolta:

if you find a way to resize the image after the graph is built that would be fine. We looked into that several times and always failed.

The interlace stuff is nice too - but since we're mostly not encoding interlaced we never thought about adding something like this :-)

Which reminds me, I'll add a control for enabling TFF and hope sysKin will commit it.

Regards
Koepi

[minolta]

@Koepi

tff addition sounds great, thanks. indeed, resize may require rebuilding the filter graph. hopefully its not too messy. here's a link, among others:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/dynformat.asp

busy this weekend so won't be able to test until wednesday or so. after reading msdn more, the interlace code needs some tweaking as well (works only by chance/defaults).
-Minolta

[minolta]

update in original post...

[malkion]

@minolta,

is this the feature which will allow directshow to display the correct AR of the video in an avi container?

[minolta]

@malkion:
yes, automatic resize even with an avi container.

[Moitah]

@minolta: It's a good start :). You need to check the value of aspect_ratio. par_width and par_height will only be set if aspect_ratio is XVID_PAR_EXT (extended, or "custom" PAR as I call it). The possible values for aspect_ratio are as follows (copied directly from xvid.h), look in the comments for the pixel ratio to use:
#define XVID_PAR_11_VGA 1 /* 1:1 vga (square), default if supplied PAR is not a valid value */
#define XVID_PAR_43_PAL 2 /* 4:3 pal (12:11 625-line) */
#define XVID_PAR_43_NTSC 3 /* 4:3 ntsc (10:11 525-line) */
#define XVID_PAR_169_PAL 4 /* 16:9 pal (16:11 625-line) */
#define XVID_PAR_169_NTSC 5 /* 16:9 ntsc (40:33 525-line) */
#define XVID_PAR_EXT 15 /* extended par; use par_width, par_height */
Also, black bars are added to adjust the aspect ratio. For example, if you have a video at SVCD resolution (480x480) and set the PAR to 4:3, black bars will be added to the top/bottom. This prevents you from going completely full screen.

EDIT: BTW, I already have the code done to change the field order flag in the bitstream. It will be in the next version of MPEG4 Modifier (not sure when it will be released, I am working on some other new features as well).

[malkion]

I tried a few tests to display correct AR.

All failed. If it works, a simple walk-thru would be appreicated.

I tried a 640,480 AR set to 16:9 using method 2 in AR tab.

Played as normal 640,480. :(

edit: using WinXP SP1, MPC defaults, ffdshow

[minolta]

@Moitah

Thanks for the advise. I'll change some AR w/ your mp4 tool and do some more tests. I've only tested with my own 4:3 and 16:9 which probably isn't very extensive (i think custom as you stated). BTW, I get black bars when windowed, but my fullscreen cuts them off as expected (WMP/MPC and VMR7/VMR9 tested). Hope this problem isn't too common.

@Malkion

Is ffdshow decoding your xvid files or not? This is the xvid directshow decoder only. 1. Disable XviD in ffdshow, 2. Install XviD codec (see Koepi's page), 3. Copy xvid.ax to system folder, 4. Verify that xvid.ax is getting used (graphedit, etc.). Can't say this filter will work for everybody since dxva/vmr9 is pretty new, but with latest installs it should.

-Minolta

[malkion]

minolta, thanks for the tip. working correctly now.

it's simply amazing.

[minolta]

@Moitah

made the changes and reupped xvid.ax and diff.zip, basically just:

if (ar == 2) {
par_x = 12; par_y = 11;
} else if (ar == 3) {
par_x = 10; par_y = 11;
} else if (ar == 4) {
par_x = 16; par_y = 11;
} else if (ar == 5) {
par_x = 40; par_y = 33;
} else if (ar != 15) {
par_x = par_y = 1;
}

also found another bug during the process (now using m_create.width instead of bitmap width)...enjoy.
-Minolta

[Koepi]

In xvid-1.1-alpha CVS i already added "manually" AR overrides to DShow decoder. I'll look into your code and will adopt the automatic settings (still default) to your way - nice that you found a working way!

Also, I finally added a "TFF" option to interlaced-encoding, but this also affects XviD-pre-1.1....

You may wanna look into that code to get some inspirations :) (i.e. how to add a control. but of course, I can do that, too...)

Regards
Koepi

EDIT: I just looked at the diffs - so you just use

IMediaSample2 *pOut2 = NULL;
AM_SAMPLE2_PROPERTIES outProp2;
[...]
CMediaType mtOut2 = m_pOutput->CurrentMediaType();
VIDEOINFOHEADER2* vihOut2 = (VIDEOINFOHEADER2*)mtOut2.Format();
[...]
pOut2->SetMediaType(&mtOut2);
m_pOutput->SetMediaType(&mtOut2);
pOut2->Release();

and it works on-the-fly-resizing?

I'll do a dirty-hack of exactly that and will see if it works :)

[minolta]

@Koepi

> (i.e. how to add a control

Hmmm, what to add for dshow controls? I downloaded the CVS and checked out the manual resize. For the automatic I think we might want:

---VMR Settings---
X Auto-Resize
X Manual-Resize (w/ your options for old/incorrect clips)
X Auto-Deinterlace
X Swap Field Parity (for compat. w/ old clips, but weak...)

But I'm bad at deciding these types of things, so I leave it to the experienced. To call the box "VMR Settings" or "VMR Input" or "Output Pin" or "Filter Output", I can't decide since none sound great. I like my four options since very flexible, but perhap too many.

Yes, the auto-resize was that simple. I tried four other advanced methods and failed, and then just tried the obvious...imagine my surprise.
-Minolta

[Koepi]

Unfortunately your diff has nothing in common with "unified" diffs like used on unix.

in which function did you add that code?

I tried putting it in the place where we just remarked DPRINTF("Autoresize here...");
in the pre-last function of CXviDDecoder.c .

but I can't properly test it now (VNC over a "low-bandtwidth" here at work, doesn't suffice for sending real images), and sysKin told me it doesn't work. (It doesn't work the way I now added it, your ax of course works [but only in mplayer2, mpc and zoomplayer override that.])

Regards
Koepi

[SeeMoreDigital]

Originally posted by Moitah
#define XVID_PAR_11_VGA 1 /* 1:1 vga (square), etc, etc.... */
#define XVID_PAR_43_PAL 2 /* 4:3 pal (12:11 625-line) */
#define XVID_PAR_43_NTSC 3 /* 4:3 ntsc (10:11 525-line) */
#define XVID_PAR_169_PAL 4 /* 16:9 pal (16:11 625-line) */
#define XVID_PAR_169_NTSC 5 /* 16:9 ntsc (40:33 525-line) */
#define XVID_PAR_EXT 15 /* extended par; use par_width, par_height */I have to admit I have never been happy with the above values. Because in order to get my Mpeg4 anamorphic 16:9PAL encodes to display the correct value of 1024 pixels I have to resize the source image to 704... and I don't like this!

Thankfully, you guys allow the user to manually input their own PAR values. So I prefer to enter the following: -

XviD PAR 4:3 PAL = 16:15 (16/15)
XviD PAR 16:9 PAL = 64:45 (64/45)
I've found that by entering the above values the Mpeg4 output exactly matches and behaves like the Mpeg2 input and the correct information is displayed in all software players.... imagine that ;)

[Stux]

Originally posted by SeeMoreDigital
I have to admit I have never been happy with the above values. Because in order to get my Mpeg4 anamorphic 16:9PAL encodes to display the correct value of 1024 pixels I have to resize the source image to 704... and I don't like this!


Your problem is your assumption/belief that 1024 is "the correct value", its not

[minolta]

@Koepi:

?? used cygwin's diff (unix compat) and tested w/ patch. oh well, here's the whole file:

CXvidDecoder.cpp (http://www.public.iastate.edu/~chadspen/CXvidDecoder.cpp)

-Minolta

[Koepi]

minolta:

ah thank you, now I found the proper place to add the stuff :)

(with the cygwin diff you should try the option -unH (i think it were those flags), it'll make the diff much more human readable.)

Checking if the stuff works now...

Thank you for the code, minolta!

Regards
Koepi

[SeeMoreDigital]

Originally posted by Stux
Your problem is your assumption/belief that 1024 is "the correct value", its not Well it obviously 1024 would be correct if you were using square pixels but answer me this....

Why is it when you extract and play an 720x576 anamorphic Mpeg2/VOB file in say MPC, the properties/details are reported as being 720x576 (16:9).

But why is it when you re-encode that same file to 3ivx or XviD using a 16:9PAL setting, and then slip the stream into an MP4 container, MPC will report the properties/details as being 720x576 (20:11)

I accept the technical reasons as to why the ratio's you use are used. However, weather they should be used and how logical they are, is another matter!

If you generate an encode using the settings I've posted there is no confusion in the players, the mattes and the video appears in exactly the same place as the DVD source, when viewed on either a CRT of LCD/Plasma monitor or TV screen. When sadly both yours and XviD's does not!

But if you don't believe me, try my calculations for yourself and compare them to yours: -


PAR 4:3PAL = 16:15 (16/15)
PAR 16:9PAL = 64:45 (64/45)
PAR 4:3NTSC = 16:18 (16/18)
PAR 16:9NTSC = 64:54 (64/54)


Cheers

[Koepi]

Ok, AR gets properly set now.

BUT...

the image gets shrinked. When setting it to fullscreen, only a small amount in the center of the screen gets filled.

Is it the same behaviour with your xvid.ax, minolta?

Regards
Koepi

[minolta]

@Koepi

Well, Moitah also reported the same thing with black bars. I have noticable black bars when windowed (since image does shrink), but my fullscreen crops them off. Tested with WMP10b, mplayer2, and MPC using
a fresh install of SP1.

Let's see if you and others have the same behavior with *.wmp files as well:

http://www.public.iastate.edu/~chadspen/highdef/kdsm-ricki-bff.wmv
http://www.public.iastate.edu/~chadspen/rl-i.avi

Both are interlaced 480x480 with 4:3 flags enabled. I'm betting you'll see the same black bars...if not, then something I need to fix.
-Minolta

[Koepi]

Found the solution on the web, precisely at microsoft's MSDN:
( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/htm/vmraspectratio.asp )

VMR7 resized in shrinking mode. at 4:3 ratio, this also happens on fullscreen. other ARs work as expected.

VMR9 properly does up-sizing in all cases.

Regards
Koepi

[minolta]

important safety tip, thank Koepi

[SeeMoreDigital]

I don't know weather this is of any interest but your XviD encode is borked when muxed into the MP4 container!

I used GraphEdit and mp4UI... but the result is the same!


Cheers

[chilledoutuk]

#define XVID_PAR_43_PAL 2 /* 4:3 pal (12:11 625-line) */
#define XVID_PAR_43_NTSC 3 /* 4:3 ntsc (10:11 525-line) */
#define XVID_PAR_169_PAL 4 /* 16:9 pal (16:11 625-line) */
#define XVID_PAR_169_NTSC 5 /* 16:9 ntsc (40:33 525-line) */

As far as i know these PAR's are the same PAR's that are used in the MPEG-2 streams that are on DVD's.

If theres a diiferance between the aspect of XVID and the orginal DVD playback then perhaps what you playing back the dvd with is displaying the movie with the incorect aspect.

[Stux]

Originally posted by chilledoutuk
#define XVID_PAR_43_PAL 2 /* 4:3 pal (12:11 625-line) */
#define XVID_PAR_43_NTSC 3 /* 4:3 ntsc (10:11 525-line) */
#define XVID_PAR_169_PAL 4 /* 16:9 pal (16:11 625-line) */
#define XVID_PAR_169_NTSC 5 /* 16:9 ntsc (40:33 525-line) */

As far as i know these PAR's are the same PAR's that are used in the MPEG-2 streams that are on DVD's.

If theres a diiferance between the aspect of XVID and the orginal DVD playback then perhaps what you playing back the dvd with is displaying the movie with the incorect aspect.

Exactly

[RadicalEd]

And yet, these ratios are still wrong (http://forum.doom9.org/showthread.php?s=&threadid=69899) :|

[SeeMoreDigital]

Originally posted by RadicalEd
And yet, these ratios are still wrong (http://forum.doom9.org/showthread.php?s=&threadid=69899) :| Try my ratio settings instead... They work perfectly for both Mpeg2/DVD and Mpeg2/DVB to anamorphic Mpeg4 :D


Cheers

[RadicalEd]

But... mine are mathematically perfect :P
Well, okay, the 702 used in the PAL calculations is also slighly imprecise due to there being no such thing as fractions of pixels, but it's pretty damn close.

[gircobain]

Standard?! What for?

Let's all advocate our particular favourite aspect ratio settings! :devil:

[obieobieobie]

Originally posted by gircobain
Let's all advocate our particular favourite aspect ratio settings! :devil:

My favourite aspect ratio is 13:37

Sorry, I couldn't resist. :D

[Koepi]

Originally posted by obieobieobie
My favourite aspect ratio is 13:37

Sorry, I couldn't resist. :D

...and I couldn't agree more ;)

Regards
Koepi

[SeeMoreDigital]

Originally posted by RadicalEd
But... mine are mathematically perfect :P
Well, okay, the 702 used in the PAL calculations is also slighly imprecise due to there being no such thing as fractions of pixels, but it's pretty damn close. Yes, but Mpeg2/DVD sources use 720 pixels, not 702 - or 704 for that matter...

The calculations that work for me were worked out as follows: -

4:3PAL = 767.999 divided by 720 = 1.0666666 - Which equates to 16:15
16:9PAL = 1023.999 divided by 720 = 1.4222222 - Which equates to 64:45
4:3NTSC = 639.999 divided by 720 = 0.8888888 - Which equates to 16:18
16:9NTSC = 853.333 divided by 720 = 1.1851851 - Which equates to 64:54Anyway, here are some tests encodes (http://homepage.ntlworld.com/seemoredigital/SMD_AR_Samples.zip) using some of the above settings.


Cheers

[gircobain]

Originally posted by SeeMoreDigital
Yes, but Mpeg2/DVD sources use 720 pixels, not 702 - or 704 for that matter...

Doesn't that somehow have something to do with the ITU-R BT.601 standard?

[RadicalEd]

Originally posted by SeeMoreDigital
Yes, but Mpeg2/DVD sources use 720 pixels, not 702 - or 704 for that matter...

The calculations that work for me were worked out as follows: -

4:3PAL = 767.999 divided by 720 = 1.0666666 - Which equates to 16:15
16:9PAL = 1023.999 divided by 720 = 1.4222222 - Which equates to 64:45
4:3NTSC = 639.999 divided by 720 = 0.8888888 - Which equates to 16:18
16:9NTSC = 853.333 divided by 720 = 1.1851851 - Which equates to 64:54

Your method has some serious flaws. They presume 720x480/576 is the full image resolution, whereas in reality 720x is merely a padded resolution. The true image frame is 711x486 and 702x576, respectively for NTSC and PAL. Since PAR = DAR/resolution, the true PAR of NTSC is (4/3)/(711/486)=0.9113... which in LCM fractional form = 72/79. In other words, no matter what the resolution, true NTSC should always be exactly that PAR. MPEG had to sacrifice accuracy in favor of mod16 practicality when they set the standard PAR at 10/11 (based on 704/480), which is only 0.25% off from the true PAR. However, it doesn't make sense to me why there were limits on the PAR accuracy, when PAR needn't be mod16. A messy digital issue, that is.
Anyway, on to PAL, (4/3)/(702/576) = 1.094... = 128/117. Abbreviated to 704/576 and 12/11, at 0.28% loss.
16:9 equations:
NTSC: (16/9)/(711/486) = 1.215...= 96/79
PAL: (16/9)/(702/576) = 1.459...= 512/351

Yeah, AR is a bitch.

References: http://www.uwasa.fi/~f76998/video/conversion/
Actually, I'm not up with the times :D NTSC is now officially 710.85/486 and 4320/4739 :P oh well... like I said, AR is a bitch.

[SeeMoreDigital]

Hi RadicalEd,

Well it's pointless turning this thread into another series of quotations regarding what constitutes the correct standard and what doesn't.

At the end of the day I don't think the majority of users are all that bothered about this. In my opinion all the majority of users want to do is encode from say, a 16:9 anamorphic PAL DVD, set the PAR in XviD (or any other codec) to 16:9PAL. And obtain an anamorphic encode that displays the correct information during playback, or when using third party applications such as the Matroska muxer!

I mean who really wants or needs to know that say, 16:9PAL is calculated as being 16:11 625-line, which generates an output encode that displays 20:11 (or whatever) in MPC or any other media player?

I would have thought the majority of people want to select 16:9PAL and generate an output encode that says it's 16:9 in MPC or any other media player?

In reality, quoting analogue PAL or NTSC line to digital pixel calculations is becoming more and more outmoded and irrelevant as we move ever nearer to an 'all' digital 'pixel only' domain... so using such calculations is probably pretty pointless anyway!


Well that's my 2 cents... Cheers

[RadicalEd]

No surprise if not a lot of users are bothered... it's totally convoluted stuff and no simple task to work out, yielding not much difference if any. MPEG's standards are fine for the majority of users. I just like the idea of getting that extra 0.3% accuracy ;]

[SeeMoreDigital]

Originally posted by RadicalEd
...I just like the idea of getting that extra 0.3% accuracy ;] Well there's nothing in-accurate about the encodes I've generated.

I've compared the original Mpeg2/DVD source against the Mpeg4 encode and viewed the results on a CRT PC monitor, CRT TV monitor, LCD PC monitor and a 42" hi-def plasma monitor. Using software and hardware players.

And everything appears in exactly the same place as the original source. What more would anybody else want other than that :D


Cheers

[OCedHrt]

Hmm, with the new directshow filter that supports AR, the reported AR in MPC and etc are more and more important now. I got this video that is 640x480 with a reported AR of 16:11, which should be 4:3 like mentioned earlier. However, since xvid's calculations sets it to 16:11, the decoder also resizes it to 16:11 >< And that isn't right :P Now there's more reason to have it say 4:3 so that the decoder will leave it at 640x480 which is 4:3 :P

Is there a way I can change the AR reported w/o re-encoding the video?

[SeeMoreDigital]

Originally posted by OCedHrt
Is there a way I can change the AR reported w/o re-encoding the video? Yes,

Use Moitah's MPEG4 Modifier (http://www.moitah.net/) and manually enter 16:18 for 4:3 NTSC....

PS: I thought 16:11 was nearer 16:9 PAL anyway!


Cheers

[sysKin]

Originally posted by OCedHrt
I got this video that is 640x480 with a reported AR of 16:11, which should be 4:3 like mentioned earlier. However, since xvid's calculations sets it to 16:11, the decoder also resizes it to 16:11 >< And that isn't right
Decoder is reporting 16:11 AR? That's wrong.
It would be good if you used XviD 1.1's dshow decoder, it also has this feature implemented and I'm (reasonably) sure the calculations are correct there. But then again they are the same, here.

Just to explain: it's not AR that is 16:11 but PAR is 16:11.

This PAR, combined with the video size 640x480, will give you AR of 64x33 (1.94 : 1) which... might be in fact incorrect. Why is it set this way?

Radek

[edit]Oh I read it again: you want 4:3 picture? But the resolution is already 4:3, why did you set PAR to anything but pure nice square?

[OCedHrt]

I didn't encode this video, the video was set to 4:3 I believe in the xvid encoder by whoever encoded it. I am using the xvid dshow decoder with the built in AR and it is using 16:11 as the AR and not 4:3. This was mentioned by SeeMoreDigital who used different calculations in the XviD encoder to get it to write 4:3 to the file. Selecting a 4:3 AR in the XviD encoder seems to output a 16:11 PAR. I'm not really sure what PAR is, but the XviD decoder is taking this value and resizing it to that ratio. I took an estimate of the new screen size from 640x480 -> 640x440. 640/440 is 16/11. Also, MPC the codec is reporting it as AR16:11 with VMR7(windowed). After some testing, here are the results:

VMR7(windowed)-> AR16:11
VMR9(windowed)-> No AR, but resized it to 698/480, which is the same thing.
VMR7(windowless)-> AR349:240 (same as 16:11)
VMR9(windowless)-> same as above.

I am pretty sure the encoder chose 4:3 in xvid when encoding and then had the video set to 640x480. Maybe thats where the problem is, should he have set it to 480x480 and then 4:3? Dunno. Either that or its an implementation error on the renderers? Doesn't seem likely but not impossible I suppose. Due to the changes in the number, I'm thinking MPC is just displaying the AR or whatever that the render is reporting. The XviD decoder is also using this value so I'm pretty sure its AR and not PAR? I'm quite clueless :) Here's a screenshot:
http://www.2and2.net/Uploads/Images/Xvid1611.jpg

[SeeMoreDigital]

OCedHrt,

What is your source. Mpeg1, Mpeg2 etc?

Do you know what the correct Aspect Ratio of your source is supposed to be?

Can you provide a small clip or full frame still from the source?


Cheers