Googleドライブは、ドキュメントの作成や管理などに利用されるオンラインストレージです。もともとは、Googleドキュメントと呼ばれ、文書、スプレッドシート、プレゼンテーションを作成するサービスでしたが、現在は、画像など、どんなファイルでもアップロードして管理することができます。
ここで意外と、知られていない?機能に、動画ファイルもアップロードできて、しかも、インターネット上に公開することができます。今回は、実際に動画をアップロードしてみて、どのような感じかを見てみましょう。
Googleドライブで、動画ファイルをアップロードすると「マイドライブ」の中にファイルが置かれます。
ここで、ファイルを選択して、「その他」のメニューから「共有」を選ぶと、自分だけでなく、インターネット上に公開することができます。
「共有するリンク」に表示される長いアドレスが、ほかの閲覧者がアクセスするときのアドレスになります。そして、そのアドレスに対して、アクセスできる共有設定を行います。
検索エンジンに登録されても良い場合は、「ウェブ上で一般公開」を選択して、登録されたくない場合は、「リンクを知っている全員」を指定します。閲覧者が特定されて、Googleのアカウントを持っている場合は、「限定公開」になります。自分で共有設定をしない場合は、この設定がデフォルトとなり自分のアカウントのみが閲覧できる状態になります。
ここでは、「ウェブ上で一般公開」の設定で検索エンジンにも登録されても良い。という設定にしました。アクセスは、閲覧者がコメントを残せるかを指定できます。
Googleドライブ上のファイルは、何人かで共同作業をするためのツールとして考えられているため、ドキュメントにコメントを付けたり、リビジョン管理で変更前の状態に戻すことができます。
公開すると、このような感じで動画を見ることができます。
https://docs.google.com/file/d/0B0EVjOw7_HKEOWo2T3RqNU12bEk/edit
また動画の埋め込み機能もついていて、ブログなどに埋め込むことができます。
実際に、YouTubeと埋め込みの動画の比較のために、サンプルを作り並べてみました。下のリンク先を見てみてください。
https://bizvalley.co.jp/asset/01/youtube_google_drive.html
よく似ていますが、YouTubeとの違いをざっくり挙げると
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のインストール
今回は、プログレッシブダウンロードのキャッシュについて考えてみようと思います。
プログレッシブダウンロードは、1つの動画ファイルをダウンロードしながら再生を行いますが、PC内に一時的にファイルを保存する(キャッシュファイル)としてファイルを残すことがあります。配信する立場からすると、キャッシュに溜まることでサーバー側の配信負荷を下げられるメリットがありますが、一方でそこからコピーされるのではないか?という不安も残ります。
ビデオカメラでパソコンモニタ画面を直接撮影されてしまえば、そもそも防ぎようがありませんが、再生可能なオリジナル動画をコピーされること、そして第三者から容易にWeb上の動画にアクセスされることは、未然に防ぎたいところです。
そこで今回は、まずブラウザキャッシュについて調べてみます。
調べたいことは2つ。
・ ブラウザキャッシュされるファイル形式
・ キャッシュされるファイルサイズに差があるのかどうか
※ 全体のキャッシュサイズでなく、ファイル単位の上限
Flash Media Playback Setup のサイトで検証してみました。
まず、3種類のファイル形式(MP4、FLV、F4V)をターゲットにして検証したところ、意外なことにキャッシュされないファイル形式があり、MP4形式はSafari以外はキャッシュされず、FLV、F4V形式はファイルサイズの違いによりキャッシュされました。
○ キャッシュされる
× キャッシュされない
ファイル形式 | Internet Explorer 10 | Chrome 32 | Firefox 26 |
MP4 | × | × | × |
F4V | ○ | ○ | ○ |
FLV | ○ | ○ | ○ |
ファイル形式 | Safari 6.1.1 | Chrome 32 | Firefox 26 |
MP4 | ○ | × | × |
F4V | ○ | ○ | ○ |
FLV | ○ | ○ | ○ |
ファイル形式 | Internet Explorer 10 | Chrome 32 | Firefox 26 | Safari 6.1.1 |
Windows7 | 制限なし | 約26M | 約43M | - |
OS X 10.8.5 | - | 約39M | 約50M | 約9M |
HTTP Live Streaming(HLS)の特徴に、アダプティブストリーミングができることを、概要で少し触ましたが、今回は、実際にアダプティブストリーミングを試してみようと思います。
まず、アダプティブストリーミングについて説明します。アダプティブという言葉は、日本語に訳すと「適応」とか「順応」という意味になります。何に適応するのかと言うと、再生端末の「通信速度」です。いまどきの映像視聴は、固定回線だけでなく、LTE、wifiなど無線回線で見ることも多くなってきました。そこで問題となるのが、通信速度が遅かったり安定しない場合、映像が途中で止まりがちになることです。
アダプティブストリーミングは、多少画質を下げてでも、なるべく再生を止めないようにする技術で、ビットレートの異なる動画を複数用意すると、通信速度に応じて、適切な動画に切り替えながら再生を行います。
また、HTTP Live Streaming のほか、同様の機能を持つストリーミング技術に、Adobe Dynamic Streaming、Microsoft Smooth Streaming があります。
アダプティブストリーミングで配信する1つ1つの動画は、特別な設定はなく単独でも再生できるHLS動画です。必要なのは、それらをまとめるファイルで、マスタインデックスファイルと呼ばれ、それぞれのプレイリストファイル(m3u8)を束ねるファイル(m3u8)になります。拡張子は同じですが、中身の記述がちょっと異なります。
マスタインデックスファイルには、それぞれのプレイリストファイルへのURL指定と、BANDWIDTHを指定します。ここでは、240k、640k、1840kの3つを指定しています。設定はこれだけです。
index.m3u8ファイルの記述例
動作確認をするには、通信速度を自由に変えられることと、通信量も確認したいので、「Entonnoir」と「Little Snitch」という接続監視アプリケーションをMacにインストールしました。
あと、動画の切り替わりが分かり易いように、
各動画にビットレート240kbps(赤色)、640kbps(黄色)、1840kbps(白色)の文字を付けておきます。
用意した動画 (c) copyright 2008, Blender Foundation / www.bigbuckbunny.org
では、実際に動作させてみましょう。
検証デモ
動画解説
(開始時)
ビットレートは、240kbpsからスタートします。ここから、データを一気に受信して10秒程度で、1840kbpsの動画に切り替わります。
(1分50秒)
ある程度まで再生を続けると、規則正しく通信・非通信状態と切り替わりながら再生していることが分かります。
(1分55秒)
ここで、回線速度を 50kbyte/sに制限をかけます。ここから、受信速度がガクンと下がり、1840kの動画で溜めておいたバッファが尽きた 2分34秒に 240kbpsの動画に切り替わります。帯域が変化しても、すぐに切り替わるわけでなく、バッファがなくなるまでは耐えて、なくなるまでに回復できれば事なきを得る感じでしょうか。
1840kから240kに切り替わる
帯域制限を解除すると、再び 1840kbpsの動画に切り替わります。
240kから1840kに切り替わる
再び、50kByte/sの制限をかけ、250kbpsの動画に切り替えます。
再び240kにする
つぎに、少し制限を緩和させ200kByte/sにすると、中間の640kbpsの動画に切り替わります。
240kから640kに切り替わる
最後に、制限を解除させて1840kbpsにして終了。
640kから1840kbpsに。
このように、アダプティブストリーミングは、通信速度に応じて動画が切り替わります。
また回線速度を640kbpsにぴったり合わせれば、640kの動画に切り替わるかと言うと、そうでもなく、ある程度のマージンが必要です。
アダプティブストリーミングは、なるべく再生を止めないというメリットがありますが、デメリットは、複数の動画を用意する必要があるため、その作業量と、動画をアップロードするサーバーのディスク容量を消耗します。その兼ね合いを、考慮したうえで利用するかどうか、決めると良いかもしれません。
次回は、HTTP Live Streaming 代替ストリームについて説明いたします。https://bizvalley.co.jp/blog/1362.html
-
前回は、HTTP Live Streamingの概要について、書きましたので今回は、実際に作ってみましょう。