junpei yoshino

ネットワークのパケット処理プログラミングを昔チームでやっていました。その当時工夫してやっていたことを簡単に紹介しようと思います。当時作っていたものの1つは、PGW/GGSNでした。これはLTEや3GのEPC(Evolved Packet Core)というモバイルコアを構成するものの1つで、端末から外部ネットワークに抜けていく時に通っていくものです。

https://github.com/mixigroup/mixi-pgw このソースコードはMITライセンスですが、依存でリンクすることになるソースコードのライセンスに留意して活用ください。

パケット処理は、トンネルのためのヘッダーのつけ外しです。コントロールプレーンでトンネルのIDや宛先を決めて、その状態をデータプレーンに持たせて、1パケットづつ処理していきます。14.8M lookup per second程度のREADとパケット処理が必要です。また、その最中にもコントロールプレーンでlookupするテーブルの書き換えが走ります。このテーブルのサイズとしても数万から数十万程度を性能を測るターゲットとしていました。

まずパケット処理のアーキテクチャとしてデザインの根底に考えたのは、2点です。(1)開発とテストがしやすいことと、(2)デプロイがしやすいことがそれにあたります。これは進化をしやすくするために必須であると考えます。

(1)開発とテストのしやすさ

データプレーンとコントロールプレーンが連携して動く必要があります。一方、データプレーンはDPDKなどを使い、またコントロールプレーンは単純なソケットプログラミングです。コントロールプレーンで受け取った変更要求に対して、データプレーンの更新を同期的に行う場合には悩みが発生します。

予備系を含めた複数系統のデータプレーン全てに対して変更が成功した場合に成功を応答するのか?という問題が生じます。

YESである場合には、全てのデータプレーンプロセスが動いて初めて成功になるので信頼性は下がる方向になります。全てのデータプレーンプロセスが正常に応答している必要があります。

NOである場合、ステートが同期されていないデータプレーンの存在を許すことになります。

またYES/NOどちらであったとしても、難しいところがあります。また、開発時はデータプレーンのモックを用意する必要があります。

この悩みを解決するために、データベースのレプリケーションの仕組みを活用した方式を考え、それを実装しました。普段使い慣れたMySQL系のデータベースのbinlogによるレプリケーションをデータプレーンのパケット書き換えを行うプロセスに組み込みました。

データベースのレプリケーションは、変更内容を順次バックアップサーバに送り同じ変更をすることで同一の内容を保とうとします。データプレーンのプロセス内にデータベースにあるトンネルに関する情報をメモリー内に全て保持し、mapとして処理することで高速にlookupを行うようにしました。

これは、同じデータプレーンのステートを持つプロセスを複数台同時運用しながらも、コントロールプレーンはデータベースを1つ書き換えれば良い状態を作ることができます。

開発時もコントロールプレーンはデータベースの更新のみに集中すれば良く、データプレーンのプロセスとは綺麗に分離されます。

データプレーンのテストについても、コントロールプレーンと独立してテストできるメリットが生まれました。

全てが幸せかというとそんなことはありません。

データベースのレプリケーションには、レプリケーション遅延というものがあります。同期的に動く設定をすれば遅延なく同じデータになりますが、書き込み性能が大きく落ちるので用途によりますがそのような設定をしないことが多いかと思います。

データベースを書き換えて成功を応答して、データプレーンにパケットが届くまでにレプリケーションが間に合ってない状況になるとデータプレーンにおいて不整合が発生します。

これを回避するための仕組みを持つ必要がありました。

そこで活用することにしたのが、GTP-Cにある、Private ExtensionというInformation Elementsの活用です。

--

--

この記事では、RGBAとYCbCrの変換におけるITU-R BT.709の話をします。映像信号に含まれる色表現の変換について我々の中で間違えたことがあったので共有できればと思います。

自社のライブ映像編集でSMPTE 2110を活用しています。SMPTE 2110とは、徐々に映像業界で導入され始めているライブ制作をIPネットワークの上でやるために使われる規格です。この規格は映像や音など要素ごとに分割して扱うため、ソフトウエアでも処理しやすいのが特徴です。

