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

[OCedHrt]

The dvd says its 2.35:1. Not sure if that is right or not, but the uncropped original is 710x480 which FairUse promptly resizes to 688x384 which is 16:9. No matter what setting I put in the XviD encoder it comes out wrong. Specifying 2.35:1 in the XviD encoder w/o cropping results in AR43:22, forcing the XviD decoder to 16:9 or 2.35:1 will result in the correct output.

Uncropped, resized to 688x384.
XviD encoder specified 2.35:1, decoder auto:
http://www.2and2.net/Uploads/Images/xvid2351.jpg
XviD encoder specified 2.35:1, decoder forced 16:9 or 2.35:1
http://www.2and2.net/Uploads/Images/xvidforced169.jpg

These are using ogm containers. Just tried avi containers same result, I will try mp4 container if I can figure it out. Hm nevermind guess mp4 container doesn't work for these? Since XviD decoder won't decode them.

[SeeMoreDigital]

I need a full frame still from the source before you or your player adjusts it!

Play the same source again in MPC, navigate to a part of the movie where it's nice and light. Then go to: File / Save Image...

MPC will generate an 'uncorrected' bitmap image of the source which is what I need to see ;)


Cheers

[OCedHrt]

Orignal dvd source: http://www.2and2.net/Uploads/Images/snapshot20040722034542.jpg

I compared it with the forced 16:9 and 2.35:1 from above and they are the same, well, off by a very small amount of pixels on the y axis.

Update to all the random settings I've been trying, encoding uncropped and resized to 688x384 automatically by FairUse, and using square pixels this time, no other AR, the result is AR43:22, which is still wrong. AR43:24 may work out to be 688:384. Sorry, I don't know how any of this works :D

Hmm, seems like FairUse forces square pixels, so I'm testing it on a vob with MPEGMediator now.

[SeeMoreDigital]

Okay OCedHrt,

I can confirm that your source image is: -

16:9 wide-screen anamorphic. Using an 720x480 pixel frame.

The active 'image' pixel area (of the still you provided) uses an anamorphic 704x361 pixel frame, which means when the image is "pinged out" using the correct software player it will be displayed with an AR of 2.35:1 (or as near as damn).

I think you need to brush up on the theory behind anamorphic sources, anamorphic encoding and how it all works... as it can be quite a difficult subject to grasp.


Cheers

[OCedHrt]

Hehe maybe. But all I'm trying to get working is the proper AR written to the bitstream so that the new XviD dshow filter doesn't resize it improperly ><. Oh well :)

[SeeMoreDigital]

Originally posted by OCedHrt
Hehe maybe. But all I'm trying to get working is the proper AR written to the bitstream so that the new XviD dshow filter doesn't resize it improperly ><. Unfortunately there are very few DSdec filters that can automatically decode anamorphic Mpeg4 signalling when stored in an AVI container.

XviD's DSdec filter cant - Meaning the filter that comes with Koepi's XviD (v1.0.1)
3ivX's DSdec filter can - But only with it's own streams (not XviD's) as it prefers to detect it's own AR signalling method
ND's DSdec can - And it can do it with both XviD and 3ivX anamorphic Mpeg4 in AVI streams

If you decide to mux the anamorphic Mpeg4 streams into the MP4 container, 3ivx's DSdec filter will play them back at the correct AR 'automatically', provided they've been encoded correctly in the first place!

How do you want to re-encode/back-up your movie... using all 720x480 pixels - ie: with the black mattes. Or do you want to crop the mattes away?


Cheers

[sysKin]

Originally posted by SeeMoreDigital
Unfortunately there are very few DSdec filters that can automatically decode anamorphic Mpeg4 signalling when stored in an AVI container.

XviD's DSdec filter cant. It can now (dshow from xvid 1.1). It needs VMR7 or 9, and doesn't seem to work in mpc or zoomplayer but does work in mplayer2.exe (6.4). No other players are available here...

[SeeMoreDigital]

Originally posted by sysKin
It can now (dshow from xvid 1.1). It needs VMR7 or 9, and doesn't seem to work in mpc or zoomplayer but does work in mplayer2.exe (6.4). No other players are available here... My apologies for my previous XviD DSdec filter statement sysKin. I should have made it clear that I was referring to Koepi's XviD (v1.0.1) build and its DSdec filter. I've just amended my previous post to suite!

Anyway, I can confirm that I after installing Minolta's version of xvid.ax my anamorphic XviD encodes work perfectly via, mplayer2 (6.4), WMP9 and MPC (v6.4.8.2) when set to 'system default'.

So I don't understand why others are having problems with MPC :confused: I don't use ZoomPlayer so I can't comment about this player.

I'll provide a link to some of my NTSC 720x480 anamorphic Mpeg4 16:9 encodes if you wish?


Cheers

[minolta]

@sysKin

i checked out 1.1 from CVS. will it support my "auto-deinterlacing" as well (WMV9 and VP6 do...)? thanks,
-Minolta

[Koepi]

minolta:

I didn't find the time to (properly) adopt that yet, I'm thinking about something like:

"deinterlace" and after that a dropdown "auto | bob | weave | adaptive | none". And then "[ ] Change field order" (or TFF, dunno if it is the same thing ;) ).

