Extract RecordingPipeline from CameraViewController (UI modernization PR 9)

[darioalessandro]

Summary

PR 9 of the UI modernization series: the recording/sample-buffer pipeline moves out of CameraViewController into a new non-UI RecordingPipeline, following the exact playbook of PR 8's CaptureEngine extraction — mechanical move, no behavior or threading changes, closure seams back to the VC, full suite green as the gate.

CameraViewController drops from 962 → 632 lines. With capture (PR 8) and recording (this PR) both out, what remains is real UI plus the frame streamers — the runway for the PR 10 SwiftUI chrome.

What moved

RecordingPipeline (407 lines, zero UIKit) now owns:

• The asset writer and its video/audio inputs, the pixel-buffer adaptor, and the writing queue
• The six-boolean recording state machine (isRecording, recordingWillBeStarted/Stopped, readyToRecordVideo/Audio) — moved intact, not redesigned; the redesign stays queued behind the single-owned-queue threading fix
• Per-frame writing and cropping, including the cached even-rounded crop rect for non-16:9 aspect ratios
• Saving/sending the finished movie (Photos library save, stop response, video resource transfer)

What stayed in the VC — and why

• The sample-buffer delegate role: captureOutput fans out to two consumers — frame streaming (live preview, not recording) and the recording path. The VC keeps the delegate and forwards recording frames to pipeline.processFrame; the audio delegate is passed into pipeline.startRecording(audioSampleBufferDelegate:) the same way PR 8 passes it into engine.setupCamera.
• The microphone-permission flow (prompt UI) — the pipeline is only invoked once permission is granted.
• Timer/progress overlays, preview layer, lifecycle — unchanged.

Seams

• sendMessage — a single actor relay for the start ack, stop response, and video resource. It captures the session ref (not the VC), carrying over PR 8's teardown-safety guarantee: an in-flight recording still reaches the actor if the VC deallocates. It also made the pipeline's no-op guards directly assertable (inject a recorder, assert nothing was sent).
• onRecordingStarted/Stopped (timer overlay), onModeChanged (idle vs recording chrome), onError, onPhotosAccessDenied.

Tests

385/385 green (381 existing + 4 new). The loopback video round-trips — including the 3-step stop protocol and the start-ack forwarding fixed in PR 8 — passed unchanged across the move, which is the point of the safety net.

New device-free RecordingPipelineTests:

• 4:3 video input setup caches the even-rounded crop rect (1920×1080 → 1440×1080 at x=240) and creates the adaptor — the "dimensions must be even for the codec" rounding had never been asserted anywhere
• 16:9 needs no crop rect and no adaptor
• Audio input setup from a bare format description
• Stop-while-idle is a strict no-op: no state change, no messages, no callbacks

Explicitly deferred (unchanged from the queued list)

Single owned serial queue (threading fix), RotationCoordinator (iOS 17) / maxPhotoDimensions (iOS 16) migrations, frame-streaming extraction, SwiftUI chrome (PR 10+).

🤖 Generated with Claude Code