On Tue, 2009-01-06 at 23:14 +0000, Andrew Church wrote: > >like we already do? > >(our current code is not that different, see for example > >frame_threads.c , and vframe_reserve/vframe_push_next and their > >implementation) > > > >In a nutshell, why can't just pass away the old frame recycling it? > > Because then we'd have to add framebuffer_free(frame) calls to every > filter that doesn't have a 1:1 correspondence between frames. > Admittedly, I don't think there are very many filters like that (modfps, > decimate, 29to23, ...) but I'm more concerned about the possibility of > resource leakage in general. As a rule, I prefer a mechanism that's > robust against leakage (e.g. by having a single free() call that applies > to every module) over one which relies on multiple modules to all do the > right thing (e.g. call free() if they don't put() the same frame buffer).
What we essentially need is a safe way for a filter _plugin_ (while I was referring to the core part handling the filtering) to deliver N *more* (cloned) frames to the core, right? If I'm right, we're facing the issue of having more than just one output for a filter module (so the issue of having more than just one input is just behind the corner). -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
