足あと(自由にコメント!)

以下のコメントに、足あとメッセージ(一番下の『コメントを書く』)を自由に残していってください。

トップページ


コメント

足あとのテストです。

来たぜ(sakaiyas)。

足あとのテストでした。

投稿: 本人 | 2010年3月 6日 (土) 14:47

単なるメモです(以下)。

LDPC Staircase は RFC5170, FEC は RFC5052, ALC は RFC3450, FLUTE は RFC3926 です。

投稿: 本人 | 2010年3月 7日 (日) 20:16

東京で一番うまい、立ち食いそば屋(以下)。

http://r.tabelog.com/tokyo/A1317/A131706/13040554/
→三軒茶屋のキャロットタワー 1Fの「かしわや」。冷凍麺でも、うまいぜ!

投稿: 本人 | 2010年3月 8日 (月) 15:01

Twitter のハッシュタグ「#isdbtmm」での検索結果です。

0032: LDPC Staircase の Staircase とは「階段」という意味で、右行列の「1」が階段状に並んでいる、ということです #isdbtmm

0031: RFC5170 の LDPC (低密度パリティ検査) Staircase の符号化と復号の計算例です。→ http://bit.ly/9thgUW #isdbtmm

0030: さらに、ファイルキャスティングのLDPCで復号したファイルの誤り検査は、MD5チェックサムで行なう仕様になっている。 #isdbtmm

0029: ファイルキャスティングのLDPCが誤り検査する必要がないのは、下位層のTSパケットでリード・ソロモン符号、畳み込み符号(ビタビ)で誤り訂正しているからである。→ http://bit.ly/aoT8XD in http://bit.ly/9h8jmu #isdbtmm

0028: ファイルキャスティングの受信漏れの考慮は、ファイル単位で数回送ること以外に、LDPCのような修復用のデータを送り、消失訂正を行なう方法もあり、通常は数回送ることと組み合わせる。 #isdbtmm

0027: よくある誤解は、ISDB-Tmm のファイルキャスティングのFLUTEのIPパケットがカルーセルで送らないから一発勝負だと考えること。受信漏れを考慮して、通常は、FLUTEのIP パケットも、ファイル単位で数回送る仕様である。 #isdbtmm

0026: ISDB-Tmm のファイルキャスティングは、SDPはカルーセルで、FDTのテーブルとデータはFLUTEのIPパケットで伝送する仕様だったな。 #isdbtmm

0025: 2036年と、ごっちゃにされてしまう、西暦2038年問題の記事です。→ http://bit.ly/9Mi2tg プログラミング言語の問題の話で、NTPとは無関係です。 #isdbtmm

0024: NTPの切り替え日の日付が1日ずれている件の説明です。→ http://bit.ly/b2QoFo まあ、2036年02月07日で終りではなく、NTP値の設定・参照方法を切り替えるだけですが。。。 #isdbtmm

0023: カルーセルとは? http://www.blwisdom.com/word/key/000939.html #isdbtmm

0022: 現行ワンセグでは、BML(HTMLに似た文字放送のようなもの)にカルーセルが使われています。 #isdbtmm

0021: これも、Vローの ISDB-Tsb の記事。 http://bit.ly/be9L35 後半に、ISDB-Tmm にはカルーセルがない、と書いてあるが、現行ワンセグの ISDB-T のカルーセルが最大64Kbps程度なので、使いたくないだけでしょうね。 #isdbtmm

0020: Vローの ISDB-Tsb の記事。 http://bit.ly/be9Vc2 VローとVハイを同じ端末で受信できる環境を整えることも考えているようです。 #isdbtmm

0019: ファイルキャスティングでヘッダ圧縮するなら、IPヘッダだけではなく、上位層の FLUTE, ALC, LCT, FEC 関連のヘッダも圧縮すべきだと考える。まあ、ROHC のように RFC で標準化されているものを使う気持ちも、わかりますけどね(笑)。 #isdbtmm

0018: TSパケットのTSヘッダの4バイト以降に分割されたペイロード部分がくるモデル(先頭は IPヘッダがくる)では、IPヘッダを圧縮する ROHC より、単にペイロード長を大きくすればいいだけ、と思うのは俺だけか? 184バイト以内という制限ないんだしね。 #isdbtmm

0017: TSパケットで、よくある誤解は、全188バイト内の先頭4バイトに引き続き、上位層のヘッダを常に置くモデルのみと勘違いすることである。先頭4バイトの直後に最大184バイトに分割されたペイロード部分がきてもよい。 http://bit.ly/9EZLv7 #isdbtmm

0016: TSパケット(トランスポート ストリーム)について→ http://bit.ly/aoT8XDhttp://bit.ly/9VXtrf #isdbtmm

0015: ISDB-Tmm のストリーミングはスカパー等がコンテンツ提供だろうが、ファイルキャスティングのコンテンツを提供するのはゲーム、新聞、天気、占い、音楽、小説、漫画、お笑い、等々 色々な業者があるな。 #isdbtmm

0014: 放送波を使うファイルキャスティングでは輻輳の心配はないが、(運用にもよるが)取り逃した部分の再送要求が頻繁に行なわれると、iモードで輻輳が発生することを忘れては ならない。 #isdbtmm

0013: ISDB-Tmm なり MediaFLO なり、プッシュキャスト(ファイルキャスト)されるコンテンツは、無限個は送れないことを忘れがちである。魅力のあるコンテンツを厳選したジャンルで分類しなさい、ということです。 #isdbtmm

0012: 地デジ跡地とかいう用語をよく見かけるけど、ISDB-Tmm とかはアナログテレビ周波数跡地であり、地デジ跡地には ならんと思うけどな。 #isdbtmm

0011: ISDB-Tmm でも MediaFLO でも、どちらでもいいけど、操作等のユーザインタフェースの統一は すべきですね。 #isdbtmm

0010: あっ、あとアンテナ長だな。 RT @sakaiyas まあ、ISDB-Tmm にしろ MediaFLO にしろ、周波数による情報量の違いを度外視すれば、受信周波数を変更するのは技術的な障害にはならないだろう。 #isdbtmm

0009: まあ、ISDB-Tmm にしろ MediaFLO にしろ、周波数による情報量の違いを度外視すれば、受信周波数を変更するのは技術的な障害にはならないだろう。 #isdbtmm

0008: マルチメディア放送のMediaFLO は、UHF帯62ch でも実証実験しているので、Vハイ不採用時の、転ばぬ先の杖も用意しているな。 http://bit.ly/b2y8Bp #isdbtmm

0007: Vローの ISDB-Tsb イジメじゃないけど、技術的には、地上デジタル音声放送の焼き直しだな、と感じる。 http://bit.ly/D4XIn #isdbtmm

0006: Vローの地上デジタルラジオって、ISDB-Tsb の1本のみで、ほぼ決定なんかな? http://bit.ly/a269Jz #isdbtmm

0005: Vハイのマルチメディア放送に、日本産の ISDB-Tmm と 米国産の MediaFLO という2つの方式が候補に挙がっている、ということです。 #isdbtmm

0004: 電波のVハイはマルチメディア放送、V ローはデジタルラジオと話題が出るが、自動車利用が想定されているVミドル(まだVミドルという言葉もない状態)は話が出てこないな。 #isdbtmm

0003: 2010年03月08日の発表会記事(一番わかりやすく詳しい、と思われる)。 http://bit.ly/8Zlse8 #isdbtmm

0002: 放送システム委員会 http://bit.ly/92YiNC #isdbtmm

0001: 株式会社マルチメディア放送(mmbi) http://www.mmbi.co.jp/ #isdbtmm

投稿: 本人 | 2010年3月21日 (日) 15:15

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その2)。

0040: よくある勘違いは、13セグメント形式がストリーミング専用、1セグメント形式がファイルキャスティング専用と勘違いすることである。13セグメント形式内にストリーミングとファイルキャスティングとが混在するのが普通である。1セグメント形式内でも混在は可能である。 #isdbtmm

