[mythtv] Filter interface change proposal, working on patch.

[Andrew Mahone]

I'm planning to port and/or write some good deinterlace and detelecine
filters for use in recording.  Good handling of interlaced video requires
chroma data for each line, so I'm working on adding the following:

Filters provide a list of accepted input pixel formats, with preferred
formats listed first (a deinterlace filter could accept YV12, but ask for
YUV422P if available).  Filters also provide a list of available output
formats.  Both of these lists would be provided as new members of the
VideoFilter structure.

A new function pointer, setup(int width, int height, int inpixelformat,
int outpixelformat, char *options) would be added to the filter
structure.  Any change in filter parameters, pixel format, or dimensions
would require re-initiialization.

A new function would be added in filters.c, filters_setup(int &width, int
&height, int &inpixelformat, int &outpixelformat, VideoFilter **filters,
int numberfilters), and would be used by filter clients to set up the
entire filter chain.  Width and height would be modified by filters which
change the frame size.  With this interface, overscan could be handled
entirely by a filter.  Inpixelformat and outpixelformat are not to be
modified unless values of -1 are passed, in which case they will be
filled with preferred values of the filters.  -1 would be passed for
inpixelformat when recording, and the capture device would be set to
capture the preferred format.  I don't see likely reasons for
outpixelformat=-1 to be used, but it will be supported in case a future
need arises.

Initially, I would have filters that do not provide an acceptable output
format for the next filter in the chain to cause filtering to be
disabled, but in the future, filters_setup could insert generic format-
conversion filters as necessary.

I'm starting work on this now, and will probably code the whole thing and
patches for existing filters myself, unless other developers express an
interest.  I would just like to get feedback and suggestions on these
ideas from other developers, and to make sure this is a good idea before
I get too far into it.
-- 
  Andrew Mahone
  andrewmahone AT eml DOT cc

-- 
http://www.fastmail.fm - The way an email service should be