February 2004 - MPlayer-DOCS - lists.mplayerhq.hu

CVS: main/DOCS/xml/en faq.xml,1.29,1.30
by wight＠mplayerhq.hu 02 Feb '04

02 Feb '04

Update of /cvsroot/mplayer/main/DOCS/xml/en In directory mail:/var2/tmp/cvs-serv8589 Modified Files: faq.xml Log Message: & removed - build fix Index: faq.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/faq.xml,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- faq.xml 2 Feb 2004 00:42:49 -0000 1.29 +++ faq.xml 2 Feb 2004 08:24:10 -0000 1.30 @@ -1162,7 +1162,7 @@ </para></question> <answer><para> This has been discussed to no end on mplayer-users. Go search the -<ulink url="http://mplayerhq.hu/cgi-bin/s-arch.cgi?&sbm=mplayer-users">archives</ulink> +<ulink url="http://mplayerhq.hu/cgi-bin/s-arch.cgi?sbm=mplayer-users">archives</ulink> for a complete answer. This is a complicated topic and your mileage may vary a lot depending on the kind of files you want to merge. MPEGs can be concatenated into a single file with luck. For AVIs there are two tools,

1 0

CVS: main/DOCS/man/en mplayer.1,1.529,1.530
by diego＠mplayerhq.hu 02 Feb '04

02 Feb '04

Update of /cvsroot/mplayer/main/DOCS/man/en In directory mail:/var2/tmp/cvs-serv7848/DOCS/man/en Modified Files: mplayer.1 Log Message: Fix description of -srate, as pointed out by Rich. Index: mplayer.1 =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/man/en/mplayer.1,v retrieving revision 1.529 retrieving revision 1.530 diff -u -r1.529 -r1.530 --- mplayer.1 1 Feb 2004 21:53:28 -0000 1.529 +++ mplayer.1 2 Feb 2004 00:33:07 -0000 1.530 @@ -920,7 +920,7 @@ Useful for playback from CDROM images / .VOB files with junk at the beginning. .TP .B \-srate <Hz> -Forces the given audio playback rate, changing video speed to keep A-V sync. +Selects the given output sampling rate, resampling if necessary. MEncoder passes this value to lame for resampling. .TP .B \-ss <time> (see \-sb option too)

1 0

CVS: main/DOCS/xml/en mencoder.xml,1.17,1.18
by diego＠mplayerhq.hu 01 Feb '04

01 Feb '04

Update of /cvsroot/mplayer/main/DOCS/xml/en In directory mail:/var2/tmp/cvs-serv3670/DOCS/xml/en Modified Files: mencoder.xml Log Message: Telecine HOWTO by Corey Hickey <bugfood-ml(a)fatooh.org>, some modifications by my humble self. Index: mencoder.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/mencoder.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- mencoder.xml 21 Jan 2004 19:59:33 -0000 1.17 +++ mencoder.xml 1 Feb 2004 22:36:14 -0000 1.18 @@ -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>

1 0

[PATCH] Telecine howto, in xml
by Corey Hickey 01 Feb '04

01 Feb '04

Ok, I've (finally) inserted XML tags into my mencoder+telecine howto. I don't know how much I've missed, but feel free to fix stuff or tell me what's wrong. -Corey Index: DOCS/xml/en/mencoder.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/mencoder.xml,v retrieving revision 1.17 diff -u -r1.17 mencoder.xml --- DOCS/xml/en/mencoder.xml 21 Jan 2004 19:59:33 -0000 1.17 +++ DOCS/xml/en/mencoder.xml 1 Feb 2004 09:40:14 -0000 @@ -761,4 +761,496 @@ </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 lavc 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 lavc 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: + "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></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 trell, <option>mbd=2</option> is one of the two + lavc 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 lavc that increase + encoding quality (and decrease encoding speed) but that is beyond the scope of + this document. + </para> + </formalpara> + </listitem> + +</orderedlist> + +</sect2> + +</sect1> + </chapter>

2 1

CVS: main/DOCS/man/en mplayer.1,1.528,1.529
by diego＠mplayerhq.hu 01 Feb '04

01 Feb '04

