図面 (/)

技術 伝送データ構造及びそれを伝送するための方法並びに装置

出願人 パナソニック株式会社
発明者 井戸大治松井義徳杉浦雅貴
出願日 2003年1月24日 (17年11ヶ月経過) 出願番号 2003-016364
公開日 2004年7月29日 (16年4ヶ月経過) 公開番号 2004-215203
状態 特許登録済
技術分野 CATV、双方向TV等 双方向TV,動画像配信等 広域データ交換 通信制御
主要キーワード 増分処理 伝送データ構造 代替プログラム 表示静止画 テキストサンプル 複数テキスト テキスト文字数 往復通信
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2004年7月29日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

Timed Textなど静的メディアストリーミング型の配信で使用する場合に、データ受信装置が静的メディアデータを受信しない場合、次に表示すべきメディアデータがないのか、伝送途中にメディアデータが損失したため表示できないのかを判定し、ユーザーにメディアデータの損失を正しく通知する。また、プレバッファリングを増加させることなく、パケットロス検出に要する時間を短くして再送要求を行うことを目的とする。

解決手段

静的メディア伝送用データに含まれる分割静的メディアデータの再生に関する情報をその静的メディア伝送用データよりも前の静的メディア伝送用データに格納して伝送することにより、分割静的メディアデータが受信されない場合に、その分割静的メディアデータが元々ないものであるか、または損失したものであるかの判断を可能とする。

概要

背景

第三世代移動通信(W−CDMA)の国際標準規格を策定する団体3GPP(Third Generation Partnership Project) のSA(Service and System Aspect) WG4グループでは、マルチメディア配信規格TS26.234を策定している(例えば非特許文献1等参照)。マルチメディア配信規格TS26.234バージョン5.2.0では、ダウンロード型マルチメディア配信に使用可能なMP4(ISO/IEC14496−1:2001)形式ファイル拡張テキストデータのデータ構造を規定している(Timed Text)。これによって、MP4ファイルをダウンロードしながら再生するサービスにおいて、ビデオオーディオのみならず、テキストも再生することが可能になっている。

概要

Timed Textなど静的メディアストリーミング型の配信で使用する場合に、データ受信装置が静的メディアデータを受信しない場合、次に表示すべきメディアデータがないのか、伝送途中にメディアデータが損失したため表示できないのかを判定し、ユーザーにメディアデータの損失を正しく通知する。また、プレバッファリングを増加させることなく、パケットロス検出に要する時間を短くして再送要求を行うことを目的とする。静的メディア伝送用データに含まれる分割静的メディアデータの再生に関する情報をその静的メディア伝送用データよりも前の静的メディア伝送用データに格納して伝送することにより、分割静的メディアデータが受信されない場合に、その分割静的メディアデータが元々ないものであるか、または損失したものであるかの判断を可能とする。

目的

本発明はかかる点に鑑みてなされたものであり、Timed Text等の静的メディアをストリーミング型の配信で使用する場合に、データ受信端末が静的メディアデータを受信しない場合、次に表示すべきメディアデータがないのか、伝送途中にメディアデータが損失したため表示できないのかを判定し、ユーザにメディアデータの損失を正しく通知するためのデータ構造、データ送信装置、データ受信装置を提供する

効果

実績

技術文献被引用数
5件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

静的メディアデータの再生にかかる静的メディア再生用データを転送し順次再生させるための静的メディア伝送用データ伝送データ構造であって、前記静的メディア再生用データは、前記静的メディアデータを分割した複数の分割静的メディアデータと、前記分割静的メディアデータを再生するための情報を含む静的メディアヘッダデータとを含み、前記静的メディア伝送用データは、前記分割静的メディアデータに付加された分割静的メディアデータ識別子と、前記静的メディアヘッダデータに付加された静的メディアヘッダデータ識別子と、次期静的メディア伝送用データに含まれる分割静的メディアデータに関わる静的メディア情報と、を含むことを特徴とする静的メディア伝送用データの伝送データ構造。

請求項2

プログラムデータの再生にかかるプログラム再生用データを転送し順次再生させるためのプログラム伝送用データの伝送データ構造であって、前記プログラム再生用データは、前記プログラムデータを分割した複数の分割プログラムデータと、前記分割プログラムデータを再生するための情報を含むプログラムヘッダデータとを含み、前記プログラム伝送用データは、前記分割プログラムデータに付加された分割プログラムデータ識別子と、前記プログラムヘッダデータに付加されたプログラムヘッダデータ識別子と、次期プログラム伝送用データに含まれる分割プログラムデータに関わるプログラム情報と、を含むことを特徴とするプログラム伝送用データの伝送データ構造。

請求項3

テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの伝送データ構造であって、前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータを再生するための情報を含むテキストヘッダデータとを含み、前記テキスト伝送用データは、前記分割テキストデータに付加された分割テキストデータ識別子と、前記テキストヘッダデータに付加されたテキストヘッダデータ識別子と、次期テキスト伝送用データに含まれる分割テキストデータに関わるテキスト情報と、を含むことを特徴とするテキスト伝送用データの伝送データ構造。

請求項4

前記次期テキスト伝送用データに含まれる分割テキストデータに関わるテキスト情報は、次期テキスト伝送用データに含まれる分割テキストデータの個数を含む、ことを特徴とする請求項3に記載のテキスト伝送用データの伝送データ構造。

請求項5

前記次期テキスト伝送用データに含まれる分割テキストデータに関わるテキスト情報は、次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報を含む、ことを特徴とする請求項3に記載のテキスト伝送用データの伝送データ構造。

請求項6

前記次期テキスト伝送用データに含まれる分割テキストデータにかかわるテキスト情報は、次期テキスト伝送用データに含まれる分割テキストデータのテキストデータ長情報を含む、ことを特徴とする請求項3に記載のテキスト伝送用データの伝送データ構造。

請求項7

テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの伝送方法であって、前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータの再生を開始する再生開始情報を含むテキストヘッダデータとを含み、前記テキスト再生用データに基づいて、前記テキスト伝送用データのペイロード部を作成するペイロード部作成ステップと、次期パケットに含まれるテキスト情報を付加した前記テキスト伝送用データのヘッダ部を作成するヘッダ部作成ステップと、前記作成された前記各ペイロード部に対して前記ヘッダ部を付加し、パケットとするヘッダ付加ステップとを備え、前記各ペイロード部は、前記テキストヘッダデータの再生開始情報を含むことを特徴とするテキスト伝送用データの伝送方法。

請求項8

テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの伝送方法であって、前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータの再生を開始する再生開始情報を含むテキストヘッダデータとを含み、前記テキスト再生用データに基づいて、前記テキスト伝送用データのペイロード部を作成するペイロード部作成ステップと、次期パケットに含まれる分割テキストデータ数を付加したテキスト伝送用データのヘッダ部を作成するヘッダ部作成ステップと、前記作成された前記各ペイロード部に対して前記ヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、前記各ペイロード部は、前記テキストヘッダデータの前記再生開始情報を含むことを特徴とするテキスト伝送用データの伝送方法。

請求項9

テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの伝送方法であって、前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータの再生を開始する再生開始情報を含むテキストヘッダデータとを含み、前記テキスト再生用データに基づいて、前記テキスト伝送用データのペイロード部を作成するペイロード部作成ステップと、次期パケットに含まれる分割テキストデータの再生時間情報を付加しテキスト伝送用データのヘッダ部を作成するヘッダ部作成ステップと、前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、前記各ペイロード部は、前記テキストヘッダデータの前記再生開始情報を含むことを特徴とするテキスト伝送用データの伝送方法。

請求項10

テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの伝送方法であって、前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータの再生を開始する再生開始情報を含むテキストヘッダデータとを含み、前記テキスト再生用データに基づいて、前記テキスト伝送用データのペイロード部を作成するペイロード部作成ステップと、次期パケットに含まれる分割テキストデータのテキストデータ長を付加しテキスト伝送用データのヘッダ部を作成するヘッダ部作成ステップと、前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、前記各ペイロード部は、前記テキストヘッダデータの前記再生開始情報を含むことを特徴とするテキスト伝送用データの伝送方法。

請求項11

テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの受信方法であって、第1のテキスト伝送用データを受信し、第1のテキストデータの再生時間が経過後、第2のテキスト伝送用データが受信されない場合データ損失があったと判定するデータ損失判定ステップと、データ損失と判定された場合、第1のテキスト伝送用データに含まれる次期テキスト伝送用データに含まれる分割テキストデータにかかわるテキスト情報を第2のテキスト伝送データとする置き換えステップとを備えたことを特徴とするテキスト伝送用データの受信方法。

請求項12

テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データの受信表示方法であって、第1のテキスト伝送用データを受信し、第1のテキストデータの再生時間が経過後、第2のテキスト伝送用データが受信されない場合データ損失があったと判定するデータ損失判定ステップと、データ損失と判定された場合、第1のテキスト伝送用データに含まれる次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報を第2のテキスト伝送データとする置き換えステップと、テキストデータ長が1以上である場合は代替テキストをテキストデータ長表示し、テキストデータ長が0である場合はテキストデータの表示を行わないテキスト表示ステップとを備えたことを特徴とするテキスト伝送用データのデータ表示方法

請求項13

サーバーまたは対局からテキストデータを受信するデータ受信部と、受信データからテキストデータを表示するテキスト表示時間を抽出するテキスト表示時間抽出部と、次期テキストデータのテキストデータ情報が格納されている拡張ヘッダの情報を受信データから抽出して記憶する拡張ヘッダ記憶部と、テキストデータの損失を判定するデータ損失判定部と、受信したデータからテキストデータを抽出し記憶するテキスト抽出・記憶部と、表示すべきテキストデータが受信されなかった場合に表示する代替テキストを記憶する代替テキスト記憶部と、前記データ損失判定部でデータの損失が判定された場合は前記拡張ヘッダ記憶部から入力されるテキスト表示時間をテキストを表示する時間として決定し、データの損失がないと判定された場合は前記テキスト表示時間抽出部から入力されるテキスト表示時間をテキストを表示する時間として決定するテキスト表示時間決定部と、前記データ損失判定部でデータの損失がないと判定された場合は前記テキスト抽出・記憶部に記憶されたテキストを表示することを決定し、前記データ損失判定部でデータの損失があると判定された場合は、前記代替テキスト記憶部に記憶されている代替テキストを表示することを決定する表示テキスト決定部と、前記テキスト表示時間決定部で決定された時間、前記表示テキスト決定部で決定されたテキストを表示するテキスト表示部とを具備することを特徴とするデータ受信装置

請求項14

対局にテキストデータを送信するデータ送信装置であって、対局に送信するテキスト情報を記憶するテキスト情報記憶部と、現在生成中送信データの次の送信データとして送信するテキストに含まれるテキスト長及び/または再生時間を含む情報を生成する次期テキストデータ情報生成部と、テキストデータ伝送のための制御情報等と前記次期テキストデータ情報生成情報からヘッダを生成するヘッダ生成部と、伝送するテキストデータおよびその修飾情報から伝送データのペイロードを生成するペイロード生成部と、前記ヘッダと前記ペイロードから送信データを合成する送信データ合成部と、前記送信データを対局に送信するデータ送信部とを具備することを特徴とするデータ送信装置。

