A few different players have crossed my path in the past few weeks but finding the time to write them up is becoming more and more difficult! I have also had a few that have totally beaten me due to their terrible structure… but that’s a story for another day!
There are a number of DVR’s and Manufacturers that export into a file with the .irf extn. This disk export comes with a player called ifileplaypack.exe but I have also seen it named ifileplayer.exe
The export disk structure consists of the player and then a selection of .irf files with a naming convention consisting of date and time: Example- 20130221_162545.irf
The lack of details in the player properties is becoming a very bad common practice!
At least the player doesn’t need installing. It runs by itself and you are required to then locate and load an .irf file by using the open dialogue at the top. It starts in multi-cam view.
The choices when in the player are limited. You can choose your view, have basic play controls and grab a bmp image using the button towards the bottom left with a circle and folder icon…. why they didn’t just use a camera icon is beyond me!
In Single Camera mode, you can turn on or off the audio if that’s been utilised within the premises.
There are no Frame FW/BW buttons. There is no export button. There is no way of verifying the image that the player exports. Dealing with the video then, from within the player, is pretty difficult.
Dropping the .irf file into MediaInfo gives me the first clue. Its detected as a single AVC Stream at 704 x 576. At least that matches the resolution of the images that the player outputs.
Running it through FFprobe, after forcing it to be read as a h264 file, also identified the video as a single stream or over 19000 frames! We already know that there is more than one camera so it appears that they are all being read as one continuous file, and as such needs sorting out.
As the camera streams are not being dealt with in a standard way (stream mapping), it is sometimes possible to identify the structure within a hex editor and carve the parts of the file out. Upon dropping the .irf into HXD, a clue!
At the start of the IRF file within the text was the word ICATCH. Rather than go to all the effort of identifying the video make-up – a Google and subsequent research revealed the iCMS software by iCatch. Included with this was a little tool, funnily enough called irftool.exe.
Update 15:03:2013 – This IRF Tool and Playback tool has been updated in the last few weeks. You can get the new version by selecting Applications under the select category box and the option is now a separate download called iFileplay. With the player comes the newly designed IRF Tool. It calls the process a transfer but works in exactly the same way as detailed below.
This turns out to be a carver and wrapper all in one!
Remember: These ‘Converters’ can be a little unreliable and in some cases completely screw up a working system. Some, the ones that usually require installing, come with codec packs built in and they can conflict with your directshow codecs. I speak from experience that if you need to install something like that – do it in a virtual environment.
This one though is a stand-alone tool that outputs separate h264/AVC .avi files for all cameras within the original .irf
2248 Frames read but they were all shown as Keyframes!
Obviously, a h264 made up of all I frames would be rather unusual so a verification of the data was required first. Was the data in the .avi, the same as the data within the .irf?
By comparing the data, this was verified.
The next point was the make-up of the file, the GOP structure etc
The .avi was examined with MediaInfo and Avinaptic but both were not reading the GOP structure as I would normally expect.
Using FFprobe to examine the stream and GOP structure revealed more:
codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
It was a standard h264 but the avi wrapping seemed to be causing it a few problems. FFprobe however identified that 2248 frames made up the video stream but only 2243 were being read. From reviewing the GOP, this detailed that the stream started at Coded Picture number 5 and finished at 2247. Frames 0-4 were duplicates of the first I frame.
This was checked by removing the h264 file from within the avi container.
ffmpeg -i filefromcam5.avi -vcodec copy cam5raw.h264
This new file was read perfectly within mediaInfo, even showing the GOP structure. The duplicate frames were seen at the start of the file when previewing.
I hope that this has highlighted that sometimes, a bit of digging around in the file can really help and give you something to search for. It has also highlighted the importance of checking all the numbers relating to the frame count in order to establish exactly what is going on and why.
I would hate to be asked “where are the 5 missing frames you have removed?” and not know the answer!!
After a few troublesome IRF Files, I have collated all the various players, wrappers and CMS Tools that I have been able to find. The DVR’s appear to be a mixture of rebrands such as the Security Labs SLD 265 https://www.security-labs.com/dvrs.html
The IRF.zip is over in my shared box – might save you a few hours of Googling! If you find another piece of linked software, such as a different version, let me know and I will update the .zip