JP5979886B2

JP5979886B2 - 送信装置及び送信方法

Info

Publication number: JP5979886B2
Application number: JP2012007458A
Authority: JP
Inventors: 亨強矢
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2012-01-17
Filing date: 2012-01-17
Publication date: 2016-08-31
Anticipated expiration: 2032-01-17
Also published as: US8959178B2; US20130185391A1; JP2013150074A

Description

本発明は送信装置及び送信方法に関し、特に、データ配信に制限がある場合に、より公平に無駄なくデータ送信を行うために用いて好適な技術に関する。

近年、動画像や音声などのマルチメディアデータを、ＩＰネットワークを利用してストリーミング配信し、視聴する技術が実用化されている。特に、ライブ映像などのリアルタイム性を必要とするマルチメディアデータを配信する際には、ＲＴＰと呼ばれる通信プロトコルが一般に使用されている。ＲＴＰは、A Transport Protocol for Real-Time Applicationsである。

ＲＴＰは、主に音声や動画像などをリアルタイムでデータ転送するためのプロトコルであり、ＩＥＴＦによりＲＦＣ３５５０として定義されている。ＲＴＰは、非コネクション型のプロトコルであるＵＤＰ(User Datagram Protocol)の上位プロトコルである。ＲＴＰを用いて動画像や音声のデータをパケット化して通信する場合、一般に、ネットワークに流れるＲＴＰパケットのことをストリームデータ、或いはメディアストリームなどと呼ぶ。

このＲＴＰを用いたメディアストリームの開始や終了など、いわゆる通信セッションの制御を行うためのプロトコルとして、一般にＲＴＳＰと呼ばれるプロトコルが用いられる。ＲＴＳＰ（Real Time Streaming Protocol）は、ＩＥＴＦによりＲＦＣ２３２６として定義されている。例えば、特許文献１には、ＲＴＳＰ（Real Time Streaming Protocol）やＳＩＰ（Session Initiation Protocol）などを使用してセッションを制御する技術が提案されている。

ところで、ＲＴＳＰでセッション制御を行うサーバは、同時に接続可能なセッション数を制限している場合がある。制限している理由には色々あるが、例えばストリームデータを配信するサーバのリソースの問題や、ネットワークの通信帯域の問題などが挙げられる。サーバがＲＴＳＰのセッション数を制限している場合、セッション数が制限に達した後に接続を要求したクライアントは、サーバに接続を拒否されてしまう。つまり、ＲＴＳＰによる通信制御では、接続予約の様な概念が無いため、セッション数に制限がある環境では、一般に早い者勝ちで接続できるクライアントが決定される。

また、一般に、サーバに接続を拒否された時点で、接続要求を拒否されたクライアントとサーバ間のＲＴＳＰのセッションは切断されてしまうため、クライアントはその後のサーバの状況を知ることができない。しかし、何らかの状況変化により、ＲＴＳＰのセッション数が制限数を下回れば、ＲＴＳＰによる接続を希望するクライアントはそのタイミングで接続要求を行えばサーバに接続することができる。

特開２０１１−２１１３９０号公報

しかし、実際にはサーバと接続していないクライアントはサーバの状況をリアルタイムには把握できない。このため、接続が可能か否かを確認するために、場合によっては何度も無駄に接続の試行を繰り返すケースや、或いは接続可能なタイミングを逃してしまうケースがある。
本発明は前述の問題点に鑑み、無駄に接続の試行を行うことを回避することを目的とする。

本発明の送信装置は、要求に応じてコンテンツを送信する送信装置であって、要求元からコンテンツの要求を受信する受信手段と、前記受信手段が第１形式のコンテンツの要求を所定数受信した後に前記第１形式のコンテンツの新たな要求を受信した場合に、前記所定数の要求に応じて送信されるコンテンツの少なくとも何れかの形式を前記第１形式とは異なる第２形式とすることを決定する決定手段と、前記決定手段による決定に基づいて、前記受信手段が受信した前記所定数の要求及び前記新たな要求の要求元へコンテンツを送信する送信手段とを有することを特徴とする。

本発明によれば、ストリームの配信数に制限がある通信環境において、配信を拒否された受信装置が無駄に配信要求を繰り返すことを無くすことができる。

第１の実施形態の送信装置の構成例を示すブロック図である。配信要求を受信した際の処理内容の一例を示すフローチャートである。新たに配信が可能になった際の処理内容の一例を示すフローチャートである。コンテンツの最大配信数が３で、受信装置が５つの場合の処理の一例を説明する図である。プロトコルにＲＴＰとＲＴＳＰを使用する１つ目の例を説明する図である。プロトコルにＲＴＰとＲＴＳＰを使用する２つ目の例を説明する図である。 VideoとAudioの２つを配信するケースを示す図である。 Videoを代替可能とする受信装置が存在する際の例を説明する図である。 Videoを代替可能とする受信装置が存在する際の別の例を説明する図である。

