![[LinuxFocus-icon]](../../common/images/logolftop_319x45.gif){kind=small} |
|
|
 |
| This document is available in: English |
![[Photo of the Author]](../../common/article395/michele.jpg)
by Michele Alessandrini <m.alessandrini**(at)**tele2.it> About the author: Michele Alessandrini, 1974, Italian, is an electronic engineer with a passion for programming. He's been using GNU/Linux systems for about 10 years. Content: |
Converting video to perfectly compliant DVDs using MPlayer/MEncoder - part 1![[Illustration]](../../common/article395/dvd_video.png)
Abstract:
You may want to convert a video from a variety of formats to DVD, to be able to watch it on a stand-alone, DVD-only reader. DVDs use a quite rigid format. Many user-friendly programs allow you to convert video to DVD format very easily and without having to know video-related aspects. But almost always, the results I got were not 100% DVD-compliant, and, while they could be correctly played in more sophisticated players, they led to bad surprises when moved to cheaper or older devices. It took me much time to correctly tune all the parameters, and I'd like to share this little bit of knowledge with people having the same problems. The solutions I propose here use the MPlayer/MEncoder pair of programs. In addition, some important concepts related to digital video are discussed.
|
The kind of videos you may want to convert to DVD are:
On the other hand, you don't need to convert your video if you saved it from satellite or digital terrestrial TV (via appropriate computer interfaces) because, unless they are HD channels, the format is probably already the same as DVD. In this case, you can directly jump to the end of the second part of this article, where I talk about how to author a DVD.
The problem in creating a DVD from an arbitrary video is actually two problems: adaptation of the video format (resolution, aspect ratio, etc) and the actual MPEG-2 conversion. We will discuss those aspects below. With MEncoder, we will address both problems, by using MEncoder video filters to adapt the contents and appropriate encoding parameters to obtain compliant video.
MPlayer/MEncoder (see references) are two complementary programs, a player and an encoder (they might be seen as the same program). Of course we will mainly use MEncoder for our goals. I use it for several reasons:
As said, to use it at its full potential, as we'll do here, you will have to type commands in a shell. The command line will include, among the other necessary parameters, the video filters to apply to the video to adjust its format (before the conversion) and the conversion parameters. We will discuss everything in the rest of this article.
A DVD contains a directory with a series of files (organized in a special way) carrying video compressed in MPEG-2 format, a format whose parameters can be varied on a wide range, but that, for DVDs, can only have a strict subset of such parameters.
Important: it must be specified that the entire article is based on the PAL format, mainly used in Europe. PAL and NTSC are two different television standards. While differences in parameters are little, they affect many of them. I'm sorry for NTSC users (mainly American), you can look here for the differences and make the proper adjustments to all the needed places. Moreover, I cannot test NTSC video with my devices.
The next subsections will describe all these parameters, how they must comply to the DVD standard, how you can choose the most suitable values and, last but not least, how to find out the parameters of your original video, because you must know its features in order to decide how to adjust them, if needed, to DVD constraints.
A simple way to know the parameters of the original video is to play it with MPlayer, by launching it manually in a console (type "mplayer <my-file>"), and then closing it soon after the video has started. You will see that MPlayer writes a lot of information on the console before actually playing the video. This information contains the parameters we are looking for. As a reference for the following subsections, while playing a sample video I isolated the following lines:
... Playing my_legally_owned_video.avi. AVI file format detected. [aviheader] Video stream found, -vid 0 [aviheader] Audio stream found, -aid 1 VIDEO: [XVID] 640x352 12bpp 25 fps 874.4 kbps (106.7 kbyte/s) ...
This informs us that the file type is AVI (this is merely a container). The video has the parameters listed after the "VIDEO:" string. For example, "[XVID]" means that the video inside the AVI is compressed with Xvid format. Every format has a 4-letter identifier. The other parameters will be explained in the following subsections.
By the way, while watching the video you can use the arrow keys to navigate forward or backward, and you can press "O" to cycle through a series of information, among which the total video duration. See MPlayer documentation for other keys.
Bit rate is the amount of data used to encode the compressed video and is measured in bits per second (bps), or better by its multiples: kbps (kilo-bps, that is thousands of bps) or Mbps (Mega-bps, that is millions of bps). Remember that a byte is 8 bits. With this number you can compute the number of bytes used for every second of video.
MPEG is a lossy format, that is, its high compression rate is obtained by "sacrificing" more or less of the picture quality. This is perfectly ok, because the information to be discarded is computed so that the resulting video is as similar as possible to the original one, at least to human eyes (it's the same principle as JPEG pictures). Of course, the more bytes per second you use, the more quality you get (details, etc), but the more space the resulting file will occupy.
The theoretical limit for DVDs is 9800 kbps, or 9.8 Mbps, but this is quite too much for a normal video. Bit rates around 3-4 Mbps are perfectly ok. Of course this depends heavily on the kind of video: detail level, resolution, slow or fast-paced action. The last one is because MPEG, to further compress video, stores a few frames entirely, and for other ones it only stores differences between consecutive frames. So if a scene stays quite stationary for several seconds, few information must be compressed, as opposed to fast moving action.
Another important thing is that you can (and you definitely should) distribute the bit rate in non-uniform manner among the frames, using more bytes where there is more movement and less where there is slower motion. What you call bit rate is thus actually the average bit rate of the whole video (still useful to compute the total file size). This dramatically increases the quality at the same bit rate or, more importantly, reduces the needed bit rate for the same quality. The opposite (using a fixed, constant bit rate) means wasting bytes where they are not needed, and having few of them where they're needed more, so that action scenes can result in blocky and ugly artifacts.
For this reason I use the variable bit rate approach, both in real-world situations and in this article. The drawback is that you have to do two conversions. In the first one, the program computes the quantity of information "contained" in every frame, then in the second pass it actually does the conversion, by distributing the total available bytes in proportional manner to every frame. The first pass, anyway, can be made much faster than the second one, and this operation is definitely worthwhile.
How to find out the bit rate of the original video? Well, you don't need it, because we are going to re-compress the video to another bit rate. Anyway, MPlayer shows it at the end of the line starting with "VIDEO:" (see above), both in bits per second and bytes per second. However this information is often wrong if it's a variable bit rate, because it should be computed over the whole video. You can always compute it by knowing the total file size and the video duration.
A digital image is represented as a series of discrete points, called pixels. Every frame of a video is thus divided up into a number of pixels, horizontally and vertically; for example, 720 pixels in width and 576 pixels in height. This will be indicated in compact form as 720x576. When writing it that way, we always mean the number of pixels. Width and height are also abbreviated in W and H, again meaning the number of pixels.
Valid resolutions for a PAL DVD are: 720x576 (the most used, especially in movies, because you have the maximum number of pixels and so the maximum detail, and because it matches the full resolution of a TV screen), 704x576, 352x576 (I never saw these two) and 352x288. The last one carries less detail, but for the same reason can be compressed more efficiently, thus resulting in a smaller file and thus allowing more minutes of video on a DVD. Not very much used commercially because producers usually have no space constraints. It can be found, for example, in cartoons or other genres where the video details are less important.
What if you find a video with a different resolution? Very often DivX videos have an intermediate resolution (e.g. 640x480). In that case you have to resize (also called to scale) the video before the conversion. But resize to what? If you don't want to lose any details, I suggest scaling to 720x576. The drawback is that it takes more time to convert to MPEG-2, because the converter must process all the pixels. Concerning the file size, the requested bit rate does not increase sensibly, because ultimately you are not adding information (details) to the original video. You may choose to resize to 352x288, instead, if you feel that the conversion process is too long on your PC (it will be very long anyway!), or if you don't care about video details (e.g. lectures, music shows, etc).
Of course there's no sense in converting from 352x288 (an already valid resolution) to 720x576, because you are not adding details where they don't exist in the first place, and instead you are deteriorating the video a little bit by using one more filter than necessary, not to mention the increased conversion time. The opposite, on the other hand, can be a valid choice (scaling from 720x576 to 352x288).
How to find out the resolution of the original video? MPlayer shows it in the line starting with "VIDEO:" (see above).
The aspect ratio is the proportion of the displayed image, that is the ratio between its width and its height. For example, traditional televisions (before LCD televisions) have a 4/3 ratio, or expressed in decimal form, 1.33 (4 divided by 3). That is, if you measure the screen of your television with a ruler and divide the two measures, you have such a ratio (1.33, or as to say that they stay in 4 to 3 proportion). New televisions have a more "panoramic" screen, that is a ratio of 16/9 (1.78 in decimal form, bigger than the previous one to indicate a "longer" screen).
This is not a property of the screen only, but of course of the video too. You can view a 16/9 movie on a 4/3 screen and vice versa, provided the television knows how to handle it correctly.
The most confusing thing in the whole process of video conversion, in my opinion, is that aspect ratio and resolution ratio (W/H) are not related, and in fact are often very different. This is so important in order to create a correct DVD that I will dedicate a section on the argument below.
Valid aspect ratios for a DVD are the two mentioned ones: 4/3 and 16/9, but the latter for 720x576 resolution only.
You can anyway find videos with different aspect ratios, especially if coming from cinema, where common aspect ratios are 1.85 and even 2.39.
When the ratio is much bigger than the allowed ones (like 2.39 versus 16/9), you can make two adaptations: cutting (also called cropping) two bands of video vertically at the two edges (reducing the amount of video, that often is made invisible anyway from the limited TV screen), or adding black bands at the top and at the bottom, also reducing the aspect ratio but keeping all the video, at the expense of having a large part of the TV screen unused. We will see examples of these calculations later.
On the other hand, if the aspect ratio is rather similar (like 1.85 versus 1.78) you can decide to ignore the difference. This may also happen if you make a little error when computing the whole thing. In my experience, a 5-10% variation of the aspect ratio goes hardly noticed while watching.
How to find out the aspect ratio of the original video? Because crucial concepts are needed, we will discuss this in the section dedicated to aspect ratio and resolution.
Frame rate is the number of frames per second. The PAL standard dictates 25 frames per second (fps). This is critical: if it's not 25 fps you can't use it. That's because, if you live in a PAL country, your player and your television are PAL too, and expect 25 fps. NTSC videos have different values (strange values that add extra complications to the job), and a PAL player can hardly read NTSC video, especially the simpler ones we are addressing.
Currently I don't know of a simple method to change the frame rate, an operation that requires some hard operations on all the frames. Some programs seem to change it (MEncoder too has a dedicated filter) but they only modify the information stored in the video, and not the video itself, so that it's then played incorrectly.
As a thumb rule, if you produced the video with the tools available in your country it will be ok, and also if you downloaded it but it's produced for your country or another PAL country. Otherwise, if you download something not produced for PAL countries, it won't probably be 25 fps.
How to find out the frame rate of the original video? MPlayer shows it in the line starting with "VIDEO:" (see above).
To further complicate things, there is interlacing. On traditional television displays (cathode-ray ones), the actual frame rate is 25 fps, but to reduce the flickering due to the continuous re-drawing of the image, it's displayed at 50 Hertz (50 times per second), by first displaying the odd lines, and then the even ones and so on (or the opposite, it's not important now). So every frame is displayed in two halves, obtaining 50 semi-frames (called fields) per second. This is called interlacing. Video produced for television is thus recorded in this way. This is the case of analog video digitalized via an acquisition card, and also of DV video from the digital camera. Even more funny, DV video has inverted fields order (first even then odd, or vice versa).
Non-interlaced videos, on the other hand, are called "progressive", and this is the case for most downloaded videos or videos produced for the computer. Progressive videos are what we consider normal videos, that is, the frames are not split into odd and even lines.
The problem with interlaced video arises when saving the video to a file: the frames are saved as a whole, by re-attaching even and odd lines together and getting the correct frame rate of 25 fps. But attaching even and odd lines together does not give a normal, non-interlaced frame. For example, consider that the scene is moving towards the right. If the odd lines are to be displayed after the even ones (1/50 second after), their contents carries the scene slightly moved to right, as it must be 1/50 second after. So when viewed as a whole frame, the odd lines are moved to the right with respect to even ones, resulting in the striped effect you can see in the image below.
Attention: when using MPlayer with default options you may not see interlacing even if it's there, see the end of this subsection on how to find out if your video is interlaced.
But the good news are: there is nothing wrong with that and it need not be fixed. The encoder can manage this by compressing odd and even lines separately. The result will be an MPEG-2 video that's still interlaced, but that's ok because we want to display it on a television, that works in mode. When displayed, you will see it perfectly, as in the case of a progressive video. Only on a PC you can see the difference, because its display is not drawn in an interlaced way.
An alternative is de-interlacing the video, by applying a filter that computes an average of even and odd lines, by more or less sophisticated algorithms, making it progressive. But, as we said, this is totally unnecessary, and moreover will degrade the video quality (the more filters, the more degradation).
But, for the encoder to manage it correctly, we must inform it that the video is interlaced, via appropriate options, and of course we must know it in the first place. A common error is omitting this information to the encoder. In this case, the encoder would try to compress the video line by line as usual, but being consecutive lines very different from one another, the compression algorithm fails miserably, with horrible results in the compressed video.
How to find out if the original video is interlaced? You may not notice that if playing it with MPlayer, because by default it uses the video card hardware acceleration, and that sometimes may apply some filters which can hide the interlacing. You have to launch MPlayer with the added option "-vo x11", that causes it to not use hardware facilities, but the normal drawing functions. That way you can see the frames in their original look, and use your eyes to evaluate it. Navigate through the video, watch moving scenes and search for the effect depicted above.
I neglected the audio until now, even if it's an important component of a video clip. The reason is that we will have no problems here. Formats supported by DVD are AC3 and MPEG audio (MPEG layer 2), the former requiring less bit rate than the latter. Theoretically, audio parameters can vary, but I noticed problems with simpler players when moving away from the default ones, so we will always use the more standard parameters, that are: AC3 format at 192 kbps, 2 channels (stereo), 48 kHz. We will use audio filters to always convert to these parameters (if some of them are already ok the filter won't do anything), so we don't even need to worry about the format of the original audio (MPlayer shows it anyway).
Note that even if your audio is low quality and a smaller bit rate would have been enough, the audio data is so small compared to the video that we don't bother to take risks.
Note also that DVDs also support 5+1 channels audio, but I never experimented with that and I wouldn't know where to find video material with 5+1 audio, apart from another DVD.
The worst pitfall of all this "knowledge" is understanding the relation between aspect ratio and resolution, that unfortunately is not so linear.
The aspect ratio is the ratio between width and height of the final image, and this has nothing to do with pixel resolution. In fact, the aspect ratio and W/H ratio are generally different. If you consider the principal DVD resolution, 720x576, you can see that that the pixel-by-pixel ratio is 1.25. But that same resolution can contain video to be displayed at 4/3 (1.33) or even at 16/9 (1.78).
The fact is that there is no relation between the aspect ratio the image will have at the end, and the number of pixels you decide to divide the image in. The latter is just how much information you want to use to digitally represent the image. The same applies to 352x288 (W/H ratio = 1.22) that carries 1.33 aspect video. The trick is: the image is resized so to have the correct proportion (aspect ratio) as the final step of displaying it.
This might seem an extra work to do, but when sending an image to the TV screen the process is simple: the player maintains the same number of rows, and adjusts the image size on the horizontal axis. Because in cathode-ray televisions the horizontal lines are drawn by an electron beam that swaps every line horizontally, scaling is accomplished by simply sending data to the beam at the correct speed. LCD televisions handle this in their specific way.
Another way of understanding the difference between aspect ratio and resolution is that the video pixels are not to be considered square pixels, like we use to consider them on a PC screen, but instead rectangular, more or less stretched horizontally according to the ratio between the aspect ratio and the W/H ratio (sorry for the confusion).
The thing is different when displaying a video on a PC, where pixels are generally (and luckily) squared, that is the W/H ratio of your screen resolution equals the monitor aspect ratio: for example, standard PC resolutions like 640x480, 800x600 or 1024x768 all give 1.33 ratio, the same of the aspect ratio of traditional (non-wide) screens. Players like MPlayer can automatically adjust the ratio by scaling the video using the video card hardware facilities, and thus with no extra computational effort. The problems are: not all players can do that, and most often the information on what the correct aspect ratio should be is not stored in the file, especially in AVI files. In this case, a 720x576 video made for 16/9 aspect ratio but seen without aspect correction would be seen heavily compressed horizontally.
For example, this is a picture of a 720x576 video frame correctly displayed at 16/9 aspect ratio:
This is the same video frame displayed on a PC with no aspect correction:
But we usually don't perceive the problem, because if we download DivX videos from the Internet, for example, such files intended to be watched on a PC are generally created (or converted to by scaling) with square pixels, that is with the same aspect ratio as the W/H ratio. That's because the author is probably aware of the potential problems and wants to avoid them for others.
So, how to find out the aspect ratio of the original video? If you play it with MPlayer and look towards the end of the console output, you will see how the program is adjusting the video size according to the aspect ratio it believes to be the correct one. I said "believes" because the program cannot evaluate by itself if the aspect is correct. That needs human eyes: if the image does not look compressed or stretched, that's probably correct.
For example, if a video is 720x576 and carries the information that its aspect ratio is 16/9, you will see this message:
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 720x576 => 1024x576 Planar YV12
As you can see, MPlayer is resizing the video from 720x576 to 1024x576, that is a resolution whose W/H equals 1.78 (16/9).
If you don't want MPlayer to auto-adjust the resolution, add the "-noaspect" option. This can be useful when making these kind of examinations. Now the output will be:
Movie-Aspect is undefined - no prescaling applied. VO: [xv] 720x576 => 720x576 Planar YV12
That is, MPlayer behaves as if it does not know it, and the resolution remains unchanged. You will see the video compressed horizontally.
If you want to override the value MPlayer uses, you can use the "-aspect" option, followed by the aspect ratio you want to impose, in decimal format or in x/y format. This is the thing to do if the default aspect ratio does not look correct, and you want to try different ones until you find the one reasonably true.
Continuing the same example, if you want to see the same video in 4/3 aspect, or in 2.39 aspect (even if they're not the correct ones), add the option "-aspect 4/3", or "-aspect 2.39". MPlayer will use that, and you will see the video compressed (first case) or stretched (second case). Output will be, in case of 4/3:
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. VO: [xv] 720x576 => 768x576 Planar YV12
Note the resolution to which the video has been scaled.
As a last example, imagine you downloaded a DivX video, whose resolution is 640x352 (note that it's not a valid DVD resolution). This gives 1.82 in pixel-by-pixel ratio, but what's the correct aspect ratio? If you remember the section about aspect ratio, one of common aspects is 1.85 (from cinema). So it can be that the video, being destined to PC, has squared pixels and the aspect ratio is also 1.82 (the little difference with 1.85 is perhaps a rounding error due to the processing the video received). If you play it and it looks good, that's probably true. To adjust it to 16/9 (the nearest valid DVD aspect ratio), as said before you can cut two little bands at right and left, or add black bands at top and bottom, or leave it that way, given that the difference is little. Additionally, when playing such a video the MPlayer output will probably be:
Movie-Aspect is 1.82:1 - prescaling to correct movie aspect. VO: [xv] 640x352 => 640x352 Planar YV12
This does not necessarily mean that the aspect is really 1.82. More probably, the player (or the encoder at the time of the conversion) had no valid information and concluded it's the same as W/H.
In conclusion, watch the video. Try the default aspect, or manually force one. When the video is good, you can assume that the aspect ratio is the one currently used by MPlayer. As a hint, 99% of times it is one of those previously listed (4/3, 16/9, 1.85, 2.39), or a very similar one.
In the second part of this article, we will see how to put all these concepts together, by invoking MEncoder with the right filters and parameters, with the help of some concrete examples.
|
Webpages maintained by the LinuxFocus Editor team
© Michele Alessandrini "some rights reserved" see linuxfocus.org/license/ http://www.LinuxFocus.org |
Translation information:
|
2009-09-20, generated by lfparser version 2.54b