JP2016171428A - 情報処理装置、通信システム、情報処理方法およびプログラム - Google Patents

Abstract

【課題】音声データを適切に扱う情報処理装置、通信システム、情報処理方法及びプログラムを提供する。【解決手段】情報処理装置１００は、通信部及び制御部を具備する。通信部１１０は、ＭＰＥＧ２−ＴＳを用いて多重化された画像信号及び音声信号を他の情報処理装置から受信する。制御部１７０は、音声データ量を削減するように他の情報処理装置に依頼を行う。また、制御部は、その依頼後に他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について第１の音声データ削減方法が適用された音声データの多重分離を行う場合に、ＰＭＴに記載される音声データ伝送を指定するＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳを取り出すように制御する。【選択図】図２

Description

本技術は、情報処理装置に関する。詳しくは、無線通信を利用して情報のやりとりを行う情報処理装置、通信システムおよび情報処理方法ならびに当該方法をコンピュータに実行させるプログラムに関する。

近年、無線ＬＡＮ（Local Area Network）を利用して無線通信を行う情報処理装置が広く普及している。この無線ＬＡＮとして、例えば、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１に代表される無線ＬＡＮが広く普及している。

また、例えば、無線ＡＶ（Audio Visual）伝送通信として、Ｗｉ−Ｆｉ（Wireless Fidelity） ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔが提案されている（例えば、特許文献１参照。）。

特開２０１４−９６０７４号公報

上述の従来技術によれば、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔ仕様に従って、２つの情報処理装置間においてリアルタイム画像伝送を行うことができる。例えば、送信側の情報処理装置から送信された画像データに基づく画像を、受信側の情報処理装置の表示部に表示させることができる。

ここで、受信側の情報処理装置の表示部に、音声が付随する複数の画像を表示する場合を想定する。また、少なくとも１つの画像をメイン画像とし、他をサブ画像として、メイン画像に付随する音声のみを出力する場合を想定する。この場合には、画像の表示態様に応じて、画像に付随する音声の扱いが異なるため、装置間でやりとりされる音声データを適切に扱うことが重要である。

本技術はこのような状況に鑑みて生み出されたものであり、音声データを適切に扱うことを目的とする。

本技術は、上述の問題点を解消するためになされたものであり、その第１の側面は、ＭＰＥＧ（Moving Picture Experts Group）２−ＴＳ（Transport Stream）を用いて多重化された画像信号および音声信号を他の情報処理装置から受信する通信部と、音声データ量を削減するように上記他の情報処理装置に依頼を行い、当該依頼後に上記他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について第１の音声データ削減方法が適用された音声データの多重分離を行う場合に、ＰＭＴ（program map table）に記載される音声データ伝送を指定するＰＩＤ（packet identifier）で指定されるＴＳ（Transport） ｐａｃｋｅｔに格納されるＰＥＳ（packetized elementary stream） ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳ（presentation time stamp）を取り出すように制御する制御部とを具備する情報処理装置およびその情報処理方法ならびに当該方法をコンピュータに実行させるプログラムである。これにより、音声データ量を削減するように他の情報処理装置に依頼を行い、その依頼後に他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＭＴに記載される音声データ伝送を指定するＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳを取り出すという作用をもたらす。

また、この第１の側面において、上記制御部は、第１のトリガに基づいて上記他の情報処理装置に上記依頼を行うようにしてもよい。これにより、第１のトリガに基づいて他の情報処理装置に依頼を行うという作用をもたらす。

また、この第１の側面において、上記制御部は、上記他の情報処理装置に上記依頼を行う場合に、上記音声データを運ぶＰＥＳ ｐａｃｋｅｔを含むＭＰＥＧ２−ＴＳ多重信号を生成して送信する上記第１の音声データ削減方法と、上記音声データを運ぶＰＥＳ ｐａｃｋｅｔを含まないＭＰＥＧ２−ＴＳ多重信号を生成して送信する第２の音声データ削減方法との何れかを指定するようにしてもよい。これにより、他の情報処理装置に依頼を行う場合に、音声データを運ぶＰＥＳ ｐａｃｋｅｔを含むＭＰＥＧ２−ＴＳ多重信号を生成して送信する第１の音声データ削減方法と、音声データを運ぶＰＥＳ ｐａｃｋｅｔを含まないＭＰＥＧ２−ＴＳ多重信号を生成して送信する第２の音声データ削減方法との何れかを指定するという作用をもたらす。

また、この第１の側面において、上記制御部は、上記音声データ量が削減されたＭＰＥＧ２−ＴＳ多重信号を受信している際に、第２のトリガに基づいて、上記音声データ量を元に戻すように上記他の情報処理装置に依頼を行い、当該依頼後に上記他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、上記ＰＥＳのＰａｙｌｏａｄに含まれる音声データを取り出すように制御するようにしてもよい。これにより、音声データ量が削減されたＭＰＥＧ２−ＴＳ多重信号を受信している際に、第２のトリガに基づいて、音声データ量を元に戻すように他の情報処理装置に依頼を行い、その依頼後に他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＥＳのＰａｙｌｏａｄに含まれる音声データを取り出すという作用をもたらす。

また、この第１の側面において、上記第１のトリガおよび上記第２のトリガは、ユーザ操作に起因するようにしてもよい。これにより、ユーザ操作に起因する第１のトリガおよび第２のトリガを用いるという作用をもたらす。

また、この第１の側面において、上記第１のトリガは、上記情報処理装置の周囲に存在するユーザまたはユーザの動きを検出したことに起因するようにしてもよい。これにより、情報処理装置の周囲に存在するユーザまたはユーザの動きを検出したことに起因する第１のトリガを用いるという作用をもたらす。

また、この第１の側面において、上記制御部は、上記依頼を行う前に出力されていた音声の音量設定値を保持しておき、上記音声データ量を元に戻すように上記他の情報処理装置に依頼を行い、当該依頼後に上記ＰＥＳのＰａｙｌｏａｄに含まれる音声データを取り出すタイミングで上記保持された音量設定値を設定するようにしてもよい。これにより、依頼を行う前に出力されていた音声の音量設定値を保持しておき、音声データ量を元に戻すように他の情報処理装置に依頼を行い、その依頼後にＰＥＳのＰａｙｌｏａｄに含まれる音声データを取り出すタイミングで、その保持された音量設定値を設定するという作用をもたらす。

また、本技術の第２の側面は、ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置に無線伝送する通信部と、上記他の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、上記ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、上記データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御を行う制御部とを具備する情報処理装置およびその情報処理方法ならびに当該方法をコンピュータに実行させるプログラムである。これにより、他の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信するという作用をもたらす。

また、この第２の側面において、上記制御部は、上記他の情報処理装置から音声データ量を削減するように依頼された際に、上記ＰＥＳのＰａｙｌｏａｄのデータ量を略ゼロ、または、完全にゼロにすることにより、当該データ量を削減する制御を行うようにしてもよい。これにより、他の情報処理装置から音声データ量を削減するように依頼された際に、ＰＥＳのＰａｙｌｏａｄのデータ量を略ゼロ、または、完全にゼロにすることにより、データ量を削減するという作用をもたらす。

また、この第２の側面において、上記制御部は、上記第１の音声データ削減によりデータ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと上記画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信している場合に、上記他の情報処理装置から音声データ量を元に戻すように依頼されたときには、上記ＰＥＳ Ｐａｙｌｏａｄに通常の音声データを格納し、上記音声信号伝送用のＰＥＳ ｐａｃｋｅｔと上記画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御を行うようにしてもよい。これにより、第１の音声データ削減によりデータ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信している場合に、他の情報処理装置から音声データ量を元に戻すように依頼されたときには、ＰＥＳ Ｐａｙｌｏａｄに通常の音声データを格納し、音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信するという作用をもたらす。

また、この第２の側面において、上記制御部は、上記他の情報処理装置から音声データ量を削減するように依頼された際に、上記第１の音声データ削減以外の音声データ削減を用いることを依頼された場合には、上記ＰＭＴに音声データを指定する上記ＰＩＤの情報を含めず、音声データを運ぶＰＥＳ ｐａｃｋｅｔを生成しない第２の音声データ削減を行い、音声信号伝送用のＰＥＳ ｐａｃｋｅｔを多重せずに、画像信号伝送用のＰＥＳ ｐａｃｋｅｔを送信する制御を行うようにしてもよい。これにより、他の情報処理装置から音声データ量を削減するように依頼された際に、第１の音声データ削減以外の音声データ削減を用いることを依頼された場合には、ＰＭＴに音声データを指定するＰＩＤの情報を含めず、音声データを運ぶＰＥＳ ｐａｃｋｅｔを生成しない第２の音声データ削減を行い、音声信号伝送用のＰＥＳ ｐａｃｋｅｔを多重せずに、画像信号伝送用のＰＥＳ ｐａｃｋｅｔを送信するという作用をもたらす。

また、この第２の側面において、上記第２の音声データ削減を行い、音声信号伝送用のＰＥＳ ｐａｃｋｅｔを多重せずに画像信号伝送用のＰＥＳ ｐａｃｋｅｔを送信している場合に、上記他の情報処理装置から音声データ量を元に戻すように依頼されたときには、上記ＰＭＴに音声データ伝送を指定する上記ＰＩＤを含め、上記ＰＥＳ Ｐａｙｌｏａｄに通常の音声データを格納し、上記音声信号伝送用のＰＥＳ ｐａｃｋｅｔと上記画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御を行うようにしてもよい。これにより、第２の音声データ削減を行い、音声信号伝送用のＰＥＳ ｐａｃｋｅｔを多重せずに画像信号伝送用のＰＥＳ ｐａｃｋｅｔを送信している場合に、他の情報処理装置から音声データ量を元に戻すように依頼されたときには、ＰＭＴに音声データ伝送を指定するＰＩＤを含め、ＰＥＳ Ｐａｙｌｏａｄに通常の音声データを格納し、音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信するという作用をもたらす。

また、本技術の第３の側面は、ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を第２の情報処理装置に無線伝送し、上記第２の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、上記ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、上記データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する第１の情報処理装置と、ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を上記第１の情報処理装置から受信している場合に、音声データ量を削減するように上記第１の情報処理装置に依頼を行い、当該依頼後に上記第１の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＭＴに記載される音声データ伝送を指定するＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳを取り出す第２の情報処理装置とを具備する通信システムおよびその情報処理方法ならびに当該方法をコンピュータに実行させるプログラムである。これにより、第１の情報処理装置は、第２の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信し、第２の情報処理装置は、音声データ量を削減するように第１の情報処理装置に依頼を行い、その依頼後に第１の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＭＴに記載される音声データ伝送を指定するＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳを取り出すという作用をもたらす。

本技術によれば、音声データを適切に扱うことができるという優れた効果を奏し得る。なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

本技術の第１の実施の形態における通信システム１０の構成例を示す図である。 本技術の実施の形態における情報処理装置１００の機能構成例を示すブロック図である。 本技術の基礎となるソース機器５０およびシンク機器６０の通信処理例を示すシーケンスチャートである。 本技術の基礎となるソース機器５０およびシンク機器６０の通信処理例を示すシーケンスチャートである。 本技術の基礎となるソース機器５０およびシンク機器６０の通信処理例を示すシーケンスチャートである。 本技術の基礎となるソース機器５０およびシンク機器６０間でやりとりされるＲＴＳＰ ｍｅｓｓａｇｅの例を示す図である。 本技術の基礎となるソース機器５０およびシンク機器６０間でやりとりされるＲＴＳＰ ｍｅｓｓａｇｅの例を示す図である。 本技術の第１の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。 本技術の第１の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。 本技術の第１の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。 本技術の第１の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。 本技術の第１の実施の形態における情報処理装置１００の表示部１４０に表示される画面と音声出力部１５０から出力される音声情報との遷移例を示す図である。 本技術の第１の実施の形態における情報処理装置１００および情報処理装置２００間でやりとりされる情報の遷移例を示す図である。 本技術の第１の実施の形態における情報処理装置１００による受信処理の処理手順の一例を示すフローチャートである。 本技術の第１の実施の形態における情報処理装置２００による送信処理の処理手順の一例を示すフローチャートである。 本技術の第２の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。 本技術の第２の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。 本技術の第２の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。 本技術の第２の実施の形態における情報処理装置１００の表示部１４０に表示される画面と音声出力部１５０から出力される音声情報との遷移例を示す図である。 本技術の第２の実施の形態における情報処理装置１００および情報処理装置２００間でやりとりされる情報の遷移例を示す図である。 本技術の第２の実施の形態における情報処理装置１００による受信処理の処理手順の一例を示すフローチャートである。 本技術の第２の実施の形態における情報処理装置２００による送信処理の処理手順の一例を示すフローチャートである。 本技術の第２の実施の形態におけるソース機器５０およびシンク機器６０の通信処理例を示すシーケンスチャートである。 本技術の第２の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。 本技術の第２の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。 本技術の第２の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。 本技術の第３の実施の形態における情報処理装置１００の表示部１４０に表示される画面と音声出力部１５０から出力される音声情報との遷移例を示す図である。 本技術の第３の実施の形態における情報処理装置１００および情報処理装置２００間でやりとりされる情報の遷移例を示す図である。 本技術の第３の実施の形態における情報処理装置１００による受信処理の処理手順の一例を示すフローチャートである。 本技術の第３の実施の形態における情報処理装置１００による受信処理の処理手順の一例を示すフローチャートである。 スマートフォンの概略的な構成の一例を示すブロック図である。 カーナビゲーション装置の概略的な構成の一例を示すブロック図である。 無線アクセスポイントの概略的な構成の一例を示すブロック図である。

以下、本技術を実施するための形態（以下、実施の形態と称する）について説明する。説明は以下の順序により行う。
１．第１の実施の形態（ストリーム中にａｕｄｉｏデータの削減を依頼する例）
２．第２の実施の形態（ストリームの開始の段階でａｕｄｉｏデータを削減する例、第２音声データ削減方法を用いるように依頼する例）
３．第３の実施の形態（シンク機器が人の動きや存在を検出して、その検出結果に基づいてａｕｄｉｏデータの削減を依頼する例）
４．応用例

＜１．第１の実施の形態＞
［通信システムの構成例］
図１は、本技術の第１の実施の形態における通信システム１０の構成例を示す図である。

通信システム１０は、情報処理装置１００と、情報処理装置２００と、情報処理装置２１０とを備える。

情報処理装置１００、情報処理装置２００および情報処理装置２１０は、無線通信機能を備え、無線通信を利用して互いに接続して各種情報を送受信することが可能な情報処理装置である。また、これらの各情報処理装置は、Ｐ２Ｐ（Peer to Peer）接続を可能とするＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１仕様に準拠した情報処理装置である。すなわち、これらの各情報処理装置は、通信グループを形成し、アクセスポイントを介することなく直接通信することができる。この場合に、どの情報処理装置が親機として動作し、どの情報処理装置機器が子機として動作するかについては、各情報処理装置の製造時に決定するようにしてもよく、その製造時に決定しなくてもよい。また、製造時に決定しない場合には、複数の情報処理装置間で、どの情報処理装置が親機として動作し、どの情報処理装置機器が子機として動作するかを、ネゴシエーションにより決定することができる。例えば、情報処理装置１００および情報処理装置２００が通信グループを形成する場合には、情報処理装置１００が情報処理装置２００にデータ（例えば、動画コンテンツ）を直接送信することができる。この場合には、無線通信を利用して互いに接続して、情報処理装置１００に記憶されている動画コンテンツを情報処理装置２００に表示させることができる。なお、情報処理装置同士が直接通信するための通信規格の一例として、Ｗｉ−Ｆｉダイレクト（Direct）が知られている。

