It's been a while and the telecine howto I wrote is out of date. Here's a patch. * Added instructions for pullup,softskip. * Removed description of pullup's shortcomings (just use softskip). * Instructions to use "." for frame-step. * A few clarifications. * One grammatical fix (I think). -Corey Index: DOCS/xml/en/mencoder.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/mencoder.xml,v retrieving revision 1.36 diff -u -r1.36 mencoder.xml --- DOCS/xml/en/mencoder.xml 7 Jan 2005 22:38:11 -0000 1.36 +++ DOCS/xml/en/mencoder.xml 19 Feb 2005 05:22:08 -0000 @@ -1036,7 +1036,7 @@ <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 + 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 @@ -1054,8 +1054,9 @@ </para> <para> - Sometimes progressive video is referred to as "soft-telecine" - because it is intended to be telecined by the DVD player. + Sometimes progressive video on DVDs is referred to as + "soft-telecine" because it is intended to be telecined by + the DVD player. </para> </sect3> @@ -1077,36 +1078,41 @@ You can look closely at this by <orderedlist> <listitem> - <screen>mplayer dvd://1 -speed 0.1</screen> + <screen>mplayer dvd://1</screen> </listitem> <listitem><para> Seek to a part with motion. </para></listitem> <listitem><para> + Use the "." key to step forward one frame at a time. + </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. + may have been telecined using some non-standard method; + <application>MEncoder</application> cannot losslessly convert + non-standard telecine 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". + Sometimes telecined video on DVDs is referred to as + "hard-telecine". Since hard-telecine is already 59.94 fields + per second, the DVD player plays the video without any manipulation. </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. + and stored on the DVD as 29.97 frames per second. The interlacing effect + (often called "combing") is a result of combining pairs of + fields into frames. Each field is supposed to be 1/59.94 seconds apart, + and when they are displayed simultaneously the difference is apparent. </para> <para> @@ -1115,8 +1121,8 @@ </para> <para> - When you view an interlaced video closely with <option>-speed 0.1</option>, - you will see that every single frame is interlaced. + When you view an interlaced video closely by frame-stepping with the + "." key, you will see that every single frame is interlaced. </para> </sect3> @@ -1176,6 +1182,15 @@ <para> <screen>mencoder dvd://1 -nosound -ovc lavc -ofps 23.976</screen> </para> + +<para> + It is often the case, however, that a video that looks progressive + actually has very short parts of telecine mixed in. Unless you are sure, + it is safest to treat the video as + <link linkend="menc-feat-telecine-encode-mixedpt">mixed progressive and + telecine</link>. The performance loss is small + <link linkend="menc-feat-telecine-footnotes">[3]</link>. +</para> </sect3> <sect3 id="menc-feat-telecine-encode-telecined"> @@ -1183,20 +1198,10 @@ <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> + <application>MPlayer</application> contains several filters to + accomplish this; the best filter, <option>pullup</option>, is described + in the <link linkend="menc-feat-telecine-encode-mixedpt">mixed + progressive and telecine</link> section. </para> </sect3> @@ -1266,7 +1271,7 @@ <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 + If you plan on downscaling dramatically, you can extract 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 @@ -1285,59 +1290,45 @@ <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). + inverse-telecined. There are three ways to accomplish this, + described below. 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>. + <option>-ofps 23.976</option> is needed here because the output video + will be 23.976 frames per second. </para> <itemizedlist> <listitem><para> - Currently the most reliable method to deal with this type of video + <option>-vf pullup</option> is designed to inverse-telecine + telecined material while leaving progressive data alone. In order to + work properly, <option>pullup</option> <emphasis role="bold">must + </emphasis> be followed by the <option>softskip</option> filter or + else <application>MEncoder</application> will crash. <option>pullup + </option> is, however, the cleanest and most accurate method + available for encoding both telecine and "mixed progressive and + telecine". + + <screen>mencoder dvd://1 -nosound -vf pullup,softskip -ovc lavc -ofps 23.976</screen> + </para> + + + </listitem> + <listitem><para> + An older method 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. + progressive. <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</application>'s behavior of dropping frames to - maintain synchronization between the audio and video: it drops - frames before sending them through the filter chain, rather than - after. As a result, <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 @@ -1478,6 +1469,21 @@ </formalpara> </listitem> +<listitem><formalpara> + <title>About the performance of pullup:</title> + <para> + It is safe to use <option>pullup</option> (along with <option>softskip + </option>) on progressive video, and is usually a good idea unless + the source has been definitively verified to be entirely progressive. + The performace loss is small for most cases. On a bare-minimum encode, + <option>pullup</option> causes <application>MEncoder</application> to + be 50% slower. Adding sound processing and advanced <option>lavcopts + </option> overshadows that difference, bringing the performance of + decrease of using <option>pullup</option> down to 2%. + </para> + </formalpara> + </listitem> + </orderedlist> </sect2>
Corey Hickey wrote:
It's been a while and the telecine howto I wrote is out of date. Here's a patch.
* Added instructions for pullup,softskip. * Removed description of pullup's shortcomings (just use softskip). * Instructions to use "." for frame-step. * A few clarifications. * One grammatical fix (I think).
-Corey
I just realized that I should be using 24000/1001 in my examples instead of 23.976. For that matter, 23.976 is used througout the mencoder documentation. If 24000/1001 is indeed correct, then all the docs should be updated. Instead of just 'sed -i s:23.976:24000/1001:g mencoder.xml' it would probably be nice to explain where all the weird numbers come from, either in our own words or by linking to an external page. I'll do the work, except that I really don't understand it myself and I couldn't dig anything up on google. Can somebody explain it to me or give me a URL? Thanks, Corey
Corey Hickey writes:
I just realized that I should be using 24000/1001 in my examples instead of 23.976. For that matter, 23.976 is used througout the mencoder documentation.
If 24000/1001 is indeed correct, then all the docs should be updated. Instead of just 'sed -i s:23.976:24000/1001:g mencoder.xml' it would probably be nice to explain where all the weird numbers come from, either in our own words or by linking to an external page.
I'll do the work, except that I really don't understand it myself and I couldn't dig anything up on google. Can somebody explain it to me or give me a URL?
I think you are right, but I forgot the reason (I don't encode). Rich? Diego
Diego Biurrun writes:
Corey Hickey writes:
I just realized that I should be using 24000/1001 in my examples instead of 23.976. For that matter, 23.976 is used througout the mencoder documentation.
If 24000/1001 is indeed correct, then all the docs should be updated. Instead of just 'sed -i s:23.976:24000/1001:g mencoder.xml' it would probably be nice to explain where all the weird numbers come from, either in our own words or by linking to an external page.
I'll do the work, except that I really don't understand it myself and I couldn't dig anything up on google. Can somebody explain it to me or give me a URL?
I think you are right, but I forgot the reason (I don't encode).
Rich?
Rich just told me the following on IRC: 00:36 <@DonDiego_> but what about the 23.976 vs 24000/1001? 00:36 <@dalias> oh 00:36 <@dalias> if you ever feed fps to mencoder, it should be 24000/1001 00:36 <@dalias> not 23.976 Corey, could you send a patch that fixes this? Diego
Diego Biurrun wrote:
Diego Biurrun writes:
Corey Hickey writes:
I just realized that I should be using 24000/1001 in my examples instead of 23.976. For that matter, 23.976 is used througout the mencoder documentation.
If 24000/1001 is indeed correct, then all the docs should be updated. Instead of just 'sed -i s:23.976:24000/1001:g mencoder.xml' it would probably be nice to explain where all the weird numbers come from, either in our own words or by linking to an external page.
I'll do the work, except that I really don't understand it myself and I couldn't dig anything up on google. Can somebody explain it to me or give me a URL?
I think you are right, but I forgot the reason (I don't encode).
Rich?
Rich just told me the following on IRC:
00:36 <@DonDiego_> but what about the 23.976 vs 24000/1001? 00:36 <@dalias> oh 00:36 <@dalias> if you ever feed fps to mencoder, it should be 24000/1001 00:36 <@dalias> not 23.976
Corey, could you send a patch that fixes this?
Diego
Sure, I can do that this weekend. Still, I'd really like to know the origin of the numbers: why is video 24000/1001 instead of just 24? Why 30000/1001 instead of just 30? I know I read the reason once, somewhere, but I can't remember. Rich, do you know of a reasource for me to read? Or will you please explain it to me yourself? If I learn why I'll write up a section for the docs. -Corey
On Fri, Feb 18, 2005 at 11:31:32PM -0800, Corey Hickey wrote:
Corey Hickey wrote:
It's been a while and the telecine howto I wrote is out of date. Here's a patch.
* Added instructions for pullup,softskip. * Removed description of pullup's shortcomings (just use softskip). * Instructions to use "." for frame-step. * A few clarifications. * One grammatical fix (I think).
-Corey
I just realized that I should be using 24000/1001 in my examples instead of 23.976. For that matter, 23.976 is used througout the mencoder documentation.
If 24000/1001 is indeed correct, then all the docs should be updated. Instead of just 'sed -i s:23.976:24000/1001:g mencoder.xml' it would probably be nice to explain where all the weird numbers come from, either in our own words or by linking to an external page.
I'll do the work, except that I really don't understand it myself and I couldn't dig anything up on google. Can somebody explain it to me or give me a URL?
Thanks, Corey
My understanding is that 60000/1001 is just the only rational number within the range of tolerance of the NTSC refresh clock, without having a ridiculously huge denominator. Thus it was standardized as the "official" refresh for NTSC with the advent of digital video. 30000/1001 and 24000/1001 are just the refresh converted from fields to field-pairs or telecined frames. I'm sure you can find better references on this somewhere if you like... Rich
D Richard Felker III wrote:
My understanding is that 60000/1001 is just the only rational number within the range of tolerance of the NTSC refresh clock, without having a ridiculously huge denominator. Thus it was standardized as the "official" refresh for NTSC with the advent of digital video. 30000/1001 and 24000/1001 are just the refresh converted from fields to field-pairs or telecined frames.
I'm sure you can find better references on this somewhere if you like...
Rich
Hmm. That makes sense. So, I understand the number now, but I still don't know why a different number had to be chosen. What was wrong with 60/1, 30/1, and 24/1? I've searched google several more times and still haven't found out why. I have a few links that come close. This page says it's a stupid hack: http://homepage.mac.com/rnc/PulldownSync.html This page says "don't ask": http://stream.uen.org/medsol/digvid/html/3B_videoframerate.html This page looks promising but doesn't seem to explain it: http://www.ntsc-tv.com/ntsc-main-01.htm That last one does list a few books that at least _ought_ to. I might have to go to the library and see if I can find them. -Corey
On Tue, Mar 01, 2005 at 05:14:30PM -0800, Corey Hickey wrote:
D Richard Felker III wrote:
My understanding is that 60000/1001 is just the only rational number within the range of tolerance of the NTSC refresh clock, without having a ridiculously huge denominator. Thus it was standardized as the "official" refresh for NTSC with the advent of digital video. 30000/1001 and 24000/1001 are just the refresh converted from fields to field-pairs or telecined frames.
I'm sure you can find better references on this somewhere if you like...
Rich
Hmm. That makes sense. So, I understand the number now, but I still don't know why a different number had to be chosen. What was wrong with 60/1, 30/1, and 24/1?
They're significantly wrong. In fact the error is so great you'd have desync after a few seconds if you just treated the video as if it were one of these rates. 5994/100, 2997/100, and 23976/1000 also have a significant margin of error. On the other hand, 60000/1001 and friends fall within the margin of tolerance for the actual clock used in NTSC. Or that's my understanding, anyway. Measure it on an oscilloscope if you really want to see! :)
I've searched google several more times and still haven't found out why. I have a few links that come close.
This page says it's a stupid hack: http://homepage.mac.com/rnc/PulldownSync.html
This page is idiotic. Pulldown is used for both NTSC and PAL, whenever progressive video is displayed on an interlaced device. NTSC just uses the common 3:2 pulldown known as "telecine" while PAL uses 2:2 pulldown (sped up by a few % so it's 25 fps instead of 24) or sometimes 3:2:2:2:2:2:2:2:2:2:2:2 pulldown (excact 25/24 ratio). Anyway, the 1001 factor is not a "stupid hack" either. It's part of the real fieldrate of NTSC, which is 59.94... fields per second, not 60 fields per second. I'm told that NTSC was originally 60 fields per second in black & white, then they had to lower the framerate slightly to make bandwidth available for the color carrier. Not sure if this is true though, but it makes sense..
This page says "don't ask": http://stream.uen.org/medsol/digvid/html/3B_videoframerate.html
Very naive page.. :)
This page looks promising but doesn't seem to explain it: http://www.ntsc-tv.com/ntsc-main-01.htm
Hmm wonder why...
That last one does list a few books that at least _ought_ to. I might have to go to the library and see if I can find them.
I'm not sure it's worth the trouble. The fact is: this is just how it is. 60000/1001 is the NTSC fieldrate. :) Rich
D Richard Felker III wrote:
On Tue, Mar 01, 2005 at 05:14:30PM -0800, Corey Hickey wrote:
D Richard Felker III wrote:
My understanding is that 60000/1001 is just the only rational number within the range of tolerance of the NTSC refresh clock, without having a ridiculously huge denominator. Thus it was standardized as the "official" refresh for NTSC with the advent of digital video. 30000/1001 and 24000/1001 are just the refresh converted from fields to field-pairs or telecined frames.
I'm sure you can find better references on this somewhere if you like...
Rich
Hmm. That makes sense. So, I understand the number now, but I still don't know why a different number had to be chosen. What was wrong with 60/1, 30/1, and 24/1?
They're significantly wrong. In fact the error is so great you'd have desync after a few seconds if you just treated the video as if it were one of these rates. 5994/100, 2997/100, and 23976/1000 also have a significant margin of error. On the other hand, 60000/1001 and friends fall within the margin of tolerance for the actual clock used in NTSC. Or that's my understanding, anyway. Measure it on an oscilloscope if you really want to see! :)
Oooh, I see what's going on now. I was under the impression that the NTSC clock rate was exactly 60 Hz. I understand what you mean now. Basing my research on that, I've finally come up with a useful page out of google: http://www.edlmax.com/NTSC3.html Some of the numbers on this page are incorrect; somebody messed up the precision. For instance, 4.5 * 10^6 / 286 = 15734.265734 265734 ... (repeating) and not 15,734.265734265700000. If the rest of the page is correct, though, it seems that 60000/1001 is actually based upon the RF frequency range available. NTSC was 60 Hz before color, and the addition of a color subcarrier necessitated a slight adjustment to the frequency. Also, if I follow the math correctly, the NTSC vertical frequency is exactly 60000/1001, so digital NTSC video is exactly the correct framerate.
Anyway, the 1001 factor is not a "stupid hack" either. It's part of the real fieldrate of NTSC, which is 59.94... fields per second, not 60 fields per second. I'm told that NTSC was originally 60 fields per second in black & white, then they had to lower the framerate slightly to make bandwidth available for the color carrier. Not sure if this is true though, but it makes sense..
Yes, it seems that the 1001 is derived from a very intelligent hack. :) -Corey
On Wed, Mar 02, 2005 at 02:47:45PM -0800, Corey Hickey wrote:
Oooh, I see what's going on now. I was under the impression that the NTSC clock rate was exactly 60 Hz. I understand what you mean now. Basing my research on that, I've finally come up with a useful page out of google:
http://www.edlmax.com/NTSC3.html
Some of the numbers on this page are incorrect; somebody messed up the precision. For instance, 4.5 * 10^6 / 286 = 15734.265734 265734 ... (repeating) and not 15,734.265734265700000.
If the rest of the page is correct, though, it seems that 60000/1001 is actually based upon the RF frequency range available. NTSC was 60 Hz before color, and the addition of a color subcarrier necessitated a slight adjustment to the frequency.
Also, if I follow the math correctly, the NTSC vertical frequency is exactly 60000/1001, so digital NTSC video is exactly the correct framerate.
OK, I think you understand it better than me now. I'll have to read that article you found.
Anyway, the 1001 factor is not a "stupid hack" either. It's part of the real fieldrate of NTSC, which is 59.94... fields per second, not 60 fields per second. I'm told that NTSC was originally 60 fields per second in black & white, then they had to lower the framerate slightly to make bandwidth available for the color carrier. Not sure if this is true though, but it makes sense..
Yes, it seems that the 1001 is derived from a very intelligent hack. :)
:) Rich
Corey Hickey writes:
It's been a while and the telecine howto I wrote is out of date. Here's a patch.
Thanks, applied.
+ Use the "." key to step forward one frame at a time.
Use <keycap> instead of " here.
+ else <application>MEncoder</application> will crash. <option>pullup + </option> is, however, the cleanest and most accurate method
Please keep tags and their content on one line. Diego
Diego Biurrun wrote:
+ else <application>MEncoder</application> will crash. <option>pullup + </option> is, however, the cleanest and most accurate method
Please keep tags and their content on one line.
Diego
Ok. Is there a set of guidelines for mplayer documentation? I've just been trying to match the existing style. Also, here's a typo patch. Thanks, Corey Index: DOCS/xml/en/mencoder.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/mencoder.xml,v retrieving revision 1.37 diff -u -r1.37 mencoder.xml --- DOCS/xml/en/mencoder.xml 19 Feb 2005 14:35:46 -0000 1.37 +++ DOCS/xml/en/mencoder.xml 19 Feb 2005 19:39:35 -0000 @@ -1478,7 +1478,7 @@ The performace loss is small for most cases. On a bare-minimum encode, <option>pullup</option> causes <application>MEncoder</application> to be 50% slower. Adding sound processing and advanced <option>lavcopts - </option> overshadows that difference, bringing the performance of + </option> overshadows that difference, bringing the performance decrease of using <option>pullup</option> down to 2%. </para> </formalpara>
Corey Hickey writes:
Diego Biurrun wrote:
+ else <application>MEncoder</application> will crash. <option>pullup + </option> is, however, the cleanest and most accurate method
Please keep tags and their content on one line.
Ok. Is there a set of guidelines for mplayer documentation? I've just been trying to match the existing style.
Nothing has been written down so far.
Also, here's a typo patch.
Ooops, almost missed that one, applied. Diego
participants (3)
-
Corey Hickey -
D Richard Felker III -
Diego Biurrun