Sampling rate is a correctness property, not a performance knob

In 1997, a Pokémon episode aired in Japan with a four-second red-and-blue strobe, causing 685 children to rush to the hospital. Following this incident, regulations were put in place, such as Ofcom Broadcasting Code 2.12 and ITU-R BT.1702, requiring broadcast deliveries to pass a photosensitive-epilepsy check before transmission.

The author built a screening tool to check for such violations. The tool is available at flashframe-production.up.railway.app and github.com/edycutjong/flashframe. The story is not about the tool itself, but about the author encountering two different bugs that were actually the same bug and not recognizing it the second time around.

The regulation states that there should be no more than three flashes in any one second. This is not a video-processing problem, but a time-series query. Per-frame luminance goes into ClickHouse, and the detection is done using windowed SQL. The window size is fps - 1 rows, because one second of frames depends on how many frames per second were sampled. The parameter of interest is fps, which determines whether a clip passes or fails the check.

Bug one occurred when a safe clip failed the extraction at 10 fps. The clip alternated 5 times per second, which is under the limit and should have passed. However, it came back with a violation. This happened because the samples landed at a beat frequency against the actual flashing, causing an aliasing effect similar to the wagon-wheel effect.

The fix was not to sample everything at 60 fps, but to resample only the span whose verdict was uncertain. When the clip resolved to 2.82 flashes/sec, it passed the check, while at 10 fps, it failed.

Bug two was when the model couldn't recognize a genuine strobe read at 6.25 Hz when sampled at 10 fps. The model was given a default sampling rate of 1 fps, and the strobe appeared as a still frame, making it undetectable. When the sample rate was increased to 24 fps, the model correctly identified the strobe. This bug highlighted the importance of checking the sampling rate, as undersampling can lead to missed hazards.

In conclusion, the author emphasizes that sampling rate is a correctness property, not a performance knob. When dealing with time-series data, such as video frames or sensor readings, it is crucial to sample at a rate that is at least twice the highest frequency of interest to avoid inaccurate results. This simple rule can prevent false failures and ensure the safety and reliability of compliance reports.