で、既に読み込みが完了している部分ではシークができるんですが、読み込みが完了していない部分ではシークができません。
これはFlashの仕様に依存しています。
で、これをなんとかしてやりたいなぁと思っているわけです。
nginxのモジュールには似たような問題の解決方法があります。
http://nginx.org/en/docs/http/ngx_http_mp4_module.html
何をやっているかというと、getパラメーターで与えた値以降のみで構成されているmp4を生成して応答してやるというもの。
10秒からを選択した場合に、10秒の部分から始まるmp4をhtmlの応答として返せばいいじゃね？というわけです。
ただこのnginxのモジュールはローカルにあるファイルに対して実行する修正になります。
僕があつかっているデータはあくまで元データはyoutubeにあり、データ転送のproxyを実行することで転送途中で速度を損ねることなくデータ調整するところがミソになっています。というわけでnginxのモジュールでハイ解決とはいきません。
で、自作する必要があるわけなのでいままでのおさらいということでメモしておきます。
■作成プログラム第１号：(単なるproxyサーバー:nettyバージョン)
はじめにつくったプログラムはnettyから起こしたサーバーでした。
なぜnettyかというとflazrつながりでnettyにハマっていたからです。
確かにnettyでhttpサーバーを書くことができたのですが１つ問題がありました。
nettyで動作させたところ、応答データの追記書き込みができないみたいです。
httpのpartial Content(206応答)の肝はデータを少しずつ応答する・・・なんですが、この少しずつというのがnettyにとっては苦手みたいです。(すくなくともhttpサーバー動作としてつかったクラスは苦手だった模様です。)
しょっちゅうtimeoutとか起こして使いにくいなぁと思っていました。
このころはまずは動作を・・・ということでテストでつくってみたproxyサーバーになります。
■作成プログラム第２号：(単なるproxyサーバー:jettyバージョン)
上記のnettyバージョンのproxyサーバーを書いているときに、jettyのproxyServletの動作を参考にしていました。proxyServletを使うと手軽にproxyサーバーをつくることができます。
ここでいうproxyサーバーというのは、ネットワーク設定にいれて、全部のhttpの通信をこのproxyサーバーを通して動作させるというたぐいのproxyです。
mp4ファイルへのアクセスがどのようになっているのか調査するのにちょうどいい感じだったので重宝していました。
で、nettyでつくっていた動作の応答が芳しくなかったし、動作の調査してるときに、ちょうどjettyのプログラムにいろいろとログを挟んだりしていたので、じゃぁ、jettyに乗り換えるか・・・ということでjettyベースのプログラムを構築しました。
もちろんつくったのは、特定のファイルの通信にのみ間に入って手を加えるproxyです。
これははっきりいってあっさりできました。だって、アクセスパスから目標mp4のアドレスを調べてしまえばあとはproxyServletのコピペで終わっちゃいましたからね。
■作成プログラム第３号：(映像のないmp4をつくるバージョン)
単なるproxyがうまくいったので、そろそろ転送しているmp4のデータに口をだそうと思いました。とりあえず目標は通常の動画から映像部分を取り除いて音楽のみのデータに変えてやってiOS6.1のiPhoneでもBGM再生させること。これが目標です。
でやったこと
・音声用trakデータ、映像用trakデータの２種類がある。
・tag名をfreeに変更すると無視するtagに変更できる
以上の２点がmp4をいじっていてわかったのでproxy転送しているデータのtrakの部分をfreeに書き換えておくってやれば音声のみのmp4にできそうということになりました。
で、つくったところ、いい感じの動作をしてくれたのでさくさくっとjqmobiバージョンのmusicTubeをつくってベータリリースしました。
■作成プログラム第４号：(映像部のデータ転送やめましたバージョン)
上記のプログラムでもうまく動作していたんですが、映像の部分を無視するようにしたとはいえ、なくなったわけではないので使わないデータ転送がある状態でした。
使わないなら消しちまえということで、削除したかったのですが、そうなってくると、4バイト書き換えるだけでは済まなくなります。
で、やったこと
・映像用trakデータは必要ないので、削除する。
・削除にあわせてヘッダデータも書き換える。
・mdatの実データ内容もうまく変更してやる必要がある。
という３つを満たしつつ
・データ実体は持たない、http proxyとしてきちんと成立させる。
(転送速度に影響がでないようにする)
というちと無謀なことに挑戦してみました。まぁ、実際にできちゃったわけですが
まず１つ目の大問題
httpの応答では、これから応答するデータがどういう大きさであるか応答しなければいけません。初回アクセス時にこのサイズがどの程度になるかは誰にもわかりませんし、さすがにこの計算を実施してから応答を開始する・・・では遅すぎます。
たまたまiPhoneのアクセスでは何度が分けてアクセスが来ることが先のproxyServletの動作ログからわかっていたので、なにもわからなければデータ元のサーバーが応答したサイズをとりいそぎ返すことにしました。
続いて２つ目の問題
httpの全体のサイズはごまかしましたが、mp4の内部データでごまかしを使うわけにはいきません。(応答データが中途で変わることはまずありえないし)
というわけで、moovのタグの開始部(先頭から30バイト程度の部分があるやつ)の大きさは正しい値にする必要があります。この計算を高速に実施しないとhttp proxyとしては成立できなくなっちゃいます。
幸い次の２点のおかげで解決することができました。
・partialContentの要求を使うことで、originalデータの問い合わせ時に必要な部分の問い合わせに狙い撃ちできたこと。
・mp4の内部データがサイズ + タグ + 内容という構成だったので、あらかじめ大きさが把握できたこと。
いくつかのタグは非常に大きいので頭から律儀に読み込みを実施しているとタイムアウトになりそうなくらい時間がかかってしまうのですが、そのあたりはすっぱりあきらめサイズだけに重点を置いたところ解決できました。
３つ目の問題
moovの内容の応答を勧めていくことになるのですが、先ほどスキップしたデータの非常に大きなタグが次の問題になります。具体的には、stco(co64)のタグが問題です。
このタグは、mp4ファイルの内部のどこに目的のデータがあるか記述しているタグです。
データを書き換えつつ応答しなければいけないので、以下のような手法をとりました。
データ元のサーバーに２本httpUrlConnectionの読み込みストリームを作成して、映像と音声のstcoのデータを並列で取得しつつ、計算してたたき出した値をiPhoneに返していくという動作にしました。
後述のmdatの編集もそうなんですが、前から順にデータが並んでいるという構造であるため、逐次データをつくって応答していくということができて助かりました。
このときに平行してサーバー上のデータとして、mdatのデータのどの部分を抜き出して応答すべきかというデータを保持するようにしています。
あとは、mdatの部分の応答ですがデータ元サーバーからは全部DLしつつもクライアントには、計算して出した必要な部分のみ応答を返していくという動作をすることで、映像のデータを完全に除外したデータ転送を実施することに成功しました。
一応まだmetaデータ部(udat)がまぁなくてもいい命令なんですが、データ元サーバーのサインみたいなものだと思うので、そこには手を出してません。
あと、html5のaudioタグの動作仕様だと思うのですが、プレーヤー側でシークした場合に新しくparticalContentsでサーバー側にDLの要求が飛んでくるので、その場合は対応するデータ元サーバーへの問い合わせ位置を計算したあと、その場所からのDLを行いつつクライアントには必要なデータのみ応答するという動作に仕上げることができました。
これが現状のproxyサーバーの動作となります。
■これからつくるやつ案
とりあえず、Flashの動作のために、moovをもっと改造して中途から始まるmp4をつくる必要があります。
で、さくっとmp4ファイルをいくつか確認して関係ありそうなタグをあつめてみました。
trakの中のstbl以下の次のデータが関係ありそうです。
stsd (Sample descriptions)
stts (Map decoding time to sample)
stsc (Map sample to chunk)
stsz (Sample sizes)
stco (Chunk offsets)
stss (Sync sample table) (これは映像onlyっぽいです。もともと映像と音声を同期させるためのデータみたい)
まずstsd
ざっと調べたところ手持ちのmp4のデータではどれも１つのデータのみはいっているみたいです。とりあえずそのままコピーでいいかも
続いてstts
サンプルの時間の記述みたいです。中途で変わることがあるデータみたいなので、中途からはじめるためには、それにあわせて変更しないとだめみたいです。
stsc
Chunkの構成とそのデコード方法？が記述されているみたいです。
audioのデータをみるとそれほどデータ数がおおいわけではなさそうです。単なるサンプルとデコード方法の対応表だったら変更なしでもとりあえずいけるのだろうか？
stsz
サンプル１つ１つのサイズ定義
mp4の解説からするとまぁ、なくてもいいよというデータっぽいですが、いまのところ消せたらラッキーくらいに思っています。DL済みデータのシークができなくなるかもしれませんね。
stco
前回修正したmdat上のどこにデータがあるか指定
moovが先頭にきているデータなので、変更にあわせて書き換えが必要。
stss
映像と音声の同期用、今回は音声のみの抽出なのでばっさり削除でいいはず。(もともと映像側にしかないデータなので切ってるし)
http://d.hatena.ne.jp/SofiyaCat/20080430
こちらを今日は参考にしました。
まじめにmp4をつくるなら上記のデータの修正が必要になりそうです。
で、そんなことをしていると大変なので、proxy用に不真面目にやる方法も考えてみました。
１：DL済みデータのシークをすっぱりあきらめて参照用のindexがmdatの先頭にしかないデータをつくるやり方。
これが可能なら結構楽です。中途の位置を計算する方法がそもそも必要なくなりますので、moovの内容もとってもコンパクトになりそうです。
ただ、きちんと成立するデータがつくれるかちょっと疑問ですが・・・
問題点は、サイドシークした場合にDL済みの位置だとしても再DLを強制されるところ。
3G回線のandroid端末だと何度もmediaデータの転送が走ってイライラするかもしれません。
２：あたまの方にあるデータをすべて0byteだったことにするやり方。
これも可能なら非常に楽です。stcoのoffsetデータを目標の時間のデータまですべて0にしてしまって全部DLしているが見かけ上は中途再生にみえるみたいなことができるかもしれません。
問題点は、うごかない端末が出てくる可能性があることくらいでしょうか。
３：FLVにしちゃう。
osmfのプラグインにHLS対応のがあるんですが、mpegts→flv変換をactionScriptでやってるみたいです。同じようにmp4→flvのコンテナ変換を自力でやっちゃってflashに送るデータをflvにしてしまえば中途データにするのは非常に楽です。
これができたら汎用性かなり高くなりますね。flashをつかっている限り・・・はですが。
需要としては、flash→mp4変換がproxyでできてしまえばすばらしく良いということになりますが、そちらはおそらく無理でしょう。mp4の作成に必要なデータがflvの先頭だけで収集完了できるとは思えないです。
４：結局つくらない。
wifi環境(使えるところが光回線ばっかりだからだと思うのですが)で何度かFlashの動作を確認しているのですが、4時間ほどあるffのmp4でもDL完了までにかかる時間が50秒程度
DL済みの部分はシークできるので、まぁストレスはあるものの使えなくはない程度かなぁという感じです。通常の動画だと数秒でDL終わるし
とりあえず、いろいろ試していけそうな予感です。
