JP2003023413A - システムデコーダ装置及びパケットデータの修正方法 - Google Patents
システムデコーダ装置及びパケットデータの修正方法Info
- Publication number
- JP2003023413A JP2003023413A JP2001208680A JP2001208680A JP2003023413A JP 2003023413 A JP2003023413 A JP 2003023413A JP 2001208680 A JP2001208680 A JP 2001208680A JP 2001208680 A JP2001208680 A JP 2001208680A JP 2003023413 A JP2003023413 A JP 2003023413A
- Authority
- JP
- Japan
- Prior art keywords
- data
- packet
- error
- decoder
- video
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims description 117
- 230000005540 biological transmission Effects 0.000 claims abstract description 47
- 238000001514 detection method Methods 0.000 claims description 110
- 238000012545 processing Methods 0.000 claims description 103
- 238000012937 correction Methods 0.000 claims description 52
- 230000008569 process Effects 0.000 claims description 52
- 238000004891 communication Methods 0.000 abstract description 26
- 230000015654 memory Effects 0.000 description 48
- 239000003550 marker Substances 0.000 description 42
- 230000004044 response Effects 0.000 description 26
- 238000012790 confirmation Methods 0.000 description 24
- 238000010586 diagram Methods 0.000 description 20
- 238000004458 analytical method Methods 0.000 description 15
- 230000006870 function Effects 0.000 description 11
- 238000013139 quantization Methods 0.000 description 9
- 230000007246 mechanism Effects 0.000 description 7
- 230000008859 change Effects 0.000 description 3
- 230000002457 bidirectional effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 101100321669 Fagopyrum esculentum FA02 gene Proteins 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000010561 standard procedure Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
- 230000002194 synthesizing effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
- H04L1/0079—Formats for control data
- H04L1/0082—Formats for control data fields explicitly indicating existence of error in data being transmitted, e.g. so that downstream stations can avoid decoding erroneous packet; relays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0045—Arrangements at the receiver end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1835—Buffer management
- H04L1/1838—Buffer management for semi-reliable protocols, e.g. for less sensitive applications such as streaming video
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
- H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
- H04N19/89—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving methods or arrangements for detection of transmission errors at the decoder
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
- H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
- H04N21/4382—Demodulation or channel decoding, e.g. QPSK demodulation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/64322—IP
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
(57)【要約】
【課題】 ディジタルメディアデータの無線通信伝送中
にパケットロスが発生した場合に、アプリケーションデ
コーダに渡されるメディアデータは、ロスが発生したパ
ケットのペイロードを省略した形式となり、伝送誤りの
正確な位置を検出することができない。 【解決手段】 受信データのパケットロス部分に、アプ
リケーションデコーダが明示的に通信エラーが発生した
と判定できるアプリケーションデコーダの仕様・規格に
含まれないデータ列をシステムデコーダにて埋め込むこ
とにより、アプリケーションデコーダが、伝送誤りの正
確な位置を検出することを可能とする。また、埋め込む
データ列をシステムデコーダとアプリケーションデコー
ダの間で予め決めておくことにより、より正確な誤り位
置検出が可能となる。
にパケットロスが発生した場合に、アプリケーションデ
コーダに渡されるメディアデータは、ロスが発生したパ
ケットのペイロードを省略した形式となり、伝送誤りの
正確な位置を検出することができない。 【解決手段】 受信データのパケットロス部分に、アプ
リケーションデコーダが明示的に通信エラーが発生した
と判定できるアプリケーションデコーダの仕様・規格に
含まれないデータ列をシステムデコーダにて埋め込むこ
とにより、アプリケーションデコーダが、伝送誤りの正
確な位置を検出することを可能とする。また、埋め込む
データ列をシステムデコーダとアプリケーションデコー
ダの間で予め決めておくことにより、より正確な誤り位
置検出が可能となる。
Description
【０００１】
【発明の属する技術分野】本発明は、ディジタルメディ
アデータの無線通信動画像符号化技術に関するものであ
り、特に、パケットロスが生じた場合の受信データ処理
に関するものである。
アデータの無線通信動画像符号化技術に関するものであ
り、特に、パケットロスが生じた場合の受信データ処理
に関するものである。
【０００２】
【従来の技術】次世代無線通信サービスとして、データ
圧縮され、配信サーバに蓄積されているディジタルメデ
ィアデータファイルを、携帯電話のような無線携帯端末
にて受信・再生することが想定されている。このような
無線通信サービスで、パケットロス（伝送中のパケット
データの損失）が生じた時の通信の形態としては、以下
の２点が想定されている。 1) 損失したパケット(データの単位、データのかたまり
の総称)の再送を行わないコネクションレス型のトラン
スポート層プロトコル(例えば、UDP: User Datagram Pr
otocol, RTP: Realtime Transport Protocol)を使用
し、データを受信しながら再生するストリーミング、 2) 損失したパケットの再送を可能とするコネクション
型のトランスポート層プロトコル(例えば、TCP: Transm
ission Control Protocol、全てのメッセージに対し
て、エラー検出や応答確認処理を行うため、信頼性を要
求するアプリケーションに適している。但し、伝送路の
状態が悪いと、頻繁な確認応答や再送要求により、スル
ープット低下が起こりやすい)を使用し、全データを受
信し、一旦蓄積してから再生処理を開始するダウンロー
ド。(UDP, RTP, TCPの詳細は後述する)ここで、トラン
スポート層とは、異機種間通信を可能にするネットワー
クアーキテクチャの標準参照モデル(OSI: Open Systems
Interconnection, 開放型システム相互接続、通信回線
に近いところから物理層-データリンク層-ネットワーク
層-トランスポート層)において、「データを確実に相手
に届ける」役割を果たすレベルのこと。「アドレスの管
理や経路の選択を行う」役割を果たすIP(InternetProto
col)はネットワーク層にあたる。上記２通りのサービス
形態のうち、ダウンロードでは、データ損失を伴う全て
のパケットに対して再送要求をかけるため、受信データ
に伝送エラーが含まれることはない。一方、ストリーミ
ングサービスでは、データ損失を伴うパケットが存在し
ても再送されないため、受信データに伝送エラーが含ま
れる可能性がある。
圧縮され、配信サーバに蓄積されているディジタルメデ
ィアデータファイルを、携帯電話のような無線携帯端末
にて受信・再生することが想定されている。このような
無線通信サービスで、パケットロス（伝送中のパケット
データの損失）が生じた時の通信の形態としては、以下
の２点が想定されている。 1) 損失したパケット(データの単位、データのかたまり
の総称)の再送を行わないコネクションレス型のトラン
スポート層プロトコル(例えば、UDP: User Datagram Pr
otocol, RTP: Realtime Transport Protocol)を使用
し、データを受信しながら再生するストリーミング、 2) 損失したパケットの再送を可能とするコネクション
型のトランスポート層プロトコル(例えば、TCP: Transm
ission Control Protocol、全てのメッセージに対し
て、エラー検出や応答確認処理を行うため、信頼性を要
求するアプリケーションに適している。但し、伝送路の
状態が悪いと、頻繁な確認応答や再送要求により、スル
ープット低下が起こりやすい)を使用し、全データを受
信し、一旦蓄積してから再生処理を開始するダウンロー
ド。(UDP, RTP, TCPの詳細は後述する)ここで、トラン
スポート層とは、異機種間通信を可能にするネットワー
クアーキテクチャの標準参照モデル(OSI: Open Systems
Interconnection, 開放型システム相互接続、通信回線
に近いところから物理層-データリンク層-ネットワーク
層-トランスポート層)において、「データを確実に相手
に届ける」役割を果たすレベルのこと。「アドレスの管
理や経路の選択を行う」役割を果たすIP(InternetProto
col)はネットワーク層にあたる。上記２通りのサービス
形態のうち、ダウンロードでは、データ損失を伴う全て
のパケットに対して再送要求をかけるため、受信データ
に伝送エラーが含まれることはない。一方、ストリーミ
ングサービスでは、データ損失を伴うパケットが存在し
ても再送されないため、受信データに伝送エラーが含ま
れる可能性がある。
【０００３】ここで、具体的な事例を示す。図２は携帯
電話のシステム構成を示す図であり、図３は、送信され
るパケットを表したものである。この携帯電話端末２０
０に向けて、図３に示すトランスポート層のパケット列
(１種類のメディアデータ)が送信された場合を考える。
TCP、UDP-RTPに関わらずトランスポート層の１パケット
は、トランスポート層のヘッダ部（４１１，４２１，４
３１，４４１，４５１）とペイロード部（４１２，４２
２，４３２，４４２，４５２）にて構成されている。こ
の例では、ペイロード部は実際のメディアデータであ
る。ヘッダ部には、ペイロード部のデータ量 (バイト単
位)、パケットの通し番号(シーケンス番号)、ペイロー
ドタイプ(RTPの場合のみ、TCPでは１度に複数タイプの
データを扱うことはない。ビデオデータ、オーディオデ
ータの識別をこのデータにて行う)ならびにタイムスタ
ンプ(RTPの場合のみ)等が書かれている。まず、アンテ
ナ２０１から受信した無線信号は、無線インタフェース
部２０２にて電気的に変換され、データリンク層プロト
コルのパケット２０３の形式でシステムデコーダ２０５
に入力される。システムデコーダ２０５では、入力され
たデータリンク層プロトコルのパケットがネットワーク
層のパケット、トランスポート層のパケットへと順にプ
ロトコル変換され、トランスポート層のペイロード部だ
けがメモリ２０７に出力される。また、システムデコー
ダでは、パケット内のエラー検出処理や、各パケットに
おけるペイロードタイプの識別(RTPの場合のみ)等も行
う。更に、異なるペイロードタイプのメディアデータが
同時に配信されている場合には、ペイロードタイプ別に
メディアデータを構成し、共に互いに同期を取りながら
メモリ２０７に出力される。
電話のシステム構成を示す図であり、図３は、送信され
るパケットを表したものである。この携帯電話端末２０
０に向けて、図３に示すトランスポート層のパケット列
(１種類のメディアデータ)が送信された場合を考える。
TCP、UDP-RTPに関わらずトランスポート層の１パケット
は、トランスポート層のヘッダ部（４１１，４２１，４
３１，４４１，４５１）とペイロード部（４１２，４２
２，４３２，４４２，４５２）にて構成されている。こ
の例では、ペイロード部は実際のメディアデータであ
る。ヘッダ部には、ペイロード部のデータ量 (バイト単
位)、パケットの通し番号(シーケンス番号)、ペイロー
ドタイプ(RTPの場合のみ、TCPでは１度に複数タイプの
データを扱うことはない。ビデオデータ、オーディオデ
ータの識別をこのデータにて行う)ならびにタイムスタ
ンプ(RTPの場合のみ)等が書かれている。まず、アンテ
ナ２０１から受信した無線信号は、無線インタフェース
部２０２にて電気的に変換され、データリンク層プロト
コルのパケット２０３の形式でシステムデコーダ２０５
に入力される。システムデコーダ２０５では、入力され
たデータリンク層プロトコルのパケットがネットワーク
層のパケット、トランスポート層のパケットへと順にプ
ロトコル変換され、トランスポート層のペイロード部だ
けがメモリ２０７に出力される。また、システムデコー
ダでは、パケット内のエラー検出処理や、各パケットに
おけるペイロードタイプの識別(RTPの場合のみ)等も行
う。更に、異なるペイロードタイプのメディアデータが
同時に配信されている場合には、ペイロードタイプ別に
メディアデータを構成し、共に互いに同期を取りながら
メモリ２０７に出力される。
【０００４】トランスポート層のプロトコルがTCPであ
る場合には、システムデコーダは、エラーなく到達した
各パケットについて、応答確認情報２０４を無線インタ
フェース部２０２に返答する。これらの応答確認情報
は、無線インタフェース部２０２にて無線信号に変換さ
れ、送信側に返信される。送信側では、送信したパケッ
トの応答確認を待ってから次のパケットの送信処理を行
うが(複数のパケットを並列に処理することも可能)、送
信から一定時間が経過しても応答確認が到達しない場合
には、そのパケットを携帯電話端末２００に再送する。
そのため、TCPではパケットロスは発生せず、図４の２
０６０に示されるようなペイロード部のみから成るデー
タがペイロードデータ２０６としてメモリ２０７に出力
される。ここで言うペイロードデータとは、一般的に、
ダウンロードの場合には、画像・音声等をまとめたファ
イルフォーマットのデータとなり、具体的には、MPEG-4
のMP4ファイルフォーマット、アップル社のQuick Tim
e、Microsoft社のWMT(Windows Media Technology)など
がある。
る場合には、システムデコーダは、エラーなく到達した
各パケットについて、応答確認情報２０４を無線インタ
フェース部２０２に返答する。これらの応答確認情報
は、無線インタフェース部２０２にて無線信号に変換さ
れ、送信側に返信される。送信側では、送信したパケッ
トの応答確認を待ってから次のパケットの送信処理を行
うが(複数のパケットを並列に処理することも可能)、送
信から一定時間が経過しても応答確認が到達しない場合
には、そのパケットを携帯電話端末２００に再送する。
そのため、TCPではパケットロスは発生せず、図４の２
０６０に示されるようなペイロード部のみから成るデー
タがペイロードデータ２０６としてメモリ２０７に出力
される。ここで言うペイロードデータとは、一般的に、
ダウンロードの場合には、画像・音声等をまとめたファ
イルフォーマットのデータとなり、具体的には、MPEG-4
のMP4ファイルフォーマット、アップル社のQuick Tim
e、Microsoft社のWMT(Windows Media Technology)など
がある。
【０００５】トランスポート層のプロトコルがUDP-RTP
である場合には、システムデコーダは、応答確認を行わ
ないため、パケットロスは許容される。例えば、図３の
第２パケット(421及び422)がシステムデコーダに到着し
なかった場合、あるいは第２パケットに伝送エラーが含
まれている場合には、図５の２０６１に示されるような
第２パケットを除いたペイロード部のみから成るデータ
がペイロードデータ２０６としてメモリ２０７に出力さ
れる。ここで言うペイロードデータとは、ストリーミン
グの場合には、一般にビデオ符号化データのパケットと
オーディオ符号化データのパケットが混成されたデータ
となる。このように複数のメディアデータ(例えば、ビ
デオデータとオーディオデータ)が同時に配信されてお
り、同時に再生する必要がある場合には、システムデコ
ーダ２０５にて、RTPパケットのヘッダ部に含まれてい
るペイロードタイプによって各パケットが関連するメデ
ィアデコーダ(例えば、ビデオデコーダ、オーディオデ
コーダ)の種類が解読され、異なる種類のメディアデー
タとしてメモリ２０７に出力する必要がある。その後、
メモリ２０７に蓄積されたデータは、ストリーミングの
場合には順次、最終パケットが到達した時点でメディア
データ２０８としてアプリケーションデコーダ２０９に
出力される。なお、本明細書では、アプリケーションデ
コーダ２０９を、ファイルフォーマットのファイルデコ
ーダならびに、ビデオデコーダ、オーディオデコーダな
どのメディアデコーダの総称とし、アプリケーションデ
コーダと示した場合には、内部の構成は限定しないこと
にする。アプリケーションデコーダでは、ロスパケット
の誤り隠蔽処理を行いつつ、タイミングをはかって各メ
ディアデータの復元・再生処理を行う。但し、メディア
デコーダに含まれる誤り隠蔽処理は標準化されていない
ため、メディアデータ２０８にパケットロスが含まれる
場合の再生画像の画質や音声品質は、誤り隠蔽処理の性
能によって異なることになる。
である場合には、システムデコーダは、応答確認を行わ
ないため、パケットロスは許容される。例えば、図３の
第２パケット(421及び422)がシステムデコーダに到着し
なかった場合、あるいは第２パケットに伝送エラーが含
まれている場合には、図５の２０６１に示されるような
第２パケットを除いたペイロード部のみから成るデータ
がペイロードデータ２０６としてメモリ２０７に出力さ
れる。ここで言うペイロードデータとは、ストリーミン
グの場合には、一般にビデオ符号化データのパケットと
オーディオ符号化データのパケットが混成されたデータ
となる。このように複数のメディアデータ(例えば、ビ
デオデータとオーディオデータ)が同時に配信されてお
り、同時に再生する必要がある場合には、システムデコ
ーダ２０５にて、RTPパケットのヘッダ部に含まれてい
るペイロードタイプによって各パケットが関連するメデ
ィアデコーダ(例えば、ビデオデコーダ、オーディオデ
コーダ)の種類が解読され、異なる種類のメディアデー
タとしてメモリ２０７に出力する必要がある。その後、
メモリ２０７に蓄積されたデータは、ストリーミングの
場合には順次、最終パケットが到達した時点でメディア
データ２０８としてアプリケーションデコーダ２０９に
出力される。なお、本明細書では、アプリケーションデ
コーダ２０９を、ファイルフォーマットのファイルデコ
ーダならびに、ビデオデコーダ、オーディオデコーダな
どのメディアデコーダの総称とし、アプリケーションデ
コーダと示した場合には、内部の構成は限定しないこと
にする。アプリケーションデコーダでは、ロスパケット
の誤り隠蔽処理を行いつつ、タイミングをはかって各メ
ディアデータの復元・再生処理を行う。但し、メディア
デコーダに含まれる誤り隠蔽処理は標準化されていない
ため、メディアデータ２０８にパケットロスが含まれる
場合の再生画像の画質や音声品質は、誤り隠蔽処理の性
能によって異なることになる。
【０００６】
【発明が解決しようとする課題】伝送中にパケットロス
が発生した場合、アプリケーションデコーダに渡される
メディアデータは、ロスが発生したパケットのペイロー
ドを省略した形式となる。一般にアプリケーションデコ
ーダでは、適用標準デコード方式に含まれないデータの
組み合わせを入力データ内に発見したときに伝送誤りが
発生していると判断する。そのため、ロスしたパケット
の前後のパケットを結合したデータが適用標準デコード
方式に含まれる組み合わせとなっていた場合、伝送誤り
の正確な位置を検出することができない。
が発生した場合、アプリケーションデコーダに渡される
メディアデータは、ロスが発生したパケットのペイロー
ドを省略した形式となる。一般にアプリケーションデコ
ーダでは、適用標準デコード方式に含まれないデータの
組み合わせを入力データ内に発見したときに伝送誤りが
発生していると判断する。そのため、ロスしたパケット
の前後のパケットを結合したデータが適用標準デコード
方式に含まれる組み合わせとなっていた場合、伝送誤り
の正確な位置を検出することができない。
【０００７】また、パケットロスを含むデータを高画質
で再現するためには、アプリケーションデコーダが伝送
誤りを検出し、エラーの影響が画質に現れないように制
御する必要がある。このような誤り訂正処理はデコーダ
の処理量を増加させるため、製品価格や消費電力の関係
で高速なプロセッサを使用できないアプリケーションで
は、再生処理速度や画像サイズの面で要求を十分に満た
せないことになる。
で再現するためには、アプリケーションデコーダが伝送
誤りを検出し、エラーの影響が画質に現れないように制
御する必要がある。このような誤り訂正処理はデコーダ
の処理量を増加させるため、製品価格や消費電力の関係
で高速なプロセッサを使用できないアプリケーションで
は、再生処理速度や画像サイズの面で要求を十分に満た
せないことになる。
【０００８】
【課題を解決するための手段】受信データのパケットロ
ス部分に、アプリケーションデコーダが明示的に通信エ
ラーが発生したと判定できるデータ列をシステムデコー
ダにて埋め込む。具体的には、アプリケーションデコー
ダの仕様・規格に含まれないデータ列を埋め込みデータ
として利用する。これにより、アプリケーションデコー
ダは、伝送誤りの正確な位置を検出することが可能とな
る。また、埋め込むデータ列をシステムデコーダとアプ
リケーションデコーダの間で予め決めておくことによ
り、より正確な誤り位置検出が可能となる。さらに、こ
のエラー検出用埋め込みデータを利用して、誤りを含ん
だメディアデータをアプリケーションデコーダの仕様・
規格に準拠したデータに変換することで、アプリケーシ
ョンデコーダにおける誤り訂正処理の負担を軽減するこ
とが可能となる。
ス部分に、アプリケーションデコーダが明示的に通信エ
ラーが発生したと判定できるデータ列をシステムデコー
ダにて埋め込む。具体的には、アプリケーションデコー
ダの仕様・規格に含まれないデータ列を埋め込みデータ
として利用する。これにより、アプリケーションデコー
ダは、伝送誤りの正確な位置を検出することが可能とな
る。また、埋め込むデータ列をシステムデコーダとアプ
リケーションデコーダの間で予め決めておくことによ
り、より正確な誤り位置検出が可能となる。さらに、こ
のエラー検出用埋め込みデータを利用して、誤りを含ん
だメディアデータをアプリケーションデコーダの仕様・
規格に準拠したデータに変換することで、アプリケーシ
ョンデコーダにおける誤り訂正処理の負担を軽減するこ
とが可能となる。
【０００９】
【発明の実施の形態】まず、図２、図３８、図３９、図
６ならびに図７にて、パケットロスの発生を検出する仕
組みを考える。図６は、図２に示すシステムデコーダ２
０５の内部構成を示したものである。入力されたパケッ
トデータは、まず、パケット処理部３０１にてトランス
ポート層のパケットとへ変換される。トランスポート層
のプロトコルがUDP-RTPの場合には、各UDPパケットのヘ
ッダ部に含まれているエラー検出情報を解析し、受信パ
ケットがエラーを含んでいる場合には、パケット処理部
３０１にてそのパケットを破棄する。RTPパケットは、U
DPパケットのペイロード部にあたり、ペイロードデータ
と、シーケンス番号ならびにペイロードタイプ情報を含
むRTPヘッダにて構成されている。そのため、後に送信
されたパケットが先に受信側に到着した場合でも、シス
テムデコーダのメディアデータ再構成部３０８にて送信
された順序に入れ替えることが可能となる。そこで、受
信したUDPパケットがエラーを含んでいない場合には、R
TPパケットを解析し、ペイロードデータ３０７と、タイ
ムスタンプ・シーケンス番号・ペイロードタイプ８０１
をメディアデータ再構成部３０８に出力する。この際、
タイムスタンプ・シーケンス番号・ペイロードタイプ８
０１をパケットロス検出部８０２にも出力する。これに
より、パケットロス検出部８０２では、シーケンス番号
とペイロードタイプを解析することで、到着していない
パケットデータならびに伝送エラーを伴うパケットデー
タをペイロードタイプ別に検出することが可能となる。
具体的には、メディアデータ再構成部３０８から出力す
べきタイミングになっても、シーケンス番号とペイロー
ドタイプがパケットロス検出部８０２に届いていないパ
ケットを、ロスパケットであると判定する。なお、ペイ
ロードデータ３０７と、タイムスタンプ・シーケンス番
号・ペイロードタイプ８０１を受け取ったメディアデー
タ再構成部３０８では、各RTPパケットのシーケンス番
号とペイロードタイプに従って、ペイロードタイプ毎に
パケット列の順序の入れ替える操作を行う。例えば、図
７の(a)のように、「あるペイロードタイプにおける２
番目のパケット（４２１と４２２）が未着信」で、「通
信に使用したネットワークの状況により、そのペイロー
ドタイプのパケットが、第１パケット、第４パケット、
第５パケット，第３パケットの順序で携帯端末側に着信
した」場合を想定する。この場合、パケット処理部３０
１は、到着したパケットを到着順（４１１と４１２，４
４１と４４２，４５１と４５２，４３１と４３２）に処
理し、図７の(b)に示すように４１２，４４２，４５
２，４３２からなるペイロードデータ列３０７とRTPヘ
ッダ部のタイムスタンプ・シーケンス番号・ペイロード
タイプ列８０１(図中では、シーケンス番号のみを表示
している)に分けてメディアデータ再構成部３０８に対
して出力する。メディアデータ再構成部３０８では、各
RTPパケットのシーケンス番号ならびにペイロードタイ
プに従って、ペイロードタイプ毎にパケット列の順序の
入れ替える操作を行う。図７の例では、図５に示すよう
なペイロードデータ２０６１が、システムデコーダとア
プリケーションとのインタフェースの役割を果たすメデ
ィアデータ出力部３１０を通してメモリ２０７に出力さ
れる。メディアデータ再構成部３０８がメディアデータ
出力部３１０に各ペイロードデータを出力するタイミン
グは、一般に各RTPパケットに含まれるタイムスタンプ
によって管理されるが、アプリケーションデコーダの再
生状況を考慮しながら制御することも可能である。図３
８は携帯電話端末の別の実施例を示す図で、２種類のメ
ディアデータ(ビデオデータとオーディオデータ)がRTP
にてストリーミング配信された場合について示してい
る。図３８では、図２に示した携帯電話端末２００と、
システムデコーダからアプリケーションデコーダへのデ
ータの流れの点で異なる。この場合には、RTPパケット
ヘッダ部のペイロードタイプは、ビデオデータあるいは
オーディオデータを示している。システムデコーダ２０
５１は受信した各RTPパケットのヘッダ部に記載されて
いるペイロードタイプとシーケンス番号を調査し、ビデ
オデータとオーディオデータに分け、それぞれシーケン
ス番号順にペイロードデータ２０６１をメモリ２０７１
に出力する。この際の各ペイロードの出力タイミング
は、RTPパケットヘッダ部のタイムスタンプを参考に、
再生時にビデオとオーディオ間で互いに同期が取れるよ
うに決められる。メモリ２０７１に蓄積された各メディ
アデータ２０８１は、それぞれ再生単位のデータ量に達
した時点で、アプリケーションデコーダ２０９１内のビ
デオデコーダならびにオーディオデコーダに入力され、
再生処理される。
６ならびに図７にて、パケットロスの発生を検出する仕
組みを考える。図６は、図２に示すシステムデコーダ２
０５の内部構成を示したものである。入力されたパケッ
トデータは、まず、パケット処理部３０１にてトランス
ポート層のパケットとへ変換される。トランスポート層
のプロトコルがUDP-RTPの場合には、各UDPパケットのヘ
ッダ部に含まれているエラー検出情報を解析し、受信パ
ケットがエラーを含んでいる場合には、パケット処理部
３０１にてそのパケットを破棄する。RTPパケットは、U
DPパケットのペイロード部にあたり、ペイロードデータ
と、シーケンス番号ならびにペイロードタイプ情報を含
むRTPヘッダにて構成されている。そのため、後に送信
されたパケットが先に受信側に到着した場合でも、シス
テムデコーダのメディアデータ再構成部３０８にて送信
された順序に入れ替えることが可能となる。そこで、受
信したUDPパケットがエラーを含んでいない場合には、R
TPパケットを解析し、ペイロードデータ３０７と、タイ
ムスタンプ・シーケンス番号・ペイロードタイプ８０１
をメディアデータ再構成部３０８に出力する。この際、
タイムスタンプ・シーケンス番号・ペイロードタイプ８
０１をパケットロス検出部８０２にも出力する。これに
より、パケットロス検出部８０２では、シーケンス番号
とペイロードタイプを解析することで、到着していない
パケットデータならびに伝送エラーを伴うパケットデー
タをペイロードタイプ別に検出することが可能となる。
具体的には、メディアデータ再構成部３０８から出力す
べきタイミングになっても、シーケンス番号とペイロー
ドタイプがパケットロス検出部８０２に届いていないパ
ケットを、ロスパケットであると判定する。なお、ペイ
ロードデータ３０７と、タイムスタンプ・シーケンス番
号・ペイロードタイプ８０１を受け取ったメディアデー
タ再構成部３０８では、各RTPパケットのシーケンス番
号とペイロードタイプに従って、ペイロードタイプ毎に
パケット列の順序の入れ替える操作を行う。例えば、図
７の(a)のように、「あるペイロードタイプにおける２
番目のパケット（４２１と４２２）が未着信」で、「通
信に使用したネットワークの状況により、そのペイロー
ドタイプのパケットが、第１パケット、第４パケット、
第５パケット，第３パケットの順序で携帯端末側に着信
した」場合を想定する。この場合、パケット処理部３０
１は、到着したパケットを到着順（４１１と４１２，４
４１と４４２，４５１と４５２，４３１と４３２）に処
理し、図７の(b)に示すように４１２，４４２，４５
２，４３２からなるペイロードデータ列３０７とRTPヘ
ッダ部のタイムスタンプ・シーケンス番号・ペイロード
タイプ列８０１(図中では、シーケンス番号のみを表示
している)に分けてメディアデータ再構成部３０８に対
して出力する。メディアデータ再構成部３０８では、各
RTPパケットのシーケンス番号ならびにペイロードタイ
プに従って、ペイロードタイプ毎にパケット列の順序の
入れ替える操作を行う。図７の例では、図５に示すよう
なペイロードデータ２０６１が、システムデコーダとア
プリケーションとのインタフェースの役割を果たすメデ
ィアデータ出力部３１０を通してメモリ２０７に出力さ
れる。メディアデータ再構成部３０８がメディアデータ
出力部３１０に各ペイロードデータを出力するタイミン
グは、一般に各RTPパケットに含まれるタイムスタンプ
によって管理されるが、アプリケーションデコーダの再
生状況を考慮しながら制御することも可能である。図３
８は携帯電話端末の別の実施例を示す図で、２種類のメ
ディアデータ(ビデオデータとオーディオデータ)がRTP
にてストリーミング配信された場合について示してい
る。図３８では、図２に示した携帯電話端末２００と、
システムデコーダからアプリケーションデコーダへのデ
ータの流れの点で異なる。この場合には、RTPパケット
ヘッダ部のペイロードタイプは、ビデオデータあるいは
オーディオデータを示している。システムデコーダ２０
５１は受信した各RTPパケットのヘッダ部に記載されて
いるペイロードタイプとシーケンス番号を調査し、ビデ
オデータとオーディオデータに分け、それぞれシーケン
ス番号順にペイロードデータ２０６１をメモリ２０７１
に出力する。この際の各ペイロードの出力タイミング
は、RTPパケットヘッダ部のタイムスタンプを参考に、
再生時にビデオとオーディオ間で互いに同期が取れるよ
うに決められる。メモリ２０７１に蓄積された各メディ
アデータ２０８１は、それぞれ再生単位のデータ量に達
した時点で、アプリケーションデコーダ２０９１内のビ
デオデコーダならびにオーディオデコーダに入力され、
再生処理される。
【００１０】一方、トランスポート層のプロトコルがTC
Pである場合には、各TCPパケットのヘッダ部に含まれて
いるエラー検出情報を解析し、エラー検出結果３０２を
再送判定部３０４に渡す。その際、受信パケットがエラ
ーを含んでいる場合には、そのパケットを破棄する。再
送判定部３０４では、エラー検出結果３０２が「エラー
なし」を示している場合には、応答確認情報３０５を応
答確認部３０６に通知する。この応答確認情報３０５
は、応答確認部３０６にて無線信号２０４に変換され、
無線インタフェース部２０２を通して送信側に通知され
る。送信側では、送信から一定時間が経過しても応答確
認が到達しないパケットを携帯電話端末２００に再送す
る。プロトコルがTCPである場合には、送信側のパケッ
ト送信は応答確認の到着状況を考慮して行われており、
基本的に不正なパケットは発生しない。しかしながら、
最近では、ダウンロードの信頼性とストリーミングのリ
アルタイム性の中間にあたる性能を持つサービスとし
て、擬似ストリーミングも提案されている。この擬似ス
トリーミングは、「ダウンロードと同様に信頼性の高い
コネクション型のトランスポート層プロトコルを使用す
るが、メディアデータを数個のファイルに分けて送信す
ることにより、再生に必要な全データの受信を待たずに
受信したファイル内のメディアデータから適宜再生す
る」というものである。ダウンロードは、通信の信頼性
は高いが、ファイルが完全に受信し終わるまで再生処理
を開始することができない。そのため、携帯電話のよう
に大きなメモリを組み込めない端末では、再生時間の長
いメディアデータは受信できないという問題がある。そ
こで、送信側にて、予めメディアデータを分割してお
き、到着したファイルから再生処理を行うことで、処理
が終わったファイルをメモリから削除していくという方
法が有効と成る。しかしながら、無線通信にて擬似スト
リーミングを行う場合には、パケットの再送が頻繁に発
生すると、あるファイルの再生が終了しても、次のファ
イルが到着せず、再生を一時停止しなければならないと
いう問題が発生する。そこで、擬似ストリーミングで
は、TCPのように送信側とのコネクションを持つ通信方
式であっても、ある程度のパケットエラーを許容する仕
組みを取り入れる必要が生じてくる。なお、このパケッ
トエラーを許容する方法は、ユーザ指令からの遅延等を
考えた場合、ダウンロードであっても有効となる。
Pである場合には、各TCPパケットのヘッダ部に含まれて
いるエラー検出情報を解析し、エラー検出結果３０２を
再送判定部３０４に渡す。その際、受信パケットがエラ
ーを含んでいる場合には、そのパケットを破棄する。再
送判定部３０４では、エラー検出結果３０２が「エラー
なし」を示している場合には、応答確認情報３０５を応
答確認部３０６に通知する。この応答確認情報３０５
は、応答確認部３０６にて無線信号２０４に変換され、
無線インタフェース部２０２を通して送信側に通知され
る。送信側では、送信から一定時間が経過しても応答確
認が到達しないパケットを携帯電話端末２００に再送す
る。プロトコルがTCPである場合には、送信側のパケッ
ト送信は応答確認の到着状況を考慮して行われており、
基本的に不正なパケットは発生しない。しかしながら、
最近では、ダウンロードの信頼性とストリーミングのリ
アルタイム性の中間にあたる性能を持つサービスとし
て、擬似ストリーミングも提案されている。この擬似ス
トリーミングは、「ダウンロードと同様に信頼性の高い
コネクション型のトランスポート層プロトコルを使用す
るが、メディアデータを数個のファイルに分けて送信す
ることにより、再生に必要な全データの受信を待たずに
受信したファイル内のメディアデータから適宜再生す
る」というものである。ダウンロードは、通信の信頼性
は高いが、ファイルが完全に受信し終わるまで再生処理
を開始することができない。そのため、携帯電話のよう
に大きなメモリを組み込めない端末では、再生時間の長
いメディアデータは受信できないという問題がある。そ
こで、送信側にて、予めメディアデータを分割してお
き、到着したファイルから再生処理を行うことで、処理
が終わったファイルをメモリから削除していくという方
法が有効と成る。しかしながら、無線通信にて擬似スト
リーミングを行う場合には、パケットの再送が頻繁に発
生すると、あるファイルの再生が終了しても、次のファ
イルが到着せず、再生を一時停止しなければならないと
いう問題が発生する。そこで、擬似ストリーミングで
は、TCPのように送信側とのコネクションを持つ通信方
式であっても、ある程度のパケットエラーを許容する仕
組みを取り入れる必要が生じてくる。なお、このパケッ
トエラーを許容する方法は、ユーザ指令からの遅延等を
考えた場合、ダウンロードであっても有効となる。
【００１１】TCPにてパケットロスを許容する場合のパ
ケットロス検出方法は、パケットロスを許容する方法そ
のものである。パケットロスを許容するには、送信側あ
るいは端末側のいずれかで応答確認手順を制御すればよ
い。送信側で制御するには、一定時間が経過しても応答
確認が到達しない場合や再送回数が一定回数を超えた場
合などの条件で、応答確認の到達をあきらめることで実
現される。この場合、パケットロスの発生は、TCPパケ
ットヘッダ部のシーケンス番号列にて確認できる(TCPで
は、同時に応答確認を行うパケット数が端末側に通知さ
れるため、その条件より大きなシーケンス番号を持つパ
ケットが着信した時点でパケットロスの発生が判断でき
る)。しかし、この方法では端末側のアプリケーション
デコーダにおける再生処理の進行状況を応答確認手順の
制御に反映することができないため、各ファイルの処理
時間の推定値と実値と間にズレがあった場合には、再生
処理を一時停止せざるを得ない状況が生じる可能性があ
る。そこで、次に端末側で応答確認処理を制御する方法
について考える。具体的には、図６の再送判定部３０４
とパケットロス検出部８０２を利用する。パケット処理
部３０１は、各TCPパケットのヘッダ部に含まれている
エラー検出情報を解析し、エラー検出結果３０２を再送
判定部３０４に渡す。この際、受信パケットがエラーを
含んでいる場合には、そのパケットを破棄する。一方、
受信パケットがエラーを含んでいない場合には、TCPパ
ケットを解析し、ペイロードデータ３０７と、シーケン
ス番号８０１(TCPには、ペイロードタイプは存在しな
い)をメディアデータ再構成部３０８に出力する。同時
にシーケンス番号８０１をパケットロス検出部８０２に
出力する。これにより、パケットロス検出部８０２で
は、シーケンス番号を解析することで、受信していない
パケットを検出することが可能となる。具体的には、パ
ケット処理部３０１からシーケンス番号が届いていない
パケットを、受信していないパケットであると判定す
る。パケットロス検出部８０２では、前後のパケットが
受信された後、規定時間(システムデコーダにて制御)が
経過しても受信されないパケットをロスパケットとし、
そのシーケンス番号８０７を再送判定部３０４に通知す
る。再送判定部３０４では、ロスパケットの再送により
再生処理に支障があるか否かを判断する。そして再送を
待つと再生処理遅延の面で問題があると判断した場合に
は、応答確認情報３０５を応答確認部３０６に通知する
とともに、再送を行わないことを示す再送判定結果・シ
ーケンス番号３０３をパケットロス検出部８０２に返答
する。再送を待っても再生処理が滞りなく進行すると判
断できる場合には、再送を行うことを示す再送判定結果
・シーケンス番号３０３をパケットロス検出部８０２に
返答する。この返答結果から、パケットロス検出部８０
２は、メディアデータ再構成部３０８にて受信できてい
ないパケットが、再送待ちのパケット(再送を行うこと
を示す再送判定結果が通知されている)であるか、パケ
ットロスとして許容されたパケットであるか(再送を行
わないことを示す再送判定結果が通知されている)が判
断できる。そして、再送待ちのパケットについては、規
定時間(システムデコーダにて制御)経過しても受信しな
い場合には、再度、再送判定部３０４に、シーケンス番
号８０７を通知する。再送判定部３０４では、再送回数
も考慮に入れて、再送要求の可能性について判定を行
う。なお、再送判定部３０４がロスパケットと判定した
後で、受信したパケットについては、通常通り処理する
ことで情報の書き換えることも可能となる。このような
手順で、ペイロードデータ３０７とシーケンス番号を受
け取ったメディアデータ再構成部３０８では、各TCPパ
ケットのシーケンス番号に従って、受信パケットの出力
順序を入れ替える操作が行われる。入れ替え後、メディ
アデータ再構成部３０８がメディアデータ出力部３１０
にペイロードデータを出力するタイミングは、一般に、
一定の時間間隔で制御されるが、アプリケーションデコ
ーダの再生状況を考慮しながら制御することも可能であ
る。図３９は携帯電話端末のさらなる実施例を示す図
で、２種類のメディアデータ(ビデオデータとオーディ
オデータ)を１つのファイルに統合・蓄積したMP4ファイ
ルフォーマットデータがTCPにて擬似ストリーミング配
信された場合について示している。図３９では、図２に
示した携帯電話端末２００と、システムデコーダからア
プリケーションデコーダへのデータの流れが異なってい
る。システムデコーダ２０５２はTCPパケットヘッダ部
のシーケンス番号を調査し、シーケンス番号順にペイロ
ードデータ２０６２をメモリ２０７２に出力する。この
際の各ペイロードの出力タイミングは、アプリケーショ
ンデコーダにおけるメディアデータの処理状況を考慮し
て決める。また、システムデコーダにおけるロスパケッ
トの再送制御にもアプリケーションデコーダでの処理状
況を反映する。メモリ２０７２に蓄積されたメディアデ
ータ２０８２は、１つのファイルフォーマットデータと
して成立した時点で、アプリケーションデコーダ２０９
２内のファイルデコーダに入力される。ファイルデコー
ダでは、ファイルヘッダの情報からファイル内の各メデ
ィアデータ(ここでは、ビデオデータとオーディオデー
タが含まれていることを想定)を取りだし、それぞれビ
デオデコーダならびにオーディオデコーダに入力され
る。図４０に携帯電話端末の別の実施例を、図４１にシ
ステムデコーダの別の実施例を示し、アプリケーション
デコーダでの処理状況を考慮して、再送判定部３０４に
てロスパケットならびにエラーパケットの再送要求判定
を行うためのデータの流れを説明する。図４０に示した
データ２１０ならびに２１１が処理状況関連情報にあた
る。データ２１１としては、メモリ内の未処理データの
残量、データ２１０としては、再生遅延の発生状況、フ
レームレートならびにビットレートなどが含まれる。こ
れらのデータは、図４１の再送判定部３０４に送られ
る。再送判定部３０４では、データ２１１により得られ
るデータ残量と、データ２１０から得られるデータの消
費速度に関する情報、さらに再送パケットが到達するに
かかる時間の推定値(それまでのデータ到達状況から推
測する)、そのパケットの重要性(例えば、ファイルフォ
ーマットデータのヘッダ部やビデオデータのシーケンス
ヘッダ部を失うとデータ全体の再生が困難となる)等か
ら、パケット再送待ちがアプリケーションデコーダに与
える影響を推定する。
ケットロス検出方法は、パケットロスを許容する方法そ
のものである。パケットロスを許容するには、送信側あ
るいは端末側のいずれかで応答確認手順を制御すればよ
い。送信側で制御するには、一定時間が経過しても応答
確認が到達しない場合や再送回数が一定回数を超えた場
合などの条件で、応答確認の到達をあきらめることで実
現される。この場合、パケットロスの発生は、TCPパケ
ットヘッダ部のシーケンス番号列にて確認できる(TCPで
は、同時に応答確認を行うパケット数が端末側に通知さ
れるため、その条件より大きなシーケンス番号を持つパ
ケットが着信した時点でパケットロスの発生が判断でき
る)。しかし、この方法では端末側のアプリケーション
デコーダにおける再生処理の進行状況を応答確認手順の
制御に反映することができないため、各ファイルの処理
時間の推定値と実値と間にズレがあった場合には、再生
処理を一時停止せざるを得ない状況が生じる可能性があ
る。そこで、次に端末側で応答確認処理を制御する方法
について考える。具体的には、図６の再送判定部３０４
とパケットロス検出部８０２を利用する。パケット処理
部３０１は、各TCPパケットのヘッダ部に含まれている
エラー検出情報を解析し、エラー検出結果３０２を再送
判定部３０４に渡す。この際、受信パケットがエラーを
含んでいる場合には、そのパケットを破棄する。一方、
受信パケットがエラーを含んでいない場合には、TCPパ
ケットを解析し、ペイロードデータ３０７と、シーケン
ス番号８０１(TCPには、ペイロードタイプは存在しな
い)をメディアデータ再構成部３０８に出力する。同時
にシーケンス番号８０１をパケットロス検出部８０２に
出力する。これにより、パケットロス検出部８０２で
は、シーケンス番号を解析することで、受信していない
パケットを検出することが可能となる。具体的には、パ
ケット処理部３０１からシーケンス番号が届いていない
パケットを、受信していないパケットであると判定す
る。パケットロス検出部８０２では、前後のパケットが
受信された後、規定時間(システムデコーダにて制御)が
経過しても受信されないパケットをロスパケットとし、
そのシーケンス番号８０７を再送判定部３０４に通知す
る。再送判定部３０４では、ロスパケットの再送により
再生処理に支障があるか否かを判断する。そして再送を
待つと再生処理遅延の面で問題があると判断した場合に
は、応答確認情報３０５を応答確認部３０６に通知する
とともに、再送を行わないことを示す再送判定結果・シ
ーケンス番号３０３をパケットロス検出部８０２に返答
する。再送を待っても再生処理が滞りなく進行すると判
断できる場合には、再送を行うことを示す再送判定結果
・シーケンス番号３０３をパケットロス検出部８０２に
返答する。この返答結果から、パケットロス検出部８０
２は、メディアデータ再構成部３０８にて受信できてい
ないパケットが、再送待ちのパケット(再送を行うこと
を示す再送判定結果が通知されている)であるか、パケ
ットロスとして許容されたパケットであるか(再送を行
わないことを示す再送判定結果が通知されている)が判
断できる。そして、再送待ちのパケットについては、規
定時間(システムデコーダにて制御)経過しても受信しな
い場合には、再度、再送判定部３０４に、シーケンス番
号８０７を通知する。再送判定部３０４では、再送回数
も考慮に入れて、再送要求の可能性について判定を行
う。なお、再送判定部３０４がロスパケットと判定した
後で、受信したパケットについては、通常通り処理する
ことで情報の書き換えることも可能となる。このような
手順で、ペイロードデータ３０７とシーケンス番号を受
け取ったメディアデータ再構成部３０８では、各TCPパ
ケットのシーケンス番号に従って、受信パケットの出力
順序を入れ替える操作が行われる。入れ替え後、メディ
アデータ再構成部３０８がメディアデータ出力部３１０
にペイロードデータを出力するタイミングは、一般に、
一定の時間間隔で制御されるが、アプリケーションデコ
ーダの再生状況を考慮しながら制御することも可能であ
る。図３９は携帯電話端末のさらなる実施例を示す図
で、２種類のメディアデータ(ビデオデータとオーディ
オデータ)を１つのファイルに統合・蓄積したMP4ファイ
ルフォーマットデータがTCPにて擬似ストリーミング配
信された場合について示している。図３９では、図２に
示した携帯電話端末２００と、システムデコーダからア
プリケーションデコーダへのデータの流れが異なってい
る。システムデコーダ２０５２はTCPパケットヘッダ部
のシーケンス番号を調査し、シーケンス番号順にペイロ
ードデータ２０６２をメモリ２０７２に出力する。この
際の各ペイロードの出力タイミングは、アプリケーショ
ンデコーダにおけるメディアデータの処理状況を考慮し
て決める。また、システムデコーダにおけるロスパケッ
トの再送制御にもアプリケーションデコーダでの処理状
況を反映する。メモリ２０７２に蓄積されたメディアデ
ータ２０８２は、１つのファイルフォーマットデータと
して成立した時点で、アプリケーションデコーダ２０９
２内のファイルデコーダに入力される。ファイルデコー
ダでは、ファイルヘッダの情報からファイル内の各メデ
ィアデータ(ここでは、ビデオデータとオーディオデー
タが含まれていることを想定)を取りだし、それぞれビ
デオデコーダならびにオーディオデコーダに入力され
る。図４０に携帯電話端末の別の実施例を、図４１にシ
ステムデコーダの別の実施例を示し、アプリケーション
デコーダでの処理状況を考慮して、再送判定部３０４に
てロスパケットならびにエラーパケットの再送要求判定
を行うためのデータの流れを説明する。図４０に示した
データ２１０ならびに２１１が処理状況関連情報にあた
る。データ２１１としては、メモリ内の未処理データの
残量、データ２１０としては、再生遅延の発生状況、フ
レームレートならびにビットレートなどが含まれる。こ
れらのデータは、図４１の再送判定部３０４に送られ
る。再送判定部３０４では、データ２１１により得られ
るデータ残量と、データ２１０から得られるデータの消
費速度に関する情報、さらに再送パケットが到達するに
かかる時間の推定値(それまでのデータ到達状況から推
測する)、そのパケットの重要性(例えば、ファイルフォ
ーマットデータのヘッダ部やビデオデータのシーケンス
ヘッダ部を失うとデータ全体の再生が困難となる)等か
ら、パケット再送待ちがアプリケーションデコーダに与
える影響を推定する。
【００１２】TCPにおいてパケットロスを制御する方法
としては、上記以外に、送信側と受信端末側の双方で制
御することも可能である。この場合には、応答確認情報
以外に、再送中止要求や再送要求を端末側から送る仕組
みを作ることでより高速で緻密な制御が可能となる。
としては、上記以外に、送信側と受信端末側の双方で制
御することも可能である。この場合には、応答確認情報
以外に、再送中止要求や再送要求を端末側から送る仕組
みを作ることでより高速で緻密な制御が可能となる。
【００１３】以上説明したTCPを利用した擬似ストリー
ミングでは、１回の通信で１種類のメディアデータしか
扱えないという問題がある。そのため、メディアデータ
を分割した各ファイルにはファイルヘッダをつけなけれ
ばならず、通信容量の増大を招く可能性がある。そこ
で、擬似ストリーミングでは、TCP-RTPという通信手段
も有効である。ここでは、端末側で応答確認処理を制御
する方法についてTCP-RTPの仕組みを図６にて説明す
る。パケット処理部３０１は、各TCPパケットのヘッダ
部に含まれているエラー検出情報を解析し、エラー検出
結果３０２を再送判定部３０４に渡す。この際、受信パ
ケットがエラーを含んでいる場合には、そのパケットを
破棄する。一方、受信パケットがエラーを含んでいない
場合には、TCPパケットヘッダとTCPペイロードに含まれ
るRTPヘッダを解析し、RTPペイロードデータ３０７と、
TCPシーケンス番号・RTPタイムスタンプ・RTPシーケン
ス番号・RTPペイロードタイプ８０１をメディアデータ
再構成部３０８に出力する。同時にTCPシーケンス番号
・RTPタイムスタンプ・RTPシーケンス番号・RTPペイロ
ードタイプ８０１をパケットロス検出部８０２に出力す
る。これにより、パケットロス検出部８０２では、TCP
シーケンス番号、RTPペイロードタイプ、RTPシーケンス
番号を解析することで、受信していないRTPパケットと
そのペイロードタイプを検出することが可能となる。具
体的には、パケット処理部３０１からTCPシーケンス番
号が届いていないパケットを、受信していないパケット
であると判定し、RTPペイロードタイプとRTPシーケンス
番号からその種別を判定する。パケットロス検出部８０
２では、前後のTCPパケットが受信された後、規定時間
(システムデコーダにて制御)が経過しても受信されない
TCPパケットをロスパケットとし、そのTCPシーケンス番
号８０７を再送判定部３０４に通知する。再送判定部３
０４では、ロスパケットの再送により再生処理に支障が
あるか否かを判断する。そして再送を待つと再生処理遅
延の面で問題があると判断した場合には、応答確認情報
３０５を応答確認部３０６に通知するとともに、再送を
行わないことを示す再送判定結果・TCPシーケンス番号
３０３をパケットロス検出部８０２に返答する。再送を
待っても再生処理が滞りなく進行すると判断できる場合
には、再送を行うことを示す再送判定結果・TCPシーケ
ンス番号３０３をパケットロス検出部８０２に返答す
る。この返答結果から、パケットロス検出部８０２は、
メディアデータ再構成部３０８にて受信できていないTC
Pパケットが、再送待ちのパケット(再送を行うことを示
す再送判定結果が通知されている)であるか、パケット
ロスとして許容されたパケットであるか(再送を行わな
いことを示す再送判定結果が通知されている)が判断で
きる。そして、再送待ちのパケットについては、規定時
間(システムデコーダにて制御)経過しても受信しない場
合には、再度、再送判定部３０４に、TCPシーケンス番
号８０７を通知する。再送判定部３０４では、再送回数
も考慮に入れて、再送要求の可能性について判定を行
う。なお、再送判定部３０４がロスパケットと判定した
後で、受信したパケットについては、通常通り処理する
ことで情報を書き換えることも可能となる。このような
手順で、ペイロードデータ３０７とTCPシーケンス番号
・RTPタイムスタンプ・RTPシーケンス番号・RTPペイロ
ードタイプを受け取ったメディアデータ再構成部３０８
では、各RTPパケットのシーケンス番号ならびにペイロ
ードタイプに従って、ペイロードタイプ毎にパケット列
の順序の入れ替える操作が行われる。メディアデータ再
構成部３０８がメディアデータ出力部３１０に各ペイロ
ードデータを出力するタイミングについては、各RTPパ
ケットに含まれるタイムスタンプとアプリケーションデ
コーダの再生状況を考慮しながら制御する方法が有効で
ある。システムデコーダから出力された各ペイロードの
再生方法は、例えば、図３８にて説明される。２種類の
メディアデータ(ビデオデータとオーディオデータ)がTC
P-RTPにて擬似ストリーミング配信された場合では、RTP
パケットヘッダ部のペイロードタイプは、ビデオデータ
あるいはオーディオデータを示している。システムデコ
ーダ２０５１は受信した各RTPパケットのヘッダ部に記
載されているペイロードタイプとシーケンス番号を調査
し、ビデオデータとオーディオデータに分け、それぞれ
シーケンス番号順にペイロードデータ２０６１をメモリ
２０７１に出力する。この際の各ペイロードの出力タイ
ミングは、RTPパケットヘッダ部のタイムスタンプとア
プリケーションデコーダにおけるメディアデータの処理
状況を考慮して決められる。また、システムデコーダに
おけるロスパケットの再送制御にもアプリケーションデ
コーダでの処理状況を反映する。システムデコーダにお
けるロスパケットの再送制御は、TCPの場合と同じく図
４０ならびに図４１にて説明できる。図４０に示したデ
ータ２１０ならびに２１１が処理状況関連情報にあた
る。データ２１１としては、メモリ内の各ペイロードタ
イプにおける未処理データの残量、データ２１０として
は、再生遅延の発生状況、フレームレートならびにビッ
トレートなどが含まれる。これらのデータは、図４１の
再送判定部３０４に送られる。再送判定部３０４では、
データ２１１により得られるデータ残量と、データ２１
０から得られるデータの消費速度に関する情報、さらに
再送パケットが到達するにかかる時間の推定値(それま
でのデータ到達状況から推測する)、ペイロードタイプ
の重要性(基本的にオーディオ再生が途切れることは許
されない)、ロスパケットのペイロードタイプ割合、各
ペイロードタイプのタイムスタンプ等から、パケット再
送待ちがアプリケーションデコーダに与える影響を推定
する。そして、メモリ２０７に蓄積された各メディアデ
ータ２０８は、「擬似ストリーミングにおけるTCP通信
の伝送速度を考慮した受信から再生開始までの待ち時
間」を考慮して規定されたデータ量に達した時点で、順
にアプリケーションデコーダ２０９内のビデオデコーダ
ならびにオーディオデコーダに入力され、再生処理され
る。
ミングでは、１回の通信で１種類のメディアデータしか
扱えないという問題がある。そのため、メディアデータ
を分割した各ファイルにはファイルヘッダをつけなけれ
ばならず、通信容量の増大を招く可能性がある。そこ
で、擬似ストリーミングでは、TCP-RTPという通信手段
も有効である。ここでは、端末側で応答確認処理を制御
する方法についてTCP-RTPの仕組みを図６にて説明す
る。パケット処理部３０１は、各TCPパケットのヘッダ
部に含まれているエラー検出情報を解析し、エラー検出
結果３０２を再送判定部３０４に渡す。この際、受信パ
ケットがエラーを含んでいる場合には、そのパケットを
破棄する。一方、受信パケットがエラーを含んでいない
場合には、TCPパケットヘッダとTCPペイロードに含まれ
るRTPヘッダを解析し、RTPペイロードデータ３０７と、
TCPシーケンス番号・RTPタイムスタンプ・RTPシーケン
ス番号・RTPペイロードタイプ８０１をメディアデータ
再構成部３０８に出力する。同時にTCPシーケンス番号
・RTPタイムスタンプ・RTPシーケンス番号・RTPペイロ
ードタイプ８０１をパケットロス検出部８０２に出力す
る。これにより、パケットロス検出部８０２では、TCP
シーケンス番号、RTPペイロードタイプ、RTPシーケンス
番号を解析することで、受信していないRTPパケットと
そのペイロードタイプを検出することが可能となる。具
体的には、パケット処理部３０１からTCPシーケンス番
号が届いていないパケットを、受信していないパケット
であると判定し、RTPペイロードタイプとRTPシーケンス
番号からその種別を判定する。パケットロス検出部８０
２では、前後のTCPパケットが受信された後、規定時間
(システムデコーダにて制御)が経過しても受信されない
TCPパケットをロスパケットとし、そのTCPシーケンス番
号８０７を再送判定部３０４に通知する。再送判定部３
０４では、ロスパケットの再送により再生処理に支障が
あるか否かを判断する。そして再送を待つと再生処理遅
延の面で問題があると判断した場合には、応答確認情報
３０５を応答確認部３０６に通知するとともに、再送を
行わないことを示す再送判定結果・TCPシーケンス番号
３０３をパケットロス検出部８０２に返答する。再送を
待っても再生処理が滞りなく進行すると判断できる場合
には、再送を行うことを示す再送判定結果・TCPシーケ
ンス番号３０３をパケットロス検出部８０２に返答す
る。この返答結果から、パケットロス検出部８０２は、
メディアデータ再構成部３０８にて受信できていないTC
Pパケットが、再送待ちのパケット(再送を行うことを示
す再送判定結果が通知されている)であるか、パケット
ロスとして許容されたパケットであるか(再送を行わな
いことを示す再送判定結果が通知されている)が判断で
きる。そして、再送待ちのパケットについては、規定時
間(システムデコーダにて制御)経過しても受信しない場
合には、再度、再送判定部３０４に、TCPシーケンス番
号８０７を通知する。再送判定部３０４では、再送回数
も考慮に入れて、再送要求の可能性について判定を行
う。なお、再送判定部３０４がロスパケットと判定した
後で、受信したパケットについては、通常通り処理する
ことで情報を書き換えることも可能となる。このような
手順で、ペイロードデータ３０７とTCPシーケンス番号
・RTPタイムスタンプ・RTPシーケンス番号・RTPペイロ
ードタイプを受け取ったメディアデータ再構成部３０８
では、各RTPパケットのシーケンス番号ならびにペイロ
ードタイプに従って、ペイロードタイプ毎にパケット列
の順序の入れ替える操作が行われる。メディアデータ再
構成部３０８がメディアデータ出力部３１０に各ペイロ
ードデータを出力するタイミングについては、各RTPパ
ケットに含まれるタイムスタンプとアプリケーションデ
コーダの再生状況を考慮しながら制御する方法が有効で
ある。システムデコーダから出力された各ペイロードの
再生方法は、例えば、図３８にて説明される。２種類の
メディアデータ(ビデオデータとオーディオデータ)がTC
P-RTPにて擬似ストリーミング配信された場合では、RTP
パケットヘッダ部のペイロードタイプは、ビデオデータ
あるいはオーディオデータを示している。システムデコ
ーダ２０５１は受信した各RTPパケットのヘッダ部に記
載されているペイロードタイプとシーケンス番号を調査
し、ビデオデータとオーディオデータに分け、それぞれ
シーケンス番号順にペイロードデータ２０６１をメモリ
２０７１に出力する。この際の各ペイロードの出力タイ
ミングは、RTPパケットヘッダ部のタイムスタンプとア
プリケーションデコーダにおけるメディアデータの処理
状況を考慮して決められる。また、システムデコーダに
おけるロスパケットの再送制御にもアプリケーションデ
コーダでの処理状況を反映する。システムデコーダにお
けるロスパケットの再送制御は、TCPの場合と同じく図
４０ならびに図４１にて説明できる。図４０に示したデ
ータ２１０ならびに２１１が処理状況関連情報にあた
る。データ２１１としては、メモリ内の各ペイロードタ
イプにおける未処理データの残量、データ２１０として
は、再生遅延の発生状況、フレームレートならびにビッ
トレートなどが含まれる。これらのデータは、図４１の
再送判定部３０４に送られる。再送判定部３０４では、
データ２１１により得られるデータ残量と、データ２１
０から得られるデータの消費速度に関する情報、さらに
再送パケットが到達するにかかる時間の推定値(それま
でのデータ到達状況から推測する)、ペイロードタイプ
の重要性(基本的にオーディオ再生が途切れることは許
されない)、ロスパケットのペイロードタイプ割合、各
ペイロードタイプのタイムスタンプ等から、パケット再
送待ちがアプリケーションデコーダに与える影響を推定
する。そして、メモリ２０７に蓄積された各メディアデ
ータ２０８は、「擬似ストリーミングにおけるTCP通信
の伝送速度を考慮した受信から再生開始までの待ち時
間」を考慮して規定されたデータ量に達した時点で、順
にアプリケーションデコーダ２０９内のビデオデコーダ
ならびにオーディオデコーダに入力され、再生処理され
る。
【００１４】ここで、パケット処理部３０１の動作につ
いて触れておく。図８は、ＩＳ−９５規格無線端末のパ
ケット処理部の詳細を示したものである。まず、無線信
号は無線インタフェース部２０２にてデータリンク層制
御プロトコルであるRLP (Radio Ling Protocol) のフレ
ームデータ９０２(フレームとパケットはともにデータ
単位のこと)に変換され、RLP解析部に入力される。図１
１にRLPフレームのデータフォーマットを示す。RLPはCD
MAデータに対応した通信プロトコルであり、データリン
ク層のプロトコルとのインタフェースを保つ役割を果た
す。RLP解析部９０３では、RLPヘッダ情報に基づいて、
複数のRLPペイロードデータ９０４を組み合わせること
で、PPP (Point to Point Protocol) に対応したフレー
ムデータ９０４１を構成し、PPP解析部９０５に出力す
る。図１０にPPPフレームのデータフォーマットを示
す。PPPは、データリンク層のプロトコルの一種であり
シリアル回線にて使用される。データリンク層は、主に
「物理的な通信を確立する」役割と「データが通信路を
通過している間に発生したエラーの検出を行う」役割を
果たす。PPP解析部９０５では、使用されているネット
ワーク層プロトコルの判別 (上位プロトコルデータを解
析)、データが通信路を通過している間に発生したエラ
ーの検出 (誤り検査データを解析)、ならびに複数ペイ
ロードデータ９０６を組み合わせたIPパケットデータ９
０６１の構成の処理を行う。なお、ここでは、上位プロ
トコルであるネットワーク層のプロトコルとしてIPv4が
採用されているものとして記載する (一般的に知られて
いるIPとしては、他に、IPv6、AppleTalk等があり、勿
論本発明に適用可能である)。図９にIPv4パケットのデ
ータフォーマットを示す。IPv4パケットデータ９０６
は、IP解析部９０７に入力される。IP解析部では、使用
されているトランスポート層プロトコルの判別 (上位プ
ロトコルデータを解析)やヘッダ部のエラーの検出 (チ
ェックサムデータを解析)を行うと共に、複数のIPペイ
ロードデータ９０８を組み合わせることで、上位プロト
コルのパケットを構成する。そして、上位パケットがTC
Pであった場合には、TCP解析部９１０にTCPパケット９
０８０を出力し、UDPであった場合には、UDP解析部９１
１にUDPパケット９０８１を出力する。図１２にTCPパケ
ットのデータフォーマット、図１３にUDPパケットのデ
ータフォーマットを示す。TCPとUDPの使い分けは、伝送
データの性質により行われ、一般的には、伝送速度より
も信頼性が重要なデータではTCP、リアルタイム性が重
要な場合にはUDPが用いられる。TCP解析部９１０では、
TCPパケットのヘッダ部に含まれるチェックサムを解析
することでエラー検出処理が行われ、エラー検出結果３
０２が再送判定部３０４に渡される(図６に示したエラ
ー検出結果３０２ならびに再送判定部３０４と同じ)。
エラー検出結果がエラーなしを示している場合には、ペ
イロードデータ３０７がメディアデータ再構成部３０８
に、送信元シーケンス番号８０１がパケット検出部８０
２とメディアデータ再構成部３０８に渡される。一方、
UDP解析部では、UDPペイロードデータを、RTPパケット
９１２１としてRTP解析部９１３に出力する。UDPパケッ
トのチェックサムはオプション機能であり、エラー検出
も必須の作業ではないが、安定した通信を提供するた
め、使用することが推奨されている。RTP解析部９１３
では、ペイロード３０７をメディアデータ再構成部３０
８に、タイムスタンプ・シーケンス番号・ペイロードタ
イプ８０１をパケット検出部８０２とメディアデータ再
構成部３０８に振り分ける。
いて触れておく。図８は、ＩＳ−９５規格無線端末のパ
ケット処理部の詳細を示したものである。まず、無線信
号は無線インタフェース部２０２にてデータリンク層制
御プロトコルであるRLP (Radio Ling Protocol) のフレ
ームデータ９０２(フレームとパケットはともにデータ
単位のこと)に変換され、RLP解析部に入力される。図１
１にRLPフレームのデータフォーマットを示す。RLPはCD
MAデータに対応した通信プロトコルであり、データリン
ク層のプロトコルとのインタフェースを保つ役割を果た
す。RLP解析部９０３では、RLPヘッダ情報に基づいて、
複数のRLPペイロードデータ９０４を組み合わせること
で、PPP (Point to Point Protocol) に対応したフレー
ムデータ９０４１を構成し、PPP解析部９０５に出力す
る。図１０にPPPフレームのデータフォーマットを示
す。PPPは、データリンク層のプロトコルの一種であり
シリアル回線にて使用される。データリンク層は、主に
「物理的な通信を確立する」役割と「データが通信路を
通過している間に発生したエラーの検出を行う」役割を
果たす。PPP解析部９０５では、使用されているネット
ワーク層プロトコルの判別 (上位プロトコルデータを解
析)、データが通信路を通過している間に発生したエラ
ーの検出 (誤り検査データを解析)、ならびに複数ペイ
ロードデータ９０６を組み合わせたIPパケットデータ９
０６１の構成の処理を行う。なお、ここでは、上位プロ
トコルであるネットワーク層のプロトコルとしてIPv4が
採用されているものとして記載する (一般的に知られて
いるIPとしては、他に、IPv6、AppleTalk等があり、勿
論本発明に適用可能である)。図９にIPv4パケットのデ
ータフォーマットを示す。IPv4パケットデータ９０６
は、IP解析部９０７に入力される。IP解析部では、使用
されているトランスポート層プロトコルの判別 (上位プ
ロトコルデータを解析)やヘッダ部のエラーの検出 (チ
ェックサムデータを解析)を行うと共に、複数のIPペイ
ロードデータ９０８を組み合わせることで、上位プロト
コルのパケットを構成する。そして、上位パケットがTC
Pであった場合には、TCP解析部９１０にTCPパケット９
０８０を出力し、UDPであった場合には、UDP解析部９１
１にUDPパケット９０８１を出力する。図１２にTCPパケ
ットのデータフォーマット、図１３にUDPパケットのデ
ータフォーマットを示す。TCPとUDPの使い分けは、伝送
データの性質により行われ、一般的には、伝送速度より
も信頼性が重要なデータではTCP、リアルタイム性が重
要な場合にはUDPが用いられる。TCP解析部９１０では、
TCPパケットのヘッダ部に含まれるチェックサムを解析
することでエラー検出処理が行われ、エラー検出結果３
０２が再送判定部３０４に渡される(図６に示したエラ
ー検出結果３０２ならびに再送判定部３０４と同じ)。
エラー検出結果がエラーなしを示している場合には、ペ
イロードデータ３０７がメディアデータ再構成部３０８
に、送信元シーケンス番号８０１がパケット検出部８０
２とメディアデータ再構成部３０８に渡される。一方、
UDP解析部では、UDPペイロードデータを、RTPパケット
９１２１としてRTP解析部９１３に出力する。UDPパケッ
トのチェックサムはオプション機能であり、エラー検出
も必須の作業ではないが、安定した通信を提供するた
め、使用することが推奨されている。RTP解析部９１３
では、ペイロード３０７をメディアデータ再構成部３０
８に、タイムスタンプ・シーケンス番号・ペイロードタ
イプ８０１をパケット検出部８０２とメディアデータ再
構成部３０８に振り分ける。
【００１５】図４２は、図８のTCP部の処理をTCP-RTPに
置き換えた図である。図８との相違点は、TCP-RTPの部
分である。TCP解析部では、TCPパケットのヘッダ部に含
まれるチェックサムを解析することでエラー検出処理が
行われ、エラー検出結果３０２が再送判定部３０４に渡
される(図６に示したエラー検出結果３０２ならびに再
送判定部３０４と同じ)。エラー検出結果がエラーなし
を示している場合には、TCPペイロードデータを、RTPペ
イロードデータ９１２０としてRTP解析部に渡すととも
に、TCPヘッダ部のTCPシーケンス番号９１２２をパケッ
トロス部とメディアデータ再構成部に渡す。RTP解析部
９１３では、RTPペイロード３０７をメディアデータ再
構成部３０８に、RTPヘッダのタイムスタンプ、シーケ
ンス番号・ペイロードタイプをTCPシーケンス番号と共
にパケット検出部８０２とメディアデータ再構成部３０
８に振り分ける。
置き換えた図である。図８との相違点は、TCP-RTPの部
分である。TCP解析部では、TCPパケットのヘッダ部に含
まれるチェックサムを解析することでエラー検出処理が
行われ、エラー検出結果３０２が再送判定部３０４に渡
される(図６に示したエラー検出結果３０２ならびに再
送判定部３０４と同じ)。エラー検出結果がエラーなし
を示している場合には、TCPペイロードデータを、RTPペ
イロードデータ９１２０としてRTP解析部に渡すととも
に、TCPヘッダ部のTCPシーケンス番号９１２２をパケッ
トロス部とメディアデータ再構成部に渡す。RTP解析部
９１３では、RTPペイロード３０７をメディアデータ再
構成部３０８に、RTPヘッダのタイムスタンプ、シーケ
ンス番号・ペイロードタイプをTCPシーケンス番号と共
にパケット検出部８０２とメディアデータ再構成部３０
８に振り分ける。
【００１６】次に図６のパケットロス検出部８０２にて
取得したパケットロス情報を用いて、パケットロス位置
をアプリケーションデコーダに明示的に通知する方法を
考える。図５に示されるように、パケットロスが発生し
た場合には、失ったパケット部分のデータが省略されて
アプリケーションデコーダに渡されることになるが、パ
ケットロスの情報はアプリケーションデコーダには通知
されない。そのため、アプリケーションデコーダがパケ
ットロスの発生ならびにその発生位置を加味して再生処
理を行えるか否かは、アプリケーションデコーダの誤り
検出能力に委ねられることになる。例えば、ロスしたパ
ケットの前後をつなげた時のデータ列が、偶然、アプリ
ケーションデコーダの仕様に含まれていた場合には、パ
ケットロスの検出が遅れる原因となることも考えられ
る。本発明では、アプリケーションデコーダがパケット
ロスの発生位置を正確に判定できるようにするために、
パケットロス部分にアプリケーションデコーダが理解で
きない符号化列を埋め込む仕組みを考える。具体的に
は、アプリケーションデコーダにおけるエラー検出を容
易にするために、デコーダが理解できないデータ列(エ
ラー検出用埋め込みデータ)をパケットロス部分に埋め
込む。アプリケーションデコーダは理解できないデータ
列をエラーと判断するため、パケットロスの発生位置を
ほぼ正確に検出可能となる。これにより、デコーダがエ
ラーデータを正常データとして扱ってしまうようなエラ
ー検出の遅延が回避され、再生画像・音声の乱れが抑制
できる。なお、ここで言うアプリケーションデコーダに
は、ファイルフォーマットのファイルデコーダや、ビデ
オデコーダ、オーディオデコーダ、シーン記述デコーダ
(複数のオブジェクトの表示位置再生処理)等のメディ
アデコーダが含まれる。従って、アプリケーションデコ
ーダが理解できないデータ列(エラー検出用埋め込みデ
ータ)は、アプリケーションデコーダに含まれるデコー
ダの種類によって異なる。例えば、図３９のようにアプ
リケーションデコーダがMP4ファイルのファイルデコー
ダとビデオ・オーディオのメディアデコーダで構成され
ている場合には、ファイルデコーダ、ビデオデコーダ、
オーディオデコーダの全てが理解できないデータ列を
「アプリケーションデコーダが理解できない符号化列
(エラー検出用埋め込みデータ)」としてもよいし、ロス
パケットがMP4ファイルのヘッダ部にあたる場合にはフ
ァイルデコーダのみが理解できない符号列、ビデオデー
タ部にあたる場合にはビデオデコーダのみが理解できな
い符号列、オーディオデータ部にあたる場合にはオーデ
ィオデコーダのみが理解できない符号列を埋め込むこと
で、アプリケーションデコーダ全体として理解できない
符号列(エラー検出用埋め込みデータ)を定義してもよ
い。また、図３８のようにアプリケーションデコーダが
オーディオデコーダとビデオデコーダで構成される場合
には、システムデコーダにて、受信パケットが、ビデオ
データとオーディオデータに分けて処理されるため、ペ
イロードタイプ別に異なるエラー検出用埋め込みデータ
を用意し、アプリケーションデコーダ全体として理解で
きない符号列(エラー検出用埋め込みデータ)を定義すれ
ばよい。
取得したパケットロス情報を用いて、パケットロス位置
をアプリケーションデコーダに明示的に通知する方法を
考える。図５に示されるように、パケットロスが発生し
た場合には、失ったパケット部分のデータが省略されて
アプリケーションデコーダに渡されることになるが、パ
ケットロスの情報はアプリケーションデコーダには通知
されない。そのため、アプリケーションデコーダがパケ
ットロスの発生ならびにその発生位置を加味して再生処
理を行えるか否かは、アプリケーションデコーダの誤り
検出能力に委ねられることになる。例えば、ロスしたパ
ケットの前後をつなげた時のデータ列が、偶然、アプリ
ケーションデコーダの仕様に含まれていた場合には、パ
ケットロスの検出が遅れる原因となることも考えられ
る。本発明では、アプリケーションデコーダがパケット
ロスの発生位置を正確に判定できるようにするために、
パケットロス部分にアプリケーションデコーダが理解で
きない符号化列を埋め込む仕組みを考える。具体的に
は、アプリケーションデコーダにおけるエラー検出を容
易にするために、デコーダが理解できないデータ列(エ
ラー検出用埋め込みデータ)をパケットロス部分に埋め
込む。アプリケーションデコーダは理解できないデータ
列をエラーと判断するため、パケットロスの発生位置を
ほぼ正確に検出可能となる。これにより、デコーダがエ
ラーデータを正常データとして扱ってしまうようなエラ
ー検出の遅延が回避され、再生画像・音声の乱れが抑制
できる。なお、ここで言うアプリケーションデコーダに
は、ファイルフォーマットのファイルデコーダや、ビデ
オデコーダ、オーディオデコーダ、シーン記述デコーダ
(複数のオブジェクトの表示位置再生処理)等のメディ
アデコーダが含まれる。従って、アプリケーションデコ
ーダが理解できないデータ列(エラー検出用埋め込みデ
ータ)は、アプリケーションデコーダに含まれるデコー
ダの種類によって異なる。例えば、図３９のようにアプ
リケーションデコーダがMP4ファイルのファイルデコー
ダとビデオ・オーディオのメディアデコーダで構成され
ている場合には、ファイルデコーダ、ビデオデコーダ、
オーディオデコーダの全てが理解できないデータ列を
「アプリケーションデコーダが理解できない符号化列
(エラー検出用埋め込みデータ)」としてもよいし、ロス
パケットがMP4ファイルのヘッダ部にあたる場合にはフ
ァイルデコーダのみが理解できない符号列、ビデオデー
タ部にあたる場合にはビデオデコーダのみが理解できな
い符号列、オーディオデータ部にあたる場合にはオーデ
ィオデコーダのみが理解できない符号列を埋め込むこと
で、アプリケーションデコーダ全体として理解できない
符号列(エラー検出用埋め込みデータ)を定義してもよ
い。また、図３８のようにアプリケーションデコーダが
オーディオデコーダとビデオデコーダで構成される場合
には、システムデコーダにて、受信パケットが、ビデオ
データとオーディオデータに分けて処理されるため、ペ
イロードタイプ別に異なるエラー検出用埋め込みデータ
を用意し、アプリケーションデコーダ全体として理解で
きない符号列(エラー検出用埋め込みデータ)を定義すれ
ばよい。
【００１７】エラー検出用データ列を埋め込む手順は次
に述べるとおりである。前に述べたように、メディアデ
ータ再構成部３０８まで到達していないパケットのシー
ケンス番号(ならびにペイロードタイプ)と再送処理状況
(再送処理中/パケットロス)は、パケットロス検出部８
０２にて認識されている。そこで、図６と図４１に示す
ように、エラー検出用埋め込みデータ８０５をパケット
ロス検出部８０２にて作成し、パケットロスが発生した
シーケンス番号(ならびにペイロードタイプ)８０６と共
にメディアデコーダ再構成部３０８に通知する仕組みを
システムデコーダ内に設ける。そして、メディアデコー
ダ再構成部３０８は、ロスしたパケットのシーケンス番
号(ならびにペイロードタイプ)８０６に対応する順番
で、エラー検出用埋め込みデータ８０５を出力する。こ
れにより、エラー検出用データの埋め込みが可能とな
る。ここでは、簡素化のため、パケットロスが発生した
部分のメディアデータを復号するアプリケーションデコ
ーダが、MPEG-4ビデオ規格であった場合、つまり図３９
で、RTPパケットのペイロードタイプがビデオであった
場合を例として、埋め込みデータのタイプを考える。図
１５は、図５のように第２番目のパケットをロスした場
合のエラー検出用埋め込みデータの例である。MPEG-4ビ
デオ規格では２進数表示で２４個以上の０を続けること
は禁止されている。従って、埋め込みデータ８０５２
は、MPEG-4ビデオ規格には含まれないデータ列であり、
ビデオデコーダには理解できず、エラーが発生したと認
識できる。しかしながら、この例のように、アプリケー
ションデコーダ(ここでは、ビデオデコーダ)との間で特
に取り決めのないユニークワードをエラー検出用埋め込
みデータとして使用した場合では、パケットロス位置の
周辺で誤りを検出することは可能であるが、エラーデー
タと正常データの切れ目を正確に検出することは難し
い。従って、既存の市販ビデオデコーダをそのまま利用
し、システムデコーダを新規開発する場合のパケットロ
ス位置検出方法としては有効であるが、十分な検出性能
は得られない。そこで図１に、アプリケーションデコー
ダとの間で予め決めておいたユニークワード８０５１を
埋め込んでおく場合のMPEG-4ビデオ規格の例を示す。MP
EG-4ビデオでは、２３個の０と１個の１の組み合わせを
データの切れ目を示すための識別コードとしており、そ
の２４ビットに続く２バイトのデータがその切れ目の種
類を示すように設計されている。図１で使用している、
１６進数のＡ１ならびにＡ５は、リザーブ用の識別コー
ドとされており、現在の規格では使用されていない。従
って、このようなユニークワードはMPEG-4ビデオの標準
デコーダでは理解できず、エラーと見なされることにな
る。そこで、このようなデータ列が予めエラー検出用埋
め込みデータであることを、MPEG-4ビデオデコーダとパ
ケットロス検出部８０２が理解しておくことにより、ビ
デオデコーダにて正確なパケットロスの位置検出が実現
でき、正常データとエラー検出用埋め込みデータの切れ
目も明確となる。また、２個のユニークワードを設定
し、これらをエラー検出用埋め込みデータの最初と最後
につけておく方法も有効である。この方法では、第１の
ユニークワードの数ビットを誤ってデコードしてしまっ
たとしても、埋め込みデータ区間の途中でエラーが検出
されるように細工しておけば(２４個以上の０を挟む)、
第２のユニークワードを検索することにより正常データ
が始まる位置を正確に検出することが可能となる。ま
た、一度処理したデータを再度検索し直すことが可能な
場合には、少し前に戻ってから、第１のユニークワード
を改めて検索することにより、パケットロスが始まる位
置も正確に検出することが可能となる。
に述べるとおりである。前に述べたように、メディアデ
ータ再構成部３０８まで到達していないパケットのシー
ケンス番号(ならびにペイロードタイプ)と再送処理状況
(再送処理中/パケットロス)は、パケットロス検出部８
０２にて認識されている。そこで、図６と図４１に示す
ように、エラー検出用埋め込みデータ８０５をパケット
ロス検出部８０２にて作成し、パケットロスが発生した
シーケンス番号(ならびにペイロードタイプ)８０６と共
にメディアデコーダ再構成部３０８に通知する仕組みを
システムデコーダ内に設ける。そして、メディアデコー
ダ再構成部３０８は、ロスしたパケットのシーケンス番
号(ならびにペイロードタイプ)８０６に対応する順番
で、エラー検出用埋め込みデータ８０５を出力する。こ
れにより、エラー検出用データの埋め込みが可能とな
る。ここでは、簡素化のため、パケットロスが発生した
部分のメディアデータを復号するアプリケーションデコ
ーダが、MPEG-4ビデオ規格であった場合、つまり図３９
で、RTPパケットのペイロードタイプがビデオであった
場合を例として、埋め込みデータのタイプを考える。図
１５は、図５のように第２番目のパケットをロスした場
合のエラー検出用埋め込みデータの例である。MPEG-4ビ
デオ規格では２進数表示で２４個以上の０を続けること
は禁止されている。従って、埋め込みデータ８０５２
は、MPEG-4ビデオ規格には含まれないデータ列であり、
ビデオデコーダには理解できず、エラーが発生したと認
識できる。しかしながら、この例のように、アプリケー
ションデコーダ(ここでは、ビデオデコーダ)との間で特
に取り決めのないユニークワードをエラー検出用埋め込
みデータとして使用した場合では、パケットロス位置の
周辺で誤りを検出することは可能であるが、エラーデー
タと正常データの切れ目を正確に検出することは難し
い。従って、既存の市販ビデオデコーダをそのまま利用
し、システムデコーダを新規開発する場合のパケットロ
ス位置検出方法としては有効であるが、十分な検出性能
は得られない。そこで図１に、アプリケーションデコー
ダとの間で予め決めておいたユニークワード８０５１を
埋め込んでおく場合のMPEG-4ビデオ規格の例を示す。MP
EG-4ビデオでは、２３個の０と１個の１の組み合わせを
データの切れ目を示すための識別コードとしており、そ
の２４ビットに続く２バイトのデータがその切れ目の種
類を示すように設計されている。図１で使用している、
１６進数のＡ１ならびにＡ５は、リザーブ用の識別コー
ドとされており、現在の規格では使用されていない。従
って、このようなユニークワードはMPEG-4ビデオの標準
デコーダでは理解できず、エラーと見なされることにな
る。そこで、このようなデータ列が予めエラー検出用埋
め込みデータであることを、MPEG-4ビデオデコーダとパ
ケットロス検出部８０２が理解しておくことにより、ビ
デオデコーダにて正確なパケットロスの位置検出が実現
でき、正常データとエラー検出用埋め込みデータの切れ
目も明確となる。また、２個のユニークワードを設定
し、これらをエラー検出用埋め込みデータの最初と最後
につけておく方法も有効である。この方法では、第１の
ユニークワードの数ビットを誤ってデコードしてしまっ
たとしても、埋め込みデータ区間の途中でエラーが検出
されるように細工しておけば(２４個以上の０を挟む)、
第２のユニークワードを検索することにより正常データ
が始まる位置を正確に検出することが可能となる。ま
た、一度処理したデータを再度検索し直すことが可能な
場合には、少し前に戻ってから、第１のユニークワード
を改めて検索することにより、パケットロスが始まる位
置も正確に検出することが可能となる。
【００１８】図１６は、メディアデータのほかに、それ
と同サイズの誤り通知データを用意する方法である。誤
り通知データにおける各バイナリーデータを、メディア
データにおける各バイナリーデータと１対１で対応させ
ておき、例えば、メディアデータ内の埋め込みデータ８
０５３の区間に１を割り当て、正常パケットの区間には
０を割り当てておく。この誤り通知データにより、アプ
リケーションデコーダは正確にパケットロスの発生を認
識できる。この際、埋め込みデータ８０５３は、必ずし
もユニークワードである必要はない。但し、誤り通知デ
ータをアプリケーションデコーダに渡すための構成が必
要となる。例えば、図６に示すように、パケットロス検
出部８０２にて生成した誤り通知データパケット７０６
を、誤り通知出力部８０４からメモリ２０７に出力する
仕組みとする。この場合、携帯電話端末の全体構成は図
１７のようになる。図２と図１７の相違点は、誤り通知
データパケット７０６がシステムデコーダ２０５からメ
モリ２０７に渡される点と、メモリ２０７に蓄積後、メ
ディアデータと同期して、誤り通知データ７０３がアプ
リケーションデコーダ２０９に出力されている点であ
る。図４３ならびに図４４は、それぞれ図３８ならびに
図３９の携帯電話端末構成に誤り通知データの機能を加
えたものを示す。RTPを使用する図４３では、ペイロー
ドタイプ別に、誤り通知データパケット７０６１ならび
に誤り通知データ７０３１が処理されている。これに対
し、TCPを使用しており、TCPパケットがペイロードタイ
プを持っていない図４４では、アプリケーションデコー
ダ内のファイルデコーダにて誤り通知データが各メディ
アデコーダに分配される。なお、図４４にて、ファイル
フォーマットデータのヘッダ部にてパケットロスが発生
している場合には、ファイルデコーダにてヘッダ部の情
報を修正する必要が生じる。但し、より確実に再生処理
を行うためには、図６あるいは図４１の再送判定部３０
４にて、ファイルヘッダ部でロスパケットが発生してい
る場合にはデータが到達するまで再送要求をかけるか、
ファイルの構成を送信側と端末側の間で決めておくとよ
い。
と同サイズの誤り通知データを用意する方法である。誤
り通知データにおける各バイナリーデータを、メディア
データにおける各バイナリーデータと１対１で対応させ
ておき、例えば、メディアデータ内の埋め込みデータ８
０５３の区間に１を割り当て、正常パケットの区間には
０を割り当てておく。この誤り通知データにより、アプ
リケーションデコーダは正確にパケットロスの発生を認
識できる。この際、埋め込みデータ８０５３は、必ずし
もユニークワードである必要はない。但し、誤り通知デ
ータをアプリケーションデコーダに渡すための構成が必
要となる。例えば、図６に示すように、パケットロス検
出部８０２にて生成した誤り通知データパケット７０６
を、誤り通知出力部８０４からメモリ２０７に出力する
仕組みとする。この場合、携帯電話端末の全体構成は図
１７のようになる。図２と図１７の相違点は、誤り通知
データパケット７０６がシステムデコーダ２０５からメ
モリ２０７に渡される点と、メモリ２０７に蓄積後、メ
ディアデータと同期して、誤り通知データ７０３がアプ
リケーションデコーダ２０９に出力されている点であ
る。図４３ならびに図４４は、それぞれ図３８ならびに
図３９の携帯電話端末構成に誤り通知データの機能を加
えたものを示す。RTPを使用する図４３では、ペイロー
ドタイプ別に、誤り通知データパケット７０６１ならび
に誤り通知データ７０３１が処理されている。これに対
し、TCPを使用しており、TCPパケットがペイロードタイ
プを持っていない図４４では、アプリケーションデコー
ダ内のファイルデコーダにて誤り通知データが各メディ
アデコーダに分配される。なお、図４４にて、ファイル
フォーマットデータのヘッダ部にてパケットロスが発生
している場合には、ファイルデコーダにてヘッダ部の情
報を修正する必要が生じる。但し、より確実に再生処理
を行うためには、図６あるいは図４１の再送判定部３０
４にて、ファイルヘッダ部でロスパケットが発生してい
る場合にはデータが到達するまで再送要求をかけるか、
ファイルの構成を送信側と端末側の間で決めておくとよ
い。
【００１９】ここまでは、メディアデコーダにパケット
ロスを通知する方法について述べてきたが、この方法で
は、再生される画質ならびに音質は最終的にアプリケー
ションデコーダの性能に依存することになる。そのた
め、アプリケーションデコーダ自体が高度な誤り訂正手
段を持っていない場合には、エラー検出用の埋め込みデ
ータは逆にデコードの性能を落としてしまう可能性もあ
る。また、アプリケーションデコーダが高度な誤り訂正
手段を持つためには、誤り検出、誤り修復等の処理をア
プリケーションデコーダに追加する必要があり、処理量
も増える。そのため、メモリ要求、CPUパワーならびに
消費電力等の要求が厳しい通信端末では、リアルタイム
再生を実現する上で、簡易な誤り訂正手段しか採用でき
ない場合も考えられる。そこで、本出願では、ファイル
転送型のサービスに関して、エラー検出用埋め込みデー
タを利用してアプリケーションデコーダで処理される前
に、パケットロスを伴うメディアデータをビデオ、オー
ディオ等の仕様や標準規格に対応したデータに修正する
方法についても提案する。
ロスを通知する方法について述べてきたが、この方法で
は、再生される画質ならびに音質は最終的にアプリケー
ションデコーダの性能に依存することになる。そのた
め、アプリケーションデコーダ自体が高度な誤り訂正手
段を持っていない場合には、エラー検出用の埋め込みデ
ータは逆にデコードの性能を落としてしまう可能性もあ
る。また、アプリケーションデコーダが高度な誤り訂正
手段を持つためには、誤り検出、誤り修復等の処理をア
プリケーションデコーダに追加する必要があり、処理量
も増える。そのため、メモリ要求、CPUパワーならびに
消費電力等の要求が厳しい通信端末では、リアルタイム
再生を実現する上で、簡易な誤り訂正手段しか採用でき
ない場合も考えられる。そこで、本出願では、ファイル
転送型のサービスに関して、エラー検出用埋め込みデー
タを利用してアプリケーションデコーダで処理される前
に、パケットロスを伴うメディアデータをビデオ、オー
ディオ等の仕様や標準規格に対応したデータに修正する
方法についても提案する。
【００２０】図１８に示す携帯電話端末２００３は、図
１７の携帯電話端末２００２に、メディアデータの修正
処理構成を加えたものである。メモリ２０７へのメディ
アデータ入力以降の処理を以下に説明する。エラー・同
期マーカ検出７０１では、メディア処理の標準規格にて
定められている同期確保用の識別コード(同期マーカ)と
システムデコーダ２０５にて埋めこんだエラー検出用埋
め込みデータ８０５を検索対象として、メモリ２０７内
のメディアデータ２０８を順に検索する(図１６で説明
した誤り通知データを利用している場合には、誤り通知
データ７０３も並列に検索し、メディアデータ内のエラ
ー検出用埋め込みデータの替わりに、誤り通知データ内
に記載されているエラー発生位置を示すデータ列を検出
する)。そして、その何れかが検出された時点で、検出
結果が同期マーカとエラー検出用埋め込みデータ(誤り
通知データを利用している場合には、誤り通知データ内
に記載されているエラー発生位置を示すデータ列)のい
ずれであったかを示す識別情報７１３をデータ修正処理
部７０７に通知する。この際、同時にスイッチ７０５
に、制御情報７０４を渡す。制御情報７０４は、検索開
始位置から検出位置までのデータを第２メモリ７１０と
データ修正処理部７０７のいずれに出力すべきかを示す
情報で、検出結果が同期マーカの場合には第２メモリ７
１０に、検出結果がエラー検出用埋め込みデータ(誤り
通知データを利用している場合には、誤り通知データ内
に記載されているエラー発生位置を示すデータ列)の場
合にはデータ処理部７０７にデータを出力することを示
す。スイッチ７０５は、制御情報７０４の値に従ってス
イッチを制御し、検出開始位置から次の同期マーカまで
のメディアデータを第２のメモリ７１０あるいはデータ
修正処理部７０７に渡るようにする(誤り通知データを
利用している場合であり、かつ検出結果が誤り通知デー
タ内に記載されているエラー発生位置を示すデータ列で
あるときには、メディアデータに対応する誤り通知デー
タ７０３も同時にデータ修正処理７０７に渡される)。
その後、メモリ２０７ではエラー・同期マーカ検出７０
１にて検出したデータ位置までの情報を削除する(ある
いは、検出した位置までポインタを移動する。誤り通知
データも同様に処理)。データ修正処理部７０７では、
入力データを調査し、規格方式に対応したデータに修正
して第２メモリ７１０に出力する。この際、データ処理
修正部７０７からスイッチ７０５に対して、スイッチ制
御情報７１２が通知される場合がある(詳細は後述)。ま
た、データ修正処理部７０７が、修正のために既に第２
メモリ７１０に渡っているデータを必要とする場合に
は、処理済みデータ７０９を第２メモリから検索して入
手する。第２メモリ７１０は、ユーザからの要求に応じ
てアプリケーションデコーダ２０９にメディアデータ７
１１を出力する。この場合、アプリケーションデコーダ
２０９は高度な誤り修正処理を必要としない(誤り通知
データを使用しており、アプリケーションデコーダが誤
り通知データを受信する仕組みを持っている場合には、
誤り通知データをアプリケーションデコーダまで渡すこ
とも可能である)。
１７の携帯電話端末２００２に、メディアデータの修正
処理構成を加えたものである。メモリ２０７へのメディ
アデータ入力以降の処理を以下に説明する。エラー・同
期マーカ検出７０１では、メディア処理の標準規格にて
定められている同期確保用の識別コード(同期マーカ)と
システムデコーダ２０５にて埋めこんだエラー検出用埋
め込みデータ８０５を検索対象として、メモリ２０７内
のメディアデータ２０８を順に検索する(図１６で説明
した誤り通知データを利用している場合には、誤り通知
データ７０３も並列に検索し、メディアデータ内のエラ
ー検出用埋め込みデータの替わりに、誤り通知データ内
に記載されているエラー発生位置を示すデータ列を検出
する)。そして、その何れかが検出された時点で、検出
結果が同期マーカとエラー検出用埋め込みデータ(誤り
通知データを利用している場合には、誤り通知データ内
に記載されているエラー発生位置を示すデータ列)のい
ずれであったかを示す識別情報７１３をデータ修正処理
部７０７に通知する。この際、同時にスイッチ７０５
に、制御情報７０４を渡す。制御情報７０４は、検索開
始位置から検出位置までのデータを第２メモリ７１０と
データ修正処理部７０７のいずれに出力すべきかを示す
情報で、検出結果が同期マーカの場合には第２メモリ７
１０に、検出結果がエラー検出用埋め込みデータ(誤り
通知データを利用している場合には、誤り通知データ内
に記載されているエラー発生位置を示すデータ列)の場
合にはデータ処理部７０７にデータを出力することを示
す。スイッチ７０５は、制御情報７０４の値に従ってス
イッチを制御し、検出開始位置から次の同期マーカまで
のメディアデータを第２のメモリ７１０あるいはデータ
修正処理部７０７に渡るようにする(誤り通知データを
利用している場合であり、かつ検出結果が誤り通知デー
タ内に記載されているエラー発生位置を示すデータ列で
あるときには、メディアデータに対応する誤り通知デー
タ７０３も同時にデータ修正処理７０７に渡される)。
その後、メモリ２０７ではエラー・同期マーカ検出７０
１にて検出したデータ位置までの情報を削除する(ある
いは、検出した位置までポインタを移動する。誤り通知
データも同様に処理)。データ修正処理部７０７では、
入力データを調査し、規格方式に対応したデータに修正
して第２メモリ７１０に出力する。この際、データ処理
修正部７０７からスイッチ７０５に対して、スイッチ制
御情報７１２が通知される場合がある(詳細は後述)。ま
た、データ修正処理部７０７が、修正のために既に第２
メモリ７１０に渡っているデータを必要とする場合に
は、処理済みデータ７０９を第２メモリから検索して入
手する。第２メモリ７１０は、ユーザからの要求に応じ
てアプリケーションデコーダ２０９にメディアデータ７
１１を出力する。この場合、アプリケーションデコーダ
２０９は高度な誤り修正処理を必要としない(誤り通知
データを使用しており、アプリケーションデコーダが誤
り通知データを受信する仕組みを持っている場合には、
誤り通知データをアプリケーションデコーダまで渡すこ
とも可能である)。
【００２１】ここで説明したデータ修正処理は、システ
ムデコーダにてメディアデータがすでにビデオデータと
オーディオデータに分かれているような場合には、個々
のメディアデータ毎に修正処理を行えばよいが、MP4フ
ァイルのように複数のメディアデータが１個のファイル
に統合されている場合には、ファイル内のデータ位置に
応じて異なる修正処理を行う必要がある。具体的には、
ファイル内の各メディアデータ部(ビデオデータ、オー
ディオデータ)ならびにファイルヘッダ部に、個々に修
理処理を施す。そして、メディアデータ部の修正内容に
従いファイルヘッダ部に記載されているデータ容量等を
更に書き換える必要がある。このように、ファイルヘッ
ダをファイルフォーマットの仕様に対応したデータに修
正することにより、ファイルフォーマットデコーダが各
メディアデータを対応するデコーダに割り当てることが
できるようになる。
ムデコーダにてメディアデータがすでにビデオデータと
オーディオデータに分かれているような場合には、個々
のメディアデータ毎に修正処理を行えばよいが、MP4フ
ァイルのように複数のメディアデータが１個のファイル
に統合されている場合には、ファイル内のデータ位置に
応じて異なる修正処理を行う必要がある。具体的には、
ファイル内の各メディアデータ部(ビデオデータ、オー
ディオデータ)ならびにファイルヘッダ部に、個々に修
理処理を施す。そして、メディアデータ部の修正内容に
従いファイルヘッダ部に記載されているデータ容量等を
更に書き換える必要がある。このように、ファイルヘッ
ダをファイルフォーマットの仕様に対応したデータに修
正することにより、ファイルフォーマットデコーダが各
メディアデータを対応するデコーダに割り当てることが
できるようになる。
【００２２】次に、MPEG-4ビデオ規格を例にとって、デ
ータ修正処理部７０７での処理を詳細に説明する。説明
に先立ち、まず、MPEG-4ビデオ規格の復号方式ならびに
データ構造について説明する。MPEG-4で扱う動画像の１
フレームは、図２３に示すように、１個の輝度信号(Y信
号：2001)と２個の色差信号(Cr信号：2002, Cb信号：20
03)にて構成されており、色差信号の画像サイズは縦横
とも輝度信号の1/2となる。MPEG-4ビデオ規格では、動
画像の各フレームを図２３に示すような小ブロックに分
割し、マクロブロックと呼ばれるブロック単位で再生処
理を行う。図24にマクロブロックの構造を示す。マクロ
ブロックは１６×１６画素の１個のY信号ブロック２１
０１と、それと空間的に一致する８×８画素のCr信号ブ
ロック２１０２ならびにCb信号ブロック２１０３にて構
成されている。なお、Y信号ブロックは、マクロブロッ
クの復元過程では更に４個の８×８画素ブロック（２１
０１１，２１０１２，２１０１３，２１０１４）に分割
して処理されることがある。MPEG-4ビデオの符号化アル
ゴリズムは、MC-DCT(動き補償-離散コサイン変換)と呼
ばれており、上記に示したマクロブロック単位で再生処
理がなされる。動き補償とは、前フレームから対象マク
ロブロックの内容と似通った部分を抜き出し、その動き
量を符号化する方法のことであり、動き補償により抜き
出された前フレームのブロック領域と原画像の符号化対
象ブロック（２１０１１，２１０１２，２１０１３，２
１０１４，２１０２，２１０３）との差分ブロック画像
が、DCTにて周波数変換された後、各変換係数が量子化
して符号化される。さらに細かく見るとMPEG-4ビデオ規
格にはフレーム内符号化 (イントラ符号化)、フレーム
間符号化 (予測符号化)、双方向符号化と呼ばれる符号
化方法がある。イントラ符号化とは、動き補償後の差分
ブロック画像ではなく、符号化対象の入力ブロック画像
に対して直接ＤＣＴを施し、各変換係数を量子化・符号
化するデータ圧縮方法であり、全てのマクロブロックに
対してイントラ符号化を適用したフレームをI-VOP(Intr
a-coded Video Object Plane、矩形画像ではVOPはフレ
ームと同義)と呼ぶ。I-VOPは、過去のフレームの復号情
報を必要としないため、ランダムアクセス時の復号開始
フレームとして使用される。予測符号化とは、MC-DCTを
利用した圧縮方法で、特に時間的に過去フレームに対し
てMCを行う符号化方法のこと。そして、フレーム内のマ
クロブロックに対して、予測符号化あるいはイントラ符
号化を施したフレームをP-VOP(Predictive-coded VOP)
と呼ぶ。これ以外に、時間的に過去と未来のフレームの
情報を用いてMCを行う方法(双方向符号化)もあり、この
符号化方法を使用したフレームはB-VOP(Bidirectionall
y predicted-coded VOP)と呼ばれている。
ータ修正処理部７０７での処理を詳細に説明する。説明
に先立ち、まず、MPEG-4ビデオ規格の復号方式ならびに
データ構造について説明する。MPEG-4で扱う動画像の１
フレームは、図２３に示すように、１個の輝度信号(Y信
号：2001)と２個の色差信号(Cr信号：2002, Cb信号：20
03)にて構成されており、色差信号の画像サイズは縦横
とも輝度信号の1/2となる。MPEG-4ビデオ規格では、動
画像の各フレームを図２３に示すような小ブロックに分
割し、マクロブロックと呼ばれるブロック単位で再生処
理を行う。図24にマクロブロックの構造を示す。マクロ
ブロックは１６×１６画素の１個のY信号ブロック２１
０１と、それと空間的に一致する８×８画素のCr信号ブ
ロック２１０２ならびにCb信号ブロック２１０３にて構
成されている。なお、Y信号ブロックは、マクロブロッ
クの復元過程では更に４個の８×８画素ブロック（２１
０１１，２１０１２，２１０１３，２１０１４）に分割
して処理されることがある。MPEG-4ビデオの符号化アル
ゴリズムは、MC-DCT(動き補償-離散コサイン変換)と呼
ばれており、上記に示したマクロブロック単位で再生処
理がなされる。動き補償とは、前フレームから対象マク
ロブロックの内容と似通った部分を抜き出し、その動き
量を符号化する方法のことであり、動き補償により抜き
出された前フレームのブロック領域と原画像の符号化対
象ブロック（２１０１１，２１０１２，２１０１３，２
１０１４，２１０２，２１０３）との差分ブロック画像
が、DCTにて周波数変換された後、各変換係数が量子化
して符号化される。さらに細かく見るとMPEG-4ビデオ規
格にはフレーム内符号化 (イントラ符号化)、フレーム
間符号化 (予測符号化)、双方向符号化と呼ばれる符号
化方法がある。イントラ符号化とは、動き補償後の差分
ブロック画像ではなく、符号化対象の入力ブロック画像
に対して直接ＤＣＴを施し、各変換係数を量子化・符号
化するデータ圧縮方法であり、全てのマクロブロックに
対してイントラ符号化を適用したフレームをI-VOP(Intr
a-coded Video Object Plane、矩形画像ではVOPはフレ
ームと同義)と呼ぶ。I-VOPは、過去のフレームの復号情
報を必要としないため、ランダムアクセス時の復号開始
フレームとして使用される。予測符号化とは、MC-DCTを
利用した圧縮方法で、特に時間的に過去フレームに対し
てMCを行う符号化方法のこと。そして、フレーム内のマ
クロブロックに対して、予測符号化あるいはイントラ符
号化を施したフレームをP-VOP(Predictive-coded VOP)
と呼ぶ。これ以外に、時間的に過去と未来のフレームの
情報を用いてMCを行う方法(双方向符号化)もあり、この
符号化方法を使用したフレームはB-VOP(Bidirectionall
y predicted-coded VOP)と呼ばれている。
【００２３】図１９は一般的なMPEG-4ビデオ復号化のブ
ロック図である。入力されたメディアデータは、まず、
符号解読部５０１によって、バイナリーコードから意味
のある復号情報に変換される。そして、DCT係数の量子
化データに関連する情報は、逆量子化部５０２に送ら
れ、DCT係数データに復号された後、逆DCT器５０３にて
差分マクロブロック画像に復元される。一方、動き量に
関する情報は動き補償部５０４に送られる。動き補償器
５０４では、前フレームのデータが蓄積されているフレ
ームメモリ５０７から、復号された動き量に従って予測
マクロブロック画像が復元される。このようにして復元
された差分マクロブロック画像と予測マクロブロック画
像は、加算器５０５にて復元マクロブロック画像が生成
され、合成部５０６にて復元フレーム画像に合成され
る。復元されたフレーム画像は、表示処理部に出力され
ると共に、次フレームの動き補償のために、フレームメ
モリ５０７に保存される。図２０は、誤り検出ならびに
誤り修正処理機能を持つMPEG-4ビデオ復号化のブロック
図例である。符号解読部５０１２では、入力データの解
析と共に誤り検出が行われる。誤り検出にはいろいろな
方法があるが、一般的には、MPEG-4ビデオ符号化のコー
ドブックに存在しない可変長コードの検出によって行わ
れる。データ誤りが検出された場合には、符号解読部５
０１２は対象データを修復処理部５０９に出力する。ま
た、符号解読部５０１２は、データ誤りを検出した時点
で予測マクロブロック画像の出力制御情報５１０をスイ
ッチ５０８に通知し、予測マクロブロック画像が修復処
理部５０９に渡るように制御する。符号解読部５０１２
における誤り検出処理ならびに修復処理部５０９の処理
内容は標準化されていないため、伝送エラーが含まれる
データの再生画質は、各製品の仕様に依存することにな
る。
ロック図である。入力されたメディアデータは、まず、
符号解読部５０１によって、バイナリーコードから意味
のある復号情報に変換される。そして、DCT係数の量子
化データに関連する情報は、逆量子化部５０２に送ら
れ、DCT係数データに復号された後、逆DCT器５０３にて
差分マクロブロック画像に復元される。一方、動き量に
関する情報は動き補償部５０４に送られる。動き補償器
５０４では、前フレームのデータが蓄積されているフレ
ームメモリ５０７から、復号された動き量に従って予測
マクロブロック画像が復元される。このようにして復元
された差分マクロブロック画像と予測マクロブロック画
像は、加算器５０５にて復元マクロブロック画像が生成
され、合成部５０６にて復元フレーム画像に合成され
る。復元されたフレーム画像は、表示処理部に出力され
ると共に、次フレームの動き補償のために、フレームメ
モリ５０７に保存される。図２０は、誤り検出ならびに
誤り修正処理機能を持つMPEG-4ビデオ復号化のブロック
図例である。符号解読部５０１２では、入力データの解
析と共に誤り検出が行われる。誤り検出にはいろいろな
方法があるが、一般的には、MPEG-4ビデオ符号化のコー
ドブックに存在しない可変長コードの検出によって行わ
れる。データ誤りが検出された場合には、符号解読部５
０１２は対象データを修復処理部５０９に出力する。ま
た、符号解読部５０１２は、データ誤りを検出した時点
で予測マクロブロック画像の出力制御情報５１０をスイ
ッチ５０８に通知し、予測マクロブロック画像が修復処
理部５０９に渡るように制御する。符号解読部５０１２
における誤り検出処理ならびに修復処理部５０９の処理
内容は標準化されていないため、伝送エラーが含まれる
データの再生画質は、各製品の仕様に依存することにな
る。
【００２４】図２１, 図２２ならびに図２５は、MPEG-4
ビデオ符号化の基本的なデータ構造を示したものであ
る。図２１が全体のデータ構造、図２２がフレームヘッ
ダのデータ構造、図２５が各マクロブロックのデータ構
造を示している。図２１において、VOSヘッダはMPEG-4
ビデオ製品の適用範囲を決めるプロファイル・レベル情
報、VOヘッダはMPEG-4ビデオ符号化のデータ構造を決め
るバージョン情報、VOLヘッダは画像サイズ、符号化ビ
ットレート、フレームメモリサイズ、適用ツール等の情
報を含んでいる。いずれも受信した符号化データを復号
する上で必須の情報である。GOVヘッダには時刻情報が
含まれているが、これは必須の情報ではなく省略も可能
である。VOSヘッダ、VOヘッダ、VOLヘッダ、GOVヘッダ
とも32ビットのユニークワードから始まるため、容易に
検索できる。シーケンスの終了を示すEnd code of VOS
も32ビットのユニークワードである。これらのユニーク
ワードは、２３個の０と１個の１で始まり、その２４ビ
ットに続く２バイトのデータがその区切れの種類を示す
ような構造となっている。VOPには、各フレーム(MPEG-4
ビデオではVOPと呼ぶ)のデータが含まれている。VOP
は、図２２に示したVOPヘッダから始まり、図２５に示
される構造のマクロブロックデータが、フレームの上か
ら下、左から右の順で続く構造となっている。図２２が
VOPヘッダのデータ構造である。VOPスタートコードと呼
ばれる32ビットのユニークワードから始まる。vop_codi
ng_typeがVOPの符号化タイプ(I-VOP, P-VOP, B-VOP等)
を表し、それに続くmodulo_time_baseならびにvop_time
_incrementがそのVOPの出力時刻を示すタイムスタンプ
となっている。modulo_time_baseは秒単位の情報、vop_
time_incrementは秒以下の情報である。vop_time_incre
mentの精度に関する情報はVOLヘッダのvop_time_increm
ent_resolutionに示されている。modulo_time_base情報
は、前VOPの秒単位の値と現VOPの秒単位の値との変化分
を示す値で、その変化分の数だけ１が符号化される。つ
まり、秒単位の時刻が前のVOPと同じ場合には０が、1秒
分異なる場合には１０、２秒分異なる場合には１１０が
符号化されている。vop_time_increment情報は、各VOP
における秒以下の情報をvop_time_increment_resolutio
nが示す精度で示している。intra_dc_vlc_thrには、イ
ントラ符号化マクロブロックにおけるDCT係数のDC成分
が、AC成分とは異なる符号化デーブルで符号化されてい
るか、同じ符号化テーブルで符号化されているかを識別
するための情報が含まれている。このintra_dc_vlc_thr
の値と各マクロブロックにおけるDCT係数の量子化精度
から、いずれの符号化テーブルを用いるかがマクロブロ
ック単位で選択される。vop_quantは、DCT係数を量子化
する際の量子化精度を示す値であり、そのフレームの量
子化精度初期値となる。vop_fcode_forwardとvop_fcode
_backwardはMCにおける動き量の最大範囲を示してい
る。図２５がマクロブロックの基本データ構造 (I-VOP
とP-VOP)である。not_codedはP-VOPのみで使用される１
ビットのフラグで、以降にそのマクロブロックに関する
データが続いているかどうかを示している、０の場合に
は、そのマクロブロックに関するデータが続くことを意
味し、１の場合には、以降に続くデータが次のマクロブ
ロックに関するデータであり、そのマクロブロックの復
号信号は前フレームの同じ位置からコピーすることによ
り生成することを示している。mcbpcは1〜9ビットの可
変長符号であり、そのマクロブロックの符号化タイプを
示すmb_typeと、２個の各色差ブロック内に符号化すべ
き量子化DCT係数(０以外の値)があるか否かを示すcbpc
(イントラ符号化ブロックの場合には、量子化DCT係数の
AC成分があるか否かを示す)を１個の符号で表してい
る。mb_typeが示す符号化タイプには、intra, intra+q,
inter, inter+q, inter4v (inter4vは、輝度信号の動
き補償を行う単位が図２４の２１０１ではなく、２１０
１１から２１０１４の４個の小ブロック単位であること
を示す), stuffingの５種類があり、intraとintra+qが
イントラ符号化、inter、inter+qならびにinter4vが予
測符号化、stuffingは符号化レートを調整するためのダ
ミーデータであることを示している。＋ｑは、DCT係数
の量子化精度が前ブロックの値(quant)あるいは初期値
(vop_quant、フレームの最初の符号化マクロブロックに
適用)から変更されることを示している。なお、stuffin
gの場合には、図２５内のac_pred_flag以降のデータは
省略されており、復号されたmcbpcとnot_codedの値も再
生画像の合成には反映されない。ac_pred_flagは、mb_t
ypeがイントラ符号化であった場合のみ含まれる情報
で、DCT係数のAC成分に対して、周囲のブロックからの
予測を行うか否かを示す。この値が１の場合は、AC成分
の量子化再生値の一部が周囲のブロックからの差分値と
なっている。cbpyは１〜６ビットの可変長符号で、４個
の各輝度ブロック内に符号化された量子化DCT係数(０以
外の値)があるか否かを示している (cbpcと同様に、イ
ントラ符号化ブロックの場合には、量子化DCT係数のAC
成分があるか否かを示す)。dquantは、mb_typeがintra+
qあるいはinter+qであった場合にのみ存在し、前ブロッ
クの量子化精度の値からの差分値を示しており、quant+
dquantがそのマクロブロックのquantとなる。動きベク
トルの符号化に関する情報は、mb_typeが予測符号化の
場合のみ含まれる。Intra差分DC成分は、mb_typeがイン
トラ符号化であり、かつuse_intra_dc_vlcが１の場合に
のみ含まれる情報である。MPEG-4ビデオでは、イントラ
符号化ブロックにおけるDCT係数のDC成分は、周囲のマ
クロブロックにおけるDCT係数のDC成分との差分値が量
子化されている。量子化の方法もAC成分とは異なり、符
号化方法もAC成分とは別の方法が用意されている。但
し、use_intra_dc_vlcを０とすることによりDC成分の量
子化値もAC成分の量子化値と同様の符号化方法を適用す
ることが可能となる。なお、use_intra_dc_vlcの値は、
VOPヘッダにて定義されるintra_dc_vlc_thrと当該マク
ロブロックのquantにて決定される。Intra AC成分 or I
nter DC&AC成分に関しては、「cbpy, cbpcにて、DCTの
量子化係数に０以外の値が存在することが示されてい
る」ブロックのみ情報を持つ。
ビデオ符号化の基本的なデータ構造を示したものであ
る。図２１が全体のデータ構造、図２２がフレームヘッ
ダのデータ構造、図２５が各マクロブロックのデータ構
造を示している。図２１において、VOSヘッダはMPEG-4
ビデオ製品の適用範囲を決めるプロファイル・レベル情
報、VOヘッダはMPEG-4ビデオ符号化のデータ構造を決め
るバージョン情報、VOLヘッダは画像サイズ、符号化ビ
ットレート、フレームメモリサイズ、適用ツール等の情
報を含んでいる。いずれも受信した符号化データを復号
する上で必須の情報である。GOVヘッダには時刻情報が
含まれているが、これは必須の情報ではなく省略も可能
である。VOSヘッダ、VOヘッダ、VOLヘッダ、GOVヘッダ
とも32ビットのユニークワードから始まるため、容易に
検索できる。シーケンスの終了を示すEnd code of VOS
も32ビットのユニークワードである。これらのユニーク
ワードは、２３個の０と１個の１で始まり、その２４ビ
ットに続く２バイトのデータがその区切れの種類を示す
ような構造となっている。VOPには、各フレーム(MPEG-4
ビデオではVOPと呼ぶ)のデータが含まれている。VOP
は、図２２に示したVOPヘッダから始まり、図２５に示
される構造のマクロブロックデータが、フレームの上か
ら下、左から右の順で続く構造となっている。図２２が
VOPヘッダのデータ構造である。VOPスタートコードと呼
ばれる32ビットのユニークワードから始まる。vop_codi
ng_typeがVOPの符号化タイプ(I-VOP, P-VOP, B-VOP等)
を表し、それに続くmodulo_time_baseならびにvop_time
_incrementがそのVOPの出力時刻を示すタイムスタンプ
となっている。modulo_time_baseは秒単位の情報、vop_
time_incrementは秒以下の情報である。vop_time_incre
mentの精度に関する情報はVOLヘッダのvop_time_increm
ent_resolutionに示されている。modulo_time_base情報
は、前VOPの秒単位の値と現VOPの秒単位の値との変化分
を示す値で、その変化分の数だけ１が符号化される。つ
まり、秒単位の時刻が前のVOPと同じ場合には０が、1秒
分異なる場合には１０、２秒分異なる場合には１１０が
符号化されている。vop_time_increment情報は、各VOP
における秒以下の情報をvop_time_increment_resolutio
nが示す精度で示している。intra_dc_vlc_thrには、イ
ントラ符号化マクロブロックにおけるDCT係数のDC成分
が、AC成分とは異なる符号化デーブルで符号化されてい
るか、同じ符号化テーブルで符号化されているかを識別
するための情報が含まれている。このintra_dc_vlc_thr
の値と各マクロブロックにおけるDCT係数の量子化精度
から、いずれの符号化テーブルを用いるかがマクロブロ
ック単位で選択される。vop_quantは、DCT係数を量子化
する際の量子化精度を示す値であり、そのフレームの量
子化精度初期値となる。vop_fcode_forwardとvop_fcode
_backwardはMCにおける動き量の最大範囲を示してい
る。図２５がマクロブロックの基本データ構造 (I-VOP
とP-VOP)である。not_codedはP-VOPのみで使用される１
ビットのフラグで、以降にそのマクロブロックに関する
データが続いているかどうかを示している、０の場合に
は、そのマクロブロックに関するデータが続くことを意
味し、１の場合には、以降に続くデータが次のマクロブ
ロックに関するデータであり、そのマクロブロックの復
号信号は前フレームの同じ位置からコピーすることによ
り生成することを示している。mcbpcは1〜9ビットの可
変長符号であり、そのマクロブロックの符号化タイプを
示すmb_typeと、２個の各色差ブロック内に符号化すべ
き量子化DCT係数(０以外の値)があるか否かを示すcbpc
(イントラ符号化ブロックの場合には、量子化DCT係数の
AC成分があるか否かを示す)を１個の符号で表してい
る。mb_typeが示す符号化タイプには、intra, intra+q,
inter, inter+q, inter4v (inter4vは、輝度信号の動
き補償を行う単位が図２４の２１０１ではなく、２１０
１１から２１０１４の４個の小ブロック単位であること
を示す), stuffingの５種類があり、intraとintra+qが
イントラ符号化、inter、inter+qならびにinter4vが予
測符号化、stuffingは符号化レートを調整するためのダ
ミーデータであることを示している。＋ｑは、DCT係数
の量子化精度が前ブロックの値(quant)あるいは初期値
(vop_quant、フレームの最初の符号化マクロブロックに
適用)から変更されることを示している。なお、stuffin
gの場合には、図２５内のac_pred_flag以降のデータは
省略されており、復号されたmcbpcとnot_codedの値も再
生画像の合成には反映されない。ac_pred_flagは、mb_t
ypeがイントラ符号化であった場合のみ含まれる情報
で、DCT係数のAC成分に対して、周囲のブロックからの
予測を行うか否かを示す。この値が１の場合は、AC成分
の量子化再生値の一部が周囲のブロックからの差分値と
なっている。cbpyは１〜６ビットの可変長符号で、４個
の各輝度ブロック内に符号化された量子化DCT係数(０以
外の値)があるか否かを示している (cbpcと同様に、イ
ントラ符号化ブロックの場合には、量子化DCT係数のAC
成分があるか否かを示す)。dquantは、mb_typeがintra+
qあるいはinter+qであった場合にのみ存在し、前ブロッ
クの量子化精度の値からの差分値を示しており、quant+
dquantがそのマクロブロックのquantとなる。動きベク
トルの符号化に関する情報は、mb_typeが予測符号化の
場合のみ含まれる。Intra差分DC成分は、mb_typeがイン
トラ符号化であり、かつuse_intra_dc_vlcが１の場合に
のみ含まれる情報である。MPEG-4ビデオでは、イントラ
符号化ブロックにおけるDCT係数のDC成分は、周囲のマ
クロブロックにおけるDCT係数のDC成分との差分値が量
子化されている。量子化の方法もAC成分とは異なり、符
号化方法もAC成分とは別の方法が用意されている。但
し、use_intra_dc_vlcを０とすることによりDC成分の量
子化値もAC成分の量子化値と同様の符号化方法を適用す
ることが可能となる。なお、use_intra_dc_vlcの値は、
VOPヘッダにて定義されるintra_dc_vlc_thrと当該マク
ロブロックのquantにて決定される。Intra AC成分 or I
nter DC&AC成分に関しては、「cbpy, cbpcにて、DCTの
量子化係数に０以外の値が存在することが示されてい
る」ブロックのみ情報を持つ。
【００２５】上記で示した図２５のマクロブロックデー
タ構造では、伝送誤り等の影響で１度データの同期が失
われると、次フレームのスタートコードまでデータ同期
を回復することができない。そこで、MPEG-4ビデオ規格
では、誤り耐性用のデータ構造を別途用意している。具
体的には、ビデオパケットならびにデータ分割と呼ばれ
る処理が用意されており、VOLヘッダにてその適用が指
定される。ビデオパケットとは、数個のマクロブロック
を集めたデータ単位のことで、各ビデオパケットデータ
の先頭には同期マーカとフレーム内での位置情報を含む
ビデオパケットヘッダが配置されている。また、ブロッ
ク間でのデータの予測もパケット内で閉じている。その
ため、データ同期が失われた場合でも、その影響を１個
のパケット内にとどめることが可能で、次のビデオパケ
ットの先頭で同期を回復することも可能である。図２６
がビデオパケット分割の例である。図２６では、２３０
１，２３０２，２３０３，２３０４，２３０５の５個の
ビデオパケットに分割されている。フレームの第１パケ
ット２３０１を除く各パケットデータの先頭には、図２
８に示されるビデオパケットヘッダが配置され、フレー
ムの第１パケットについては、図２２のVOPヘッダが配
置される。パケットヘッダのデータ構造は、resync_mar
kerと呼ばれる同期マーカから始まる。この同期マーカ
は、１７〜２３ビットのユニークワードで、そのデータ
サイズはフレームの符号化タイプや動き補償時の動き量
の範囲から一意に決まるものである。macroblock_numbe
rはパケット内の先頭マクロブロックのフレーム内位置
を示すものである。この最初の２個のデータにより、同
期は完全に回復する。quant_scaleは、そのビデオパケ
ットにおけるDCT係数の量子化精度の初期値である。こ
の値が当該ビデオパケットの最初の符号化マクロブロッ
クに対する前マクロブロックのquantとして適用され
る。header_extension_codeは、modulo_time_baseからv
op_fcode_backwardまでのデータをビデオパケットヘッ
ダに含めるか否かを示すための１ビットのフラグで、１
の場合にはmodulo_time_base以降が含まれる。なお、mo
dulo_time_base以降のデータについては、VOPヘッダと
同じ値にすることが規定されており、VOPヘッダ内の情
報が伝送エラーの影響を受けているかどうかを調査する
等の役割を持つ。これに対してデータ分割とは、図２５
にて説明したマクロブロックのデータ構造にて示される
符号の位置をビデオパケット内で入れ替えることによ
り、各マクロブロックの重要データが伝送エラーにて解
読不能になる確率を減らす機能のことである。
タ構造では、伝送誤り等の影響で１度データの同期が失
われると、次フレームのスタートコードまでデータ同期
を回復することができない。そこで、MPEG-4ビデオ規格
では、誤り耐性用のデータ構造を別途用意している。具
体的には、ビデオパケットならびにデータ分割と呼ばれ
る処理が用意されており、VOLヘッダにてその適用が指
定される。ビデオパケットとは、数個のマクロブロック
を集めたデータ単位のことで、各ビデオパケットデータ
の先頭には同期マーカとフレーム内での位置情報を含む
ビデオパケットヘッダが配置されている。また、ブロッ
ク間でのデータの予測もパケット内で閉じている。その
ため、データ同期が失われた場合でも、その影響を１個
のパケット内にとどめることが可能で、次のビデオパケ
ットの先頭で同期を回復することも可能である。図２６
がビデオパケット分割の例である。図２６では、２３０
１，２３０２，２３０３，２３０４，２３０５の５個の
ビデオパケットに分割されている。フレームの第１パケ
ット２３０１を除く各パケットデータの先頭には、図２
８に示されるビデオパケットヘッダが配置され、フレー
ムの第１パケットについては、図２２のVOPヘッダが配
置される。パケットヘッダのデータ構造は、resync_mar
kerと呼ばれる同期マーカから始まる。この同期マーカ
は、１７〜２３ビットのユニークワードで、そのデータ
サイズはフレームの符号化タイプや動き補償時の動き量
の範囲から一意に決まるものである。macroblock_numbe
rはパケット内の先頭マクロブロックのフレーム内位置
を示すものである。この最初の２個のデータにより、同
期は完全に回復する。quant_scaleは、そのビデオパケ
ットにおけるDCT係数の量子化精度の初期値である。こ
の値が当該ビデオパケットの最初の符号化マクロブロッ
クに対する前マクロブロックのquantとして適用され
る。header_extension_codeは、modulo_time_baseからv
op_fcode_backwardまでのデータをビデオパケットヘッ
ダに含めるか否かを示すための１ビットのフラグで、１
の場合にはmodulo_time_base以降が含まれる。なお、mo
dulo_time_base以降のデータについては、VOPヘッダと
同じ値にすることが規定されており、VOPヘッダ内の情
報が伝送エラーの影響を受けているかどうかを調査する
等の役割を持つ。これに対してデータ分割とは、図２５
にて説明したマクロブロックのデータ構造にて示される
符号の位置をビデオパケット内で入れ替えることによ
り、各マクロブロックの重要データが伝送エラーにて解
読不能になる確率を減らす機能のことである。
【００２６】図２７は、フレームタイプがI-VOPの場合
について、ビデオパケット内のデータ分割構造を示した
ものである。図２７におけるビデオパケットヘッダ２４
０１のデータ構造は、図２８に示したとおりである。図
２９は、図２７の優先データ部２４０２に配置されるデ
ータについて、１マクロブロック分の優先データ部のデ
ータ構造２４０２１を示したものである。この図２９の
データは、図２５に示したマクロブロックデータから再
生ブロックを合成する上で重要なデータのみを抜き出し
たものと言える。図２７の優先データ部２４０２には、
ビデオパケット内の各マクロブロックについて図２９に
示したデータ)のみを抜き出し、順次配置される。但
し、dquantとIntra差分DC成分については、図中に示し
た条件が成立しているマクロブロックのみに存在する。
図２７のdc_marker２４０３は１９ビットのユニークワ
ードである。図３０は、図２７のAC成分制御情報2404に
配置されるデータについて、１マクロブロック分のAC成
分制御情報部のデータ構造２４０４１を示したものであ
る。図３１は、図２７のAC成分情報２４０５に配置され
るデータについて、１マクロブロック分のAC成分情報部
のデータ構造２４０５１を示したものである。いずれ
も、ビデオパケット内の各マクロブロックについて、図
２５に示したマクロブロックデータから図２９または図
３０に示したデータのみを抜き出し、順次配置される。
但し、各マクロブロックにおけるAC成分情報の存在はcb
py, cbpcの値に依存して変化する。このような構造を持
つことにより、２４０４あるいは２４０５にて伝送誤り
が発生しても、dc_markerの復号にて、優先データ部２
４０２が同期崩れなく復号されていることが判定できる
ようになる。これにより、優先データ部のデータのみを
用いて、当該ビデオパケット内の全マクロブロックにつ
いて、大まかな特徴を持つブロック画像を合成すること
が可能となる。また、優先データ部２４０２にて伝送誤
りが発生しても、dc_markerを検索することにより、ビ
デオパケット内で同期を回復させることも可能である。
但し、優先データ部のデータが壊れているとAC成分制御
情報部２４０４とAC成分情報部２４０５に伝送エラーが
無い場合であっても、mb_type, cbpcならびにdquant等
の情報が使えないため、必ずしも正確に復号できるとは
限らない。
について、ビデオパケット内のデータ分割構造を示した
ものである。図２７におけるビデオパケットヘッダ２４
０１のデータ構造は、図２８に示したとおりである。図
２９は、図２７の優先データ部２４０２に配置されるデ
ータについて、１マクロブロック分の優先データ部のデ
ータ構造２４０２１を示したものである。この図２９の
データは、図２５に示したマクロブロックデータから再
生ブロックを合成する上で重要なデータのみを抜き出し
たものと言える。図２７の優先データ部２４０２には、
ビデオパケット内の各マクロブロックについて図２９に
示したデータ)のみを抜き出し、順次配置される。但
し、dquantとIntra差分DC成分については、図中に示し
た条件が成立しているマクロブロックのみに存在する。
図２７のdc_marker２４０３は１９ビットのユニークワ
ードである。図３０は、図２７のAC成分制御情報2404に
配置されるデータについて、１マクロブロック分のAC成
分制御情報部のデータ構造２４０４１を示したものであ
る。図３１は、図２７のAC成分情報２４０５に配置され
るデータについて、１マクロブロック分のAC成分情報部
のデータ構造２４０５１を示したものである。いずれ
も、ビデオパケット内の各マクロブロックについて、図
２５に示したマクロブロックデータから図２９または図
３０に示したデータのみを抜き出し、順次配置される。
但し、各マクロブロックにおけるAC成分情報の存在はcb
py, cbpcの値に依存して変化する。このような構造を持
つことにより、２４０４あるいは２４０５にて伝送誤り
が発生しても、dc_markerの復号にて、優先データ部２
４０２が同期崩れなく復号されていることが判定できる
ようになる。これにより、優先データ部のデータのみを
用いて、当該ビデオパケット内の全マクロブロックにつ
いて、大まかな特徴を持つブロック画像を合成すること
が可能となる。また、優先データ部２４０２にて伝送誤
りが発生しても、dc_markerを検索することにより、ビ
デオパケット内で同期を回復させることも可能である。
但し、優先データ部のデータが壊れているとAC成分制御
情報部２４０４とAC成分情報部２４０５に伝送エラーが
無い場合であっても、mb_type, cbpcならびにdquant等
の情報が使えないため、必ずしも正確に復号できるとは
限らない。
【００２７】図３２は、フレームタイプがP-VOPの場合
について、ビデオパケット内のデータ分割構造を示した
ものである。図３２におけるビデオパケットヘッダ２４
０１のデータ構造は、図２８に示したとおりである。図
３３は、図３２の優先データ部２９０２に配置されるデ
ータについて、１マクロブロック分の優先データ部のデ
ータ構造２９０２１を示したものである。この図３３の
データは、図２５に示したマクロブロックデータから再
生ブロックを合成する上で重要なデータのみを抜き出し
たものと言える。図３２の優先データ部２９０２には、
ビデオパケット内の各マクロブロックについて、図３３
に示したデータのみを抜き出し、順次配置される。但
し、not_codedの値が１のマクロブロックについては、m
cbpcと動きベクトル情報は省略される。また、mb_type
がイントラ符号化あるいはstuffingのマクロブロックに
ついては、動きベクトル情報は省略される。図３２のmo
tion_marker２９０３は１７ビットのユニークワードで
ある。図３４は、図３２のIntra差分DC成分情報&AC成分
制御情報２９０４に配置されるデータについて、１マク
ロブロック分のIntra差分DC成分情報&AC成分制御情報の
データ構造２９０４１を示したものである。図３５は、
図３２のIntra AC成分 or Inter DC&AC成分情報２９０
５に配置されるデータについて、１マクロブロック分の
Intra AC成分 or Inter DC&AC成分情報のデータ構造２
９０５１を示したものである。いずれも、ビデオパケッ
ト内の各マクロブロックについて、図２５に示したマク
ロブロックデータから図３４または図３５に示したデー
タのみを抜き出し、順次配置される。但し、not_coded
が１のマクロブロックについては、マクロブロック内に
図３４ならびに図３５に示すデータが存在しないため、
省略される。また、各マクロブロックにおけるIntra差
分DC成分情報&AC成分制御情報２９０４１内のac_pred_f
lag, dquantならびにIntra差分DC成分については、図中
に示した条件が成立しているマクロブロックのみに存在
する。さらに、各マクロブロックにおけるIntra AC成分
(mb_typeがイントラ符号化の場合) or Inter DC&AC成分
情報 (mb_typeが予測符号化の場合)の存在はcbpy, cbpc
に依存して変化する。
について、ビデオパケット内のデータ分割構造を示した
ものである。図３２におけるビデオパケットヘッダ２４
０１のデータ構造は、図２８に示したとおりである。図
３３は、図３２の優先データ部２９０２に配置されるデ
ータについて、１マクロブロック分の優先データ部のデ
ータ構造２９０２１を示したものである。この図３３の
データは、図２５に示したマクロブロックデータから再
生ブロックを合成する上で重要なデータのみを抜き出し
たものと言える。図３２の優先データ部２９０２には、
ビデオパケット内の各マクロブロックについて、図３３
に示したデータのみを抜き出し、順次配置される。但
し、not_codedの値が１のマクロブロックについては、m
cbpcと動きベクトル情報は省略される。また、mb_type
がイントラ符号化あるいはstuffingのマクロブロックに
ついては、動きベクトル情報は省略される。図３２のmo
tion_marker２９０３は１７ビットのユニークワードで
ある。図３４は、図３２のIntra差分DC成分情報&AC成分
制御情報２９０４に配置されるデータについて、１マク
ロブロック分のIntra差分DC成分情報&AC成分制御情報の
データ構造２９０４１を示したものである。図３５は、
図３２のIntra AC成分 or Inter DC&AC成分情報２９０
５に配置されるデータについて、１マクロブロック分の
Intra AC成分 or Inter DC&AC成分情報のデータ構造２
９０５１を示したものである。いずれも、ビデオパケッ
ト内の各マクロブロックについて、図２５に示したマク
ロブロックデータから図３４または図３５に示したデー
タのみを抜き出し、順次配置される。但し、not_coded
が１のマクロブロックについては、マクロブロック内に
図３４ならびに図３５に示すデータが存在しないため、
省略される。また、各マクロブロックにおけるIntra差
分DC成分情報&AC成分制御情報２９０４１内のac_pred_f
lag, dquantならびにIntra差分DC成分については、図中
に示した条件が成立しているマクロブロックのみに存在
する。さらに、各マクロブロックにおけるIntra AC成分
(mb_typeがイントラ符号化の場合) or Inter DC&AC成分
情報 (mb_typeが予測符号化の場合)の存在はcbpy, cbpc
に依存して変化する。
【００２８】図３６に、データ修正処理部７０７での処
理をビデオパケットならびにデータ分割の機能を用いた
データを例として示す。最初に、図１８のエラー・同期
マーカ検出部７０１から、データ検索の結果が同期マー
カ(各種スタートコードあるいはresync_marker)あるい
はエラー検出用埋め込みデータのいずれであったかを示
す識別情報７１３を受け、検出結果が同期マーカであっ
たか否かを判定する（ステップ３３０１）。検出結果が
同期マーカであった場合には、検索開始位置から検出位
置までのデータ、すなわち１ビデオパケット分のデータ
が、図１８のエラー・同期マーカ検出部７０１からスイ
ッチ７０５に通知される制御情報７０４により第２メモ
リ７１０に出力される。データ処理部７０７では、第２
メモリ７１０へ入力されたデータを保存することを示す
情報を通知し、処理を終了する（ステップ３３１３）。
一方、検出結果がエラー検出用埋め込みデータであった
場合には、図１８のエラー・同期マーカ検出部７０１か
らスイッチ７０５に通知される制御情報７０４により、
検索開始位置から次の同期マーカまでのメディアデータ
２０８がメモリ２０７からデータ修正処理部７０７に得
られる（ステップ３３０２）。次に、データ処理部７０
７では、獲得したメディアデータ２０８を解析し、エラ
ー区間をチェックする。チェックは、エラー区間がVOL
ヘッダを含むか？（ステップ３３０３）、ステップ３３
０３でVOLヘッダを含んでいない場合、エラー区間がVOP
ヘッダを含むか？（ステップ３３０４）、ステップ３３
０４でVOPヘッダを含んでいない場合、エラー区間がビ
デオパケットヘッダ内のマクロブロック位置データ(図
２８のmacroblock_number)を含むか？（ステップ３３０
５）、ステップ３３０３でVOLヘッダを含んでいた場
合、そのVOLヘッダは再送ヘッダであるか？（ステップ
３３０６）、ステップ３３０４でVOPヘッダを含んでい
た場合、vop_coding_typeがB-VOPであるか？（ステップ
３３０７）の５つで行う。ここでステップ３３０７につ
いては、VOPヘッダ内のvop_coding_type情報がエラー区
間に含まれていた場合、当該フレーム内のパケットヘッ
ダに含まれるvop_coding_type情報(図２８のvop_coding
_type)をこの判定に利用してもよい。エラー区間チェッ
クの結果、ステップ３３０６にて、エラー区間が再送VO
Lヘッダを含むと判定される場合には、VOSヘッダ、VOヘ
ッダならびにVOLヘッダの組み合わせを捨てることを示
すエラー修正情報７０８を図１８の第２のメモリ７１０
に通知し、処理を終了する（ステップ３３１５）。この
際、VOSヘッダ、VOヘッダが既に第２のメモリ７１０に
移動している場合には、第２のメモリはエラー修正情報
７０８に応じて、対応するヘッダ情報を削除する。エラ
ー区間チェックの結果、4)にて、エラー区間がシーン先
頭のVOLヘッダを含むと判定される場合には、エラーを
含まない次のVOLヘッダまでのメディアデータがデータ
修正処理部７０７に入力されるようにスイッチ制御情報
７１２を制御し、図１８のスイッチ７０５に通知する
（ステップ３３１４）。そして、次のVOLヘッダまでの
情報を削除し、VOLヘッダ情報のみをエラー修正情報７
０８として第２のメモリに渡す。また、VOLヘッダ後のV
OPがI-VOPでない場合には、次のI-VOPまでのメディアデ
ータがデータ修正処理部７０７に入力されるようにスイ
ッチ制御情報７１２を制御し、スイッチ７０５に通知す
る。そして、シーン先頭のVOLヘッダに続くVOPの種類が
I-VOPとなるようにデータの削除を行う。エラー区間チ
ェックの結果、ステップ３３０７にて、vop_coding_typ
eがB-VOPであると判定できる場合には、次のVOPヘッダ
までのメディアデータがデータ修正処理部７０７に入力
されるように、スイッチ制御情報７１２を図１８のスイ
ッチ７０５に通知し、次のスタートコードまでのデータ
を削除する（ステップ３３１５）。エラー区間チェック
の結果、5)にて、vop_coding_typeがB-VOPでないと判断
できる場合には、以下の（１）から（４）の処理をおこ
なう（ステップ３３１７）。 (1) 次のヘッダ情報付き同期マーカあるいはスタートコ
ードまでのデータを捨てるようにスイッチ制御情報７１
２を制御し、スイッチ７０５に通知する。 (2) 現マクロブロックの位置(macroblock_number)を０
とする。 (3) ヘッダ情報付き同期マーカがフレーム内に含まれる
場合、ヘッダ情報からVOPヘッダを生成する。 (4) ヘッダ情報付き同期マーカがフレーム内に含まれて
いない場合、vop_codedを０としてVOPヘッダを作成す
る。次フレームのvop_time_incrementの値が、前フレー
ムよりも小さい場合には、modulo_time_baseを１０と
し、vop_time_incrementを０とする。それ以外の場合に
は、modulo_time_baseを０とし、vop_time_incrementを
前フレームの値に1を加えた値とする。なお、処理(3)、
(4)に示すヘッダ情報付き同期マーカの検索の際には、
メモリ２０７内のメディアデータ２０８を利用する。処
理(4)を実行した場合には、修正データの終端部にバイ
トアライン処理を施し（ステップ３３１１）、第２のメ
モリ７１０にバイトアライン化した修正データ７０８を
出力して、処理を終了する（ステップ３３１２）。エラ
ー区間チェックの結果、ステップ３３０５にて、エラー
区間がビデオパケットヘッダ内のマクロブロック位置デ
ータを含んでいた場合、第２のメモリから前ビデオパケ
ット(VP)の処理済みデータ７０９を読み込み、前VPヘッ
ダ内のmacroblock_numberと前VPの符号化MB数を調査す
る（ステップ３３１６）。この処理により、当該VPヘッ
ダのmacroblock_numberを再現することが可能となる。
理をビデオパケットならびにデータ分割の機能を用いた
データを例として示す。最初に、図１８のエラー・同期
マーカ検出部７０１から、データ検索の結果が同期マー
カ(各種スタートコードあるいはresync_marker)あるい
はエラー検出用埋め込みデータのいずれであったかを示
す識別情報７１３を受け、検出結果が同期マーカであっ
たか否かを判定する（ステップ３３０１）。検出結果が
同期マーカであった場合には、検索開始位置から検出位
置までのデータ、すなわち１ビデオパケット分のデータ
が、図１８のエラー・同期マーカ検出部７０１からスイ
ッチ７０５に通知される制御情報７０４により第２メモ
リ７１０に出力される。データ処理部７０７では、第２
メモリ７１０へ入力されたデータを保存することを示す
情報を通知し、処理を終了する（ステップ３３１３）。
一方、検出結果がエラー検出用埋め込みデータであった
場合には、図１８のエラー・同期マーカ検出部７０１か
らスイッチ７０５に通知される制御情報７０４により、
検索開始位置から次の同期マーカまでのメディアデータ
２０８がメモリ２０７からデータ修正処理部７０７に得
られる（ステップ３３０２）。次に、データ処理部７０
７では、獲得したメディアデータ２０８を解析し、エラ
ー区間をチェックする。チェックは、エラー区間がVOL
ヘッダを含むか？（ステップ３３０３）、ステップ３３
０３でVOLヘッダを含んでいない場合、エラー区間がVOP
ヘッダを含むか？（ステップ３３０４）、ステップ３３
０４でVOPヘッダを含んでいない場合、エラー区間がビ
デオパケットヘッダ内のマクロブロック位置データ(図
２８のmacroblock_number)を含むか？（ステップ３３０
５）、ステップ３３０３でVOLヘッダを含んでいた場
合、そのVOLヘッダは再送ヘッダであるか？（ステップ
３３０６）、ステップ３３０４でVOPヘッダを含んでい
た場合、vop_coding_typeがB-VOPであるか？（ステップ
３３０７）の５つで行う。ここでステップ３３０７につ
いては、VOPヘッダ内のvop_coding_type情報がエラー区
間に含まれていた場合、当該フレーム内のパケットヘッ
ダに含まれるvop_coding_type情報(図２８のvop_coding
_type)をこの判定に利用してもよい。エラー区間チェッ
クの結果、ステップ３３０６にて、エラー区間が再送VO
Lヘッダを含むと判定される場合には、VOSヘッダ、VOヘ
ッダならびにVOLヘッダの組み合わせを捨てることを示
すエラー修正情報７０８を図１８の第２のメモリ７１０
に通知し、処理を終了する（ステップ３３１５）。この
際、VOSヘッダ、VOヘッダが既に第２のメモリ７１０に
移動している場合には、第２のメモリはエラー修正情報
７０８に応じて、対応するヘッダ情報を削除する。エラ
ー区間チェックの結果、4)にて、エラー区間がシーン先
頭のVOLヘッダを含むと判定される場合には、エラーを
含まない次のVOLヘッダまでのメディアデータがデータ
修正処理部７０７に入力されるようにスイッチ制御情報
７１２を制御し、図１８のスイッチ７０５に通知する
（ステップ３３１４）。そして、次のVOLヘッダまでの
情報を削除し、VOLヘッダ情報のみをエラー修正情報７
０８として第２のメモリに渡す。また、VOLヘッダ後のV
OPがI-VOPでない場合には、次のI-VOPまでのメディアデ
ータがデータ修正処理部７０７に入力されるようにスイ
ッチ制御情報７１２を制御し、スイッチ７０５に通知す
る。そして、シーン先頭のVOLヘッダに続くVOPの種類が
I-VOPとなるようにデータの削除を行う。エラー区間チ
ェックの結果、ステップ３３０７にて、vop_coding_typ
eがB-VOPであると判定できる場合には、次のVOPヘッダ
までのメディアデータがデータ修正処理部７０７に入力
されるように、スイッチ制御情報７１２を図１８のスイ
ッチ７０５に通知し、次のスタートコードまでのデータ
を削除する（ステップ３３１５）。エラー区間チェック
の結果、5)にて、vop_coding_typeがB-VOPでないと判断
できる場合には、以下の（１）から（４）の処理をおこ
なう（ステップ３３１７）。 (1) 次のヘッダ情報付き同期マーカあるいはスタートコ
ードまでのデータを捨てるようにスイッチ制御情報７１
２を制御し、スイッチ７０５に通知する。 (2) 現マクロブロックの位置(macroblock_number)を０
とする。 (3) ヘッダ情報付き同期マーカがフレーム内に含まれる
場合、ヘッダ情報からVOPヘッダを生成する。 (4) ヘッダ情報付き同期マーカがフレーム内に含まれて
いない場合、vop_codedを０としてVOPヘッダを作成す
る。次フレームのvop_time_incrementの値が、前フレー
ムよりも小さい場合には、modulo_time_baseを１０と
し、vop_time_incrementを０とする。それ以外の場合に
は、modulo_time_baseを０とし、vop_time_incrementを
前フレームの値に1を加えた値とする。なお、処理(3)、
(4)に示すヘッダ情報付き同期マーカの検索の際には、
メモリ２０７内のメディアデータ２０８を利用する。処
理(4)を実行した場合には、修正データの終端部にバイ
トアライン処理を施し（ステップ３３１１）、第２のメ
モリ７１０にバイトアライン化した修正データ７０８を
出力して、処理を終了する（ステップ３３１２）。エラ
ー区間チェックの結果、ステップ３３０５にて、エラー
区間がビデオパケットヘッダ内のマクロブロック位置デ
ータを含んでいた場合、第２のメモリから前ビデオパケ
ット(VP)の処理済みデータ７０９を読み込み、前VPヘッ
ダ内のmacroblock_numberと前VPの符号化MB数を調査す
る（ステップ３３１６）。この処理により、当該VPヘッ
ダのmacroblock_numberを再現することが可能となる。
【００２９】エラー区間処理にて、ステップ３３０３と
ステップ３３０４の処理を満たさない場合と、ステップ
３３０７にてVOP符号化タイプがB-VOPではないと判定で
き、かつステップ３３１７の処理にて処理(3)を実行し
た場合については、マクロブロックデータの修正処理を
行う。まず、ステップ３３０３とステップ３３０４の処
理を満たさない場合については、当該ビデオパケットの
第１MBの位置(macroblock_number)を検出する（ステッ
プ３３０８）。ステップ３３０４を満たす場合に関して
は、ステップ３３１７の処理(2)において、当該ビデオ
パケットの第１MBの位置を0と設定しているため、ステ
ップ３３０８は省略できる。次に、メモリ２０７内のメ
ディアデータ２０８を検索し、次VPの第１MBの位置、す
なわち当該VP内における処理MB数を検出する（ステップ
３３０９）。なお、検索の結果、次VPのresync_marker
の前にスタートコードが検出された場合には、当該VPの
最終MBが当該VOPの最終MBであると判定する。そして、
ビデオパケット内の符号化マクロブロック数情報とビデ
オパケット内のメディアデータ２０８を用いて、図３７
に示すマクロブロックデータ修正処理３３１０を実行す
る。最後に修正データの終端部にバイトアライン処理３
３１１を施し、第２のメモリ７１０にバイトアライン化
した修正データ７０８を出力して、処理を終了する（ス
テップ３３１２）。
ステップ３３０４の処理を満たさない場合と、ステップ
３３０７にてVOP符号化タイプがB-VOPではないと判定で
き、かつステップ３３１７の処理にて処理(3)を実行し
た場合については、マクロブロックデータの修正処理を
行う。まず、ステップ３３０３とステップ３３０４の処
理を満たさない場合については、当該ビデオパケットの
第１MBの位置(macroblock_number)を検出する（ステッ
プ３３０８）。ステップ３３０４を満たす場合に関して
は、ステップ３３１７の処理(2)において、当該ビデオ
パケットの第１MBの位置を0と設定しているため、ステ
ップ３３０８は省略できる。次に、メモリ２０７内のメ
ディアデータ２０８を検索し、次VPの第１MBの位置、す
なわち当該VP内における処理MB数を検出する（ステップ
３３０９）。なお、検索の結果、次VPのresync_marker
の前にスタートコードが検出された場合には、当該VPの
最終MBが当該VOPの最終MBであると判定する。そして、
ビデオパケット内の符号化マクロブロック数情報とビデ
オパケット内のメディアデータ２０８を用いて、図３７
に示すマクロブロックデータ修正処理３３１０を実行す
る。最後に修正データの終端部にバイトアライン処理３
３１１を施し、第２のメモリ７１０にバイトアライン化
した修正データ７０８を出力して、処理を終了する（ス
テップ３３１２）。
【００３０】次に、図３７のマクロブロックデータ修正
処理３３１０について説明する。パケット内の各マクロ
ブロックのデータ修正方法として、本明細書では以下の
３つの方法を用いることにする。 処理Ｉ：not_codedフラグを１とする。MB内の元データ
は削除。 処理ＩＩ：MB内の差分DC成分を全て０とし、mb_typeを
「intra」、cpby, cbpcを符号化ブロックなしに設定す
る。ＭＢ内の元データは削除。 処理ＩＩＩ：cpby, cbpcを符号化ブロックなしに設定す
る。さらに、I-VOPの場合には、ac_pred_flagを０と
し、AC成分データは削除する。P-VOPの場合には、mb_ty
peがイントラ符号化(intra, intra+q)のときは処理I、m
b_typeが予測符号化(inter, inter+q, inter4v)のとき
は、Inter DC&AC成分データを削除する。 処理方法の選択手順は、図２７あるいは図３２のどの部
分でエラーが発生しているかによって決める。そこで、
入力されたビデオパケット内のメディアデータ２０８を
チェックし、エラー区間を、エラー区間がビデオパケッ
トヘッダ(図２７の２４０１あるいは図３２の２４０１)
を含むか？（ステップ３４０１）、ステップ３４０１で
ビデオパケットヘッダを含んでいない場合、エラー区間
が優先データ部(図２７の２４０２あるいは図３２の２
９０２)を含むか？（ステップ３４０３）、ステップ３
４０３でビデオパケットヘッダを含んでいる場合、エラ
ー区間が中間マーカ(図２７の２４０３あるいは図３２
の２９０３)を含んでいるか？（ステップ３４０４）の
ように３つのステップでチェックする。
処理３３１０について説明する。パケット内の各マクロ
ブロックのデータ修正方法として、本明細書では以下の
３つの方法を用いることにする。 処理Ｉ：not_codedフラグを１とする。MB内の元データ
は削除。 処理ＩＩ：MB内の差分DC成分を全て０とし、mb_typeを
「intra」、cpby, cbpcを符号化ブロックなしに設定す
る。ＭＢ内の元データは削除。 処理ＩＩＩ：cpby, cbpcを符号化ブロックなしに設定す
る。さらに、I-VOPの場合には、ac_pred_flagを０と
し、AC成分データは削除する。P-VOPの場合には、mb_ty
peがイントラ符号化(intra, intra+q)のときは処理I、m
b_typeが予測符号化(inter, inter+q, inter4v)のとき
は、Inter DC&AC成分データを削除する。 処理方法の選択手順は、図２７あるいは図３２のどの部
分でエラーが発生しているかによって決める。そこで、
入力されたビデオパケット内のメディアデータ２０８を
チェックし、エラー区間を、エラー区間がビデオパケッ
トヘッダ(図２７の２４０１あるいは図３２の２４０１)
を含むか？（ステップ３４０１）、ステップ３４０１で
ビデオパケットヘッダを含んでいない場合、エラー区間
が優先データ部(図２７の２４０２あるいは図３２の２
９０２)を含むか？（ステップ３４０３）、ステップ３
４０３でビデオパケットヘッダを含んでいる場合、エラ
ー区間が中間マーカ(図２７の２４０３あるいは図３２
の２９０３)を含んでいるか？（ステップ３４０４）の
ように３つのステップでチェックする。
【００３１】ステップ３４０１にて、エラー区間がビデ
オパケットヘッダを含むと判断される場合には、ステッ
プ３４０２処理を実行し、処理を終了する。具体的に
は、まず、図３６のステップ３３０８の処理で検出した
第１MBの位置に従って、ビデオパケットヘッダ部を修正
する。その際、quant_scaleがエラー区間に含まれてい
た場合には、前VPパケットと同じ値に定める。次に、ビ
デオパケット内の各MBについてデータを生成する。生成
方法としては、VOPの符号化タイプがI-VOPの場合には処
理ＩＩ、P-VOPの場合には処理Ｉの方法を利用する。さ
らに、優先データ部の後に中間マーカ(I-VOPの場合には
dc_marker、P-VOPの場合にはmotion_marker)を追加す
る。なお、このケースでは、パケット内の元のデータは
全て廃棄し、修正データのみ出力する。
オパケットヘッダを含むと判断される場合には、ステッ
プ３４０２処理を実行し、処理を終了する。具体的に
は、まず、図３６のステップ３３０８の処理で検出した
第１MBの位置に従って、ビデオパケットヘッダ部を修正
する。その際、quant_scaleがエラー区間に含まれてい
た場合には、前VPパケットと同じ値に定める。次に、ビ
デオパケット内の各MBについてデータを生成する。生成
方法としては、VOPの符号化タイプがI-VOPの場合には処
理ＩＩ、P-VOPの場合には処理Ｉの方法を利用する。さ
らに、優先データ部の後に中間マーカ(I-VOPの場合には
dc_marker、P-VOPの場合にはmotion_marker)を追加す
る。なお、このケースでは、パケット内の元のデータは
全て廃棄し、修正データのみ出力する。
【００３２】ステップ３４０３にて、エラー区間が優先
データを含まないと判断される場合には、ステップ３４
０７の処理を実行し、処理を終了する。具体的には、DC
Tデータ部(図２７の２４０４と２４０５、あるいは図３
２の２９０４と２９０５)が正常なMBについては、優先
データ部ならびにDCTデータ部のデータをそのまま保存
する。DCTデータ部がエラー区間に含まれているMBにつ
いては、処理ＩＩＩの方法でデータを修正する。なお、
次のVPヘッダのresync_markerがエラー区間に含まれて
いる場合には、図３６のステップ３３０９の処理にて検
出したVPは、実際には２つ後のVPとなり、次VP内のMBも
当該VP内のMBとして扱う必要が生じる。このように優先
データ部の情報がないMBについては、VOPの符号化タイ
プがI-VOPなら処理ＩＩ、P-VOPなら処理Ｉを用いて優先
データ部ならびにAC成分制御情報部(I-VOPの場合のみ)
のMBデータを生成し、優先データ部の直後に中間マーカ
を挿入する。
データを含まないと判断される場合には、ステップ３４
０７の処理を実行し、処理を終了する。具体的には、DC
Tデータ部(図２７の２４０４と２４０５、あるいは図３
２の２９０４と２９０５)が正常なMBについては、優先
データ部ならびにDCTデータ部のデータをそのまま保存
する。DCTデータ部がエラー区間に含まれているMBにつ
いては、処理ＩＩＩの方法でデータを修正する。なお、
次のVPヘッダのresync_markerがエラー区間に含まれて
いる場合には、図３６のステップ３３０９の処理にて検
出したVPは、実際には２つ後のVPとなり、次VP内のMBも
当該VP内のMBとして扱う必要が生じる。このように優先
データ部の情報がないMBについては、VOPの符号化タイ
プがI-VOPなら処理ＩＩ、P-VOPなら処理Ｉを用いて優先
データ部ならびにAC成分制御情報部(I-VOPの場合のみ)
のMBデータを生成し、優先データ部の直後に中間マーカ
を挿入する。
【００３３】ステップ３４０４にて、エラー区間が中間
マーカを含んでいると判断される場合には、ステップ３
４０５の処理を実行し、処理を終了する。具体的には、
優先データ部が正常なMBについては処理ＩＩＩ、優先デ
ータ部がエラー区間に含まれているI-VOP上のMBについ
ては処理ＩＩ、優先データ部がエラー区間に含まれてい
るP-VOP上のMBについては処理Ｉの方法でデータを修正
する。さらに、優先データ部の直後に中間マーカ(I-VOP
の場合にはdc_marker、P-VOPの場合にはmotion_marker)
を挿入する。
マーカを含んでいると判断される場合には、ステップ３
４０５の処理を実行し、処理を終了する。具体的には、
優先データ部が正常なMBについては処理ＩＩＩ、優先デ
ータ部がエラー区間に含まれているI-VOP上のMBについ
ては処理ＩＩ、優先データ部がエラー区間に含まれてい
るP-VOP上のMBについては処理Ｉの方法でデータを修正
する。さらに、優先データ部の直後に中間マーカ(I-VOP
の場合にはdc_marker、P-VOPの場合にはmotion_marker)
を挿入する。
【００３４】ステップ３４０４にて、エラー区間が中間
マーカを含まないと判断される場合には、ステップ３４
０６の処理を実行し、処理を終了する。具体的には、優
先データ部、DCTデータ部共に正常なMBについては、優
先データ部ならびにDCTデータ部のデータをそのまま保
存する。優先データ部のみエラー区間に含まれているMB
については、VOPの符号化タイプがI-VOPなら処理ＩＩ、
P-VOPなら処理Ｉを用いて優先データ部ならびにAC成分
制御情報部(I-VOPの場合のみ)のMBデータを修正する。D
CTデータ部のみがエラー区間に含まれているMBについて
は、処理ＩＩＩの方法でデータを修正する。なお、次の
VPヘッダのresync_markerまでがエラー区間に含まれて
いる場合には、図３６のステップ３３０９の処理にて検
出したVPは、実際には２つ後のVPとなり、次VP内のMBも
当該VP内のMBとして扱う必要が生じる。このような優先
データ部情報がないMBについては、VOPの符号化タイプ
がI-VOPなら処理ＩＩ、P-VOPなら処理Ｉを用いて優先デ
ータ部ならびにAC成分制御情報部(I-VOPの場合のみ)のM
Bデータを生成する。
マーカを含まないと判断される場合には、ステップ３４
０６の処理を実行し、処理を終了する。具体的には、優
先データ部、DCTデータ部共に正常なMBについては、優
先データ部ならびにDCTデータ部のデータをそのまま保
存する。優先データ部のみエラー区間に含まれているMB
については、VOPの符号化タイプがI-VOPなら処理ＩＩ、
P-VOPなら処理Ｉを用いて優先データ部ならびにAC成分
制御情報部(I-VOPの場合のみ)のMBデータを修正する。D
CTデータ部のみがエラー区間に含まれているMBについて
は、処理ＩＩＩの方法でデータを修正する。なお、次の
VPヘッダのresync_markerまでがエラー区間に含まれて
いる場合には、図３６のステップ３３０９の処理にて検
出したVPは、実際には２つ後のVPとなり、次VP内のMBも
当該VP内のMBとして扱う必要が生じる。このような優先
データ部情報がないMBについては、VOPの符号化タイプ
がI-VOPなら処理ＩＩ、P-VOPなら処理Ｉを用いて優先デ
ータ部ならびにAC成分制御情報部(I-VOPの場合のみ)のM
Bデータを生成する。
【００３５】ここまで述べてきたように、データのエラ
ー修正機能はスタートコード、同期マーカならびに中間
マーカを起点として行われる。従って、これらのユニー
クワードを区切りとし、例えば、中間マーカとDCTデー
タ部が１個のパケットに含まれないように、送信側で伝
送パケットを構成しておくことで、本発明にて述べてい
る方法はより有効に機能する。本発明には次のような場
合も含まれる。１つめは、本発明のエラー検出用埋め込
みデータの埋め込み方法は、パケットロスを伴う通信手
段で利用でき、かつ各パケット内のヘッダ部にそのパケ
ットのシーケンス番号(パケットを合成する順番)が含ま
れているプロトコルであれば、送信端末とのコネクショ
ンレス型、コネクション型に関わらず適用可能である。
よって、本発明のエラー検出用埋め込みデータの埋め込
み方法は、本明細書で示したTCPとUDP/RTPに特化するも
のではない。また、回線交換方式であっても、決まった
区切りで伝送エラーを修正するため、アプリケーション
デコーダへの出力にエラー修正結果を反映させることが
可能である。このように、受信データの特定部分に通信
エラーが発生していると判定できる場合には本発明のエ
ラー検出用データ埋め込み方法は適用できる。２つめ
は、本発明のエラー検出用埋め込みデータの埋め込み方
法は、パケットロス部等の影響で発生するデータ誤りの
位置を、明示的にアプリケーションデコーダに伝えるた
めの識別コードをメディアデータ内に埋め込むことに特
徴があり、その具体的な数値は図１、図１５ならびに図
１６に示した数値には依存しない。パケットロス部分の
データを再生するアプリケーションデコーダがエラーと
判定できる埋め込みデータの発生手段ならびに埋め込み
構成は本発明に含まれる。また、埋め込み位置の検出方
法ならびに構成も図２と図６に限定されるものではな
い。３つめは、本発明のメディアデータ修正方法は、パ
ケットロス等の伝送誤りの影響を受けた画像、音声等の
メディアデータを、アプリケーションデコーダに入力す
る前に、そのメディアデータを解読し、再現するための
仕様・規格に従ったデータに修正することに特徴があ
る。従って、本明細書では、MPEG-4ビデオ規格を例にと
って説明したが、このようなデータ修正は、他の動画像
符号化方式でも同様のことは実現可能であり、様々な静
止画符号化方式、音声符号化方式ならびにデータ符号化
方式、さらにMP4のようなメディア統合ファイルフォー
マットに対しても実現可能である。よって、アプリケー
ションデコーダ(ビデオデコーダ、オーディオデコー
ダ、シーン記述デコーダ、ファイルフォーマットデコー
ダならびにこれらの組み合わせ等)に入力する前に、デ
ータを仕様準拠・規格準拠に変換する方法は全て本発明
に含まれる。また、本発明を実現するための構成は図１
８に限定されるものではない。例えば、メモリを１個と
し、随時データを修正して入れ替える方法やエラー検出
機能をデータ修正処理部に含めるような場合も本発明に
含まれる。４つめは、本明細書では、携帯電話端末を例
にとって説明したが、本発明はその他の無線端末や配信
サーバ等でも実現できる。例えば、無線通信から有線通
信へデータ変換部・変換機に本発明のデータ修正方法を
適用することは有効である。
ー修正機能はスタートコード、同期マーカならびに中間
マーカを起点として行われる。従って、これらのユニー
クワードを区切りとし、例えば、中間マーカとDCTデー
タ部が１個のパケットに含まれないように、送信側で伝
送パケットを構成しておくことで、本発明にて述べてい
る方法はより有効に機能する。本発明には次のような場
合も含まれる。１つめは、本発明のエラー検出用埋め込
みデータの埋め込み方法は、パケットロスを伴う通信手
段で利用でき、かつ各パケット内のヘッダ部にそのパケ
ットのシーケンス番号(パケットを合成する順番)が含ま
れているプロトコルであれば、送信端末とのコネクショ
ンレス型、コネクション型に関わらず適用可能である。
よって、本発明のエラー検出用埋め込みデータの埋め込
み方法は、本明細書で示したTCPとUDP/RTPに特化するも
のではない。また、回線交換方式であっても、決まった
区切りで伝送エラーを修正するため、アプリケーション
デコーダへの出力にエラー修正結果を反映させることが
可能である。このように、受信データの特定部分に通信
エラーが発生していると判定できる場合には本発明のエ
ラー検出用データ埋め込み方法は適用できる。２つめ
は、本発明のエラー検出用埋め込みデータの埋め込み方
法は、パケットロス部等の影響で発生するデータ誤りの
位置を、明示的にアプリケーションデコーダに伝えるた
めの識別コードをメディアデータ内に埋め込むことに特
徴があり、その具体的な数値は図１、図１５ならびに図
１６に示した数値には依存しない。パケットロス部分の
データを再生するアプリケーションデコーダがエラーと
判定できる埋め込みデータの発生手段ならびに埋め込み
構成は本発明に含まれる。また、埋め込み位置の検出方
法ならびに構成も図２と図６に限定されるものではな
い。３つめは、本発明のメディアデータ修正方法は、パ
ケットロス等の伝送誤りの影響を受けた画像、音声等の
メディアデータを、アプリケーションデコーダに入力す
る前に、そのメディアデータを解読し、再現するための
仕様・規格に従ったデータに修正することに特徴があ
る。従って、本明細書では、MPEG-4ビデオ規格を例にと
って説明したが、このようなデータ修正は、他の動画像
符号化方式でも同様のことは実現可能であり、様々な静
止画符号化方式、音声符号化方式ならびにデータ符号化
方式、さらにMP4のようなメディア統合ファイルフォー
マットに対しても実現可能である。よって、アプリケー
ションデコーダ(ビデオデコーダ、オーディオデコー
ダ、シーン記述デコーダ、ファイルフォーマットデコー
ダならびにこれらの組み合わせ等)に入力する前に、デ
ータを仕様準拠・規格準拠に変換する方法は全て本発明
に含まれる。また、本発明を実現するための構成は図１
８に限定されるものではない。例えば、メモリを１個と
し、随時データを修正して入れ替える方法やエラー検出
機能をデータ修正処理部に含めるような場合も本発明に
含まれる。４つめは、本明細書では、携帯電話端末を例
にとって説明したが、本発明はその他の無線端末や配信
サーバ等でも実現できる。例えば、無線通信から有線通
信へデータ変換部・変換機に本発明のデータ修正方法を
適用することは有効である。
【００３６】
【発明の効果】本発明により、アプリケーションデコー
ダにてパケットロスの影響を受けているデータ位置を正
確に検出することが可能となる。また、アプリケーショ
ンデコーダに入力する前にメディアデータをデコーダの
仕様・規格に修正することで、アプリケーションデコー
ダにおける誤り修正処理の負担を減らし、データの再生
速度を高速化することが可能となる。
ダにてパケットロスの影響を受けているデータ位置を正
確に検出することが可能となる。また、アプリケーショ
ンデコーダに入力する前にメディアデータをデコーダの
仕様・規格に修正することで、アプリケーションデコー
ダにおける誤り修正処理の負担を減らし、データの再生
速度を高速化することが可能となる。
【図１】本発明のユニークワードを埋め込んだシステム
デコーダの出力データ。
デコーダの出力データ。
【図２】携帯電話端末の内部構成を示す図。
【図３】送信パケットの一例図。
【図４】パケットロスが発生していない場合のシステム
デコーダからの出力メディアデータの一例図。
デコーダからの出力メディアデータの一例図。
【図５】パケットロスが発生した場合の、システムデコ
ーダからの出力メディアデータの一例図。
ーダからの出力メディアデータの一例図。
【図６】エラー検出用埋め込みデータの埋め込み処理を
実現するためのシステムデコーダ。
実現するためのシステムデコーダ。
【図７】本発明のシステムデコーダにおける、パケット
処理部からメディアデータ再構成部への出力データ。
処理部からメディアデータ再構成部への出力データ。
【図８】本発明のシステムデコーダにおいて、パケット
処理部の処理手順の一例。
処理部の処理手順の一例。
【図９】IPv4パケットのデータ構成。
【図１０】PPPフレームのデータ構成。
【図１１】RLPフレームのデータ構成。
【図１２】TCPパケットのデータ構成。
【図１３】UDPパケットのデータ構成。
【図１４】RTPパケットのデータ構成。
【図１５】本発明のエラー検出用埋め込みデータの一
例。
例。
【図１６】本発明の誤り通知データを付加するエラー検
出用埋め込みデータの一例。
出用埋め込みデータの一例。
【図１７】誤り通知データの出力機能を持つ携帯電話端
末の内部構成図。
末の内部構成図。
【図１８】本発明のデータ修正処理を実現する携帯電話
端末の内部構成図。
端末の内部構成図。
【図１９】MPEG-4デコーダのブロック図の一例。
【図２０】誤り訂正機能を持つMPEG-4デコーダのブロッ
ク図の一例。
ク図の一例。
【図２１】MPEG-4ビデオ符号化ビットストリームの一
例。
例。
【図２２】MPEG-4ビデオ符号化ビットストリームにおけ
るVOPヘッダのデータ構成。
るVOPヘッダのデータ構成。
【図２３】MPEG-4ビデオ符号化におけるマクロブロック
分割を示す図。
分割を示す図。
【図２４】MPEG-4ビデオ符号化におけるマクロブロック
の構成。
の構成。
【図２５】MPEG-4ビデオ符号化ビットストリームにおけ
るMBデータのデータ構成。
るMBデータのデータ構成。
【図２６】MPEG-4ビデオ符号化におけるビデオパケット
分割例。
分割例。
【図２７】MPEG-4ビデオ符号化ビットストリームにおけ
るビデオパケットデータ(I-VOP)のデータ構造。
るビデオパケットデータ(I-VOP)のデータ構造。
【図２８】MPEG-4ビデオ符号化ビットストリームにおけ
るビデオパケットヘッダのデータ構造。
るビデオパケットヘッダのデータ構造。
【図２９】MPEG-4ビデオ符号化ビットストリームにおけ
るビデオパケット優先データ部(I-VOP)のデータ構造。
るビデオパケット優先データ部(I-VOP)のデータ構造。
【図３０】MPEG-4ビデオ符号化ビットストリームにおけ
るビデオパケットAC成分制御情報部のデータ構造。
るビデオパケットAC成分制御情報部のデータ構造。
【図３１】MPEG-4ビデオ符号化ビットストリームにおけ
るビデオパケットAC成分情報部のデータ構造。
るビデオパケットAC成分情報部のデータ構造。
【図３２】MPEG-4ビデオ符号化ビットストリームにおけ
るビデオパケットデータ(P-VOP)のデータ構造。
るビデオパケットデータ(P-VOP)のデータ構造。
【図３３】MPEG-4ビデオ符号化ビットストリームにおけ
るビデオパケット優先データ部(P-VOP)のデータ構造。
るビデオパケット優先データ部(P-VOP)のデータ構造。
【図３４】MPEG-4ビデオ符号化ビットストリームにおけ
るビデオパケットIntra差分DC成分情報&AC成分制御情報
部のデータ構造。
るビデオパケットIntra差分DC成分情報&AC成分制御情報
部のデータ構造。
【図３５】MPEG-4ビデオ符号化ビットストリームにおけ
るビデオパケットIntra AC成分 or Inter DC&AC制御情
報部のデータ構造。
るビデオパケットIntra AC成分 or Inter DC&AC制御情
報部のデータ構造。
【図３６】本発明のメディアデータ修正アルゴリズムを
示すフローチャート。
示すフローチャート。
【図３７】本発明のマクロブロックデータ修正アルゴリ
ズム示すフローチャート。
ズム示すフローチャート。
【図３８】RTP使用時における携帯電話端末の内部構成
を示す図。
を示す図。
【図３９】TCP使用時における携帯電話端末の内部構成
を示す図。
を示す図。
【図４０】アプリケーションデコーダでの処理状況を考
慮して、不正パケットの再送判定を行うことが可能な携
帯電話端末の内部構成を示す図。
慮して、不正パケットの再送判定を行うことが可能な携
帯電話端末の内部構成を示す図。
【図４１】エラー検出用埋め込みデータの埋め込み処理
を行うシステムデコーダ。
を行うシステムデコーダ。
【図４２】本発明のシステムデコーダにおいて、擬似ス
トリーミングにおけるパケット処理部の処理手順の一
例。
トリーミングにおけるパケット処理部の処理手順の一
例。
【図４３】RTP使用時における誤り通知データの出力機
能を持つ携帯電話端末の内部構成図。
能を持つ携帯電話端末の内部構成図。
【図４４】TCP使用時における誤り通知データの出力機
能を持つ携帯電話端末の内部構成図。
能を持つ携帯電話端末の内部構成図。
２０５…システムデコーダ、２０７、７１０…メモリ、
２０９…アプリケーションデコーダ、３０１…パケット
処理部、３０３…再送判定結果・シーケンス番号、３０
４…再送判定部、３０５…応答確認部、３０７…ペイロ
ードデータ、３０８…メディアデータ再構成部、８０１
…タイムスタンプ・シーケンス番号・ペイロードタイ
プ、８０２…パケットロス検出部、７０１…エラー・同
期マーカ検出部、８０５、８０５１、８０５２、８０５
３…エラー検出用埋め込みデータ、８０６、８０７…パ
ケットロスが発生したシーケンス番号ならびにペイロー
ドタイプ、８０７…パケットロスが発生したシーケンス
番号、７０６…誤り通知データ、７０５…スイッチ、７
０７…データ修正処理部、３３１０…マクロブロックデ
ータ修正部、３３１１…バイトアライン処理部
２０９…アプリケーションデコーダ、３０１…パケット
処理部、３０３…再送判定結果・シーケンス番号、３０
４…再送判定部、３０５…応答確認部、３０７…ペイロ
ードデータ、３０８…メディアデータ再構成部、８０１
…タイムスタンプ・シーケンス番号・ペイロードタイ
プ、８０２…パケットロス検出部、７０１…エラー・同
期マーカ検出部、８０５、８０５１、８０５２、８０５
３…エラー検出用埋め込みデータ、８０６、８０７…パ
ケットロスが発生したシーケンス番号ならびにペイロー
ドタイプ、８０７…パケットロスが発生したシーケンス
番号、７０６…誤り通知データ、７０５…スイッチ、７
０７…データ修正処理部、３３１０…マクロブロックデ
ータ修正部、３３１１…バイトアライン処理部
─────────────────────────────────────────────────────
フロントページの続き
(72)発明者 木村 淳一
東京都国分寺市東恋ケ窪一丁目280番地
株式会社日立製作所中央研究所内
Ｆターム(参考） 5C059 KK01 MA05 MA23 MC11 NN01
RB02 RC04 RC22 RF02 RF07
RF09 RF23 SS06 TA76 TC22
TD13 UA05 UA33
5K014 AA01 FA02 FA09 FA15
5K034 AA02 AA05 CC02 DD01 EE03
EE11 FF13 HH10 KK28 MM01
SS03 TT01
Claims (16)
- 【請求項１】入力した複数のパケットデータからペイロ
ード部を取り出すパケット処理部と、到着していないパ
ケットデータ及び伝送エラーを伴うパケットデータのシ
ーケンス番号を検出し、前記検出されたシーケンス番号
に対応する到着していないパケット及び伝送エラーを伴
うパケットのペイロード部の替わりにエラー検出用のユ
ニークワードを出力するパケットロス検出部と、前記ペ
イロード部と前記ユニークワードとをアプリケーション
デコーダが再生する順序に入れ替えて出力するメディア
データ再構成部とを備えることを特徴とするシステムデ
コーダ装置。 - 【請求項２】前記ユニークワードは、アプリケーション
デコーダの仕様に含まれていないデータ列であり、アプ
リケーションデコーダがエラーとして判定するデータ列
であることを特徴とする請求項１記載のシステムデコー
ダ装置。 - 【請求項３】前記ユニークワードは、アプリケーション
デコーダとの間で予めエラー通知用データとして定めて
おいたデータ列であることを特徴とする請求項１記載の
システムデコーダ装置。 - 【請求項４】前記パケットロス検出部からの入力を受け
て、前記メディアデータ再構成部から出力されるメディ
アデータと同サイズの誤り通知データを出力する誤り通
知出力部とを備えることを特徴とする請求項１記載のシ
ステムデコーダ装置。 - 【請求項５】前記パケットロス検出部は、前記到着して
いないパケットデータ及び伝送エラーを伴うパケットデ
ータのシーケンス番号を検出する際に、当該パケットの
ペイロードタイプを同時に検出し、ペイロードタイプに
決定されるメディアデコーダの種類毎に異なったユニー
クワードを出力することを特徴とする請求項１記載のシ
ステムデコーダ装置。 - 【請求項６】前記パケットロス検出部は、前記到着して
いないパケットデータ及び伝送エラーを伴うパケットデ
ータのシーケンス番号を検出する際に、当該パケットの
ペイロードタイプを同時に検出し、前記誤り通知出力部
は、該ペイロードタイプによりペイロードタイプに決定
されるメディアデコーダの種類毎に異なった誤り通知デ
ータを出力することを特徴とする請求項１記載のシステ
ムデコーダ装置。 - 【請求項７】入力した複数のパケットデータからペイロ
ード部を取り出すパケット処理部と、到着していないパ
ケットデータ及び伝送エラーを伴うパケットデータの再
送を行うか否かの再送判定を行い結果を出力する再送判
定部と、到着していないパケットデータ及び伝送エラー
を伴うパケットデータのシーケンス番号を検出し前記再
送判定部に該シーケンス番号を出力し、前記再送判定部
の通知結果から到着していないパケット及び伝送エラー
を伴うパケットのペイロード部の替わりにエラー検出用
のユニークワードを出力するパケットロス検出部と、前
記ペイロード部と前記ユニークワードとをアプリケーシ
ョンデコーダが再生する順序に入れ替えて出力するメデ
ィアデータ再構成部とを備えることを特徴とするシステ
ムデコーダ装置。 - 【請求項８】前記再送判定部は、アプリケーションデコ
ーダでの処理状況に関連する情報を用いることにより到
着していないパケットデータ及び伝送エラーを伴うパケ
ットデータの再送の必要性を判定することを特徴とする
請求項７記載のシステムデコーダ装置。 - 【請求項９】前記再送判定部は、前記到着していないパ
ケットデータ及び伝送エラーを伴うパケットデータの重
要性に基づき、該到着していないパケットデータ及び伝
送エラーを伴うパケットデータの再送の必要性を判定す
ることを特徴とする請求項７記載のシステムデコーダ装
置。 - 【請求項１０】入力した複数のパケットデータからペイ
ロード部を取り出し、到着していないパケットデータ及
び伝送エラーを伴うパケットデータのシーケンス番号を
検出し、前記到着していないパケット及び伝送エラーを
伴うパケットのペイロード部の替わりにエラー検出用の
ユニークワードを出力し、前記ペイロード部と前記ユニ
ークワードとをアプリケーションデコーダが再生する順
序に入れ替えた信号を生成し、前記信号からユニークワ
ードを検出し修正をおこなうパケットデータの修正方
法。 - 【請求項１１】前記修正をバイトアライン処理を含む修
正手段によっておこなうことを特徴とする請求項１０記
載のパケットデータの修正方法。 - 【請求項１２】前記信号がブロック単位の符号化アルゴ
リズムにて生成されたビデオデータである場合には、デ
ータの修正に、符号化ブロックのデータに含まれる符号
化タイプの情報を変更する処理を含むことを特徴とする
請求項１０記載のパケットデータの修正方法。 - 【請求項１３】前記信号がビデオデータである場合、デ
ータの修正に、フレーム画像のデータに含まれるタイム
スタンプ情報を変更する処理を含むことを特徴とする請
求項１０記載のパケットデータの修正方法。 - 【請求項１４】前記信号がブロック単位の符号化アルゴ
リズムにて生成されたビデオデータである場合、データ
の修正に、符号化ブロックを符号化データの無いブロッ
クに変更すると共に当該ブロックに関連する符号化デー
タの有無を示すフラグを変更する処理を含むことを特徴
とする請求項１０記載のパケットデータの修正方法。 - 【請求項１５】前記信号が複数の符号化ブロックを１個
のビデオパケットとして扱うことが可能なブロック単位
の符号化アルゴリズムにて生成されたビデオデータであ
る場合、データの修正に、ビデオパケットのヘッダ部に
含まれるブロック位置情報を変更する処理を含むことを
特徴とする請求項１０記載のパケットデータの修正方
法。 - 【請求項１６】前記信号が複数の符号化ブロックを１個
のビデオパケットとして扱うことが可能なブロック単位
の符号化アルゴリズムにて生成されたビデオデータであ
留場合、データの修正に、ビデオパケット内にて処理す
べき符号化ブロックの数を変更する処理を含むことを特
徴とする請求項１０記載のパケットデータの修正方法。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001208680A JP3931595B2 (ja) | 2001-07-10 | 2001-07-10 | データ修正装置及びデータ修正方法 |
| US09/940,576 US7131048B2 (en) | 2001-07-10 | 2001-08-29 | Apparatus for system decoder and method for error correction of packet data |
| KR20010052915A KR100761181B1 (ko) | 2001-07-10 | 2001-08-30 | 시스템 디코더 장치 및 패킷 데이터의 수정 방법 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001208680A JP3931595B2 (ja) | 2001-07-10 | 2001-07-10 | データ修正装置及びデータ修正方法 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003023413A true JP2003023413A (ja) | 2003-01-24 |
| JP2003023413A5 JP2003023413A5 (ja) | 2005-06-09 |
| JP3931595B2 JP3931595B2 (ja) | 2007-06-20 |
Family
ID=19044458
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001208680A Expired - Lifetime JP3931595B2 (ja) | 2001-07-10 | 2001-07-10 | データ修正装置及びデータ修正方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7131048B2 (ja) |
| JP (1) | JP3931595B2 (ja) |
| KR (1) | KR100761181B1 (ja) |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005006340A (ja) * | 2003-06-13 | 2005-01-06 | Microsoft Corp | ネットワーク通信のための時間指向、ベストエフォート的、穴埋め型再試行方法およびシステム |
| JP2006323203A (ja) * | 2005-05-19 | 2006-11-30 | Sony Corp | コンテンツ再生装置及びコンテンツ再生方法 |
| JP2007295535A (ja) * | 2006-03-08 | 2007-11-08 | Canon Inc | 送信中に損失を受けた画像を受信する方法及び装置 |
| JP2008514164A (ja) * | 2004-09-22 | 2008-05-01 | クゥアルコム・インコーポレイテッド | 効果的なデータ回復を用いるビデオ・デマルチプレクサ及びビデオ・デコーダ |
| JP2008546230A (ja) * | 2005-05-13 | 2008-12-18 | クゥアルコム・インコーポレイテッド | インバンド誤りパターンを使用する誤り回復のための装置と方法 |
| JP2009290567A (ja) * | 2008-05-29 | 2009-12-10 | Canon Inc | データ送信装置及びデータ受信装置 |
| JP2010517395A (ja) * | 2007-01-26 | 2010-05-20 | トムソン ライセンシング | メディア・データのパケット交換伝送方法およびメディア・データの処理方法 |
| JP2010193327A (ja) * | 2009-02-20 | 2010-09-02 | Nec Engineering Ltd | 画像復号装置およびパケット損失補償方法 |
| JP2010232861A (ja) * | 2009-03-26 | 2010-10-14 | Sony Corp | 情報処理装置、音声信号処理方法、およびプログラム |
| US8379733B2 (en) | 2006-09-26 | 2013-02-19 | Qualcomm Incorporated | Efficient video packetization methods for packet-switched video telephony applications |
| JP2018113599A (ja) * | 2017-01-12 | 2018-07-19 | 日本電気株式会社 | 通信処理システム、通信監視装置、通信監視方法及び通信監視プログラム |
| US11227687B2 (en) | 2010-01-22 | 2022-01-18 | Deka Products Limited Partnership | System, method, and apparatus for communicating data |
Families Citing this family (55)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003046912A1 (fr) * | 2001-11-29 | 2003-06-05 | Sharp Kabushiki Kaisha | Procede d'enregistrement de donnees, procede d'effacement de donnees, procede d'affichage de donnees, appareil d'enregistrement, support d'enregistrement et programme |
| FR2833796B1 (fr) * | 2001-12-19 | 2004-04-09 | Thomson Licensing Sa | Procede et dispositif de compression de donnees video codees par paquets video |
| US7106757B2 (en) * | 2001-12-19 | 2006-09-12 | Intel Corporation | System and method for streaming multimedia over packet networks |
| KR100460970B1 (ko) * | 2002-01-10 | 2004-12-09 | 삼성전자주식회사 | 데이터 송수신 시스템 및 방법 |
| US6983408B2 (en) * | 2002-03-08 | 2006-01-03 | Microsoft Corporation | Managing error/status information generated during video processing |
| JP4355156B2 (ja) * | 2002-04-16 | 2009-10-28 | パナソニック株式会社 | 画像復号化方法及び画像復号化装置 |
| US7450646B2 (en) * | 2002-06-04 | 2008-11-11 | Panasonic Corporation | Image data transmitting apparatus and method and image data reproducing apparatus and method |
| JP2004038575A (ja) * | 2002-07-03 | 2004-02-05 | Sony Corp | データ送受信システム及びデータ送受信方法、情報提供装置及び情報提供方法、並びにデータ受信装置及びデータ受信方法 |
| JP3821086B2 (ja) * | 2002-11-01 | 2006-09-13 | ソニー株式会社 | ストリーミングシステム及びストリーミング方法、クライアント端末及びデータ復号方法、並びにプログラム |
| US7627042B2 (en) * | 2003-01-23 | 2009-12-01 | Ittiam Systems (P) Ltd. | System, method, and apparatus for error recovery in coded video signals |
| WO2004073246A1 (ja) * | 2003-02-17 | 2004-08-26 | Nec Corporation | メディア符号化データ送信方法および装置ならびにプログラム |
| US7206577B2 (en) * | 2003-05-06 | 2007-04-17 | Nokia Corporation | Method and apparatus for receiving site selection diversity transmit (SSDT) signal in a wideband code division multiple access (WCDMA) system |
| GB0321641D0 (en) * | 2003-09-16 | 2003-10-15 | Agilent Technologies Inc | Methods and apparatus for measuring service disruption |
| KR100608715B1 (ko) * | 2003-09-27 | 2006-08-04 | 엘지전자 주식회사 | ＱｏＳ보장형 멀티미디어 스트리밍 서비스 시스템 및 방법 |
| US20050100098A1 (en) * | 2003-10-23 | 2005-05-12 | Gong-Sheng Lin | Highly integrated mpeg-4 video decoding unit |
| US7567584B2 (en) * | 2004-01-15 | 2009-07-28 | Panasonic Corporation | Multiplex scheme conversion apparatus |
| JP2005210219A (ja) * | 2004-01-20 | 2005-08-04 | Sony Corp | 送受信システム、送信装置および方法、受信装置および方法、記録媒体、並びにプログラム |
| TWI270774B (en) * | 2004-01-20 | 2007-01-11 | Mediatek Inc | Memory control method and related device |
| US8966551B2 (en) * | 2007-11-01 | 2015-02-24 | Cisco Technology, Inc. | Locating points of interest using references to media frames within a packet flow |
| US9197857B2 (en) * | 2004-09-24 | 2015-11-24 | Cisco Technology, Inc. | IP-based stream splicing with content-specific splice points |
| JP2006129018A (ja) * | 2004-10-28 | 2006-05-18 | Fujitsu Ltd | 無線通信装置及び移動局 |
| US7747921B2 (en) * | 2005-08-05 | 2010-06-29 | Sony Corporation | Systems and methods for transmitting data over lossy networks |
| JP4322851B2 (ja) * | 2005-08-19 | 2009-09-02 | Ｎｅｃディスプレイソリューションズ株式会社 | 動画配信システムおよび動画配信サーバー |
| JP4725262B2 (ja) * | 2005-09-14 | 2011-07-13 | 富士フイルム株式会社 | 画像形成装置 |
| EP1827009A1 (en) * | 2006-02-28 | 2007-08-29 | Matsushita Electric Industrial Co., Ltd. | Video encoder and decoder for an improved zapping service for mobile video reception |
| KR100728038B1 (ko) * | 2006-03-03 | 2007-06-14 | 삼성전자주식회사 | Ｐｌｃ 네트워크상에서 데이터를 묶어서 전송하는 방법 및장치 |
| JP4419023B2 (ja) * | 2006-03-23 | 2010-02-24 | 株式会社カシオ日立モバイルコミュニケーションズ | 移動体通信端末、および、プログラム |
| US8358704B2 (en) * | 2006-04-04 | 2013-01-22 | Qualcomm Incorporated | Frame level multimedia decoding with frame information table |
| CN101087438A (zh) * | 2006-06-06 | 2007-12-12 | 安捷伦科技有限公司 | 计算无参考视频质量评估的分组丢失度量的系统和方法 |
| US8306063B2 (en) | 2006-08-29 | 2012-11-06 | EXFO Services Assurance, Inc. | Real-time transport protocol stream detection system and method |
| US8310920B2 (en) * | 2007-03-02 | 2012-11-13 | Saratoga Data Systems, Inc. | Method and system for accelerating transmission of data between network devices |
| DE102007018484B4 (de) * | 2007-03-20 | 2009-06-25 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Vorrichtung und Verfahren zum Senden einer Folge von Datenpaketen und Decodierer und Vorrichtung zum Decodieren einer Folge von Datenpaketen |
| US8023419B2 (en) | 2007-05-14 | 2011-09-20 | Cisco Technology, Inc. | Remote monitoring of real-time internet protocol media streams |
| US7936695B2 (en) * | 2007-05-14 | 2011-05-03 | Cisco Technology, Inc. | Tunneling reports for real-time internet protocol media streams |
| JP5224731B2 (ja) * | 2007-06-18 | 2013-07-03 | キヤノン株式会社 | 映像受信装置及び映像受信装置の制御方法 |
| US7835406B2 (en) | 2007-06-18 | 2010-11-16 | Cisco Technology, Inc. | Surrogate stream for monitoring realtime media |
| US7817546B2 (en) * | 2007-07-06 | 2010-10-19 | Cisco Technology, Inc. | Quasi RTP metrics for non-RTP media flows |
| CN101394336B (zh) * | 2007-09-17 | 2012-02-22 | 华为技术有限公司 | 一种在分组网络中传输trau帧的方法、系统和设备 |
| US9128868B2 (en) * | 2008-01-31 | 2015-09-08 | International Business Machines Corporation | System for error decoding with retries and associated methods |
| US8902996B2 (en) | 2008-02-26 | 2014-12-02 | Richwave Technology Corp. | Adaptive wireless video transmission systems and methods |
| US9357233B2 (en) * | 2008-02-26 | 2016-05-31 | Qualcomm Incorporated | Video decoder error handling |
| US8265171B2 (en) * | 2008-02-26 | 2012-09-11 | Richwave Technology Corp. | Error resilient video transmission using instantaneous receiver feedback and channel quality adaptive packet retransmission |
| EP2234314A1 (en) | 2009-03-25 | 2010-09-29 | Thomson Licensing SA | A method of managing a packet administration map |
| US8301982B2 (en) * | 2009-11-18 | 2012-10-30 | Cisco Technology, Inc. | RTP-based loss recovery and quality monitoring for non-IP and raw-IP MPEG transport flows |
| CN101729840A (zh) * | 2009-12-17 | 2010-06-09 | 于培宁 | 一种利用视频图像特征序列的存储处理方法 |
| US8819714B2 (en) | 2010-05-19 | 2014-08-26 | Cisco Technology, Inc. | Ratings and quality measurements for digital broadcast viewers |
| CN103988518B (zh) | 2011-11-25 | 2018-05-15 | 日立麦克赛尔株式会社 | 图像传输装置 |
| EP2811705B1 (en) * | 2012-01-31 | 2019-06-26 | Sharp Kabushiki Kaisha | Generation device and generation method for data packets |
| KR101971623B1 (ko) * | 2012-05-10 | 2019-04-23 | 삼성전자주식회사 | 컨텐츠 및 사용자 인터랙션 전송방법 |
| TWI540886B (zh) * | 2012-05-23 | 2016-07-01 | 晨星半導體股份有限公司 | 音訊解碼方法及音訊解碼裝置 |
| US9104611B1 (en) * | 2012-11-13 | 2015-08-11 | Sprint Communications Company L.P. | Management of syntax errors in signaling messages |
| US20160127930A1 (en) * | 2013-05-31 | 2016-05-05 | Cellular South, Inc. Dba C Spire Wireless | Wireless system |
| KR101610715B1 (ko) * | 2014-06-11 | 2016-04-08 | 한국전자통신연구원 | 단방향 데이터 송수신 시스템 및 방법 |
| JP5940231B1 (ja) * | 2016-01-15 | 2016-06-29 | 株式会社 ディー・エヌ・エー | 情報処理システム、情報処理プログラム及び情報処理方法 |
| US10992724B2 (en) * | 2017-01-20 | 2021-04-27 | Hanwha Techwin Co., Ltd. | Media playback apparatus and method including delay prevention system |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR940012945A (ko) * | 1992-11-26 | 1994-06-24 | 윤종용 | 에러신호 발생방법 및 장치 |
| US5737022A (en) * | 1993-02-26 | 1998-04-07 | Kabushiki Kaisha Toshiba | Motion picture error concealment using simplified motion compensation |
| JP2576776B2 (ja) * | 1993-11-10 | 1997-01-29 | 日本電気株式会社 | パケット伝送方法・パケット伝送装置 |
| US5475688A (en) * | 1994-04-22 | 1995-12-12 | Thomson Consumer Electronics, Inc. | Media error code generation as for a video inverse transport processor |
| JP2898212B2 (ja) | 1994-12-21 | 1999-05-31 | 沖電気工業株式会社 | 画像復号回路 |
| JPH08191337A (ja) * | 1995-01-09 | 1996-07-23 | Daikin Ind Ltd | データ伝送装置及びデータ伝送方法 |
| DE69631393T2 (de) * | 1995-03-29 | 2004-10-21 | Hitachi Ltd | Dekoder für komprimierte und multiplexierte Bild- und Audiodaten |
| JPH09247132A (ja) * | 1996-03-08 | 1997-09-19 | Yazaki Corp | 無線パケット通信装置及び送信装置 |
| US5802050A (en) * | 1996-06-10 | 1998-09-01 | Telefonaktiebolaget Lm Ericsson | Minicell sequence number count |
| JP3291532B2 (ja) | 1996-07-24 | 2002-06-10 | 松下電器産業株式会社 | 復号化装置 |
| JP3884172B2 (ja) * | 1997-10-02 | 2007-02-21 | 株式会社東芝 | 可変長復号化装置および復号化方法 |
| US5956102A (en) * | 1997-11-04 | 1999-09-21 | Hitachi America Ltd. | Methods and apparatus for the efficient implementation of signal synchronization and cyclic redundancy checks in communication systems |
| JPH11331261A (ja) | 1998-05-20 | 1999-11-30 | Kokusai Electric Co Ltd | パケット通信装置 |
| US6310884B1 (en) * | 1998-05-21 | 2001-10-30 | Lsi Logic Corporation | Data transfer method and apparatus that allocate storage based upon a received relative offset |
| FI105962B (fi) * | 1998-06-30 | 2000-10-31 | Nokia Mobile Phones Ltd | Virheiden ilmaisu multipleksattuja signaaleja vastaanotettaessa |
| KR100354745B1 (ko) * | 1998-11-02 | 2002-12-18 | 삼성전자 주식회사 | 비디오코딩및디코딩방법 |
| EP1919117B1 (en) * | 1998-11-30 | 2014-10-15 | Panasonic Corporation | Packet retransmission control using priority information |
| JP4218112B2 (ja) | 1999-02-26 | 2009-02-04 | 三菱電機株式会社 | マルチメディア通信システム |
| JP3411234B2 (ja) * | 1999-04-26 | 2003-05-26 | 沖電気工業株式会社 | 符号化情報受信復号装置 |
| JP2001025010A (ja) * | 1999-07-09 | 2001-01-26 | Mitsubishi Electric Corp | マルチメディア情報通信装置およびその方法 |
| KR20010063821A (ko) * | 1999-12-24 | 2001-07-09 | 서평원 | 통신 시스템에서 패킷 유실 검출 장치 및 방법 |
-
2001
- 2001-07-10 JP JP2001208680A patent/JP3931595B2/ja not_active Expired - Lifetime
- 2001-08-29 US US09/940,576 patent/US7131048B2/en not_active Expired - Fee Related
- 2001-08-30 KR KR20010052915A patent/KR100761181B1/ko not_active IP Right Cessation
Cited By (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4694152B2 (ja) * | 2003-06-13 | 2011-06-08 | マイクロソフト コーポレーション | ネットワーク通信のための時間指向、ベストエフォート的、穴埋め型再試行方法およびシステム |
| JP2005006340A (ja) * | 2003-06-13 | 2005-01-06 | Microsoft Corp | ネットワーク通信のための時間指向、ベストエフォート的、穴埋め型再試行方法およびシステム |
| JP4819815B2 (ja) * | 2004-09-22 | 2011-11-24 | クゥアルコム・インコーポレイテッド | 効果的なデータ回復を用いるビデオ・デマルチプレクサ及びビデオ・デコーダ |
| JP2011172245A (ja) * | 2004-09-22 | 2011-09-01 | Qualcomm Inc | 効果的なデータ回復を用いるビデオ・デマルチプレクサ及びビデオ・デコーダ |
| JP2008514164A (ja) * | 2004-09-22 | 2008-05-01 | クゥアルコム・インコーポレイテッド | 効果的なデータ回復を用いるビデオ・デマルチプレクサ及びビデオ・デコーダ |
| JP2008546230A (ja) * | 2005-05-13 | 2008-12-18 | クゥアルコム・インコーポレイテッド | インバンド誤りパターンを使用する誤り回復のための装置と方法 |
| JP2006323203A (ja) * | 2005-05-19 | 2006-11-30 | Sony Corp | コンテンツ再生装置及びコンテンツ再生方法 |
| JP4614395B2 (ja) * | 2006-03-08 | 2011-01-19 | キヤノン株式会社 | 送信中に損失を受けた画像を受信する方法及び装置 |
| JP2007295535A (ja) * | 2006-03-08 | 2007-11-08 | Canon Inc | 送信中に損失を受けた画像を受信する方法及び装置 |
| US8379733B2 (en) | 2006-09-26 | 2013-02-19 | Qualcomm Incorporated | Efficient video packetization methods for packet-switched video telephony applications |
| JP2010517395A (ja) * | 2007-01-26 | 2010-05-20 | トムソン ライセンシング | メディア・データのパケット交換伝送方法およびメディア・データの処理方法 |
| JP2009290567A (ja) * | 2008-05-29 | 2009-12-10 | Canon Inc | データ送信装置及びデータ受信装置 |
| JP2010193327A (ja) * | 2009-02-20 | 2010-09-02 | Nec Engineering Ltd | 画像復号装置およびパケット損失補償方法 |
| JP2010232861A (ja) * | 2009-03-26 | 2010-10-14 | Sony Corp | 情報処理装置、音声信号処理方法、およびプログラム |
| US8676363B2 (en) | 2009-03-26 | 2014-03-18 | Sony Corporation | Information processing apparatus, audio signal processing method, and program product |
| US11227687B2 (en) | 2010-01-22 | 2022-01-18 | Deka Products Limited Partnership | System, method, and apparatus for communicating data |
| US11830617B2 (en) | 2010-01-22 | 2023-11-28 | Deka Products Limited Partneship | System, method, and apparatus for communicating data |
| JP2018113599A (ja) * | 2017-01-12 | 2018-07-19 | 日本電気株式会社 | 通信処理システム、通信監視装置、通信監視方法及び通信監視プログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP3931595B2 (ja) | 2007-06-20 |
| KR100761181B1 (ko) | 2007-09-21 |
| US20030014705A1 (en) | 2003-01-16 |
| US7131048B2 (en) | 2006-10-31 |
| KR20030006881A (ko) | 2003-01-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3931595B2 (ja) | データ修正装置及びデータ修正方法 | |
| Wenger et al. | RTP payload format for H. 264 video | |
| KR100960282B1 (ko) | 비디오 부호화 | |
| CN1910926B (zh) | 用于处理视频通信差错的方法和装置 | |
| JP5341629B2 (ja) | ピクチャ復号化方法 | |
| EP1882343B1 (en) | Improving error resilience using out of band directory information | |
| US20050123042A1 (en) | Moving picture streaming file, method and system for moving picture streaming service of mobile communication terminal | |
| US9578360B2 (en) | Information presentation device and method | |
| US9153127B2 (en) | Video transmitting apparatus, video receiving apparatus, and video transmission system | |
| KR20050122281A (ko) | 픽처 코딩 방법 | |
| JP2006319992A (ja) | マルチメディアストリーミングサービスのためのパケット転送装置及びその方法 | |
| JP2009177447A (ja) | 動画像送受信システム | |
| US7839925B2 (en) | Apparatus for receiving packet stream | |
| Wenger et al. | RFC 3984: RTP payload format for H. 264 video | |
| US8068721B2 (en) | Method of transmitting video data | |
| JP2006013583A (ja) | 符号化ストリーム中継装置、その方法及びプログラム | |
| JP2004328353A (ja) | 逆転ストリームパケットの補正方法及び装置 | |
| JP2009049530A (ja) | データ送信装置、データ中継装置及びデータ受信装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040825 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040825 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060213 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060314 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060418 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060515 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060725 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060921 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070220 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070305 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110323 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110323 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120323 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130323 Year of fee payment: 6 |