SRTとVTTとTTML、3つのフォーマットに3つの役割

3つのフォーマット、3つの役割

SRTは移植性のため、VTTはウェブ向け、TTMLは放送とOTT配信用です。 キャプションファイルをアップロードして、何も言わずに失敗するのを見たことがあるなら、このミスマッチにぶつかったことがあるでしょう。3つのフォーマットは外見は似ていますが、それぞれ異なる問題を解決しており、ほとんどのプラットフォームはそのうち1つか2つしか受け付けません。

この記事では、各フォーマットを実際の用途にマッピングします。構造的にどう見えるか、どのプレイヤーやプラットフォームが受け入れるか、そしてコンテンツがNetflix、Amazon、Disney+に載る場合に重要となるOTT配信仕様の分岐点はどこか。SRTとWebVTTの単純な2択なら、SRTとVTTの比較が放送の文脈なしでより深く掘り下げています。

SRT: 最小公分母

SRT（SubRip）は3つのうち最古で、存在する中で最も広くサポートされているフォーマットです。 素のSRTファイルはこんな感じです:

1
00:00:01,000 --> 00:00:04,500
これが最初のキャプションです。

2
00:00:05,000 --> 00:00:08,200
これが2番目のキャプションです。

各ブロックには連番、ミリ秒区切りにカンマを使うタイムコード範囲、そして1行か2行のテキストがあります。そのカンマは偶然ではありません。SRTはヨーロッパで作られ、そこではカンマが小数点区切りです。SRTをVTTに手動で変換する際、カンマをピリオドに変え忘れると、ブラウザでファイルは静かに失敗します。

SRTの強みは、その限界と切り離せません。このフォーマットは非常にシンプルなので、あらゆるOSのあらゆるビデオプレイヤーが読み取ります。YouTube、Vimeo、VLC、Plex、Premiere Pro、DaVinci Resolve、そしてほとんどの放送グレードのエンコーダーです。1つのフォーマットしか配信できないなら、SRTを配信しましょう。

弱点は、ネイティブなスタイリングがないことと、1ファイルにつき1言語という制約です。太字、色、画面上の配置、話者の属性をキャプションデータ自体に含める必要がある場合、SRTでは対応できません。スタイル付きキャプションが必要なワークフローのほとんどは、テキストをビデオのピクセルに焼き込んでおり、その点は字幕ジェネレーターガイドで別途解説しています。

VTT: モダンウェブの標準形式

WebVTTは、W3CがHTML5ビデオ用に構築した形式で、現代のすべてのブラウザがネイティブに理解できる唯一の形式です。 構造はSRTに似ていますが、ミリ秒の区切りにピリオドを使い、スタイリング、配置、話者メタデータを明示的にサポートしています。

WEBVTT

00:00:01.000 --> 00:00:04.500 line:90% align:center
<v Alice>これが最初のキャプションです。

00:00:05.000 --> 00:00:08.200
<v Bob>これが2番目のキャプションです。

<v Alice>と<v Bob>タグは話者の音声注釈で、VTTファイルはそのままダイアライゼーションデータを保持できます。line:90% align:centerのキューの設定は、画面上のどこにテキストを表示するかをプレイヤーに指示します。また、::cue疑似要素を使ってCSSを適用し、色、フォントサイズ、背景を調整することも可能です。

自分のサイトでHTML5の<track>要素を使って<video>タグにキャプションを付ける場合、VTTが必須です。現代のすべてのブラウザがネイティブに読み取ります。Video.jsやPlyrなどのJavaScriptプレイヤーもVTTを中心に構築されています。ウェブ動画を公開するなら、この形式を選ぶべきです。

VTTが苦手なのは、ウェブ以外の配信先です。YouTubeはVTT（SRT、SBV、TTML、DFXPも同様）を受け入れますが、ほとんどのコンシューマー向けエンコーダーや放送ツールはSRTをデフォルトにするか、TTMLを要求します。最初に生成した形式から変換してください。タイムコードの置き換えだけが唯一の技術的な作業です。

一度生成して、宛先が要求する形式でエクスポート

TTML: 放送およびOTT向けの形式

TTML（Timed Text Markup Language）は、主要なストリーミングサービスや放送局が納品時に要求する形式で、SRTやVTTとは互換性がなく、それらの宛先には使えません。 このファイルはXMLで、他の2つに比べて見た目がかなり重厚です：

<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml"
    xmlns:tts="http://www.w3.org/ns/ttml#styling">
  <head>
    <styling>
      <style xml:id="default"
             tts:fontFamily="sansSerif"
             tts:color="white"
             tts:fontSize="100%"/>
    </styling>
  </head>
  <body>
    <div>
      <p begin="00:00:01.000" end="00:00:04.500"
         style="default">This is the first caption.</p>
      <p begin="00:00:05.000" end="00:00:08.200"
         style="default">This is the second caption.</p>
    </div>
  </body>
