[mythtv] packed image format and new deinterlacers

[Andrew Mahone]

There are a few problems with filters using multiple frames without
copying. If more than one filter is modifying frame data, and storing
a reference to old frame data, a filter may have it's "previous frame"
changed under it by another filter in the chain.

It seems the best thing to do is either:
1) create a new frame when modifying frame contents (might be a
problem already, are frames passed to filter chain still referenced in
the video codec as well?)
2) copy contents of any old frame you want to reference later

2) is not necessarily a huge performance hit for filters that read
through the whole frame anyway. Before it's current single-frame
implementation, I toyed around with a kerneldeint that used
previous-frame data as well. The data was copied to the previous-frame
buffer as it was being read for processing - ie, before a chunk was
operated on, it would be copied to another buffer. The extra store to
memory might be a bit of a hit, but there will probably not be an
extra read if gcc does its job.

1) might be the way to go, though. If a filter doesn't want to modify
a particular frame, it can leave it alone entirely. If it must change
frame contents, it will need to write the filtered frame into a new
buffer. Some sort of reference tracking would be needed to make sure
that these buffers aren't leaked.

Another problem is going to be handling telecined content. To take
care of this sort of thing, we need a way to be able to drop a frame,
or to adjust the timing of a frame. For double-framerate output, we
need a way to insert extra frames. Perhaps adding a function that
allows for the insertion of a new frame, and having the filter call it
after filling out the new frame structure? Or the filter API could be
altered to have filters call a function with each frame they output,
and allow it to be called twice (or not at all, to drop a frame?).

Anybody else have thoughts on how to implement this? Perhaps somebody
who knows what they're doing in this area (because I mostly don't).
-- 
Andrew Mahone
andrew DOT mahone AT gmail DOT com