請求項15

静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの伝送データ構造であって、前記静止画再生用データは、前記静止画データを分割した複数の分割静止画データと、前記分割静止画データを再生するための情報を含む静止画ヘッダデータとを含み、前記静止画伝送用データは、前記分割静止画データに付加された分割静止画データ識別子と、前記静止画ヘッダデータに不可された静止画ヘッダデータ識別子と、次期静止画伝送データに含まれる分割静止画データにかかわる静止画情報と、を含むことを特徴とする静止画伝送用データの伝送データ構造。

請求項16

前記次期静止画伝送データに含まれる分割静止画データに関わる静止画情報は、次期静止画伝送データに含まれる分割静止画データの個数を含むことを特徴とする請求項15に記載の静止画伝送用データの伝送データ構造。

請求項17

前記次期静止画伝送データに含まれる分割静止画データに関わる静止画情報は、次期静止画伝送データに含まれる分割静止画データの静止画再生時間情報を含むことを特徴とする請求項15に記載の静止画伝送用データの伝送データ構造。

請求項18

前記次期静止画伝送データに含まれる分割静止画データに関わる静止画情報は、次期静止画伝送データに含まれる分割静止画データの静止画サイズ情報を含むことを特徴とする請求項15に記載の静止画伝送用データの伝送データ構造。

請求項19

静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの伝送方法であって、前記静止画再生用データは、前記静止画データを分割した複数の分割静止画データと、前記分割静止画データの再生を開始する再生開始情報を含む静止画ヘッダデータとを含み、前記静止画再生用データに基づいて、前記静止画伝送用データのペイロード部を作成するペイロード部作成ステップと、次期パケットに含まれる静止画情報付加して前記静止画伝送用データのヘッダ部を作成するヘッダ部作成ステップと、前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、前記各ペイロード部は、前記静止画ヘッダデータの前記再生開始情報を含むことを特徴とする静止画伝送用データの伝送方法。

請求項20

静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの伝送方法であって、前記静止画再生用データは、前記静止画データを分割した複数の分割静止画データと、前記分割静止画データの再生を開始する再生開始情報を含む静止画ヘッダデータとを含み、前記静止画再生用データに基づいて、前記静止画伝送用データのペイロード部を作成するペイロード部作成ステップと、次期パケットに含まれる分割静止画データ数を付加して静止画伝送用データのヘッダ部を作成するヘッダ部作成ステップと、前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、前記各ペイロード部は、前記静止画ヘッダデータの前記再生開始情報を含むことを特徴とする静止画伝送用データの伝送方法。

請求項21

静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの伝送方法であって、前記静止画再生用データは、前記静止画データを分割した複数の分割静止画データと、前記分割静止画データの再生を開始する再生開始情報を含む静止画ヘッダデータとを含み、前記静止画再生用データに基づいて、前記静止画伝送用データのペイロード部を作成するペイロード部作成ステップと、次期パケットに含まれる分割静止画データの再生時間情報を付加して静止画伝送用データのヘッダ部を作成するヘッダ部作成ステップと、前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、前記各ペイロード部は、前記静止画ヘッダデータの前記再生開始情報を含むことを特徴とする静止画伝送用データの伝送方法。

請求項22

静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの伝送方法であって、前記静止画再生用データは、前記静止画データを分割した複数の分割静止画データと、前記分割静止画データの再生を開始する再生開始情報を含む静止画ヘッダデータとを含み、前記静止画再生用データに基づいて、前記静止画伝送用データのペイロード部を作成するペイロード部作成ステップと、次期パケットに含まれる分割静止画データの静止画サイズを付加して静止画伝送用データのヘッダ部を作成するヘッダ部作成ステップと、前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとするヘッダ部付加ステップとを備え、前記各ペイロード部は、前記静止画ヘッダデータの前記再生開始情報を含むことを特徴とする静止画伝送用データの伝送方法。

請求項23

静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの受信方法であって、第1の静止画伝送用データを受信し、第1の静止画データの再生時間が経過後、第2静止画の静止画伝送用データが受信されない場合データ損失があったと判定するデータ損失判定ステップと、データ損失と判定された場合第1の静止画伝送用データに含まれる次期静止画伝送データに含まれる分割静止画データに関わる静止画情報を第2の静止画伝送データとする置き換えステップとを備えたことを特徴とする静止画伝送用データの受信方法。

請求項24

静止画データの再生にかかる静止画再生用データを転送し順次再生させるための静止画伝送用データの受信表示方法であって、第1の静止画伝送用データを受信し、第1の静止画データの再生時間が経過後、第2静止画の静止画伝送用データが受信されない場合データ損失があったと判定するデータ損失判定ステップと、データ損失と判定された場合第1の静止画伝送用データに含まれる次期静止画伝送データに含まれる分割静止画データに関わる静止画情報を第2の静止画伝送データとする置き換えステップと、静止画サイズのサイズに応じて代替静止画を表示する静止画表示ステップとを備えた静止画伝送用データの表示方法

請求項25

サーバーまたは対局から静止画データを受信するデータ受信部と、受信データから静止画データを表示する静止画表示時間を抽出する静止画表示時間抽出部と、次期静止画データの静止画データ情報が格納されている拡張ヘッダの情報を記憶する拡張ヘッダ記憶部と、静止画データの損失を判定するデータ損失判定部と、受信したデータから静止画データを抽出し記憶する静止画抽出・記憶部と、表示すべき静止画データが受信されなかった場合に表示する静止画を記憶する代替静止画記憶部と、前記データ損失判定部でデータの損失があると判定された場合は前記拡張ヘッダ記憶部から入力される静止画表示時間を静止画を表示する時間と決定し、データの損失がないと判定された場合は前記静止画表示時間抽出部から入力される静止画表示時間を静止画を表示する時間と決定する静止画表示時間決定部と、前記データ損失判定部でデータの損失がないと判定された場合は前記静止画抽出・記憶部に記憶された静止画を表示することを決定し、データの損失があると判定された場合は、前記代替静止画記憶部に記憶されている代替静止画を表示することを決定する表示静止画決定部と、前記静止画表示時間決定部で決定された時間、前記表示静止画決定部で決定された静止画を表示する静止画表示部とを具備することを特徴とするデータ受信装置。

請求項26

対局に静止画データを送信するデータ送信装置であって、対局に送信する静止画情報を記憶する静止画情報記憶部と、現在生成中の送信データの次の送信データとして送信する静止画に含まれる静止画サイズや再生時間等の情報を生成する次期静止画データ情報生成部と、静止画データ伝送のための制御情報等と前記次期静止画データ情報生成情報からヘッダを生成するヘッダ生成部と、伝送する静止画データおよびその修飾情報から伝送データのペイロードを生成するペイロード生成部と、前記ヘッダと前記ペイロードから送信データを合成する送信データ合成部と、前記送信データを対局に送信するデータ送信部とを具備することを特徴とするデータ送信装置。

請求項27

静的メディアデータを再生させるために、前記静的メディアデータと前記静的メディアデータの再生時間を表す情報を伝送するデータ伝送方法であって、前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表すデータを前記静的メディアデータとともに伝送するデータ伝送方法。

請求項28

複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間を表す静的メディア伝送用データを受信するデータ受信方法であって、第1の静的メディア伝送用データを受信した後、この第1の静的メディア伝送用データを基に再生される第1の静的メディアデータの再生時間が経過後、第2の静的メディア伝送用データが受信されたか否かを判断する受信結果判断ステップと、前記受信結果判断ステップの判断結果に基づいて、前記第2の静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定ステップと、前記データ損失判定ステップにおいてデータ損失があったものと判定された場合、前記第1の静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始ステップと、を具備するデータ受信方法。

請求項29

複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間及び前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表す静的メディア伝送用データを受信するデータ受信方法であって、第1の静的メディア伝送用データを受信した後、この第1の静的メディア伝送用データを基に再生される第1の静的メディアデータの再生時間が経過後、前記第1の静的メディアデータに続く前記次期静的メディアデータを再生するための第2の静的メディア伝送用データが受信されたか否かを判断する受信結果判断ステップと、前記受信結果判断ステップの判断結果に基づいて、前記第2の静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定ステップと、前記データ損失判定ステップにおいてデータ損失があったものと判定された場合、前記第1の静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始ステップと、前記第1の静的メディア伝送用データに含まれる、前記次期静的メディアデータの再生時間に基づき、この次期静的メディアデータの再生時間の経過に応じて前記第2の静的メディア伝送用データの再送要求の送信を終了する再送要求送信終了ステップと、を具備するデータ受信方法。

請求項30

前記再送要求送信終了ステップでは、前記第2の静的メディア伝送用データの再送要求の送信を終了するタイミングとして、前記次期静的メディアデータの再生時間が終了する時間から、前記静的メディア伝送用データの送信側と受信側間でデータを往復伝送するために要する往復時間だけ遡った時間が設定されることを特徴とする請求項29記載のデータ受信方法。

請求項31

静的メディアデータを再生させるために、前記静的メディアデータと前記静的メディアデータの再生時間を表す情報を伝送するデータ伝送方法であって、前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表すデータと前記次期静的メディアデータに含まれる文字数を表す情報とを前記静的メディアデータとともに伝送するデータ伝送方法。

請求項32

複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間及び前記静的メディアデータの次に再生される次期静的メディアデータの再生時間と前記次期静的メディアデータに含まれる文字数とを表す静的メディア伝送用データを受信するデータ受信方法であって、静的メディア伝送用データを受信した後、この静的メディア伝送用データを基に再生される静的メディアデータの再生時間が経過後、前記静的メディアデータに続く前記次期静的メディアデータを再生するための次期静的メディア伝送用データが受信されたか否かを判断する受信結果判断ステップと、前記受信結果判断ステップの判断結果に基づいて、前記次期静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定ステップと、前記データ損失判定ステップにおいてデータ損失があったものと判定された場合、前記静的メディア伝送用データによって示される、次期静的メディアデータの文字数が0より大きいことを条件に、前記静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始ステップと、を具備するデータ受信方法。

請求項33

複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間を表す静的メディア伝送用データを受信するデータ受信装置であって、第1の静的メディア伝送用データを受信した後、この第1の静的メディア伝送用データを基に再生される第1の静的メディアデータの再生時間が経過後、第2の静的メディア伝送用データが受信されたか否かを判断する受信結果判断手段と、前記受信結果判断手段の判断結果に基づいて、前記第2の静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定手段と、前記データ損失判定手段によってデータ損失があったものと判定された場合、前記第1の静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始手段と、を具備するデータ受信装置。

技術分野

0001

本発明は、例えばテキストデータ等の静的メディアデータを伝送する伝送データ構造及びそれを伝送するための方法及び装置に関する。