</tt>

この冗長さには実用的な能力が伴います。リッチなスタイリング、1つのファイルに複数の言語トラック、パーセントベースの配置、日本語用のルビテキスト、アクセシビリティ監査用の構造化メタデータなどです。TTMLはW3Cの仕様ですが、実際にはこれを要求する各プラットフォームが特定のプロファイルを使用しています。

OTTプロファイル：Netflix、Amazon、Disney+

ここで「TTML」は単一の答えではなくなります。主要なストリーマーはそれぞれ異なるプロファイルや制約セットを義務付けています。

Netflixは、全言語で.xmlまたは.ttmlのファイル拡張子を持つTTML1を要求します。ただし日本語は例外で、Netflixは日本語に限りIMSC 1.1形式を要求し、独自のプロファイル識別子を使用します。一般的なTTML1の要件は厳格です。すべての位置データはパーセント値のみを使用し、ピクセルは不可。フォントサイズは100%で表現し、タイムコードはソースのフレームレートに依存します。

Amazon Prime Video はNetflixよりも寛容です。キャプションについては、STL、DFXP/TTML、SCC、SRTを受け付けています。字幕ファイル（会話のみ）については、DFXP/TTML、iTT（Appleが開発したTTML 1.0のサブセット）、SRTを受け付けています。字幕トラックでSRTが認められているため、多くの小規模プロデューサーはPrime Video Directへの提出でTTMLを完全に回避できます。

Disney+ は一般的な納品フォーマットとしてIMSC 1.1を要求します。日本向けコンテンツについては、独自のIMSC 1.1プロファイルを公開し、別途バリデーションルールを設けています。

EBU-TT-D は、欧州放送連合がIP配信とDVB-DASHストリーミング向けに開発したプロファイルです。IMSC 1テキストプロファイルのサブセットで、細かい違いがいくつかあります。英国のFreelyプラットフォーム（BBC、ITV、Channel 4、Channel 5が共同で2024年に立ち上げたIPTVサービス）は、参加するすべてのプレイヤーにEBU-TT-Dを義務付けています。契約書に「EBU-TT-D」と記載されている場合、それはまったく別のフォーマットではなく、制約付きのTTMLファイルを求めていることになります。

私の見解としては、放送局や指定されたOTTプラットフォームに納品しないのであれば、TTMLはほぼ間違いなく不要です。このフォーマットの複雑さはコストであり、特定の仕様が要求する場合にのみ報われます。そうした契約以外では、業界の残りの部分はSRTとVTTで十分にまかなえます。

機能比較表

この階層は実用的です。SRTは最も広いリーチ、VTTはHTML5ビデオ、TTMLは契約で特定のプロファイルが指定された場合に使います。

変換: 各方向で失われるもの

3つの形式間の変換はほとんど機械的ですが、変換は対称的ではありません。

SRTからVTTへはほぼロスレスです。1行目にWEBVTTヘッダーを追加し、タイムコード内のカンマ区切りをすべてピリオドに変更します。ブロック構造はそのまま維持されます。話者ラベルが必要な場合は、<v Name>注釈を手動で追加するか、ダイアライズ済みのトランスクリプトソースから取得します。

SRTまたはVTTからTTMLへは、埋める必要のある構造が追加されます。タイムコードはきれいに転送されます。スタイリング属性は空白（ローカライズエンジニアが埋める必要がある）か、変換ツールが自動入力します。プラットフォームプロファイルは汎用コンバーターではほとんど処理されません。プロファイル指定子、パーセントのみのフォントサイズ、仕様で要求されるフレームレートタイムコードモードを自分で追加する必要があります。TTML変換後はQCパスを計画してください。

TTMLからSRTへの変換はロスがあります。 スタイル、位置情報、多言語トラックはすべて失われます。変換後のSRTは、正しいタイムコードを持つプレーンテキストになりますが、YouTubeへのアップロードには多くの場合、まさにそれで十分です。

タイミングに関する落とし穴をひとつ挙げておきます。TTML変換では、ソースが異なるフレームレートのタイムコードモード（SMPTEとメディアタイム）を使っている場合、ミリ秒精度が失われることがあります。変換後にキャプションが1フレームずれているように感じたら、原因はコンテンツではなくタイムコードモードです。

実際によくあるシナリオは次の2つです。

1. クライアントからSRTを受け取り、放送局が納品仕様としてTTMLを要求する場合。変換後、必要なメタデータフィールドを追加し、仕様に対して検証します。ゼロから作成する必要がある場合は、字幕ジェネレーターで音声からSRTを生成できます。
2. 放送局からTTMLを受け取り、YouTubeアップロードやWebプレーヤー用にSRTが必要な場合。変換してスタイルの損失を受け入れます。テキストとタイミングは正しいです。

プラットフォームの現実チェック

主要な配信先が実際に受け付ける形式は、現在のプラットフォームドキュメントで確認したところ、次のとおりです。