0039: ISDB-Tmm は、最大33セグメントとれるが、13セグメント形式と1セグメント形式をそれぞれ整数個配置できるということである。(例) 13×2個+1×7個=33セグメント。 #isdbtmm

0038: ISDB-Tmm の場合は、ワンセグ等のEPG(電子番組表、電子番組ガイド)ではなく、ECG(電子コンテンツガイド)ということです。「コンテンツ」=「マルチメディア」 #isdbtmm

0037: スカパーでいうプロモチャンネルやEPGは、ISDB-Tmmではファイルキャスティングで配布が望ましいはずなので、「いったいストリーミングに流すほどリアルタイム性のあるコンテンツとは?」と、ふと疑問に思った。 #isdbtmm

0036: Vハイ全帯域分の ISDB-Tmm 送信機のハード開発記事。→ http://bit.ly/7IoK2g #isdbtmm

0035: ISDB-Tmm と MediaFLO の Vハイのハード会社は、1社体制に絞り込まれる話もある。→ http://bit.ly/d9O7dM #isdbtmm

0034: Vハイでの ISDB-Tmm と MediaFLO の共存も検討されている。→ http://bit.ly/cwV4I5 の(16/25)ページ目 in http://bit.ly/aBSdOU #isdbtmm

0033: ISDB-Tmm の いままでのツイート(つぶやき)をまとめました。→ http://bit.ly/bWnuuK #isdbtmm

投稿: 本人 | 2010年3月25日 (木) 19:00

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その3)。

0048: 地上波テレビ周波数の将来。UHF後半は携帯電話に割り当て、Vローは ISDB-Tsb でほぼ決定、Vハイは ISDB-Tmm と MediaFLO が候補に挙がっている、という現状と考える。→ http://bit.ly/9Q1Huj #isdbtmm

0047: 目安だが、Vハイの ISDB-Tmm の伝送速度は、1セグで300~400Kbps程度にはなるのだろう。→ http://bit.ly/bRE7iD http://bit.ly/aOOT7N #isdbtmm

0046: 概算だが、UHFのISDB-Tの12セグで16.8Mbps、1セグで416Kbps、VローのISDB-Tsbの3セグで990Kbps、1セグで 330Kbpsの伝送速度になる。→ http://bit.ly/bRE7iD http://bit.ly/aOOT7N #isdbtmm

0045: MediaFLO担当者に聞く、「携帯マルチメディア放送」の展望。記事中の「放送サービス」、「蓄積型サービス」は、それぞれ ISDB-Tmm での「ストリーミング」、「ファイルキャスティング」に相当する。→ http://bit.ly/aehkAd #isdbtmm

0044: ISDB-Tsb が音声だけのラジオではないことを強調するために、「V-Low3セグメントマルチメディア放送」という名称も出てきた。→ http://bit.ly/c9cxFs http://bit.ly/byNLTB #isdbtmm

0043: 将来的に、「地デジ」と「マルチメディア放送」と「デジタルラジオ」を1つの携帯電話で受信できそうです。→ http://bit.ly/byNLTB 「地デジ」:UHF、「マルチメディア放送」:Vハイ、「デジタルラジオ」:Vロー #isdbtmm

0042: Vローを ISDB-Tsb の3セグメント形式で目一杯割り当てると、3×13個+1×2個=41セグメントと計算でき、最大13個の3セグメント形式のマルチメディア放送ができることになる。→ http://bit.ly/c9cxFs #isdbtmm

0041: 1セグメント=429kHz幅で計算(ガードバンド 38.48kHz)すると、Vハイ(207.5~222MHz)の ISDB-Tmm は最高33セグメント、Vロー(90~108MHz)の ISDB-Tsb は最高41セグメントになるな。 #isdbtmm

投稿: 本人 | 2010年3月26日 (金) 11:58

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その4)。

0052: ISDB-Tmm 関連の情報をまとめてみました。→ http://bit.ly/difWBo #isdbtmm

0051: Vハイの ISDB-Tmm や Vローの ISDB-Tsb を利用したサービスは、イーピーやモバHO! の失敗から学ぶことは多い、と考える。 #isdbtmm

0050: イーピー(ep)。2004年4月に蓄積型サービスを終了しています。→ http://bit.ly/asVSo6 #isdbtmm

0049: モバHO!(モバホ!)。既に、2009年3月31日でサービスを終了しています。→ http://bit.ly/c7ozwr #isdbtmm

投稿: 本人 | 2010年3月27日 (土) 22:15

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その5)。

0061: ISDB-Tmm のファイルキャスティング(蓄積型放送)は、FLUTE を利用します。→ http://bit.ly/bbWJWZ ※ISDB-Tmm では ARIB を利用しないわけではなく、まだ ARIB で規格化されていない、という意味です。 #isdbtmm

0060: ISDB-Tmm の元となる ISDB-T のARIB規格番号一覧です。→ http://bit.ly/dliImU の「ISDB-T仕様」という一覧表 #isdbtmm

0059: ARIB(アライブと読む人が多い)の標準規格と技術資料の一覧の一覧。→ http://bit.ly/vzd4u in http://www.arib.or.jp/ #isdbtmm

0058: 私が、VHF-HIGH 帯とVHF-LOW 帯をそれぞれ Vハイ、Vローと書く理由は、Twitter が文字数を全角でも半角でも1文字とカウントする仕様なので、VハイもVローも3文字と一番短く書けるからです。 #isdbtmm

0057: Vローのマルチメディア放送の説明がある Webページ。→ http://bit.ly/d76CeD in http://bit.ly/cjzYb3 #isdbtmm

0056: エンジニアリングサービスの説明。 → http://bit.ly/aIzk2H ISDB-Tmmでは、ファイルキャスティングで特定の受信機のソフト改変パッチや全機種共通の変更アイコン画像等を送ることになるでしょう。 #isdbtmm

0055: 【訂正】Vミドルではなく、VHF-High帯の前半。自営通信に利用予定。→ http://bit.ly/bD64G2 QT @sakaiyas (略)…自動車利用が想定されているVミドル(まだVミドルという言葉もない状態)は話が出てこないな。 #isdbtmm
→「0004:」の訂正です。

0054: 「委託事業者」(コンテンツ供給者)→→→(コンテンツ)→→→「受託事業者」(放送免許と送信設備を所有)。→ http://bit.ly/9SkITi #isdbtmm

0053: 携帯端末向けマルチメディア放送の「委託事業者」と「受託事業者」の関係です。→ http://bit.ly/9SkITi #isdbtmm

投稿: 本人 | 2010年3月29日 (月) 21:35

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その6)。

0075: 復号時のメモリ使用量に関しては、LDPC Staircase のシンボル長( E バイト) 以外に、修復シンボルを含めたブロックの限界サイズ( max_n シンボル数) 等が関係します。→ http://bit.ly/9thgUW #isdbtmm

0074: ISDB-Tmm では、携帯端末での復号時のメモリ使用量を考慮して、LDPC Staircase のシンボル長( E バイト) の上限が決定します。→ http://bit.ly/9thgUW #isdbtmm

0073: FLUTE の UDP/IP ヘッダー、ALC/LCT ヘッダーのオーバーヘッドを減少するために、通常は LDPC Staircase のシンボル長( E バイト) を大きくとります。→ http://bit.ly/9thgUW #isdbtmm

0072: FLUTE の IPパケットのサイズに関係のある、LDPC Staircase のシンボル長( E バイト) は、技術的には4バイトでも512バイトでも問題なしです( E = 64Kバイト程度まで可能)。→ http://bit.ly/9thgUW #isdbtmm

0071: 【ファイルキャスティング関連】の図の「LDPC復号」の欠損パケットは、FLUTE の IPパケットのことです。ヘッダーのオーバーヘッド減少のため、通常 IPパケットは複数のTSパケットにまたがるサイズとなります。→ http://bit.ly/difWBo #isdbtmm