以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
＜第１の実施形態＞
本実施形態の送信装置を構成するコンピュータ装置の構成について、図１のブロック図を参照して説明する。なお、送信装置や受信装置はそれぞれ単一のコンピュータ装置で実現してもよいし、必要に応じた複数のコンピュータ装置に各機能を分散して実現するようにしてもよい。複数のコンピュータ装置で構成される場合は、互いに通信可能なようにLocal Area Network（ＬＡＮ）などで接続されている。

図１において、送信装置１００は、データパケット生成部１０１、通信制御部１０２、配信可否判定部１０３、配信要求データ記憶部１０４、パケット送受信部１０５から構成されている。
データパケット生成部１０１は、例えばＲＴＰプロトコルを用いて通信する場合、外部から入力された動画像や音声の符号化されたデータを、通信に適したサイズに分割する。更に、通信するために必要なヘッダを付加してパケット化し、ＲＴＰのデータパケットを生成する。

通信制御部１０２は、配信可否判定部１０３からの指示に従って、受信装置との新たな接続を許可、または拒否するための制御を行う。
配信可否判定部１０３は、例えば送信装置１００が同時に配信可能な受信装置の数を管理し、受信装置から新たにデータ配信の要求を受けた場合に、その受信装置へのデータ配信の可否を判定する。
配信要求データ記憶部１０４は、配信可否判定部１０３で配信要求を拒否した場合に、拒否した配信要求の情報を一時的に記憶するための記憶部である。

次に、本実施形態の送信装置１００による配信制御の詳細について、図２及び図３を用いて説明する。
図２及び図３は、本実施形態の送信装置１００における配信制御の一例を示すフローチャートであり、図２は受信装置から配信要求を受信した際の処理内容の一例を示しており、図３は図２の処理後に新たに配信が可能になった場合の処理内容の一例を示している。

まず図２に示すように、Ｓ２０１では、送信装置１００は受信装置からの配信要求を受信する。
Ｓ２０２では、配信可否判定部１０３において配信数が上限に達しているか判定する。Ｓ２０２の判定の結果、配信数が上限に達していなければＳ２０５に進み、配信可否判定部１０３は配信を許可し、通信制御部１０２は配信許可に基づいて配信処理を行う。

一方、Ｓ２０２の判定の結果、配信数が上限に達している場合はＳ２０３に進み、配信可否判定部１０３は配信を拒否する判定を行い、受信装置には配信を拒否することを通知する。本実施形態では、送信装置１００から配信要求を拒否された受信装置は、配信要求の許可を待つ状態となっている。

次に、Ｓ２０４では、配信可否判定部１０３は、拒否した配信要求の情報を配信要求データとして配信要求データ記憶部１０４に保管する。配信要求データには、配信要求を行った受信装置のＩＰアドレスや、要求されたコンテンツの情報などが含まれる。

続いて図３を用いて、図２のフローチャートで配信を拒否した後の処理内容を説明する。
まずＳ３０１では、配信可否判定部１０３は、配信要求データ記憶部１０４を参照することで、配信待ちの受信装置が存在するか判定する。配信待ちの受信装置が存在する場合は、Ｓ３０２に進み、存在しない場合は処理を終了する。

Ｓ３０２では、配信可否判定部１０３は、新たに配信が可能になるまで待機し、配信数の減少などにより新たに配信が可能になったらＳ３０３に進む。
Ｓ３０３では、配信要求データを参照し、配信待ちの受信装置が複数存在するか判定する。この判定の結果、配信待ちの受信装置が複数存在する場合はＳ３０４に進み、存在しない場合はＳ３０５に進む。
Ｓ３０４では、複数の受信装置間の配信優先度を算出する。

次に、Ｓ３０５では、配信優先度に基づいて、配信待ちの受信装置に配信を許可する通知を行う。配信を許可する通知を受けた受信装置は、改めて送信装置１００に配信要求を行うことで、コンテンツを受信することができる。

次に、図２及び図３を用いて説明した処理の流れの一例について、図４を用いて説明する。図４は、コンテンツの最大配信数が３で、受信装置が５つの場合の処理の一例を示している。
図４において、受信装置１〜５は送信装置に対して順次配信を要求しているが、最大配信数が３のため、受信装置４と５の配信要求は拒否され、Ａのタイミングでは、受信装置１〜３に対してコンテンツの配信が行われている。

