ページ

2011年11月13日日曜日

MediatombをビエラのDLNAサーバとして使う(その7)

(前回)

MediatombをビエラのDLNAサーバとして使った場合、早送りや一時停止をすると最後まで早送りができなかったり、一時停止後の復帰ができなかったりする。
(解決方法は、最下段(つづく)に記載しました)

別のDLNAサーバを使っても、無線LANを使わないようにしても現象は改善されなかった。


で、いろいろ調べてみるとDLNAクライアントからDLNAサーバにシーク指示(早送り等)を行う方法にはバイト・レンジ・シークとタイム・ベース・シークの2通りあることが判った。

(詳細は、PC onlineの記事の記事を参照)


そこで、tcpdumpコマンドを使ってパケットの内容を確認してみるとMediatombとビエラ間ではバイト・レンジ・シークを使っていた。

次に、ビエラから早送りをした時のパケットを確認してみると、ある一定の場所でビエラ側からシーク指示をやめていることが判った。

どうも、ビエラ側のプログラムは32bitで作成されているのか、ビデオのサイズを格納する変数がunsigned long int(4バイト)になっているようである。

つまり、4GB以上のビデオサイズ情報を格納する際にビエラ側で桁あふれを起こしてしまい、正しいビデオサイズが取得できないのである。(非常にレベルの低いプログラムバグであるが、パナソニックはタイム・ベース・シークのディーガ対応しか考慮していないようである。そうであるなら、dlna対応の表示を無くすべきであるが・・・)


(桁あふれの詳細を以下に記載)

ビデオサイズが15,993,158,308バイト(約15GB)の場合、ビエラ側で早送り指示を行うと約125,000,260バイト(約125MB)ずつの単位で次の開始位置をDLNAサーバに指示してきます。

(1)2,750,069,640バイトから再生
                 ↓
(2)2,875,069,900バイトから再生
                 ↓
(3)3,000,069,972バイトから再生

とパケットが来ますが、上記(3)の3,000,069,972バイトの次の指示をビエラが行わないのです。

unsigned long intの最大値は4,294,967,295バイトなのですが、ここに15,993,158,308バイトを格納すると桁あふれを起こして、3,108,256,422という数値が格納されてしまいます。

上記の(3)3,000,069,972に早送り分の125,000,260を足すと3,125,100,232という数値になってしまい、ビエラが間違って格納しているビデオサイズ(3,108,256,422)を超えてるので再生終了となってしまうのです。

この事から判るとおり、必ず4GBを超えて早送りができないという訳ではなく、3GBかも1GBかもしれないし、最悪は全く早送りができないかもしれません。つまり、桁あふれの仕方によるのです。

最悪です・・・

こんなことなら、レグザかブラビアにしておけば良かった。パナソニックは、この家電OSを他の家電メーカーに採用してもらおうと考えているようですが・・・・こんなレベルではね~どこも採用しませんよ。他にもバグありそうだし。

(追記 2012年7月11日)
上記への対応方法は(つづく)に記載しました。

(つづく)

0 件のコメント:

コメントを投稿