(57)【特許請求の範囲】
【請求項１】
静的メディアデータの再生にかかる静的メディア再生用データを転送し順次再生させるための静的メディア伝送用データの伝送データ構造であって、
前記静的メディア再生用データは、前記静的メディアデータを分割した複数の分割静的メディアデータと、前記分割静的メディアデータを再生するための情報を含む静的メディアヘッダデータとを含み、
前記静的メディア伝送用データは、前記分割静的メディアデータに付加された分割静的メディアデータ識別子と、前記静的メディアヘッダデータに付加された静的メディアヘッダデータ識別子と、次期静的メディア伝送用データに含まれる分割静的メディアデータに関わる静的メディア情報と、を含むことを特徴とする静的メディア伝送用データの伝送データ構造。
【請求項２】
プログラムデータの再生にかかるプログラム再生用データを転送し順次再生させるためのプログラム伝送用データの伝送データ構造であって、
前記プログラム再生用データは、前記プログラムデータを分割した複数の分割プログラムデータと、前記分割プログラムデータを再生するための情報を含むプログラムヘッダデータとを含み、
前記プログラム伝送用データは、前記分割プログラムデータに付加された分割プログラムデータ識別子と、前記プログラムヘッダデータに付加されたプログラムヘッダデータ識別子と、次期プログラム伝送用データに含まれる分割プログラムデータに関わるプログラム情報と、を含むことを特徴とするプログラム伝送用データの伝送データ構造。
【請求項３】
テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの伝送データ構造であって、
前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータを再生するための情報を含むテキストヘッダデータとを含み、
前記テキスト伝送用データは、前記分割テキストデータに付加された分割テキストデータ識別子と、前記テキストヘッダデータに付加されたテキストヘッダデータ識別子と、次期テキスト伝送用データに含まれる分割テキストデータに関わるテキスト情報と、を含むことを特徴とするテキスト伝送用データの伝送データ構造。
【請求項４】
前記次期テキスト伝送用データに含まれる分割テキストデータに関わるテキスト情報は、
次期テキスト伝送用データに含まれる分割テキストデータの個数を含む、
ことを特徴とする請求項３に記載のテキスト伝送用データの伝送データ構造。
【請求項５】
前記次期テキスト伝送用データに含まれる分割テキストデータに関わるテキスト情報は、
次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報を含む、
ことを特徴とする請求項３に記載のテキスト伝送用データの伝送データ構造。
【請求項６】
前記次期テキスト伝送用データに含まれる分割テキストデータにかかわるテキスト情報は、
次期テキスト伝送用データに含まれる分割テキストデータのテキストデータ長情報を含む、
ことを特徴とする請求項３に記載のテキスト伝送用データの伝送データ構造。
【請求項７】
テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの伝送方法であって、
前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータの再生を開始する再生開始情報を含むテキストヘッダデータとを含み、前記テキスト再生用データに基づいて、前記テキスト伝送用データのペイロード部を作成するペイロード部作成ステップと、
次期パケットに含まれるテキスト情報を付加した前記テキスト伝送用データのヘッダ部を作成するヘッダ部作成ステップと、
前記作成された前記各ペイロード部に対して前記ヘッダ部を付加し、パケットとするヘッダ付加ステップとを備え、前記各ペイロード部は、前記テキストヘッダデータの再生開始情報を含むことを特徴とするテキスト伝送用データの伝送方法。
【請求項８】
テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの伝送方法であって、
前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータの再生を開始する再生開始情報を含むテキストヘッダデータとを含み、前記テキスト再生用データに基づいて、前記テキスト伝送用データのペイロード部を作成するペイロード部作成ステップと、
次期パケットに含まれる分割テキストデータ数を付加したテキスト伝送用データのヘッダ部を作成するヘッダ部作成ステップと、
前記作成された前記各ペイロード部に対して前記ヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、前記各ペイロード部は、前記テキストヘッダデータの前記再生開始情報を含むことを特徴とするテキスト伝送用データの伝送方法。
【請求項９】
テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの伝送方法であって、
前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータの再生を開始する再生開始情報を含むテキストヘッダデータとを含み、前記テキスト再生用データに基づいて、前記テキスト伝送用データのペイロード部を作成するペイロード部作成ステップと、
次期パケットに含まれる分割テキストデータの再生時間情報を付加しテキスト伝送用データのヘッダ部を作成するヘッダ部作成ステップと、
前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、前記各ペイロード部は、前記テキストヘッダデータの前記再生開始情報を含むことを特徴とするテキスト伝送用データの伝送方法。
【請求項１０】
テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの伝送方法であって、
前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータの再生を開始する再生開始情報を含むテキストヘッダデータとを含み、前記テキスト再生用データに基づいて、前記テキスト伝送用データのペイロード部を作成するペイロード部作成ステップと、
次期パケットに含まれる分割テキストデータのテキストデータ長を付加しテキスト伝送用データのヘッダ部を作成するヘッダ部作成ステップと、
前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、前記各ペイロード部は、前記テキストヘッダデータの前記再生開始情報を含むことを特徴とするテキスト伝送用データの伝送方法。
【請求項１１】
テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの受信方法であって、
第１のテキスト伝送用データを受信し、第１のテキストデータの再生時間が経過後、第２のテキスト伝送用データが受信されない場合データ損失があったと判定するデータ損失判定ステップと、
データ損失と判定された場合、第１のテキスト伝送用データに含まれる次期テキスト伝送用データに含まれる分割テキストデータにかかわるテキスト情報を第２のテキスト伝送データとする置き換えステップと
を備えたことを特徴とするテキスト伝送用データの受信方法。
【請求項１２】
テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの受信表示方法であって、
第１のテキスト伝送用データを受信し、第１のテキストデータの再生時間が経過後、第２のテキスト伝送用データが受信されない場合データ損失があったと判定するデータ損失判定ステップと、
データ損失と判定された場合、第１のテキスト伝送用データに含まれる次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報を第２のテキスト伝送データとする置き換えステップと、
テキストデータ長が１以上である場合は代替テキストをテキストデータ長表示し、テキストデータ長が０である場合はテキストデータの表示を行わないテキスト表示ステップと
を備えたことを特徴とするテキスト伝送用データのデータ表示方法。
【請求項１３】
サーバーまたは対局からテキストデータを受信するデータ受信部と、
受信データからテキストデータを表示するテキスト表示時間を抽出するテキスト表示時間抽出部と、
次期テキストデータのテキストデータ情報が格納されている拡張ヘッダの情報を受信データから抽出して記憶する拡張ヘッダ記憶部と、
テキストデータの損失を判定するデータ損失判定部と、
受信したデータからテキストデータを抽出し記憶するテキスト抽出・記憶部と、
表示すべきテキストデータが受信されなかった場合に表示する代替テキストを記憶する代替テキスト記憶部と、
前記データ損失判定部でデータの損失が判定された場合は前記拡張ヘッダ記憶部から入力されるテキスト表示時間をテキストを表示する時間として決定し、データの損失がないと判定された場合は前記テキスト表示時間抽出部から入力されるテキスト表示時間をテキストを表示する時間として決定するテキスト表示時間決定部と、
前記データ損失判定部でデータの損失がないと判定された場合は前記テキスト抽出・記憶部に記憶されたテキストを表示することを決定し、前記データ損失判定部でデータの損失があると判定された場合は、前記代替テキスト記憶部に記憶されている代替テキストを表示することを決定する表示テキスト決定部と、
前記テキスト表示時間決定部で決定された時間、前記表示テキスト決定部で決定されたテキストを表示するテキスト表示部と
を具備することを特徴とするデータ受信装置。
【請求項１４】
対局にテキストデータを送信するデータ送信装置であって、
対局に送信するテキスト情報を記憶するテキスト情報記憶部と、
現在生成中の送信データの次の送信データとして送信するテキストに含まれるテキスト長及び／または再生時間を含む情報を生成する次期テキストデータ情報生成部と、
テキストデータ伝送のための制御情報等と前記次期テキストデータ情報生成情報からヘッダを生成するヘッダ生成部と、
伝送するテキストデータおよびその修飾情報から伝送データのペイロードを生成するペイロード生成部と、
前記ヘッダと前記ペイロードから送信データを合成する送信データ合成部と、
前記送信データを対局に送信するデータ送信部と
を具備することを特徴とするデータ送信装置。
【請求項１５】
静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの伝送データ構造であって、
前記静止画再生用データは、前記静止画データを分割した複数の分割静止画データと、前記分割静止画データを再生するための情報を含む静止画ヘッダデータとを含み、
前記静止画伝送用データは、前記分割静止画データに付加された分割静止画データ識別子と、前記静止画ヘッダデータに付加された静止画ヘッダデータ識別子と、次期静止画伝送データに含まれる分割静止画データにかかわる静止画情報と、を含むことを特徴とする静止画伝送用データの伝送データ構造。
【請求項１６】
前記次期静止画伝送データに含まれる分割静止画データに関わる静止画情報は、
次期静止画伝送データに含まれる分割静止画データの個数を含むことを特徴とする請求項１５に記載の静止画伝送用データの伝送データ構造。
【請求項１７】
前記次期静止画伝送データに含まれる分割静止画データに関わる静止画情報は、次期静止画伝送データに含まれる分割静止画データの静止画再生時間情報を含むことを特徴とする請求項１５に記載の静止画伝送用データの伝送データ構造。
【請求項１８】
前記次期静止画伝送データに含まれる分割静止画データに関わる静止画情報は、次期静止画伝送データに含まれる分割静止画データの静止画サイズ情報を含むことを特徴とする請求項１５に記載の静止画伝送用データの伝送データ構造。
【請求項１９】
静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの伝送方法であって、
前記静止画再生用データは、前記静止画データを分割した複数の分割静止画データと、前記分割静止画データの再生を開始する再生開始情報を含む静止画ヘッダデータとを含み、前記静止画再生用データに基づいて、前記静止画伝送用データのペイロード部を作成するペイロード部作成ステップと、
次期パケットに含まれる静止画情報付加して前記静止画伝送用データのヘッダ部を作成するヘッダ部作成ステップと、
前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、
前記各ペイロード部は、前記静止画ヘッダデータの前記再生開始情報を含むことを特徴とする静止画伝送用データの伝送方法。
【請求項２０】
静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの伝送方法であって、
前記静止画再生用データは、前記静止画データを分割した複数の分割静止画データと、前記分割静止画データの再生を開始する再生開始情報を含む静止画ヘッダデータとを含み、前記静止画再生用データに基づいて、前記静止画伝送用データのペイロード部を作成するペイロード部作成ステップと、
次期パケットに含まれる分割静止画データ数を付加して静止画伝送用データのヘッダ部を作成するヘッダ部作成ステップと、
前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、
前記各ペイロード部は、前記静止画ヘッダデータの前記再生開始情報を含むことを特徴とする静止画伝送用データの伝送方法。
【請求項２１】
静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの伝送方法であって、
前記静止画再生用データは、前記静止画データを分割した複数の分割静止画データと、前記分割静止画データの再生を開始する再生開始情報を含む静止画ヘッダデータとを含み、前記静止画再生用データに基づいて、前記静止画伝送用データのペイロード部を作成するペイロード部作成ステップと、
次期パケットに含まれる分割静止画データの再生時間情報を付加して静止画伝送用データのヘッダ部を作成するヘッダ部作成ステップと、
前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、
前記各ペイロード部は、前記静止画ヘッダデータの前記再生開始情報を含むことを特徴とする静止画伝送用データの伝送方法。
【請求項２２】
静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの伝送方法であって、
前記静止画再生用データは、前記静止画データを分割した複数の分割静止画データと、前記分割静止画データの再生を開始する再生開始情報を含む静止画ヘッダデータとを含み、前記静止画再生用データに基づいて、前記静止画伝送用データのペイロード部を作成するペイロード部作成ステップと、
次期パケットに含まれる分割静止画データの静止画サイズを付加して静止画伝送用データのヘッダ部を作成するヘッダ部作成ステップと、
前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、
前記各ペイロード部は、前記静止画ヘッダデータの前記再生開始情報を含むことを特徴とする静止画伝送用データの伝送方法。
【請求項２３】
静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの受信方法であって、
第１の静止画伝送用データを受信し、第１の静止画データの再生時間が経過後、第２静止画の静止画伝送用データが受信されない場合データ損失があったと判定するデータ損失判定ステップと、
データ損失と判定された場合第１の静止画伝送用データに含まれる次期静止画伝送データに含まれる分割静止画データに関わる静止画情報を第２の静止画伝送データとする置き換えステップと
を備えたことを特徴とする静止画伝送用データの受信方法。
【請求項２４】
静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの受信表示方法であって、
第１の静止画伝送用データを受信し、第１の静止画データの再生時間が経過後、第２静止画の静止画伝送用データが受信されない場合データ損失があったと判定するデータ損失判定ステップと、
データ損失と判定された場合第１の静止画伝送用データに含まれる次期静止画伝送データに含まれる分割静止画データに関わる静止画情報を第２の静止画伝送データとする置き換えステップと、
静止画サイズのサイズに応じて代替静止画を表示する静止画表示ステップと
を備えた静止画伝送用データの表示方法。
【請求項２５】
サーバーまたは対局から静止画データを受信するデータ受信部と、
受信データから静止画データを表示する静止画表示時間を抽出する静止画表示時間抽出部と、
次期静止画データの静止画データ情報が格納されている拡張ヘッダの情報を記憶する拡張ヘッダ記憶部と、
静止画データの損失を判定するデータ損失判定部と、
受信したデータから静止画データを抽出し記憶する静止画抽出・記憶部と、
表示すべき静止画データが受信されなかった場合に表示する静止画を記憶する代替静止画記憶部と、
前記データ損失判定部でデータの損失があると判定された場合は前記拡張ヘッダ記憶部から入力される静止画表示時間を静止画を表示する時間と決定し、データの損失がないと判定された場合は前記静止画表示時間抽出部から入力される静止画表示時間を静止画を表示する時間と決定する静止画表示時間決定部と、
前記データ損失判定部でデータの損失がないと判定された場合は前記静止画抽出・記憶部に記憶された静止画を表示することを決定し、データの損失があると判定された場合は、前記代替静止画記憶部に記憶されている代替静止画を表示することを決定する表示静止画決定部と、
前記静止画表示時間決定部で決定された時間、前記表示静止画決定部で決定された静止画を表示する静止画表示部と
を具備することを特徴とするデータ受信装置。
【請求項２６】
対局に静止画データを送信するデータ送信装置であって、
対局に送信する静止画情報を記憶する静止画情報記憶部と、
現在生成中の送信データの次の送信データとして送信する静止画に含まれる静止画サイズや再生時間等の情報を生成する次期静止画データ情報生成部と、
静止画データ伝送のための制御情報等と前記次期静止画データ情報生成情報からヘッダを生成するヘッダ生成部と、
伝送する静止画データおよびその修飾情報から伝送データのペイロードを生成するペイロード生成部と、
前記ヘッダと前記ペイロードから送信データを合成する送信データ合成部と、
前記送信データを対局に送信するデータ送信部と
を具備することを特徴とするデータ送信装置。
【請求項２７】
静的メディアデータを再生させるために、前記静的メディアデータと前記静的メディアデータの再生時間を表す情報を伝送するデータ伝送方法であって、
前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表すデータを前記静的メディアデータとともに伝送するデータ伝送方法。
【請求項２８】
複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間及び前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表す静的メディア伝送用データを受信するデータ受信方法であって、
第１の静的メディア伝送用データを受信した後、この第１の静的メディア伝送用データを基に再生される第１の静的メディアデータの再生時間が経過後、前記第１の静的メディアデータに続く前記次期静的メディアデータを再生するための第２の静的メディア伝送用データが受信されたか否かを判断する受信結果判断ステップと、
前記受信結果判断ステップの判断結果に基づいて、前記第２の静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定ステップと、
前記データ損失判定ステップにおいてデータ損失があったものと判定された場合、前記第１の静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始ステップと、
前記第１の静的メディア伝送用データに含まれる、前記次期静的メディアデータの再生時間に基づき、この次期静的メディアデータの再生時間の経過に応じて前記第２の静的メディア伝送用データの再送要求の送信を終了する再送要求送信終了ステップと、
を具備するデータ受信方法。
【請求項２９】
前記再送要求送信終了ステップでは、
前記第２の静的メディア伝送用データの再送要求の送信を終了するタイミングとして、前記次期静的メディアデータの再生時間が終了する時間から、前記静的メディア伝送用データの送信側と受信側間でデータを往復伝送するために要する往復時間だけ遡った時間が設定される
ことを特徴とする請求項２８記載のデータ受信方法。
【請求項３０】
静的メディアデータを再生させるために、前記静的メディアデータと前記静的メディアデータの再生時間を表す情報を伝送するデータ伝送方法であって、
前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表すデータと前記次期静的メディアデータに含まれる文字数を表す情報とを前記静的メディアデータとともに伝送するデータ伝送方法。
【請求項３１】
複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間及び前記静的メディアデータの次に再生される次期静的メディアデータの再生時間と前記次期静的メディアデータに含まれる文字数とを表す静的メディア伝送用データを受信するデータ受信方法であって、
静的メディア伝送用データを受信した後、この静的メディア伝送用データを基に再生される静的メディアデータの再生時間が経過後、前記静的メディアデータに続く前記次期静的メディアデータを再生するための次期静的メディア伝送用データが受信されたか否かを判断する受信結果判断ステップと、
前記受信結果判断ステップの判断結果に基づいて、前記次期静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定ステップと、
前記データ損失判定ステップにおいてデータ損失があったものと判定された場合、前記静的メディア伝送用データによって示される、次期静的メディアデータの文字数が０より大きいことを条件に、前記静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始ステップと、
を具備するデータ受信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばテキストデータ等の静的メディアデータを伝送する伝送データ構造及びそれを伝送するための方法及び装置に関する。
【０００２】
【従来の技術】
第三世代移動通信（W-CDMA）の国際標準規格を策定する団体3GPP(Third Generation Partnership Project) のSA（Service and System Aspect） WG4グループでは、マルチメディア配信規格TS26.234を策定している（例えば非特許文献１等参照）。マルチメディア配信規格TS26.234バージョン5.2.0では、ダウンロード型マルチメディア配信に使用可能なMP4（ISO/IEC 14496-1:2001）形式のファイルを拡張しテキストデータのデータ構造を規定している（Timed Text）。これによって、MP4ファイルをダウンロードしながら再生するサービスにおいて、ビデオやオーディオのみならず、テキストも再生することが可能になっている。
【０００３】
テキストによる情報通知は、伝えたい情報を直接に使用者に伝えることができ、ビデオに比べて、データ量はきわめて少なくて済むため、情報通知手段としては非常に重要である。上述のようなMP4ファイルをダウンロードしながら再生するサービスにおいては、ビデオとテキストとを合成して符号化し伝送するのではなく、テキストを独立したトラックとして伝送するため、テキストがつぶれて読めなくなることが少なくなっており、有効に情報通知を行うことが可能となっている。
【０００４】
さらに、3GPPで規定したTimed Textでは、テキストの一部を修飾したり、移動させたり、あるいは文字列に他のURLへのリンクを貼り付けたりすることが可能である（スタイル、ハイライト、カラオケ、テキストボックス、ブリンク、スクロール、ハイパーリンク、他）。これにより、伝えたい情報をさまざまな表現形式で再生することが可能となっている。
【０００５】
ここで、図１８を用いて、3GPPで規定したTimed Textのデータ構造について説明する。
【０００６】
MP4ファイル３０００は、ヘッダ部３０１０とデータ部３０２０とから構成される。ヘッダ部３０１０は、トラックヘッダ３０３０と、サンプルディスクリプション３０４０と、サンプルテーブル３０５０とを備えている。データ部３０２０は、テキストサンプル３０６０、３０６１、…を備えている。
【０００７】
トラックヘッダ３０３０は、Timed Textの再生にかかる情報であり、レイアウト（表示領域の大きさ、ビデオとの相対位置）、レイヤ（ビデオ等他のメディアとの階層関係）、Timed Textの再生時間、ファイルの再生日時、後述するTime-to-Sample-Box ３０５１のタイムスケール等の情報を含んでいる。
【０００８】
サンプルディスクリプション３０４０は、複数のサンプルエントリ３０４１、３０４２、…を有している。サンプルエントリ３０４１，３０４２、…は、テキストサンプル３０６０、３０６１、…のデフォルトの書式にかかる情報であり、スクロールの有無と方向、水平・垂直の寄せ位置、背景色、フォント名、フォントサイズ等を含んでいる。
【０００９】
サンプルテーブル３０５０は、Time-to-Sample-Box ３０５１と、Sample-Size-Box ３０５２と、Sample-to-Chunk-Box ３０５３とを有している。Time-to-Sample-Box ３０５１は、テキストサンプル３０６０、３０６１、…のそれぞれの再生時間に関する情報３０５５、３０５６、…をテキストサンプル３０６０、３０６１、…の配置順に含んでいる。情報３０５５、３０５６、…が格納する値のタイムスケールは、トラックヘッダ３０３０により指定されている。具体的には、トラックヘッダ３０３０は、タイムスケールとして、１秒間の解像度を格納しており、例えば、トラックヘッダ３０３０が格納するタイムスケールの値が［１０００］の場合、１／１０００秒単位の解像度となる。従ってテキストサンプル３０６０、３０６１、…それぞれの再生時間を秒換算した値は、情報３０５５、３０５６、…をトラックヘッダ３０３０が格納するタイムスケールの値を除算した値となり、例えば、タイムスケールの値が［１０００］の場合、情報３０５６の示す値［３４００］は、テキストサンプル３０６１を３．４秒間再生することを意味している。以下、タイムスケールの値が［１０００］と設定されているとして説明を行う。Sample-Size-Box３０５２は、テキストサンプル３０６０、３０６１、…のそれぞれのデータ長に関する情報３０５７、３０５８、…をテキストサンプル３０６０、３０６１、…の配置順に含んでいる。これにより、再生側では、テキストサンプル３０６０、３０６１、…のそれぞれの情報の境目を検出することができる。Sample-to-Chunk-Box ３０５３は、テキストサンプル３０６０、３０６１、…のそれぞれとサンプルエントリ３０４１、３０４２、…のそれぞれとを関連付ける情報を含んでいる。
【００１０】
テキストサンプル３０６０は、テキスト３０６５と、テキスト３０６５のデータ長３０６６と、モディファイア３０６７とを有している。モディファイア３０６７は、テキスト３０６５のオプションの書式についての情報であり、テキスト３０６５をハイライト、カラオケ、ブリンク、ハイパーリンク等により再生させるための情報である。その他のテキストサンプル３０６１、…は、テキストサンプル３０６０と同様のデータ構造であるため、説明を省略する。
【００１１】
次に、図１９を用いて、Timed Textの再生に関して具体的に説明する。
【００１２】
まず、サンプルエントリ３０４１の詳細な構造について図１９（ａ）を参照して説明する。その他のサンプルエントリ３０４２、…については、同様のデータ構造であるので、説明を省略する。サンプルエントリ３０４１は、スクロールの有無と方向（displayFlags）、表示領域内での水平・垂直の寄せ位置(Horizontal justification, Vertical justification)、RGB値および透明度により指定される背景色(bgColor)、表示領域(TextBox)、フォント名(fontTable, font-ID)、フォントサイズ(fontSize)、太字・イタリック・アンダーライン等のスタイル(faceStyle)、RGB値および透明度により指定されるフォント色(textColor)等を含んでいる。なお、この書式を適用する範囲を指定するデータ(startChar,EndChar)は、常に値［０］を取り、サンプルエントリ３０４１の指定する書式が適用されるテキストサンプル中の全範囲のテキストに対して、この書式が適用されることを示している。図１９(ａ)に示すサンプルエントリ３０４１のそれぞれの値は、テキスト３０６５のデフォルトの書式を、背景色を白色、フォント色を黒色およびスタイルをノーマルに指定することを意味している。
【００１３】
次に、モディファイア３０６７の詳細な構造について図１９（ｂ）を参照して説明する。モディファイア３０６７は、モディファイア３０６７のデータ長(modifierSize)、テキスト３０６５のオプション書式の指定(modifierType, entryCount)、オプション書式を適用するテキスト３０６５の範囲の指定(startChar,EndChar)、フォント名(font-ID)、フォントサイズ(fontSize)、太字・イタリック・アンダーライン等のスタイル(faceStyle)、RGB値および透明度により指定されるフォント色(textColor)等を含んでいる。このオプション書式の指定は、サンプルエントリ３０４１、３０４２、…のいずれかで指定された書式に優先して適用される。図１９（ｂ）に示すモディファイア３０６７のそれぞれの値は、テキスト３０６５の５文字目から８文字目までを［太字］にすることを意味している。
【００１４】
図１９（ｃ）に以上の書式が適用されたテキストサンプル３０６０の再生状態を示す。例えば、テキスト３０６５が示す内容が、［It's fine today.］である場合に、5文字目から8文字目の［fine］が太字で再生される。またその再生時間は、Time-to-Sample-Box ３０５１において最初に配置される情報３０５５の値［１０００］により、１０００［ミリ秒］であることが分かる（図１８参照）。
【００１５】
以上に説明した構造をもつMP4ファイルの再生に際しては、あらかじめ受信端末にてMP4ファイルをダウンロードし、ダウンロード完了後に受信端末にてMP4ファイルの再生が行われる。MP4ファイルのダウンロードには、通常、信頼性のある伝送プロトコルであるＴＣＰが用いられ、MP4ファイルが完全な形で受信端末に受信されることを保証する。
【００１６】
【非特許文献１】
'3GPP TS26.234 v5.0.0.'Page56.[online].3GPP,2002.[Retrieved on 2002-10-07].Retrieved from the Internet:<URL:ftp://ftp.3gpp.org/Specs/2002-03/Rel-5/26_series/26234-500.zip>
【００１７】
【発明が解決しようとする課題】
一方、ビデオ、オーディオを含むメディアデータを配信するサービスにおいて、ダウンロード型に代えてストリーミング型の配信が採用されることも多くなってきている。ストリーミング型の配信では、受信端末にてメディアデータを受信する処理と、受信したメディアデータを再生する処理とが並行して行われる。このため、長時間のメディアデータを再生する場合であっても、そのメディアデータの要求を行ってから再生が行われるまでの待ち時間が、少なくなるという利点を持つ。また、生中継されるメディアデータの配信にも好適な配信形式である。
【００１８】
このようなストリーミング型の配信においては、メディアデータを伝送するための伝送プロトコルとしては、ＴＣＰではなくＲＴＰ／ＵＤＰが用いられる。ＴＣＰが信頼性のあるプロトコルであり、データの伝送を保証するのに対して、ＲＴＰ／ＵＤＰは非信頼性プロトコルであり、リアルタイム性に優れるため、ストリーミング型配信に好適である。
【００１９】
ＲＴＰを用いテキストや静止画といった静的メディアをＲＴＰを用いて伝送する方式として、Generic RTP Payload Format for Time-lined static Media (http://standards.ericsson.net/westerlund/draft-westerlund-avt-rtp-static-media-00.txt)がある。この方式では、再生時間(duration) を表すためにDurationヘッダを付与したフォーマットであり、再生時間が受信側に通知されるという特徴がある。また、ＴＣＰではなくＲＴＰを用いることから、静的メディアのリアルタイム送信利用することが可能となっている。
【００２０】
しかしながら、ＲＴＰ／ＵＤＰを用いるストリーミング型配信の場合、有線ネットワーク上や無線伝送路上でメディアデータを含んだパケットが損失する場合があり、再生すべきテキストが表示できない。パケットが損失した場合、または次に再生すべきメディアデータが送信されない場合、いずれの場合であっても、受信端末では何もデータを受信しないので、次に表示すべきメディアデータがないのか、伝送途中にメディアデータが損失したため表示できないのか、受信端末は判定できないという課題があった。そのため、「ただいまデータを受信できません」というような表示を行い、ユーザにメディアデータの損失を通知することができなかった。
【００２１】
一方、ＲＴＰを用いたストリーミングの場合、伝送路の状況に応じてパケットロス（パケット損失）が発生する場合がある。ＲＴＰによるパケット伝送においては、ＲＴＰに付与されたシーケンス番号（ＳＮ）からパケットロスを検出する。すなわち、ＳＮが４であるパケットを受信しない間にＳＮが５であるパケットを受信した場合、ＳＮが４であるＲＴＰパケットが損失したと判定する。音声及び映像データといった連続メディアの場合、各ＲＴＰパケットの送信間隔は、数１０ミリ秒から１００ミリ秒程度の短い間隔であるため、このようなパケットロス判定方法が可能である。パケットロスの品質への影響が大きい場合には、さらに、パケットロスの判定後、再送要求を行うことで品質劣化を防ぐことも可能である。この場合、再送による遅延を吸収するため、メディアの再生を開始する前に、通常、２〜３秒間データを先行して取得するプレバッファリング時間を設けることが行われている。
【００２２】
しかしながら、Timed TextといったテキストメディアやＪＰＥＧ等の静止画等の静的メディアに、ＲＴＰを用いたストリーミングを適用した場合、次のような問題がある。静的メディアの再生時間、すなわち、同一テキストや同一静止画を表示する時間は、通常数秒から１０数秒であるため、ＲＴＰパケット送信間隔はそれに応じて数秒から１０数秒となる。このＲＴＰパケット送信間隔は、パケットロス検出に要する時間に等しく、通常のプレバッファリング時間よりも大きい。そのため、パケットロス検出に要する時間をプレバッファリング時間で吸収することが困難である。また、プレバッファリング時間を、例えば１０〜２０秒程度に大きくすれば、ユーザの快適性を著しく阻害するという問題がある。
【００２３】
本発明はかかる点に鑑みてなされたものであり、Timed Text等の静的メディアをストリーミング型の配信で使用する場合に、データ受信端末が静的メディアデータを受信しない場合、次に表示すべきメディアデータがないのか、伝送途中にメディアデータが損失したため表示できないのかを判定し、ユーザにメディアデータの損失を正しく通知するためのデータ構造、データ送信装置、データ受信装置を提供することを目的とする。
【００２４】
また、本発明は、Timed Text等の静的メディアをストリーミング型の配信で使用する場合に、プレバッファリングを増加させることなく、パケットロス検出に要する時間を短くして再送要求を行うデータ伝送方法およびデータ受信装置を提供することを目的とする。
【００２５】
【課題を解決するための手段】
本発明の静的メディア伝送用データの伝送データ構造は、静的メディアデータの再生にかかる静的メディア再生用データを転送し順次再生させるための静的メディア伝送用データの伝送データ構造であって、前記静的メディア再生用データは、前記静的メディアデータを分割した複数の分割静的メディアデータと、前記分割静的メディアデータを再生するための情報を含む静的メディアヘッダデータとを含み、前記静的メディア伝送用データは、前記分割静的メディアデータに付加された分割静的メディアデータ識別子と、前記静的メディアヘッダデータに付加された静的メディアヘッダデータ識別子と、次期静的メディア伝送用データに含まれる分割静的メディアデータに関わる静的メディア情報と、を含む構成を採る。
【００２６】
この構成によれば、次期静的メディア伝送データに含まれる分割静的メディアデータの個数と次期静的メディア伝送データに含まれる分割静的メディアデータの静的メディア再生時間情報と次期静的メディア伝送データに含まれる分割静的メディアデータの静的メディアデータ長情報を含む次期静的メディア伝送データに含まれる分割静的メディアデータにかかわる静的メディア情報とを含むので、次期静的メディア伝送データが伝送エラー等の理由により損失した場合であっても、代替静的メディアを正確なデータ長と再生時間で表示することができる。なお、静的メディアデータとは、ＣＧ（Computer Graphics）等を構成するデータを意味する。
【００２７】
本発明のプログラム伝送用データの伝送データ構造は、プログラムデータの再生にかかるプログラム再生用データを転送し順次再生させるためのプログラム伝送用データの伝送データ構造であって、前記プログラム再生用データは、前記プログラムデータを分割した複数の分割プログラムデータと、前記分割プログラムデータを再生するための情報を含むプログラムヘッダデータとを含み、前記プログラム伝送用データは、前記分割プログラムデータに付加された分割プログラムデータ識別子と、前記プログラムヘッダデータに付加されたプログラムヘッダデータ識別子と、次期プログラム伝送用データに含まれる分割プログラムデータに関わるプログラム情報と、を含む構成を採る。
【００２８】
この構成によれば、次期プログラム伝送データに含まれる分割プログラムデータの個数と次期プログラム伝送データに含まれる分割プログラムデータのプログラム再生時間情報と次期プログラム伝送データに含まれる分割プログラムデータのプログラムデータ長情報を含む次期プログラム伝送データに含まれる分割プログラムデータにかかわるプログラム情報とを含むので、次期プログラム伝送データが伝送エラー等の理由により損失した場合であっても、代替プログラムを正確なデータ長と再生時間で表示することができる。なお、プログラムデータとは、ＪＡＶＡ(Ｒ)言語によるプログラムや、ＸＭＬ言語を利用したスクリプト等を含むものとする。
【００２９】
本発明のテキスト伝送用データの伝送データ構造は、テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータを再生するための情報を含むテキストヘッダデータとを含み、前記テキスト伝送用データは、前記分割テキストデータに付加された分割テキストデータ識別子と、前記テキストヘッダデータに付加されたテキストヘッダデータ識別子と、次期テキスト伝送データに含まれる分割テキストデータの個数と次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報と、を含む構成を採る。
【００３０】
この構成によれば、次期テキスト伝送データに含まれる分割テキストデータの個数と次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報とを含むので、次期テキスト伝送データが伝送エラー等の理由により損失した場合であっても、代替テキストを正確なテキスト長と再生時間で表示することができる。
【００３１】
本発明のテキスト伝送用データの伝送方法は、前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータの再生を開始する再生開始情報を含むテキストヘッダデータとを含み、前記テキスト再生用データに基づいて、前記テキスト伝送用データのペイロード部を作成する作成ステップと、次期パケットに含まれる分割テキストデータ数と、次期パケットに含まれる分割テキストデータの再生時間情報と、次期パケットに含まれる分割テキストデータのテキストデータ長とを付加しテキスト伝送用データのヘッダ部を作成する作成ステップと、前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとする付加ステップとを備え、前期各ペイロード部は、前記テキストヘッダデータの前記再生開始情報を含むようにした。
【００３２】
この方法によれば、次期テキスト伝送データに含まれる分割テキストデータの個数と次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報とを伝送するので、次期テキスト伝送データが伝送エラー等の理由により損失した場合であっても、代替テキストを正確なテキスト長と再生時間で表示することができる伝送方法を可能とする。
【００３３】
本発明のデータ受信装置は、サーバーまたは対局からテキストデータを受信するデータ受信部と、受信データからテキストデータを表示するテキスト表示時間を抽出するテキスト表示時間抽出部と、次期テキストデータのテキストデータ情報が格納されている拡張ヘッダの情報を記憶する拡張ヘッダ記憶部と、テキストデータの損失を判定するデータ損失判定部と、受信したデータからテキストデータを抽出し記憶するテキスト抽出・記憶部と、表示すべきテキストデータが受信されなかった場合に表示するテキストを記憶する代替テキスト記憶部と、前記データ損失判定部でデータの損失があると判定された場合は前記拡張ヘッダ記憶部から入力されるテキスト表示時間をテキストを表示する時間と決定し、データの損失がないと判定された場合は前記テキスト表示時間抽出部から入力されるテキスト表示時間をテキストを表示する時間と決定するテキスト表示時間決定部と、前記データ損失判定部でデータの損失がないと判定された場合は前記テキスト抽出・記憶部に記憶されたテキストを表示することを決定し、データの損失があると判定された場合は、前記代替テキスト記憶部に記憶されている代替テキストを表示することを決定する表示テキスト決定部と、前記テキスト表示時間決定部で決定された時間、前記表示テキスト決定部で決定されたテキストを表示するテキスト表示部とを含む構成を採る。
【００３４】
この構成によれば、次期テキスト伝送データに含まれる分割テキストデータの個数と次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報とを受信するので、次期テキスト伝送データが伝送エラー等の理由により損失した場合であっても、代替テキストを正確なテキスト長と再生時間で表示することができる受信装置を可能とする。
【００３５】
本発明のデータ表示方法は、テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データのデータ受信表示方法であって、第１のテキスト伝送用データを受信し、第１のテキストデータの再生時間が経過後、第２テキストのテキスト伝送用データが受信されない場合データ損失があったと判定するデータ損失判定ステップと、データ損失と判定された場合第１のテキスト伝送用データに含まれる次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報を第２のテキスト伝送データとする置き換えステップと、テキストデータ長が１以上である場合は代替テキストをテキストデータ長表示し、テキストデータ長が０である場合はテキストデータの表示を行わないテキスト表示ステップとを含むようにした。
【００３６】
この方法によれば、次期テキスト伝送データに含まれる分割テキストデータの個数と次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報とを受信するので、次期テキスト伝送データが伝送エラー等の理由により損失した場合であっても、代替テキストを正確なテキスト長と再生時間で表示することができる受信表示方法を可能とする。
【００３７】
本発明のデータ送信装置は、対局にテキストデータを送信するデータ送信装置であって、対局に送信するテキスト情報を記憶するテキスト情報記憶部と、現在生成中の送信データの次の送信データとして送信するテキストに含まれるテキスト長や再生時間等の情報を生成する次期テキストデータ情報生成部と、テキストデータ伝送のための制御情報等と前記次期テキストデータ情報生成情報からヘッダを生成するヘッダ生成部と、伝送するテキストデータおよびその修飾情報から伝送データのペイロードを生成するペイロード生成部と、前記ヘッダと前記ペイロードから送信データを合成する送信データ合成部と、前記送信データを対局に送信するデータ送信部、とを含む構成を採る。
【００３８】
この構成によれば、次期テキスト伝送用データに含まれる分割テキストデータの個数と次期テキスト伝送用データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送用データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送用データに含まれる分割テキストデータに関わるテキスト情報とを送信するので、次期テキスト伝送用データが伝送エラー等の理由により損失した場合であっても、受信側が代替テキストを正確なテキスト長と再生時間で表示することができる送信装置を可能とする。
【００３９】
本発明のデータ伝送方法は、静的メディアデータを再生させるために、前記静的メディアデータと前記静的メディアデータの再生時間を表す情報を伝送するデータ伝送方法であって、前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表すデータを前記静的メディアデータとともに伝送するようにした。
【００４０】
この方法によれば、静的メディアデータの再生側において、次の静的メディアデータが元々あるものであるか否かを判断することができることにより、本来あるべき静的メディアデータが受信されない場合の対応をとることが可能となる。この対応としては、静的メディアデータの再送要求を送信すること、又は、本来あるべき静的データが再生されないことを表示することなどである。
【００４３】
本発明のデータ受信方法は、複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間及び前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表す静的メディア伝送用データを受信するデータ受信方法であって、第１の静的メディア伝送用データを受信した後、この第１の静的メディア伝送用データを基に再生される第１の静的メディアデータの再生時間が経過後、前記第１の静的メディアデータに続く前記次期静的メディアデータを再生するための第２の静的メディア伝送用データが受信されたか否かを判断する受信結果判断ステップと、前記受信結果判断ステップの判断結果に基づいて、前記第２の静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定ステップと、前記データ損失判定ステップにおいてデータ損失があったものと判定された場合、前記第１の静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始ステップと、前記第１の静的メディア伝送用データに含まれる、前記次期静的メディアデータの再生時間に基づき、この次期静的メディアデータの再生時間の経過に応じて前記第２の静的メディア伝送用データの再送要求の送信を終了する再送要求送信終了ステップと、を具備するようにした。
【００４４】
この方法によれば、次期静的メディアデータの再生時間の経過に応じて第２の静的メディア伝送用データの再送要求の送信を終了することができ、無用なデータの送信処理を回避することができる。
【００４５】
本発明のデータ受信方法は、上記方法において、前記再送要求送信終了ステップでは、前記第２の静的メディア伝送用データの再送要求の送信を終了するタイミングとして、前記次期静的メディアデータの再生時間が終了する時間から、前記静的メディア伝送用データの送信側と受信側間でデータを往復伝送するために要する往復時間だけ遡った時間が設定されるようにした。
【００４６】
この方法によれば、第２の静的メディアデータによる次期静的メディアの再生終了タイミングよりも、再送要求を送信してからこの再送要求に応じて第２の静的メディア伝送用データが受信されるまでの時間だけ遡ったタイミングを再送要求の終了タイミングとしたことにより、無用なデータの送信処理を回避することができる。
【００４７】
本発明のデータ伝送方法は、静的メディアデータを再生させるために、前記静的メディアデータと前記静的メディアデータの再生時間を表す情報を伝送するデータ伝送方法であって、前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表すデータと前記次期静的メディアデータに含まれる文字数を表す情報とを前記静的メディアデータとともに伝送するようにした。
【００４８】
この方法によれば、次期静的メディアデータとして再生されるべきデータがない場合には、データ受信装置側において、再送要求を行わせないようにすることにより、無用な再送要求の送信を回避させることができる。
【００４９】
本発明のデータ受信方法は、複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間及び前記静的メディアデータの次に再生される次期静的メディアデータの再生時間と前記次期静的メディアデータに含まれる文字数とを表す静的メディア伝送用データを受信するデータ受信方法であって、静的メディア伝送用データを受信した後、この静的メディア伝送用データを基に再生される静的メディアデータの再生時間が経過後、前記静的メディアデータに続く前記次期静的メディアデータを再生するための次期静的メディア伝送用データが受信されたか否かを判断する受信結果判断ステップと、前記受信結果判断ステップの判断結果に基づいて、前記次期静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定ステップと、前記データ損失判定ステップにおいてデータ損失があったものと判定された場合、前記静的メディア伝送用データによって示される、次期静的メディアデータの文字数が０より大きいことを条件に、前記静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始ステップと、を具備するようにした。
【００５０】
この方法によれば、次期静的メディアデータとして再生されるべきデータがない場合には、再送要求を行わないことにより、無用な再送要求の送信を回避することができる。
【００５３】
【発明の実施の形態】
本発明の骨子は、静的メディア伝送用データに含まれる分割静的メディアデータの再生に関する情報をその静的メディア伝送用データよりも前の静的メディア伝送用データに格納して伝送することにより、分割静的メディアデータが受信されない場合に、その分割静的メディアデータが元々ないものであるか、または損失したものであるかを判断することである。
【００５４】
また、本発明の骨子は、静的メディア伝送用データに含まれる再生時間情報を用いて、再生時間が経過した後に、次に再生すべき静的メディアが受信されない場合に、パケットロスが発生したと判定し、再送要求を行うか否かを判断することである。
【００５５】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００５６】
（実施の形態１）
実施の形態１では、ＲＴＰ（Real Time Transport Protocol）、ＲＴＳＰ（Real Time Streaming Protocol）およびＳＤＰ（Session Description Protocol）を用いたテキストトラックのストリーミング伝送について説明する。ＲＴＰはＩＥＴＦ（Internet Engineering Task Force）が勧告するＲＦＣ１８８９において規定されている、マルチメディアストリームのパケットフォーマットである。ＲＴＳＰ，ＳＤＰは、それぞれ、ＲＦＣ２３２６、ＲＦＣ２３２７で規定される、マルチメディアストリーミングの制御プロトコルである。なお、この実施の形態においては、静的メディアデータとしてテキストデータを用いる場合について説明する。
【００５７】
図１は本発明の実施の形態１に係るデータ受信装置の構成を示すブロック図である。このデータ受信装置は、テキストデータを含むRTPパケット（RTP packet）を受信するデータ受信部１００１と、RTPパケットに含まれるテキストを表示する時間を抽出するテキスト表示時間抽出部１００２と、RTPパケットの拡張ヘッダ部に含まれる次期テキスト長、次期テキスト表示時間記憶部を抽出し記憶する拡張ヘッダ記憶部１００３と、RTPパケットが受信されるべく時刻になっても受信されない場合、RTPパケットの損失または遅延と判定するデータ損失判定部１００４と、RTPパケットに含まれるテキストデータを抽出し、記憶するテキスト抽出・記憶部１００５と、フォント、色などテキストデータを修飾するための修飾情報を受信データから判定するテキスト修飾判定部１００６と、RTPパケットの損失又は遅延により、表示すべきテキストデータが利用できない場合に表示するための代替テキストを記憶する代替テキスト記憶部１００７と、前記テキスト表示時間抽出部１００２で抽出された時間、または、拡張ヘッダ記憶部１００３で記憶された次期テキスト表示時間記憶部からテキストデータを表示する時間を決定するテキスト表示時間決定部１００８と、パケットの損失または遅延がない場合はRTPパケットに含まれるテキストデータを前記テキスト修飾判定部で判定された修飾方法に従って表示テキストを決定し、パケットの損失または遅延がある場合は、前記代替テキスト記憶部１００７で記憶された代替テキストを表示することを決定する表示テキスト決定部１００９と、前記テキスト表示時間決定部１００８で決定された時間、前記表示テキスト決定部１００９で決定されたテキストを表示するテキスト表示部１０１０とを有する。なお、データ損失判定部１００４でデータの損失がないと判定された場合はテキスト抽出・記憶部１００５に記憶されたテキストをテキスト修飾判定部１００６で判定された修飾方法でテキストを表示することを表示テキスト決定部１００９において決定する。
【００５８】
このデータ受信装置において、データ損失判定部１００４がデータの損失がないものと判定すると、テキスト表示時間抽出部１００２においてRTPパケットに含まれるテキストを表示する時間（図２において後述するDuration ８００６）を抽出するとともに、この抽出された時間をテキスト表示時間決定部１００８が選択する。また、このとき、表示テキスト決定部１００９は、データ損失判定部１００４から供給されるデータ損失がない旨の情報に基づいて、テキスト抽出・記憶部１００５によって抽出されたテキストデータ（図２において後述するテキスト８００８）を選択する。これにより、データ損失判定部１００４においてデータの損失がないものと判定された場合には、現在受信中のテキストデータがその現在のRTPパケットに含まれるDuration ８００６によって決定される時間だけテキスト表示部１０１０に表示されることとなる。
【００５９】
これに対して、データ損失判定部１００４においてデータの損失があるものと判定された場合には、その結果に基づいて、表示テキスト決定部１００９は、テキスト抽出・記憶部１００５に代えて、代替テキスト記憶部１００７に記憶されている例えば「＊印」のような代替テキストを選択する。また、このとき、テキスト表示時間決定部１００８は、拡張ヘッダ記憶部１００３に記憶されている前のRTPパケットにおいて受信された拡張ヘッダ（図２において後述するHeader Extension ８００３）の表示時間（図２において後述するNext Sample Duration８２０２,８２０４,８２０６及びNext Sample Length ８２０３,８２０５,８２０７、すなわち現在受信中のデータ損失が生じた部分の表示時間に関する情報）に基づいて、そのNext Sample Durationによって指定される時間だけ代替テキスト記憶部１００７に記憶されている代替テキストをテキスト表示部１０１０に表示させる。但し、拡張ヘッダ記憶部１００３に記憶されているNext Sample Lengthが０である場合は、表示されるテキストが元々ないことを意味していることにより、テキスト表示時間決定部１００８は、Next Sample Durationが指定する間においても、テキスト表示部１０１０には何も表示させないようにする。
【００６０】
このように、現在受信中のRTPパケットのテキストデータの表示時間及びテキストデータの有無を表す情報が、前のRTPパケットの拡張ヘッダに格納されて送信されて来ることにより、この拡張ヘッダを拡張ヘッダ記憶部１００３に記憶しておけば、この記憶された拡張ヘッダに基づいて、データ損失時に、元々テキストデータが有ったのか否かを判断することができ、テキストデータが元々有ったにも関わらずデータ損失判定がなされた場合には、代替テキストをその時間だけ表示させることが可能となる。
【００６１】
ここで、本発明の実施の形態１に係るサーバーが備えるMP4ファイル形式のメディアデータは、RTPパケットとして伝送される。
【００６２】
MP4ファイルが備えるTimed Textをストリーミング伝送により利用するために、RTPパケットは図２に示すデータ構造を有している。図２に示すRTPパケットのデータ構造は、RTPヘッダ８００１とRTPペイロード８００２とから構成される。この実施の形態では、RTPヘッダ８００１とRTPペイロード８００２を含むパケット全体をテキスト伝送用データと呼ぶ。RTPペイロードは、後述するHeader Extension(拡張ヘッダ)８００３と、それぞれ1つのテキストサンプルを含むテキストフレーム#1, #2, #3（８１０１,８１０２,８１０３）を含む。それぞれのテキストフレームの構成をテキストフレーム#1(８１０１)を用いて説明する。テキストフレーム#2、テキストフレーム#3、以降、同一の構成であるので説明を省略する。因みに、この実施の形態では、RTPヘッダ８００１とRTPペイロードのHeader Extension(拡張ヘッダ)とをヘッダ部と呼ぶこととする。
【００６３】
テキストフレーム８１０１の構成は、テキストフレーム長を表すLength ８００４と、サンプルエントリとの関連を表すIndex ８００５と、テキストサンプルを表示する時間を表すDuration ８００６と、テキストサンプルに含まれるテキストの長さを表すTextLength ８００７と、表示するテキスト８００８と、テキストを修飾するための情報Modifier ８００９からなる。この実施の形態では、テキストフレーム長を表すLength ８００４と、サンプルエントリとの関連を表すIndex ８００５と、テキストサンプルを表示する時間を表すDuration ８００６とをまとめてテキストヘッダデータと呼び、テキストサンプルに含まれるテキストの長さを表すTextLength ８００７と、表示するテキスト８００８と、テキストを修飾するための情報Modifier ８００９とからなるText Sampleを分割テキストデータと呼ぶこととする。また、テキスト再生用データとは、図１８について上述したMP4ファイル３０００を意味するものとする。図１８に示したMP4ファイル３０００のヘッダ部３０１０を構成するデータは、図２に示した、テキストヘッダデータ（テキストフレーム長を表すLength ８００４、サンプルエントリとの関連を表すIndex ８００５及びテキストサンプルを表示する時間を表すDuration ８００６）として、対応するテキストサンプル（分割テキストデータ）とともにRTPパケットのテキストフレームに格納される。
【００６４】
次に、次のRTPパケット（SN=2）に含まれるテキストフレームの情報を記述するHeader Extension(拡張ヘッダ)８００３の構成を説明する。Header Extension(拡張ヘッダ)８００３は、次RTPパケットに含まれるテキストフレーム数を表すNo. of Next Samples ８２０１と、次RTPに含まれるテキストフレームの情報を表すNextSampleDuration#1 ８２０２、NextSampleLength#1 ８２０３、NextSampleDuration#2 ８２０４、NextSampleLength#2 ８２０５、…、とから構成される。No. of Next Samples ８００３が３である場合は、次のRTPパケットにはテキストフレームが３つ含まれることを表す。次のRTPパケットに含まれる第１テキストフレームの情報であるNextSampleDuration#1 ８２０２、NextSampleLength#1 ８２０３について説明する。第２テキストフレーム以降については、第１テキストフレームの場合と同様であるので説明を省略する。NextSampleDuration#1 ８２０２は、次のRTPパケットに含まれる第１テキストフレームのテキスト表示時間を示す。NextSampleLength#1 ８２０３は、次のRTPパケットに含まれる第１テキストフレームにテキスト長を示す。すなわち、NextSampleDuration#1 ８２０２は、SN=２のRTPパケットのDuration ８２１２と同一であり、NextSampleLength#1 ８２０３は、SN=２のRTPパケットのTextLength ８２１３と同一である。
【００６５】
この伝送構造を用いた場合の受信端末動作例について説明する。受信端末装置に図３に示すような表示がなされる例を説明する。まず、テキスト長が２２である"Could you help me out?"が６秒表示され、テキスト長が５である"Sure"が３秒表示され、テキスト長が７である"Thanks."が５秒表示される。なお、空白も文字数に含まれる。
【００６６】
この場合のTimedTextのRTPパケットへの格納方法を図２を用いて説明する。なお、この場合、１テキストサンプルを１RTPパケットに格納する場合について説明している。SN=１のRTPパケットには、"Could you help me out?"がTextフィールドに格納され、Durationに６０００、TextLengthに２２が格納される。次のRTPパケット（SN=２）に含まれるテキストフレーム表示時間であるNextSampleDurationと、NextSampleLengthには、それぞれ、３０００、５が格納され、５文字から成る"Sure."が３秒表示されることを示す。以下、同様に、RTPパケットSN２, SN３にテキスト情報が格納される。
【００６７】
次にRTPパケット（SN=２）が損失した場合の、受信端末装置の表示について図４を用いて説明する。受信端末装置は、RTPパケット（SN=１）を受信すると、"Could you help me out?"を指定された時間である６秒間表示する。RTPパケット（SN=２）が損失した場合、６秒後になっても次のテキスト情報が受信されないので、RTPパケット(SN=１)に含まれるHeader Extensionによってテキスト長が５、テキスト表示時間が３秒であることを参照し、テキストが正しく受信できなかったことを表す"*"を５文字分、"*****"と3秒間表示する。
【００６８】
次に、以上のように格納されたRTPパケットを受信した受信端末の動作を図５に示すフロー図を用いて説明する。
【００６９】
受信端末装置は、RTPパケット（SN=ｉ）を受信後、テキストを再生し、SN=ｉに含まれるテキストの再生時刻が終了するまで表示を続ける（ステップＳＴ９００１）。再生時刻が終了すると、次のシーケンス番号SN=ｉ+１のRTPパケットを受信したかどうか判定する（ステップＳＴ９００２）。RTP パケット(SN=ｉ+１)を受信している場合はステップＳＴ９００３に、受信していない場合はステップＳＴ９００５に進む。ステップＳＴ９００３では、受信したSN=ｉ+１のRTPパケットからDuration、Textを読み込み（ステップＳＴ９００３）、TextをDurationで指定された時間受信端末に表示する（ステップＳＴ９００４）。ステップＳＴ９００５では、SN=ｉのRTPパケットからNextSampleDuration、NextSampleLengthを読み込み、表示すべきデータが損失したことを示す"＊"を、TextLength個、NextSampleDuration時間再生する（ステップＳＴ９００６）。ステップＳＴ９００７では、ｉを１増分する。
【００７０】
次に、１RTPパケットに複数のテキストフレームを格納する場合の動作について説明する。１RTPパケットあたり１テキストフレームを格納する場合と異なる部分のみ説明する。
【００７１】
図６、図７及び図８はRTPパケットへのテキスト格納例である。""は空のテキスト、すなわち何もテキストを表示しないことを表す。
【００７２】
RTPパケット(SN=1)には「Tom, this is Kay Adams.」８５０１、「""」８５０３、「Kay, this is my brother, Tom Hagen.」８５０２というテキストが格納される。拡張ヘッダにはRTPパケット（SN=２）に含まれるテキスト情報も格納される。RTPパケット(SN=２)には「How do you do.」８５０４、「""」８５０５、「How do you do.」８５０６というテキストが格納される。拡張ヘッダにはRTPパケット（SN=３）に含まれるテキスト情報も格納される。RTPパケット(SN=３)には「Nice to meet you.」８５０７、「""」８５０８が格納され、拡張ヘッダにはRTPパケット（SN=４）に含まれるテキスト情報も格納される。
【００７３】
図９を用いて伝送誤りがない場合の表示例を説明する。最初の0.5秒間 「Tom, this is Kay Adams.」、次の0.5秒間「Kay, this is my brother, Tom Hagen.」が表示され、次の0.4秒間は何も表示されない。その後は、0.5秒間「How do you do.」、0.2秒間空のテキスト、0.5秒間「How do you do.」、0.6秒間「Nice to meet you.」、６秒間空のテキストを表示する。
【００７４】
次に伝送誤りがあり、RTPパケット（SN=２）が損失した場合の表示方法について図１０を用いて説明する。
【００７５】
SN=１のRTPパケットは正しく受信されているので、最初の0.5秒間 「Tom, this is Kay Adams.」、次の0.5秒間「Kay, this is my brother, Tom Hagen.」が表示され、次の0.4秒間は何も表示されない。次のRTPパケットは損失しているため、次のテキストは正しく表示することができないが、0.5秒間１４文字、0.2秒間空テキスト、0.5秒間１４文字であることが、SN=１のRTPパケットに含まれる拡張ヘッダに格納されているため、0.5秒間「＊」を１４文字並べたものを表示し、次に0.2秒間テキストを非表示にし、次の0.5秒間「＊」を１４文字並べたものを表示する。
【００７６】
なお、完全に損失した場合について説明したが、SN=２のRTPパケットが遅延した場合に、本方法を用いて表示を行ってもよい。その場合、本表示方法を用いて表示している間に遅延RTPパケットが到着次第、エラーがない場合の表示方法に切り替えてもよい。
【００７７】
図１１は本発明の実施の形態１に係るデータ送信装置の構成を示すブロック図である。
【００７８】
このデータ送信装置は、送信先に送信するテキスト情報と修飾情報を記憶するテキスト情報記憶部２００１と、現在生成中の送信データの次の送信データとして送信するテキストに含まれるテキスト長や再生時間等の情報を生成する次期テキストデータ情報生成部２００３と、テキストデータ伝送のための制御情報等と前記次期テキストデータ情報生成情報からヘッダを生成するヘッダ生成部２００２と、伝送するテキストデータおよび修飾情報から伝送データのペイロードを生成するペイロード生成部２００４と、前記ヘッダと前記ペイロードから送信データを合成する送信データ合成部２００５と、前記送信データを送信先に送信するデータ送信部２００６、とを有する。
【００７９】
かかる構成の送信装置において、次期テキストデータ情報生成部２００３は、テキスト情報記憶部２００１から次の送信データとして送信するテキストの情報を読み出すことにより、現在送信中の送信データに、次の送信データのテキストに含まれる情報（テキスト調、再生時間等）を含めることができる。
【００８０】
このように、本実施の形態のデータ構造、データ受信端末装置及びデータ送信端末装置によれば、拡張ヘッダによって次のRTPパケットとして送信されるテキストデータの表示時間（Next Sample Duration）及びテキストデータの有無（Next Sample Length）を予め送信しておくことにより、データ受信端末装置では、データ損失があった場合に、元々テキストデータがなかったものであるか否かを判断することができ、元々テキストデータがなかった場合には、テキスト表示部１０１０において代替テキストを表示させず、これに対して元々テキストデータが有った場合には、テキスト表示部１０１０において代替テキストを表示させるようにすることができる。
【００８１】
これにより、テキスト表示部１０１０において＊印のような代替テキストが表示されるか否かによって、元々何らかのテキストデータが有ったにも関わらずデータ損失が有った場合と、元々テキストデータがない場合の識別が可能となる。
【００８２】
なお、本発明の拡張ヘッダはデータ送信前にあらかじめクライアントに送信されるSDPのパラメータによって、拡張ヘッダ使用の有無を通知してもよい。例えば、サーバーが次期伝送データ情報を拡張ヘッダを用いて送信する場合には、SDPに「next-packet-info: 1」と記述し、拡張ヘッダを含まないときはSDPに「next-packet-info: 0」と記述することができる。
【００８３】
また、上述の実施の形態１においては、静的メディアデータとしてテキストデータを伝送する場合について述べたが、本発明はこれに限らず、静止画データやＣＧ等の静的メディアデータ、若しくはＪＡＶＡ（Ｒ）言語等によるプログラムデータ等のデータを伝送する場合において広く適用することができる。この場合、テキストデータに代えて静止画データ、静的メディアデータ又はプログラムデータを用いるようにすればよく、代替テキスト記憶部１００７には代替静止画データ、代替静的メディアデータ又は代替プログラムデータが記憶されていることとなる。この代替静止画データ、代替静的メディアデータ又は代替プログラムデータは、表示テキスト決定部１００９（静止画を受信する場合には静止画を決定する機能となり、静的メディアを受信する場合は静的メディアを決定する機能となり、プログラムデータを受信する場合はプログラムを決定する機能となる）は、受信された静止画データ、静的メディアデータ又はプログラムデータのサイズに合わせたサイズの代替静止画、代替静的メディア又は代替プログラムを代替テキスト記憶部１００７に要求し、代替テキスト記憶部１００７は、要求されたサイズの代替静止画、代替静的メディア又は代替プログラムを表示テキスト決定部１００９に供給するものとする。
【００８４】
（実施の形態２）
実施の形態２では、MPEG-2 TSを用いたテキストトラックのストリーミング伝送について説明する。テキストトラックは、3GPPで規定されるTimed Textと同様な表現でテキスト再生を行うための情報を備えるデータである。
【００８５】
MPEG-2 TSを用いテキストトラックをストリーミング伝送するためのPESパケット1のデータ構造を図１２に示す。
【００８６】
MPEG-2システムでは、ビデオ、オーディオ、あるいはテキストといったトラックを構成する要素となる信号をES(Elementary Stream)と呼んでいる。さらに、ESを可変長のブロックに区切り、ヘッダ情報を付加したものをPES(Packetized Elementary Stream)と呼んでいる。MPEG-2システムでは、複数のPESを多重伝送する信号として、TS(Transport Stream)を規定している。
【００８７】
図１２に示すPESパケットのデータ構造は、MPEG-2システムで規定されるPESヘッダ部３１０と、ペイロード部３１１とから構成される。PESヘッダ部３１０は、ビデオ、オーディオ、あるいはテキストといったトラック間の同期再生のための時刻情報であるPTS(Presentation Time Stamp)を有している。ペイロード部３１１は、トラックヘッダ３１１１と、サンプルディスクリプション３１１２と、コンフィグインフォメーション３１１３と、拡張ヘッダ３１１４と、テキストフレーム３１１５、３１１５′、…と、それぞれの情報を識別する識別子（トラックヘッダ識別子３１１１ａ、サンプルディスクリプション識別子３１１２ａ、コンフィグインフォメーション識別子３１１３ａ、拡張ヘッダ識別子３１１４ａ、テキストフレーム識別子３１１５ａ）とを含んでいる。トラックヘッダ３１１１と、サンプルディスクリプション３１１２と、コンフィグインフォメーション３１１３と、テキストフレーム３１１５、３１１５′については実施の形態１と同じであるため説明を省略する。ペイロードに含まれる各情報の識別子の直前にはスタートコード(SCP)３１１０として "000001"が挿入される。
【００８８】
拡張ヘッダ３１１４は、実施の形態１と同様に、PESパケットに含まれるテキストフレームの情報を記述するHeader Extension(拡張ヘッダ)８００３の構成を説明する。Header Extension(拡張ヘッダ)８００３は、次PESパケットに含まれるテキストフレーム数を表すNo. of Next Samples ８２０１と、次RTPに含まれるテキストフレームの情報を表すNextSampleDuration#1 ８２０２、NextSampleLength#1 ８２０３、NextSampleDuration#2 ８２０４、NextSampleLength#2 ８２０５ 、…、とから構成される。No. of Next Samples ８００３が３である場合は、次のPESパケットにはテキストフレームが３つ含まれることを表す。次のPESパケットに含まれる第１テキストフレームの情報であるNextSampleDuration#1 ８２０２、NextSampleLength#1 ８２０３について説明する。第２テキストフレーム以降については、第１テキストフレームの場合と同様であるので説明を省略する。NextSampleDuration#1 ８２０２は、次のPESパケットに含まれる第１テキストフレームのテキスト表示時間を示す。NextSampleLength#1 ８２０３は、次のRTPパケットに含まれる第１テキストフレームにテキスト長を示す。すなわち、NextSampleDuration#1 ８２０２は、次のPESパケットのDuration ８２１２と同一であり、NextSampleLength#1 ８２０３は、次のPESパケットのTextLength ８２１３と同一である。
【００８９】
このように、本実施の形態のデータ構造によれば、MPEG-2 TSを用いたテキストトラックのストリーミング伝送においても、テキストデータ損失時に元々テキストデータが有ったものであるか否かの判断が容易になる。
【００９０】
（実施の形態３）
実施の形態３では、実施の形態１の場合と同様にして、ＲＴＰ（Real Time Transport Protocol）、ＲＴＳＰ（Real Time Streaming Protocol）およびＳＤＰ（Session Description Protocol）を用いたテキストトラックのストリーミング伝送について説明する。ＲＴＰはＩＥＴＦ（Internet Engineering Task Force）が勧告するＲＦＣ１８８９において規定されている、マルチメディアストリームのパケットフォーマットである。ＲＴＳＰ，ＳＤＰは、それぞれ、ＲＦＣ２３２６、ＲＦＣ２３２７で規定される、マルチメディアストリーミングの制御プロトコルである。なお、この実施の形態においては、静的メディアデータとしてテキストデータを用いる場合について説明する。
【００９１】
図１３は本発明の実施の形態３に係るデータ受信装置の構成を示すブロック図である。このデータ受信装置は、テキストデータを含むRTPパケットを受信するデータ受信部１００１と、RTPパケットに含まれるテキストを表示する時間を抽出するテキスト表示時間抽出部１００２と、RTPパケットの拡張ヘッダ部に含まれる次期テキスト文字数、次期テキスト表示時間を抽出し記憶する拡張ヘッダ記憶部１００３と、時間情報を生成するタイマー１０１７と、このタイマー１０１７を用い、RTPパケットが受信されるべき時刻になっても受信されない場合に、RTPパケットの損失があると判定するデータ損失判定部１００４と、RTPパケットに含まれるテキストデータを抽出し、記憶するテキスト抽出・記憶部１００５と、フォント、色等、テキストデータを修飾するための修飾情報を受信データから判定するテキスト修飾判定部１００６と、テキスト抽出・記憶部１００５から出力されるテキストデータをテキスト修飾判定部１００６から出力される修飾情報によって修飾したデータを、テキスト表示時間抽出部１００２から供給される表示時間だけ液晶表示部等の所定の表示手段に表示させるテキスト表示部１０１０と、データ損失判定部１００４においてデータ損失と判定された場合に、再送要求の送信開始時刻と送信終了時刻をタイマー１０１７を用いて算出し、再送要求を行うか否かを判定する再送要求判定部１０１８と、再送要求判定部１０１８において再送要求を行うと判定された場合に再送要求パケットを生成する再送要求パケット生成部１０１９と、再送要求パケット生成部１０１９において生成された再送要求パケットを送信側に送信するデータ送信部１０１１とを有する。
【００９２】
このデータ受信装置において、データ損失判定部１００４がデータの損失がないものと判定すると、テキスト表示時間抽出部１００２においてRTPパケットに含まれるテキストを表示する時間（図２において上述したDuration８００６）を抽出し、テキスト表示部１０１０はそれに従いテキストを表示する。
【００９３】
ここで、本発明の実施の形態３に係るサーバが備えるMP4ファイル形式のメディアデータは、ＲＴＰパケットとして伝送される。
【００９４】
MP4ファイルが備えるTimed Textをストリーミング伝送により利用するために、RTPパケットは、実施の形態１において図２に示したデータ構造と同様のデータ構造を有している。図２に示したように、RTPパケットのデータ構造は、RTPヘッダ８００１とRTPペイロード８００２とから構成される。この実施の形態では、RTPヘッダ８００１とRTPペイロード８００２を含むパケット全体をテキスト伝送用データと呼ぶ。RTPペイロードは、後述するHeader Extension(拡張ヘッダ)８００３と、それぞれ1つのテキストサンプルを含むテキストフレーム#1, #2, #3（８１０１,８１０２,８１０３）を含む。それぞれのテキストフレームの構成をテキストフレーム#1(８１０１)を用いて説明する。テキストフレーム#2、テキストフレーム#3、以降、同一の構成であるので説明を省略する。因みに、この実施の形態では、RTPヘッダ８００１とRTPペイロードのHeader Extension(拡張ヘッダ)とをヘッダ部と呼ぶこととする。
【００９５】
テキストフレーム８１０１の構成は、テキストフレーム長を表すLength ８００４と、サンプルエントリとの関連を表すIndex ８００５と、テキストサンプルを表示する時間を表すDuration ８００６と、テキストサンプルに含まれるテキストの長さを表すTextLength ８００７と、表示するテキスト８００８と、テキストを修飾するための情報Modifier ８００９からなる。この実施の形態では、テキストフレーム長を表すLength ８００４と、サンプルエントリとの関連を表すIndex ８００５と、テキストサンプルを表示する時間を表すDuration ８００６とをまとめてテキストヘッダデータと呼び、テキストサンプルに含まれるテキストの長さを表すTextLength ８００７と、表示するテキスト８００８と、テキストを修飾するための情報Modifier ８００９とからなるText Sampleを分割テキストデータと呼ぶこととする。また、テキスト再生用データとは、図１８について上述したMP4ファイル３０００を意味するものとする。図１８に示したMP4ファイル３０００のヘッダ部３０１０を構成するデータは、図２に示した、テキストヘッダデータ（テキストフレーム長を表すLength ８００４、サンプルエントリとの関連を表すIndex ８００５及びテキストサンプルを表示する時間を表すDuration ８００６）として、対応するテキストサンプル（分割テキストデータ）とともにRTPパケットのテキストフレームに格納される。
【００９６】
次に、次のRTPパケット（SN=2）に含まれるテキストフレームの情報を記述するHeader Extension(拡張ヘッダ)８００３の構成を説明する。Header Extension(拡張ヘッダ)８００３は、次RTPパケットに含まれるテキストフレーム数を表すNo. of Next Samples ８２０１と、次RTPに含まれるテキストフレームの情報を表すNextSampleDuration#1 ８２０２、NextSampleLength#1 ８２０３、NextSampleDuration#2 ８２０４、NextSampleLength#2 ８２０５、…、とから構成される。No. of Next Samples ８２０１が３である場合は、次のRTPパケットにはテキストフレームが３つ含まれることを表す。次のRTPパケットに含まれる第1テキストフレームの情報であるNextSampleDuration#1 ８２０２、NextSampleLength#1 ８２０３について説明する。第２テキストフレーム以降については、第１テキストフレームの場合と同様であるので説明を省略する。NextSampleDuration#1 ８２０２は、次のRTPパケットに含まれる第１テキストフレームのテキスト表示時間を示す。NextSampleLength#1 ８２０３は、次のRTPパケットに含まれる第１テキストフレームのテキスト長を示す。すなわち、NextSampleDuration#1 ８２０２は、SN=２のRTPパケットのDuration ８２１２と同一であり、NextSampleLength#1 ８２０３は、SN=２のRTPパケットのTextLength ８２１３と同一である。
【００９７】
この伝送構造を用いた場合の受信端末動作例について説明する。受信端末装置に図３に示したような表示がなされる例を説明する。まず、テキスト長が２２である"Could you help me out?"が６秒表示され、テキスト長が５である"Sure"が３秒表示され、テキスト長が７である"Thanks."が５秒表示される。なお、空白も文字数に含まれる。
【００９８】
この場合のTimedTextのRTPパケットへの格納方法を図１４を用いて説明する。なお、この場合、１テキストサンプルを１RTPパケットに格納する場合について説明している。SN=１のRTPパケットには、"Could you help me out?"がTextフィールドに格納され、Durationに６０００、TextLengthに２２が格納される。次のRTPパケット（SN=２）に含まれるテキストフレーム表示時間であるNextSampleDurationと、NextTextLengthには、それぞれ、３０００、５が格納され、５文字から成る"Sure."が３秒表示されることを示す。以下、同様に、RTPパケットSN２, SN３にテキスト情報が格納される。
【００９９】
次に、RTPパケットが損失した場合の、データ受信装置の表示動作について、図１５を用いて説明する。
【０１００】
まず、パケットが損失した場合の、データ受信装置の動作を説明する。図１５（ａ）において、横軸は時間を表し、時刻t1、t2、t3、t4は、それぞれ、RTPパケット（SN=1、SN=2、SN=3、SN=4）に含まれるテキストを再生する時刻である。プレバッファリング時間が０である場合は、時刻t1、t2、t3、t4はRTPパケット（SN=1、SN=2、SN=3、SN=4）を受信する時刻に等しくなる。プレバッファリング時間がptime（秒）である場合は、RTPパケット（SN=1、SN=2、SN=3、SN=4）を受信する時刻は、t1＋ptime、t2＋ptime、t3＋ptime、t4＋ptimeとなる。ここでは、プレバッファリング時間を０として説明する。
【０１０１】
また、図１５（ａ）に示すように、例えば、SN=1のRTPパケットに含まれる表示時間DUR（Duration）の秒換算値は５秒であり、次の表示時間DUR（すなわちNDUR（Next Duration））の秒換算値は６秒であるとする。つまり、SN=1のRTPパケットに含まれるテキストを表示する時間は５秒であり、次のSN=2のRTPパケットに含まれるテキストを表示する時間は６秒であり、それはSN=2のRTPパケットのDURの秒換算値に等しい。また、SN=2以降のRTPパケットについても同様である。
【０１０２】
そして、本実施の形態では、そのRTPパケット（例えばSN=1のRTPパケット）に含まれるそのRTPパケットの再生時間（Duration）に基づいて、次のRTPパケット（例えばSN=2）の再生開示時間を判断することができ、また、図１６について後述するように、そのRTPパケット（例えばSN=1のRTPパケット）に含まれる、次のRTPパケット（SN=2）の再生時間（NextSampleDuration）に基づいて、当該次のRTPパケット（例えばSN=2）に続くさらに次のRTPパケット（例えばSN=3）の再生開示時間を判断することができることに着目し、この再生時間に基づいて再送要求を行うか否かを判断することを特徴としている。
【０１０３】
次に、SN=2のRTPパケットが損失した場合の動作を図１５（ｂ）を用いて説明する。本実施の形態では、SN=3のRTPパケットを受信する前に、SN=1のDUR値を用いてSN=2のRTPパケットのパケットロスを検出するようにしている点を特徴としている。
【０１０４】
SN=1のRTPパケットの再生時間が５秒であることは、SN=1に含まれる再生時間情報DUR（Duration）が５秒であることから算出できる。従って、SN=2のRTPパケットを再生開始する時刻t2は、SN=1の再生開始時刻t1にその再生時間DURの５秒を加えた値となる。そして、時刻t1に姿勢を開始したSN=1のRTPパケットのテキスト再生終了時刻t2においてSN=2のRTPパケットが受信されない場合は、SN=2のRTPパケットがロスしたものと判定し、再送要求パケットを送信する。
【０１０５】
次に、連続する２つのRTPパケットがロスした場合の動作を図１６を用いて説明する。図１６（ａ）は、SN=2及びSN=3のRTPパケットがロスした場合を示している。この場合、図１５に示した場合と同様にして、時刻t1で再生を開始したSN=1のRTPパケットのテキスト再生終了時刻t2でSN=2のRTPパケットが受信されない場合は、SN=2のRTPパケットがロスしたものと判定し、再送要求パケットを送信する。そしてさらに、SN=2のRTPパケットに含まれるテキストの表示時間（再生時間）は、時刻t3で終了するため、本実施の形態では、SN=2のRTPパケットの再送要求は時刻t3以降送信しない。すなわち、SN=2のRTPパケットに対する再送要求は、時刻t2に開始され、SN=2のRTPパケットを受信するまで定期的に再送要求が行われ、時刻t3になってもSN=2のRTPパケットが受信されない場合は、再送要求の送信を停止する。これにより、時刻t3以降は、SN=3のRTPパケットに対する再送要求を開始することができる。因みに、SN=3のRTPパケットの再生開始時刻t3は、その前に受信済みであるSN=1のRTPパケットに記述されているSN=2の再生時間（NextSampleDuration）とSN=1の再生開始時刻t1に基づいて判断することが可能である。なお、以後の説明では、次のRTPパケットの再生時間（NextSampleDuration）は、NDUR（Next Duration）と表記することがある。
【０１０６】
ここで、図１６（ｂ）は、図１６（ａ）に示した再送要求処理の他の実施の形態を示す略線図である。この図１６（ｂ）に示す再送要求処理では、図１６（ａ）に示した場合と比べて、再送要求の送信開始のタイミング及び送信終了のタイミングをRTPパケットの再生開始時刻t1、t2、t3、…とは異なるタイミングとしている点が相違する。
【０１０７】
すなわち、例えば、SN=2のRTPパケットの再送要求を開始する時刻t2’は、本来、SN=2のRTPパケットを再生開始する時刻t2の時刻に対して、ある一定時間（const）を加えた時刻t2’（=t2＋const）としている。これにより、RTPパケットの受信タイミングの誤差を吸収することができ、実際に送信側から送信されたSN=2のRTPパケットが時刻t2を過ぎて受信されたとしても、その遅れがconst以内であれば、これを受信及び再生することができ、無用な再送要求の送信を回避することができる。
【０１０８】
また、例えば、SN=2のRTPパケットの再送要求の終了タイミングは、SN=3のRTPパケットの再生開始時刻t3よりも、送信側との間の往復通信時間（Round Trip Time：RTT）だけ早い時刻t3’（=t3−RTT）となっている。これにより、データ受信装置から送信側に対して再送要求を送信し、送信側がその再送要求に応じてRTPパケットを再送する場合に、時刻t3’までにデータ受信装置から再送要求を送信すれば、SN=2のRTPパケットの再生終了タイミング（SN=3のRTPパケットの再生開示時刻）までに再送されたSN=2のRTPパケットをデータ受信装置において受信することができる。
【０１０９】
このように図１６（ｂ）の再送要求処理によれば、一段と円滑な再送要求及びこれに応じて再送されたRTPパケットの再生処理を行うことが可能となる。
【０１１０】
以上説明したRTPパケットを受信する際のデータ受信装置の受信動作を、図１７に示すフローチャートを用いて説明する。
【０１１１】
図１７に示すように、データ受信装置のデータ損失判定部１００４は、ステップＳＴ９０１１において、SN=iのRTPパケットを受信したか否かを判断する。ここで否定結果が得られると、このことは、未だSN=iのRTPパケットを受信していないことを意味しており、このときデータ損失判定部１００４は、当該ステップＳＴ９０１１の判断処理を繰り返す。
【０１１２】
これに対して、ステップＳＴ９０１１において肯定結果が得られると、このことは、SN=iのRTPパケットを受信したことを意味しており、このときデータ損失判定部１００４は、続くステップＳＴ９０１２に移って、現在時刻tと、SN=iのRTPパケットの再生開始時刻tiにその再生時間DUR（i）を加算した時刻を比較し、現在時刻tの方が大きいか又は等しい場合は、SN=i＋1のRTPパケットに含まれるテキストの再生開示時刻が経過したものと判断し、ステップＳＴ９０１３に移る。
【０１１３】
因みに、ステップＳＴ９０１２において否定結果が得られると、このことは、SN=i＋1のRTPパケットに含まれるテキストの再生開始時刻が未だ経過していないことを意味しており、このときデータ損失判定部１００４は、このステップＳＴ９０１２の判断処理を繰り返す。
【０１１４】
かくして、SN=i＋1のRTPパケットに含まれるテキストの再生開始時刻が経過した際に、データ損失判定部１００４は、ステップＳＴ９０１３に移り、SN=i＋1のRTPパケットが受信されたか否かを判断する。このステップＳＴ９０１３において肯定結果が得られると、このことは、SN=iのRTPパケットの再生時間が経過した後、このRTPパケットに続くSN=i＋1のRTPパケットが受信されたこと、すなわち、SN=iのRTPパケットの表示時間が経過した際に、次に表示すべきデータを受信したことを意味している。従って、このときデータ損失判定部１００４は、ステップＳＴ９０１７に移って、ｉを１増分した後、上述のステップＳＴ９０１２に戻り、ステップＳＴ９０１３において受信が確認されたRTPパケットの表示時間の経過を待つ。
【０１１５】
これに対して、ステップＳＴ９０１３において否定結果が得られると、このことは、SN=iのRTPパケットの再生時間が経過した後、このRTPパケットに続くSN=i＋1のRTPパケットが受信されていないこと、すなわち、SN=iのRTPパケットの表示時間が経過した際に、次に表示すべきデータが受信されていないことを意味しており、このとき、データ損失判定部１００４は、再送要求判定部１０１８に対して、受信されているべきRTPパケットが受信されていない旨を報告する。
【０１１６】
かくして、この報告を受けた再送要求判定部１０１８は、ステップＳＴ９０１４において、このとき受信されていなければならないにも関わらず未だ受信されていないSN=i＋1のRTPパケットについての再送要求を送信する。
【０１１７】
一方、データ損失判定部１００４は、ステップＳＴ９０１３においてSN=i＋1が受信されていない結果を得、これを再送要求判定部１０１８に報告した後、ステップＳＴ９０１５に移って、このとき再送要求判定部１０１８によって再送要求が行われたSN=i＋1のRTPパケットに続く、SN=i＋2のRTPパケットが受信されたか否か、または、現在時刻tと、SN=iのRTPパケットの再生開始時刻tiにその再生時間DUR（i）及びSN=i＋1の再生時間NDUR（i）を加算した時刻とを比較し、現在時刻tの方が大きいか否かを判断する。
【０１１８】
ここで、否定結果が得られると、このことは、SN=i＋2のRTPパケットを受信すべき時刻に達していないことを意味しており、このとき、データ損失判定部１００４は、上述のステップＳＴ９０１３に戻って、ステップＳＴ９０１３〜ステップＳＴ９０１５の処理を繰り返す。これにより、SN=i＋2のRTPパケットが受信されるべき時刻になるまでの間は、そのRTPパケットの前に受信されるべきSN=i＋1のRTPパケットについて、受信されたか否かの判断、及び受信されていない場合のそのRTPパケットの再送要求を繰り返す。
【０１１９】
これに対して、ステップＳＴ９０１５において肯定結果が得られると、このことは、SN=i＋2のRTPパケットを受信すべき時刻に達したか、又は実際にそのRTPパケットを受信したことを意味しており、このときデータ損失判定部１００４は、ステップＳＴ９０１６に移って、iを１増分した後、ステップＳＴ９０１７に移って、さらにiを１増分する。
【０１２０】
このように、ステップＳＴ９０１５において肯定結果が得られると、データ損失判定部１００４は、ステップＳＴ９０１６及びステップＳＴ９０１７においてiの増分処理を行うことにより、iは合計２増分された後、上述のステップＳＴ９０１１の処理に戻り、以下、上述した場合と同様の処理を繰り返す。
【０１２１】
かくして、図１７に示した受信処理手順によれば、再送要求を行う際に、RTPパケットの受信を待つことなく、RTPパケットの再生時間を基に再送要求するか否かを判定することにより、再送要求を送信するまでの時間を短縮することができる。また、連続して２つのRTPパケットがロスした場合であっても、最近に受信したRTPパケットに含まれる次期再生時間（NDUR）を用いて、適切に再送要求を行うことができる。
【０１２２】
このように本実施の形態のデータ受信装置によれば、RTPパケットの受信を待つことなく、RTPパケットの再生時間に基づいて再送要求を行うか否かを判断することにより、パケットロスの検出に要する時間を短縮することができる。
【０１２３】
なお、上述の実施の形態においては、静的メディアデータとしてテキストデータを伝送する場合について述べたが、本発明ではこれに限られるものではなく、静止画データやＣＧ等の静的メディアデータ、若しくはＪＡＶＡ（Ｒ）言語又はＸＭＬ言語等によるプログラムデータ等のデータを伝送する場合において広く適用することができる。この場合、テキストデータに代えて静止画データ、静的メディアデータ又はプログラムデータを用いるようにすればよい。
【０１２４】
【発明の効果】
以上説明したように、本発明によれば、静的メディア伝送データが伝送エラー等の理由により損失した場合であっても、代替静的メディアを正確な再生時間で表示することができる。また、本発明によれば、パケットロスの検出に要する時間を短縮することが可能となる。
【図面の簡単な説明】
【図１】本発明のデータ受信装置の構成を示すブロック図
【図２】本発明のＲＴＰパケットのデータ構造を示す略線図
【図３】本発明のデータ表示方法のテキスト表示例を示す略線図
【図４】本発明のデータ表示方法の伝送誤りが発生した場合のテキスト表示例を示す略線図
【図５】本発明のデータ表示方法の動作を説明するためのフローチャート
【図６】本発明のデータ送信方法のテキストデータ格納例を示す略線図
【図７】本発明のデータ送信方法のテキストデータ格納例を示す略線図
【図８】本発明のデータ送信方法のテキストデータ格納例を示す略線図
【図９】本発明のデータ表示方法の複数テキストを格納する場合のテキスト表示例を示す略線図
【図１０】本発明のデータ表示方法の伝送誤りが発生した場合のテキスト表示例を示す略線図
【図１１】本発明のデータ送信装置の構成を示すブロック図
【図１２】本発明の実施の形態２に係るＰＥＳパケットのデータ構造を示す略線図
【図１３】本発明の実施の形態３に係るデータ受信装置の構成を示すブロック図
【図１４】本発明のデータ構造を示す略線図
【図１５】データ受信装置の表示動作を示す略線図
【図１６】データ受信装置の表示動作を示す略線図
【図１７】データ受信装置の受信処理手順を示すフローチャート
【図１８】  3GPPで規定されるTimed Text のデータ構造を示す略線図
【図１９】  Timed Textのデータ構造の略線図
【符号の説明】
１００１  データ受信部
１００２  テキスト表示時間抽出部
１００３  拡張ヘッダ記憶部
１００４  データ損失判定部
１００５  テキスト抽出・記憶部
１００６  テキスト修飾判定部
１００７  代替テキスト記憶部
１００８  テキスト表示時間決定部
１００９  表示テキスト決定部
１０１０  テキスト表示部
１０１７  タイマー
１０１８  再送要求判定部
１０１９  再送要求パケット生成部
２００１  テキスト情報記憶部
２００２  ヘッダ生成部
２００３  次期テキストデータ情報生成部
２００４  ペイロード生成部
２００５  送信データ合成部
２００６  データ送信部
８００１  ＲＴＰヘッダ
８００２  ＲＴＰペイロード
８００３  拡張ヘッダ
８００４  テキストフレーム長
８００５  インデックス
８００６  再生時間（デュレーション）
８００７  テキスト長
８００８  テキスト
８００９  修飾子
８１０１、８１０２、８１０３  テキストフレーム
８２０１  次期テキストフレームサンプル数
８２０２、８２０４、８２０６  次期テキストフレーム再生時間
８２０３、８２０５、８２０７  次期テキストフレームテキスト長
８２１２  再生時間（デュレーション）
８２１３  テキスト長
【図１】
0003836077.tif 000002
【図２】
0003836077.tif 000003
【図３】
0003836077.tif 000004
【図４】
0003836077.tif 000005
【図５】
0003836077.tif 000006
【図６】
0003836077.tif 000007
【図７】
0003836077.tif 000008
【図８】
0003836077.tif 000009
【図９】
0003836077.tif 000010
【図１０】
0003836077.tif 000011
【図１１】
0003836077.tif 000012
【図１２】
0003836077.tif 000013
【図１３】
0003836077.tif 000014
【図１４】
0003836077.tif 000015
【図１５】
0003836077.tif 000016
【図１６】
0003836077.tif 000017
【図１７】
0003836077.tif 000018
【図１８】
0003836077.tif 000019
【図１９】
0003836077.tif 000020