A quick one to highlight that the original name of a file can send you down the wrong path.
We are greeted with a disk containing a number of files and folders.
A common export structure of player, video files, and then a filter. I didnt bother looking in the filter.rar to start with as they are commonly installation files and I don’t want to install anything. The player is named MP4 Player and all the video files have a .mp4 extension. Taking a look inside the player folder also highlights the existence of mp4 references.
Within the DVR world, and the recording of proprietary overt surveillance video, there has been a move from mpeg4 part 2, to mpeg4 part 10. In my experience, if the DVR utilises part2, the references in the player and video files all use the mp4 naming convention. If, however, the DVR utilises part 10, they tend to use h264 or 264. To read up more on all the mpeg4 parts, there is a good guide on Wikipedia.
So, by understanding this, you may be able to see why I began to form the opinion that the files were mpeg4 part 2……..
Staying with the player folder for the time being, I have seen some of the files before but with slightly different names. The HIE_MP4Play.dll is a very common one and often linked with Hikvision exports.
The player also had a very common interface but with a slightly different logo.
A Google image search of the blue logo in the middle was negative. (Logo searches are great for finding out the brand of DVR. Although it would be whole lot easier if they actually put their details in the About box!)
The player works with an overlay method. This means that the video file plays over the top of the player window. This was a common method a number of years ago and meant that, in order to screen capture the video, the computer’s hardware acceleration had to be turned off, in order for the software to see the video. Now though, screen capturing or screen recording, is pretty low down on the options list. Near the top is the ability to understand, validate and read the native file without capturing.
Dropping one of the mp4 files into Mediainfo revealed a strange result.
Two Audio streams in an Mpeg Program Stream container. This didn’t look right so before I did anything else, it was time to take a look in the Media Filter compressed folder.
In here was a readme.txt file that gave the first mention of the mp4video.ax filter decoding h264 video.
By using FFplay and forcing the file to be read as a H264 file, the result was successful playback. So, after all of that, the video was actually a standard H264/AVC stream.
I have asked this many times, but why do companies make it so hard, and so complicated? If they are standard streams, which is great and what we want, why make it so difficult?
Dropping all of the files into AnotherGui and using a pre-set to re wrap the H264 streams into an AVI container, resulted in all files being wrapped up within a minute.
All these files are then readable immediately by most modern NLE’s. No screen capturing required!
As a reminder:
ffplay -f h264 thefile.mp4
ffmpeg -f h264 -i thefile.mp4 -vcodec copy -fflags genpts -f avi thefile.avi
All tools are in my software pack
Hope it helps….
If you are using a recent version of FFmpeg (This post was written in 2013), please see this post regarding the type of stream and container format. It is linked with Compn’s points below that, although worked in the version detailed in this post, will no longer work in recent FFmpeg builds.