[MPlayer-DOCS] RFC: mencoder with interlacing/telecine howto (draft 1)

Corey Hickey bugfood-ml at fatooh.org
Thu Jan 8 02:51:41 CET 2004


D Richard Felker III wrote:
> On Mon, Jan 05, 2004 at 02:34:12PM -0800, Corey Hickey wrote:

>>+4. 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 -vf field, then crop[1] and scale appropriately.
> 
> 
> The footnote doesn't apply here. :) Once you drop a field, the
> remaining picture is "progressive", so you can crop to any even
> size/offset.
> 

Well, I have a feeling that many people reading this won't know that
cropping evenly is necessary. I used mencoder for months before I knew
that, because I had no idea what YUV 4:2:0 is. Checking now, I can't
find any mention in the manpage or docs, not even in the new DVD ripping
howto or encoding-tips.txt. It probably ought to be in at least some of
those places, too, and perhaps after this is finished, when I have more
time, I'll try to submit some patches. Anyway, the first part of the
footnote explains why "even" is needed, so it does apply. :)

> 
>>-   may adversely affect the progressive parts.
>>+   may slightly degrade the progressive parts.
>>+
>>+   This option should definitely not be used if you want to eventually display
>>+   the video on an interlaced device (with a TV card, for example). It may also
>>+   be a bad idea for progressive display, too. It will drop interlaced fields,
>>+   resulting in a discontinuity of 1/24.976 second, which can be more noticable than
>>+   the next option, which will make some frames display for 1/29.97 second
>>+   longer than they would otherwise. Either way, it's best to consider your
> 
> 
> Eh? This isn't quite what I said.

Yeah, I misread that as what my brain wanted to think rather than what
my eyes actually say. It should be fixed now.

> In fact the problem is much worse
> than I said before. If you have interlaced frames in 23.976 fps video,
> then playing it on a TV will naturally telecine it, meaning that half
> of the interlaced "frames" will get displayed for 3 fields duration.
> This will result in a flickering "jump back in time" effect during
> interlaced sequences, and it looks very very bad. So if you're going
> to use -ofps 23.976, you _really_ should deinterlace the interlaced
> parts with l5 or lb (or better, make a new adaptive-deinterlace filter
> that only applies l5 where it sees interlacing).
> 
> 

Changes:

* typos...
* Changed an instance of "watch out" to "beware". I think it sounds
   better. :)
* Reorder section on how to deal with mixed telecine/progressive: put
   softpulldown,ivtc in front and number each method.
* More detail on how and why pullup can fail.
* Fixed my misinterpretation of how treating mixed
   interlaced/progressive as progressive is bad, and added new details
   regarding interlaced display.


Diff attached, complete current draft at:
http://fatooh.org/files/telecine.txt

Thanks,
Corey
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: telecine.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-docs/attachments/20040107/2cb9e963/attachment.asc>


More information about the MPlayer-DOCS mailing list