The fps value in flashframe is not one setting in one place. It goes to ffmpeg for extraction, to `setup_db_and_ingest` alongside the source rate of 25.0, to `detect_violations`, and into the SQL window itself, sized `ROWS BETWEEN int(fps)-1 PRECEDING AND CURRENT ROW` [6][19]. The window spans fps-1 rows, and it equals one second only when the rate that produced the rows matches the rate that sized the window. The regulation counts seconds; the query counts rows, and everything downstream inherits the difference [3].
Nyquist sets the rest. Sampling at 10 fps means nothing above 5 Hz is representable [10], which is 1.67 times the three-flashes-per-second threshold being certified against [6]. That is thin headroom for a rule a delivery can be rejected on. The adjudication path had less: the API default of 1 fps puts the representable ceiling at 0.5 Hz, six times below the limit [7]. The signal was discarded before the tokens existed, so no prompt could recover it, and the rewrite cost hours and changed nothing [16][20].
The latency table needs the same reading. flashframe's author reports p50 106 ms and p95 163 ms over a 92-minute feature of 138,240 frames [7]. 92 minutes is 5,520 seconds, and 138,240 divided by 5,520 is 25.04, so that frame count is the container's own rate, the 25.0 handed to ingest, not the 10 fps the tool extracted at [1][19]. At 10 fps the table holds about 55,200 rows per tile, roughly 40 percent of the frame count in the header [2], times however many tiles the frame is cut into, which the writeup does not state [6]. For 106 ms to mean anything on your footage you need the same tile count and the same extraction rate, with no escalation, since extraction, adjudication and ingest all sit outside the timed region [7][12]. That timed region measures only the fast part; the real cost lives outside it.
The escalation arithmetic is the good engineering here. Span 1025-1055 is 30 frames, three seconds of video at 10 fps; re-extracting it at 30 fps and then 60 fps costs 90 plus 180 frames, so 270 [4][13]. Re-extracting the whole feature at 60 fps costs 331,200 [5]. A resample tool capped at two iterations buys the escalated answer for about 1,227 times fewer frames [5][12], and the property mattered in maybe 30 frames out of 138,240 to begin with, about 0.02 percent of the file [11][3].
One caution on the false-negative case. The genuine strobe read 5.0 flashes per second at 10 fps and 6.25 after escalation, a 20 percent understatement of the escalated value [15][8]. Both readings exceed 3.00, so on that clip the verdict never moved, only the number [9]. For undersampling to pass a real hazard you need content whose true rate sits just above the limit and aliases below it. The clips described in the writeup sit either side of that case, at five alternations per second and at 6.25 Hz [9][16], and that gap is where I would build the next fixture.
