(57)【要約】【課題】送信された映像コンテンツの表示を補償する。【解決手段】実施形態の映像送信装置は、第１の送信手段と、受信手段と、調整手段と、第２の送信手段と、を備える。第１の送信手段は、伝送路を介して接続された通信装置に対して、音声情報と映像情報とを、コネクションレス型の通信プロトコルを用いて送信する。受信手段は、映像情報の表示で満足していないことが示された所定のリクエストを受信する。調整手段は、受信手段が所定のリクエストを受信した場合に、映像情報のフレームレートが小さくなるよう調整する。第２の送信手段は、通信装置に対して、調整手段により調整された後の映像情報を、コネクションレス型の通信プロトコルからコネクション型の通信プロトコルに切り替えて送信すると共に、前記音声情報について前記コネクションレス型の通信プロトコルによる送信を維持する。【選択図】図４
2014027613.tif 000002
【特許請求の範囲】
【請求項１】
伝送路を介して接続された通信装置に対して、音声情報と映像情報とを、コネクションレス型の通信プロトコルを用いて送信する第１の送信手段と、
所定のリクエストを受信する受信手段と、
前記受信手段が前記所定のリクエストを受信した場合に、前記映像情報のフレームレートが小さくなるよう調整する調整手段と、
前記通信装置に対して、前記調整手段により調整された後の前記映像情報を、前記コネクションレス型の通信プロトコルからコネクション型の通信プロトコルに切り替えて送信すると共に、前記音声情報について前記コネクションレス型の通信プロトコルによる送信を維持する第２の送信手段と、
を備える映像送信装置。
【請求項２】
前記第２の送信手段は、前記コネクション型の通信プロトコルに切り替えた後における前記映像情報の再送要求回数が所定の回数以下の場合に、前記映像情報を、前記コネクション型の通信プロトコルからコネクションレス型の通信プロトコルに切り替えて送信する、
請求項１に記載の映像送信装置。
【請求項３】
前記リクエストは、前記映像情報の表示で満足していないことが示されたリクエストである、請求項１又は２に記載の映像送信装置。
【請求項４】
前記受信手段が受信する前記リクエストが、前記通信装置からのＧＥＴ式リクエストである、
請求項１乃至３のいずれか一つに記載の映像送信装置。
【請求項５】
前記通信装置との間の伝送路におけるデータ伝送レートを測定するレート測定手段をさらに備え、
前記受信手段は、前記レート測定手段により測定された前記データ伝送レートを、前記所定のリクエストとして受信する、
請求項１に記載の映像送信装置。
【請求項６】
第１の送信手段が送信する前記映像情報を一時的に蓄積するバッファと、
前記受信手段は、前記バッファにおける前記映像情報の蓄積状態を、前記所定のリクエストとして受信する、
請求項１に記載の映像送信装置。
【請求項７】
前記受信手段が受信する前記リクエストが、前記映像送信装置内からのＰＵＳＨ式リクエストである、
請求項１又は２に記載の映像送信装置。
【請求項８】
伝送路を介して接続された通信装置に対して、音声情報をコネクションレス型の通信プロトコルを用いて送信すると共に、映像情報をコネクション型の通信プロトコルを用いて送信する第１の送信手段と、
前記コネクション型の通信プロトコルによる前記映像情報の再送要求回数が所定の回数以下の場合に、前記映像情報を、前記コネクション型の通信プロトコルからコネクションレス型の通信プロトコルに切り替えて送信すると共に、前記音声情報について前記コネクションレス型の通信プロトコルによる送信を維持する第２の送信手段と、
を備える映像送信装置。
【請求項９】
前記コネクション型の通信プロトコルによる前記映像情報の再送要求回数が所定の回数以下であって、前記映像情報のフレームレートが所定の値よりも小さい場合に、前記映像情報のフレームレートが大きくする調整を行う調整手段を、さらに備え、
前記第２の送信手段は、前記コネクション型の通信プロトコルによる前記映像情報の再送要求回数が所定の回数以下であって、前記映像情報のフレームレートが前記所定の値の場合に、前記映像情報を、前記コネクション型の通信プロトコルからコネクションレス型の通信プロトコルに切り替えて送信する、
請求項８に記載の映像送信装置。
【請求項１０】
第２の送信手段は、前記コネクション型の通信プロトコルと、前記コネクションレス型の通信プロトコルと、の間を切り替える際に、前記コネクション型の通信プロトコル、及び前記コネクションレス型の通信プロトコルより上位階層の通信プロトコルで、前記映像情報の再送信の要不要を検出し、必要であると判定された場合に当該映像情報を再送信する、
を特徴とする請求項１乃至９のいずれか一つに記載の映像送信装置。
【請求項１１】
前記伝送路は無線伝送路を含む、
を特徴とする請求項１乃至１０のいずれか一つに記載の映像送信装置。
【請求項１２】
伝送路を介して接続された通信装置に対して、音声情報と映像情報とを、コネクションレス型の通信プロトコルを用いて送信する第１の送信ステップと、
前記映像情報の表示で満足していないことが示された所定のリクエストを受信する受信ステップと、
前記受信ステップが前記所定のリクエストを受信した場合に、前記映像情報のフレームレートが小さくなるよう調整する調整ステップと、
前記通信装置に対して、前記調整ステップにより調整された後の前記映像情報を、前記コネクションレス型の通信プロトコルからコネクション型の通信プロトコルに切り替えて送信すると共に、前記音声情報について前記コネクションレス型の通信プロトコルによる送信を維持する第２の送信ステップと、
を備える映像送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、映像送信装置、及び映像送信方法に関する。
【背景技術】
【０００２】
従来から、インターネットなどの公衆ネットワークを介して、ユーザ間を接続するビデオ通話システムや、複数のユーザが参加可能な電子会議システムが提案されている。
【０００３】
これらシステムを介して、音声コンテンツと共に、映像コンテンツを伝達する場合、転送速度が速いが信頼性の低いコネクションレス型の通信プロトコルであるＵＤＰ（User  Datagram  Protocol）等が用いられる。ＵＤＰは、処理が簡単で遅延が少ないという利点を有している。ＵＤＰを用いることで、映像情報を伝達する際に、ほぼリアルタイムで伝達できる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２００９−５１０９６８
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、映像コンテンツは音声コンテンツと比べて通信レートが大きい必要がある。このため、従来技術である、ＵＤＰ等のコネクションレス型の通信プロトコルを用いた場合、伝送線路上での帯域の制約があると，音声は送れても、映像はあきらめざるを得ないという状況が生じていた。
【０００６】
本発明は、上記に鑑みてなされたものであって、送信された映像コンテンツの表示を補償する映像送信装置、及び映像送信方法を提供する。
【課題を解決するための手段】
【０００７】
実施形態の映像送信装置は、第１の送信手段と、受信手段と、調整手段と、第２の送信手段と、を備える。第１の送信手段は、伝送路を介して接続された通信装置に対して、音声情報と映像情報とを、コネクションレス型の通信プロトコルを用いて送信する。受信手段は、映像情報の表示で満足していないことが示された所定のリクエストを受信する。調整手段は、受信手段が所定のリクエストを受信した場合に、映像情報のフレームレートが小さくなるよう調整する。第２の送信手段は、通信装置に対して、調整手段により調整された後の映像情報を、コネクションレス型の通信プロトコルからコネクション型の通信プロトコルに切り替えて送信すると共に、前記音声情報について前記コネクションレス型の通信プロトコルによる送信を維持する。
【図面の簡単な説明】
【０００８】
【図１】図１は、第１の実施形態にかかるネットワーク構成の第１の例を示した図である。
【図２】図２は、第１の実施形態にかかるネットワーク構成の第２の例を示した図である。
【図３】図３は、第１の実施形態にかかるネットワーク構成の第３の例を示した図である。
【図４】図４は、第１の実施形態にかかるユーザ端末の構成を示したブロック図である。
【図５】図５は、第１の実施形態にかかるユーザ端末における映像コンテンツの送信処理の手順を示すフローチャートである。
【図６】図６は、第１の実施形態にかかる複数のユーザ端末の間における通信処理の手順を示すシーケンスである。
【図７】図７は、第１の実施形態にかかる複数のユーザ端末の間における通信処理の手順を示すシーケンスである。
【図８】図８は、第２の実施形態にかかるユーザ端末の構成を示したブロック図である。
【図９】図９は、第２の実施形態にかかるユーザ端末における映像コンテンツの送信処理の手順を示すフローチャートである。
【図１０】図１０は、第２の実施形態にかかる複数のユーザ端末の間における通信処理の手順を示すシーケンスである。
【図１１】図１１は、第２の実施形態にかかる複数のユーザ端末の間における通信処理の手順を示すシーケンスである。
【発明を実施するための形態】
【０００９】
（第１の実施形態）
以下、実施形態について図面を参照して説明する。以下に示す実施形態では、映像送信装置として、個々のユーザ端末で実現されている。ユーザ端末としては、携帯型パーソナルコンピュータ、携帯電話端末、スマートフォン、タブレット型端末装置など様々な装置が適用できる。
【００１０】
図１は、第１の実施形態にかかるネットワーク構成の第１の例を示した図である。図１に示す様に、ユーザ端末１００−１、１００−２が設けられている。そして、ユーザ端末１００−１、１００−２は、無線ＬＡＮ−ＡＰ／コントローラ／ルータ１６０−１、１６０−２を介して公衆ネットワーク１５０と接続されている。かかるネットワーク構成を備えていることで、ユーザ端末１００−１、及びユーザ端末１００−２の間でデータの送受信を可能としている。
【００１１】
図１に示す例では、データの送受信を１対１で行う例を示した。しかしながら、本実施形態は、データの送受信を１対１に制限するものではなく、多対多であってもよい。
【００１２】
図２は、第１の実施形態にかかるネットワーク構成の第２の例を示した図である。図２に示す様に、ユーザ端末１００−１、１００−２、１００−３、１００−４、１００−５、１００−６が設けられている。そして、ユーザ端末１００−１〜１００−６は、無線ＬＡＮ−ＡＰ／コントローラ／ルータ１６０−１、１６０−２を介して公衆ネットワーク１５０と接続されている。
【００１３】
例えば、ユーザ端末１００−１が、Source機器として音声コンテンツ及び映像コンテンツを送信する場合に、他のユーザ端末１００−２〜１００−６が、Sink機器として、受信した音声コンテンツ及び映像コンテンツを表示する。各ユーザ機器１００−２〜１００−６は、Source機器及びSink機器としての機能を有する。そして、ユーザ端末１００−１〜１００−６間で、音声コンテンツ及び映像コンテンツの送受信が行われることで、電子会議システムを実現できる。
【００１４】
図２では、個々のユーザ端末１００−１〜１００−６が、他のユーザ端末の各々に対して、音声コンテンツ及び映像コンテンツを伝送している例について説明した。しかしながら、このような手法に制限するものではない。例えば、グループオーナ端末が、小規模ネットワーク内のユーザ端末の映像コンテンツ及び音声コンテンツをまとめた上で、公衆ネットワークを介して、他のグループオーナ端末との間で、映像コンテンツ及び音声コンテンツを送受信しても良い。
【００１５】
図３は、第１の実施形態にかかるネットワーク構成の第３の例を示した図である。図３に示す様に、ユーザ端末１００−１、１００−２、１００−３、１００−４が設けられている。そして、グループオーナ端末３００−１は、ユーザ端末１００−１、１００−２の映像コンテンツ及び音声コンテンツをまとめて、他のグループオーナ端末３００−２に対して送信する。そして、他のグループオーナ端末３００−２は、受信した映像コンテンツ及び音声コンテンツを、ユーザ端末１００−３、１００−４に受け渡す。このように、グループオーナ端末３００−１、３００−２が、複数のユーザ端末の映像コンテンツ及び音声コンテンツをまとめて制御することで、各ユーザ端末の負担、及びネットワークの負担を軽減できる。また、ユーザ端末１００−１（１００−３）とユーザ端末１００−２（１００−４）との間においても、映像コンテンツ及び音声コンテンツの送受信は行われる。これにより、各ユーザ端末は、他のユーザ端末との間で映像コンテンツ及び音声コンテンツの送受信が行われるため、電子会議システムを実現できる。グループオーナを設けることで、ネットワーク上は、図１の１対１通信を行っているのと同じ状態になり、ネットワーク経由のデータ授受が容易になる。
【００１６】
本実施形態にかかるユーザ端末１００−１〜１００−６は、他のユーザ端末に対して、音声コンテンツを送信する際にコネクションレス型の通信プロトコルを用いる。そして、本実施形態にかかるユーザ端末１００−１〜１００−６は、他のユーザ端末に対して、映像コンテンツを送信する際、コネクション型の通信プロトコル、及びコネクションレス型の通信プロトコルを、必要に応じて切り替えることとした。
【００１７】
コネクション型の通信プロトコルは、通信量が増えるが再送機能を有する。本実施形態では、コネクション型の通信プロトコルとして、ＴＣＰ（Transmission  Control  Protocol）を用いる。
【００１８】
コネクションレス型の通信プロトコルは、再送機能は有していないが通信量が小さくなるという利点を有している。本実施形態では、コネクションレス型の通信プロトコルとしてＵＤＰ（User  Datagram  Protocol）を用いる。
【００１９】
ところで、映像コンテンツの転送は、音声コンテンツと比べて、通信量が大きくなる。このため、ＵＤＰを用いて通信量を少なくしたとしても、ユーザ端末間のネットワーク回線上の制約があれば、音声コンテンツは送信できても、映像コンテンツにはブロックノイズの混入等が生じる。場合によっては、映像コンテンツが視聴に堪えられなくなり、視聴をあきらめざるを得ないという状況が生じていた。
【００２０】
このように、従来は、映像コンテンツを送信するために、コネクションレスの通信プロトコルを用いていた。これに対して、本実施形態では、伝送路の許容通信レートが低い場合、コネクションレス型の通信プロトコルの代わりに、コネクション型の通信プロトコルを用いることとした。なお、音声コンテンツの送信は、従来と同様に、コネクションレス型の通信プロトコルを用いる。
【００２１】
つまり、コネクション型の通信プロトコル（例えばＴＣＰ）は、コネクションレス型の通信プロトコル（例えばＵＤＰ）と比べて、通信量が増加するが、再送機能を有している。このため、回線の通信容量が低い場合でも再送機能を利用することで、ブロックノイズを多く含む不明瞭な映像コンテンツの代わりに、ブロックノイズのない明瞭な映像コンテンツを提供することができる。
【００２２】
ただし、コネクション型の通信プロトコル（例えばＴＣＰ）を用いると、通信量が増加するため、通信容量が低い回線でも映像コンテンツを送信できるように、映像コンテンツのフレームレートを下げる制御も併せて行う。
【００２３】
これにより、ユーザ端末は、送信元との間の伝送路の通信容量が小さい場合でも、ブロックノイズを多く含む不明瞭な映像コンテンツではなく、フレームレートが低くてもブロックノイズのない明瞭な映像コンテンツを受信することが可能となる。
【００２４】
次に、ユーザ端末１００−１〜１００−６の各構成について説明する。図４は、本実施形態にかかるユーザ端末１００−１、１００−２の構成を示したブロック図である。以下、ユーザ端末１００−１について主に説明するが、他のユーザ端末１００−２〜１００−６も同様の構成を備え、同様の処理が可能なものとして、説明を省略する。
【００２５】
図４に示すユーザ端末１００−１は、Ｉ／Ｏ４０１と、画像音声入出力部４０２と、制御部４０３と、時計部４０４と、映像コンテンツ処理部４０５と、音声コンテンツ処理部４０６と、記憶部４０７と、制御コマンド生成部４０８と、パケット処理部４０９と、通信処理部４１０と、バッファ４１１と、ネットワークインターフェース部４１２と、を備えている。
【００２６】
画像音声入出力部４０２は、（図示しない）表示部、マイク、スピーカ、及びカメラを備え、マイクから収音された音声情報の入力、カメラからの映像情報の入力、表示部に対して映像情報の出力、スピーカに対する音声情報の出力を行う。
【００２７】
制御部４０３は、ユーザ端末１００−１を制御するＣＰＵ（Central  Processing  Unit）等の制御部と、各種データや各種プログラムを記憶するＲＯＭ（Read  Only  Memory）、及びＲＡＭ（Random  Access  Memory）等の主記憶部を備え、各種プログラムを実行することで、様々な制御を実現する。
【００２８】
時計部４０４は、現在の日時を計時し、掲示された日時を示した情報を制御部４０３に出力する。
【００２９】
記憶部４０７は、ＨＤＤ等のハードウェア構成で実現され、様々なデータを記憶する。
【００３０】
本実施形態にかかる制御部４０３は、映像送信プログラムを実行することで、調整部４５１と、判定部４５２と、を実現する。
【００３１】
判定部４５２は、映像コンテンツを送信するために用いる通信プロトコルを、コネクション型の通信プロトコル、又はコネクションレス型の通信プロトコルにするかを判定する。例えば、映像コンテンツの送信先であるユーザ端末１００−２〜１００−６において、表示されている映像コンテンツの品質で問題ある場合に、判定部４５２は、コネクション型の通信プロトコルを用いると判定する。当該品質に問題があるかは、例えば、他のユーザ端末１００−２〜１００−６からリクエストを受け付けたか否かに応じて判定する。
【００３２】
調整部４５１は、他のユーザ端末１００−２〜１００−６に送信する映像コンテンツのフレームレートを調整する。例えば、調整部４５１は、再送信を繰り返している場合、映像コンテンツのフレームレートを下げるように調整する。一方、調整部４５１は、再送信があまり行われていない場合に、映像コンテンツのフレームレートを上げるように調整する。
【００３３】
映像コンテンツ処理部４０５は、映像コンテンツに関する様々な処理を行う。例えば、映像コンテンツ処理部４０５は、送信する映像コンテンツのエンコード処理や、受信した映像コンテンツのデコード処理等を行う。音声コンテンツ処理部４０６は、音声コンテンツに関する様々な処理を行う。
【００３４】
制御コマンド生成部４０８は、他のユーザ端末１００−２〜１００−６を制御するための制御コマンドを生成する。例えば、制御コマンド生成部４０８は、コネクションレス型の通信プロトコル及びコネクション型の通信プロトコルの間を切り替えるための修正リクエストを生成する。本実施形態では、他のユーザ端末１００−２〜１００−６から映像コンテンツを取得するためのＧＥＴ式のリクエストを生成する。
【００３５】
パケット処理部４０９は、通信パケットを処理する。パケット処理部４０９は、他のユーザ端末１００−２〜１００−６に送信する際に、映像コンテンツ及び音声コンテンツをパケット単位で分割し、プロトコル毎に適したヘッダを添付する。本実施形態では、パケット処理部４０９は、分割した音声コンテンツに対して、ＵＤＰヘッダを割り当て、ＵＤＰパケットを生成する。また、パケット処理部４０９は、分割した映像コンテンツに対して、ＴＣＰヘッダ又はＵＤＰヘッダを割り当て、ＴＣＰパケット又はＵＤＰパケットを生成する。
【００３６】
また、パケット処理部４０９は、他のユーザ端末１００−２〜１００−６から受信したＵＤＰパケット及びＴＣＰパケットに含まれているデータを結合し、映像コンテンツ及び音声コンテンツを生成する。
【００３７】
通信処理部４１０は、伝送路（公衆ネットワーク１５０）を介して接続されたユーザ端末１００−２〜１００−６との間でデータの送受信を行う。
【００３８】
本実施形態にかかる通信処理部４１０は、映像コンテンツの送信開始時に、ユーザ端末１００−２〜１００−６に対して、映像コンテンツを、コネクションレス型の通信プロトコル（例えばＵＤＰ）を用いて送信する。また、通信処理部４１０は、音声コンテンツも同様に、コネクションレス型の通信プロトコル（例えばＵＤＰ）を用いて送信する。
【００３９】
そして、伝送路の通信容量と比べて、映像コンテンツの通信量が大きい場合（送信先で映像コンテンツが満足に表示されていない場合）、通信処理部４１０は、ユーザ端末１００−２〜１００−６から、映像コンテンツの表示で満足していないことが示された修正リクエストを受信する。本実施形態では、ユーザ端末１００−２〜１００−６から、ＧＥＴ式によるリクエストを受信する。
【００４０】
当該リクエストを受信した場合に、本実施形態にかかるユーザ端末１００−１は、修正リクエストを送信してきたユーザ端末１００−２〜１００−６に適した送信に切り替える。これにより、伝送路の前後でデータを一時的に保存しておくためのバッファの容量オーバーのおそれなく、映像コンテンツを伝送できる。
【００４１】
また、映像コンテンツの送信手法を切り替えるための修正リクエストは、ＧＥＴ式のリクエストに制限するものではなく、ユーザ端末１００−２〜１００−６で映像コンテンツが満足に表示されてないことが認識できる情報であればよい。例えば、修正リクエストは、映像コンテンツの送信先のユーザ端末１００−２〜１００−６で、ユーザから、映像コンテンツが表示されていないものとして入力された操作データでもよい。さらには、この操作データと、ＧＥＴ式と、を組み合わせても良い。 
【００４２】
また、通信プロトコルを切り替えるための修正リクエストとして、ユーザ端末１００−２〜１００−６で表示された（現在の表示状態を表した）画像データであってもよい。さらには、ユーザ端末１００−２〜１００−６から送信されたテキスト若しくはメールでもよい。また、修正リクエストは、ユーザ端末１００−１を利用するユーザに対する通知でも良く、例えば、ユーザ端末１００−２〜１００−６から情報を受信したことを示す受信音、若しくはバイブレータによる振動等であっても良い。この場合、ユーザ端末１００−１を使用するユーザが、通信プロトコルを切り替えるための操作を行うこととなる。
【００４３】
また、修正リクエストは、ＧＥＴ型に制限するものではない。変形例としては、自装置内からのＰＵＳＨ型リクエストを用いることも考えられる。例えば、ユーザ端末１００−１内に自装置内に（図示しない）レート測定部を備え、レート測定部が、映像コンテンツの送信先との伝送路の伝送レートを監視して、制御コマンド生成部４０８が、監視結果である伝送レートに応じてＰＵＳＨ型リクエストを発行する。そして、通信処理部４１０が、当該ＰＵＳＨ型のリクエストを受け取った後、第１の実施形態と同様の調整を行う。また、ユーザ端末１００−１の制御コマンド生成部４０８は、コネクション型プロトコルで送信している際の送信先からのＡＣＫの受信状態に応じてＰＵＳＨ型リクエストを発行しても良い。
【００４４】
そして、当該修正リクエストを受信した場合に、ユーザ端末１００−１の調整部４５１が映像コンテンツのフレームレートを下げる調整を行う。なお、フレームレートを下げる調整は、修正リクエストを送信してきたユーザ端末に限っても良いし、全てのユーザ端末に対して行っても良い。
【００４５】
そして、通信処理部４１０は、ユーザ端末１００−２〜１００−６に対して、調整部４５１により調整された後の映像コンテンツを、コネクションレス型の通信プロトコル（例えばＵＤＰ）からコネクション型の通信プロトコル（ＴＣＰ）に切り替えて送信すると共に、音声コンテンツについてコネクションレス型の通信プロトコル（ＵＤＰ）による送信を維持する。換言すると、通信処理部４１０は、映像コンテンツの送信に用いる通信プロトコルを上述のように切り替えつつ、音声コンテンツの送信に関しては常時コネクションレス型の通信プロトコルを用いても良い。
【００４６】
本実施形態にかかるユーザ端末１００−１は、映像コンテンツをコネクション型の通信プロトコル（ＴＣＰ）で送信を開始することで、再送要求回数をモニタリングすることが可能となる。そして、調整部４５１が、再送要求回数に応じてフレームレートを調整する。
【００４７】
本実施形態では、コネクション型の通信プロトコルに切り替えた後、判定部４５２が、単位時間あたりの再送（要求）回数が所定の回数以下であるか否かを判定する。そして、再送（要求）回数が所定の回数以下の場合に、フレームレートを漸増させる。これにより、フレームレートが所定の値に達したにも拘わらず、判定部４５２が、単位時間あたりの再送（要求）回数が所定の回数以下であると判定した場合に、伝送路が回復したと判断し、再びコネクションレス型の通信プロトコル（ＵＤＰ）に切り替える。
【００４８】
また、本実施形態にかかるコネクション型とコネクションレス型との切り替えは、トランスポーテーションレイヤーよりも上位レイヤーでの再送制御を用いても良い。これにより、伝送中であってもシームレスに切り替えることが可能となる。
【００４９】
このように、本実施形態では、Source機器側となるユーザ端末１００−１が、コネクションレス型の通信プロトコル、及びコネクション型の通信プロトコルのどちらを利用するかを決めることが可能となる。
【００５０】
バッファ４１１は、送信するパケットを一時的に記憶する。または、バッファ４１１は、受信したパケットを一時的に記憶する。
【００５１】
ネットワークインターフェース部４１２は、無線ＬＡＮ−ＡＰ／コントローラ／ルータ１６０−１と接続するためのインターフェースとする。接続する手法としては、無線、有線を問わず、データの送受信が可能となればよい。
【００５２】
また、本実施形態では、最初から、映像コンテンツと、音声コンテンツとをそれぞれ別セッションで送信しているが、最初は映像コンテンツと音声コンテンツとをまとめて送信しておき、修正リクエストの受信をトリガとして、映像コンテンツと音声コンテンツとをそれぞれ別のセッションとして送信を開始しても良い。
【００５３】
このように、本実施形態においては、伝送路中でボトルネックとなる通信容量が、映像コンテンツをリアルタイムで伝送するコネクションレス型の通信プロトコルでの伝送を満足しなくなった場合に、ユーザ端末１００−２〜１００−６からの修正リクエストに応じて、コネクション型の通信プロトコルに切り替えることとした。そして、コネクション型の通信プロトコルを利用する際、再送要求回数に応じてフレームレートを調節して、送信先が満足する映像コンテンツの送信を実現した。
【００５４】
また、ユーザ端末１００−１からの映像コンテンツを受信するユーザ端末１００−２も、ユーザ端末１００−１と同様の構成を有し、同様の処理を実現するものとして説明を省略する。
【００５５】
次に、本実施形態にかかるユーザ端末１００−１における、映像コンテンツの送信処理について説明する。図５は、本実施形態にかかるユーザ端末１００−１における上述した処理の手順を示すフローチャートである。なお、音声コンテンツは、送信開始時から終了するまでコネクションレス型の通信プロトコルを用いて送信するものとして、図５に示す処理では、説明を省略する。
【００５６】
まず、ユーザ端末１００−１の通信処理部４１０が、映像コンテンツの送信先である通信装置（例えば、ユーザ端末１００−２〜１００−６）との間で、接続手続きを行う（ステップＳ５０１）。
【００５７】
次に、ユーザ端末１００−１の通信処理部４１０が、接続されたユーザ端末間で相互の能力を交換するケイパビリティ交換を行う（ステップＳ５０２）。
【００５８】
次に、ユーザ端末１００−１の通信処理部４１０が、映像コンテンツを送信するために、コネクションレス型の通信プロトコル（例えばＵＤＰ）によるセッションの準備した後、当該セッションを開始する（ステップＳ５０３）。
【００５９】
その後、通信処理部４１０が、映像コンテンツの送信先である通信装置（例えば、ユーザ端末１００−２〜１００−６）との間で、コネクションレス型の通信プロトコル（例えばＵＤＰ）による通信開始制御を行う（ステップＳ５０４）。
【００６０】
その後、通信処理部４１０は、他の通信装置（例えば、ユーザ端末１００−２〜１００−６）に対する映像コンテンツの伝達を継続するか否かの判定する（ステップＳ５０５）。継続しないと判定した場合（ステップＳ５０５：Ｎｏ）、処理を終了する。
【００６１】
一方、映像コンテンツの伝達を継続すると判定した場合（ステップＳ５０５：Ｙｅｓ）、判定部４５２が、他の通信装置（例えば、ユーザ端末１００−２〜１００−６）から、映像コンテンツに満足していないことを表す修正リクエストを受け付けた（受信した）か否かを判定する（ステップＳ５０６）。修正リクエストを受け付けていない場合（ステップＳ５０６：Ｎｏ）、再びステップＳ５０５から開始する。
【００６２】
そして、判定部４５２が、修正リクエストを受け付けたと判定した場合（ステップＳ５０６：Ｙｅｓ）、調整部４５１が、送信する映像コンテンツのフレームレートを下げる修正を行う（ステップＳ５０７）。なお、フレームレートの下げ幅は、実施の態様に併せて定められた値でよいが、好ましくは、フレームレートの下げ幅は、コネクションレス型の通信プロトコルからコネクション型の通信プロトコルに切り替えにより、増加するであろう再送を含む通信容量より、大きい値に設定することが望ましい。こうすることで、通信プロトコルの切り替えにより、トータルの通信量を削減できる。
【００６３】
さらに、通信処理部４１０が、コネクション型の通信プロトコルによる通信のための準備を行った後、通信開始制御を行う（ステップＳ５０８）。この際に、パケット処理部４０９が生成するパケットも、ＵＤＰパケットからＴＣＰパケットに切り替わる。
【００６４】
その後、判定部４５２が、コネクション型の通信プロトコルからコネクションレス型の通信プロトコルに復帰する復帰設定があるか否かを判定する（ステップＳ５０９）。復帰設定がない場合（ステップＳ５０９：Ｎｏ）、通信処理部４１０は、他の通信装置（例えば、ユーザ端末１００−２〜１００−６）に対する映像コンテンツの伝達を終了するか否かの判定する（ステップＳ５１２）。そして、伝達を終了しないと判定した場合（ステップＳ５１２：Ｎｏ）、映像コンテンツの伝達を継続し、再びステップＳ５０９の処理を行う。一方、伝達を終了すると判定した場合（ステップＳ５１２：Ｙｅｓ）、映像コンテンツの伝達を終了する。
【００６５】
また、ステップＳ５０９において、復帰設定がある場合（ステップＳ５０９：Ｙｅｓ）、判定部４５２は、所定時間単位での、他の通信装置（例えば、ユーザ端末１００−２〜１００−６）からの映像コンテンツの再送要求回数が、所定値より小さいか否かを判定する（ステップＳ５１０）。所定値以上と判定した場合（ステップＳ５１０：Ｎｏ）、映像コンテンツの伝達を継続し、再びステップＳ５０９の処理を行う。
【００６６】
一方、判定部４５２が、映像コンテンツの再送要求回数が、所定値より小さいと判定した場合（ステップＳ５１０：Ｙｅｓ）、伝送路の通信容量が回復したものとして、コネクションレス型の通信プロトコルによる、ＵＤＰセッションへの復帰を準備し、ＵＤＰセッションによる通信制御を再開する（ステップＳ５１１）。その際に、調整部４５１が、送信する映像コンテンツのフレームレートを調整しても良い。その後、再びステップＳ５０４から処理を開始する。
【００６７】
上述した一連の処理手順により、映像コンテンツが満足に表示できない場合に、フレームレートこそ下がるが、コネクション型の通信プロトコルの再送機能等を用いることで送信先での映像コンテンツの表示が可能となる。さらに、伝送路の通信容量が所定容量に回復した際には、フレームレートを増加させることや、伝送路の状況によっては、コネクションレス型の通信プロトコルに切り替えることで、ユーザ端末１００−１の利用する伝送路の許容する最適範囲で、映像コンテンツを送れることになる。なお、所定容量は実施の態様に応じて定められるものとする。
【００６８】
なお、図５に示すフローチャートでは、ユーザ端末１００−１が修正リクエストを受け付けて、自動的に切り替える例について説明したが、修正リクエストをユーザ端末１００−１の利用者宛に送信し、当該修正リクエストを受け付けた利用者が、手動でコネクションレス型の通信プロトコルから、コネクション型の通信プロトコルに切り替えても良い。また、ユーザ端末１００−１の制御部４０３は、映像送信に用いている通信プロトコルを示すＧＵＩや、送信する映像コンテンツのフレームレートを示すＧＵＩを生成し、表示部に表示させても良い。
【００６９】
次に、本実施形態にかかるユーザ端末１００−１及びユーザ端末１００−２の間における通信処理について説明する。図６及び図７は、本実施形態にかかるユーザ端末１００−１及びユーザ端末１００−２の間における上述した処理の手順を示すシーケンスである。なお、音声コンテンツの伝送ではコネクションレス型の通信プロトコルを用いた通信制御を行うものとして、図６及び図７で示すシーケンスでは説明を省略する。
【００７０】
まず、ユーザ端末１００−１の通信処理部４１０が、映像コンテンツの送信先であるユーザ端末１００−２との間で、接続手続きを行う（ステップＳ６０１）。
【００７１】
次に、ユーザ端末１００−１の通信処理部４１０が、接続されたユーザ端末１００−２との間で相互の能力を交換するケイパビリティ交換を行う（ステップＳ６０２）。
【００７２】
なお、フロー中の、ケイパビリティの交換は必ずしもここで必要としない場合もある。そのときは、ステップＳ６０２の処理をしても良い。
【００７３】
次に、ユーザ端末１００−１の通信処理部４１０が、接続されたユーザ端末１００−２との間で、映像コンテンツを送信するためのコネクションレス型プロトコル、（例えばＵＤＰ）によりセッションの準備した後、当該ＵＤＰセッションを開始する（ステップＳ６０３）。
【００７４】
その後、通信処理部４１０が、ユーザ端末１００−２との間で、コネクションレス型の通信プロトコル（例えばＵＤＰ）による通信開始制御を行う（ステップＳ６０４）。
【００７５】
そして、ユーザ端末１００−１は、ユーザ端末１００−２に対して、映像コンテンツが格納された第１〜第５パケットを送信する（ステップＳ６０５〜Ｓ６０９）。これら送信したパケットのうち、第２パケットと第４パケットの送信（ステップＳ６０６、Ｓ６０８）でエラーが生じたものとする。
【００７６】
このエラーにより、映像コンテンツが満足に表示されなくなる。そこで、ユーザ端末１００−２は、ユーザから映像に満足できない旨の入力を受け付ける（ステップＳ６１０）。なお、映像に満足できない旨をユーザから入力を受け付ける例について説明したが、受信したパケットでユーザ端末１００−２の判定部４５２が、通信パケットの受信状態等に基づいて、映像に満足できるか否かを判定しても良い。
【００７７】
これにより、ユーザ端末１００−２の通信処理部４１０が、ユーザ端末１００−１に対して、修正リクエストを送信する（ステップＳ６１１）。
【００７８】
当該修正リクエストを受信したユーザ端末１００−１の調整部４５１が、送信する映像コンテンツのフレームレートを下げる修正を行う（ステップＳ６１２）。
【００７９】
さらに、ユーザ端末１００−１の通信処理部４１０は、ユーザ端末１００−２との間で、コネクション型の通信プロトコルによるＴＣＰ（コネクション型）セッションのための準備を行った後、当該ＴＣＰセッションを開始する（ステップＳ６１３）。
【００８０】
その後、通信処理部４１０が、ユーザ端末１００−２との間で、コネクション型の通信プロトコル（例えばＴＣＰ）による通信開始制御を行う（ステップＳ６１４）。
【００８１】
そして、ユーザ端末１００−１は、ユーザ端末１００−２に対して、映像コンテンツが格納された第６〜第９パケットを送信する（ステップＳ６１５〜Ｓ６１８）。これら送信したパケットのうち、第７パケットと第９パケットの送信（ステップＳ６１６、Ｓ６１８）でエラーが生じたものとする。
【００８２】
そして、ユーザ端末１００−２の通信処理部４１０が、ユーザ端末１００−１に対して、第６パケット及び第８パケットに対応するＡＣＫを返信する（ステップＳ６１９、Ｓ６２０）。
【００８３】
ステップＳ６１９〜Ｓ６２０のＡＣＫより、第７パケットの送信でエラーが生じたことが確認できたため、ユーザ端末１００−１の通信処理部４１０が、ユーザ端末１００−２に対して、第７パケットを再送信する（ステップＳ６２１）。さらに、ユーザ端末１００−１の通信処理部４１０が、ユーザ端末１００−２に対して、第１０パケットを送信する（ステップＳ６２２）。
【００８４】
そして、ユーザ端末１００−２の通信処理部４１０が、ユーザ端末１００−１に対して、第７パケット及び第１０パケットに対応するＡＣＫを返信する（ステップＳ６２３、Ｓ６２４）。
【００８５】
ステップＳ６２０、Ｓ６２４のＡＣＫより、第９パケットの送信でエラーが生じたことが確認できたため、ユーザ端末１００−１の通信処理部４１０が、ユーザ端末１００−２に対して、第９パケットを再送信する（ステップＳ６２５）。なお、この再送信でもエラーが生じたものとする。
【００８６】
そして、第９パケットのＡＣＫが所定時間返されない場合に、ユーザ端末１００−１の通信処理部４１０が、第９パケットの再々送信を行う（ステップＳ６２６）。そして、ユーザ端末１００−２の通信処理部４１０が、ユーザ端末１００−１に対して、第９パケットに対応するＡＣＫを返信する（ステップＳ６２７）。これにより、第１〜第１０パケットの送信が完了する。
【００８７】
その後、ユーザ端末１００−１の通信処理部４１０が、ユーザ端末１００−２に対して、第１１〜１４パケットを送信する（ステップＳ６２８〜Ｓ６３１）。そして、ユーザ端末１００−２の通信処理部４１０が、ユーザ端末１００−１に対して、第１１〜１４パケットに対応するＡＣＫを返信する（ステップＳ６３２〜Ｓ６３５）。
【００８８】
さらに、ユーザ端末１００−１の通信処理部４１０が、ユーザ端末１００−２に対して、第１５パケットを送信する（ステップＳ６３６）。そして、ユーザ端末１００−２の通信処理部４１０が、ユーザ端末１００−１に対して、第１５パケットに対応するＡＣＫを返信する（ステップＳ６３７）。
【００８９】
その後、ユーザ端末１００−１の判定部４５２が、再送要求回数が所定値以下であるか否かを判定する（ステップＳ６３８）。図７に示すシーケンスでは、所定値以下であると判定されたものとする。
【００９０】
そこで、判定部４５２が、コネクションレス型の通信プロトコルを使用するプロトコルとして選択する（ステップＳ６３９）。
【００９１】
そして、ユーザ端末１００−１の通信処理部４１０が、コネクションレス型の通信プロトコルによる、ＵＤＰセッションへの復帰を準備し、ＵＤＰセッションによる通信制御を再開する（ステップＳ６４０）。
【００９２】
その後、通信処理部４１０が、コネクションレス型の通信プロトコルによる通信開始制御を行う（ステップＳ６４１）。
【００９３】
これにより、ユーザ端末１００−１の通信処理部４１０が、ユーザ端末１００−２に対して、ＵＤＰを用いて第１６〜第１９パケットを送信する（ステップＳ６４２〜Ｓ６４５）。
【００９４】
上述したように、ＴＣＰに切り替えてからは、再送機能を用いることで映像コンテンツを欠落することなく送信できる。また、電子会議システムにおいては、音声コンテンツのリアルタイム性と比べると、映像コンテンツのリアルタイム性の優先度は低いので、再送機能を用いることで映像コンテンツのリアルタイム性が低減しても、映像コンテンツの確実な表示が可能となるため、利便性が向上する。
【００９５】
ところで、本実施形態では、セッションを切断せずに通信プロトコルを切り替えても良い。この場合に、通信処理部４１０が、コネクション型の通信プロトコルと、前記コネクションレス型の通信プロトコルと、の間を切り替える際に、コネクション型の通信プロトコル、及びコネクションレス型の通信プロトコルより上位階層の通信プロトコルで、映像コンテンツの再送信の要不要を検出し、必要であると判定された場合に当該映像コンテンツを再送信する。上位層のプロトコルとしては、例えば、ＳＩＰやＲＴＣＰがある。
【００９６】
本実施形態では、説明を容易にするために、映像コンテンツを送信するSource機器と、映像コンテンツを受信するSink機器と、をそれぞれ分けて説明した。しかしながら、実際の会議システム等においては、ユーザ端末１００−１〜１００−６は、Source機器であると同時に、Sink機器として機能してもよい。このように、ユーザ端末１００−１〜１００−６は、同時に双方向に映像コンテンツ及び音声コンテンツの通信を行ってもよい。
【００９７】
上述した実施形態では修正リクエストの様々な態様について説明したが、通信プロトコルを切り替えるためのコマンドに制限するものではなく、映像コンテンツの表示が要求を満たしていないことを、ユーザ端末１００−１のユーザに認知させ、当該ユーザによる対処を期待させるリクエストでも良い。例えば、チャットのテキスト、メール、送信先のユーザ端末で表示された画像や、当該画像のサムネイルでもよい。なお、後述する変形例等についても同様とする。
【００９８】
なお、本実施形態では、映像コンテンツと音声コンテンツの同期方法については記載していないが、タイムスタンプとなる伝送情報を利用する、あるいは機器内のタイマーを使うなどの方法を用いることで、ある程度の精度での同期は可能である。
【００９９】
ユーザに認知させるリクエストを用いることで、SINK機器側のユーザ端末でどのように表示されているかを、SOUCE機器側のユーザ端末１００−１で把握することができる。これにより、ユーザの操作により、映像コンテンツの表示に改善を図ることができる。また、相手側でどのように表示されているかを認識できるために、遠隔通信によるユーザの不安感を軽減できる。
【０１００】
本実施形態では、調整部４５１が、通信プロトコルを切り替える際に、映像コンテンツの通信量を削減するために、フレームレートを下げる制御を行っていた。しかしながら、通信量を削減するための手法を、フレームレートを下げることに制限するものではなく、例えば、解像度や色深度を小さくすることで、データ量を低下させても良い。
【０１０１】
（第１の実施形態の変形例１）
上述した実施形態では、送信先からのユーザ端末からのＧＥＴ式のリクエストに応じて、映像コンテンツを伝送する例について説明した。しかしながら、ＧＥＴ式のリクエストに制限するものではなく、送信元のユーザ端末から、ＰＵＳＨ式のリクエストで、映像コンテンツを伝送しても良い。これにより、メーカが異なるなどの理由により、Source機器側のユーザ端末が認識可能なリクエストを発行できない場合でも、Source機器側から映像コンテンツを伝送することができる。
【０１０２】
（第１の実施形態の変形例２）
上述した実施形態では、修正リクエストが、切り替えるためのコマンドや、ユーザに認識させるための情報である場合について説明した。しかしながら、修正リクエストはこれらに制限するものではなく、伝送路の状態であってもよい。
【０１０３】
例えば、ユーザ端末１００−１が、映像コンテンツの送信先のユーザ端末において測定された伝送路のデータ伝送レートを、修正リクエストとして受信し、当該データ伝送レートが所定値よりも小さい場合に通信プロトコルを切り替えても良い。
【０１０４】
さらには、ユーザ端末１００−１が、自装置内にレート測定部を備え、レート測定部により測定された伝送路のデータ転送レートを修正リクエストとして、判定部４５２に出力してもよい。そして、判定部４５２は、修正リクエストに含まれているデータ伝送レートにより、通信プロトコルを切り替えるか否か判定しても良い。このように、Source機器側で伝送路のデータ伝送レートを測定することで、他の機器からの通知を待たずに、映像コンテンツを送信可能であるか否かを判定できる。
【０１０５】
（第１の実施形態の変形例３）
また、修正リクエストが、映像コンテンツの送信先のユーザ端末で現在表示された静止画や映像コンテンツであってもよい。そして、伝送路の品質を確認するために、送信元のユーザ端末１００−１が、送信する映像コンテンツを、複製又は補間などの手段を用いて、単位時間当たりの枚数を増やした状態，あるいは画像一枚当たりのデータサイズを大きくした状態に変換させた（換言すれば、通信量を増加させた）のち、伝送路を介して、Sink機器側のユーザ端末に映像コンテンツを送信しても良い。
【０１０６】
そして、Sink機器側のユーザ端末から、映像コンテンツの表示結果が、静止画又は映像コンテンツとして、Source機器側に送信される。この表示結果を修正リクエストとして用いる。これにより、Source機器側のユーザ端末１００−１が、伝送路の状態、再送の有無、あるいは，伝送された映像コンテンツが所定の品質を満足するか否かを認識できる。
【０１０７】
このように、伝送路の通信レートを図る手段として、当該変形例では、映像コンテンツのサイズを送信前に意図的に大きくすることとした。そして、送信先でどのように表示されているのか確認することで、伝送路の品質を把握することができる。当該処理を定期的に行うことで、経時変化を伴う伝送路の状態を把握できる。伝送路の状態を把握することで、映像コンテンツを送信する際に、伝送路の状態に応じたフレームレートに調整することが可能となる。これにり、送信先のユーザ端末の満足度が高い映像コンテンツの送信が可能となる。
【０１０８】
（第１の実施形態の変形例４）
第１の実施形態の変形例４にかかるユーザ端末では、Source機器となるユーザ端末１００−１において、バッファ４１１の容量を監視する監視部を備え、当該監視部による監視結果（バッファ４１１における映像コンテンツのパケットの蓄積状態）を、通信プロトコルを切り替えるためのリクエストとして受け付ける。そして、ユーザ端末では、受け付けたリクエスト、換言すればバッファ４１１の容量に基づいて、通信処理部４１０が送信する映像コンテンツの通信プロトコルを切り替える。
【０１０９】
具体的には、判定部４５２が、当該監視結果から、バッファ４１１の容量が所定の容量以上を占めているか否かを判定する。所定の容量以上の場合に、映像コンテンツの送信が適切に行われておらず、送信先では映像コンテンツが満足に表示されていないものとして、通信プロトコルをコネクションレス型の通信プロトコルからコネクション型の通信プロトコルに切り替える。これにより、Sink機器側のユーザ端末１００−２〜１００−６からリクエストを受け取らずとも、Sink機器側に併せた通信プロトコルの切替を可能とする。
【０１１０】
（第２の実施形態）
第１の実施形態では、映像コンテンツについては、コネクションレス型の通信プロトコルを用いて通信を開始し、必要に応じて、コネクション型の通信プロトコルに切り替える例について説明した。しかしながら、最初にコネクションレス型の通信プロトコルで通信する手法に制限するものではなく、必要に応じて通信プロトコルを切り替えればよい。そこで、第２の実施形態では、映像コンテンツの送信として、コネクション型の通信プロトコルを用いた上、フレームレートを下げた状態で伝送を開始する例について説明する。
【０１１１】
図８は、本実施形態にかかるユーザ端末８００−１、８００−２の構成を示したブロック図である。図８に示す、本実施形態にかかるユーザ端末８００−１、８００−２は、上述した第１の実施形態にかかるユーザ端末１００−１、１００−２とは、通信処理部４１０、制御部４０３とは処理が異なる通信処理部８０２、制御部８０１に変更されている。
【０１１２】
ユーザ端末８００−１の通信処理部８０２は、映像コンテンツの送信を開始する際に、コネクション型の通信プロトコル（例えば、ＴＣＰ）を用いて送信を開始する。なお、音声コンテンツは、コネクションレス型の通信プロトコル（例えば、ＵＤＰ）を用いて送信する。
【０１１３】
制御部８０１は、調整部８５１と、判定部８５２と、を備える。
【０１１４】
そして、本実施形態にかかるユーザ端末８００−１の判定部８５２は、通信処理部８０２がコネクション型の通信プロトコルで通信を開始した後、映像コンテンツの再送信が多いか否かを判定する。
【０１１５】
本実施形態では、判定部８５２が、コネクション型の通信プロトコルによる映像コンテンツの再送要求回数が所定の回数以下であるか否かを判定する。そして、再送要求回数が所定の回数より多い、つまり、再送信が多いと判定した場合に、伝送路の状態が良くないものとみなす。その場合、調整部８５１は、映像コンテンツのフレームレートを維持するか、フレームレートをさらに下げる調整を行う。
【０１１６】
一方、判定部８５２が、再送要求回数が所定の回数以下であると判定した場合、映像コンテンツのフレームレートが、最大値として定められたフレームレートより小さい場合には、調整部８５１がフレームレートを大きくする調整を行う。
【０１１７】
その後、さらに、判定部８５２が、再送要求回数が所定の回数以下であるか否かを判定する。最大のフレームレートに上げても、再送要求回数が所定の回数以下に収まる場合、伝送路は十分なレートを確保されている状態にあると判断し、ユーザ端末８００−１は、映像コンテンツの送信に用いる通信プロトコルを、コネクション型の通信プロトコルから、コネクションレス型の通信プロトコルに切り替える。なお、フレームレート上げる際の判定基準となる所定の回数と、通信プロトコルを変える際の基準となる所定の回数とは、同じ回数であっても良いし、異なる回数であっても良い。
【０１１８】
以後、ユーザ端末８００−１の通信処理部８０２は、コネクションレス型の通信プロトコルを用いて、ユーザ端末８００−２に対して映像コンテンツを送信すると共に、音声コンテンツについてはコネクションレス型の通信プロトコルによる送信を維持する。言い換えると通信処理部８０２は、映像コンテンツの送信に用いる通信プロトコルを上述のように切り替えつつ、音声コンテンツの送信に関しては常時コネクションレス型の通信プロトコルを用いても良い。
【０１１９】
次に、本実施形態にかかるユーザ端末８００−１における、映像コンテンツの送信処理について説明する。図９は、本実施形態にかかるユーザ端末８００−１における上述した処理の手順を示すフローチャートである。なお、音声コンテンツは、送信開始時から終了するまでコネクションレス型の通信プロトコルを用いて送信するものとして、図９に示す処理では、説明を省略する。
【０１２０】
まず、ユーザ端末８００−１の通信処理部８０２が、映像コンテンツの送信先である通信装置（例えば、ユーザ端末８００−２）との間で、接続手続きを行う（ステップＳ９０１）。
【０１２１】
次に、ユーザ端末８００−１の通信処理部８０２が、接続されたユーザ端末間で相互の能力を交換するケイパビリティ交換を行う（ステップＳ９０２）。
【０１２２】
次に、ユーザ端末８００−１の通信処理部８０２が、映像コンテンツを送信するためのＴＣＰセッションの準備した後、当該ＴＣＰセッションを開始する（ステップＳ９０３）。
【０１２３】
その後、調整部８５１が、送信する映像コンテンツに対する初期フレームスキッピング量を設定する（ステップＳ９０４）。
【０１２４】
その後、通信処理部８０２が、映像コンテンツの送信先である通信装置（例えば、ユーザ端末８００−２）との間で、コネクション型の通信プロトコル（例えばＴＣＰ）による通信開始制御を行う（ステップＳ９０５）。
【０１２５】
その後、通信処理部８０２は、他の通信装置（例えば、ユーザ端末８００−２）に対する映像コンテンツの伝達を継続するか否かの判定する（ステップＳ９０６）。継続しないと判定した場合（ステップＳ９０６：Ｎｏ）、処理を終了する。
【０１２６】
一方、映像コンテンツの伝達を継続すると判定した場合（ステップＳ９０６：Ｙｅｓ）、判定部８５２は、他の通信装置（例えば、ユーザ端末８００−２）からの、映像コンテンツの再送要求回数が所定値より小さいか否かを判定する（ステップＳ９０７）。映像コンテンツの再送要求回数が所定値以上と判定された場合（ステップＳ９０７：Ｎｏ）、再びステップＳ９０６から開始する。なお、ステップＳ９０６に戻る際に、調整部８５１は、映像コンテンツのフレームレートをさらに下げる調整を行っても良い。
【０１２７】
そして、映像コンテンツの再送要求回数が所定値より小さいと判定した場合（ステップＳ９０７：Ｙｅｓ）、判定部８５２は、送信する映像コンテンツのフレームレートが、最大値であるか否かを判定する（ステップＳ９０８）。なお、フレームレートの最大値とは、送信可能なフレームレートとして予め定められた最大値をいう。
【０１２８】
そして、判定部８５２が最大値ではないと判定した場合（ステップＳ９０８：Ｎｏ）、調整部８５１は、映像コンテンツのフレームレートを予め定められた幅だけ増加させる（ステップＳ９０９）。その後、再びステップＳ９０６から開始する。
【０１２９】
一方、判定部８５２がフレームレートが最大値であると判定した場合（ステップＳ９０８：Ｙｅｓ）、判定部８５２は、さらに、通信プロトコルを切り替えるための切替設定がなされているか否かを判定する（ステップＳ９１０）。切替設定がなされていないと判定した場合（ステップＳ９１０：Ｎｏ）、通信処理部８０２は、他の通信装置（例えば、ユーザ端末８００−２）に対する映像コンテンツの伝達を終了するか否かの判定する（ステップＳ９１３）。そして、伝達を終了しないと判定した場合（ステップＳ９１３：Ｎｏ）、映像コンテンツの伝達を継続し、再びステップＳ９１３の処理を行う。伝送終了すると判定した場合（ステップＳ９１３：Ｙｅｓ）、映像コンテンツの伝送を停止して、処理を終了する。
【０１３０】
また、ステップＳ９１０において、切替設定がある場合（ステップＳ９１０：Ｙｅｓ）、判定部８５２は、所定時間単位での、他の通信装置（例えば、ユーザ端末８００−２）からの映像コンテンツの再送要求回数が、所定値より小さいか否かを判定する（ステップＳ９１１）。所定値以上と判定した場合（ステップＳ９１１：Ｎｏ）、映像コンテンツの伝達を継続し、再びステップＳ９１０の処理を行う。
【０１３１】
一方、判定部８５２が、映像コンテンツの再送要求回数が、所定値より小さいと判定した場合（ステップＳ９１１：Ｙｅｓ）、通信処理部８０２は、コネクションレス型の通信プロトコルによる、ＵＤＰセッションへの復帰を準備し、ＵＤＰセッションによる通信制御を再開する（ステップＳ９１２）。
【０１３２】
その後、通信処理部８０２は、他の通信装置（例えば、ユーザ端末８００−２）に対する映像コンテンツの伝達を終了するか否かの判定する（ステップＳ９１３）。そして、伝達を終了しないと判定した場合（ステップＳ９１３：Ｎｏ）、映像コンテンツの伝達を継続し、再びステップＳ９１３から処理を行う。伝送終了すると判定した場合（ステップＳ９１３：Ｙｅｓ）、映像コンテンツの伝送を停止して、処理を終了する。
【０１３３】
次に、本実施形態にかかるユーザ端末８００−１及びユーザ端末８００−２の間における通信処理について説明する。図１０及び図１１は、本実施形態にかかるユーザ端末８００−１及びユーザ端末８００−２の間における上述した処理の手順を示すシーケンスである。なお、音声コンテンツの伝送ではコネクションレス型の通信プロトコルを用いた通信制御を行うものとして、図１０及び図１１で示すシーケンスでは説明を省略する。
【０１３４】
まず、ユーザ端末８００−１の通信処理部８０２が、映像コンテンツの送信先であるユーザ端末８００−２との間で、接続手続きを行う（ステップＳ１００１）。
【０１３５】
次に、ユーザ端末８００−１の通信処理部８０２が、接続されたユーザ端末８００−２との間で相互の能力を交換するケイパビリティ交換を行う（ステップＳ１００２）。
【０１３６】
次に、ユーザ端末８００−１の通信処理部８０２が、接続されたユーザ端末８００−２との間で、映像コンテンツを送信するためのＴＣＰセッションの準備した後、当該ＴＣＰセッションを開始する（ステップＳ１００３）。
【０１３７】
その後、通信処理部８０２が、ユーザ端末８００−２との間で、コネクション型の通信プロトコル（例えばＴＣＰ）による通信開始制御を行う（ステップＳ１００４）。
【０１３８】
そして、ユーザ端末８００−１は、ユーザ端末８００−２に対して、映像コンテンツが格納された第１〜第２パケットを送信する（ステップＳ１００５、Ｓ１００６）。ステップＳ１００５、Ｓ１００６では、所定時間ΔＴ内に、２個のパケットを送信している。
【０１３９】
そして、ユーザ端末８００−２の通信処理部８０２が、ユーザ端末８００−１に対して、第１パケット及び第２パケットに対応するＡＣＫを返信する（ステップＳ１００７、Ｓ１００８）。
【０１４０】
その後、判定部８５２は、当該返信結果に基づいて、再送要求回数が所定値以下であると判定する。そして、調整部８５１が映像コンテンツのフレームレートを増加させる制御を行う（ステップＳ１００９）。フレームレートの増加により、送信するパケットの数が増加する。
【０１４１】
よって、ユーザ端末８００−１は、ユーザ端末８００−２に対して、映像コンテンツが格納された第３〜第６パケットを送信する（ステップＳ１０１０〜Ｓ１０１３）。ステップＳ１０１０〜Ｓ１０１３では、所定時間ΔＴ内に、４個のパケットを送信している。
【０１４２】
そして、ユーザ端末８００−２の通信処理部８０２が、ユーザ端末８００−１に対して、第３〜第６パケットに対応するＡＣＫを返信する（ステップＳ１０１４〜Ｓ１０１７）。
【０１４３】
その後、判定部８５２は、当該返信結果に基づいて、再送要求回数が所定値以下であると判定する。そして、調整部８５１が映像コンテンツのフレームレートを増加させる制御を行う（ステップＳ１０１８）。フレームレートの増加により、送信するパケットの数が増加する。
【０１４４】
そして、ユーザ端末８００−１は、ユーザ端末８００−２に対して、映像コンテンツが格納された第７〜第１２パケットを送信する（ステップＳ１０１９〜Ｓ１０２４）。ステップＳ１０１９〜Ｓ１０２４では、所定時間ΔＴ内に、６個のパケットを送信している。
【０１４５】
そして、ユーザ端末８００−２の通信処理部８０２が、ユーザ端末８００−１に対して、第７〜第１２パケットに対応するＡＣＫを返信する（ステップＳ１０２５〜Ｓ１０３０）。
【０１４６】
その後、判定部８５２は、当該返信結果に基づいて、再送要求回数が所定値以下であると判定するが、フレームレートが最大値となっているため、フレームレートの変更は行われずに、パケット送信が継続する。
【０１４７】
そして、ユーザ端末８００−１は、ユーザ端末８００−２に対して、映像コンテンツが格納された第１３〜第１８パケットを送信する（ステップＳ１０３１〜Ｓ１０３６）。
【０１４８】
そして、ユーザ端末８００−２の通信処理部８０２が、ユーザ端末８００−１に対して、第１３〜第１８パケットに対応するＡＣＫを返信する（ステップＳ１０３７〜Ｓ１０４２）。
【０１４９】
その後、判定部８５２は、再送要求回数が所定値以下であるため、コネクション型の通信プロトコルから、コネクションレス型の通信プロトコルの利用を選択する（ステップＳ１０４３）。
【０１５０】
次に、ユーザ端末８００−１の通信処理部８０２が、接続されたユーザ端末８００−２との間で、映像コンテンツを送信するためのＵＤＰセッションの準備した後、当該ＵＤＰセッションを開始する（ステップＳ１０４４）。
【０１５１】
その後、通信処理部８０２が、ユーザ端末８００−２との間で、コネクションレス型の通信プロトコル（例えばＵＤＰ）による通信開始制御を行う（ステップＳ１０４５）。
【０１５２】
そして、ユーザ端末８００−１の通信処理部８０２が、コネクションレス型の通信プロトコル（例えばＵＤＰ）を用いて、ユーザ端末８００−２に対して、第１９〜第３０パケットを送信する（ステップＳ１０４６〜Ｓ１０５７）。
【０１５３】
また、本実施形態では、第１の実施形態と同様に、セッションを切断せずに、コネクション型の通信プロトコルと、コネクションレス型の通信プロトコルと、の間を切り替えてもよい。この場合に、コネクション型の通信プロトコル、及びコネクションレス型の通信プロトコルより上位階層の通信プロトコルで、再送の要不要を検出し、必要であると判定された場合に再送させることとした。上位層のプロトコルとしては、例えば、ＳＩＰやＲＴＣＰがある。
【０１５４】
本実施形態においては、映像コンテンツについて、最初はコネクション型の通信プロトコルを利用し、再送要求回数に応じて、フレームスキッピングの程度を調整し、フレームレートが最大でも問題がない場合に、コネクションレス型のプロトコルに切り替えることとした。これにより、送信先が満足できる映像コンテンツを提供可能にすると共に、コネクションレス型の通信プロトコルに切り替えることで、処理負担を軽減できる。
【０１５５】
（第２の実施形態の変形例１）
第２の実施形態は、再送要求回数に応じて、フレームレートの増加や、コネクションレス型の通信プロトコルに切り替える例について説明した。しかしながら、再送要求回数切り替える例に制限するものではなく、第１の実施形態と同様にリクエストでフレームレートの増加や通信プロトコルを切り替えても良い。
【０１５６】
第２の実施形態の変形例１としては、ユーザ端末が、最初コネクション型の通信プロトコル（例えばＴＣＰ）で映像コンテンツを送信し、送信先のユーザ端末からの映像コンテンツが問題なく表示されている旨（または映像コンテンツの品質を上げて欲しい旨）が示されたリクエストを受信した場合に、フレームレートの増加や、コネクションレス型の通信プロトコルへの切り替え等を行う。リクエストの種類は、第１の実施形態と同様に様々な態様が考えられる。さらに、通信プロトコルの切り替え手順等は第２の実施形態と同様として説明を省略する。
【０１５７】
（第２の実施形態の変形例２）
本実施形態では再送要求回数に応じて、フレームレートや通信プロトコルを切り替える例について説明した。しかしながら、再送要求回数に制限するものではなく、例えば、Source機器側のバッファ４１１に蓄積された映像コンテンツのパケットの量に応じて切り替えても良い。そこで、第２の実施形態の変形例２としては、Source機器側のユーザ端末８００−１において、判定部８５２が、バッファ４１１にパケットが所定容量以上蓄積されたと判定した場合には、伝送路が混雑しているものとして、調整部８５１がフレームレートを下げる調整を行う。そして、判定部８５２が、バッファ４１１にパケットが蓄積記されていないと判定した場合には、伝送路が込んでいないものとして、調整部８５１がフレームレートを上げる調整を行う、又は通信処理部８０２が送信する通信プロトコルを、コネクション型の通信プロトコルからコネクションレス型の通信プロトコルに切り替える。
【０１５８】
本変形例では、バッファ４１１に映像コンテンツが溢れた場合に、送信先の映像コンテンツの表示が満足できるものであるはずがないため、通信プロトコルを切り替える。これにより、送信先で視聴に堪える映像コンテンツの転送を、簡易な構成で実現できる。
【０１５９】
上述した実施形態では、ＴＣＰに切り替えた後に再送機能により、送信された映像コンテンツに関する情報を認識する例について説明した。しかしながら、既存技術として、コネクションレス型の通信プロトコルＵＤＰにＲＴＰおよびＲＴＣＰを実装することで、送信された映像コンテンツに関する情報を、Source側のユーザ端末に送信することもできる。
【０１６０】
しかしながらセッション制御のためのＲＴＣＰの実装が必要なことや、ＲＴＣＰのSource機器側へ送るレポートの遅延が大きいなどの課題があり、コネクション型の通信プロトコルＴＣＰを用いた転送のほうが簡易である。
【０１６１】
従来技術においては、伝送経路のボトルネックが生じたことで、映像コンテンツを伝送するための帯域を確保できない場合、当該映像コンテンツの送信先では、ブロックノイズが映像に多く混入し，視聴に堪えない状況になっていた。
【０１６２】
これに対して、上述した実施形態及び変形例においては、視聴に耐えないという状況になるのを抑止し、映像コンテンツのフレームレートこそ低下するものの、明瞭な映像を提供することが可能となる。
【０１６３】
また、従来、混雑状況により時間的にゆるやかに変動する伝送路の通信レートに応じてフレームレートを調整することは困難であった。これに対して、上述した実施形態にかかるユーザ端末は、SOURCE端末側で調整が可能となる。これにより、伝送路の帯域が映像コンテンツの伝送に堪えられない場合でも、フレームレートを調整したり、通信プロトコルを切り替えることで、ブロックノイズが抑止された映像コンテンツを提供することが可能となる。このようにして、送信先での映像コンテンツの表示を補償できる。
【０１６４】
従来、映像コンテンツや音声コンテンツの伝送に用いられるコネクションレス型の通信プロトコル（例えばＵＤＰ）の代わりに、上述した実施形態では、映像コンテンツの伝送にコネクション型の通信プロトコルを用いることとした。これにより、映像コンテンツの遅延こそ許すものの、映像コンテンツを欠落なく伝送できる。
【０１６５】
従来は、映像コンテンツを伝送にエラーが生じても、再送信していなかった。これに対して、上述した実施形態では、映像コンテンツの欠落部分の再送要求を繰り返すことで、送信先では、映像コンテンツを欠落無く表示することが可能となる。SOURCE機器側での端末からのフレームスキッピングをすることにより，受信側で適切なレートでの画像切り替えが可能となる。
【０１６６】
また、コネクション型の通信プロトコルを利用する際に、フレームレートを下げることで、伝送路の負荷を削減できる。これにより、伝送路が細い場合において、フレームレートは遅くてもブロックノイズのない明瞭な映像を受信できる。
【０１６７】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１６８】
１００−１〜１００−６，８００−１，８００−２…ユーザ端末、１５０…公衆ネットワーク、１６０−１，１６０−２…無線ＬＡＮ−ＡＰ／コントローラ／ルータ、３００−１，３００−２…グループオーナ端末、４０１…Ｉ／Ｏ、４０２…画像音声入出力部、４０３，８０１…制御部、４０４…時計部、４０５…映像コンテンツ処理部、４０６…音声コンテンツ処理部、４０７…記憶部、４０８…制御コマンド生成部、４０９…パケット処理部、４１０，８０２…通信処理部、４１１…バッファ、４１２…ネットワークインターフェース部、４５１，８５１…調整部、４５２，８５２…判定部
【図１】
2014027613.tif 000003
【図２】
2014027613.tif 000004
【図３】
2014027613.tif 000005
【図４】
2014027613.tif 000006
【図５】
2014027613.tif 000007
【図６】
2014027613.tif 000008
【図７】
2014027613.tif 000009
【図８】
2014027613.tif 000010
【図９】
2014027613.tif 000011
【図１０】
2014027613.tif 000012
【図１１】
2014027613.tif 000013