What are acceptable DivX Pro 5.0.2 cropping and resolution mods?

[JimmyBarnes]

I've used mod 16 for resolution, but wonder if this is unnecessarily restrictive. No particular restrictions on cropping.

A search of the groups suggests that one should only crop on increments of 2. That's news to me as I've always cropped as the movie required - often in odd numbers of pixels - and seem to get very good results anyway. The only filter I use is Resize.

The Bitrate and Resolution Guide
http://www.doom9.org/index.html?/vdub_resize.htm
suggests horizontal or vertical resolutions evenly divisible by 8
are OK but "The final word on divx5 acceptable resolution"
http://forum.doom9.org/showthread.php? s=&threadid=19737&highlight=resolution
suggests mod 16 is the minimum acceptable (I notice Acaila agrees).

When I try mod8 res eg 664x280 I don't get the artifacts described, though the resultant AVI seemed to contain occasional large dust or similar film artifacts (as tho telecined, which was not the case), which I don't usually notice.

Interested in others opinions and experience.

JB

[ReTroAcTive]

the only restrictions on 5.0.2 i know can be found in vdub under options/compression. it says as follows,
width must be a multiple of 4
height must be a multiple of 2
valid depths 24 32

[TheWEF]

divx is encoded in macroblocks of 16 x 16 pixels.

e.g.:

640 x 272 = 174080 pixels = 680 macroblocks.

640 x 274 = 175360 pixels (0.7% more) = 720 macroblocks (5.9% more).

more macroblocks - more compression overhead.

for compressibility reasons i highly recommend to at least use w-mod and h-mod of 16 pixels.

w-mod 32 is recommended for playback compatibility on older gfx-cards.


wef.

[TheWEF]

Originally posted by JimmyBarnes
...A search of the groups suggests that one should only crop on increments of 2. That's news to me...

that was necessary using an older version of simpleresize.dll, problem is solved in the latest release.

no restrictions...

wef.

[hakko504]

Yes, there are some restrictions on cropping in AviSynth:

In RGB:
width no restriction
height no restriction if video is progressive
height mod-2 if video is interlaced

In YUY2:
width mod-2
height no restriction if video is progressive
height mod-2 if video is interlaced

In YV12:
width mod-2
height mod-2 if video is progressive
height mod-4 if video is interlaced


Using other crop-vaules can create strange artifacts at the end of lines/frames. And simple resize isn't the only filter that has problems with uneven crops. Check the AviSynth forum.

[ArdenDag]

There's also a good thread discussing compressibility with XviD on crops of mod 8, 16 and 32. With 32 giving the lower file sizes with equal quants, it's a good read.

http://forum.doom9.org/showthread.php?s=&threadid=18277&perpage=20&pagenumber=4

Of course it also proved that resizing threw away all the file size gains :D

[OvERaCiD23]

W-Mod ~~> 16
H-Mod ~~> 16

Crop values I tend to keep even, as I had a lengthy discussion a while back on this. however, i encode at either 640xXXX or 704xXXX, so my W-Mod is actually 32, but I'm not against 16.

[JohnMK]

Originally posted by hakko504
Yes, there are some restrictions on cropping in AviSynth:
In YV12:
width mod-2
height mod-2 if video is progressive
height mod-4 if video is interlaced


Interlaced input or output? What if you use DVD2AVI's Forced FILM or decomb's ivtc, is it still considered interlaced? I know XviD can output in interlaced, but DivX 5.02 cannot, at least not through GKnot directly. So the 4 mod restriction essentially irrelevent to this forum?

Also, Are you talking about this:

716x476 (that's mod 2 & 4) by -3 left, -1 right
(does this fail because 3 and 1 aren't mod2?)

Is that acceptable?

Or do you mean this:

716x476 (mod 2 & 4 again) by -2 left, -2 right

So essentially my question is, mod4 . . mod4 what? Mod4 the crop on any particular edge, or mod4 . . the 476 thingy?

Thanks for putting up with my incessant questioning. ;)

[hakko504]

I've become a little too accoustumed to the usage of Crop(left,top,-right,-bottom)

Yes, I mean that Crop(3,0,-1,0) is NOT acceptable as it means you split a pixel pair! The values are stored in AVIsynth in pairs (or 2x2 matrixes in the case of YV12), and they should never be separated. The restrictions I mentioned are applicable to both the values you feed to Crop() using the above notation, as well as the final resolution.

The reason interlaced YV12 has mod-4 resolution is that it stores the chroma for line 2 and 4 in the same unit! As well as the croma for line 1 and 3 is stored in the same unit.

Consider this, a small progressive picture of 4x4 pixels:
Luma: Chroma
AABB A B
AABB
CCDD C D
CCDDA,B,C& D are pixels who share chroma data.
Now this wouldn't be so bad to cut in half right? But now consider an interlaced picture with the same dimensions:Luma: Chroma
AABB A B
CCDD
AABB C D
CCDDIf you cut this in half, the two bottom lines dissappear, and along with them the color information for line 2! Not good.

But lets say that you cut 1 pixel from each side in the 4x4 frame. That should work, right? No, not really, because then you would have to interpolate to get the new chroma value { (A+B)/2 }

This situation will never appear in RGB as every pixel has full data in all channels, but even here it is a good idea to make the fields have the same size, hence mod-2 on height.
YUY2 on the other hand stores the data so two pixels next to each other shares the chroma data, and should therefor not be separated.

And after IVTC, ForceFilm or Deinterlace a video is always progressive. (Which means that the chroma data actually changes what lines it refers to before and after the deinterlace!) And whether the interlacing question is relevant here or not, the answer is that: yes it is. To gain speed you may put the crop before the deinterlacing stage thus gaining speed by deinterlacing less pixels. It may not seem like a major speed gain, but it may be significant if you have a long video (like LotR-SE) or a low end computer.

[JohnMK]

Very useful information. It might be useful if this knowledge is forced upon users of GordianKnot in future versions.

[hakko504]

I'm bumping this thread to say I've added most of this information to this page at www.avisynth.org (http://www.avisynth.org/index.php?page=DataStorageInAviSynth)

[manono]

Good one hakko504-

I've added your information to the new Sticky (http://forum.doom9.org/showthread.php?s=&threadid=42708).