Hi, On Thu, Sep 13, 2012 at 5:42 PM, Diego Biurrun <di...@biurrun.de> wrote: > --- > This iteration fixes some #includes.
I'd like to repeat something I said on IRC, because I feel it's relevant to this discussion. Assertion 1: dsputil is an infinite mess. Assertion 2: in the ideal state, dspcontext is split in an infinite number of small, self-contained, clean units of dsp code that can then be used invidually by codecs or other code needing access to dsp. Assertion 3: since the amount of work to be done in cleaning up dsputil is linearly dependent on the amount of code+mess (i.e. it's infinite), this will never be finished. Your approach 1: - split 1 dsputil in N files which all share 1 context. (a variable approach here is to split 1 dsputil in N equal files which each use their own context, that's slightly better but still suffers from the same problem) The disadvantage of the split is that a split of 1 infinite unit in 3 units leaves 3 infinite units. Thus, there is no cleanup, just a spreading. Add to that that it's still using DSPContext, and you'll see why I'm not very excited about this. My approach 2 (also used by Justin, Mans and several others): - cut out small chunks of self-contained code from dspcontext in a new codec-specific mycodec-dspcontext (can also be a utility-dspcontext). The advantage here is that we work towards the final goal, and we do that not by creating 2 messes, but by leaving the 1 mess as it is (1 mess), and creating a new, small, clean chunk that does not have that issue. Thus, there is no spreading of the issue, but rather a very slow but meaningful solving of the issue. The problem will never be solved entirely, but that's to be expected (see assertion 3). Ronald _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
