2012年6月23日土曜日

[日常][PC]DLNAアプリを作りたい・・・んだけど・・・

発端は会社での友人との会話。
「中華タブ買って、HDMI出力をアンプに入れて、タブからNASを見に行って音楽再生させたいんよね。」
「ほぅほぅ、いわゆるDMRってやつね」
「そそ。で、Androidアプリを探してみたけど、これが全然見つからない。」
「あら意外。DLNAアプリって結構見つかりそうなもんだけれど。」
「自分がDMCとかDMPになるアプリはあるけど、DMRはないんよなぁ。」
「あーまぁ、そらそうか。スマホやタブレットをレンダラーにする需要はあんまりなさそうやからなぁ・・・」
「そうなんよなー。毎回毎回タブレットを操作してるけど、できたらスマホからタブレットを操作したい。」
「なければ作ってみるかー? 多分フリーソフトがあるってことは仕様も公開されてるんでしょう」

って感じで作ってみようという事に。
まずはDLNAライブラリを探す。フリーソフトが出てるってことはきっとライブラリがあるのだろうとかって思ったけど思いの外無いのな!
Androidにも対応してるのでまず見つけたのがこれ。

対応Androidバージョンは2.1、一部2.2から。中華タブは4.0なので全く問題ないですね。
サンプルもあるしドキュメントも充実してるし、なかなか良さ気な感じ。

ただ、肝心のメディアレンダラーのサンプルがGStreamer使ってる。。。 ここは自分で実装しなさいという事に。
まーしゃーないな、とりあえず通信の流れを調べないとなーって思ったけどソースコード見てても正直よく分からん。。。

DLNAってちゃんとした規格? なんだし、どっかにドキュメントくらい落ちてるだろうって思って探したけどこいつがほんっとに見つからない! どうなってんねんというくらいに見つからない。DLNAの規格団体?のHPとか行ってみるけどドキュメント類は見つからない。

で、途方に暮れながら色々と調べていると見つかったのがこのツール。

なんかネットワーク内にあるDLNA(というかUPnP)デバイスの仕様を調べるのに便利なツールと、それらのツールのソースコード、さらにはプログラムのスケルトンを作ってくれるコードジェネレータがセットになった太っ腹なツール! Intelが公開しているようで、ライセンスはApache-2.0。素晴らしい。実に使いやすそう。

で、ようやく見つけたドキュメント類!

UPnPの団体の方を当たらないといけなかったか・・・。それは盲点だった。

で、DMSやらDMCやらDMRやらの用語が出てくるのかと想ったらそこはそうでもない。それはあくまでDLNAの範疇であって、UPnPでは
・DMS = Content Directory
・DMR = Media Renderer
・DMC = Control Point
と微妙に呼び方が違ったり。最初混乱したぜ・・・。

で、それらが通信する仕組みを理解してくるにつけ、
「あぁ、こいつらそりゃDLNA1.5準拠とか言っててもそりゃ繋がらねぇわ」
という思いが強まってくる。

なんせ、「UPnP」それぞれのサービスで規定されている事柄は非情に多岐にわたるんだけど、必須条件はかなり限られる。再生できるフォーマットの必須条件がかなり少ないのは調べてすぐ出てくる話だから知ってたけど、メディアデータの通信コントロールの実装がオプションだとは知らなかったわ・・・。

UPnPデバイスは「サービス」って言われる、UPnPで定められた役割をいくつか実装してるらしい。

例えば"Connection Manager"サービス。
まずLAN内にブロードキャスト飛ばして、
「おるかー?」
って聞いたり
「おるでー」
って答えたり、
「おぉお前さんどんなメディアとプロトコル扱えんの?」
とかのやりとりをする。

で、DMSが自分の持っているメディアの情報をやりとりするのが"Content Directory"サービス。
他のコントロールポイントとかレンダラーからの問い合わせに対して
「俺の扱えるMIMEタイプってこんなんやでー」
とか
「そのファイルのタグ情報はこれやでー」
みたいなやりとりをする。DMSはCMSとCDSの2つが必須。あとはオプション。

続いて、DMRが自分のプレイヤー状態をやりとりするのが"Remote Control"サービス。
これはまさにリモコン。特にテレビのリモコンをイメージするといいかな?
音量調整やら画質調整などを行う。DMRはCMSとRCSの2つが必須。あとはオプション。

そう、実はDMSとDMR、これらのデバイスって、必須条件はこれだけ。
メディアファイルをやりとりするサービスは両者ともにオプション扱い!

まぁ実際のところ、メディアをやり取りする"AVTransport"サービスについては多くの場合レンダラーが実装しているようです。いわゆるDMPですね。

まぁしかし、こうしたややこしい通信規約を見ると、そりゃ相性やらなんやらって出てくるわけだわ。メディア情報を見るための通信経路と実際にファイルをやり取りする経路は別だし。

ということで、ようのようやく概要を理解できてきたのでIntelのツールを使ってスケルトンコードを作り、その中身を実装していきたい所存。

ただ、それもかなり難航中。。。 ソースコードはまるっとあるからありがたいけど、ドキュメント類は特になし。。。 手を加える部分というか、見える部分のソースにはコメントが結構ついてるけど、そうじゃなくてライブラリとして使っちゃう部分はほぼコメント無し。ただ、APIのシグネチャにもコメント付けられてないからその関数が何をするものか、引数に何を与えるべきかはサンプルプログラムを見たりするしかない。。。
そこがちょっとしんどいかな。サンプルがあるだけマシと見るべきか・・・。

いやーにしても、ちょっとややこしいところに手を出しちゃった感じがするなぁ・・・。
分かってはきたけど逆に深みにハマっている気もする・・・w