0002

第三世代移動通信(W−CDMA)の国際標準規格を策定する団体3GPP(Third Generation Partnership Project) のSA(Service and System Aspect) WG4グループでは、マルチメディア配信規格TS26.234を策定している(例えば非特許文献1等参照)。マルチメディア配信規格TS26.234バージョン5.2.0では、ダウンロード型マルチメディア配信に使用可能なMP4(ISO/IEC14496−1:2001)形式ファイル拡張しテキストデータのデータ構造を規定している(Timed Text)。これによって、MP4ファイルをダウンロードしながら再生するサービスにおいて、ビデオオーディオのみならず、テキストも再生することが可能になっている。

0003

テキストによる情報通知は、伝えたい情報を直接に使用者に伝えることができ、ビデオに比べて、データ量はきわめて少なくて済むため、情報通知手段としては非常に重要である。上述のようなMP4ファイルをダウンロードしながら再生するサービスにおいては、ビデオとテキストとを合成して符号化し伝送するのではなく、テキストを独立したトラックとして伝送するため、テキストがつぶれて読めなくなることが少なくなっており、有効に情報通知を行うことが可能となっている。

0004

さらに、3GPPで規定したTimed Textでは、テキストの一部を修飾したり、移動させたり、あるいは文字列に他のURLへのリンクを貼り付けたりすることが可能である(スタイルハイライトカラオケテキストボックスブリンクスクロールハイパーリンク、他)。これにより、伝えたい情報をさまざまな表現形式で再生することが可能となっている。

0005

ここで、図18を用いて、3GPPで規定したTimed Textのデータ構造について説明する。

0006

MP4ファイル3000は、ヘッダ部3010とデータ部3020とから構成される。ヘッダ部3010は、トラックヘッダ3030と、サンプルディスクリプション3040と、サンプルテーブル3050とを備えている。データ部3020は、テキストサンプル3060、3061、…を備えている。

0007

トラックヘッダ3030は、Timed Textの再生にかかる情報であり、レイアウト(表示領域の大きさ、ビデオとの相対位置)、レイヤ(ビデオ等他のメディアとの階層関係)、Timed Textの再生時間、ファイルの再生日時、後述するTime−to−Sample−Box 3051のタイムスケール等の情報を含んでいる。

0008

サンプルディスクリプション3040は、複数のサンプエントリ3041、3042、…を有している。サンプルエントリ3041,3042、…は、テキストサンプル3060、3061、…のデフォルト書式にかかる情報であり、スクロールの有無と方向、水平・垂直の寄せ位置、背景色フォント名、フォントサイズ等を含んでいる。

0009

サンプルテーブル3050は、Time−to−Sample−Box 3051と、Sample−Size−Box 3052と、Sample−to−Chunk−Box 3053とを有している。Time−to−Sample−Box 3051は、テキストサンプル3060、3061、…のそれぞれの再生時間に関する情報3055、3056、…をテキストサンプル3060、3061、…の配置順に含んでいる。情報3055、3056、…が格納する値のタイムスケールは、トラックヘッダ3030により指定されている。具体的には、トラックヘッダ3030は、タイムスケールとして、1秒間の解像度を格納しており、例えば、トラックヘッダ3030が格納するタイムスケールの値が[1000]の場合、1/1000秒単位の解像度となる。従ってテキストサンプル3060、3061、…それぞれの再生時間を秒換算した値は、情報3055、3056、…をトラックヘッダ3030が格納するタイムスケールの値を除算した値となり、例えば、タイムスケールの値が[1000]の場合、情報3056の示す値[3400]は、テキストサンプル3061を3.4秒間再生することを意味している。以下、タイムスケールの値が[1000]と設定されているとして説明を行う。Sample−Size−Box3052は、テキストサンプル3060、3061、…のそれぞれのデータ長に関する情報3057、3058、…をテキストサンプル3060、3061、…の配置順に含んでいる。これにより、再生側では、テキストサンプル3060、3061、…のそれぞれの情報の境目を検出することができる。Sample−to−Chunk−Box 3053は、テキストサンプル3060、3061、…のそれぞれとサンプルエントリ3041、3042、…のそれぞれとを関連付ける情報を含んでいる。

0010

テキストサンプル3060は、テキスト3065と、テキスト3065のデータ長3066と、モディファイア3067とを有している。モディファイア3067は、テキスト3065のオプションの書式についての情報であり、テキスト3065をハイライト、カラオケ、ブリンク、ハイパーリンク等により再生させるための情報である。その他のテキストサンプル3061、…は、テキストサンプル3060と同様のデータ構造であるため、説明を省略する。

0011

次に、図19を用いて、Timed Textの再生に関して具体的に説明する。

0012

まず、サンプルエントリ3041の詳細な構造について図19(a)を参照して説明する。その他のサンプルエントリ3042、…については、同様のデータ構造であるので、説明を省略する。サンプルエントリ3041は、スクロールの有無と方向(displayFlags)、表示領域内での水平・垂直の寄せ位置(Horizontal justification, Vertical justification)、RGB値および透明度により指定される背景色(bgColor)、表示領域(TextBox)、フォント名(fontTable, font−ID)、フォントサイズ(fontSize)、太字イタリックアンダーライン等のスタイル(faceStyle)、RGB値および透明度により指定されるフォント色(textColor)等を含んでいる。なお、この書式を適用する範囲を指定するデータ(startChar,EndChar)は、常に値[0]を取り、サンプルエントリ3041の指定する書式が適用されるテキストサンプル中の全範囲のテキストに対して、この書式が適用されることを示している。図19(a)に示すサンプルエントリ3041のそれぞれの値は、テキスト3065のデフォルトの書式を、背景色を白色、フォント色を黒色およびスタイルをノーマルに指定することを意味している。

0013

次に、モディファイア3067の詳細な構造について図19(b)を参照して説明する。モディファイア3067は、モディファイア3067のデータ長(modifierSize)、テキスト3065のオプション書式の指定(modifierType, entryCount)、オプション書式を適用するテキスト3065の範囲の指定(startChar,EndChar)、フォント名(font−ID)、フォントサイズ(fontSize)、太字・イタリック・アンダーライン等のスタイル(faceStyle)、RGB値および透明度により指定されるフォント色(textColor)等を含んでいる。このオプション書式の指定は、サンプルエントリ3041、3042、…のいずれかで指定された書式に優先して適用される。図19(b)に示すモディファイア3067のそれぞれの値は、テキスト3065の5文字目から8文字目までを[太字]にすることを意味している。

0014

図19(c)に以上の書式が適用されたテキストサンプル3060の再生状態を示す。例えば、テキスト3065が示す内容が、[It’s fine today.]である場合に、5文字目から8文字目の[fine]が太字で再生される。またその再生時間は、Time−to−Sample−Box 3051において最初に配置される情報3055の値[1000]により、1000[ミリ秒]であることが分かる(図18参照)。

0015

以上に説明した構造をもつMP4ファイルの再生に際しては、あらかじめ受信端末にてMP4ファイルをダウンロードし、ダウンロード完了後に受信端末にてMP4ファイルの再生が行われる。MP4ファイルのダウンロードには、通常、信頼性のある伝送プロトコルであるTCPが用いられ、MP4ファイルが完全な形で受信端末に受信されることを保証する。

背景技術

0016

【非特許文献1】
’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>

0017

一方、ビデオ、オーディオを含むメディアデータを配信するサービスにおいて、ダウンロード型に代えてストリーミング型の配信が採用されることも多くなってきている。ストリーミング型の配信では、受信端末にてメディアデータを受信する処理と、受信したメディアデータを再生する処理とが並行して行われる。このため、長時間のメディアデータを再生する場合であっても、そのメディアデータの要求を行ってから再生が行われるまでの待ち時間が、少なくなるという利点を持つ。また、生中継されるメディアデータの配信にも好適な配信形式である。

0018

このようなストリーミング型の配信においては、メディアデータを伝送するための伝送プロトコルとしては、TCPではなくRTP/UDPが用いられる。TCPが信頼性のあるプロトコルであり、データの伝送を保証するのに対して、RTP/UDPは非信頼性プロトコルであり、リアルタイム性に優れるため、ストリーミング型配信に好適である。

0019

RTPを用いテキストや静止画といった静的メディアをRTPを用いて伝送する方式として、Generic RTP Payload Format for Time−lined static Media (http://standards.ericsson.net/westerlund/draft−westerlund−avt−rtp−static−media−00.txt)がある。この方式では、再生時間(duration) を表すためにDurationヘッダを付与したフォーマットであり、再生時間が受信側に通知されるという特徴がある。また、TCPではなくRTPを用いることから、静的メディアのリアルタイム送信利用することが可能となっている。

0020

しかしながら、RTP/UDPを用いるストリーミング型配信の場合、有線ネットワーク上や無線伝送路上でメディアデータを含んだパケット損失する場合があり、再生すべきテキストが表示できない。パケットが損失した場合、または次に再生すべきメディアデータが送信されない場合、いずれの場合であっても、受信端末では何もデータを受信しないので、次に表示すべきメディアデータがないのか、伝送途中にメディアデータが損失したため表示できないのか、受信端末は判定できないという課題があった。そのため、「ただいまデータを受信できません」というような表示を行い、ユーザにメディアデータの損失を通知することができなかった。

0021

一方、RTPを用いたストリーミングの場合、伝送路の状況に応じてパケットロスパケット損失)が発生する場合がある。RTPによるパケット伝送においては、RTPに付与されたシーケンス番号(SN)からパケットロスを検出する。すなわち、SNが4であるパケットを受信しない間にSNが5であるパケットを受信した場合、SNが4であるRTPパケットが損失したと判定する。音声及び映像データといった連続メディアの場合、各RTPパケットの送信間隔は、数10ミリ秒から100ミリ秒程度の短い間隔であるため、このようなパケットロス判定方法が可能である。パケットロスの品質への影響が大きい場合には、さらに、パケットロスの判定後、再送要求を行うことで品質劣化を防ぐことも可能である。この場合、再送による遅延を吸収するため、メディアの再生を開始する前に、通常、2〜3秒間データを先行して取得するプレバッファリング時間を設けることが行われている。

0022

しかしながら、Timed TextといったテキストメディアやJPEG等の静止画等の静的メディアに、RTPを用いたストリーミングを適用した場合、次のような問題がある。静的メディアの再生時間、すなわち、同一テキストや同一静止画を表示する時間は、通常数秒から10数秒であるため、RTPパケット送信間隔はそれに応じて数秒から10数秒となる。このRTPパケット送信間隔は、パケットロス検出に要する時間に等しく、通常のプレバッファリング時間よりも大きい。そのため、パケットロス検出に要する時間をプレバッファリング時間で吸収することが困難である。また、プレバッファリング時間を、例えば10〜20秒程度に大きくすれば、ユーザの快適性を著しく阻害するという問題がある。

0023

