YouTubeの再生時間と等比数列

投稿者: | 2017年10月27日

途中で止まる動画

YouTube の動画を再生している時、
途中で再生が止まることありますよね。
クイズの答えがまさに発表されようとしているタイミングで止まると、
早く続きが見たくてうずうずしてしまいます。

動画が止まってから、しばらく待っていると、
また動き出すこともありますが、
少し進んだところで、また止まってしまい、
とても見られたものではなくなってしまうこともあります。

今回は、そんな再生中の動画が止まるという現象についてのお話です。

動画はなぜ止まるのか

そもそも、何で動画は止まってしまうのでしょうか。
この答えは単純で、動画の続きをまだ受け取っていないからです。
物理的な実体がある郵便を考えるとわかりやすいでしょう。
まだ、手元に受け取っていない手紙を読むことはできないのです。

では、何で動画の続きを受け取っていないのでしょうか。
それは、通信速度が遅く、動画の受け取りが遅れているからです。
道路が渋滞していると、手紙の到着が遅れてしまいます。

動画再生は追いかけっこ

インターネットでは、通信速度は頻繁に変化します。
例えば、トンネルに電波が遮られてしまったとか、
アクセスが集中して、他の人と通信資源を取り合うことで、
通信速度が遅くなってしまうことがあります。

もし、通信速度が変わるたびに動画が止まるのなら、
誰も動画を見なくなってしまうかもしれません。

でも実際は、そんなに頻繁に動画が止まることはありません。
トンネルに入っても、すぐにトンネルを抜けるのであれば、
動画は途切れずに再生されるという経験があると思います。

実は、通信速度が変わっても動画を再生し続けるための仕組みが用意されているのです。
それは、動画再生中に、先読みで動画の続きを読み込むというものです。
このような仕組みを バッファリング と言い、
先読みした動画を蓄えておく場所を バッファ と言います。

つまり、通信速度が速い時に、バッファにある程度先の動画を読み込んでおいて、
通信速度が遅くなった時には、バッファの中の動画を再生するのです。

YouTube 等の動画プレイヤーではよく下の図のようなシークバーが用意されています。
シークバーをよく見ると、今の再生位置と、先読みの位置が表示されていることが分かります。
その間の時間は、まだ再生されていないが、
すでに手元に届いていてバッファに置いている動画を表しています。
動画を再生していると、再生位置と先読みがそれぞれのタイミングで進んでおり、
追いかけっこしているように見えると思います。
この追いかけっこで再生位置が先読みの位置に追いつくと、
手元の動画を再生し切ってしまうので、動画が止まってしまいます。

再生が止まる時間は等比数列の和

さて、今バッファには 30 秒先の動画まで読み込みが終わっています。
ところが、トンネルに入ってしまい通信速度が大きく低下してしまいました。
この動画の再生はいつ止まるでしょうか?
バッファに 30 秒分の動画があるから 30 秒で止まるのでしょうか?

通信速度がゼロになり、全く続きを読み込まなければ 30 秒で止まります。
ところが、通信速度は遅くなっても、少しでも読み込むのであれば、
バッファから 30 秒再生している間にも、先読みはいくらか進んでいるので、
その分だけ、さらに再生できます。

通信速度(スループット\(T\) を 1 秒当たりに通信可能なデータ量として、
動画再生レート \(r\) を 1 秒当たりに再生する動画のデータ量とします。
すると、\(\frac{T}{r}\) は 1 秒当たりの通信されるデータを、
動画の何秒分に当たるかを換算した値です。
言い換えると、\(\frac{T}{r}\) は 1 秒間で読み込む動画の再生時間の長さを表します。

これで、バッファ内の 30 秒の動画を再生している間に読み込む動画の長さは、
\(30 \times \frac{T}{r}\) で求まることが分かります。

では、動画が止まる時間は、
最初にバッファにあった 30 秒分と、それを再生している間に読み込む分を足して、
\(30 + 30 \times \frac{T}{r}\) 秒でしょうか。
いいえ、30 秒再生した時と同じように、\(30 \times \frac{T}{r}\) 秒再生している間にも、
いくらか動画を読み込んでいるはずです。

このように考えると、最初のバッファにあった 30秒分を再生している間に
\(30 \times \frac{T}{r}\) 秒読み込み、
さらにその間に、
\(30 \times \frac{T}{r}\times \frac{T}{r}\) 秒読み込み、
さらにその間にと無限に続くことが分かります。

これはまさに等比数列になっていて、並べると、
\(30, 30 \times \frac{T}{r}, 30 \times (\frac{T}{r})^2, …\) です。

動画が止まるまでの時間は、
これらのバッファに読み込んだ動画を全て続けて再生した時の合計の時間なので、
等比数列の和が動画が止まるまでの時間です。

これは、等比数列の和の公式から、 \[ \frac{30}{1-\frac{T}{r}} \tag{1}\] と分かります。 ただし、通信速度は動画再生レートよりも小さい \(T<r\) としています。

シミュレーションで確かめてみよう

では、計算の通り再生停止時間が求まるのか、
簡単なシミュレーションで確かめてみます。

シミュレーションでは、MPEG-DASH の動きを真似ていて、
動画は、一定時間単位に区切られた セグメント 単位でダウンロードします。 (参考記事:dash.js で CORS に苦戦するの巻)

セグメントのダウンロードが完了した時点で、バッファの残量が増えるので、
バッファの残量はギザギザに変化します。
YouTube のシークバーをじっくり眺めてみると先読みの位置が急に進んだり、
止まったりしていることが分かりますが、そんな感じです。

シミュレーターのソースコードは長いので、記事の一番最後に乗せることとして、
先にシミュレーションを実行してしまいましょう。

シミュレーションでは、動画再生レートを 100 に固定して、
スループットを 200 から 30 に途中で変化させています。
グラフでは、再生時間(play_time)、バッファに読み込まれた動画の長さ(buffer)、
動画再生レート(bitrate)、スループット(throughput) をそれぞれ表示しています。

スループットが低下する前はバッファ内にはほぼ満タンの 30 秒分の動画が読み込まれていましたが、
時刻100 でスループットが低下すると、バッファ内の動画の長さが減少していることが分かります。

そして、ついにバッファ内の動画の長さがゼロになると、動画の再生が止まってしまい、
再生時刻が 140 当たりで一時停止していることが分かります。

グラフ内の縦の破線では、上の式(1) で計算された動画が止まる時間を表していて、
実際に、シミュレーションで動画が止まった時刻とよく一致していることが分かります。
このように、等比数列の和の計算で正しく動画が止まる時間を計算できることが確かめられました。

動画が止まった後は、再生を行わずに、動画の読み込みだけを行うので、
徐々にバッファが増加して、再生が再開され、バッファがなくなるとまた停止を繰り返しています。

まとめ

等比数列の説明をするときに、
アキレスと亀の追いかけっこを題材とするのはよく見かけます。
今回は、YouTube のようなストリーミング再生も追いかけっこの構造を持っていて、
同じように等比数列と関係があることを見てきました。

等比数列を学ぶような学生は、YouTube を普段から利用しているだけあって、
より身近で取っ付き安い例だと思います。
何より、アキレスに亀が追いついたところでそれがどうしたのという気がしますが、
動画の例の場合だと、再生が止まってしまうという問題意識を持てるので、
より、学習意欲をもたらすことができそうです。

動画プレイヤーのシミュレーター

最後に今回使った動画プレイヤーのシミュレーターのソースコードを載せておきます。


 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です