On Mon, 2009-01-12 at 13:18 +0100, Georg Martius wrote: > Hi, > I think there is a better way to deal with it. Why not having a FIFO at each > edge of the tree. Each node runs in its thread and basically asks the > upstream FIFO(s) for a frame and processes it and stores it in the downstream > FIFO(s).
It's probably cleaner: what I was suggested is less or more an hidden FIFO. Following my gut feeling, the overall design should be (hopefully) cleaner if we have both upstream and downstream buffering, *and* we can still have direct rendering (aka zero-copy). But I've to think a bit more about that and try to sort out the whole thing. > It only blocks if there are not frames available otherwise it can > run on full speed. If we have a demux or mux node then it has simply more > then one in/out-going edge (FIFO). There are serveral ways to do it. Either > the FIFOS life in the nodes or are extra objects. Let's say we have them > separate for now: I like this way too. [...] > I know that we don't want to change the interface for the modules but in the > long run I think we should use the new architecture to allow the Frame meta > data to change. E.g. to allow resizing and stuff just everywhere. This is mainly a constraint of framebuffer code; the modules are pretty neutral with respect to this. Moreover, I can't figure out nothing in the current NMS API which can prevent us to have changing metadata across nodes. > Allow modules could get multiple frames as input as once. Yes, that's one of my major concerns. > Currently the filters can already specify how many frames they need but > they still have to store them internally. IMHO that can be solved too using a new framebuffer model. It should be enough to `lock' frames into the fifo and wakeup when the needed amount is ready. For example, let's considere a FIFO size of 5 elements. Let's consider a filter needing 2 frames to work and produce a new one Frame In Out 1 N/A 2 process(1,2) -> 1 3 process(2,3) -> 2 ... It's smarter (and absolutely feasible) to wakeup when fifo_size(IN_FIFO) >= 2. The current situation is due to legacy for a significant amount. [...] > Now if we really want multithread nodes, say for encoding, then we can have a > special ProcessingNodeMT that handles the frame order and stuff. [...] I think we should'nt be concerned by that. The frame ordering issue are -again- a legacy and a constraint due of the current MT *filter* design. I'm pretty convinced that a new design -like the new one we're talking about- removes this problem alltogether and without further effort. Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