本発明はかかる点に鑑みてなされたものであり、Timed Text等の静的メディアをストリーミング型の配信で使用する場合に、データ受信端末が静的メディアデータを受信しない場合、次に表示すべきメディアデータがないのか、伝送途中にメディアデータが損失したため表示できないのかを判定し、ユーザにメディアデータの損失を正しく通知するためのデータ構造、データ送信装置データ受信装置を提供することを目的とする。

発明が解決しようとする課題

0024

また、本発明は、Timed Text等の静的メディアをストリーミング型の配信で使用する場合に、プレバッファリングを増加させることなく、パケットロス検出に要する時間を短くして再送要求を行うデータ伝送方法およびデータ受信装置を提供することを目的とする。

0025

本発明の静的メディア伝送用データの伝送データ構造は、静的メディアデータの再生にかかる静的メディア再生用データを転送し順次再生させるための静的メディア伝送用データの伝送データ構造であって、前記静的メディア再生用データは、前記静的メディアデータを分割した複数の分割静的メディアデータと、前記分割静的メディアデータを再生するための情報を含む静的メディアヘッダデータとを含み、前記静的メディア伝送用データは、前記分割静的メディアデータに付加された分割静的メディアデータ識別子と、前記静的メディアヘッダデータに付加された静的メディアヘッダデータ識別子と、次期静的メディア伝送用データに含まれる分割静的メディアデータに関わる静的メディア情報と、を含む構成を採る。

0026

この構成によれば、次期静的メディア伝送データに含まれる分割静的メディアデータの個数と次期静的メディア伝送データに含まれる分割静的メディアデータの静的メディア再生時間情報と次期静的メディア伝送データに含まれる分割静的メディアデータの静的メディアデータ長情報を含む次期静的メディア伝送データに含まれる分割静的メディアデータにかかわる静的メディア情報とを含むので、次期静的メディア伝送データが伝送エラー等の理由により損失した場合であっても、代替静的メディアを正確なデータ長と再生時間で表示することができる。なお、静的メディアデータとは、CG(Computer Graphics)等を構成するデータを意味する。

0027

本発明のプログラム伝送用データの伝送データ構造は、プログラムデータの再生にかかるプログラム再生用データを転送し順次再生させるためのプログラム伝送用データの伝送データ構造であって、前記プログラム再生用データは、前記プログラムデータを分割した複数の分割プログラムデータと、前記分割プログラムデータを再生するための情報を含むプログラムヘッダデータとを含み、前記プログラム伝送用データは、前記分割プログラムデータに付加された分割プログラムデータ識別子と、前記プログラムヘッダデータに付加されたプログラムヘッダデータ識別子と、次期プログラム伝送用データに含まれる分割プログラムデータに関わるプログラム情報と、を含む構成を採る。

0028

この構成によれば、次期プログラム伝送データに含まれる分割プログラムデータの個数と次期プログラム伝送データに含まれる分割プログラムデータのプログラム再生時間情報と次期プログラム伝送データに含まれる分割プログラムデータのプログラムデータ長情報を含む次期プログラム伝送データに含まれる分割プログラムデータにかかわるプログラム情報とを含むので、次期プログラム伝送データが伝送エラー等の理由により損失した場合であっても、代替プログラムを正確なデータ長と再生時間で表示することができる。なお、プログラムデータとは、JAVA(R)言語によるプログラムや、XML言語を利用したスクリプト等を含むものとする。

0029

本発明のテキスト伝送用データの伝送データ構造は、テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータを再生するための情報を含むテキストヘッダデータとを含み、前記テキスト伝送用データは、前記分割テキストデータに付加された分割テキストデータ識別子と、前記テキストヘッダデータに付加されたテキストヘッダデータ識別子と、次期テキスト伝送データに含まれる分割テキストデータの個数と次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報と、を含む構成を採る。

0030

この構成によれば、次期テキスト伝送データに含まれる分割テキストデータの個数と次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報とを含むので、次期テキスト伝送データが伝送エラー等の理由により損失した場合であっても、代替テキストを正確なテキスト長と再生時間で表示することができる。

0031

本発明のテキスト伝送用データの伝送方法は、前記テキスト再生用データは、前記テキストデータを分割した複数の分割テキストデータと、前記分割テキストデータの再生を開始する再生開始情報を含むテキストヘッダデータとを含み、前記テキスト再生用データに基づいて、前記テキスト伝送用データのペイロード部を作成する作成ステップと、次期パケットに含まれる分割テキストデータ数と、次期パケットに含まれる分割テキストデータの再生時間情報と、次期パケットに含まれる分割テキストデータのテキストデータ長とを付加しテキスト伝送用データのヘッダ部を作成する作成ステップと、前記作成された前記各ペイロード部に対してヘッダ部を付加し、パケットとする付加ステップとを備え、前期各ペイロード部は、前記テキストヘッダデータの前記再生開始情報を含むようにした。

0032

この方法によれば、次期テキスト伝送データに含まれる分割テキストデータの個数と次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報とを伝送するので、次期テキスト伝送データが伝送エラー等の理由により損失した場合であっても、代替テキストを正確なテキスト長と再生時間で表示することができる伝送方法を可能とする。

0033

本発明のデータ受信装置は、サーバーまたは対局からテキストデータを受信するデータ受信部と、受信データからテキストデータを表示するテキスト表示時間を抽出するテキスト表示時間抽出部と、次期テキストデータのテキストデータ情報が格納されている拡張ヘッダの情報を記憶する拡張ヘッダ記憶部と、テキストデータの損失を判定するデータ損失判定部と、受信したデータからテキストデータを抽出し記憶するテキスト抽出・記憶部と、表示すべきテキストデータが受信されなかった場合に表示するテキストを記憶する代替テキスト記憶部と、前記データ損失判定部でデータの損失があると判定された場合は前記拡張ヘッダ記憶部から入力されるテキスト表示時間をテキストを表示する時間と決定し、データの損失がないと判定された場合は前記テキスト表示時間抽出部から入力されるテキスト表示時間をテキストを表示する時間と決定するテキスト表示時間決定部と、前記データ損失判定部でデータの損失がないと判定された場合は前記テキスト抽出・記憶部に記憶されたテキストを表示することを決定し、データの損失があると判定された場合は、前記代替テキスト記憶部に記憶されている代替テキストを表示することを決定する表示テキスト決定部と、前記テキスト表示時間決定部で決定された時間、前記表示テキスト決定部で決定されたテキストを表示するテキスト表示部とを含む構成を採る。

0034

この構成によれば、次期テキスト伝送データに含まれる分割テキストデータの個数と次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報とを受信するので、次期テキスト伝送データが伝送エラー等の理由により損失した場合であっても、代替テキストを正確なテキスト長と再生時間で表示することができる受信装置を可能とする。

0035

本発明のデータ表示方法は、テキストデータの再生にかかるテキスト再生用データを転送し順次再生させるためのテキスト伝送用データのデータ受信表示方法であって、第1のテキスト伝送用データを受信し、第1のテキストデータの再生時間が経過後、第2テキストのテキスト伝送用データが受信されない場合データ損失があったと判定するデータ損失判定ステップと、データ損失と判定された場合第1のテキスト伝送用データに含まれる次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報を第2のテキスト伝送データとする置き換えステップと、テキストデータ長が1以上である場合は代替テキストをテキストデータ長表示し、テキストデータ長が0である場合はテキストデータの表示を行わないテキスト表示ステップとを含むようにした。

0036

この方法によれば、次期テキスト伝送データに含まれる分割テキストデータの個数と次期テキスト伝送データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送データに含まれる分割テキストデータにかかわるテキスト情報とを受信するので、次期テキスト伝送データが伝送エラー等の理由により損失した場合であっても、代替テキストを正確なテキスト長と再生時間で表示することができる受信表示方法を可能とする。

0037

本発明のデータ送信装置は、対局にテキストデータを送信するデータ送信装置であって、対局に送信するテキスト情報を記憶するテキスト情報記憶部と、現在生成中送信データの次の送信データとして送信するテキストに含まれるテキスト長や再生時間等の情報を生成する次期テキストデータ情報生成部と、テキストデータ伝送のための制御情報等と前記次期テキストデータ情報生成情報からヘッダを生成するヘッダ生成部と、伝送するテキストデータおよびその修飾情報から伝送データのペイロードを生成するペイロード生成部と、前記ヘッダと前記ペイロードから送信データを合成する送信データ合成部と、前記送信データを対局に送信するデータ送信部、とを含む構成を採る。

0038

この構成によれば、次期テキスト伝送用データに含まれる分割テキストデータの個数と次期テキスト伝送用データに含まれる分割テキストデータのテキスト再生時間情報と次期テキスト伝送用データに含まれる分割テキストデータのテキストデータ長情報を含む次期テキスト伝送用データに含まれる分割テキストデータに関わるテキスト情報とを送信するので、次期テキスト伝送用データが伝送エラー等の理由により損失した場合であっても、受信側が代替テキストを正確なテキスト長と再生時間で表示することができる送信装置を可能とする。

0039

本発明のデータ伝送方法は、静的メディアデータを再生させるために、前記静的メディアデータと前記静的メディアデータの再生時間を表す情報を伝送するデータ伝送方法であって、前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表すデータを前記静的メディアデータとともに伝送するようにした。

0040

この方法によれば、静的メディアデータの再生側において、次の静的メディアデータが元々あるものであるか否かを判断することができることにより、本来あるべき静的メディアデータが受信されない場合の対応をとることが可能となる。この対応としては、静的メディアデータの再送要求を送信すること、又は、本来あるべき静的データが再生されないことを表示することなどである。

0041

本発明のデータ受信方法は、複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間を表す静的メディア伝送用データを受信するデータ受信方法であって、第1の静的メディア伝送用データを受信した後、この第1の静的メディア伝送用データを基に再生される第1の静的メディアデータの再生時間が経過後、第2の静的メディア伝送用データが受信されたか否かを判断する受信結果判断ステップと、前記受信結果判断ステップの判断結果に基づいて、前記第2の静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定ステップと、前記データ損失判定ステップにおいてデータ損失があったものと判定された場合、前記第1の静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始ステップと、を具備するようにした。

0042

この方法によれば、本来あるべき静的メディアデータが受信されない場合、静的メディアデータの再送要求を送信することができる。そして、この再送要求を行うに際して、静的メディア伝送用データの受信を待つことなく、静的メディアデータの再生時間に基づいて再送要求を行うか否かを判断することにより、データのロスの検出に要する時間を短縮することができる。

0043

本発明のデータ受信方法は、複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間及び前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表す静的メディア伝送用データを受信するデータ受信方法であって、第1の静的メディア伝送用データを受信した後、この第1の静的メディア伝送用データを基に再生される第1の静的メディアデータの再生時間が経過後、前記第1の静的メディアデータに続く前記次期静的メディアデータを再生するための第2の静的メディア伝送用データが受信されたか否かを判断する受信結果判断ステップと、前記受信結果判断ステップの判断結果に基づいて、前記第2の静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定ステップと、前記データ損失判定ステップにおいてデータ損失があったものと判定された場合、前記第1の静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始ステップと、前記第1の静的メディア伝送用データに含まれる、前記次期静的メディアデータの再生時間に基づき、この次期静的メディアデータの再生時間の経過に応じて前記第2の静的メディア伝送用データの再送要求の送信を終了する再送要求送信終了ステップと、を具備するようにした。

