[MPlayer-users] Re: mencoder/crop => image distortion

[D Richard Felker III]

On Mon, Jul 28, 2003 at 12:57:34PM +0200, ROED,HAAVARD (HP-Norway,ex1) wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> > I can't remember where, but I'm pretty sure I've read that 
> > MPEG-4 video 
> > can have dimensions that are multiples of eight. It may be 
> > that modern 
> > encoders have no problem with it, though older, less 
> > compliant ones did. 
> > I've been sticking with sixteen, since I know it works and it's not a 
> > hassle anyway.
> > 
> > Jonathan Rogers
> 
> I'd like to stick to 16 too (or even 8, if thats a 'good' number), but what
> if cropdetect says to crop the movie at some odd dimension that's divisible
> by neither 16 nor 8, or even 4 (or 2) if those numbers work with encoder "X"
> version "Y", ie 720:549.
> 
> 1. Round up to nearest acceptable Y, ie leaving (thin) black bands
> above/below
> 2. Round down ..., ie cropping a bit of the actual movie
> 3. Crop and then rescale the movie for the encoder
> 
> None of the above yields satisfactory results, since #1 propably affect the
> macroblocks and still consumes bandwidth due to edges, #2 obviously is not a

Yes, #1 is a very horrible choice unless you want to make a 3- or 4-cd
rip.

> brilliant solution (to me, atleast, I want the whole thing, not "most of

Cut the perfectionism. Encoding a movie with lossy compression is not
about getting a perfect quality copy. If you want to do that, rent the
film reel and duplicate it. Compressing movies is about getting a copy
that's not noticably missing anything compared to the original DVD.
BTW, the border pixels are typically full of noise that looks ugly and
wastes bits anyway. And when watching on a TV you wouldn't have seen
them anyway since they're in the overscan area.

> it"), and #3 would modify the aspect ratio, "mangling" the original movie.
> Scaling except in a player seems like a bad idea to me anyway.

Why? This is nonsense. The standard way of dealing with movies that
don't naturally come out to a perfect size is to scale to the nearest
multiples of 16. Then encode the actual perfect aspect in the mpeg4
headers, if you care, but no one will notice the difference anyway.

> (Particularily since the new aspect cannot be saved in the resulting file,
> except for the proprietary MPlayer tag.)

It is NOT a proprietary tag!!! It's in the mpeg4 standard!!!!! Crappy
windows players just suck too much to read it.

> If I were to scale the encoded movie, does something like -vop
> scale=720:560,crop=720:549:0:11 make sense? (the numbers are fictional, and
> for illustration purposes only - the point being that the cropping is done
> exactly at the edges of some funky movie with 11pxl black band above 12pxl
> below)

Lines come in pairs (because of the way chroma works, so I would
always use crop sizes and offsets that are even numbers. Otherwise you
could seriously misalign or distort the color.

> Finally, I guess it's the actual production of the movie that leaves us with
> problems such as these; In a really good (new, digital, precise) production,
> I guess cropping always can be done in sensible (ie. encodable) dimensions.

No one produces movies at 720x576.... The people doing this have much
higher-end tools and don't really care how well it compresses, since
they probably edit uncompressed video on huge clustered machines...

Rich