An ftyp is a four letter code (sometime including blanks) that is used to identify the "type" of encoding used, the "compatibility", or the "intended usage" of a media file. It only pertains to MP4 or newer QuickTime (.mov) container file formats. It is somewhat analogous to the so-called fourcc code, used for a similar purpose for media embedded in the AVI container format.

The four letter code "ftyp" itself is the atom type (in QuickTime terminology) or box type (in MP4 terminology). An atom/box with this label contains data comprised of certain identifier(s). The table created for this website is an attempt to compile a list of all such identifiers one might find.

While there are many sites with comprehensive lists of AVI fourcc codes, I have found no satisfactory listing of ftyp codes. Because I needed such a list to improve the MP4 support of my GSpot application, I compiled a list myself from websites, specifications, samples, and helpful information from other contributors. The original and main intent of compiling the data was (and still is) to incorporate into GSpot's external database file. But while I was at it, I decided to create this webpage as well, since there really does seem to be a need for one.

Note that ISO/IEC, the organization responsible for the MP4 specification, created the original, most basic, codes. They also set up an official "registration authority" called MP4REG. Vendors who create new encoders may create and elect to use their own new ftyp codes are encouraged to "register" them with that authority. That way the information is publicly available, and it would help prevent the possibility of multiple vendors inadvertently using the same code for a different purpose. The MP4RA website does publicly offer such a list on their website, but, as I mentioned above, it is woefully incomplete. I guess the fact that ISO/IEC considers registration of the codes "voluntary" is part of the problem.

But back to subject itself: in the case of AVI, there is only one fourcc code per file to indicate its type (well, there's actually two, but the any distinction between them is moot. And there's a third code, sometimes called a twocc, which indicates the audio type used).

Unlike AVI, however, the ftyp system uses the following setup (this is the actual layout of the contents of the atom/box):
 

It's these <cccc> codes that I'm collecting and documenting on this website - that's the premise.

The ftyp system is a somewhat more flexible one than the AVI's "fourcc", although I was personally confused and thought of it "backwards" the first time I saw it. Say, for example, you have an MP4 AAC audio file whose size, bitrate, etc. were all specifically optimized for use with an audio iPod. My original thought was that its "main" or "major" type was "MP4/AAC" and that - as an aside - the "minor" information might indicate "and oh, by the way, this is optimized iPod use".

In reality, it's the other way around. ISO/IEC prefers to consider the main type (or "brand" as they prefer to call it) to be an "iPod Audio File". And - as an aside - "oh, by the way, it happens to also conform to standard MP4/AAC, so you may also be able to play it on your PC". So for this hypothetical iPod audio file, the ftyp box may look something like this:

In this case the two "compatible brands" simply indicate that this is a standard MP4 file, compliant with ISO's basic "Base Media" specification.

The latter one, "isom" is the most general of all, and simply means that the file complies with the most basic MP4 file format specification. In fact, as further evidence of my comment above that the "major brand" should be the most "specific" one: the current ISO specification now actually prohibits using "isom" as the "major brand". Apparently their feeling being that it's "too general" to usefully identify the file in any practical way. That said, in actual files you will see "isom" used as the major brand quite often.

What I've left unanswered here, among other things, are some rather basic questions, some of which I'm not 100% clear on the answers to:

1.      Should the "major brand" be duplicated as a "compatible brand"? That would certainly always appear to be true, but isn't that a bit redundant? Seems like, in practice, sometimes this is done and sometimes it isn't.

2.      Should an file list as a "compatible brand" a specification for a player which can only perform a "subset" of the features of the major brand? Apparently the answer is yes. Which makes a certain amount of sense. For example, if the major brand was a spec which included the ability to "skip chapters" while watching a video, one certainly might consider it useful to know that the file will also play fine on a slightly more basic player, one that has the ability to do everything except "skip chapters". But certain more extreme examples make one wonder. Apple lists "M4A " as a compatible subtype of "M4V ", which is to say "sure, you can play this video on your 'audio-only' iPod - but don't expect to see any video" ;) That particular fact seems somewhat less than useful, in my own opinion, though I suppose the fact that you could just listen to the audio track of a video file is of some, albeit rather limited, use. [1]

3.      Should an file list as a "compatible brand" a specification which is a "superset" of the major brand? In this case the media file will play properly with all features intact. But it's neither practical nor required to list all of the more "advanced" specifications for this "simple file". Indeed, this would be impossible as more advanced specifications that include all of the features of previous specs are being created all the time. So such a list would never be guaranteed to be up to date. In this case it seems it's the media player's responsibility to recognize that the file's "main brand", or at least one of the compatible ones, is one of the many types that it "knows" how to handle.

Notes

[1] According to this 3GPP specification document (and I'm sure ISO/IEC says this too, but I find the 3GPP spec more readable on this subject):

"... [the inclusion of a brand as compatible indicates] that the file conforms to the specification; it includes everything required by, and nothing contrary to the specification (though there may be other material)" [emphasis mine].

So that would make Apple's decision to include "M4A "as a "compatible brand" for the "M4V " major brand technically correct. The video file indeed includes everything required by (and apparently nothing contrary to) Apple's audio player. It's just that the file contains "extra material" - namely the video content!

- Steve G

   Last Update: 12 December 2006