情報処理装置１００は、例えば、動画コンテンツを記録または表示させる映像視聴装置（例えば、ハードディスク内蔵型テレビジョン）である。例えば、情報処理装置１００は、放送局１１からの放送波を受信して放送波に基づく画像２１を表示部１４０に表示することができる。また、情報処理装置１００は、例えば、情報処理装置２００から送信された画像コンテンツに基づく画像２２を表示部１４０に表示することができる。また、情報処理装置１００は、例えば、情報処理装置２１０から送信された画像コンテンツに基づく画像２３を表示部１４０に表示することができる。

また、情報処理装置２００は、例えば、携帯型情報処理装置（例えば、通話機能およびデータ通信機能を備えるスマートフォン）である。また、情報処理装置２１０は、例えば、各種情報処理を行う情報処理装置（例えば、タブレット端末、ノート型ＰＣ（Personal Computer））である。

なお、情報処理装置１００、情報処理装置２００および情報処理装置２１０は、無線通信を利用してアクセスポイント（図示せず）に接続して各種情報を送受信することができる。ここで、アクセスポイントは、例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ等の無線ＬＡＮ方式に対応するアクセスポイントである。すなわち、ルータおよびアクセスポイント（例えば、ルータにアクセスポイントを内蔵した製品）により、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎにより規格化された無線ＬＡＮが実現される。

なお、図１に示す情報処理装置は一例であり、他の情報処理装置についても適用することができる。例えば、無線通信機能を備える撮像装置（例えば、デジタルスチルカメラ、デジタルビデオカメラ（例えば、カメラ一体型レコーダ））、無線通信機能および表示部を備える音声出力装置（例えば、表示パネルを備える携帯型ミュージックプレーヤー）に適用することができる。また、例えば、無線通信機能を備える表示装置（例えば、デジタルフォトフレーム）、無線通信機能を備える電子書籍表示装置に適用することができる。また、例えば、無線通信機能を備える他の情報処理装置に適用することができる。無線通信機能を備える情報処理装置は、例えば、家庭用映像処理装置（ＤＶＤレコーダ、ビデオデッキ等）、ＰＤＡ（Personal Digital Assistants）、家庭用ゲーム機器、家電機器、携帯用映像処理装置、携帯用ゲーム機器等である。また、例えば、無線通信機能を備える無線通信機器を装着することにより、無線通信を行うことが可能な情報処理装置（例えば、無線通信機能を備えていないパーソナルコンピュータ）についても適用することができる。

［情報処理装置の構成例］
図２は、本技術の実施の形態における情報処理装置１００の機能構成例を示すブロック図である。なお、情報処理装置２００および情報処理装置２１０の機能構成（無線通信に関する機能構成）については、情報処理装置１００と略同様であるため、ここでの説明を省略する。

情報処理装置１００は、通信部１１０と、アンテナ１１４と、センサ１２０と、操作受付部１３０と、表示部１４０と、音声出力部１５０と、メモリ１６０と、制御部１７０とを備える。また、通信部１１０は、データ処理部１１１と、伝送処理部１１２と、無線インターフェース部１１３とを備える。

データ処理部１１１は、制御部１７０の制御に基づいて、各種データを処理するものである。例えば、送信動作を行う場合には、データ処理部１１１は、上位レイヤからの要求に応じて各種データフレーム、データパケットを作成して伝送処理部１１２に供給する。また、例えば、受信動作を行う場合には、データ処理部１１１は、伝送処理部１１２から供給される各種データフレーム、データパケットを処理して解析する。

伝送処理部１１２は、制御部１７０の制御に基づいて、各種伝送処理を行うものである。例えば、送信動作を行う場合には、伝送処理部１１２は、データ処理部１１１により生成されたパケットに対して各種データヘッダやＦＣＳ（Frame Check Sequence）等の誤り検出符号の付加等の処理を行う。そして、伝送処理部１１２は、その処理後のデータを無線インターフェース部１１３に供給する。また、例えば、受信動作を行う場合には、伝送処理部１１２は、無線インターフェース部１１３から供給される各種データフレームに付加されているヘッダを解析する。そして、伝送処理部１１２は、誤り検出符号に基づいてデータフレームに誤りがないことを確認すると、各種データフレームをデータ処理部１１１に供給する。

無線インターフェース部１１３は、他の情報処理装置と接続して各種情報を送受信するためのインターフェースである。例えば、送信動作を行う場合には、無線インターフェース部１１３は、伝送処理部１１２から受け取ったデータから搬送波の周波数帯の変調信号を生成し、この生成された変調信号をアンテナ１１４から無線信号として送信させる。また、例えば、受信動作を行う場合には、無線インターフェース部１１３は、アンテナ１１４により受信された無線信号をダウンコンバージョンし、ビット列に変換することにより各種データフレームを復号する。

また、例えば、通信部１１０は、ＭＰＥＧ（Moving Picture Experts Group）２−ＴＳ（Transport Stream）を用いて多重化された画像信号および音声信号を他の情報処理装置から受信する。また、例えば、通信部１１０は、ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置に無線伝送する。

センサ１２０は、人の存在、人の動き、ジェスチャー（例えば、手を振る人の動作、何らかの操作を行う人の動作）等を検出するセンサであり、検出された各情報を制御部１７０に供給する。ここで、センサ１２０として、例えば、被写体を撮像して画像データを生成し、その画像データについて各種画像認識を行うイメージセンサを用いることができる。また、センサ１２０として、例えば、赤外線を利用して各種情報を取得する赤外線センサを用いることができる。また、センサ１２０として、赤外線、超音波、可視光等を用いて、人間の存在（例えば、情報処理装置１００に近接する人間）を検知する人感センサを用いることができる。また、これらのうちの１つをセンサ１２０として用いるようにしてもよく、これらのうちの複数を組み合わせてセンサ１２０として用いるようにしてもよい。また、他のセンサを用いるようにしてもよい。

操作受付部１３０は、ユーザにより操作された操作入力を受け付ける操作受付部であり、受け付けられた操作入力に応じた操作情報を制御部１７０に出力する。操作受付部１３０として、例えば、マウス、キーボード、タッチパネル、ボタン、マイクロフォン、スイッチ、レバーを用いることができる。また、操作受付部１３０は、他の情報処理装置との間で各種データの送受信を行うための操作を受け付ける。

表示部１４０は、制御部１７０の制御に基づいて、各種情報（画像情報、文字情報、時刻情報等）を表示する表示部である。表示部１４０は、例えば、他の情報処理装置から送信された画像（例えば、図１に示す画面）を表示する。なお、表示部１４０として、例えば、有機ＥＬ（Electro Luminescence）パネル、ＬＣＤ（Liquid Crystal Display）パネル等の表示パネルを用いることができる。なお、操作受付部１３０および表示部１４０については、使用者がその指を表示面に接触または近接することにより操作入力を行うことが可能なタッチパネルを用いて一体で構成することができる。

音声出力部１５０は、制御部１７０の制御に基づいて各種音声情報を出力する音声出力部（例えば、スピーカ）である。

メモリ１６０は、制御部１７０によるデータ処理の作業領域としての役割や、各種データを保持する記憶媒体としての機能を有する。また、メモリ１６０には、接続相手の情報処理装置に送信するデータに含める各種情報が記録される。メモリ１６０として、例えば、不揮発性メモリ、磁気ディスク、光ディスク、ＭＯ（Magneto Optical）ディスク等の記憶媒体を用いることができる。なお、不揮発性メモリとして、例えば、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）、ＥＰＲＯＭ（Erasable Programmable ROM）を用いることができる。また、磁気ディスクとして、例えば、ハードディスク、円盤型磁性体ディスクを用いることができる。また、光ディスクとして、例えば、ＣＤ（Compact Disc）、ＤＶＤ−Ｒ（Digital Versatile Disc Recordable）、ＢＤ（Blu-Ray Disc（登録商標））を用いることができる。

制御部１７０は、メモリ１６０に記憶されている制御プログラムに基づいて、情報処理装置１００の各部を制御するものである。例えば、制御部１７０は、データ処理部１１１、伝送処理部１１２および無線インターフェース部１１３の各々の受信動作および送信動作を制御する。例えば、制御部１７０は、利用周波数の決定、制御メッセージの作成や送信命令、制御メッセージの解釈等の動作を行う。なお、制御メッセージは、例えば、ビーコン、ビーコンの受信応答、プローブリクエスト（Probe request）、プローブレスポンス（Probe response）等の報知情報である。また、上述したように、情報処理装置１００は、放送波を受信して放送波に基づく画像を表示部１４０に表示することができる。このため、制御部１７０は、放送受信部（図示せず）を経由して放送波を取得し、その放送波に基づく画像を表示部１４０に表示させることができる。

［Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔ ｒｅｌｅａｓｅ−１］
ここで、Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅによって策定されたＷｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔ ｒｅｌｅａｓｅ−１について説明する。

図３乃至図５は、本技術の基礎となるソース機器５０およびシンク機器６０の通信処理例を示すシーケンスチャートである。

図６および図７は、本技術の基礎となるソース機器５０およびシンク機器６０間でやりとりされるＲＴＳＰ ｍｅｓｓａｇｅの例を示す図である。図６および図７では、Ｍｅｓｓａｇｅ ＩＤの欄にＲＴＳＰ ｍｅｓｓａｇｅの名称を示す。また、ｒｅｑ／ｒｅｓ（ｄｉｒｅｃｔｉｏｎ）の欄に、ＲＴＳＰ ｍｅｓｓａｇｅがＲｅｑｕｅｓｔなのかＲｅｓｐｏｎｓｅなのかを示すとともに、ソース機器からシンク機器へのＲＴＳＰ ｍｅｓｓａｇｅを（ｓｒｃ→ｓｎｋ）で示し、シンク機器からソース機器へのＲＴＳＰ ｍｅｓｓａｇｅを（ｓｎｋ→ｓｒｃ）で示す。

図３および図４では、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔによる機器発見からＡＶストリーム伝送開始までの流れを示す。また、図５では、図３および図４に示す各処理のうち、ＲＴＳＰによるＡＶフォーマットの決定からＡＶストリーム伝送開始までのストリーム制御の流れを示す。

ここで、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔでは、複数の機器が互いの存在を検出する（Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ、Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ）。そして、接続機器選択を行うと、その選択された機器間において、ＷＰＳ（Wi-Fi Protected Setup）で機器認証を行うことによりダイレクト接続を確立する。また、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔでは、複数の機器が親機（Ｇｒｏｕｐ Ｏｗｎｅｒ）または子機（Ｃｌｉｅｎｔ）の何れとしての役割を担うかを決定して通信グループを形成する。

ただし、図３および図４に示す通信処理例では、一部のパケット送受信については省略して示す。例えば、初回接続時には、上述したように、ＷＰＳを使うためのパケット交換が必要であり、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅのやり取り等においてもパケット交換が必要となる。しかしながら、図３および図４では、これらのパケット交換についての図示を省略し、２回目以降の接続についてのみを示す。

なお、図３および図４では、ソース機器５０およびシンク機器６０間における通信処理例を示すが、他の機器間における通信処理についても同様である。

最初に、ソース機器５０およびシンク機器６０間においてＤｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙが行われる（７１）。例えば、ソース機器５０は、Ｐｒｏｂｅ ｒｅｑｕｅｓｔ（応答要求信号）を送信し、このＰｒｏｂｅ ｒｅｑｕｅｓｔに対するＰｒｏｂｅ ｒｅｓｐｏｎｓｅ（応答信号）をシンク機器６０から受信する。これにより、ソース機器５０およびシンク機器６０は、互いの存在を発見することができる。また、Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙにより、相手のデバイス名、種類（ＴＶ、ＰＣ、スマートフォン等）、ソース対応機器／シンク対応機器等を取得することができる。

続いて、ソース機器５０およびシンク機器６０間においてＳｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙが行われる（７２）。例えば、ソース機器５０は、Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙで発見したシンク機器６０が対応しているサービスを問い合わせるＳｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｑｕｅｒｙを送信する。そして、ソース機器５０は、Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅをシンク機器６０から受信することにより、シンク機器６０が対応しているサービスを取得する。すなわち、Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙにより、相手が実行可能なサービス、相手が使用可能な詳細能力等を取得することができる。相手が実行可能なサービスは、例えば、ｓｅｒｖｉｃｅ、ｐｒｏｔｏｃｏｌ（ＤＬＮＡ（Digital Living Network Alliance） ＤＭＲ（Digital Media Renderer）等）である。

続いて、ユーザにより接続相手の選択操作（接続相手選択操作）が行われる（７３）。この接続相手選択操作は、ソース機器５０およびシンク機器６０の何れか一方のみに発生することもある。例えば、ソース機器５０の表示部に接続相手選択画面が表示され、この接続相手選択画面において接続相手としてシンク機器６０がユーザ操作により選択される。

ユーザにより接続相手選択操作が行われると（７３）、ソース機器５０およびシンク機器６０間においてＧｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが行われる（７４）。図３および図４では、Ｇｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎの結果により、ソース機器５０がグループオーナー（Group Owner）７５になり、シンク機器６０がクライアント（Client）７６になる例を示す。

続いて、ソース機器５０およびシンク機器６０間において、各処理（７７乃至８１）が行われることにより、ダイレクト接続が確立される。すなわち、Ａｓｓｏｃｉａｔｉｏｎ（Ｌ２（第２層） ｌｉｎｋ確立）（７７）、Ｓｅｃｕｒｅ ｌｉｎｋ確立（７８）、ＩＰ Ａｄｄｒｅｓｓ Ａｓｓｉｇｎｍｅｎｔ（７９）が順次行われる。また、ＴＣＰ接続確立（８０）、ＲＴＳＰによるストリーム制御（８１）が順次行われる。

そして、ソース機器５０からシンク機器６０へのＭＰＥＧ２−ＴＳによるＡＶデータ伝送が行われる（８２）。

このように、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔ ｒｅｌｅａｓｅ−１では、リアルタイムでソース機器５０からシンク機器６０にＡＶデータをストリームすることができる。しかしながら、この規格においては、シンク機器６０側からソース機器５０側に対してａｕｄｉｏデータを送信するか否かを指定することはできない。

また、例えば、図１に示すように、比較的大型の表示部を備えるシンク機器（情報処理装置１００）の場合には、その表示部に複数の画面表示が行われることがある。この場合には、複数の画面のうちの１つの画面に付随する音声を出力することが考えられる。例えば、ユーザがメイン画面として指定したコンテンツに付随する音声を出力し、メイン画面として指定されなかったコンテンツに付随する音声を出力しないようにすることができる。