0070: 【ファイルキャスティング関連】の図では、FLUTE の SDP(ファイル詳細等が書かれたセッション記述プロトコル)や FDT(XML表現のファイル送付形式)は省略しました。→ http://bit.ly/difWBo #isdbtmm

0069: 【ファイルキャスティング関連】の図では、バイトインターリーブ(バイト単位で並び替え)等のバーストノイズ回避対策は省略しました。→ http://bit.ly/difWBo #isdbtmm

0068: 間違えやすいが、伝送路(放送波)に近い方を内符号、遠い方を外符号と呼ぶ。 #isdbtmm

0067: 【ファイルキャスティング関連】に図を追加しました。→ http://bit.ly/difWBo #isdbtmm

0066: 「株式会社マルチメディア放送」(mmbi) は、かつて「マルチメディア放送企画 LLC合同会社」(MMBP)と呼ばれていました。→ http://bit.ly/aHlAHh #isdbtmm

0065: 株式会社マルチメディア放送(mmbi) は、ファイルキャスティングを軸にサービス展開を考えているようです。→ http://bit.ly/a3ul9a #isdbtmm

0064: 2010年03月08日の発表会記事(「蓄積型放送」を「貯蓄型放送」と書き間違えている以外は、すごくわかりやすい内容です)。→ http://bit.ly/cM7His #isdbtmm

0063: 【ISDB-Tmmの概要図】を追加しました。→ http://bit.ly/difWBo #isdbtmm

0062: Vハイの ISDB-Tmm や MediaFLO の予測を含めた今後のスケジュール(2010年4月からは予測となる)。→ http://bit.ly/aCe7hY in http://bit.ly/cFKVvJ #isdbtmm

投稿: 本人 | 2010年4月 7日 (水) 15:12

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その7)。

0090: まとめると、技術的には UHF帯でもVハイでもVローでも、コンテンツ配信が可能である、ということ。(コンテンツ:マルチメディア ファイル)。 #isdbtmm

0089: さらに、UHF帯のエリア限定ワンセグでもファイルキャスティングの技術検証を行なっている、ということである。→ http://bit.ly/cOBSoR #isdbtmm

0088: Vローのマルチメディア放送を UHF帯の ISDB-T のワンセグに例えると、「地方ブロック向け」が通常のワンセグ、「新型コミュニティ」がエリア限定ワンセグに相当する。→ http://twitpic.com/1e0hv4 #isdbtmm

0087: エリア・ワンセグ(エリア限定ワンセグ)とは。→ http://bit.ly/aVMJyD #isdbtmm

0086: AMIOフォーラムでの、ISDB-T のワンセグ放送波を利用したコンテンツ(新聞・雑誌)配信の記事です。→ http://bit.ly/cOBSoR #isdbtmm

0085: 【訂正】RFC4326 の ULE を考慮すると E = 32Kバイト程度までとなる。 QT @sakaiyas FLUTE の IPパケットのサイズに関係のある、LDPC Staircase のシンボル長( E バイト) は、…(略)… #isdbtmm
→「0072:」の訂正です。

0084: Vハイの ISDB-Tmm や Vローの ISDB-Tsb の技術はさておき、ファイルキャスティングを生かすも殺すもコンテンツプロバイダ次第だと考えている。→ http://bit.ly/5ziSp6 #isdbtmm

0083: 一例(案)だが、ファイルキャスティングの新聞配布では、Vハイの ISDB-Tmm が全国紙、Vローの ISDB-Tsb が地方紙となる。さらに、Vローの「新型コミュニティ」にチラシ配布がある(案)。 #isdbtmm

0082: 現状「ユビキタス」に厳密な定義はないが、「『いつでも、どこでも、だれでも』恩恵をうけることができるインタフェース、環境、技術」と考えてください。→ http://bit.ly/tQJQI #isdbtmm

0081: Vローで使用予定の ISDB-Tsb 方式での、福岡ユビキタス特区におけるマルチメディア放送実験の様子です。→ http://bit.ly/bTXi2k #isdbtmm

0080: Vローの「マルチメディア放送ビジネスフォーラム」のWebページです。→ http://www.drforum.jp/ #isdbtmm

0079: Vローの「デジタル新型コミュニティ放送WG」についての記述があります。→ http://bit.ly/fS6Pu #isdbtmm

0078: 放送システム委員会(第20回)「資料20-4」の最終ページの写し。→ http://twitpic.com/1e0hv4 Vハイは「全国向け」、Vローは「地方ブロック向け」と「新型コミュニティ」に割り当てることが適当と考えている。 #isdbtmm

0077: 携帯端末向け放送の方式としては、MediaFLO、ISDB-Tのワンセグ、ISDB-Tsb、T-DMB、DVB-H や ISDB-Tmm がある、ということです。→ http://bit.ly/7QKWHO #isdbtmm

0076: 地上デジタルテレビ放送の方式分布図(携帯端末向けではなく固定テレビ中心です)。→ http://bit.ly/dk4A2D #isdbtmm

投稿: 本人 | 2010年4月10日 (土) 12:33

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その8)。

0101: 要するに、今回は「Vハイ」についての話であって、「Vロー」の制度整備等については後日行なう予定である、ということ。→ http://bit.ly/bixPeo #isdbtmm

0100: 総務省の考え方としては、「90~108MHz帯(いわゆるVHF-LOW帯)を用いて実現する放送についての制度整備を行うに当たっても、今回と同様に意見募集を実施することを予定しています。」とのこと。→ http://bit.ly/bixPeo の「別紙1」より #isdbtmm

0099: 【周波数の図】2010年4月14日「携帯端末向けマルチメディア放送の実現に向けた制度整備案に対する意見募集の結果並びに当該制度整備案の一部に係る電波監理審議会への諮問及び答申」の「別紙4」の1頁目の写し。→ http://twitpic.com/1fo70n #isdbtmm

0098: 既に携帯電話でワンセグ放送が視聴でき、BML からのパケット通信で双方向性もある日本の環境では、ストリーミングではなくファイルキャスティングに ISDB-Tmm 陣営も MediaFLO 陣営も注力するのは、至極当然のことではある。 #isdbtmm

0097: MediaFLO 方式でサービスしている米国の FLO TV が、既存の「ストリーミング放送」に加えて4つのサービス(双方向、1日契約のPPD、契約者用のオプション番組視聴、時差視聴)を開始する、という記事。→ http://bit.ly/cTPwxZ #isdbtmm

0096: ファイルキャスティングで携帯端末に蓄積したコンテンツを使用する際の認証や購入時にも、iモード等のパケット通信を使用します。→ http://mmbi.co.jp/about.html #isdbtmm

0095: ISDB-Tmm のファイルキャスティングでは、受信シンボル数不足でLDPCを使っても どうしても修復できなかった部分は、iモード等のパケット通信で、携帯端末側から再送要求して、サーバ側から不足シンボルを送ってもらい、通信補完する方法があります。 #isdbtmm

0094: 【ファイルキャスティングの送出側】(ROHCによるヘッダ短縮)と括弧しているのは、RFC4815(RFC3095の訂正と解説) にある UDP/IP の ROHC によるヘッダ短縮という細かい部分までは、存在自体知っている程度でよいと考えているからです。 #isdbtmm

0093: 【ファイルキャスティングの送出側】(FEC追加)と括弧しているのは、FDT(XML表現のファイル送付形式)等は誤り訂正(消失訂正)の修復パケットを送らない場合があるため。 #isdbtmm

0092: 【ファイルキャスティングの送出側】「任意ファイル」→「固定長ブロック分割」→(FEC追加)→「FLUTE(LCT, FEC)」→「UDP/IP」→(ROHCによるヘッダ短縮)→「ULEによるカプセル化」→「IP over MPEG-2 によるTSパケット化」 #isdbtmm

