Convert DAV to MP4 with ffmpeg, without re-encoding

To convert DAV to MP4, run ffmpeg -i input.dav -c copy output.mp4. DAV is the container Dahua recorders write, along with the many recorders built on Dahua's platform, and inside the wrapper is an ordinary H.264 or H.265 stream. That stream can be copied into an MP4 in seconds with nothing decoded and nothing lost, and ffmpeg reads the wrapper itself (ffmpeg -demuxers lists it as dhav), so there is no renaming and no plugin.

The steps below cover the file that refuses to open, the one that plays at the wrong speed, the audio an MP4 will not take, the batch, and the check that no frames went missing. They end with what we do with the footage once it opens.

The warehouse has three years of footage on the recorder in the comms cupboard and a new project that needs a few weeks of it: the pallet aisle, morning shifts, forklifts coming and going. The operations manager exports the window from the recorder's own screen and hands over a drive with a folder of files ending in .dav and a copy of the recorder's player. The player runs on one old laptop. Nothing else on the site opens the files.

01Look inside the file before converting anything

ffmpeg -i camA_morning.dav

Run with no output file, ffmpeg prints what it found and stops. The line that matters is the video stream line, which names the codec, h264 or hevc, the resolution and a frame rate. That is the ordinary stream the next step copies, and an unencrypted export shows it here.

Two outcomes send a file to the troubleshooting section first. Invalid data found when processing input or could not find codec parameters on a recorder export usually means the export was encrypted and the recorder's own player holds the key. A stream listed with no duration, or with a frame rate that looks doubled, means the wrapper carries no timing and step three will be needed.

02Copy DAV to MP4 with one ffmpeg command

ffmpeg -i camA_morning.dav -c copy camA_morning.mp4

The flag -c copy is the whole command. ffmpeg's own manual describes it as copying the stream's packets "without decoding, filtering, or encoding them", and adds that because nothing is decoded or encoded "it is very fast and there is no quality loss". The H.264 bytes in the MP4 are the bytes the camera produced.

For a dataset that matters more than it sounds. Without the flag, ffmpeg decodes every frame and encodes it again, and the result looks the same to a person and slightly different to a model. A model that trains on a re-encoded copy learns the second encoder's artefacts, then watches a live stream that does not have them.

If the files will be scrubbed in a browser or served from object storage, add -movflags +faststart, which moves the index to the front of the file so a player can start before the whole file has arrived.

03Fix a file that plays too fast or too slow

Some exports carry a raw stream and no timing, and ffmpeg has to assume a frame rate for it. On a raw H.264 stream I tested, ffprobe reported a rate twice the true one, and a copy made from that file would play at double speed. The fix is to give ffmpeg the recorder's frame rate as an input option, placed before -i:

ffmpeg -r 25 -i camA_morning.dav -c copy camA_morning.mp4

The manual is specific about what that does as an input option: "ignore any timestamps stored in the file and instead generate timestamps assuming constant frame rate fps". The rate itself is on the recorder's export screen or in its channel settings, and it is the one number worth writing down before the drive leaves the site.

Check the result against the export screen:

ffprobe -v error -show_entries format=duration -of csv=p=0 camA_morning.mp4

A clip the recorder said was an hour long should report a duration, in seconds, of about an hour. Half that means the rate was wrong, and the export screen has the right one.

04Deal with audio the MP4 will not take

Some recorders store audio in a codec that MP4 players do not handle, and the copy then fails on the audio stream while the video was fine. Two fixes, and both leave the video bytes untouched.

Drop the audio:

ffmpeg -i camA_morning.dav -c:v copy -an camA_morning.mp4

Or keep it and re-encode only the audio to AAC, which every MP4 player reads:

ffmpeg -i camA_morning.dav -c:v copy -c:a aac camA_morning.mp4

For a labeling dataset the first is usually right, since nothing trains on the sound.

05Batch the folder and keep the recorder's names

Nobody converts a thousand files one at a time. A loop over the folder, writing each MP4 into a separate folder under the same name, is the whole script:

mkdir -p converted
for f in *.dav; do
  out="converted/${f%.dav}.mp4"
  [ -e "$out" ] && continue
  ffmpeg -v error -i "$f" -c copy "$out" && echo "ok $f" || echo "FAILED $f"
done

