
草の根ST2110ことはじめ (1) PTPサーバーの導入
さよならSyncController
いきなり悲しいサブタイトルですが、
筆者の業務上必須だった動画と音声の(絶対時間による)同期を目指してここ3年ほど開発中だった SyncController ですが、残念ながらこれ以上の開発を断念せざるを得ませんでした。
理由は、コロナ以後の世界的半導体在庫払底によって、必要な半導体それも中核をなすマイコンチップが全く手に入らなかったことによりプロトタイプすらも2年以上も作れなかったこと、さらに入手可能になった最近になって、ベースとしていた開発環境 "mbed" が所有者のNXPによって終結宣言されたこと、によります。
これにより、使用部品だけでなくプラットフォームそのものからの見直し、つまりゼロベースで考え直さなければならなくなりました。
ただ動画、それも複数個所で動画をとり、さらに音声ともタイミングをとって収録したり配信したりする需要そのものは、コロナ終結後も旺盛です。そこであらたに着目したのは、2016年から2018年にかけて発表され、近年対応機器が出そろってきた
ST2110
という放送業務用のIP伝送の規格です。
ST2110って?
そのものずばりはここで説明されています。
これがとってもわかりやすい。
実際どう使うのか・どう使われるのかについては、これが一番かなと思っているんですが、

