Another strange one!
The disk comes in a common structure with a selection of .umv files, each with an associated .idx file. There is also a .cdb file. After taking a look at the .cdb file in a hex editor, it appears to be a file that relates to the specific DVR and lists the camera numbers 1-16. The idx files aren’t readable but I imagine that they are the date time indexes. It all makes sense when we launch the SimplePlayer_M4.exe
After Launch we see a calendar search which automatically detects the files inside the folder.
After selecting play, the main interface appears.
The player links to the .idx files but, through testing, it can also play the .umv files directly and still reads the date and time. The date and time appears along the top with all the camera views in square boxes below.
Theres not a lot else really. There is an about dialogue box but it doesn’t give anything away.
The problem though, is that there is no method to extract native video or still images from the player. There is no information on how to do this and when playing back the picture is distorted as it’s squished into the square window.
The .umv files are in a naming convention of date and time. The files are in 5 minute intervals. I therefore have five files of five minutes length and each one holds 9 camera streams.
A quick FFprobe of the first .umv file reveals all within a text file. The command being:
ffprobe -show_streams -count_frames -pretty firstfile.umv > firstfiledetails.txt
It shows 9 streams of MPEG-4 part 2 video at 352 x 288, and produces a frame count for each. It also shows the duration. Doing the math for the frame count and duration of each stream reveals a variable frame rate of between 6 and 7 frames per second.
Its quite easy to go through each stream view in FFplay with the following command
ffplay -vst 0 inputfile.umv
The number after the -vst equates to the stream number you wish to view. In the example above, I would be viewing Stream 0….. the first stream in the file.
It would then usually be pretty easy to identify the stream required and then map this out of each .umv file. The problem though is that in the example here, each .umv file had the cameras mapped to different streams! In the first .umv file the camera required was stream 6. In the second it was the same camera but it was stream 0!
I have written about stream mapping before but just to recap. The FFmpeg commands for the example here would be:
ffmpeg -i firstfile.umv -map 0:6 -vcodec copy -f m4v firstfile_stream6.mp4 ffmpeg -i secondfile.umv -map 0:0 -vcodec copy -f m4v secondfile_stream0.mp4
I now have two .mp4 files of 5mins length of the camera I require. They play in a variety of programs, such as SMplayer.
For frame accurate scrubbing it’s possible to individually rewrap these into a container if need be and this would be the best course of action if only dealing with a small section or if you required to extract still images from the stream.
The final issue is joining the files together. Again, FFmpeg is used with the ‘concat’ command.
ffmpeg -r 6 -i "concat:file1_6.mp4|file2_0.mp4" -f avi -vcodec rawvideo joined.avi
This then outputs a 10minute uncompressed file with a frame rate of 6 FPS. It was necessary to place the -r 6 before the input parameter as they had very slightly different frame rates. One was 6.03fps and the other 6.06fps.
On checking the frame count, both streams had 1797 frames and when checking the new file, it read at 3594. No frames missing.
Its worth mentioning that the second file had 4 duplicates at the start of the file. This was due to it not starting at an I frame so in some analysis it was reporting 1801 frames but only 1797 readable.
So, if you come across these files – they can be dealt with, but in rather time consuming way!
December 2013 Update: This may make things a little easier:
There is a UMV to AVI converter for the M4 Format UMV’s. It can be found here. Remember the warning for using converters. It may change the make up of the video, it may install codecs and filters on your PC. Use carefully!
I have tried it, but cant verify the quality yet…. The AVI’s crashed windows explorer in XP with the old faithful error of SHMedia.dll. Hadn’t seen this one in a while but its caused by badly encoded video files crashing the windows media handler!
Took a look in Win7 – It crashed both Mplayer and Vdub!
YOU HAVE BEEN WARNED – Although I may have just been unlucky!!
H264 – If you are unlucky enough to have the newer SimplePlayer_H264, you may want to take a look here!