On Tue, 2009-01-06 at 18:07 +0100, Francesco Romani wrote: > 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).
Because we already have a few filters that need more than one frame to work -smartyuv, smartdeinter...-. It would be nice to sort out a method to handle such situation at the core level, simplyfing the filters and removing (or at least optimizing) the need for internal buffer (reimplemented each time). -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
