Hi On Fri, Jan 05, 2007 at 03:24:22PM -0500, Jason Tackaberry wrote: > On Fri, 2007-01-05 at 20:52 +0100, Michael Niedermayer wrote: > > 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, ...) > > Every single bullet on this list is supported by Xine's post plugin > architecture, if so, then how hard would it be to port the xine filter API to ffmpeg? also i assume it doesnt have any other silly limitations like only doing RGB24 or only YV12 or needing threads or doing a memcpy between all filters [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato -------------- 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/4f41c538/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