Explain Tesla 2026.20 clip encryption instead of a generic corrupt-file error

[danielchalmers]

Why

Tesla software 2026.20 (released May 30, 2026) enables Encrypt Dashcam Recordings by default on Ryzen-infotainment vehicles — which includes every current model. The USB drive then holds AES-encrypted containers instead of MP4s, and the per-file keys are only obtainable from Tesla''s servers via the owner''s account (reverse-engineering write-up). The app can''t play that footage, but until now it also couldn''t say why: every chunk failed the moov probe, was auto-excluded by the builder, and the owner of a drive full of files saw "No front camera footage found."

What

• EncryptedClipDetector sniffs the first box header of each chunk''s front file. A clip whose files all have content but none starts with a known ISO-BMFF box type is flagged as encrypted. A merely corrupt or truncated recording still carries its ftyp header on at least some chunks, so ordinary corruption stays on the existing probe/recovery path.
• The two dead-end sites in VideoPlayerController (primary playlist missing after the builder excluded everything, and GiveUpOnClip) now show a message pointing at the in-car toggle (Controls > Safety > Encrypt Dashcam Recordings) and Tesla''s own viewer (dashcam.tesla.com).

Detection only — actually decrypting in-app would require Tesla account auth and posting file UUIDs to Tesla''s API, which is a separate product decision.

Verification

• 246 tests pass (10 net-new: header sniffing vs valid/truncated/garbage/missing files, clip-level all-vs-some semantics, and two end-to-end controller tests through the real ffconcat builder asserting the encrypted message and that truncated-but-headered files keep the ordinary message).
• Drove the built app against a synthetic clip of encryption-shaped files (20-byte header + IV-prefixed 4 KiB chunk): the error overlay shows the explanation with the toggle path and viewer link.