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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4