I have had a few emails surrounding these files over the last few months so thought it worthwhile to share my findings.
First up, hopefully your .ave files have been supplied to you with some software. This test footage came with a standalone player.
Why? Well although the player is downloadable….
apparently you need a licence key!
I would love to have tested this, but unfortunately a number of the download install links failed during my testing. If it does start working and you give it a go – if you do require a licence key – please add a comment and let me know.
Note to Avigilon – After an Evidential Export, the next most important task is to facilitate immediate playback of that footage. Players should be immediately available online, they should not require a licence and should not require installing. Remember – most corporate computers are behind very secure and controlled IT systems.
UPDATE (22/10/15) – Thanks to a bit of research by another analyst, the following FTP site gives a link to a standalone Player:
That makes things a little easier!
OK, where was I?
The standalone version of the player supplied with my test export reports version 188.8.131.52.
After running the player, and then opening an.ave file, the standard player interface appears.
Date and Time Overlay, Timeline scrub bar, player controls etc etc…
With a right click, and selecting camera properties, we get some useful information. The camera was a H264 ONVIF Standards compliant and it was recording at 720×480.
Again, under the right click options we get an export frame function.
This is worth highlighting due to the controls that a user has in exporting images. A user can control the region,format, resolution, and colour and intensity levels.
The result being that it would be possible to receive an uncompressed image, exported from this player – but it being cropped, re-scaled and having incorrect colour and levels. Worrying.
Up in the top right, we have some options hidden away under a settings icon.
The first one of note being “Authenticate Images”.
The important information here is that the software is reading 531 frames. We can use this information later…
For now though, what information is under ‘Player Settings’.?
Knowing that these settings are here could be important, especially if you are dealing with an interlaced source. Another issue, that could affect validation processes, is the display quality. Taking a screen grab of a correctly scaled image and comparing that to exports or recovered video data is often a way to assess video quality and identify any player processing. I think i’ll change this to Maximum – why would I want to see an image of a lower quality than the original?
Nowhere could I find any method to export the video… until I received a friendly nudge to check out the small + icon in the top left.
So, that’s where the EXPORT was hiding!
There are a number of options for export format. In the example above I have used TIFF images. Be careful of the resolution options. In the next export test I chose AVI…
There is a choice of codec, with none being uncompressed – so it should be the same as the original! There is no choice for original – No transcoding.
At the end of every export, a little message appears. The frames exported match the number of ‘authentic frames’.
Now that we have some exports to use in our analysis, lets dig a little deeper into this .ave file.
The camera stated that it was an ONVIF Compliant H264 – that’s a good start point as hopefully this means that the stream is a standard H264.
To make things easier, I have conducted all my analysis and file quality comparisons in Amped FIVE.
After dropping the .ave file into FIVE, it has opened immediately, using the Directshow video engine. All initially appeared OK but after taking a look at the frame count..
This read 453 frames. How many were reported by the software as authentic? – 531!
With 78 frames missing it is clear that Directshow is not reading the H264 correctly. Before doing anything else, what about the TIFF sequence?..
These dropped in without any issues… what about the uncompressed AVI?..
Again, no issues…. but…. they were different. Look at the Histogram and values. The AVI was much darker.
I mixed the two (The TIFF and the AVI), and had a look at the difference. I have accentuated the difference here to make it visible. If they were the same – it should all be black.
So, Directshow misses frames and the TIFF’s and the AVI are different…. Back to the .ave file!!
This time I loaded the .ave into FIVE using FFmpeg to wrap the stream. This is completed from within the Interface using the Convert DVR tool.
We now have 533 frames!… i’ll come back to that in a moment but the raw data was read perfectly.
It would appear that both the Tiff and AVI exports go through some level adjustment during the export from the player. Not a big deal for many tasks but it could interfere with analysis and enhancement of small details. The difference is more than I would expect from a standard YUV to RGB conversion.
Where have those extra 2 frames come from? The last 2 frames in the rewrap are duplicates. This is due to the embedded presentation time stamp (PTS) holding the last frame for that duration.
I checked the timing by adding in the timecode to match the player.
This was frame accurate with the milliseconds matching the player, the AVI and the TIFF sequence.
So, in conclusion….
- The player has its faults but the functionality of the exports are suitable for validation purposes.
- The exports do suffer with some hidden processing during transcode.
- The H264 stream can be read by Directshow but be careful of missing frames.
- FFmpeg can rewrap the stream and the PTS is read correctly.
As always, I hope this helps in the never ending, but rewarding, challenge of Forensic Video Analysis.