Streaming Tuning Test

Makoto Uehara

Client App

RTMP Broadcast Library(Lib)Live Media Player(Mobile App)Flash Media Encoder(PC App)

Media Servers

Zencoder Live API(britcove)Flash Media Server(Adobe)

Wowza Media Server(wowza)

Defference in Media Server

Zencoder

FlashMediaServer,wowza

is SaaS

is App

Full Managed

Need Implement

CDN

AkamaiCloud Front

Limelight

Trade-Off

Delay < === > Stability

Trade-Off

Delay < === > Stability

Important

Trade-Off

Delay

Cache,BufferSmall

Cache,Buffer

Big

Delay

CostCost

Stability

GoodBad

Stability

Delay

PC2Mobile: 15～20s

Mobile2Mobile: 35～40s

Streaming System

１ 2 3 4 5 6

１ 2 3

１

EncoderRTMP

HLS

CDN

manifest file：hoge.m3u8123:

READ

Streaming System

１ 2 3 4 5 6

１ 2 3

１

EncoderRTMP

HLS

CDN READ

manifest file：hoge.m3u8123:

Tuning point

Tuning of Encoder

Cache control： 4s

Segment seconds： 10s

cache control

Example Pamameter： 4sCDN側に受け渡す際のリクエストパラメータに含まれる

CDN側でのキャッシュ時間となるが、パラメータが効くか効かないかはCDN側次第となる。

マニフェストファイルの更新タイミングはsegment secondsだが、CDN側のキャッシュの影響も受ける為、

CDN側のキャッシュ時間が長かればユーザー側として遅延を感じるが安定性は一般的なキャッシュのメリットと同様。キャッシュ時間が短ければ遅延を感じないがキャッシュが効かない分安定した配信になりずらい。

segment seconds

Example Pamameter： 10s動画をチャンクする単位。小さい方が遅延しない

小さい場合、マニフェストファイル(例えばHLSだとhoge.m3u8)が同じファイル名で更新が高頻度に行われる。なので安定し

ない可能性もあるが大きな問題とは思えない。

再生時、モバイル側でhttpリクエスト数が増えるのでそれは負荷となりうる。

Tuning of SDK

buffer

prefetch

Buffer

Buffer

録画する時：スマホ内でのローカルだからさほどバッファは必要ないかも

RTMPで出す時：ネットワーク越しなので通信状況がいい時に大量に送りたい。

Prefetch

prefetchセグメントの先読み

1を再生中に2をダウンロード帯域の話。1を再生中に複数のsegment取りにいっても2をダウンロードしおわらない

と再生がはじまらない

ユーザー特性として、動画を見始めて離脱するユーザーが多いならなるべく離脱しないようにsegmentの大きさとprefetchの数は小さめがいいかも

だいたい1再生中に2を取りにいくくらいでいんじゃないか

Tuning of CDN

TTL

TTL

value that is set by the cache control