I may do that next week, I'm quite busy lately again. :(

Regards
Koepi

[minolta]

good news, thanks Koepi. i guess you'll add an interlace flag to xvid_dec_stats_t.data.vol.general, right? the interface's drop-down menues for aspect and deinterlace sound good. i think specifying bob/adaptive could be problematic. perhaps 'auto', 'auto (tff)', 'auto (bff)', and 'none' (no more checkmark for swap fields).
-Minolta

[SeeMoreDigital]

I wonder whether this filter of yours could be used to read anamorphic Mpeg4 streams in the MP4 container too?

I guess all we need now is a nice splitter... anyone with any ideas!


Cheers

[minolta]

so far mp4 is supported by 3ivx, nero, qt, and mpegable filters, i think. not sure if xvid developers plan to support the container or not, but probably won't anytime soon. we'll see...
-minolta

[pogo stick]

Originally posted by minolta
UPDATE: Auto-resize now works!!!
Great! Thanks Minolta! :)
It really works for me in MP4 with MPC (except Overlay Mixer)! Behaviour is the same as with 3ivx and FFDShow decoders. It's very good to have it now in XviD decoder! :)
By the way, about anamorphic encoding. I still use GKnot to configurate crop part of AVS script. I was never good in counting numbers. :) So what I am doing now is cropping out black bars to make resolution even with 16 or at least 8. And then I am taking resize values from GKnot, putting it in Picture Aspect Ratio in XviD encoder and encoding video anamorphic. For example, 720x576(4:3 PAL)->(AVS crop)->704x576->(encode with PAR X:704 Y:528)->it plays as 4:3 video. So the question is: is it right thing to do? Not mathematically, because I don't mind a little error when my eyes doesn't see it.
And will there be any possible issues (that I should be aware of) with playing anamorphic in hardware MP4 players when (if?) they will be available.

[nanga parbat]

And then I am taking resize values from GKnot

while this will give you a correct apect, it is not the proper way to do it. see, the fact with anamorphic encoding is to keep the height constant (576 in your case) and adjust the width accordingly (which should then be 768).

notice that the width is now bigger than in the uncropped, squeezed picture. you size the picture down, that might introduce quality degradation, visually.

nanga

[pogo stick]

So the main point with anamorphic resizing is not downsizing height, but upsizing width? I thought it's the other way around with DVDs. :confused:
But there will not be a problem for me to change that info in bitstream of video with Moitah's Great (he should add this word to official name of the tool :)) MPEG4 Modifier. I didn’t mux videos finally yet. I am keeping it on HDD (the space is not big problem yet), waiting for 3ivx release to decide the fate of my encodes (mkv or mp4 ;)).

[gircobain]

The point is the human eye is much more sensible to image quality in the vertical axis than in the horizontal one
So keeping maximum height retains more 'perceivable' quality

[OCedHrt]

minolta's xvid.ax plays my square pixel files fine :) so does the 1.01 dshow filter. However, the dshow filter from cvs resizes my square pixel encodes improperly still :/ It downsizes the height by about 10%.

[SeeMoreDigital]

Has anybody else noticed that when you generate anamorphic encodes with B-VOP the new filter does not auto-adjust the AR of the image. But when you generate encodes without B-VOP the new filter does!

I've done tests using XviD, DivX5.2 and (de-muxed) Nero Recode2 video streams. And all behave in the same way.


Cheers

[Koepi]

The version I use locally (already with deinterlace-support[deinterlace if interlaced flag in mp4 is set, switchable in dshow gui], syskin has to check the code still) does the resizing properly.

It'll be out soon i'd say.

Regards
Koepi

[SeeMoreDigital]

Are you aware of the B-VOP problem then Koepi?

Just to confirm, all the B-VOP AR problems I've experienced are with progressive .AVI's streams.


Cheers

[Koepi]

No problems with xvid.ax (depending on bvops).

Latest CVS has an issue solved (also not depending on bvops), where it choose wrong AR all the time predefined ARs got used (i.e. PAR 1:1 has black bars added then, the image is "sompressed" in the height).

Try the attached avid.ax (copy it into your c:\winnt\system32-dir over the "old" xvid.ax, it should have the issue solved.)

