As is the norm with a huge amount of proprietary video, the h264 standard seems to get a little stretched and as such becomes non-standard! Considering that the whole point of standards is to provide interoperability, the amount of tweaked formats does seem to be increasing and as such, causes more problems when trying to understand the video.
The video wrapped up inside a .har file that has been created using a COP DVR (Make and Model Unknown) is relatively easy to deal with but does highlight a few common issues. Along with the file there is a player named COPPlayer.exe. A plus point is that at least it displays manufacturer and version number that when checked on the COP website, did appear to be up to date. The COP website is not the easiest to navigate around when looking for video software, as each piece of software is linked to the individual DVR product. I find that by just typing DVR in the downloads search box will result in most being found and you can go hunting from there. Obviously, if you know the model number used, that is gonna make things easier straight away.
A quick look at the video within the player reveals that there are a number of video streams muxed together within the single .har file. I had three playing but had no details of how many had been downloaded to start with.
Each video has a camera number overlay. Although the video was playing in boxes 1,2 and 3. The third camera displayed the overlay of Camera 16. This would suggest that the DVR has the ability to record 16+ Cameras but only 3 had been downloaded to disk.
Investigating the .har file within HXD revealed MPG4 within the file header and the 000001 mpeg4 chunk identifier throughout the data.
Loading the file into Defraser resulted in a negative return. Defraser has received some good updates recently and although its free, the ability to identify and carve out h264 streams now comes at a price as this is a purchase only add-on. It does still deal with mpeg4-visual and other streams.
FFMPEG produced the same negative response with the ‘Unknown File Format’ text being displayed.
Mediainfo reported 7 Mpeg Audio streams. Obviously this was wrong but confuses the situation somewhat with the requirement now to establish audio within the file.
Count : 217
Count of stream of this kind : 7
Kind of stream : Audio
Kind of stream : Audio
Stream identifier : 0
Stream identifier : 1
Inform : MPEG Audio
ID : 196
ID : 196 (0xC4)
Format : MPEG Audio
Commercial name : MPEG Audio
Internet media type : audio/mpeg
Codec : MPEG-2A
Codec : MPEG-2 Audio
Codec/Family : MPEG-A
Compression mode : Lossy
Compression mode : Lossy
Upon investigation no audio was being recorded by the DVR. It is believed that Mediainfo has incorrectly identified the proprietary streams as audio as that is what it is reading. It cannot differentiate between a standard mpeg audio file and a proprietary video file. Further analysis of the files would suggest that there is an mpeg header for each video stream (3) and an mpeg header for each audio stream(3) and also an mpeg menu header. *Further work required to verify this!
Taking a closer look at the player revealed the option to conduct an AVI export. These can be deceiving as they regularly transcode and/or resize the original video. If done correctly they are very useful but it’s always worthwhile verifying any exports against the original to ensure that no transcoding or resizing has taken place. Transcoding is pretty easy to spot but resizing can be harder. The speed of the export function is a usual marker and if its quick to write the new file then this is commonly a sign that the file has not been transcoded. This was the case here. Although a point worth noting is that although the AVI tool identifies the video as CH03, it was actually the footage from Ch16.
To verify the data had not changed, the new video files were compared against the original .har using HXD. My method for this is to load the original .har file and the three avi files into HXD and then, one at a time, copy a chunk of data from each AVI and search for this within the .har file. I usually use a chunk from near the beginning and a chunk from near the end of the file just to be sure.
The result of this was that I confirmed that the data held within each avi was the same as the data held within the .har
All looks fine……however, when I look at the file size of the .har (115mb) and then look at the file sizes of the avi’s I see an issue! The three file sizes are added together and make 143.3mb. That promotes the question of what data has been added to make it bigger than the original?
I conducted the avi exports with the tick box selected for ‘include audio’. Upon conducting exports with this off, the file size was brought down to a more understandable size. No actual audio was found.
Time to examine the avi’s – Playback and scrubbing was completed in Virtualdub and although they did not scrub well, I could easily see that there was a lot of duplicate frames. Before looking at the files any further I required to understand their make up so analyzed them in Avinaptic.
h264 / AVC Codec with all the usual information was returned to me along with the structure of the h264 video.
35,885 Total Frames
28,707 Null Frames
Of these Total Frames, 288 were MPEG I frame frames and 6890 were MPEG P Frames.
6890 + 288 = 7178 frames.
Total Frames minus the amount of I and P Frames equals the total of null frames.
MediaInfo reported the GOP structure of 1 I frame to 24 P frames (GOP=25).
They both reported the same Frame size and FPS of 30.
The conclusion to all this is that each avi has a large amount of duplicate frames that are unnecessary and could complicate matters further in an investigation. When reviewing the files in Virtualdub again the frame identifiers can be seen and a duplicate sequence of between 4 and 6 frames was observed. The decimate filter can only be used when there is a standard pattern to the frame rate so this was not suitable.
Time to rewrap the video within FFMPEG to ignore the duplicate frames!
FFMPEG -i input.avi -an -vsync drop -vcodec copy -f avi out.avi
I told FFmpeg to rewrap the video using avi again (-vcodec copy -f avi) but to ignore the audio (-an) and most importantly to rewrite the Presentation Time Stamp (-vsync drop).
This resulting avi had a perfect 7178 Frames and upon analysis revealed the correct GOP structure of 1 I frame and 24 P frames. When scrubbing back and forth, there was no issues with the mpeg decoding and all frames presented themselves correctly.
The last thing was the timing. By using the timestamp on the video and moving through frame by frame enabled a visual establishment of 6 frames per second. Comparing and verifying this with the maths, using the total time of 19mins and 56 seconds (1196 seconds), if this is then divided by the 7178 frames it equals 6.001 FPS.
Using Virtualdub and changing the video framerate to 6 FPS changes the duration of the video to match the duration.
After all that… wouldn’t it be nice if that was what the DVR had given me in the first place and actually told me what it had placed on the disk.
Onto the next one………..!