SeekPreviewService

Scrub-bar thumbnails for any source libavformat can open — the floating frame a player HUD shows while the user drags the seek bar.

This is deliberately its own small pipeline, not a reuse of the playback paths, and independent of which engine is actually playing the title:

• It opens its own context. An AVFormatContext is not safe for concurrent use, and the producer's is busy producing — a thumbnail request must never stall playback, only itself.
• It decodes on the CPU only. A thumbnail is one keyframe scaled to ~300 px: VideoToolbox would win milliseconds and cost a hardware session per preview strip, plus the fallback complexity playback genuinely needs and this doesn't. sws_scale also IS the delivery format step — the decode and the downscale are one pipeline stage here.
• The image comes back as a CGImage, because the only consumer is a HUD about to draw it. No CVPixelBuffer, no CMSampleBuffer — those exist for renderers.

A request decodes the keyframe at-or-before the timestamp (av_seek_frame BACKWARD lands there; keyframes decode standalone, so one packet usually suffices) and the result is cached by the keyframe's PTS: scrubbing within one GOP is a dictionary hit, not a decode. When the source has a harvested keyframe map (KeyframeIndexCache, issue #34), requests resolve to their keyframe before seeking, so even the first touch of a GOP that is already cached skips the demuxer entirely.

Known caveats, accepted for v1: HDR (PQ/HLG) sources are converted by matrix, not tone-mapped — previews look flatter than the picture. Dolby Vision Profile 5 (IPT-PQc2) has no honest RGB conversion here at all; the host should not offer engine previews for P5 (SourceInfo says).