競輪視聴体験を アップデートする WINTICKETの映像伝送技術 近藤信輝 株式会社WinTicket 株式会社サイバーエージェント

•所属 株式会社サイバーエージェント 株式会社WinTicket 映像技術PM（スポーツテック事業・番組技術・配信/伝送） 過去：スタジオ戦略室 ABEMA etc KAIROS導入プロジェクト それ以前：LINE ( LINE LIVE ), J-Stream, KENEK Japan •映像とIPの狭間にいるテクニカルマネージャー

WINTICKET 2019年にリリースされた公営競技のインターネット投票サービス。 競輪のインターネット投票シェアは42%(※1) となっており業界No.1。 競輪に馴染みのある方々はもちろんのこと、特に若い世代に面白さを伝え 裾野を広げることを目指している。 「アリかも競輪」「すきま時間に競輪」

WINTICKETの映像配信全体 WINTICKETサービス開始当初から「映像を見ながら車券購入ができる」 ◯ABEMA「競輪オートレースCh」での配信利用 ◯上記Ch内での、毎日の番組／特別番組制作での利用 ◯WINTICKETアプリ内での複数競輪場の利用

WINLIVE 競輪が、初心者に優しくない競技と言われる所以 ● ラインと呼ばれるチームの概念がある ○ チームを組む選手自身が動力となっている（心理読み） ● 良い位置の取り合い ○ 先頭選手は主導権を得ると同時に強い空気抵抗を受け、隊列全体の入れ替わりが多い ○ また、レース前半は風除けを担当する誘導員がいる準備時間 ● 「いまどういう状況！？」となりやすい これらを解決するための新映像 →

WINLIVE 動画内のスクショに説明する - これは体力 - これは周回状況 - など レースの進捗状況 選手の体力状況 エフェクト判定・ 表示位置 データ技術による表示物

WINLIVEのシステム全体概要 ！競輪選手にセンサーを付けることができない！

WINLIVEのシステム 各種詳細 ● 描画を中心としたプレゼンテーション ○ サイバーエージェント Developers blog 「競輪オリジナル中継映像「WINLIVE」の描画システムについて」 ● 画像処理 消費HP計算のプレゼンテーション ○ 上記のBlog記事内からリンク 「競輪選手の体力を視覚化するための物体認識と データサイエンスの融合」

WINLIVEの運用課題 解決方法の条件 屋上 作業スペース Optical 2D用映像 CG出力

映像伝送変更のためのシステム前提 競輪場 2D用映像 スタジオ CG出力 ● 映像伝送経路の変更 ○ Phase0では、合成後の映像音声の伝送を行っていた。 ○ ３D計測用カメラ＋２D座標用映像＋余剰で８伝送が必要。 ● 帯域のコントロール／選択 ■ Ether回線とVPN回線のどちらを使うか。 IPエンコーダ IPデコーダ IP回線

映像伝送機器の検証（機器選定） シンク ロ出力 操作性 監視性能 音／サイズ 調達金額 備考 A 社 明記 明示せずにシン クロ メトリクス弱 大の大 High 電源２重化 M 社 対応明 言でき ず メトリクス弱 小の中 Mid フロントパネルあ り Ha ivi sio n 明記 設定必要 メトリクス強 小の小 High Mini SDI

シンクロ伝送に必要なもの ● エンコード設定／デコード設定が全Ch同じこと ○ Makitoの場合、H265の推奨がある Makitoの場合、マルチシンクはデコーダの機能ではある ○ 設定が同じでも、すんなりつながるとは限らない ● 共通のNTPサーバを参照できること ○ 今回は、閉域網の中に、独立したNTPが存在していた ● 十分な帯域のネットワーク ○ 今回は、閉域網のため安定度が高い。 だが、帯域の制限は存在している。

映像伝送機器の検証（現地テスト） SEIL ルータ Timecode 表示用 カメラ画像 既設伝送機 VDA or A社 or Makito 下はA社 上がMakito スタジオへ Complexityな環境での単体試験 ● 現地回線／SEILのルータをつかった負荷検証 ● 配線関連／システム接続関連の実地検証 ● スタジオ側は、正常受信の確認