Regards
Koepi

[SeeMoreDigital]

Just tried your proposed DSdec filter and I'm afraid to say that none of my anamorphic 720x576 or 720x480 Mpeg4 test encodes work correctly with it!

I tried MPC and WMP9 and it's the same in both... at least the previous build worked with non B-VOP encodes.

Just to confirm, when I change the encodes 4CC to NDIG and force them to use Nero's DSdec filter they AR correctly.

Let me know if you need any further info?


Cheers

[Koepi]

Maybe you need a new core for it, too... damn, i should have thought about that earlier. Can you send me an email so i can send you a complete build?

Thank you.

Regards
Koepi

[SeeMoreDigital]

Hi Koepi,

I've just sent you a PM with my email information.


Thanks

[SeeMoreDigital]

Okay, for all those people who doubt my method of calculating anamorphic aspect ratios is 'flawed'. Please download each of the following images into one folder and then flick through them, one at a time, using Micro$oft's "Windows Picture and Fax Viewer".

When you do this, you'll be able to see quite clearly that XviD's (and 3ivX's) default 16:9 PAL setting does not match the DVD source. For starters the horizontal pixel width is out by 23 pixels!

This is what you see when you capture from the 'original' Mpeg2/DVD .VOB: -

http://img45.exs.cx/img45/9674/SMD_01_Mpeg2-VOB_in_VOB.jpg


This is what you see when you use "XviD's default 16:9 PAL (16:11) setting": -

http://img38.exs.cx/img38/8831/SMD_02_XviD_Default_in_AVI.jpg


This is what you see when you use "My proposed 16:9 PAL (64:45) setting": -

http://img38.exs.cx/img38/7378/SMD_03_SMD_Proposal_in_AVI.jpg


This is what you see when you use "My proposed 16:9 PAL (64:45) setting" after muxing into MP4: -

http://img47.exs.cx/img47/4635/SMD_04_SMD_Proposal_in_MP4.jpg


Cheers

[Didée]

I see 3 oval lenses, and 1 circular one ;)

You're right regarding "reproducing the source" - but that doesn't save you from checking if the source is correct, after all.

[SeeMoreDigital]

Originally posted by Didée
... but that doesn't save you from checking if the source is correct, after all. You should not need to check the source first if your generating an 'full' 1:1 'pixel-for-pixel' encode.

The point that I'm trying to put across (badly it would seem) is that the method currently used to calculate the default anamorphic PAR settings is not correct.

Sadly even Moitah's 'excellent' MPEG Modifier uses the same 'default' PAR calculations as both XviD and 3ivx!


Cheers

[Wilbert]

When you do this, you'll be able to see quite clearly that XviD's (and 3ivX's) default 16:9 PAL setting does not match the DVD source.
This doesn't mean that the DVD source is played correctly. It all comes down to whether DVD's are mastered being ITU compliant or not. If it isn't the DVD source is played correctly (1024x576), and if it is XviD/3ivX plays them correctly (1047x576).

[SeeMoreDigital]

Hi Wilbert,

I've tried over 20 DVD's. Some PAL, some NTSC and they all respond in the same way.

I've tested my findings in my software players (WMP9, MPC and ZoomPlayer) and in hardware player (Sigma Xcard), using both software and hardware output options.

I've puked the video output from my PC to an analog CRT TV via composite, s-video and scart RGB. I've puked the video output from my PC to an 42" HD plasma TV via composite, s-video, scart RGB, component RGB, component YUV.

I've also used an analog PC monitor connection and a digital DVI monitor connection. And all confirm/reveal the same results!

It think it would be just my bad luck if all the DVD's I've tried were not mastered to ITU compliancy :eek:

But in the interests of accuracy I'm willing to do more tests using any DVD you care to recommend... I would just like to get this matter out sorted and out of my head.

Maybe you could do some encoding and capture tests yourself. As a cross reference?


Thanks :D

[Wilbert]

I've tried over 20 DVD's. Some PAL, some NTSC and they all respond in the same way. (...) It think it would be just my bad luck if all the DVD's I've tried were not mastered to ITU compliancy :eek:
Btw, software dvd players just use 16:9 or 4:3 for display by reading of the DAR (I think). The DAR is not enough in order to know how to play them correctly.

Besides that, you can't tell which resizing is correct by just watching it on a dvd player.

I think there's only one way to check it. On some dvd's the real aspect ratio is given (2.35:1, 2.40:1, 1.78:1, etc.) You should do the following test on them (assuming they are anamorphic):

1) Resize them to 1024x576 and crop away all black borders (not ITU compliant).
2) Resize them to 1048x576 and crop away all black borders (ITU compliant).

