映像制作 eラーニングのことならビズバレー
文字サイズの変更 標準 
大きい
ホーム > スタッフブログ
スタッフブログ
k.takahashi
k.taguchi
j.hashimoto
j.katou
y.hotate
m.kawai
s_inomata
t.saito
ビズバレーは、東京都 千代田区で活動する、映像制作、DVD、eラーニングを扱う会社です。

エンジニア:田口

<コメント>
15年以上 eラーニング業界にさまざまな立場で関わってきました。教材開発からLMSの企画開発、コンシューマ向けeラーニングの経験を経て、多様なラーニングの企画開発を行っています。専門分野 Web技術全般、Adobe AIR、動画配信技術など。
日本イーラーニングコンソシアム認定 SCORM技術者。

<制作実例>
スマートフォンアプリ開発、LMS開発・運用、SCORM教材開発

<趣味>
一眼レフカメラ撮影

こんにちは、田口です、今回はNikon D610にWifi機能を付けて試してみようと思います。D610は、基本スペックは高いのですが、D5300やCanon EOS 6Dに付いているようなwifi機能は標準で付いていません。

個人的には、なくても構わない機能ですが、リアルタイムにスマホやiPadに画像ファイルを転送して確認できるんでは?と思いつつ、ちょっと購入して試してみました。今までは、SDカードを取り出してiPadにApple iPad Camera Connection Kitを繋げて画像を取り込んでいました。

20140119-02

ワイヤレスモバイルアダプター WU-1b

取り付けると、このような感じになります。
20140119-01

Androidから使うには、クライアントアプリをダウンロードして、wifi設定を開くと、Nikon_WUの表示がでてきます。
20140119-06

20141901-00
接続フリーになってますが、認証をかける事もできます。

さて、ここで準備が整いましたので、まずアプリを立ち上げると、写真を撮るか・見るかで選ぶことができます。撮るの方を選びます。
20140119-05

そうするとカメラのファインダー越しから見えるものが、スマホ画面に映りだします。この機能でちょっと面白いのが、スマホの画面からフォーカスを当てる箇所をタップすると、そのポイントにピントを合わせることができます。
20140119-07

そしてスマホからシャッターを切ると遠隔でカメラが動作して、スマホにサムネイル画像が転送されます。(約10~15秒)
20140119-08

スマホ内で画像をみてみる。
20140119-09

カメラ内のSDカードに入っている画像も表示することができますが、表示はサムネイルサイズと簡易的(推奨サイズ/640x480サイズ)なため画質は良くないです、きちんと取り込むには、画像を選択して取り込みボタンを押す必要があります。iPadでは、アプリケーションがiPadに最適化されておらず、iphone用のアプリをダウンロードして利用することなります。
20140119-10
iPadで表示してみる、残念・・・。

ちなみにMacからwifi接続できるかと試してみましたが、案の定できず。そして、オリジナルサイズの画像の取り込むこともできますが、リアルタイムに取り込みはできず、選択して取り込むというスタイルです。ちょいちょいwifiの接続が切れることもあり、iPadでオリジナルサイズで確認する場合、Apple iPad Camera Connectionとどちらが良いかと言えば、一枚ちょっと取り込むならwifi接続、まとめて取り込むならCamera Connectionという感じでしょうか。

 


Googleドライブは、ドキュメントの作成や管理などに利用されるオンラインストレージです。もともとは、Googleドキュメントと呼ばれ、文書、スプレッドシート、プレゼンテーションを作成するサービスでしたが、現在は、画像など、どんなファイルでもアップロードして管理することができます。

ここで意外と、知られていない?機能に、動画ファイルもアップロードできて、しかも、インターネット上に公開することができます。今回は、実際に動画をアップロードしてみて、どのような感じかを見てみましょう。

Googleドライブで、動画ファイルをアップロードすると「マイドライブ」の中にファイルが置かれます。

Googleドライブ

ここで、ファイルを選択して、「その他」のメニューから「共有」を選ぶと、自分だけでなく、インターネット上に公開することができます。