0091: 「MPEG-2 TS over IP」は、TSパケットを IPパケットに乗せて送ること。「IP over MPEG-2」は、IPパケットをTSパケットに乗せて送ること。ISDB-Tmm は後者の「IP over MPEG-2」でファイルキャスティングしている。 #isdbtmm

投稿: 本人 | 2010年4月16日 (金) 14:08

《任意のファイルからTSパケットに分解する手順》

「平成二十二年四月二十三日 総務省令第五十五号」及び
「平成二十二年四月二十三日 総務省告示第百七十一号」より

http://twilog.org/sakaiyas/date-100429 の記述の整理(下記)

【ファイルキャスティングの送出側】(ISDB-Tmm の場合)

(1) 「任意ファイル」→「固定長ブロック分割」→(FEC追加)→ 「FLUTE(LCT, FEC)」→「UDP/IP」→(TLV式のヘッダ短縮)→「ULEによるカプセル化」→「IP over MPEG-2 によるTSパケット化」

(2) 「固定長ブロック分割」(A_large と A_small)やFEC(一方向誤り訂正符号)の1つである LDPC Staircase の詳細です。→ http://bit.ly/9thgUW

(3) (FEC追加)と括弧しているのは、FDT(XML表現のファイル送付形式)や極小サイズのファイル等は誤り訂正(消失訂正)の修復パケットを送らない場合があるため。

(4) (TLV式のヘッダ短縮)と括弧しているのは、 直接 UDP/IPv4 や UDP/IPv6 で送る場合もあるため。(『TLV式のヘッダ短縮』:TLV多重化方式で用いたUDP/IPヘッダ圧縮方式)

(5) 「TLV式のヘッダ短縮」の詳細は、私の2010年04月25日のツイートを参照のこと(ヘッダ圧縮IPパケットのあたり)。→ http://twilog.org/sakaiyas/date-100425

  http://twilog.org/sakaiyas/date-100425 の記述の整理(下記)

 (5-1) 【TLV】Type Length Value での伝送方式。8ビットの packet_type、16ビットの length、可変長のデータ部がある。ISDB-Tsb および ISDB-Tmm では、TLV多重化するのではなく、TLV多重化方式のヘッダ圧縮方式を使用する。

 (5-2) 【TLVのpacket_type(パケット種別)】0x01:IPv4パケット、0x02:IPv6パケット、0x03:ヘッダ圧縮IPパケット、 0xFE:伝送制御信号パケット、0xFF:ヌルパケット。ISDB-Tsb および ISDB-Tmm では、TLV自体は使用せず、ULEでカプセル化する。

 (5-3) 【ヘッダ圧縮IPパケット】12ビットの CID(コンテクスト識別)、4ビットの SN(連続番号)、8ビットの CIDヘッダ種別、圧縮ヘッダと任意長のペイロード部がある。

 (5-4) 【ヘッダ圧縮IPパケットのCID】IPv4パケットのプロトコル又は、IPv6パケットのネクストヘッダ並びに送信元アドレス、宛先アドレス、送信元ポート及び宛先ポートの5つの領域の値が同一の組み合わせを持つIPパケットに同一のCID値を与える。

 (5-5) 【ヘッダ圧縮IPパケットのCIDヘッダ種別】0x20:IPv4/UDPヘッダを持つIPパケット圧縮時のフルヘッダ(ただし、データ長やチェックサムは削除して詰めたヘッダ)、0x21:IPv4/UDPヘッダを持つIPパケット圧縮時の圧縮ヘッダ、

 (5-6) 【ヘッダ圧縮IPパケットのCIDヘッダ種別】0x60:IPv6/UDPヘッダを持つIPパケット圧縮時のフルヘッダ(ただし、データ長やチェックサムは削除して詰めたヘッダ)、0x61:IPv6/UDPヘッダを持つIPパケット圧縮時の圧縮ヘッダ。

 (5-7) 【ヘッダ圧縮IPパケットのCIDヘッダ種別=0x20の場合】12ビットの CID、4ビットの SN、8ビットの CIDヘッダ種別(0x20)、128ビットの 部分IPv4ヘッダ、32ビットの部分UDPヘッダ、任意長のペイロード部。

 (5-8) 【ヘッダ圧縮IPパケットのCIDヘッダ種別=0x21の場合】12ビットの CID、4ビットの SN、8ビットの CIDヘッダ種別(0x21)、16ビットの IPv4ヘッダ内の識別子(identification)、任意長のペイロード部。(『IPv4』時の圧縮ヘッダ)。

 (5-9) 【ヘッダ圧縮IPパケットのCIDヘッダ種別=0x60の場合】12ビットの CID、4ビットの SN、8ビットの CIDヘッダ種別(0x60)、304ビットの 部分IPv6ヘッダ、32ビットの部分UDPヘッダ、任意長のペイロード部。

 (5-10) 【ヘッダ圧縮IPパケットのCIDヘッダ種別=0x61の場合】12ビットの CID、4ビットの SN、8ビットの CIDヘッダ種別(0x61)、任意長のペイロード部。(『IPv6』時の圧縮ヘッダ)。

 (5-11) 【ヘッダ圧縮IPパケットでのIPv4パケット送出】時々 CIDヘッダ種別=0x20 のフルヘッダで送り、主に CIDヘッダ種別=0x21 の圧縮ヘッダで送る、ということ。

 (5-12) 【ヘッダ圧縮IPパケットでのIPv6パケット送出】時々 CIDヘッダ種別=0x60 のフルヘッダで送り、主に CIDヘッダ種別=0x61 の圧縮ヘッダで送る、ということ。

【補足資料】

・標準テレビジョン放送等のうちデジタル放送に関する送信の標準方式(平成十五年一月十七日総務省令第二十六号)→ http://bit.ly/avhrGf

・標準テレビジョン放送等のうちデジタル放送に関する送信の標準方式第三条第二項第二号及び第三号等の規定に基づく関連情報の構成及び送出手順等(平成二十一年総務省告示第八十八号)→ http://bit.ly/drUVHh

以上

投稿: 本人 | 2010年4月29日 (木) 15:25

【FLUTEヘッダ】

http://twilog.org/sakaiyas/date-100502 の記述の整理(下記)

(1) EXT_FTI は FDT(XML)には必須だが、ファイル(オブジェクト)に関しては、FDT に FEC-OTI-* を書いてあるので、EXT_FTI があっても無くてもよい(RFC3926, RFC3450, RFC5170 より)。

(2) LDPC Staircase の場合の図には、グループ化(G>1)までは書いていない。E バイトの Encoding Symbol が G個置かれることになる(RFC5170 より)。→ http://twitpic.com/1kaqxd

(3) HDR_LEN は、32ビット単位のLCTヘッダ長(32ビットで1行となる)で、標準LCTヘッダと拡張LCTヘッダを合わせた行数である(RFC3450, RFC3451 より)。

(4) HET が 0以上127以下の場合は、その拡張LCTヘッダは HEL行となる。HET が 128以上255以下の場合は、その拡張LCTヘッダは1行(32ビット)となる(RFC3450, RFC3451 より)。

投稿: 本人 | 2010年5月 2日 (日) 23:44

【PM88】

http://twilog.org/sakaiyas/date-100505 の記述の整理(下記)

(1) RFC5170に出てくるPRNG(擬似乱数生成器)。A=16807、M=2147483647 固定で、I[0]=seed値(1~2147483646)を与えた、『I[j+1] = mod(A * I[j], M)』の擬似乱数列(I[1], I[2], …)のこと。

(2) RFC5170では、さらに 0 以上 maxv-1 以内の数値になるように、擬似乱数列(I[1], I[2], …)に maxv を掛けたものを 2147483647 で割り、スケーリングしています。

(3) SymbianOSでの一例ですが、RFC5170の pmms_rand(maxv) を『scaled_value = (TUint32) ((TUint64)maxv * (TUint64)raw_value / (TUint64)0x7FFFFFFF);』と書いても問題ありません。

投稿: 本人 | 2010年5月 5日 (水) 12:06

