こんにちは、田口です、今回からvideo-js の機能をいろいろ見てみようと思います。前回はデモを動かしてみましたが、それだけでもさまざまなボタンや機能があったと思います。

まずは、ということでクローズドキャプションとサブタイトルについて見てみましょう。この機能は、動画内の設定したシーク位置に字幕を表示することができます。デモでは２種類の色違いの文字が表示されていたと思います。これが、クローズドキャプションとサブタイトルになります。



ざっくり違いを書いてみると

クローズドキャプション
聴覚障害を持つ方にも考慮された字幕

サブタイトル
映画などの字幕（英語→日本語）や音声の内容を文字にしたもの

私の理解では、話し手のことばの言語を、そのまま文字にして起こしたもの、そのなかで状態の伝達に必要な（効果）音の文字表現は、クローズドキャプションに相当して、海外の映画などの日本語字幕は、サブタイトルに相当すると思います。例えば、ガラスが割れる音「ガシャーン！」という音の表現は、クローズドキャプションでは入り、一方、サブタイトルでは入らないケースもあるのかもしれません。

調べてみたら意外と難しかったというオチですが、ではテロップはどちらに入れるの？といえば、サブタイトルになると思います。また、動画教材で音声を切った状態で、学習できるように文字を起こす場合、その文字をクローズドキャプションに設定するといった使い方もできるでしょう。

※ ちなみに、デモの動画では、そこまで深く区別されておらず、クローズドキャプションとサブタイトルの内容は同じものです。

Webサーバーの Apache にワンタイムURLを設定して、動画へのアクセスを制限してみようと思います。

ワンタイムURLには、イベントベースのものと時間ベースのものがあるようです。イベントベースは、アクセス回数で制限を加え、時間ベースは、アドレスの生成から何秒間 そのURLが有効というもので、有効時間を過ぎると、そのURLでアクセスすることはできなくなります。

今回のものは、時間ベースのもので、mod_auth_token を利用します。通常、Apache にはインストールされていないため、ソースコードからコンパイルします。今回も、OSは、Debian Linux で話を進めます。

mod-auth-token のサイト
https://code.google.com/p/mod-auth-token/

下準備
Mod-Auth-Tokenは、automake、apxs を必要とするため動作するよう準備します、あとコンパイルに make を使うのでそれも入れておきます。

automakeのインストール

/usr/bin/ に automake-1.11 がインストールされます。

apxsが、入っているパッケージ apache2-prefork-dev をインストールします。今回、動作させている Apache のマルチプロセッシングモジュール（MPM）は、Prefork のため、apache2-dev では動きませんので注意してください。Prefork や Worker といったものは、apache2 -V で調べることができます。


apache2-prefork-dev 、make のインストール

Mod-Auth-Token をインストールする
wget でファイルをダウンロードして解凍します。

mod_auth_token-1.0.5 フォルダの中身

リンクされている automake のバージョンが1.10と違うため、削除して張り直します。

コンパイルしてインストールします。そしてApacheを再起動。

つぎに、/etc/apache2/sites-available/default ファイルの、<VirtualHost *:80> の中に、下記コードを追加します。これはURLに、video の文字が含まれ AuthTokenSecret は、要求元からの合言葉となり、AuthTokenTimeout は、試しに10秒として、URLの生成後10秒でURLが無効になります。

サーバー側の設定は、これで完了です。次にWebページ側は、今回はPHPを使い下記コードにして、bunny.mp4 にアクセスした場合の設定です。実際は、動的にファイルが指定される実装になるでしょう。IPアドレス部分 ***.***.***.*** は、適宜設定してください。

ファイル名はonetime.php としてFTP上 videoフォルダの上に配置します。videoフォルダの中には、bunny.mp4を入れておきます。



では、すべて準備が整ったのでブラウザでアクセスしてみましょう。そうすると、自動生成されたリアドレスが表示されます。



このアドレスは、リロードするたびにコロコロと変わり、サーバー側で設定した時間、10秒間有効です。


リンクをクリックするとbunny.mp4ファイルに接続され動画が再生されます。


10秒経過後、リロードを掛けるとこのように410エラーとなり接続できなくなります。


試しに、直接 bunny.mp4にアクセスしてみると、認証エラーとなり接続することはできません。


動画で確認してみましょう。


このようにして、動画にアクセス有効時間を設定することで第三者からのアクセスをしずらくすることができます。ウィークポイントを言えば、動画再生の権限を持ち再生したとき、そのユーザーに対して有効時間内はその動画へのアドレスはノーガードとなるため、URLを突き止められるとダウンロードされる可能性は捨て切れません。そのあたりは工夫や、妥協が必要になるかもしれません。

（参考）
動画配信 CDNでワンタイムURLを設定してみよう
https://bizvalley.co.jp/blog/4470.html

今回は、今まであまり見かけなかったレンジリクエストによる動画再生の仕組みについて見てみようと思います。

通常 Webサーバーに、動画ファイルを置いてFlashなどで再生する場合、プログレッシブダウンロード形式になります。頭から動画データをダウンロードしながら再生するもので、まだダウンロードされていない位置にシーク移動することはできません。ダウンロードされるまで待つ必要があります。

Flashを利用した、典型的なプログレッシブダウンロード

しかしながら、HTML5 Videoで再生するときなど、典型的なプログレッシブダウンロードのはずが、ダウンロードされていない位置に、シーク移動できて、何事もなく再生ができるものがあります。これはなぜでしょうか。

実は、プレイヤー側がサーバーに対して、レンジリクエスト（範囲リクエスト）を要求しています。これは、動画ファイルに対して、開始あたまから動画データを受信要求せず、途中からの動画データを要求しています。そのため、シークした位置からキャッシュが溜まっていくように見えます。

Google ChromeでMP4を再生

レンジリクエストの身近な例では、ブラウザでファイルをダウンロードするとき、「一時停止」「再開」ボタンが付いているものがあります、「途中からデータを取得する」という意味では、同じようなもので、Apacheなどは、デフォルトの設定でレンジリクエストが動作します。

ここでは、動画再生で、本当にレンジリクエストを行っているのかを確認してみようと思います。

サーバーは、レンジリクエストに対するレスポンスは、「206 Partial Content」のステータスコードを返します。206 を返しているか、「Charles（チャールズ）」というソフトを利用して確認しました。 ※ Charles は、インターネットとクライアント間のトラフィックを表示できるリバースプロクシのソフトウェアです。



ブラウザ Chromeを使い、MP4ファイルにアクセスして、再生位置を変えてみます。
そうすると、サーバーが 206 Partial Content を返していることがわかります。



もうひとつ今度は、サーバーに対して、（開始）何バイト～（終了）何バイトのリクエストをしているか確認してみると。Range 範囲にて、バイトの範囲指定をしていることが分かります。



このように、ちょっと謎だった動画再生の仕組みが、見えてきたと思います。

今回のポイントは、
動画ファイルには、特別な設定や加工はしていません。１つの動画ファイルとしてエンコードしただけで、プレイヤー側の機能と、サーバー側の応答で、実現したものになります。

つまるところ、利用したFlashの再生プレイヤーは、対応していなかったということで。またVLC Playerでも動作しますので HTML5 Videoのプレイヤーだけが動作する、ということではありません。プレイヤー側の対応次第でレンジリクエストによる再生は、できるということになるでしょう。