SyncController技術メモ - 「時刻情報と映像」編
(title image - PexelsのIana Pugachovaによる写真)
必ずしも現状のバージョンの話だけではなく、今後も含んだ仕様技術の詳細、ほかの選択肢、などを記しておきます(Facebook記事のまとめです)。
NTP
SyncControllerはNTPというインターネット標準の時刻同期プロトコルを使用します。これはWindows、MacOSなどで標準的に使われており、要はインターネット上の正確な時刻を持つサーバーから時刻情報を取得し、ネット内での伝送遅延を考慮したうえで、ハードウェアが持っている時刻をできるだけ正確な時刻に近づけるというシステムです。
詳しくはこの辺りがわかりやすいかな。
いくつかある制限として、
- ネットの遅れ(latency)は勘案されているが、行きと帰りの遅延が同じという前提がある(上のリンクの記事にもその理由が書かれている)
- 当然サーバーの(ネット上での)距離が遠いと、誤差も広がる
- (OSの実装上の問題だが)時刻がずれているからといって、急にその時刻に合わせると動作中のソフトウェアが混乱する可能性があるので、「徐々に近づける」
- 仕組み上、1mS(ミリ秒)以下の精度は保てない(実用では10 - 50mS程度)
その時刻サーバーについては、MicrosoftやGoogleなどのネット大手も提供していましたし、日本では政府の研究機関 「情報通信研究機構」が日本標準時刻情報(電波時計用の電波もここが送信)の一つとして提供しています
が、例えば国を移動すると日本にあるNTPサーバーが遠くなる、などの問題がありました。最近ではそれを解決するこういうプロジェクト
ができ、 "pool.ntp.org" というドメイン名でアクセスするとほぼ一番近いNTPサーバーにアクセスすることができます。まだ世界中すべてとは言えませんが、かなりの地域をカバーしています。
たとえばこのサーバーのうちの一つに、往復2mSでアクセスできれば、そのサーバーと同期させることで1mS以下の精度で同期することができます。
ただ残念ながら、現在のOS標準の時刻同期または時刻取得ライブラリでは、上にあげたように「さっき大幅にずれてて、徐々に合わせている途中」かもしれないのと、1秒以下の時間情報を提供していないことが多いです。またユーザーや場所によっては遠いNTPサーバーに設定しているかもしれません。
PTPとは
PTPは以上のNTPの制限を減らし、精度を上げるために開発されたプロトコルです。技術情報はこちらに。格段に複雑になっています。
たしかLinuxではライブラリで、WindowsではOSのAPIで高精度な時刻が提供されます(Windows 10 2018Oct Update以降、Windows Server 2019以降)。(MacOSについては要調査)
ただし、経路途中のネットワークハードウェアが高精度クロックに対応している必要があります。ネットワークインターフェースなどのハードウェアレベルでの遅延も管理しているからです。サポートしているルーターなどの一覧はこちらにあります。
ネットワークインターフェースについては、サーバー用と謳われているものならほぼ大丈夫です。このあたりかな。
マザーボードの対応については、使用されているチップについて調べる必要があります。ノートPC・ラップトップについてはほとんど非対応じゃないかと思います。
PTPの時刻サーバーとしては、例えばこういった製品があります。
ただ、インターネット上に置くとなると経路上すべてのルーターなどが対応する必要があるので、現状では現実的ではありません。
NTPでも高精度時刻情報を！
上記のように、「ネットワーク遅延ができるだけ小さければ」取得できる時刻情報の精度は上がります。もし、pool.ntp.org に ping してみて、
このくらいの遅延ですまないようなネットワークであれば、ローカルネットワークにGPSベースのNTPサーバーを構築する、という方法もあります。こちらに解説しています。
GPSが見えるところ(空の半分程度が見えるような窓のそばなど)にこのサーバーを置く必要がありますが、ローカルネットワークに置くことによってそのネット上のすべての機器の時刻情報がだいたい1mS程度で同期させることができます(実証済み)。
映像ストリームにタイムコードをバンドルする
SyncControllerで生成したタイムコードを入力して収録した映像データには、高精度な実時間タイムコードが付加されていますが、現在のところ、例えば ATEM mini PRO といった比較的手ごろな配信機器にはタイムコードを付加してストリーム配信する機能はないようです。
LiveShell Xには、HDMI/SDIのエンベデッドタイムコードではなく、NTPから取得した時刻をベースにタイムコードを生成し付加する機能がファームウェアアップデートでサポートされています。
規格としては以下のISO/IEC 14496のようなので、受け取り側がサポートしてれば処理することができると思います。
参考技術仕様・製品など
ISO/IEC 14496-10:2020 -
Information technology — Coding of audio-visual objects —
Part 10: Advanced video coding
動画データの中にどうタイムコードを組み込むかという仕様です。以下のAWSはこれに沿ったデータを扱うことが可能のようです。仕様書はこちらからダウンロードできます。
NDI
ネットワーク上の映像フレームワークであるNDIには、その仕様中でタイムコードの記述があるようです。それを使用して、映像ソースからタイムコード付きのネットワークストリームを出力する製品もあります。
これはBlackmagic DesignのDecklinkなどでSDI/HDMIの映像信号を取り込み、NDIストリームデータとして吐き出すソフトウェアですが、ソースにエンベッドされているタイムコードにも対応しているようです。
SMPTE
SMPTEではネットワーク時刻同期について以下のように定義されています。
JVC CONNECTED CAM STUDIO
JVCの業務用カメラはネットワークストリームを直接送信できるのですが、GPSまたはNTPでの時刻取得をサポートしています。
で、リモートで受け取ったタイムコード付きのストリームを、同期を合わせてスイッチすることができます。
これはある意味理想の環境です。が、ちょっとお値段が…。(4入力モデルで130万円)
AWS
AWSメディアサービスではタイムコード付きのストリームをサポートしており、
というエンコーダで送り込んだタイムコード付き映像ストリームをこういったフレームワークで処理することができます。
で、例えばタイムコードをエンベデッドされた同じ映像ストリームを2系統受け取っていれば、どちらかが途切れたときもタイムコードで同期されているのでフレームがずれることなく切り替わる、ということが可能になっています。これを応用・延長すれば、タイムコード同期の複数ソースをスイッチングすることも可能だと思われます。
サポート Welcome! いただいたサポートは今後の研究開発や寄付に使わせていただきます。