Now calculate the aspect ratio for both cases and see which one matches the given one on the back of the dvd. A while ago I did it for Gladiator (which is 2.35:1), and it turned out (1) should be used for resizing.

Maybe we should start a new thread and do those tests for various dvd's.

[SeeMoreDigital]

I understand what you mean but cropping away the mattes is not going to help matters here.

The purpose of my exercise is to show that the method of PAR calculation (for the entire frame) is incorrect.

At the moment it appears to have been calculated using 704 pixels as the horizontal pixel start point. This would be fine if an DVD used 704 pixels but it does not. It uses 720!

For example. When calculating the PAR of an 16:9 PAL anamorphic clip, XviD and 3ivx (and now Moitah) currently do this: -

720 x (16:11) 1.45454545 = 1047.2726 - which is incorrect!


However, if the DVD contained 704 horizontal pixels (which is does not) they would get this: -

704 x (16:11) 1.45454545 = 1023.9999 - Which would be correct.


If they used my calculation they would get this: -

720 x (64:45) 1.42222222 = 1023.9999 - Which is correct.


Cheers

EDIT: My calculations also work for cropped encodes

[Koepi]

The mpeg4 standard has a clear regulation for this. Maybe we should add "[ ] non mpeg4 compliant AR mode", where we would respect your observation.

I'm getting DSL in 2 weeks, so until then I can't do any "serious" coding / uploading / anything (I'm online from work though, but there I don't have any time left for these things - and I have to do much on my old and new flat...)

Anyways, would that be a solution in your sense?

Regards
Koepi

[SeeMoreDigital]

Originally posted by Koepi
The mpeg4 standard has a clear regulation for this. Maybe we should add "[ ] non mpeg4 compliant AR mode", where we would respect your observation. Hmm!

Who's to say that the Mpeg4 standard is correct?

I think it's safe to say when they came up with these calculations they had no method of checking them because nobody had developed any encoding or decoding software to see if they worked.

Given that most people who use XviD, crop and re-size their Mpeg4 back-ups, it ain't going to bother them anyway!

But I really think adding a "non mpeg4 compliant AR mode" is a step too far. I mean, if you just used my proposed calculations, how many end users are gonna know the difference anyway?

At least when the generate full or cropped anamorphic encodes they'll get a correctly sized encode :D

Am I rambling?

Nice to see you're settling in to you new home Koepi.


Cheers

[Wilbert]

@Koepi,

If you feel the need to split of some post in a separate thread, go ahead :)

"[ ] non mpeg4 compliant AR mode"
Sounds great! But I prefer to call it "[ ] non itu compliant AR mode" (GKnot and FitCD calls it this way).

@SeeMoreDigital,

Either you didn't read my post carefully, or you didn't understand. Because it gives a clear answer to your question.

If the calculated AR (after cropping) matches the AR on the back of a DVD using (1), then you should use (anarmorphic case)

576*16/9 = 1024

with PAR = 16/9 * (576 / 720) = 1.4222 (just like you said).

If the calculated AR (after cropping) matches the AR on the back of a DVD using (2), then you should use (anarmorphic case)

576*1.3675*1.3333 = 1050

with PAR = 1.3675 * 1.3333 * (576 / 720) = 1.4586 (just like you said).

The numbers are not entirely the same because they assume an active image of 704x576 instead of 702x576.

Accordingly to the specs the 16:9 image should be contained in 702x576. That's why XviD/3ivX resizes a 720x576 clip to a width which is a bit wider than 1024 (because it assumes the itu specs).

[RadicalEd]

That's why XviD/3ivX resizes a 720x576 clip to a width which is a bit wider than 1024 (because it assumes the itu specs).

That's not entirely true. Mpeg-4 AR assumes 704x active image in its ratio calculations. Of course, that's not the case for either PAL or NTSC, but rather a digitally convenient approximation. As I already mentioned previously in the thread, here (http://forum.doom9.org/showthread.php?s=&threadid=69899) is a list of correct PAR calculations taking into account the true encapsulated image area.

SMD, as Wilbert pointed out and as I mentioned earlier in the thread, your calculations are wrongly assuming that 720x is the active image. It's not. If it were, they'd be precisely correct. Since the true image is encapsulated in the 720x frame, instead, they are even further off than Mpeg-4's default values.
If non-mpeg 4 AR presets are included, they should be the true values I listed.

[SeeMoreDigital]

Originally posted by RadicalEd
SMD, as Wilbert pointed out and as I mentioned earlier in the thread, your calculations are wrongly assuming that 720x is the active image. It's not. If it were, they'd be precisely correct. Since the true image is encapsulated in the 720x frame, instead, they are even further off than Mpeg-4's default values.
If non-mpeg 4 AR presets are included, they should be the true values I listed. I think it's far to say we can all understand each others point of view and have a working knowledge of why the ITU standards are there and what they represent.

As I've said before, I don't think the majority of people need to know or understand all this technical stuff. All they want to do is generate encodes.

And if they want to generate, anamorphic Mpeg4 encodes (which in essence should be at 1:1 with anamorphic signalling) it's all getting very confusing!

In my opinion, there shouldn't be any need to crop/resize the horizontal axis of the Mpeg2 source prior to generating an 1:1 encode. The less work you need to do with the souce the better!

I just think this has become another classic case of "the more we learn the less we know" - And I include myself in this ;)

