I wanted every crossing of the I-90 floating bridge in 240 drive folders of dashcam footage, 1,958 GB, for a montage. I wasn’t going to watch the footage to find them, and my Rivian R1T’s GPS was too coarse to. What found them was the color of the lights in the Mount Baker tunnel, which sits at the Seattle end of the bridge. Brightness couldn’t see that tunnel. A red/blue ratio found it on 71 of the 79 bridge drives scanned, and a person looking at one frame per candidate confirmed 68 crossings. How to sort months of dashcam footage with Claude Code has the rest of the job this was one stage of.

Signals instead of pixels

The footage already describes itself if you read the right parts of it. Each 15-minute segment carries one GPS fix, at its start, in the container’s location tag. That sorts drives by area, but one fix per 15 minutes can’t place a bridge crossing to the minute, let alone the second.

The finer signal is in the keyframes. The truck writes one keyframe per second. Decoding only those, downscaled to 64 × 48, gives a per-second record of a drive and skips the 29 frames between them. Each second becomes four numbers: the mean change in green from the previous keyframe, which I called motion, and the mean red, green and blue. That record was computed once, cached as CSV, and every detector afterward read the cache instead of the video.

The first calibration read a motion of zero everywhere, parked or moving. The cause was ffmpeg duplicating the keyframes back up to 30 fps, so every frame was compared with a copy of itself. -fps_mode passthrough fixed it. The bug showed up only because the check ran on a known parked segment and a known moving one before it ran on anything else. A detector that reads zero on both cases is measuring itself.

Why brightness failed

A tunnel should be the easiest thing in a drive to find: the outside goes away and the picture gets darker. In this footage it doesn’t get darker. The camera’s auto-exposure raises the gain as the light drops and holds the frame’s brightness close to what it was in daylight. That’s what the exposure control is for, and it erases the one property a brightness threshold depends on.

Why color worked

Exposure scales brightness, and the hue of the lamps comes through. The Mount Baker tunnel is lit by sodium lamps, and sodium light is orange. Inside the tunnel, the front camera’s mean red rises above its mean blue. That ratio is the whole detector.

It runs with three guards:

• The red/blue ratio has to stay above 1.0 for 25–150 seconds, so a single orange frame or a long orange stretch doesn’t count.
• A rolling median smooths the ratio first, so one bright frame inside a tunnel doesn’t break the run in two.
• The first and last 3 minutes of every drive are ignored, because parking garages look the same to the ratio.

On the 79 bridge drives scanned, it found a tunnel on 71. Seven of the eight misses were after dark. My reading is that the ratio describes light, and once the light outside is artificial too, a tunnel stops standing out from the road around it.

Detector proposes, person confirms

Finding a tunnel isn’t the same as finding the right one. A drive on I-90 passes more than one stretch that reads as a tunnel, including the Mercer Island lid, and most drives had several candidates. The obvious rule, pick one tunnel by its position in the drive, was right about two times in three.

I could have spent the effort on a better rule. Instead the tool writes a guess for every drive and a contact sheet to check it against, then stops. Each row of the sheet is one drive, and each tile is a frame from the bridge side of one candidate. The bridge is unmistakable in a frame, so the right column is obvious, and the edit is one number in a picks file, which the cut turns into synced clips. Reviewing that way confirmed 68 crossings. Two night drives couldn’t be confirmed, because a dark frame of a dark bridge proves nothing, and one drive had no crossing among its candidates.

The layout of the sheet mattered as much as having one. The first version was a flat grid of every candidate frame, and it was easy to match a tile to the wrong drive. One row per drive makes that mistake visible rather than merely possible.

The sheet is also an instrument, and an instrument can be wrong. At one point I announced that the picks for some drives were the Mercer Island lid, not the Mount Baker tunnel. The sheets had been built with a seek that ffmpeg applied after tiling, so they showed a different window than the one they claimed. Extracting the same frame two ways exposed it, and the picks had been right all along. When a result contradicts work that was already verified, check the instrument before the conclusion.

The review step reads like an admission that the detector wasn’t good enough. I think it’s the reason the detector could stay simple. Take a rule that’s right two times in three, and add a sheet a person reads at a glance. That beats a rule that’s right more often and still needs someone to check it.

Signals that could not separate the cases

The same per-second record answered four other questions, and each answer was no for the same reason: the signal moved for the thing I wanted and for something I didn’t.

• Parked footage. Near-zero motion found parked time reliably, but there was little to find: 23 GB of the 1,760 GB scanned, because with Gear Guard turned off, the truck stops recording seconds after it parks.
• Hard stops. A sudden change in the picture marks braking, but turning changes the picture as much. Of 875 candidates, all 12 at the top were turns into parking lots or ordinary stops.
• Traffic jams. Sustained low motion should mark crawling traffic, but the neighboring cars keep moving, so the picture keeps changing and a jam looks like driving.
• Garage boundaries. A gray band at the top of the frame marks a concrete ceiling on a clear day, but an overcast sky is the same gray. The boundary was set by timing instead.

None of these is fixed by tuning a threshold. When a signal can’t tell two cases apart, a better number for the threshold still can’t.

Close passes did work once the frame’s overall brightness change was subtracted from the side cameras: 37 of the top 60 were real passes. A person still had to sort them.

Signals the camera leaves alone

A camera processes its own picture before anything reads it, and that processing exists to make the picture look normal. Auto-exposure made a tunnel look like daylight and left the lamp color intact. Before measuring anything in recorded video, ask which properties the camera flattens and which it passes through, and build on the second kind.

TL;DR

When a video has one keyframe per second, decode only the keyframes and give each one a frame at 30 fps. The result plays 30 times faster than the drive:

$ ffmpeg -skip_frame nokey -i <clip>.mp4 -vf "setpts=N/(30*TB)" -r 30 \
    -map_metadata -1 -c:v hevc_videotoolbox -q:v 65 -tag:v hvc1 \
    -color_range pc -an <clip>_30x.mp4

-skip_frame nokey goes before -i, because it tells the decoder to discard every frame that isn’t a keyframe. setpts=N/(30*TB) gives frame N the timestamp N/30 seconds, so one second of driving becomes one frame of output.

To keep several cameras in sync, render each recording segment separately, pad every camera’s segment with black to the front camera’s length, and join the segments with a stream copy. The script later in this article does that.

A Rivian R1T films five directions for as long as it’s driven. I wanted a hyperlapse of every drive from a summer of footage, one file per camera, so a drive could be cut as a multi-camera edit at 30× speed. An ordinary hyperlapse decodes 30 frames to keep one, and this footage didn’t need that: the truck writes one keyframe every second. Reading only those, a 36-minute drive became 72 seconds of video and took 4.4 minutes to render, with one drive rendering at a time. The hyperlapses for 218 drives, five cameras each, came to 107 GB.

This is part of a series about reading dashcam video without watching it. How to sort months of dashcam footage with Claude Code is the hub, with the prompts and the checks that drove the whole job.

Why keyframes are enough

The Rivian’s clips are H.264 at 30 fps with I- and P-frames only, and one keyframe (an I-frame) every second. A keyframe decodes on its own. A P-frame needs the frames before it, so taking every 30th frame of an ordinary decode still means decoding the other 29.

With -skip_frame nokey the decoder drops the P-frames before decoding them. What reaches the filter is one picture per second of driving, already spaced evenly in time. The setpts=N/(30*TB) filter discards their timestamps and numbers them off at 30 per second. N is the frame’s index and TB is the stream’s time base. Without setpts, the output has the same frames, each still held for a second, and plays at the speed of the drive.

The speed this produces is fixed by the footage: one keyframe per second, shown at 30 fps, is 30×. Footage with a keyframe every two seconds would come out at 60× from the same command.

Check the keyframe rhythm

Before relying on it, count the keyframes in one clip. In a terminal, run:

$ ffprobe -v error -skip_frame nokey -select_streams v \
    -show_entries frame=pts_time -of csv=p=0 <clip>.mp4 | head -3

0.000000
1.000000
2.000000

Pipe the same command to wc -l instead of head for the count. On a 351-second clip it printed 351, and a full 15-minute segment from the truck has 900. On some drives one camera’s keyframes fall at 0.967 s past each second rather than on it, and which camera varies by drive. The spacing is still one second, which is what the speed depends on.

