フル HD 環境のビデオオンデマンドデータの作成と配信澤昌孝, 水谷文保自然科学研究機構分子科学研究所技術課 1. 概要昨今家庭用フル HD ビデオカメラが普及しており講義や講演を HDTV 級の高画質で保存することが容易になっている今回はフル HD ビデオカメラ出力を H.264 リアル

(1)

熊本大学学術リポジトリ

Kumamoto University Repository System

Title

フルHD環境のビデオオンデマンドデータの作成と配信

Author(s)

澤, 昌孝; 水谷, 文保

Citation

Issue date

2011-03-18

Type

Presentation

URL

http://hdl.handle.net/2298/23572

Right

(2)

フル

HD 環境のビデオオンデマンドデータの作成と配信

○澤昌孝，水谷文保自然科学研究機構分子科学研究所技術課 1. 概要 昨今、家庭用フルHD ビデオカメラが普及しており、講義や講演を HDTV 級の高画質で保存することが容易になっている。今回はフルHD ビデオカメラ出力を H.264 リアルタイムエンコーダに処理させて、視聴に問題ないエンコード設定について試行した。長時間の講義をオンデマンド授業用にリアルタイムエンコードした際の状況と、実際に配信した際に起きた問題などについても報告する。 2. 背景 昨年度、総合研究大学院大学（以下、総研大）のセミナー配信用システムとして、大学院講義の行われるセミナー室などにWeb カメラ・エンコーダが設置され、それらのエンコードされたデータを配信するサーバ類が導入された（図 1）。図 1：セミナー配信システム概要図

ただ、設置されたWeb カメラ（Panasonic DG-NS202A）はパワーポイントなど投影されているプロジェクター部分を主に撮っており、教員の姿はあまり見えない状態になっている（図2）。

(3)