And in this instance we are letting the ITU specs get in the way of what should be logical 'pixel size and frame size' information!

Anyway, I think it's healthy for us to voice opinions every once in a while. As sometimes it can change ways of thinking and sometimes not!

At least non of us have started falling out :D Which is nice!

Now one more thing! Koepi, when do you think you'll be able to release your new DSdec filter?


Cheers

[Koepi]

SMD:

i should have internet in 2 weeks, also I should have cleaned my old flat then. So expect it mid-september. (I don't even find the time to compile a 1.0.2 binary :( )

Regards
Koepi

[SeeMoreDigital]

Thanks Koepi,

At least now we have an approximate date to pass onto the 'millions' of people who are asking about it.

If the auto AR setting can be made to work as seamlessly as Nero's, as time goes by people won't even realise it's there!

And sadly all those newbie users wont even realise the effort you guys went to to create an 'anamorphic' DSdec :(

I appreciate it though and thank you very much indeed :D


Cheers

[Palikrovol]

Originally posted by Koepi
SMD:

i should have internet in 2 weeks, also I should have cleaned my old flat then. So expect it mid-september. (I don't even find the time to compile a 1.0.2 binary :( )

Regards
Koepi

A binary for 1.0.2 is availble in www.canalxvid.com (spanish web). Go to "descargas" -> "codecs" -> "XviD 1.0.2 Final" -> DESCARGAR

regards

[RadicalEd]

Originally posted by SeeMoreDigital
In my opinion, there shouldn't be any need to crop/resize the horizontal axis of the Mpeg2 source prior to generating an 1:1 encode.
Of course, there is no need to do so. That's the beauty of PAR, it's independent of frame encapsulation. You can pad and crop all you want and the correct PAR setting will still deliver the correct image. It doesn't matter if it's 720x480 or 704x480 or 711x486 or 539x1068, as long as each pixel is distorted by the right ratio (PAR). The only difference between 64:45, 16:11, and 512:351 is that the latter is the true PAR of PAL anamorphic pixels (calculated from an active image of 702x), whereas the other two are respectively calculated from an arbitrary width of 720 (which doesn't correspond at all with actual active image) and 704, an approximated active image area for digital convenience.
Either way, the ratios I mentioned are the most accurate (within reason) no matter how you crop it. There's no sense in using less accurate values. I'm not trying to sound like a selfimportant ass, I'm just positive about my reasoning :p if a better explanation is needed, please let me know.

[SeeMoreDigital]

Originally posted by RadicalEd
The only difference between 64:45, 16:11, and 512:351 is that the latter is the true PAR of PAL anamorphic pixels (calculated from an active image of 702x), whereas the other two are respectively calculated from an arbitrary width of 720 (which doesn't correspond at all with actual active image) and 704, an approximated active image area for digital convenience. Quoting 'active image' areas (in accordance to the ITU specs) is all well and good but as we all know not all Mpeg2/DVD's follow this spec 'to the letter'.

All professionally made DVD's are encoded using 720 pixels, whether all the pixels are active or not.

I've generated quite a few encodes using my preferred custom PAR settings. And I'll continue to use them because my own tests have shown that they are more accurate.

Plus, if you use VMR9 rendering the correct pixel frame (video size) is revealed. This sort of information might not be useful to some people... but it can confuse the hell out of most!


Cheers

[Wilbert]

@SeeMoreDigital, RadicalEd,

Did anyone of you do the test I proposed?

[SeeMoreDigital]

Originally posted by Wilbert
@SeeMoreDigital, RadicalEd,

Did anyone of you do the test I proposed? Not recently Wilbert!

But I do know what your driving at. For example the Star Wars 1 (PAL) DVD I tested, after cropping has an 'active' pixel frame of, 718x440 - which for a supposed 2.35:1 movie, is quite a bit out.

T2 Extreme (NTSC) @ 2.35:1, after cropping has an active pixel frame of, 719x366.

American Beauty (PAL) @ 2.35:1, after cropping has an active pixel frame of, 704x428

Gold Member (PAL) @ 2.35:1, after cropping has an 'soft' active pixel frame of, 716x439. And a 'hard' active pixel area of 714x435.

The thing is, most DVD's these days are telecined to use the 704-720 space as an 'frame bounce' area (not just an over-scan area). This is fine if the frame bounce is just horizontal. But does look a right arse if it starts happening vertically - as seen in both my Blade Runner DVD's.

When DVD's are viewed on a TV, nobody tends to realise that there's a bit more image hidden away from their view to be seen. It's only us "saddo's" who know about these things... and want to watch it!


Cheers

[pogo stick]

I finally had a little time to test filter again.
I tried interlaced encoding and I must say that XviD decoding is very nice. It makes me rethink my attitude to encoding of interlaced video. No problems with deinterlacing and it looks very good. Also I thought of possibility of making decoder not only "bob", but also to "weave" and to make it auto-choose between 2 modes like in most MPEG2 decoders. Will it be very hard thing to do? It would be great for hybrid video, I think.
Originally posted by SeeMoreDigital
Has anybody else noticed that when you generate anamorphic encodes with B-VOP the new filter does not auto-adjust the AR of the image. But when you generate encodes without B-VOP the new filter does!
I also noticed B-VOPs bug.
1.1 version from 2004.09.06 doesn't seem to work right too. :(
Originally posted by nanga parbat
while this will give you a correct apect, it is not the proper way to do it. see, the fact with anamorphic encoding is to keep the height constant (576 in your case) and adjust the width accordingly (which should then be 768).
notice that the width is now bigger than in the uncropped, squeezed picture. you size the picture down, that might introduce quality degradation, visually.
And I noticed that it doesn't matter if PAR is 704:528 or 768:576. Two files will be exactly the same with AR 4:3. And the picture is upsized and not downsized.

[SeeMoreDigital]

Hi pogo stick, long time no see!

Here's hoping that the bugs in the XviD DSdec filter can be solved soon!

Out of all the Mpeg4 filters currently available it's my one of choice!


Cheers

[pogo stick]

Hello, SeeMoreDigital!
It’s good to be back. :)
Decoder is good, but there are no perfect things. :(
Let’s wait...
By the way, did you try interlaced video with your hardware card?

[minolta]

Originally posted by pogo stick
I finally had a little time to test filter again.
I tried interlaced encoding and I must say that XviD decoding is very nice. It makes me rethink my attitude to encoding of interlaced video. No problems with deinterlacing and it looks very good. Also I thought of possibility of making decoder not only "bob", but also to "weave" and to make it auto-choose between 2 modes like in most MPEG2 decoders. Will it be very hard thing to do? It would be great for hybrid video, I think.


As it concerns the de-interlace/weave of the filter:
-progressive clips are played progressive (interlace is turned off; graphedit may report otherwise; let me know if you think your progressive clips are 'bobbing' up/down)
-interlace clips are de-interlaced by the vmr (usually bob, but vmr9 can do motion-based techniques if available in hardware)
-so, all is automatic...
-hybrid clips are possible (i've joined progressive and interlace AVIs using vdub, and the decoder did automatically switch; even switched when aspect ratio changed!)
-koepi will add settings to decoder gui, such as: auto, weave, bob (tff), bob (bff)

sound good?
-minolta

p.s. i discussed my dvd/mpeg-4 experience in this thread:
http://forum.doom9.org/showthread.php?s=&threadid=81495

[pogo stick]

Sounds great! Anything new will be good for me! :)
Originally posted by minolta
-hybrid clips are possible (i've joined progressive and interlace AVIs using vdub, and the decoder did automatically switch; even switched when aspect ratio changed!)
But is joining progressive and interlaced video MPEG-4 compliant?
And if yes, then is it possible to include in XviD encoder option to encode different parts of video differently (progressive or interlaced)? Maybe using "zones"? But then, in case of hybrid NTSC video frame rate should be different. So I think it will be hard to do, even so MP4 and Matroska supports VFR. I am confused here. :confused:
Is there something like post-IVTC possible to include in decoder?
Originally posted by minolta
-koepi will add settings to decoder gui, such as: auto, weave, bob (tff), bob (bff)
Maybe instead of bob (tff) and bob (bff) "Swap Fields" checkbox would look better? Or just TFF checkbox, like in DivX encoder?

[minolta]

I "think" joining clips may still be mpeg-4 compliant...I assume frame 0 has full header info. Like you said, however, not really useful until VFR is possible. Mixing 30p with 60i only goes so far.

Not sure exactly what Koepi will decide for the decoder gui. A "swap fields" checkbox is probably very likely.

Would be great if decoder supported .mp4 (just VFR would be "huge", not to mention the other features).

-Minolta

[pogo stick]

But decoder works with MP4. Deinterlacing and auto-resizing (without B-VOPs) works the same way as with avi.
By the way, FFDShow isn’t auto-resizing avi.

[SeeMoreDigital]

Originally posted by pogo stick
But decoder works with MP4. Deinterlacing and auto-resizing (without B-VOPs) works the same way as with avi.
By the way, FFDShow isn’t auto-resizing avi. I have not been able to get this filter (or even any of Koepi's test filters) to work with Mpeg4 in MP4:( What parser are you using?


Cheers

[pogo stick]

3ivx D4 media splitter.
“Allow Unsupported Decoders” checked and no problems with XviD decoder.

[SeeMoreDigital]

Originally posted by pogo stick
3ivx D4 media splitter.
“Allow Unsupported Decoders” checked and no problems with XviD decoder. I will have to try that on my other boot drive!

I currently don't have 3ivX filters installed on both my boots because I've been generating a whole load of XviD Mpeg4/AAC files in .mov (for various commercial based web sites) and the 3ivX filters over-ride the default QuickTime player settings!

Thanks for the heads-up!

Now can any of the XviD guys make their own splitters and parsers for MP4?


Cheers

[pogo stick]

Originally posted by SeeMoreDigital
Now can any of the XviD guys make their own splitters and parsers for MP4?
That would be great.
Originally posted by minolta
I "think" joining clips may still be mpeg-4 compliant...
Can anyone confirm that to be sure?

I also noticed that auto-resizing avi’s with B-VOPs and packed bitstream works.

[SeeMoreDigital]

Originally posted by pogo stick
...I also noticed that auto-resizing avi’s with B-VOPs and packed bitstream works. Yes, these sorts of streams work very well.

It's very odd that when you generate XviD encodes with B-VOP but without packed-bitsteam (or remove the packed bit-stream afterwards), auto AR signalling/resizing with the XviD DSdec filter fails :(

I wonder if any progress can be made in this area?


Cheers

[lunaticmoon]

Originally posted by minolta
As it concerns the de-interlace/weave of the filter:
-progressive clips are played progressive (interlace is turned off; graphedit may report otherwise; let me know if you think your progressive clips are 'bobbing' up/down)
-interlace clips are de-interlaced by the vmr (usually bob, but vmr9 can do motion-based techniques if available in hardware)
-so, all is automatic...
-hybrid clips are possible (i've joined progressive and interlace AVIs using vdub, and the decoder did automatically switch; even switched when aspect ratio changed!)
-koepi will add settings to decoder gui, such as: auto, weave, bob (tff), bob (bff)


@minolta

Although it was late, I am interested in this report. :)

Does this mean the following two things?
1) The material creation by combination of an interlace material and a progressive material is possible.
2) A hybrid material (mixture fps material) can be treated by AVI.

When the above-mentioned mistake occurs, I want you to point out.

Using what means did you carry out 2) ?

Is only "hybrid" which is not so and is in your report a meaning called hybrid of an interlace material and a progressive material?

Then, it is interesting even if it is. I have heard that such a source material exists really. That means may be able to use for encoding of such a material. :)

[minolta]

My hybrid clip only mixed 30p and 60i, which maintained the same reported avi framerate (unfortunately). However, it shows that the VMR7/9 can switch on-the-fly between progressive and 'bob', which makes true hybrid clips (progressive, bob, and VFR) very possible. However, you'll need a container besides avi...

[billou2k]

I just wanted to come back briefly on the aspect ratio discussion between SeeMoreDigital , Wilbert, and Koepi. (Sorry;-) )
It seems to me that the misunderstanding comes from the fact that SMD interpreted "active" picture as "non-black" content in the picture (left and right side black bars cropped). But "active" has nothing to do with that. I think it is not just related with MPEG4 but more generally with the 601 standard (PAL and NTSC).
Actual frame size of PAL and NTSC are 720x576 and 720x486.
But "active" regions are 702x576 and 711x486 (that could be approximated to 704x480).
This means that these areas have to be displayed with a 4:3 aspect ratio (even if the picture actually has more than 702 or 711 non black pixels per line). That's what a TV does when receiving a signal, and that's what our monitors don't do, primarly because monitors are square pixel displays (that's why even 4:3 aspect ratios videos have to be resized on a PC).
Now as we have frames with 720pixels per line( 18 extra pixels in PAL and 9 in NTSC), the picture displayed will have a (width/length) ratio > 16/9.
That is the reason why I think Xvid is doing the proper thing. The only way to check that might be to check it with the method proposed by Wilbert. Surely at the end the eye can't tell which video has been displayed with the correct method as picture sizes are so close but it's still better to do it the proper way if we can I guess;-)
I hope I was clear enough, and apologies to SMD if he actually understood what I'm trying to explain here:D