0044

この方法によれば、次期静的メディアデータの再生時間の経過に応じて第2の静的メディア伝送用データの再送要求の送信を終了することができ、無用なデータの送信処理を回避することができる。

0045

本発明のデータ受信方法は、上記方法において、前記再送要求送信終了ステップでは、前記第2の静的メディア伝送用データの再送要求の送信を終了するタイミングとして、前記次期静的メディアデータの再生時間が終了する時間から、前記静的メディア伝送用データの送信側と受信側間でデータを往復伝送するために要する往復時間だけ遡った時間が設定されるようにした。

0046

この方法によれば、第2の静的メディアデータによる次期静的メディアの再生終了タイミングよりも、再送要求を送信してからこの再送要求に応じて第2の静的メディア伝送用データが受信されるまでの時間だけ遡ったタイミングを再送要求の終了タイミングとしたことにより、無用なデータの送信処理を回避することができる。

0047

本発明のデータ伝送方法は、静的メディアデータを再生させるために、前記静的メディアデータと前記静的メディアデータの再生時間を表す情報を伝送するデータ伝送方法であって、前記静的メディアデータの次に再生される次期静的メディアデータの再生時間を表すデータと前記次期静的メディアデータに含まれる文字数を表す情報とを前記静的メディアデータとともに伝送するようにした。

0048

この方法によれば、次期静的メディアデータとして再生されるべきデータがない場合には、データ受信装置側において、再送要求を行わせないようにすることにより、無用な再送要求の送信を回避させることができる。

0049

本発明のデータ受信方法は、複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間及び前記静的メディアデータの次に再生される次期静的メディアデータの再生時間と前記次期静的メディアデータに含まれる文字数とを表す静的メディア伝送用データを受信するデータ受信方法であって、静的メディア伝送用データを受信した後、この静的メディア伝送用データを基に再生される静的メディアデータの再生時間が経過後、前記静的メディアデータに続く前記次期静的メディアデータを再生するための次期静的メディア伝送用データが受信されたか否かを判断する受信結果判断ステップと、前記受信結果判断ステップの判断結果に基づいて、前記次期静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定ステップと、前記データ損失判定ステップにおいてデータ損失があったものと判定された場合、前記静的メディア伝送用データによって示される、次期静的メディアデータの文字数が0より大きいことを条件に、前記静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始ステップと、を具備するようにした。

0050

この方法によれば、次期静的メディアデータとして再生されるべきデータがない場合には、再送要求を行わないことにより、無用な再送要求の送信を回避することができる。

0051

本発明のデータ受信装置は、複数の静的メディアデータを順次再生させるために送信された、前記静的メディアデータの再生時間を表す静的メディア伝送用データを受信するデータ受信装置であって、第1の静的メディア伝送用データを受信した後、この第1の静的メディア伝送用データを基に再生される第1の静的メディアデータの再生時間が経過後、第2の静的メディア伝送用データが受信されたか否かを判断する受信結果判断手段と、前記受信結果判断手段の判断結果に基づいて、前記第2の静的メディア伝送用データが受信されない場合、データ損失があったものと判定するデータ損失判定手段と、前記データ損失判定手段によってデータ損失があったものと判定された場合、前記第1の静的メディア伝送用データの再送要求の送信を開始する再送要求送信開始手段と、を具備する構成を採る。

課題を解決するための手段

0052

この構成によれば、本来あるべき静的メディアデータが受信されない場合、静的メディアデータの再送要求を送信することができる。そして、この再送要求を行うに際して、静的メディア伝送用データの受信を待つことなく、静的メディアデータの再生時間に基づいて再送要求を行うか否かを判断することにより、データのロスの検出に要する時間を短縮することができる。

0053

本発明の骨子は、静的メディア伝送用データに含まれる分割静的メディアデータの再生に関する情報をその静的メディア伝送用データよりも前の静的メディア伝送用データに格納して伝送することにより、分割静的メディアデータが受信されない場合に、その分割静的メディアデータが元々ないものであるか、または損失したものであるかを判断することである。

0054

また、本発明の骨子は、静的メディア伝送用データに含まれる再生時間情報を用いて、再生時間が経過した後に、次に再生すべき静的メディアが受信されない場合に、パケットロスが発生したと判定し、再送要求を行うか否かを判断することである。

0055

以下、本発明の実施の形態について、図面を参照して詳細に説明する。

0056

(実施の形態1)
実施の形態1では、RTP(Real Time Transport Protocol)、RTSP(Real Time Streaming Protocol)およびSDP(Session Description Protocol)を用いたテキストトラックのストリーミング伝送について説明する。RTPはIETF(Internet Engineering Task Force)が勧告するRFC1889において規定されている、マルチメディアストリームパケットフォーマットである。RTSP,SDPは、それぞれ、RFC2326、RFC2327で規定される、マルチメディアストリーミングの制御プロトコルである。なお、この実施の形態においては、静的メディアデータとしてテキストデータを用いる場合について説明する。

0057

図1は本発明の実施の形態1に係るデータ受信装置の構成を示すブロック図である。このデータ受信装置は、テキストデータを含むRTPパケット(RTP packet)を受信するデータ受信部1001と、RTPパケットに含まれるテキストを表示する時間を抽出するテキスト表示時間抽出部1002と、RTPパケットの拡張ヘッダ部に含まれる次期テキスト長、次期テキスト表示時間記憶部を抽出し記憶する拡張ヘッダ記憶部1003と、RTPパケットが受信されるべく時刻になっても受信されない場合、RTPパケットの損失または遅延と判定するデータ損失判定部1004と、RTPパケットに含まれるテキストデータを抽出し、記憶するテキスト抽出・記憶部1005と、フォント、色などテキストデータを修飾するための修飾情報を受信データから判定するテキスト修飾判定部1006と、RTPパケットの損失又は遅延により、表示すべきテキストデータが利用できない場合に表示するための代替テキストを記憶する代替テキスト記憶部1007と、前記テキスト表示時間抽出部1002で抽出された時間、または、拡張ヘッダ記憶部1003で記憶された次期テキスト表示時間記憶部からテキストデータを表示する時間を決定するテキスト表示時間決定部1008と、パケットの損失または遅延がない場合はRTPパケットに含まれるテキストデータを前記テキスト修飾判定部で判定された修飾方法に従って表示テキストを決定し、パケットの損失または遅延がある場合は、前記代替テキスト記憶部1007で記憶された代替テキストを表示することを決定する表示テキスト決定部1009と、前記テキスト表示時間決定部1008で決定された時間、前記表示テキスト決定部1009で決定されたテキストを表示するテキスト表示部1010とを有する。なお、データ損失判定部1004でデータの損失がないと判定された場合はテキスト抽出・記憶部1005に記憶されたテキストをテキスト修飾判定部1006で判定された修飾方法でテキストを表示することを表示テキスト決定部1009において決定する。

0058

このデータ受信装置において、データ損失判定部1004がデータの損失がないものと判定すると、テキスト表示時間抽出部1002においてRTPパケットに含まれるテキストを表示する時間(図2において後述するDuration 8006)を抽出するとともに、この抽出された時間をテキスト表示時間決定部1008が選択する。また、このとき、表示テキスト決定部1009は、データ損失判定部1004から供給されるデータ損失がない旨の情報に基づいて、テキスト抽出・記憶部1005によって抽出されたテキストデータ(図2において後述するテキスト8008)を選択する。これにより、データ損失判定部1004においてデータの損失がないものと判定された場合には、現在受信中のテキストデータがその現在のRTPパケットに含まれるDuration 8006によって決定される時間だけテキスト表示部1010に表示されることとなる。

0059

これに対して、データ損失判定部1004においてデータの損失があるものと判定された場合には、その結果に基づいて、表示テキスト決定部1009は、テキスト抽出・記憶部1005に代えて、代替テキスト記憶部1007に記憶されている例えば「*印」のような代替テキストを選択する。また、このとき、テキスト表示時間決定部1008は、拡張ヘッダ記憶部1003に記憶されている前のRTPパケットにおいて受信された拡張ヘッダ(図2において後述するHeader Extension 8003)の表示時間(図2において後述するNext Sample Duration8202,8204,8206及びNext Sample Length 8203,8205,8207、すなわち現在受信中のデータ損失が生じた部分の表示時間に関する情報)に基づいて、そのNext Sample Durationによって指定される時間だけ代替テキスト記憶部1007に記憶されている代替テキストをテキスト表示部1010に表示させる。但し、拡張ヘッダ記憶部1003に記憶されているNext Sample Lengthが0である場合は、表示されるテキストが元々ないことを意味していることにより、テキスト表示時間決定部1008は、Next Sample Durationが指定する間においても、テキスト表示部1010には何も表示させないようにする。

0060

このように、現在受信中のRTPパケットのテキストデータの表示時間及びテキストデータの有無を表す情報が、前のRTPパケットの拡張ヘッダに格納されて送信されて来ることにより、この拡張ヘッダを拡張ヘッダ記憶部1003に記憶しておけば、この記憶された拡張ヘッダに基づいて、データ損失時に、元々テキストデータが有ったのか否かを判断することができ、テキストデータが元々有ったにも関わらずデータ損失判定がなされた場合には、代替テキストをその時間だけ表示させることが可能となる。

0061

ここで、本発明の実施の形態1に係るサーバーが備えるMP4ファイル形式のメディアデータは、RTPパケットとして伝送される。

0062

MP4ファイルが備えるTimed Textをストリーミング伝送により利用するために、RTPパケットは図2に示すデータ構造を有している。図2に示すRTPパケットのデータ構造は、RTPヘッダ8001とRTPペイロード8002とから構成される。この実施の形態では、RTPヘッダ8001とRTPペイロード8002を含むパケット全体をテキスト伝送用データと呼ぶ。RTPペイロードは、後述するHeader Extension(拡張ヘッダ)8003と、それぞれ1つのテキストサンプルを含むテキストフレーム#1, #2, #3(8101,8102,8103)を含む。それぞれのテキストフレームの構成をテキストフレーム#1(8101)を用いて説明する。テキストフレーム#2、テキストフレーム#3、以降、同一の構成であるので説明を省略する。因みに、この実施の形態では、RTPヘッダ8001とRTPペイロードのHeader Extension(拡張ヘッダ)とをヘッダ部と呼ぶこととする。

0063

