Analyze frame-by-frame timing of stimuli

Psychtoolbox complains about MacOS interfering with its ability to display things on screen with accurate timing, and refuses to continue unless you skip some internal tests. This is a problem because we fully intend to run this experiment on a Mac. Thus, we ought to see see how much that really matters. Comes now this timing branch, which adds some tests to analyze video timing when PTB's synchronization tests are bypassed.

Results after one run of n=30 videos are that all videos stay close to the target framerate of 60 fps or 16.67 msec/frame, but there is a distribution around that target (mean = 16.917, std = 2.045). The mean is pulled to the right by a small cluster of anomalously large frame durations: about 1.45% of frames form a distribution around 33.18 msec (std = 1.40), which is closer to 30 fps than 60. If we exclude those outlier frames, the main distribution is (mean = 16.677 msec, std = 0.51 msec). See Fig. 1 below.

All that is to say that about 99% of the time, things are happening exactly as they should, but 1% of the time, in each video, the framerate drops from 60fps to 30fps. This does not happen at a regular time, e.g. always the first or final frame, but seems to happen randomly - as likely to be 30% to 75% into the video duration as it is the very beginning or end.

It remains unclear whether this is problematic or not for this project. We send the eyetracker a timestamp of every frame's onset, so even if the video is not necessarily stable during presentation, eyetracking data should be synced to that instability. We also now output the frame durations to a file per subject (labelled as task-debug) so we know exactly when and where frame instability happens and have the ability to reject trials post-hoc based on that information.

Qualitatively, though, I didn't notice anything wrong with the videos when watching. They're so sparsely animated that it's likely not much of a factor - it may even be a deliberate attempt by the video engine to save bandwidth when there is no action on screen. I could keep analyzing, but it seems to be much ado about nothing.

Current directive is to soldier on.

Fig. 1 Histogram of frame durations Screen Shot 2024-01-23 at 12 58 49 PM Note. The target duration is 16.67msec or 60Hz. The vast majority of frames are reasonably close to this value, but a small subset (~1%) are at the wildly different 30 fps.

VPNLirvine / trEYEcopa

Analyze frame-by-frame timing of stimuli #15