Tokyo Video Tech #3 開催レポート

Published in

Tokyo Video Tech

14 min readJun 5, 2019

Reported by Takesato Hayashi
Photograph by Akihisa Katsumi, Kanako Tomita

2019年4月22日、 Tokyo Video Tech #3 Foundation (Foundation − オンラインビデオを支える基盤にフォーカス)がFastly K.K.で開催された。今回の参加者は28名。スピーカー3名、うち1名は海外から特別ゲストによるプレゼンテーション。終了後は、スピーカーと参加者が交流を楽しむNetworking with Food & Beverage、オンラインビデオに関わるエンジニアが集まる、素敵な一夜となった。

イベント告知ページ：https://www.meetup.com/Tokyo-Video-Tech/events/260331664/

# Opening remark

Opening remark は、オーガナイザーの林岳里。

きっかけは昨年12月。Tokyo Video Tech #1のアナウンス直後に、岳里がFastly K.K.のDoug Chuchroさんからイベントをサポートしたいと申し出をいただいたこと。Dougさんはエンジニアのコミュニティが経験や学んだことを積極的にシェアするスタイルが好きで一緒に何かできないか？と。それからディスカッションを重ね、本日の会では、素敵な会場と素晴らしい食事＆飲み物を提供いただき、さらに、サンフランシスコから特別ゲストに来ていただけることとなった。

最後に注目のTokyo Video Tech #4が2019年6月19日にYahoo! JAPAN 17階にあるオープンコラボレーションスペース「LODGE」にて開催されることをアナウンス。詳細はMeetup.comからのお知らせとSlack workspace <https://bit.ly/video-dev-jp>にエントリー開始時に掲載するので、楽しみにしていただきたい。

# Taipei Video Tech #3/Streaming Summit/NAB Show 2019

最初の登壇はフォアキャスト・コミュニケーションズのチーフマネージングディレクター＆本イベントの共同オーガナイザー金沢広峰さん。

Taipei Video Tech #3/Streaming Summit/NAB Show 2019と題し、今年3月に台北で開催されたイベントと今月ラスベガスで開催されたイベントを紹介。

金沢さんは3月13日に台北で開催されたTaipei Video Tech Meetup #3に日本語字幕のエキスパートとして公演した。タイトルは“Subtitles University”。日本語特有の表現であるルビと縦中横等について説明。標準規格だけでは乗り越えられない日本語表現をどう実現するのか？金沢さんのアプローチは、WebVTTを使って表示のタイミングをコントロールしつつ、字幕は画像ファイルとして表示させるというもの。これにより綺麗な日本語字幕の実現と、字幕が焼き付けされていないため１つのビデオで複数言語をサポートが可能となる。近いうちにTokyo Video Techでも、日本語字幕に特化したセッションを提供したいと考えている。

次のトピックスは、ラスベガスのNAB Show 2019で開催されていたイベントStreaming Summit。メディア技術に関わる多くの方がすでにNBA Showについては聞いたことがあると思うので、本レポートではStreaming Summitについて伝えたい。

Streaming SummitはLas Vegas Convention Centerで開催された、ストリーミングに特化した二日間の有償イベント。

公式サイト：https://www.nabstreamingsummit.com/
チケット: US$695.00
セッション: 32
スピーカー: 75人以上

金沢さんは参加してよかったセッションとして、下記4つを挙げている。
- Best Practices for Deploying CMAF, DASH and HLS at Scale
- Best Practices for Video Packaging, Playback and Low-Latency Delivery
- Engineering A Modern Super Bowl Streaming Workflow From The Ground Up
- Using VMAF, Netflix’s Video Encoding Metric to Measure QoE

公式サイトにビデオが掲載されているので、上記セッションをチェックしてみると良いだろう。https://www.nabstreamingsummit.com/schedule/vegas19/

金沢さんによるとStreaming Summitは途中から複数のトラックが走るため、より多くのトピックスをカバーしたいのであれば、二名以上での参加がオススメとのこと。そして、NAB ShowのOTT関連の展示はSouth Upper floorで行われており、移動に片道20分程度かかってしまうとのこと。展示と聴講の両方を同日にカバーするのは至難とのこと。ラスベガス滞在の二日間をStreaming Summit用に割くのが良いだろう。

# Building a Network Emulation Application with Raspberry Pi

二人目の登壇者は株式会社SPARROWS＆本イベントの共同オーガナイザー酒井克幸さん。

Raspberry Piをつかったネットワークエミュレーター開発。酒井さんがOTTアプリケーションを開発している際に、コーポレートネットワークが高速すぎて、ユーザーの挙動再現には不向きであるという課題に直面し、自らエミュレーターを作った経験について語った。

最初に、TCPのパケットロスや遅延がどのようにネットワークのスループットに影響があるのか？を調べたとのこと。そこで問題。

何パーセントパケットロスが発生すると、有効スループットが半分になってしまうでしょうか？
1. 1%
2. 5%
3. 10%

正解は1。わずか1% のパケットロスで、有効スループットが半分になる。（TCPの輻輳制御アルゴリズムとしてCUBICが使われている場合）

そこで、酒井さんは当初からの課題である高速すぎるコーポレートネットワークとデバイスの間の通信をコントロールできる、Raspberry Piを使ったネットワークブリッジを作成。搭載機能は、帯域幅調整/レイテンシーの付与/パケットロス/データの破損/パケットの複製。OTTアプリケーションのテストに必要充分な機能を備え、開発に必要な機材は、Raspberry PiとUSB-Ethernet x 2で、2万円程度で購入できるとのこと。