このような場合でも、メイン画面として指定されなかった画像データおよびａｕｄｉｏデータ（サブ画面）についても、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔを用いて送信されるため、出力されないａｕｄｉｏデータを送信することになる。この場合には、出力されないａｕｄｉｏデータの送信により、無線区間の帯域を圧迫してしまうおそれがある。

また、出力されないａｕｄｉｏデータを送信することにより、ソース機器５０の消費電力が必要以上に大きくなってしまうおそれがある。また、出力されないａｕｄｉｏデータを受信することにより、シンク機器６０の消費電力も必要以上に大きくなってしまうおそれがある。

そこで、本技術の実施の形態では、ソース機器５０およびシンク機器６０間でやりとりされるａｕｄｉｏデータを適切に扱う例を示す。なお、本技術の実施の形態では、音声出力をする画面をメイン画面と称し、音声出力をしない画面をサブ画面と称する。また、表示サイズや表示位置を基準にメイン画面およびサブ画面を定義するようにしてもよい。

［ＲＴＳＰ ｍｅｓｓａｇｅの構成例］
図８は、本技術の第１の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。図８では、新しいｐａｒａｍｅｔｅｒ（ＷＦＤ−ａｕｄｉｏ−ｓｔｒｅａｍ−ｃｏｎｔｒｏｌ）をＲＴＳＰに定義する場合におけるＡＢＮＦ（Augmented Backus-Naur form）シンタックスによる定義の一例を示す。

図９は、本技術の第１の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。図９では、ＲＴＳＰ Ｍ３ ＲｅｑｕｅｓｔおよびＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅの構成例を示す。図９において、点線の矩形４０１乃至４０４で囲む情報が、図６に示す例と異なる。

図１０および図１１は、本技術の第１の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。図１０および図１１では、新たに定義するＲＴＳＰ Ｍ１１０ ＲｅｑｕｅｓｔおよびＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅの構成例を示す。

ここで、特定機能は、本技術の各実施の形態で示す各機能を意味するものとする。例えば、本技術の第１の実施の形態では、シンク機器からの依頼に基づいて、シンク機器に送信すべきストリームにおけるａｕｄｉｏデータ量を削減し、そのストリームをシンク機器に送信する機能を特定機能とする例を示す。

例えば、ソース機器（情報処理装置２００）が、特定機能に対応する場合には、ソース機器（情報処理装置２００）は、ＲＴＳＰ Ｍ３ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅにｗｆｄ＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｃｏｎｔｒｏｌ（図９に示す点線の矩形４０２）を含めて送信する。これにより、ソース機器（情報処理装置２００）は、自装置が特定機能に対応していることをシンク機器（情報処理装置１００）に示すとともに、シンク機器（情報処理装置１００）が特定機能に対応するか否かを問い合わせる。

ここで、特定機能に対応していないシンク機器は、ＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅにおいて「ｎｏｎｅ」を返信する。このため、その返信を受信した以降は、ソース機器（情報処理装置２００）は、特定機能を使用しないようにする。

また、特定機能に対応するシンク機器（情報処理装置１００）は、対応可能なｂｉｔを１に設定し、ＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅによりソース機器（情報処理装置２００）に送信する。

ここで、図９に示す点線の矩形４０４において、ＷＦＤ＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｃｏｎｔｒｏｌの値（ｃ）を１６進数で示す。この値は、１０進法では１２であり、４ｂｉｔの２進数では１１００である。このため、ＷＦＤ＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｃｏｎｔｒｏｌの値（ｃ）は、図８に示すビット位置Ｂ３の（ｒｅ−）ｉｎｃｌｕｄｅ ａｕｄｉｏと、ビット位置Ｂ２のｒｅｄｕｃｅ ａｕｄｉｏとに対応することを示す。

また、シンク機器（情報処理装置１００）において、Ａｕｄｉｏデータの削減がトリガされた場合には、例えば、シンク機器（情報処理装置１００）は、その旨を示すメッセージをソース機器に送信する。例えば、図１０に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ（点線の矩形４０５で囲む情報により指定）を送信する。

このように、シンク機器は、第１のトリガに基づいて、ソース機器にＡｕｄｉｏデータの削減の依頼を行うことができる。ここで、第１のトリガは、例えば、ユーザ操作（例えば、メイン画面、サブ画面の切替操作）に起因するものとすることができる。

また、図１０に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを受信したソース機器は、図１０に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。続いて、ソース機器は、シンク機器からの指示に従って、シンク機器に送信すべきストリームにおけるａｕｄｉｏデータ量を削減し、そのストリームをシンク機器に送信する。

ここで、ａｕｄｉｏデータの削減方法について説明する。

例えば、ソース機器は、ＰＭＴ（program map table）に記載される音声データ伝送を指定するＰＩＤは変えずに、ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを概ね周期的に生成するようにして第１の音声データ削減を行うことができる。そして、ソース機器は、データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する。この場合に、ソース機器は、ＰＥＳのＰａｙｌｏａｄのデータ量を略ゼロ、または、完全にゼロにすることにより、データ量を削減することができる。

この場合に、ＰＥＳ Ｐａｙｌｏａｄをデータに全く含まないようにしてもよく、ｓｔｕｆｆｉｎｇ ｂｙｔｅを含みつつも、実際のａｕｄｉｏデータを含まないようにしてもよい。

また、ＰＥＳ ｐａｃｋｅｔ発生の周期としては、１００ｍｓｅｃ程度に設定することが好ましい。これにより、ａｕｄｉｏ ｃｌｏｃｋに同期してｖｉｄｅｏの再生を行うようなシンク機器であっても、ａｕｄｉｏ ｃｌｏｃｋの再生を行うことができ、ｃｌｏｃｋはｆｒｅｅｒｕｎにならず、適切にｃｌｏｃｋ同期が取れたｖｉｄｅｏ再生を行うことができる。

また、例えば、シンク機器は、ＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＭＴに記載される音声データ伝送を指定するＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳを取り出すようにする。

このように、本技術の第１の実施の形態では、ａｕｄｉｏデータの削減方法として、ＰＴＳを残す第１の音声データ削減方法を用いる例を示す。

また、シンク機器（情報処理装置１００）において、Ａｕｄｉｏデータを再度含めるようにトリガされた場合には、例えば、シンク機器（情報処理装置１００）は、その旨を示すメッセージをソース機器に送信する。例えば、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ（点線の矩形４０６で囲む情報により指定）を送信する。

また、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを受信したソース機器は、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。続いて、ソース機器は、シンク機器からの指示に従って、シンク機器に送信すべきストリームにおけるａｕｄｉｏデータ量を元に戻して、そのストリームをシンク機器に送信する。

このように、シンク機器の制御部は、音声データ量が削減されたＭＰＥＧ２−ＴＳ多重信号を受信している際に、第２のトリガに基づいて、音声データ量を元に戻すようにソース機器に依頼を行うことができる。ここで、第２のトリガは、例えば、ユーザ操作（例えば、メイン画面、サブ画面の切替操作）に起因するものとすることができる。

また、例えば、ソース機器の制御部は、第１の音声データ削減によりデータ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信している場合に、シンク機器から音声データ量を元に戻すように依頼されたときには、ＰＥＳ Ｐａｙｌｏａｄに通常の音声データを格納し、音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御を行う。

また、シンク機器の制御部は、その依頼後にソース機器から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＥＳのＰａｙｌｏａｄに含まれる音声データを取り出すように制御する。

［メイン画面の表示切替例］
次に、ソース機器の画面がシンク機器に表示されている場合に、シンク機器が放送波を受信して放送波に基づく画面を新たに表示する場合の例を示す。

図１２は、本技術の第１の実施の形態における情報処理装置１００の表示部１４０に表示される画面と音声出力部１５０から出力される音声情報との遷移例を示す図である。

図１３は、本技術の第１の実施の形態における情報処理装置１００および情報処理装置２００間でやりとりされる情報の遷移例を示す図である。図１３には、図１２に対応する情報のやりとりの例を示す。

図１２のａには、情報処理装置２００からの画像およびこれに付随する音声が情報処理装置１００から出力されている場合の例を示す。すなわち、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔを用いて、情報処理装置２００から情報処理装置１００に、ａｕｄｉｏ有の設定によりストリームの送信が行われている場合（図１３に示す３１１、３１２）の例を示す。この場合には、情報処理装置２００からの画像に付随する音声３０１が音声出力部１５０から出力される。

図１２のｂには、図１２のａに示す状態で、ユーザ操作により、放送波を受信して放送波に基づく画像を表示部１４０に表示させる設定がされた場合（図１３に示す３１３）の例を示す。また、そのユーザ操作により、情報処理装置２００からの画像３０６と、放送波に基づく画像３０５との２画面が同時に表示部１４０に表示される設定もされたものとする。また、そのユーザ操作により、放送波に基づく画像３０５をメイン画面とする設定がされたものとする。

この場合には、情報処理装置１００は、ＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ（図１０に示す）を情報処理装置２００に送信してａｕｄｉｏデータの削減を依頼する（図１３に示す３１４、３１５）。また、情報処理装置２００は、ＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫ（図１０に示す）を情報処理装置１００に送信する（図１３に示す３１６、３１７）。

続いて、情報処理装置２００は、ａｕｄｉｏデータが削減されたストリームを情報処理装置１００に送信する（図１３に示す３１８、３１９）。この場合には、図１２のｂに示すように、情報処理装置２００からの画像３０６に付随する音声が出力されない。すなわち、放送波に基づく画像３０５をメイン画面とする設定がされた場合には、情報処理装置２００からの画像３０６に付随する音声が出力されない。そして、放送波に基づく画像３０５に付随する音声３０２が音声出力部１５０から出力される。

図１２のｃには、図１２のｂに示す状態で、ユーザ操作により、放送波に基づく画像３０５をサブ画面とし、情報処理装置２００からの画像３０８をメイン画面とする設定がされた場合（図１３に示す３２０）の例を示す。

この場合には、情報処理装置１００は、ＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ（図１１に示す）を情報処理装置２００に送信してａｕｄｉｏデータの追加を依頼する（図１３に示す３２１、３２２）。また、情報処理装置２００は、情報処理装置１００にＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫ（図１１に示す）を送信する（図１３に示す３２３、３２４）。

続いて、情報処理装置２００は、ａｕｄｉｏデータを含むストリームを情報処理装置１００に送信する（図１３に示す３２５、３２６）。この場合には、図１２のｃに示すように、放送波に基づく画像３０７に付随する音声が出力されない。また、情報処理装置２００からの画像３０８に付随する音声３０３が音声出力部１５０から出力される。

ここで、図１２のａに示すように、情報処理装置２００からの画像がメイン画像として表示部１４０に表示されている場合には、その画像に付随する音声３０１が音声出力部１５０から出力される。この場合に、画像を視聴しているユーザは、音声３０１の音圧に応じて、音声出力部１５０から出力される音声３０１の音量設定値（ｖｏｌｕｍｅ）を調整することが想定される。そこで、情報処理装置１００の制御部１７０は、音声出力部１５０から出力される音声３０１の音量設定値が調整された場合には、その調整後の値をメモリ１６０に保持させる。

また、図１２のｂに示すように、放送波に基づく画像３０５がメイン画像として表示部１４０に表示されている場合には、画像３０５に付随する音声３０２が音声出力部１５０から出力される。この場合にも、画像３０５を視聴しているユーザは、その放送波の受信中に、音声３０２の音圧に応じて、音声出力部１５０から出力される音声３０２の音量設定値（ｖｏｌｕｍｅ）を調整することが想定される。

そして、図１２のｃに示すように、情報処理装置２００からの画像３０８をメイン画像とする設定がされた場合に、情報処理装置１００の制御部１７０は、メモリ１６０に保持されている値に対応する音量を設定する。すなわち、情報処理装置２００からの画像３０８をメイン画像とする設定がされた場合に、情報処理装置１００の制御部１７０は、放送波に基づく画像３０５に付随する音声３０２の出力中に設定された音量設定値（ｖｏｌｕｍｅ）を破棄し、情報処理装置２００からの画像をメイン画像とする設定がされていた際の音量を再設定する。

このように、情報処理装置１００の制御部１７０は、ソース機器への依頼を行う前に出力されていた音声の音量設定値をメモリ１６０に保持しておく。そして、例えば、情報処理装置１００の制御部１７０は、音声データ量を元に戻すようにソース機器に依頼を行い、その依頼後にＰＥＳのＰａｙｌｏａｄに含まれる音声データを取り出すタイミングで、メモリ１６０に保持された音量設定値を設定することができる。

これにより、例えば、メイン画面を切り替える際に、その切替時にユーザが意図しない音量が出力されることを防止することができる。

［シンク機器の動作例］
図１４は、本技術の第１の実施の形態における情報処理装置１００による受信処理の処理手順の一例を示すフローチャートである。図１４では、ソース機器およびシンク機器の双方が特定機能に対応している場合の例を示す。

最初に、情報処理装置１００の制御部１７０は、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔの開始処理を行う（ステップＳ８０１）。

続いて、制御部１７０は、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔのセッションを開始する（ステップＳ８０２）。この場合にやりとりされるストリームにはａｕｄｉｏデータが含まれる。

続いて、制御部１７０は、ａｕｄｉｏデータを含むストリームの受信、復号、再生等の処理を行う（ステップＳ８０３）。これにより、受信したストリームに含まれる画像データに基づく画像が表示部１４０に表示され、受信したストリームに含まれるａｕｄｉｏデータに基づく音声が音声出力部１５０から出力される。

続いて、制御部１７０は、表示部１４０に表示されている画像（受信したストリームに基づく画像）のうち、ａｕｄｉｏデータが不要である画像が存在するか否かを判断する（ステップＳ８０４）。例えば、図１２のａおよびｂに示すように、放送波を受信してメイン画面として表示するユーザ操作が行われた場合には、ソース機器からのａｕｄｉｏデータが不要であると判断される（ステップＳ８０４）。

ａｕｄｉｏデータが不要である画像が存在しない場合には（ステップＳ８０４）、ステップＳ８０３に戻る。ａｕｄｉｏデータが不要である画像が存在する場合には（ステップＳ８０４）、制御部１７０は、そのａｕｄｉｏデータが不要である画像に対応するストリームを送信しているソース機器に、ａｕｄｉｏデータの削減を依頼するためのメッセージを送信する（ステップＳ８０５）。例えば、図１０に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを送信する。

そのメッセージを送信した後に、通信部１１０は、そのメッセージに対する返信をソース機器から受信する（ステップＳ８０６）。ソース機器は、例えば、図１０に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。

ａｕｄｉｏデータの削減を依頼するためのメッセージを受信した後に（ステップＳ８０６）、制御部１７０は、ａｕｄｉｏデータが削減されたストリームの受信、復号、再生等の処理を行う（ステップＳ８０７）。この場合には、受信したストリームに含まれる画像データに基づく画像が表示部１４０に表示されるが、受信したストリームにはａｕｄｉｏデータが含まれないため、音声は出力されない。

