Sometimes, things are not what they seem!
Update: Important further information on this codec can be found here. I have also placed a link at the end of this report.
Before I start, let me just state that I do not think these files have any connection with the Tenvis .V264 files detailed here.
We start our journey with an AVI file that will not play. After trying the usual software players (WMP, SMplayer and Virtualdub with various input drivers including ffmpeg), I finally attempted playback with FFplay. This was the one bundled in my software pack. It was built using the FFmpeg build of 10/10/2012 which is now rather dated. It would not play even when forcing the input as h264.
ffplay –f h264 incident.avi
If you are new to using command line tools, take a look here.
From there I needed to have a look at the file data. Gspot and AVInaptic both appeared to read the data and both reported a FourCC of V264. This usually means that the file requires a codec that is specific to V264 in order to decode and render the data correctly.
During the data analysis I noted a number of figures that appeared wrong.
The AVI resolution was shown as 704 x 576 but the data stream resolution was 704 x 288. The Frame, Pixel and Display Aspect Ratio’s were also all different values.
[ Video track ]
Resolution: 704 x 576
Resolution (bs): 704 x 288
Frame aspect ratio: 11:9 = 1.222222
Pixel aspect ratio: 6:11 = 0.545455
Display aspect ratio: 2:3 = 0.666667
Framerate: 6.25 fps
Total frames: 3,763
Next it was into HXD, in order to take a look at the raw data.
This all looked normal with the .avi header showing the V264 codec markers and the first mpeg frame header was easily identified (00 00 01).
Just to let you know, the answer to repairing this video turns out to be quite simple but the route I took to establish this fact is worth detailing!
I first removed the header from the .avi file. I deleted all the data up to the first mpeg header and then saved this as a new file. Upon placing this new file into ffplay, using the –f h264 flag, it played!
We are over the first hurdle, although interestingly, it played within a square (ish) window. This appeared wrong due to the stream being 704×288.
After establishing that the AVI header was causing a problem, probably down to the V264 4CC, I wanted to test this theory. I changed the V264 code to H264
This was completed with the 4CC Code Changer.
The new file played in all programs first time! The company behind this video file may well have a V264 Codec but it appears to simply use the H264 algorithm.
It’s not over yet though, as there was still the issue of resolution and aspect ratio to deal with.
Having identified that the version of FFmpeg that I was using could not deal with the avi header, I updated to the latest version from Zeranoes windows builds.
The original file played first time!!
This highlights the importance of keeping your software updated and continuously identifying new versions. With a number of command line interfaces, it is worth keeping a number of versions, especially if one has been configured specifically for a certain purpose.
With the latest FFmpeg build, it was over to FFprobe for some information:
ffprobe –show_streams –count_frames –pretty incident.avi > incident-ffprobe.txt ffprobe –show_frames –print_format xml incident.avi > incident-frames.xml
The first command verified the results from previous analysis programs and the second produced the XML table detailing the exact frame structure.
Using this information, and the new ffmpeg, it was now possible to repair our video file so we can start with exactly what was recorded, not a distorted version! It was necessary to use the file with the header removed in order to ensure no trace of any aspect ratio flags were retained.
ffmpeg -f h264 incident_header-removed.h264 -vcodec copy -aspect 176:72 -vsync 0 -r 6.25 -f avi incident-new.avi
Before the input file we have –f h264 to ensure the file is interpreted as a standard h264 stream. After the input file we have –vcodec copy to ensure the video is not transcoded.
After this we have –aspect 176:72
This was calculated by using the following:
The Display Aspect Ratio can be calculated from the Pixel Aspect Ratio using this formula: DAR = Width/Height * PAR.
This ensures that the original Display Aspect Ratio of 2:3 is overridden and the new .avi file will retain its square pixel, native ratio.
After that we have –vsync 0 to ensure the original timecode is retained.
The original frame rate of 6.25 FPS is then retained by using the –r command.
After testing this video in various players and seeing that it was not being automatically resized, I verified the aspect settings by creating a test video in Virtualdub. I used the same pixel measurements of 704 x 288 and then encoded to H264.
ffmpeg –i virtualdub_720x288.avi –vcodec h264 virtualdub_720x288_h264.avi
The results were compared to my newly created incident file and they matched.
Finally then, how should it be displayed, according to what the data is telling us? FFprobe can identify each Sample Aspect Ratio (SAR). This is the H264 term for Pixel Aspect Ratio and is taken from the original file.
In the original file, each pixel should be displayed nearly double in height with a ratio of 6:11.
704 x 6 = 4224
288 x 11 = 3168
4224 / 3168 = 1.333
1.333 = 4:3
The data is therefore telling me that for correct image representation, it should have a 4:3 Aspect Ratio. FFmpeg presented this as a D.A.R as it is able to work this out from the S.A.R automatically. Therefore, if we are retaining square pixel’s, the image should be 704 x 528. Obviously this would not be suitable for outputting to another TV source, such as Video DVD and in those cases the non square pixel size would be taken into account.
The problem though is that we really have no idea exactly what it should be. If we just doubled our height making 704 x 576 then this would give a display aspect ratio of 11:9. Increasing to full D1, 720 x 576, gives 5:4. The software creating the original AVI has placed a flag detailing that it must be played at a 2:3 aspect ratio! There is a possibility that it started out as 640 x 480. It could have started out with non square pixels within an analogue camera and then digitized. Without a complete assessment of the infrastructure along with capture and recording facilities, it would be wrong to rely wholly on the data being presented. With this file in particular, there is a very good chance that it may have been transcoded from the original recording. A naming convention with words and no date / time information on the video – has this been changed?
This pixel manipulation by companies purely to save space needs to stop. If the camera captures information at a 4:3 resolution then that is what must be recorded. Not a squished down version, and then manipulated to bring it back up. You cannot lose 50% of the image and then think that the quality will not suffer. Especially when dealing with highly compressed predicted frames that make up 96% of a video file.
In summary, the workflow was:
- Create analysis reports of original file (I used AVInaptic and FFprobe)
- Remove AVI header
- Rewrap h264 stream with correct AVI details
- Create new analysis reports of new AVI using same software as before in order to compare results
- Compare raw data in hex editor to verify no transcoding
In a few frame comparisons, I noted an increase in quality in a frame extracted directly from the stream and then resized in Photoshop, to that of a frame adjusted in a player through a correction in Aspect Ratio.
I hope that this highlights some of the issues you may experience with files produced from DVR’s and acts as some words of warning to manufacturers who continue to throw away image information.
Oh well, what next????
Click here to learn more