映像伝送機器の検証（現地テスト 日程その1） ● いきなりMAXビットレートを突いてみたりしちゃう ● A社のエンコーダは、すんなり接続。テストを実施。 ● いっぽうMakitoのテストは… ○ 弊社側での準備不足 ■ ベストプラクティス作らず突入 ■ ３D計測など伝送以外のテスト負荷 ■ 立て直しできずに予定時刻を終了

映像伝送機器の検証（現地テスト 日程その1） A社機材 タイムラグ検証Shot ・東京との時刻合わせのため、PC画面を利用。だいたいの確認用。 （詳細確認は画面に焼いたTCで。信号としてのTCは仕組み上、スルーしないため） ・遅延のコントロールと帯域のコントロールの詰めが必要であった。

映像伝送機器の決定 複数台 数の動 作 操作性 監視性能 音／サイズ 調達金額 備考 A 社 不明 明示せず にシンク ロ メトリクス弱 大の大 High▲ 電源２重化 Ma kit o OK 設定必要 メトリクス強 小の小 High□ Mini SDI サイズ：持ち運びが容易である。 調達金額：Encoder／Decoderの役割が分かれている部分の評価

映像伝送機器の検証（現地テスト２） ● 東京でLAN環境でのベストプラクティス作って乗込み ● 映像伝送後の映像認識に問題ないことの確認 ● Makitoは東京LAN環境で成功した設定が,,, ○ 100Mbpsを確保したネットワークを利用して ６Mbpsのエンコードを３つ４つするだけで、 Makitoの通信のパケットロスが２０％を上回る。 ○ 同じ回線で、同時に使っているA社機器では、 映像の破綻や問題は発生していない。 （イコール、NW機器の問題である可能性は薄い）

映像伝送機器の検証（現地テスト２） ● EncoderのStream設定の LINK PARAMETERSの設定が決まらない ○ Timing ＆ Shaping と Tos [VBR][0x80]で接続不安定 [CBR][0x80]で接続安定 [VBR][0x00]で接続不安定 ■ ThroughputのMaxでVBRだと、 破綻するのはなんとなく理解できる ■ 推奨がCVBRとのことで、 CVBRで安定稼働 (Encoder→CBR,Stream→CVBR) 専用線の場合は､ほとんどのケースはTosのバ リュー0x00で問題なく動きます。 そうでもないんだけど

映像伝送機器の検証 ● DecoderでのDelay値のRangeが定まらない Rangeが使用中に変動する。 →Rengeのレートが上振れて外れると、たまにBlackが現れる Delayを1000msを超えることはなさそうなので、1000msで固定した。 （今回は低遅延に拘る必要がなかったが、他機器を考慮しても限界な値…） 専用線をつかっているのに、なぜ・・・？（Encoder/Decoderは100ms） CBRなど、設定変更をしても、変化がなかった 将来のバージョンで 改善される予定とのこと

● 100MベストエフォートVPN回線 ● IP-SECあり(Ether側もある) ● OUT４,IN３の映像追加 ● マルチシンクOFF 固定値に。 ● CPU負荷の吹き上がりがリニア ● Ether回線の方は、ルータ処理能力ほんのり変わった程度 ○ かなり心配だったルータ処理能力は問題なさそう。（受信側ルータも） ○ ６Mbps+Overhead25％ｘ７本＝52.5Mbps（＋IP920の12Mbps） 64Mbpsが想定アベレージビットレート ネットワーク機器の処理能力 ● 別目的／別タイミングで試したVPN回線でのテストは顕著に値が変わった

マルチシンク映像伝送運用 これまでとこれから ● 1000時間以上運用してきたが、ノートラブル ○ ６Mbps／８ch伝送 伝送つなげっぱなしで数日設置も （映像信号を久しぶりにINするときには、多少の注意） ○ ただし、利用用途はあくまでも画像認識が中心 ○ リモートプロダクションの運用も経験 ● 設定のパターンをもっとわかりやすく ○ ベストプラクティスの提示の難しさ ○ 低遅延には今後期待 ● SDIではない出力手段 ■ データ処理を前提としたワークフロー ■ Haivision製品間でのもっと密接した連携を

マルチシンク映像伝送運用 これから SDIではない出力手段 ■ Makitoのデコーダが対応しているからこその技術 ■ SEIメッセージの基本と応用 ■ IPプロダクションでの利用可能な仕組みへ ■ 他社連携（クラウドスイッチャー） 受信 サーバ (not encoder) クラウドSW OR クラウドSW Global or Private モニタ 認識など 別用途