Harper Shaw Investigation Consultants · Research Post · Part 2 · 30 May 2026
Tesla SEI Forensics — what happened in 1/36th of a second
One minute, six cameras, 13,044 records of telemetry — and one missing from one CSV.
This is the second AI-assisted post in the Tesla SEI series. The first post took a single front-camera MP4 and traced its telemetry from container structure to decoded values. This one widens the lens to all six cameras on the vehicle, recording the same minute. The other five CSVs hold the record the front camera's export missed. The MP4 binary holds it too. The vehicle was doing 26.1 mph and the IMU registered a single-frame disturbance on the vertical axis. Here is how every step was verified — and what it takes for a single missing row in a single export to become a finding you can stand behind.
🤖 About this experiment
This is the second in a series of AI-assisted vehicle forensics posts. Noel Lowdon brought the file set, the forensic context, and the decisions about what was worth investigating. Claude — the AI assistant from Anthropic — brought the binary parsing, the cross-camera comparison logic, and the writing. Between the first post and this one, Claude also helped Noel build a standalone Tesla SEI binary decoder — a tool that reads the raw MP4 directly rather than depending on Tesla's export. That tool appears at the end. The methodology shown here is what the tool automates.
Files: 6 MP4 cameras · 6 SEI Explorer CSV exports
Clip: 16:05:52 · 60 seconds
Records: 13,044 across six cameras
Tool built: TVN Labs SEI Decoder
AI assistant: Claude (Anthropic)
1
The cameras
One minute, six cameras, six CSVs
The vehicle in this case has six cameras feeding the dashcam recorder. For each one-minute clip the recorder produces an MP4 per camera, and each MP4 carries its own embedded SEI telemetry. For the 16:05:52 clip there are six MP4 files, and Tesla's SEI Explorer was used to export each one to CSV.
🎭 Think of it like this
Six observers stood at different corners of a courtyard. In the middle, an announcer reads out what the vehicle is doing thirty-six times every second — speed, gear, steering, acceleration, position, sixteen pieces of information in each call. Every observer writes down what they hear in their own notebook. If the announcer is heard the same way by all six, every notebook should read identically for any given moment. Comparing the notebooks afterwards is how you check what was said.
Front
2,174 records
150,030 → 152,204
1 record missing
Left B-pillar
2,175 records
150,030 → 152,204
No gaps
Left repeater
2,175 records
150,030 → 152,204
No gaps
Right B-pillar
2,175 records
150,030 → 152,204
No gaps
Right repeater
2,175 records
150,030 → 152,204
No gaps
Back
2,170 records
150,052 → 152,221
Different frame range
Five of the six cameras share an identical frame window — every CSV begins at frame 150,030 and ends at 152,204. Four of them hold the full 2,175 records that range allows. The front camera holds 2,174. The single gap in the front camera CSV is at frame 151,884.
The back camera sits outside the alignment. Its frame range is shifted later at both ends and the record count is five short of the others. That is the second thread of this investigation — and it is examined in Section 5 once the missing-record question is settled.
2
The missing record
Frame 151,884 — present in the binary, absent from the export
The first post established that the Tesla SEI Explorer reads telemetry out of the MP4 and writes it to CSV. When a row is missing from that CSV, the question is whether the data was missing from the recording or missing from the export. Those are two very different findings forensically.
The front camera CSV runs from frame 150,030 to 152,204 with one frame missing at 151,884. Every other camera that shares this frame window has the record. That alone shifts the working assumption toward an export artefact rather than missing data — but a working assumption is not a verified finding. The source MP4 had to be checked.
⚙️ The forensic question stated plainly
Two possibilities. Either Tesla's vehicle bus produced no telemetry for this frame and the gap is a recording fault, or the telemetry was recorded into the MP4 and the SEI Explorer's export missed it. A gap in the export does not, by itself, tell you which it is. The MP4 has to be read directly — at binary level — to answer the question.
In the first post that meant 010 Editor, manual hex navigation, and a five-attempt search for the right UUID signature. For this case the same method would have worked, but a more direct route was now available — the standalone decoder Claude and Noel built between the two posts. That tool is the subject of the next section.
3
The tool we built
The TVN Labs SEI Decoder, looking at the same MP4
Between the first post and this one, the methodology from that 90-minute hex session was turned into a standalone web tool. It does the work a forensic investigator would otherwise do by hand — locating SEI units in the MP4, decoding the protobuf payload, and comparing the result against any CSV export of the same file.
🎭 What the decoder does
If the first post was a hand search of the removal van — opening every box, checking every envelope — the decoder is a scanner that walks the van and reads every envelope's address in seconds. It does not require knowledge of hex editing or the MP4 box structure. It does require the original MP4. The output is a complete list of every telemetry frame the binary contains.
The front camera's 16:05:52 MP4 was opened in the decoder. Tesla's SEI Explorer CSV for the same file was dropped into the comparison panel. The decoder's output is shown below.
TVN Labs SEI Decoder reading the front camera MP4 and cross-checking against Tesla's SEI Explorer CSV. Single discrepancy identified: frame 151,884 present in the binary, absent from the CSV export. Vehicle speed at the missing frame: 26.1 mph.
The decoder reports 2,175 SEI units in the binary against 2,174 records in the CSV. The single discrepancy is frame 151,884. Vehicle speed at that frame is 26.1 mph. The file's SHA-256 hash is recorded alongside the result — a cryptographic fingerprint that changes entirely if a single byte of the MP4 is altered, recorded so the file analysed here can be confirmed identical to the file held in evidence at any later point.
⚙️ One finding, settled
Frame 151,884 exists in the front camera MP4 binary as a complete, structurally valid SEI unit. The Tesla SEI Explorer's CSV export omits this record. The omission is not missing vehicle data — it is missing from the export, with the source data intact. That settles the question this post opened with.
The decoder runs in the browser. It does not upload the file anywhere. It produces a deterministic output that any second analyst can reproduce given the same MP4. That last property matters: the conclusion does not rest on what one person typed into 010 Editor. It rests on a tool whose behaviour can be checked and re-checked.
4
Cross-camera corroboration
What the other four cameras recorded at frame 151,884
The decoder confirmed the missing record exists in the source MP4. That is one independent verification. A second is available — the other four cameras on the vehicle that share the same frame window were recording the same vehicle bus and should have written the same record.
The relevant row was pulled from the CSV exports of the left B-pillar, left repeater, right B-pillar and right repeater cameras. Every field at frame 151,884 was compared across the four cameras.
Field
Left B-pillar
Left repeater
Right B-pillar
Right repeater
gear_state
GEAR_DRIVE
GEAR_DRIVE
GEAR_DRIVE
GEAR_DRIVE
vehicle_speed_mps
11.688889
11.688889
11.688889
11.688889
accelerator_pedal_position
14.0
14.0
14.0
14.0
steering_wheel_angle
−2.5
−2.5
−2.5
−2.5
brake_applied
False
False
False
False
linear_acceleration_x
0.03250
0.03250
0.03250
0.03250
linear_acceleration_y
0.56750
0.56750
0.56750
0.56750
linear_acceleration_z
−0.39000
−0.39000
−0.39000
−0.39000
The four cameras carry identical values across every field. The vehicle was in drive, travelling at 11.689 m/s — 26.1 mph — accelerator at 14%, steering 2.5° left of centre, no brake. The Z-axis acceleration registers a transient −0.390 m/s². Surrounding frames carry Z readings of +0.19 and +0.18 m/s². For one frame the vertical acceleration dips sharply downward — the kind of reading that corresponds to a single-frame physical disturbance.
⚙️ Five sources, one value
Frame 151,884 holds vehicle telemetry recorded identically by four side-facing cameras and verified at binary level by the TVN Labs SEI Decoder against the front camera MP4. Five independent recordings of the same vehicle bus reading, identical to the precision the format allows. The absence of this record from Tesla's CSV export is a tool artefact, not missing data.
The forensic point is worth saying once and moving on. A row missing from one camera's CSV export should not be treated as missing data when other cameras on the same vehicle are recording the same bus. The first check should be the other CSVs. The second check should be the source MP4 of the camera with the gap. In this case both routes recover the same record.
💡 Casework tip
Whenever you receive Tesla dashcam evidence, ask for every camera's MP4 from every clip — not just the front, not just the clip of the moment of interest. Disclosure that arrives as a single camera is a procurement decision, not a technical limit of the data. Six cameras record the same vehicle bus, and the more files you have, the more cross-references are available when a record like frame 151,884 needs verifying. Where possible, request the full dashcam folder for the period in question.
5
The back camera offset
Why frame 151,884 in the back camera holds a different reading
The back camera's frame range did not match the other five. It begins at 150,052 and ends at 152,221 — shifted later at both ends, with five fewer records overall. The question is whether that means the back camera was recording later real-world content, or whether it was numbering the same content with different frame numbers.
🎭 Frame number is not time
Each camera writes a frame_seq_no to every record — its own internal count of frames. Two cameras' frame 151,884 are not necessarily the same moment in real time. They might be; they might not. The number is a private counter. What is shared between the cameras is the vehicle bus reading, not the label the camera puts on it. To match an event across cameras, you match the reading and let the frame numbers fall where they fall.
The Z-axis dip is a useful marker. It occurs once in this clip on each of the five non-back cameras at frame 151,884. If the back camera was recording the same vehicle bus during the same one-minute window, the same reading should appear in its data — but not necessarily at the same frame number.
It does. The back camera records linear_acceleration_z = −0.39000 m/s² at frame 151,901. Every other field at that frame matches the other five cameras' frame 151,884.
Field
Other 5 cameras · frame 151,884
Back camera · frame 151,901
Match
vehicle_speed_mps
11.688889
11.688889
✓
accelerator_pedal_position
14.0
14.0
✓
steering_wheel_angle
−2.5
−2.5
✓
linear_acceleration_x
0.03250
0.03250
✓
linear_acceleration_y
0.56750
0.56750
✓
linear_acceleration_z
−0.39000
−0.39000
✓
Exact match across every field. Two cameras, two frame numbers separated by 17, the same vehicle bus reading. Sequence matching the surrounding eight frames confirms the offset holds across more than a single row — the back camera's frame N corresponds to the other five cameras' frame N − 17 throughout the clip.
⚙️ Back camera frame offset, measured directly
Within the 16:05:52 clip the back camera tags real-time-simultaneous events with frame numbers 17 higher than the other five cameras. The offset is verified by matching a multi-field telemetry fingerprint, not inferred from clip arithmetic. Subtract 17 from the back camera's frame number to align with the other cameras, or align by data fingerprint as above.
With the 17-frame numbering offset removed, the start and end frames reconcile cleanly. The back camera ends at frame 152,221 — that is 152,204 after offset removal, the same as the other five cameras. The back camera begins at frame 150,052, which becomes 150,035 after offset removal — five frames later than the other cameras' 150,030. The back camera ends the clip at the same real-world instant as the others, but begins recording approximately five frames later in real-world time.
Why the back camera begins recording later than the other five is not established by SEI data alone. The data shows that it does, and by how much. Candidate explanations include differences in hardware initialisation, firmware write paths, or recording schedule. Distinguishing between them would require examination of multiple clips on the same vehicle and ideally on more than one Tesla — work outside the scope of this post.
💡 Casework tip
For rear-end collisions the instinct is to seize the back camera as the closest physical vantage of the impact. This case shows why that instinct should be checked. The back camera began recording slightly later than the other five in at least one clip — by roughly five frames or 140 milliseconds. If a collision happens close to a clip transition, the opening moments may be on every other camera but missing from the back. The back camera is still relevant; it should not be the only camera seized.
6
Two approaches to the same data
Our decoder vs the published Python — why one finds frames the other misses
The TVN Labs decoder was built without reference to any published Tesla SEI parsing code. Only after it was working was the published Python implementation read and compared. Some of what follows is convergent — both tools arrived at the same protocol logic independently — and some is divergent, in ways that matter forensically.
🎭 Walking the corridor versus scanning the building
One way to find every envelope in a building is to follow the corridor: enter the front door, walk to each numbered office, check each desk in order. That works perfectly if the building's signs are intact. If a corridor has a damaged sign or a missing room number, the walker may step past a whole row of offices without realising. The other way is to scan the building for envelopes regardless of room number. Slower in principle, but it finds envelopes the corridor-walker misses when the signs are broken.
Where the two tools agree
Both tools follow the same rules for unpacking the raw bytes. H.264 has a quirk where the recorder slips in an extra 0x03 byte whenever the data would otherwise contain a sequence the video format reserves for its own use — both tools recognise these inserted bytes and strip them back out before reading the telemetry. Both find Tesla's UUID signature 42 42 42 69 as the marker for the start of a telemetry payload. Both parse the same protobuf record structure, with the same fields in the same order, and produce identical decoded values for every frame they both find. The decode logic — the part where bytes become floating-point speeds, gear states, and GPS coordinates — is identical in result.
Where the two tools differ
The published Python is container-aware. It navigates the MP4 box structure, locates the mdat atom, then walks NAL units inside mdat using the 4-byte length prefix that precedes each unit in the avcC format. For each NAL it checks the type (6 = SEI) and the SEI payload type (5 = user data unregistered) before reading the protobuf. Clean and structured.
The TVN Labs decoder does not walk the container. It scans the entire file for the UUID byte signature and reads the protobuf payload that follows. It does not depend on any NAL length prefix being correct, on any box boundary being where the spec says it should be, or on any container atom being present at the expected offset.
⚙️ Why this matters for frame 151,884
If a NAL length prefix is corrupt, ambiguous, or simply unexpected, a container-walking parser may skip past the affected region — leaving frames undecoded. A raw scanner finds them anyway because it is not following the container's signs. Frame 151,884 is missing from Tesla's CSV; it is present in the binary at file offset 406BEB0h. The TVN Labs scanner finds it. That difference in approach is the most likely mechanism behind the missing-record finding throughout this post.
The convergence is also worth noting. Two implementations written independently — one by a Tesla-published author working in Python with the container spec to hand, the other by Claude working from binary inspection and protocol reasoning — arrived at the same decode logic at the byte level. Independent arrival at the same answer is itself a methodological strength. It means the protocol reading is not idiosyncratic to either implementation.
7
What this clip establishes
What this clip establishes
Three findings rest on this one-minute clip. Each is verified by multiple independent routes.
📌 Finding one — the missing record exists in the source
Frame 151,884 holds telemetry recorded by the vehicle bus at the same instant as the surrounding frames: gear in drive, 26.1 mph, accelerator at 14%, steering 2.5° left, no brake, transient downward Z-axis acceleration of −0.390 m/s². The Tesla SEI Explorer's CSV export for the front camera omits this record. The TVN Labs SEI Decoder finds it in the front camera MP4 binary at offset 406BEB0h. The CSV exports of all four other forward and side cameras carry the same record with identical values. Five independent sources, one verified data point.
📌 Finding two — the back camera uses a different frame-number origin
The back camera tags real-time-simultaneous events with a frame number 17 higher than the other five cameras for the duration of the 16:05:52 clip. The offset is measured by matching telemetry fingerprints, not inferred from clip arithmetic. The back camera also begins recording approximately five frames later in real-world time than the other five, while ending at the same real-world instant. Frame number is therefore not a valid cross-camera time reference between the back camera and the others on this vehicle.
📌 Finding three — a plausible mechanism for the export gap
The most likely mechanism for the front camera's missing CSV record is that Tesla's container-aware parser encounters an irregularity at the frame in question and steps past it. This is a working hypothesis, supported by the way the published Python implementation handles NAL boundaries, but not proven at byte level within this post — proving it would require walking the NAL chain in the binary and identifying the exact byte where the container walk misroutes, which is its own piece of work. A raw binary scanner, indifferent to container structure, finds the SEI unit anyway. The protobuf payload is intact and structurally complete; only the container-walk approach loses sight of it.
🎭 What this clip does not establish
The clips immediately before and after this one have not been examined to the same standard. Whether the 17-frame back camera offset is constant across multiple clips, or whether other frames in this dataset are silently dropped by Tesla's export tool, remain open questions. The methodology shown here can be applied to those clips when the time is right. The cause of the back camera's later start is also not determined by SEI data alone — only that it occurs and by how much. The findings above are what this clip, examined carefully, will support.
Decode Your Own MP4
Try the SEI Decoder yourself
The standalone tool used in this post reads Tesla MP4 files directly and compares them against Tesla SEI Explorer CSV exports. It finds SEI units the container-aware parsers miss, identifies frames omitted from CSV exports, and produces a SHA-256 hash for evidential file integrity. It runs in your browser. No file is uploaded.
