text: Technical details The byte sequence is usually restricted to ASCII printable characters, with space characters reserved for padding shorter sequences.  Case sensitivity is preserved, unlike in file extensions. FourCCs are sometimes encoded in hexadecimal (e.g., "0x31637661" for 'avc1') and sometimes encoded in a human-readable way (e.g., "mp4a"). Some FourCCs however, do contain non-printable characters, and are not human-readable without special formatting for display; for example, 10bit Y'CbCr 4:2:2 video can have a FourCC of ('Y', '3', 10, 10) which ffmpeg displays as rawvideo (Y3[10] [10] / 0x0A0A3359), yuv422p10le.
  Four-byte identifiers are useful because they can be made up of four human-readable characters with mnemonic qualities, while still fitting in the four-byte memory space typically allocated for integers in 32-bit systems (although endian issues may make them less readable). Thus, the codes can be used efficiently in program code as integers, as well as giving cues in binary data streams when inspected.
  Compiler support
  FourCC is written in big endian relative to the underlying ASCII character sequence, so that it appears in the correct byte order when read as a string. Many C compilers, including GCC, define a multi-character literal behavior of right-aligning to the least significant byte, so that  becomes 0x31323334 in ASCII. This is the conventional way of writing FourCC codes used by Mac OS programmers for OSType. (Classic Mac OS was exclusively big-endian.)
  On little-endian machines, a byte-swap on the value is required to make the result correct. Taking the avc1 example from above: although the literal  already converts to the integer value , a little-endian machine would have reversed the byte order and stored the value as . To yield the correct byte sequence , the pre-swapped value  is used.