On Wed, Mar 02, 2016 at 07:19:08PM +0000, Rostislav Pehlivanov wrote: > > - entry->cb = cb; > > - entry->rtz = rtz; > > + cb, 1.0f, INFINITY, &entry->bits, > > &entry->energy, 0); > > + *cache_state = cb; > > } > > - if (bits) > > - *bits = entry->bits; > > - if (energy) > > - *energy = entry->energy; > > + *bits = entry->bits & 0xffffff; > > + *energy = entry->energy; > > return entry->rd; > > } > > > > > The whole point of the function was to be a universal caching system for > every single scalefactor band which could be used in other parts of the > code (e.g. intensity stereo, mid/side, prediction, pns, etc.). Granted, > caching hasn't been implemented there yet. But by reducing the number of > arguments and assuming everything uses the same value for lambda and uplim > removes any possibility of the caching system being used anywhere outside.
Which is a reason why such design considerations really should be in a comment near the relevant code, because otherwise the code as-is doesn't make any sense and looks pointlessly obfuscated to anyone reading it. That said, those changes are mostly a left-over from experiments as I couldn't figure out why the code is so slow. I can look into it, but it might be worth for someone to look more closely into how this implementation can be made more CPU-cache-efficient as I only optimized the cost of clearing but not the CPU cache hit rates when we actually have a match. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel