DAV File Documentation

Summary

A DAV file is surveillance video from a CCTV recorder, saved in the DVR365/Dahua DHAV format. It wraps an H.264 or H.265 stream (with optional audio) in Dahua’s per-frame “DHAV” framing, and is exported by Dahua DVR/NVR hardware sold under many brands (DVR365, Amcrest, Lorex, Q-See). The extension is .dav; its unofficial MIME type is video/x-dav. Play it with the free Dahua SmartPlayer, or with VLC and FFmpeg, which support DHAV.

Technical details

FeatureValue
Full nameDVR365 Video File (Dahua DHAV stream)
File extension.dav
MIME typevideo/x-dav (unofficial)
Format typeProprietary CCTV video container (DHAV framing)
DeveloperDahua Technology (marketed as DVR365 and other OEM brands)
IntroducedMid-2000s (Dahua DVR/NVR hardware)
Open standardNo — proprietary; documented via FFmpeg’s DHAV demuxer
Byte orderLittle-endian (frame header integers)
Frame framingEach frame starts with ASCII DHAV and ends with dhav
Magic number (hex)44 48 41 56 (ASCII DHAV)
Video codecH.264 (AVC) or H.265 (HEVC) elementary stream
Audio codecG.711 (A-law/µ-law) or AAC, when audio is recorded
Per-frame metadataFrame type (I/P/audio), channel, frame number, epoch date, timestamp
ScramblingOptional — some firmware exports are scrambled, readable only by Dahua tools
FFmpeg supportDHAV demuxer since FFmpeg 4.2 (2019)
OEM brandsDVR365, Amcrest, Lorex, Q-See, Mace, and others
Tamper evidenceDahua embedded watermark, verifiable in SmartPlayer
EditableNo — remux/convert to MP4 for editing
Related extensions.mp4, .avi, .h264, .264, .dvr
Specificationgit.ffmpeg.org (libavformat/dhav.c)
File signature (magic bytes)
44 48 41 56

Offset 0, 4 bytes of ASCII. This reads D H A V, the tag that opens every frame in a Dahua DHAV stream, so a standard DAV export begins with it. The same 4-byte tag repeats at the start of each frame, and each frame closes with the lowercase footer 64 68 61 76 (dhav) plus a length, which lets a player scan backwards to seek. A DAV file that does not begin with DHAV is usually a scrambled or encrypted export from a camera’s firmware, which only Dahua’s own SmartPlayer can open.

What is a DAV file?

A DAV file is surveillance footage produced by a CCTV digital video recorder (DVR) or network video recorder (NVR). The format is often labelled the DVR365 Video File after one of the brands that shipped it, but the underlying format is Dahua Technology’s DHAV stream. Dahua is one of the world’s largest surveillance manufacturers, and its hardware is rebranded by many OEMs (DVR365, Amcrest, Lorex, Q-See, Mace and others), which is why the same .dav file turns up under so many camera-system names.

Technically a DAV file is not a general-purpose video container like MP4 or MKV. It is a stream of frames wrapped in Dahua’s own DHAV framing, each frame carrying an H.264 or H.265 payload plus per-frame surveillance metadata: which channel it came from, the frame type, and an absolute timestamp. Its unofficial MIME type is video/x-dav. The format was reverse-engineered into FFmpeg as the DHAV demuxer (added in FFmpeg 4.2, 2019), and that implementation is the clearest public documentation of the frame layout described below.

The DHAV frame header, field by field

Every frame in a DAV file begins with a fixed 24-byte header that starts with the ASCII tag DHAV. FFmpeg’s dhav.c reads the fields in this order, with the multi-byte integers little-endian:

Offset  Size  Field
0       4     Magic tag      "DHAV" (44 48 41 56)
4       1     Type           frame type (I-frame, P-frame, audio, ...)
5       1     Subtype
6       1     Channel         camera channel number
7       1     Frame subnumber
8       4     Frame number    (little-endian)
12      4     Frame length    total frame size in bytes (little-endian, >= 24)
16      4     Date            packed calendar date/time (little-endian)
20      2     Timestamp       (little-endian)
22      1     Extension length
23      1     Checksum        (skipped by the demuxer)
24      ...   Extension data  variable, per the extension length
...     ...   Payload         H.264/H.265 (or audio) elementary data

The Type byte distinguishes a video I-frame from a P-frame and from an audio frame, which is how a player can seek to a clean random-access point without decoding everything in between. The Channel byte records which camera the frame came from, so a single export can interleave several channels. The Frame length at offset 12 gives the whole frame’s size (it must be at least 24 to cover the header), letting a reader jump frame to frame by offset. The packed Date and Timestamp fields are what put the burned-in and metadata time on surveillance footage, and they are the reason evidential workflows care about keeping the original DAV.

