Telecine HOWTO by Corey Hickey <bugfood-ml@fatooh.org>, some modifications

by my humble self.


git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@11906 b3059339-0415-0410-9bf9-f77b7e298cf2

1 files changed, 544 insertions, 0 deletions

diff --git a/DOCS/xml/en/mencoder.xml b/DOCS/xml/en/mencoder.xml
index 2786173ad4..5dc70154ae 100644
--- a/DOCS/xml/en/mencoder.xml
+++ b/DOCS/xml/en/mencoder.xml
@@ -761,4 +761,548 @@ mencoder dvd://1 -aid 128 -oac copy -ovc lavc -lavcopts vcodec=mpeg4:vqscale=3:v
 
 </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
+  &quot;30fps NTSC content.&quot;
+</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 &quot;soft-telecine&quot;
+  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 &quot;blink&quot;: 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 &quot;hard-telecine&quot;.
+</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 &quot;mixed progressive and telecine&quot; 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 &quot;30fps
+  NTSC&quot; and &quot;24fps progressive NTSC&quot;. Watch the bottom of
+  <application>MPlayer's</application> output to see these messages.
+</para>
+
+<para>
+  You should check the &quot;30fps NTSC&quot; 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 &quot;mixed progressive and interlaced&quot; content, progressive
+  and interlaced video have been have been spliced together.
+</para>
+
+<para>
+  This category looks just like &quot;mixed progressive and telecine&quot;,
+  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 &quot;guess&quot; 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 &quot;deint&quot;), 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 &amp; 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
+  &quot;jump back in time&quot; 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 (&quot;brightness&quot;) and chroma (&quot;color&quot;)
+  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>