テキストフレーム8101の構成は、テキストフレーム長を表すLength 8004と、サンプルエントリとの関連を表すIndex 8005と、テキストサンプルを表示する時間を表すDuration 8006と、テキストサンプルに含まれるテキストの長さを表すTextLength 8007と、表示するテキスト8008と、テキストを修飾するための情報Modifier 8009からなる。この実施の形態では、テキストフレーム長を表すLength 8004と、サンプルエントリとの関連を表すIndex 8005と、テキストサンプルを表示する時間を表すDuration 8006とをまとめてテキストヘッダデータと呼び、テキストサンプルに含まれるテキストの長さを表すTextLength 8007と、表示するテキスト8008と、テキストを修飾するための情報Modifier 8009とからなるText Sampleを分割テキストデータと呼ぶこととする。また、テキスト再生用データとは、図18について上述したMP4ファイル3000を意味するものとする。図18に示したMP4ファイル3000のヘッダ部3010を構成するデータは、図2に示した、テキストヘッダデータ(テキストフレーム長を表すLength 8004、サンプルエントリとの関連を表すIndex 8005及びテキストサンプルを表示する時間を表すDuration 8006)として、対応するテキストサンプル(分割テキストデータ)とともにRTPパケットのテキストフレームに格納される。

0064

次に、次のRTPパケット(SN=2)に含まれるテキストフレームの情報を記述するHeader Extension(拡張ヘッダ)8003の構成を説明する。Header Extension(拡張ヘッダ)8003は、次RTPパケットに含まれるテキストフレーム数を表すNo. of Next Samples 8201と、次RTPに含まれるテキストフレームの情報を表すNextSampleDuration#1 8202、NextSampleLength#1 8203、NextSampleDuration#2 8204、NextSampleLength#2 8205、…、とから構成される。No. of Next Samples 8003が3である場合は、次のRTPパケットにはテキストフレームが3つ含まれることを表す。次のRTPパケットに含まれる第1テキストフレームの情報であるNextSampleDuration#1 8202、NextSampleLength#1 8203について説明する。第2テキストフレーム以降については、第1テキストフレームの場合と同様であるので説明を省略する。NextSampleDuration#1 8202は、次のRTPパケットに含まれる第1テキストフレームのテキスト表示時間を示す。NextSampleLength#1 8203は、次のRTPパケットに含まれる第1テキストフレームにテキスト長を示す。すなわち、NextSampleDuration#1 8202は、SN=2のRTPパケットのDuration 8212と同一であり、NextSampleLength#1 8203は、SN=2のRTPパケットのTextLength 8213と同一である。

0065

この伝送構造を用いた場合の受信端末動作例について説明する。受信端末装置図3に示すような表示がなされる例を説明する。まず、テキスト長が22である”Could you help me out?”が6秒表示され、テキスト長が5である”Sure”が3秒表示され、テキスト長が7である”Thanks.”が5秒表示される。なお、空白も文字数に含まれる。

0066

この場合のTimedTextのRTPパケットへの格納方法図2を用いて説明する。なお、この場合、1テキストサンプルを1RTPパケットに格納する場合について説明している。SN=1のRTPパケットには、”Could you help me out?”がTextフィールドに格納され、Durationに6000、TextLengthに22が格納される。次のRTPパケット(SN=2)に含まれるテキストフレーム表示時間であるNextSampleDurationと、NextSampleLengthには、それぞれ、3000、5が格納され、5文字から成る”Sure.”が3秒表示されることを示す。以下、同様に、RTPパケットSN2, SN3にテキスト情報が格納される。

0067

次にRTPパケット(SN=2)が損失した場合の、受信端末装置の表示について図4を用いて説明する。受信端末装置は、RTPパケット(SN=1)を受信すると、”Could you help me out?”を指定された時間である6秒間表示する。RTPパケット(SN=2)が損失した場合、6秒後になっても次のテキスト情報が受信されないので、RTPパケット(SN=1)に含まれるHeader Extensionによってテキスト長が5、テキスト表示時間が3秒であることを参照し、テキストが正しく受信できなかったことを表す”*”を5文字分、”*****”と3秒間表示する。

0068

次に、以上のように格納されたRTPパケットを受信した受信端末の動作を図5に示すフロー図を用いて説明する。

0069

受信端末装置は、RTPパケット(SN=i)を受信後、テキストを再生し、SN=iに含まれるテキストの再生時刻が終了するまで表示を続ける(ステップST9001)。再生時刻が終了すると、次のシーケンス番号SN=i+1のRTPパケットを受信したかどうか判定する(ステップST9002)。RTPパケット(SN=i+1)を受信している場合はステップST9003に、受信していない場合はステップST9005に進む。ステップST9003では、受信したSN=i+1のRTPパケットからDuration、Textを読み込み(ステップST9003)、TextをDurationで指定された時間受信端末に表示する(ステップST9004)。ステップST9005では、SN=iのRTPパケットからNextSampleDuration、NextSampleLengthを読み込み、表示すべきデータが損失したことを示す”*”を、TextLength個、NextSampleDuration時間再生する(ステップST9006)。ステップST9007では、iを1増分する。

0070

次に、1RTPパケットに複数のテキストフレームを格納する場合の動作について説明する。1RTPパケットあたり1テキストフレームを格納する場合と異なる部分のみ説明する。

0071

図6図7及び図8はRTPパケットへのテキスト格納例である。””は空のテキスト、すなわち何もテキストを表示しないことを表す。

0072

RTPパケット(SN=1)には「Tom, this is Kay Adams.」8501、「””」8503、「Kay, this is my brother, Tom Hagen.」8502というテキストが格納される。拡張ヘッダにはRTPパケット(SN=2)に含まれるテキスト情報も格納される。RTPパケット(SN=2)には「How do you do.」8504、「””」8505、「How do you do.」8506というテキストが格納される。拡張ヘッダにはRTPパケット(SN=3)に含まれるテキスト情報も格納される。RTPパケット(SN=3)には「Nice to meet you.」8507、「””」8508が格納され、拡張ヘッダにはRTPパケット(SN=4)に含まれるテキスト情報も格納される。

0073

図9を用いて伝送誤りがない場合の表示例を説明する。最初の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.」、6秒間空のテキストを表示する。

0074

次に伝送誤りがあり、RTPパケット(SN=2)が損失した場合の表示方法について図10を用いて説明する。

0075

SN=1のRTPパケットは正しく受信されているので、最初の0.5秒間 「Tom, this is Kay Adams.」、次の0.5秒間「Kay, this is my brother, Tom Hagen.」が表示され、次の0.4秒間は何も表示されない。次のRTPパケットは損失しているため、次のテキストは正しく表示することができないが、0.5秒間14文字、0.2秒間空テキスト、0.5秒間14文字であることが、SN=1のRTPパケットに含まれる拡張ヘッダに格納されているため、0.5秒間「*」を14文字並べたものを表示し、次に0.2秒間テキストを非表示にし、次の0.5秒間「*」を14文字並べたものを表示する。

0076

なお、完全に損失した場合について説明したが、SN=2のRTPパケットが遅延した場合に、本方法を用いて表示を行ってもよい。その場合、本表示方法を用いて表示している間に遅延RTPパケットが到着次第、エラーがない場合の表示方法に切り替えてもよい。

0077

図11は本発明の実施の形態1に係るデータ送信装置の構成を示すブロック図である。

0078

このデータ送信装置は、送信先に送信するテキスト情報と修飾情報を記憶するテキスト情報記憶部2001と、現在生成中の送信データの次の送信データとして送信するテキストに含まれるテキスト長や再生時間等の情報を生成する次期テキストデータ情報生成部2003と、テキストデータ伝送のための制御情報等と前記次期テキストデータ情報生成情報からヘッダを生成するヘッダ生成部2002と、伝送するテキストデータおよび修飾情報から伝送データのペイロードを生成するペイロード生成部2004と、前記ヘッダと前記ペイロードから送信データを合成する送信データ合成部2005と、前記送信データを送信先に送信するデータ送信部2006、とを有する。

0079

かかる構成の送信装置において、次期テキストデータ情報生成部2003は、テキスト情報記憶部2001から次の送信データとして送信するテキストの情報を読み出すことにより、現在送信中の送信データに、次の送信データのテキストに含まれる情報(テキスト調、再生時間等)を含めることができる。

0080

このように、本実施の形態のデータ構造、データ受信端末装置及びデータ送信端末装置によれば、拡張ヘッダによって次のRTPパケットとして送信されるテキストデータの表示時間(Next Sample Duration)及びテキストデータの有無(Next Sample Length)を予め送信しておくことにより、データ受信端末装置では、データ損失があった場合に、元々テキストデータがなかったものであるか否かを判断することができ、元々テキストデータがなかった場合には、テキスト表示部1010において代替テキストを表示させず、これに対して元々テキストデータが有った場合には、テキスト表示部1010において代替テキストを表示させるようにすることができる。

0081

これにより、テキスト表示部1010において*印のような代替テキストが表示されるか否かによって、元々何らかのテキストデータが有ったにも関わらずデータ損失が有った場合と、元々テキストデータがない場合の識別が可能となる。

0082

なお、本発明の拡張ヘッダはデータ送信前にあらかじめクライアントに送信されるSDPのパラメータによって、拡張ヘッダ使用の有無を通知してもよい。例えば、サーバーが次期伝送データ情報を拡張ヘッダを用いて送信する場合には、SDPに「next−packet−info: 1」と記述し、拡張ヘッダを含まないときはSDPに「next−packet−info: 0」と記述することができる。

0083

また、上述の実施の形態1においては、静的メディアデータとしてテキストデータを伝送する場合について述べたが、本発明はこれに限らず、静止画データやCG等の静的メディアデータ、若しくはJAVA(R)言語等によるプログラムデータ等のデータを伝送する場合において広く適用することができる。この場合、テキストデータに代えて静止画データ、静的メディアデータ又はプログラムデータを用いるようにすればよく、代替テキスト記憶部1007には代替静止画データ、代替静的メディアデータ又は代替プログラムデータが記憶されていることとなる。この代替静止画データ、代替静的メディアデータ又は代替プログラムデータは、表示テキスト決定部1009(静止画を受信する場合には静止画を決定する機能となり、静的メディアを受信する場合は静的メディアを決定する機能となり、プログラムデータを受信する場合はプログラムを決定する機能となる)は、受信された静止画データ、静的メディアデータ又はプログラムデータのサイズに合わせたサイズの代替静止画、代替静的メディア又は代替プログラムを代替テキスト記憶部1007に要求し、代替テキスト記憶部1007は、要求されたサイズの代替静止画、代替静的メディア又は代替プログラムを表示テキスト決定部1009に供給するものとする。

0084

(実施の形態2)
実施の形態2では、MPEG−2 TSを用いたテキストトラックのストリーミング伝送について説明する。テキストトラックは、3GPPで規定されるTimed Textと同様な表現でテキスト再生を行うための情報を備えるデータである。

0085

MPEG−2 TSを用いテキストトラックをストリーミング伝送するためのPESパケット1のデータ構造を図12に示す。

0086

MPEG−2システムでは、ビデオ、オーディオ、あるいはテキストといったトラックを構成する要素となる信号をES(Elementary Stream)と呼んでいる。さらに、ESを可変長のブロックに区切りヘッダ情報を付加したものをPES(Packetized Elementary Stream)と呼んでいる。MPEG−2システムでは、複数のPESを多重伝送する信号として、TS(Transport Stream)を規定している。

