This has been on the ‘to do’ list for a little while. It’s time to grab a coffee and get to grips with MEncoder in order to deal with footage encoded using the IMM4 Codec.
There appear to be a number of DVR’s that utilise the Infinity encoding chip. As such it is difficult to specify manufacturer or DVR Model. It is highly likely though that each manufacturer, or should I say system builder (most don’t actually make anything themselves), utilise the same SDK’s, so the playback functionality should be pretty common to those dealing regularly with CCTV Footage.
The folder structure, either on disk or USB Device, is pretty simple.
We have a player, the video footage inside an avi container, a text file detailing the export process and one detailing the Motion Detection activations. We also have a set-up file to install a codec.
Looking at the player first, when it runs, I notice a small uncompressing dialogue box appear. By looking at this, it reveals that this is just a self executing file to uncompress the player into my C:\Temp folder. Looking in here reveals the actual player. By looking at its properties, I find a few issues that cause a little concern.
With little information, I am not going to be installing any codec into my working machine that has the likelihood of screwing it up! I will leave the codec install until later – and within a Virtual machine.
Now we know where the player is, I can copy all these files out and save them into a new folder for permanent usage without having to extract every time. Opening the player and loading the video hits another problem.
The player’s video overlay functionality doesn’t like Windows 7. I can see the information such as resolution, date and time etc. but no video. Time to hit the Virtual Machine.
Running the player in a WinXP SP2 VM produced a similar problem, although this time the video screen was black. I have seen this before when using Virtual PC’s and always suggests a graphics issue with the playback program. Whilst in the VM though I can take a look at the codec install.
I have started to log what is being done when I install certain types of software. This helps in identifying what is going where and what is being changed. Check out Whatchanged.exe
By installing the codec, I could review the footage easily in Virtualdub, identifying the mpeg4 structure and the inclusion of duplicate frames. By analyzing the results from whatchanged.exe I could see that the codec installed was VCMIMM4.dll and this was in the Windows/System32 folder. The registry was also updated and the codec was registered with the windows media handler. It’s this registering that often screws up a system when installing proprietary codecs.
At this point I needed to attempt two things. Firstly to get the footage playing within its player in Win7 and then to figure out how to deal with the video.
I copied the .dll codec file out of the virtual machine and did a bit of research.
It turned out that this codec is supported within Mplayer!
Mplayer is able to play files independently due to having its own Codecs folder. By placing the VCMIMM4.dll file into this folder and then opening the avi file within Mplayer, it played in Win7 without the need to install the Codec. I actually used the standalone SMplayer GUI found in my software pack but it will work in any flavour of the software.
Next it was onto the proprietary player in order to visualise the date/time overlay along with the video.
Back to the Virtual machine again, I installed the latest Network client for the DVR where this export originated from. Part of the install included an archive player that was an updated version. It is not available by itself but comes built into the client. By removing this part only from within the Virtual Machine, it could be used for standalone playback within Win7.
So, we are getting somewhere now….. we can play it within its player, we can see it within Vdub and deal with its information within a Virtual PC and we can play it using Mplayer within Win7 by using its .dll codec.
From running a few tests I was concerned with the fact that the video was being presented in all software as 704×576 however the overlay information revealed 352 x 288. When using the Backup Player, it produces still images at 640×480! It turns out, after extensive research, that the video is recorded by the DVR at 352 x 288 but it is exported at 704 x 576. THERE IS NO WAY TO GET AROUND THIS. It happens automatically during export from within the DVR! You need to be aware of this horrendous issue. Again, who comes up with these ideas?
Lastly, as we can now deal with the video, is it possible to get this into some understandable format for investigative use without the need for a VM?
MEncoder can also read the .dll files that are acceptable to Mplayer. As a result it is possible to deal with the video from the command line using MEncoder.
16/05/13 MEncoder Update – I was informed today that things are now slightly different with the Windows builds. Upon checking there is a new method to compile Windows .dll codecs. I will get around to doing a new MEncoder guide but in the meantime I have placed an older version with the Codecs.conf file in my shared box. It’s on the right side in the widget!!
I used the
latest MEncoder build and then worked out the following command:
mencoder input.avi -endpos 200 -ovc raw -ffourcc RGB -nosound -of avi -noskip -vf decimate=-0:99999,scale=352:-2,flip -o output.avi
Breaking this down:
mencoder > use mencoder
input.avi > the file to be transcoded
-endpos 200 > this was a test file so wanted to end the transcode after 200 seconds
-ovc raw > Output Video Codec as Raw Uncompressed Video
-ffourcc RGB > add fourCC code RGB
-nosound > Don’t include audio
-of avi > Output Format AVI
-noskip > Do not skip frames
-vf decimate=-0:99999,scale=352:-2,flip > This is a list of three filters. It starts with a decimate filter detailing that if the frame is the same as the previous one, it can be removed. Then it is scaled back to its original size. Finally it is flipped. This was found to be necessary as the transcoding process reversed the image.
-o output.avi > your file to be created.
After successful testing, I identified the period of interest with Mplayer and then changed my command to:
mencoder input.avi -ss 38:00 -endpos 60 -ovc raw -ffourcc RGB -nosound -of avi -noskip -vf decimate=-0:99999,scale=352:-2,flip -o output.avi
The -ss means start seek, so I have stated that the encode starts at 38mins and lasts for 60 seconds (-endpos 60). Remember that this is 60 seconds of video time and not realtime. The player indicates that it should be 12FPS. I could add in to the command -f 12, but I prefer to do this during any presentation transcode and not for frame / image analysis.
I now have an uncompressed, frame only video clip that can be reviewed in Vdub frame by frame and exported to image sequence if necessary.
As this was transcoding at 150+ FPS, this is a very fast way to get the video you require from a large IMM4 based AVI.
To help, I have packaged up the two players, original and new, along with the .dll file and the codec install. It is in my BOX shared files.
Update: This zip file now includes another version of the player that supports the IMM5 and IMM6 Codecs. Also included are the dll files for those Codecs and the Codec installs.
I have found Mencoder to be another really handy tool and learning some of the commands will surely come in handy in the future. It’s ability to read VFW dll’s makes it very versatile.
See Portable SMplayer with Codecs preconfigured for further help.
If you have audio or only require a basic Video DVD copy then this may help. IMM Update