ブロげ

屋外で802.11nの距離特性を測定した結果が伝えられている。

結論からすると、250m程度は届いたらしい。

AMIMON、WHDIチップセットの出荷開始を発表 、「非圧縮高品位ビデオの無線伝送が家中どこでも可能に – WHDI HDTV技術を世界最大の家電見本市、IFA2007（2007年度 IFA/ベルリン国際コンシューマー・エレクトロニクス展）にて展示」 – – CNET Venture View

船井電機Product Planning Divisionのゼネラルマネージャであるヨシタケ・モリヤス氏は次のように述べています。

ちょ、おま

AMIMONのWHDI技術はビデオモデムによる独自のアプローチを基盤としています。WHDIはライセンス不要の5GHz帯の40MHzチャンネルにおいて、非圧縮1080p（3 Gbpsのビデオレートに相当）の無線伝送を可能にします。20MHzチャンネルでは非圧縮720p、1080i、および1080p 24/30p（最大1.5 Gbpsのビデオレートに相当）を伝送することができ、FCC規制と日本の周波数帯域規制に適合しています。到達範囲は壁越しに150フィート以上（家屋全体）であり、またレイテンシは1ミリ秒未満です。

壁越しに30メートルいけるらしいです。

こういうのが、非圧縮無線技術で出てくるとですね、僕の研究がね、意味ないんですよ。3G bpsを伝送なんて言われちゃうとね、もう、どうでもいいやって。しかもレイテンシは1ミリ秒未満だって。

こりゃ、ちょ、おまなワケだよなぁ

IEEE802.11n用の試験システムが登場，東陽テクニカが販売：ITpro

731万6000円から。

ピクチャに含まれるスライスのサイズを数えて足してピクチャのサイズを算出した。映像ソースは1440×1080のHDV。

[code]
GOP_START_CODE 0:0:00:00 1 0
PICTURE_START_CODE 0 I
SLICE_START_CODE 1 [3255]
SLICE_START_CODE 2 [3203]
SLICE_START_CODE 3 [3181]
SLICE_START_CODE 4 [3220]
SLICE_START_CODE 5 [3170]
SLICE_START_CODE 6 [3074]
SLICE_START_CODE 7 [3435]
SLICE_START_CODE 8 [2836]
SLICE_START_CODE 9 [3062]
SLICE_START_CODE 10 [3140]
:
:
[/code]

Iピクチャ 20〜22kByte 1スライスあたり 3k〜4kByte
Pピクチャ 15〜16kByte 1スライスあたり 2.2k〜2.3kByte
Bピクチャ 6〜7kByte 1スライスあたり 0.9k〜1.1kByte

RTPもしくはDCCPの1つあたりに188バイト（TS）×7パケット＝1316バイトで、これが損失することで1スライス0.9k〜4kByte巻き込んで損失することになる。

当初はスライスヘッダを数えて損失の評価ができるかどうか考えていたが、1スライス内に1RTP分のペイロードの損失が見られるので、スライスの数に異常がなくてもマクロブロック・ブロックが消えてしまっているという状況がありえることが分かった。

スライスごとのサイズは算出できているので、サイズ比較をすれば上手くいくかもしれない。

補足：
VLCにESを食わせて吐かせたTSからさらにESを取り出すとスライスのサイズが変わっている。食わせたESがPESでAudioを含み、吐かせたESからはVideoしか抽出していないからかもしれない。

画像情報特論 授業資料 ストリーミングソフトウェアについてがMPEGについて分かりやすい。

この授業では、MPEG-2内部について考察させたりRTPやRTCPの送受信プログラムを組ませたりと、実装させている。時間がかかりそうな課題だ。

スライスヘッダのスタートコードを検索すると1ピクチャーあたり68のスライスがあった。このスライスは16ライン幅のマクロブロックの帯であるらしいので、16ライン×68スライス＝1088ライン？

スライスレイヤの下位にマクロブロックレイヤ、ブロックレイヤがある。この2つはそれぞれ動き補償・DCT処理を行うのだが、これらにはスタートコードがない。よってエラー発生時には次のスライスレイヤを探索してデコードを行うらしい。スライスレイヤはエラー発生時のときに再同期するために用意しているレイヤらしい。

VLCが吐いたMPEG TSからPESを取り出してESを取り出してMPEG VIDEO解析。スタートコードという0x000001b8などが来るまで待って、シーケンスヘッダということが分かるからその後は解析、という手順。

