[MPlayer-dev-eng] Recommend error for bad dimensions

D Richard Felker III dalias at aerifal.cx
Wed Mar 24 07:03:05 CET 2004


On Mon, Mar 01, 2004 at 07:25:05PM -0600, Zoltan Hidvegi wrote:
> > Would anyone object if I modify ve_lavc's config to FAIL by default if
> > dimensions are not multiples of 16? There would be an option to
> > override ("forcebadsize" maybe?) but IMO too many newbies refuse to
> > RTFM and generate poor encodes (which some players won't even play) by
> > choosing bad dimensions.
> 
> Well, this 16 limitation is not really spelled out in the docs.  Only
> DOCS/tech/encoding-tips.txt mentions it and even there it is not clear
> how important it is to keep the dimensions a multiple of 16.  I do not
> really care about other players, I only care about quality and size.
> E.g., the default 1080i HDTV resolution is not a multiple of 16.
> Also, when encoding DVDs I prefer not to scale them, I just crop the
> borders, so if I do not want to scale, is it better to leave it
> uncropped?  Or it is better to crop it then epand it so that only two
> edges have black borders?

No, it's best to overcrop or to scale. Why do you prefer not to scale?
Is there any good reason, or just superstition?

BTW, crop+expand (to add perfect-solid-black borders) is the absolute
worst option.

> What is the exact quality loss I would
> have?

Hard to measure directly. The theoretical explanations are very
satisfactory though. One is that mpeg formats always use 16x16
macroblocks, so if your dimensions aren't a multiple of 16, some of
the blocks will only be partially used (but still take just as much
space on average as a fully-used block). Also, motion estimation can't
work well at misaligned boundaries.

> If I use v4mv, then is it OK to use multiple of 8 dimensions?

No, v4mv doesn't change the fact that chroma blocks are 16x16 in luma
units... However, aligning dimensions at 8 is always better than not
aligning them at all. And v4mv might help motion estimation work
better near misaligned boundaries.

Rich




More information about the MPlayer-dev-eng mailing list