図 2：Web カメラからの映像図（WMV9,解像度 640×480,フレームレート 29.97,ビットレート 663kbps,倍率 100％）また、Web カメラ自体が主に監視カメラ用であるため、それほど画質はよろしくない。そういったこともあり、高画質データ用に別途フルHD ビデオカメラも導入された。このフル HD ビデオカメラを使用して、分子研で 11 月に行われた総研大学の集中講義（3 日間）の撮影を行った。 3. 撮影方式とシステム構成 今回 HDTV 級の動画を保存するにあたって、高画質ながら動画ファイルサイズが小さくできる H.264 エンコード (MPEG4(以下 MP4)）形式を使用した。ただ、ある程度品質が高い MP4 ファイルをシングルコア CPU の古い端末で再生すると、負荷が大きいため画像がもたつくなどの問題があったが、集中授業の動画を見る総研大生にはセミナー視聴用に最近のマルチコアCPU のノート PC が配布されているためその点で問題はないものとした。次にカメラからの外部出力を取り込みについて、使用したカメラにはHDMI、D 端子及び RCA が付属されているが、劣化のないデジタルでの取り込みが好ましいので自ずとHDMI の選択となった。ただ、一般的な HD 対応の HDMI キャプチャは PCI-Express のものがほとんどである。こちらの要望としてはカメラと一緒に持ち運びができるノートPC での処理を想定していたので、ノートPC に接続できる ExpressCard もしくは USB 等での HDMI キャプチャを探したところ、USB 接続で HDMI 入力ができる _{H.264 リアルタイムエンコーダ（以下 HD264）を見つけたので採用した。以下が撮影システムの構成と} なる。

HD ビデオカメラ：Sony HDR-AX2000

リアルタイムエンコーダ：SKNET Monster HD264（USB バスパワー）

(4)

4. エンコード設定の試行

実際、集中授業を撮影及びエンコードするにあたり、H.264 エンコードを行ったことがなかったので、視聴に問題がない設定をするため事前にテストを行った。関係する主な設定項目は以下のとおり。

HD ビデオカメラ

・外部出力：1080i/480i（以下 1080i とする）、720p/480i（以下 720p とする）、480p、480i HD264

・出力解像度：最大1920×1080p ・フレームレート：最大30fps ・ビットレート：最大20Mbps ・レベル：1～5.1

・ピクチャーコーディング：Progressive Flame、Interlaced Field など

なお、今回の目的はHDTV 品質の保存であるため、カメラ出力は 720p/480i 以上、HD264 側の出力解像度は 1280×720 以上の設定とした。また、動きに影響するフレームレートについては最大設定の30fps で固定にした。これまでの設定でレベルの設定も4 以上に自ずと決まった（1920×1080@30fps での推奨レベル 4 以上であるため[1]_{。始めのテストは、} テレビの放送時間外に映されているモノスコープパターン(図 3)をプリントしたものを 1 分間撮影し、比較を行った（図 4、図 5）。

(5)

図4：1080i,1920×1280,30fps,1Mbps,level5.1,倍率 50%

図5：1080i,1920×1280,30fps,20Mbps,level5.1,倍率 50%

ビットレートを1Mbps～20Mbps の間を適当に変更させて見てみたもの、撮影対象が静物のみ（静止画）なので、低めのビットレートにしても視聴に影響が出る程度の違い（可視できる解像度の線など）が発生しないことに気が付いたので、横にゆっくり回転する風車を置いて再度テストを行った（図6、図 7）

(6)

図6：1080i,1920×1280,30fps,1Mbps,level5.1,倍率 50% 図7：1080i,1920×1280,30fps,10Mbps,level5.1,倍率 50% カメラ出力1080i・出力解像度 1920×1080 の場合、10Mbps より低いビットレートで回転している風車付近を中心にブロックノイズが発生することが観測できた。ブロックノイズの大きさは低ビットレートであるほど大きくなり、動いていない背景の部分にもノイズの影響が発生した。青い壁紙の目の部分等にその影響が顕著に出た。なお、レベルによる画質の差はあまり感じることはなかった。次にカメラ出力720p・出力解像度 1280×720 の設定でテストを行った。5Mbps より低いビットレートでブロックノイズが発生することが観測でき、1080i で同一のビットレートでものと比較した場合、 Progressive の 720p の方はノイズが出にくい・小さいという結果となった（図 8、図 9）。

(7)

図8：1080i,1920×1280,30fps,1Mbps,level5.1,倍率 50% 図9：720p1280×720,30fps,1Mbps,level5.1,倍率 75% 以上の結果から、視聴環境を重視することにしていたので、本番でのカメラ出力は720p の設定で行うことにした。なお、以下に一分間撮影した際の各設定（出力解像度・レベル・ビットレートの値を変化。フレームレートのみ30fps 固定）での出力MP4 ファイルのおおよそのサイズの結果をまとめた（5 回ぐらいの撮影データの平均）。 1920x1080i 1280x720p level4 level5.1 level4 level5.1 1Mbps 9MB 9MB 9MB 8MB 2Mbps 17MB 17MB 16MB 16MB 5Mbps 37MB 39MB 36MB 39MB 10Mbps 73MB 77MB 70MB 75MB 15Mbps 106MB 112MB 105MB 114MB 20Mbps 126MB 145MB 127MB 150MB

(8)

上の表の黄色の部分の_{MP4 ファイルの映像では、ブロックノイズが観測されたものである。1920×1080i から 1280×720p} による違いは解像度がおよそ半分になった分、走査方式の分で倍になっているため、データ量がほぼ同じとなり出力されるMP4 ファイルのサイズにあまり差は出ない。レベルの違いによる MP4 ファイルサイズの差は、ビットレートが 10Mbps ぐらいから明確になり、20Mbps では顕著に差が出た。ビットレートの増加によるファイルサイズの増加が正比例しているものとすると、20Mbps のファイルサイズとしてはレベル 5.1 での方が理想的な値となっている。これはレベル 4 での最大映像ビットレートは規格上20000kbps であるが、HD264 での処理では 17～18Mbps ぐらいで頭打ちになったものと推測される。なお、同一ビットレートでレベル4 とレベル 5.1 と比較して見易さの点で差を特に感じることはできなかった (図 10、図 11)。図10：720p1280×720,30fps,20Mbps,level4,倍率 75% 図11：720p1280×720,30fps,20Mbps,level5.1,倍率 75%

(9)

5. 集中講義の撮影 集中講義でのカメラ及びHD264 の設定は、できたデータを後々、編集することを想定してソース用に一番良い設定（HD ビデオカメラ-外部出力：720p/480i（HD）、HD264-出力解像度：1280×720、フレームレート：30fps、ビットレート：20Mbps、レベル：5.1、ピクチャーコーディング：Progressive Flame）で行った。なお、この設定で 1 分撮影した場合 150MB ぐらいのエンコードデータ（MP4 ファイル）、1 時間で 9GB ぐらいのデータが作成されることが事前のテストにて予想できていた。集中講義は3 日間、おおよそ 8 時間×3 日の 24 時間程度（1～2 時間の講座が 14 コマ）が予定されており、合計の映像データが 200GB を超えることが予想されていたので、内臓の SSD では不足する可能性があったので、予め大容量（1.5TB）の USB-HDD を接続してエンコードされたデータはそこに保存することにした。講義中の様子を以下に示す（図 12）。図 12：HD カメラの映像をエンコードした講義動画図（720p,1280×720,30fps,20Mbps,level5.1,倍率 50%）図2 の Web カメラのものと比較して、講義中の教員の様子見えることはさることながら、プロジェクターで投影されているパワーポイント中の計算式なども見やすいものになっている（図13、14）。図 13：Web カメラでの画像（WMV9,解像度 640×480,フレームレート 29.97fps,ビットレート 663kbps,倍率 100％）

(10)

図 14：HD カメラの映像をエンコードした講義動画図（H.264,720p,1280×720,30fps,20Mbps,level5.1,倍率 100%）講義の撮影は1～2 コマで交代しながら行い、特に問題なく進んでいたが、一日目の終わり頃（2010/11/24 17：00 頃）の講義中に中電の送電線事故による瞬時電圧低下が起きた。幸い今回の撮影及びエンコードシステムはUSB-HDD 以外は内臓電池で稼動できるものであったため、システムが停止することはなかった。 6. エンコードデータの配信と再処理 エンコードされたデータ（MP4 ファイル）は、とりあえず図 1 の資料配信サーバにアップロードして閲覧できる状態にした。しかし、1 コマの講義時間が 2 時間ぐらいであったのものは 20GB 程度の MP4 ファイルになった。所内ネットワーク及びNIC（有線）などの環境は AllGigaEther であるため、MP4 ファイルのダウンロード完了まで我慢できないぐらい待たされることはないものと考える（理論上の最適値（1Gbps）で 20GB のダウンロードは 160 秒）。ただ、ユーザフレンドリーではないことは確かなので、Youtube のように H.246 エンコードされた動画がダウンロードしながら視聴できる方法を探したところ、MP4 などの動画ファイルにヒントトラックを追加してストリーム用に再処理にすればよいことが判明したので試した。MP4 ファイルにヒントトラックを追加するには MP4Box[2]_や _mp4UI[3]_{にて可能とあったので、} mp4UI にて 1 分間撮影した小さめの MP4（約 150MB）を再処理してみたところ、ヒントトラック分若干サイズが増えた MP4 が問題なく作成された。ヒントトラック付きの MP4 ファイルを Web サーバにアップロードした後、JW player[5]_を利用してMP4 ファイルを Youtube のように Web ブラウザ上で動作させるようにした。実際にストリーム再生できた様子を図15 に示す。また、ipad 上でもストリーム再生ができたとユーザより伺っている。図 15：FireFox 上のストリーム再生

(11)

実際の講義の_{MP4 ファイル（10～20GB）にて試したところ、ファイルを開く（解析する）時点でエラー終了となった。} MP4Box でも 10G 級の MP4 ファイルにヒントトラックの追加を試みても、サイズ 0 の MP4 ファイルができるのみプログラムが完了しない。MP4 ファイルをソース用にと無駄に品質を良くした（ファイルサイズを大きい）のが仇となった。サイズの大きいMP4 ファイルを再エンコード（品質下げる）してファイルを ffmpeg[4]_{にてある程度小さくしてからヒン} トトラックを付けてみることにした。ファイルサイズ：11.2GB（元の MP4 ファイル）→2.77GB（再エンコード後）ビデオビットレート：20Mbps→5Mbps オーディオビットレート：128kbps→44kbps この再エンコードしたMP4 ファイルにヒントトラックの追加を試みたところ、mp4UI では以前と同様ファイルを開く時点でエラーとなったが、MP4Box では追加することはできた。しかし、このヒントトラックを追加した MP4 ファイルをブラウザ上で再生すると通常のMP4 と同じ様に全てダウンロードしてからでないと再生しない状態になり、ヒントトラックが上手く機能しなかった（ローカルでのメディアプレイヤーなどの再生には問題なし）。原因を探っていたところ、 Win32 では一プロセス当たりの仮想メモリが 2GB までという記事をいくつか見つかった。MP4Box の 64bit 版があるのでは探したところあったので、64bit 版 MP4Box で 2.77G の MP4 ファイルのヒントトラック追加を試みたが、MP4 ファイルを開く段階で「out of memory」と返され処理できなかった。また、2.77GB の MP4 ファイルにヒントトラックの追加できたMP4Box は若干リビジョンが古いもの（GPAC Version 0.46-DEV (build1 – Jun 29 2009)を使用していたので最新リビジョン（GPAC Version 0.46-DEV (internal rev.8）Dec 14 2010)を使用したところ、同様に「out of memory」となった。以上のことから2GB 以上のファイルのヒントトラック追加処理には問題ありと判断したので、2GB 未満のサイズになるよう以下のように再度エンコードした。ファイルサイズ：11.2GB（元の MP4 ファイル）→1.67GB（再エンコード後）ビデオビットレート：20Mbps→3Mbps オーディオビットレート：128kbps→44kbps この2GB 未満の MP4 ファイルでは、mp4UI でも MP4Box でもヒントトラックの追加処理は問題なくできた。このヒントトラック付きMP4 ファイルをブラウザ上で再生させたところ、問題なくストリーム再生することが確認できた。 7. 最後に 映像を高品質（HD）に撮影及びエンコードする分には特に問題はないが、ヒントトラック追加などの再処理や、動画を容易にユーザに閲覧できる（ストリーム）には品質をある程度落とす必要があるなど、主にファイルサイズ的に後々のことで問題があることが分かった。今回、再処理で使用したソフトは基本フリーソフトのみで行ったので、有償ソフトを使うことで解決できることが期待できる。調査してお手ごろな価格で利用できそうなら今後試してみたいと考える。また、 Google が高品質 Web 向けビデオフォーマットとして WebM[6]_{を開発しており、今後}_{Google ブラウザの Chrome の HTML5} 用ではH.264 の替わりにするといった新しい規格の普及する兆しが出てきた。H.264 と比較した記事を見ると、エンコード時間がかかるなど、まだまだこれからの規格らしいがWebM での HD 映像のエンコードもいずれ試してみたい。 HD 級の映像のリアルタイム配信が、ストリーミングサーバ（図 1）などに追加設定することで可能な様なので、現在環境を整えて準備・試行中である。今後ある程度結果がまとまったらご報告したいと考える。参考文献 [1] 総務省情報通信審議会情報通信技術分科会（第４２回）情報源符号化部『H.264 | MPEG-4 AVC 規格の概要』配布資料 2 「8.2 レベル」（P.20） http://www.soumu.go.jp/joho_tsusin/policyreports/joho_tsusin/bunkakai/pdf/060720_3_1-2_sa2.pdf

(12)

[3] mp4UI - MP4 file tool http://mp4ui.sourceforge.net/

[4] FFMpeg http://www.ffmpeg.org/

[5] LongTail Video | Home of the JW Player http://www.longtailvideo.com/