[code]
0:0:00:00 1 0 0 I 3 P 1 B 2 B 6 P 4 B 9 P 7 B 8 B 12 P 10 B 11 B
0:0:00:13 0 0 2 I 0 B 1 B 5 P 3 B 4 B 8 P 6 B 7 B 11 P 9 B 10 B 14 P 12 B 13 B
0:0:00:28 0 0 2 I 0 B 1 B 5 P 3 B 4 B 8 P 6 B 7 B 11 P 9 B 10 B 14 P 12 B 13 B
0:0:01:13 0 0 2 I 0 B 1 B 5 P 3 B 4 B 8 P 6 B 7 B 11 P 9 B 10 B 14 P 12 B 13 B
0:0:01:28 0 0 2 I 0 B 1 B 5 P 3 B 4 B 8 P 6 B 7 B 11 P 9 B 10 B 14 P 12 B 13 B
0:0:02:13 0 0 2 I 0 B 1 B 5 P 3 B 4 B 8 P 6 B 7 B 11 P 9 B 10 B 14 P 12 B 13 B
0:0:02:28 0 0 2 I 0 B 1 B 5 P 3 B 4 B 8 P 6 B 7 B 11 P 9 B 10 B 14 P 12 B 13 B
0:0:03:13 0 0 2 I 0 B 1 B 5 P 3 B 4 B 8 P 6 B 7 B 11 P 9 B 10 B 14 P 12 B 13 B
0:0:03:28 1 0 0 I 1 P
0:0:04:00 1 0 0 I 3 P 1 B 2 B 6 P 4 B 5 B 9 P 7 B 8 B 12 P 10 B 11 B 15 P 13 B 14 B
0:0:04:16 0 0 2 I 0 B 1 B 5 P 3 B 4 B 8 P 6 B 7 B 11 P 9 B 10 B 14 P 12 B 13 B 17 P 15 B 16 B
0:0:05:04 0 0 2 I 0 B 1 B 5 P 3 B 4 B 8 P 6 B 7 B 11 P 9 B 10 B 14 P 12 B 13 B 17 P 15 B 16 B
0:0:05:22 0 0 2 I 0 B 1 B 5 P 3 B 4 B 7 P 6 B
[/code]

まずはGOPヘッダとPICTUREヘッダまでを解析。hour:minute:second:picture closed_gop broken_link (temporal_referece picture_coding_type)の順序。

GOPがIピクチャーから始まっていなかったり、GOPが15ピクチャー以上あったり。この方法で比較してはいけないということが分かってきた。これ以上はスライスレイヤ・マクロブロックレイヤ・ブロックレイヤに下ることになる。これをソースと比較してするのは難しいのではないかと思う。

途中損失した場合の挙動はデコーダごとに異なるので、既存のデコーダを使って静止画をdumpさせて単純にSNR比較した方がいい気がする。

評価方法は別にして、IピクチャPピクチャBピクチャの探索の仕方が分かったのは大きい。Iピクチャは大事なので誤り訂正を付加したり、Bピクチャを捨ててしまおうと考えていた時期があったが、単にTSを見るだけでは無理だということが分かった。TSからESを取り出して、かつPICTUREヘッダを探してピクチャを見つけ、それに依存する下位のレイヤを全て抽出する作業が必要になってくる。

再生にPESヘッダが必要なのか疑問になってきた。DTS、PTSなくてもGOPにtime_codeあるし。ここら辺がよく分からない。

やけくそでMPEG-2コーデックに潜航してたらWeb上の資料が意外と多くて驚いた。

真空波動研がPCRとかGOPを解析しているとか知らなかったし。

mediatoolsのm2vhdrというプログラムが使いやすそうだけどソースコードがないし。

まるもさんのMPEG-2 VIDEO VFAPI Plug-Inにはaviutl時代にはお世話になった。まるもさんの日記がMPEGが濃くて一番面白い。

以下、参考資料。
Diary 2000-7
プログラミング万屋
MPEG.htm
MPEG1

MPEG-2 TSのPTS・DTS取得が出来た。

最後の1つ、2つの値が、PTSもしくはDTS/PTSの値。単位は秒。

30秒の動画で試したら、始まりが14810.282733s、終わりが14840.145900、ちゃんと30秒できている。

どうもMPEG_Primer_PV-050106-00.pdf (application/pdf オブジェクト)と同じ作業としているような…

で、PTSとDTSを取り出してから思った。これだけじゃ何処が損失したか分からない。GOPまで解析せにゃあかんのだろうか。

たぶんPESヘッダのRTPデータグラムをロスすると60kByteが全滅する可能性が高そう。たぶん次のPESヘッダ0x000001が来るまで回復できないんじゃなかろうか。たぶんPESヘッダは2つくらい冗長して送っても問題ないと思う。

てことが、CiNii – 高品質なMPEG2ビデオストリーミング配信のためのPESヘッダ保護の検討(Webサービスベースのオフィスアプリケーション・ネットワーキング・マネジメント及び一般)に書いてありそうなのだが、2年経過していないので読めない。悲しい。

