On Sunday 04 January 2009, Francesco Romani wrote: > .... > Filter layer uses N threads per stream. The thread can finish in any > order, so they can deliver the frames to export in any order. > But export expects frames in-order! > > An order as returned by filter layer can be 1-2-3-4, 4-3-2-1, 1-3-2-4, > any combination is legal. How is it exactly done? I am wondering whether it is still garanteed that filter plugins are called with subsequent frames. E.g. the stabilization filter requires to be called with subsequent frames. Also the transform plugin has for each frame a certain transformation to make so it would be bad if it is called out of order.
> .... > I've initially thought (and I'm still convinced that is possible, that's > the most efficient solution and it's also quite elegant) that it is > possible to use a pseudo-sliding-window procedure > (http://en.wikipedia.org/wiki/Sliding_window), having implicit ordering. > The export buffers become a sort of rotating sliding window (so, a > sliding window implemented using a ring buffer), > no longer a plain old FIFO. So filter layer can deliver the completed > frames directly into the correct slot without hassle and, as said, with > implicit ordering. And maximum efficiency. > > Uhm, clever! Probably too clever. That's hard to explain (so hard to > document, hard understand, hard to hack, and that's Bad. Very Bad.) I also believe that sliding window is to be preferred over a heap. The concept is not so difficult and should be easier to understand than a heap. Regards! Georg