If the times are not one second apart, the hyperlapse still renders, but its speed is the keyframe interval times 30 rather than 30×.

Render one clip

In the folder that holds the clip, run:

$ ffmpeg -nostdin -v error -skip_frame nokey -i <clip>.mp4 \
    -vf "setpts=N/(30*TB)" -r 30 -map_metadata -1 \
    -c:v hevc_videotoolbox -q:v 65 -tag:v hvc1 \
    -color_range pc -an <clip>_30x.mp4

It writes <clip>_30x.mp4 beside the source and changes nothing else. On a 351-second clip of a bridge crossing, the output was 351 frames and 11.7 seconds long, 11.2 MB from a 438.8 MB source.

The encoder options are the part to change on another machine:

• hevc_videotoolbox is the Mac’s hardware HEVC encoder. The Homebrew build of ffmpeg used here includes it; ffmpeg -encoders | grep videotoolbox lists it if yours does.
• -q:v 65 asks it for constant quality rather than a bitrate.
• -tag:v hvc1 labels the HEVC stream the way QuickTime and Apple’s players expect.
• -color_range pc labels the output full range like the footage, which the black filler and the join depend on. Apple’s encoder ignores -pix_fmt yuvj420p with a warning, so it isn’t set here.
• -map_metadata -1 drops the source’s tags, including its GPS fix.
• -an writes no audio track. The truck records none.

Pad each segment to the front camera’s length

The truck splits a drive into 15-minute segments, one file per camera per segment. All five cameras’ files for a segment have the same length, unless a camera stopped recording. If one did, that camera’s segment has fewer keyframes, its hyperlapse has fewer frames, and every later frame of that angle plays early. A camera that is missing a whole segment is worse.

When I first rendered every camera of one drive, two came out at 1,303 frames against the front camera’s 2,170. The rear camera had stopped 33 seconds into a segment and recorded the rest of the drive in a sibling folder.

Pad every camera’s segment to the front camera’s frame count with black, so each segment ends at the same frame on every camera. The numbers in these steps are an example, a 351-keyframe front segment and a camera that stopped 33 seconds in:

1. Count the front camera’s keyframes for the segment, as in the first step. On a 351-second segment, that’s 351.

2. Count the other camera’s keyframes for the same segment. A clip that stopped 33 seconds in has 33.

3. Render that camera’s segment with tpad adding the difference as black frames, and -frames:v capping it at the front camera’s count:

   Command

   $ ffmpeg -nostdin -v error -skip_frame nokey -i <rear-segment>.mp4 \
       -vf "setpts=N/(30*TB),tpad=stop=318:color=black" -r 30 -frames:v 351 \
       -map_metadata -1 -c:v hevc_videotoolbox -q:v 65 -tag:v hvc1 \
       -color_range pc -an <rear-segment>_30x.mp4

The -frames:v cap also trims a camera that recorded slightly longer than the front one.

Fill a missing segment with full-range black

When a camera has no file at all for a segment, render a black part of the same size and frame count. The front, rear and side cameras are 1920 × 1536; the Gear Guard bed camera is 1280 × 720.

$ ffmpeg -nostdin -v error -f lavfi -i "color=black:s=1920x1536:r=30" \
    -frames:v 351 -map_metadata -1 -c:v hevc_videotoolbox -q:v 65 -tag:v hvc1 \
    -color_range pc -an <missing-segment>_30x.mp4

The filler must be full range, the same as the footage. -color_range pc is what makes it so: without it, generated black came out labeled limited range (tv), and -pix_fmt yuvj420p doesn’t help, because Apple’s encoder ignores it. The decoded footage is already full range, so the same options are safe on every part.

A mismatch doesn’t make the next step fail. The join is a stream copy, which converts nothing, and the joined file takes its range label from the first part. A camera whose file opens on limited-range filler is labeled limited range throughout, real footage included. That happened to 11 of the more than a thousand hyperlapse files in my batch, all in folders that held only a fragment of a drive, and they had to be rendered again. The script checks each part’s range before joining, because the joined file shows only the first part’s.

Join the segments without re-encoding

List the parts in order in a text file, one file line each, then join them with the concat demuxer and a stream copy:

$ printf "file '%s'\n" <part-001>.mp4 <part-002>.mp4 > list.txt
$ ffmpeg -nostdin -v error -f concat -safe 0 -i list.txt -c copy <camera>_30x.mp4

Every part was encoded with the same options, so the copy only rewrites the container. It takes seconds.

Script the whole drive

The steps combine into one script per camera. It reads the segment list from the front camera’s files, so a camera missing a segment gets black filler for it. The macOS ._ files beside the clips on the truck’s exFAT drive don’t match its pattern, so they’re skipped. The front camera sets every segment’s length, so all five files come out the same length.

#!/usr/bin/env bash
set -euo pipefail

folder=$1
camera=$2
size=${3:-1920x1536}
name=$(basename "$folder")
encode=(-map_metadata -1 -c:v hevc_videotoolbox -q:v 65 -tag:v hvc1
        -color_range pc -an)

keyframes() {
  ffprobe -v error -skip_frame nokey -select_streams v \
    -show_entries frame=pts_time -of csv=p=0 "$1" | wc -l | tr -d ' '
}

work=$(mktemp -d)
: > "$work/list.txt"