http://twilog.org/sakaiyas/date-100507 の記述の整理(下記)

(1) RFC5170 で擬似乱数に PM88 を使用する一番の理由は、計算式が単純で計算時間が短いことである。擬似乱数列が長周期性で一様性(散らばり具合が均等)があるのは、オマケのような必須条件である。

(2) RFC5170 のグループ化(G>1)時に ESI(Encoding Symbol ID)を修復シンボルのみランダマイズする理由は、LDPC Staircase では、隣接する修復シンボルが同時に欠損すると、ソースシンボルを修復しづらくなるためである。

投稿: 本人 | 2010年5月 7日 (金) 12:36

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その9)。

0117: 「マルチメディア放送のデジタルコンテンツと主な金銭の流れ図」→ http://twitpic.com/2fhie7 委託放送事業者と受託放送事業者まわりの関係図です。 #isdbtmm

0116: 【『委託』放送事業者】報道・教養・音楽・娯楽 等の、映像・音声ばかりでなく様々なファイル形式の、コンテンツ供給者。【『受託』放送事業者】放送免許と送信設備を所有。 #isdbtmm

0115: 「ISDB-Tマルチメディアフォーラムでの新分科会設置について」→ http://mmbi.co.jp/?p=218 「委託放送分科会」と「受託放送分科会」が設置されました。 #isdbtmm

0114: マルチメディア放送がもたらす「あたらしい感動」の可能性(報告)→ http://bit.ly/b6y2bz #isdbtmm

0113: 【説明会の実施内容の記事】「携帯端末向けマルチメディア放送の実現のための開設計画に関する公開説明会(第2回)」(開催日:平成22年7月27日)→ http://bit.ly/afuAEI #isdbtmm

0112: 「放送」と聞くとストリーミングという映像のリアルタイム放送をイメージしがちだが、マルチメディア放送の場合は、電波によって報道・教養・音楽・娯楽などを多数の受信者に送ることであり、映像以外に様々な形式のファイル(コンテンツ)も送ります。 #isdbtmm

0111: 総務省 報道資料「携帯端末向けマルチメディア放送の実現のための開設計画に関する公開説明会(第2回)の開催」(開催日:平成22年7月27日)→ http://bit.ly/arAkKu #isdbtmm

0110: 総務省 報道資料「207.5MHz以上222MHz以下の周波数を使用する特定基地局の開設計画の認定に係るヒアリングの開催」(開催日:平成22年7月21日)→ http://bit.ly/952aGT #isdbtmm

0109: 株式会社マルチメディア放送もメディアフロージャパン企画株式会社も衛星回線で中継するので、雲が厚くて衛星からの電波が届かないときにどうするのかと思っていたが、どちらも光等の予備回線を考えているので安心した。 #isdbtmm

0108: 平成22年6月25日「携帯端末向けマルチメディア放送の実現のための開設計画に関する公開説明会」の記事です。→ http://bit.ly/94FXxV #isdbtmm

0107: 総務省 報道資料「携帯端末向けマルチメディア放送の実現のための開設計画に関する公開説明会の開催」(開催日:平成22年6月25日)→ http://bit.ly/9Zmc6x #isdbtmm

0106: 総務省 報道資料 平成22年6月9日「207.5MHz以上222MHz以下の周波数を使用する特定基地局の開設計画に係る認定申請の受付結果」→ http://bit.ly/9LCcz9 #isdbtmm

0105: 結局、ISDB-Tmm 側は、mmbi が受託放送事業者(ハード事業者)として特定基地局の開設計画の認定申請を行なった、ということである。→ http://bit.ly/9cQDsA #isdbtmm

0104: 携帯端末向けマルチメディア放送に関する特定基地局開設計画の認定申請について。→ http://mmbi.co.jp/?p=144 #isdbtmm

0103: 【続き】 http://bit.ly/cVtejr in http://bit.ly/cNm4sY 勝手な想像だが、基地局から発射する電波の型式が ISDB-Tmm 方式か MediaFLO 方式かのどちらか決定してから、その1方式をARIB標準化するという考えだと思われる。 #isdbtmm

0102: Vハイの携帯端末向けマルチメディア放送のARIB標準化は、2010年秋頃になる模様です。→ http://bit.ly/cVtejr in http://bit.ly/cNm4sY 【続く】 #isdbtmm

投稿: 本人 | 2010年8月18日 (水) 09:46

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その10)。

0134: 総務省 報道資料 平成22年9月9日「207.5MHz以上222MHz以下の周波数を使用する特定基地局の開設計画の認定」→ http://bit.ly/ans1Sm 総務省は、株式会社マルチメディア放送(mmbi)の開設計画を認定しました。 #isdbtmm

0133: 総務省 報道資料 平成22年9月8日「207.5MHz以上222MHz以下の周波数を使用する特定基地局の開設計画の認定に係る電波監理審議会からの答申」→ http://bit.ly/djMcEv #isdbtmm

0132: 【放送】電波によって、報道・教養・音楽・娯楽などを多数の受信者に送ること。→ 音声配信が「ラジオ放送」、さらに +映像配信が「テレビ放送」、さらに +ファイル配信が「マルチメディア放送」と考えるとよい。 #isdbtmm

0131: 総務省 平成22年9月3日「207.5MHz以上222MHz以下の周波数を使用する特定基地局の開設計画に係る公開説明会」の記事です。→ http://bit.ly/cWPCaA #isdbtmm

