Mercurial > mplayer.hg
changeset 11905:e1730b82a762
Telecine HOWTO by Corey Hickey <bugfood-ml@fatooh.org>, some modifications
by my humble self.
| author | diego |
|---|---|
| date | Sun, 01 Feb 2004 22:36:14 +0000 |
| parents | 7fd3f926a294 |
| children | 47e9cd92d163 |
| files | DOCS/xml/en/mencoder.xml |
| diffstat | 1 files changed, 544 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- 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 @@ </sect1> +<sect1 id="menc-feat-telecine"> +<title>How to deal with telecine and interlacing within NTSC DVDs</title> + +<formalpara> +<title>Introduction</title> +<para> + I suggest you visit this page if you don't understand much of what + is written in this document: + <ulink url="http://www.divx.com/support/guides/guide.php?gid=10">http://www.divx.com/support/guides/guide.php?gid=10</ulink> + This URL links to an understandable and reasonably comprehensive + description of what telecine is. +</para></formalpara> + +<para> + 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. +</para> + +<para> + 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. +</para> + +<para> + 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 + <emphasis>before</emphasis> 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. +</para> + +<para> + 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. +</para> + +<para> +Notes: +</para> +<itemizedlist> +<listitem><para> + This section only applies to NTSC DVDs, and not PAL. + </para></listitem> +<listitem><para> + The example <application>MEncoder</application> lines throughout the + document are <emphasis role="bold">not</emphasis> 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 + <systemitem class="library">libavcodec</systemitem> for maximum + quality is not within the scope of this document. + </para></listitem> +<listitem><para> + There are a couple footnotes specific to this guide, linked like this: + <link linkend="menc-feat-telecine-footnotes">[1]</link> + </para></listitem> +</itemizedlist> + +<sect2 id="menc-feat-telecine-ident"> +<title>How to tell what type of video you have</title> + +<sect3 id="menc-feat-telecine-ident-progressive"> +<title>Progressive</title> +<para> + Progressive video was originally filmed at 23.976 fps, and stored + on the DVD without alteration. +</para> + +<para> + When you play a progressive DVD in <application>MPlayer</application>, + <application>MPlayer</application> will print the following line as + soon as the movie begins to play: + + <screen> demux_mpg: 24fps progressive NTSC content detected, switching framerate.</screen> + + From this point forward, demux_mpg should never say it finds + "30fps NTSC content." +</para> + +<para> + 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 <emphasis>really</emphasis> thorough, you can scan the + entire movie: + + <screen>mplayer dvd://1 -nosound -vo null -benchmark</screen> + + Using <option>-benchmark</option> makes + <application>MPlayer</application> 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. +</para> + +<para> + Sometimes progressive video is referred to as "soft-telecine" + because it is intended to be telecined by the DVD player. +</para> +</sect3> + +<sect3 id="menc-feat-telecine-ident-telecined"> +<title>Telecined</title> +<para> + Telecined video was originally filmed at 23.976, but was telecined + <emphasis>before</emphasis> it was written to the DVD. +</para> + +<para> + <application>MPlayer</application> does not (ever) report any + framerate changes when it plays telecined video. +</para> + +<para> + 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 + <orderedlist> + <listitem> + <screen>mplayer dvd://1 -speed 0.1</screen> + </listitem> + <listitem><para> + Seek to a part with motion. + </para></listitem> + <listitem><para> + 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 + <application>MEncoder</application> cannot losslessly convert it + to progressive. If you don't see any pattern at all, then it is + most likely interlaced. + </para></listitem> + </orderedlist> +</para> + +<para> + Sometimes telecined video is referred to as "hard-telecine". +</para> +</sect3> + +<sect3 id="menc-feat-telecine-ident-interlaced"> +<title>Interlaced</title> +<para> + + 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. +</para> + +<para> + As with telecined video, <application>MPlayer</application> should + not ever report any framerate changes when playing interlaced content. +</para> + +<para> + When you view an interlaced video closely with <option>-speed 0.1</option>, + you will see that every single frame is interlaced. +</para> +</sect3> + +<sect3 id="menc-feat-telecine-ident-mixedpt"> +<title>Mixed progressive and telecine</title> +<para> + All of a "mixed progressive and telecine" video was originally + 23.976 frames per second, but some parts of it ended up being telecined. +</para> + +<para> + When <application>MPlayer</application> plays this category, it will + (often repeatedly) switch back and forth between "30fps + NTSC" and "24fps progressive NTSC". Watch the bottom of + <application>MPlayer's</application> output to see these messages. +</para> + +<para> + You should check the "30fps NTSC" sections to make sure + they are actually telecine, and not just interlaced. +</para> +</sect3> + +<sect3 id="menc-feat-telecine-ident-mixedpi"> +<title>Mixed progressive and interlaced</title> +<para> + In "mixed progressive and interlaced" content, progressive + and interlaced video have been have been spliced together. +</para> + +<para> + 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. +</para> +</sect3> + +</sect2> + +<sect2 id="menc-feat-telecine-encode"> +<title>How to encode each category</title> +<para> + As I mentioned in the beginning, example <application>MEncoder</application> + lines below are <emphasis role="bold">not</emphasis> meant to actually be used; + they only demonstrate the minimum parameters to properly encode each category. +</para> + +<sect3 id="menc-feat-telecine-encode-progressive"> +<title>Progressive</title> +<para> + Progressive video requires no special filtering to encode. The only + parameter you need to be sure to use is + <option>-ofps 23.976</option>. Otherwise, <application>MEncoder</application> + will try to encode at 29.97 fps and duplicate frames. +</para> + +<para> + <screen>mencoder dvd://1 -nosound -ovc lavc -ofps 23.976</screen> +</para> +</sect3> + +<sect3 id="menc-feat-telecine-encode-telecined"> +<title>Telecined</title> +<para> + Telecine can be reversed to retrieve the original 23.976 content, + using a process called inverse-telecine. + <application>MPlayer</application> contains two filters to + accomplish this: <option>detc</option> and + <option>ivtc</option>. You can read the manual page to see their + differences, but for DVDs I've never had a problem with + <option>ivtc</option>. Note that you should + <emphasis role="bold">always</emphasis> inverse-telecine before any + rescaling; unless you really know what you're doing, + inverse-telecine before cropping, too + <link linkend="menc-feat-telecine-footnotes">[1]</link>. Again, + <option>-ofps 23.976</option> is needed, too. +</para> + +<para> + <screen>mencoder dvd://1 -nosound -vf ivtc=1 -ovc lavc -ofps 23.976</screen> +</para> +</sect3> + +<sect3 id="menc-feat-telecine-encode-interlaced"> +<title>Interlaced</title> +<para> + 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). +</para> + +<orderedlist> +<listitem><para> + + Encode the video in interlaced form. Normally, interlacing wreaks + havoc with the encoder's ability to compress well, but + <systemitem class="library">libavcodec</systemitem> has two + parameters specifically for dealing with storing interlaced video a + bit better: <option> ildct</option> and <option>ilme</option>. Also, + using <option>mbd=2</option> is strongly recommended + <link linkend="menc-feat-telecine-footnotes">[2] </link> because it + will encode macroblocks as non-interlaced in places where there is + no motion. Note that <option>-ofps</option> is NOT needed here. + + <screen>mencoder dvd://1 -nosound -ovc lavc -lavcopts ildct:ilme:mbd=2</screen> + </para></listitem> +<listitem><para> + Use a deinterlacing filter before encoding. There are several of + these filters available to choose from, each with its own advantages + and disadvantages. Consult <option>mplayer -pphelp</option> to see + what's available (grep for "deint"), and search the + <ulink url="http://www.mplayerhq.hu/homepage/design6/info.html#mailing_lists"> + MPlayer mailing lists</ulink> to find many discussions about the + various filters. Again, the framerate is not changing, so no + <option>-ofps</option>. Also, deinterlacing should be done after + cropping <link linkend="menc-feat-telecine-footnotes">[1]</link> and + before scaling. + + <screen>mencoder dvd://1 -nosound -vf pp=lb -ovc lavc</screen> + </para></listitem> +<listitem><para> + Unfortunately, this option is buggy with + <application>MEncoder</application>; it ought to work well with + <application>MEncoder G2</application>, but that isn't here yet. You + might experience crahes. Anyway, the purpose of <option> -vf + tfields</option> 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 + <option>tfields</option> you + <emphasis role="bold">have to </emphasis> specify both + <option>-fps</option> and <option>-ofps</option> to be twice the + framerate of your original source. + + <screen>mencoder dvd://1 -nosound -vf tfields=2 -ovc lavc -fps 59.94 -ofps 59.94</screen> + </para></listitem> +<listitem><para> + 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 + <option>-vf field</option>, then crop + <link linkend="menc-feat-telecine-footnotes">[1]</link> and scale + appropriately. Remember that you'll have to adjust the scale to + compensate for the vertical resolution being halved. + <screen>mencoder dvd://1 -nosound -vf field=0 -ovc lavc</screen> + </para></listitem> +</orderedlist> +</sect3> + +<sect3 id="menc-feat-telecine-encode-mixedpt"> +<title>Mixed progressive and telecine</title> +<para> + 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). +</para> + +<itemizedlist> +<listitem><para> + 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 <option>detc</option> or + <option>ivtc</option>, the final result will be entirely + progressive. Cropping and scaling should be done after the + inverse-telecine operations, and <option> -ofps 23.976</option> is + needed. + + <screen>mencoder dvd://1 -nosound -vf softpulldown,ivtc=1 -ovc lavc -ofps 23.976</screen> + </para> + </listitem> +<listitem><para> + <option>-vf pullup</option> is designed to inverse-telecine + telecined material while leaving progressive data alone. Pullup + doesn't really work well with the current + <application>MEncoder</application>, though, and is really intended + for use with <application>MEncoder G2</application> (whenever it's + ready). It works fine without <option>-ofps</option>, but + <option>-ofps</option> is needed to prevent choppy output. With + <option>-ofps</option>, it sometimes fails. The problems arise from + <application>MEncoder's</application> 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, <option>pullup</option> is sometimes deprived + of the data it needs. + </para> + + <para> + If <application>MEncoder</application> drops too many frames in a + row, it starves <option>pullup</option>'s buffers and causes it to + crash. + </para> + + <para> + Even if <application>MEncoder</application> only drops one frame, + <option> pullup</option> 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, <option> pullup</option> 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. + </para> + </listitem> + +<listitem><para> + I haven't used <option>-vf filmdint</option> myself, but here's what + D Richard Felker III has to say: + + <blockquote><para>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.</para></blockquote> + </para></listitem> +</itemizedlist> +</sect3> + +<sect3 id="menc-feat-telecine-encode-mixedpi"> +<title>Mixed progressive and interlaced</title> +<para> + 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. +</para> + +<itemizedlist> +<listitem><para> + 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. + </para> + + <para> + 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 <emphasis role="bold">must</emphasis> use a + deinterlacing filter like <option>lb</option> or + <option>l5</option>. + </para> + + <para> + 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. + </para> + + <para> + 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. + </para> + </listitem> + +<listitem><para> + 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. + </para></listitem> + +</itemizedlist> +</sect3> + +</sect2> + +<sect2 id="menc-feat-telecine-footnotes"> +<title>Footnotes</title> +<orderedlist> +<listitem><formalpara> + <title>About cropping:</title> + <para> + 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, + <option>crop=716:380:2:26</option> is OK but + <option>crop=716:380:3:26 </option> is not. + </para> + </formalpara> + + <para> + 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 + <emphasis>frame </emphasis> sharing a chroma pixel, every four luma + pixels in each <emphasis> field</emphasis> 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. + </para> + + <para> + 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. + </para> + + <para> + For interlaced (not telecined) video, you must always crop + vertically by multiples of four unless you use <option>-vf + field</option> before cropping. + </para> + </listitem> + +<listitem><formalpara> + <title>About encoding parameters and quality:</title> + <para> + Just because I recommend <option>mbd=2</option> here doesn't mean it + shouldn't be used elsewhere. Along with <option>trell</option>, + <option>mbd=2</option> is one of the two + <systemitem class="library">libavcodec</systemitem> 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 + <systemitem class="library">libavcodec</systemitem> that increase + encoding quality (and decrease encoding speed) but that is beyond + the scope of this document. + </para> + </formalpara> + </listitem> + +</orderedlist> + +</sect2> + +</sect1> + </chapter>