次に、コンテンツを受信していた受信装置２が、セッションの切断を要求すると、送信装置はセッションを切断し受信装置２へのコンテンツの配信を停止すると共に、配信要求を拒否していた受信装置４へ、配信を許可することを通知する。配信を許可された受信装置４は、送信装置に改めて配信要求することで、コンテンツを受信することができる。

したがって、図４のＢのタイミングでは、配信を停止した受信装置２に代わって、受信装置４がコンテンツを受信している。
タイミングＢからＣにかけての処理は、タイミングＡからＢにかけての処理と同様に、コンテンツを受信していた受信装置１に代わって、受信装置５がコンテンツを受信する処理の流れを示している。
ところで、図４の例では、タイミングＡで配信待ちとなった受信装置４と５に優先度の差異はないものとし、単純に先着順を優先順として、先に配信要求を行っていた受信装置４に先に配信許可を通知している。

次に、使用するプロトコルの例として、ＲＴＰとＲＴＳＰを使用する場合の例を、図５及び図６を用いて説明する。
図５は、ＲＴＰとＲＴＳＰを使用する場合の１つ目の例である。制御の流れの説明を簡単にするため、図５では、送信装置からコンテンツを受信可能な受信装置の数は同時に１つだけとする。

図５において、受信装置１はＲＴＳＰのＤＥＳＣＲＩＢＥ及びＳＥＴＵＰメソッドによりＲＴＳＰのセッションを生成し、更にＰＬＡＹメソッドにより送信装置からのコンテンツ配信、即ち、ＲＴＰストリームの配信が開始される。この時点で、別の受信装置２からＲＴＳＰのＤＥＳＣＲＩＢＥメソッドによりセッション情報を要求された送信装置は、同時に２個の受信装置にコンテンツの配信を行えないため、エラー（図５の例では、406 Not Acceptable）を返す。

送信装置からエラーを返された受信装置２は、送信装置からの配信許可待ちの状態となり、ＲＴＳＰのコネクションは維持される。その後、受信装置１が例えばＲＴＳＰのＴＥＡＲＤＯＷＮメソッドによりコンテンツ配信の停止を要求した場合、送信装置は直ちに受信装置１へのコンテンツ配信を停止し、続いて受信装置２にコンテンツの配信が可能になったことを通知する。

この配信可能通知をＲＴＳＰで行う場合、ＲＴＳＰを定義しているＲＦＣ２３２６には特に適切なメソッドは無いので、送信装置側から受信装置側に使用可能なメソッドであるＡＮＮＯＵＮＣＥやＯＰＴＩＯＮＳ、ＲＥＤＩＲＥＣＴなどを利用する。
配信可能通知を受信した受信装置２は、改めてＤＥＳＣＲＩＢＥからＰＬＡＹまでのメソッドを使用して、コンテンツの配信が開始される。

ところで、配信可能通知は何らかの方法で受信装置２に通知できればよいので、ＲＴＳＰメソッドの使用は必須ではない。配信可能通知を行うＲＴＳＰ以外の方法としては、受信装置側が配信可能通知を受信するための通信ポートを開け、送信装置はそのポートに配信可能通知を送信する仕組みとしてもよい。また、その他の方法としては、送信装置と受信装置が共に参照可能なファイルに、送信装置が配信可能であることを通知する情報を書き込む方法でも、本実施形態の効果は得ることができる。

次に、プロトコルにＲＴＰとＲＴＳＰを使用するもう一つの例について図６を用いて説明する。
図６は、ＲＴＰとＲＴＳＰを使用する場合の２つ目の例である。制御の流れの説明を簡単にするため、図５と同様に図６でも、送信装置からコンテンツを受信可能な受信装置の数は同時に１つだけとする。

図６において、受信装置１がコンテンツを受信するまでの処理は図５と同様である。
続いて送信装置は、受信装置１に対してコンテンツを配信中に、受信装置２からＲＴＳＰメソッドによる配信要求を受信した場合に、図５のケースとは異なり、エラーを返さない。
しかし図６では、実際にコンテンツの配信を開始するのは、受信装置１への配信が停止された後に、受信装置２への配信を開始する。図６のケースでは、受信装置２への配信可能通知は行ってもよいが、省略することも可能である。

