MP4 or H264?

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.

Snap 2013-11-30-15_30_49

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.

Snap 2013-11-30-16_29_47

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.

Snap 2013-11-30-16_30_08

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.

Snap 2013-11-30-15_37_30

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.

Snap 2013-11-30-15_33_06

In here was a readme.txt file that gave the first mention of the 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

Using command line tools article


All tools are in my software pack

Snap 2013-11-30-15_44_45

All my re-wrapped files, ready to work with

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.


By Spreadys Posted in EEPIP

11 comments on “MP4 or H264?

  1. if they are indeed h264 files, its not wise to copy them into avi container.

    avi has trouble with h264 b-frames, sometimes displaying them out of order in various old software players.

    its recommended to output h264 in mkv or mp4 formats.
    if it works for you, go for it. but i would not rely on h264 in avi for long term archiving.

    btw its also a good idea to archive the official player that plays the original files. because some of these companies go out of business, and then you cant find that software ever again.

    it may also be a good idea to keep the copy of ffmpeg/mencoder that works with those files. you never know when that codec functionality could break or be removed. keeping 20+mb extra isnt that bad to be prepared.

    • Thanks again Compn.

      I have used mkv a number of times when frame analysis has not been required. The avi version is an interim ‘working’ format. Its not a final file and not the first one.

      We start with the raw stream, or file, that is produced by a DVR and for the purpose of analysis, AVI is a workable container.

      Thanks for pointing out the good guidance on making regular copies of working builds. I have mentioned that before somewhere but will do again in the future.
      Thanks again

  2. Hello David,

    I have to thank you for your fantastic job here, I’m a beginner i this field and your site helps me a lot.

    I have a question, though: I’m currently trying to extract data from a DVR, made by ITX. Its specification states it’s MPEG-4 compatible. I’ve gained access to the files stored directly on its HDD in order to rip video streams directly out of them (bypassing the customized filesystem), basing on their hex signatures inside the files. I have succeeded previously with H264-based DVR also manufactured by them, but this time it’s different. I can find the VOS start code (000001B0, as stated in ISO/IEC 14496-2) and part/level identification (2, simple), but I’m unable to play the ripped stream. Neither FFmpeg (I’m a beginner here) nor VLC are able to play it, though VLC is able to recognize it as MPEG 1/2 (?).

    Here’s one of the archive files containing video stream (aside from it, there are timestamps). First MPEG sequence apparently starts at 0F6416.

    *Link Removed*

    The problem is, when I crop the sequence and paste it into a new file, I’m unable to play it back.

    The question is – what am I getting wrong?

    Thanks in advance.

  3. Just following up….
    I have replied in full via email to Adam with a few more questions regarding the DVR and the exports it creates. These are very useful to understand how the streams are created during an export. If we get anywhere, I will post back!

  4. Hi, I tried running my file through ffmpeg with the command you put at the bottom and it creates a file, but it still doesn’t play in VLC (and causes it to crash). I did notice during the conversion process it says this a bunch of times:
    [NULL @ 002f2c00] Reducing left cropping to 0 chroma samples to preserve alignment.
    [NULL @ 002f2c00] crop values invalid 0 2 3 49 / 31568 48
    [NULL @ 002f2c00] Reducing left cropping to 0 chroma samples to preserve alignment.
    [NULL @ 002f2c00] illegal aspect ratio

    • Hi there,
      due to the variables encountered when dealing with surveillance system footage, it is a bit tricky to give a definite answer. Do you have the same folder structure, player and naming convention with the exports dealt with in the article? Perhaps you could share a file with me to peer review. I can then take a look – which may be easier! if so, send me a dropbox (or similar) link to david (at)
      All the best,

      • I’m not sure exactly what you mean by “exports”. I know I am dealing with the same type of video files as your article does. I dropped it into the same folder as one that has the “MP4 Player” in it and was referencing it in both my ffmpeg and ffmpeg commands. I put quotes around it because there was spaces in the file path.

        I just tried to play the file using the ffplay command and while it works it is extremely choppy. It eventually crashed and compalined about resolution size again.

        I think it might have to do with the video being in a non-normal aspect ratio. I set the files to record in “D1″ which gives it a resolution of 704 x 480.

      • The exports are the files that you have exported from the DVR. It may prove difficult to establish an issue without analysing the file. If that’s not possible then I’m sorry I can’t be if much assistance.

      • OK, issue solved…. Neil kindly shared a file to test and it turns out that the latest versions of ffmpeg are slightly more fussy on what bitstream types they put into different containers. I have completed a new blog entry and linked it to the bottom of this one.

  5. Pingback: Update to MP4 or H264 and the constraints of containers |

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s