On Sat, 2009-01-10 at 12:13 +0100, Georg Martius wrote: > Hi Francesco, > > You know that I am rather new to transcode so please keep this in mind when > reading my comments ;-)
It's good to hear something new :) > I just want to say that I like the idea to have a sequence of processing > nodes > with little streams between each node. > I would like to add that also the properties structures have to be processed > through the processing chain. What I mean is that every processing node can > change the frame-size, frame-color model and so on. Each node just gets the > structure information from the previous one, that's it. I mostly agree. Of course one of the objective of the chaining code should be to minimize the expensive transformation (say, colorspace conversions) as much as is possible. > I believe the meta > information and the actual frame should be dislinked. The meta data is not > changing over the processing time and has to be saved for each intermediate > stream whereas the frame-data changes. That should be a property of the TCProcessingItem into the former example. (BTW, another big thing to sort out properly in order to develop my idea is how to handle the input probing). > I see the following: > > Processing Processing > -> Stream -> -> .... > Node1 Node 2 > > where Stream has a FIFO (sliding window type) for frames and meta-data. The siliding window thing becames irrilevant if Node1 is single-threaded. > Frame > number or only valid within a stream. If we would limit the multiprocessing > to one thread per Processing Node then there is also not problem with > out-of-order frames. Excaltly. Moreover, in the common case, one thread per node is likely an overkill. More nodes (I intend Node=TCProcessingItem as in my former example) can be effectively handled by a single thread. Maybe it could be nice to add some kind of "declared weight" for each node and collect nodes into threads until the sum of the node's weight reaches a threshold (some kind of automatic load balancing). > In the case we need more threads per Node I suggest to > have a small multithread wrapper around the particular Nodes that need it. > Nodes that might clone or skip frames might not be necessary to run in > parallel and have therefore less problems with framenumbers. IMHO that should be handled trasparently by the underlying TCModule. Of course no more than one TCModule for TCNode :) > Concerning the move to a new executeable I fear that if we share the same > modules we might block ourselves since we cannot change their interface. Well, the module interface (I mean libtc/tcmodule-data.h) itself should be separated by the client code by at very least one incapsulation layer, so this should'nt be a big deal. What I try my best to achieve is to a better separation between layers, so, say, a change of interface for modules affects little or nothing the client code. > I would make a change to the next major release (1.2.0). On this topic, I haven't no changes on my own list for 1.2.0 (neither for 1.3.0) except minor things (maybe a few more methods for modules). I'm of course collecting the drawbacks and shortcomings of existing API/implementation, but I do want to see a NMS-powered transcode deployment into the wild before to do big changes. So, at very minimum, nothing serious should change (on my side, of course) until 1.3.0 > I see the scripting interface totally decoupled from the change in the core > architecture. The latter is a backend change and the scripting interface > is "just" a way to control things, so a frontend. Indeed :) Neverthless I find it really cool ;) Moreover, applying a scripting interface upon the structure outlined into my last mail is WAY easier than applying over the existing one. Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
