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

[D Richard Felker III]

On Mon, Jan 05, 2004 at 02:34:12PM -0800, Corey Hickey wrote:
> D Richard Felker III wrote:
> 
> >>
> >>Hoping you don't mind, I quoted this paragraph and attributed it to you.
> >
> >
> >OK, let's just be sure to change it if/when filmdint improves. You
> >should also try it yourself and see if you agree with my assessment.
> >It might be much better on live content than animation; the only
> >telecined DVDs I have are anime.
> >
> 
> Sure. Trouble is, I don't think I'll be able to find any telecine
> sources here at my mom's house, so I'll have to wait until I go home
> sometime next week. :)

Ah, ok. BTW you can try some of my (pathological :) examples at:
http://brightrain.aerifal.cx/~dalias/video_examples

> +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.

>  Pullup doesn't really work well with the current mencoder, and is intended for
> -use with mencoder G2 (whenever it's ready).
> -
> -Filmdint
> -TODO: DESCRIBE FILMDINT (I haven't used filmdint yet, but it ought to be good)
> +use with mencoder G2 (whenever it's ready). It works fine without -ofps, but
> +-ofps is needed to prevent choppy output. With -ofps, it sometimes fails.

You might want to mention the two ways it can fail. Both are related
to the way mencoder skips frames to keep fixed output framerate & A/V
sync.

One way is running out of buffers (because of bad design/bug in G1's
filter layer), and that results in a crash. It happens when too many
frames get dropped to preserve a/v sync.

The other way it can fail doesn't cause a crash, but whenever mencoder
skips a frame, pullup doesn't get to see that frame, meaning it will
be operating based on an incorrect frame sequence. This can cause it
to make bad decisions about how to reconstruct progressive frames out
of fields, and it can end up dropping several fields to compensate, or
incorrectly matching fields that don't belong together.

So therefore I would strongly recommend against using -ofps with
pullup, or at least recommend that anyone wishing to do so use a great
deal of caution in checking that the output looks ok. The results
certainly won't be as correct as when using pullup without -ofps.

By the way, this would be fairly easy to fix by putting framerate
regulation code in vf_pullup...

> -   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. 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).

> +   For telecined video, I recommend that cropping take place after inverse
> +   telecining. Once the video is progressive you only need to crop by even by
> +   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.

Yep. Not only will it have the wrong data, but it won't know. The
inverse telecine filters _ignore_ chroma for doing their computations
(because it's often noisy and low-resolution), so they'll happily
reassemble chroma incorrectly if your crop offset isn't a multiple of
4, and your output will look very bad.

> +   For interlaced (not telecined) video, you must always crop vertically by
> +   multiples of four unless you use -vf field before cropping.

Ah, here you said it. :)

> +2. Just because I recommend mbd=2 here doesn't mean it shouldn't be used
> +   elsewhere. Along with trell, mbd=2 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.

Good!

Rich