Disclaimer
The following comments were based on much testing in Builds 4580 and 4582. In other builds, the versions of the included utilities (Codecs and encoders, etc) may differ as may the way they are implemented in MediaCoder. Thus, some differences will be found. Later, I used builds 4740 and 4797 to check the behaviour and to test the new features introduced in build 4740 (Sections 7 and 8, below).
What I have done here is to describe what happened with these two builds in a framework of what I think should happen, logically. The hope is that your understanding will then be enough to cope with any unusual behaviour that may occur and to choose an option that works in your case!
Contents
Section 1. Aspect Ratio: what is it?
Section 2. Aspect Ratio options
Section 3. Related Parameters that must be considered
Section 4. Examples in setting Aspect Ratio
Section 5: Get info on the source file
Section 6. Values of Aspect Ratio supported by Codecs
Section 7. Limitations on Width and Height
Section 8. The “Auto Adjust” panel
Section 1. Aspect Ratio: what is it?
The aspect ratio of an image or video is defined as the ratio of its width to its height. It is expressed in the form of a ratio, such as 16:9, or as a single value, in this case 16 ÷ 9 = 1.778. This is the aspect ratio of a Widescreen TV, which has a width that is 1.778 times that of its height. Older types of TV, referred to as Standard TV, used an aspect ratio of 4:3 = 1.333. In other words, video is displayed on TV with a DAR (Display Aspect Ratio) of 16:9 or 4:3.
The video information is stored as Pixels in the form of a rectangular array called a Frame, and, of course, the properties of the pixels change with time as the video progresses. Also, the size of the frame for TV video depends on the country of transmission. For example, in Europe and Australia, the PAL system is used. It has a frame of 720 pixels wide by 576 high. In the USA, the NTSC system is used, with frames being 720 by 480 pixels. In each case, the frame size, such as 720x576, is also referred to as the Resolution. Also, the aspect ratio of either frame is referred to as the FAR (Frame Aspect Ratio).
Another term often used for the frame aspect ratio is 'SAR' (Storage Aspect Ratio), i.e., the aspect ratio of the frames that store the video information. For example, the often used application Gspot gives values of all aspect ratios for video: SAR, PAR and DAR, where PAR is defined below. I mention SAR here for this reason. Unfortunately, SAR is sometimes used to mean 'Sample aspect ratio', equal to PAR, which is very different and may lead to confusion. So, I shall refrain from using 'SAR', where possible, and use FAR instead.
We now seem to have a contradiction: the above frames have aspect ratios that do not match the TV! They are 1.25 (5:4) for the PAL frames and 1.50 (3:2) for NTSC, whereas, the corresponding TV sets have aspect ratios of 4:3 or 16:9! This didn't matter for the earlier analogue TVs because the video was input in analogue form and simply stretched to fit. However, for digital TVs, another method had to be devised.
The method finally adopted for video files intended for TV was to define the pixels as rectangles, with a width not equal to its height. Each pixel has a Pixel Aspect Ratio (PAR) that is different for each TV system (PAL, NTSC, SECAM).
For historical reasons, the same video frame, i.e., with the same FAR, is used for both Standard and Widescreen TVs. For example, PAL television has an FAR of 1.25 for both, and achieves the differing display sizes with different values of PAR. The PAR used for a 4:3 screen is ~1.067 and that for 16:9 screen is ~1.422. In other words, when playing PAL frames on a 16:9 screen the width of each pixel is stretched by the Player so as to be 1.422 times its height. As a result, the Displayed Aspect Ratio = 1.25 x 1.422 = 1.778 (=16:9). More accurate values of Aspect Ratio are given in the summary for this Section.
Notice that DAR = FAR x PAR.
Let me illustrate the point with a PAL file intended for a 16:9 TV. Its pixels are far from 'square', they are 42% wider than their height. The frame for this file is shown at left, in Fig. 1. The video frame is described by ~415,000 pixels arranged in an array of 720x576 pixels.
When viewed on TV or a player that supports PAR, all pixels will be displayed as rectangles so as to cover the full 16:9 screen, as shown at right, in Fig. 1. However, if the player does not support PAR (ignores it or assumes PAR = 1, to give square pixels), the video will appear squashed, as at left. Similarly, if the Codec in MediaCoder used for encoding the file does not support the PAR (see Section 6), the result will also be incorrect!
Square Pixels (PAR = 1): actually, most digital devices for displaying video display the video on their screens by presenting each pixel as a 'square' with a width equal to its height. They assume a PAR = Width ÷ Height = 1. This is so for those devices not directly related to TV, including the default condition for software players. This is only a simplified summary – there are exceptions.
Usually, video files intended for TV and DVDs, such as a VOB or MPEG-2 files, or the output from digital cameras, such as DV AVI files, have values of PAR to suit the 4:3 or 16:9 aspect.
To Summarise: in most cases, the PAR will be set equal to 1.0 and the frame (Resize) set to match the screen of the target device. However, for conversions relating to TV, things are different. For example, the values of Aspect Ratio (AR) used in movies for standard TV are as follows.
For PAL, the video frames are normally 720x576 pixels, i.e., have a Frame AR of 5:4 (= 720 ÷ 576) and need a Pixel AR of 64:45 (= 1.4222...) to achieve a display of 16:9 and a PAR of 16:15 (1.0666...) for a display in 4:3. For NTSC, the frames are 720x480, with a Frame AR = 3:2 and, thus, require a Pixel AR of 32:27 (= 1.185185...) to achieve a display of 16:9 and a PAR of 8:9 (0.888...) for 4:3. Thus, we have:
* for PAL, its FAR = 5:4 and PAR = 16:15 (~1.07) for a 4:3 display or 64:45 (~1.42) for a 16:9 display
* for NTSC, its FAR = 3:2 and PAR = 8:9 (~0.89) or 32:27 (~1.19).
Section 2. Aspect ratio options
Also on the Picture tab is the Aspect Ratio sub-panel, which offers: (1) Keep Display AR, the default, (2) Keep Pixel AR, (3) Set Display AR and (4) Set Pixel AR.
The first two will usually give predictable outcomes, after all, their meaning is reasonably obvious. On the other hand, Set Pixel AR and Set Display AR, whose meanings also seems obvious, may give strange results since they have the same choices on offer: (a) 4:3 and 16:9, which are values of Display AR required for TV, (b) 5:4 and 3:2, values of Frame AR, used for PAL and NTSC TV, (c) 2:1 and 12:5 and (d) 1:1, the Pixel AR used by most players.
These may lead to some ambiguity and confusion. For example, does the choice of 16:9 for Set Pixel AR give the appropriate value of PAR required for 16:9 TV, as I would have assumed, or does it set PAR to be 16:9 literally, an unorthodox value? Unfortunately, the conversion will aim for the latter, i.e., it will give a PAR equal to the nearest value to 16:9 (~1.78) as allowed by the Codec (see Section 6), and thus not suitable for TV display. To set the PAR at a value suited to TV, its value given in Section 1 needs to be typed in manually. Alternatively, you may change the available list by going to Advanced Settings> Overall; > Presets > Aspect Ratio Presets and adding 16:15 and 64:45 for PAL or 8:9 and 32:27 for NTSC (MediaCoder will then need to be re-opened)! These values are explained above.
Note: whatever you choose, the actual values of DAR and PAR achieved in the output file may well differ from what was intended (see Section 6).
Section 3. Related Parameters that must be considered
The aspect ratio is effectively set on the Picture tab of MediaCoder. However, the Picture tab has two other settings that are related : (1) 'Resize' and (2) 'Crop'. Since each has a number of choices, as does the Aspect Ratio, there are many possible combinations, with not all giving a desired outcome! There are so many choices it may be confusing. I'll try not to add to the confusion.
Resize: this parameter defines the resolution of the output file – the frame dimensions in pixels. The ratio of its two values (W:H) is the Frame AR for the output file. And, of course, when the output frames are viewed/displayed in a Player or TV, the Display AR will depend also on its Pixel AR. Note that if “Resize” is deselected (blank), the output fame will have the same resolution as that of the source file.
Crop options: the default setting is 'Disabled', which will result in the entire original frame being forced into the shape of the output frame, as defined by 'Resize'. This will include any black bands since black pixels are just as valid as the others. In doing so, the width and the height of the source frames will be independently stretched to fit the new dimensions. This will result in a distortion when played if the output Pixel AR does not suit.
On the other hand, two of the other Crop options will uniformly expand or shrink the source frame until either it just fits ('Expand to Fit'), with black bands, if necessary, or until the output frame is full ('Crop to Fit'), with any excess being cropped. Quite sensibly, this adjustment takes into account the Pixel AR for the output, i.e., when Expand to Fit is chosen the source video is adjusted to just fit into the displayed 'frame' – not merely the actual (Resize) frame! The black bands that may result from 'Expand to Fit' will be either be at both the top and bottom ('Letter boxed', if the source is wider) or on both sides ('Pillar boxed).
The Crop options are explained in: viewtopic.php?f=17&t=8188&start=0. Another option is “Manual”, also achieved via the Cropper button on the Picture tab, a tool that is also described in this link.
Section 4. Examples in setting Aspect Ratio
The decision on “Aspect Ratio” must be done in conjunction with a choice for the “Resize” and the setting for “Crop”, also on the Picture tab.
The first thing to realise is that all pixels in the source frame will be mapped onto the output frame, whose dimensions are defined by 'Resize', i.e., each dimension of the source frames will be stretched independently to just fill the new frames. This assumes that Crop is disabled, the default. Secondly, if the original frames (source video) have black bands, they will be retained in the output frames unless cropped out in MediaCoder. This is because all pixels, whether black or otherwise, are valid and no distinction will be made. This may have occurred, for example, when a Widescreen TV clip had previously been converted to suit a 4:3 player.
Thirdly, the output frame Resolution, the 'Resize' values, should be set to suit the requirement of the intended Player or TV standard.
Note: each of the following examples were achieved in build 4740. I chose this build since all builds from 4760 to 4799, will fail to give a Pixel AR other than 1.00 (see bug report: viewtopic.php?f=3&t=9890). In Example 2, build 4740 gave an unusual (illogical) outcome, so, on this one occasion I tried build 4640, which functioned properly (see below).
Example 1: both Source and Output have PAR = 1.
Let's start with an easy one. Suppose we have an FLV file (PAR= 1) downloaded from the web, having a resolution of 368x208 (FAR=1.77 or roughly 16:9), and wish to convert it to suit an iPhone having a max resolution of 640x480 (4:3) and preferring a source PAR of 1. For this example, I chose the MP4 settings in the Encoder Guide (viewtopic.php?f=17&t=9643), but with the Picture tab values changed. Here, we would choose Keep Pixel AR in MediaCoder, since PAR is to be the same for source and output, or Set Pixel AR= 1:1 and either:
(1) set the Resize of 640x480, which has a smaller Frame AR (1.333 or 4:3), and set Crop to 'Expand to Fit' for a Letter Boxed result, or
(2) set the Resize to give the same Frame AR as the input, such as 640x362 (FAR = 1.77), which when rounded to the nearest multiple of 8 (see Section 7), becomes 640x360. Then, leave Crop as Disabled.
Example 2: Source has PAR = 1 and Output to suit TV
Such a conversion may be required if, for example, the output is aimed at a DVD or to play on TV. This may involve editing in a Video Editor and/or the use of a Video Authoring program. As an example of the video format required for a quality NLE editor, see the Guide: viewtopic.php?f=17&t=9488&p=28837#p28837; and the editor, Windows Movie Maker, is discussed in: viewtopic.php?f=17&t=8429&p=25736#p25736. Also, authoring is covered in the Guide: viewtopic.php?f=17&t=8454&start=0.
Back to the topic! Consider another FLV, which of course has a Pixel AR of 1.00. Its resolution was 528x400, i.e., with a Frame AR of 1.32 (close to 4:3) and we wish to convert it to MPEG2 to suit TV in NTSC at 4:3. This would requires Resize set to 720x480 (a requirement for NTSC) and we can leave Crop at Disabled, the default. To get the correct Pixel AR for a 4:3 TV, we could set Aspect Ratio to (1) Keep Display AR, since the source was also ~4:3, (2) Set Display AR = 4:3 or (3) Set Pixel AR = 8:9 (see end of Section 1). They all work.
More difficult would be the conversion of this 4:3 source clip to suit a 16:9 TV. It needs to be Pillar Boxed, and for this you need to set Crop at “Expand to Fit”. Then, for “Aspect Ratio”, choose Set Display AR = 16:9, which should have worked, but it gave a Pixel AR of 1.47 in build 4740 and thus a Display AR of 2.2:1 for the 3:2 output frame! So, I chose Set Pixel AR = 32:27 (see Section 1) and got the correct result. As a check, I tried build 4640: it gave the correct, expected result when Set Display AR was set at 16:9!
Example 3: Source from DVD and Output to have PAR = 1.
Consider a VOB file with a 16:9 aspect for PAL (720x576 frames) and the intention to convert to MP4 for playing in a software player needing a Pixel AR of 1.00. In this case, the output file needs its appearance (aspect ratio) fully defined by its frame and, thus, an aspect ratio of 16:9. So, I chose resize = 1024x576 (Frame AR = 1.778 = 16:9) and kept Crop at its default setting (Disabled). Finally, on choosing Set Pixel AR = 1:1, it worked. Build 4797 also gave the correct output because it allows PAR =1 (see above).
See also, Case 1 in Section 8.
Example 4: Source in PAL and Output to be in NTSC
The initial comments made in Example 2 also apply here.
For this case, consider a VOB from a PAL disc with a 16:9 Display AR and the aim is to convert it to an MKV file to suit NTSC Widescreen TV (16:9). In other words, the source file has a frame of 720x576 (25 fps) and a Pixel AR of 64:45 (~1.42) and the output is to have a frame of 720x480 (29.97 fps) and a Pixel AR of 32:27 (~1.19). Such a conversion is likely to cause a slight degradation in quality, but, the reverse (NTSC to PAL) is likely to be worse. However, this is merely an exercise in changing aspect ratios.
I shall begin with the MKV settings in the Encoding Guide (viewtopic.php?f=17&t=9643), which should work whether “Aspect Ratio” is kept at Keep Display AR, since source and output are both in 16:9, or changed to Set Pixel AR at 32:27 (suits NTSC at 16:9). Unfortunately, both failed because the video source was set to “Bypass” and it failed to interpret things properly, with the result that the Display AR was 3:2! So, I changed the video source to MEncoder and both AR choices worked. The MKV file displayed as 16:9 via a Pixel AR of ~1.19. Of course I had also changed the frame rate to 29.97 fps.
See also, Section 8 for another method.
Section 5. Get Info on the Source file
To make the correct choice for Resize, etc, the frame Resolution, Pixel AR and/or Display AR of the input/source file must be determined. The easiest way is to read the details from the Properties panel in MediaCoder, where the Resolution, Aspect Ratio and Pixel AR are given. Here, “Aspect Ratio” will usually be the Display AR. However, depending on the build and the source file, this may be incorrect, especially if the PAR is incorrectly read by MediaCoder. For example, in build 4740, source files in DV AVI or Xvid/AVI with a DAR of 16:9 will be seen as having a PAR of 1 and a display AR = Frame AR (W ÷ H); and build 4797 gets only one of these wrong. This is because MediaCoder relies on a built-in version of MediaInfo that may be out of date. For more info, MediaInfo may also be accessed in MediaCoder using: Item > 'Details of Selected File (F8)'. It is better to use a recent (separate) version of MediaInfo or Gspot.
Section 6. values of Aspect Ratio Supported by Codecs
At first thought, it would seems that we can arrange for any desired Display Aspect Ratio for any chosen frame resolution ('Resize') and with the appropriate value of PAR. This is not so! The reason? The Codec/Encoder combination and/or how they are implemented in MediaCoder may not support the chosen values. (Codecs are selected on the Video tab as “Format”.) See also, Section 7.
For example, in MediaCoder build 4582, with FFmpeg as encoder, the H.264 Codec (in an MP4 container) and the Huffyuv or Xvid Codec (in AVI) allow numerous options for Resize (FAR) and DAR, but only one value of PAR (1.00). Even more restrictive is the DV Video Codec. It allows only the PAL frame (720x576 pixels) and two values of PAR (1.067 and 1.422).
Such a limitation will often cause an apparent bug in MediaCoder. For example, the H264/MP4 combination will not only ignore the PAR for the input file but will not be able to apply one to the Resize value. It assumes PAR= 1 for both, and the original frame will be pushed into the shape of the Resize frame and appear distorted, if different. An attempt to increase the viewing aspect ratio (DAR) by using Set Display AR or Set Pixel AR will have no effect, since they imply a PAR of other than 1, which is not supported.
By contrast, the MPEG2 Codec (video Format), via the FFmpeg encoder, allows numerous values of PAR and DAR. However, there are limitations! The MPEG2 Codec in builds 4640 and 4740, for example, supports only a limited number of PAR values, such as 1.00, 1.07, 1.42 and 1.76 for PAL. Here, the second and third are those appropriate to TV. For conversions to NTSC the supported values are 0.89, 1.00, 1.19 and 1.47, with the first and third being for TV. Hence, use of Set Pixel AR will result in an output PAR equal to the nearest value in the relevant series!
Unfortunately, the utilities in some builds of MediaCoder may not do their job. For example, in builds 4792 to 4799, and probably back to 4760 (same version of FFmpeg), the output PAR is written as 1.00 to the header of the file, regardless of what was set (see bug report: viewtopic.php?f=3&t=9890). The solution is to either revert to build 4740 or replace the EXE for FFmpeg by that from build 4740!
Section 7: Limitations on Width and Height
The actual values of Width and Height achieved in an output file are not necessarily equal to the values set as 'Resize'. For example, in MediaCoder builds earlier than 4740, such as 4640, the set values will be rounded down to the nearest multiple of 2. On the other hand, more recent builds will round down the frame dimensions to the nearest values divisible by 8!
The reason? Video Codecs encode by dividing the frame into blocks of 8x8 or 16x16, called macro-blocks, with the larger size being used by the more modern Codecs like H263 and H264. Even then, the macro-blocks may be broken down into smaller blocks, called partitions, such as four blocks of 8x8. If the frame dimensions, width and height, are not multiples of 8 the Codec may well work, with difficulty, and the video could display artefacts as a result. Hence, as a safeguard, in build 4740 onwards, the chosen dimensions in Resize are rounded down to the nearest multiple of 8.
This is usually not a problem because virtually all players and hand-held devices also require source files with frame dimensions that are multiples of 8, as are all the default values of Resize! In any case, if the Resize dimensions are changed to arbitrary values, the biggest 'error' would be 7 pixels. This amounts to only 1.4% in a height of 487, such as when set at 720x487 instead of 720x480. Even for a small frame, such as 352x240, as required for MPEG1, the error would be only 2.8%, if the height is set at 247 pixels. Thus, when played, these 'errors' amount to a shrinking of less than 2.8%, a level of distortion you would not spot !!
It is not so easy when the input file relies on a PAR other than 1 and the chosen Codec supports only this value. Then, the DAR of the input file will not be read since the Codec will usually ignore its PAR. Either rely on the Player to make a choice or use the Cropper.
Section 8: The “Auto Adjust” panel
Also introduced in build 4740, is a panel on the Picture tab labelled 'Auto Adjust', which was moved to the ‘Scale’ tab, opposite ‘Picture’, in build 5002. This has check boxes for Width and Height, which by default are unchecked.
It allows the automatic adjustment of the resolution, via either the Width or Height, as chosen by the user, to achieve the same Display AR as that of the source file. In this way, regardless of the Resize values, etc, the result will be undistorted (match the appearance/aspect of the source) and not require the use of either of the cropping options: 'Expand to Fit' or 'Crop to Fit', see above.
Case 1. Auto Adjust checked and Aspect Ratio = 'Keep Display AR'. This option tries to create an output with a Display AR equal to that of the source with PAR nominally set at 1.00. To achieve this, MediaCoder adjusts the set value of either the Width or the Height, depending on which is checked, to achieve the desired AR with PAR =1. Then, the values are rounded down, if necessary, to the nearest multiples of 8, which in turn may require a small adjustment to PAR.
Case 2. Auto Adjust checked and Aspect Ratio = 'Keep Pixel AR': This option tries to create an output with a Display AR equal to that of the source with the PAR nominally equal to that of the source. Firstly, the set value of either the Width or the Height is adjusted to give the desired DAR, i.e., the required FAR for this PAR. Then, the values are rounded down, if necessary, which may need a corresponding, small adjustment to the PAR.
As an example with Keep Display AR (Case 1), consider a source file at 720x576 (PAL) at 16:9, i.e., a PAR of 1.778. On converting this to 720x480 (NTSC) with the Height box checked, the width of 720 is retained and the height is changed to 405 to give DAR = 16:9 with PAR = 1. This value needs rounding down to 400 (FAR now 1.800) and the PAR changed to 0.988 to suit. On the other hand, if the Width box had been checked, the initial frame choice would be 853.3x480 for a PAR = 1. Rounding the width to 848 gives an actual output frame of 848x480 pixels; with a slightly modified PAR of 1.006. In both cases, a Player that assumes/requires a PAR of 1 would show very little distortion.
Note: I shall not consider the use of “Shrink Only”, another check box on the Picture tab. It leads to seemingly strange results and is an option I won't want to use (so far)!