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

[Wayde Milas]

On Tue, 2004-03-02 at 14:52, D Richard Felker III wrote:

> No, the movie is 720x480. 720x576 is for PAL discs. 720x480 for NTSC.

Oh. Duh. That makes sense :)

> > is scaling it to 720x480 for play on the computer. Why? I can see it
> > being scaled for TV play, why for computer play?
> 
> Because your monitor (or rather video mode) has square pixels and the
> encoded movie doesn't. Thus you'll have to scale.

Ah.. I see what you mean now that I think about it that way. Even though
the monitor is 1.33 in physical aspect, it in efect has square pixels
because its run at a resolution like 1024/768. 

> > 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?
> 
> By upscaling 720x480 to obtain dimensions with 1.78:1 aspect ratio.
> 480 * 1.78 = 854.

This is throwing me a bit. I think what you mean is you first need to
convert 720x480 -> 480x480 to take in to account the square aspect ratio
of the monitor. Then you multiply the new width of 480 by 1.78 which
yields the 854?

> 
> > 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?
> 
> All of this is correct. multiple-of-4 only applies for interlaced or
> telecined video.

Another concept demystified. Thanks :)

> 
> > 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?
> 
> Size is smaller? Under what encoding constraints?

Take a 720x480 file. Crop it to 716x480. Encode it and call it Avi-A.
Take a 720X480 file. Crop it to 716x480 and scale it to 704x480 (forget
about the AR error for now). Call this Avi-B.

Now compare the 2 files for file size. You cant compare them directly
because one was scaled. However, you can multiply Avi-B by 1 + the extra
bits that were scalled off to grow the file to compare it to Avi-A (I
think). This should give you a rough and ready number on what the actual
bits savings on encoding on a 16 bit boundry is. I'm trying to figure
out if there is a large savings in bits doing this, or if its minimal,
aside from the effect of the scale down.

> 
> > 3c) If I do not use the cronstraints, is this permissable by the mpeg4
> > standard, or is it just "wierd" that mplayer supports this?
> 
> AFAIK it's permissible, but some players don't like it. It might not
> be permissible in some of the more basic profiles.

As I'm encoding the files for play upon demand in my own household, and
the boxes that play all use mplayer, I guess thats not much of an issue
then.

> 
> > 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?
> 
> Because the final aspect needs to give square pixels if you're making
> an avi file that you want other players to be able to play. MPEG4
> codec has an aspect tag to support arbitrary aspect, but stupid
> windows avi player apps don't honor it.

Ah. Now I understand. Thats the whole thing with the autoaspect flag not
being honored by other players. I'm assuming its because arbitrary
software scaling is difficult, and other players just get away with
pixel doubling instead of tru scaling...

Thanks much,

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/20040303/01c01764/attachment.pgp>