(57)【特許請求の範囲】
【請求項１】
受信デバイスで用いられる方法であって、
送信デバイスから入手可能な所定のストリームメディアデータを選択する工程と、
前記送信デバイスに対して、所定の要求エラー訂正レベルを有する要求メッセージを送信する工程と、
前記送信デバイスが前記送信した要求エラー訂正レベルを受け入れない場合には、異なる要求エラー訂正レベルを有する要求メッセージを送信し、該送信デバイスが所定の要求エラー訂正レベルの受け入れを決定するまで前記要求メッセージの送信を行う工程と、
前記送信デバイスから、前記ストリームメディアデータと、該データに対応する前記決定された所定の要求エラー訂正レベルに基づいて生成された所定のエラー訂正データとを受信する工程と、
前記受信した対応するエラー訂正データに基づいて、前記受信したストリームメディアデータ中に検出されたエラーを訂正する工程と
を具えたことを特徴とする方法。
【請求項２】
前記ストリームメディアデータを選択する工程は、
要求エラー訂正データ密度を指定することによって前記要求エラー訂正レベルを識別する工程を含むことを特徴とする請求項１記載の方法。
【請求項３】
前記要求エラー訂正データ密度を指定する工程は、
スパン内のストリームデータパケットの数を識別する工程と、
前記スパンに関連するエラー訂正データパケットの数を識別する工程と
を含むことを特徴とする請求項２記載の方法。
【請求項４】
前記スパン内のストリームデータパケットの数が約１と約２４の間であり、前記スパンに関連するエラー訂正データパケットの数が約１と約２４との間であることを特徴とする請求項３記載の方法。
【請求項５】
前記要求メッセージを送信する工程は、
リアルタイムストリーミングプロトコル（ＲＴＳＰ）セットアップメッセージを前記送信デバイスに送信する工程を含むことを特徴とする請求項１記載の方法。
【請求項６】
前記送信デバイスから送信されるストリームデータパケットおよびエラー訂正データパケットを受信する工程と、
前記受信したストリームデータパケットを複数含むスパンを、前記受信したエラー訂正データパケットの少なくとも１つに関連付ける工程と、
前記受信エラー訂正データパケットの中の前記少なくとも１つを使用して前記スパン中のエラーを必要に応じて訂正する工程と
をさらに具えたことを特徴とする請求項１記載の方法。
【請求項７】
前記スパンは、複数の連続的なストリームデータパケットを含むことを特徴とする請求項６記載の方法。
【請求項８】
前記スパンは、複数の不連続的なストリームデータパケットを含むことを特徴とする請求項６記載の方法。
【請求項９】
前記送信デバイスが連続的なストリームデータパケットを含む前記スパンに基づいて前記エラー訂正データパケットの中の前記少なくとも１つを生成するように、選択的に要求する工程をさらに具えたことを特徴とする請求項６記載の方法。
【請求項１０】
前記送信デバイスが不連続的なストリームデータパケットを含む前記スパンに基づいて前記エラー訂正データパケットの中の前記少なくとも１つを生成するように、選択的に要求する工程をさらに具えたことを特徴とする請求項６記載の方法。
【請求項１１】
前記スパンを前記少なくとも１つの受信エラー訂正データパケットに関連付ける工程は、
前記受信エラー訂正データパケットの中の前記少なくとも１つのパケットヘッダを調べて、
前記スパン内の前記複数の受信データパケットと、
前記スパンに関連するエラー訂正データパケットシーケンス内における前記受信エラー訂正データパケットの中の前記少なくとも１つに対する位置パラメータとを決定する工程と
を含むことを特徴とする請求項６記載の方法。
【請求項１２】
前記パケットヘッダは、拡張リアルタイムトランスポートプロトコル（ＲＴＰ）ヘッダを含むことを特徴とする請求項１１記載の方法。
【請求項１３】
前記エラー訂正データパケットは、フォワードエラー訂正（ＦＥＣ）によって生成されたエラー訂正データを含むことを特徴とする請求項６記載の方法。
【請求項１４】
前記要求メッセージを送信する工程は、前記ストリームメディアを求める要求を少なくとも１つの無線通信リンクを介して送信することを含むことを特徴とする請求項１記載の方法。
【請求項１５】
前記受信デバイスがクライアントデバイスであり、前記送信デバイスがサーバデバイスであることを特徴とする請求項１記載の方法。
【請求項１６】
受信デバイスで用いられる装置であって、
送信デバイスから入手可能な所定のストリームメディアデータを選択する手段と、
前記送信デバイスに対して、所定の要求エラー訂正レベルを有する要求メッセージを送信する手段と、
前記送信デバイスが前記送信した要求エラー訂正レベルを受け入れない場合には、異なる要求エラー訂正レベルを有する要求メッセージを送信し、該送信デバイスが所定の要求エラー訂正レベルの受け入れを決定するまで前記要求メッセージの送信を行う手段と、
前記送信デバイスから、前記ストリームメディアデータと、該データに対応する前記決定された所定の要求エラー訂正レベルに基づいて生成された所定のエラー訂正データとを受信する手段と、
前記受信した対応するエラー訂正データに基づいて、前記受信したストリームメディアデータ中に検出されたエラーを訂正する手段と
を具えたことを特徴とする装置。
【請求項１７】
前記ストリームメディアデータを選択する手段は、
要求エラー訂正データ密度を指定することによって前記要求エラー訂正レベルを識別する手段を含むことを特徴とする請求項１６記載の装置。
【請求項１８】
前記要求エラー訂正データ密度を指定する手段は、
スパン内のストリームデータパケットの数を識別する手段と、
前記スパンに関連するエラー訂正データパケットの数を識別する手段と
を含むことを特徴とする請求項１７記載の装置。
【請求項１９】
前記スパン内のストリームデータパケットの数が約１と約２４の間であり、前記スパンに関連するエラー訂正データパケットの数が約１と約２４との間であることを特徴とする請求項１８記載の装置。
【請求項２０】
前記要求メッセージを送信する手段は、
リアルタイムストリーミングプロトコル（ＲＴＳＰ）セットアップメッセージを前記送信デバイスに送信する手段を含むことを特徴とする請求項１６記載の装置。
【請求項２１】
前記送信デバイスから送信されるストリームデータパケットおよびエラー訂正データパケットを受信する手段と、
前記受信したストリームデータパケットを複数含むスパンを、前記受信したエラー訂正データパケットの少なくとも１つに関連付ける手段と、
前記受信エラー訂正データパケットの中の前記少なくとも１つを使用して前記スパン中のエラーを必要に応じて訂正する手段と
をさらに具えたことを特徴とする請求項１６記載の装置。
【請求項２２】
前記スパンは、複数の連続的なストリームデータパケットを含むことを特徴とする請求項２１記載の装置。
【請求項２３】
前記スパンは、複数の不連続的なストリームデータパケットを含むことを特徴とする請求項２１記載の装置。
【請求項２４】
前記送信デバイスが連続的なストリームデータパケットを含む前記スパンに基づいて前記エラー訂正データパケットの中の前記少なくとも１つを生成するように、選択的に要求する手段をさらに具えたことを特徴とする請求項２１記載の装置。
【請求項２５】
前記送信デバイスが不連続的なストリームデータパケットを含む前記スパンに基づいて前記エラー訂正データパケットの中の前記少なくとも１つを生成するように、選択的に要求する手段をさらに具えたことを特徴とする請求項２１記載の装置。
【請求項２６】
前記スパンを前記少なくとも１つの受信エラー訂正データパケットに関連付ける手段は、
前記受信エラー訂正データパケットの中の前記少なくとも１つのパケットヘッダを調べて、
前記スパン内の前記複数の受信データパケットと、
前記スパンに関連するエラー訂正データパケットシーケンス内における前記受信エラー訂正データパケットの中の前記少なくとも１つに対する位置パラメータとを決定する手段と
を含むことを特徴とする請求項２１記載の装置。
【請求項２７】
前記パケットヘッダは、拡張リアルタイムトランスポートプロトコル（ＲＴＰ）ヘッダを含むことを特徴とする請求項２６記載の装置。
【請求項２８】
前記エラー訂正データパケットは、フォワードエラー訂正（ＦＥＣ）によって生成されたエラー訂正データを含むことを特徴とする請求項２１記載の装置。
【請求項２９】
前記要求メッセージを送信する手段は、前記ストリームメディアを求める要求を少なくとも１つの無線通信リンクを介して送信することを含むことを特徴とする請求項１６記載の装置。
【請求項３０】
前記受信デバイスがクライアントデバイスであり、前記送信デバイスがサーバデバイスであることを特徴とする請求項１６記載の装置。
【請求項３１】
コンピュータによって、請求項１ないし１５のいずれかに記載の方法を実行するためのコンピュータ実行可能命令を有するコンピュータ可読媒体。
【請求項３２】
送信デバイスで用いられる方法であって、
入手可能なストリームメディアデータに関する情報を受信デバイスに送信する工程と、
前記受信デバイスから、所定の要求エラー訂正レベルを有する要求メッセージを受信する工程と、
前記受信した要求エラー訂正レベルが受け入れ可能かどうかを決定する工程と、
前記受信した要求エラー訂正レベルを受入れられない場合、当該要求エラー訂正レベルを実行できないことを通知し、受入れ可能な要求エラー訂正レベルを受信するまで前記決定の処理を継続する工程と、
前記決定された要求エラー訂正レベルに基づいて、エラー補正データを生成する工程と、
前記ストリームメディアデータと、前記生成されたエラー補正データとを、前記受信デバイスへ送信する工程と
を具えたことを特徴とする方法。
【請求項３３】
前記ストリームメディアデータに関する情報は、
要求エラー訂正データ密度を指定することによって前記要求エラー訂正レベルを識別することを特徴とする請求項３２記載の方法。
【請求項３４】
前記要求エラー訂正データ密度は、
スパン内に含まれることになるストリームデータパケットの数と、前記スパンに関連するエラー訂正データパケットの数とを識別することを特徴とする請求項３３記載の方法。
【請求項３５】
前記受信した要求エラー訂正レベルを選択的にオーバーライドする工程をさらに具えたことを特徴とする請求項３２記載の方法。
【請求項３６】
前記受信された要求メッセージは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）セットアップメッセージ中に含まれることを特徴とする請求項３２記載の方法。
【請求項３７】
前記生成されたエラー訂正データを出力する工程は、
拡張リアルタイムトランスポートプロトコル（ＲＴＰ）ヘッダを生成する工程を含むことを特徴とする請求項３２記載の方法。
【請求項３８】
前記要求メッセージは、無線通信リンクを介して受信され、
前記ストリームメディアデータと、前記生成されたエラー補正データとは、前記無線通信リンクを介した通信に向けて送信されることを特徴とする請求項３２記載の方法。
【請求項３９】
前記エラー補正データを生成する工程は、
複数の連続的なデータパケットに対してスパンを生成する工程を含むことを特徴とする請求項３２記載の方法。
【請求項４０】
前記エラー補正データを生成する工程は、
複数の不連続的なデータパケットに対してスパンを生成する工程を含むことを特徴とする請求項３２記載の方法。
【請求項４１】
連続的なデータパケットを含む前記スパンに基づいて前記エラー訂正データパケットの中の前記少なくとも１つを生成するよう求める要求を、前記受信デバイスから受信する工程
をさらに具えたことを特徴とする請求項３９記載の方法。
【請求項４２】
不連続的なデータパケットを含む前記スパンに基づいて前記エラー訂正データパケットの中の前記少なくとも１つを生成するよう求める要求を、前記受信デバイスから受信する工程
をさらに具えたことを特徴とする請求項４０記載の方法。
【請求項４３】
前記エラー補正データを生成する工程は、
第１のエラー訂正レベルが第１タイプのコンテンツに適用され、異なる第２のエラー訂正レベルが第２タイプのコンテンツに適用されるように、ストリーミングされることになるデータパケット内のコンテンツに基づいて、ストリーミングされることになるデータパケットのスパンに関連する少なくとも１つのエラー訂正データパケットを選択的に生成する工程を含むことを特徴とする請求項３２記載の方法。
【請求項４４】
前記第１タイプのコンテンツは、オーディオコンテンツを含み、
前記第２タイプのコンテンツは、ビデオコンテンツを含むことを特徴とする請求項４３記載の方法。
【請求項４５】
前記第１タイプのコンテンツは、第１タイプのビデオコンテンツを含み、
前記第２タイプのコンテンツは、第２タイプのビデオコンテンツを含むことを特徴とする請求項４３記載の方法。
【請求項４６】
前記第１タイプのビデオコンテンツは、Ｉフレームビデオコンテンツを含み、
前記第２タイプのビデオコンテンツは、Ｐフレームビデオコンテンツを含むことを特徴とする請求項４５記載の方法。
【請求項４７】
前記第１タイプのビデオコンテンツは、第１のプログラムに関連するビデオコンテンツを含み、
前記第２タイプのビデオコンテンツは、付加される第２のプログラムに関連するビデオコンテンツを含むことを特徴とする請求項４５記載の方法。
【請求項４８】
付加される第２のプログラムに関連する前記ビデオコンテンツは、広告コンテンツを含むことを特徴とする請求項４７記載の方法。
【請求項４９】
前記送信デバイスは、サーバデバイスを含み、
前記受信デバイスは、クライアントデバイスを含むことを特徴とする請求項３２記載の方法。
【請求項５０】
前記エラー補正データは、フォワードエラー訂正（ＦＥＣ）によって生成されたデータを含むことを特徴とする請求項３２記載の方法。
【請求項５１】
送信デバイスで用いられる装置であって、
入手可能なストリームメディアデータに関する情報を受信デバイスに送信する手段と、
前記受信デバイスから、所定の要求エラー訂正レベルを有する要求メッセージを受信する手段と、
前記受信した要求エラー訂正レベルが受け入れ可能かどうかを決定する手段と、
前記受信した要求エラー訂正レベルを受入れられない場合、当該要求エラー訂正レベルを実行できないことを通知し、受入れ可能な要求エラー訂正レベルを受信するまで前記決定の処理を継続する手段と、
前記決定された要求エラー訂正レベルに基づいて、エラー補正データを生成する手段と、
前記ストリームメディアデータと、前記生成されたエラー補正データとを、前記受信デバイスへ送信する手段と
を具えたことを特徴とする装置。
【請求項５２】
前記ストリームメディアデータに関する情報は、
要求エラー訂正データ密度を指定することによって前記要求エラー訂正レベルを識別することを特徴とする請求項５１記載の装置。
【請求項５３】
前記要求エラー訂正データ密度は、
スパン内に含まれることになるストリームデータパケットの数と、前記スパンに関連するエラー訂正データパケットの数とを識別することを特徴とする請求項５２記載の装置。
【請求項５４】
前記受信した要求エラー訂正レベルを選択的にオーバーライドする手段をさらに具えたことを特徴とする請求項５１記載の装置。
【請求項５５】
前記受信された要求メッセージは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）セットアップメッセージ中に含まれることを特徴とする請求項５１記載の装置。
【請求項５６】
前記生成されたエラー訂正データを出力する手段は、
拡張リアルタイムトランスポートプロトコル（ＲＴＰ）ヘッダを生成する手段を含むことを特徴とする請求項５１記載の装置。
【請求項５７】
前記要求メッセージは、無線通信リンクを介して受信され、
前記ストリームメディアデータと、前記生成されたエラー補正データとは、前記無線通信リンクを介した通信に向けて送信されることを特徴とする請求項５１記載の装置。
【請求項５８】
前記エラー補正データを生成する手段は、
複数の連続的なデータパケットに対してスパンを生成する手段を含むことを特徴とする請求項５１記載の装置。
【請求項５９】
前記エラー補正データを生成する手段は、
複数の不連続的なデータパケットに対してスパンを生成する手段を含むことを特徴とする請求項５１記載の装置。
【請求項６０】
連続的なデータパケットを含む前記スパンに基づいて前記エラー訂正データパケットの中の前記少なくとも１つを生成するよう求める要求を、前記受信デバイスから受信する手段
をさらに具えたことを特徴とする請求項５８記載の装置。
【請求項６１】
不連続的なデータパケットを含む前記スパンに基づいて前記エラー訂正データパケットの中の前記少なくとも１つを生成するよう求める要求を、前記受信デバイスから受信する手段
をさらに具えたことを特徴とする請求項５９記載の装置。
【請求項６２】
前記エラー補正データを生成する手段は、
第１のエラー訂正レベルが第１タイプのコンテンツに適用され、異なる第２のエラー訂正レベルが第２タイプのコンテンツに適用されるように、ストリーミングされることになるデータパケット内のコンテンツに基づいて、ストリーミングされることになるデータパケットのスパンに関連する少なくとも１つのエラー訂正データパケットを選択的に生成する手段を含むことを特徴とする請求項５１記載の装置。
【請求項６３】
前記第１タイプのコンテンツは、オーディオコンテンツを含み、
前記第２タイプのコンテンツは、ビデオコンテンツを含むことを特徴とする請求項６２記載の装置。
【請求項６４】
前記第１タイプのコンテンツは、第１タイプのビデオコンテンツを含み、
前記第２タイプのコンテンツは、第２タイプのビデオコンテンツを含むことを特徴とする請求項６２記載の装置。
【請求項６５】
前記第１タイプのビデオコンテンツは、Ｉフレームビデオコンテンツを含み、
前記第２タイプのビデオコンテンツは、Ｐフレームビデオコンテンツを含むことを特徴とする請求項６４記載の装置。
【請求項６６】
前記第１タイプのビデオコンテンツは、第１のプログラムに関連するビデオコンテンツを含み、
前記第２タイプのビデオコンテンツは、付加される第２のプログラムに関連するビデオコンテンツを含むことを特徴とする請求項６４記載の装置。
【請求項６７】
付加される第２のプログラムに関連する前記ビデオコンテンツは、広告コンテンツを含むことを特徴とする請求項６６記載の装置。
【請求項６８】
前記送信デバイスは、サーバデバイスを含み、
前記受信デバイスは、クライアントデバイスを含むことを特徴とする請求項５１記載の装置。
【請求項６９】
前記エラー補正データは、フォワードエラー訂正（ＦＥＣ）によって生成されたデータを含むことを特徴とする請求項５１記載の装置。
【請求項７０】
コンピュータによって、請求項３２ないし５０のいずれかに記載の方法を実行するためのコンピュータ実行可能命令を有するコンピュータ可読媒体。
【請求項７１】
システムであって、
ネットワークと、
前記ネットワークに接続された第１のデバイスと、
前記ネットワークに接続された第２のデバイスと
を具え、
前記第１のデバイスは、
前記第２のデバイスから入手可能な所定のストリームメディアデータを選択する手段と、
前記第２のデバイスに対して、所定の要求エラー訂正レベルを有する要求メッセージを送信する手段と、
前記第２のデバイスが前記送信した要求エラー訂正レベルを受け入れない場合には、異なる要求エラー訂正レベルを有する要求メッセージを送信し、該第２のデバイスが所定の要求エラー訂正レベルの受け入れを決定するまで前記要求メッセージの送信を行う手段と、
前記第２のデバイスから、前記ストリームメディアデータと、該データに対応する前記決定された所定の要求エラー訂正レベルに基づいて生成された所定のエラー訂正データとを受信する手段と、
前記受信した対応するエラー訂正データに基づいて、前記受信したストリームメディアデータ中に検出されたエラーを訂正する手段と
を具え、
前記第２のデバイスは、
入手可能なストリームメディアデータに関する情報を前記第１のデバイスに送信する手段と、
前記第１のデバイスから、所定の要求エラー訂正レベルを有する要求メッセージを受信する手段と、
前記受信した要求エラー訂正レベルが受け入れ可能かどうかを決定する手段と、
前記受信した要求エラー訂正レベルを受入れられない場合、当該要求エラー訂正レベルを実行できないことを通知し、受入れ可能な要求エラー訂正レベルを受信するまで前記決定の処理を継続する手段と、
前記決定された要求エラー訂正レベルに基づいて、エラー補正データを生成する手段と、
前記ストリームメディアデータと、前記生成されたエラー補正データとを、前記第１のデバイスへ送信する手段と
を具えたことを特徴とするシステム。
【請求項７２】
前記第１のデバイスは、クライアントデバイスを含み、
前記第２のデバイスは、サーバデバイスを含むことを特徴とする請求項７１記載のシステム。
【請求項７３】
前記第１のデバイスは、移動通信デバイスを含み、
前記第２のデバイスは、基地局を含むことを特徴とする請求項７１記載のシステム。
【請求項７４】
前記第１のデバイスは、後で受信するストリームメディアに対する前記要求エラー訂正レベルを動的に変更するようにさらに構成されたことを特徴とする請求項７１記載のシステム。
【請求項７５】
前記要求エラー訂正レベルは、
スパン内のストリームデータパケットの指定数と、前記スパンに関連するエラー訂正データパケットの指定数とを含むことを特徴とする請求項７１記載のシステム。
【請求項７６】
前記第１のデバイスは、
ストリームメディアを求める前記要求をリアルタイムストリーミングプロトコル（ＲＴＳＰ）セットアップメッセージ内で出力することを特徴とする請求項７１記載のシステム。
【請求項７７】
前記第１のデバイスは、
受信時にスパンを前記少なくとも１つのエラー訂正データパケットに関連付け、前記少なくとも１つの受信エラー訂正データパケットを使用して前記スパン中のエラーを必要に応じて訂正するようにさらに構成されたことを特徴とする請求項７１記載のシステム。
【請求項７８】
前記第１のデバイスは、
前記少なくとも１つの受信エラー訂正データパケット内のパケットヘッダを調べて、前記スパン内の前記複数の受信データパケットと、前記スパンに関連するエラー訂正データパケットシーケンス内における前記少なくとも１つの受信エラー訂正データパケットに対する位置パラメータとを決定するようにさらに構成されたことを特徴とする請求項７７記載のシステム。
【請求項７９】
前記パケットヘッダは、拡張リアルタイムトランスポートプロトコル（ＲＴＰ）ヘッダを含むことを特徴とする請求項７８記載のシステム。
【請求項８０】
前記第２のデバイスは、変更された要求エラー訂正レベルを受信し、それに応答して、前記変更された要求エラー訂正レベルに従って後でストリーミングするデータパケットのスパンに関連する少なくとも１つのエラー訂正データパケットを生成するようにさらに構成されたことを特徴とする請求項７１記載のシステム。
【請求項８１】
前記第２のデバイスは、前記受信した要求エラー訂正レベルを選択的にオーバーライドするようにさらに構成されたことを特徴とする請求項７１記載のシステム。
【請求項８２】
前記ネットワークは、少なくとも１つの無線通信リンクを含むことを特徴とする請求項７１記載のシステム。
【請求項８３】
前記第１のデバイスと前記第２のデバイスとは、前記エラー訂正レベルを動的に交渉するように構成されたことを特徴とする請求項７１記載のシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般に通信ネットワークに関し、より詳しくは、ストリームメディアに対する動的エラー訂正を、配線式および／または無線の通信／ネットワークを介して提供する方法および装置に関する。
【０００２】
【従来の技術】
現在、インターネットおよびその他類似のネットワークを使用して、サーバデバイスからクライアントデバイスにストリーミングメディアが送達されている。例えば、ニュース放送からのオーディオおよび／またはビデオコンテンツを、ネットワークを介してサーバデバイスから１つまたは複数のクライアントデバイスにストリーミングすることができる。
【０００３】
本明細書では、用語「ストリーミングメディア」および「ストリームメディア」は、クリティカルなコンテンツ（例えばオーディオおよび／またはビデオデータ）をリアルタイムで、またはほぼリアルタイムで、加入ユーザのクライアントデバイスに送達することを本質的に意味する。クライアントデバイスは、クライアントデバイスおよびメディアに適した方式でストリームメディアをレンダリングする。例として、生放送または事前録音済みのラジオ番組を、ストリーミングされるオーディオデータとしてネットワークを介して無線通信デバイス、例えば移動電話デバイスなどに送信することができ、次いで、移動電話デバイスはオーディオ信号を再生する。
【０００４】
よりよいサービスをユーザに提供するために、ストリーミングメディアに使用されるネットワークのいくつかは、予測可能レベルのサービスを提供し始めている。例えばいくつかのネットワークでは、ネットワーク接続のスループット（すなわちデータ転送速度）とこれらの接続上で送信されるデータに導入されるエラー（すなわち残留ビットエラー率またはＢＥＲ）との両方を、接続時間にわたりある予測限度内に維持することが試みられている。
【０００５】
このようなネットワークの一例が、いわゆる「第３世代」（３Ｇ）無線ネットワークである。３Ｇ無線ネットワークは、高データ転送速度の無線電話サービスをサポートするように設計されつつある。ストリーミングコンテンツサービスは、これらおよび他のタイプのネットワークにおいて主要な用途となることが予測される。このようなサービスは、許容できるストリーミングコンテンツ体験を加入ユーザに対して維持しながら、一定レベルのＢＥＲに対処することが必要になる。したがって、これらのネットワークの多くでは、破損データの量を減少させるエラー訂正サービスが必要とされている。
【０００６】
Ｒｏｓｅｎｂｅｒｇ他に発行された米国特許第６１４１７８８号は、パケットネットワーク中でフォワードエラー訂正（ＦＥＣ）技法を適用する方法を提供している。ＦＥＣは周知のエラー訂正技法だが、この技法は、送信デバイスが追加のＦＥＣデータを受信デバイスに提供した後で、受信デバイスがＦＥＣデータを使用して受信データ中のエラーを検出および訂正することのできる機構を提供する。したがって、ＦＥＣをサポートするために、送信デバイスは通常はＦＥＣエンコーダを備え、受信デバイスは通常はＦＥＣデコーダを備える。ＦＥＣは、様々な符号化レベルを可能にする。様々な符号化レベルは、所与のデータ量の場合に生成されるＦＥＣデータ量に基づく密度比で表すことができる。したがって、例えばいくつかのシステムでは、ＦＥＣ符号化レベルは「高く」、あらゆるデータパケットにつき１つのＦＥＣパケットの割合である。他のシステムでは、ＦＥＣ符号化レベルは「より低く」、したがって４つのデータパケットにつき１つのＦＥＣパケットの割合である。
【０００７】
Ｒｏｓｅｎｂｅｒｇ他は、ＦＥＣパケットを送信デバイスから１つまたは複数の受信デバイスに転送することができる方法を開示している。受信デバイスは、ＦＥＣ復号を提供するように構成される場合も、されない場合もある。必要なＦＥＣ復号を提供できる受信デバイスの場合、Ｒｏｓｅｎｂｅｒｇ他は、デコーダがＦＥＣパケットのヘッダからＦＥＣ符号化レベルを識別した後で必要に応じてエラー訂正プロセスを完了する方式を提供する。
【０００８】
【発明が解決しようとする課題】
Ｒｏｓｅｎｂｅｒｇ他によって提供される方法および装置の欠点の一つは、送信デバイスが受信デバイスに関係なくＦＥＣ符号化レベルを制御することである。受信デバイスは単に、送信デバイスによって適用されたＦＥＣ符号化レベルについて勧告されるだけである。受信デバイスは、送信デバイスによるＦＥＣ符号化レベルの選択に影響を及ぼすことができない。
【０００９】
受信デバイスが送信デバイスの決定に影響を及ぼすことができ、それによって例えば所与の場所／時間で適用されるエラー訂正密度に受信デバイスがよりよく適合することができることが有利である。
【００１０】
そこで、本発明の目的は、送信デバイスによってストリームメディアに適用される符号化レベルを、受信デバイスが制御することが可能な、ストリームメディアに対する交渉方式の／動的なエラー訂正に関する、方法、および、装置を提供することにある。
【００１１】
すなわち、本発明の目的は、ストリームメディアに適用されるエラー訂正レベルに関する送信デバイスの決定を、受信デバイスが動的に制御することを可能とし、さらには他の手法を用いてその決定に影響を及ぼすことが可能な、方法、および、装置を提供することにある。
【００１２】
【課題を解決するための手段】
本発明のいくつかの態様によれば、ストリームメディアに適用されるエラー訂正レベルに関する送信デバイスの決定を受信デバイスが動的に制御すること、および／または他のやり方でそれに影響を及ぼすことができるようにする方法および装置が提供される。
【００１３】
例えば、本発明の例示的ないくつかの実装形態によれば、受信デバイス中で用いられる方法が提供される。この方法は、最初の要求エラー訂正レベルを備えたストリームメディア要求を生成することを含む。このようにして受信デバイスは、送信デバイスがストリームメディアに対して特定の符号化レベルを提供するように要求することができる。さらにいくつかの実装形態では、この方法はさらに、ストリーミングメディアに適用される要求エラー訂正レベルを受信デバイスが動的に変更するようにすることも含む。
【００１４】
本発明の様々な方法および装置に関するより完全な理解は、後続の詳細な説明を添付の図面と共に参照することによって得られる。
【００１５】
【発明の実施の形態】
図面に目を向けると、適したコンピューティング環境で本発明を実施した場合が示されており、図面では、同じ参照番号は同じ要素を指す。必須ではないが、本発明の各部分は、プログラムモジュールなど、コンピュータや同様のデバイスによって実行されるコンピュータ実行可能命令の一般的なコンテキストで述べる。コンピュータは、例えばパーソナルコンピュータ（ＰＣ）、ワークステーション、ポータブルコンピュータ、サーバ、複数のプロセッサ、メインフレームコンピュータ、無線通信基地局、ハンドヘルド通信デバイス、ストリームメディアプレーヤ、セットトップボックスなどの形をとる場合がある。
【００１６】
一般にプログラムモジュールは、特定のタスクを実施するか特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明の様々な例示的実装形態はまた、分散コンピューティング環境で実施することもでき、その場合、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される。分散コンピューティング環境では、プログラムモジュールはローカルとリモートの両方のメモリ記憶デバイス中に配置することができる。
【００１７】
本明細書では、用語「ロジック」は、例えばソフトウェア、ファームウェア、ハードウェア、および／またはこれらの任意の組合せを含めた、任意の形のロジックおよび必要なサポート要素について使用するものとする。
【００１８】
図１に、後で述べる方法および装置の一部を実装することのできる、適したコンピューティング環境１２０の例を示す。
【００１９】
例示的なコンピューティング環境１２０は、適したコンピューティング環境の一例にすぎず、本明細書に述べる改良型の方法および装置の使用または機能の範囲についてどんな限定も示すものではない。また、コンピューティング環境１２０は、コンピューティング環境１２０中に示すコンポーネントのいずれか１つまたは組合せに関してどんな依存性または要件を有するとも解釈されるものではない。
【００２０】
本明細書における改良型の方法および装置は、その他多くの汎用および／または特殊目的のコンピューティングシステム環境または構成でも機能する。
【００２１】
図１に示すように、コンピューティング環境１２０は、コンピュータ１３０の形をとる汎用コンピューティングデバイスを含む。コンピュータ１３０のコンポーネントとしては、１つまたは複数のプロセッサまたはプロセッシングユニット１３２と、システムメモリ１３４と、システムメモリ１３４を含めた様々なシステムコンポーネントをプロセッサ１３２に結合するバス１３６とが挙げられる。
【００２２】
バス１３６は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、周辺バス、ＡＧＰ（ａｃｃｅｌｅｒａｔｅｄ  ｇｒａｐｈｉｃｓ  ｐｏｒｔ）、およびプロセッサバスまたはローカルバスを含む、いくつかのタイプのバス構造の１つまたは複数を表す。限定ではなく例として、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスを含めることができる。
【００２３】
コンピュータ１３０は通常、様々なコンピュータ可読媒体を備える。このような媒体は、コンピュータ１３０からアクセス可能な任意の利用可能媒体とすることができ、揮発性媒体と不揮発性媒体、取外し可能媒体と取外し不可能媒体の両方が含まれる。
【００２４】
図１では、システムメモリ１３４は、ランダムアクセスメモリ（ＲＡＭ）１４０などの揮発性メモリ、および／または読み出し専用メモリ（ＲＯＭ）１３８などの不揮発性メモリの形をとるコンピュータ可読媒体を備える。ＲＯＭ１３８には、起動中などにコンピュータ１３０内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）１４２が記憶されている。ＲＡＭ１４０は通常、プロセッサ１３２からすぐにアクセス可能な、かつ／またはプロセッサ１３２が現在作用している、データおよび／またはプログラムモジュールを含む。
【００２５】
コンピュータ１３０はさらに、その他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例として図１には、取外し不可能かつ不揮発性の磁気媒体（図示していないが通常「ハードドライブ」と呼ばれる）に対して読み書きを行うためのハードディスクドライブ１４４と、取外し可能かつ不揮発性の磁気ディスク１４８（例えば「フロッピー（登録商標）ディスク」）に対して読み書きを行うための磁気ディスクドライブ１４６と、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭやその他の光学媒体など、取外し可能かつ不揮発性の光ディスク１５２に対して読み書きを行うための光ディスクドライブ１５０も備える。ハードディスクドライブ１４４、磁気ディスクドライブ１４６、および光ディスクドライブ１５０はそれぞれ、１つまたは複数のインタフェース１５４でバス１３６に接続される。
【００２６】
ドライブおよびそれらに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性記憶域をコンピュータ１３０に提供する。本明細書で述べる例示的な環境では、ハードディスク、取外し可能磁気ディスク１４８、および取外し可能光ディスク１５２を採用しているが、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）など、コンピュータからアクセス可能なデータを記憶できる他のタイプのコンピュータ可読媒体もこの例示的な動作環境で使用することができることを、当業者は理解されたい。
【００２７】
ハードディスク、磁気ディスク１４８、光ディスク１５２、ＲＯＭ１３８、またはＲＡＭ１４０には、例としてオペレーティングシステム１５８、１つまたは複数のアプリケーションプログラム１６０、その他のプログラムモジュール１６２、プログラムデータ１６４を含めて、いくつかのプログラムモジュールを記憶することができる。
【００２８】
本明細書で述べる改良型の方法および装置は、オペレーティングシステム１５８、１つまたは複数のアプリケーションプログラム１６０、その他のプログラムモジュール１６２、および／またはプログラムデータ１６４内に実装することができる。
【００２９】
ユーザは、キーボード１６６やポインティングデバイス１６８（例えば「マウス」）などの入力デバイスを介してコンピュータ１３０にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、衛星受信アンテナ、シリアルポート、スキャナ、カメラなどを含めることができる。これらおよび他の入力デバイスは、バス１３６に結合されたユーザ入力インタフェース１７０を介してプロセッシングユニット１３２に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など他のインタフェースおよびバス構造で接続することもできる。
【００３０】
モニタ１７２または他のタイプの表示装置もまた、ビデオアダプタ１７４などのインタフェースを介してバス１３６に接続することができる。モニタ１７２に加え、パーソナルコンピュータは通常、スピーカやプリンタなど他の周辺出力デバイス（図示せず）も備え、これらは出力周辺インタフェース１７５を介して接続することができる。
【００３１】
コンピュータ１３０は、リモートコンピュータ１８２など１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ１８２は、コンピュータ１３０に関して本明細書に述べる要素および機能の多くまたはすべてを含むことができる。
【００３２】
図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７７および一般的なワイドエリアネットワーク（ＷＡＮ）１７９である。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットによくあるものである。
【００３３】
ＬＡＮネットワーキング環境で使用されるときは、コンピュータ１３０は、ネットワークインタフェースまたはアダプタ１８６を介してＬＡＮ１７７に接続される。ＷＡＮネットワーキング環境で使用されるときは、コンピュータは通常、ＷＡＮ１７９を介した通信を確立するためのモデム１７８または他の手段を備える。モデム１７８は内蔵でも外付けでもよく、ユーザ入力インタフェース１７０または他の適した機構を介してシステムバス１３６に接続することができる。
【００３４】
図１には、インターネットを介したＷＡＮの具体的な実装形態が示してある。この場合、コンピュータ１３０は、モデム１７８を採用して、インターネット１８０を介して少なくとも１つのリモートコンピュータ１８２との通信を確立する。
【００３５】
ネットワーク化された環境では、コンピュータ１３０に関して示したプログラムモジュールまたはそれらの一部を、リモートのメモリ記憶デバイスに記憶することもできる。したがって、例えば図１に示すように、リモートアプリケーションプログラム１８９がリモートコンピュータ１８２のメモリデバイス上にある場合もある。図示および記述したネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立するための他の手段を使用することもできることを理解されたい。
【００３６】
次に図２を参照するが、図２には、例示的な通信環境２００が示してある。通信環境２００は、ネットワーク２０４に結合されたサーバ２０２を含む。サーバ２０２は、この例では、ネットワーク２０４を介してストリームメディアを提供する送信デバイスとして構成される。ネットワーク２０４は、１つまたは複数の通信リンク／ネットワークを表す。いくつかの例示的な実装形態では、ネットワーク２０４はインターネット、イントラネット、またはその他同様のネットワークを含む。
【００３７】
図では、ネットワーク２０４には第２のサーバ２０６も結合されている。サーバ２０６は、この例では、アンテナ２０８を介して無線受信デバイス２１０にストリーミングメディアを提供することのできる送信デバイスとして構成される。したがって例えば、サーバ２０６は無線基地局と同じ場所に位置することができる。サーバ２０６は、ストリームメディア自体を生成することもでき、かつ／あるいは、ストリームメディアをサーバ２０２から受信して、それを受信デバイス２１０に提供することもできる。この例では、サーバ２０６から受信デバイス２１０に送信されるストリームメディアには、エラー訂正データが関連付けられている。エラー訂正データは、例えばサーバ２０２および／またはサーバ２０６が生成することができる。
【００３８】
後続の例では、サーバ２０６は、ストリームメディアの提供と、関連するエラー訂正データの生成の両方を受信デバイス２１０に対して行う送信デバイスであると仮定し、受信デバイス２１０はクライアントデバイスとして構成される。ただし、本明細書に提供する方法および装置は、配線式環境と無線環境の両方での使用に適合可能であることに留意されたい。
【００３９】
受信デバイス２１０は、無線通信リンクを介してストリームメディアを受信することのできる任意のデバイスを表す。無線通信リンクは、この例では、物体または他の信号によって遮断されるか、または干渉を受ける場合がある。例えば図２に示すように、トラック２１２などの障害物がアンテナ２０８と受信デバイス２１０の間を通過するとき、これが信号干渉を引き起こす恐れがある。このような信号干渉は、受信データ中のエラーにつながる可能性があり、これが訂正されないと、ストリームメディアのプレゼンテーションが劣化する可能性がある。
【００４０】
本発明のいくつかの態様によれば、受信データ中のエラーを訂正するために、サーバ２０６および受信デバイス２１０は、改良型のエラー訂正方式をサポートするように構成される。この改良型エラー訂正方式は本質的に、ストリームメディアに対して提供されるエラー訂正レベルについて送信デバイスと受信デバイスが交渉することを可能にする。交渉は、ストリーミングメディアプロセスの開始時、およびその後いつでも行うことができる。
【００４１】
したがって、この改良型のエラー訂正方式を用いると、エラー訂正レベルを必要に応じて動的に改変して、種々の干渉要因によって引き起こされるエラーを克服することが可能である。例えば、受信デバイス２１０は、要求エラー訂正レベル２１６を識別する要求メッセージ２１４を送信することができる。トラック２１２が干渉を引き起こしているときは、より高いエラー訂正レベルを要求することができる。しかしトラック２１２が前進した後は、受信デバイス２１０は、より低いエラー訂正レベルを要求することができる。
【００４２】
本発明のいくつかの例示的な実装形態によれば、要求メッセージ２１４は、リアルタイムストリーミングプロトコル（ＲＴＳＰ）セットアップメッセージである。例えばこの場合、要求されるエラー訂正レベル２１６は、複数のストリーミングメディアデータパケットに対して生成されるエラー訂正パケットの密度を示すことができる。例えばいくつかの実装形態では、エラー訂正パケットの密度は、あるスパン内のストリーミングメディアデータパケットの数と共に指定される。したがって、受信デバイス２１０は、ストリームメディアを要求するとき、各スパンがストリーミングメディアデータパケットを４つ含む場合にエラー訂正パケットの密度がスパンごとに２つになるように要求することができる。送信デバイス、この場合サーバ２０６は、この要求を受け入れることもでき、異なるエラー訂正レベルを提案することもでき、要求されたエラー訂正レベルを無視することもできる。したがってこの例では、サーバ２０６が要求エラー訂正レベル２１６を受け入れることを決定したと仮定する。このためサーバ２０６は、エラー訂正データ生成プロセスに必要なコンピューティングリソースおよびデータ記憶リソースを提供することになる。ストリーミングメディアセッション中のいずれかの時点でサーバ２０６がもはやこのようなリソースを提供することができない場合、サーバ２０６は、提供するエラー訂正レベルを必要に応じて下げることができる。後で述べるが、受信デバイス２１０に送信されるエラー訂正パケットは、送信デバイス（ここではサーバ２０６）が適用したエラー訂正レベルを示す。このようにして、受信デバイスと送信デバイスのどちらも、エラー訂正レベルを必要に応じて確定し、交渉し、かつ／あるいは動的に改変することができる。
【００４３】
この例を念頭に置き、次に図３に注目する。図３には、本発明のいくつかの実装形態による例示的なストリーミングメディア構成３００が示してある。ここで、送信デバイス３０２は受信デバイス３０４にメディアをストリーミングしている。図示のように、データ接続３０６にはフォワードエラー訂正（ＦＥＣ）保護がかけられている。データ接続３０６は、リアルタイムトランスポートプロトコル（ＲＴＰ）データストリーム３０６ａと、関連するＲＴＰ  ＦＥＣデータストリーム３０６ｂを含む。この例ではデータストリーム３０６ａと３０６ｂは別個のデータストリームだが、他の構成では、これらのデータストリームを単一のデータストリームにインタリーブすることもできる。
【００４４】
送信デバイス３０２には、改良型のエラー訂正方式をサポートするためのロジック３０８が備わる。この例では、ロジック３０８はサーバ動的ＦＥＣロジックを含み、これは、メディアをストリーミングし、ストリームメディアに関連するエラー訂正データを符号化する（かつストリーミングする）ように構成される。ストリーミングメディアの前に、ロジック３０８は、入手可能なストリーミングメディアに関する情報を受信デバイス３０４に提供する。例えばいくつかの実装形態では、標準的なセッション記述プロトコル（ＳＤＰ）要素に対する向上がなされ、ＳＤＰ要素は、ストリームメディアおよび関連するＦＥＣデータストリームの位置および特性を受信デバイス３０４が識別できるようにする。
【００４５】
受信デバイス３０４がストリームメディアを選択すると、受信デバイス３０４は、送信デバイス３０２にＲＴＳＰセットアップメッセージ２１４（図２）を送信し、ロジック３０８がこれに応答して、データ接続３０６を介してメディアをストリーミングする。前述のように、送信デバイス３０２は、要求されたエラー訂正レベル２１６、または状況からしてより適切な他の何らかのエラー訂正レベルを受け入れる／サポートする。どのように決定された場合でも、得られるエラー訂正レベルは、ロジック３０８によってＲＴＰ  ＦＥＣストリーム３０６ｂ内で識別される。例えばロジック３０８は、ＲＴＰ  ＦＥＣストリーム３０６ｂ中の１つまたは複数のパケット内のＲＴＰメッセージのヘッダ部内で、あるスパンのデータパケットに適用されるエラー訂正密度を識別することができる。
【００４６】
このようなタスクをサポートするために、ロジック３０８は通信インタフェース３１０に動作可能に結合され、通信インタフェース３１０は、送信デバイス３０２と受信デバイス３０４との間の通信をサポートするように構成された送信機および受信機（図示せず）を備える。ロジック３０８はメモリ３１２にも動作可能に結合され、メモリ３１２は、メディアおよび／または改良型エラー訂正方式のためのエラー訂正データに、必要なバッファリングを施すことをサポートするように構成される。この例では、ロジック３０８はまた、オプションの管理インタフェース３１４にも動作可能に結合され、管理インタフェース３１４は、ロジック３０８に関するいくつかの動作パラメータを構成するようになっている。したがって例えば、管理インタフェース３１４は、ユーザがロジック３０８を制御／監視できるようにするユーザインタフェースを提供することができる。例として、ユーザは、ロジック３０８が提供する最低／最高エラー訂正レベルを確定することができる。
【００４７】
ロジック３０８は、受信デバイス３０４内に備わる対応するロジック３１６と共に動作する。この例では、ロジック３１６はクライアント動的ＦＥＣロジックを含む。ロジック３１６は、通信インタフェース３１８に動作可能に結合され、通信インタフェース３１８は、例えば通信インタフェース３１０を介して、送信デバイス３０２への通信を提供するように構成される。
【００４８】
ロジック３１６は、改良型のエラー訂正方式をサポートするように構成される。したがってロジック３１６は、受信したエラー訂正データパケットを使用して、受信したストリームメディアパケット中のエラーを訂正するように構成される。したがっていくつかの実装形態では、ロジック３１６は、所与の数のＦＥＣデータパケットが適用されることになるデータパケットの数（またはスパン）を任意の時に指定し、その後、受信したスパンおよびそれに関連する受信ＦＥＣデータパケットを識別し、必要ならこれらのデータパケットを再整理し、次いで、データ中で識別される、引き起こされたビットエラーにエラー訂正を適用する。このようなタスクをサポートするために、ロジック３１６はメモリ３２０にも動作可能に結合され、メモリ３２０は、必要なバッファリングをメディアおよび／またはエラー訂正データに施すことをサポートするように構成される。
【００４９】
ロジック３１６はまた、アプリケーションインタフェース３２２にも動作可能に結合され、アプリケーションインタフェース３２２は、アプリケーション３２４とロジック３１６との間の通信を提供する。アプリケーション３２４は、例えばストリームメディアプレーヤ／レコーダとすることができる。ロジック３１６は、アプリケーション３２４の動作をサポートするように構成される。
【００５０】
以上を念頭に置き、次に図４の流れ図を参照する。図４には、受信デバイス３０４中で用いられる例示的な動的エラー訂正プロセス４００が示してある。ステップ４０２で、受信デバイス３０４は、送信デバイス３０２上で入手可能なストリーミングメディアを発見し選択する。次いでステップ４０４で、要求するエラー訂正レベル２１６を（例えばＲＴＳＰセットアップメッセージ内で）識別する要求メッセージ２１４（図２）を送信デバイス３０２に送信する。
【００５１】
次にステップ４０６で、送信デバイスが何らかの理由で要求を受け入れない場合は、好ましくは異なる要求エラー訂正レベルを有する１つまたは複数の追加要求を、送信デバイスが要求のストリームメディアを提供することに同意するまで必要に応じて送信する。次いで、プロセス４００はステップ４０８に進むが、ここで送信デバイス３０２は、ストリームメディアを求める要求を受け入れたところである。ステップ４０８で、受信デバイス３０４は、ストリームメディアデータパケットおよび対応するＦＥＣデータパケットの受信を開始する。ステップ４１０で、少なくとも１つのスパンのストリームメディアデータパケットを、関連する１つまたは複数のＦＥＣパケットと共にバッファリング／構成する。ここで、スパン中のストリームメディアデータパケットの数をＦＥＣデータパケット中で識別することができる。
【００５２】
次にステップ４１２で、エラー訂正を必要に応じて行う。例えば、スパン中のデータに対して、関連するＦＥＣデータパケットを使用してＦＥＣデコーダ操作を行う。ステップ４１４で、エラー訂正されたストリームメディアデータを、次の処理に向けてアプリケーションインタフェース３２２を介してアプリケーション３２４（図３）に提供する。
【００５３】
ステップ４１６で、ロジック３１６はストリームメディアプロセスを監視し、望ましければ異なるエラー訂正レベルを交渉する。例えば、異なる要求エラー訂正レベル２１６を（例えばＲＴＳＰセットアップメッセージ内で）識別する新しい要求メッセージ２１４を送信デバイス３０２に送信することができる。要求エラー訂正レベルが変更されてから、または変更なしで、次いでプロセス４００はステップ４０８に戻る。その後、ストリームメディア接続の存続時間にわたり、ステップ４０８から４１６を繰り返す。
【００５４】
次に図５に注目するが、図５には、送信デバイス３０２中で用いられる例示的な動的エラー訂正プロセス５００が示してある。ステップ５０２で、送信デバイス３０２は、照会してきた受信デバイスに対してストリームメディアの入手可能性を識別する。次にステップ５０４で、ストリームメディアを求める要求を受信する。この要求は、指定のストリームメディアに適用される最初のエラー訂正レベルを識別する。例えば、要求エラー訂正レベル２１６を（例えばＲＴＳＰセットアップメッセージ内で）識別する要求メッセージ２１４を、受信デバイス３０４から送信デバイス３０２に送信することができる。
【００５５】
ステップ５０６で、送信デバイス３０２が要求エラー訂正レベルをサポートできるかどうかについて決定する。要求エラー訂正レベルをサポートできない場合は、プロセス５００はステップ５０８に進む。ステップ５０８で、送信デバイス３０２は、要求エラー訂正レベルをサポートできないことを受信デバイス３０４に通信する（能動的または受動的に）。その後、送信デバイス３０２は新しい要求メッセージを待機する。受け入れられるエラー訂正レベルが要求されるまで、このようなまたは同様の交渉手順を継続する。任意選択で、いくつかの実装形態では、送信デバイス３０２はいずれかの時点で一方的にエラー訂正レベルを受け入れられるレベルに調節することもできる。例えば、ＦＥＣデータストリームに関連する処理／メモリの量を削減する必要が送信デバイスにある場合、送信デバイス３０２は、対応する必要な変更をエラー訂正レベルに加える（例えば下げる）ことができる。
【００５６】
エラー訂正レベルが受け入れられるようになれば、プロセス５００はステップ５１０に進み、送信デバイス３０２は、定義されたスパンの１つまたは複数のストリームメディアデータパケットに対して適切な数のエラー訂正データパケットを生成する。ストリームデータパケットのスパンは、ストリームメディアパケットの連続的なスパンまたは不連続的なスパンを含む場合がある。
【００５７】
次にステップ５１２で、送信デバイス３０２は、スパンおよび関連するエラー訂正データパケットを受信デバイス３０４に提供する。ステップ５１４で、受信デバイス３０４が異なるエラー訂正レベルを要求した場合は、プロセス５００はステップ５０６に戻り、そうでない場合はステップ５１０に戻る。ストリームメディア接続の存続時間にわたり、ステップ５０６から５１４を繰り返す。
【００５８】
次に図６を参照するが、図６には、本発明のいくつかの例示的な実装形態による、送信デバイス３０２から受信デバイス３０４に提供されるＦＥＣデータパケット中で使用するのに適したＲＴＰメッセージヘッダの拡張６００が例示的に示してある。この場合、ＲＴＰメッセージヘッダ６００は、マスク、ＦＥＣスパン、およびＦＥＣインデックスを指定することにより、ＦＥＣデータパケットに関連するエラー訂正レベルを識別する。マスクは、ＦＥＣデータパケットに関連するスパン中のパケット数を識別する。この例では、マスクフィールドは２４ビットである。ＦＥＣスパンは、スパンに関連するＦＥＣデータパケットの数を識別する。ここではＦＥＣスパンフィールドは５ビットである。ＦＥＣインデックスは、ＦＥＣスパン内における現在のＦＥＣデータパケットの位置を識別する。ここではＦＥＣインデックスフィールドは６ビットである。
【００５９】
例示的な拡張６００内に含まれるその他のフィールドには、１６ビットのパケットシーケンス番号（ＳＮ）ベースフィールド、１６ビットの長さ回復フィールド、１ビットの拡張（Ｅ）フラグフィールド、７ビットのペイロードタイプ（ＰＴ）回復フィールド、３２ビットのメディアパケットタイムスタンプ（ＴＳ）回復フィールド、５ビットのＥＸフラグフィールド、および１６ビットの予約フィールドがある。
【００６０】
ＳＮベースフィールドは、ＦＥＣによって保護されることになるこのストリーミング接続上のメディアパケットの最小シーケンス番号に設定される。これにより、ＦＥＣ操作を一連のパケットにわたって拡張することができる。長さ回復フィールドは、回復されるいずれかのパケットの長さを決定するのに使用される。これは、１６ビットの自然２進数表現のペイロード長（バイト）に適用される保護操作によって計算される。ペイロード長は、メディアペイロード自体、ならびに、ＦＥＣパケットに関連するメディアパケットのＣＳＲＣリスト、拡張、およびパディングのための追加のオーバーヘッドを含む。このフィールドにより、この接続上でストリーミングされるメディアパケットの長さが変動する場合でもＦＥＣ手順を適用することができる。例えば、２つのメディアパケットの排他的論理和をとることによってＦＥＣパケットが生成されると仮定する。２つのメディアパケットの長さは、それぞれ３（０ｂ０１１）バイトおよび５（０ｂ１０１）バイトである。この場合、長さ回復フィールドは、０ｂ０１１ＸＯＲ０ｂ１０１＝０ｂ１１０として符号化される。
【００６１】
Ｅフラグはヘッダ拡張を示す。ＰＴは、メディアパケットペイロードに関するペイロードタイプを示す。ＰＴ回復フィールドは、ＦＥＣデータパケットに関連するメディアパケットのペイロードタイプの値に適用される保護操作によって得られる。マスクフィールドは２４ビットであり、ＦＥＣデータパケットに関連するメディアパケットを識別する。マスク中のビットｉが１にセットされた場合、シーケンス番号Ｎ＋ｉのメディアパケットがＦＥＣデータパケットに関連付けられ、ＮはＦＥＣパケットヘッダ中のＳＮベースフィールドである。最下位ビットはｉ＝０に相当し、この例では、ＦＥＣ保護されるストリームメディアパケットのシーケンス中に多くて２４個のパケットがある可能性があるので、最上位ビットはｉ＝２３に相当する。
【００６２】
ＴＳ回復フィールドは、ＦＥＣデータパケットに関連するストリームメディアパケットのタイムスタンプに適用される保護操作によって計算される。これにより、タイムスタンプを完全に回復することができる。ＥＸフラグフィールドおよび予約フィールドはそれぞれ、将来の使用に向けて予約される。
【００６３】
以下のセクションでは、前述の方法および装置を使用したいくつかの例示的なメッセージ交換に焦点を合わせる。
【００６４】
以下の抜粋は、ＤＥＳＣＲＩＢＥ要求に応答して送信デバイス３０２から受信デバイス３０４に送信されるＳＤＰコンテンツ記述からのものである。このＳＤＰ記述は、コンテンツファイルに対するパス、オーディオビデオストリームに対するＵＲＬ、ならびに関連する標準的および動的ＦＥＣストリームを示す。
v=0
o=SYSTEM200103261741470200
200103261741470200
IN IP4 127.0.0.1
s=<No Title>
c=IN IP4 0.0.0.0
b=AS:5
a=maxps:900
t=0.0
a=control:rtsp://test/welcome.asf/ //このメディアストリームに対する絶対ＵＲＬ
a=etag:{6CAE8AA4-1866-A24D-344E-3CF22C3894A7}
a=range:npt=0.000-110.474
a=recvonly
a=pgmpu:data:application/x-wms-contentdesc,Copied%20MetaData%20From%20Playlist%20File=1%0D%0A
:
m=audio0RTP/AVP96 97 98
b=AS:7
b=RS:0
b=RR:0
a=rtpmap:96x-asf-pf/1000
a=rtpmap:97parityfec/1000
a=fmtp:97audio/fec97 24 1
a=rtpmap:98wms-fec/1000
a=fmtp:98audio/fec98 24 1//このメディアストリームに関連する動的ＦＥＣストリームに対する相対ＵＲＬ
a=control:audio
a=stream:1
m=application0RTP/AVP96
b=RS:0
b=RR:0
a=rtpmap:96x-wms-rtx/1000
a=control:rtx
a=stream:65536
m=video0RTP/AVP96 97 98
b=AS:45
b=RS:0
b=RR:0
a=rtpmap:96x-asf-pf/1000
a=rtpmap:97parityfec/1000
a=fmtp:97video/fec97 24 1
a=rtpmap:98wms-fec/1000
a=fmtp:98video/fec98 24 1
a=control:video
a=stream:2
【００６５】
以下の行は、動的エラー訂正レベルペイロードフォーマットと、このフォーマットに対応するＦＥＣストリームに使用されるＵＲＬを識別する。
a=rtpmap:98wms-fec/1000//Windows（登録商標）Media Services FEC payload format98
a=fmtp:98 audio/fec98 24 1//このペイロードフォーマットを使用するこのメディアストリームに関連する動的ＦＥＣストリームに対する相対ＵＲＬ
【００６６】
この例では、ｒｔｓｐ：／／ｔｅｓｔ／ｗｅｌｃｏｍｅ．ａｓｆ．にあるストリームメディアに対する関連ＦＥＣ接続に対するＵＲＬとして、ｒｔｓｐ：／／ｔｅｓｔ／ｗｅｌｃｏｍｅ．ａｓｆ／ａｕｄｉｏ／ｆｅｃ９８  ２４  １に到達するために、受信デバイス３０４は、メディアストリームに対する絶対ＵＲＬに相対ＵＲＬを添付する。ＦＥＣ  ＵＲＬ記述は、ＦＥＣスパン、すなわち特定のＦＥＣデータパケットまたは一組のＦＥＣデータパケットが適用されるデータパケットの数と、このスパンに適用されるＦＥＣデータパケットの数とを含む。
a=fmtp:98audio/fec98 24 1//スパン=24、1スパンあたりのＦＥＣパケット=1
【００６７】
これから受信デバイス３０４は、例えばオーディオおよび／またはビデオストリームを選択することができ、これらのそれぞれにつき、標準的ＦＥＣまたは動的ＦＥＣに従って符号化される関連のＦＥＣストリームを選択することができる。この例における動的ＦＥＣの場合、送信デバイス３０２と受信デバイス３０４との間で要求／応答交換が行われ、それにより送信デバイス３０２は、２４のパケットスパンおよび１スパンにつき４つのＦＥＣデータパケットを使用して動的ＦＥＣデータパケットのストリームを再生する受信デバイスのＳＥＴＵＰ要求に同意する。ここで、ＦｅｃＢｕｒｓｔＭａｒｇｉｎを使用して、一組のパケットスパンおよび関連するＦＥＣパケットを、エラー訂正問題に一般的に適用される計算を含むヴァンデルモンド行列の形でバッファリングする。
SETUPrtsp://test/welcome2.asf/stream=5/fec98RTSP/1.0
Transport:
RTP/AVP/UDP;unicast;client_port=2408;ssrc=6dded651;mode=PLAY;FecSpan=4;FecPerSpan=1;FecBurstMargin=6,
RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6dded651;mode=PLAY
If-Match:"{83A04BD0-FD30-1984-4994-0A22CA116ED3}"
Date:Fri,23Mar2001 04:28:14GMT
CSeq:8
Session:1077055954
User-Agent:WMPlayer/9.0.0.197guid/CB131790-CC16-4CCE-A234-6D29BEE21FCE
Accept-Language:en-us,*;q=0.1
Accept-Charset:UTF-8,*;q=0.1
X-Accept-Authentication:NTLM,Digest,B
RTSP/1.0 200 OK
Transport:
RTP/AVP/UDP;unicast;source=157.56.216.159;server_port=2410;client_port=2408;ssrc=3874dd27;mode=PLAY;FecSpan=4;FecPerSpan=1;FecBurstMargin=6
Date:Fri,23Mar2001 04:28:14GMT
CSeq:8
Timestamp:1 0.031
Session:1077055954;timeout=60
Server:WMServer/9.0.0.197
Cache-Control:must-revalidate,proxy-revalidate
【００６８】
以下の例では、受信デバイス３０４は初期ＦＥＣ密度４：２を確定する。ＲＴＳＰセットアップメッセージは以下のものを含む。
SETUPrtsp://test/welcome2.asf/stream=5/fec98RTSP/1.0
Transport:
RTP/AVP/UDP;unicast;client_port=2408;ssrc=6dded651;mode=PLAY;FecSpan=4;FecPerSpan=2;
【００６９】
送信デバイス３０２は、以下のとおり成功を返す。
RTSP/1.0 200 OK
Transport:
RTP/AVP/UDP;unicast;source=157.56.216.159;server_port=2410;client_port=2408;ssrc=3874dd27;
【００７０】
その後、受信デバイス３０４は、ストリームメディアおよび関連するＦＥＣデータパケットを送信デバイス３０２から受信することになる。各ＦＥＣデータパケットはＲＴＰヘッダ拡張６００を使用する。
【００７１】
次に、図７に示す例示的な図に注目するが、この図には、４×４行列のメディアデータパケット（７０１から７１６）と、関連する２つの代替ＦＥＣデータパケットセット７１６および７１８とを有する構成７００が示してある。ＦＥＣデータパケットセット７１６は、ＦＥＣデータパケット７３１から７３８までを含み、ＦＥＣデータパケットセット７１８は、ＦＥＣデータパケット７２１から７２８までを含む。構成７００は、ＦＥＣ符号化が連続的なストリームメディアデータパケットまたは不連続的なデータパケットに適用できることを示している。この場合に例えば、影付きの領域７４２で表すように、ＦＥＣ符号化を連続的なデータパケット７０１〜７０４に適用して、関連するＦＥＣデータパケット７２１および７２２を生み出すことができる。あるいは、影付きの領域７４０で表すように、ＦＥＣ符号化を不連続的なデータパケット７０１、７０５、７０９、７１３に適用して、関連するＦＥＣデータパケット７３１および７３２を生み出すことができる。両方の例で、エラー訂正密度は４：２であることに留意されたい。
【００７２】
【発明の効果】
本発明のいくつかの実装形態によれば、不連続的なデータパケットを符号化する方が、ある種の無線リンク中で一般的に経験されるバーストエラーの有害な影響を低減することができるので有利である。しかし、このような不連続的な符号化は、比較できる連続的な符号化よりも多くのメモリを必要とする（送信デバイス３０２と受信デバイス３０４の両方で）。
【００７３】
本発明のいくつかの実装形態によれば、ロジック３０８およびロジック３１６（図３参照）はさらに、連続的符号化と不連続的符号化の間で選択的／動的に切り替わるように構成される。したがって例えば、受信デバイス３０４と送信デバイス３０２は、特定のタイプのエラー訂正符号化を用いるように、最初に／動的に交渉することができる。この追加能力を用いて、ストリームメディアプロセスをさらに改善することができる。
【００７４】
本発明による他のいくつかの実装形態によれば、ロジック３０８およびロジック３１６はさらに、ストリームメディアのコンテンツに基づいて、エラー訂正符号化をストリームメディアに選択的／動的に適用するように構成することができる。例として、ビデオコンテンツとオーディオコンテンツに異なるエラー訂正符号化を適用することができる。
【００７５】
他のいくつかの実装形態では、例えば、ストリームビデオの異なる部分に異なるエラー訂正符号化を適用することができる。したがってニュース放送で、挿入されるコマーシャル部分をニュース部分とは異なるレベルでエラー訂正符号化することができる。他の実装形態によれば、異なるタイプのビデオフレームデータを搬送するストリームメディアデータパケットに異なるエラー訂正符号化を適用することができる。例えばＭＰＥＧストリームで、Ｉフレームを有するデータパケットを、Ｐフレームを有するデータパケットよりも高いレベルでエラー訂正符号化することができる。
【００７６】
本発明の様々な方法および装置に関するいくつかの好ましい実装形態を、添付の図面に示し、以上の詳細な説明に述べたが、本発明は、開示した例示的な実装形態に限定されるのではなく、頭記の特許請求の範囲に記述および定義する本発明の趣旨を逸脱することなく多くの再構成、修正、および代用が可能であることを理解されたい。
【図面の簡単な説明】
【図１】本発明のいくつかの実装形態による、ストリームメディアを提供、受信、および／または他の方法で通信する際に使用するのに適した、コンピュータの形をとる例示的なデバイスを示すブロック図である。
【図２】本発明のいくつかの実装形態による、送信デバイスと受信デバイスの間でメディアをストリーミングするのに適した無線通信リンクを含む例示的な通信環境を示すブロック図である。
【図３】本発明のいくつかの例示的な実装形態による、例えば図２のような通信環境で受信デバイスにメディアをストリーミングする送信デバイスを示すブロック図である。
【図４】本発明のいくつかの例示的な実装形態による、例えば図３のような受信デバイス中で用いられる方法を示す流れ図である。
【図５】本発明のいくつかの例示的な実装形態による、例えば図３のような送信デバイス中で用いられる方法を示す流れ図である。
【図６】本発明のいくつかの例示的な実装形態による、例えば図３のような送信デバイスと受信デバイスの間でメディアをストリーミングするのをサポートする際に使用するのに適したメッセージフォーマットの一部を示す例示的な図である。
【図７】本発明のいくつかの例示的な実装形態による、データパケットの行列にエラー訂正を適用する際に使用される２つの例示的技法を示す例示的な図である。
【符号の説明】
１２０  コンピューティング環境
１３０  コンピュータ
１３２  プロセッシングユニット／プロセッサ
１３４  システムメモリ
１３６  バス
１３８  ＲＯＭ
１４０  ＲＡＭ
１４２  ＢＩＯＳ
１４４  ハードディスクドライブ
１４６  磁気ディスクドライブ
１４８  磁気ディスク
１５０  光ディスクドライブ
１５２  光ディスク
１５４  インタフェース
１５８  オペレーティングシステム
１６０  アプリケーションプログラム
１６２  その他のプログラムモジュール
１６４  プログラムデータ
１６６  キーボード
１６８  ポインティングデバイス
１７０  ユーザ入力インタフェース
１７２  モニタ
１７４  ビデオアダプタ
１７５  出力周辺インタフェース
１７７  ＬＡＮ
１７８  モデム
１７９  ＷＡＮ
１８０  インターネット
１８２  リモートコンピュータ
１８６  ネットワーク
１８９  リモートアプリケーションプログラム
２００  通信環境
２０２  サーバ
２０４  ネットワーク
２０６  サーバ
２０８  アンテナ
２１０  受信デバイス
２１２  トラック
２１４  要求メッセージ
２１６  要求エラー訂正レベル
３０２  送信デバイス
３０４  受信デバイス
３０６  データ接続
３０６ａ  ＲＴＰデータストリーム
３０６ｂ  ＲＴＰ  ＦＥＣデータストリーム
３０８  ロジック
３１０  通信インタフェース
３１２  メモリ
３１４  管理インタフェース
３１６  ロジック
３１８  通信インタフェース
３２０  メモリ
３２２  アプリケーションインタフェース
３２４  アプリケーション
６００  拡張ＲＴＰメッセージヘッダ
７０１〜７１６  メディアデータパケット
７２１〜７２８  ＦＥＣデータパケット
７３１〜７３８  ＦＥＣデータパケット
【図１】
0004118617.tif 000002
【図２】
0004118617.tif 000003
【図３】
0004118617.tif 000004
【図４】
0004118617.tif 000005
【図５】
0004118617.tif 000006
【図６】
0004118617.tif 000007
【図７】
0004118617.tif 000008