「同期」という観点にフォーカスを絞ると、これまでは、
時刻の同期はタイムコード(LTC)
ビデオ(フレーム)の同期はGENLOCK
オーディオの同期はワードクロック
という3つの同期信号・データによって同期させていました。なので状況や機材によっては一つの機器に対してほんとに3本の線が「同期のためだけに」必要とされていました。
それを、映像・音声データもひっくるめて一つのネットワーク中で、物理的には慣れ親しんだLANケーブルを一本それぞれにつなげるだけで、すべて完結させてやろう、というのがST2110の狙いです。
きっかけは
の記事を、Facebookの業界関係者用グループの中で紹介されていたことです。いまや映画やテレビの業務用機器のトップメーカーといってもいいBlackmagicが満を持して参入するってことは、この規格が瞬く間に広がる可能性があるんじゃないか、と。なんたって8Kとか12Kとかのカメラで個人でも買えそうな金額の製品を出し、そしてなにより!この配信時代が始まって価格破壊ともいえる映像スイッチャー兼映像配信機器で一般にもメジャーに躍り出たBlackmagicだから!
おお、使えそうじゃん、でも?
で、記事を読むとおおむね期待通りだったものの、1点気になったのは、
一方、Blackmagicの機器同士をマスターとスレーブで接続した場合、「Mini BiDirect 12G」に関してゆらぎが見られ、整合する時としない時が存在する。ただし、その誤差は50ミリ秒程度の微細な乱れである。
というところ。正直これは「やっぱりか…」という感じなのだが、Blackmagic Designの機器はどれもみなあまりにも安いため、いわゆる「付加的」機能の精度や性能がいまいちだったり、ということがよくある。つまりそこには期待せずに専用機器を使え、ということなんだろうと思うのだが、この場合は想像通り
PTPグランドマスター
の非存在が問題になりうる、ということがレビュー記事からよくわかる。なぜなら30ミリ秒のずれというのは決して小さくなく、たとえば収録側で欠落があってそれが集積されると、何時間も収録した時にほかの機器での収録と差が出てしまわないか、という心配が出てくる。おそらく大丈夫なんではとは思うが、そのずれがセイコーソリューションズ製の専用機器=PTPグランドマスターと同時に使う限りは心配ない、ということは、やはり「あった方が何倍もいい」ということだろうと思います。たぶん。
今度はアレが必要なの
でそのPTPグランドマスター、実体はオニ正確なタイム/クロックサーバーなんだけれど、とやらはだいたいこんな感じのお値段で…。
実はこれはPTPではなくNTPサーバーのみ対応している製品なんだけれど、まあ軽く80万円をこえますよと。放送局とかのレベルじゃないとちょっと…てな感じですよね。PTPだとさらに、おそらく一番下位レベルの製品で100マソ越えではないかと。
実は!GPS/GNSSに対応したミリ秒精度のNTPタイムサーバーは比較的簡単に自作できてお値段もお安いのです。実際に作ってみて、もう何年も正常に稼働しています。のがこちら。
部品合計で1万円ぐらいだったかな。同じネットワークにぶら下げておきさえすればどこにおいてもかまわないしキーボードやらディスプレイを必要とするわけではないので、窓のそばに放置するのもありです。とてもお手軽でなかなかな精度(ほぼ数ミリ秒以内)の時間が得られます。なんと80万円が1万円に!まあそりゃ安定性とかGPSが受信できないときとかには動かないわけですが、家に固定して自分ちで使うだけならもう必要十分。ふつう家にはタイムサーバー置かないか…w
でもこの構成をそのままPTPにも適用するのさすがに不可能で、なぜならPTPは高精度を謳っているため、今までざっくり「ネットワーク往復にこれだけかかったからうちらのマシンはこれだけずれてるだろ」と目分量でwやってた計算が成り立たなくなるから。ソフトウェアからネットワークのハードウェアを経由して相手方にいってまた返ってくるまで、どこにどのくらい時間がかかったかをナノ秒単位で計測し、それをもとに正確な時間を割り出すのがPTPだから。なのでネットワークアダプタつまりネットワークに一番近いところに「ハードウェアのタイムスタンプ」が必要になるわけです…。
そ、そういえば!ラズパイの新しい奴 Raspberry Pi 5Bでは、ネットワークインターフェースがタイムスタンプに対応した!んじゃなかったっけ?
ならほとんど同じ方法でタイムサーバー、いやPTPグランドマスターも作れるのでは!?
というわけで作ってみました。というのがこのnoteの骨子。つまり前置き。長かった…。
で、PTPそのものの解説はこれがとても分かりやすいのでこれでおさらいしておいてと…。
お手軽PTPグランドマスターの製作
(この項鋭意執筆中 - アップデートするかもです)
三分クッキングのテーマ「おもちゃの兵隊のマーチ」をBGMに流しながら、まずこれ。
基本的にはこの手順にそのまま従います。GPSの接続や設定などは上記のわたしのnote中で紹介した記事が役に立つかも。
あ、一つあった。この中で /etc/chrony/chrony.conf を書き換えるところで、
# refclock from gpsd
refclock SOCK /run/chrony.ttyAMA0.sock refid GPS precision 1e-1 offset 0.9999 delay 0.2
refclock SOCK /run/chrony.pps0.sock refid PPS precision 1e-7上の行のrefclockがSOCKだとうまく同期されず、SHM(共有メモリ)だとうまく同期した、けれどこれは筆者のケースだけかもしれない。SOCK(ソケット)でも動かない理由はないはずなんだけど。
offsetとdelayの値は後で調整します。自分の環境の場合は
refclock SHM 0 refid GPS precision 1e-1 offset 0.421
refclock SOCK /run/chrony.pps0.sock refid PPS precision 1e-7 offset 0.1でうまく認識して同期するようになりました。
追加で、ちょっとしたTIPS、なんだけど、実質これをやらないと動かない。これそのものは次項のWindows 10/11をPTPで同期させるためのTIPSだけど、Windowsで認識してもらうために、サーバー側にも設定追加が必要。
この中で書かれているように、サーバー側の /etc/linuxptp/ptp4l.conf の中に、次の11項目の "GRANDMASTER_SETTINGS_NP" の設定が必要になる。すでにあるものは値を書き換え、無いものは追加する必要がある。ちなみにこのリンク先の文書の中で "clockCss"とあるのは "clockClass" のマチガイ。こういうのがあると油断ができないよねw (15分は悩んだorz)
clockClass 6
clockAccuracy 0x20
offsetScaledLogVariance 0xffff
currentUtcOffset 37
leap61 0
leap59 0
currentUtcOffsetValid 1
ptpTimescale 1
timeTraceable 0
frequencyTraceable 0
timeSource 0xa0ということで、実際に動かしてみました。ちゃんとGPSから時刻情報をひろって、GPSが出すPPSという1秒ごとのパルスを絶対時間の基準にして同期しているさまがわかると思います。近隣のw タイムサーバー(この場合はNTPのみ)との時間差もわかりますが、おおむね1ミリ秒を切り、数百~数十マイクロ秒レベルで追従しているのがわかると思います。タイムサーバーのほとんどは原子時計内蔵なので、ゆらぎの大きいNTPでもこれくらいなら絶対精度としては上等です。


