Caption Conversion Guide
Convert EBU-STL to IMSC
Of every conversion in broadcast subtitling, this is the one where the target is more capable in every dimension. Nothing is lost. Most usefully, the single character table that constrains every STL file stops being a constraint at all, because IMSC is Unicode.
Can you convert an EBU-STL file to IMSC?
Yes, and nothing is lost. IMSC is Unicode-based, so any script the STL's character table carried survives intact, including Cyrillic, Greek, Arabic and Hebrew. Teletext rows become percentage-based regions, frame timing becomes media time, and the teletext palette becomes explicit colour values.
What changes when you convert EBU-STL to IMSC
This is a promotion at every level. The only real work is authoring a region and style model in the space IMSC opens up, and satisfying the receiving platform's profile requirements.
| Property | In the EBU-STL | In the IMSC | Result |
|---|---|---|---|
| Text encoding | One character table per file | Unicode | The script limitation disappears entirely. This is the biggest gain |
| Non-Latin scripts | One per file, table-selected | Any script, mixed freely | A title in multiple scripts becomes possible for the first time |
| Timing | Explicit in and out timecodes in frames | Explicit begin and end | Transfers directly. Frames convert to the chosen time base |
| Frame rate | 25 fps, declared | Depends on the time base | Choose media offsets or SMPTE, per the platform spec |
| Vertical position | Teletext row number | Named regions as percentages | Rows become percentages. More precise, not less |
| Horizontal position | Justification | Region alignment and extent | Transfers, with finer control available |
| Colour | Teletext palette | Arbitrary colours with opacity | The palette becomes explicit values you choose |
| Line length | Constrained by the teletext line | No hard limit | The constraint disappears. Existing breaks are preserved |
| Programme metadata | Title, episode, translator in the header | Limited metadata | Mostly dropped. Keep the STL for your archive |
| Profile conformance | Not applicable | Version and profile must be declared | The platform decides. This is where deliveries fail |
Before you start: the platform spec, and the character table
You need almost nothing from the source that the source does not already carry. What you need is the receiving platform's requirements.
- The STL's character table. Read it from the header so the text decodes correctly on the way in. Everything downstream depends on it.
- The IMSC version and profile the platform requires. A file valid against one version can be rejected by a validator expecting another.
- The time base the platform expects. Media offsets are common for OTT; SMPTE timecode appears in some specs.
- The aspect ratio of the master. Regions are percentages, so a layout built against one aspect ratio does not transfer to another unchanged.
- Whether the platform specifies a default region. Matching it avoids placement disputes at QC.
How to convert EBU-STL to IMSC
The subtitles themselves come across cleanly. The steps are about decoding correctly on the way in and conforming to a specification on the way out.
-
Read the STL header
Note the character table, the declared frame rate and the display standard. The character table is the critical one. -
Open the STL with the correct character table
Verify the text is genuinely correct, not merely readable. A mis-declared table produces plausible but wrong characters, and Unicode output will preserve the error faithfully. -
Map teletext rows onto regions
Convert row placements to percentage-based regions. This is the point at which placement becomes more precise than the source allowed. -
Author the style model
Translate the teletext palette into explicit colour values, and decide whether to specify font and size or defer to platform defaults. -
Choose the time base
Convert the 25 fps frame timings to the time base the platform expects, usually media offsets for OTT delivery. -
Declare the correct IMSC version and profile
Write the profile declaration the platform's specification names. -
Export and validate against the platform spec
Validate against the named profile and version, not against TTML generally. -
QC against picture
Check placement, reading speed and that non-Latin text renders correctly in the target player.
What breaks, and how to catch it
Because nothing is lost in translation, every failure here happens either before the conversion or at the validator.
- A mis-declared character table. Decode with the wrong table and the wrong characters are faithfully preserved into Unicode, where they are much harder to spot as an encoding fault.
- Profile mismatch on delivery. The document is valid TTML and does not satisfy the version and profile the platform requires. This is the most common rejection.
- A region layout that assumes one aspect ratio. Regions are percentages of the frame. A layout that cleared graphics on the broadcast master can sit over picture on a differently framed OTT version.
- Lost header metadata. Programme title, translator and reel information have no real home in IMSC. Keep the STL if that record matters.
- Assumed default styling. Teletext colours have to become explicit values. Accepting converter defaults can change speaker colours that were carrying meaning.
When not to convert EBU-STL to IMSC
This is nearly always the right conversion for an OTT delivery from European broadcast material.
- The platform names EBU-TT-D. Closely related and also a TTML profile, but with different required attributes. Target what the spec says.
- The platform wants WebVTT. WebVTT is simpler and native to browsers. Some services prefer it.
- The delivery is still broadcast. If the file is going to playout rather than a streaming service, STL remains the correct deliverable.
- A better source exists. If the subtitles were authored in PAC or a project file, converting from that source preserves more than going through STL.
The IMSC format reference covers what each version and profile requires.
EBU-STL to IMSC questions
Specific questions about this conversion. For the formats themselves, see the EBU-STL and IMSC references below.
Not from the subtitles. IMSC is more capable than EBU-STL in every dimension that matters — Unicode text, percentage positioning, arbitrary colours, no line length ceiling. The one real loss is the STL header metadata: programme title, translator and reel information have no equivalent home in IMSC, so keep the original STL for your archive.
Yes, and this is the strongest reason to make this conversion. EBU-STL holds one character table per file, so a title is locked to a single script. IMSC is Unicode, so the script comes across intact and a single file can even mix scripts. The only requirement is decoding the STL with the correct character table on the way in.
They convert to named regions expressed as percentages of the video frame. This is more precise than the source, not less, because teletext rows are a coarse fixed grid while percentages are continuous. The thing to check is aspect ratio: a region that cleared a lower third on the broadcast master may not clear it on a differently framed version.
Whichever the platform's specification names. Both are TTML profiles and the subtitle content is effectively identical between them; what differs is which attributes are required and which features are permitted. Converting between the two afterwards is a light conformance exercise rather than a data conversion, so this is a low-risk decision either way.
Usually media offsets, meaning time expressed as elapsed time from the start of the media rather than as SMPTE timecode. Most OTT platforms specify this because their players work from media time. Check the spec, because some deliveries do call for SMPTE timecode, and reading one as the other shifts every subtitle.
Escape the character table
Closed Caption Creator reads EBU-STL with explicit character table selection and writes Unicode IMSC to the version and profile your platform names.
Map teletext rows onto regions with the layout visible against picture, and validate before delivery rather than after rejection.