[MPlayer-users] probably my usual stupid question of the week

[D Richard Felker III]

On Sat, Apr 17, 2004 at 01:43:44PM -0700, rcooley wrote:
> On Fri, 16 Apr 2004 04:04:01 -0400
> D Richard Felker III <dalias at aerifal.cx> wrote:
> 
> > The code seems to be incorrect. It rounds to a larger region, leaving
> > black border, which makes cropping pointless.
> 
> I've been using it for months, and I can assure you that there are no
> black borders on anything I encode.  You must have simply read it wrong.
>  The way I formatted it might not have helped readability any.

OK, maybe so. It was confusing and I just read it quickly.

> > But even this is nonsense, since you
> > should just scale after cropping rather than overcropping or
> > undercropping to meet n%16==0 requirements.
> 
> First off, I would think that any scaling the video would cause some
> quality loss.  Am I wrong here?  Is there some method of losslessly
> scaling video that mplayer impliments?  I can deal with loosing 4 lines
> of picture, but adding more blur or other artifacts across the whole
> video is something I definately want to avoid. 

This sort of preconception comes from the "old days" of scaling
pixel-painted images, nearest-neighbor "scaling", etc. The game is
totally different with sampled images. Mathematically speaking, any of
the decent scaling algorithms lose much less data than cropping lines,
and in fact certain scalers (sinc) are lossless (aside from off-by-one
rounding errors) if you scale up. (But otherwise sinc is not a very
good choice.)

Of course there are lots of subjective factors too, as well as the
question of how different scaling or cropping parameters will affect
the efficiency of the mpeg4 encoder. But scaling by a few pixels
height won't really "blur" your picture.

> Also, this code has another purpose as well.  I couldn't use
> cropdetect by itself, because it usually didn't completely chop off
> the black.  I tried different values to cropdetect, but it was always
> either leaving a couple lines of black borders, or regularly cropping
> off too much.  It was mainly a problem on videos where the picture fades
> into black over 2-4 lines, like most videos recorded from a TV signal. 
> Interlaced content seems to confuse cropdetect as well, even when
> cropdetect is invoked after a deinterlacer, it seems that cropdect never
> gets it quite right.

BTW, always make sure your crop offsets are even numbers. Odd offsets
don't make sense. And for interlaced content, vertical crop offset
needs to be a multiple of 4.

Rich