0130: VHF-High帯マルチメディア放送の受託放送事業者(放送免許と送信設備を所有)の認定について、同じ日に、非公開ヒアリング( http://bit.ly/9zbfAk )と公開説明会( http://bit.ly/bGx8tv )が、あるわけです。 #isdbtmm

0129: 総務省 報道資料「207.5MHz以上222MHz以下の周波数を使用する特定基地局の開設計画に係る公開説明会の開催」(開催日:平成22年9月3日17時~)→ http://bit.ly/bGx8tv (電波監理審議会が要請した)総務省開催の公開説明会です。 #isdbtmm

0128: 総務省 開催案内「207.5MHz以上222MHz以下の周波数を使用する特定基地局の開設計画の認定に係るヒアリング開催案内」(開催日:平成22年9月3日)→ http://bit.ly/9zbfAk 『電波監理審議会』がヒアリングします。 #isdbtmm

0127: 「VHF/UHF とは」→ http://bit.ly/bD64G2 一般的に、VHFの方がUHFより遠く広範囲に電波が届くが、伝送できる情報量はVHFの方が少なくなる。 #isdbtmm

0126: 「マルチメディア放送とは?」→ http://mmbi.co.jp/about.html 「ISDB-Tmm」方式でのマルチメディア放送の説明です。 #isdbtmm

0125: ISDB-Tmm 用の「INTの構成」( http://twitpic.com/2g3j8q ) および「IP/MACストリーム配置記述子の構成」( http://twitpic.com/2g3jeg )。(平成22年 総務省告示第171号の写し) #isdbtmm

0124: ISDB-Tmm 用【システム管理記述子の構成における、放送の標準方式の種別】値:「‘001010’」、割当て:「標準方式第3章の2第1節に規定するデジタル放送」を追加する。(平成22年 総務省告示第171号より) #isdbtmm

0123: ISDB-Tmm 用【サービスリスト記述子の構成における、サービス形式識別の種別】値:「0xC2」、割当て:「マルチメディア放送」を追加する。(平成22年 総務省告示第171号より) #isdbtmm

0122: ISDB-Tmm 用【INTの構成】「INTの構成」やINTの記述子1又は記述子3の領域で伝送する「IP/MACストリーム配置記述子の構成」が、平成22年 総務省告示第171号に書かれています。 #isdbtmm

0121: ISDB-Tmm 用【INT】伝送制御信号に、セクション形式によるINT(IP/MAC Notification Table:放送番組番号を識別するサービス識別子とIPパケット等とを関連付ける伝送制御信号)を追加する。(平成22年 総務省令第55号より) #isdbtmm

0120: 「携帯マルチメディア放送、事業者選び最終局面 ドコモ有利? 決着先送り濃厚」→ http://bit.ly/95IOI8 VHF-High帯を使用する携帯端末向けマルチメディア放送の現状を、簡潔にまとめている記事です。 #isdbtmm

0119: 【諮問直後の関連記事です】平成22年8月17日「207.5MHz以上222MHz以下の周波数を使用する特定基地局の開設計画の認定に係る電波監理審議会への諮問」→ http://bit.ly/bN8wYJ #isdbtmm

0118: 総務省 報道資料 平成22年8月17日「207.5MHz以上222MHz以下の周波数を使用する特定基地局の開設計画の認定に係る電波監理審議会への諮問」→ http://bit.ly/ck8TPk #isdbtmm

投稿: 本人 | 2010年9月 9日 (木) 18:20

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その11)。

0148: 【ISDB-Tmm の FLUTE ヘッダ詳細】Compact No-Code FEC の場合(TOI>0, CP=0)の例(UDP/IPv4)です。→ http://twitpic.com/1kar6j/full #isdbtmm

0147: 【ISDB-Tmm の FLUTE ヘッダ詳細】LDPC Staircase の場合(TOI>0, CP=3)の例(G=1, UDP/IPv4)です。→ http://twitpic.com/1kaqxd/full #isdbtmm

0146: 【ISDB-Tmm の FLUTE ヘッダ詳細】FDT(XML)の場合(TOI=0)の例(UDP/IPv4)です。→ http://twitpic.com/1kaqj7/full #isdbtmm

0145: 「LDPC Staircase の勘どころメモ」のコメント欄に、LDPC Staircase 復号(Decode)の実装(コーディング)時の注意事項を追記しました。→ http://bit.ly/9MwePU #isdbtmm

0144: 総務省 報道資料「携帯端末向けマルチメディア放送の委託放送業務の認定に係る制度整備に関する考え方等についての意見募集及び参入希望調査の実施」→ http://bit.ly/cGybgA #isdbtmm

0143: RFC4326( http://www.ietf.org/rfc/rfc4326.txt )の4.2章とAppendix Bによると、ULE の Length は Type Field 以降(含まない)~ CRC-32 まで(含む)のバイト数となる。 #isdbtmm

0142: 【CEATEC JAPAN 2010】「みんなの放送局」を目指すmmbi二木社長→ http://bit.ly/b6Q6er 「様々な人が色々なビジネスモデルを考え、参画・関与できるマルチメディア放送」という意味だと感じます。 #isdbtmm

0141: 「テレビジョン放送」は「静止し、又は移動する事物の瞬間的影像及びこれに伴う音声その他の音響を送る放送(文字、図形その他の影像(音声その他の音響を伴うものを含む。)又は信号を併せ送るものを含む。)」と定義されている。→ http://bit.ly/aQtuF5 #isdbtmm

0140: 【平成22年総務省令第51号より】電波法施行規則第二条第一項第二十八号の四の二 「マルチメディア放送」とは、二値のデジタル情報を送る放送であつて、テレビジョン放送に該当せず、かつ、他の放送の電波に重畳して行う放送でないものをいう。 #isdbtmm

0139: 「マルチメディア放送を行う放送局のうち標準方式第三章の二第二節に規定する放送」とは、V-High帯を使用する MediaFLO 方式による放送のことです。→ http://bit.ly/avhrGf #isdbtmm

0138: 「マルチメディア放送を行う放送局のうち標準方式第三章の二第一節に規定する放送」とは、V-High帯を使用する ISDB-Tmm 方式による放送のことです。→ http://bit.ly/avhrGf #isdbtmm

0137: Wikipedia の「マルチメディア放送 (企業)」(mmbi)のページです。→ http://bit.ly/ciqFO0 #mmbi #isdbtmm

0136: 平成22年4月23日総務省告示第174号「極微小電力でマルチメディア放送を行う放送局の設備の条件等を定める件」→ PDF形式 http://bit.ly/b1vpPm in http://bit.ly/admrj0 #isdbtmm

0135: 「CEATEC JAPAN 2010への出展とmmbiスペシャルサイトの開設について」→ http://mmbi.co.jp/?p=337 今回は「蓄積型放送」(ファイルキャスティング)も実演とのこと。 #mmbi #isdbtmm

投稿: 本人 | 2010年11月23日 (火) 13:19

《任意のファイルからTSパケットに分解する手順》

ISDB-T マルチメディアフォーラム
ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版
第十一編 マルチメディア放送 蓄積型放送の運用
一般公開版 (2010年11月29日版) より

【ファイルキャスティングの送出側】(ISDB-Tmm の場合)

(1) 「任意ファイル」→「固定長ブロック分割」→(FEC追加)→ 「FLUTE(LCT, FEC)」→「UDP/IP」→(ROHCによるヘッダ短縮)→「ULEによるカプセル化」→「IP over MPEG-2 TS によるTSパケット化」

(2) 「固定長ブロック分割」(A_large と A_small)やFEC(一方向誤り訂正符号)の1つである LDPC Staircase の詳細です。→ http://bit.ly/9thgUW

(3) (FEC追加)と括弧しているのは、FDT(XML表現のファイル送付形式)や極小サイズのファイル等は誤り訂正(消失訂正)の修復パケットを送らない場合があるため。

(4) (ROHCによるヘッダ短縮)と括弧しているのは、直接 UDP/IPv4 で送る場合もあるため。

 ROHCを使用する場合、一例ですが、送信元IPアドレスを 0.0.0.0、宛先IPアドレスを 255.255.255.255、送信元・宛先UDPポート番号を 65528 といったように、固定的にマッピングされた CID(この場合『2』)を用意して、常に2バイトに短縮された UO-0 ヘッダで伝送できる仕様となっています。
 ROHC UDP U-mode 伝送でも上記のように常に UO-0 パケットを使用するのではなく、受信側の状況を予測等して、IR / IR-DYN / UO-0 ヘッダを切り替えて伝送するモードもあります。
 ROHCによる非圧縮伝送(Profile=0x0000)は使用しませんが、ROHCを使わない純粋な IPv4 パケットのヘッダでの伝送は使用可能です。

(5) 「ULEによるカプセル化」のパケット種別(Type Field)に指定する EtherType は、「0x0800」(IPv4)と「0x22F1」(ROHC)があります。

投稿: 本人 | 2010年12月19日 (日) 20:45

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その12)。

0166: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」によると、蓄積コンテンツ補完の際の通信補完は、LDPC Staircase の場合は、1回の再送要求で復号できない場合は、再度 再送要求してもよい仕様である。 #isdbtmm

0165: 【続き(通信補完)】「Range: bytes= 0-299, 1200-1499, 2400-2699」(シンボル長:E=300の例)といった HTTP Byte Range Request で補完サーバに要求する仕様である。 #isdbtmm

0164: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」によると、蓄積コンテンツ補完の際の通信補完は、SBN と ESI を指定するのではなく、【続く(通信補完)】 #isdbtmm

0163: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」によると、推奨値ではあるが、各ソースブロックのソースシンボル数の上限を10000とする旨の記述がある。 #isdbtmm

0162: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」によると、推奨値ではあるが、ソースシンボル数が100以下の場合は、LDPC Staircase ではなく、Compact No-Code FEC を使用する旨の記述がある。 #isdbtmm

0161: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」によると、推奨値ではあるが、符号化シンボル長(E)は、1バイト以上1200バイト以下との旨の記述がある。 #isdbtmm

0160: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」によると、コンテンツ長(Content-Length)は、「4GB まで対応する。」との記述がある。 #isdbtmm

0159: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」によると、ULE ヘッダ(RFC4326)内の宛先MACアドレス(Destination Address)は運用しない仕様となる。すなわち、先頭の宛先フラグ(D)が「D=1」となる。 #isdbtmm

0158: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」によると、UDP ヘッダ内のチェックサムは、「0」(運用しない仕様)となる。 #isdbtmm

0157: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」によると、LDPC Staircase のシンボル多重化数(G)は、「G=1」(1シンボルを1パケットで伝送する仕様)となる。 #isdbtmm

0156: 【続き】ROHC に関しては、RFC3095 や訂正・追補版の RFC4815 は参考程度にとどめ、将来的に ARIB技術資料(TR)になる予定の「ISDB-Tmm運用規定」(2010年11月29日現在は案段階)を主体に読まないと、混乱をきたすでしょう。 #isdbtmm

0155: 【続き】UDP/IP部分のヘッダは、(1)「純粋なUDP/IPv4ヘッダ」、(2)「IR/IR-DYN/UO-0ヘッダを適時切り替えるROHC UDP U-mode」、(3)「常にUO-0ヘッダを使用するROHC UDP U-mode」、があります。【続く】 #isdbtmm

0154: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」によると、結局 ISDB-Tmm では、「TLV式のヘッダ短縮」を採用せず、「ROHCによるヘッダ短縮」を採用することになりました。【続く】 #isdbtmm

0153: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」に基づき、【ファイルキャスティング関連】内を修正しました。→ http://bit.ly/difWBo #isdbtmm

0152: RFC4326 の ULE ヘッダ内にある Type Field(パケット種別)に設定する ROHC(RFC3095 と訂正・追補版の RFC4815)用の EtherType 値「0x22F1」が採番されました。→ http://bit.ly/gVfoAW #isdbtmm

0151: 総務省 報道資料「携帯端末向けマルチメディア放送の委託放送業務の認定に係る制度整備に関する考え方等に対する意見及び参入希望調査の結果の公表」→ http://bit.ly/eFKlHX #isdbtmm

0150: 「移動体・携帯端末向け地上マルチメディア放送のセグメント連結伝送方式 標準規格 ARIB STD-B46 1.0版」(2010年11月05日 策定)→ http://bit.ly/eZsIJq (PDF形式) in http://bit.ly/4CXfmB #isdbtmm

0149: 「LDPC Staircase の勘どころメモ」のコメント欄に、ファイルサイズがシンボル長で割り切れない場合の、最終ソースシンボルの取り扱いについて追記しました。→ http://bit.ly/enCuA9 #isdbtmm

投稿: 本人 | 2010年12月21日 (火) 12:25

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その13)。

