[FFmpeg-devel] DVCPRO HD: request for review

[Roman V. Shaposhnik]

On Fri, 2008-08-29 at 20:20 +0200, Michael Niedermayer wrote:
> So i ask again, where is that prommised cleanup?

It will follow either today or tomorrow if you stop distracting
me from it. I need to run a bunch of tests on different 
architectures to determine which scheme of replacing the tables
would be the fastest one. I don't want to repeat the mistake
that Dan has originally made where he replaced tables with
calculations only to discover that they were slower. The formulas
are *highly* irregular. For example here's what it takes to
calculate placement for 1080i60:
      case s1080i60:
           X = (j*2+(h%2))*9 + k%9;
           Y = (i*3+k/9)*2 + (h/2);

           if (X >= 80) {
               if (Y<4*8) {
                   X = (Y/4)*10 + X - 80;
                   Y %= 4;
               }
               else if (Y<4*8+3*8) {
                   Y -= 4*8;
                   X += (Y/3)*10 - 80;
                   Y = 64 + Y%3;
               }
               else {
                   X = ((Y-4*8-3*8)*10 + X - 80)*2;
                   Y = 67;
               }
           } else
             Y += 4;
May be it can be optimized via some clever formula manipulation
but not much. The formulas will remain highly irregular. So, the
question then becomes what's the best trade-off. And however ugly
static tables are they are not much worse than generating all the
same table upfront. The only difference would be heap vs. .rodata
section and bigger size of the disc image of the library. So, once
again, I have to run tests in order to offer the list all the
information for the qualified tradeoff.

> When will it happen?

In two days, if you stop distracting me AND if tables are the 
only real issue at hand. I'll submit the statistics today and hopefully
we can pick the right strategy. Since the code for all three
ways of how to deal with the tables is ready it shouldn't take
longer than a weekend to commit the one we agree upon. Does
it look reasonable to you?

> Besides of course the commit could and should have been split.
> But in this case iam more concerned about the huge (and unneeded) tables
> than the spliting. That if you insist on not doing it ...

Here's a quote from my original email:

-------------------------------------------------------------------
   2. The new set of tables is added. I would like to proceed with
      adding them first and them trying to figure out whether an
      alternative technique (such as generating tables on the fly, etc.)
      is feasible.
-------------------------------------------------------------------

and after the initial email on every occasion I mentioned that I
promise to deal with tables right after the code hits SVN. 

How much more explicit do you want me to be? Sign a contract
in blood?

Thanks,
Roman.

P.S. Besides you, yourself, have repeatedly indicated that you
do accept temporary commits of suboptimal code provided that
a replacement is committed really quickly. Heck! You even
admitted you do it yourself. So, why can't I? Especially
in a piece of code that I still maintain?