Subtitles added to the HLS stream you already serve
SyncWords writes WebVTT subtitle tracks directly into your existing HLS stream at the origin. Viewers pick a language in the player's own caption menu, and your video segments are never copied, re-encoded or republished.
- WebVTT subtitle tracks
- Player-native display
- Zero added video latency
- CDN and DRM friendly
How it works
Augment the stream, don't rebuild it
In append mode, SyncWords references your existing HLS media and adds subtitle playlists next to it. The original video segments stay exactly where they are.
Point us at your stream
SyncWords pulls your HLS over HTTP or from S3, or accepts a WebDAV push. S3 access can assume an IAM role you provide.
Captioned and translated
Live ASR transcribes the program audio and translation produces each subtitle language, with your dictionaries and glossaries applied.
WebVTT written at the origin
Each language becomes a WebVTT track in the manifest, pushed to HTTP, S3, MediaStore, MediaPackage V2 or WebDAV.
Players do the rest
Playlists and segments stay cacheable, so captions ride the CDN you already use, and viewers toggle languages in the player's own menu.
Why this position
The richest subtitle rendering of any path
Nearly the full WebVTT spec
Because this path targets players rather than a packager, styling and positioning are not cut down to a converter's subset. Line length, line count and vertical position are all controllable.
Every script, natively
Cyrillic, Arabic, CJK and Hebrew ride in WebVTT without workarounds, which makes this the standard answer for multilingual OTT.
Inside DRM and multi-CDN
DRM and AES-128 are preserved, DVR features keep working, and delivery stays on CloudFront, Akamai or Fastly exactly as before.
In your chain
Player-side by design
The output is standard HLS with WebVTT, so it plays wherever HLS plays: JW Player, THEOplayer, HLS.js, Video.js and the players built on them, on desktop, mobile and connected TVs.
Frequently asked questions
How far behind the audio do captions appear in HLS?
Viewers typically see captions about 5 seconds behind the program audio in HLS workflows. The base latency of this path itself is a true zero: in append mode SyncWords adds no delay to your video, which also means there is no buffer available on this path to absorb caption processing time. The trade-offs are explained on the latency page.
Can SyncWords embed EIA-608 captions in our HLS segments?
No. Embedded 608 is an MPEG transport stream capability, not an HLS one, and SyncWords does not write HLS segments carrying embedded 608. If your distribution requires 608 in HLS, take 608 in SRT from us and transcode in your own pipeline. For HLS itself, WebVTT is the native answer and the one players support best.
Do you copy or re-host our video segments?
Not in append mode. SyncWords references your existing media and writes subtitle playlists alongside it, so the original segments are never copied or republished. A relay mode also exists where SyncWords serves the full stream, which is useful when you want the buffer control that append mode cannot offer.
Does this work with DRM-encrypted streams?
Yes. DRM and AES-128 are preserved, and SyncWords operates inside DRM-encrypted, multi-CDN environments. DVR features are preserved in HLS delivery as well.
How much control do we get over how subtitles look?
More than on any other path. Maximum line length from 12 to 120 characters, one to five lines, and a bottom margin from 0 to 90% of the viewport. Because the WebVTT goes straight to players, what you configure is what renders.
Try it against your origin
Bring a test stream and our engineers will add live subtitle tracks to it in a proof of concept, on your own origin and CDN.