Structure of MPEG-4 "©xyz" box

Question

I am trying to parse out ISO/IEC 14496-12 based files (essentially MPEG-4 movies). There are a few boxes are not in the standards (or on the MP4 Registration Authority lists), but are in real-world files. They mostly pretty simple to trace to QuickTime or similar, where the implementation is just not updated.

I'm struggling with the GPS location box (©xyz).

Here is an example:

0x00, 0x00, 0x00, 0x1e, 0xa9, 0x78, 0x79, 0x7a,
0x00, 0x12, 0x15, 0xc7, 0x2b, 0x34, 0x31, 0x2e,
0x33, 0x37, 0x35, 0x38, 0x2b, 0x30, 0x30, 0x32,
0x2e, 0x31, 0x34, 0x39, 0x32, 0x2f

The first eight bytes are the box length and box name. No problem with that.

The next four bytes are the unknowns: 0x00, 0x12, 0x15, 0xc7.

The remaining bytes are text "+41.3758+002.1492/" which is the expected latitude and longitude (Barcelona) per ISO 6709 (albeit not the 2023 version).

Of the unknowns, I can interpret the first two bytes as a 16 bit (unsigned) integer which matches the number of characters in the text. That is guesswork though.

The next two are a mystery - could perhaps be constants since I see the same 0x15 0xc7 values when generated from a different device in Australia.

What is the defined structure for this box, and is there a published specification that defines that structure?

Answer 1

As Fraser noted in his answer, 0x15 0xc7 indeed stands for the language code "English". However, it is actually documented. These 16 Bits correspond to Quicktime's Language List Atom, and looking into the table you'll find that 5575 (0x15 0xc7) equals "Packed ISO code for ‘eng’ (English)".

Fraser linked the source code for the MPEG4Extractor of the AV Framework. Though useful, note that the Quicktime File Format Documentation emphasizes:

The QuickTime File Format is the basis of the MPEG-4 standard and the JPEG-2000 standard, developed by the International Organization for Standardization (ISO). Although these file types have similar structures and contain many functionally identical elements, they are distinct file types.

So be careful, and always check the docs.

Answer 2

The two mystery bytes 0x15 0xc7 are the language code en based on the MPEG4Extractor.cpp here

https://android.googlesource.com/platform/frameworks/av/+/937c6bedd4b6e5c6cb29a238eb459047dedd3486/media/libstagefright/MPEG4Extractor.cpp#1489

But this is just inference - ultimately, without a published specification (or deeper reverse engineering and analysis of multiple samples) determining the meaning of the bytes accurately is not really possible. It is entirely feasible that no such public specification exists for manufacturer/device specific encodings.

As an aside, personally I would try generating multiple files with different locales, languages, etc to see how that might affect the metadata encoding.

Answer 3

The 0x15 0xC7 as a language code by both the other answers was a great insight. In binary, that is 0001 0101 1100 0111.

There is a structure in ISO 14496-12 (e.g. in the media header box) that looks like a 1 bit pad, then three 5 bit values that are interpreted as the difference between the ASCII value and 0x60. Changing the spacing in the binary, it is 0 00101 01110 00111, the three values are [5,E,7] (in hex). Adding 0x60, it is [0x65, 0x6E, 0x67]. In ASCII that becomes, [e, n, g], or "eng" as a code.