On Mon, 2010-07-26 at 12:39 -0400, Allan N. Snider wrote: > Transcoders:
Hi there, [...] > As far as I know, the next frame isn't available yet to the filter. > My question is this: does the filter API provide any kind of forward > lookahead, ie. maintain a small window of frames as it makes filter > calls? No, the filter API lacks this feature. Frames are pushed into the filter layer one at time, without any forward or backward buffering/windowing In other words, each filter which operates on more than one frame at time (e.g. which exploits or just depend on any frame inter-correlation) has to do its own buffering. We already have some filters doing the above, hqdn3d if memory serves well, but they are easily found with the aid of grep. Clearly, the filter API is too simple (the code duplication into the filters demonstrates that) in this regard. There is (a lot of) room for improvement. Chances are some tuning is possible to ameliorate this issue or maybe to even solve it for the simpler cases. E.g: the core can wait to have 3 (not one) frames avalaible before to push them into the filter. Of course some API change will be needed. A proper general purpose solution will quite possibly involve some architectural changes to the transcode core (buffers/frame management/references). I'm open to discussion and suggestions, if you're (or anyone else) is interested. If you want to dig the sources, src/framebuffer.? is probably the best way to start. Be aware than things are changed (for the better, hopefully) into HEAD/1.2.0 with respect to 1.1.0. > I know transcode development is pretty much halted now, but it's > still the ideal infrastructure for playing with video filters, so I'm > not letting it go yet. With more of this (very good) attitude, transcode can restart even better than before ;) Bests, -- Francesco Romani
