Media MIME Types
A media MIME type labels the kind of content delivered by a protocol such as HTTP.
When a player fetches a resource over HTTP, the response can include:
Content-Type: video/mp4
This is a media type, commonly called a MIME type. It describes the response body. The URL may have no extension, and the bytes may be delivered dynamically, so the HTTP label has a job independent of the filename.
The first part, video, is the broad category; mp4 is the subtype. A parameter adds information whose meaning is defined for that type.
| Media type | What the response represents |
|---|---|
| video/mp4 | MP4-family content with video |
| audio/mp4 | MP4-family audio without video |
| audio/mpeg | MPEG audio |
| application/vnd.apple.mpegurl | An HLS playlist describing other resources |
From a playlist to media bytes
A streaming player can first receive an HLS playlist with the playlist media type. It reads that text to find media locations. A later request obtains an actual media segment whose type describes its own container. These responses participate in one presentation but contain different kinds of data.
Emby can similarly deliver a package different from the library file. The Content-Type belongs to the response being sent, so it should describe that output rather than simply repeat the source's extension.
Making the track description more precise
RFC 6381 defines a codecs parameter for supported media types. An MP4 type can, for example, be accompanied by codecs="avc1.640028,mp4a.40.2". The first token describes an AVC track: the hexadecimal profile value 64 means 100, the compatibility byte is 00, and the level value 28 means 40. The second identifies MPEG-4 audio object type 2, AAC-LC. These are declarations about encoded tracks within the package.
That precision helps a browser or playback framework choose a decoding path before reading all the media. The byte contents still need to agree with the declaration. Merely changing the label cannot change an AVC profile or turn one audio codec into another.
A useful HTTP investigation follows the resource sequence: which request returned the playlist, which returned media, which Content-Type each response supplied, and which codecs the actual tracks use. It distinguishes a wrong label from wrong media and from a reader that lacks the required decoding path.