The per-frame extension block

The single byte at offset 22 is an extension length: it says how many bytes of extension records follow the fixed header before the media payload begins. FFmpeg’s parse_ext() walks these records to recover stream parameters that are not in the fixed header, including the video codec identity, picture width and height, frame rate, and, for audio frames, the audio codec, channel count and sample rate.

This is the mechanism by which a raw elementary stream becomes playable: the DHAV framing carries no global header describing the whole file, so a demuxer learns the resolution and codec from these per-frame extension records as it reads the first frames. It also means a DAV file is inherently streamable and append-friendly, which suits a recorder writing continuously to disk, but it has no single index at the front the way a faststart MP4 does.

Each frame ends with a footer: the lowercase tag dhav (bytes 64 68 61 76) followed by a 4-byte length that repeats the frame’s size. Having the length at both ends of a frame lets a player scan the file backwards, stepping from one frame’s trailing length to the start of the previous frame. For a recorder that appends frames indefinitely and a player that must jump to the end of a long recording, reverse scanning by footer length is far cheaper than reading the whole file forward.

[ DHAV header 24B ][ ext ][ H.264/H.265 payload ][ "dhav" + length 8B ]
[ DHAV header 24B ][ ext ][ H.264/H.265 payload ][ "dhav" + length 8B ]
...

Video and audio payloads inside the frames

The bytes between the DHAV header (and its extension block) and the dhav footer are a plain codec elementary stream. Video is an H.264/AVC or H.265/HEVC bitstream, the same coded data an MP4 would carry, which is exactly why converting DAV to MP4 can be a lossless remux: the compressed frames are copied unchanged and only the surrounding framing is swapped for MP4 boxes. Audio, present only when the camera recorded it, is typically G.711 (A-law or µ-law PCM) or AAC.

Because the payload is standard H.264/H.265, a tool that understands DHAV framing can hand the frames straight to an ordinary decoder. That is the basis of the two practical facts users hit most: FFmpeg’s -c copy remuxes a DAV into MP4 in seconds without re-encoding, and a modern VLC (which uses FFmpeg’s demuxers) plays most DAV files directly. Where audio is G.711, only the audio needs re-encoding to fit an MP4 that expects AAC.

Scrambled exports and why VLC sometimes fails

Some Dahua firmware offers a tamper-resistant export mode that scrambles the file. A scrambled DAV does not present the clean DHAV tag at offset 0 that the FFmpeg demuxer probes for, so VLC and FFmpeg see no recognisable format and refuse it. Those files open only in Dahua’s own tools (SmartPlayer, or a brand build such as Amcrest Smart Player), which know how to descramble them. In practice this is the dividing line: if VLC plays the file, it is a standard DHAV export; if VLC shows nothing while SmartPlayer works, the export was scrambled.

Dahua’s players also verify an embedded watermark that detects tampering, which matters for evidential use. For footage handed to police or insurers, the recommended approach is to keep the untouched original .dav (which preserves the metadata and watermark) alongside any MP4 copy made for easy viewing, and to record when and how the copy was produced, since re-encoding can otherwise be challenged as alteration.

Why a single export becomes many DAV files

DVRs and NVRs segment their recordings by time block, by channel and by event, so exporting an incident that spans an hour can produce dozens of separate .dav files rather than one. Each segment is a self-contained DHAV stream. Dahua SmartPlayer can load a whole export folder and play the segments continuously as if they were one recording, and FFmpeg can concatenate them into a single MP4. This segmentation is a property of how the recorder writes continuous video to disk, not of any per-file limit in the format itself.

Deep questions about the DAV format

Why can DAV convert to MP4 losslessly, and when can it not?

The video payload inside DHAV framing is already an H.264 or H.265 elementary stream, the same coded data MP4 carries, so remuxing (ffmpeg -i in.dav -c copy out.mp4) copies the frames untouched into MP4 boxes with no quality loss. The exception is audio: if the recording used G.711, which MP4 does not normally carry, only the audio track needs re-encoding (for example to AAC) while the video is still copied.

Why won’t VLC open one of my DAV files when it opens the others?

The ones VLC opens are standard DHAV streams that begin with the DHAV tag its FFmpeg demuxer recognises. The one it refuses is almost certainly a scrambled firmware export, which hides that tag and can only be read by Dahua’s SmartPlayer or your camera brand’s equivalent player.

References