Another one that requires a bit of understanding before anything gets done!
Note to DVR manufacturers: Please stop ‘modifying’ codecs so that they can’t be played without installing separate, proprietary software and can’t be understood effectively without unnecessary work.
The video files exported by the Digital Video Recorder are held within the standard AVI wrapper. The files in question did not include any player or help file but upon the usual examination of the files using gSpot, they required the FJHT Codec. The naming conventions were date and start time.
There is not a lot on-line regarding this little, but necessary, codec. It was eventually found on the PC based DVR in a folder named DVR Codec.
It takes a few years of trial, error, and trust for me to install a third party codec into any of my main systems so it was over to a Virtual XP Machine to install the codec and assess the video.
The install process was simple. It did seem a little more controlled than some other codecs we have to install in order to play a video.
It even comes with a fairly good config tool, an un-installer and a trimmed down WMP Classic.
Now that the VFW Codec is installed, things look better when we assess the video again in gSpot.
Although it now renders correctly and playback seems possible, there does appear to be a lot of frames…..time to take a further look!
Virtualdub reveals all – there are a huge amount of duplicate frames. The details were verified by Avinaptic.
Bitstream type: MPEG-4 Part 2
Aspect ratio: Square pixels
Quant type: H.263
Total frames: 44,993
Drop/delay frames: 40,445
Corrupt frames: 0
I-VOPs: 182 ( 0.405 %)
P-VOPs: 4366 ( 9.704 %) ##
B-VOPs: 0 ( 0.000 %)
S-VOPs: 0 ( 0.000 %)
N-VOPs: 0 ( 0.000 %)
So, out of 44,993 frames, only 4548 were actual frames. Things would be very easy if the frames had a constant pattern, we could just use the decimate filter within Vdub. However the pattern is variable. As an example here is the structure of the first GOP.
Each GOP is 25 true images but the amount of duplicates, and the pattern that they present, is different.
There is a possibility that an Avisynth filter script will be able to remove the duplicates directly from within Virtualdub, whilst inside the Virtual Machine. I am working on this and will update in the future, if I find a successful filter graph.
A number of questions now arise:
- Can we play the video without installing the codec?
- Can we manipulate / transcode the video if necessary?
- Can we remove the duplicates?
- Can we identify the GOP structure?
Regular readers may remember the IMM4 Codec article and how we identified it’s ability to play avi files using the IMM4 Codec. All we had to do was place the necessary .dll file in the Codecs folder. This was because the details for the codec were already configured inside the codecs.conf file. Unfortunately FJHT is not! Time to manually add it…
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 on the right side in the widget!!
The FJHT Codec install folder includes the required .dll file – FJHT264.dll. Copy this into the Codecs folder inside the main Mplayer folder. (Article on installing and using cmd tools)
Next, inside the main folder will be another folder called mplayer. Inside here you will find a file called codecs.conf – open this with notepad. Here you will see all the codec configuration scripts.
Add this text to the file, in the same format as the others.
videocodec fjht info "FJHT" status buggy fourcc FJHT driver vfw dll "FJHT264.DLL" #out YUY2 flip out BGR15,BGR16,BGR24,BGR32,RGB16,RGB24,RGB32 flip
Using Mplayer, I can now play the video inside Win7 without installing the codec.
Now that Mplayer can see it, we can obviously manipulate it using Mencoder. Due to the file containing such an amount of frames for a large period of time, I have found it necessary to deal with a small amount rather than the whole thing. The bigger the initial file the more chances you have of faults occurring. You may want to try the whole thing first and if you get the correct frame count then great. On my tests I was losing 8 frames when parsing the entire 44,993. I should have had a new file with 4548 but was only getting 4540. Obviously this is not acceptable. There are a number of ways to get a smaller clip to narrow down the work required and therefore eliminate the chances of losing frames.
If you have the codec installed and the file playing in Virtualdub, you can create a clip containing just your video of interest. Remember NOT to change the codec. Do this by selecting Video > Direct Stream Copy. Ensure you start at a keyframe and end on the last duplicate before another keyframe. In the example below I have used this method as it provides greater transparency in the video workflow.
The other option, if you have not installed the codec and are completing the entire task with Mplayer and Mencoder, is to identify a start position by navigating through the video and identifying how long your required portion lasts. You would then have to add in the parameters of -ss (start seek) and -endpos (end position) to the command line script below. Remember that this has to be in time reference and not frame number. So, -ss 36:00 would start 36 mins in and -endpos 60 would end encoding 60 seconds later. I would only do this if the identity of the I frames was NOT an issue. I may just want to discard the duplicates.
So, using the Virtualdub method, we now have a clip of the original video covering only our part of interest. It consists of 1713 frames and the avinaptic report details 7 Keyframes, the ‘I’ frames, and 168 P frames. So, if we want to remove all the duplicates we should be left with 175 frames and every 25th frame will be the I frame.
mencoder input.avi -noskip -vf decimate=-0:99999,flip -ovc raw -ffourcc RGB -nosound -of avi -o output.avi
This results in an uncompressed avi file containing 175 frames, no duplicates and every 25th frame is the I frame.
To conclude, we can now deal with the video for any requirement. It is interesting to see the footage now, in it’s cleaned up format. It’s very easy to see the variable frame rate of 2-3 FPS and that there are approx. 9 seconds between I frames!
The workflow would now be:
Original file into Virtual Machine > Play using Codec inside Vdub > Select part of interest > Save clip without re-encoding > Remove duplicates from clip file using Mencoder.
During the workflow, I would obtain Avinaptic and other video analysis reports to ensure documentation of every change.
I hope that this has highlighted a few options when dealing with codecs and another way to get the video into something a little more versatile.
I have added the FJHT Codec to my shared Box account that is accessible from the widget down the right side.
See Portable SMplayer with Codecs preconfigured for further help.