• YouTube: SRT、VTT、SBV、TTML、DFXP、SCC、およびYouTube Studio経由のいくつかのレガシー放送形式。
• Vimeo: SRTとVTT。
• FacebookとInstagram: クリエイター向けアップロードツールではSRTのみ。ほとんどのショートフォームコンテンツはキャプションを動画に焼き付けます。
• TikTok: 外部キャプションファイルのアップロードは不可。動画に焼き付けます。
• Netflix: 全言語でTTML1（.xml/.ttml）。日本語はIMSC 1.1。位置データはすべてパーセント値のみ使用可能。
• Amazon Prime Video: 字幕トラックにはDFXP/TTML、iTT、SRT。
• Disney+: IMSC 1.1。
• 欧州放送 / DVB-DASH: EBU-TT-D（制約付きTTMLサブセット）。
• 自社サイトのHTML5動画: <track>要素によるVTT。

複数の配信先に公開する場合は、まずクリーンなSRTを生成し、下流で変換してください。XMLを手作業で編集するのは時間がかかりますが、プレーンテキストのSRTを編集して再変換するのは数秒で済みます。

正しい開始形式の選び方

ほとんどのユースケースでは、まずSRTを生成しましょう。どの文字起こしからでもSRTを直接書き出せます。プレーンテキストエディタで誤字を修正し、YouTubeにアップロードして、動画ファイルに添付できます。配信先が自社サイトのHTML5プレーヤーなら、書き出しをVTTに切り替えてください。放送局やOTTプラットフォームが配信経路に入る場合は、仕様が求める正確なプロファイルを確認した上で、SRTソースから変換します。

フォーマット自体がボトルネックになることはほとんどありません。視聴者が気にするのは、正確さ、読みやすい改行、正しいタイミングです。これらが整っていれば、フォーマット変換は数秒で終わる作業です。ConvertAudioToTextは、あらゆる音声・動画ファイルからSRTとVTTを直接生成し、作業に使えるクリーンなソースを提供します。TTML配信が必要な場合は、ラフドラフトから変換するのではなく、そのSRTを変換入力として使ってください。

よくある質問

SRTとVTTの違いは何ですか？

SRTはタイムコードのミリ秒区切りにカンマを使い（00:00:01,000）、ヘッダー行がありません。VTTはピリオドを使い（00:00:01.000）、WEBVTTヘッダーで始まります。VTTは話者ボイスタグ、パーセントベースの配置、CSSスタイリングにも対応しています。HTML5のWeb動画にはVTTが適しています。クロスプラットフォーム互換性を最大限求めるなら、SRTの方が広く届きます。SRT vs VTT比較で、2つのフォーマットの選択について詳しく解説しています。

NetflixはTTMLまたはIMSCを必須にしていますか？

Netflixは、ほとんどの言語の字幕・SDH納品物に対してTTML1（ファイル拡張子.xmlまたは.ttml）を必須としています。日本語コンテンツに限っては、Netflix独自のIMSC 1.1プロファイルに基づき、IMSC 1.1が必須です。この2つは関連しています。IMSCは制約付きのTTMLプロファイルですが、Netflixの仕様書での呼び名は具体的です。提出前に、現在のNetflixパートナー納品ドキュメントで正確なプロファイルを確認してください。

SRTをTTMLに自動変換できますか？

はい、ただし条件付きです。一般的な変換ツールはタイムコードとテキストを正確に転送します。ただし、特定のOTT仕様が要求するプラットフォーム固有のプロファイル指定子、パーセントベースのフォントサイズ、フレームレートのタイムコードモードまでは通常設定してくれません。自動でSRTからTTMLへ変換した後は、配信前に必ず対象仕様に照らしたQCチェックが必要です。

YouTubeではどのフォーマットを使うべきですか？

SRTとVTTのどちらもYouTubeで動作します。YouTubeはこの2つを含む複数のフォーマットに対応しています。SRTはほぼすべての文字起こしツールが出力する形式で、手動編集も簡単なため、より一般的に使われています。文字起こしワークフローがVTTを生成するなら、それでも問題なく機能します。YouTube字幕に特化した話ですが、字幕ジェネレーターを使えば、音声や動画のアップロードからどちらの形式でも生成できます。

出典

• Netflixパートナーヘルプセンター: Timed Text Style Guide General Requirements
• Netflixパートナーヘルプセンター: Netflix IMSC 1.1 Text Profile
• Amazon Prime Video Direct: Caption Requirements
• YouTubeヘルプ: Supported Subtitle and Closed Caption Files
• W3C: WebVTT: The Web Video Text Tracks Format
• W3C: TTML Profiles for Internet Media Subtitles and Captions (IMSC 1.2)
• MDN Web Docs: IMSC: Subtitles and Captioning for the Web
• DVB: DVB-TTML Subtitling Systems