続いて、制御部１７０は、表示部１４０に表示されている画像（受信したストリームに基づく画像）のうち、ａｕｄｉｏデータが必要となる画像が存在するか否かを判断する（ステップＳ８０８）。例えば、図１２のｂおよびｃに示すように、ソース機器からの画像をメイン画面として表示するユーザ操作が行われた場合には、ソース機器からのａｕｄｉｏデータが必要であると判断される（ステップＳ８０８）。

ａｕｄｉｏデータが必要となる画像（受信したストリームに基づく画像）が存在しない場合には（ステップＳ８０８）、ステップＳ８０７に戻る。ａｕｄｉｏデータが必要となる画像が存在する場合には（ステップＳ８０８）、制御部１７０は、そのａｕｄｉｏデータが必要となる画像に対応するストリームを送信しているソース機器に、ａｕｄｉｏデータの追加を依頼するためのメッセージを送信する（ステップＳ８０９）。例えば、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを送信する。

そのメッセージを送信した後に、通信部１１０は、そのメッセージに対する返信をソース機器から受信する（ステップＳ８１０）。ソース機器は、例えば、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。

ａｕｄｉｏデータの追加を依頼するためのメッセージに対する返信を受信した後に（ステップＳ８１０）、制御部１７０は、受信処理の終了が指示されたか否かを判断する（ステップＳ８１１）。そして、受信処理の終了が指示されていない場合には（ステップＳ８１１）、ステップＳ８０３に戻り、制御部１７０は、ａｕｄｉｏデータを含むストリームの受信、復号、再生等の処理を行う（ステップＳ８０３）。一方、受信処理の終了が指示された場合には（ステップＳ８１１）、受信処理の動作を終了する。なお、ステップＳ８０３、Ｓ８０７は、特許請求の範囲に記載の通信手順の一例である。また、ステップＳ８０５乃至Ｓ８０７は、特許請求の範囲に記載の制御手順の一例である。

［ソース機器の動作例］
図１５は、本技術の第１の実施の形態における情報処理装置２００による送信処理の処理手順の一例を示すフローチャートである。図１５では、ソース機器およびシンク機器の双方が特定機能に対応している場合の例を示す。

最初に、情報処理装置２００の制御部（図２に示す制御部１７０に相当）は、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔの開始処理を行う（ステップＳ８２１）。

続いて、情報処理装置２００の制御部は、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔのセッションを開始する（ステップＳ８２２）。この場合にやりとりされるストリームにはａｕｄｉｏデータが含まれる。

続いて、情報処理装置２００の制御部は、ａｕｄｉｏデータを含むストリームを生成し、その生成されたストリームをシンク機器に送信する（ステップＳ８２３）。これにより、送信したストリームに含まれる画像データに基づく画像がシンク機器の表示部に表示され、受信したストリームに含まれるａｕｄｉｏデータに基づく音声がシンク機器の音声出力部から出力される。

続いて、情報処理装置２００の制御部は、ａｕｄｉｏデータの削減を依頼するためのメッセージをシンク機器から受信したか否かを判断する（ステップＳ８２４）。例えば、図１０に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを受信したか否かを判断する。そのメッセージをシンク機器から受信していない場合には（ステップＳ８２４）、ステップＳ８２３に戻る。

そのメッセージをシンク機器から受信した場合には（ステップＳ８２４）、情報処理装置２００の制御部は、そのメッセージに対する返信をシンク機器に送信する（ステップＳ８２５）。情報処理装置２００は、例えば、図１０に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。

続いて、情報処理装置２００の制御部は、ａｕｄｉｏデータが削減されたストリームを生成し、その生成されたストリームをシンク機器に送信する（ステップＳ８２６）。この場合には、受信したストリームに含まれる画像データに基づく画像がシンク機器の表示部に表示されるが、音声は出力されない。

続いて、情報処理装置２００の制御部は、ａｕｄｉｏデータの追加を依頼するためのメッセージをシンク機器から受信したか否かを判断する（ステップＳ８２７）。例えば、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを受信したか否かを判断する。そのメッセージをシンク機器から受信していない場合には（ステップＳ８２７）、ステップＳ８２６に戻る。

そのメッセージをシンク機器から受信した場合には（ステップＳ８２７）、情報処理装置２００の制御部は、そのメッセージに対する返信をシンク機器に送信する（ステップＳ８２８）。情報処理装置２００は、例えば、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。

続いて、情報処理装置２００の制御部は、送信処理の終了が指示されたか否かを判断する（ステップＳ８２９）。そして、送信処理の終了が指示されていない場合には（ステップＳ８２９）、ステップＳ８２３に戻る。一方、送信処理の終了が指示された場合には（ステップＳ８２９）、送信処理の動作を終了する。なお、ステップＳ８２３、Ｓ８２６は、特許請求の範囲に記載の通信手順の一例である。また、ステップＳ８２６は、特許請求の範囲に記載の制御手順の一例である。

＜２．第２の実施の形態＞
本技術の第２の実施の形態では、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔを用いたストリームの開始の段階でａｕｄｉｏデータを削減する例を示す。また、本技術の第２の実施の形態では、本技術の第１の実施の形態で示した音声データ削減方法以外の音声データ削減方法（第２音声データ削減方法）を用いるように依頼する例を示す。すなわち、本技術の第２の実施の形態では、ａｕｄｉｏデータを削減する削減方法を指定することができる。このため、本技術の第２の実施の形態では、新設するＲＴＳＰ ｐａｒａｍｅｔｅｒの構造に更なる拡張を導入する。

なお、本技術の第２の実施の形態における情報処理装置の構成については、図１等に示す情報処理装置１００、２００と略同一である。このため、本技術の第１の実施の形態と共通する部分については、本技術の第１の実施の形態と同一の符号を付してこれらの説明の一部を省略する。

［ＲＴＳＰ ｍｅｓｓａｇｅの構成例］
図１６は、本技術の第２の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。図１６では、新設するＲＴＳＰ ｐａｒａｍｅｔｅｒの構造に更なる拡張を導入する場合の一例を示す。

図１７は、本技術の第２の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。図１７では、ＲＴＳＰ Ｍ３ ＲｅｑｕｅｓｔおよびＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅの構成例を示す。図１７において、点線の矩形４１１乃至４１４で囲む情報が、図６に示す例と異なる。

図１８は、本技術の第２の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。図１８では、新たに定義するＲＴＳＰ Ｍ１１０ ＲｅｑｕｅｓｔおよびＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅの構成例を示す。

例えば、ソース機器（情報処理装置２００）が、特定機能に対応する場合には、ソース機器（情報処理装置２００）は、ＲＴＳＰ Ｍ３ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅにｗｆｄ＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｃｏｎｔｒｏｌ（図１７に示す点線の矩形４１２）を含めて送信する。これにより、ソース機器（情報処理装置２００）は、自装置が特定機能に対応していることをシンク機器（情報処理装置１００）に示すとともに、シンク機器（情報処理装置１００）が特定機能に対応するか否かを問い合わせる。

ここで、特定機能に対応していないシンク機器は、ＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅにおいて「ｎｏｎｅ」を返信する。このため、その返信を受信した以降は、ソース機器（情報処理装置２００）は、特定機能を使用しないようにする。

また、特定機能に対応するシンク機器（情報処理装置１００）は、対応可能なｂｉｔを１に設定し、ＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅによりソース機器（情報処理装置２００）に送信する。

ここで、図１７に示す点線の矩形４１４において、ＷＦＤ＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｃｏｎｔｒｏｌの値（Ｆ）を１６進数で示す。この値は、１０進法では１５であり、４ｂｉｔの２進数では１１１１である。このため、ＷＦＤ＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｃｏｎｔｒｏｌの値（Ｆ）は、図１６に示すビット位置Ｂ３乃至Ｂ１の何れにも対応することと、ストリーム開始時点からａｕｄｉｏデータを削減するように依頼していることを示す。すなわち、図１６に示すビット位置Ｂ３の（ｒｅ−）ｉｎｃｌｕｄｅ ａｕｄｉｏと、ビット位置Ｂ２のｒｅｄｕｃｅ ａｕｄｉｏとに対応することを示す。また、ビット位置Ｂ１で、ｒｅｄｕｃｅ ａｕｄｉｏとは異な削減方法を用いたａｕｄｉｏデータ量削減に対応していることを示し、かつ、ビット位置Ｂ０（最下位ビット）で、ストリームの開始時点からａｕｄｉｏデータを削減するように依頼することを示す。

すなわち、図１７では、ストリームの開始時点からａｕｄｉｏデータを削減することを要求するＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅの一例を示す。このＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅを受信したソース機器は、シンク機器が対応しているデータ削減方法の何れかでデータを削減してからストリームをシンク機器に送信する。例えば、本技術の第１の実施の形態と同一の削減方法（第１の音声データ削減方法）を用いることができる。

また、Ａｕｄｉｏデータを再度含めるようにトリガされた場合には、シンク機器は、例えば、新設したＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ（図１１に示す）を送信する。ＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを受信したソース機器は、ＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫ（図１１に示す）を送信する。そして、ソース機器は、シンク機器からの指示に従ってａｕｄｉｏデータ量を元に戻して送信する。なお、ＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅおよびＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅの構成については、図１１と同一であるため、ここでの詳細な説明を省略する。

ここで、ユーザがシンク機器を操作して、放送波に基づく画像をメイン画面とし、ソース機器からの画像をサブ画面に設定する場合を想定する。この場合には、シンク機器は、ソース機器からの画像に付随するａｕｄｉｏデータが不要になったと判断することができる。このため、シンク機器は、その操作をトリガとして、ソース機器に対してａｕｄｉｏデータ削減を依頼する。この場合に、シンク機器は、ａｕｄｉｏ ＰＴＳが無くても、ソース機器からの画像をスムーズに表示させることができるように設計・実装されているものとする。このため、シンク機器は、他の削減方法（例えば、データ量をさらに削減するためにａｕｄｉｏ ＰＥＳ ｐａｃｋｅｔを全く送らない削減方法）を指定することができる。

この場合に送信されるＲＴＳＰ Ｍ１１０ ＲｅｑｕｅｓｔおよびＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅの構成例を図１８に示す。

図１８に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを受信したソース機器は、ＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅでＯＫを送信する。そして、ソース機器は、そのＯＫの送信以降に送信されるストリームについて第２の音声データ削減方法を用いてデータ削減を行い、ａｕｄｉｏデータ用のＰＥＳ ｐａｃｋｅｔを全く多重せずにそれ以外のデータを送信する。ここで、第２の音声データ削減方法は、ストリームにおいて、ＰＭＴにａｕｄｉｏデータを指定するＰＩＤの情報を含めず、ａｕｄｉｏデータを運ぶＰＥＳ ｐａｃｋｅｔを全く生成しない削減方法である。

このように、ソース機器は、ＰＭＴに音声データを指定するＰＩＤの情報を含めず、音声データを運ぶＰＥＳ ｐａｃｋｅｔを生成しない第２の音声データ削減を行い、音声信号伝送用のＰＥＳ ｐａｃｋｅｔを多重せずに、画像信号伝送用のＰＥＳ ｐａｃｋｅｔを送信することができる。

シンク機器は、第２の音声データ削減方法によりａｕｄｉｏデータが削減されたストリームを受信し、その受信したストリームに含まれるｖｉｄｅｏデータを復号する。

この状態で、ユーザが２画面を解除してソース機器からの画像のみを表示するように指定する場合を想定する。この場合には、ソース機器からの画像に付随するａｕｄｉｏデータが必要になったと判断することができる。このため、シンク機器は、その操作をトリガとして、ソース機器に対してａｕｄｉｏデータを元に戻すようにＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍａｓｓａｇｅにより依頼を出す。

この場合に送信されるＲＴＳＰ Ｍ１１０ ＲｅｑｕｅｓｔおよびＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅの構成例については、図１１と同様である。

ソース機器は、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ内でＯＫを送信した以降に送信されるストリームについては、ａｕｄｉｏデータを含めて送信する。すなわち、ソース機器は、ストリームにおいてＰＭＴにａｕｄｉｏデータを指定するＰＩＤの情報を含み、そのＰＩＤで指定されるＴＳ ｐａｃｋｅｔを用いてａｕｄｉｏデータを運ぶＰＥＳ ｐａｃｋｅｔを生成する。そして、ソース機器は、その生成されたａｕｄｉｏデータを運ぶＰＥＳ ｐａｃｋｅｔと、ｖｉｄｅｏデータを運ぶＰＥＳ ｐａｃｋｅｔとを多重化してシンク機器に送信する。

このように、ソース機器は、第２の音声データ削減を行い、音声信号伝送用のＰＥＳ ｐａｃｋｅｔを多重せずに画像信号伝送用のＰＥＳ ｐａｃｋｅｔを送信している場合に、シンク機器から音声データ量を元に戻すように依頼されたときには、ＰＭＴに音声データ伝送を指定するＰＩＤを含め、ＰＥＳ Ｐａｙｌｏａｄに通常の音声データを格納し、音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信することができる。

シンク機器は、ａｕｄｉｏデータを含むストリームを受信し、その受信したストリームに含まれるｖｉｄｅｏデータおよびａｕｄｉｏデータを多重分離し、復号、再生等を行う。

［メイン画面の表示切替例］
次に、放送波に基づく画面がシンク機器に表示されている場合に、シンク機器がソース機器からの画像を新たに表示する場合の例を示す。

図１９は、本技術の第２の実施の形態における情報処理装置１００の表示部１４０に表示される画面と音声出力部１５０から出力される音声情報との遷移例を示す図である。

図２０は、本技術の第２の実施の形態における情報処理装置１００および情報処理装置２００間でやりとりされる情報の遷移例を示す図である。図２０には、図１９に対応する情報のやりとりの例を示す。

図１９のａには、放送波を受信して放送波に基づく画像およびこれに付随する音声が情報処理装置１００から出力されている場合の例を示す。

図１９のｂには、図１９のａに示す状態で、ユーザによる情報処理装置２００の操作により、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔを用いて、情報処理装置２００から情報処理装置１００へのストリームの送信が開始された場合の例を示す。

この場合には、情報処理装置１００の制御部１７０は、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔを用いた接続を検出する。そして、情報処理装置１００の制御部１７０は、１画面で表示していた放送波に基づく画像をメイン画面とし、新規に追加された情報処理装置２００からの画像をサブ画面とする設定を自動で行う。このように、情報処理装置１００の制御部１７０は、情報処理装置２００からの画像をサブ画面にすると決定することができる（図２０に示す３３１）。

また、情報処理装置１００の制御部１７０は、その決定をトリガにして、ａｕｄｉｏデータを削減して送信するように情報処理装置２００に依頼する。この場合には、情報処理装置１００は、受信したＲＴＳＰ Ｍ３ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅに対する応答であるＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内においてｃｏｎｔｒｏｌ−ｂｉｔｍａｐの最下位ビットＢ０を１に設定して（図１７に示す）情報処理装置２００に送信することにより、ａｕｄｉｏデータの削減を依頼する（図２０に示す３３２、３３３）。この時点では、情報処理装置１００の制御部１７０は、削減方法を指定しない。このため、情報処理装置２００は、削減方法を自動または手動で決定することができる。そして、情報処理装置２００は、ａｕｄｉｏデータが削減されたストリームを情報処理装置１００に送信する（図２０に示す３３４、３３５）。

