(57)【要約】【課題】  バッファあふれが生じた場合でも、データ受信機側でデコード処理にかかる異常を抑制することのできるデータ送信機を提供する。【解決手段】  データ送信機であるワイヤレスＴＶチューナは、ある所定のデータ構造単位を持つストリームデータをデータ受信機であるＴＶに対して送信する。ストリームバッファの未送信データ記憶領域からデータを読み込む際に、同じくストリームバッファの送信中データ記憶領域にそのデータ構造単位のデータを格納しておき（ステップ８１）、このデータは、送信が完了（ステップ８４のＹｅｓ）するまで保持する。これにより、例え通信が一時的に中断されても、デコード側にそのデータ構造単位全体のデータを送ることが可能となり、デコード処理での異常発生を抑制することが可能となる。【選択図】      図８
2006211602.tif 000002
【特許請求の範囲】
【請求項１】
所定のデータ構造単位を持つストリームデータをデータ受信機にストリーム型データ伝送するデータ送信機において、
前記ストリームデータを供給するデータ供給手段と、
前記データ供給手段により供給される前記ストリームデータを一時的に蓄積するバッファと、
前記バッファに蓄積された前記ストリームデータを読み出し、前記データ受信機に送信する通信手段と
を備え、
前記バッファは、前記ストリームデータの前記データ供給手段から供給されるデータ量が前記バッファの空き容量を超過した際に、前記通信手段から送信途中の前記データストリームの前記所定のデータ構造単位のデータの内少なくとも前記通信手段から未送信のデータを、前記通信手段から送信されるまで保持すること
を特徴とするデータ送信機。
【請求項２】
前記通信手段は、前記データ受信機への前記ストリームデータの伝送の中断後に伝送を再開する際に、前記バッファに記憶された前記未送信のデータを前記データ受信機へ送信すること
を特徴とする請求項１記載のデータ送信機。
【請求項３】
前記バッファは、蓄積する前記ストリームデータのデータ量が前記バッファの空き容量を超過した際に、前記ストリームデータを前記所定のデータ構造単位で廃棄すること
を特徴とする請求項２記載のデータ送信機。
【請求項４】
請求項１乃至請求項３記載のデータ送信機において、
前記ストリームデータの種類に基づいて、前記データ構造単位を判断するデータ構造単位判断手段
をさらに備えることを特徴とするデータ送信機。
【請求項５】
前記データストリームの種類がＤＴＣＰ−ＩＰであり、
前記所定のデータ構造単位は、前記ＤＴＣＰ−ＩＰで規定されるＰＣＰであること
を特徴とする請求項１乃至請求項３記載のデータ送信機。
【請求項６】
前記データ供給手段が供給するストリームデータは、ＴＶチューナから受信する映像データであることを特徴とする請求項１乃至請求項３記載のデータ送信機。
【請求項７】
所定のデータ構造単位を持つストリームデータをデータ受信機にストリーム型データ伝送するデータ送信機を制御するプログラムにおいて、
前記ストリームデータを供給するデータ供給機能と、
前記データ供給機能により供給される前記ストリームデータを一時的に蓄積するバッファ機能と、
前記バッファ機能により蓄積された前記ストリームデータを読み出し、前記データ受信機に送信する通信機能と
を備え、
前記バッファ機能は、前記ストリームデータの前記データ供給機能により供給されるデータ量が前記バッファ機能の持つの空き容量を超過した際に、前記通信機能による送信途中の前記データストリームの前記所定のデータ構造単位のデータの内少なくとも前記通信機能により未送信のデータを、前記通信機能により送信されるまで保持すること
を特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば動画データ等のストリームデータを送信するデータ送信機、及びこのデータ送信機を制御するプログラムに関する。
【背景技術】
【０００２】
現在、インターネットやＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等、様々な通信媒体を介した画像、音声データ等のデータ転送が盛んに行われている。特に近年のネットワークの伝送速度の向上に伴い、ストリーム型の伝送方式が普及しつつある。ストリーム型伝送方式は、送信機から受信端末にデータを転送するのと並行して、受信データの再生処理を実行するものである。このとき、例えば送信機側では、画像データのＭＰＥＧ圧縮処理により作成されるＭＰＥＧストリームを一度バッファに格納した上でＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットとしてこれを送信し、受信端末側ではＩＰパケットとして受信したＭＰＥＧストリームをデコードに必要なデータとなるまでバッファリングしてこれを順次デコードする。このような処理により、受信端末側でデータを受信してから再生するまでの遅延が少なくなり、ほぼリアルタイムでの再生が可能となる（例えば、特許文献１参照）。
【０００３】
【特許文献１】特開２００３―１６９０４０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、例えば伝送している画像データがテレビチューナから受信した映像データ等の実時間処理が必要なデータであり、且つ通信が切断される等の事情により正常にデータを送信できない場合には、送信機側でバッファあふれが生じる。このようなバッファあふれが生じた際には、一般にバッファに格納された古いデータから順に破棄する処理が行われている。これにより通信が再開した際に新たなデータから送信できるようになるが、例えばＭＰＥＧ２−ＰＳ（Ｐｒｏｇｒａｍ  Ｓｔｒｅａｍ）等のストリームデータのデータ構造が破壊されることとなり、受信端末側ではデコードに異常をきたす可能性がある。尚、特許文献１では、ＩＰパケットの損失が生じた場合に、この再送を要求することによりデータ再生の劣化を防ぐ手法について提案されているが、送信機側でバッファあふれが生じた場合については考慮されていない。
【０００５】
そこで本発明は、バッファあふれが生じた場合でも、データ受信機側でデコード処理にかかる異常を抑制することのできるデータ送信機を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するために、本発明のデータ送信機は、所定のデータ構造単位を持つストリームデータをデータ受信機にストリーム型データ伝送するデータ送信機において、前記ストリームデータを供給するデータ供給手段と、前記データ供給手段により供給される前記ストリームデータを一時的に蓄積するバッファと、前記バッファに蓄積された前記ストリームデータを読み出し、前記データ受信機に送信する通信手段とを備え、前記バッファは、前記ストリームデータの前記データ供給手段から供給されるデータ量が前記バッファの空き容量を超過した際に、前記通信手段から送信途中の前記データストリームの前記所定のデータ構造単位のデータの内少なくとも前記通信手段から未送信のデータを、前記通信手段から送信されるまで保持することを特徴とする。
【０００７】
本発明のプログラムは、所定のデータ構造単位を持つストリームデータをデータ受信機にストリーム型データ伝送するデータ送信機を制御するプログラムにおいて、前記ストリームデータを供給するデータ供給機能と、前記データ供給機能により供給される前記ストリームデータを一時的に蓄積するバッファ機能と、前記バッファ機能により蓄積された前記ストリームデータを読み出し、前記データ受信機に送信する通信機能とを備え、前記バッファ機能は、前記ストリームデータの前記データ供給機能により供給されるデータ量が前記バッファ機能の持つの空き容量を超過した際に、前記通信機能による送信途中の前記データストリームの前記所定のデータ構造単位のデータの内少なくとも前記通信機能により未送信のデータを、前記通信機能により送信されるまで保持することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、バッファあふれが生じた場合でも、データ受信機側でデコード処理にかかる異常を抑制することのできるデータ送信機を提供することができる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明のデータ送信機及びプログラムについて、図面を参照しながら説明する。
【実施例１】
【００１０】
図１は、本発明の実施例にかかるワイヤレスＴＶチューナ（データ送信機）が使用される映像通信システムの構成を示す図である。図１に示すように本映像通信システムは、ＬＡＮ１と、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）１０と、ＰＣ１０にＴＶチューナからの映像データを送信するワイヤレスＴＶチューナ２０と、ＰＣ１０で視聴させる映像データを格納するＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）２と、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）を再生しＰＣ１０で視聴させるＤＶＤプレーヤ３とから構成される。即ちＰＣ１０は、ＬＡＮ１を介して、ワイヤレスＴＶチューナ２０からの映像、ＨＤＤ２からの映像、及びＤＶＤプレーヤ３からの映像を視聴することができる。以下、ワイヤレスＴＶチューナ２０及びＰＣ１０について説明を行う。
【００１１】
図２は、ワイヤレスＴＶチューナ２０及びＰＣ１０の構成を示す構成図である。先述した通り、ワイヤレスＴＶチューナ２０とＰＣ１０とは、ＬＡＮ１により接続されている。
【００１２】
ワイヤレスＴＶチューナ２０は、制御部２１と、送信するデータに関する情報を管理するコンテンツ情報管理部２２（データ構造単位判断手段）と、地上波アナログ放送、ＢＳデジタル放送、及び地上波デジタル放送を受信するチューナ２３と、受信した映像データを符号化するエンコーダ２４（データ供給手段）と、エンコーダ２４から供給されるデータを一時的に格納するストリームバッファ２５と、ＰＣ１０に対してデータを送信する通信部２６とを有する。それぞれ、コンテンツ情報管理部２２、チューナ２３、エンコーダ２４、ストリームバッファ２５、通信部２６は、それぞれ制御部２１に接続される。
【００１３】
制御部２１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）及びメモリから構成されており、ワイヤレスＴＶチューナ２０全体の動作を統括制御する。
【００１４】
コンテンツ情報管理部２２は、コンテンツ情報２２ａ及びメディア情報２２ｂを持ち、通信部２６からＰＣ１０に向けて送信するそれぞれのデータの情報を管理する。図３に、コンテンツ情報２２ａ及びメディア情報２２ｂの例を示す。
【００１５】
図３（ａ）は、コンテンツ管理部２２が持つコンテンツ情報の例を示す図である。コンテンツ情報は、ワイヤレスＴＶチューナ２０から配信可能なコンテンツデータのコンテンツ名、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）、ＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎ）  ＴＹＰＥ、メディアフォーマットに関する情報を持つ。尚、ワイヤレスＴＶチューナ２０は、地上波アナログ放送、ＢＳデジタル放送、及び地上波デジタル放送に対応しているので、コンテンツ情報２２ａではそれぞれのチャネルに対する情報を格納している。このようなコンテンツ情報は、ＨＤＤ２、ＤＶＤプレーヤ３等でも有している。
【００１６】
コンテンツ名は、ユーザに提示するコンテンツデータの名前である。図３（ａ）の例では、「アナログ１ｃｈ」「ＢＳデジタル１ｃｈ」等のコンテンツ名が割り当てられている。このコンテンツ名は、ＰＣ１０の表示部１４に表示させることができ、ユーザはこれをキーにコンテンツを選択することができる。
【００１７】
ＵＲＬは、ＰＣ１０からそれぞれのコンテンツデータへのアクセスを受ける際に使用されるＵＲＬである。例えばアナログ１ｃｈにはＵＲＬ「ｈｔｔｐ：／／１９２．１６８．１．１／Ａ１ｃｈ．ｍｐｇ」が、ＢＳデジタル１ｃｈにはＵＲＬ「ｈｔｔｐ：／／１９２．１６８．１．１／ＢＳＤ１ｃｈ．ｍｐｇ」が割り当てられている。
【００１８】
ＭＩＭＥ−ＴＹＰＥは、ＰＣ１０にメディアの種類を知らせるための識別子の役割を果たす。例えば、図３（ａ）のアナログ１ｃｈのようにＭＩＭＥ−ＴＹＰＥが「ｖｉｄｅｏ／ｍｐｅｇ」である場合にはメディアの種類がＭＰＥＧであることが、ＢＳデジタル１ｃｈのように「ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｄｔｃｐ１」である場合にはメディアの種類がＤＴＣＰ−ＩＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔｓ  Ｐｒｏｔｅｃｔｉｏｎ  ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）であることがわかる。ワイヤレスＴＶチューナ２０がＰＣ１０にコンテンツデータを送信する前に、このＭＩＭＥ−ＴＹＰＥをＰＣ１０に通知する。
【００１９】
メディアフォーマットは、当該コンテンツデータをエンコードするメディアフォーマットを定めるものである。図３（ａ）の例では、例えばアナログ１ｃｈ等のアナログ放送はＭＰＥＧ２−ＰＳに、ＢＳデジタル１ｃｈ等のデジタル放送はＤＴＣＰ−ＩＰにエンコードされる。
【００２０】
図３（ｂ）は、コンテンツ管理部２２が持つメディア情報２２ｂの例を示す図である。メディア情報２２ｂは、それぞれのメディアフォーマットに対する、構造単位（所定のデータ構造単位）を示している。図３（ｂ）の例では、ＭＰＥＧ１及びＭＰＥＧ２−ＰＳの構造単位はパックであり、ＤＴＣＰの構造単位がＰＣＰ（Ｐｒｏｔｅｃｔｅｄ  Ｃｏｎｔｅｎｔ  Ｐａｃｋｅｔｓ）であることがわかる。尚この構造単位は、ストリームバッファ２５がそれぞれのコンテンツデータを管理する単位となる。
【００２１】
再び図２の説明に戻ると、チューナ２３は、テレビ放送信号を受信するチューナである。チューナ２３は、アナログ地上波放送、ＢＳデジタル放送、及び地上波デジタル放送を受信することが可能である。
【００２２】
エンコーダ２４は、チューナ２３で受信したテレビ放送信号を所定のメディアフォーマットに符号化する。エンコーダ２４は、コンテンツ情報管理部２２の持つメディア情報２２ａで規定されるメディアフォーマットに従い、先述のように、アナログ地上波放送はＭＰＥＧ２−ＰＳに、ＢＳデジタル放送及び地上波デジタル放送はＤＴＣＰ−ＩＰに符号化される。
【００２３】
ストリームバッファ２５は、エンコーダ２４が符号化したコンテンツデータを、一時的に格納するバッファである。ストリームバッファは、コンテンツ情報管理部２２ｂの持つメディア情報に従い、コンテンツデータのメディアフォーマットによって管理方法を変化させる。具体的には、メディアフォーマットがＭＰＥＧ２−ＰＳであればパック単位で、ＤＴＣＰ−ＩＰであればＰＣＰ単位でデータを管理する。それぞれの詳細については、後述する。
【００２４】
通信部２６は、ワイヤレスＴＶチューナ２０の通信インタフェースである。通信部２６は、ストリームバッファ２５から読み込んだコンテンツデータを、ＩＰパケットとしてＬＡＮ１を介してＰＣ１０に向けて送信する。このとき通信部２６は、ＰＣ１０に向けて送信を終えたデータのデータ量を、制御部２１に通知する。
【００２５】
ＰＣ１０は、通信部１１、バッファ１２、デコーダ１３、表示部１４から構成される。尚、図２には図示していないが、ＰＣ１０は、全体の動作を統括制御する制御部やユーザがコンテンツを選ぶための操作部等も有する。
【００２６】
通信部１１は、ワイヤレスＴＶチューナ２０からコンテンツデータを受信するための通信インタフェースである。通信部１１は、ＩＰパケットとしてコンテンツデータを受信し、それをバッファ１２に渡す。
【００２７】
バッファ１２は、デコードに必要なデータ量となるまで、通信部１１から受信したコンテンツデータを一時的に格納する。デコーダ１３は、バッファ１２に格納されたコンテンツデータが、デコードに必要なデータ量に達すれば、これを順次デコードする。例えば、コンテンツデータのメディアフォーマットがＭＰＥＧ２−ＰＳである場合には、デコーダ１３は一般にパック単位で、ＤＴＣＰ−ＩＰである場合にはＰＣＰ単位でデコードするので、バッファ１２に格納されたデータがこれらの構造単位に達すれば、順次デコードしていく。表示部１４は、コンテンツデータ１３をデコーダ１３がデコードして得られる映像を表示する。
【００２８】
次に、ワイヤレスＴＶチューナ２０からＰＣ１０に向けてコンテンツデータを送信する際の、制御部２１で実行されるプログラムの流れについて、アナログ１ｃｈを伝送する場合を例に説明を行う。図４は、ワイヤレスＴＶチューナ２０がＰＣ１０に向けてアナログ１ｃｈの伝送を開始するまでのプログラムの処理の流れを示すフローチャートである。
【００２９】
まず、ワイヤレスＴＶチューナ２０は、通信部２６でＰＣ１０からのデータ要求を受信する（ステップ４１）。このとき、ＰＣ１０からはＵＲＬによって各コンテンツを指定される。制御部２１は、ＰＣ１０からアクセスを受けるＵＲＬとコンテンツ情報管理部２２の持つコンテンツ情報２２ａを参照することにより、各コンテンツを特定することができる。より具体的には、図３（ａ）の例であれば、ＵＲＬ「ｈｔｔｐ：／／１９２．１６８．１．１／Ａ１ｃｈ．ｍｐｇ」に対してＰＣ１０からアクセスを受ければ、コンテンツ情報２２ａを参照することによりアナログ１ｃｈを伝送すれば良い事がわかる。
【００３０】
次に、制御部２１は、当該コンテンツデータを伝送するのに必要となるＭＩＭＥ−ＴＹＰＥやメディアフォーマット、構造単位に関する情報を取得する（ステップ４２）。アナログ１ｃｈであれば、制御部２１はコンテンツ情報２２ａを参照することにより、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）で伝送する場合のＭＩＭＥ−ＴＹＰＥは「ｖｉｄｅｏ／ｍｐｅｇ」であり、エンコードするメディアフォーマットはＭＰＥＧ２−ＰＳであることがわかる。さらに、メディア情報２２ｂを参照することにより、制御部２１はＭＰＥＧ２−ＰＳの構造単位がｐａｃｋであることがわかる。
【００３１】
ここで得られた情報を元に、プログラムはＭＩＭＥ−ＴＹＰＥ（ここでは「ｖｉｄｅｏ／ｍｐｅｇ」）を含むＨＴＴＰヘッダを生成し、通信部２６からデータ受信機に向けて送信する（ステップ４３）。ＰＣ１０はこのＨＴＴＰヘッダを受信することにより、受信するコンテンツデータのメディアフォーマットがＭＰＥＧであることがわかり、それに応じた処理が可能となる。
【００３２】
さらに制御部２１は、エンコーダ２４に対してエンコードするメディアフォーマットを指示する（ステップ４４）。アナログ１ｃｈであれば、エンコーダ２４はＴＶチューナ２３から受信した地上波アナログ放送を、ＭＰＥＧ２−ＰＳへのエンコードする。
【００３３】
図５は、エンコーダ２４でエンコードするＭＰＥＧ２−ＰＳのデータ構成を示す図である。図５に示す通り、ＭＰＥＧ２−ＰＳのデータストリームは、２０４８バイトの固定長であるパックから構成されている。さらに、それぞれのパックは、パックヘッダ及び複数個のパケットから構成されている。
【００３４】
また制御部２１は、ストリームバッファ２５に対して、データ構造単位を通知する（ステップ４５）。ＭＰＥＧ２−ＰＳであれば、データ構造単位はパックである。図６は、パック単位でデータを管理する場合のストリームバッファ２５の構成例を示す図である。パック単位でデータを管理する際、ストリームバッファ２５は未送信データ記憶領域２５ａ及び送信中データ記憶領域２５ｂを設ける。
【００３５】
図６（ａ）に示す通り、エンコーダ２４から供給されたデータは、順次未送信データ記憶領域２５ａに格納される。尚、エンコーダ２４から供給されるデータは、特にパック単位で無くとも良い。このデータを送信する際には、ストリームバッファ２５はパック単位で順次通信部２６にこれを渡す。パックは先述の通り固定長であるので、ストリームバッファ２５はデータの先頭から２０４８バイトずつ区切ることにより、それぞれのパックを認識することができる。また、送信部２６に渡したパックの複製を送信中記憶領域２５ｂに作成する。即ち、図６（ｂ）に示すように、例えば通信部２６からパック＃０が送信されている際には、送信中データ記憶領域２５ｂにパック＃０のデータが保持される。
【００３６】
このような処理の後、アナログ１ｃｈのコンテンツデータのＰＣ１０への送信が開始される（ステップ４６）。
次に、アナログ１ｃｈのコンテンツデータの送信中におけるストリームバッファ２５への書込み制御について説明する。図７は、ワイヤレスＴＶチューナ２０からＰＣ１０に向けてアナログ１ｃｈのコンテンツデータ伝送を行う際の、制御部２１で実行されるプログラムによるストリームバッファ２５へのデータ書込み制御の流れを示すフローチャートである。
【００３７】
アナログ１ｃｈのコンテンツデータのＰＣ１０への送信が開始されると（ステップ４６）、チューナ２３から受信したアナログ１ｃｈのアナログ信号をエンコーダ２４でＭＰＥＧ２−ＰＳ形式に順次エンコードする。制御部２１はエンコーダ２４がエンコードしたデータを、順次見送信データ記憶領域２５ａへ書込む（ステップ７１）。この際、バッファ溢れが生じたか否か、即ち送信データ記憶領域２５ａへデータを書き込めたか否かを判断し(ステップ７２)、バッファ溢れが生じれば（ステップ７２のＹｅｓ）、エンコーダ２４から供給されるデータを１パック分（即ち２０４８バイト）廃棄する（ステップ７３）。データを廃棄した後、或いはバッファ溢れが生じなければ（ステップ７２のＹｅｓ）、さらに新たなデータの書き込みを行う（ステップ７１）。
【００３８】
続いて、アナログ１ｃｈのデータを通信部２６からＰＣ１０へ送信する際の通信部２６に対する処理の流れを説明する。図８は、ワイヤレスＴＶチューナ２０からＰＣ１０に向けてアナログ１ｃｈのコンテンツデータ伝送を行う際の、制御部２１で実行されるプログラムによる通信部２６に対する処理の流れを示すフローチャートである。
【００３９】
まず、制御部２１は未送信データ記憶領域２５ａから、次に伝送すべきデータをパック単位で読み込み、これと共に送信中データ記憶領域２５ｂにこの複製を作成する（ステップ８１）。このとき、読み込んだパック単位のデータが格納されていた未送信データ記憶領域２５ａ内の領域は空き容量となり、エンコーダ２４からのデータを新たに書き込むことができるようになる。
【００４０】
次に、制御部２１は読み込んだデータをＩＰパケット化し、これを順次ＬＡＮ１を通じて通信部２６からＰＣ１０に向けて送信させる（ステップ８２）。送信後、通信部２６から送信したデータ量は、制御部２１に対して通知される（ステップ８３）。制御部２１はこのデータ量が、ステップ８１で読み込んだデータ量と同一であるか否か、即ち送信したデータ量が２０４８バイトであるか否かを判断し（ステップ８４）読み込んだデータ量と同一であれば（ステップ８４のＹｅｓ）、次のパックを送信する処理に移る（ステップ８１）。
【００４１】
ステップ８１で読み込んだデータ量とステップ８３で通信部２６から通知を受けたデータ量が一致しなければ（ステップ８４のＮｏ）、切断されたものと判断し、切断後の処理に移る（ステップ８５）。
【００４２】
ＰＣ１０との通信切断後の、制御部２１で実行されるプログラムの処理について、図９を参照して説明する。図９は、ＰＣ１０との通信切断後の、制御部２１で実行されるプログラムの処理の流れを説明するフローチャートである。
【００４３】
制御部２１は通信が切断されると（ステップ８５）、ＰＣ１０と通信部２６との通信が再開されたか否かを判断する（ステップ９１）。通信が再開されていなければ（ステップ９１のＮｏ）、通信の再開を待ち、通信が再開されれば（ステップ９１のＹｅｓ）、送信中データ記憶領域２５ｂに格納されたデータのうち、未送信のデータを通信部２６からＰＣ１０に向けて送信する（ステップ９２）。
【００４４】
図１０は、通信を再開する際の、送信中データ記憶領域２５ｂの未送信データを説明するための図である。図８中のステップ８３により、通信部２６からＰＣ１０に向けて送信したデータのデータ量は取得できる。よって、制御部２１は、送信中データ記憶領域２５ｂに格納されたデータの内、送信済みのデータ量を除く部分を未送信データ２５ｂ１と判断し、これを通信部２６に渡してＰＣ１０に向けて送信する。未送信データ２５ｂ１を送信した後、通常のデータ転送処理に移る(ステップ４６)。
【００４５】
続いて、ワイヤレスＴＶチューナ２０からＰＣ１０に向けて送るコンテンツデータがＢＳデジタル１ｃｈである場合について説明する。ＢＳデジタル１ｃｈである場合には、ＤＴＣＰ−ＩＰによりデータの転送を行う。尚、ＤＴＣＰ−ＩＰは、機器認証及びかぎ交換処理、ＣＣＩ（Ｃｏｐｙ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）の設定処理、コンテンツの暗号化処理、不正機器の排除等に対して特長を持つ、ネットワーク上の著作権保護技術であり、家庭内ＡＶネットワーク等を主眼に置いた規格である。ＤＴＣＰ−ＩＰでは、コンテンツデータを暗号鍵によって暗号化して伝送する。今回の説明においては、ワイヤレスＴＶチューナ２０及びＰＣ１０はお互いに暗号鍵を予め有しているものとする。
【００４６】
ＢＳデジタル１ｃｈを送信する際においても、図４における接続に係る処理の流れはほぼ同様である。しかし、ステップ４２において取得されるコンテンツデータの情報は、コンテンツ情報２２ａを参照してもわかる通り、メディアフォーマットはＤＴＣＰ−ＩＰであり、またメディア情報２２ｂを参照してもわかる通り、ＤＴＣＰ−ＩＰのデータの構造単位はＰＣＰである。
【００４７】
よって、ステップ４４で制御部２１からエンコーダ２４に対し、メディアフォーマットがＤＴＣＰ−ＩＰであることが指示されると、エンコーダ２４は、チューナ２３から受信するＢＳデジタル１ｃｈのデータ（ＭＰＥＧ２−ＴＳ形式で放送される）をＰＣＰの形にエンコードする。図１１は、ＰＣＰのデータ構造を示す例である。ＰＣＰ１１０は、ヘッダ領域１１１とデータ領域１１２とから構成され、各データはこのＰＣＰのデータ領域１１２に暗号化されて格納される。尚、ＰＣＰ１１０のデータサイズは、パックと異なり固定長ではない。ＰＣＰ１１０のデータ長は、ヘッダ領域１１１に記載されており、デコーダは、このヘッダ領域１１１を読み込むことによりＰＣＰ１１０のデータ長がわかる。
【００４８】
また、ステップ４５で制御部２１からデータ構造単位がＰＣＰであることが指示されると、ストリームバッファ２５は、それに応じて構成を変化させる。図１２は、ＰＣＰ１１０単位でデータを管理する場合のストリームバッファ２５の構成例を示す図である。ＰＣＰ１１０単位でデータを管理する際、ストリームバッファ２５ストリームバッファ２５は未送信データ領域２５ａ、送信中データ記憶領域２５ｂ、及びＰＣＰテーブル２５ｃを設ける。
【００４９】
エンコーダ２４からデータが書き込まれる際には未送信データ記憶領域２５ａに対してデータを書き込むと際に、ＰＣＰテーブル２５ｃに対してそのＰＣＰのデータサイズとポインタとを書き込む。これにより、未送信データ記憶領域２５ａ内において、それぞれのＰＣＰ１１０の領域がどこからどこまでかを認識することができる。ＰＣＰ１１０は先述の通り固定長ではないので、このようなテーブルを設けなければ、それぞれのＰＣＰ１１０の領域を認識することができない。
【００５０】
図７、図８、図９に示したデータ送信後、及び通信切断後のデータ伝送再開にかかるそれぞれの処理の流れについては、アナログ１ｃｈの場合とほぼ同様であるので、説明を省略する。
【００５１】
以上説明したように、本実施例によれば、途中で通信が切断された際にも未送信データを送信中データ記憶領域２５ｂに格納しておき、通信再開後にこのデータをＰＣ１０に対して送信するので、ＰＣ１０内のバッファ１２には、正しいデータ構造単位（パック若しくはＰＣＰ１１０）が格納される。これにより、ＰＣ１０のデコーダ１３での復号化に際して異常が発生することを抑制することができる。特に、ＰＣＰ１１０である場合には、この先頭位置をＰＣ１０で認識することができないため、一度この構造単位を見失うと、ＰＣ１０ではそれ以降の信号は全て復号できなくなる可能性があるが、本実施例では、この危険性を回避することが可能である。
【００５２】
本実施例では、ストリームバッファ２５でバッファ溢れが生じた際に、破棄するデータはパックやＰＣＰといった単位でデータを破棄するので、これによっても、送信するコンテンツデータのデータ構造の維持に貢献している。
【図面の簡単な説明】
【００５３】
【図１】本発明の実施例１にかかるワイヤレスＴＶチューナが使用される映像通信システムの構成を示す図。
【図２】本発明の実施例１に係るワイヤレスＴＶチューナ、及びワイヤレスＴＶチューナからデータを受信するＰＣの構成を示す図。
【図３】本発明の実施例１に係るワイヤレスＴＶチューナのコンテンツ情報管理部が持つコンテンツ情報及びメディア情報の例を示す図。
【図４】本発明の実施例１に係るワイヤレスＴＶチューナがコンテンツデータの伝送を開始するまでのプログラムの処理の流れを示すフローチャート。
【図５】本発明の実施例１に係るワイヤレスＴＶチューナのエンコーダがエンコードするＭＰＥＧ２−ＰＳのデータ構成を示す図。
【図６】本発明の実施例１に係るワイヤレスＴＶチューナのストリームバッファの構成例を示す図。
【図７】本発明の実施例１に係るワイヤレスＴＶチューナを制御するプログラムによる、ストリームバッファへのデータ書き込み制御の流れを示すフローチャート。
【図８】本発明の実施例１に係るワイヤレスＴＶチューナを制御するプログラムによる、伝送処理にかかる通信部への処理の流れを示すフローチャート。
【図９】本発明の実施例１に係るワイヤレスＴＶチューナを制御するプログラムによる、ＰＣとの通信切断後の処理の流れを説明するフローチャート。
【図１０】本発明の実施例１に係るワイヤレスＴＶチューナの送信中データ記憶領域に格納される未送信データを説明する図。
【図１１】本発明の実施例１に係るワイヤレスＴＶチューナのエンコーダがエンコードするＤＴＣＰ−ＩＰのＰＣＰのデータ構造を示す図。
【図１２】本発明の実施例１に係るワイヤレスＴＶチューナのストリームバッファの構成例を示す図。
【符号の説明】
【００５４】
１・・・ＬＡＮ
２・・・ＨＤＤ
３・・・ＤＶＤプレーヤ
１０・・・ＰＣ
１１・・・通信部
１２・・・バッファ
１３・・・デコーダ
１４・・・表示部
２０・・・ワイヤレスＴＶチューナ
２１・・・制御部
２２・・・コンテンツ情報管理部
２２ａ・・・コンテンツ情報
２２ｂ・・・メディア情報
２３・・・チューナ
２４・・・エンコーダ
２５・・・ストリームバッファ
２５ａ・・・未送信データ記憶領域
２５ｂ・・・送信中データ記憶領域
２５ｂ１・・・未送信データ
２５ｃ・・・ＰＣＰテーブル
２６・・・通信部
１１０・・・ＰＣＰ
１１１・・・ヘッダ領域
１１２・・・データ領域
【図１】
2006211602.tif 000003
【図２】
2006211602.tif 000004
【図３】
2006211602.tif 000005
【図４】
2006211602.tif 000006
【図５】
2006211602.tif 000007
【図６】
2006211602.tif 000008
【図７】
2006211602.tif 000009
【図８】
2006211602.tif 000010
【図９】
2006211602.tif 000011
【図１０】
2006211602.tif 000012
【図１１】
2006211602.tif 000013
【図１２】
2006211602.tif 000014