「共有するリンク」に表示される長いアドレスが、ほかの閲覧者がアクセスするときのアドレスになります。そして、そのアドレスに対して、アクセスできる共有設定を行います。

URLの取得

検索エンジンに登録されても良い場合は、「ウェブ上で一般公開」を選択して、登録されたくない場合は、「リンクを知っている全員」を指定します。閲覧者が特定されて、Googleのアカウントを持っている場合は、「限定公開」になります。自分で共有設定をしない場合は、この設定がデフォルトとなり自分のアカウントのみが閲覧できる状態になります。

20130111_2

ここでは、「ウェブ上で一般公開」の設定で検索エンジンにも登録されても良い。という設定にしました。アクセスは、閲覧者がコメントを残せるかを指定できます。

Googleドライブ上のファイルは、何人かで共同作業をするためのツールとして考えられているため、ドキュメントにコメントを付けたり、リビジョン管理で変更前の状態に戻すことができます。

公開すると、このような感じで動画を見ることができます。

Googleドライブから再生
https://docs.google.com/file/d/0B0EVjOw7_HKEOWo2T3RqNU12bEk/edit

また動画の埋め込み機能もついていて、ブログなどに埋め込むことができます。

20130111_5

実際に、YouTubeと埋め込みの動画の比較のために、サンプルを作り並べてみました。下のリンク先を見てみてください。

20130111_6 https://bizvalley.co.jp/asset/01/youtube_google_drive.html


よく似ていますが、YouTubeとの違いをざっくり挙げると

  • YouTubeへのリンクが付かない
  • 共有動画サイトに動画をアップロードしなくてよい、安心感
  • Googleドライブのディスク容量を気にする必要がある
  • 最大1GBまでの動画をアップロード公開することができる
  • 自動再生など、パラメータを付けた再生制御などカスタマイズすることはできない
  • YouTubeではアップロード拒否される、著作権的にアレな動画もアップロードできる
  • 再生ボタンなどのツールバーが常に表示される
  • ページ埋め込みにすると、自動的に画面中央に動画を表示(スクロール)しようとする
また共有の制限に関しては、下記リンクを参照してみてください。
http://support.google.com/drive/bin/answer.py?hl=ja&answer=2494827

YouTubeなど動画共有サイトを利用せず、一部の方に動画の確認してもらう方法として、オンラインストレージを利用する方法は、知っておくと良いかもしれません。また、Googleドライブだけでなく、Dropboxなどほかのオンラインストレージでも、動画公開できるものがありますので、いろいろ違いを見てみるのもいいかもしれません。

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のインストール

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

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

Server version: Apache/2.2.22 (Debian)
Server built: Feb 1 2014 21:26:04
Server's Module Magic Number: 20051115:30
Server loaded: APR 1.4.6, APR-Util 1.4.1
Compiled using: APR 1.4.6, APR-Util 1.4.1
Architecture: 64-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"

apache2-prefork-dev 、make のインストール
sudo apt-get install apache2-prefork-dev
sudo apt-get install make
Mod-Auth-Token をインストールする
wget でファイルをダウンロードして解凍します。
cd ~
wget "http://mod-auth-token.googlecode.com/files/mod_auth_token-1.0.5.tar.gz"
tar xvzf mod_auth_token-1.0.5.tar.gz
cd mod_auth_token-1.0.5/
mod_auth_token-1.0.5 フォルダの中身
.svn
AUTHORS
COPYING -> /usr/share/automake-1.10/COPYING
ChangeLog
INSTALL
LICENSE
Makefile.am
Makefile.in
NEWS
README
aclocal.m4
buildconf
config.guess -> /usr/share/automake-1.10/config.guess
config.sub -> /usr/share/automake-1.10/config.sub
configure
configure.in
install-sh -> /usr/share/automake-1.10/install-sh
ltmain.sh
missing -> /usr/share/automake-1.10/missing
リンクされている automake のバージョンが1.10と違うため、削除して張り直します。
sudo rm missing
sudo rm config.guess
sudo rm config.sub
sudo rm COPYING
sudo rm install-sh

