[MPlayer-users] Converting 512:272 to 480:480 with aspect=4/3?

[D Richard Felker III]

On Sat, Jan 17, 2004 at 02:37:06PM -0200, romildo at uber.com.br wrote:
> On Thu, Jan 15, 2004 at 07:07:11PM -0500, D Richard Felker III wrote:
> > 
> > On Thu, Jan 15, 2004 at 11:54:32PM +0100, Svante Signell wrote:
> > 
> > > Need advise hoe to expand/scale/crop an avi clip of size 512x272 to an
> > > mpeg2(SVCD) clip of size 480:480 expanded to 640:480 when displayed.
> > 
> > You have to do the math to work out the right sizes,
> 
> Is the math the following?
> 
> 	width ------------------ height
> 	640   ------------------ y
> 
> 	width * y = 640 * height
> 
> 	y = (640 * height)/width
> 
> In the example above of a frame size 512x272 we have y = 340.

Yes.

> > or else get
> > mencoder to do it for you with fancy use of the automatic options for
> > scale.
> 
> How would that be achieved?

You'd have to think about it some. See the man page for the various
ways to automate the sizes expand and scale select (using negative
w/h). You'd probably also need to use the dsize filter to set the
desired aspect. It's complicated and I don't feel like working out
exactly how it should be done, especially since I think it's better to
do things manually to be sure you stay on multiple-of-16 boundaries to
maximize quality.

> > Try:
> > 
> > -vf scale=480:340,expand=480:480
> 
> -vf scale=480:y,expand=:480
> 
> > Actually you should fudge the vertical scale slightly so that black
> > borders end up _exactly_ at multiple-of-16 boundaries (in this case,
> > scale to height 336 instead of 340) to maximize quality, but the above
> > commandline will at least work.
> 
> That is not much clear to me. You say that the black borders should
> end up exactly at multiple of 16 boundaries. What exactly a multiple
> of 16 boundary mean?
> 
>    0 ->	+-------------------------------------------+
> 	|                                           |
> 	|   (top black border)                      | 70
> 	|                                           |
>   70 ->	+-------------------------------------------+ <- boundary ?
> 	|                                           |
> 	|                                           |
> 	|   (movie image)                           | 340
> 	|                                           |
> 	|                                           |
>  410 -> +-------------------------------------------+ <- boundary ?
> 	|                                           |
> 	|   (bottom black border)                   | 70
> 	|                                           |
>  480 ->	+-------------------------------------------+
> 
> Is a boundary an offset in the vertical axis?

Yes.

> Are the boundaries in the example 70 and 410? If so,
> you are right. They are not multiples of 16.

Right.

> Using a height of 336 instead of 340 will give the
> boundaries (480-336)/2=72 and (480-336)/2+336=408, which
> are not multiple of 16 neither.

Sorry, my bad for being incomplete. You can tell expand to put the top
of the image at line 64 instead of 72 (-vf expand=480:480:0:72) and
then both top and bottom will be multiples of 16.

By the way, aligning to a multiple of 8 is better than no alignment at
all, but not as good as alignment by 16.

> In the example given, you say 336 is better than 340.
> I see that the image height (336) is a multiple of 16,
> but each black border height (72) is not. Is it
> enough that the image height be a multiple of 16 to
> get maximized quality?

No, sorry, I just messed up. :(

> PS: Which scaling method do you suggest for a good
>     speed/quality compromise?

Read DOCS/tech/swscaler_methods.txt. You're not just making a
speed/quality tradeoff decision, but a decision on what type of
artefacts/ugliness you'll get. Some scalers are better for downscaling
and others are better for upscaling. And certain scalers do better for
different types of content (CG versus animation versus live action)
etc. Why not try them with MPlayer first and see which ones you like?
The only ones I would recommend _never_ using are 4 (nearest
neighbor), 5 (area), and 8 (sinc).

Rich