Skip to content

Ingest all camera angles, not a fixed four#65

Merged
danielchalmers merged 1 commit into
mainfrom
claude/2026-features-models-support-f8dfb8
Jul 9, 2026
Merged

Ingest all camera angles, not a fixed four#65
danielchalmers merged 1 commit into
mainfrom
claude/2026-features-models-support-f8dfb8

Conversation

@danielchalmers

Copy link
Copy Markdown
Owner

What & why

Tesla HW4/AI4 vehicles record two extra B-pillar cameras (left_pillar, right_pillar), and future firmware may add more. The filename parser already captured any suffix, but everything downstream looped a fixed four-camera list (CameraNames.All), so a fifth/sixth camera was silently dropped — discovered on disk, then thrown away.

This is P0 of the dynamic-camera work: ingest every camera and never crash. The extra angles are now parsed, kept, and have playback playlists built — surfacing them in the UI is a follow-up (P1).

Changes

  • Build playlists for the cameras actually present in a clip instead of the fixed CameraNames.All (FfconcatMediaSourceBuilder). The front camera still drives the shared timeline.
  • Canonicalize the legacy rear_view suffix to back at parse time (CamFile) so old and new clips share one vocabulary.
  • Fix a latent whole-folder-drop crash (CamChunk): a duplicate camera suffix at one timestamp used to throw in ToDictionary, and because CamClip.TryMap swallows exceptions, the entire clip folder silently vanished from the library. Now keep-first + log.
  • Add left_pillar/right_pillar to CameraNames.All.

Scope notes

  • UI still shows four cameras — the intended P0 interim. A HW4 owner's pillar footage is now ingested and playlist-built, just not yet displayed.
  • Front stays the timeline/required anchor. Generalizing to a "resolved primary" is deferred to P1, where the player pool changes too (zero practical gain now — front is universal on real Teslas).

Tests

235 pass, 0 failures (14 new; existing suite unchanged). New coverage:

  • 6-camera clip builds pillar playlists; HW3 4-camera clip builds exactly four with no pillars (missing pillars ≠ corruption).
  • Unknown suffix (front_bumper) still gets a playlist.
  • Duplicate suffix keeps-first without dropping the folder; CamChunk.Map retains pillar/unknown cameras.
  • rear_view canonicalizes to back at parse.

Verified against ehendrix23/tesla_dashcam: the six on-disk suffixes are front, back, left_repeater, right_repeater, left_pillar, right_pillar.

Tesla HW4/AI4 vehicles record two extra B-pillar cameras (left_pillar,
right_pillar), and future firmware may add more. The filename parser
already captured any suffix, but everything downstream looped a fixed
four-camera list, so a fifth/sixth camera was silently dropped.

- Build ffconcat playlists for the cameras actually present in a clip
  instead of CameraNames.All (front still drives the shared timeline).
- Canonicalize the legacy rear_view suffix to back at parse time so old
  and new clips share one vocabulary.
- Guard CamChunk's file map against a duplicate camera suffix at one
  timestamp: it used to throw in ToDictionary, and because CamClip.TryMap
  swallows that, the whole clip folder silently vanished from the library.
- Add left_pillar/right_pillar to CameraNames.All.

Cameras are ingested and their playlists built; surfacing the extra
angles in the UI is a follow-up. Front remains the timeline/required anchor.
@danielchalmers
danielchalmers merged commit b8d878a into main Jul 9, 2026
1 check passed
@danielchalmers
danielchalmers deleted the claude/2026-features-models-support-f8dfb8 branch July 9, 2026 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant