[MPlayer-dev-eng] [PATCH] New filter: vf_phase.c

[D Richard Felker III]

On Sun, Mar 28, 2004 at 05:38:56AM +0300, Ville Saari wrote:
> If film is converted to PAL video using top-first field dominance and then
> captured using bottom-first field dominance or vice versa, then inherently
> progressive material will have really terrible interlacing artifacts (twice
> as strong as true interlaced video). Some PAL DVDs suffer from this.
> 
> I wrote a filter to fix this. It changes the field dominance of the video
> by doing 180 degree phase shift to the interlace pattern. Or in other words
> it delays the video by half a frame.
> 
> -- 
>  Ville

> diff -Naur main/DOCS/man/en/mplayer.1 patched/DOCS/man/en/mplayer.1
> --- main/DOCS/man/en/mplayer.1	2004-03-28 04:12:48.000000000 +0300
> +++ patched/DOCS/man/en/mplayer.1	2004-03-28 04:16:30.000000000 +0300
> @@ -3136,6 +3136,37 @@
>  Currently only libmpeg2 exports the needed flags.
>  If used on material that does not set them, the filter does nothing.
>  .TP
> +.B phase[=options]
> +Delay interlaced video by one field time so that the field dominance
> +changes. The intended use is to fix PAL movies that have been captured
> +with the opposite field dominance to the film-to-video transfer.
> +The options are:
> +.PD 0
> +.RSs
> +.IPs b
> +Capture field dominance bottom-first, transfer top-first. Filter will
> +delay the top field.
> +.IPs t
> +Capture top-first, transfer bottom-first. Filter will delay the bottom field.
> +.IPs p
> +Capture and transfer with the same field dominance. Filter will do nothing.
> +.IPs B
> +Capture bottom-first, transfer unknown or varying. Filter selects among
> +b and p on a frame by frame basis by analyzing which alternative
> +produces best match between the fields.
> +.IPs T
> +Capture top-first, transfer unknown or varying. Filter selects among
> +t and p.
> +.IPs u
> +Both capture and transfer unknown or varying. Filter selects among
> +t, b and p. This is the default.

Like I said, both-unknown isn't needed or useful. The capture
field-order is always known (the mpeg decoded exports it). It's
possible for this to vary if the repeat-first-field flag is ever used;
does your filter handle this case?

Rich