We can deal with the video, but it is ridiculously difficult, and highlights the problems caused by poor exports.
We start off with a disk loaded with content. It’s always interesting to see players using ffmpeg.exe and the avcodec-52.dll
avcodec.dll is an open source LGPL-licensed library of codecs for encoding and decoding video and audio data. Many third party applications that require video encoding integrate this LGPL library within the program for video playback functionality.
This usually means that the player is using a standard codec and it may also be possible to to rewrap and transcode from within the software. The other point that immediately stands out is that the file extension used by the largest file, looks very similar to mjpg – motion Jpeg. If this is the case, and we can deal with all of the video from within the player, then that would make things easy.
The first thing is to check out the player….
GUI-ARCH.exe obviously stands for Graphical User Interface – Archive. When it loads, the video window is empty until you double click a camera that is listed down the right side. There were no details within the software regarding manufacturer, and the Help button didn’t do anything! The Archive menu item just brings up the option to open a new archive file or folder.
Before figuring out the player, I went back into the folder structure and took a good look at all the files and their properties, looking for some company details. Inside the icons folder was a splash screen image.
A quick Google of this reveals http://www.cathexis.co.za/ They have a software section on the site but it requires a username and password. I cant find any assistance for playaback or investigative support.
Back to the player…… Scrubbing through forward and back, and using the time overlay on the video, I identified two images displayed every second. I was pretty confident on a jpeg based format after watching the footage so it was interesting to see the save image result. It produces a jpeg at 746 x 598. This seemed a strange pixel size. The time overlay was not on the resulting jpeg so I didn’t think that it was just being screen grabbed within the player….. wrong – it was! When measuring the video window within the interface, it was the same size, 746 x 598.
So, if f this is the image size being produced, is that the size of the images that make up the video? Before looking further I figured out how to export the video.
You are required to set a pin marker at your selected start point and then another at your end point. When these are in place, the times will display at either end of the lower blue bar. Its at this point that the disk icon becomes usable.
Export to Archive gives you another sjpg file.
Export to CD/DVD gives you the same as what you have already have.
Export to AVI….. It was at this point that I expected the players in-built ffmpeg library to kick in and, either get given the option to chose a transcoding format, or simply rewrap the sjpg into a mjpeg avi.
I MUST STOP USING COMMON SENSE WHEN DEALING WITH CCTV PLAYERS!
The resulting .avi is transcoded, using the WMV1 Codec, at 2.083 FPS and with a frame size of 352 x 288! That wasn’t expected… time to have a closer look at the sjpg file.
HXD revealed the existence of the jpeg headers…. and taking a closer look revealed how many. 265!
Next then it was into JpegSnoop, in order to take a closer look at these images.
It’s at this point then, after identifying that the file is a straight forward list of jpeg images all at 352 x 288, one has to ask why the player’s image export produces jpeg’s at 746 x 598 and the video export gets converted to WMV? I would have loved to have been in the software designers meeting when those were agreed!!
Anyway, we are now getting somewhere…. whilst JpegSnoop was running, I exported all images out. This can take a little time if you have large files with thousands of images.
This resulted in 265 Images. A quick bit of maths was needed to check the frame rate. When originally played within the player, I noted two images every second. 265 / 2 = 132.5
132.5 equals 2 mins, 12 secs, 500 milliseconds. Here lies a problem – my footage time was just short of 2mins!
I ran a hash check across all the images.
MD5Summer revealed that throughout the folder full of images there were a number of duplicates. In the image above I have highlighted just the last ones.
I therefore used Duplicate Photo Finder to find and move all the Duplicates to a separate folder. I set the differences to 100% and was left with 234 unique images.
I went back to the player to check a few things and used the Omnivore to capture the footage in order to review what was being displayed. This captured 236 unique frames! I scanned through and found two images where the time overlay changed but the image did not. From this I concluded a number of things.
We actually had 234 images as found by the jpegsnoop export but more importantly, the amount of images presented had been altered by the software to meet that of the time index. It appears to have been altered, and the duplicate images added when exported from the DVR and that’s why the file presents a large number of duplicate files. Having the time change, when the image stays the same also means that it needs to be verified in order for it to be truly relied upon. How can the same image be recorded at two different seconds?
All of this work led me to try and establish what was going on.
Using FFrobe, I found another issue!
ffprobe -f mjpeg -show_streams -count_frames -pretty inputfile.sjpg > fileprobe.txt
This resulted in the following output:
codec_long_name=MJPEG (Motion JPEG)
Having it read 262, and not the 265 found by JpegSnoop, gave me some cause for concern. I ran a few other tests in an attempt to establish the causes of the frame differences. Using FFmpeg and attempting to rewrap the sjpg into a standard avi with the same codec worked great…but produced a file with 264 frames!
Just to refresh: we have 265 Jpeg headers, 265 Images extracted, ffprobe states 262 frames, re-wrapping to .avi gives 264 frames….. but we actually only have 234!!!
This really does highlight the importance in assessing your proprietary video files. If you are relying on the timing information or the frame rate and things don’t look quite right, it may be worth double checking to really be clear on what you are being presented. When playing through, the duplicates are really hard to spot. I can only see them now as I know what to look for.
In all of my testing I have attempted exports using ffmpeg and then outputting to single frames using the -f image2 function. I found that this dropped frames, even when I slowed down the read rate. The .avi exports, keeping with the mjpeg format, still had the duplicate frames and as they had different time stamps, they could not be removed using the usual -vsync drop method.
The final result is that in the future, I will skip all of that and just rip all the images out using JpegSnoop and then remove the duplicates using Duplicate Finder. I will then batch re-name sequentially and then place them all into Virtualdub as an Image Sequence. Using the time overlay from the original player we can work out a frame rate.
Why didn’t the developer just create the exports in the correct size, and with the correct frame rate, and to the correct time, and the correct amount? Oh well – I guess we’ll never know!