図１９のｃには、図１９のｂに示す状態で、ユーザ操作により、放送波に基づく画像３２７をサブ画面とし、情報処理装置２００からの画像３２８をメイン画面とする設定がされた場合（図２０に示す３３６）の例を示す。

この場合には、情報処理装置１００は、ＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ（図１１に示す）を情報処理装置２００に送信してａｕｄｉｏデータの追加を依頼する（図２０に示す３３７、３３８）。また、情報処理装置２００は、情報処理装置１００にＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫ（図１１に示す）を送信する（図２０に示す３３９、３４０）。

続いて、情報処理装置２００は、ａｕｄｉｏデータを含むストリームを情報処理装置１００に送信する（図２０に示す３４１、３４２）。この場合には、図１９のｃに示すように、放送波に基づく画像３２７に付随する音声が出力されない。また、情報処理装置２００からの画像３２８に付随する音声３２３が音声出力部１５０から出力される。

ここで、情報処理装置２００からの画像３２８に付随する音声３２３の音声出力部１５０からの出力を開始する場合に、放送波に基づく画像に付随する音声３２２と同一の音量とすると、突然大きな音が出力されてしまう可能性もある。そこで、情報処理装置２００からの画像３２８に付随する音声３２３の音声出力部１５０からの出力を開始する場合に、放送波に基づく画像に付随する音声３２２よりも小さめの音量設定値（ｖｏｌｕｍｅ）に再設定するようにしてもよい。

また、図１９のｃに示す状態で、ユーザ操作により、放送波に基づく画像３２７をメイン画面とし、情報処理装置２００からの画像３２８をサブ画面とする設定がされた場合（図２０に示す３４３）を想定する。

この場合には、情報処理装置１００は、ＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ（図１８に示す）を情報処理装置２００に送信してａｕｄｉｏデータの削減を依頼する（図２０に示す３４４、３４５）。ここでは、ａｕｄｉｏデータを削減する削減方法として、ａｕｄｉｏ ＰＥＳ ｐａｃｋｅｔを含まない方法（第２の音声データ削減方法）を指定する場合を想定する。

また、情報処理装置２００は、情報処理装置１００にＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫ（図１８に示す）を送信する（図２０に示す３４６、３４７）。

続いて、情報処理装置２００は、ａｕｄｉｏデータが削減されたストリームを情報処理装置１００に送信する（図２０に示す３４８、３４９）。

［シンク機器の動作例］
図２１は、本技術の第２の実施の形態における情報処理装置１００による受信処理の処理手順の一例を示すフローチャートである。図２１では、ソース機器およびシンク機器の双方が特定機能に対応している場合の例を示す。

最初に、情報処理装置１００の制御部１７０は、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔの開始トリガが生じたか否かを判断する（ステップＳ８３１）。開始トリガが生じていない場合には（ステップＳ８３１）、監視を継続して行う。

開始トリガが生じた場合には（ステップＳ８３１）、制御部１７０は、開始時点にａｕｄｉｏデータが必要であるか否かを判断する（ステップＳ８３２）。開始時点にａｕｄｉｏデータが不要である場合には（ステップＳ８３２）、制御部１７０は、ストリームの送信を開始するソース機器に、ａｕｄｉｏデータの削減を依頼するためのメッセージを送信する（ステップＳ８３３）。例えば、受信した図１７に示すＲＴＳＰ Ｍ３ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅに対する応答として、図１７に示すＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅを送信する際にｃｏｎｔｒｏｌ−ｂｉｔｍａｐの最下位ビットＢ０を１に設定してａｕｄｉｏデータの削減を依頼する。

続いて、制御部１７０は、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔのセッションを開始する（ステップＳ８３４）。この場合にやりとりされるストリームにはａｕｄｉｏデータが含まれない。

続いて、制御部１７０は、ａｕｄｉｏデータが削減されたストリームの受信、復号、再生等の処理を行う（ステップＳ８３５）。この場合には、受信したストリームに含まれる画像データに基づく画像が表示部１４０に表示されるが、受信したストリームにはａｕｄｉｏデータが含まれないため、音声は出力されない。

続いて、制御部１７０は、表示部１４０に表示されている画像（受信したストリームに基づく画像）について、ａｕｄｉｏデータが必要であるか否かを判断する（ステップＳ８３６）。ａｕｄｉｏデータが不要である場合には（ステップＳ８３６）、ステップＳ８３５に戻る。

ａｕｄｉｏデータが必要である場合には（ステップＳ８３６）、制御部１７０は、ストリームを送信しているソース機器に、ａｕｄｉｏデータの追加を依頼するためのメッセージを送信する（ステップＳ８３７）。例えば、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを送信する。

そのメッセージを送信した後に、通信部１１０は、そのメッセージに対する返信をソース機器から受信する（ステップＳ８３８）。ソース機器は、例えば、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。

また、開始時点にａｕｄｉｏデータが必要である場合には（ステップＳ８３２）、制御部１７０は、ストリームの送信を開始するソース機器に、ａｕｄｉｏデータの包含を依頼するためのメッセージを送信する（ステップＳ８３９）。例えば、図６に示すＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅを送信する。

続いて、制御部１７０は、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔのセッションを開始する（ステップＳ８４０）。この場合にやりとりされるストリームにはａｕｄｉｏデータが含まれる。

続いて、制御部１７０は、ａｕｄｉｏデータを含むストリームの受信、復号、再生等の処理を行う（ステップＳ８４１）。この場合には、受信したストリームに含まれる画像データに基づく画像が表示部１４０に表示され、受信したストリームに含まれるａｕｄｉｏデータに基づく音声が音声出力部１５０から出力される。

続いて、制御部１７０は、表示部１４０に表示されている画像（受信したストリームに基づく画像）について、ａｕｄｉｏデータが不要であるか否かを判断する（ステップＳ８４２）。ａｕｄｉｏデータが必要である場合には（ステップＳ８４２）、ステップＳ８４１に戻る。

ａｕｄｉｏデータが不要である場合には（ステップＳ８４２）、制御部１７０は、ａｕｄｉｏデータの削減方法を決定する（ステップＳ８４３）。例えば、制御部１７０は、接続されているソース機器の数、ソース機器の性能、周囲の通信環境等に基づいて、ａｕｄｉｏデータの削減方法を決定することができる。

例えば、第１の方法（第１の音声データ削減方法）が決定された場合には（ステップＳ８４３）、制御部１７０は、ストリームを送信しているソース機器に、ａｕｄｉｏデータの削減を依頼するためのメッセージを送信する（ステップＳ８４４）。例えば、図１０に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを送信する。

そのメッセージを送信した後に、通信部１１０は、そのメッセージに対する返信をソース機器から受信する（ステップＳ８４５）。ソース機器は、例えば、図１０に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。

例えば、第２の方法（第２の音声データ削減方法）が決定された場合には（ステップＳ８４３）、制御部１７０は、ストリームを送信しているソース機器に、ａｕｄｉｏデータの削除を依頼するためのメッセージを送信する（ステップＳ８４６）。例えば、図１８に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを送信する。

そのメッセージを送信した後に、通信部１１０は、そのメッセージに対する返信をソース機器から受信する（ステップＳ８４７）。ソース機器は、例えば、図１８に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。

続いて、制御部１７０は、ａｕｄｉｏデータが削除されたストリームの受信、復号、再生等の処理を行う（ステップＳ８４８）。この場合には、受信したストリームに含まれる画像データに基づく画像が表示部１４０に表示されるが、受信したストリームにはａｕｄｉｏデータが含まれないため、音声は出力されない。

続いて、制御部１７０は、表示部１４０に表示されている画像（受信したストリームに基づく画像）について、ａｕｄｉｏデータが必要であるか否かを判断する（ステップＳ８４９）。ａｕｄｉｏデータが不要である場合には（ステップＳ８４９）、ステップＳ８４８に戻る。ａｕｄｉｏデータが必要である場合には（ステップＳ８４９）、ステップＳ８３７に戻る。

このように、制御部１７０は、ソース機器に依頼を行う場合に、音声データを運ぶＰＥＳ ｐａｃｋｅｔを含むＭＰＥＧ２−ＴＳ多重信号を生成して送信する第１の音声データ削減方法と、音声データを運ぶＰＥＳ ｐａｃｋｅｔを含まないＭＰＥＧ２−ＴＳ多重信号を生成して送信する第２の音声データ削減方法との何れかを指定することができる。

［ソース機器の動作例］
図２２は、本技術の第２の実施の形態における情報処理装置２００による送信処理の処理手順の一例を示すフローチャートである。図２２では、ソース機器およびシンク機器の双方が特定機能に対応している場合の例を示す。

最初に、情報処理装置２００の制御部は、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔの開始トリガが生じたか否かを判断する（ステップＳ８５１）。開始トリガが生じていない場合には（ステップＳ８５１）、監視を継続して行う。

開始トリガが生じた場合には（ステップＳ８５１）、情報処理装置２００の制御部は、受信したＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅにおいて、ａｕｄｉｏデータが不要と指定されているか否かを判断する（ステップＳ８５２）。

ａｕｄｉｏデータが不要と指定されている場合には（ステップＳ８５２）、情報処理装置２００の制御部は、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔのセッションを開始する（ステップＳ８５３）。この場合にやりとりされるストリームにはａｕｄｉｏデータが含まれない。

続いて、情報処理装置２００の制御部は、ａｕｄｉｏデータが削減されたストリームを生成し、その生成されたストリームをシンク機器に送信する（ステップＳ８５４）。この場合には、受信したストリームに含まれる画像データに基づく画像がシンク機器の表示部に表示されるが、音声は出力されない。

続いて、情報処理装置２００の制御部は、ａｕｄｉｏデータの追加を依頼するためのメッセージをシンク機器から受信したか否かを判断する（ステップＳ８５５）。例えば、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを受信したか否かを判断する。そのメッセージをシンク機器から受信していない場合には（ステップＳ８５５）、ステップＳ８５４に戻る。

そのメッセージをシンク機器から受信した場合には（ステップＳ８５５）、情報処理装置２００の制御部は、そのメッセージに対する返信をシンク機器に送信する（ステップＳ８５６）。情報処理装置２００は、例えば、図１１に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。

ａｕｄｉｏデータが必要と指定されている場合には（ステップＳ８５２）、情報処理装置２００の制御部は、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔのセッションを開始する（ステップＳ８５７）。この場合にやりとりされるストリームにはａｕｄｉｏデータが含まれる。

続いて、情報処理装置２００の制御部は、ａｕｄｉｏデータを含むストリームを生成し、その生成されたストリームをシンク機器に送信する（ステップＳ８５８）。これにより、送信したストリームに含まれる画像データに基づく画像がシンク機器の表示部に表示され、受信したストリームに含まれるａｕｄｉｏデータに基づく音声がシンク機器の音声出力部から出力される。

続いて、情報処理装置２００の制御部は、ａｕｄｉｏデータの削減を依頼するためのメッセージをシンク機器から受信したか否かを判断する（ステップＳ８５９）。例えば、図１０、または、図１８に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを受信したか否かを判断する。そのメッセージをシンク機器から受信していない場合には（ステップＳ８５９）、ステップＳ８５８に戻る。

そのメッセージをシンク機器から受信した場合には（ステップＳ８５９）、情報処理装置２００の制御部は、そのメッセージにおいて指定されたａｕｄｉｏデータの削減方法を確認する（ステップＳ８６０）。そして、その削減方法が第１の方法である場合（図１０に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅの場合）には（ステップＳ８６０）、情報処理装置２００の制御部は、そのメッセージに対する返信をシンク機器に送信する（ステップＳ８６１）。情報処理装置２００の制御部は、例えば、図１０に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。

また、その削減方法が第２の方法である場合（図１８に示すＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅの場合）には（ステップＳ８６０）、情報処理装置２００の制御部は、自装置が第２の方法に対応するか否かを判断する（ステップＳ８６２）。そして、自装置が第２の方法に対応していない場合には（ステップＳ８６２）、ステップＳ８６１に進む。

また、自装置が第２の方法に対応する場合には（ステップＳ８６２）、情報処理装置２００の制御部は、そのメッセージに対する返信をシンク機器に送信する（ステップＳ８６３）。情報処理装置２００は、例えば、図１８に示すＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫを送信する。

続いて、情報処理装置２００の制御部は、ａｕｄｉｏデータが削除されたストリームを生成し、その生成されたストリームをシンク機器に送信する（ステップＳ８６４）。この場合には、受信したストリームに含まれる画像データに基づく画像がシンク機器の表示部に表示されるが、音声は出力されない。

続いて、情報処理装置２００の制御部は、ａｕｄｉｏデータの追加を依頼するためのメッセージをシンク機器から受信したか否かを判断する（ステップＳ８６５）。そのメッセージをシンク機器から受信していない場合には（ステップＳ８６５）、ステップＳ８６４に戻る。一方、そのメッセージをシンク機器から受信した場合には（ステップＳ８６５）、ステップＳ８５６に進む。

［他のｍｅｓｓａｇｅを用いる例］
以上では、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔ ｒｅｌｅａｓｅ−１のＲＴＳＰ ｍｅｓｓａｇｅ交換のシーケンスに可能な限り変更を入れないようにする例を示した。すなわち、Ｍ３ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ Ｒｅｓｐｏｎｓｅに、ａｕｄｉｏデータを入れずに開始する旨の依頼を入れる例を示した。

ここでは、後継規格や独自実装等のように、ＲＴＳＰ ｍｅｓｓａｇｅ交換のシーケンスを変更することが可能である場合の例を示す。例えば、Ｍ３Ｒ Ｒｅｑｕｅｓｔ／Ｒｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ、Ｍ４Ｒ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅを定義する。これらは、Ｍ３ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ、Ｍ４ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅの向きを逆にしたものである。そして、Ｍ３Ｒ Ｒｅｑｕｅｓｔ／Ｒｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅやＭ４Ｒ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅを用いてソース機器およびシンク機器間のｃａｐａｂｉｌｉｔｙ告知、パラメータ設定等を行う。

図２３は、本技術の第２の実施の形態におけるソース機器５０およびシンク機器６０の通信処理例を示すシーケンスチャートである。なお、図２３は、図５に示す例において、新たに定義したＲＴＳＰ ｍｅｓｓａｇｅを追加したものである。すなわち、ＲＴＳＰ Ｍ３Ｒ Ｒｅｑｕｅｓｔ、ＲＴＳＰ Ｍ３Ｒ Ｒｅｓｐｏｎｓｅ、ＲＴＳＰ Ｍ４Ｒ Ｒｅｑｕｅｓｔ、ＲＴＳＰ Ｍ４Ｒ Ｒｅｓｐｏｎｓｅを追加したものである。

ここで、Ｍ３ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ、Ｍ４ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲは、ソース機器からシンク機器に対してＲｅｑｕｅｓｔを出すものである。図２３では、その逆向きのメッセージを新たに定義した場合のＲＴＳＰ ｍｅｓｓａｇｅのシーケンスチャートを示す。

