[Ffmpeg-devel] New/extended filter API discussion
Michael Niedermayer
michaelni
Fri Jan 5 20:52:48 CET 2007
Hi
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