ところで、本実施形態では、一旦コンテンツの配信を拒否された受信装置は、送信装置からの配信可能通知を待つことになるが、この待ち時間を指定してもよい。待ち時間が設定されている場合、送信装置は、所定の時間以内に新たにコンテンツの配信が可能になった場合のみ、優先順位の高い受信装置から配信可能通知を行う。待ち時間は、受信装置側が指定してもよいし、送信装置側から指定してもよい。また、送信装置は、受信装置への配信可能通知後、一定時間反応が無い場合は、別の受信装置に配信可能通知を行うようにしてもよい。
また、送信装置は、通信帯域と要求されたメディアのビットレートを基に、データ配信の可否を判定する。

＜第２の実施形態＞
次に、本発明の第２の実施形態について、第１の実施形態との差異を中心に説明する。
前述の第１の実施形態では、配信するコンテンツに含まれるメディアが１種類のケースについて説明した。

これに対して、本実施形態では、コンテンツに複数のメディアが含まれるケースについて説明する。
図７は、配信可能なコンテンツにVideoとAudioの２つのメディアが存在するケースでの制御の流れを表す一例を示す図である。

図７において、VideoとAudioの２つのメディアは各々最大２セッションに配信可能であるとする。送信装置は、まず受信装置１からのVideoとAudioの配信要求に対し、VideoとAudioの双方のメディアの配信を開始する。

次に、受信装置２からのVideoの配信要求に対し、Videoの配信を開始する。
更に、受信装置３からVideoとAudioの配信要求を受けた場合、既にVideoは受信装置１と受信装置２の２つのセッションに対して配信中であるため、その時点で配信可能なAudioのみ配信を開始する。

その後、受信装置１がセッションの切断を要求してきた場合、受信装置１へ配信していたVideoとAudioの配信を止めることで、新たにVideoの配信が可能になり、一旦拒否していた受信装置３に対するVideoの配信を開始することができる。

ところで、受信装置が同時に複数のメディア配信を希望する場合の配信制御には、いくつかの方法が存在する。
１つ目の方法は、メディアを問わず、配信可能になったメディアから順次配信する方法であり、図７を用いて説明した本実施形態の一例はこのケースに該当する。
２つ目の方法は、希望するすべてのメディアが配信可能になった時点で、初めてメディアの配信を開始する方法である。
そして３つ目の方法は、特定のメディアが配信可能になった時点で、配信可能なメディアから配信を開始する方法である。

２つ目の方法と図７で説明した方法の差異は、受信装置３に対するAudioの配信開始のタイミングである。２つ目の方法であれば、図７の受信装置３は、受信装置１へ配信していたVideoとAudioの配信を停止した時点で、VideoとAudioの配信を共に開始することになる。

３つ目の方法の具体例としては、例えば特定のメディアがVideoであった場合に、Videoと共に受信する他のメディアが配信可能であっても、特定のメディアであるVideoが配信可能になるまでは、メディアの配信を開始しないケースも考えられる。

ところで、３つ目のケースは、１つ目のケースと組み合わせた方法も考えられる。
例えば、前述の特定のメディアがVideoであった場合に、Videoが配信可能であれば、とりあえずVideoのみでも配信を開始し、他のメディアの配信が可能になった時点で、順次他のメディアの配信を開始していくケースである。

次に、配信を要求するメディアの内、特定のメディアについて代替可能なメディアを指定する方法について説明する。
図８は、Videoの符号化形式に例えばＪＰＥＧとＨ.２６４の２種類が存在し、この２種類のメディアを代替可能とする受信装置が存在する場合の処理の一例について示したものである。

図８において、Ｈ.２６４は最大２セッションに配信可能であるとする。
受信装置１と受信装置２は、共にＨ.２６４の配信を要求しており、各々、要求後直ちにＨ.２６４のコンテンツを受信している。
その後、受信装置３は、Ｈ.２６４かＪＰＥＧの配信を要求しているが、この時点では受信装置１と受信装置２がＨ.２６４のコンテンツを受信しているため、受信装置３はＪＰＥＧの受信を開始する。

その後、受信装置１がセッションを切断する要求を行った時、送信装置は受信装置１へのセッションを切断すると共にＨ.２６４の配信を停止し、受信装置３へ送信していたコンテンツをＪＰＥＧからＨ.２６４へ切り替えている。

この受信装置３へ送信しているコンテンツの切替えは、受信装置３が代替可能なメディア種別間の優先順位を送信装置に伝えることで実現することも可能であるし、送信装置側の意図で任意にコンテンツを切り替えることも可能である。ところで、ＲＴＳＰで配信するコンテンツの切替えを行う場合、ＲＦＣ２３２６にはＡＮＮＯＵＮＣＥ等のメソッドを利用することが記述されている。

