トランスコード後に音声だけが同期ずれする原因は何ですか？

トランスコード後に音声がずれるのは、生成された音声のタイムラインが動画とまったく同じ速度またはタイムスタンプ境界で進まなくなった場合です。

ダイレクト再生では、クライアントが元のコンテナとそのネイティブなタイミング情報をそのまま利用するため、問題が見えないことがあります。一方、トランスコードでは、一方または両方のストリームをデコード、リサンプリング、再エンコード、タイムスタンプ付与、セグメント化、再多重化します。まず、ずれが一定のオフセットなのか、徐々に拡大するドリフトなのか、シークや再開によって発生するジャンプなのかを判断してください。これらのパターンは、メディア処理パイプライン内の異なる箇所を示します。

トランスコーダーを変更する前に同期エラーを分類する

シークせずに最初から再生し、開始時・中間・終了間際のオフセットを記録します。バックグラウンド音楽で推測するのではなく、目に見える衝撃音や発話の子音がある場面を使ってください。

一定のオフセットが変わらない場合は、初期タイムスタンプ、編集リスト、受信側の遅延、またはクライアント設定が原因と考えられます。ずれが着実に拡大する場合は、クロックレートの不一致、フレームレートの解釈、音声のストレッチ、またはリサンプリングが疑われます。シークや再開の後に突然ずれる場合は、セグメントおよび再開時のタイムスタンプが原因です。

字幕を無効にし、クライアントの手動音声遅延設定をゼロにした状態でも測定を繰り返します。一定のオフセットだけで変動するドリフトを補正すると、特定のタイムスタンプで症状を隠すだけになります。

元のファイルが同期していることを確認する

信頼できるデスクトッププレーヤーでソースをローカル再生し、互換性のあるメディアクライアントでダイレクト再生します。トランスコード時にずれるのと同じタイムスタンプ範囲をテストしてください。

ソースもローカルでずれる場合は、サーバーを変更する前にメディアファイルを調査または修復します。トランスコード経路以外ではソースが同期している場合は、ファイルを保持したまま、メディアサーバーの再生方式の判断、FFmpegコマンド、クライアントのバージョンを記録してください。

同じコーデックを使用し、タイムラインが正常であることが分かっている別のファイルを対照として使います。問題がある作品が1つだけなら、ソースのタイムスタンプまたはコンテナメタデータが疑われます。1つのクライアントで多くの作品が失敗する場合は、共通のトランスコーダー、セグメンター、またはプレーヤー経路が原因と考えられます。

実際に変換されているストリームを確認する

セッションが、動画ストリームをコピーした音声のみのトランスコードなのか、コーデック変換を伴わない再多重化なのか、動画と音声の完全なトランスコードなのかを確認します。これらの経路では、タイミングの境界が異なります。

音声のみの変換でも、シーク後に同期が失われることがあります。Jellyfinの問題では、動画ストリームをコピーしたままE-AC-3またはDTSをAACに変換すると、シーク後に音声がずれる現象が再現されています。

動画、画質、字幕を変更せず、クライアントが対応する音声トラックに切り替えます。セッションがダイレクト再生になり、ずれが消える場合は、動画エンコードの性能ではなく、音声のタイムスタンプ、リサンプリング、チャンネル変換、または生成される配信コンテナに注目してください。

ZimaSpaceの音声トランスコードパイプラインの概要では、このストリーム単位のテスト結果を解釈するための関連メカニズムを説明しています。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

最初からの再生、シーク後、再開後の再生をテストする

同じクライアントとファイルを使い、ゼロから中断せずに再生する場合、バッファー範囲を超えてシークする場合、保存位置から再開する場合の3つの制御セッションを実行します。同期が変化した正確なタイミングを記録してください。

トランスコードされた4K再生では、最初からは同期していても、スクラブ、チャプター変更、または再開後にずれることが報告されています。区別するポイントは、メディアをデコードできるかどうかではなく、トランスコード中のタイムライン変更です。

別のJellyfin報告では、ソースファイル自体が正しい場合でも、再開に固有の同期ずれが発生しています。このパターンは、ライブラリ全体の再多重化を行う前に、再開処理に原因を絞り込めます。

シークまたは再開だけが失敗する場合は、アプリケーションにその विकल्पがあるなら、別の配信コンテナまたはクライアントプレーヤーをテストします。結果をタイムスタンプ再開処理に帰属できるよう、中断しない再生を対照として残してください。

ソースのタイミング、フレームレート、音声ストレッチメタデータを調査する

メディアプローブを使用して、動画のフレームレートとタイムベース、音声サンプルレート、ストリームの開始時刻、再生時間、負のタイムスタンプ、編集リスト、トラック遅延やストレッチ値を記録します。最初と最後の表示タイムスタンプを比較してください。

一部のMatroskaトラックには、異なるフレームレートのソースからの音声に合わせるため、意図的な線形タイミング調整が含まれています。Jellyfinの問題では、元のコンテナでは利用できるものの、トランスコード時に正しく処理されない線形ドリフトのある音声トラックについて説明されています。

音声の再生時間が動画の再生時間と比例して異なる場合は、音声を一度だけ明示的にリサンプリングまたはタイムストレッチし、クリーンなタイムスタンプで再多重化した修正版のテストコピーを作成します。元のファイルは保持し、一括修復を適用する前に1作品でテストしてください。

HLSまたはfMP4のセグメントタイムスタンプの挙動を確認する

トランスコーダーのコマンドで、シークフラグ、タイムスタンプのコピー、負のタイムスタンプの処理、HLSセグメント形式、セグメント長、クライアントがバッファー範囲を超えた後に新しいトランスコードプロセスが開始されるかどうかを確認します。

Jellyfinのタイムスタンプ調査では、不正確なシーク処理によって、HLSストリームが元のタイムラインからずれた位置で再開される可能性が確認されました。主な問題はトランスコード後のタイムスタンプの不整合であり、その結果、クライアント側で表示されるタイミングにも影響しました。

無関係なバージョンのコマンドラインフラグを本番コンテナにそのままコピーしないでください。まず、サポート対象の構成内でサーバーとクライアントを更新またはロールバックし、再生成可能なトランスコードセグメントだけを削除します。そのうえで、アプリケーションに選択肢がある場合は、MPEG-TS、fMP4、またはネイティブプレーヤーの挙動を比較してください。

最小限の修正を適用し、再生時間全体で検証する

テストで原因を確認できた分岐に沿って対応します。互換性のある音声トラックまたはクライアントを選ぶ、問題のあるシークや再開経路を避ける、サポート対象のストリーミングコンテナに変更する、メディアサーバーのビルドを更新または固定する、またはタイミングメタデータが壊れたソースを1つだけ正規化します。

あるテレビアプリで1本の映画がずれるからといって、すべての映画を再エンコードしないでください。クライアント固有の問題はクライアントまたは再生プロファイルのレイヤーで修正し、ソース固有の線形ドリフトはそのファイルのタイミング修復で対応します。

修正した経路を最初から最後まで検証し、元の失敗地点付近でもう一度シークと再開を行います。再生時間全体でオフセットが安定し、生成されたセグメントが期待どおりのタイムラインを保持し、クライアントの再起動とサーバーの再生成後も同じ設定が維持されて初めて、問題は解決したと判断できます。