我が家ではServiioは必要ないと思っていましたが、MP4(H264+AC3)のビデオファイルをDiXiM Media ServerとDiXiM TVでは再生できないことがわかり、またDiXiMソフトウェアを導入しているPCはHDD障害への対応ができていません。
この2点により、今後もWHSにServiioを導入して利用する必要があります。
そこで、これまでの試行の中でわかったことをまとめておきます。
※Serviioの利用を検討している方の参考になればと思い記載しました。
※本文中の「MediaFormat ProfileName」は、「MediaFormat Profile ID」と同じ意味で使用しています。
1.DLNA1.5準拠
ServiioはDLNA1.5準拠を謳っています。
DLNA1.5の特徴は3BOX構成(DMS+DMR+DMC)をサポートしている点です。
そのため、ServiioはDMRを発見し、そのDMRデバイスごとの個別設定を割り当てることが可能です。
※DLNA1.0の2BOX構成(DMS+DMP)の場合は、DMPを発見すると思いますが使用できるかどうかは不明です。
「TVersity」や「Windows Media Center」などとは異なりDLNA以外の共有手段がないので、使い勝手が悪いと思われるかもしれません。
HTTPによる擬似ストリーミング配信です。
ストリーミングとは、本来、ネットワークを経由してコンテンツを再生するには、「ダウンロード」⇒「再生」となりダウンロードが完了しなければ再生できませんので待ち時間が発生します。
動画ファイルになるとファイルのデータ量も増大になり、それに比例してダウンロード完了までの待ち時間も増大してしまいます。
ストリーミングは、ダウンロードが完了しなくてもその途中から再生ができますので、見たいときにすぐ見れるようになります。
ストリーミングには専用ストリーミングサーバが必要でしたが、そのかわりに通常のWebサーバを利用して配信するのが擬似ストリーミング配信(http配信)です。
ストリーミング専用サーバと比較すると機能面性能面では劣るものの、低コストですみます。
動画共有サイトのようなインターネット上の多くの人が同時にアクセスするサイトでは、同時アクセス数による負荷を考慮すると専用サーバが必要になるでしょうが、家庭内ネットワークを前提としているDLNAのストリーミングにはHTTP配信で十分です。
Serviioは、UPnP AVアーキテクチャのMedia Serverになります。
MediaServerはコンテンツの保管とストリーミングのソース(配信元)の役割があり、ConnectionManagerサービスとContentDirectoryサービスとで構成されています。
ConnectionManagerサービスはストリーミングのプロトコルとデータフォーマットを列挙と現在のコネクション状況を列挙し、ContentDirectoryサービスはコンテンツ階層の閲覧と属性検索、コンテンツのメタデータ (タイトル、作者、URLなど属性)、その他コンテンツの操作 (作成、削除、属性変更、リソース転送)を担っています。
Serviioでは、それぞれ画像コンテンツ用7種類、音楽コンテンツ用10種類、ビデオコンテンツ用71種類のMediaFormat Profileが登録されています。(※Serviio ver0.5.2時点)
ServiioのMediaFormat Profileを勝手に新規登録はできませんので、トランスコード機能を使って対応するMediaFormat Profileに変換することになります。
ただし、地デジなどデジタルTV番組を録画したコンテンツの配信に必要なDTCP-IP機能は、日本独自の規制なのでServiioはじめ日本以外で開発されたDLNAソフトウェアには通常この機能は実装されていませんので注意してください。
※日本では著作権の利用料が、著作権を扱う製品(ソフトウェアおよびハードウェア)に課せられ徴収される仕組みになっているため、DTCP-IP機能のあるフリーソフトは存在できないといえます。
2.Serviioの機能
ServiioはDLNAのDMSの役割です。
それに付随するアプリケーションが実装されています。
ServiioはApacheを使ったjavaベースのアプリケーション群で、以下の①~⑨のプログラムファイルはすべてServiio導入フォルダのlib以下にあります。
①HTTPサーバ
UPnP/UPnP AVでのデバイスの発見、コントロール機能、プレゼーション機能などHTTPリクエストを送信したりレスポンスを返すのにHTTPサーバ機能は必須です。
また、HTTPによるストリーミング配信を行うためにもHTTPサーバ機能が使われます。
サーバからはデータが1バイト8ビットで転送されますが、送られたデータが何なのかがわからなければ受信側では正しく扱えません
HTTPヘッダーのContent-TypeにMIME-TYPEを記述し、データがどのようなファイルであるかを受信側に伝えることで受信側はそのデータを受け取った後正しい処理が可能になります。
ServiioのHTTPサーバは、javaベースの軽量版のApacheが使われています。
②画像解析
画像コンテンツ情報を取得するための解析用および画像フォーマット変換用を行う機能です。
Apacheで利用できるjavaベースのSanselanが使用されています。
③テンプレート
FreeMakerというテンプレートエンジンが使用されています。
Apacheで利用できるjavaベースのアプリケーションです。
Restletプロジェクトに依存。
④キャッシュ
キャッシュからのデータの保存、キャッシュからのデータの取得、キャッシュからのデータ削除などの機能です。
Apacheで利用できるJCSといわれるjavaベースのキャッシングシステムです。
⑤XMLの永続化
JavaオブジェクトをXMLデータへ永続化するための簡単なライブラリとしてXstreamが使用されています。
⑥RSETアプリケーション
REST(REpresentational State Transfer)型の通信を行うアプリケーションを構築する「軽量な(Lightweight)」Javaフレームワークとして、Restletが使用されています。
⑦オーディオタギング
オーディオファイルのタグ情報を収集して追加するものです。
jaudiotaggerが使われています。javaベースのAudio Taging Libraryです。
⑧データベース
データベースには、公開しているコンテンツ情報やDMSサーバの設定などが保存されます。
Serviioには、組み込み向けのApache Derbyが使われています。
DerbyはjavaベースのRDBMSです。
データベースは”C:Program FilesServiiolibrarydb”になります。
テーブルは以下で構成されています。(※マークの部分は私の場合の状態です)
CONFIG | Serviioコンソールで設定したLibrary&PresentationとAdvanced Optionsの設定値が格納されています。 |
COVER_IMAGE | 公開しているビデオおよび音楽コンテンツのカバーイメージ画像です。画像データが直接保存されその画像のMIME-TYPEや画像サイズが格納されています。 MEDIA_ITEMテーブルに格納されているCOVER_IMAGE_IDで各コンテンツと紐付けされます。 |
DB_SCHEMA_VERSION | DB起動時のメンテナンス用SQLファイルが複数格納されています。ServiioService.exe起動時にスクリプトが実行されます。 |
FOLDER | 公開フォルダの情報になりますが、ID番号が登録されているだけです。 |
GENRE | コンテンツのジャンル名が格納されています。 ※ID=2がunkownです。 |
MEDIA_ITEM | 公開しているすべてのコンテンツの情報が格納されています。各コンテンツにID番号が付与され番号(MEDIA_ITEM_ID番号)で管理されます。公開フォルダをスキャン時に新しいコンテンツを発見すると”ffmpeg -i ファイル名”を実行し、その結果から情報を取得します。 |
METADATA_DESCRIPTOR | ビデオコンテンツの更新日時が記録されています。MEDIA_ITEM_ID番号で紐付けされます。 |
METADATA_EXTRACTOR_CONFIG | ビデオコンテンツのメタデータを取得するための設定が格納されます。 ※metadataの設定を”no descriptive metadata”にしているためか空です。 |
MUSIC_ALBUM | 音楽コンテンツのアルバムのタイトルとアーティスト名が格納されています。 ※音楽コンテンツを公開していないので空です。 |
PERSON | PERSON_ROLEのカテゴリで登場する人名の情報が格納されています。MEDIA_ITEM_ID番号で紐付けされます。 ※ID=2がunkownです。 |
PERSON_ROLE | コンテンツをプロデューサ、ディレクタ、俳優、ジャンルなどのカテゴリに分けて表示するための情報が格納されています。 MEDIA_ITEM_ID番号で紐付けされます。 ※metadataの設定を”no descriptive metadata”にしているためか空です。 |
RENDERER | 発見したMediaRendererの情報と使用しているデバイスプロファイル名が格納されています。 ServiioコンソールのDevice&Status画面に表示される情報そのものです。 |
REPOSITORY | ServiioコンソールのLibrary&Presention画面で公開フォルダの追加時の設定値と前回の更新スキャン実行時間が格納されています。 |
SERIES | コンテンツのシリーズ情報が格納されています。 ※metadataを取得していないためか空です。 |
Execute Queryを使用してデータベースを操作できます。
インストールおよび設定方法はこちらを参照してください。
⑨ログ記録
log4jによりロギング機能が実装されています。
log4jはApache Logging Serviceの成果物で、ログファイルのローテート機能やその他カスタマイズが可能で高機能なロギングツールです。
さらにslf4jを使用しているため、xmlファイルを編集すれば、出力するログレベルを簡単に変更できます。
通常は簡易ログレベル(INFO)になっていますが、詳細ログレベル(DEBUG)にすることで、Serviioの内部処理の詳細なログを記録できます。
このログを参照することで、パケットキャプチャーツールやUPnP Toolなどを使用せずに解析が可能になります。
プロファイルの自動識別のための記述やトランスコード時の生成されたffmpegコマンドの確認、MediaFormat ProfileNameの確認などServiioのプロファイルを編集する際に便利です。
log4jのログ自体はchainsawを使えばGUI操作でログ管理が行えるようです。
➉トランスコード
トランスコードにはマルチエンコーダ(エンコード&デコードが可能)のffmpegが使用されています。
ffmpegはソースからコンパイルする際にライブラリを追加することで多くのフォーマットやコーデックに対応させることができます。
GUI操作の動画変換ソフトのバックエンドに利用されていますが、ffmpeg自体はCUIのソフトウェアですのでコマンドのオプション指定は知識が必要になります。
Serviioでは、そのコマンドオプションの生成をprofileのトランスコード設定箇所の記述から自動生成してくれます。
ビデオコンテンツの場合にTargetFormatで指定できるのはmpeg(MPEG1/MPEG2 PS)、mpegts(MPEG2 TS)のみです。
それ以外を指定するとServiio起動時にエラーになり起動できません。なお、MP4へのトランスコードには対応していません。
ユーザが使用する可能性のあるファイルは、プロファイル(profile.xml)、ログファイル(serviio.log)とログ設定ファイル(log4j.xml)です。
3.Serviioの動作
(1)ServiioServiceの起動
①Serviio.logファイルがなければ作成
②ApplicationInstanceManager開始
③MediaServer開始
④RestletServer開始
⑤DBチェックおよびDB開始
⑥profiles.xmlを読み込み
⑦ffmpegプログラムのチェック
⑧トランスコード用のテンポラリファイルをクリーニング
⑨Webサーバの開始、キャッシュシステム起動
(2)UPnP/UPnP AVの開始
①Media ServerにUUIDを割り当て
②DiscoveryManagerにてデバイスドキュメントの取得
③さらにサービスドキュメントの取得
④デバイスをProfileに割り当て
(3)コンテンツの更新チェック
※ServiioのLibrary Optionsの設定により更新間隔が変わります。
公開しているコンテンツは「Library」と呼ばれており、公開フォルダに新しく追加されたLibraryのチェックと既存のLibraryの更新チェックが行われます。
簡単にいえば、Libraryのaddとupdateがチェックが定期的に行われるということです。
コンテンツはMediaItemのID番号で管理されている。
DBに未登録のものは、コンテンツ情報を”ffmpeg -i コンテンツファイル”を実行して取得
取得した情報をDBに登録する
MediaItem ID番号からデータベース(MetadataDescriptorテーブル)を参照し再チェック
※ffmpeg -i を実行して不明なコーデックなどでエラーになるとDBに登録されず毎回チェックされることになる
(4)フォルダ移動の操作時(DLNAクライアント側で操作)
要求があるとContentDirectoryサービスによりフォルダ内のコンテンツ一覧をDBから取得し送信する
(5)コンテンツの再生操作時(DLNAクライアント側で操作)
選択されたコンテンツのMediaItem IDからDBを参照し対象コンテンツを特定
DBを参照してファイルパスを取得し、FFmpegを実行することでトランスコードが開始される。
※トランスコードは、トランスコードマネージャによりjobが実行され管理される。
DBから取得したMime-TypeとProfile.xmlのMediaFormat P/NからコンテンツのMediaFormat profileNameが割り当てられ、PrptocolInfoが生成される。
変換したStreamデータを送信開始
(6)ServiioServiceの停止
①WEbServer停止
②DBとの接続をクローズしてDBを停止
③UPnPツールの停止
④トランスコードマネージャの停止
⑤トランスコード用テンポラリのクリーニング
⑥サービスの停止
4.Serviioのデバイスプロファイル定義
Serviioのデバイスプロファイル(profiles.xml)
(1)対応デバイス
標準デバイスの設定をのぞく12種類のデバイス用のプロファイルが用意されています。
登録済みデバイスプロファイル一覧
※この一覧にある機器がServiioで標準サポートしている機器ということになります。
※年々新製品が発売されていますので、製品の型式によってはカスタマイズが必要になります。
1 | Generic DLNA profile (※標準) |
2 | Samsung TV (B-series) |
3 | XBox 360 |
4 | Playstation 3 |
5 | Samsung TV (A-series) |
6 | DirecTV HD-DVR |
7 | Samsung TV / player (C/D-series) |
8 | LG BD player |
9 | Sony Bravia TV |
10 | Sony BD Player |
11 | – |
12 | Panasonic Viera |
13 | Toshiba Rezga |
プロファイルとデバイスの割り当ては、自動識別と手動割り当てがあります。
自動の場合は、UPnPのデバイスの発見時に行われるM-SEARCHやSOAPアクションの結果から文字列の一致によりプロファイルが割り当てられます。
手動の場合は、プルダウンリストからプロファイルを選択して割り当てます。
どちらの場合も事前にprofile.xmlに登録しておく必要があります。
※私の場合は、DiXiM Digital TV plus for IO-DATA用のプロファイルをID=14に登録し、自動識別するようにしてあります。
(2)MediaFormat Profile
Windowsは拡張子でプログラムと関連付けを行い、ファイルを実行すると拡張子に関連付けされたアプリケーションが起動します。
間違った関連付けをするとアプリケーションが正常に動作しません。(※間違った関連付けとは、アプリケーションが対応していない拡張子を意味します。)
それと似ており、HTTPサーバを使用したストリーミング配信では、1バイト8ビットのデータが送られそのデータが何であるかを伝えるためにMime-Typeが使われ、HTTPヘッダーのContent-Typeに記述しています。(※これが通常のインターネットを経由したHTTPストリーミング配信です)
さらにDLNAでは、MediaFormat ProfileNameにてサーバとクライアント間で互換性のあるコンテンツを選択します。
DMSのContentManagerから送られてきた情報の中のMediaFormat ProfileNameから判断してDLNAクライアントは、画面の一覧に表示するのかを決定します。
Serviioが対応しているMediaFormat ProfileNameはprofiles.xmlのID=1に定義され、さらにMIME-TYPEとMediaFormat ProfileNameが関連付けされています。
MIME-TYPEは、【mime media type name】/【mime subtype】で表記されますが、標準化されているMIME-TYPEはこちらを参照してください。
「x-」から始まるものはまだ標準化されていない仮のものです。
※MIME-TYPEで使われる標準の拡張子については文書内に記載があります。
DLNAがサポートしているMediaClassはimage(画像)・audio(音楽)・video(ビデオ)の3種類が標準ですので、mime media type nameもimage、audio、videoになります。
またmime subtypeに記述する文字列でファイルの拡張子と関連付けられる場合もあれば、HTTPサーバの設定ファイルに拡張子とMIME-TYPEの関連付けを明示してある場合もありますし、UNIXのfileコマンドのようなプログラムでファイルの中身を調査してMIME-TYPEを取得することもできます。
Serviioは公開しているコンテンツファイルを発見したときに”ffmpeg -i ファイル名” コマンドを実行して、データベースに取得した情報を格納していますが、MIME-TYPEに相当するContent-Typeは「UNKOWN」になっています。
トランスコード機能をEnableにしている場合は、ストリーミング配信直前にMediaFormat ProfileNameが決定されます。
Serviioでは、このMIME-TYPEとMediaFormat ProfileNameの関連付けを変更することは可能ですが、新たにMediaFormat ProfileNameを追加することはできません。
(3)トランスコード
①再生要求を受信し、トランスコードが有効の場合に実行
②profile.xmlの記述にあわせてトランスコードコマンド生成(トランスコード時)
③jobに登録され変換処理を開始
③MediaFormat Profileへの関連付け
④逐次ストリーミング配信により送信
まだまだ内部処理についてはわからない部分や正確でない部分もありますが、こんな感じ動作していると思われます。
[common_content id=”13602″]