The name is what carries the camera and the start time through, since a DAV file holds the video and little else. Most recorders write the camera and the start time into the filename on export, so camA_morning.dav becomes camA_morning.mp4 with nothing about when it was recorded lost. If step three applied, put -r and the rate before -i in the loop as well.

Three habits are built into those five lines. The converted files go into their own folder, so a failed run is obvious. A file that already exists is skipped, so a rerun after a failure only does the work that is left. And each file prints ok or FAILED, since a batch that finishes with three failures in the middle looks like a success from the outside.

My own view is that a team should keep the DAV originals until the model has trained at least once. They cost disk space. Re-exporting them from a recorder that has since overwritten the window costs the footage.

06Check that the frames add up

A copy adds nothing and drops nothing, so the converted file should hold exactly as many video packets as the original, one packet per coded frame:

ffprobe -v error -count_packets -select_streams v:0 -show_entries stream=nb_read_packets -of csv=p=0 camA_morning.dav
ffprobe -v error -count_packets -select_streams v:0 -show_entries stream=nb_read_packets -of csv=p=0 converted/camA_morning.mp4

Two matching numbers mean the remux was clean. A smaller number on the MP4 means ffmpeg hit a corrupt section and skipped it, which is worth knowing before those frames are labeled. Then open a few of the converted files in any ordinary player and scrub through them: the pallet aisle should be there, the forklifts should move at the speed forklifts move, and the clip should run as long as the export screen said.

The operations manager checked the first file, found the aisle lights off, and realised the export had started at 5 am rather than at the start of the morning shift. That was an hour of black frames nobody needed to convert.

07When the conversion fails, what each failure means

The file will not open at all. On a recorder export this is almost always encryption, and ffmpeg cannot decrypt it. Go back to the recorder: the export screen usually offers MP4 or AVI in place of DAV, and that is the shortest route. Lorex's help pages say to pick .mp4 or .avi in the backup window instead of the default .dav. Dahua's wiki describes exporting a clip to AVI from SmartPlayer and offers MP4 from SmartPSS backup. Amcrest owners on the company's forum report exporting MP4 from Amcrest Surveillance Pro. Download a recorder's player only from the maker's own site.

ffmpeg sees the stream but the copy fails. Force the raw demuxer and give it the rate, -f h264 for H.264 or -f hevc for H.265:

ffmpeg -f h264 -r 25 -i camA_morning.dav -c copy camA_morning.mp4

The manual notes that "the format option may be needed for raw input files", and a DAV with its header stripped by an earlier tool is exactly that.

ffmpeg complains about timestamps, with warnings about non-monotonic DTS or missing PTS, and the output stutters. Ask it to rebuild the presentation timestamps from the decode ones:

ffmpeg -fflags +genpts -i camA_morning.dav -c copy camA_morning.mp4

The clip plays but breaks up partway through. The export is damaged at that point. -fflags +discardcorrupt tells ffmpeg to drop the corrupted packets and carry on, and the packet count in step six will show how much was lost.

Nothing above works and only the recorder's player opens the file. Export from the player, and if that is not possible either, re-encode as a last resort:

ffmpeg -i camA_morning.dav -c:v libx264 -crf 18 -preset medium -an camA_morning.mp4

This changes the pixels, which is what every earlier step avoided. Mark those clips in the dataset so the team knows which frames carry a second encoder's fingerprint.

One method that is not on the list: online converters. The footage is a site's own cameras, and it should not be uploaded to a website to be unwrapped.

08What happens to the footage once it opens

The converted folder goes into the labeling project from a drive, from Google Drive or from S3, and the import keeps the files as they are. Nothing is re-encoded on the way in. The quickstart covers the import and the first labels in the minutes after it.

From there, LexData takes the aisle model through its whole life. You type what to look for, forklift and pallet and person, Lexi puts a box on every frame, and a person checks each label before anything trains on it. The model then watches the aisle cameras the warehouse already has, in the cloud, on your servers, or on a runner beside the recorder in the comms cupboard, which the deployment guide covers.

Frames it is unsure of come back to a person, the corrections retrain it, and the new version replaces the old one with no downtime. The conversion is a one-time rescue of the archive; once the model is live, the recorder is watched as a stream and the DAV export is never repeated.

The old laptop with the recorder's player on it is still in the comms cupboard, because it is also the only machine that can change the recorder's clock.