図２３に示すように、シンク機器６０は、Ｍ３Ｒ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを用いて、ソース機器５０の対応能力（例えば、ａｕｄｉｏデータ削減に対応するか否か）を問い合わせる（５０１）。また、ソース機器５０は、Ｍ３Ｒ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅに対する応答（Ｍ３Ｒ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ）を用いて、シンク機器６０に自装置の対応能力を通知する（５０２）。

また、シンク機器６０は、Ｍ４Ｒ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを用いて、ソース機器５０にＡｕｄｉｏデータを含めずにストリーム送信を行うように設定する（５０３）。また、ソース機器５０は、Ｍ４Ｒ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅに対する応答（Ｍ４Ｒ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ）を用いて、シンク機器６０に了解の意を通知する（５０４）。

図２４乃至図２６は、本技術の第２の実施の形態における各情報処理装置間でやりとりされる情報の一例を示す図である。

図２４には、新たに定義したＲＴＳＰ ｍｅｓｓａｇｅにおいて、ｗｆｄ＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｃｏｎｔｒｏｌを用いる場合のｂｉｔの定義例を示す。この例では、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲでａｕｄｉｏを含めないことをシンク機器６０からソース機器５０に明示的に伝えられることができる。このため、図１６に示す例において、最下位ビット（ビット位置Ｂ０）の「Ｉｎｉｔｉａｌ ａｕｄｉｏ−ｏｆｆ」を省略することができる。

図２５には、ＲＴＳＰ Ｍ３Ｒ Ｒｅｑｕｅｓｔ、ＲＴＳＰ Ｍ３Ｒ Ｒｅｓｐｏｎｓｅ、ＲＴＳＰ Ｍ４Ｒ ＲｅｑｕｅｓｔおよびＲＴＳＰ Ｍ４Ｒ Ｒｅｓｐｏｎｓｅの構成例を示す。

次に、図２５を参照して具体的なｍｅｓｓａｇｅに構成例について説明する。

シンク機器６０は、ＲＴＳＰ Ｍ３Ｒ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅにｗｆｄ＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｃｏｎｔｒｏｌ（図２５に示す点線の矩形４２０）を入れてソース機器５０に送信する（図２３に示す５０１）。これにより、シンク機器６０は、ソース機器５０が特定機能に対応するか否かを問い合わせることができる。

ソース機器５０は、それに対して、ＲＴＳＰ Ｍ３Ｒ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅをシンク機器６０に返信し、ソース機器５０が特定機能に対応することを通知する（図２３に示す５０２）。この例では、ソース機器５０は、Ａｕｄｉｏデータを（再度）含める機能、Ａｕｄｉｏデータを削減する機能、他の手法でａｕｄｉｏデータを削減する機能の全てに対応する例を示す。このため、ソース機器５０は、２進数で１１１０、１６進数で「Ｅ（図２５の点線の矩形４２１）」を設定して送り返す（図２３に示す５０２）。

続いて、シンク機器６０は、ＲＴＳＰ Ｍ４Ｒ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅをソース機器５０に送信し、Ａｕｄｉｏデータを削減して送信するようにＳＥＴする（図２３に示す５０３）。この例では、ＲＴＳＰ Ｍ３Ｒ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅにより、ソース機器５０が他の手法でａｕｄｉｏデータを削減する機能を備えることを確認できている。このため、シンク機器６０は、図２４に示すビット位置Ｂ１のみを１に設定し、ａｕｄｉｏデータを全く含まないようにして送信するように指定することができる。これに対してソース機器５０は、シンク機器６０にＲＴＳＰ Ｍ４Ｒ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫ（図２５に示す）を送信する（図２３に示す５０４）。

このように、シンク機器６０は、図２４に示すビット位置Ｂ１のみを１に設定するため、２進数で００１０、１６進数で「２（図２５の点線の矩形４２２）」をＲＴＳＰ ｐａｒａｍｅｔｅｒの設定値として用いる。

続いて、ソース機器５０は、ＲＴＳＰ Ｍ４ Ｒｅｑｕｅｓｔを送信して用いるｆｏｒｍａｔを設定する。この場合に、上述したように、ａｕｄｉｏ ｆｏｒｍａｔを含めて設定するようにしてもよく、ａｕｄｉｏ ｆｏｒｍａｔを含めずに設定してもよい。ａｕｄｉｏ ｆｏｒｍａｔを含めずに設定する例を図２６に示す。

図２６には、ＲＴＳＰ Ｍ４ ＲｅｑｕｅｓｔおよびＲＴＳＰ Ｍ４ Ｒｅｓｐｏｎｓｅの構成例を示す。

ここで、最初からａｕｄｉｏデータを含めずに送信することを指定し、かつ、ａｕｄｉｏ削減方法としてａｕｄｉｏのｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍを全く含まない方法を選択し、かつ、ＲＴＳＰ Ｍ４ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅにａｕｄｉｏ ｆｏｒｍａｔの情報を含めずに送信する場合を想定する。この場合に、ソース機器５０は、次にシンク機器６０からＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを用いて、ａｕｄｉｏを追加するように指定されたときには、ＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅを用いて承諾したことを伝える以外に、ＲＴＳＰ Ｍ４ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを用いて、ａｕｄｉｏ ｆｏｒｍａｔを指定するパラメータを追加して送信する必要がある。この場合に用いられるＲＴＳＰ Ｍ４ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅの構成例は、図７に示す例と同一であるため、ここでの説明を省略する。

＜３．第３の実施の形態＞
本技術の第３の実施の形態では、シンク機器が人の動きや存在を検出して、その検出結果に基づいてａｕｄｉｏデータの削減を依頼する例を示す。

なお、本技術の第３の実施の形態における情報処理装置の構成については、図１等に示す情報処理装置１００、２００と略同一である。このため、本技術の第１の実施の形態と共通する部分については、本技術の第１の実施の形態と同一の符号を付してこれらの説明の一部を省略する。

［メイン画面の表示切替例］
最初に、ソース機器の画面がシンク機器に表示されている場合に、その画面をユーザが見ているか否かに基づいて音声の出力を制御する場合の例を示す。

図２７は、本技術の第３の実施の形態における情報処理装置１００の表示部１４０に表示される画面と音声出力部１５０から出力される音声情報との遷移例を示す図である。

図２８は、本技術の第３の実施の形態における情報処理装置１００および情報処理装置２００間でやりとりされる情報の遷移例を示す図である。図２８には、図２７に対応する情報のやりとりの例を示す。

図２７のａには、情報処理装置２００からの画像およびこれに付随する音声が情報処理装置１００から出力されている場合の例を示す。すなわち、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔを用いて、情報処理装置２００から情報処理装置１００に、ａｕｄｉｏ有の設定によりストリームの送信が行われている場合（図２８に示す３６１、３６２）の例を示す。この場合には、情報処理装置２００からの画像に付随する音声３５１が音声出力部１５０から出力される。

図２７のｂには、図２７のａに示す状態で、表示部１４０に表示されている画面をユーザが見ていないと判断された場合（図２８に示す３６３）の例を示す。

例えば、センサ１２０により人の存在や、人の動きを検出することができる。また、情報処理装置１００の制御部１７０は、センサ１２０による検出結果に基づいて、ユーザが表示部１４０の画面を見ているか否かを判断することができる。そして、情報処理装置１００の制御部１７０は、一定期間、ユーザが表示部１４０の画面を見ていないと判断した場合には、音声出力部１５０からの音声出力をオフする。

この場合には、情報処理装置１００は、ＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ（図１０に示す）を情報処理装置２００に送信してａｕｄｉｏデータの削減を依頼する（図２８に示す３６４、３６５）。また、情報処理装置２００は、ＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫ（図１０に示す）を情報処理装置１００に送信する（図２８に示す３６６、３６７）。

続いて、情報処理装置１００は、ａｕｄｉｏデータが削減されたストリームを情報処理装置２００に送信する（図２８に示す３６８、３６９）。この場合には、図２７のｂに示すように、情報処理装置２００からの画像に付随する音声が出力されない。

また、この場合には、図２７のｂに示すように、情報処理装置１００の制御部１７０は、表示部１４０に「見ている人がいないと判断したので音声を消去した」旨の通知情報を表示することができる。また、情報処理装置１００の制御部１７０は、警告音を出力する等してユーザの注意を喚起するようにしてもよい。この通知情報の出力や警告音の出力等をした後に、所定時間以内にユーザが何らかの行為（例えば、手を振る動作）をした場合や、センサ１２０により所定の反応があった場合には、ａｕｄｉｏデータの削減の依頼をしないようにしてもよい。

また、情報処理装置１００の制御部１７０は、一定期間、ユーザが表示部１４０の画面を見ていないと判断した場合には、音声出力部１５０から出力される音声の音量設定値（ｖｏｌｕｍｅ値）を徐々に下げていくようにしてもよい。この場合には、情報処理装置１００の制御部１７０は、音声出力部１５０から出力される音声の音量設定値（ｖｏｌｕｍｅ値）が十分に小さくなってから、ａｕｄｉｏデータの削減を依頼するようにしてもよい。

また、情報処理装置１００の制御部１７０は、一定期間、ユーザが表示部１４０の画面を見ていないと判断した場合には、低消費電力化を図るための依頼を情報処理装置２００に送信するようにしてもよい。例えば、情報処理装置１００の制御部１７０は、画像の解像度（ｒｅｓｏｌｕｔｉｏｎ）を下げる、ｒｅｆｒｅｓｈ ｒａｔｅを下げる等の依頼を情報処理装置２００に送信することができる。

図２７のｃには、図２７のｂに示す状態で、表示部１４０に表示されている画面を見るユーザが検出された場合（図２８に示す３７０）の例を示す。例えば、図２７のｂに示すメッセージを見たユーザが情報処理装置１００側に戻ってくることが想定される。また、ユーザが所定の動作（例えば、手を振る等の動作）を行うことを条件に、ユーザの存在を検出するようにしてもよい。

この場合には、情報処理装置１００は、ＲＴＳＰ Ｍ１１０ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ（図１１に示す）を情報処理装置２００に送信してａｕｄｉｏデータの追加を依頼する（図２８に示す３７１、３７２）。また、情報処理装置２００は、情報処理装置１００にＲＴＳＰ Ｍ１１０ Ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ内でＯＫ（図１１に示す）を送信する（図２８に示す３７３、３７４）。

続いて、情報処理装置１００は、ａｕｄｉｏデータを含むストリームを情報処理装置２００に送信する（図２８に示す３７５、３７６）。この場合には、図２７のｃに示すように、情報処理装置２００からの画像に付随する音声３５２が音声出力部１５０から出力される。

このように、本技術の第３の実施の形態は、Ａｕｄｉｏデータの削減を依頼するトリガが本技術の第１の実施の形態とは異なるが、他の点については、本技術の第１の実施の形態と略同様である。

［シンク機器の動作例］
図２９および図３０は、本技術の第３の実施の形態における情報処理装置１００による受信処理の処理手順の一例を示すフローチャートである。図２９および図３０では、ソース機器およびシンク機器の双方が特定機能に対応している場合の例を示す。また、図２９および図３０に示す各処理手順（ステップＳ８７１、Ｓ８７２、Ｓ８７４、Ｓ８８４乃至Ｓ８８６、Ｓ８８８乃至Ｓ８９０）は、図１４に示す各処理手順（ステップＳ８０１乃至Ｓ８０３、Ｓ８０５乃至Ｓ８０７、Ｓ８０９乃至Ｓ８１１）に対応する。このため、これらの説明の一部を省略する。

また、図２９に示す点線の矩形６０１は、図１４におけるａｕｄｉｏデータが必要であるか否かを判断する判断処理（ステップＳ８０８）に相当する。また、図３０に示す点線の矩形６０２は、図１４におけるａｕｄｉｏデータが不要であるか否かを判断する判断処理（ステップＳ８０４）に相当する。

Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔのセッションを開始した後に（ステップＳ８７２）、制御部１７０は、第１のタイマをリセットする（ステップＳ８７３）。ここで、第１のタイマは、ユーザへの通知情報を出力するか否かを判断する際に用いられるタイマである。続いて、制御部１７０は、ａｕｄｉｏデータを含むストリームの受信、復号、再生等の処理を行う（ステップＳ８７４）。

続いて、制御部１７０は、センサ１２０によりユーザの存在や動きが検出されたか否かを判断する（ステップＳ８７５）。ユーザの存在や動きが検出された場合には（ステップＳ８７５）、ステップＳ８７３に戻る。

ユーザの存在や動きが検出されない場合には（ステップＳ８７５）、制御部１７０は、第１のタイマをインクリメントする（ステップＳ８７６）。そして、制御部１７０は、第１のタイマが上限値を超えたか否かを判断する（ステップＳ８７７）。第１のタイマが上限値を超えていない場合には（ステップＳ８７７）、ステップＳ８７４に戻る。

第１のタイマが上限値を超えた場合には（ステップＳ８７７）、制御部１７０は、第２のタイマをリセットする（ステップＳ８７８）。ここで、第２のタイマは、ソース機器にａｕｄｉｏデータの削減を依頼するか否かを判断する際に用いられるタイマである。続いて、制御部１７０は、ユーザへの通知情報を出力（例えば、表示、音声出力）する（ステップＳ８７９）。

続いて、制御部１７０は、センサ１２０によりユーザの存在や動きが検出されたか否かを判断する（ステップＳ８８０）。ユーザの存在や動きが検出された場合には（ステップＳ８８０）、制御部１７０は、第２のタイマをリセットして（ステップＳ８８１）、ステップＳ８７３に戻る。

ユーザの存在や動きが検出されない場合には（ステップＳ８８０）、制御部１７０は、第２のタイマをインクリメントする（ステップＳ８８２）。そして、制御部１７０は、第２のタイマが上限値を超えたか否かを判断する（ステップＳ８８３）。第２のタイマが上限値を超えていない場合には（ステップＳ８８３）、ステップＳ８７９に戻る。第２のタイマが上限値を超えた場合には（ステップＳ８８３）、ステップＳ８８４に進む。

また、制御部１７０は、センサ１２０によりユーザの存在や動きが検出されたか否かを判断する（ステップＳ８８７）。ユーザの存在や動きが検出された場合には（ステップＳ８８７）、ステップＳ８８８に進む。一方、ユーザの存在や動きが検出されない場合には（ステップＳ８８７）、ステップＳ８８６に戻る。

このように、ａｕｄｉｏデータを削減してデータを送信する依頼をソース機器にするトリガ（第１のトリガ）を、情報処理装置１００の周囲に存在するユーザまたはユーザの動きを検出したことに起因するトリガとすることができる。

なお、ソース機器の動作例については、図１５と同様であるため、ここでの説明を省略する。

このように、本技術の実施の形態では、ＭＰＥＧ２−ＴＳ用いた伝送方法において、接続されたシンク機器からａｕｄｉｏデータが不要であることを通知された場合に、ソース機器は、ａｕｄｉｏデータを削減してデータを送信する。例えば、ソース機器は、ＰＩＤは変更せずに、ＰＥＳ ｐａｃｋｅｔのＰａｙｌｏａｄに格納されるａｕｄｉｏデータを削減してデータを送信することができる。これにより、接続されたシンク機器からの依頼に応じて、ソース機器は、Ａｕｄｉｏ ｅｌｅｍｅｎｔａｒｙストリームのデータ量を適切に調節することができる。