補足：
ブロげ » MPEG-2ヘッダ解析プログラム

MPEG 2-TSについて調べた。今まではWebの情報とffmpegのソースコードを見て理解してきたが、デジタル放送教科書を拾ってきて読んだら、ソースコードの意味がよく分かった。まだ、紙資源は必要だ。

まずMPEG−2には「MPEG-2システム」という概念があり、その中にフォーマットとしてPSとTSがある。このPSとTSはPESを入れる入れ物でヘッダを持つ。PESとは符号化したばっかりのものであるESをパケット化したもので、これもまたヘッダを持つ。PSは蓄積メディア向けのヘッダであり、TSは放送メディア向けのヘッダである。

このPESにPTSとDTSという2つタイムスタンプが入っている。このPESがPSには複数入っているのだが、TSはPESを分割して入れてあるらしい。今日知った。

今まで全てのTSにPESヘッダが入っていると思ってパースして変になっていた。で、どのTSにPESヘッダが入っているのか分からないじゃないか、と思っていたら、TSにペイロードユニットスタートインジケータというビットがあり、このビットが1だとPESヘッダが入っていることが分かるらしい。

といってもPESヘッダはTSペイロードの途中に入ってもいいので、どこから始まりなのか分からんじゃないか、と思っていたらPESヘッダは必ず0x000001で始まるらしいことが分かった。

TSでも巡回カウンターというシーケンス番号っぽいものを持っているのだが、4ビットしか持たないため16パケット以上の損失が分からない。今回の実験ではMTU 1500としているため188バイト×7で7つのTSパケットを1データグラムに持つ。つまり、1データグラム損失してしまうと7進んでしまうのでTSの巡回カウンターでは損失は検知できても量まではよくわからない。やはりPTSで判断すべきか。

PTSは90KHzのクロックで計測した値を33ビット長で表すらしい。90kHzの理由はPALとNTSCの公約数で、33ビット長は24時間を表現するためらしい。計算すると確かに26時間以上表現できることが分かる。

PESヘッダを解析していくと、PESのペイロードのサイズは大きいもので65,508バイトあたりであった。つまり1つのPESを運ぶためには50データグラムのRTPの転送に成功する必要があるらしい。このPESペイロードに抜けができた場合、つまり損失があった場合にMPEGデコーダはどのような挙動をするのだろうか。

やはり、PES丸ごと捨ててしまうのだろうか。

参考：
MPEG-2システム – Wikipedia

MPEG-2 TSの概要 前編

MPEG-2 TSの概要 後編

フォーマット辞典 映像編 – しいしせねっと

MPEG技術解説 -第3章　MPEG-2 – [3.1 MPEG-2システム]

MPEG2/TS

作ってるプロトコル解析プログラムの備忘録。ソース見れば思い出すかもしれないけれど、きっと忘れる。

main.cの動き。

1. libpcapにてpcapファイルからプロトコル情報を全てメモリ上のリスト構造体にコピーする。
2. リストから最もはじめに受信したTCP, UDP, DCCPのうちのどれかを解析対象とする。
3. 解析対象プロトコルのうち、「送信元IPアドレス・あて先IPアドレス・送信元ポート番号・あて先ポート番号」が一致するフレームを数える。
4. 最も一致した「送信元IPアドレス・あて先IPアドレス・送信元ポート番号・あて先ポート番号」の組を新しいリストにフィルタリングする
5. フィルタリングした新しいリストに対してMAC層解析とトランスポート層解析を行い、テキスト出力する

pcapファイルの全フレームのヘッダ情報をメモリ上にコピーするのでメモリを食う。topコマンドで見ると5MB強。約6万フレームのヘッダ約80B程度とすると4.8MBなので、そんなもの。

サイズ（ストリップ込み）
[code]
noch@debian-noch:~/wa2/wa2$ ls -l a.out
-rwxr-xr-x 1 noch noch 12208 Aug 20 02:22 a.out
[/code]

速度
[code]
noch@debian-noch:~/wa2/wa2$ time ./a.out \
/tmp/tshark-tcp-snd070817-2257 > /dev/null

real 0m0.369s
user 0m0.268s
sys 0m0.100s
[/code]
グラフ作成込みで
[code]
noch@debian-noch:~/wa2/wa2$ time ./tcp.seq \
/tmp/tshark-tcp-snd070817-2257 > /dev/null

real 0m2.383s
user 0m1.020s
sys 0m0.124s
[/code]

依存関係はlibpcap.soくらい。
[code]
noch@debian-noch:~/wa2/wa2$ ldd a.out
libpcap.so.0.7 => /usr/lib/libpcap.so.0.7 (0xb7f4c000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e1b000)
/lib/ld-linux.so.2 (0xb7f7b000)
[/code]