[MPlayer-users] mplayer, scaling, croping, the REAL story? (long)

[Wayde Milas]

Ok, in my quest to understand DVD encoding, and how mplayer actually
works, I've come across this issue. I'm trying to completely understand
the scaling, aspect ratios, and how everything relates to everything
else. While I'm competent enough to encode movies that look good, I
still don't understand some of the fundamentals that have to do with
croping and scaling "correctly" and how this affects Aspect Ratios. BTW,
if this thread takes off and alot of my questions are answered, this
might not be a bad thing to add to the mplayer FAQ/documentation as I
feel alot of people are confused by this and there is no good source (at
least that I could find) to the following questions.

In all my following examples, I'm going to use the DVD AI (Artficial
Intellegance - Haley Osmond - Kubrik) chapter 5. To start, let me first
note some facts (and correct me if I get them wrong) and then pose some
questions.

1) All standard DVD's are encoded at 720x576. I've heard that there are
some that are not encoded at this, but I havent seen any.

So, My first question:

1A) How do you detect if a DVD is encoded at something different that
720x576? Using AI/chapter 5, mplayer shows on startup that:
MPEG-PS file format detected.
VIDEO:  MPEG2  720x480  (aspect 3)  29.970 fps  9801.6 kbps (1225.2
kbyte/s)
So I'm assuming that even though the DVD is encoded at 720x576, mplayer
is scaling it to 720x480 for play on the computer. Why? I can see it
being scaled for TV play, why for computer play?

2) Because all DVD's are encoded at 720x576, they must be "scaled" to
fit either the 4/3 "TV" or 16/9 "Widescreen" or some other ratio. I
understand this concept. TV and widescreen pixel are not square, thus,
the image must be "stretched" to look correct at this aspect ratio.

2a) What I don't understand is why mplayer spits out:
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [null] 720x480 => 854x480 Mpeg PES
How was this number obtained? I'm assuming 480 was kept constant because
both widescreen and normal TV's are assumed to only have 480 scan lines
(based on the 30 hz principal/rule that goes way back.. which is another
topic all unto itself). How in the world though does 720 get transformed
into 854? My limited understand and some playing around with numbers on
some scratch paper yields:

scaled width = Unscaled with * (aspect ratio/ (720/576))

This would be 720 *((16/9)/(720/576)) = 720 * 1.42 = 1024.

So... where does 854 come from? I've got the feeling I've overlooked
something having to do with aspect rations, but I cant figure it out.

3) I want to now crop this movie. Basicly, get rid of any black bars
that show up to both speed up the encode process, and save bits. crop
detect for AI chapter 5 reports:
crop area: X: 2..718  Y: 0..479  (-vf crop=716:480:2:0)14%  1.1% 0 0 67%

However It has been noted that cropdetect just outputs the raw "edges"
and that have been detected. It is up to the user to do the actual crop,

3a) It has been noted that one must apply constraints to the crop size
because mpeg4 encoding uses block sizes of 16 aligned on even boundries.
Ok.  I've heard that the width and height must be divisible by 16, and
that the vertical and horizontal offsets must be even. I have also heard
that vertical ofset should only be a multiple of 4? What exactly are the
constraints for optimal encoding?

3b) If I dont crop on the constraints listed above (and just use the raw
output from cropdetect), I've noted that mplayer plays the movie back
just fine, and that the size of the encoded file, compared to once
encoded with no crop at all, is smaller. Will there be an even greater
compression savings if the constraints are used?

3c) If I do not use the cronstraints, is this permissable by the mpeg4
standard, or is it just "wierd" that mplayer supports this?

4) Fun with scaling. The next step is to suppose that croping on a non
16 boundry is a bad thing. There are 2 ways to fix this. The first is to
crop on a 16 divisible boundry. In my case instead of croping at 716x480
I would crop at 704x480. Unfortunately, I am throwing away 12 lines and
I'd rather not do that. The Alternative is to scale the image. This
preserves the 12 lines of info, but intruduces some rounding errors.
Assuming the rounding errors are minimal, this is not a bad thing (in my
eyes).

I turned to the mplayer TOOLS directory and came out with the 
calcbpp.pl tool that computes a table of scaling sizes based on the crop
size and the aspect ratio. It also calculates average bits per pixel
based on a bits per second number you give it for each ratio. For AI the
top part of the table looks like (using calcbpp.pl 716x480 16/9 29.970
2000)

Prescaled picture: 1018x480, AR 2.12
720x336, diff   3, new AR 2.14, AR error 1.00% scale=720:336 bpp: 0.000
704x336, diff  -4, new AR 2.10, AR error 1.25% scale=704:336 bpp: 0.000
688x320, diff   4, new AR 2.15, AR error 1.33% scale=688:320 bpp: 0.000
672x320, diff  -3, new AR 2.10, AR error 1.02% scale=672:320 bpp: 0.000
656x304, diff   5, new AR 2.16, AR error 1.69% scale=656:304 bpp: 0.000
640x304, diff  -2, new AR 2.11, AR error 0.77% scale=640:304 bpp: 0.000
.
.
.

Ok, so the questions start right away:

4a) The first line is the prescaled picture line. What exactly is this?
The number looks familiar though.. Based on my above formula fo figuring
the scaled width of a DVD, 716 * (16/9 / 720/576) = 1018.111.. Ah Ha!
That number somewhat makes sense to me. I totaly loose it though when I
see the AR (Aspect ratio) of 2.12. What happened? Where does 2.12 come
from? The ratio of the movie is 1.78... Again, I feel like im missing
something basic. I though maybe its stretching the 1.78 * 1.42 but thats
2.53 which is way off. Help?

4b) The first line is silly since I would be scaling up, the second is
what I want, scaling down to the next 16 boundry in width. But why do
all these lines scale height by so much? I could see it perhaps being
480 or even 464. But 336? That completely distorts the aspect ratio plus
throws out a ton of the info I need to do an accurate encoding?

Well, that about it right now. I do have more questions, but I'm going
to wait till I understand the above concepts because I'm certain alot of
the questions I have not asked will be answered if I understand the
above. They mostly relate to autoaspect and set aspect ratios.

Thanks much for swimming through all this :)

Wayde



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20040302/fe0ffd6d/attachment.pgp>