Even with the incredibly low bitrate parts of that look pretty nice. And it looks like the zoom and pan are very smooth!

To be honest, I actually hacked the numerical integration routine to do the required calculation when computing V while staying in the velocity domain. It just turned out that my approximation was exactly the routine required with the magic number tweak.

I'll run through a cut-down example. Say the magnification level M(t) happens to be 1, 2, and then 4 for a three frame animation. The rate of motion at each frame is V/1, V/2, and V/4, for some constant V, so that the motion appears smooth visually. Say we need to move a total distance of D=5 units during the pan. Since distance = rate * time, and our rate is V/1, V/2, or V/4, for time steps dt between frames, we can calculate the distance panned between each frame as V/n*dt, n=1, 2, or 4. The total distance moved is then V/1*dt + V/2*dt + V/4*dt = D = 5. Thus,

V = D/(1/1*dt + 1/2*dt + 1/4*dt).

In the integral call, Start and End will always be 0 and 1, so Size is basically 1/(NumFrames+1) = dt. [It looks like maybe you'll get slightly more accurate results if you use the magic constant NumFrames+1 instead of NumFrames-1, but meh, I knew it was NumFrames possibly with an off-by-1 error, so I just tested it to see what gave basically correct results, and NumFrames-1 did .]

The integral call computes the sum of 1/M(t)*Size, with M(t) computed at each frame, with each term multiplied effectively by dt = Size. This happens to be exactly the denominator necessary to compute V in this case. It's really just a convenient coincidence.