次に、送信装置から配信するコンテンツのメディア種別を切り替える別のケースについて図９を用いて説明する。
図９は、Videoの符号化形式にＪＰＥＧとＨ.２６４の２種類が存在し、この２種類のメディアを代替可能とする受信装置が存在する場合の処理のもう一つの例について示したものである。図９において、図８と同様にＨ.２６４は最大２セッションに配信可能であるとする。

まず、受信装置１は、送信装置にＨ.２６４の配信を要求し、Ｈ.２６４のコンテンツを受信している。
次に受信装置２は、代替可能なメディアとしてＨ.２６４かＪＰＥＧの配信を要求し、Ｈ.２６４のコンテンツの受信を開始する。

続いて受信装置３は、Ｈ.２６４の配信を要求するが、この時点で既に受信装置１と受信装置２にＨ.２６４のコンテンツを配信している。このため、送信装置は、受信装置２へ配信するコンテンツのメディア種別をＨ.２６４からＪＰＥＧに切替えると共に、受信装置３へＨ.２６４の配信を開始している。

図９の例は、送信装置が、受信装置毎に代替可能なメディアの種別を把握することで、既に配信していたコンテンツを切り替えることにより、メディア種別毎の最大配信数の制限を回避して、より多くの受信装置にコンテンツを配信する様子を示している。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（コンピュータプログラム）を、ネットワークまたは各種のコンピュータ読み取り可能な記憶媒体を介してシステム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１００送信装置、１０１データパケット生成部、１０２通信制御部、１０３配信可否判定部、１０４配信要求データ記憶部、１０５パケット送受信部

Claims

要求に応じてコンテンツを送信する送信装置であって、
要求元からコンテンツの要求を受信する受信手段と、
前記受信手段が第１形式のコンテンツの要求を所定数受信した後に前記第１形式のコンテンツの新たな要求を受信した場合に、前記所定数の要求に応じて送信されるコンテンツの少なくとも何れかの形式を前記第１形式とは異なる第２形式とすることを決定する決定手段と、
前記決定手段による決定に基づいて、前記受信手段が受信した前記所定数の要求及び前記新たな要求の要求元へコンテンツを送信する送信手段とを有することを特徴とする送信装置。
前記決定手段は、前記送信手段が前記決定に基づく前記第２形式のコンテンツの送信を終了する前に前記第１形式のコンテンツの送信のうち何れかを終了した場合に、前記送信手段により送信されるコンテンツのうち何れかの形式を前記第２形式から前記第１形式に変更することを決定することを特徴とする請求項１に記載の送信装置。
前記受信手段により受信されるコンテンツの要求の数は、前記送信手段が要求に応じてコンテンツを送信するために使用するＲＴＳＰセッションの数であることを特徴とする請求項１又は２に記載の送信装置。
前記受信手段により受信されるコンテンツの要求の数は、前記送信手段が要求に応じてコンテンツを送信する送信先の数であることを特徴とする請求項１又は２に記載の送信装置。
前記コンテンツは動画であり、前記第１形式及び前記第２形式はそれぞれ異なる符号化形式であることを特徴とする請求項１乃至４の何れか１項に記載の送信装置。
前記所定数は、前記送信手段により送信されるコンテンツのビットレートに基づいて定まることを特徴とする請求項１乃至５の何れか１項に記載の送信装置。
前記送信手段は、ＲＴＰプロトコルを用いて要求元へコンテンツを送信することを特徴とする請求項１乃至６の何れか１項に記載の送信装置。
送信装置が要求に応じてコンテンツを送信する送信方法であって、
要求元からコンテンツの要求を受信する受信工程と、
前記受信工程において第１形式のコンテンツの要求を所定数受信した後に前記第１形式のコンテンツの新たな要求を受信した場合に、前記所定数の要求に応じて送信されるコンテンツの少なくとも何れかの形式を前記第１形式とは異なる第２形式とすることを決定する決定工程と、
前記決定工程における決定に基づいて、前記受信工程において受信された前記所定数の要求及び前記新たな要求の要求元へコンテンツを送信する送信工程とを有することを特徴とする送信方法。
前記決定工程は、前記送信工程において前記決定に基づく前記第２形式のコンテンツの送信が終了する前に前記第１形式のコンテンツの送信のうち何れかが終了した場合に、前記送信工程において送信されるコンテンツのうち何れかの形式を前記第２形式から前記第１形式に変更することを決定することを特徴とする請求項８に記載の送信方法。
前記受信工程において受信されるコンテンツの要求の数は、前記送信工程において要求に応じてコンテンツを送信するために使用されるＲＴＳＰセッションの数であることを特徴とする請求項８又は９に記載の送信方法。
コンピュータを、請求項１乃至７の何れか１項に記載の送信装置として動作させるためのプログラム。