トラフィックのコントロールはLinuxのtcコマンドで行っている。酒井さんの開発方法については、下記のスライドに詳しく記載されているので、参照いただきたい。

“Building a Network Emulation Application with Raspberry Pi” by Katsuyuki Sakai
https://www.slideshare.net/onflow1/building-a-network-emulator-application-with-raspberry-pi/

あわせて、今回紹介したツールは“Mr.Carson”という名称でGithubにMIT Licenseで公開されている。OTTアプリケーション開発で、Charles Web Debugging Proxyでは対応できないデバイスなどを抱えている人には朗報だ。

Mr,Carson.
https://github.com/katz/mr-carson

# Best Practices of building a highly scalable, available, resilient live streaming architecture

最後の登壇者はFastly ビデオストリーミングソリューション＆パートナーシップ担当 Ashok Lalwani (Ashok)さん。

“Best Practices of building a highly scalable, available, resilient live streaming architecture”と題して、数多くの大規模配信で得た知見を紹介いただいた。

本日のトピックスは以下３つ。

ライブストリーミングのアーキテクチャーに弾力性を持たせる
エンドツーエンドのモニタリングに投資する
ユーザーエクスペリエンスを向上させるベストプラクティス

1. ライブストリーミングのアーキテクチャーに弾力性を持たせる

Ashokさんは、よく採用されているライブストリーミングのワークフローの説明から始めた。オリジンサーバー + シングルCDN + ビデオ再生時の QoSサービス(Conviva/MUX/NPAW)。徐々に視聴者数が増加するとワークフローも変化が求められ、次のステップとしては複数CDNの追加が行われる（CDNセレクター機能もあわせて導入）。視聴者のQoEは向上するが、オペレーションコストの増加とシステムの複雑さも同時に高くなる。

あわせて、システムの弾力性や全てのワークフローの可用性を考えると、オリジンサーバーとエンコーダーに冗長化が求められる。過去に行われた大規模ライブストリーミングのシステム構成図を紹介しながら、全てのコンポーネントが複数用意されていることを強調。これはシステムを保有する維持管理総費用であるTCOと、可用性や弾力性のトレードオフとなる。

複雑であり、担当システムに何が最適なのか？を決断するのは難しい。Ashokさんは、多くのOTTサービスは次のようにしているというヒントを出してくれた。

24x7のようなライブ配信を続けるものと、単発的なライブイベントのアーキテクチャーは別々に運用管理する。
自前のライブストリーミング用アーキテクチャーを運用して、実験や繰り返し利用する。

2. エンドツーエンドのモニタリングに投資する

時にメディア配信におけるインターネットはひどいもので、オリジンサーバーからエンドユーザーまで、非常に多くの仲介者が存在している。そして、トラブル発生時、少し変更を加えるだけでサービスで発生していた問題が、すぐさま軽減される素晴らしいシステムでもある。

ビデオ再生時のQoSでよく使われているメトリックス（リバッファー率/再生開始までの時間/平均スループット等）があるが、ライブイベントではこのメトリックスだけでは充分ではないとAshokさんは言う。ある特定のメトリックスの値が急激に上昇した際、「何故？」にたどり着くのが非常に困難であるからだ。このような問題に遭遇しないために、推奨したいのが“Build your end to end data pipeline”（エンドツーエンドのデータパイプラインを構築する）。ライブイベントで何が起きているのか？を把握するには、エンドユーザーから始まり、CDNセレクター、CDN、オリジンサーバーの全ての情報を掌握できていることが大事。そこから、デバッグを開始しトラブルに対処すればいい。モニタリングの例として紹介されたのは、

クライアント側のQoE
- Conviva
- MUX
- NPAW

総合的なモニタリング
- TouchStream
- Internal Alignment Checking Tools (based on hlspider<https://github.com/brookemckim/hlspider>)
ログの収集
- SumoLogic
ダッシュボード＆Slackを使ったアラート

3. ユーザーエクスペリエンスを向上させるベストプラクティス

最後によく使われているテクニックを紹介した。

1. ターゲットデバイスに合わせてビットレートやマニフェストを用意する
各デバイスにあわせたマニフェストを用意することで、ユーザーエクスペリエンスとコストを最適化できる。

2. HLSかDASH、それとも両方用意しなければならないのか？？
ライブストリーミングでは圧倒的にHLSが使われている。DASHを使う理由は、DRMが必須である場合かDASHのみ再生可能なデバイスをサポートする時のみ。

一般的なセグメントデュレーションは4secもしくは6sec。

最後に

セッション終了後はNetworking with Food & Beverageに。美しく美味な食事と飲み物を片手にスピーカーと楽しそうに語らう参加者の姿が多く見られた。今回3回目となったTokyo Video Tech、オーガナイザーメンバーも過去のイベントに参加いただいた方と話でき、コミュニティとしての広がりと深みを感じられるひとときとなった。

この場を借りて、まずスピーカーの3人、特にサンフランシスコから遠路東京へ来てくれたAshokさんに感謝したい。Fastly K.K.の素敵なみなさま。「どんなことが一緒にできるのか？」から始まったディスカッション、会場、Food & Beverageを提供いただき、誠にありがとうございました。