極寒地ゆえサッシのガラスが三重!でGPS電波を通さないため、ベランダに追い出されています。同時に耐侯試験も(嘘。あー、PoEにしたいなあ。ほんとはGPSのアンテナケーブルを延長するのが正しいんですが、というかそういうモデルを選べばよかったな…。
ちなみにUSB接続のGPSユニットはこの用途には使用できません。1秒単位のパルスPPSが取れないからです。なのでこの部分については1PPS対応GPSユニットが必ず必要です。
PCを輪の中に
で、いまのところまだPTPを使用する機器を持っていないので、うまく動いているっぽいものの確認できない。ということで、そこらにある(ないかw)デスクトップPCをまず同期させちゃいましょう。
必要なものは、まずハードウェア・タイムスタンプ対応のネットワークアダプタ。デスクトップPC、サーバー、またはそれに準ずるものなら対応していることが多いけれど、それ以外は調べるしかない。モバイル用プロセッサが載っている超ミニPCはチップセットその他もノートPC用であることが多いので注意を要します。PCIeバス用などはサーバー用と書いてあれば間違いなく動作します。USBにつなげるものはほぼ無理。WiFiは論外(これはしょうがないでしょうね)。
Windowsの場合
まず、Windows 10 1809以降またはWindows 11 (PROじゃないとダメという情報もあるが未確認)が必要。
対応しているネットワークアダプタであれば、デバイスマネージャー→ネットワークアダプタの各ハードウェアのプロパティを参照したときに、

とハードウェアタイムスタンプのOn/Offを変えられる項目が見えるはず。ただ、もしかしたら対応していても項目がないものもあるかも。
[追記] とか書いていたら、さっそくこの項目がないのに対応しているネットワークアダプタを発見w。IntelのNUCに乗ってるアダプタなのだけれど、
これで、

この項目が"Yes"であれば対応しています。にもかかわらずこのネットワークアダプタのプロパティを見ても上記項目""は出てこないw
てことで、もし自分のマザーボード上のネットワークアダプタの型番がIntelのものであるとわかれば、このIntelのサイト上で対応しているかどうかは確認できます。
具体的な設定はこちらに詳しいのだけれど、
Precision Time Protocol Validation Guide
または
https://github.com/microsoft/W32Time/tree/master/Precision%20Time%20Protocol/docs
のなかのドキュメント
実はこれだけでは足りないので、以下のレジストリの追加もさらに必要。
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient /t REG_DWORD /v EnableMulticastTx /d 1設定出来たらタスクマネージャーの「サービス」から W32Time という名前のサービスをさがし、右クリックで「再起動」する。そのあと、管理者権限のコンソールターミナルから
w32tm /query /configurationとうちこんで、 以下の表示がされればOK。Enabledの項目がPtpClient以外は"0"であることを確認する。
[TimeProviders]
PtpClient (Local)
DllName: C:\WINDOWS\system32\ptpprov.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
NtpClient (Local)
DllName: C:\WINDOWS\system32\w32time.dll (Local)
Enabled: 0 (Local)
InputProvider: 1 (Local)
NtpServer (Local)
DllName: C:\WINDOWS\system32\w32time.dll (Local)
Enabled: 0 (Local)
InputProvider: 0 (Local)
VMICTimeProvider (Local)
DllName: C:\WINDOWS\System32\vmictimeprovider.dll (Local)
Enabled: 0 (Local)
InputProvider: 1 (Local)てことで、同期している状況は w32tm コマンドでばっちり確認することができました。

めでたしめでたし?
Linuxの場合
まず対応しているネットワークアダプタかどうかは
$ ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off
on
onestep-sync
Hardware Receive Filter Modes:
none
allと"hardware-raw-clock"などの項目が表示されれば対応している。もちろん"eth0"の部分はお使いのネットワークインターフェースに合わせてください。
(設定 - linuxptpを使った場合 - 鋭意執筆中。たぶん別noteにします。まあまあめんどくさそう?)
Macの場合
調べた限り、PTPタイムソースとは同期不可能のようです…。なんと…。
マジか…。せっかくMac mini M4 Pro買ったのに…。
ローカルネットを超えたいんだが
基本的にはサブネットの中だけしかリレーできません。もちろん対応するルーターを買えばいいんだけど、きっと恐ろしい値段がします。
問題は、同じサブネットのなかでもスイッチングハブを挟むと厳密にはスイッチングハブ内で処理に時間を要するので、正確に合わせられなくなります。なので、正しくはPTPに対応するスイッチングハブを導入すべきです。んがw 当然お値段は結構します…。
NETGEARのなかでは、このAVLineというのが対応するスイッチングハブです。ほかに、YAMAHAだと
が対応しています(Transparent clock)。
今後の補完計画
まずPTP/ST2110に対応した機器を導入して、組み合わせて使ってみたい。これは必要そうな現場が半年後にあるので、間に合えば現場でも使ってみますが…。
それにここまで考えてプロトタイプというか、単にラズパイとGPSレシーバーを組み合わせただけなのだけれど、この先何が欲しくなるかが見えてしまった…。ということで SyncControllerでできてたこと(タイムコード生成)はもちろんのこと、その先も目指せるかどうかやってみたいな、と思っています。