On Sun, 2008-06-22 at 15:21 +0200, Georg Martius wrote: > Hi Francesco, Hi transcode-folks > > I guess you thought I gave it up, since I did not reply for half a year, but > this is not the case, I just had absolutely no time. > In the meanwhile I adapted my code to compile with the CVS HEAD.
Don't worry, we're quite used to long development cycles :) > I have now some questions: > a) how am I supposed to contribute the code. Do I get a CVS login or should I > send patches? Usually our CVS policy is something on those lines: after some less or more regolar contributions, if the contributor agrees with our development policies (STYLE guidelines on top), and if the other devs have no objections, it will get a brand new cvs account. Until that moment, patches here on -devel are just fine :) > b) Do you have a better name for the plugins? > The stabilization as a whole is a two phase process: > I) detection of relative transformations, which is at the moment > called "stabilize" which is not very fitting. > II) smoothing and application of transformation. This is called "transform" > and can also be used for different purposes. I think that is okay. Both names are perhaps a bit too generic, maybe adding (the initials of) the name of the algorythm used could help? Something like xyzstabilize xyztransform I want to avoid, if possible, the questionable choices we did for filters like `smartdeint' and `smartyuv' > c) For the transformation plugin I would like to be able to resize the frames > (one factor for the entire clip), because I do also rotations and there is a > need for interpolations. An increase in frame size would increase the > quality. Is it possible to do that and what is neccessary. This will need a bit more discussion because one of basic assumption behind transcode processing pipeline are that some frame properties like width and height will not change. IMHO one of the biggest problem we'll face in relaxing this constraint is related to allocation of resources. Transcode tries to allocate as most as is possible the resource needed by processing before to enter the processing loop (for speed/efficiency reasons). We already have some problems in doing this because modules doesn't declare their needs, so the transcode core has to guess (and to be safe it greatly overstimates the needs of the modules). Fixing this isn't that hard, but it needs to change a lot of things. Anothe problem is that frame properties source isn't fixed (e.g. we lack a proper policy for this), sometimes the global vob_t is autoritathive, sometimes the value stored in frames are used. Once again, fixing this isn't hard, but it needs a general agreement on a policy and it needs a deep auditing of codebase. Bests, -- Francesco Romani // Ikitt
