If this is your version of SimplePlayer, and not the M4 version discussed here – prepare to be disappointed! (Dec 2013 Update: GOOD NEWS – See Report at bottom)
The disk format is the same as before. There is a .cdb file that details the playlist of UMV files. Each umv video file has an associated .idx file containing timecode and then there is the player and it’s linked files.
These linked files, avcodec-52.dll etc are the open source video library files that enable the software to correctly read, control and render the video on the display. My hopes were therefore raised that we would be able to effectively deal with the video!
The reason for this is that the player suffers from the same problems as the M4 version.
Upon opening the player it automatically detects the presence of video files and an index page appears. When the data is selected, the player disables all visual themes in Win7 and the video plays.
The problem of not being able to do anything with the video is a big challenge, and one that could be overcome when the company involved here retained the M4V standard and used stream mapping to separate their camera streams.
With the H264 version things are different.
The player does not display the video as it was recorded. There is no method to do so. There is no method to identify frame type. There is no method to extract an image. There is no method to remove the video from the inferior and restricted interface.
From analysing the UMV streams and identifying the .h264 frame headers, it would appear that some form of modification is being used to separate the individual cameras. Usually the stream itself would be able to be identified as h264 video but these are not.
So, at the time of writing, we are hitting that common brick wall of being denied the information required by a poorly designed and implemented system. This one is now a work in progress and if I or anyone else figures it out, I will update the post!
Dec 2013 Update:
These things always come back around and tonight I have had to make a concerted effort to figure out what was going on. My attempts to manually decrypt the h264 streams failed so reverted back to researching players and clients that ‘should’ have the capability built in.
My research led me to a resellers site in the UK and then an installers site in Australia, with a set of DVR’s branded as XDH & UNIMO
On here were a number of players….
and then the UMV H264 Converter…
This ‘converter’ worked much better than the MP4 version detailed in the SimplePlayer_M4 post. It retains the h264 coding and keeps with the original recording resolution. Upon comparison of the raw data, the hex matched.
It would appear that the index structure is removed from the UMV file. The index helps the simpleplayer control a video backwards – something that is a bit tricky with h264 mpeg video. After the index is removed, it gets placed into the .avi container through a re-wrap process.The .avi itself is still not perfect. It did have problems scrubbing and some software could not detect and read the frame type (I,P etc). The added empty audio stream may not have done it any good! A simple removal of the audio, a re-wrap and a re-index in FFmpeg solved the problem.
ffmpeg -f h264 -i problemfile.avi -an -vcodec copy -fflags genpts -f avi newcleanfile.avi
So, a minor breakthrough!!
As always, hope it helps….. and the Players and Converter are in my shared Box on the right (UMV_H264). IMPORTANT: Avast AV software detects the two players with network interfaces as suspected Malware. I believe this is due to their ability to communicate over a network. Please ensure you have up to date AV software – just in case!