for front in "$folder/${name}_frontCenter_"*.mp4; do
  segment=${front##*_}
  frames=$(keyframes "$front")
  source="$folder/${name}_${camera}_${segment}"
  part="$work/$segment"

  if [[ -f $source ]]; then
    shortfall=$(( frames - $(keyframes "$source") ))
    if (( shortfall < 0 )); then shortfall=0; fi
    ffmpeg -nostdin -v error -skip_frame nokey -i "$source" \
      -vf "setpts=N/(30*TB),tpad=stop=${shortfall}:color=black" -r 30 \
      -frames:v "$frames" "${encode[@]}" "$part"
  else
    ffmpeg -nostdin -v error -f lavfi -i "color=black:s=${size}:r=30" \
      -frames:v "$frames" "${encode[@]}" "$part"
  fi
  range=$(ffprobe -v error -select_streams v -show_entries stream=color_range \
    -of csv=p=0 "$part")
  if [[ $range != pc ]]; then
    echo "$part: color_range=$range, expected pc" >&2
    exit 1
  fi
  echo "file '$part'" >> "$work/list.txt"
done

ffmpeg -nostdin -v error -f concat -safe 0 -i "$work/list.txt" \
  -c copy "${name}_${camera}_30x.mp4"
rm -r "$work"

It writes <drive>_<camera>_30x.mp4 in the current folder. Run it once per camera, from the folder where the hyperlapses belong, and pass 1280x720 as the third argument for the Gear Guard camera:

$ for camera in frontCenter rearCenter sideLeft sideRight; do \
    bash hyperlapse.sh <drive-folder> "$camera"; done
$ bash hyperlapse.sh <drive-folder> gearGuard 1280x720

The script assumes the front camera recorded every segment. If it didn’t, the segment is missing from every camera’s hyperlapse.

Confirm every camera has the same frame count

Same length is the whole point of the padding, so count the frames in each output, and read the pixel format while you’re there:

$ for f in *_30x.mp4; do echo "$f $(ffprobe -v error -select_streams v \
    -count_packets -of compact=p=0 \
    -show_entries stream=nb_read_packets,pix_fmt,color_range "$f")"; done

<drive>_frontCenter_30x.mp4 pix_fmt=yuvj420p|color_range=pc|nb_read_packets=351
<drive>_gearGuard_30x.mp4 pix_fmt=yuvj420p|color_range=pc|nb_read_packets=351
<drive>_rearCenter_30x.mp4 pix_fmt=yuvj420p|color_range=pc|nb_read_packets=351
<drive>_sideLeft_30x.mp4 pix_fmt=yuvj420p|color_range=pc|nb_read_packets=351
<drive>_sideRight_30x.mp4 pix_fmt=yuvj420p|color_range=pc|nb_read_packets=351

Every camera of a drive prints the same count, and every file prints yuvj420p and pc. A camera with fewer frames was not padded. The range here is only the first part’s, because a stream-copy join takes its label from the first part, so the script checks every part’s range before it joins them and stops on one that isn’t pc.

Remove the location before publishing

A hyperlapse runs from the start of a drive to its end. Trim both ends before you publish one, too.

Keyframes vs a setpts timelapse of every frame

Reading only keyframes is what makes this fast, and it fixes what the hyperlapse can be.

On the same 351-second clip, I rendered the 30× hyperlapse twice: once from keyframes, and once by decoding every frame and keeping every 30th with select='not(mod(n,30))'. Both came out at 351 frames. The keyframe render took 4.4 seconds and used about one CPU core. The full decode finished in 7.0 seconds only because it spread across the cores: it used 57 seconds of CPU time, roughly 13 times the work. On one clip that’s a few seconds of waiting. Across a batch of drives, the CPU time is what adds up.

What the full decode buys you is choice:

For dashcam footage with a steady one-second keyframe, 30× was the speed I wanted, so keyframes were the right choice. If the speed has to be something else, decode everything and accept the cost.

The same -skip_frame nokey read is the cheap way to analyze footage, not only to watch it. When you extract keyframes as raw frames rather than encoding a video, add -fps_mode passthrough. Without it, ffmpeg duplicates each keyframe back up to 30 fps, and every frame-to-frame difference you compute reads zero.

TL;DR

Cut each camera with one pass of ffmpeg’s concat demuxer over its source segments, with -c copy. In the listing, set the first inpoint to that camera’s own keyframe at or before the moment you want, not to the moment itself:

file '<drive-folder>/07_16_26_120000_sideLeft_002.mp4'
inpoint 889.966667
outpoint 900
file '<drive-folder>/07_16_26_120000_sideLeft_003.mp4'
inpoint 0
outpoint 30

$ ffmpeg -f concat -safe 0 -i sideLeft.txt -c copy sideLeft.mp4

Snapping makes an offset camera’s file start a few frames early. Confirm that every file has a start_time of 0 and the same number of frames plus that lead. In DaVinci Resolve, set each clip’s In point that many frames in, then build the multicam with the angles synced by In point.

I wanted the same few minutes of a drive, the crossing of the I-90 floating bridge, from all five cameras of a Rivian R1T, as five files for a multicam edit. Re-encoding five streams to get exact cuts costs time and picture quality, so the cut is a stream copy. A stream copy is exact only where the source allows it. My first three attempts came out of sync, and each failure is the reason for one step in the procedure.

How the truck records

The truck writes one folder per drive, named MM_DD_YY_HHMMSS in local time. It holds one file per camera per 15-minute segment, <drive>_<camera>_<NNN>.mp4, and every segment except the last runs 900 s. The cameras are frontCenter, rearCenter, sideLeft, sideRight, and gearGuard.

Three properties of the files decide how they can be cut and synced:

• The video is H.264 at 30 fps, with I-frames and P-frames only and one keyframe per second.
• The files have no audio track and no timecode track.
• All five cameras of a segment have the same 900 s duration; their creation_time can differ by a couple of seconds, so it can’t sync them.

With no audio and no timecode, an editor has nothing to sync the angles on but each file’s first frame. The cut has to start every camera on a known frame, so the edit can line the first frames up.

Why stream-copied cameras drift

A stream copy can’t start a file on a P-frame, because a P-frame is stored as a difference from earlier frames that the new file won’t contain. It starts on a keyframe. Two details of this footage turn that rule into drift:

• Keyframes don’t fall at the same instant on every camera. On most cameras they fall on whole seconds. On some drives, one or more cameras put them 0.967 s after each second, one frame before the next whole second.
• Some cameras’ groups of pictures run across segment files. A segment can open with frames that come before its first keyframe. Those frames reference frames at the end of the previous file.

Each attempt that failed ran into one of these, and the checks in the last step of the procedure catch each one:

Equal durations aren’t enough. Two files can be the same length and still start at different moments, so the checks look at frame counts and at start_time together.

Find the segments the window touches

Express the window in seconds from the start of the drive. Segment NNN covers drive seconds (NNN − 1) × 900 to NNN × 900. The examples here use a window chosen to straddle a join, because that’s where a cut goes wrong: from 1790 to 1830 s, it touches two segments:

Every segment after the first starts at inpoint 0, and every segment before the last ends at outpoint 900. Only the first segment’s in-point is snapped.

Find each camera’s keyframe at the in-point

Each camera writes a keyframe about once a second, but not at the same fraction of a second as the others, and not always at the same fraction for a whole segment. On one drive, the Gear Guard camera’s keyframes start on whole seconds and slip to whole seconds plus 0.933 by the end of the segment:

$ ffprobe -v error -select_streams v -skip_frame nokey \
>   -show_entries frame=pts_time -of csv=p=0 -read_intervals %+3 \
>   08_02_26_120000_gearGuard_001.mp4

0.000000
1.000000
1.966667
2.966667

$ ffprobe -v error -select_streams v -skip_frame nokey \
>   -show_entries frame=pts_time -of csv=p=0 -read_intervals 887%+3.001 \
>   08_02_26_120000_gearGuard_001.mp4

887.933333
888.933333
889.933333

Across the drives I checked, keyframes sat on whole seconds or at whole seconds plus anything from 0.733 to 0.967, and most cameras that weren’t on whole seconds drifted within a segment. Which camera is offset, and by how much, changes from drive to drive. Test your own footage rather than assuming any of these numbers: list the keyframes in the 3 seconds before the in-point, in the segment that contains it, for every camera.

Snap the in-point to the camera’s own keyframe

For each camera, move the first in-point back to the latest keyframe at or before it, from the listing near the in-point. On the drive above, 890 becomes 889.933333 for the Gear Guard camera and stays 890 for the others. Measuring the offset at the start of the segment and applying it at 890 would give 889.966667, which is after the real keyframe.

Snap in drive time, not segment time. When the in-point falls before the first keyframe of its segment, start on the last keyframe of the previous segment, because the first frames of a segment reference the tail of the one before it. Only at the start of a drive, with nothing before it, does such an in-point become 0.

Rounding back rather than forward is the point. On the drive these examples come from, a stream copy given 890 on the offset side-left camera started at its next keyframe, 890.967, so the file opened 0.967 s late and carried that as its start_time. Given 889.966667, its keyframe there, it started on the keyframe exactly, at time 0. The snapped camera’s first frames come before the other cameras’ first frame, by the gap between its keyframe and the in-point: 1 frame at 0.967, 8 frames at 0.733. A stream copy can’t remove them, so the edit does: set that clip’s In point that many frames in.

Write one concat listing per camera

Write a listing for each camera with one file, inpoint, and outpoint entry per segment. <drive-folder> stands for the drive folder’s absolute path, which is why the cut later needs -safe 0:

file '<drive-folder>/07_16_26_120000_sideLeft_002.mp4'
inpoint 889.966667
outpoint 900
file '<drive-folder>/07_16_26_120000_sideLeft_003.mp4'
inpoint 0
outpoint 30

One listing for both segments is what keeps the frames after the join. The concat demuxer reads segment 003 straight after the tail of 002, so the frames at the start of 003 that reference 002 still have their reference. Cutting 003 on its own drops them, and joining the two pieces afterwards can’t bring them back.

Cut each camera with a stream copy

Run the concat demuxer once per camera. This writes a new file and leaves the source segments untouched:

$ ffmpeg -f concat -safe 0 -i 07_16_26_120000_sideLeft.txt \
>   -c copy 07_16_26_120000_sideLeft.mp4

The following script does the last four steps for all five cameras. It takes the drive folder, the window’s start and end in drive seconds, and an output folder, and writes each camera’s listing and clip there:

#!/bin/bash
set -euo pipefail
folder=$(cd "$1" && pwd) start=$2 end=$3 out=$4
drive=$(basename "$folder")
segment_seconds=900
mkdir -p "$out"

# Stop with the camera and the file named, rather than ffprobe's bare error.
require() {
  if [[ ! -f $1 ]]; then
    echo "$camera: no file $(basename "$1")" >&2
    exit 1
  fi
}

# Print the latest keyframe at or before $3 seconds into file $1, looking back
# $2 seconds; print nothing if there is none in that span.
keyframe_at_or_before() {
  local file=$1 back=$2 at=$3 from
  from=$(awk -v a="$at" -v b="$back" 'BEGIN { f = a - b; if (f < 0) f = 0; print f }')
  ffprobe -v error -select_streams v -skip_frame nokey \
    -show_entries frame=pts_time -of csv=p=0 \
    -read_intervals "${from}%$(awk -v a="$at" 'BEGIN { print a + 0.001 }')" "$file" |
    cut -d, -f1 | awk -v a="$at" -v f="$from" \
      '$1 >= f - 0.0005 && $1 <= a + 0.0005 { k = $1 } END { if (k != "") print k }'
}

for camera in frontCenter rearCenter sideLeft sideRight gearGuard; do
  segment=$(( start / segment_seconds + 1 ))
  local_in=$(( start - (segment - 1) * segment_seconds ))
  file="$folder/${drive}_${camera}_$(printf '%03d' "$segment").mp4"
  require "$file"
  length=$(ffprobe -v error -show_entries format=duration -of csv=p=0 "$file")
  if awk -v l="$length" -v i="$local_in" 'BEGIN { exit !(l <= i) }'; then
    echo "$camera: $(basename "$file") ends before ${local_in}s" >&2
    exit 1
  fi
  keyframe=$(keyframe_at_or_before "$file" 3 "$local_in")
  if [[ -n $keyframe ]]; then
    snapped=$(awk -v k="$keyframe" -v b=$(( (segment - 1) * segment_seconds )) \
      'BEGIN { printf "%.6f", b + k }')
  elif (( local_in >= 3 )); then
    # No keyframe this far into the segment means the file ends before it.
    echo "$camera: $(basename "$file") ends before ${local_in}s" >&2
    exit 1
  elif (( segment > 1 )); then
    # The in-point falls before this segment's first keyframe, so the frames
    # there depend on the previous segment: start on its last keyframe.
    previous="$folder/${drive}_${camera}_$(printf '%03d' $(( segment - 1 ))).mp4"
    require "$previous"
    keyframe=$(keyframe_at_or_before "$previous" 3 "$segment_seconds")
    if [[ -z $keyframe ]]; then
      echo "$camera: segment $(( segment - 1 )) ends early" >&2
      exit 1
    fi
    snapped=$(awk -v k="$keyframe" -v b=$(( (segment - 2) * segment_seconds )) \
      'BEGIN { printf "%.6f", b + k }')
  else
    snapped=0
  fi
  echo "$camera starts $(awk -v s="$snapped" -v a="$start" \
    'BEGIN { printf "%d", (a - s) * 30 + 0.5 }') frames early"
  first=$(awk -v s="$snapped" -v n="$segment_seconds" 'BEGIN { print int(s / n) + 1 }')
  last=$(( (end - 1) / segment_seconds + 1 ))
  listing="$out/${drive}_${camera}.txt"
  : > "$listing"
  for (( segment = first; segment <= last; segment++ )); do
    source="$folder/${drive}_${camera}_$(printf '%03d' "$segment").mp4"
    require "$source"
    segment_start=$(( (segment - 1) * segment_seconds ))
    clip_in=0
    (( segment == first )) && clip_in=$(awk -v s="$snapped" \
      -v b="$segment_start" 'BEGIN { printf "%.6f", s - b }')
    clip_out=$(( end - segment_start ))
    (( clip_out > segment_seconds )) && clip_out=$segment_seconds
    length=$(ffprobe -v error -show_entries format=duration -of csv=p=0 "$source")
    if awk -v l="$length" -v o="$clip_out" 'BEGIN { exit !(l < o - 0.05) }'; then
      echo "$camera: $(basename "$source") ends before ${clip_out}s" >&2
      exit 1
    fi
    printf "file '%s'\ninpoint %s\noutpoint %s\n" \
      "$source" "$clip_in" "$clip_out" >> "$listing"
  done
  ffmpeg -nostdin -v error -f concat -safe 0 -i "$listing" \
    -c copy "$out/${drive}_${camera}.mp4"
done

$ bash cut-window.sh <drive-folder> 1790 1830 cuts

For each camera, the script prints how many frames before the window’s start its file begins: 0 for a camera with a keyframe on the start, more for an offset one. Keep that list for the edit.

If a camera has no file for a segment the window touches, or its file ends before the window does, the script stops and names the camera and the file rather than writing a short clip. The camera usually restarted into a sibling folder partway through the drive.

Verify the start and frame count of every camera

In the output folder, print each file’s start_time, the number of frames that decode, and the number of packets in the file:

$ for clip in *.mp4; do
>   printf '%s ' "$clip"
>   ffprobe -v error -select_streams v -count_frames -count_packets \
>     -show_entries stream=start_time,nb_read_frames,nb_read_packets \
>     -of csv=p=0 "$clip"
> done

07_16_26_120000_frontCenter.mp4 0.000000,1200,1200
07_16_26_120000_gearGuard.mp4 0.000000,1200,1200
07_16_26_120000_rearCenter.mp4 0.000000,1201,1201
07_16_26_120000_sideLeft.mp4 0.000000,1201,1201
07_16_26_120000_sideRight.mp4 0.000000,1200,1200

The cut is good when all three hold:

Start

Every file’s start_time, the first column, is 0.000000.

Length

The frame counts differ only by each camera’s lead, the frames the script reported it starts early.

Join

The decoded frames equal the packets on every file, so every frame after the segment join decoded.

The third check is the one that sees the join. -count_frames decodes the whole file and counts only the frames that decoded; a frame whose reference is missing is dropped without an error. The same command on the source segment 003 on its own, outside the concat pass, shows the frames that depend on 002:

$ ffprobe -v error -select_streams v -count_frames -count_packets \
>   -show_entries stream=nb_read_frames,nb_read_packets -of csv=p=0 \
>   07_16_26_120000_sideLeft_003.mp4

26971,27000

Those 29 frames are the ones a per-segment cut loses. Decoding with ffmpeg -v error … -f null - prints nothing for them, so a silent decode is not evidence of a clean join. Compare the counts.

Build the multicam clip

In DaVinci Resolve, the leads the script printed are the only alignment the five files need:

1. Import the five files into the Media Pool.
2. For each camera with a lead, open its file in the source viewer, step forward that many frames from the first, and mark an In point.
3. Select all five, right-click, and choose Create New Multicam Clip Using Selected Clips.
4. Set Angle Sync to In.
5. Create the multicam clip, and put it on a timeline.
6. Switch the Edit page’s source viewer to Multicam and cut between angles during playback.

In lines up each file’s In point, which is its first frame unless you mark one. The other sync methods need something these files don’t carry: Timecode needs a timecode track and Sound needs audio. A file whose first frame is 0.967 s later than the others’ is 0.967 s out of sync after an In-point sync, whatever its start_time says. That’s why the verification step checks the start before the files reach Resolve.

Check each clip for a location before you share it

The concat demuxer drops the truck’s GPS fix, but other ways of cutting keep it; Read the GPS location from Rivian dashcam video with ffprobe covers which. Check the file you’re about to share:

$ exiftool -G1 -a "-gps*" "-location*" 07_16_26_120000_sideLeft.mp4

Empty output means no location field was found.

TL;DR

The camera didn’t stop recording. It restarted seconds later into a new drive folder that holds only the restarted cameras. Look for a folder named a few seconds after the broken one, with fewer than five cameras in it.

Don’t take the offset from the two folder names. Measure it by correlating the motion of two cameras that face the same way, such as the Gear Guard camera and the rear camera. Then re-encode the restarted cameras from the sibling folder at that offset, so that they start on the exact frame.

I cut a five-camera clip from a drive on August 7 and dropped it into a multicam timeline. Three angles played to the end. The rear camera and the side-left camera went black after 33 seconds. Every file was readable and nothing reported an error. The footage I thought was lost was in the next folder.

Rear or side camera stopped recording after a few seconds

The symptom has a few forms, depending on what you build from the drive:

• A camera’s only file in the drive folder is a few seconds long, while the other cameras have a full set of 15-minute segments.
• A multicam clip or a grid of the five cameras shows black tiles for one or two angles for most of the drive.
• A hyperlapse of one angle is much shorter than the others, or ends in black.

On the August 7 drive, the folder 08_07_26_140000 holds full segments for the front, Gear Guard and side-right cameras, and one 33-second file each for the rear and side-left cameras:

$ ffprobe -v error -show_entries format=duration -of csv=p=0 \
    08_07_26_140000/08_07_26_140000_rearCenter_001.mp4

33.000000

Cause: the camera restarted into a sibling folder

The truck writes one folder per drive, named MM_DD_YY_HHMMSS in local time, and one file per camera per 15-minute segment inside it. When a camera stops and restarts partway through a drive, its recording doesn’t continue in the drive’s folder. A new folder is created a few seconds later, and it holds only the cameras that restarted. The rest of the drive stays in the original folder.

The two folders together hold the whole drive. Nothing was lost, but the drive is now split across two clocks.

Find the sibling folder

Run this in the DriveStream folder of the truck’s drive, or of your copy of it. It prints each drive folder with the cameras it holds:

for d in */; do
  printf '%s ' "${d%/}"
  ls "$d" | grep -v '^\._' \
    | sed -E 's/^[0-9_]+_([A-Za-z]+)_[0-9]{3}\.mp4$/\1/' \
    | sort -u | tr '\n' ' '
  echo
done

The grep -v '^\._' drops the AppleDouble files that macOS leaves beside every clip on the truck’s exFAT drive. The August 7 folders look like this:

08_07_26_100000 frontCenter gearGuard rearCenter sideLeft sideRight
08_07_26_140000 frontCenter gearGuard rearCenter sideLeft sideRight
08_07_26_140034 rearCenter sideLeft
08_07_26_160000 frontCenter gearGuard rearCenter sideLeft sideRight

A sibling folder has all three of these properties:

• Its name is seconds, not minutes, after the previous folder’s name.
• It holds fewer than five cameras.
• Its cameras are the ones that stop early in the previous folder.

A short folder with one camera and no partner is a different case: a stray fragment, not half of a drive. Across 233 drive folders, one was a 21-second fragment from a single camera.

Folder name offset is wrong

The folder names differ by 34 seconds, so the obvious fix is to place the restarted cameras 34 seconds into the drive. Measured from the footage, the restarted cameras begin 32.7 seconds into the drive. The names are wrong by more than a second. The files’ creation_time tags are no better: the two folders' differ by 35 seconds, a third answer.

A folder name is a label, not a clock: nothing ties it to the first frame of the video inside. An error of more than a second is visible in a multicam edit. A car that passes the truck crosses the rear view and the side view at moments that no longer match. The truck’s files carry no timecode track to correct it, so the offset has to come from the pictures.

Measure the offset by motion correlation

Two cameras that see the same scene change at the same moments. When the truck hits a bump or a car passes behind it, both backward-facing pictures move at once. The script reduces each camera to a motion signal and slides one signal along the other until they match best:

1. Decode a window of each clip at a fixed sample rate, scaled to a tiny grayscale frame.
2. Take the mean absolute change between consecutive frames. That’s the motion signal: high when the picture changes, low when it holds still.
3. Standardize the reference, and each stretch of the other signal it’s compared with, so that a brighter or busier camera or stretch doesn’t outweigh the rest.
4. Try every lag within a search range around your guess, and keep the lag with the highest correlation.

It needs Python 3 and ffmpeg on your path, and nothing else:

"""Measure the time offset between two dashcam clips by correlating their motion.

Usage:
    python3 measure_offset.py REFERENCE OTHER --at SECONDS [--guess SECONDS]

Reads a window of REFERENCE starting at --at, and a slightly wider window of
OTHER around --at minus --guess. Prints the offset that lines the two up:
a moment at time t in REFERENCE is at time t - offset in OTHER.
"""
import argparse
import subprocess

WIDTH, HEIGHT = 32, 24
SAMPLES_PER_SECOND = 10


def motion(clip: str, start: float, seconds: float) -> list[float]:
    """Mean absolute change between consecutive tiny grayscale frames."""
    raw = subprocess.run(
        ["ffmpeg", "-nostdin", "-v", "error",
         "-ss", f"{start:.3f}", "-t", f"{seconds:.3f}", "-i", clip,
         "-vf", f"fps={SAMPLES_PER_SECOND},scale={WIDTH}:{HEIGHT},format=gray",
         "-f", "rawvideo", "-"],
        capture_output=True, check=True,
    ).stdout
    size = WIDTH * HEIGHT
    frames = [raw[i:i + size] for i in range(0, len(raw) - size + 1, size)]
    return [sum(abs(a - b) for a, b in zip(before, after)) / size
            for before, after in zip(frames, frames[1:])]


def standardize(values: list[float]) -> list[float]:
    mean = sum(values) / len(values)
    variance = sum((v - mean) ** 2 for v in values) / len(values)
    spread = variance ** 0.5 or 1.0
    return [(v - mean) / spread for v in values]


def best_lag(reference: list[float], other: list[float]) -> tuple[float, int]:
    """Slide reference along other; return the best correlation and its lag."""
    scores = []
    for lag in range(len(other) - len(reference) + 1):
        window = standardize(other[lag:lag + len(reference)])
        score = sum(a * b for a, b in zip(reference, window)) / len(reference)
        scores.append((score, lag))
    return max(scores)


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("reference")
    parser.add_argument("other")
    parser.add_argument("--at", type=float, required=True,
                        help="window start in REFERENCE, seconds")
    parser.add_argument("--guess", type=float, default=0.0,
                        help="expected offset, seconds")
    parser.add_argument("--length", type=float, default=120.0,
                        help="window length, seconds")
    parser.add_argument("--search", type=float, default=5.0,
                        help="how far either side of the guess to look")
    args = parser.parse_args()

    reference = standardize(motion(args.reference, args.at, args.length))
    # The other window starts --search seconds early, so lag 0 means guess + search.
    other_start = args.at - args.guess - args.search
    other_length = args.length + 2 * args.search
    other = motion(args.other, other_start, other_length)

    score, lag = best_lag(reference, other)
    offset = args.guess + args.search - lag / SAMPLES_PER_SECOND
    print(f"window at {args.at:g} s: correlation {score:.2f}, offset {offset:+.1f} s")


if __name__ == "__main__":
    main()

Give it a camera from the original folder as the reference, a camera from the sibling folder as the other, and the folder-name difference as the guess. Both folders number their segments from 001 and every segment but the last runs 900 seconds, so segment 002 of the sibling starts the same offset after segment 002 of the original. Compare files with the same segment number, and keep the window inside one segment.

In the DriveStream folder, run:

$ python3 measure_offset.py \
    08_07_26_140000/08_07_26_140000_gearGuard_001.mp4 \
    08_07_26_140034/08_07_26_140034_rearCenter_001.mp4 \
    --at 300 --guess 34

window at 300 s: correlation 0.84, offset +32.6 s

One window is one measurement. Repeat it in windows that don’t overlap, from different segments, and trust the offset only when they agree. Four windows on the August 7 drive gave this:

That’s 32.7 seconds, plus or minus 0.1, from four independent windows. A moment at time t in the original folder is at t − 32.7 in the sibling folder.

Compare cameras that face the same way

The front camera was my first choice for the reference, because it recorded the whole drive. Against the restarted rear camera it gave two answers:

The two windows disagree by 0.9 seconds, and each one looks plausible on its own. The front camera sees the road ahead and the rear camera sees the road behind. Their pictures change for different reasons most of the time, so the best match moves from one window to the next. The Gear Guard camera looks backward over the bed, the same direction as the rear camera, and the two agree.

Pick a reference camera that kept recording in the original folder and faces the same direction as one of the restarted cameras. The files in a sibling folder share one start time and the same segment lengths, so the offset you measure for one of its cameras applies to all of them.

Stitch the restarted cameras

A stream copy can only start on a keyframe, and the truck writes one keyframe per second. The stream-copied angles from the original folder start on their own keyframes. An offset of 32.7 seconds isn’t a whole number of seconds, so no keyframe in the sibling folder falls on the same instant. Re-encode only the restarted cameras, cut at the exact frame, and leave the rest as stream copies.

Suppose your clip covers START to END seconds of the original folder, and OFFSET is the measured offset. The window has to begin after the restart, so START is greater than OFFSET. In the sibling folder, the clip begins at START minus OFFSET and lasts END minus START seconds.

In the DriveStream folder, the following commands write a concat list of the restarted camera’s segments in the sibling folder, and then cut the clip from the joined segments, re-encoding to HEVC. They create two files and change nothing in the drive folders:

printf "file '%s'\n" "$PWD"/08_07_26_140034/08_07_26_140034_rearCenter_*.mp4 \
  > rearCenter.txt
ffmpeg -f concat -safe 0 -i rearCenter.txt -ss <sibling-start> -t <duration> \
  -c:v hevc_videotoolbox -q:v 80 -tag:v hvc1 -color_range pc -an \
  <clip-folder>/rearCenter.mp4

Run the same two commands for every other camera in the sibling folder.

-ss after -i decodes from the start of the list and discards frames up to the exact time, so the output starts on that instant rather than on the nearest keyframe. It’s slow for a window late in the drive, because ffmpeg decodes everything before the window first. Joining the segments in one concat pass, rather than cutting each file and joining the cuts, keeps the frames whose group of pictures runs across a segment boundary. Cut multi-camera dashcam clips with ffmpeg covers the stream-copied cameras and that join in full.

The encoder hevc_videotoolbox is the hardware HEVC encoder on macOS. On another system, use the encoder you’d use for the rest of the project. The option -color_range pc labels the re-encoded angle full range like the truck’s footage, so it matches the stream-copied ones; check it with ffprobe -show_entries stream=color_range. The truck records no audio, so -an drops nothing.

Every file now starts at time 0. The re-encoded angles start on the exact frame, and a stream-copied one starts early by the lead the cut script printed for it. In DaVinci Resolve, mark each lead as an In point, then create the multicam clip with angle sync set to the In point.

Confirm the stitch

Run the same script on the finished clip, with the guess left at zero. In the clip’s folder, compare the Gear Guard camera, which was stream-copied from the original folder, with the re-encoded rear camera:

$ python3 measure_offset.py 08_07_26_140000_gearGuard.mp4 \
    08_07_26_140000_rearCenter.mp4 --at 300 --length 90

window at 300 s: correlation 0.79, offset +0.1 s

An offset of +0.1 seconds is one sample step of SAMPLES_PER_SECOND, the resolution of the method. The angles are in sync. The same script reported 32.7 seconds on the unstitched folders, so it does notice an offset when one exists. A zero from a check that has never reported anything else proves nothing.

TL;DR

The GPS position is in the MP4 container’s location tag. Read it with ffprobe:

$ ffprobe -v error -show_entries format_tags=location -of default=nw=1:nk=1 \
    <clip>.mp4

47.589462-122.2655

The value is a signed latitude immediately followed by a signed longitude, in decimal degrees: 47.589462 north, -122.2655 west. That clip starts on the I-90 floating bridge. 0,0 means the truck had no fix.

There is one fix per file, taken where the 15-minute segment began. There is no per-second GPS track.

Spellings of the tag

The value has no separator between the two numbers. The sign of the longitude is the separator, so a parser has to split on the second + or -, not on a comma or a space. The truck never writes a leading plus sign. Across 475 front-camera segments, all from encoder tag Rivian Firmware ver. 2022-47, three spellings turned up, and 0,0 stands in when there is no fix:

Usual

47.589462-122.2655, on 439 of the 475 segments.

Trailing slash

the same form ending in /, on the other 36.

After ffmpeg copies the file

+47.5894-122.2655/, the ISO 6709 form, with a leading plus sign and four decimal places. This is ffmpeg’s rewrite, not a firmware variant.

No fix

0,0, which is a position in the Gulf of Guinea, not a reading.

ffprobe also prints a location-eng tag with the same value. Either one works; the commands here read location.

What one fix per segment rules out

The truck records one file per camera per 15-minute segment, and each file carries a single fix from the moment that segment started. Nothing inside the file records where the truck was a minute later. That rules out:

• A route drawn from the video. A segment gives you a point every 15 minutes, which is too coarse to follow a road.
• Speed. Two fixes 15 minutes apart give an average over the whole segment, not the speed at any moment.
• Finding a place by GPS alone. A drive across the floating bridge takes less than a segment, so the bridge usually falls between two fixes.

The five cameras of a segment each carry their own fix. In the clip earlier, the front and rear files read 47.589462-122.2655 and the two side cameras and the Gear Guard camera read 47.589474-122.2659. Treat any one of them as the segment’s position.

To place a moment inside a segment, read the picture instead of the container. Finding a bridge in dashcam video by the color of tunnel lights locates the I-90 floating bridge crossing from the picture, where the GPS can’t.

Parse the tag in Python

parse_location returns a (latitude, longitude) tuple, or None when the tag is missing, unreadable, or 0,0. read_location runs ffprobe on one file. The standard library is enough; Python 3.10 or later, for the | in the type hints.

import re
import subprocess
import sys

# A signed latitude immediately followed by a signed longitude. The leading
# plus sign and the trailing slash are optional because not every writer
# emits them.
LOCATION = re.compile(r"([+-]?\d+(?:\.\d+)?)([+-]\d+(?:\.\d+)?)")


def parse_location(tag: str) -> tuple[float, float] | None:
    match = LOCATION.search(tag)
    if not match:
        return None
    latitude, longitude = float(match[1]), float(match[2])
    # The truck writes 0,0 when it has no GPS fix.
    if latitude == 0 and longitude == 0:
        return None
    return latitude, longitude


def read_location(clip: str) -> tuple[float, float] | None:
    tag = subprocess.run(
        ["ffprobe", "-v", "error", "-show_entries", "format_tags=location",
         "-of", "default=nw=1:nk=1", clip],
        capture_output=True, text=True, check=True,
    ).stdout
    return parse_location(tag)


if __name__ == "__main__":
    for clip in sys.argv[1:]:
        point = read_location(clip)
        print(clip, "no fix" if point is None else f"{point[0]}, {point[1]}")

Pass it one or more clips:

$ python3 rivian_location.py <clip>.mp4

<clip>.mp4 47.589462, -122.2655

The tests cover every spelling in the list earlier, a southern and eastern position so both signs are exercised, and each way the tag can mean “no fix”:

import pytest

from rivian_location import parse_location


@pytest.mark.parametrize(("tag", "expected"), [
    ("47.589462-122.2655", (47.589462, -122.2655)),
    ("47.589462-122.2655/", (47.589462, -122.2655)),
    ("+47.5894-122.2655/", (47.5894, -122.2655)),
    ("-33.8688+151.2093/", (-33.8688, 151.2093)),
])
def test_reads_each_spelling_of_the_tag(tag, expected):
    assert parse_location(tag) == expected


@pytest.mark.parametrize("tag", ["", "\n", "garbage", "+0.0000+0.0000/", "0-0"])
def test_returns_none_for_no_fix(tag):
    assert parse_location(tag) is None

$ python3 -m pytest -q

.........                                                                [100%]
9 passed in 0.01s

Dropping the optional sign from the latitude’s half of the pattern fails the southern-hemisphere case, so the tests do notice a broken pattern.

Remove the GPS location from a clip before sharing it

The tag travels with the file. A raw clip posted online tells anyone who downloads it where it was recorded, and a folder of them maps where the truck goes every day. Trimming the clip doesn’t necessarily remove it: a stream copy with ffmpeg kept the tag, rewritten in the +…/ form, and exiftool reports it as a GPS position:

$ ffmpeg -i <clip>.mp4 -t 2 -c copy copy.mp4
$ exiftool -G1 -a "-gps*" "-location*" copy.mp4

[Composite]     GPS Altitude                    : 0 m
[Composite]     GPS Altitude Ref                : Above Sea Level
[Composite]     GPS Latitude                    : 47 deg 35' 22.02" N
[Composite]     GPS Longitude                   : 122 deg 15' 55.76" W
[Composite]     GPS Position                    : 47 deg 35' 22.02" N, 122 deg 15' 55.76" W
[UserData]      Location Information            : (none) Role=shooting Lat=47.58945 Lon=-122.26549 Alt=0.00 Body=earth Notes=

Other ways of writing a file behave differently. The multi-camera clips cut with ffmpeg’s concat demuxer came out with no location tag at all, because the demuxer drops file-level metadata. The hyperlapse tool I used kept it, because it copies the first source file’s metadata on purpose. Check each file rather than trusting the tool. To drop the container’s metadata while copying, add -map_metadata -1; the same exiftool command then prints nothing:

$ ffmpeg -i <clip>.mp4 -t 2 -c copy -map_metadata -1 strip.mp4
$ exiftool -G1 -a "-gps*" "-location*" strip.mp4

Empty output is the result you want. Run the check on the file you’re about to upload, not on its source: each tool between the two can keep the tag or drop it.

TL;DR

Give Claude Code one prompt per stage: survey, move, find, cut, publish. Each prompt states what the agent can’t touch and carries three demands: run on one drive first, break your own check on purpose and confirm that it fails, and list what you couldn’t verify. The agent reads the GPS tag and the keyframes instead of the pixels and proposes candidates. You confirm every pick on a contact sheet before anything is cut, moved, or deleted.

Driving from July to September filled the truck’s 2 TB dashcam drive, a SanDisk Extreme Portable SSD (opens in a new tab) (affiliate link): 240 drive folders, 1,958 GB, five cameras recording on every trip. I wanted to keep only what might make a video, and the backup drive couldn’t hold all of it. Watching it wasn’t an option. I directed Claude Code in plain language instead. It sorted the drives by where they went using GPS, found the I-90 floating bridge by the color of the tunnel lights, cut synced clips, and rendered a hyperlapse of every drive.

Almost every failure in that work was caught by a check: a size comparison, a frame count, a positive control, a contact sheet, or me. One failure was caught by nothing for hours. The prompts in this guide are general versions of the ones I typed, rewritten for your own footage, and each one carries the guardrail that the failure taught.

Signals already in the files

A Rivian writes one folder per drive and one MP4 per camera per 15-minute segment. Two things in those files do most of the work, and neither needs anyone to watch the video:

• GPS. The container’s location tag holds one fix per segment, taken at its start. That’s the only GPS in the file; there’s no per-second track.
• Keyframes. Every camera writes one keyframe per second. Decoding only the keyframes, downscaled to 64 × 48, gives a per-second record of motion and color without decoding the frames between them.

Read the tag from any clip:

$ ffprobe -v error -show_entries format_tags=location -of default=nw=1:nk=1 <clip>.mp4

It prints a signed latitude immediately followed by a signed longitude, such as 47.589462-122.2655. Some tags end in / and most don’t, and 0,0 means the truck had no fix. Read the GPS location from Rivian dashcam video with ffprobe covers every spelling. Other dashcams store GPS differently, which is why the first prompt asks the agent to find out rather than assume.

Tools and rules for every stage

You need:

• Claude Code, run in a terminal on the machine that has the footage mounted
• The ffmpeg and ffprobe commands on the PATH
• The exiftool command, for the privacy stage
• A second drive with room for whatever you keep

Every prompt carries three rules, worded for its stage. They’re repeated on purpose, so that a prompt pasted on its own still carries them:

• One drive first. A bug found on the first drive costs one drive’s time. The same bug found late in a batch costs every drive before it.
• Break the check on purpose. A check that has never failed proves nothing. The agent damages its own input or output, confirms the check catches it, and then restores it.
• Say what couldn’t be verified. Matching file sizes aren’t matching content, and a report that doesn’t say so reads as if they were.

Survey every drive without changing anything

In Claude Code, from the folder that holds the drive folders, paste:

The folder <footage-folder> holds video from my truck's dashcam: one subfolder per drive, and one MP4 per camera per segment. Survey it without changing anything.

For every drive folder, use ffprobe to read each segment's duration and GPS location tag. Report each drive's start time, length, GPS points, the distance between its two farthest points, and its size on disk. Ignore any ._ files macOS has left beside the clips on a FAT32 or exFAT drive.

Rules:
- Read only. Do not move, rename, re-encode, or delete anything.
- Run on one drive first and show me the result before you run the rest.
- The location tag is written in more than one format. Parse it permissively, and treat 0,0 as no fix, not as a place.
- Before you run the whole batch, feed your parser a malformed tag on purpose and confirm that it reports the drive instead of skipping it silently.
- Cache everything you read in one file, so that later steps don't read the drives again.
- Then propose a way to sort the drives into routine and unusual, and wait. I'll tell you my regular routes.
- Finish with a list of the drives you couldn't read and anything you couldn't verify.

What went wrong here. I asked for road trips, and the agent ranked drives by distance. The ranking itself showed there were none: no drive in the batch went far. Distance was the wrong question, and only I could supply the right one: the corridor across the I-90 bridges that most of the drives used. With that, the classification became a corridor test. A drive whose every GPS point falls inside a box around that corridor is a corridor drive; anything else is worth a look. The test found 168 corridor drives, 1,594 GB, and 14 off the corridor worth keeping, 171 GB. That’s why the prompt ends by waiting for you. Your routes are context the agent can’t get from the files.

The parser also failed on its first real run, on a tag that ended in /. The fix was a pattern that finds two signed numbers wherever they sit. Expect the same from your own camera’s metadata, and test both spellings.

Move the drives you keep

Decide which drives to keep from the survey, then paste:

Move these drives from <footage-folder> to <backup-drive>/<kept-folder>: <list of drive folders>.

Rules:
- Before you copy anything, compare the total size with the free space on <backup-drive>, and stop if it won't fit.
- Copy first. After each drive, compare every file's size on the destination with the source.
- Do not delete anything from the source until I say so. Show me the drives whose sizes all match, and wait.
- When I confirm, remove the source files with a tool that removes only what it has copied, such as rsync --remove-source-files. Do not rely on shell-specific glob features.
- Skip any folder that another process, such as Finder, is still writing to or moving.
- Report the empty folders that a move leaves behind. Do not delete them, and make every later step skip them.
- Move one drive first and show me the result.
- Before the batch, truncate a copy in a scratch folder and confirm your size check reports it.
- Say plainly that a size match isn't a content match, and list anything you couldn't verify.

What went wrong here. A queued move used a zsh glob qualifier that the shell Claude Code runs commands in doesn’t enable. It would have copied every file and deleted none. Inspecting the running process caught it, and the move switched to rsync --remove-source-files, which removes only what it copied. Later, a cleanup command of the form rm -f $B/*.jpg was blocked by Claude Code’s own guard, because an unset $B would expand the path to /*. The cleanup wasn’t needed, and the guard was right to stop it.

The moves also left empty drive folders behind. Nothing failed because of them until the hyperlapse run, in a later stage, which is why this prompt asks for them to be reported now.

Find a landmark from computed signals

GPS places a drive to within a 15-minute segment, which is too coarse to find a bridge crossing. The picture has to do it, and the cheap way to read the picture is to compute a few numbers per second once and reuse them. Paste:

I want the moment in each drive where the truck passes <landmark>. The GPS has one point per segment, which is too coarse, so find it from the picture.

1. From keyframes only, downscaled to 64x48, compute per-second signals for each camera: the mean change in green from the previous keyframe, and the mean red, green, and blue. Cache them per drive and per camera, so that no later step decodes video again.
2. Propose a signal that marks <landmark>, and explain why it should separate the landmark from things that look like it.
3. Propose candidates. Do not pick for me.

Rules:
- Read only on <footage-folder>. Write only under <work-folder>.
- When you extract keyframes as raw frames, make sure ffmpeg doesn't duplicate them back up to the source frame rate.
- Before you scan everything, calibrate the signal on a drive where I know the landmark is present and a drive where I know it isn't. If both read the same, suspect your extraction before the signal.
- Run on one drive first.
- Build a contact sheet with one row per drive, labeled with the drive's name, and one frame per candidate in time order. Write a picks file with your best guess for each drive, which I can edit. Then wait for me.
- Ignore the first and last few minutes of each drive, where the truck is parking or leaving.
- If a result contradicts something already confirmed, check your tool before you report the contradiction: extract the same frame two ways and compare them.
- List the drives with no candidate, and anything you couldn't verify.

For a tunnel, the signal turned out to be color. Auto-exposure keeps a tunnel’s brightness close to daylight’s, but sodium lighting tips the front camera’s red/blue ratio above 1.0. A run of 25–150 s above that ratio, away from the first and last 3 minutes of the drive, found a tunnel on 71 of the 79 bridge drives scanned. Seven of the eight misses were after dark. Finding a bridge in dashcam video by the color of tunnel lights is the full account, including what didn’t work.

What went wrong here. The first calibration read zero change between every pair of keyframes, parked or moving. A signal that’s flat on a known positive and a known negative is a broken instrument, not a finding. The cause was ffmpeg duplicating keyframes back up to 30 fps, so consecutive frames were identical. -fps_mode passthrough fixed it. That bug is why the prompt asks for a known positive and a known negative before the scan.

The automatic pick, one tunnel chosen by its position in the drive, was right about two times in three. The rest landed on other tunnels. The contact sheet is what turned an unreliable detector into a usable one. It showed one frame per candidate, taken from the bridge side of the tunnel. From it, I confirmed 68 crossings, couldn’t confirm two night drives, and found none on one. The first sheet was a flat grid of every candidate frame, and it was easy to match a frame to the wrong drive. One row per drive makes that mistake visible.

The worst wrong claim of the whole session came at this stage. Partway through, the agent reported that the picks for some drives were the wrong tunnel, the Mercer Island lid instead of the Mount Baker tunnel. The contact sheets had been built with an output-side -ss, which ffmpeg applied after tiling, so the sheets showed a different window from the one the picks named. Extracting one frame two ways exposed it. The picks had been right, and the claim was retracted.

Cut synced clips and render hyperlapses

With picks confirmed, paste:

For each confirmed pick in <picks-file>, cut a clip from every camera, from <seconds-before> seconds before the landmark to <seconds-after> seconds after it, without re-encoding. Then render a 30x hyperlapse of every drive for every camera, decoding keyframes only.

Rules:
- Read only on <footage-folder>. Write only under <work-folder>.
- A stream copy can start only on a keyframe. Measure each camera's keyframe timing first; do not assume the cameras share it.
- A camera's first frames in a segment file can depend on frames at the end of the previous file. Cut across segment files in one pass, and check the joins.
- After cutting, compare every camera's frame count, duration, and start_time. Same length isn't the same as in sync.
- Pad a camera that stopped early with black frames, per segment, so that every camera stays the same length as the front camera. Give the black the footage's pixel format and color range, and check the range of every joined file.
- Do not trust folder names or file timestamps for timing. If a camera restarted into another folder, measure its offset from cameras that see the same scene, in more than one window. If that offset doesn't land on one of the camera's keyframes, re-encode only that camera, cut at the exact frame, and tell me which files were re-encoded.
- Test on one drive first, and include a drive where a camera stopped early.
- Before the batch, shift one camera by a second on purpose and confirm that your sync check fails. Then restore it.
- In the batch, one bad drive must be logged and skipped, not stop the run. Write each output to a temporary name and rename it when it's complete, so that a rerun resumes.
- Time the test drive and estimate the batch from that.
- If the run will outlive this session, start a watcher that tells me when the run ends or stops making progress.
- List the drives that were skipped or padded, and anything you couldn't verify.

Each keyframe becomes one frame at 30 fps, so a hyperlapse plays at 30× speed. A 36-minute drive became 72 s and took 4.4 minutes to render. The hyperlapses of 218 drives, five cameras each, came to 107 GB. Cut multi-camera dashcam clips with ffmpeg and make a hyperlapse from keyframes with ffmpeg cover each step in full.

What went wrong here. On the first drive I cut, the side-left camera came out short. On other drives it’s a different camera, or none, so the prompt measures every camera. The frame-count comparison caught it twice:

1. Its GOPs run across segment files. Cutting each segment separately and joining them dropped the frames that reference the previous file: the camera came out 1.9 s short, with a jump at the join. One concat-demuxer pass over the source segments keeps them.
2. It was still 29 frames short, because its keyframes fall at n + 0.967 s, not on whole seconds like the other cameras’. Landing each camera’s in-point exactly on its own keyframe makes every file start at time 0. An offset camera starts a few frames early, and setting that clip’s In point that many frames in lines it up with the others.

A third check, on start_time, caught a version that had the right length but started 0.967 s late, which an editor might ignore.

The hyperlapse test drive caught two more. Two cameras came out at 1,303 frames against the front camera’s 2,170. The first guess was the black filler’s pixel format; the real cause was the rear camera stopping 33 s into a segment. The fix is to pad every segment to the front camera’s length. The filler has a trap of its own: it has to be full range like the footage, which takes -color_range pc; Apple’s hardware encoder ignores -pix_fmt yuvj420p. A mismatched part doesn’t make the stream-copy join fail. The joined file takes the first part’s label, so a camera whose file opens on filler was labeled limited range throughout: 11 of more than a thousand hyperlapse files, found and re-rendered later. Across 233 drive folders, six hyperlapse sets needed black-filled segments.

On that same drive, the rear and side-left cameras had restarted into a sibling folder whose name was 34 s later. The name was wrong by more than a second. Correlating motion between the Gear Guard camera and the restarted rear camera, which both face backward, measured 32.7 s ± 0.1 s across four independent windows. Front against rear disagreed by 0.9 s between windows, because those two cameras don’t see the same scene. Rivian dashcam camera missing from a drive covers the restart.

Then the batch failed, and no check caught it. Background jobs in the session stopped at a time limit, so the run was relaunched detached. A detached process sends no notice when it ends. It crashed at 10:11 on one of the empty folders the moves had left behind, and it sat dead until 16:48, when I asked what was next: more than six and a half hours. Two fixes came out of it, and both are in the prompt: an empty or bad drive is now a logged skip, and a long run gets a watcher.

Keep location out of anything you publish

Paste, for each file you mean to share:

Prepare <export-file> for publishing.

Rules:
- Treat GPS in any clip as private. List every metadata field that holds a location, with: exiftool -G1 -a "-gps*" "-location*" <file>
- First run that command on an original clip from the truck and confirm that it finds the location. Then run it on the export.
- If the export carries a location, write a copy without it, run the same command again, and show me the empty result.
- List the first and last frames of every clip, and flag any frame from either end of a drive, any license plate, and any face. Do not decide for me what to blur or cut.
- Also list creation dates, and any drive date or time in file names. Strip them with -map_metadata -1 and rename the files, unless I say otherwise.
- List what this check can't see, such as a street sign or a house number in the picture.

Run the check on every export rather than reasoning about which files carry a tag. In this work the answer differed by tool. The raw clips carry it. The hyperlapse tool I used copies the first source file’s metadata, GPS included, so the set stays traceable; the published hyperlapse script strips it. Clips cut with the concat demuxer came out without it, but a plain -c copy of a single file keeps it, and -map_metadata -1 removes it. Show only public landmarks on screen, and never frames from either end of a drive.

Detectors that didn’t work

Four ideas failed, and each failure says something about the signal rather than the threshold:

• Parked footage. The hypothesis was that recording while parked padded every drive. The measurement found 23 GB of 1,760 GB: with Gear Guard turned off, the truck stops recording seconds after parking. The scan still paid for itself, because its per-second signals fed every detector after it.
• Hard stops. The detector returned 875 candidates, and all 12 at the top were turns into parking lots or ordinary stops. Turning changes the picture as much as braking does.
• Traffic jams. Crawling traffic still changes the picture, because the neighboring cars move.
• Garage boundaries by color. An overcast sky is as gray as a concrete ceiling. It worked on a clear day and failed on a cloudy one, which is the case to test first.

One detector worked with a person in the loop. Close passes, read as a one-sided spike on a side camera while the front camera shows steady driving, were swamped by overpass shadows until the frame’s overall brightness change was subtracted. Of the top 60, 37 were real passes, and a contact sheet sorted them. A human pass was cheaper than a better detector.

Failures and the checks that caught them

Each stage in depth

Each later part of this series takes one stage and stands on its own:

2. Read the GPS location from Rivian dashcam video with ffprobe: the tag’s spellings, a parser, and how to strip it.
3. Rivian dashcam camera missing from a drive: it restarted in another folder: finding the sibling folder and measuring its real offset.
4. Cut multi-camera dashcam clips with ffmpeg without re-encoding, and keep them in sync: snapping each camera to its own keyframe.
5. Make a hyperlapse from keyframes with ffmpeg without decoding every frame: the 30× render, the padding, and the full-range filler.
6. Finding a bridge in dashcam video by the color of tunnel lights: the detector, the review sheet, and what didn’t work.