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

[D Richard Felker III]

On Wed, Mar 03, 2004 at 09:19:27AM -0600, Wayde Milas wrote:
> 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?

No, it just means that the physical width of the movie needs to be
1.78 times the physical height when displayed. As long as pixels are
square, physical dimensions are equally proportional to pixel
dimensions in both directions.

> > > 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.

It's difficult to make an accurate estimate like this. Bitrate
requirements do NOT scale with image dimensions. The reason is that
when you scale an image down, you increase the high-frequency content
in each block, so the DCT coefficients go up (and new nonzero
coefficients appear) and the resulting blocks don't compress as well.

> > > 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...

No. It has nothing to do with difficulty; all these players use
hardware scaling anyway. For other formats (mpeg, nut, quicktime,
matroska, ...) the aspect is stored in the container (or the container
is directly tied to the codec), so it's available early-on at init
time. But avi doesn't have an aspect header itself, so the only aspect
data comes from the codec once it's initialized and reads its headers.
But these bad players don't accept aspect from the codec, just from
the file format reader. Or at least that's my understanding.

So to settle the debate about standards. The mpeg4 aspect header is
totally standard in mpeg4. But mpeg4-video-inside-avi is not a
standard. It would make good sense to support using the aspect from
the mpeg4 stream (like mplayer does), but I guess these bad players
aren't violating any standards by assuming that avi means square
pixels (like it always historically did).

Rich