[vlc-devel] [PATCH] [RFC] Phosphate/IVTC2x deinterlacer

[Juha Jeronen]

Hi,

On 03/05/2011 10:35 PM, Rémi Denis-Courmont wrote:
> My only concern is that the current deinterlace filter is a kind of a mess of 
> huge file. It really needs to be sensibly split before it is meaningfully 
> extended. Otherwise, it's really up to you what you would like to merge in the 
> official codebase or not.

Ok. Thanks for the input. Personally, currently I think the original
purpose of Phosphate can be better served with a 2x mode in the
traditional IVTC filter. Too bad for the obvious pun and the working 1D
density estimator, but unnecessary things are unnecessary :)

I agree about the deinterlacer module. Originally it was a nice,
self-contained package, the workings of which one could approximately
learn in an evening or two (hence, I'm here), but the file is getting a
bit long.

I'll help with its refactoring (including splitting) in the near future.
I'm proceeding pretty much according to the plan I posted a while back -
Phosphor first, then IVTC, and then the refactor. I'm not particularly
attached to ordering the last two items that way - this order inherits
from my original plan, combined with j-b's suggestion to get the new
filters in first.

I could do the refactoring right after Phosphor, too. That way, I could
then use IVTC as a test case of adding a new mode into the new design.
Testing it this way might be good for writing some (brief) developer
documentation about implementing new deinterlace modes. (The first
question a new developer asks: which parts need to be modified, and
where are they?)

(I think the deinterlacer needs both developer and end-user
documentation. I'm considering writing some, but that can wait until the
code changes are complete.)

Anyway, either ordering for the two tasks is fine with me.

The refactor TODO list currently looks as follows:

- Make a subdirectory (in video_filter), move deinterlace.c there
- Update Modules.am
- Keep general stuff in deinterlace.c
- Keep general-use data in filter_sys_t
- Move filter_sys_t to header
- Move each algorithm into its own file
- Move general-use helper functions into one file
- Move private data into private structs; add init/uninit API
- Use an enum instead of a bunch of #defines for the modes.
- In all modes, loop over y instead of p_out.
- Use the new helper functions (plane_ToFieldPlane(),
plane_CopyPixelsLineByLine()) where possible. This applies at least to
Bob, Linear and Discard.
- Make a field/plane merge helper function and use it in all
modes/functions that can be simplified using one. At least
ComposeFrame() and Linear would benefit, and maybe also Mean and Blend.

Everyone is welcome to suggest new items :)


> I have no ideological nor technical issues. I simply don't have the skillset 
> to review this, and it would take for too much time. Laurent would be a better 
> contact, but he too has a free time bottleneck and other priorities (including 
> writing cool VLC code of his own).

Yes, of course. I understand :)


 -J