[pogo stick]

Milan added deinterlacing part of this patch to FFDShow!
Look here (http://forum.doom9.org/showthread.php?postid=573151#post573151).

[hworldjj]

Hi, Minolta

I failed to download xvid-1.0.1-auto-diff.zip. Does it expire? It seemed this code had not been adopted in the new xvid, so would you please post it again or send me a copy? My email: hworldjj@gmail.com
Thanks!

hworldjj

[Jay Bee]

Wow, I've been looking for something like this for ages. Maybe I can finally leave my TV encodes interlaced now instead of bobbing to 50 fps before encoding.

Where can I get the file? And why hasn't this feature made it into official XviD builds?

[foxyshadis]

Because FFDshow has supported playback deinterlacing/bobbing for years now, presumably.

[Jay Bee]

Because FFDshow has supported playback deinterlacing/bobbing for years now, presumably.

But you have to switch it on per file instead of flag based auto-deinterlacing, right? (or am missing something again?)

[foxyshadis]

Well, kernelbob and dgbob you could leave on without affecting progressive video, but it would waste a lot of cpu, so yeah... be a nice addition to ffdshow though.

[SeeMoreDigital]

Where can I get the file? And why hasn't this feature made it into official XviD builds?XviD's encoder has offered "interlaced" encoding for quite some time.... I've been using it to generate interlaced encodes from pure interlaced HDTV sources for over a year now ;)

[Jay Bee]

Well, kernelbob and dgbob you could leave on without affecting progressive video, but it would waste a lot of cpu, so yeah... be a nice addition to ffdshow though.

Didn't know that they don't affect progressive. I just gave them a quick try. DGbob is too much for my CPU (Opteron 144@2.6 GHz) but Kernelbob is quite nice.



XviD's encoder has offered "interlaced" encoding for quite some time.... I've been using it to generate interlaced encodes from pure interlaced HDTV sources for over a year now ;)

