[MPlayer-users] mencoder: ripping a dvd to a 700MB avi questions

Arpi arpi at thot.banki.hu
Sat Jul 6 10:39:01 CEST 2002


Hi,

> > Cropdetect tells the absolute maximum cropping, though, and as such is
> > only half the story: it's always best to keep the resolution as a
> > multiple of 8 (I've heard 16 is better, but I've never had trouble with
> > 8). Anyway, this necessitates either scaling a bit differently or
> > padding the crop estimates slightly with very small black borders.
> 
> also heard that. but what's the reason?

most codecs (mpegs, mjpeg, h263, sorenson) operates on 16x16 pixel macroblocks,
constructed from 4 8x8 Y (luminance) and 2 8x8 U,V (color) scaled blocks.

so, you should use width/height divisable by 16, but at least 8.

some vga cards has limitation on video width when using acceleration, so you
should try to get width divisable by 32 to work well with these.

why to avoid bad w/h ?
most codecs allow non macroblock boundary width/height, but it is just
wasting of bits (they actually expand the image to MB boundary size, adding
black bars, and they are automagically cropped down by the decoder) and
some codecs and standards(!) has bugs with these sizes, especially the
divx/mpeg4 ones, so it's better to avoid.

anyway, black bars itself don't waste the disk space, it actually uses just
a few bits, as modern codecs can handle such things well. but there are
disadvnages coding them:
- player will transfer black bars to the card, wasting PCI/AGP bandwith/CPU
- if the picture-blackbar edge isn't at MB boundary, it will reduce the
  quality of the edge a lot. (bits wasted to code the edge, instead of the
  picture)


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu




More information about the MPlayer-users mailing list