[MPlayer-dev-eng] vo_sdl aspect

[Stephen Davies]

> btw. Steve, can you point me to a good website about these issues, I'm sure 
> you have digged far enough in this direction to have found one.

Hi Felix,

I've appended the README I wrote to try to explain this for my previous
patch.

For me, I got to understand it properly like so:

1) Aspect ratio of input files

First, consider the digitized resolution and intended aspect ration of the
source video file:

Remember that in the analogue video world, a picture doesn't have any
particular horizontal pixels.  Resolveable detail just depends on the
video bandwidth and electronics quality etc.  All the timings of the
PAL/NTSC signal + the TV electronics conspire to arrange that the
displayed video is around 4:3 in ratio.

In the analogue world the actual displayed ratio is a pretty inexact
science, with displays varying due to differing amount of overscan, video
signals are sometimes non-standard with different lengths of sync pulses,
front and back porch and all that stuff.

So: when it comes to digitizing analogue video:  You have a limited
vertical resolution - being the number of scan lines.  For PAL video,
there are 576 "visible" scan lines over the 2 fields of an interlaced
frame.  (Note that this can be a bit imprecise too - there are actually a
total of 625 lines all together including "non video" lines and the
vertical sync pulse time and all that).

So "full resolution" digital video will have 576 lines (all this for PAL,
NTSC is 480 I believe).

Now how many horizontal pixels?  Us PC people would have used square
pixels, and come up with 768x576 as the "right" ratio.  But the TV
industry settled on a "D1" ratio - 720x576.  I couldn't find a "why" on
that.  But its important to understand that the 720 pixels still represent
the whole horizontal line.  This is the ratio that is used on DVDs.  

Now 16:9 DVDs are digitized with the same 720x576 resolution.  But
are intended to display 16:9 ratio.  In this case its obvious that the
pixels are much wider than they are high (1024/720=1.42222 wider).

I suppose that using the same resolution made for easy compatibility to
the world of analogue widescreen, kept the mpeg2 stream within appropriate
bit rates etc etc.

Of course with real life video files you never can be sure what the
"proper" ratio is suppsed to be.  4:3 and 16:9 are in theory the likely
"proper" ones, but with all the clipping and scaling that goes on I'm sure
there are plenty around that should be displayed at other ratios to be
precisely right.  So its an inexact business in reality.


2) Aspect ratio of output display

Now - all the same issues of ratios come up on the output side
too.  Pixels put into video memory have to be turned into an analogue
video signals and displayed onto a CRT.

For many video displays and modes, the theory is that the video mode is in
a 4:3 ratio, and the displayed image has the same ratio.  But that isn't
always the case.  If you measure your displayed image on your monitor for
a 4:3 mode there's a good chance that it won't actually be
4:3.  Obsessive-compulsives might want to adjust their display controls to
get this exact...

There's a more important common case, though: those outputting video to
widescreen TVs - for me its convenient to leave the video mode as 720x576,
and switch my TV to a mode that displays that over a 16:9 ratio.  That
does the rescaling directly in my TV, stays within a resolution thats
supported by the bt869 PAL encoder used on my video card, etc etc.


So to do this all properly you have to take into account the
resolution/aspect ratio of the input, AND the resolution/aspect ratio of
the output.


                     input-aspect-x   input-pixels-x
x-scaling        = ( -------------- / -------------- ) * ...
                     input-aspect-y   input-pixels-y


                     screen-aspect-x   screen-pixels-x
                   ( --------------- / --------------- )
                     screen-aspect-y   screen-pixels-y


If you allow people to set the real screen-aspect-x/screen-aspect-y then
they can put that in their mplayer config once and for all after measuring
it.  Then you just need to set the aspect ratio of each input video
file.  With 4:3 being the default, 16:9 for "aspect 3" mpeg2 files.

Regards,
Steve Davies






===============================

From:		Steve Davies <steve at daviesfam.org>
Subject:	Aspect Ratio processing in mplayer
Date:		17th June 2001


Hi,

I've added some new functionality to mplayer to get it to handle
aspect ratios better.  Here's some background, and details on
my changes.


BACKGROUND
----------

Computer displays - in theory at least - usually have "square pixels".
That is, each pixel has the same height and width.

For example: computer monitors have an x to y ratio of 4:3.  Standard
video modes (640x480, 1024x768) have the same ratio of x to y pixels.

Of course you may be using an X mode which doesn't have square pixels.
If you are, you are probably used to seeing distorted images - X
programs generally don't take this into account - but mplayer now does.

It's common (usual, even) for digitized video to have non-square
pixels too.

The most obvious example is anamorphic widescreen DVD - where a 16:9
ratio picture is encoded at 720x576 pixels.  In this case the pixels
are 42% wider than they are high.  So, for it to display correctly on
a screen with square pixels, it needs to be scaled to 1024x576.

But even non-widescreen video files have slightly non-square pixels.
Standard TV displays have 4:3 aspect.  But non-widescreen DVD is
encoded at 720x576 - the pixels are 6.67% wider than they are high.
So this needs to be scaled to 768x576 to avoid putting everyone on a
diet!

Material encoded for 'SuperVCD' is another example: 4:3 source
material is encoded at 480x576 - needs to be scaled to 768x576 for
correct viewing.

Mplayer attempts to make scaling adjustments to correct for all this -
rescaling to account for non-square pixels both in the input video
and on the output display.


IMPLEMENTATION
--------------

Here's how I've implemented aspect ratio processing.

First off - if you use the -x and -y options to mplayer then the sizes
that you give are used with no further adjustment.  This ensures that
you can always get exactly the size that you want.

The -x and -y options are now honoured with -fs too.  The image will
set to the size you request and centred on the screen.

Some examples:

  mplayer -x 640 -y 480 filename.mpg	 - 640x480 pixel window used
  mplayer -x 640 -y 480 -fs filename.mpg - 640x480 image centred fullscreen
  mplayer -x 1 -y 1 filename.mpg	 - shown pixel-for-pixel same size

If you do not specify the -x or -y options, then aspect ratio
processing is done to determine the correct size.

To do this, the code needs to know the physical aspect ratio of the
source video, together with the physical aspect ratio of your output
display.  That is: the width:height ratio represented by the x and y
pixels in the input file or on the output display.

By default both are set to 4:3, except for MPEG input files in "aspect
3" - where 16:9 is used.

The -aspect and -displayaspect parameters can be used to explictly
pass the aspect ratio of the source video and output display.  You
might use these if you have a non-MPEG widescreen file, or an unusual
display mode in X.

In full-screen mode, the code will maximize the image size whilst
maintaining the physical aspect ratio.  In non-full-screen mode, the x
size will be scaled to correct the aspect ratio.

The -xy option may be used to scale the overall picture size.
Fractional scaling can be used to reduce the picture size.

Some examples:

 mplayer file.mpg			- assumes source and destination aspect is 4:3,
 mplayer -aspect 16:9 file.mpg		- assumes source is 16:9, destination 4:3.
 mplayer -aspect 16:9 -fs file.mpg	- scales x to be full display width, y is worked
					  out to provide the right 16:9 image size
 mplayer -displayaspect 16:9 file.mpg   - you've got a widescreen monitor... <jealous>


FINAL NOTES
-----------

All this only applies for -vo drivers that support scaling.

Questions/bugs to steve at daviesfam.org

					  
===============================