Floating point precision errors lead to blank frames at end of composite clips

[Humper]

Example:

clip duration = 0.56
fps = 12.5

When this gets written out to frames, we use (in Clip.py's iterframes):

        for t in np.arange(0, self.duration, 1.0/fps):

But numpy gives:

(Pdb) np.arange(0, .56, 1.0/12.5)
array([ 0.  ,  0.08,  0.16,  0.24,  0.32,  0.4 ,  0.48,  0.56])

This means that a composite video clip will try to generate an 8th frame at t=0.56. However, since the individual clips that make up the composite all have end=0.56, none of them is considered to be playing at that time. This results in a black final frame (just the background color, with no clips composited over it).

I don't think this is really a bug in the compositor so much as a result of numerical precision issues resulting in the extra t=0.56 frame being generated. Specifically, numpy says that arange generates a half-open interval [start, end), so in theory the arange array should end at t=0.48, but it doesn't, because the numbers 0.56 and 0.8 cannot be represented perfectly by floating point.

One quick hacky workaround to this specific problem is to change the upper limit of the arange to:

self.duration - 1.0/(2*fps)

This will prevent the spurious final frame from being generated.

[ghost]

to avoid the floating point error issue, would it be better to do something like:

for t in np.arange(0, self.duration * fps, 1)
    new_t = t/fps