0173: @nikkeibpITpro 【続き】 http://bit.ly/fSiXx7 表2のリアルタイム型放送に、352x480p 30fpsの 525HHRも追加されたようです。→ http://bit.ly/gOfyD9 「正誤表(2011年1月27日版)」より #isdbtmm

0172: ITpro「V-High帯全国向けマルチメディア放送(ISDB-Tmm)のサービスの仕組み(第1回)」→ http://bit.ly/fSiXx7 #isdbtmm

0171: 「ISDB-Tmm運用規定(案)文章CD-ROM 2010.11.29版」の「正誤表(2011年1月25日版)」によると、推奨値ではあるが、各ソースブロックのソースシンボル数の上限を2000(以前は10000)とする旨の記述がある。 #isdbtmm

0170: 「IPDCフォーラム開催、携帯向け放送の展望など紹介」→ http://bit.ly/gIQ42D V-Low と V-High のマルチメディア放送について、取り組み等がまとめられています。 #isdbtmm

0169: IR と IR-DYN パケットの 8-bit CRC は、CRC 領域を 0 に設定してから、ISDB-Tmm の場合は、Add-CID から Dynamic Chain までのデータで計算します(RFC3095 の 5.9.1 章より)。 #isdbtmm

0168: UDP/IPv4 の 3-bit と 7-bit CRC を求めるサンプルコードです(RFC3095 の 5.9.2 章より)。32-bit と 8-bit CRC は、扱うデータが異なります。→ http://bit.ly/hlZwhA (perl コード) #isdbtmm

0167: RFC4815 にある ROHC(RFC3095) の CRC の perl サンプルコードを UDP/IPv4 ヘッダ用に改良しました。→ http://bit.ly/hlZwhA (perl コード) #isdbtmm

投稿: 本人 | 2011年2月15日 (火) 14:13

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その14)。

0182: 「セグメント連結伝送方式による地上マルチメディア放送運用規定 第3分冊 技術資料 ARIB TR-B33 1.0版」(2011年03月28日 策定)→ http://bit.ly/gzdKtE (PDF形式) in http://bit.ly/6wZ8cn #isdbtmm

0181: 「セグメント連結伝送方式による地上マルチメディア放送運用規定 第2分冊 技術資料 ARIB TR-B33 1.0版」(2011年03月28日 策定)→ http://bit.ly/exHDGW (PDF形式) in http://bit.ly/6wZ8cn #isdbtmm

0180: 「セグメント連結伝送方式による地上マルチメディア放送運用規定 第1分冊 技術資料 ARIB TR-B33 1.0版」(2011年03月28日 策定)→ http://bit.ly/g9ONCi (PDF形式) in http://bit.ly/6wZ8cn #isdbtmm

0179: 「セグメント連結伝送方式による地上マルチメディア放送用受信装置(望ましい仕様) 標準規格 ARIB STD-B53 1.0版」(2011年03月28日 策定)→ http://bit.ly/eInR1t (PDF) in http://bit.ly/4CXfmB #isdbtmm

0178: 「セグメント連結伝送方式による地上マルチメディア放送の伝送方式 標準規格 ARIB STD-B46 1.1版」(2011年03月28日 改定)→ http://bit.ly/hBQZxg (PDF形式) in http://bit.ly/4CXfmB #isdbtmm

0177: ITpro「V-High帯全国向けマルチメディア放送(ISDB-Tmm)のサービスの仕組み(第3回)―マルチメディア放送のデータ放送と蓄積型放送―」→ http://bit.ly/gyBFfj #isdbtmm

0176: 【続き】EPG/ECGメタデータサービスの service_id が 0x0001~0x0FFF の場合、当日~2日目までの番組情報となり、0x1000~0x1FFF の場合、3~8日目までの番組情報となるようです。 #isdbtmm

0175: 【続き】 http://bit.ly/eMjAsI 表1のEPG/ECGメタデータサービスは、1セグメント放送で送出してもよい仕様になったようです。→ http://bit.ly/gOfyD9 「正誤表(2011年1月25日版)」より。【続く】 #isdbtmm

0174: ITpro「V-High帯全国向けマルチメディア放送(ISDB-Tmm)のサービスの仕組み(第2回)―マルチメディア放送のサービス情報とメタデータ仕様―」→ http://bit.ly/eMjAsI 【続く】 #isdbtmm

投稿: 本人 | 2011年4月15日 (金) 12:19

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その15)。

0188: 「『マルチメディア放送』って、なん(何)や?」と思ったとき、ぱっと理解したいときは、このページを最初から最後まで読むと良いでしょう。ただし、細かい技術的な話は、書いていないです。→ http://p.tl/f-Ib (Wikipedia) #isdbtmm

0187: ISDB-T マルチメディアフォーラム「ISDB-Tmm運用規定の公開について」→ http://www.isdb-t.jp/2011/05/isdb-tmm-kitei-koukai.html #isdbtmm