0087

図12に示すPESパケットのデータ構造は、MPEG−2システムで規定されるPESヘッダ部310と、ペイロード部311とから構成される。PESヘッダ部310は、ビデオ、オーディオ、あるいはテキストといったトラック間の同期再生のための時刻情報であるPTS(Presentation Time Stamp)を有している。ペイロード部311は、トラックヘッダ3111と、サンプルディスクリプション3112と、コンフィグインフォメーション3113と、拡張ヘッダ3114と、テキストフレーム3115、3115′、…と、それぞれの情報を識別する識別子(トラックヘッダ識別子3111a、サンプルディスクリプション識別子3112a、コンフィグインフォメーション識別子3113a、拡張ヘッダ識別子3114a、テキストフレーム識別子3115a)とを含んでいる。トラックヘッダ3111と、サンプルディスクリプション3112と、コンフィグインフォメーション3113と、テキストフレーム3115、3115′については実施の形態1と同じであるため説明を省略する。ペイロードに含まれる各情報の識別子の直前にはスタートコードSCP)3110として ”000001”が挿入される。

0088

拡張ヘッダ3114は、実施の形態1と同様に、PESパケットに含まれるテキストフレームの情報を記述するHeader Extension(拡張ヘッダ)8003の構成を説明する。Header Extension(拡張ヘッダ)8003は、次PESパケットに含まれるテキストフレーム数を表すNo. of Next Samples 8201と、次RTPに含まれるテキストフレームの情報を表すNextSampleDuration#1 8202、NextSampleLength#1 8203、NextSampleDuration#2 8204、NextSampleLength#2 8205 、…、とから構成される。No. of Next Samples 8003が3である場合は、次のPESパケットにはテキストフレームが3つ含まれることを表す。次のPESパケットに含まれる第1テキストフレームの情報であるNextSampleDuration#1 8202、NextSampleLength#1 8203について説明する。第2テキストフレーム以降については、第1テキストフレームの場合と同様であるので説明を省略する。NextSampleDuration#1 8202は、次のPESパケットに含まれる第1テキストフレームのテキスト表示時間を示す。NextSampleLength#1 8203は、次のRTPパケットに含まれる第1テキストフレームにテキスト長を示す。すなわち、NextSampleDuration#1 8202は、次のPESパケットのDuration 8212と同一であり、NextSampleLength#1 8203は、次のPESパケットのTextLength 8213と同一である。

0089

このように、本実施の形態のデータ構造によれば、MPEG−2 TSを用いたテキストトラックのストリーミング伝送においても、テキストデータ損失時に元々テキストデータが有ったものであるか否かの判断が容易になる。

0090

(実施の形態3)
実施の形態3では、実施の形態1の場合と同様にして、RTP(Real Time Transport Protocol)、RTSP(Real Time Streaming Protocol)およびSDP(Session Description Protocol)を用いたテキストトラックのストリーミング伝送について説明する。RTPはIETF(Internet Engineering Task Force)が勧告するRFC1889において規定されている、マルチメディアストリームのパケットフォーマットである。RTSP,SDPは、それぞれ、RFC2326、RFC2327で規定される、マルチメディアストリーミングの制御プロトコルである。なお、この実施の形態においては、静的メディアデータとしてテキストデータを用いる場合について説明する。

0091

図13は本発明の実施の形態3に係るデータ受信装置の構成を示すブロック図である。このデータ受信装置は、テキストデータを含むRTPパケットを受信するデータ受信部1001と、RTPパケットに含まれるテキストを表示する時間を抽出するテキスト表示時間抽出部1002と、RTPパケットの拡張ヘッダ部に含まれる次期テキスト文字数、次期テキスト表示時間を抽出し記憶する拡張ヘッダ記憶部1003と、時間情報を生成するタイマー1017と、このタイマー1017を用い、RTPパケットが受信されるべき時刻になっても受信されない場合に、RTPパケットの損失があると判定するデータ損失判定部1004と、RTPパケットに含まれるテキストデータを抽出し、記憶するテキスト抽出・記憶部1005と、フォント、色等、テキストデータを修飾するための修飾情報を受信データから判定するテキスト修飾判定部1006と、テキスト抽出・記憶部1005から出力されるテキストデータをテキスト修飾判定部1006から出力される修飾情報によって修飾したデータを、テキスト表示時間抽出部1002から供給される表示時間だけ液晶表示部等の所定の表示手段に表示させるテキスト表示部1010と、データ損失判定部1004においてデータ損失と判定された場合に、再送要求の送信開始時刻送信終了時刻をタイマー1017を用いて算出し、再送要求を行うか否かを判定する再送要求判定部1018と、再送要求判定部1018において再送要求を行うと判定された場合に再送要求パケットを生成する再送要求パケット生成部1019と、再送要求パケット生成部1019において生成された再送要求パケットを送信側に送信するデータ送信部1011とを有する。

0092

このデータ受信装置において、データ損失判定部1004がデータの損失がないものと判定すると、テキスト表示時間抽出部1002においてRTPパケットに含まれるテキストを表示する時間(図2において上述したDuration8006)を抽出し、テキスト表示部1010はそれに従いテキストを表示する。

0093

ここで、本発明の実施の形態3に係るサーバが備えるMP4ファイル形式のメディアデータは、RTPパケットとして伝送される。

0094

MP4ファイルが備えるTimed Textをストリーミング伝送により利用するために、RTPパケットは、実施の形態1において図2に示したデータ構造と同様のデータ構造を有している。図2に示したように、RTPパケットのデータ構造は、RTPヘッダ8001とRTPペイロード8002とから構成される。この実施の形態では、RTPヘッダ8001とRTPペイロード8002を含むパケット全体をテキスト伝送用データと呼ぶ。RTPペイロードは、後述するHeader Extension(拡張ヘッダ)8003と、それぞれ1つのテキストサンプルを含むテキストフレーム#1, #2, #3(8101,8102,8103)を含む。それぞれのテキストフレームの構成をテキストフレーム#1(8101)を用いて説明する。テキストフレーム#2、テキストフレーム#3、以降、同一の構成であるので説明を省略する。因みに、この実施の形態では、RTPヘッダ8001とRTPペイロードのHeader Extension(拡張ヘッダ)とをヘッダ部と呼ぶこととする。

0095

テキストフレーム8101の構成は、テキストフレーム長を表すLength 8004と、サンプルエントリとの関連を表すIndex 8005と、テキストサンプルを表示する時間を表すDuration 8006と、テキストサンプルに含まれるテキストの長さを表すTextLength 8007と、表示するテキスト8008と、テキストを修飾するための情報Modifier 8009からなる。この実施の形態では、テキストフレーム長を表すLength 8004と、サンプルエントリとの関連を表すIndex 8005と、テキストサンプルを表示する時間を表すDuration 8006とをまとめてテキストヘッダデータと呼び、テキストサンプルに含まれるテキストの長さを表すTextLength 8007と、表示するテキスト8008と、テキストを修飾するための情報Modifier 8009とからなるText Sampleを分割テキストデータと呼ぶこととする。また、テキスト再生用データとは、図18について上述したMP4ファイル3000を意味するものとする。図18に示したMP4ファイル3000のヘッダ部3010を構成するデータは、図2に示した、テキストヘッダデータ(テキストフレーム長を表すLength 8004、サンプルエントリとの関連を表すIndex 8005及びテキストサンプルを表示する時間を表すDuration 8006)として、対応するテキストサンプル(分割テキストデータ)とともにRTPパケットのテキストフレームに格納される。

0096

次に、次のRTPパケット(SN=2)に含まれるテキストフレームの情報を記述するHeader Extension(拡張ヘッダ)8003の構成を説明する。Header Extension(拡張ヘッダ)8003は、次RTPパケットに含まれるテキストフレーム数を表すNo. of Next Samples 8201と、次RTPに含まれるテキストフレームの情報を表すNextSampleDuration#1 8202、NextSampleLength#1 8203、NextSampleDuration#2 8204、NextSampleLength#2 8205、…、とから構成される。No. of Next Samples 8201が3である場合は、次のRTPパケットにはテキストフレームが3つ含まれることを表す。次のRTPパケットに含まれる第1テキストフレームの情報であるNextSampleDuration#1 8202、NextSampleLength#1 8203について説明する。第2テキストフレーム以降については、第1テキストフレームの場合と同様であるので説明を省略する。NextSampleDuration#1 8202は、次のRTPパケットに含まれる第1テキストフレームのテキスト表示時間を示す。NextSampleLength#1 8203は、次のRTPパケットに含まれる第1テキストフレームのテキスト長を示す。すなわち、NextSampleDuration#1 8202は、SN=2のRTPパケットのDuration 8212と同一であり、NextSampleLength#1 8203は、SN=2のRTPパケットのTextLength 8213と同一である。

0097

この伝送構造を用いた場合の受信端末動作例について説明する。受信端末装置に図3に示したような表示がなされる例を説明する。まず、テキスト長が22である”Could you help me out?”が6秒表示され、テキスト長が5である”Sure”が3秒表示され、テキスト長が7である”Thanks.”が5秒表示される。なお、空白も文字数に含まれる。

0098

この場合のTimedTextのRTPパケットへの格納方法を図14を用いて説明する。なお、この場合、1テキストサンプルを1RTPパケットに格納する場合について説明している。SN=1のRTPパケットには、”Could you help me out?”がTextフィールドに格納され、Durationに6000、TextLengthに22が格納される。次のRTPパケット(SN=2)に含まれるテキストフレーム表示時間であるNextSampleDurationと、NextTextLengthには、それぞれ、3000、5が格納され、5文字から成る”Sure.”が3秒表示されることを示す。以下、同様に、RTPパケットSN2, SN3にテキスト情報が格納される。

0099

次に、RTPパケットが損失した場合の、データ受信装置の表示動作について、図15を用いて説明する。

0100

まず、パケットが損失した場合の、データ受信装置の動作を説明する。図15(a)において、横軸は時間を表し、時刻t1、t2、t3、t4は、それぞれ、RTPパケット(SN=1、SN=2、SN=3、SN=4)に含まれるテキストを再生する時刻である。プレバッファリング時間が0である場合は、時刻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となる。ここでは、プレバッファリング時間を0として説明する。

0101

また、図15(a)に示すように、例えば、SN=1のRTPパケットに含まれる表示時間DUR(Duration)の秒換算値は5秒であり、次の表示時間DUR(すなわちNDUR(Next Duration))の秒換算値は6秒であるとする。つまり、SN=1のRTPパケットに含まれるテキストを表示する時間は5秒であり、次のSN=2のRTPパケットに含まれるテキストを表示する時間は6秒であり、それはSN=2のRTPパケットのDURの秒換算値に等しい。また、SN=2以降のRTPパケットについても同様である。

0102

