[MPlayer-users] Re: best encoder ?

[D Richard Felker III]

On Tue, Jul 23, 2002 at 08:06:59AM +0200, Moritz Bunkus wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Hi.
> 
> > Personally I would just recommend scaling down vertically by about
> > 1/2, then there's no reason not to deinterlace since you're losing
> > half the lines anyway -- no additional "blurring" as you claim.
> 
> This does not always work. My Ally McBeal DVDs (bought in Germany) have
> some VERY strange interlaced pictures. If you take only the odd or only
> the even lines (that's what you would do if you scaled down to half the
> height) then the pictures still show interlacing artefacts. An example:
> The full picture
> http://www.bunkus.org/deinterlacing/int.png
> Only the even lines
> http://www.bunkus.org/deinterlacing/even.png
> Only the odd lines
> http://www.bunkus.org/deinterlacing/odd.png

Huh, this is a real DVD!?! It looks to me like a bad encode in
non-interlaced mode of a movie that was originally in interlaced form.
Seems there weren't enough bits to keep the interlacing intact so both
fields got blurred together in many places.

Also, every 16th line or so is doubled. This suggests that someone
scaled the movie vertically before encoding it. My guess would be they
scaled it from an interlaced NTSC source to PAL resolution without any
regard for fixing the interlacing.

Does this movie actually look right when played on a TV!?

Also, are you sure *you* didn't accidentally scale it when capturing
those pictures, e.g. with mplayer -zoom or whatnot?

> > Also, black borders make it impossible to play the movie on slow
> > computers since lots of memory bandwidth is wasted copying nothing.
> 
> That's not true. The black borders themself don't take that much
> bandwidth or processing power - the problem is that the transition from
> the picture to the black borders make the codecs waste a lot of
> bandwidth. So it's often better to either crop the black bars
> completely or even to take away some lines from the picture itself in
> order to get width and height divisable by 16.

Arrg, read what I said again! Memory bandwidth has nothing to do with
bit usage in the encoded file, but bandwidth on the memory bus when
decoding!! The only way to avoid this is if the codec supports DR
method 2. Otherwise, the whole frame has to be copied to video memory
24 times per second, and *gasp* that means we have to copy tons of
black pixels. With some hacking -vop crop should be able to improve
the situation, but right now it doesn't. In any case, leaving black
borders is terrible for performance.

Rich