[vlc-devel] [PATCH] Phosphor deinterlacer, reworked

[Juha Jeronen]

On 02/23/11 10:48, Jean-Baptiste Kempf wrote:
> On Wed, Feb 23, 2011 at 02:56:44AM +0200, Juha Jeronen wrote :
>> +/* "Phosphor" algorithm chroma output mode:
>> +   1 - always output 4:2:2 pictures, even for 4:2:0 input (better quality*; higher CPU usage; not good for netbooks),
>> +   0 - match input chroma format (faster for 4:2:0 input, which is common on DVDs).
>> +
>> +   * The choice affects the quality of output frames falling across an input frame boundary,
>> +     i.e. for output frames where one field comes from input frame "a", and the other from frame "b".
>> +     It has no effect on the quality of output frames that correspond to an input frame,
>> +     i.e. for frames where both fields come from the same input frame.
>> +
>> +   The choice "0" is recommended.
>> +*/
>> +#define PHOSPHOR_OUTPUT_422 0
> I must be stupid, but why proposing that as a runtime option?

I'm not sure I understand? Obviously, it's currently a compile-time
option... did you mean, why propose it as an option at all? Or why not
propose it as a runtime option?

For the first one - I think that although I would personally recommend
matching input chroma format, it's a nontrivial choice. It depends on
the input material whether this choice makes any difference. Think
telecined 4:2:0 with the chroma alternate line copied during telecine.
4:2:2 output won't help with that, because the input frames are already
messed up (chroma for one of the fields may be in the next frame!), and
should be corrected by undoing (redoing) the alternate line copy, like
the IVTC filter does.

It also depends on the kinds of devices that VLC is intended to run on.
For fast desktops/laptops 4:2:2 should not pose a problem, but e.g. Atom
netbooks and other slower hardware are simply not fast enough to compose
and render 4:2:2 at 60 fps. (I have to admit I haven't checked whether
it's a CPU or bandwidth problem.)

For the second one - any pointers on how to do that? Currently none of
the deinterlacers have any runtime options, so there was no example. (I
think that's pretty neat - since they have nothing to configure, they
have to be designed carefully, and also are easier to use. The "no
options" approach is not always reasonable, but for deinterlacers I
think it should work - at least for the most part, hence the current
confusion.)

 -J