そして、本実施の形態では、そのRTPパケット(例えばSN=1のRTPパケット)に含まれるそのRTPパケットの再生時間(Duration)に基づいて、次のRTPパケット(例えばSN=2)の再生開示時間を判断することができ、また、図16について後述するように、そのRTPパケット(例えばSN=1のRTPパケット)に含まれる、次のRTPパケット(SN=2)の再生時間(NextSampleDuration)に基づいて、当該次のRTPパケット(例えばSN=2)に続くさらに次のRTPパケット(例えばSN=3)の再生開示時間を判断することができることに着目し、この再生時間に基づいて再送要求を行うか否かを判断することを特徴としている。

0103

次に、SN=2のRTPパケットが損失した場合の動作を図15(b)を用いて説明する。本実施の形態では、SN=3のRTPパケットを受信する前に、SN=1のDUR値を用いてSN=2のRTPパケットのパケットロスを検出するようにしている点を特徴としている。

0104

SN=1のRTPパケットの再生時間が5秒であることは、SN=1に含まれる再生時間情報DUR(Duration)が5秒であることから算出できる。従って、SN=2のRTPパケットを再生開始する時刻t2は、SN=1の再生開始時刻t1にその再生時間DURの5秒を加えた値となる。そして、時刻t1に姿勢を開始したSN=1のRTPパケットのテキスト再生終了時刻t2においてSN=2のRTPパケットが受信されない場合は、SN=2のRTPパケットがロスしたものと判定し、再送要求パケットを送信する。

0105

次に、連続する2つのRTPパケットがロスした場合の動作を図16を用いて説明する。図16(a)は、SN=2及びSN=3のRTPパケットがロスした場合を示している。この場合、図15に示した場合と同様にして、時刻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)と表記することがある。

0106

ここで、図16(b)は、図16(a)に示した再送要求処理の他の実施の形態を示す略線図である。この図16(b)に示す再送要求処理では、図16(a)に示した場合と比べて、再送要求の送信開始のタイミング及び送信終了のタイミングをRTPパケットの再生開始時刻t1、t2、t3、…とは異なるタイミングとしている点が相違する。

0107

すなわち、例えば、SN=2のRTPパケットの再送要求を開始する時刻t2’は、本来、SN=2のRTPパケットを再生開始する時刻t2の時刻に対して、ある一定時間(const)を加えた時刻t2’(=t2+const)としている。これにより、RTPパケットの受信タイミング誤差を吸収することができ、実際に送信側から送信されたSN=2のRTPパケットが時刻t2を過ぎて受信されたとしても、その遅れがconst以内であれば、これを受信及び再生することができ、無用な再送要求の送信を回避することができる。

0108

また、例えば、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パケットをデータ受信装置において受信することができる。

0109

このように図16(b)の再送要求処理によれば、一段と円滑な再送要求及びこれに応じて再送されたRTPパケットの再生処理を行うことが可能となる。

0110

以上説明したRTPパケットを受信する際のデータ受信装置の受信動作を、図17に示すフローチャートを用いて説明する。

0111

図17に示すように、データ受信装置のデータ損失判定部1004は、ステップST9011において、SN=iのRTPパケットを受信したか否かを判断する。ここで否定結果が得られると、このことは、未だSN=iのRTPパケットを受信していないことを意味しており、このときデータ損失判定部1004は、当該ステップST9011の判断処理を繰り返す。

0112

これに対して、ステップST9011において肯定結果が得られると、このことは、SN=iのRTPパケットを受信したことを意味しており、このときデータ損失判定部1004は、続くステップST9012に移って、現在時刻tと、SN=iのRTPパケットの再生開始時刻tiにその再生時間DUR(i)を加算した時刻を比較し、現在時刻tの方が大きいか又は等しい場合は、SN=i+1のRTPパケットに含まれるテキストの再生開示時刻が経過したものと判断し、ステップST9013に移る。

0113

因みに、ステップST9012において否定結果が得られると、このことは、SN=i+1のRTPパケットに含まれるテキストの再生開始時刻が未だ経過していないことを意味しており、このときデータ損失判定部1004は、このステップST9012の判断処理を繰り返す。

0114

かくして、SN=i+1のRTPパケットに含まれるテキストの再生開始時刻が経過した際に、データ損失判定部1004は、ステップST9013に移り、SN=i+1のRTPパケットが受信されたか否かを判断する。このステップST9013において肯定結果が得られると、このことは、SN=iのRTPパケットの再生時間が経過した後、このRTPパケットに続くSN=i+1のRTPパケットが受信されたこと、すなわち、SN=iのRTPパケットの表示時間が経過した際に、次に表示すべきデータを受信したことを意味している。従って、このときデータ損失判定部1004は、ステップST9017に移って、iを1増分した後、上述のステップST9012に戻り、ステップST9013において受信が確認されたRTPパケットの表示時間の経過を待つ。

0115

これに対して、ステップST9013において否定結果が得られると、このことは、SN=iのRTPパケットの再生時間が経過した後、このRTPパケットに続くSN=i+1のRTPパケットが受信されていないこと、すなわち、SN=iのRTPパケットの表示時間が経過した際に、次に表示すべきデータが受信されていないことを意味しており、このとき、データ損失判定部1004は、再送要求判定部1018に対して、受信されているべきRTPパケットが受信されていない旨を報告する。

0116

かくして、この報告を受けた再送要求判定部1018は、ステップST9014において、このとき受信されていなければならないにも関わらず未だ受信されていないSN=i+1のRTPパケットについての再送要求を送信する。

0117

一方、データ損失判定部1004は、ステップST9013においてSN=i+1が受信されていない結果を得、これを再送要求判定部1018に報告した後、ステップST9015に移って、このとき再送要求判定部1018によって再送要求が行われたSN=i+1のRTPパケットに続く、SN=i+2のRTPパケットが受信されたか否か、または、現在時刻tと、SN=iのRTPパケットの再生開始時刻tiにその再生時間DUR(i)及びSN=i+1の再生時間NDUR(i)を加算した時刻とを比較し、現在時刻tの方が大きいか否かを判断する。

0118

ここで、否定結果が得られると、このことは、SN=i+2のRTPパケットを受信すべき時刻に達していないことを意味しており、このとき、データ損失判定部1004は、上述のステップST9013に戻って、ステップST9013〜ステップST9015の処理を繰り返す。これにより、SN=i+2のRTPパケットが受信されるべき時刻になるまでの間は、そのRTPパケットの前に受信されるべきSN=i+1のRTPパケットについて、受信されたか否かの判断、及び受信されていない場合のそのRTPパケットの再送要求を繰り返す。

0119

これに対して、ステップST9015において肯定結果が得られると、このことは、SN=i+2のRTPパケットを受信すべき時刻に達したか、又は実際にそのRTPパケットを受信したことを意味しており、このときデータ損失判定部1004は、ステップST9016に移って、iを1増分した後、ステップST9017に移って、さらにiを1増分する。

0120

このように、ステップST9015において肯定結果が得られると、データ損失判定部1004は、ステップST9016及びステップST9017においてiの増分処理を行うことにより、iは合計2増分された後、上述のステップST9011の処理に戻り、以下、上述した場合と同様の処理を繰り返す。

0121

かくして、図17に示した受信処理手順によれば、再送要求を行う際に、RTPパケットの受信を待つことなく、RTPパケットの再生時間を基に再送要求するか否かを判定することにより、再送要求を送信するまでの時間を短縮することができる。また、連続して2つのRTPパケットがロスした場合であっても、最近に受信したRTPパケットに含まれる次期再生時間(NDUR)を用いて、適切に再送要求を行うことができる。

0122

このように本実施の形態のデータ受信装置によれば、RTPパケットの受信を待つことなく、RTPパケットの再生時間に基づいて再送要求を行うか否かを判断することにより、パケットロスの検出に要する時間を短縮することができる。

発明を実施するための最良の形態

0123

なお、上述の実施の形態においては、静的メディアデータとしてテキストデータを伝送する場合について述べたが、本発明ではこれに限られるものではなく、静止画データやCG等の静的メディアデータ、若しくはJAVA(R)言語又はXML言語等によるプログラムデータ等のデータを伝送する場合において広く適用することができる。この場合、テキストデータに代えて静止画データ、静的メディアデータ又はプログラムデータを用いるようにすればよい。

図面の簡単な説明

0124

以上説明したように、本発明によれば、静的メディア伝送データが伝送エラー等の理由により損失した場合であっても、代替静的メディアを正確な再生時間で表示することができる。また、本発明によれば、パケットロスの検出に要する時間を短縮することが可能となる。

図1
本発明のデータ受信装置の構成を示すブロック図
図2
本発明のRTPパケットのデータ構造を示す略線図
図3
本発明のデータ表示方法のテキスト表示例を示す略線図
図4
本発明のデータ表示方法の伝送誤りが発生した場合のテキスト表示例を示す略線図
図5
本発明のデータ表示方法の動作を説明するためのフローチャート
図6
本発明のデータ送信方法のテキストデータ格納例を示す略線図
図7
本発明のデータ送信方法のテキストデータ格納例を示す略線図
図8
本発明のデータ送信方法のテキストデータ格納例を示す略線図
図9
本発明のデータ表示方法の複数テキストを格納する場合のテキスト表示例を示す略線図
図10
本発明のデータ表示方法の伝送誤りが発生した場合のテキスト表示例を示す略線図
図11
本発明のデータ送信装置の構成を示すブロック図
図12
本発明の実施の形態2に係るPESパケットのデータ構造を示す略線図
図13
本発明の実施の形態3に係るデータ受信装置の構成を示すブロック図
図14
本発明のデータ構造を示す略線図
図15
データ受信装置の表示動作を示す略線図
図16
データ受信装置の表示動作を示す略線図
図17
データ受信装置の受信処理手順を示すフローチャート
図18
3GPPで規定されるTimed Text のデータ構造を示す略線図
図19
Timed Textのデータ構造の略線図
【符号の説明】
1001データ受信部
1002 テキスト表示時間抽出部
1003拡張ヘッダ記憶部
1004データ損失判定部
1005テキスト抽出・記憶部
1006 テキスト修飾判定部
1007代替テキスト記憶部
1008 テキスト表示時間決定部
1009表示テキスト決定部
1010 テキスト表示部
1017タイマー
1018再送要求判定部
1019再送要求パケット生成部
2001テキスト情報記憶部
2002ヘッダ生成部
2003次期テキストデータ情報生成部
2004ペイロード生成部
2005送信データ合成部
2006データ送信部
8001RTPヘッダ
8002RTPペイロード
8003 拡張ヘッダ
8004テキストフレーム長
8005インデックス
8006 再生時間(デュレーション
8007テキスト長
8008 テキスト
8009修飾子
8101、8102、8103 テキストフレーム
8201 次期テキストフレームサンプル数
8202、8204、8206 次期テキストフレーム再生時間
8203、8205、8207 次期テキストフレームテキスト長
8212 再生時間(デュレーション)
8213 テキスト長

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