[Ffmpeg-devel] New/extended filter API discussion

Michael Niedermayer michaelni
Fri Jan 5 20:52:48 CET 2007


On Fri, Jan 05, 2007 at 01:04:21PM -0500, Jason Tackaberry wrote:
> On Wed, 2007-01-03 at 11:52 +0100, Michael Niedermayer wrote:
> > > (BTW, I think the library will need to provide two
> > > separate APIs: one for audio and one for video... Or is it possible to
> > > design a filter API that can support both audio and video?)
> > 
> > yes 2 seperate APIs make most sense
> How will this accommodate filters that deal with both audio and video?
> For example a visualization filter (goom, say) will receive audio as
> input, and provide the video as output.

by having an audio and a video filter which are connected together

anyway if whoever designs the filter API decides to have a single audio+video
API then i certainly wont complain but until now _everyone_ has failed to
design a good video filter API, so adding yet another interdependancy 
is probably not going to make that any easier

to repeat again some goals of a video filter API
* well documented (see mplayer for how not to do it)
* writing a filter should not require complete knowledge of all
  (undocumented) internals of the video filter system
* direct rendering (useing a buffer provided by the next filter)
* inplace rendering (for example adding some subtitles shouldnt need the
  whole frame to be read and written)
* slices based rendering (improves cache locality, but there are issues
  with out of order decoding ...)
* multiple inputs
* multiple outputs (could always trivially be handled by several filters
  with just a single output each)
* timestamps per frame
* also th number of frames consumed by a filter does not have to match the
  number output ((inverse)telecine, ...)

also i suggest that whoever designs the filter system looks at mplayers
video filters as they support a large number of the things above

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070105/fccfed24/attachment.pgp>

More information about the ffmpeg-devel mailing list