0186: 「NTT技術ジャーナル( http://p.tl/tYnq )に掲載されました。」→ http://mmbi.co.jp/2011/05/557/ 「ARIB TR-B33」( http://p.tl/UGfo から入手可能)等の まとめとして読むと良いですね。 #isdbtmm

0185: 左行列にUEP機能を付加した LDPC Staircase のパリティチェック行列を表示する Excel ファイルのリンクがあります。→ http://t.co/iEMWksq 「ARIB TR-B33 1.0版」のものと、その修正版(私の考察結果)があります。 #isdbtmm

0184: LDPC Staircase のパリティチェック行列を表示する Excel ファイルのリンクがあります。→ http://bit.ly/aRa8KZ ISDB-Tmm の場合は、N1=3(推奨値), G=1(仕様)となります。 #isdbtmm

0183: ITpro「V-High帯全国向けマルチメディア放送(ISDB-Tmm)のサービスの仕組み(最終回)―アクセス制御とコンテンツ保護―」→ http://bit.ly/efHa51 #isdbtmm

投稿: 本人 | 2011年5月31日 (火) 10:10

上記の【0186: 「NTT技術ジャーナル( http://p.tl/tYnq )に掲載されました。」→ …】にある http://mmbi.co.jp/2011/05/557/ は、オフィシャルサイトのリニューアルに伴い http://mmbi.co.jp/news/2011/05/11/0063.html に URL が変更されているな。

投稿: 本人 | 2011年6月10日 (金) 08:35

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その16)。

0198: 左行列にUEP機能を付加した LDPC Staircase のパリティチェック行列を表示する Excel ファイルのリンクがあります。→ http://t.co/iEMWksq 後半のリンクが、1.0版の改定版である「ARIB TR-B33 1.1版」用です。 #isdbtmm

0197: 「セグメント連結伝送方式による地上マルチメディア放送運用規定 第3分冊 技術資料 ARIB TR-B33 1.1版」(2011年07月07日 改定)→ http://bit.ly/pRhyiF (PDF形式) in http://bit.ly/6wZ8cn #isdbtmm

0196: 「セグメント連結伝送方式による地上マルチメディア放送運用規定 第2分冊 技術資料 ARIB TR-B33 1.1版」(2011年07月07日 改定)→ http://bit.ly/o2hXkX (PDF形式) in http://bit.ly/6wZ8cn #isdbtmm

0195: 「セグメント連結伝送方式による地上マルチメディア放送運用規定 第1分冊 技術資料 ARIB TR-B33 1.1版」(2011年07月07日 改定)→ http://bit.ly/oJmlAL (PDF形式) in http://bit.ly/6wZ8cn #isdbtmm

0194: 2011年06月30日「放送法改正により、委託放送事業者は移動受信用地上基幹放送事業者、受託放送事業者は基幹放送局提供事業者となる。」→ http://p.tl/lcQF (Wikipedia『マルチメディア放送』より) #isdbtmm

0193: マルチメディア放送(V-High)の現状を把握できる記事です。→ アナログ放送終了で立ち上がる「モバキャス」の中身とは? - デジタル - 日経トレンディネット http://t.co/aEyi3YQ via @Nikkei_TRENDY #isdbtmm

0192: 【続き】「基幹放送局提供事業者」=「受託放送事業者」(ハード側)、「認定基幹放送事業者」=「委託放送事業者」(ソフト側)、ということです。 #isdbtmm

0191: 株式会社ジャパン・モバイルキャスティング(略称「Jモバ」)「ソフト事業(認定基幹放送事業)に関する情報」→ http://www.j-mobilecasting.com/entrust/ #isdbtmm

0190: 株式会社ジャパン・モバイルキャスティング(略称「Jモバ」) NEWS【V-High マルチメディア放送のネーミング「モバキャス」の決定について】→ http://www.j-mobilecasting.com/news/2011/07/14/58/ #isdbtmm

0189: mmbi ニュース【V-High マルチメディア放送のネーミング「モバキャス」の決定について】→ http://mmbi.co.jp/news/2011/07/14/0094.html #isdbtmm

投稿: 本人 | 2011年7月26日 (火) 19:30

Twitter のハッシュタグ「#isdbtmm」での検索結果です(その17)。

0212: あとは、ARIB TR-B33 1.2版の各分冊の改定履歴を読めばよいが、サービスイン前なので、まだ流動的な箇所が多い印象を持つ。 #isdbtmm #モバキャス

0211: ARIB TR-B33 1.2版の第10編に付録5「BiM エンコード規則」(EPG/ECGメタデータ用XMLスキーマと伝送制御制御メタデータ用XMLスキーマを包む Wrapperスキーマ等の解説)が追加された。 #isdbtmm #モバキャス

0210: 伝送制御メタデータのファイル拡張子は、.fci(XML 形式)、.bfci(BiM 形式)、.bfcix(MIME multipart 形式)となる。(ARIB TR-B33 1.2版 第11編 2.2.4『メタデータ識別方法』より) #isdbtmm #モバキャス

0209: EPG/ECGメタデータのファイル拡張子は、.ecg(XML 形式)、.becg(BiM 形式)、.becgx(MIME multipart 形式)となる。(ARIB TR-B33 1.2版 第11編 2.2.4『メタデータ識別方法』より) #isdbtmm #モバキャス

0208: ROHC の UO-0 ヘッダは、IPv4 では2バイトだが、IPv6 では4バイト(UDP Checksum の2バイト追加)となる。(ARIB TR-B33 1.2版 第11編 2.1.8『ROHC 伝送運用』より) #isdbtmm #モバキャス

0207: ROHC の UO-0 を常に使用する場合の送信元アドレスと宛先アドレスに IPv6 のアドレスも追加された。(ARIB TR-B33 1.2版 第11編 2.1.7『UDP/IP 伝送運用』より) #isdbtmm #モバキャス

0206: ULEヘッダのパケット種別は、0x0800(IPv4)、0x86DD(IPv6)、0x22F1(ROHC)となる。(ARIB TR-B33 1.2版 第11編 2.1.9『ULE 伝送運用』より) #isdbtmm #モバキャス

0205: 2011年12月06日の改定で、ISDB-Tmm 方式における蓄積型放送関連の改定箇所の把握は、まず ARIB STD-B45 2.1版の改定履歴を読むべきですね(理解度UPと強制力が『省令・告示 > STD > TR』の為)。 #isdbtmm #モバキャス

0204: 限定受信方式識別(CA_system_id)に、ISDB-Tmm 方式の地上マルチメディア放送向けである ConPas 方式(0x000F)を追加。(ARIB STD-B10 5.0版より) #isdbtmm #モバキャス

0203: データ符号化方式識別(data_component_id)に、ISDB-Tmm 方式の地上マルチメディア放送向け字幕・文字スーパー符号化方式(0x001C)を追加。(ARIB STD-B10 5.0版より) #isdbtmm #モバキャス

0202: データ符号化方式識別(data_component_id)に、ISDB-Tmm 方式の地上マルチメディア放送向けマルチメディア符号化方式(Xプロファイル)(0x001B)を追加。(ARIB STD-B10 5.0版より) #isdbtmm #モバキャス

0201: 「セグメント連結伝送方式による地上マルチメディア放送運用規定 第3分冊 技術資料 ARIB TR-B33 1.2版」(2011年12月06日改定) http://bit.ly/uXfPHQ (PDF) in http://bit.ly/6wZ8cn #isdbtmm #モバキャス

0200: 「セグメント連結伝送方式による地上マルチメディア放送運用規定 第2分冊 技術資料 ARIB TR-B33 1.2版」(2011年12月06日改定) http://bit.ly/tyeMJs (PDF) in http://bit.ly/6wZ8cn #isdbtmm #モバキャス

0199: 「セグメント連結伝送方式による地上マルチメディア放送運用規定 第1分冊 技術資料 ARIB TR-B33 1.2版」(2011年12月06日改定) http://bit.ly/tsrY2g (PDF) in http://bit.ly/6wZ8cn #isdbtmm #モバキャス

投稿: 本人 | 2011年12月22日 (木) 12:02

上記の【0211: ARIB TR-B33 1.2版の第10編に付録5「BiM エンコード規則」…】で、「伝送制御メタデータ」を「伝送制御制御メタデータ」と制御をダブって書いてしまったな。

投稿: 本人 | 2011年12月23日 (金) 22:43

ずっと使い続けてきて、とっても良いソフトであることなどから、いつか、Ace/Winの後継版が出ることを期待します。
sun

投稿: スギ | 2013年2月10日 (日) 21:56

コメントを書く



(ウェブ上には掲載しません)