Use frame number for encoder timestamp

Turns out it was always the frame number anyway, but when we calculated
the timestamp from the fileTime, we were liable to get an int64_t
overflow around 45 minutes in (for 29.97 (30000/1001) fps).
Fortunately, we can calculate the frame number directly without any
overflow problems. If we were using something other than 1/fps for the
encoder's timescale, we wouldn't have this work-around.

This fix addresses issue #4.