I successfully ran a few test captures with the syncmouse last night. The idea behind a frame-by-frame telecine is to take a single picture of each frame while it is being projected. The projector/telecine has a little claw that pulls the film down in order to advance it, and this happens at the frame rate. On a normal 8mm projector, this would be 18 frames per second, but this telecine has been modified to run at 6 8 fps instead, or 1/3 ~1/2 the usual rate. The pulldown itself happens quickly, I estimate within 25-30 degrees of the projection cycle which is a full 360 degrees. With this estimate, we can estimate the time required to pull the frame down. At 8 fps, each frame consumes 124.6 ms of projection time total. Some of that time is used for the pulldown sequence. With the 27.5 degree estimate, we can divide that by the 360 degree cycle to find that 7.6% of the time is used for the pulldown. Multiplying this by the 124.6 ms projection cycle time tells us the pulldown is present for ~9.5 ms. Some time must also be allowed for the film to stop moving. This is the window we must avoid.
Unfortunately, it appears to be difficult to set this window up correctly due to a number of factors that must be accounted for. In the Workprinter XP telecine, the “mouse click” time accounts for approximately 110 degrees of the projection cycle, or 38 ms, during which the frame must remain absolutely still. However, the frame must be still at the final capture destination rather than the source (the telecine itself); this is tricky due to a number of delays in the capture path. There is a slight delay between when the syncmouse is triggered and the computer receives and processes the action to capture the frame, there is a processing delay within the camera viewing the frame, there is a processing delay within the Avermedia C127 HDMI capture card
|Pulldown – 10 ms | Mouse click – 38 ms | Capture delay – 67 ms | remaining time 10 ms|
|Pulldown ———–| Still frame ————————————————CAPTURE————–|
However, I am still capturing moving frames. This indicates that there is more than an additional 10 ms of delay present between the camera, OS, and capture program. This is solved by measuring the amount input delay present and advancing trigger wheel by the amount of delay present. For example, if we 67 ms for our input delay, we would divide that by the projection time of 124.6 ms to find that the delay is 53% of the projection sequence. We multiply 53% times 360 degrees to find the degrees of advance required to compensate for the delay, which is 194 degrees of advance. This signals the computer to capture the frame 194 degrees earlier so that by the time the delay has elapsed, a perfectly still frame will be present.
This poses yet another question – how do we measure the delay? The closest answer I’ve come up with is to display an accurate timer or clock on a monitor alongside the capture preview window, then capture the monitor. The difference in time between original timer and the timer as viewed in the capture window is the delay in the camera, capture card, OS, and capture preview. Some delay will exist in actually displaying the information, but as it is present in both the original output and capture, it should cancel out. However, this does not account for signaling delay, which is hopefully minimal. As long as this signaling and capture delay is less than ~77 ms (125 ms projection time – [10 ms pulldown + 38 ms capture window]), the capture should be successful.
I measured the delay using the above method and came up with an astounding average delay of 256 ms over an average of five measurements! That’s more than TWICE the projection time which means I drop two frames every time the capture starts. Below are my exact results
Trial Screen Clock Diff
—————————————————————
1 21:59.941 22:00.208 249 ms
2 24:17.609 24:17.892 283 ms
3 25:04.009 25:04.259 250 ms
4 26:51.542 26.51.809 267 ms
5 28:20.859 28.21.090 231 ms
AVG 256 ms delay
256 milliseconds of delay is equal to (256 ms delay / 124.6ms projection time = 2.05457 frames) * 360 degrees = 739.65 degrees of advance required to correct for the delay. Because I can’t advance the timing disc by more than one full rotation, we get rid of any whole intervals of 360* to leave 19* as the answer to getting perfect results. Unfortunately, this assumes the timing remains perfect – and apparently it doesn’t because I STILL get pulldown blur 🙁 So the next fix either slowing down the projector to provide more timing leeway and/or increasing timing consistency.
An interesting note to these calculations is that the telecine is supposed to run at 6 fps (I believe). However, I felt it necessary to measure and verify the speed – and it’s a good thing I did because the calculation completely changed with the telecine running at 8 fps! I measured the speed using two different methods. The first method involved recording the running telecine with a microphone, then identifying the audio fingerprint of a new frame being projected. Once this was identified, I measure the time which I found to be ~.12832 seconds or 128.32 ms. This corresponds to 7.79 fps. The second method was performed by using an online stopwatch, positioning the mouse over the lap button, and letting the syncmouse rip. Over an average of 5 “laps,” I recorded a time of 124.6 ms which is almost exactly 8 fps.
*Side note: The shear volume of information captured is worth noting. At 1080p in high color, each frame generates a 4 megabyte bitmap. At eight frames per second, 32 MB/s continuous write speed is required to flush the information to disk. This makes fast drives an absolute requirement to avoid dropping frames. Worse, playback at 18 fps requires three times more bandwidth, or 72 MB/s, something my RAID 1 volume** is apparently incapable of, although my SSD handles it without a problem. Unfortunately, SSD space is expensive.
**Fixed that… maybe I’ll post about it later. I had a 5400 rpm & 7200 rpm running in the same RAID array due to an ordering error. I swapped out the 5400 rpm drive for another 7200 rpm drive and all is well.
time!
