Subtitle support in media containers

Container subtitle support requires a defined codec mapping and preserved timing/configuration, while player support determines whether that representation can be presented.

A container needs a defined way to identify a subtitle codec, store its payloads, and describe their timing and configuration. A player then needs to interpret that mapping and present the recovered subtitle.

Those are two compatibility boundaries. A valid subtitle track can be inside a valid media file without every player supporting it.

Examples of defined mappings

Container/framework Subtitle representation or identifier Interpretation
Matroska S_TEXT/UTF8 SRT-style text, with container cue timing
Matroska S_TEXT/ASS ASS event payloads and global script/style configuration
Matroska S_HDMV/PGS Presentation-graphics segments
ISO base media / MP4 tx3g 3GPP timed text
ISO base media / MP4 wvtt WebVTT sample carriage
ISO base media / MP4 stpp family XML timed-text carriage with applicable profile identification
MPEG transport stream DVB subtitle service Timed subtitle segments plus service signaling

This is a set of mapping examples, not a product support matrix. Container brands, profile requirements and the intended receiving system can impose additional restrictions.

Changing a filename extension does not construct these structures. Copying arbitrary SRT bytes into an MP4 track also does not make them a conforming tx3g, wvtt or stpp sample.

The same sentence can be packaged differently

A standalone SRT gives “The platform is empty” its start and end in a text timestamp line. Matroska can store the wording in a UTF-8 subtitle block, with the block timestamp/duration representing the interval.

Those literal bytes differ while the timed sentence can remain equivalent. A muxer writes the target mapping; an extractor can reconstruct the standalone cue.

For ASS or graphics, global styles, palette/object state and supporting resources also matter. Moving only the visible text or only selected binary packets can discard interpretation information.

Playback support has another scope

An Emby route considers the selected app's container, codec and subtitle requirements. A container readable by the app can still contain a subtitle that needs conversion or upstream rendering. Conversely, compatible video can remain unchanged while a separate subtitle conversion supplies an accepted format.

A remux to another container preserves a subtitle only if the output has a suitable mapping and the necessary configuration is retained. It does not turn a PGS image into character text. It also does not make a reader implement a format it previously could not render.

See Also

References