sudo ln -s /usr/share/automake-1.11/missing missing
sudo ln -s /usr/share/automake-1.11/config.guess config.guess
sudo ln -s /usr/share/automake-1.11/config.sub config.sub
sudo ln -s /usr/share/automake-1.11/COPYING COPYING
sudo ln -s /usr/share/automake-1.11/install-sh install-sh

コンパイルしてインストールします。そしてApacheを再起動。
sudo ./configure
sudo make
sudo make install
sudo service apache2 restart
つぎに、/etc/apache2/sites-available/default ファイルの、<VirtualHost *:80> の中に、下記コードを追加します。これはURLに、video の文字が含まれ AuthTokenSecret は、要求元からの合言葉となり、AuthTokenTimeout は、試しに10秒として、URLの生成後10秒でURLが無効になります。
<Location /video/>
AuthTokenSecret "SecretString"
AuthTokenPrefix /video/
AuthTokenTimeout 10
</Location>
サーバー側の設定は、これで完了です。次にWebページ側は、今回はPHPを使い下記コードにして、bunny.mp4 にアクセスした場合の設定です。実際は、動的にファイルが指定される実装になるでしょう。IPアドレス部分 ***.***.***.*** は、適宜設定してください。
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>ワンタイムURL</title>
</head>

<body>

<?php
// Settings to generate the URI
$secret = "SecretString"; // Same as AuthTokenSecret
$protectedPath = "/video/"; // Same as AuthTokenPrefix
$hexTime = dechex(time()); // Time in Hexadecimal
$fileName = "/bunny.mp4"; // The file to access

$token = md5($secret . $fileName. $hexTime);

// We build the url
$url = $protectedPath . $token. "/" . $hexTime . $fileName;

echo "<a href='http://***.***.***.***$url'>http://***.***.***.***$url</a>"
?>

</body>
</html>

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

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

20140210-2
このアドレスは、リロードするたびにコロコロと変わり、サーバー側で設定した時間、10秒間有効です。
20140210-3
リンクをクリックするとbunny.mp4ファイルに接続され動画が再生されます。
20140210-4

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

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

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


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

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

今回は、プログレッシブダウンロードのキャッシュについて考えてみようと思います。

プログレッシブダウンロードは、1つの動画ファイルをダウンロードしながら再生を行いますが、PC内に一時的にファイルを保存する(キャッシュファイル)としてファイルを残すことがあります。配信する立場からすると、キャッシュに溜まることでサーバー側の配信負荷を下げられるメリットがありますが、一方でそこからコピーされるのではないか?という不安も残ります。

ビデオカメラでパソコンモニタ画面を直接撮影されてしまえば、そもそも防ぎようがありませんが、再生可能なオリジナル動画をコピーされること、そして第三者から容易にWeb上の動画にアクセスされることは、未然に防ぎたいところです。

そこで今回は、まずブラウザキャッシュについて調べてみます。
調べたいことは2つ。
・ ブラウザキャッシュされるファイル形式
・ キャッシュされるファイルサイズに差があるのかどうか
※ 全体のキャッシュサイズでなく、ファイル単位の上限

20140125-0
Flash Media Playback Setup のサイトで検証してみました。

まず、3種類のファイル形式(MP4、FLV、F4V)をターゲットにして検証したところ、意外なことにキャッシュされないファイル形式があり、MP4形式はSafari以外はキャッシュされず、FLV、F4V形式はファイルサイズの違いによりキャッシュされました。

○ キャッシュされる
× キャッシュされない

Windows7
ファイル形式 Internet Explorer 10 Chrome 32 Firefox 26
MP4 × × ×
F4V
FLV
OS X 10.8.5
ファイル形式 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
なかなか中途半端なサイズになりました。もしかしたらOSやブラウザのバージョンなど環境により変わってくるかもしれませんので「違いがある」という程度に留めたほうが良いかも知れません。IEは450MB程度のサイズがキャッシュされたことで制限なしと判断しました。ただしインターネット一時ファイルの指定が最大1024MBのため、完全に無制限という訳ではありません。

次回は、このことを踏まえて、キャッシュさせないように制御をしてみようと思います。

関連記事
FLV、MP4をFlash使いプログレッシブで再生するときの要点

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

-