Smooth DVR playback: native-rate playback (true 720p90 / 1080p60) via the live-video display path

[bob9]

DVR recordings of 60 and 90 fps flights judder on playback because the menu UI drives the panel at 1080p50 while the recording's frames arrive at 60/90 fps. This PR plays them at their native rate: 90 fps recordings at true 720p90 (every frame shown), 60 fps at 1080p60.

Why v2 looks nothing like v1

The first version of this PR retimed the display on the FPGA's UI input path. Hardware bring-up falsified that approach: on both goggle generations the UI path only ever locks 1080p50 — every recipe tried (bare vdpo retime, clock phases, MFPGA setups, OLED timing sets) produced an unlocked panel. I closed the PR, built an in-firmware display bench, and found the route that works: enter the genuine live-video display mode and let the decoded video ride the vdpo overlay plane — the same path the OSD uses in race mode every day.

What's here

• ts_probe: the platform demuxer reports 0 fps for every goggle TS recording, which silently disabled any retime. Derive the frame rate from video PES PTS spacing instead (validated against 92 real DVR files plus synthetic 90/60/59.94/50/30, B-frame, truncated and junk streams).
• goggles2 (hardware-verified): 90 fps → 720p90 with the VO layer sized 1280x720; 60 fps → video-path 1080p60, pixel-perfect.
• goggle v1 (hardware-verified), with two v1-specific findings baked in:
  • the DE wraps a 1920-stride framebuffer at the 720p90 mode's 1280-wide scanout, so the UI re-renders at 1280x720 for the duration (exactly like the race OSD does);
  • the FPGA idles its video input on a green raster and its overlay chroma-key punches near-black pixels through to it — one receiver init per boot leaves a black mute raster behind the key, after which the receiver stays off for playback (prewarmed in the background while the user browses the file list, so no start-up penalty).
• boxpro: UI already runs 720p60 — no-op stubs.
• Playback UX: control bar auto-hides after 4 s and wakes on dial input, positioned inside the visible 720p90 window; unplayable files show an explanation instead of a silent black screen; thumbnails load straight off the card (the /tmp staging overflows its tmpfs past a few dozen recordings and silently degrades previews to placeholder icons).
• Bring-up tooling, kept on purpose: right-click during playback steps an on-hardware display bench (how both goggles were verified), and display/receiver transitions plus playback stalls append to a log on the SD card. Cheap, and invaluable for field diagnosis — happy to gate either behind a build flag if preferred.
• MP4 stays on the stock display path deliberately; TS-only retiming.

Credit

The live-video-path architecture and the goggles2 verification are @bolagnaise's work; the goggle v1 bring-up, probe validation and playback UX were done on this side. Field-tested on real race footage on both goggle generations.