Tesla Dashcam SEI Decoder
This tool walks you through exactly how telemetry data is hidden inside a Tesla dashcam video file — and how a forensic examiner reads it. It uses one verified reference MP4 file with confirmed, independently decoded values.
Every byte shown here is from a real Tesla dashcam clip. Every value has been verified against Tesla's own SEI Explorer tool. This is not a simulation — it is a learning tool built on real forensic data.
Decoded and built by Noel Lowdon, Harper Shaw Investigation Consultants Ltd in collaboration with Claude (Anthropic) — an AI assistant used to perform, verify, and explain the decode process and build this interactive tool.
This tool has been made freely available to support learning and professional development within the vehicle forensics community. It is built on a single verified reference file and is intended to illustrate how Tesla dashcam SEI telemetry is structured and decoded — not to serve as a substitute for validated casework tools or peer-reviewed methodology.
Every effort has been made to ensure the content is accurate. All decoded values have been independently verified against the Tesla SEI Explorer. However, vehicle systems and file formats can vary, and this tool should be treated as educational material rather than definitive technical guidance.
If you spot an inaccuracy, have a correction, or want to contribute to improving the content, please contact training@harpershaw.co.uk — feedback from the community is genuinely welcomed and helps keep this resource accurate for everyone.
What is hexadecimal?
Computers store everything as binary — 1s and 0s. Eight binary digits make one byte. Each byte can hold a value from 0 to 255. Writing long strings of 1s and 0s is unreadable, so we use hexadecimal instead: a counting system using digits 0–9 and letters A–F, giving 16 symbols. In hex, each byte takes exactly two characters.
Ordinary counting uses ten symbols (0–9) — when you reach 9 you carry over and write 10. Hex uses sixteen — when you reach F (= 15) you carry over and write 10. Hex 10 = decimal 16. It is just a different way of writing the same number. The byte FF = 255. The byte 41 = 65 (also the letter 'A' in ASCII). Same number, different notation.
Why use hex? Because each byte always takes exactly two characters, it is easy to see where one byte ends and the next begins. When you see 25 82 2D 48 41 you are looking at exactly 5 bytes — no ambiguity, no guesswork.
In a hex editor like 010 Editor, every byte in every file is visible. A video file, an image, a Word document — all ultimately a sequence of numbers. A hex editor shows those numbers directly, without any software interpretation filtering what you see.
00 = 0 · 0A = 10 · 0C = 12 · 10 = 16 · 59 = 89 · FF = 255. Each byte is always exactly two hex characters — never more, never fewer.
The MP4 container format
An MP4 file is a container — 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.
Imagine a removal van. Open the back: labelled boxes. Open a box: sealed envelopes. Open an envelope: a letter. A video file works the same way — nested containers. The video on screen is just one box. Inside the others is data that never appears during normal playback.
The reference file has four top-level boxes:
| Box | Offset | Size | What it contains |
|---|---|---|---|
| ftyp | 0x00 | 32 B | File Type — declares this is MP4. Always first. |
| free | 0x20 | 8 B | Empty padding. Nothing significant. |
| mdat | 0x28 | 79 MB | Media Data — all video frames and embedded SEI telemetry. |
| moov | end | 273 KB | Movie index — timestamps, frame locations. Written last when recording stops cleanly. |
Tesla records continuously into mdat and only writes moov when recording stops cleanly. Power cut at impact → moov never written → file appears unreadable in a standard video player. But the raw mdat block — and every SEI telemetry unit inside it — is still on the drive and recoverable. Absence of a readable file is not absence of data.
NAL units and SEI telemetry
Inside mdat the video stream is divided into chunks called NAL units (Network Abstraction Layer). Each starts with a one-byte header identifying its type. In the avcC format used here, each NAL unit is also preceded by a 4-byte length field.
NAL units are standardised shipping containers. The one-byte header is the label — Type 5 is a video frame, Type 7 is config paperwork, Type 6 is a reserved container for custom cargo. The manufacturer fills Type 6 with telemetry data, one per frame, attached to every frame of dashcam footage unseen by normal video players.
| Type byte | Name | Contents |
|---|---|---|
| 0x07 | SPS | Codec config — resolution, frame rate, profile. Written once at stream start. |
| 0x08 | PPS | Picture config. Housekeeping, not video content. |
| 0x06 | SEI | Supplemental Enhancement Information — vendor custom data. One per frame here. |
| 0x05 | IDR Frame | A complete keyframe — the actual video content. |
Each SEI unit contains a 16-byte UUID starting 42 42 42 69, followed by 66 bytes of protobuf-encoded telemetry. The SEI Explorer tool recognises this UUID and decodes it across all 2,174 frames.
Searching the 79MB file for 42 42 42 69 08 returned 2,175 hits — 2,174 genuine SEI units plus one coincidental byte match in the compressed video data. The genuine count matches MediaInfo's frame count exactly.
IEEE 754 floating point
IEEE 754 is the published international standard for storing decimal numbers in binary — used in virtually every processor, language, and file format on earth. It is used here for speed, accelerator pedal, and steering angle.
A 32-bit float splits its 32 bits into three parts:
Sign=0 (positive) · Exponent 10000010=130, minus bias 127=3 · Mantissa=1.5639 · Result: 1.5639 × 2³ = 12.511 m/s
Scientific notation writes 12,500 as 1.25 × 10⁴ — a mantissa and an exponent. IEEE 754 does the same thing in binary. The mantissa holds the significant digits, the exponent says how many times to multiply by 2, the sign bit says positive or negative.
Worked example — vehicle speed
Raw bytes at offset 0x68: 82 2D 48 41
Stored little-endian — reverse first: 41 48 2D 82
As 32 binary bits: 0100 0001 0100 1000 0010 1101 1000 0010
Sign = 0 (positive). Exponent = 10000010 = 130 − 127 = 3. Mantissa = 1.5639.
Result: 1.5639 × 2³ = 1.5639 × 8 = 12.511 m/s = 45.04 km/h
SEI Explorer CSV: 12.511110 m/s. Manual decode: 12.511 m/s. Match confirmed.
Multi-byte values are stored least-significant byte first. Always reverse 4-byte floats and 8-byte doubles before applying IEEE 754. This is standard on x86 and ARM processors — not specific to this vehicle or format.
Protobuf varints
Telemetry is encoded using Google's Protocol Buffers — an efficient binary format. Each field starts with a tag byte encoding the field number and wire type. For whole numbers, protobuf uses a varint: each byte contributes 7 data bits, and the 8th bit is a continuation flag — 1 means more bytes follow, 0 means stop.
Instead of always using 4 bytes for a number, protobuf uses only as many bytes as needed. The number 1 needs one byte. The number 150,030 needs three. Each byte's MSB acts like a flag on a parcel — ticked means "there's another parcel after this," blank means "this is the last one."
Worked example — frame sequence number
Tag 18 = field 3, wire type 0 (varint). Data bytes: 8E 94 09
8E = 10001110 → MSB=1, continues. Data bits: 0001110
94 = 10010100 → MSB=1, continues. Data bits: 0010100
09 = 00001001 → MSB=0, last byte. Data bits: 0001001
Concatenate reversed (LSB first): 0001001 · 0010100 · 0001110 → decimal 150,030
SEI Explorer CSV: frame_seq_no = 150030. Manual decode: 150,030. Match confirmed. This number places the clip ~69 minutes into the drive — prior footage should exist on the drive.
Field number = tag >> 3. Wire type = tag & 0x07. So 0x25: field = 4, wire type = 5 (32-bit float). 0x59: field = 11, wire type = 1 (64-bit double). 0x18: field = 3, wire type = 0 (varint).
GPS coordinates — 64-bit doubles
Speed and steering use 32-bit floats — 4 bytes, ~7 significant figures. GPS coordinates use 64-bit doubles — 8 bytes, ~15 significant figures. The conversion is identical to IEEE 754 float but with exponent bias 1023 instead of 127.
A 32-bit float locates you to within ~1–2 metres. A 64-bit double locates you to within a fraction of a millimetre. The CSV value reads 53.72891032171984 not 53.72891 — those extra digits are real data, not noise. For forensic GPS evidence that precision is essential.
Verified values from frame 1: latitude 53.7289°N, longitude -1.6932°W — Brighouse/Halifax area, West Yorkshire. By frame 2,174 heading has rotated from 253° to 215°, consistent with steering angle data showing a gradual left turn.
Why this methodology stands up
Vehicle driven → SEI written per frame → USB recovered → MP4 located → container parsed (MediaInfo) → binary examined (010 Editor) → SEI units located by binary search → bytes decoded (IEEE 754 + protobuf) → values verified (SEI Explorer CSV) → findings reported. Every step documented. Every value traceable to a specific byte offset. Every conversion using published mathematics checkable by any qualified examiner independently.
Data written at time of recording. SEI is embedded per-frame by the vehicle's own systems. Cannot be added retrospectively without re-encoding the entire stream, which changes the file hash.
Three independent tools, consistent results. MediaInfo timestamps match encoded dates. Hand-decoded bytes match the SEI Explorer CSV exactly. 010 Editor confirms the container structure MediaInfo reported.
False values provably absent, not assumed. Protobuf omits fields at their default value. Brake=false, indicators=false, autopilot=NONE are absent from every frame's binary payload. Absence is the proof — not missing data, but the encoding working exactly as the published specification says.
As we say at Harper Shaw: assume nothing, believe nobody, check everything.
Glossary