Err, exactly. XviD has interlaced encoding but no deinterlacing decoding. So how are you playing those HDTV files?

[SeeMoreDigital]

Err, exactly. XviD has interlaced encoding but no deinterlacing decoding. So how are you playing those HDTV files?I'm playing them in hardware using a Zensonic Z500 (fitted with high-def capable Sigma EM8620L chip-set).

And yes, the lack of interlaced support in MPEG-4 software decoders is very frustrating.... Especially if you are into capturing and converting PAL DVB-T/S/C streams.

Just in-case you did not know, Moitah's MPEG4 Modifier is able to detect whether an MPEG-4 stream contains interlaced frames... I've found it very useful when generating test files.

[Jay Bee]

I'm playing them in hardware using a Zensonic Z500 (fitted with high-def capable Sigma EM8620L chip-set).

And yes, the lack of interlaced support in MPEG-4 software decoders is very frustrating.... Especially if you are into capturing and converting PAL DVB-T/S/C streams.

Just in-case you did not know, Moitah's MPEG4 Modifier is able to detect whether an MPEG-4 stream contains interlaced frames... I've found it very useful when generating test files.

Interesting. I haven't looked at anything to do with hardware yet, prolly should. Yes I am also a bit frustrated how everything in the MPEG-4 world seems to move with 25 FPS when real TVs have had much smoother motion for decades.

