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

[Andrew Mahone]

On Wed, 22 Oct 2003 23:43:12 -0400, "D Banerjee" <davatar at comcast.net>
said:
> Remember it's not just people running older machines, get a pcHDTV
> card, and you won't have enough free cpu to be able to encode anymore
> even on cutting edge stuff.

That's another case I wasn't thinking about, but my main goal is
improvement of available filters at encode time.  Letting filters select
a good input format at capture time is important for deinterlacing at
capture, but most of the rest of these changes can help everywhere that
filters are used, and pushing frame parameters into filter load will
simplify things greatly for people developing or porting filters.  As
far as cropping goes, I'd also like to see a "crop input" option.  On
cards which support the feature, it would set a crop window for capture.
When cropped capture is not supported, it can insert a crop filter in
the filter chain.  Overscan could work the same way, if the output
allows crop/resize, great, if not, put the crop filter at the end of the
filter chain.

> But the reload on format change really does need to be done, also
> moving the frame parameters into a struct accessible from filter init
> is a good idea too. The main filter function should be as bare as
> possible (only pointer to frame buffer). BTW what's wrong with just
> expanding the current "load_videoFilter"? (including filter pre-
> enumeration for configuration purposes)

I see two benefits here.  By making load and setup two separate
processes, can skip filter reload when we are using the same filter
chain with different inputs.  Also, splitting setup into a separate
function allows the minimal change from the current method, while still
allowing filters that would alter the size or pixel format of frames.
Filters may need to know their requested output format at setup time,
and they can't know that without the next filter already being loaded,
unless we add a new way to probe filters for supported formats before
they are loaded.  OTOH, that could also be part of a framework for
enumerating available filters, which would give us a nice way to build
filter chains in the GUI.
-- 
  Andrew Mahone
  andrewmahone AT eml DOT cc

-- 
http://www.fastmail.fm - IMAP accessible web-mail