このように、本技術の実施の形態によれば、ａｕｄｉｏが不要なときには、無線区間に必要となるデータ量を削減することができ、衝突や混雑を回避することができる。また、ソース機器およびシンク機器の双方の消費電力を削減することができる。

また、シンク機器がＡｕｄｉｏ ｍａｓｔｅｒで動作するときには、ＰＴＳに基づいて同期再生を行うことが可能となる。

また、Ａｕｄｉｏの再生クロックに対してｆｒｅｅｒｕｎでｖｉｄｅｏを再生可能な状態にあるシンク機器の場合には、ＰＴＳも含めないようにして送信するようにソース機器に依頼を出すことができる。これにより、一層のデータ量削減による衝突や混雑の回避、ソース機器およびシンク機器の双方の消費電力を削減することができる。

また、メイン画面およびサブ画面の切り替え操作（例えば、ユーザ操作）や、表示画面の追加等の自動的な動き、あるいはユーザが画面を見ているかどうかに連動してａｕｄｉｏデータの追加および削減を行うことができる。この場合には、ａｕｄｉｏデータの追加および削減のための煩雑なユーザ操作を行う必要がない。

なお、本技術の第１および第２の実施の形態では、放送波に基づく画像とソース機器からの画像とを同時にシンク機器に表示する場合の例を示す。ただし、２台以上のソース機器からの画像を同時にシンク機器に表示する場合、または、１台のソース機器からの複数の画像を同時にシンク機器に表示する場合についても同様に、本技術の第１および第２の実施の形態を適用することができる。また、本技術の第３の実施の形態では、１台のソース機器からの画像をシンク機器に表示する場合の例を示す。ただし、２台以上のソース機器からの画像を同時にシンク機器に表示する場合についても同様に、本技術の第３の実施の形態を適用することができる。

＜４．応用例＞
本開示に係る技術は、様々な製品へ応用可能である。例えば、情報処理装置１００、２００、２１０は、スマートフォン、タブレットＰＣ（Personal Computer）、ノートＰＣ、携帯型ゲーム端末若しくはデジタルカメラなどのモバイル端末、テレビジョン受像機、プリンタ、デジタルスキャナ若しくはネットワークストレージなどの固定端末、又はカーナビゲーション装置などの車載端末として実現されてもよい。また、情報処理装置１００、２００、２１０は、スマートメータ、自動販売機、遠隔監視装置又はＰＯＳ（Point Of Sale）端末などの、Ｍ２Ｍ（Machine To Machine）通信を行う端末（ＭＴＣ（Machine Type Communication）端末ともいう）として実現されてもよい。さらに、情報処理装置１００、２００、２１０は、これら端末に搭載される無線通信モジュール（例えば、１つのダイで構成される集積回路モジュール）であってもよい。

一方、例えば、情報処理装置１００、２００、２１０は、ルータ機能を有し又はルータ機能を有しない無線ＬＡＮアクセスポイント（無線基地局ともいう）として実現されてもよい。また、情報処理装置１００、２００、２１０は、モバイル無線ＬＡＮルータとして実現されてもよい。さらに、情報処理装置１００、２００、２１０は、これら装置に搭載される無線通信モジュール（例えば、１つのダイで構成される集積回路モジュール）であってもよい。

［４−１．第１の応用例］
図３１は、本開示に係る技術が適用され得るスマートフォン９００の概略的な構成の一例を示すブロック図である。スマートフォン９００は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１３、アンテナスイッチ９１４、アンテナ９１５、バス９１７、バッテリー９１８及び補助コントローラ９１９を備える。

プロセッサ９０１は、例えばＣＰＵ（Central Processing Unit）又はＳｏＣ（System on Chip）であってよく、スマートフォン９００のアプリケーションレイヤ及びその他のレイヤの機能を制御する。メモリ９０２は、ＲＡＭ（Random Access Memory）及びＲＯＭ（Read Only Memory）を含み、プロセッサ９０１により実行されるプログラム及びデータを記憶する。ストレージ９０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。外部接続インタフェース９０４は、メモリーカード又はＵＳＢ（Universal Serial Bus）デバイスなどの外付けデバイスをスマートフォン９００へ接続するためのインタフェースである。

カメラ９０６は、例えば、ＣＣＤ（Charge Coupled Device）又はＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子を有し、撮像画像を生成する。センサ９０７は、例えば、測位センサ、ジャイロセンサ、地磁気センサ及び加速度センサなどのセンサ群を含み得る。マイクロフォン９０８は、スマートフォン９００へ入力される音声を音声信号へ変換する。入力デバイス９０９は、例えば、表示デバイス９１０の画面上へのタッチを検出するタッチセンサ、キーパッド、キーボード、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９１０は、液晶ディスプレイ（ＬＣＤ）又は有機発光ダイオード（ＯＬＥＤ）ディスプレイなどの画面を有し、スマートフォン９００の出力画像を表示する。スピーカ９１１は、スマートフォン９００から出力される音声信号を音声に変換する。

無線通信インタフェース９１３は、ＩＥＥＥ８０２．１１ａ、１１ｂ、１１ｇ、１１ｎ、１１ａｃ及び１１ａｄなどの無線ＬＡＮ標準のうちの１つ以上をサポートし、無線通信を実行する。無線通信インタフェース９１３は、インフラストラクチャーモードにおいては、他の装置と無線ＬＡＮアクセスポイントを介して通信し得る。また、無線通信インタフェース９１３は、アドホックモード又はＷｉ−Ｆｉ Ｄｉｒｅｃｔ等のダイレクト通信モードにおいては、他の装置と直接的に通信し得る。なお、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔでは、アドホックモードとは異なり２つの端末の一方がアクセスポイントとして動作するが、通信はそれら端末間で直接的に行われる。無線通信インタフェース９１３は、典型的には、ベースバンドプロセッサ、ＲＦ（Radio Frequency）回路及びパワーアンプなどを含み得る。無線通信インタフェース９１３は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を集積したワンチップのモジュールであってもよい。無線通信インタフェース９１３は、無線ＬＡＮ方式に加えて、近距離無線通信方式、近接無線通信方式又はセルラ通信方式などの他の種類の無線通信方式をサポートしてもよい。アンテナスイッチ９１４は、無線通信インタフェース９１３に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９１５の接続先を切り替える。アンテナ９１５は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９１３による無線信号の送信及び受信のために使用される。

なお、図３１の例に限定されず、スマートフォン９００は、複数のアンテナ（例えば、無線ＬＡＮ用のアンテナ及び近接無線通信方式用のアンテナ、など）を備えてもよい。その場合に、アンテナスイッチ９１４は、スマートフォン９００の構成から省略されてもよい。

バス９１７は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１３及び補助コントローラ９１９を互いに接続する。バッテリー９１８は、図中に破線で部分的に示した給電ラインを介して、図３１に示したスマートフォン９００の各ブロックへ電力を供給する。補助コントローラ９１９は、例えば、スリープモードにおいて、スマートフォン９００の必要最低限の機能を動作させる。

図３１に示したスマートフォン９００において、図２を用いて説明した制御部１７０は、無線通信インタフェース９１３において実装されてもよい。また、これら機能の少なくとも一部は、プロセッサ９０１又は補助コントローラ９１９において実装されてもよい。

なお、スマートフォン９００は、プロセッサ９０１がアプリケーションレベルでアクセスポイント機能を実行することにより、無線アクセスポイント（ソフトウェアＡＰ）として動作してもよい。また、無線通信インタフェース９１３が無線アクセスポイント機能を有していてもよい。

［４−２．第２の応用例］
図３２は、本開示に係る技術が適用され得るカーナビゲーション装置９２０の概略的な構成の一例を示すブロック図である。カーナビゲーション装置９２０は、プロセッサ９２１、メモリ９２２、ＧＰＳ（Global Positioning System）モジュール９２４、センサ９２５、データインタフェース９２６、コンテンツプレーヤ９２７、記憶媒体インタフェース９２８、入力デバイス９２９、表示デバイス９３０、スピーカ９３１、無線通信インタフェース９３３、アンテナスイッチ９３４、アンテナ９３５及びバッテリー９３８を備える。

プロセッサ９２１は、例えばＣＰＵ又はＳｏＣであってよく、カーナビゲーション装置９２０のナビゲーション機能及びその他の機能を制御する。メモリ９２２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９２１により実行されるプログラム及びデータを記憶する。

ＧＰＳモジュール９２４は、ＧＰＳ衛星から受信されるＧＰＳ信号を用いて、カーナビゲーション装置９２０の位置（例えば、緯度、経度及び高度）を測定する。センサ９２５は、例えば、ジャイロセンサ、地磁気センサ及び気圧センサなどのセンサ群を含み得る。データインタフェース９２６は、例えば、図示しない端子を介して車載ネットワーク９４１に接続され、車速データなどの車両側で生成されるデータを取得する。

コンテンツプレーヤ９２７は、記憶媒体インタフェース９２８に挿入される記憶媒体（例えば、ＣＤ又はＤＶＤ）に記憶されているコンテンツを再生する。入力デバイス９２９は、例えば、表示デバイス９３０の画面上へのタッチを検出するタッチセンサ、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９３０は、ＬＣＤ又はＯＬＥＤディスプレイなどの画面を有し、ナビゲーション機能又は再生されるコンテンツの画像を表示する。スピーカ９３１は、ナビゲーション機能又は再生されるコンテンツの音声を出力する。

無線通信インタフェース９３３は、ＩＥＥＥ８０２．１１ａ、１１ｂ、１１ｇ、１１ｎ、１１ａｃ及び１１ａｄなどの無線ＬＡＮ標準のうちの１つ以上をサポートし、無線通信を実行する。無線通信インタフェース９３３は、インフラストラクチャーモードにおいては、他の装置と無線ＬＡＮアクセスポイントを介して通信し得る。また、無線通信インタフェース９３３は、アドホックモード又はＷｉ−Ｆｉ Ｄｉｒｅｃｔ等のダイレクト通信モードにおいては、他の装置と直接的に通信し得る。無線通信インタフェース９３３は、典型的には、ベースバンドプロセッサ、ＲＦ回路及びパワーアンプなどを含み得る。無線通信インタフェース９３３は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を集積したワンチップのモジュールであってもよい。無線通信インタフェース９３３は、無線ＬＡＮ方式に加えて、近距離無線通信方式、近接無線通信方式又はセルラ通信方式などの他の種類の無線通信方式をサポートしてもよい。アンテナスイッチ９３４は、無線通信インタフェース９３３に含まれる複数の回路の間でアンテナ９３５の接続先を切り替える。アンテナ９３５は、単一の又は複数のアンテナ素子を有し、無線通信インタフェース９３３による無線信号の送信及び受信のために使用される。

なお、図３２の例に限定されず、カーナビゲーション装置９２０は、複数のアンテナを備えてもよい。その場合に、アンテナスイッチ９３４は、カーナビゲーション装置９２０の構成から省略されてもよい。

バッテリー９３８は、図中に破線で部分的に示した給電ラインを介して、図３２に示したカーナビゲーション装置９２０の各ブロックへ電力を供給する。また、バッテリー９３８は、車両側から給電される電力を蓄積する。

図３２に示したカーナビゲーション装置９２０において、図２を用いて説明した制御部１７０は、無線通信インタフェース９３３において実装されてもよい。また、これら機能の少なくとも一部は、プロセッサ９２１において実装されてもよい。

また、無線通信インタフェース９３３は、上述した情報処理装置１００、２００、２１０として動作し、車両に乗るユーザが有する端末に無線接続を提供してもよい。

また、本開示に係る技術は、上述したカーナビゲーション装置９２０の１つ以上のブロックと、車載ネットワーク９４１と、車両側モジュール９４２とを含む車載システム（又は車両）９４０として実現されてもよい。車両側モジュール９４２は、車速、エンジン回転数又は故障情報などの車両側データを生成し、生成したデータを車載ネットワーク９４１へ出力する。

［４−３．第３の応用例］
図３３は、本開示に係る技術が適用され得る情報処理装置と通信を行う無線アクセスポイント９５０の概略的な構成の一例を示すブロック図である。無線アクセスポイント９５０は、コントローラ９５１、メモリ９５２、入力デバイス９５４、表示デバイス９５５、ネットワークインタフェース９５７、無線通信インタフェース９６３、アンテナスイッチ９６４及びアンテナ９６５を備える。

コントローラ９５１は、例えばＣＰＵ又はＤＳＰ（Digital Signal Processor）であってよく、無線アクセスポイント９５０のＩＰ（Internet Protocol）レイヤ及びより上位のレイヤの様々な機能（例えば、アクセス制限、ルーティング、暗号化、ファイアウォール及びログ管理など）を動作させる。メモリ９５２は、ＲＡＭ及びＲＯＭを含み、コントローラ９５１により実行されるプログラム、及び様々な制御データ（例えば、端末リスト、ルーティングテーブル、暗号鍵、セキュリティ設定及びログなど）を記憶する。

入力デバイス９５４は、例えば、ボタン又はスイッチなどを含み、ユーザからの操作を受け付ける。表示デバイス９５５は、ＬＥＤランプなどを含み、無線アクセスポイント９５０の動作ステータスを表示する。

ネットワークインタフェース９５７は、無線アクセスポイント９５０が有線通信ネットワーク９５８に接続するための有線通信インタフェースである。ネットワークインタフェース９５７は、複数の接続端子を有してもよい。有線通信ネットワーク９５８は、イーサネット（登録商標）などのＬＡＮであってもよく、又はＷＡＮ（Wide Area Network）であってもよい。

無線通信インタフェース９６３は、ＩＥＥＥ８０２．１１ａ、１１ｂ、１１ｇ、１１ｎ、１１ａｃ及び１１ａｄなどの無線ＬＡＮ標準のうちの１つ以上をサポートし、近傍の端末へアクセスポイントとして無線接続を提供する。無線通信インタフェース９６３は、典型的には、ベースバンドプロセッサ、ＲＦ回路及びパワーアンプなどを含み得る。無線通信インタフェース９６３は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を集積したワンチップのモジュールであってもよい。アンテナスイッチ９６４は、無線通信インタフェース９６３に含まれる複数の回路の間でアンテナ９６５の接続先を切り替える。アンテナ９６５は、単一の又は複数のアンテナ素子を有し、無線通信インタフェース９６３による無線信号の送信及び受信のために使用される。

図３３に示した無線アクセスポイント９５０において、図２を用いて説明した制御部１７０は、無線通信インタフェース９６３において実装されてもよい。また、これら機能の少なくとも一部は、コントローラ９５１において実装されてもよい。

なお、上述の実施の形態は本技術を具現化するための一例を示したものであり、実施の形態における事項と、特許請求の範囲における発明特定事項とはそれぞれ対応関係を有する。同様に、特許請求の範囲における発明特定事項と、これと同一名称を付した本技術の実施の形態における事項とはそれぞれ対応関係を有する。ただし、本技術は実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において実施の形態に種々の変形を施すことにより具現化することができる。

