JP5130352B2 - マルチメディアコンテナファイルの受信ヒントトラックに記録するメディアストリーム - Google Patents

マルチメディアコンテナファイルの受信ヒントトラックに記録するメディアストリーム Download PDF

Info

Publication number
JP5130352B2
JP5130352B2 JP2010504987A JP2010504987A JP5130352B2 JP 5130352 B2 JP5130352 B2 JP 5130352B2 JP 2010504987 A JP2010504987 A JP 2010504987A JP 2010504987 A JP2010504987 A JP 2010504987A JP 5130352 B2 JP5130352 B2 JP 5130352B2
Authority
JP
Japan
Prior art keywords
media
file
packet
hint
format
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.)
Expired - Fee Related
Application number
JP2010504987A
Other languages
English (en)
Other versions
JP2010526468A (ja
Inventor
ミスカ ハンヌクセラ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Nokia Oyj filed Critical Nokia Oyj
Publication of JP2010526468A publication Critical patent/JP2010526468A/ja
Application granted granted Critical
Publication of JP5130352B2 publication Critical patent/JP5130352B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/912—Applications of a database
    • Y10S707/913—Multimedia

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、概して、マルチメディアコンテナファイルフォーマット（Multimedia Container File Format）に関する。より具体的には、本発明は、マルチメディアコンテナファイルフォーマットにおける受信ヒントトラック（Reception Hint Track）の使用および処理に関する。
発明の背景
本項は、請求項に列挙される本発明の背景または内容を提供することを意図する。本項における説明は、追求され得る概念を含むかもしれず、必ずしも過去に着想または追求された概念というわけではない。したがって、本明細書において別途明示されない限り、本項に説明される事項は、本出願における説明および請求項に対する従来技術ではなく、本項に含められているからといって直ちに従来技術であると考えてはならない。
マルチメディアコンテナファイルフォーマットは、一連のマルチメディアコンテンツの生成や操作、伝送、消費において重要な要素である。ここで、符号化フォーマット（すなわち、エレメンタリストリームフォーマット（Elementary Stream Format））は、コンテンツ情報をビットストリームに符号化する、符号化アルゴリズムの動作に関するものである。これに対してコンテナファイルフォーマット（Container File Format）は、多種多様なストレージやトランスポートアーキテクチャを利用して、ローカルで復号したり再生したり、ファイルとして転送したり、ストリーミングするべく、生成されたビットストリームがアクセス可能になるように、組織化するためのメカニズムを備えるものである。また、コンテナファイルフォーマットによって、メディアを交換および編集すること、ならびに受信したリアルタイムストリーミングをファイルに記録することが容易になる。したがって、符号化フォーマットとコンテナファイルフォーマットとは大幅に異なる。
マルチメディアファイルフォーマットの一般的階層構造について、図1の1000に示す。エレメンタリストリームフォーマット1100は、独立した単一のストリームを表す。.amrおよび.aacファイル等の音声ファイルは、エレメンタリストリームフォーマットに準拠して構築される。コンテナファイルフォーマット1200は、単一のファイルに音声および映像の両方のストリームを含みうるフォーマットである。コンテナファイルフォーマット1200のファミリの例は、ISOベースのメディアファイルフォーマットに基づく。階層構造1000におけるコンテナファイルフォーマット1200の真下に、多重化フォーマット（Multiplexing Format）1300が存在する。典型的には、多重化フォーマット1300は、コンテナファイルフォーマット1200に準拠して構築される音声/映像（audio/video; AV）ファイルよりも、柔軟性が低く、かつより強く圧縮される。多重化フォーマット1300に準拠して構築されるファイルは、典型的には、再生目的だけに使用される。動画像専門家グループ(Moving Picture Experts Group; MPEG)-2プログラムストリームは、多重化フォーマット1300に準拠して構築されるストリームの例である。プレゼンテーション言語フォーマット1400は、レイアウト、双方向性、AVおよび離散メディアの同期化等の目的で使用される。いずれもワールドワイドウェブコンソーシアム（World Wide Web Consortium; W3C）で定められる同期マメルチメディア統合言語（synchronized multimedia integration language; SMIL）およびスケーラブル映像グラフィックス（scalable video graphics; SVG）は、プレゼンテーション言語フォーマット1400の例である。プレゼンテーションファイルフォーマット1500は、同一のファイルに全ての部分のプレゼンテーションを含むことによって特徴付けられる。プレゼンテーションファイルフォーマットに準拠して構築されるオブジェクトの例として、PowerPointファイルと、3GPファイルフォーマットの拡張プレゼンテーションプロファイルに従うファイルとが挙げられる。
利用可能なメディアおよびコンテナファイルフォーマット規格には、ISOベースのメディアファイルフォーマット（ISO/IEC 14496-12）、MPEG-4ファイルフォーマット（ISO/IEC 14496-14、MP4フォーマットとしても知られている）、高度映像符号化（Advanced Video Coding; AVC）ファイルフォーマット（ISO/IEC 14496-15）、3GPPファイルフォーマット（3GPP TS 26.244、3GPフォーマットとしても知られている）が含まれる。また、MPEGにおいて、スケーラブル映像符号化（scalable video coding; SVC）ファイルフォーマットの開発のためのプロジェクトが存在し、これは、高度映像符号化（advanced video coding; AVC）ファイルフォーマットに対する修正になる。並行して、MPEGは、一方向トランスポート上のファイル配信（file delivery over unidirectional transport; FLUTE）および非同期階層符号化（asynchronous layered coding; ALC）セッションのヒントトラックフォーマットの規定に努めており、これは、ISOベースのメディアファイルフォーマットの修正になる。
デジタル映像ブロードキャスティング（Digital Video Broadcasting; DVB）メカニズムは、現在、DVBファイルフォーマットを規定する過程にある。DVBファイルフォーマットを規定する主な目的は、現在のDVB規格（DVT-T、DVB-C、DVB-S）および今後のDVB規格に準拠するセットアップボックス、インターネットプロトコル（Internet Protocol; IP）テレビジョン受像機、ならびにDVBハンドヘルド（DVB-Handheld; DVB-H）に準拠するモバイルテレビジョン受像機およびその今後の進化等のDVB技術の実装間のコンテンツの相互運用性を容易化することにある。DVBファイルフォーマットによって、異なる製造者による機器間において記録される（読み取りのみ）メディアの交換、USB大容量メモリまたは類似の読み取り/書き込み機器を使用するコンテンツの交換、家庭用ネットワークにおける共有ディスクストレージへの共用アクセス、ならびに他の機能が可能になる。現在、ISOベースのメディアファイルフォーマットは、DVBファイルフォーマットの開発のための基礎として最も強力な候補である。ISOファイルフォーマットは、上記で参照したコンテナファイルフォーマットの全て（ISOファイルフォーマット自体は含まない）の派生の基礎である。これらのファイルフォーマット（ISOファイルフォーマット自体を含む）は、ファイルフォーマットのISO群と呼ばれる。
ISOベースのメディアファイルフォーマットにおける基本構成要素は、ボックス（box）と呼ばれる。各ボックスは、ヘッダおよびペイロードを含む。ボックスヘッダは、ボックスの型と、バイトを単位としたボックスのサイズとを示す。ボックスは、他のボックスを包含してもよく、ISOファイルフォーマットは、特定の型のボックス内においてどのボックス型が許容されるかについて特定する。さらに、各ファイルに強制的に存在するボックスもあれば、一方、単にオプション的であるボックスもある。さらに、ボックス型によっては、ファイルに複数のボックスが存在することが可能である。ゆえに、ISOベースのメディアファイルフォーマットは、ボックスの階層構造を本質的に特定する。
図2は、ISOベースのメディアファイルフォーマットに準拠する簡略化ファイル構造を示す。ファイルフォーマットのISO群によると、ファイル200は、メディアデータおよびメタデータを含み、これらは、別々のボックスに含まれる。すなわち、メディアデータ（mdat）ボックス210、およびムービー（moov）ボックス220である。ファイルが動作可能であるためには、これらのボックスが両方とも存在しなければならない。メディアデータボックス210は、インターリーブされ、かつ時系列順である映像フレームおよび音声フレームを含む。ムービーボックス220は、１つ以上のトラックを含んでもよく、各トラックは、１つのトラックボックス240に存在する。１つのメディアタイプのプレゼンテーションでは、典型的には、１つのトラックが選択される。
ISOベースのメディアファイルフォーマットは、プレゼンテーションがただ１つのファイルに含まれるという形態に制限される訳ではないことに留意されたい。実際は、プレゼンテーションは、いくつかのファイルに含まれうる。そのようなシナリオにおいても、プレゼンテーション全体のメタデータは１つのファイルに含まれる。また、このファイルは、メディアデータの全てを含んでもよく、この場合、プレゼンテーションは、自立型である。他のファイルを使用する場合、ISOベースのメディアファイルフォーマットに準拠して他のファイルをフォーマット化する必要はない。他のファイルは、メディアデータを含むために使用され、また、未使用のメタデータまたは他の情報を含みうる。ISOベースのメディアファイルフォーマットは、メタデータを含むファイルの構造のみに関与する。メディアファイルにおけるそのメディアデータが、ISOベースのメディアファイルフォーマットまたはその派生フォーマットにおいて特定されるようにフォーマット化されなければならないという点においてのみ、メディアデータファイルのフォーマットは、ISOベースのメディアファイルフォーマットまたはその派生フォーマットによって制約される。
時間的トラックに加え、ISOファイルは、メタボックスに非時間的バイナリオブジェクトを含むことが可能である。メタボックスは、ファイルの最上位、ムービーボックス220内、トラックボックス内240に存在することが可能であるが、最大限でも１つのメタボックスが、ファイルレベル、ムービーレベル、トラックレベルの各々において発生し得る。メタボックスは、「hdlr」ボックスを含むことを必要とし、このボックスは、「メタ」ボックスコンテンツの構造またはフォーマットを示す。メタボックスは、参照可能な任意の数のバイナリ項目を含み、バイナリ項目の各１つをファイル名と関連付けることが可能である。
ファイルは、ファイルフォーマットのISO群における複数のフォーマットに適合してもよく、ゆえに、ファイルについて単一の「型（type）」または「ブランド（brand）」の観点から説明することは、必ずしも可能であるとは限らない。全てのISOファイルは、ファイルの「最善の使用（best use）」と、ファイルが従う一連の他の仕様とをどのファイルフォーマットが特定するかを示すファイル型ボックスを含む。ファイルの「最善の使用」であるフォーマットは、ファイルの主要ブランド（major brand）と呼ばれ、他の互換性のあるフォーマットは、互換ブランド（Compatible Brand）と呼ばれる。
ファイル型ボックスについて、互換ブランドのリストにブランドが存在することは、要求（claim）および許可（permission）の両方を構成する。その存在は、ファイルがそのブランドの全ての必要性に適合するという点において要求であり、また、その存在は、ファイルを読み取るためにそのブランドのみを読み取り器が実装するからもしれないことに対する許可を表す。一般に、読み取り器は、以下のうちの１つに当てはまる場合でない限り、ブランドについて記載される全ての特徴を実装する必要がある。
１．読み取り器が使用するメディアが、特徴を使用または必要としない場合。例えば、Iフレーム映像は、同期サンプルテーブルを必要とせず、また、コンポジション再順序付け（composition reordering）を使用しない場合、コンポジション時間オフセットテーブル（composition time offset table）も必要とされない。同様に、コンテンツ保護が必要とされない場合、コンテンツ保護の構造への対応は必要とされない。
２．ファイルが準拠する別の仕様によって、特徴の使用が妨げられる場合。例えば、いくつかの派生した仕様によって、ムービーフラグメントの使用が明確に妨げられる。
３．製品が動作するコンテクストが、いくつかの構造が関連しないことを意味する場合。例えば、ヒントトラック構造は、ヒントトラックにおけるプロトコルのファイル配信（ストリーミング等）のためのコンテンツを作成するか、そのファイル配信を実行する製品のみに関連する。
特定のブランドを実装するファイル読み取り器は、そのブランドに適合すると表示されるファイルの読み取りを試行するべきである。
ヒントトラック（Hint Track）は、通常はメディアデータを含まない特別なトラックである。代わりに、ヒントトラックは、１つまたはそれ以上のトラックを、特定の通信プロトコルにおいて配信するために、パッケージするための命令を含む。パケットを送信するプロセスは時間ベースであり、また、時間ベースのデータ表示に実質的に等しく、したがって、トラックによって適切に記述されうる。ヒントトラックの存在によって、送信機の動作負荷は低減され、また、送信機の実装は、任意のヒントを含まずにメディアサンプルからプロトコルデータユニット（Protocol Data Unit）を構築する送信機に比べて単純であることが可能である。
ISOベースのメディアファイルフォーマットは、リアルタイムプロトコル（Real-Time Protocol; RTP）およびセキュアリアルタイムトランスポートロトコル（Secure Real-Time Transport Protocol; SRTP）に関するヒントトラック定義を含んでおり、ISOベースのメディアファイルフォーマットに関する将来の修正２（amendment 2）は、FLUTEおよびALCプロトコルに関するヒントトラック定義を含む。MPEG-2トランスポートストリーム（transport stream; TS）のヒントトラックフォーマットも、例えば、DVBファイルフォーマットの一部として特定され得る。
図2に示すmdatボックスは、トラックのサンプルを含む。非ヒントトラックでは、サンプルは、映像の個々のフレーム、時間的に連続した映像フレーム、時間的に連続した音声圧縮部分である。ヒントトラックでは、サンプルは、ヒントトラックのヘッダにおいて識別される通信プロトコルに準拠してフォーマット化される１つ以上のパケットの形成を規定する。
ヒントトラックは、サンプルのタイミングや同期用サンプルの標示等の、通常のメディアトラックの特徴の全てを受け継ぐ。ヒントサンプル（Hint Sample）は、伝送用パケットを送信機が構成することを支援する命令を含む。これらの命令は、送信する直値（immediate data）（例えばヘッダ情報）や、メディアデータの参照セグメントを含みうる。言い換えると、メディアトラックにおけるメディアサンプルを、ヒントトラックのサンプルにコピーする必要はなく、むしろ、ヒントサンプルは、メディアトラックのサンプルを指し示す。ゆえに、メディアデータ自体を再フォーマット化する必要は全くない。この手法は、所定のトランスポートフォーマットやメディアフォーマットについて伝送される実際のデータユニットに、メディア情報を区分する必要がある手法よりも空間効率が良い。このような手法においては、ローカルの再生処理は、メディアをパケットから再構築することか、メディアについて２つのコピー（１つはローカルの再生処理用、もう１つはトランスポート用）を有することを必要とする。同様に、この手法を使用する多くのプロトコルにおけるこのようなメディアの伝送は、配信プロトコル毎にメディアデータの多数のコピーを必要とする。これは、メディアデータがトランスポートのために大幅に変換される場合（例えば、エラー訂正符号化技術や暗号化の適用によって変換される場合）を除き、空間に関して非効率的である。
ISOファイルがヒントトラックを含む場合、ヒントが構成されるメディアデータを参照するメディアトラックは、その中のデータがヒントトラックによって直接参照されなくてもファイルに残る。全ヒントトラックの削除後、非ヒントプレゼンテーション全体は残る。
図3は、一般的な映像通信システムの図である。非圧縮の映像が極めて大きな帯域幅を必要とするという事実により、入力映像300は、ソース符号器305によって所望のビットレートに圧縮される。ソース符号器305は、2つの構成要素（波形符号器310およびエントロピー符号器315）に分けることができる。波形符号器310は、非可逆映像信号圧縮を実行し、一方、エントロピー符号器315は、波形符号器310の出力をバイナリシーケンスに可逆的に変換する。トランスポート符号器320は、例えば、データをインターリーブおよび変調することによって、使用中のトランスポートプロトコルに準拠して、圧縮された映像をカプセル化する。データは、伝送チャネル325を介して受信機側に伝送される。受信機は、逆の動作を実行して、表示のために再構築される映像信号を入手する。逆の動作には、トランスポート復号器330と、エントロピー復号器340および波形復号器345に分けることができるソース復号器335との使用が含まれ、最終的に、出力映像350がもたらされる。
大部分の実チャネルは、伝送エラーの影響を受け易い。伝送エラーは、概略的に2つのカテゴリ（ビットエラーおよび消失エラー）に分類できる。ビットエラーは、雑音や干渉等の、伝送チャネルにおいて発生する物理的事象によって引き起こされる。リアルタイムメディアトランスポートのためのプロトコルスタックは、典型的には、ビットエラーを検出するために、巡回冗長検査（cyclic redundancy check; CRC）コード等のメカニズムを提供する。一般的に、エラーのあるプロトコルペイロードは、トランスポート復号器において破棄される。エラーを含む映像データの復号における課題は、バースト性ビットエラーの可能性、エラーの位置の厳密な検出、エントロピー符号器が使用する可変長符号化（variable length coding; VLC）にある。ビットエラーのバースト性により、大部分のプロトコルペイロードが、いずれにしても検出不可能である可能性があるため、プロトコルペイロード全体を破棄することは、全く不必要なデータ排除を引き起こすわけではない。通信プロトコルにより提供されるエラー検出メカニズムは、典型的には、バイナリ的な結論（パケットが破損しているか、パケットが正確であるか）を提供しうる。このため、エラーの厳密な位置を判断することは、ソース符号化層メカニズムに依存する。エラーの位置を検出するために、構文的、意味的、不自然なテクスチャに基づく様々な方法が存在するが、それでも、ビットエラーの誤検出によって、見て不自然な映像がもたらされることがある。可変長符号化に起因して、たった１つのビットエラーが、それが生成するコードワードの解釈を変更させ、後続のコードワードの同期化の損失を引き起こす可能性がある。コードワード同期化が再確立されたとしても、復号されたデータの空間的または時間的位置を判断することは不可能な場合もある。
消失エラーに関しては、2つの主な原因が存在する。第1に、ルーター等の混雑したネットワーク要素におけるキューのあふれが、パケット損失を引き起こす。第2に、トランスポート復号器が、通常、ビットエラーが発生するパケット全体を除去することによってパケットエラーを処理することに起因する。
一般に、発生した伝送エラーは、まず検出され、次いで、受信機によって訂正または隠蔽されるべきである。上述のように、ビットエラーは、典型的には、CRCまたは類似のコードを使用して検出され、破損したパケットは破棄される。リアルタイムメディアトランスポートの通信プロトコルは、典型的には、伝送されるパケット毎に１ずつ増分するシーケンス番号を付加する、パケット損失は、連続的なパケットのシーケンス番号値における空白から検出可能である。エラー訂正とは、最初からエラーがなかったかのように、エラーデータを完全に復元する機能をいう。エラー隠蔽（Error concealment）とは、再構築された映像において伝送エラーが不可視であるように、伝送エラーの影響を隠蔽する能力をいう。典型的には、ある量の冗長性が、エラーの検出、訂正、隠蔽に役立てるために、ソース符号化またはトランスポート符号化に付加される。
エラー訂正および隠蔽技術は、およそ３つのカテゴリ（順方向エラー隠蔽法、後処理によるエラー隠蔽法、双方向エラー隠蔽法）に分類可能である。順方向エラー隠蔽法（forward error concealment）は、送信機側が伝送データに冗長性を付加して、伝送エラーが存在したとしても、受信機が伝送データを容易に復元可能にする技術である。後処理によるエラー隠蔽法（error concealment by postprocessing）は、完全に受信機指向型である。これらの方法は、誤って受信したデータの正確な表現の推定を試行する。また、送信機および受信機は、伝送エラーの影響を最小限に抑えるために協働し得る。これらの方法は、受信機が提供するフィードバック情報を大いに利用する。後処理によるエラー隠蔽法は、受動的エラー隠蔽法（passive error concealment）とも呼ばれる。一方、他の2つのカテゴリは、能動的エラー隠蔽法に分類される。
エラー訂正および隠蔽アルゴリズムの直交分類（orthogonal classification）は、上述の分類に比べ、該当するアルゴリズムが動作するプロトコルスタック層に基づく。物理層における方法は、例えば、インテリジェントに変調を使用するか、または伝送されるデータビットをインターリーブする。リンク層における方法は、誤って受信したデータブロックを、例えば、選択的に再伝送するかもしれない。一般に、ソース符号器またはソース復号器を伴う方法は、メディアアウェアなエラー訂正および隠蔽アルゴリズム（Media-Aware Error Correction and Concealment Algorithm）と呼ばれ、一方、単に、トランスポート符号器および復号器において動作する方法は、メディアに依存する。いくつかのプロトコルスタック層の相互運用を必要とする方法は、交差層最適化アルゴリズム（Cross-Layer Optimization Algorithm）のカテゴリに入る。用語の「統合ソースチャネル符号化（Joint Source-Channel Coding）」は、ソースおよびトランスポート符号化が協働して伝送エラーにシームレスに対処するように動作する際に、使用される。
多くのリアルタイムマルチメディア通信アプリケーションでは、マルチメディアファイルがファイルとして伝送されるよりも、メディアデータが通信プロトコルのパケットにカプセル化される方が好ましい。さらに、既存のメディアプレーヤが、受信したメディアストリームから生成される如何なるマルチメディアファイルも解析、復号、再生可能であることが望ましい。もしどのようなマルチメディアファイルであっても、既存のメディアプレーヤによって再生可能であるならば、メディアプレーヤを更新・変更する必要はない。
全てではないが、大部分のコンテナファイルフォーマットは、再生デバイスへ確実に転送された、エラーの無いファイルの再生を目標とし、また、ストリーミングサーバや他の送信デバイスから伝送されうるメディアコンテンツを提供することを目標とする。結果的に、コンテナファイルフォーマットは、伝送エラーを標示するメカニズムを提供せず、既存のプレーヤが、エラーのあるメディアストリームに正常に対処可能であることが保証されない。代わりに、このようなプレーヤは、クラッシュする可能性があり、そうでない場合は、予想外の動作となる可能性がある。ゆえに、受信したメディアストリームから生成されたファイルが、既存のメディアプレーヤで再生されること、ならびに、既存のファイルフォーマットと互換性を有することが望ましい。さらに、高性能のプレーヤおよび復号器が、受信したストリームであってファイルに記録されるストリームから伝送エラーを効率的に隠蔽するためのメカニズムを含むことが望ましい。
上述の問題の少なくともいくつかに対処するための従来の手法が多数存在している。第1の手法では、受信したトランスポートストリームをファイル等に含めるか、別のファイルに格納する。そして、その別のファイルはプレゼンテーションファイル（すなわちメタデータを含むファイル）から参照される。この構成では、トランスポートストリームは、アプリケーションに関連すると考えられる最下位プロトコルスタック層を参照する。RTPベースのメディア伝送では、トランスポートストリームは、典型的には、RTPパケットのストリームを参照する。エレメンタリメディアストリームが、（例えばDVB-T、DVB-C、DVB-Sのように）MPEG-2トランスポートストリームにカプセル化される場合、トランスポートストリームは、MPEG-2トランスポートストリームを参照する。ISOベースのメディアファイルフォーマット構造では、トランスポートストリームは、単一のサンプルとしてメディアトラックへ含まれることができる。これは、MPEG-2トランスポートストリームがQuickTimeファイルに含まれる方法である。トランスポートストリームに特有のメタデータは、ファイルフォーマットの新しい構造に格納されてもよく、ISOベースのメディアファイルフォーマットでは、構造は、メタボックスに存在し得る。
第2の手法では、受信したトランスポートストリームは、エレメンタリデータトラックに変換される。トランスポートストリームに特有のメタデータは、ファイルフォーマット中の新しい構造に格納される。ISOベースのメディアファイルフォーマットでは、その構造はメタボックス内に存在する。
第3の手法では、受信したトランスポートパケットのストリームそれ自身が、それが記録されるファイルのヒントトラックに書き込まれる。しかしながら、ヒントトラックが、パケット化命令（packetization instruction）をサーバ、より一般的には、送信機に提供するため、ヒントトラックの使用は、論理的には有効なソリューションではない。さらに、記録されるヒントトラックは、再送信される有効なストリームを提供し得ない。例えば、RTPシーケンス番号は、伝送されるストリームにおいて連続的であることが必要とされるが、記録されるストリームにおいて、欠落パケットにより、RTPシーケンス番号における不連続性が発生する。
メディアデータの全てを受信した後にのみmoovボックスが完成可能であるという事情があるため、上述の第2の手法および第3の手法では、単一ファイルへの連続的な記録はできない。この問題は、2005年12月1日に出願された米国特許出願第11/292,786号において記載するように、ムービーフラグメントという特徴を使用して、記録ファイルを分割することにより、回避することができる。別の方法として、受信したストリームのメディアデータを、メタデータにとは別のファイルに記録することも可能である。しかしながら、記録されるファイルを時間的にシフトさせて同時に再生したい場合、米国特許出願第11/292,786号に記載のムービーフラグメントを使用するべきである。
米国特許出願第11/292,786号明細書
本発明の種々の実施形態は、メディアパケットのストリームを受信し、メディアコンテンツを記録するためのシステムおよび方法を提供する。メディアコンテンツは、メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、ファイルに記録される。受信したメディアパケットの少なくとも１つは、メディアパケットを構築するための命令を使用することによってファイル中に表される。また、ファイル中の少なくとも１つの受信したメディアパケットが、それがエラーを含みうるという標示に関連付けられる。
本発明の種々の実施形態は、受信したリアルタイムメディアストリームをマルチメディアコンテナファイルに格納するための、後方互換性のある（backward-compatible）メカニズムを提供する。実際は、これは、既存のプレーヤが、受信したストリームにおける復元可能な部分を正確に再生可能であることを意味する。受信したストリームにおける伝送エラーの識別および位置特定が可能になるため、高性能のプレーヤは、伝送エラーを効率的に隠蔽することが可能である。さらに、本発明の種々の実施形態は、記録されるファイルにおける任意のメディアデータの複製を回避する効果も奏する。本発明の種々の実施形態は、DVBファイルフォーマットに準拠して、事実上全ての受信機と併用して使用可能である。
本発明に関するこれらの利点および特徴ならびにその他の利点および特徴と、その動作のメカニズムおよび方式とは、添付の図面を併用して、以下の説明により、更に明白になるだろう。添付の図面において、同一の要素は同一の符号を有する。
マルチメディアファイルフォーマットの階層構造の図である。
ISOファイルの簡略化構造の図である。
一般的な映像通信システムの図である
本発明の種々の実施形態と使用するための汎用マルチメディア通信システムの図である。
本発明の種々の実施形態に従う受信機の簡略化版の動作を示すフローチャートである。
本発明の種々の実施形態の実装と併用して使用可能である電子デバイスの斜視図である。
図6の電子デバイスに含まれうる回路の略図である。
本発明の種々の実施形態は、メディアパケットのストリームを受信し、メディアコンテンツを記録するためのシステムおよび方法を提供する。メディアコンテンツは、メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、ファイルに記録される。受信したメディアパケットの少なくとも１つは、メディアパケットを構築するための命令を使用することによってファイル中に表される。また、ファイル中の少なくとも１つの受信したメディアパケットが、それがエラーを含みうるという標示に関連付けられる。
本発明の一実施形態によると、ストリームは、ファイルフォーマットの１つ以上のヒントトラックに記録され、受信したストリームからヒントトラックが生成されたということが、当該ヒントトラックにおいて具体的に示される。ヒントトラックは、受信したストリームに正確に対応するため、可能な限り効率的に伝送エラーに対処するための全てのメカニズムを、メディアプレーヤに提供する。例えば、ヒントトラックのサンプル構造（すなわちパケット構造）は、パケットのシーケンス番号を含み、そのシーケンス番号から、欠落パケットが識別可能になる。ISOベースのメディアファイルフォーマットのRTPヒントトラック構造が、本発明の種々の実施形態の受信ヒントトラックのために再利用される場合、シーケンス番号は、RTPパケットデータ構造のRTPシーケンスの構文要素に存在しうる。
本発明の第2の実施形態によると、受信したストリームを、有効なメディアトラック、すなわち、非標準的な伝送エラー検出メカニズムや対処メカニズムを利用せずに復号可能なメディアトラックに変換する。有効なメディアトラックの形成は、既存のメディアプレーヤが記録されるファイルを再生可能であることを保証する。また、１つ以上の特有のヒントトラックも形成される。可能である場合はいつでも、ヒントサンプルは、パケットペイロードのコピーを含むのではなく、メディアトラックのサンプルへの参照を含み、ファイルのストレージ空間の必要性を低減する。
有効なメディアトラックの形成によって、いくつかのパケットがまとめて省略（omission）される場合がある。例えば、符号化された映像ストリームにおける参照ピクチャが損失する場合、メディアトラックは、損失した参照ピクチャから直接的または間接的に予測される任意の画像をスキップするはずである。そこで、ヒントサンプルは、対応するメディアトラックには存在しないパケットペイロードのコピーを含んでもよい。
図4は、本発明の種々の実施形態が実装され得る汎用マルチメディア通信システムを図示したものである。図4に示すように、データソース100は、アナログフォーマット、非圧縮デジタルフォーマット、圧縮デジタルフォーマット、あるいはこれらのフォーマットの任意の組み合わせでソース信号を提供する。符号器110は、ソース信号を、符号化メディアビットストリームに符号化する。復号されるべきこのビットストリームは、事実上、いかなるタイプのネットワークに位置する遠隔デバイスによっても、直接的または間接的に受信可能であることに留意されたい。さらに、このビットストリームは、ローカルハードウェアまたはソフトウェアから受信可能である。符号器110は、音声および映像等の複数のメディアタイプを符号化可能であってもよく、異なるメディアタイプのソース信号を符号化するために複数の符号器110が必要とされてもよい。また、符号器110は、グラフィックスやテキストを合成して生成された入力を得てもよく、合成メディアの符号化ビットストリームを生成可能であってもよい。以下においては、説明を簡略化するために、１つのメディアタイプの１つの符号化メディアビットストリームの処理のみについて考察する。しかしながら、典型的には、リアルタイムブロードキャストサービスが、いくつかのストリーム（典型的には、少なくとも１つの音声、映像、テキストサブタイトルのストリーム）を含むことに留意されたい。また、システムが、多数の符号器を含んでもよいが、図4において、一般性を欠如することなく説明を簡略化するために、符号器110を１つだけ示すことに留意されたい。さらに、本明細書に含まれるテキストおよび例は、符号化プロセスを具体的に説明し得るが、同一の概念および原理が、対応する復号プロセスにも適用すること、その逆も同様であることを、当業者が理解することを理解されたい。
符号化（された）メディアビットストリームは、ストレージ120に転送される。ストレージ120は、符号化メディアビットストリームを格納するために、任意のタイプの大容量メモリを備えることができる。ストレージ120における符号化メディアビットストリームのフォーマットは、エレメンタリ自立型ビットストリームフォーマット（Elementary Self-Contained Bitstream Format）であってもよく、または１つ以上の符号化メディアビットストリームがコンテナファイルにカプセル化されてもよい。いくつかのシステムは、「ライブ」で動作し、すなわち、ストレージを省略して、符号化メディアビットストリームを符号器110から送信機130に直接転送する。次いで、符号化メディアビットストリームは、必要に応じて送信機130（サーバとも呼ばれる）に転送される。伝送に使用するフォーマットは、エレメンタリ自立型ビットストリームフォーマットやパケットストリームフォーマット（Packet Stream Format）であってもよい。または、１つ以上の符号化メディアビットストリームが、コンテナファイルにカプセル化されてもよい。符号器110、ストレージ120、サーバ130は、同一の物理的デバイスに存在してもよく、別々のデバイスに備えられていてもよい。符号器110およびサーバ130は、ライブリアルタイムコンテンツで動作してもよく、この場合、符号化メディアビットストリームは、典型的には、永久的に格納されないが、コンテンツ符号器110および/またはサーバ130において短期間バッファリングされて、処理遅延、転送遅延、符号化メディアビットレートにおける変動を平滑化する。
サーバ130は、通信プロトコルスタックを使用して符号化メディアビットストリームを送信する。スタックには、リアルタイムトランスポートプロトコル（Real-Time Transport Protocol; RTP）、ユーザデータグラムプロトコル（User Datagram Protocol; UDP）、インターネットプロトコル（Internet Protocol; IP）が含まれてもよいが、これらに限定されない。通信プロトコルスタックがパケット指向型である場合、サーバ130は、符号化メディアビットストリームをパケットにカプセル化する。例えば、RTPを使用する場合、サーバ130は、RTFペイロードフォーマットに準拠して、符号化メディアビットストリームをRTPパケットにカプセル化する。典型的には、各メディアタイプは、専用RTPペイロードフォーマットを有する。前述のように、システムが、複数のサーバ130を含んでもよいが、簡略化するために、以下の説明では１つのサーバ130についてのみ考察することに留意されたい。
サーバ130は、通信ネットワークを介してゲートウェイ140に接続されてもよく、または接続されなくてもよい。ゲートウェイ140は、一方の通信プロトコルスタックに準拠するパケットストリームの別の通信プロトコルスタックへの変換、データストリームの統合および分岐、ならびに優勢のダウンリンクネットワーク条件に準拠して転送されるストリームのビットレートの制御等の、ダウンリンク能力および/または受信機能力に従うデータストリームの操作等の、様々なタイプの機能を実行し得る。ゲートウェイ140の例として、マルチポイント会議制御ユニット（multipoint conference control unit; MCU）、回路交換およびパケット交換映像電話間のゲートウェイ、プッシュトゥートークオーバーセルラ（Push-to-talk over Cellular; PoC）サーバ、デジタル映像ブロードキャストハンドヘルド（digital video broadcasting-handheld; DVB-H）システムにおけるIPエンカプスレータ、家庭用無線ネットワームへ局所的にブロードキャスト伝送を転送するセットトップボックスが挙げられる。RTPを使用する際、ゲートウェイ140は、RTP混合器またはRTP変換器と呼ばれ、典型的には、RTP接続の終点としての役割を果たす。
システムは、１つ以上の受信機150を含む。この受信機は、典型的には、伝送された信号を受信し、受信し、復調し、符号化メディアビットストリームに非カプセル化することが可能である。符号化メディアビットストリームは、記録ストレージ155に転送される。記録ストレージは、符号化メディアビットストリームを格納するための大容量メモリを備えてもよい。記録ストレージ155は、代替的にまたは付加的に、ランダムアクセスメモリ等の計算メモリを備えてもよい。記録ストレージ155における符号化メディアビットストリームのフォーマットは、エレメンタリ自立型ビットストリームフォーマットであってもよく、１つ以上の符号化メディアビットストリームが、コンテナファイルにカプセル化されてもよい。音声ストリームおよび映像ストリーム等の相互に関連付けられる多数の符号化メディアビットストリームが存在する場合、コンテナファイルは、典型的には使用され、受信機150は、入力ストリームからコンテナファイルを生成するコンテナファイル生成器を備えるか、コンテナファイル生成器に取り付けられる。いくつかのシステムは、「ライブ」で動作し、すなわち、記録ストレージ155を省略して、符号化メディアビットストリームを受信機150から復号器に130に直接転送する。システムによっては、記録されるストリームの直近の部分のみ、例えば、記録されるストリームの直近の10分が抜粋して記録ストレージ155に保持され、一方、それより前に記録される任意のデータは、記録ストレージ155から破棄される。
符号化メディアビットストリームは、記録ストレージ155から復号器160に転送される。音声ストリームおよび映像ストリーム等の、相互に関連付けられ、かつコンテナファイルにカプセル化される多くの符号化メディアビットストリームが存在する場合、ファイルパーサ（図示せず）を使用して、コンテナファイルから各符号化メディアビットストリームを非カプセル化する。記録ストレージ155または復号器160は、ファイルパーサ機能を備えてもよい。または、ファイルパーサは、記録ストレージ155または復号器160のいずれかに付加される。
符号化メディアビットストリームは、通常、復号器160によってさらに処理される。その出力は、１つ以上の非圧縮メディアストリームである。最後に、レンダラ170は、例えば、スピーカやディスプレイで非圧縮メディアストリームを再現してもよい。受信機150、記録ストレージ155、復号器160、レンダラ170は、同一の物理的デバイスに存在してもよく、別々のデバイスに含まれてもよい。
以下は、ISOベースのメディアファイルフォーマットにおいて、記録されるヒントトラックを示す方法に関する実装例である。この実装例では、記録されるヒントトラックは、サーバヒントトラック用の対応するサンプルエントリとは異なるサンプルエントリで示される。例えば、サーバ用のRTPヒントトラックは、サンプル記述"rtp"の中にエントリフォーマットを含むヒントトラック（メディアハンドラ「hint」）である。これに対して記録されるRTPヒントトラックは、サンプル記述"rrtp"の中にエントリフォーマットを含む。両方のサンプルエントリは、以下のように同一に記載される。

class RtpHintSampleEntryO extends SampleEntry ('rtp ') {
uint(16) hinttrackversion = 1 ;
uint(16) highestcompatibleversion = 1 ;
uint(32) maxpacketsize;
box additionaldata[ ];
}

class ReceivedRtpHintSampleEntry() extends SampleEntry ('rrtp') {
uint(16) hinttrackversion = 1 ;
uint(16) highestcompatibleversion = 1;
uint(32) maxpacketsize;
box additional data[ ];
サーバ用サンプルエントリフォーマットおよび記録されるもの用のサンプルエントリフォーマットの対は、SRTPやMPEG-2トランスポートストリーム（transport stream; TS）等のヒント可能なプロトコル毎に特定される。ヒントサンプルは、任意のプロトコルのサーバ用および記録されるもの用のヒントトラックフォーマットの各対について全く同じように特定されてもよい。任意のプロトコルのサーバ用および記録されるもの用のヒントトラックフォーマットの各対におけるヒントサンプルフォーマットの定義が同一であることによって、例えば、プログラミング言語のコードの種類またはマシンにより実行可能な命令の数の観点から、ソフトウェア実装のサイズを小さくしうる。しかしながら、記録されるヒントトラックのサンプルフォーマットを、同じプロトコルのサーバヒントトラックフォーマットとは異なるように設定することも有利であり得る。例えば、サーバは、伝送されるパケット毎に、（モジュロ演算において）値が１しか増えないと仮定している。すると、サーバヒントサンプルフォーマットのMPEG-2 TSパケットヘッダに、連続カウンタ（continuity_counter）フィールドを含むことは合理的ではないかもしれない。しかし、受信した後続パケットのcontinuity_counter値がとびとびになっていると、パケット損失の存在という結論を導き出すことが可能であるため、continuity_counterフィールドは、記録されるヒントサンプルフォーマットには必要とされる。
さらに、サーバヒントトラックにおいて使用する層とは異なるプロトコルスタック層において、記録されるヒントトラックフォーマットを特定することが合理的であるかもしれない。例えば、記録されるヒントサンプルが、インターネットプロトコル（IP）パケットに対応する場合、ファイルパーサは、ユーザデータグラムプトロコル（User Datagram Protocol; UDP）ヘッダのチェックサムを使用して、受信したパケットにおけるビットエラーの存在、すなわち、受信したパケットのインテグリティについて結論を出すことが可能である。代替的または補足的に、記録されるヒントサンプルは、対応するパケットフーマットには存在しないフィールドを含みうる。このようなフィールドは、例えば、下層プロトコルスタック層から情報を伝達するために使用され得る。このようなフィールドの一例は、記録されるRTPヒントサンプルのビットエラー標示フィールドであることができる。受信機は、UDPチェックサムまたは任意の下層プロトコルスタック層に存在する任意のCRCコードもしくはチェックサムに基づいて、ビットエラー標示フィールドを設定することができる。
図5は、本発明の種々の実施形態に従う受信機の簡略化版の動作を示すフローチャートである。しかしながら、受信機が多種多様の形式および構成を取ることが可能であることに留意されたい。図5のプロセスは、510において、受信したトランスポートパケットの受信機のバッファから、トランスポートパケットが取り出されることから開始する。さらに、トランスポートパケットは、第2のバッファに書き込まれる。第2のバッファは、本明細書において短期パケットバッファ（short-term packet buffer）と呼ばれる。トランスポートパケットは、RTPパケット、MPEG-2トランスポートストリームパケット、または任意の他のトランスポートプロトコルのパケットを含みうる。520において、パケットシーケンス番号の連続性が確認され、シーケンス番号の列に間が空いているか否かに関して判断が行なわれる。トランスポートパケットが、RTPに準拠してフォーマットされる場合、シーケンス番号（SN）は、RTPヘッダに存在する。トランスポートパケットがMPEG-2トランスポートストリームに準拠してフォーマットされる場合、シーケンス番号は、continuity_counterと呼ばれ、TSパケットヘッダに存在する。
シーケンス番号の列に間が空いてなく、短期パケットバッファにおけるパケットがビットエラーを含むとは識別されない場合、530において、映像フレームの、またはより一般的には、パケットが短期パケットバッファに現在格納中の映像アクセスユニットの、最終ペイロードバイトを現在のパケットが含むか否かに関して確認する。大部分の映像RTPペイロードにおいて、RTPヘッダのMビットは、符号化された映像フレームの最終ペイロードバイトをパケットが含むことを示すようになっている。映像フレームの最終パケットを検出する別の方式として、次のパケットのRTPタイムスタンプを確認することが挙げられる。次のRTPタイムスタンプが現在のRTPタイムスタンプと異なる場合、現在のパケットは、現在の符号化された映像フレームの最終ペイロードを含む。MPEG-2トランスポートストリームへのカプセル化が使用されている場合、次のトランスポートストリームパケットにおいて、payload_unit_start_indicator値が１に等しいことは、現在のTSパケットが、現在の符号化された映像フレームの最終ペイロードバイトを含むことを示す。現在のパケットが、映像フレームの最終パケットではない場合、プロセスは510に戻る。プロセス520および530が、符号化された映像データの復号順と伝送順が同一である場合にのみ動作することに留意されたい。伝送の順番がインターリーブされている場合、損失の検出や最終フレームの検出は、通常、受信したデータユニットの分析を必要とする。H.264/AVC映像において、伝送がインターリーブされている場合の損失検出の例が、3GPP Technical Recommendation 26.946（Release 6）、「Multimedia Broadcast/Multicast Service, User service guidelines」の第8章に提供されている。フレーム境界の検出については、H.264/AVC（すなわち、ITU-T Recommendation H 264）の第7.4.1.2.4節に明記されている。
さらに、図5に関する上記説明は、映像ストリームの観点から説明されていることに留意されたい。通常、音声は、多数のフレームから時間的に予測されるようにはなっておらず、音声フレーム全体が、１つのトランスポートパケットに含まれる。従って、上に説明した、次のランダムアクセスフレームの検索に対応する処理部分は、音声ストリームにおいては省略可能である。さらに、音声フレームが、常に１つのトランスポートパケットに適応する場合、書き込みプロセス530も省略可能であり、ステップ540は、音声サンプルをファイルに書き込む際に、欠落音声フレームを空きフレームと置換するように修正してもよい。
現在のパケットが、符号化された映像フレームの最終パケットである場合、540において、短期パケットバッファに収集されるパケットペイロードから、映像サンプルが引き出される。この引き出しプロセスは、パケットペイロードの単純な連結（Concatenation）を含むことが可能である。次いで、生成された映像サンプルがファイルに書き込まれる。通常、メタデータ（moovボックスまたはmoofボックス）が、出現の順番においてメディアデータに先行することから、映像サンプルが一時的ファイルにまず書き込まれ、その後、対応する全メタデータが完了すると生成される実際のファイルに、コピーされてもよいことに留意されたい。
550において、短期パケットバッファに格納されるパケットのそれぞれから、ヒントサンプルが生成される。540において生成された映像サンプルが、符号化された映像データを既に含むため、ヒントサンプルは、単に、映像トラック、生成された映像サンプル、映像サンプル内における適切なバイト領域を参照する。ヒントサンプルが、短期パケットバッファにおけるパケットの全てについて生成されると、バッファは空になり、プロセスは510に戻る。
520において、パケットのシーケンス番号に空白が検出されたり、短期パケットバッファにおけるいずれかのパケットにビットエラーが検出されたりする場合も、560において、短期パケットバッファに格納されるパケットの各々から、ヒントサンプルが生成される。しかしながら、短期パケットバッファにおけるパケットペイロードにエラーが存在するため、映像サンプルは、映像トラックへとは生成されない。したがって、パケットペイロードは、直コンストラクタメカニズム（immediate constructor mechanism）または「fat」ヒントトラックメカニズムのいずれかを使用して、ヒントサンプルにどうしても含まれることになる。直コンストラクタを使用する場合、ペイロードデータのコピーは、パケット化命令に含まれる。「fat」ヒントトラックを使用する場合、パケットペイロードは、ヒントトラックのmdat区分に含まれ、ヒントトラックのコンストラクタから参照される。ヒントサンプルが、短期パケットバッファにおける全パケットについて生成されると、バッファは空になる。
560の後、570において、受信したトランスポートパケットの次のパケットが、受信機のバッファから入手される。次いで、そのパケットは、
ランダムアクセスポイントをストリームに提供する、符号化された映像フレームをそのパケットが開始するか否かを判断するべく、調べられる。符号化された映像フレームの開始ポイントは、プロセス530に従って検出することができる。ランダムアクセスポイントの検出は、映像フォーマットおよびそそのペイロードフォーマットに依存する。例えば、H.264/AVCでは、独立復号リフレッシュ（independent decoding refresh; IDR）フレームが、パケットペイロードから容易にアクセス可能であるネットワーク抽象化層（network abstraction layer; NAL）単位ヘッダから識別可能となっている。H.264/AVCにより提供される別のランダムアクセスポイント標示メカニズムは、リカバリポイント補助的拡張情報（supplemental enhancement information; SEI）メッセージであり、これは、様々なタイプの段階的アクセス位置（gradual random access position）を示すことができる。ランダムアクセスポイントの標示に関する別の例が、その目的のための特定のフラグを含む、VC-IコーデックのRTPペイロードフォーマットに含まれている。ランダムアクセスポイントが標示される場合、プロセスは530から継続する。そうでない場合は、プロセスは、560から継続する。
上述のプロセスが、多数の方式で実装され得ることに留意されたい。例えば、受信プロセス中にメディアトラックが形成されず、ヒントトラックだけがファイルに形成される可能性がある。メディアトラックは、ストリームの受信の終了後に、オフラインで形成されることができる。メディアトラックのオフライン生成中、ヒントサンプル（メディアペイロードデータを含む）は、メディアトラックのサンプルにおけるデータを参照するように変化してもよく、変化しなくてもよい。図4を参照すると、メディアトラックのオフライン生成は、その入力を記録ストレージ155から入手し、復号器160に出力する、２つの追加のブロックをもたらしうる。処理順番における第1のブロックは、ファイル再書き込み部と考えることができ、これは、ヒントトラックのみ（メディアトラックは存在せず）を含むファイルを入力し、メディアトラックを含むファイルを出力する。処理順番における第2のブロックは、第2の記録ストレージと考えることができ、これは、記録ストレージ155と類似の特性を有し得る。
別の実装例は、受信中に中間フォーマットに記録することを含む。中間フォーマットは、受信したパケットの単純なストレージフォーマットを含むことが可能である。例えば、MPEG-2トランスポートストリームは、ファイル等に格納可能であり、RTPパケットも、パケットのサイズを示すいくつかのフレームがファイルに含まれる場合に格納可能である。中間フォーマットに準拠するファイルは、その後、ISOベースのメディアファイルフォーマットの或るバージョンまたはその派生等の、さらに構造化されたファイルフォーマットに変換可能である。変換プロセス中、上述の動作に似た動作を使用し得る。図4を参照する。この実装例は、記録ストレージ155からその入力を入手し、復号器160に出力する２つの追加のブロックが必要になり得る。処理順番における第1のブロックは、ファイル再書き込み部と考えることができ、これは、中間フォーマットに準拠してファイルを入力し、より構造化されたファイルフォーマットに準拠してファイルを出力する。処理順番における第2のブロックは、第2の記録ストレージと考えることができ、これは、記録ストレージ155と似た特性を有することができる。
上述のファイル再書き込み部および第2の記録ストレージは、受信機150や、記録ストレージ155、復号器160の中に設けられてもよいし、他のデバイスに存在してもよい。さらに、ファイル再書き込み部および第2の記録ストレージは、同一のデバイス内に設けられていてもよいし、それぞれ異なるデバイスに存在してもよい。
復号器160に含まれるまたは復号器160に付加されるファイルパーサおよび復号器160は、通常のファイルが解析・復号されるように動作しうる。つまり、メディアトラックおよびメディアサンプルのみが解析および復号され、ヒントトラックおよびヒントサンプルは省略されるように動作し得る。代替として、ファイルパーサおよび復号器160は、復号されたメディアビットストリームがリアルタイムで受信されるように動作し得る。言い換えると、ファイルパーサは、ヒントサンプルにおける命令に従ってパケットを構築し、パケットを復号器160に送出することが可能である。さらに、パケットを復号器160に送出する速度は、パケットの受信スケジュールに対応することが可能である。パケットのフォーマットは、送信機130から伝送されたパケットと同一であってもよいし、送信機から伝送されたパケットと同じ情報に加えて、下層プロトコルスタックからのデータを含みうるものであってもよい。復号器160は、図5を参照して上述したように、パケットの欠落や破損を検出する。復号器160は、エラー隠蔽および/またはエラー追跡アルゴリズムを適用することによって、欠落または破損パケットに対応し得る。さらに、復号器は、送信機130からのフィードバックプロトコルにより、欠落または破損パケットの回復または隠蔽を要求し得る。ファイルパーサおよび復号器160に関する他の配置も可能である。例えば、復号器160は、メディアトラックのメディアサンプルまたはヒントサンプルのそれぞれにそのデータが含まれる場合に、パケットが正しくまたは誤って復号可能であるかについて結論を出し得る。
ヒントトラックが１つ以上のメディアストリーム/型を含みうること、関連のメタデータも含みうることに留意されたい。例えば、音声および映像が、MPEG-2トランスポートストリームにおいてエレメンタリストリームとして搬送される場合、音声および映像は、同一のヒントトラックに記録可能である。さらに、MPEG-2特有の信号伝達も、同一のヒントトラックに含まれることが可能である。
さらに、トランスポートドメインにおいて動作する、暗号化/DRMシステムが存在することに留意されたい。このシステムは、パケットまたはパケットペイロードを、独立して、またはパケットのストリームとして暗号化可能である。（つまり、符号化されたメディアフレームとは対照的である。）提供されるDRM利用権利が、暗号化解除されたフォーマットにおいて、コンテンツの格納を拒否する場合、受信機は、メディアトラックを再構築せず、代わりに、受信したパケットを特別なヒントトラックに格納だけする。
本発明の種々の実施形態を組み込むおよび実装する通信デバイスは、種々の伝送技術を使用して通信してもよく、この通信技術には、符号分割多元接続（Code Division Multiple Access; CDMA）、モバイル通信のためのグローバルシステム（Global System for Mobile Communications; GSM）、ユニバーサル移動体通信システム（Universal Mobile Telecommunications System; UMTS）、時分割多元接続（Time Division Multiple Access; TDMA）、周波数分割多元接続（Frequency Division Multiple Access; FDMA）、伝送制御プロトコル／インターネットプロトコル（Transmission Control Protocol/Internet Protocol; TCP/IP）、ショートメッセージサービス（Short Messaging Service; SMS）、マルチメディアメッセージサービス（Multimedia Messaging Service; MMS）、電子メール、インスタントメッセージサービス（Instant Messaging Service; IMS）、Bluetooth、IEEE 802.11等が含まれるが、これらに限定されない。本発明の種々の実施形態の実装に伴う通信デバイスは、無線接続、赤外線接続、レーザ接続、ケーブル接続、その同等物を含むが、これらに限定されない種々の媒体を使用して通信し得る。
図6および図7は、本発明が実装され得る１つの代表的な電子デバイス12を示す。しかしながら、本発明が、１つの特定の型の電子デバイス12に限定されるように意図されないことを理解されたい。図6および図7の電子デバイス12は、ハウジング30、液晶ディスプレイ形式のディスプレイ32、キーパッド34、マイクロホン36、イヤホン38、バッテリ40、赤外線ポート42、アンテナ44、本発明の一実施形態に従うUICC形式のスマートカード46、カード読み取り器48、無線インターフェース回路52、コーデック回路54、制御器56、メモリ58、電池80を含む。個々の回路および要素は、全て、当技術分野において、例えば、ノキアの種類の携帯電話機において周知のタイプである。
本明細書において説明する本発明の種々の実施形態は、方法ステップまたはプロセスの一般的な内容において説明された。これは、ネットワーク環境においてコンピュータにより実行されるプログラムコード等の、コンピュータにより実行可能な命令を含むプログラムであって、コンピュータ可読媒体に内蔵されるコンピュータによって、具現化され得る。概して、プログラムモジュールは、特定のタスクを実行するか、特定の抽象的なデータ型を実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含みうる。コンピュータにより実行可能な命令、関連のデータ構造、プログラムモジュールは、本明細書に開示する方法のステップを実行するためのプログラムコードの例を表す。特定の一連のこのような実行可能な命令または関連のデータ構造は、このようなステップまたはプロセスにおいて説明する機能を実装するための対応する動作の例を表す。
本発明の種々の実施形態のソフトウェアおよびウェブ実装は、種々のデータベース検索ステップまたはプロセス、相関ステップまたはプロセス、比較ステップまたはプロセス、ならびに決定ステップまたはプロセスを達成するために、法則ベースの論理および他の論理を含む標準的なプログラミング技術により達成することができる。本明細書および以下の請求項で使用する際、単語の「構成要素」および「モジュール」は、１つ以上の種類のソフトウェアコード、および/またはハードウェア実装、および/または手動入力を受信するための設備を使用する実装を包含するように意図されることに留意されたい。
本発明の実施形態に関する前述の説明は、例証目的および説明目的のために提示されている。前述の説明は、包括的であるように、または開示される厳密な形式に本発明の実施形態を限定するように意図されず、また、上記教示を考慮した修正および変形が可能であるか、または、これらの修正および変形は、本発明の実践により入手され得る。本明細書において論じられる実施形態は、本発明の種々の実施形態およびその実用的なアプリケーションに関する原理および性質を説明して、種々の実施形態における本発明および想定される特定の使用に適合する種々の修正を有する本発明を当業者が利用できるように、選択および説明されている。

Claims (8)

  1. メディアコンテンツを含むメディアパケットのストリームを受信することと、
    メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、前記メディアコンテンツをファイルに記録することと、
    を含み、
    前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれ、
    前記受信したメディアパケットのストリームにおける少なくとも１つのメディアパケットは、前記ファイル中に少なくとも１つのヒントトラックのヒントサンプルで表され、前記ヒントサンプルは、メディアパケットがエラーを含むか否かの標示を含む、方法。
  2. 前記ヒントサンプルは、前記ストリーム中の少なくとも１つのパケットの損失に関する標示を含む、請求項１に記載の方法。
  3. 前記エラーは、前記ストリームの通信中のビットエラーかパケット損失の少なくともいずれかを表す、請求項１または２に記載の方法。
  4. 請求項１から３のいずれかに記載の方法をプロセッサに実行させる命令を備える、コンピュータプログラム。
  5. メディアコンテンツを含むメディアパケットのストリームを受信する手段と、
    メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、前記メディアコンテンツをファイルに記録する手段と、
    を備え、
    前記前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれ、
    前記受信したメディアパケットのストリームにおける少なくとも１つのメディアパケットは、前記ファイル中に少なくとも１つのヒントトラックのヒントサンプルで表され、前記ヒントサンプルは、メディアパケットがエラーを含むか否かの標示を含む、装置。
  6. 前記ヒントサンプルは、前記ストリーム中の少なくとも１つのパケットの損失に関する標示を含む、請求項５に記載の装置。
  7. 前記エラーは、前記ストリームの通信中のビットエラーかパケット損失の少なくともいずれかを表す、請求項５または６に記載の装置。
  8. プロセッサとメモリユニットとを備え、前記メモリユニットが、請求項１から３のいずれかに記載の方法を前記プロセッサに実行させるコンピュータ命令を格納する、装置。
JP2010504987A 2007-05-04 2008-05-02 マルチメディアコンテナファイルの受信ヒントトラックに記録するメディアストリーム Expired - Fee Related JP5130352B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US91625607P 2007-05-04 2007-05-04
US60/916,256 2007-05-04
PCT/IB2008/051711 WO2008135932A2 (en) 2007-05-04 2008-05-02 Media stream recording into a reception hint track of a multimedia container file

Publications (2)

Publication Number Publication Date
JP2010526468A JP2010526468A (ja) 2010-07-29
JP5130352B2 true JP5130352B2 (ja) 2013-01-30

Family

ID=39940334

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010504987A Expired - Fee Related JP5130352B2 (ja) 2007-05-04 2008-05-02 マルチメディアコンテナファイルの受信ヒントトラックに記録するメディアストリーム

Country Status (12)

Country Link
US (1) US8078644B2 (ja)
EP (1) EP2145270B1 (ja)
JP (1) JP5130352B2 (ja)
KR (1) KR101107815B1 (ja)
CN (1) CN101675435B (ja)
AP (1) AP2923A (ja)
BR (1) BRPI0810699B1 (ja)
CA (1) CA2684851C (ja)
MX (1) MX2009011873A (ja)
RU (1) RU2434277C2 (ja)
TW (1) TWI500325B (ja)
WO (1) WO2008135932A2 (ja)

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1855887A (zh) * 2005-04-29 2006-11-01 华硕电脑股份有限公司 在接收端中减少数据串流前后跳动的方法及其相关装置
EP1999883A4 (en) 2006-03-14 2013-03-06 Divx Llc FEDERATED DIGITAL RIGHTS MANAGEMENT SYSTEM COMPRISING CONFIDENCE SYSTEMS
US8396082B2 (en) * 2007-06-05 2013-03-12 Core Wireless Licensing S.A.R.L. Time-interleaved simulcast for tune-in reduction
US20080301742A1 (en) * 2007-06-04 2008-12-04 Nokia Corporation Time-interleaved simulcast for tune-in reduction
US9043276B2 (en) * 2008-10-03 2015-05-26 Microsoft Technology Licensing, Llc Packaging and bulk transfer of files and metadata for synchronization
US8510303B2 (en) 2009-01-07 2013-08-13 Divx, Llc Singular, collective and automated creation of a media guide for online content
US8768984B2 (en) * 2009-04-09 2014-07-01 Telefonaktiebolaget L M Ericsson (Publ) Media container file management
WO2011068355A2 (ko) * 2009-12-01 2011-06-09 삼성전자 주식회사 상호 계층 최적화를 이용한 멀티미디어 데이터 패킷을 송신하는 방법 및 장치
WO2011068668A1 (en) 2009-12-04 2011-06-09 Divx, Llc Elementary bitstream cryptographic material transport systems and methods
US8743178B2 (en) * 2010-01-05 2014-06-03 Dolby Laboratories Licensing Corporation Multi-view video format control
CN107196941B (zh) 2010-04-20 2021-09-03 三星电子株式会社 用于传送和接收媒体数据的接口装置和方法
KR20120008432A (ko) * 2010-07-16 2012-01-30 한국전자통신연구원 스트리밍 서비스 송/수신 장치 및 방법
US9602883B2 (en) 2010-07-19 2017-03-21 Lg Electronics Inc. Method for transmitting/receiving media and device for transmitting/receiving using same
CN102447673A (zh) * 2010-09-30 2012-05-09 突触计算机系统（上海）有限公司 一种用于解封装携有封装格式的多媒体文件的方法与设备
US8914534B2 (en) 2011-01-05 2014-12-16 Sonic Ip, Inc. Systems and methods for adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol
EP2728861B1 (en) * 2011-07-02 2017-10-04 Samsung Electronics Co., Ltd. Method and apparatus for multiplexing and demultiplexing video data to identify reproducing state of video data.
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
US8806188B2 (en) 2011-08-31 2014-08-12 Sonic Ip, Inc. Systems and methods for performing adaptive bitrate streaming using automatically generated top level index files
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US8964977B2 (en) 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
KR20130040090A (ko) * 2011-10-13 2013-04-23 삼성전자주식회사 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법
US9674532B2 (en) * 2012-06-24 2017-06-06 Lg Electronics Inc. Image decoding method using information on a random access picture and apparatus using same
WO2014001605A1 (en) * 2012-06-28 2014-01-03 Ant-Advanced Network Technologies Oy Processing and error concealment of digital signals
US11290510B2 (en) 2012-11-29 2022-03-29 Samsung Electronics Co., Ltd. Method and apparatus for encapsulation of motion picture experts group media transport assets in international organization for standardization base media files
US9313510B2 (en) 2012-12-31 2016-04-12 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
US9906785B2 (en) 2013-03-15 2018-02-27 Sonic Ip, Inc. Systems, methods, and media for transcoding video data according to encoding parameters indicated by received metadata
WO2014163467A1 (ko) * 2013-04-05 2014-10-09 삼성전자 주식회사 랜덤 엑세스를 위한 멀티 레이어 비디오 부호화 방법 및 그 장치, 랜덤 엑세스를 위한 멀티 레이어 비디오 복호화 방법 및 그 장치
US9094737B2 (en) 2013-05-30 2015-07-28 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
KR102210509B1 (ko) 2013-06-24 2021-02-01 삼성전자주식회사 멀티미디어 시스템에서 컨텐츠를 변환하는 방법 및 장치
US9967305B2 (en) 2013-06-28 2018-05-08 Divx, Llc Systems, methods, and media for streaming media content
US9614890B2 (en) * 2013-07-31 2017-04-04 Avaya Inc. Acquiring and correlating web real-time communications (WEBRTC) interactive flow characteristics, and related methods, systems, and computer-readable media
WO2015104450A1 (en) * 2014-01-07 2015-07-16 Nokia Technologies Oy Media encapsulating and decapsulating
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
GB2527786B (en) 2014-07-01 2016-10-26 Canon Kk Method, device, and computer program for encapsulating HEVC layered media data
TWI631835B (zh) 2014-11-12 2018-08-01 弗勞恩霍夫爾協會 用以解碼媒體信號之解碼器、及用以編碼包含用於主要媒體資料之元資料或控制資料的次要媒體資料之編碼器
EP3234775A4 (en) * 2014-12-19 2018-11-07 Nokia Technologies Oy Media encapsulating and decapsulating
CN107111477B (zh) 2015-01-06 2021-05-14 帝威视有限公司 用于编码内容和在设备之间共享内容的系统和方法
KR101792519B1 (ko) 2015-06-04 2017-11-02 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10911413B2 (en) * 2015-09-16 2021-02-02 Oracle International Corporation Encapsulating and tunneling WebRTC traffic
WO2018171758A1 (en) * 2017-03-24 2018-09-27 Mediatek Inc. Method and apparatus for deriving vr projection, packing, roi and viewport related tracks in isobmff and supporting viewport roll signaling
US11589032B2 (en) * 2020-01-07 2023-02-21 Mediatek Singapore Pte. Ltd. Methods and apparatus for using track derivations to generate new tracks for network based media processing applications

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6134243A (en) * 1998-01-15 2000-10-17 Apple Computer, Inc. Method and apparatus for media data transmission
WO2004036760A1 (en) * 2002-10-15 2004-04-29 Koninklijke Philips Electronics N.V. System and method for providing error recovery for streaming fgs encoded video over an ip network
JP3719516B2 (ja) 2003-06-11 2005-11-24 ソニー株式会社 情報処理装置および方法、プログラム、並びに記録媒体
US7555009B2 (en) * 2003-11-14 2009-06-30 Canon Kabushiki Kaisha Data processing method and apparatus, and data distribution method and information processing apparatus
JP2005151128A (ja) * 2003-11-14 2005-06-09 Canon Inc データ処理方法および装置
US20050154987A1 (en) 2004-01-14 2005-07-14 Isao Otsuka System and method for recording and reproducing multimedia
ATE511721T1 (de) * 2004-10-06 2011-06-15 Nokia Corp Zusammenstellen von vorwärtsfehlerkorrektur- rahmen
US7447978B2 (en) * 2004-11-16 2008-11-04 Nokia Corporation Buffering packets of a media stream
KR20060086997A (ko) 2005-01-27 2006-08-02 삼성전자주식회사 컨텐츠 재생을 위한 장치간의 자동 인터페이스 방법 및장치와 그 방법을 수행하기 위한 프로그램이 저장된 기록매체
EP1932315A4 (en) * 2005-09-01 2012-05-09 Nokia Corp METHOD FOR INTEGRATING SVG CONTENT INTO ISO MULTIMEDIA FILE FORMAT FOR PROGRESSIVE DOWNLOAD AND CONTINUOUS TRANSMISSION OF RICH MULTIMEDIA CONTENT
US8346789B2 (en) 2005-10-03 2013-01-01 Intel Corporation System and method for generating homogeneous metadata from pre-existing metadata
KR101125819B1 (ko) * 2005-10-11 2012-03-27 노키아 코포레이션 효율적인 규모가변적 스트림 조정을 위한 시스템 및 방법
CN101371312B (zh) * 2005-12-08 2015-12-02 维德约股份有限公司 用于视频通信系统中的差错弹性和随机接入的系统和方法
CN1984231A (zh) * 2005-12-12 2007-06-20 深圳艾科创新微电子有限公司 一种无线媒体接收播放装置及其实现方法
ATE551787T1 (de) * 2006-01-05 2012-04-15 Ericsson Telefon Ab L M Verwaltung von medienbehälterdateien
JP2007318545A (ja) * 2006-05-26 2007-12-06 Canon Inc データ送信装置、データ受信装置、データ送信方法及びデータ受信方法

Also Published As

Publication number Publication date
CN101675435B (zh) 2013-02-06
US20080275905A1 (en) 2008-11-06
TWI500325B (zh) 2015-09-11
BRPI0810699A2 (pt) 2016-09-27
KR101107815B1 (ko) 2012-02-06
EP2145270B1 (en) 2016-08-17
CA2684851A1 (en) 2008-11-13
AP2923A (en) 2014-05-31
CA2684851C (en) 2015-11-24
TW200901761A (en) 2009-01-01
WO2008135932A3 (en) 2009-02-19
MX2009011873A (es) 2009-11-18
US8078644B2 (en) 2011-12-13
KR20100028546A (ko) 2010-03-12
RU2434277C2 (ru) 2011-11-20
EP2145270A2 (en) 2010-01-20
CN101675435A (zh) 2010-03-17
JP2010526468A (ja) 2010-07-29
WO2008135932A2 (en) 2008-11-13
AP2009005050A0 (en) 2009-12-31
BRPI0810699B1 (pt) 2021-03-02

Similar Documents

Publication Publication Date Title
JP5130352B2 (ja) マルチメディアコンテナファイルの受信ヒントトラックに記録するメディアストリーム
US20090177942A1 (en) Systems and methods for media container file generation
RU2481627C2 (ru) Быстрый и удобный для редактирования способ ассоциирования сэмплов для форматов мультимедийных файлов
EP3092772B1 (en) Media encapsulating and decapsulating
KR101757306B1 (ko) 방송 신호 송/수신 처리 방법 및 장치
JP4766473B2 (ja) メディアデータコンテナとメタデータコンテナとを有するファイルを処理し読出すための装置および方法
US20100250633A1 (en) Systems and methods for storage of notification messages in iso base media file format
CN101802823A (zh) 用于流式多媒体数据的分段的元数据和位标
KR20040041174A (ko) 메타-데이터 및 미디어-데이터를 포함하는 멀티미디어파일의 스트리밍
US7555009B2 (en) Data processing method and apparatus, and data distribution method and information processing apparatus
US7711718B2 (en) System and method for using multiple meta boxes in the ISO base media file format
EP3234775A1 (en) Media encapsulating and decapsulating

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111220

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20120309

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20120316

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20120514

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20120521

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120619

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: 20121009

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121105

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 5130352

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151109

Year of fee payment: 3

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees