# HG changeset patch # User diego # Date 1075674974 0 # Node ID e1730b82a76230785b33c5aac5c2265554776a31 # Parent 7fd3f926a2945eb66693d49be649628c15072c88 Telecine HOWTO by Corey Hickey , some modifications by my humble self. diff -r 7fd3f926a294 -r e1730b82a762 DOCS/xml/en/mencoder.xml --- a/DOCS/xml/en/mencoder.xml Sun Feb 01 21:53:28 2004 +0000 +++ b/DOCS/xml/en/mencoder.xml Sun Feb 01 22:36:14 2004 +0000 @@ -761,4 +761,548 @@ + +How to deal with telecine and interlacing within NTSC DVDs + + +Introduction + + I suggest you visit this page if you don't understand much of what + is written in this document: + http://www.divx.com/support/guides/guide.php?gid=10 + This URL links to an understandable and reasonably comprehensive + description of what telecine is. + + + + For technical reasons pertaining to the limitations of early + television hardware, all video intended to be displayed on an NTSC + television set must be 59.94 fields per second. Made-for-TV movies + and shows are often filmed directly at 59.94 fields per second, but + the majority of cinema is filmed at 24 or 23.976 frames per + second. When cinematic movie DVDs are mastered, the video is then + converted for television using a process called telecine. + + + + On a DVD, the video is never actually stored as 59.94 fields per + second. For video that was originally 59.94, each pair of fields is + combined to form a frame, resulting in 29.97 frames per + second. Hardware DVD players then read a flag embedded in the video + stream to determine whether the odd- or even-numbered lines should + form the first field. + + + + Usually, 23.976 frames per second content stays as it is when + encoded for a DVD, and the DVD player must perform telecining + on-the-fly. Sometimes, however, the video is telecined + before being stored on the DVD; even though it + was originally 23.976 frames per second, it becomes 59.94 fields per + second, and is stored on the disk as 29.97 frames per second. + + + + When looking at individual frames formed from 59.94 fields per + second video, telecined or otherwise, interlacing is clearly visible + wherever there is any motion, because one field (say, the + even-numbered lines) represents a moment in time 1/59.94th of a + second later than the other. Playing interlaced video on a computer + looks ugly both because the monitor is higher resolution and because + the video is shown frame-after-frame instead of field-after-field. + + + +Notes: + + + + This section only applies to NTSC DVDs, and not PAL. + + + The example MEncoder lines throughout the + document are not intended for + actual use. They are simply the bare minimum required to encode the + pertaining video category. How to make good DVD rips or fine-tune + libavcodec for maximum + quality is not within the scope of this document. + + + There are a couple footnotes specific to this guide, linked like this: + [1] + + + + +How to tell what type of video you have + + +Progressive + + Progressive video was originally filmed at 23.976 fps, and stored + on the DVD without alteration. + + + + When you play a progressive DVD in MPlayer, + MPlayer will print the following line as + soon as the movie begins to play: + + demux_mpg: 24fps progressive NTSC content detected, switching framerate. + + From this point forward, demux_mpg should never say it finds + "30fps NTSC content." + + + + When you watch progressive video, you should never see any + interlacing. Beware, however, because sometimes there is a tiny bit + of telecine mixed in, where you wouldn't expect. I've encountered TV + show DVDs that have one second of telecine at every scene change, or + at seemingly random places. I once watched a DVD that had a + progressive first half, and the second half was telecined. If you + want to be really thorough, you can scan the + entire movie: + + mplayer dvd://1 -nosound -vo null -benchmark + + Using makes + MPlayer play the movie as quickly as it + possibly can; still, depending on your hardware, it can take a + while. Every time demux_mpg reports a framerate change, the line + immediately above will show you the time at which the change + occurred. + + + + Sometimes progressive video is referred to as "soft-telecine" + because it is intended to be telecined by the DVD player. + + + + +Telecined + + Telecined video was originally filmed at 23.976, but was telecined + before it was written to the DVD. + + + + MPlayer does not (ever) report any + framerate changes when it plays telecined video. + + + + Watching a telecined video, you will see interlacing artifacts that + seem to "blink": they repeatedly appear and disappear. + You can look closely at this by + + + mplayer dvd://1 -speed 0.1 + + + Seek to a part with motion. + + + Look at the pattern of interlaced-looking and progressive-looking + frames. If the pattern you see is PPPII,PPPII,PPPII,... then the + video is telecined. If you see some other pattern, then the video + may have been telecined using some non-standard method and + MEncoder cannot losslessly convert it + to progressive. If you don't see any pattern at all, then it is + most likely interlaced. + + + + + + Sometimes telecined video is referred to as "hard-telecine". + + + + +Interlaced + + + Interlaced video was originally filmed at 59.94 fields per second, + and stored on the DVD as 29.97 frames per second. The interlacing is + a result of combining pairs of fields into frames, because within + each frame, each field is 1/59.94 seconds apart. + + + + As with telecined video, MPlayer should + not ever report any framerate changes when playing interlaced content. + + + + When you view an interlaced video closely with , + you will see that every single frame is interlaced. + + + + +Mixed progressive and telecine + + All of a "mixed progressive and telecine" video was originally + 23.976 frames per second, but some parts of it ended up being telecined. + + + + When MPlayer plays this category, it will + (often repeatedly) switch back and forth between "30fps + NTSC" and "24fps progressive NTSC". Watch the bottom of + MPlayer's output to see these messages. + + + + You should check the "30fps NTSC" sections to make sure + they are actually telecine, and not just interlaced. + + + + +Mixed progressive and interlaced + + In "mixed progressive and interlaced" content, progressive + and interlaced video have been have been spliced together. + + + + This category looks just like "mixed progressive and telecine", + until you examine the 30fps sections and see that they don't have the + telecine pattern. + + + + + + +How to encode each category + + As I mentioned in the beginning, example MEncoder + lines below are not meant to actually be used; + they only demonstrate the minimum parameters to properly encode each category. + + + +Progressive + + Progressive video requires no special filtering to encode. The only + parameter you need to be sure to use is + . Otherwise, MEncoder + will try to encode at 29.97 fps and duplicate frames. + + + + mencoder dvd://1 -nosound -ovc lavc -ofps 23.976 + + + + +Telecined + + Telecine can be reversed to retrieve the original 23.976 content, + using a process called inverse-telecine. + MPlayer contains two filters to + accomplish this: and + . You can read the manual page to see their + differences, but for DVDs I've never had a problem with + . Note that you should + always inverse-telecine before any + rescaling; unless you really know what you're doing, + inverse-telecine before cropping, too + [1]. Again, + is needed, too. + + + + mencoder dvd://1 -nosound -vf ivtc=1 -ovc lavc -ofps 23.976 + + + + +Interlaced + + For most practical cases it is not possible to retrieve a complete + progressive video from interlaced content. The only way to do so + without losing half of the vertical resolution is to double the + framerate and try to "guess" what ought to make up the + corresponding lines for each field (this has drawbacks - see method + 3). + + + + + + Encode the video in interlaced form. Normally, interlacing wreaks + havoc with the encoder's ability to compress well, but + libavcodec has two + parameters specifically for dealing with storing interlaced video a + bit better: and . Also, + using is strongly recommended + [2] because it + will encode macroblocks as non-interlaced in places where there is + no motion. Note that is NOT needed here. + + mencoder dvd://1 -nosound -ovc lavc -lavcopts ildct:ilme:mbd=2 + + + Use a deinterlacing filter before encoding. There are several of + these filters available to choose from, each with its own advantages + and disadvantages. Consult to see + what's available (grep for "deint"), and search the + + MPlayer mailing lists to find many discussions about the + various filters. Again, the framerate is not changing, so no + . Also, deinterlacing should be done after + cropping [1] and + before scaling. + + mencoder dvd://1 -nosound -vf pp=lb -ovc lavc + + + Unfortunately, this option is buggy with + MEncoder; it ought to work well with + MEncoder G2, but that isn't here yet. You + might experience crahes. Anyway, the purpose of is to create a full frame out of each field, which + makes the framerate 59.94. The advantage of this approach is that no + data is ever lost; however, since each frame comes from only one + field, the missing lines have to be interpolated somehow. There are + no very good methods of generating the missing data, and so the + result will look a bit similar to when using some deinterlacing + filters. Generating the missing lines creates other issues, as well, + simply because the amount of data doubles. So, higher encoding + bitrates are required to maintain quality, and more CPU power is + used for both encoding and decoding. tfields has several different + options for how to create the missing lines of each frame. If you + use this method, then Reference the manual, and chose whichever + option looks best for your material. Note that when using + you + have to specify both + and to be twice the + framerate of your original source. + + mencoder dvd://1 -nosound -vf tfields=2 -ovc lavc -fps 59.94 -ofps 59.94 + + + If you plan on downscaling dramatically, you can excise and encode + only one of the two fields. Of course, you'll lose half the vertical + resolution, but if you plan on downscaling to at most 1/2 of the + original, the loss won't matter much. The result will be a + progressive 29.97 frames per second file. The procedure is to use + , then crop + [1] and scale + appropriately. Remember that you'll have to adjust the scale to + compensate for the vertical resolution being halved. + mencoder dvd://1 -nosound -vf field=0 -ovc lavc + + + + + +Mixed progressive and telecine + + In order to turn mixed progressive and telecine video into entirely + progressive video, the telecined parts have to be + inverse-telecined. There are two filters that accomplish this + natively, but a better solution most of the time is to use two + filters in conjunction (read onward for more detail). + + + + + Currently the most reliable method to deal with this type of video + is to, rather than inverse-telecine the telecined parts, telecine + the non-telecined parts and then inverse-telecine the whole + video. Sound confusing? softpulldown is a filter that goes through + a video and makes the entire file telecined. If we follow + softpulldown with either or + , the final result will be entirely + progressive. Cropping and scaling should be done after the + inverse-telecine operations, and is + needed. + + mencoder dvd://1 -nosound -vf softpulldown,ivtc=1 -ovc lavc -ofps 23.976 + + + + is designed to inverse-telecine + telecined material while leaving progressive data alone. Pullup + doesn't really work well with the current + MEncoder, though, and is really intended + for use with MEncoder G2 (whenever it's + ready). It works fine without , but + is needed to prevent choppy output. With + , it sometimes fails. The problems arise from + MEncoder's behavior of dropping frames to + maintain synchronization between the audio and video: it drops + frames before sending them through the filter chain, rather than + after. As a result, is sometimes deprived + of the data it needs. + + + + If MEncoder drops too many frames in a + row, it starves 's buffers and causes it to + crash. + + + + Even if MEncoder only drops one frame, + still doesn't get to see it, and will end + up operating on an incorrect sequence of frames. Even though this + doesn't cause a crash, won't be able to + make correct decisions on how to reassemble progressive frames, and + will either match fields together incorrectly or drop several fields + to compensate. + + + + + I haven't used myself, but here's what + D Richard Felker III has to say: + +
It's OK, but IMO it tries to deinterlace rather + than doing inverse telecine too often (much like settop DVD + players & progressive TVs) which gives ugly flickering and + other artefacts. If you're going to use it, you at least need to + spend some time tuning the options and watching the output first + to make sure it's not messing up.
+
+
+
+ + +Mixed progressive and interlaced + + There are two options for dealing with this category, each of + which is a compromise. You should decide based on the + duration/location of each type. + + + + + Treat it as progressive. The interlaced parts will look interlaced, + and some of the interlaced fields will have to be dropped, resulting + in a bit of uneven jumpiness. You can use a postprocessing filter if + you want to, but it may slightly degrade the progressive parts. + + + + This option should definitely not be used if you want to eventually + display the video on an interlaced device (with a TV card, for + example). If you have interlaced frames in a 23.976 frames per + second video, they will be telecined along with the progressive + frames. Half of the interlaced "frames" will be displayed for three + fields' duration (3/59.94 seconds), resulting in a flicking + "jump back in time" effect that looks quite bad. If you + even attempt this, you must use a + deinterlacing filter like or + . + + + + It may also be a bad idea for progressive display, too. It will drop + pairs of consecutive interlaced fields, resulting in a discontinuity + that can be more visible than with the second method, which shows + some progressive frames twice. 29.97 frames per second interlaced + video is already a bit choppy because it really should be shown at + 59.94 fields per second, so the duplicate frames don't stand out as + much. + + + + Either way, it's best to consider your content and how you intend to + display it. If your video is 90% progressive and you never intend to + show it on a TV, you should favor a progressive approach. If it's + only half progressive, you probably want to encode it as if it's all + interlaced. + + + + + Treat it as interlaced. Some frames of the progressive parts will + need to be duplicated, resulting in uneven jumpiness. Again, + deinterlacing filters may slightly degrade the progressive parts. + + + + + +
+ + +Footnotes + + + About cropping: + + Video data on DVDs are stored in a format called YUV 4:2:0. In YUV + video, luma ("brightness") and chroma ("color") + are stored separately. Because the human eye is somewhat less + sensitive to color than it is to brightness, in a YUV 4:2:0 picture + there is only one chroma pixel for every four luma pixels. In a + progressive picture, each square of four luma pixels (two on each + side) has one common chroma pixel. You must crop progressive YUV + 4:2:0 to even resolutions, and use even offsets. For example, + is OK but + is not. + + + + + When you are dealing with interlaced YUV 4:2:0, the situation is a + bit more complicated. Instead of every four luma pixels in the + frame sharing a chroma pixel, every four luma + pixels in each field share a chroma + pixel. When fields are interlaced to form a frame, each scanline is + one pixel high. Now, instead of all four luma pixels being in a + square, there are two pixels side-by-side, and the other two pixels + are side-by-side two scanlines down. The two luma pixels in the + intermediate scanline are from the other field, and so share a + different chroma pixel with two luma pixels two scanlines away. All + this confusion makes it necessary to have vertical crop dimensions + and offsets be multiples of four. Horizontal can stay even. + + + + For telecined video, I recommend that cropping take place after + inverse telecining. Once the video is progressive you only need to + crop by even numbers. If you really want to gain the slight speedup + that cropping first may offer, you must crop vertically by multiples + of four or else the inverse-telecine filter won't have proper data. + + + + For interlaced (not telecined) video, you must always crop + vertically by multiples of four unless you use before cropping. + + + + + About encoding parameters and quality: + + Just because I recommend here doesn't mean it + shouldn't be used elsewhere. Along with , + is one of the two + libavcodec options that + increases quality the most, and you should always use at least those + two unless the drop in encoding speed is prohibitive (e.g. realtime + encoding). There are many other options to + libavcodec that increase + encoding quality (and decrease encoding speed) but that is beyond + the scope of this document. + + + + + + + + +
+