[Zeros]

Is there any MPEG-4 codec/decoder that suports deinterlace decoding? I know this thread is old but im very interesting in this feature. I know Videolan and FFDSHOW but I'm looking for a codec or decoder.

Thak you guys, and sorry for my English ;)

[SeeMoreDigital]

Is there any MPEG-4 codec/decoder that suports deinterlace decoding? I know this thread is old but im very interesting in this feature. I know Videolan and FFDSHOW but I'm looking for a codec or decoder.I'm not entirely convinced that even VLC player or FFdshow's decoders are actually able to correctly handle "interlaced" MPEG-4 sources....

EDIT: Shame they don't operate more like MPEG-2 decoders (ie: be set-up to work automatically)

[Zeros]

Well, at least my interlaced XviD encodings can be deinterlaced with Videolan in Bob mode (those videos are 720x576@25)

I also used MPCLassic with his shaders, deinterlacing in Blend mode, but takes lots of CPU.

Of course this videos looks great in my DVD-DivX player , but this is normal because my TV is interlaced.

On another way, thanks for your answers :)

[Jay Bee]

Shame they don't operate more like MPEG-2 decoders (ie: be set-up to work automatically)

Yes, but I think the original xvid.ax posted in this thread did exactly that which is why I was asking if anyone could still provide the file since it's down.