Harper Shaw Investigation Consultants · Research Post · 9 May 2026
Tesla SEI Forensics — a live AI-assisted investigation into hidden dashcam telemetry
This post is a live experiment. Noel Lowdon of Harper Shaw Investigation Consultants drove a Tesla, pulled the USB drive, and worked in real time with Claude — an AI assistant made by Anthropic — to locate, extract, and verify telemetry data embedded inside a dashcam MP4 file. The question was simple: could an AI guide a forensic investigator through reverse engineering a binary file format, decode raw hex to meaningful values, and produce independently verifiable findings? The entire session — from opening the file to decoding the final byte — took under 90 minutes. Every screenshot is from that session. Every byte value is from the actual file.
🤖 About this experiment
Noel brought the file, the tools, and the forensic expertise. Claude brought technical knowledge of binary formats, H.264 structure, protobuf encoding, and IEEE 754 mathematics. Neither could have completed this analysis as quickly alone. This post shows what that collaboration looks like in practice — including the dead ends, the failed searches, and the reasoning behind every decision. The complete session ran to under 90 minutes from first file open to final decoded value.
File: 2026-05-04_16-05-52-front.mp4
Duration: 60 seconds · 2,174 frames
Tools: MediaInfo · 010 Editor · Tesla SEI Explorer
Date: 9 May 2026
AI assistant: Claude (Anthropic)
1
The foundation
What is actually inside a video file?
Before we could find anything, we needed to understand what we were looking at. Most people think a video file contains video. It does — but that is only part of the story.
🎭 Think of it like this
Imagine a removal van. From the outside you see a big white van. Open the back and there are labelled boxes. Open each box and there are sealed envelopes. Open each envelope and there is a letter. A video file works exactly the same way — nested containers, each holding something different. The video people watch on screen is just one of the boxes. Inside the others is data that does not appear during normal video playback. In Tesla dashcam footage recorded since December 2025, one of those hidden envelopes contains a complete telemetry snapshot for every single frame of video — speed, gear, steering angle, autopilot state, GPS coordinates, and acceleration on three axes. Written by the vehicle at the moment of recording. Sealed inside the file. Not visible during normal playback in standard video players — but readable using Tesla's own published SEI Explorer tool, and verifiable at the raw binary level using a hex editor. That is what this session demonstrates.
The MP4 container — the filing system inside the file
An MP4 file is a container format. It is not just a video — it is a structured wrapper holding multiple types of data in labelled sections called boxes. Every box starts with its size in bytes, then a four-character name. Boxes nest inside each other like Russian dolls. Here is the complete hierarchy of the Tesla file we examined:
BoxOffsetSizeWhat it contains
ftyp
0x00
32B
File Type Box — the label on the van
Declares this is an MP4 and which standards it follows. Compatible brands: mp42, mp41, isom, iso2. First box in every MP4 file.
free
0x20
8B
Free Space Box — empty padding, nothing significant
mdat
0x28
79MB
Media Data Box — the van, 79 million bytes of video
Every frame of video lives here as raw encoded data. The SEI telemetry units are embedded inside this block — one per frame, physically present. Standard video players do not display this data during playback. Tesla's own SEI Explorer tool decodes and displays it alongside the video.
↳ NAL
inside mdat
—
Network Abstraction Layer units — the envelopes inside the van
The video stream is divided into chunks called NAL units. Type 7 = SPS (codec config). Type 8 = PPS (picture config). Type 6 = SEI — the telemetry carrier. One SEI unit per frame. Decoded and displayed by Tesla's SEI Explorer tool; verifiable at the raw binary level.
↳↳ SEI
inside NAL
89B
Tesla telemetry — the letter inside the envelope
Each SEI unit carries a UUID consistent with Tesla's encoding (decoded by Tesla's own SEI Explorer) + protobuf-encoded telemetry: speed, gear, steering, brake, autopilot, GPS, acceleration. 89 bytes. One per frame. 2,174 total in this file.
moov
end
273KB
Movie Box — the index, written at the END of the file
Contains timestamps, frame locations, codec config. Written only when recording stops cleanly. If power cuts during a collision, moov is never written — the file appears unreadable, but the frame data in mdat still exists and is recoverable.
⚙️ Why moov at the end matters forensically
MediaInfo confirmed this file as IsStreamable: No — meaning moov is at the end. Tesla records continuously into mdat and only finalises the index when recording stops cleanly. In a collision: power cuts, recording stops, moov is never written, file appears corrupt. But the raw frame data — including every SEI telemetry unit up to the moment of impact — is physically on the drive. Recovery is possible. Absence of a readable file is not absence of data.
2
First tool
MediaInfo — reading the label on the van
The first thing we did was run MediaInfo on the file. This is always the starting point — understand what you have before you go deeper. MediaInfo reads the container layer and tells you everything about the file's shape without touching the contents.
🎭 Think of it like this
MediaInfo reads the label on the outside of the van. It tells you the van's dimensions, what it's made of, when it was loaded, and how heavy it is. It does not open the van and look at the boxes inside. For that we need different tools. But the label is important — it tells us which format the contents are packed in, and that changes how we search for them.
Noel ran MediaInfo on the file and pasted the JSON output. Here is that output — the first screenshot from the actual session:
Screenshot 1 — actual session · MediaInfo JSON output
MediaInfo reveals the file's structure — and a critical clue
The JSON output confirms format MPEG-4, codec AVC (H.264) High Profile, resolution 2896×1876, duration 60.394 seconds, 2,174 frames. Three timestamps are visible: Encoded_Date: 2026-05-04 15:05:52 UTC (recording started), Tagged_Date: 2026-05-04 15:06:53 UTC (recording finished — 61 seconds later, matching the clip duration exactly), and File_Created_Date: 2026-05-04 15:06:52 UTC. The forensically significant field is IsStreamable: No — confirming the moov index is at the end of the file. And buried near the bottom: CodecConfigurationBox: avcC — which will become critical when we search for the SEI data.
What MediaInfo told us — field by field
Format
MPEG-4 · mp42
Base Media Version 2
Codec
H.264 High Profile
avc1 · avcC packaging
Resolution
2896 × 1876
Non-standard — Tesla specific hardware
Duration
60.394 seconds
2,174 frames at 35.997 fps
Encoded_Date (UTC)
15:05:52
Recording started — use as clip start time
Tagged_Date (UTC)
15:06:53
Recording finished — 61s later, matches duration
IsStreamable
No
moov index at end of file — power loss = unreadable
CodecConfigurationBox
avcC
Critical — means no start codes in this file
Bitrate
10.5 Mbps
High quality dashcam recording
File size
79.15 MB
79,154,081 bytes
The avcC field is the one that matters most for what comes next. It tells us the video stream uses length-prefix packaging rather than start codes to separate NAL units. This is why our first search attempt in 010 Editor failed — and understanding why it failed led us directly to the correct approach.
✓ What MediaInfo confirmed
The file is intact, the timestamps corroborate each other, the resolution is characteristic of Tesla hardware (not a consumer dashcam), and the avcC codec packaging tells us exactly how to search for the SEI units inside the binary. MediaInfo cannot see the SEI content — but it told us everything we needed to know about how the file is structured before we opened the hex editor.
3
Second tool
010 Editor — the X-ray machine
MediaInfo showed us the label. 010 Editor lets us see the actual bytes — every number physically stored in the file, in sequence, with nothing hidden.
🎭 Think of it like this
Every file on a computer is ultimately a sequence of numbers written directly onto the storage medium. A hex editor is an X-ray machine that strips away all software interpretation and shows you those raw numbers. 010 Editor then lays a template over the top — like a doctor placing an anatomical diagram over an X-ray to label what each part is. What you see is the file itself, not a software interpretation of it. This is as close to the raw truth as it is possible to get without cutting open the hard drive.
What hexadecimal is — and why we use it
Computers store everything as binary — 1s and 0s. Eight bits make one byte. Each byte can hold a number from 0 to 255. To display bytes readably, we use hexadecimal: a numbering system using 0–9 then A–F, so each byte takes exactly two characters. The byte 06 in hex = 6 in decimal. The byte 59 in hex = 89 in decimal. When you see 00 00 00 59 you are seeing four bytes — the number 89 stored as a 32-bit big-endian integer. Once you know this, the raw binary becomes readable.
Loading the file — the box structure in 010 Editor
Noel opened the MP4 in 010 Editor and ran the MP4.bt template. The template parsed the container and displayed all four top-level boxes in the Template Results panel:
Screenshot 2 — actual session · 010 Editor with MP4.bt template
The MP4 container structure — all four boxes visible
The Template Results panel at the bottom shows exactly what MediaInfo reported but now labelled in the binary: ftyp at offset 0h (File Type Box), free at 20h (empty padding), mdat at 28h starting at byte 40 with size 4B76097h = 79,126,167 bytes (the 79MB of video data), and moov at offset 4B760BFh — all the way at the end of the file, confirming IsStreamable: No. The hex view above shows the raw bytes corresponding to these boxes in sequence.
Navigating to the video data
Clicking Box[2] mdat in the template results jumped the hex view to offset 0x28 — the first byte of the media data box where all video frames and SEI units live:
Screenshot 3 — actual session · navigating to mdat at offset 0x28
Offset 0x28 — the start of 79MB of video data
With mdat selected, row 000:0020 in the hex view shows 04 B7 60 97 — the mdat box size (79,126,167 bytes, matching MediaInfo exactly) — followed by 6D 64 61 74 which spells "mdat" in ASCII, visible in the right-hand column. Two independent tools confirming the same values: MediaInfo read the container layer, 010 Editor shows the raw bytes that produce those values. The actual video frame data begins 8 bytes further on at offset 0x30.
4
The investigation
The hunt for SEI — every attempt, every failure, every lesson
This is the part most write-ups skip. Finding specific data in 79MB of binary is not always straightforward. Here is exactly what we tried, why each attempt failed, and what that failure taught us.
🎭 Think of it like this
We knew the envelopes were somewhere in 79 million bytes. We needed a description unique enough to find only the genuine envelopes — not things that happened to look like them by coincidence. Too short a description and the same pattern appears everywhere accidentally. Too specific and you miss envelopes that are slightly different from what you expected. What follows is the actual search process — not the clean version.
Attempt 1 — the obvious approach that failed
In most H.264 video streams, each data chunk (NAL unit) is preceded by a start code: 00 00 00 01. NAL type 6 is SEI. The logical first search was 00 00 00 01 06. It returned only 18 results from a file with 2,174 frames. This is where MediaInfo's avcC field became important.
⚙️ Why start codes don't exist here — the avcC format
H.264 video has two packaging formats. In Annex B (used for broadcast and live streaming), NAL units are separated by start codes 00 00 00 01. In avcC format (used in MP4 files), start codes are replaced by a 4-byte length field stating how many bytes the NAL unit contains. MediaInfo told us this file uses avcC — the CodecConfigurationBox: avcC field. We had the right idea but were searching for the wrong packaging. Understanding why the search failed led directly to the right approach.
The full search log — five attempts to nail it
Search bytesHitsWhat we learnedVerdict
00 00 00 01 06
18
H.264 Annex B start codes. Wrong format — avcC uses length prefixes not start codes. The 18 hits are real SEI units but the search method is wrong.
Wrong method
06 05
3,004
NAL type 6 + SEI payload type 5. Correct concept but only two bytes — they appear by coincidence throughout 79MB of compressed video data thousands of times.
Too many hits
06 05 52 42 42 42 69
1,826
Added the payload size byte (0x52=82) and start of Tesla's UUID. Better — but the payload size varies between frames. Some frames have slightly more telemetry data, changing that one byte.
Size varies
06 05 42 42 42
2,154
Removed the variable payload size byte. Getting very close — but 20 frames still unaccounted for, suggesting a slight variation in the UUID or preceding bytes for those frames.
Nearly there
42 42 42 69 08
2,175
UUID start (consistent across all frames in this file) + first protobuf field tag. 2,174 genuine SEI units (one per frame) plus exactly one coincidental byte match in the compressed video data. Expected, explainable, and not significant.
✓ Answer
The result — 2,175 occurrences confirmed
Screenshot 4 — actual session · Find All results for Tesla UUID
"Found 2175 occurrences of '42 42 42 69 08'"
The Find Results panel confirms 2,175 hits. The hex view shows one of them — row 001:5DA0 has 42 42 42 69 08 highlighted in blue, the UUID start sitting inside the compressed video stream at that exact byte offset. This UUID is consistent across all SEI units in the file and is the sequence Tesla's own SEI Explorer expects and decodes. The list of addresses on the left shows hit after hit, each one a SEI telemetry unit attached to a video frame. The count 2175 is visible at bottom left. The one false positive — a coincidental byte match in the video data — is expected in 79MB of binary content and does not affect the findings. 2,174 genuine hits for 2,174 frames.
✓ What this proved
Tesla embeds telemetry in every frame of dashcam footage. The data is physically present in the binary file — not generated by a viewer tool, not added retrospectively. It was there before we looked. The search process itself is part of the methodology: we showed that the data exists at the binary level using a UUID byte sequence that is consistent across all frames and recognised by Tesla's own published tool, and counted every occurrence independently of any extraction tool.
5
The raw proof
The first SEI unit — the actual bytes in the file
Clicking the first search result jumped to offset 0x50 — the start of Tesla's UUID in the very first SEI unit. Here is what those bytes look like, and what the surrounding structure reveals.
Screenshot 5 — actual session · first SEI unit at offset 0x50
The UUID highlighted at its exact byte offset in the raw file
Row 000:0050 shows 42 42 42 69 08 highlighted in blue — the start of the UUID inside the first SEI unit, consistent across all 2,174 frames and recognised by Tesla's own published tool, at exactly the byte offset the search found it. Looking one row up at 000:0040, the bytes 00 00 59 06 05 52 are visible — the NAL unit length (89 bytes), NAL type 6 (SEI), payload type 5 (unregistered user data), and payload size 82. Every part of the SEI structure is visible in the raw binary. The Find Results panel below still shows all 2,175 hits. This screenshot is the physical evidence: the exact bytes, at the exact offset, in the actual file.
What is a NAL unit?
Before we get into the file structure, one term appears throughout this post that needs a plain English explanation: NAL unit.
NAL stands for Network Abstraction Layer. When the H.264 video standard was designed, the engineers wanted it to work across completely different delivery systems — broadcast television, streaming, disc storage, mobile networks, files on disk — each with different packaging requirements. Their solution was to separate the video compression from the packaging. The Network Abstraction Layer is that packaging system.
In practice, the H.264 stream is divided into discrete chunks called NAL units. Each NAL unit starts with a one-byte header that identifies what type of data it contains. The type numbers relevant to this investigation are:
Type byteNameWhat it contains
0x07
SPS — Sequence Parameter Set
Codec configuration — resolution, frame rate, encoding profile. Written once at the start of the stream. Not video content.
0x08
PPS — Picture Parameter Set
Picture-level configuration — entropy coding settings, reference frames. Housekeeping, not video content.
0x06
SEI — Supplemental Enhancement Information
Custom vendor data. The H.264 standard deliberately reserves this type for manufacturers to attach additional information to their video streams. Tesla uses it to carry telemetry. This is what we are looking for.
0x05
IDR Frame
A complete keyframe — a full video frame that does not depend on any other frame to decode. The actual video content.
🎭 Think of it like this
NAL units are standardised shipping containers. The video data is the cargo. The one-byte NAL header is the label on the container telling you what type of cargo is inside. Type 5 is a video frame. Type 7 is configuration paperwork. Type 6 is a special container type reserved for custom cargo — and Tesla fills theirs with telemetry data. Every frame of dashcam footage has one of these custom containers attached to it, travelling alongside the video unseen.
The name — Network Abstraction Layer — is slightly misleading. It sounds like it only applies to streaming over networks. In practice every H.264 file uses NAL units regardless of whether it ever goes near a network. It is simply the standard unit of packaging for H.264 data in any context.
The complete NAL unit structure — every byte labelled
Noel copied 128 bytes starting at offset 0x30 and pasted them here in two passes. This is the full decode of the first three NAL units — two housekeeping units followed by the first SEI telemetry block:
OffsetRaw hexWhat it is and what it means
0x30
00 00 00 0C
→
NAL unit 1 length = 12 bytes — SPS
In avcC format every NAL unit starts with a 4-byte length. This says 12 bytes follow. This is the Sequence Parameter Set — codec configuration, not telemetry.
0x0000000C = 12 decimal
0x34
67 64 00 0A AC B4 01 6A 07 6F CE 80
→
NAL type 7 = SPS · High Profile H.264
0x67 = NAL type 7. First payload byte 0x64 = High Profile — matches MediaInfo Format_Profile: High exactly. Independent cross-check confirmed.
0x40
00 00 00 05
→
NAL unit 2 length = 5 bytes — PPS
Picture Parameter Set — more codec configuration. Still housekeeping, not telemetry.
0x00000005 = 5
0x44
68 CE 01 AE 0C
→
NAL type 8 = PPS · CABAC disabled · 1 ref frame
Matches MediaInfo Format_Settings_CABAC: No and RefFrames: 1. A third independent cross-check between tools.
0x49
00 00 00 59
→
NAL unit 3 length = 89 bytes ← THE SEI UNIT
The third NAL unit. 89 bytes follow. This is the telemetry carrier for frame 1.
0x00000059 = 89 decimal
0x4D
06
→
NAL type 6 = SEI confirmed
One byte. This is the proof of type. 06 = Supplemental Enhancement Information — the H.264 standard's designated carrier for vendor-defined custom data.
0x06 = nal_unit_type 6 per H.264 specification
0x4E
05
→
SEI payload type 5 = unregistered user data
The H.264 standard reserves type 5 for vendor-defined data identified by a UUID. This is the type Tesla uses for their telemetry payload.
payload_type = 5 per H.264 spec Table D-1
0x4F
52
→
Payload size = 82 bytes
16 bytes of UUID origin identifier + 66 bytes of protobuf-encoded telemetry follow.
0x52 = 82 decimal
0x50
42 42 42 69 08 01 10 01 18 8E 94 09 25 82 2D 48
→
UUID — 16 bytes identifying the payload origin
Every H.264 SEI type 5 payload begins with a 16-byte UUID identifying the payload origin. The UUID beginning 42 42 42 69 appears consistently across all 2,174 SEI units in this file and is recognised and decoded by Tesla's own published SEI Explorer tool. It is the byte sequence we used to locate every SEI unit in the binary.
6
The conversion
From bytes to numbers — the maths behind the telemetry
Every value in the final CSV came from bytes in the file. Here is exactly how each type converts — the complete arithmetic, shown once, using the actual bytes from the actual file.
The CSV — cross-referencing the raw decode against Tesla's own tool
Before decoding the bytes manually, the same MP4 file — 2026-05-04_16-05-52-front.mp4 — was loaded into Tesla's SEI Explorer, the manufacturer's own browser-based tool published at teslamotors.github.io/dashcam/sei_explorer.html. The tool decoded all 2,174 frames and displayed the telemetry alongside the video in real time. The Export CSV button produced a file named 2026-05-04_16-05-52-front_sei.csv — 2,174 rows, one per frame, one column per telemetry field.
The purpose of the manual byte decode that follows is to verify that what Tesla's tool reports matches what is physically present in the binary. Every value in the decode table is marked ✓ where it matches the CSV exactly. This cross-reference closes the chain — the raw bytes, the manufacturer's tool, and the manual decode all produce the same values independently.
Screenshot 6 — Tesla SEI Explorer · teslamotors.github.io/dashcam/sei_explorer.html
Tesla's own tool decoding the same file — frame 1 of 2,174
The SEI Explorer loads the MP4 file entirely in the browser — Tesla's own note confirms "All processing happens locally in your browser — no video/SEI data is uploaded." The right panel shows all telemetry fields for frame 1: filename 2026-05-04_16-05-52-front.mp4 confirmed, Frame Seq No 150030, Vehicle Speed 12.51 m/s, Accelerator Pedal Position 15.60, Steering Wheel Angle 0.20°, both blinkers false, Brake Applied false, Autopilot State NONE, Latitude 53.73°N, Longitude -1.69°W, Heading 253.47°. These are the exact values subsequently located and decoded from the raw binary in 010 Editor — the worked example above uses this frame's speed value. The Export CSV button at bottom right produced the 2,174-row CSV used throughout.
Screenshot 7 — CSV exported from Tesla SEI Explorer · 2026-05-04_16-05-52-front_sei.csv
2,174 rows of decoded telemetry — one per frame
The CSV exported from Tesla's SEI Explorer opened in Numbers. The filename 2026-05-04_16-05-52-front_sei.csv matches the source MP4 exactly. Every column is visible: version, gear_state, frame_seq_no, vehicle_speed_mps, accelerator_pedal_position, steering_wheel_angle, blinker_on_left, blinker_on_right, brake_applied, autopilot_state, latitude_deg, longitude_deg, heading_deg, and linear acceleration on three axes. The first data row confirms frame_seq_no 150030, gear GEAR_DRIVE, speed 12.511 m/s, autopilot NONE — the values we subsequently located and verified in the raw binary. This CSV is the reference against which every ✓ in the decode table below was checked.
Verifying the tool — going back to the raw binary
At this point we had the CSV — 2,174 rows of decoded telemetry produced by Tesla's own tool. The next step was to verify it. The question was straightforward: do the values the tool reports actually match what is physically encoded in the binary file? To answer that, Noel navigated to offset 0x30 in 010 Editor — the first byte of video data after the mdat header — copied 128 bytes in two passes, and pasted them here. Claude identified each field's byte position, named the encoding format, and performed the conversion. Here is what that process looks like for a single field before the full table.
Worked example — vehicle speedframe 1 of 2,174 · offset 0x68
CSV says
12.511110 m/s
= 45.04 km/h
→
Raw bytes at offset 0x68 in the file
25 82 2D 48 41
tag byte + 4 data bytes
The conversion — step by step
1Tag byte 25 = field 4, wire type 5 (32-bit fixed). This tells us the next 4 bytes are a 32-bit float.
2Data bytes: 82 2D 48 41 — stored in little-endian order (reversed). Flip to big-endian: 41 48 2D 82
5Calculate: 1.5639 × 2³ = 1.5639 × 8 = 12.511 m/s = 45.04 km/h
The tool reported 12.511110 m/s. The raw bytes decode to 12.511 m/s. They match. This same process was repeated for every field in the table below — gear state, frame sequence number, steering angle, GPS coordinates, acceleration. In every case the manual decode from the binary matched the CSV value exactly.
This is what the AI-assisted element of the session looked like in practice. Noel provided the raw bytes from 010 Editor. Claude identified the protobuf field tag, named the wire type, specified the encoding format (varint, IEEE 754 float, or 64-bit double depending on the field), and performed the arithmetic. The full table below records every field decoded in this way during the session.
🎭 Think of it like this
Tesla stores telemetry using Google's Protocol Buffers — an efficient binary shorthand. Instead of writing "speed equals twelve point five metres per second" it writes a field number, a wire type code, and the value compressed into the minimum possible bytes. The rules of this shorthand are published openly by Google. Once you know them, any byte sequence becomes readable. This is not guesswork. It is arithmetic using published standards that any examiner can independently verify.
Raw bytesFieldHow it decodes — the maths
08 01
Field 1
→
version = 1
Schema version number.
Tag 0x08 = field 1, wire type 0 (varint). Value 0x01 = 1.
10 01
Field 2
→
gear_state = GEAR_DRIVE ✓ matches CSV
An enum — a list of named options. 0=Park, 1=Drive, 2=Reverse, 3=Neutral.
Tag 0x10 = field 2, wire type 0. Value 0x01 = enum GEAR_DRIVE. CSV: GEAR_DRIVE ✓
18 8E 94 09
Field 3
→
frame_seq_no = 150,030 ✓ matches CSV
A variable-length integer (varint). Large numbers use multiple bytes, each contributing 7 bits with the 8th bit flagging whether more bytes follow. Strip the top bit from each byte: 8E→0001110, 94→0010100, 09→0001001. Concatenate right-to-left: 150,030.
Tag 0x18 = field 3, wire type 0. Varint: 3 bytes → 150,030. CSV: 150030 ✓
Near straight-ahead at clip start. By frame 2,174 the steering reaches -11° — a gradual left turn over 60 seconds, confirmed independently by the GPS heading rotating from 253° to 215°.
CD CC 4C 3E → reversed → 3E 4C CC CD → IEEE 754 → 0.200. CSV: 0.200000 ✓
Protobuf does not write fields whose value equals the default. For boolean fields the default is false. These fields are absent from every frame's binary payload — and their absence is the proof they are false. This is not missing data. It is the encoding working exactly as the published specification says it should.
Absence = default value = false. Confirmed across all 2,174 frames in CSV ✓
[ absent ]
Field 10
→
autopilot_state = NONE ✓ — all 2,174 frames
Enum default is 0 = NONE. The field is absent from every single frame in this file. No Autopilot. No TACC. No FSD. Zero of 2,174 frames. The vehicle was being driven by the driver throughout this clip.
Enum default=0=NONE. Absent from binary = NONE confirmed. 2,174 of 2,174 frames ✓
59 + 8 bytes
Field 11
→
latitude = 53.72891°N — West Yorkshire ✓
64-bit double precision float, 8 bytes, little-endian. GPS requires this precision — 32-bit float would only give accuracy to ~1 metre.
Wire type 1 = 64-bit. 8 bytes LE IEEE 754 double → 53.728910. CSV: 53.72891032 ✓
61 + 8 bytes
Field 12
→
longitude = -1.69316°W — West Yorkshire ✓
Negative value = west of the meridian. Combined with latitude: Brighouse/Halifax area.
8 bytes LE double → -1.693162. CSV: -1.69316192 ✓
69 + 8 bytes
Field 13
→
heading = 253.47° WSW ✓ matches CSV
Compass heading in degrees — 0=North, 90=East, 180=South, 270=West. Rotates to 215° SSW by clip end, consistent with the steering angle data showing a left turn.
8 bytes double → 253.470. CSV: 253.469628 ✓
What IEEE 754 is — and which fields use it
⚙️ IEEE 754 — the global standard for storing decimal numbers in binary
IEEE 754 is the published international standard that defines how computers store decimal numbers as binary. It is used in virtually every processor, programming language, and file format on earth. Tesla uses it for speed, accelerator pedal position, and steering angle — any field that needs a decimal value rather than a whole number.
The format works by splitting 32 bits into three parts: a sign bit (positive or negative), an exponent (the power of 2 to scale by), and a mantissa (the significant digits). Combined they can represent any decimal number to about 7 significant figures in just 4 bytes. The worked example above showed the complete conversion for the speed field — 82 2D 48 41 → 12.511 m/s. The accelerator pedal position and steering angle fields use exactly the same format and the same conversion process. Only the four bytes change.
One practical detail worth noting: multi-byte values in this file are stored in little-endian order — the bytes are written in reverse compared to how you would read them. This is standard on x86 and ARM processors and is not specific to Tesla. For any multi-byte IEEE 754 value — floats (4 bytes) and doubles (8 bytes) — reverse the byte order before applying the formula. Single-byte values such as the NAL type byte or protobuf tag bytes do not need reversing. Protobuf varints use their own multi-byte encoding system entirely and are decoded differently, as shown in the varint section below.
How protobuf varint works — the frame sequence number in full
⚙️ Converting variable-length bytes to frame number — 18 8E 94 09 → 150,030
Protobuf uses variable-length integers (varints) to store whole numbers efficiently. Small numbers use one byte. Large numbers use more. Each byte contributes 7 bits of the number — the 8th bit (the most significant bit, MSB) is a flag: if it is 1, more bytes follow; if it is 0, this is the last byte. Here is the decode for frame sequence number 150,030:
Step 1 — read the bytes after the tag:8E 94 09
Step 2 — check the MSB of each byte:
8E = 10001110 — MSB is 1, more bytes follow
94 = 10010100 — MSB is 1, more bytes follow
09 = 00001001 — MSB is 0, this is the last byte
Step 3 — strip the MSB from each, leaving 7 data bits:
8E → 0001110
94 → 0010100
09 → 0001001
Step 4 — concatenate in reverse order (LSB first):0001001 · 0010100 · 0001110
Step 5 — convert binary to decimal:150,030
This matches the CSV value of 150030 exactly. The frame sequence number tells us this clip started approximately 69 minutes into the vehicle's journey — meaning prior clips should exist on the USB drive covering everything before this point.
How GPS coordinates are stored — 64-bit doubles
⚙️ Why GPS uses 8 bytes not 4 — precision matters
Speed and steering are stored as 32-bit floats — 4 bytes giving roughly 7 significant figures of precision. GPS coordinates are stored as 64-bit doubles — 8 bytes giving roughly 15 significant figures. The reason is straightforward: a 32-bit float can only locate you to within about 1–2 metres anywhere on earth. A 64-bit double locates you to within a fraction of a millimetre. For forensic GPS evidence the higher precision is essential — and it is why the latitude value in the CSV reads 53.72891032171984 rather than just 53.72891. Those extra digits are real data, not noise. The conversion process is identical to IEEE 754 float but using 8 bytes instead of 4 and a different exponent bias.
7
The outcome
What this 60-second clip proves
From 2,174 frames of telemetry — found in the raw binary, decoded using published standards, verified against Tesla's own extraction tool.
Gear — all 2,174 frames
Drive
GEAR_DRIVE every frame without exception
Autopilot — all 2,174 frames
None
No TACC, Autosteer or FSD at any point
Speed throughout
45 km/h
12.0–12.5 m/s · steady, no hard acceleration
Brake applied
Never
False all 2,174 frames
Indicators
Neither
Both left and right false throughout
Steering
0° → -11°
Gradual left turn over 60 seconds
Location
W Yorkshire
53.73°N tracking south-west
Frame seq at start
150,030
~69 minutes of prior footage should exist on drive
✓ The complete chain — from road to report
Vehicle driven → SEI written per frame by Tesla's systems → USB recovered → MP4 located → container parsed with MediaInfo (avcC format confirmed) → raw binary examined in 010 Editor → SEI units located by binary search → bytes decoded using IEEE 754 and protobuf standards → values verified against Tesla's official export tool → CSV produced → findings reported. Every step documented. Every value traceable to a specific byte offset. Every conversion using published mathematics checkable by any qualified examiner.
Why this methodology stands up
✓
Data written at time of recording — not reconstructed
SEI is embedded per-frame during recording by the vehicle's own systems. Cannot be added retrospectively without re-encoding the entire stream, which changes the file hash.
✓
Manufacturer's own tool used for extraction
Tesla SEI Explorer published by Tesla Motors LLC on GitHub. No third-party interpretation of proprietary data. The manufacturer's tool, decoding the manufacturer's data.
✓
Every value traced to specific byte offsets in the raw file
Decoded using IEEE 754 floating point and Google Protocol Buffers wire format — both open published standards. The arithmetic is checkable by any examiner independently.
✓
False values provably absent — not assumed
Protobuf omits default values from the binary. Brake=false, indicators=false, and autopilot=NONE are absent from the binary encoding across all 2,174 frames. Their absence is the proof.
✓
Three independent tools, consistent results
MediaInfo timestamps match the file's encoded dates. Hand-decoded bytes match Tesla's SEI Explorer CSV output exactly. 010 Editor confirms the container structure MediaInfo reported. Three tools, one consistent picture.
Interactive Learning Tool
Want to try it yourself?
We built an interactive decoder so you can walk through the actual hex bytes from this file, work through the decode arithmetic step by step, explore the SEI Explorer output, and test your understanding with a quiz. No tools to install — it runs in your browser.