また、上述の実施の形態において説明した処理手順は、これら一連の手順を有する方法として捉えてもよく、また、これら一連の手順をコンピュータに実行させるためのプログラム乃至そのプログラムを記憶する記録媒体として捉えてもよい。この記録媒体として、例えば、ＣＤ（Compact Disc）、ＭＤ（MiniDisc）、ＤＶＤ（Digital Versatile Disc）、メモリカード、ブルーレイディスク（Blu-ray（登録商標）Disc）等を用いることができる。

なお、本明細書に記載された効果はあくまで例示であって、限定されるものではなく、また、他の効果があってもよい。

なお、本技術は以下のような構成もとることができる。
（１）
ＭＰＥＧ（Moving Picture Experts Group）２−ＴＳ（Transport Stream）を用いて多重化された画像信号および音声信号を他の情報処理装置から受信する通信部と、
音声データ量を削減するように前記他の情報処理装置に依頼を行い、当該依頼後に前記他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について第１の音声データ削減方法が適用された音声データの多重分離を行う場合に、ＰＭＴ（program map table）に記載される音声データ伝送を指定するＰＩＤ（packet identifier）で指定されるＴＳ（Transport） ｐａｃｋｅｔに格納されるＰＥＳ（packetized elementary stream） ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳ（presentation time stamp）を取り出すように制御する制御部と
を具備する情報処理装置。
（２）
前記制御部は、第１のトリガに基づいて前記他の情報処理装置に前記依頼を行う前記（１）に記載の情報処理装置。
（３）
前記制御部は、前記他の情報処理装置に前記依頼を行う場合に、前記音声データを運ぶＰＥＳ ｐａｃｋｅｔを含むＭＰＥＧ２−ＴＳ多重信号を生成して送信する前記第１の音声データ削減方法と、前記音声データを運ぶＰＥＳ ｐａｃｋｅｔを含まないＭＰＥＧ２−ＴＳ多重信号を生成して送信する第２の音声データ削減方法との何れかを指定する前記（１）または（２）に記載の情報処理装置。
（４）
前記制御部は、前記音声データ量が削減されたＭＰＥＧ２−ＴＳ多重信号を受信している際に、第２のトリガに基づいて、前記音声データ量を元に戻すように前記他の情報処理装置に依頼を行い、当該依頼後に前記他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、前記ＰＥＳのＰａｙｌｏａｄに含まれる音声データを取り出すように制御する前記（１）から（３）のいずれかに記載の情報処理装置。
（５）
前記第１のトリガおよび前記第２のトリガは、ユーザ操作に起因する前記（４）に記載の情報処理装置。
（６）
前記第１のトリガは、前記情報処理装置の周囲に存在するユーザまたはユーザの動きを検出したことに起因する前記（２）に記載の情報処理装置。
（７）
前記制御部は、前記依頼を行う前に出力されていた音声の音量設定値を保持しておき、前記音声データ量を元に戻すように前記他の情報処理装置に依頼を行い、当該依頼後に前記ＰＥＳのＰａｙｌｏａｄに含まれる音声データを取り出すタイミングで前記保持された音量設定値を設定する前記（１）から（６）のいずれかに記載の情報処理装置。
（８）
ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置に無線伝送する通信部と、
前記他の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、前記ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、前記データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御を行う制御部と
を具備する情報処理装置。
（９）
前記制御部は、前記他の情報処理装置から音声データ量を削減するように依頼された際に、前記ＰＥＳのＰａｙｌｏａｄのデータ量を略ゼロ、または、完全にゼロにすることにより、当該データ量を削減する制御を行う前記（８）に記載の情報処理装置。
（１０）
前記制御部は、前記第１の音声データ削減によりデータ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと前記画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信している場合に、前記他の情報処理装置から音声データ量を元に戻すように依頼されたときには、前記ＰＥＳ Ｐａｙｌｏａｄに通常の音声データを格納し、前記音声信号伝送用のＰＥＳ ｐａｃｋｅｔと前記画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御を行う前記（８）または（９）に記載の情報処理装置。
（１１）
前記制御部は、前記他の情報処理装置から音声データ量を削減するように依頼された際に、前記第１の音声データ削減以外の音声データ削減を用いることを依頼された場合には、前記ＰＭＴに音声データを指定する前記ＰＩＤの情報を含めず、音声データを運ぶＰＥＳ ｐａｃｋｅｔを生成しない第２の音声データ削減を行い、音声信号伝送用のＰＥＳ ｐａｃｋｅｔを多重せずに、画像信号伝送用のＰＥＳ ｐａｃｋｅｔを送信する制御を行う前記（８）に記載の情報処理装置。
（１２）
前記第２の音声データ削減を行い、音声信号伝送用のＰＥＳ ｐａｃｋｅｔを多重せずに画像信号伝送用のＰＥＳ ｐａｃｋｅｔを送信している場合に、前記他の情報処理装置から音声データ量を元に戻すように依頼されたときには、前記ＰＭＴに音声データ伝送を指定する前記ＰＩＤを含め、前記ＰＥＳ Ｐａｙｌｏａｄに通常の音声データを格納し、前記音声信号伝送用のＰＥＳ ｐａｃｋｅｔと前記画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御を行う前記（１１）に記載の情報処理装置。
（１３）
ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を第２の情報処理装置に無線伝送し、前記第２の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、前記ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、前記データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する第１の情報処理装置と、
ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を前記第１の情報処理装置から受信している場合に、音声データ量を削減するように前記第１の情報処理装置に依頼を行い、当該依頼後に前記第１の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＭＴに記載される音声データ伝送を指定するＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳを取り出す第２の情報処理装置と
を具備する通信システム。
（１４）
ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置から受信する通信手順と、
音声データ量を削減するように前記他の情報処理装置に依頼を行い、当該依頼後に前記他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＭＴに記載される音声データ伝送を指定するＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳを取り出す制御手順と
を具備する情報処理方法。
（１５）
ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置に無線伝送する通信手順と、
前記他の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、前記ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、前記データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御手順と
を具備する情報処理方法。
（１６）
ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置から受信する通信手順と、
音声データ量を削減するように前記他の情報処理装置に依頼を行い、当該依頼後に前記他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＭＴに記載される音声データ伝送を指定するＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳを取り出す制御手順と
をコンピュータに実行させるプログラム。
（１７）
ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置に無線伝送する通信手順と、
前記他の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、前記ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、前記データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御手順と
をコンピュータに実行させるプログラム。

１０ 通信システム
１１ 放送局
５０ ソース機器
６０ シンク機器
１００、２００、２１０ 情報処理装置
１１０ 通信部
１１１ データ処理部
１１２ 伝送処理部
１１３ 無線インターフェース部
１１４ アンテナ
１２０ センサ
１３０ 操作受付部
１４０ 表示部
１５０ 音声出力部
１６０ メモリ
１７０ 制御部
９００ スマートフォン
９０１ プロセッサ
９０２ メモリ
９０３ ストレージ
９０４ 外部接続インタフェース
９０６ カメラ
９０７ センサ
９０８ マイクロフォン
９０９ 入力デバイス
９１０ 表示デバイス
９１１ スピーカ
９１３ 無線通信インタフェース
９１４ アンテナスイッチ
９１５ アンテナ
９１７ バス
９１８ バッテリー
９１９ 補助コントローラ
９２０ カーナビゲーション装置
９２１ プロセッサ
９２２ メモリ
９２４ ＧＰＳモジュール
９２５ センサ
９２６ データインタフェース
９２７ コンテンツプレーヤ
９２８ 記憶媒体インタフェース
９２９ 入力デバイス
９３０ 表示デバイス
９３１ スピーカ
９３３ 無線通信インタフェース
９３４ アンテナスイッチ
９３５ アンテナ
９３８ バッテリー
９４１ 車載ネットワーク
９４２ 車両側モジュール
９５０ 無線アクセスポイント
９５１ コントローラ
９５２ メモリ
９５４ 入力デバイス
９５５ 表示デバイス
９５７ ネットワークインタフェース
９５８ 有線通信ネットワーク
９６３ 無線通信インタフェース
９６４ アンテナスイッチ
９６５ アンテナ

Claims (17)

1. ＭＰＥＧ（Moving Picture Experts Group）２−ＴＳ（Transport Stream）を用いて多重化された画像信号および音声信号を他の情報処理装置から受信する通信部と、
   音声データ量を削減するように前記他の情報処理装置に依頼を行い、当該依頼後に前記他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について第１の音声データ削減方法が適用された音声データの多重分離を行う場合に、ＰＭＴ（program map table）に記載される音声データ伝送を指定するＰＩＤ（packet identifier）で指定されるＴＳ（Transport） ｐａｃｋｅｔに格納されるＰＥＳ（packetized elementary stream） ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳ（presentation time stamp）を取り出すように制御する制御部と
   を具備する情報処理装置。
2. 前記制御部は、第１のトリガに基づいて前記他の情報処理装置に前記依頼を行う請求項１記載の情報処理装置。
3. 前記制御部は、前記他の情報処理装置に前記依頼を行う場合に、前記音声データを運ぶＰＥＳ ｐａｃｋｅｔを含むＭＰＥＧ２−ＴＳ多重信号を生成して送信する前記第１の音声データ削減方法と、前記音声データを運ぶＰＥＳ ｐａｃｋｅｔを含まないＭＰＥＧ２−ＴＳ多重信号を生成して送信する第２の音声データ削減方法との何れかを指定する請求項１記載の情報処理装置。
4. 前記制御部は、前記音声データ量が削減されたＭＰＥＧ２−ＴＳ多重信号を受信している際に、第２のトリガに基づいて、前記音声データ量を元に戻すように前記他の情報処理装置に依頼を行い、当該依頼後に前記他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、前記ＰＥＳのＰａｙｌｏａｄに含まれる音声データを取り出すように制御する請求項１記載の情報処理装置。
5. 前記第１のトリガおよび前記第２のトリガは、ユーザ操作に起因する請求項４記載の情報処理装置。
6. 前記第１のトリガは、前記情報処理装置の周囲に存在するユーザまたはユーザの動きを検出したことに起因する請求項２記載の情報処理装置。
7. 前記制御部は、前記依頼を行う前に出力されていた音声の音量設定値を保持しておき、前記音声データ量を元に戻すように前記他の情報処理装置に依頼を行い、当該依頼後に前記ＰＥＳのＰａｙｌｏａｄに含まれる音声データを取り出すタイミングで前記保持された音量設定値を設定する請求項１記載の情報処理装置。
8. ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置に無線伝送する通信部と、
   前記他の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、前記ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、前記データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御を行う制御部と
   を具備する情報処理装置。
9. 前記制御部は、前記他の情報処理装置から音声データ量を削減するように依頼された際に、前記ＰＥＳのＰａｙｌｏａｄのデータ量を略ゼロ、または、完全にゼロにすることにより、当該データ量を削減する制御を行う請求項８記載の情報処理装置。
10. 前記制御部は、前記第１の音声データ削減によりデータ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと前記画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信している場合に、前記他の情報処理装置から音声データ量を元に戻すように依頼されたときには、前記ＰＥＳ Ｐａｙｌｏａｄに通常の音声データを格納し、前記音声信号伝送用のＰＥＳ ｐａｃｋｅｔと前記画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御を行う請求項８記載の情報処理装置。
11. 前記制御部は、前記他の情報処理装置から音声データ量を削減するように依頼された際に、前記第１の音声データ削減以外の音声データ削減を用いることを依頼された場合には、前記ＰＭＴに音声データを指定する前記ＰＩＤの情報を含めず、音声データを運ぶＰＥＳ ｐａｃｋｅｔを生成しない第２の音声データ削減を行い、音声信号伝送用のＰＥＳ ｐａｃｋｅｔを多重せずに、画像信号伝送用のＰＥＳ ｐａｃｋｅｔを送信する制御を行う請求項８記載の情報処理装置。
12. 前記第２の音声データ削減を行い、音声信号伝送用のＰＥＳ ｐａｃｋｅｔを多重せずに画像信号伝送用のＰＥＳ ｐａｃｋｅｔを送信している場合に、前記他の情報処理装置から音声データ量を元に戻すように依頼されたときには、前記ＰＭＴに音声データ伝送を指定する前記ＰＩＤを含め、前記ＰＥＳ Ｐａｙｌｏａｄに通常の音声データを格納し、前記音声信号伝送用のＰＥＳ ｐａｃｋｅｔと前記画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御を行う請求項１１記載の情報処理装置。
13. ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を第２の情報処理装置に無線伝送し、前記第２の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、前記ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、前記データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する第１の情報処理装置と、
    ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を前記第１の情報処理装置から受信している場合に、音声データ量を削減するように前記第１の情報処理装置に依頼を行い、当該依頼後に前記第１の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＭＴに記載される音声データ伝送を指定するＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳを取り出す第２の情報処理装置と
    を具備する通信システム。
14. ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置から受信する通信手順と、
    音声データ量を削減するように前記他の情報処理装置に依頼を行い、当該依頼後に前記他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＭＴ（program map table）に記載される音声データ伝送を指定するＰＩＤ（packet identifier）で指定されるＴＳ（Transport） ｐａｃｋｅｔに格納されるＰＥＳ（packetized elementary stream） ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳ（presentation time stamp）を取り出す制御手順と
    を具備する情報処理方法。
15. ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置に無線伝送する通信手順と、
    前記他の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、前記ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、前記データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御手順と
    を具備する情報処理方法。
16. ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置から受信する通信手順と、
    音声データ量を削減するように前記他の情報処理装置に依頼を行い、当該依頼後に前記他の情報処理装置から受信するＭＰＥＧ２−ＴＳ多重信号について多重分離を行う場合に、ＰＭＴ（program map table）に記載される音声データ伝送を指定するＰＩＤ（packet identifier）で指定されるＴＳ（Transport） ｐａｃｋｅｔに格納されるＰＥＳ（packetized elementary stream） ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄに含まれるデータを廃棄し、かつ、ＰＥＳ ｈｅａｄｅｒ部分に含まれるＰＴＳ（presentation time stamp）を取り出す制御手順と
    をコンピュータに実行させるプログラム。
17. ＭＰＥＧ２−ＴＳを用いて多重化された画像信号および音声信号を他の情報処理装置に無線伝送する通信手順と、
    前記他の情報処理装置からの依頼に基づいて、ＰＭＴに記載される音声データ伝送を指定するＰＩＤは変えずに、前記ＰＩＤで指定されるＴＳ ｐａｃｋｅｔに格納されるＰＥＳ ｐａｃｋｅｔのうち、ＰＥＳのＰａｙｌｏａｄのデータ量を削減し、かつ、ＰＥＳ ｈｅａｄｅｒ部分にＰＴＳを含むＰＥＳ ｐａｃｋｅｔを生成する第１の音声データ削減を行い、前記データ量が削減された音声信号伝送用のＰＥＳ ｐａｃｋｅｔと画像信号伝送用のＰＥＳ ｐａｃｋｅｔとを多重して送信する制御手順と
    をコンピュータに実行させるプログラム。

Images