Update of /cvsroot/mplayer/main/DOCS/man/en In directory mail:/var2/tmp/cvs-serv11710/DOCS/man/en Modified Files: mplayer.1 Log Message: rgbtest filter added, kerndeint filter description fixed and moved to a more sensible location. Index: mplayer.1 =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/man/en/mplayer.1,v retrieving revision 1.528 retrieving revision 1.529 diff -u -r1.528 -r1.529 --- mplayer.1 1 Feb 2004 13:08:40 -0000 1.528 +++ mplayer.1 1 Feb 2004 21:53:28 -0000 1.529 @@ -2695,6 +2695,10 @@ .B test\ \ \ Generate various test patterns. .TP +.B rgbtest +Generate an RGB test pattern useful for detecting RGB vs BGR issues. +You should see a red, green and blue stripe from top to bottom. +.TP .B lavc[=quality:fps] Fast software YV12 to MPEG1 conversion with libavcodec for use with DVB/\:DXR3. Faster and of better quality than \-vf fame. @@ -2848,6 +2852,24 @@ .B lavcdeint Use libavcodec's deinterlace filter. .TP +.B kerndeint[=map[:order[:thresh[:sharp[:twoway]]]]] +Donald Graft's adaptive kernel deinterlacer. +Deinterlaces parts of a video if a configurable threshold is exceeded. +.PD 0 +.RSs +.IPs "map (0 or 1)" +Paint pixels which exceed the threshold white (default: 0). +.IPs "order (0 or 1)" +Swap fields if 1 (default: 0). +.IPs "thresh (0 - 255)" +Threshold (default 10). +.IPs "sharp (0 or 1)" +Enable additional sharpening (default: 0). +.IPs "twoway (0 or 1)" +Enable twoway sharpening (default: 0). +.RE +.PD 1 +.TP .B unsharp=l|cWxH:amount[:l|cWxH:amount] Unsharp mask / gaussian blur. .RSs @@ -2959,7 +2981,7 @@ As with detc, you must specify the correct output framerate (\-ofps 23.976) when using MEncoder. .TP -.B pullup +.B pullup\ Third-generation pulldown reversal (inverse telecine) filter, capable of handling mixed hard-telecine, 24 fps progressive, and 30 fps progressive content. @@ -3342,24 +3364,6 @@ The option fd instructs the filter to always perform the requested decimation (ugly). .RE -.PD 1 -.TP -.B kerndeint[=map[:order[:thresh[:sharp[:twoway]]]]] -Donald Graft's adaptive kernel deinterlacer. -Deinterlaces parts of video if a configurable threshold is exceeded. -.PD 0 -.RSs -.IPs map (0 or 1) -Paint pixels which exceed the threshold white (default 0). -.IPs order (0 or 1) -Swap fields if 1 (default 0). -.IPs thresh (0 - 255) -Threshold (default 10). -.IPs sharp (0 or 1) -Enable additional sharping (default 0). -.IPs twoway (0 or 1) -Enable twoway sharping (default 0). -.RE . . .SH "VIDEO OUTPUT DRIVERS (MPLAYER ONLY)"

1 0

CVS: main/DOCS/man/en mplayer.1,1.528,1.529
by diego＠mplayerhq.hu 01 Feb '04

01 Feb '04

Update of /cvsroot/mplayer/main/DOCS/man/en In directory mail:/var2/tmp/cvs-serv15596/DOCS/man/en Modified Files: mplayer.1 Log Message: rgbtest filter added, kerndeint filter description fixed and moved to a more sensible location. Index: mplayer.1 =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/man/en/mplayer.1,v retrieving revision 1.528 retrieving revision 1.529 diff -u -r1.528 -r1.529 --- mplayer.1 1 Feb 2004 13:08:40 -0000 1.528 +++ mplayer.1 1 Feb 2004 20:46:05 -0000 1.529 @@ -1,5224 +0,0 @@ -.\" $Revision$ -.\" MPlayer (C) 2000-2004 MPlayer Team -.\" This man page was/is done by Gabucino, Diego Biurrun, Jonas Jermann -. -.\" -------------------------------------------------------------------------- -.\" Macro definitions -.\" -------------------------------------------------------------------------- -. -.\" default indentation is 7, don't change! -.nr IN 7 -.\" define indentation for suboptions [...5193 lines suppressed...] -MPlayer is (C) 2000\-2004 -.B The MPlayer Team -.TP -This man page is written and maintained by -.B Gabucino -.br -.B Diego Biurrun -.br -.B Jonas Jermann -.PP -Please send mails about it to the MPlayer-DOCS mailing list. -. -. -.SH "STANDARD DISCLAIMER" -Use only at your own risk! -There may be errors and inaccuracies that could be damaging to your system or -your eye. -Proceed with caution, and although this is highly unlikely, the authors don't -take any responsibility for that! -.\" end of file

2 1

CVS: main/DOCS/man/en mplayer.1,1.527,1.528
by ranma＠mplayerhq.hu 01 Feb '04

01 Feb '04

Update of /cvsroot/mplayer/main/DOCS/man/en In directory mail:/var2/tmp/cvs-serv15620/DOCS/man/en Modified Files: mplayer.1 Log Message: kerndeint documentation Index: mplayer.1 =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/man/en/mplayer.1,v retrieving revision 1.527 retrieving revision 1.528 diff -u -r1.527 -r1.528 --- mplayer.1 29 Jan 2004 18:45:20 -0000 1.527 +++ mplayer.1 1 Feb 2004 13:08:40 -0000 1.528 @@ -3342,6 +3342,24 @@ The option fd instructs the filter to always perform the requested decimation (ugly). .RE +.PD 1 +.TP +.B kerndeint[=map[:order[:thresh[:sharp[:twoway]]]]] +Donald Graft's adaptive kernel deinterlacer. +Deinterlaces parts of video if a configurable threshold is exceeded. +.PD 0 +.RSs +.IPs map (0 or 1) +Paint pixels which exceed the threshold white (default 0). +.IPs order (0 or 1) +Swap fields if 1 (default 0). +.IPs thresh (0 - 255) +Threshold (default 10). +.IPs sharp (0 or 1) +Enable additional sharping (default 0). +.IPs twoway (0 or 1) +Enable twoway sharping (default 0). +.RE . . .SH "VIDEO OUTPUT DRIVERS (MPLAYER ONLY)"

2 1

Install on OpenBSD
by Dave Sorg 01 Feb '04

01 Feb '04

Hello, I'm a new OpenBSD user. I'd like to install MPlayer on it. I have the port, and when I run the make and make install commands, I get an error that I don't have the codecs installed. Which file are they in, and which directory should they be saved to? Also, once I have it installed how do I use it (type mplayer (file name here) I guess)? Dave _________________________________________________________________ Scope out the new MSN Plus Internet Software optimizes dial-up to the max! http://join.msn.com/?pgmarket=en-us&page=byoa/plus&ST=1

2 1