Format reference
STL subtitle format for training video: EBU-STL vs Spruce-STL, and when you actually need it
STL is a subtitle file you will see requested by broadcast-grade content pipelines, large European learning portals, and the occasional enterprise LMS that inherits its video infrastructure from a TV-adjacent vendor. Confusingly, two different specs share the name. This is which one your upload form means, when you actually need STL over SRT, and why most training teams do not.
TL;DR
"STL" means one of two things. EBU Tech 3264 STL is a binary, fixed-block broadcast subtitle format used by European television. Spruce Subtitle (Spruce-STL) is a plain-text authoring format from the Spruce DVD mastering toolchain. Both end in .stl; they are not interchangeable. For training video, the common path is: your LMS or corporate broadcast workflow asks specifically for "EBU-STL" because the downstream distribution is European-broadcast-adjacent. If the upload form just says "subtitle" or "SRT/VTT/STL", pick SRT — STL's broadcast metadata is not something an LMS needs.
EBU Tech 3264 STL — the European broadcast spec
EBU-STL is defined in EBU Technical Publication 3264 (first published 1991). It is a binary format: fixed-length 1024-byte General Subtitle Information (GSI) block at the head, followed by 128-byte Text-Timing-Information (TTI) blocks, one per subtitle. Timing uses SMPTE timecode at the frame rate declared in GSI. Character encoding is ISO 6937 by default, with Latin-1/Hebrew/Arabic/Cyrillic/Greek code-page variants available per GSI.
When you will meet EBU-STL:
- Your organisation captions training video for regulatory filing with a European broadcaster or a broadcast-aligned service (very rare for internal L&D).
- Your LMS is built on a video platform descended from a broadcast MAM (Media Asset Management) system — some European public-university Kaltura deployments, some government-sector learning portals.
- You are archiving training content under a long-term preservation policy that mandates EBU-STL alongside MPEG-2/4 source files.
When you will not meet it: a modern SaaS LMS (TalentLMS, Docebo, Absorb, Thinkific, Teachable). These take SRT or VTT. They will not accept an EBU-STL upload because their players cannot parse ISO 6937.
Spruce-STL — the legacy DVD authoring format
The other STL is the Spruce Subtitle format, a plain-text file used by Spruce Technologies' DVDMaestro authoring tool (and by Apple's DVD Studio Pro, which inherited Spruce's pipeline when Apple acquired the company in 2001). It looks like:
$FontName = Arial
$FontSize = 32
00:00:03:08 , 00:00:06:10 , First, run kubectl get pods to see what's running.
00:00:06:10 , 00:00:09:03 , Then apply the Helm chart with helm install.
00:00:09:03 , 00:00:12:20 , [laughter] You'll see the deployment start immediately.Header directives control font and style; the body is semicolon-separated-ish timecode + dialogue rows. You will almost never see a training LMS ask for Spruce-STL — it is a DVD-mastering legacy. We mention it because if someone on your team says "just give me an STL" and the next question is "what renderer", the answer matters.
When STL is the right export from GlossCap
Short answer: rarely, but cleanly when you need it. Long answer:
- Your upload target specifies EBU-STL by name — not just "subtitle" in a generic sense. A Kaltura caption-upload that lists STL alongside SRT/VTT is accepting EBU-STL. You will typically also be asked for a frame rate; 25 fps is the European broadcast default, 29.97 for US hybrid pipelines.
- You need SMPTE timecode precision that the tenths-of-a-second resolution of SRT/VTT does not match. Broadcast pipelines align captions to frame boundaries, and drift matters over a long programme. This is not a training-video concern for normal-length modules.
- Archival-grade caption preservation for a regulated content library. STL's fixed binary schema is easier to ingest into long-term preservation systems than SRT's loose text.
Everywhere else, exporting STL from GlossCap is overkill — pick SRT for LMS upload or VTT for HTML5 embed and move on.
What GlossCap's STL export does (and does not) do
GlossCap's STL export targets EBU Tech 3264 with sensible broadcast-friendly defaults:
- 25 fps timecode in GSI by default (configurable to 29.97 or 30 for US-broadcast alignment).
- ISO 6937 character encoding — the EBU baseline — with a Latin-1 fallback option for systems that request it.
- Double-height top-bottom placement defaults to bottom; position override is supported per-cue via the TTI format flag.
- Speaker labels emit as in-line text (EBU-STL has no speaker metadata channel, so
[Alex]:lands in the cue text). If you need structured speaker attribution, TTML is the richer format. - Non-speech sound cues emit as bracketed dialogue in the same stream — the closest STL can get to the SRT/VTT convention.
We do not emit Spruce-STL. If your pipeline genuinely needs DVD-era Spruce, export SRT and convert with an open-source tool — the text content is what matters, and the format is a mechanical transform.
The content still has to be right
The same rule that holds for SRT, VTT, and TTML holds for STL: the format is WCAG-neutral; the content is what passes an audit. EBU-STL wraps your captions in a fixed binary envelope, but if the text inside has kubectl transcribed as "cube control" or Docebo as "doh say boh", the audit fails on the same verbatim-for-dialogue criterion it would fail on in a 1990s .stl or a modern .vtt. GlossCap biases the Whisper decoder on your company glossary before any export runs, so the term-preservation promise holds regardless of which format you export. Our SC 1.2.2 page walks through what an auditor actually samples.
Related questions
Does STL support colour and positioning like TTML?
EBU-STL has positional codes (justification, vertical position, double-height flags) and a small palette of named colours via teletext-compatible control codes. It is much less expressive than TTML's full styling surface. If you need rich styling, TTML is the format; STL's styling exists mainly for broadcast-safe-area compliance.
What frame rate should I pick?
Match the frame rate of your source video. 25 fps for European PAL-origin content, 29.97 for US hybrid pipelines, 24 for film-origin training (rare but possible for academic content rereleases). Mismatched frame rate is the single most common STL import error.
Can my HTML5 player render STL directly?
No mainstream HTML5 player parses EBU-STL natively. If your LMS accepts STL, it is because the server converts it to VTT or burns it into the video at ingest. For an HTML5 <video> <track> element, use VTT — see our VTT page.
Why do some upload forms list STL without qualifying?
Because the tooling has been around long enough that "STL" without modifier is a regional shorthand. In European broadcast-adjacent contexts it means EBU-STL. In post-production tooling it can mean Spruce-STL. If in doubt, ask the admin or check the upload form's help text; the wrong STL will silently render as empty captions.