我々は、SMPTE 2110に関連するソフトウエア開発を行っています。映像は、SMPTE 2110の中で、-20(ダッシュ20)というパートで扱われています。SMPTE 2110–20では、RGBやYCbCrでの表現などいろいろなパターンがあります。

我々が使っているベースバンド信号をIPに変換する機材では、YCbCrで映像をIPネットワークに流しています。今日はこのYCbCrとRGBの変換の話をします。ネットワーク中を流れるYCbCrを含むパケットをサーバに引き込んで、映像の画像を加工等の処理をします。OpenGLなどでRGBAな素材を映像に混ぜ込みたいため、変換の必要が発生します。

この変換の計算について教えてくれるのが、ITU-R BT.709 です。我々はBT.709–6を活用して計算を行っています。

ドキュメントは公開されているので読めばわかると言えばそうなのですが、これを読まずに変換を想像でやっていたときは、若干の色の違いが発生して、悩みました。具体的には、BT.709–6では、各値ごとに値域があり、その範囲に合わせる必要がありました。

YCbCrが10bitでRGBが8bitの場合

Y: 64 から 940

Cb,Cr: 64 から 960

R,G,B: 16 から 235

以下の記事で紹介したWebRTCと2110を繋ぐMoaniというアプリでもこの計算をしています。

映像信号の画素等の表現を変換するときは、その値域について調べてから実装するようにしましょう。

--

--

弊社の TIPSTAR というサービスでは、映像の編集と拠点間伝送にSMPTE 2110を利用しています。

また、リモートワークでも映像確認を可能にするためWebRTCによる(ほぼ)リアルタイムな映像をインターネットを通して送信しています。これによりリモートプロダクションを可能にしています。

従来、SMPTE 2110とWebRTCはSDIゲートウエイとPCIeベースのSDIキャプチャボードを利用して構成していましたが、SMPTE 2110を直接サーバで処理し、WebRTCに送信するアプリを開発しました。SMPTE 2022–7も実装しており、映像伝送区間のシームレスなプロテクションにも対応しています。

放送制作等で使われているIPパケットをシンプルにWebRTCに接続することができました。

私たちの部隊では、映像関連システムの設計、開発、構築、運用をしております。こちらの内容を紹介できればと思います。仲間も募集しております。

背景

SMPTE 2110でHD素材38種以上を常時流しています。

渋谷区3箇所、豊洲、大手町の都内5箇所を冗長ルートでネットワークを構築して運用しています。

各拠点間は最低100Gbps以上の冗長で接続されています。

この映像を遠隔地から柔軟に視聴するため、WebRTCを活用しています。

課題

より多くの映像処理やコンテンツ増加に対して、冗長系統を十分に作れるだけのコストパフォーマンスを得たかった。

実装したもの

今回は、NVIDIA(R)のRivermax(R)ConnectX(R)-6 Dxを利用し実装しました。

コストパフォーマンスについて今回開発した物と弊社内での旧実装を比較します。

以下は従来構成と今回開発したものを物理面からみた構成の比較です。

青と赤のネットワークはSMPTE 2022–7における2面のネットワークを示しています。

従来はSDIゲートウエイを通してSDIの信号に変換し、SDIのキャプチャボードを使いキャプチャしていました。

これに対して、今回作ったものは、サーバで直接ネットワークから映像や音声のパケットを受け取り、これを処理してSDIのゲートウエイを排除しています。

チャンネル数分のゲートウエイを用意し、ケーブリングし、ゲートウエイの設定とWebRTCのシグナリングの設定を別々でやっていたものを一括でできるようにしました。

弊社環境においては、この部分でコストが下がりました。

ソフトウエア内での工夫

WebRTCへの映像、音声の接続も今回改善を入れました。

v4l2やalsaを通して実装していたものを、直接libwebrtcにデータを投入できるようにしました。

いろいろなコンテキストを行き来して、作っていたものをシンプルにシングルプロセスで実装しています。

受信するSMPTE 2110の信号を自分のプロセス内で制御できるのも大きな強みです。

WebRTCのシグナリング情報とSMPTE 2110の情報の連携を管理するシステムも作成しました。

--

--