(57)【要約】本発明は、符号化コンテンツが特定の付加的なヒントトラックと共に．ｍｐ４ファイルフォーマットで記憶されるＭＰＥＧ−４符号器に関する。これらのトラックは、パケット伝送（ｐａｃｋｅｔｉｚｅｄ ｔｒａｎｓｍｉｓｓｉｏｎ）（ＡＴＭ、ＭＰＥＧ−２ ＴＳ、ＩＰ、…）に用いられるパケットの大きさに合致させるためにアクセスユニットに編成される符号化データを断片化する方法を示すプリセグメンテーション情報を含む。本発明によれば、符号化ビットストリームを独立エンティティ中に構成する断片化情報は、符号化する間に、．ｍｐ４ファイルから独立している断片構造中に記憶される。本発明はまた、斯様な符号器の出力部において利用可能な符号化信号、及び前記符号化信号を受け取り、適当な構文を持つファイル構造に応じて該符号化信号を読み取る端末にも関する。【特許請求の範囲】
【請求項１】
伝送ネットワークによって送られるべき出力符号化コンテンツに対応するビットストリームが、メディアトラックとして所謂．ｍｐ４ファイルフォーマットで記憶され、転送機構が、特定ヒントトラックを付加することによりファイル中にメディアトラック毎に１つ記憶され、前記ヒントトラックは、前記符号化コンテンツを所与のタイプのネットワークに対応する伝送パケットの大きさに適合させるため、前記メディアトラックに記憶されるＭＰＥＧ−４データエンティティ（又はアクセスユニット）を該パケットの大きさに合致させるために断片化する方法を示すプリセグメンテーション情報を含めるのに用いられるＭＰＥＧ−４符号器であり、パケットが失われる場合でもいくらかの文脈を回復させるために目下独立しているエンティティ中に符号化ビットストリームを構成する断片化情報が、符号化する間に、前記．ｍｐ４ファイルから独立している断片構造ファイル中に記憶されるようなＭＰＥＧ−４符号器。
【請求項２】
伝送ネットワークによって送られるべきビットストリームの形態でＭＰＥＧ−４符号器の出力部において利用可能な、一方で所謂．ｍｐ４ファイルフォーマットで記憶されるメディアデータを含み、他方で前記メディアデータに対応するＭＰＥＧ−４データエンティティ（又はアクセスユニット）を前記伝送ネットワークのパケットの大きさに合致させるために断片化する方法を示すプリセグメンテーション情報を含む符号化信号。
【請求項３】
請求項２に記載の符号化信号を受け、
−ＭＰＥＧ−４アクセスユニットにおいて、ファイルの終わりまで、各アクセスユニットに対して以下をループする、
−断片の数Ｎを読み取る、
−断片において、Ｎ個まで、各断片に対して以下をループする、
−（ビット単位で）断片の大きさを読み取る、
−断片におけるループの終わり、
−アクセスユニットにおけるループの終わり
という構文を持つファイル構造に応じて前記符号化信号が読み取られるＭＰＥＧ−４端末。
【請求項４】
ヒント添付プログラムが、最適のヒントトラックを収容している新しい．ｍｐ４ファイルを前記．ｍｐ４ファイルと共に生成するために供給され、次いで、ヒント付きの前記ファイルが、関係しているアプリケーションに応じて当該端末により用いられる請求項３に記載のＭＰＥＧ−４端末。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、伝送ネットワークによって送られるべき出力符号化コンテンツに対応するビットストリームが、メディアトラックとして所謂．ｍｐ４ファイルフォーマットで記憶され、転送機構（ｔｒａｎｓｐｏｒｔ ｍｅｃｈａｎｉｓｍ）が、特定ヒントトラックを付加することによりメディアトラック毎に１つ記憶され、前記ヒントトラックは、前記符号化コンテンツを所与のタイプのネットワークに対応する伝送パケットの大きさに適合させるため、前記メディアトラックに記憶されるＭＰＥＧ−４データエンティティ（又はアクセスユニット）を該パケットの大きさに合致させるために断片化する（ｆｒａｇｍｅｎｔ）方法を示すプリセグメンテーション情報（ｐｒｅ−ｓｅｇｍｅｎｔａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を含めるのに用いられるＭＰＥＧ−４符号器に関する。本発明は、ＭＰＥＧ−４規格による、それ故ＭＰＥＧ−４ファイルフォーマット（ファイル拡張子．ｍｐ４）を用いるビデオ・オン・デマンド関連の用途に供される。
【０００２】
【従来の技術】
ネットワークを介する転送、又はストリーミングを取り扱うために、ＭＰＥＧ−１規格及びＭＰＥＧ−２規格は、ファイルに書き込まれ得るビットストリーム構造を規定し、そして別個に転送機構（例えばＭＰＥＧ−２ ＴＳ）を規定した。しかしながら、所与のタイプのコンテンツは、各々が特定の性質を持つ実に様々な転送（又はネットワーク）システム、例えばＡＴＭ又はＩＰにおいて転送され得る。その場合には、最適性のために特定の転送の機構のセットが規定されなければならず、このことは、コンテンツ製作者（ｃｏｎｔｅｎｔ ｍａｋｅｒ）が所与の「転送」フォーマットで符号化コンテンツを記憶する方法を規定している場合には、前記フォーマットはおそらく異なるネットワークにおいて最適に再利用することは出来ないであろうという問題を招く。
【０００３】
ＭＰＥＧ−４システムの仕様は、ストリーミングを取り扱う特定の方式を持つファイルフォーマット、．ｍｐ４を規定しており、符号化コンテンツはメディアトラックとして．ｍｐ４ファイルフォーマットで記憶される（例えば、オーディオはメディアトラックであり、ビデオは別のメディアトラックである等々）。更に、転送機構が、特定ヒントトラックを付加することによりファイル中にメディアトラック毎に１つ記憶され得る。即ち、斯様な機構では、単一のファイルが、メディアトラック中のメディアデータ自体及びヒントトラック中の転送の特定のデータのための単一のコンテナとして用いられ得る。そして、このファイルが異なる２つのネットワークにおける転送のために書かれる場合には、メディアトラック毎の２つのヒントトラックなどがあるであろう。
【０００４】
これらのヒントトラックは必須でないことに注意されたい。前記ヒントトラックは例えば（ディスクからの）ローカルな再生には必要とされない。その上、これらのヒントトラックは無視し得ない大きさを持つ。実際には、サーバのパフォーマンスの観点から、最適のヒントの添付（ｈｉｎｔｉｎｇ）は、ヒントトラック中にネットワークパケットを直接的に記憶することにより、元のファイルの２倍以上の大きさを持つファイルを必要とする。それ故、ヒントトラックは、該ヒントトラックが必要であることが確実でない場合には、ファイル中に必要とされない。
【０００５】
ＭＰＥＧ−４ファイルフォーマットは規範的に規定されており、メディアトラック中に記憶されるデータエンティティがＭＰＥＧ−４アクセスユニットであり、ＭＰＥＧ−４アクセスユニットは一般にネットワークパケットより大きい。そして、ヒントトラックの役割は、ネットワークパケットがどのように作られ、前記ネットワークパケットがどのように満たされ得るのかについての情報を記憶することにあり、ヒントトラックは、サーバが各アクセスユニットをネットワークパケットに断片化する方法を知るようにプリセグメンテーション情報を実際に収容している。それ故、先ずメディアトラックを生成し、前記メディアトラックを．ｍｐ４ファイル中に記憶し、次いで、このファイルをパーズ（ｐａｒｓｅ）し、アクセスユニット構造を解析し、適切な付加的なヒントトラックを生成するために別個のヒント添付プログラム（ｈｉｎｔｅｒ ｐｒｏｇｒａｍ）を用いることが出来る。
【０００６】
しかしながら、最大のネットワークパケットの大きさに対応するパケットを構成するブラインド・セグメンテーション（ｂｌｉｎｄ ｓｅｇｍｅｎｔａｔｉｏｎ）、又は関係しているメディアに対して規定される誤り耐性戦略（ｅｒｒｏｒ ｒｅｓｉｌｉｅｎｃｅ ｓｔｒａｔｅｇｙ）を当てにするスマート・セグメンテーション（ｓｍａｒｔ ｓｅｇｍｅｎｔａｔｉｏｎ）のいずれかである、パケットを生成する２つの主要な方式がある。損失が生じる場合には、（クライアント側の）復号器がギャップの後のビットストリームを正確に復号することは困難であり得る。ビットストリームは一般に最小限の帯域使用のために設計されている（このことは可能な限り冗長性が取り除かれていることを意味する）ので、項目（ｉｔｅｍ）を認識するには、ビットストリームの断片（ｆｒａｇｍｅｎｔ）自体が失われる場合に失われ得るいくらかの文脈（ｃｏｎｔｅｘｔ）を必要とする。
【０００７】
この問題を解決するため、ビットストリームは独立エンティティ（又は断片）中に構成され、故に各断片は１つのネットワークパケットにおいて転送され得る。パケットが失われる場合には、独立エンティティである次のパケットが、復号器が損失をものともせずいくらかの文脈を回復させることを可能にする。メディア固有のものである（各メディアのタイプ、即ちオーディオ、ビデオ、…に対して異なり、別個の符号化オプションに対してさえも異なる）断片化情報（ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ） は、．ｍｐ４ファイルフォーマットのヒントトラック中に置かれ、符号器の出力部において利用可能である。パケット損の場合には、メディアがヒントトラックなしに符号化する間に．ｍｐ４ファイル中に記憶される場合に、スマート断片化情報が失われ、ヒント添付プログラムはブラインド・セグメンテーションしか行うことが出来ず、このことは、復号問題（大きなプリゼンテーション品質の劣化）をもたらす。
【０００８】
【課題を解決するための手段】
それ故、本発明の目的は、データエンティティの転送のための別の解決策を実施するＭＰＥＧ−４符号器を提案することにある。
【０００９】
この目的のため、本発明は明細書の導入部に規定されているＭＰＥＧ−４符号器に関し、更に、前記ＭＰＥＧ−４符号器は、パケットが失われる場合でもいくらかの文脈を回復させるために目下独立しているエンティティ中に符号化ビットストリームを構成する断片化情報が、符号化する間に、前記．ｍｐ４ファイルから独立している断片構造ファイル（ｆｒａｇｍｅｎｔ ｓｔｒｕｃｔｕｒｅ ｆｉｌｅ）中に記憶されるようなＭＰＥＧ−４符号器である。
【００１０】
コンテンツ生産者（ｃｏｎｔｅｎｔ ｐｒｏｄｕｃｅｒ）のための解決策は、常に、２つの．ｍｐ４ファイル、ヒントトラックを備える．ｍｐ４ファイル及びヒントトラックのない別の．ｍｐ４ファイルを生成することにある。しかしながら、ヒント付きファイル（ｈｉｎｔｅｄ ｆｉｌｅ）は元のファイルの２倍以上大きいことから、この従来の解決策の場合に必要とされる記憶容量は、元のメディアの大きさの３倍以上である。提案した解決策は、断片化情報ファイルがメディアの大きさと比べて非常に小さいことから、よりはるかに効率的である。
【００１１】
別の解決策は、常にヒント付きファイルを生成し、特定のツールを用いて、このファイルを編集し、ヒント付きトラックを取り除き、メディアデータしか持たない．ｍｐ４ファイルを作成せんとするものであろう。しかしながら、この解決策は、別個のエディションステップを含む。その上、前記ヒントトラックはネットワーク固有のものであり（ＡＴＭ、ＭＰＥＧ−２ ＴＳ又はＩＰに対して異なるヒントトラックが必要とされる）、この解決策は、容易には例えばＡＴＭ転送からＩＰ転送に変わることを許容しない。反対に、本発明による解決策では、全ての所要情報を収容している断片化情報ファイルが、ネットワーク固有のものではなく、それ故、如何なるネットワーク固有のヒント付きファイルの生成に対しても用いられ得る。
【００１２】
本発明はまた、伝送ネットワークによって送られるべきビットストリームの形態で斯様な符号器の出力部において利用可能な、一方で所謂．ｍｐ４ファイルフォーマットで記憶されるメディアデータを含み、他方で前記メディアデータに対応するＭＰＥＧ−４データエンティティ（又はアクセスユニット）を前記伝送ネットワークのパケットの大きさに合致させるために断片化する方法を示すプリセグメンテーション情報を含む符号化信号に関する。
【００１３】
更に、本発明は、斯様な符号化信号を受けるＭＰＥＧ−４端末に関し、前記符号化信号は以下の構文を持つファイル構造に応じて読み取られる。
−ＭＰＥＧ−４アクセスユニットにおいて、ファイルの終わりまで、各アクセスユニットに対して以下をループする、
−断片の数Ｎを読み取る、
−断片において、Ｎ個まで、各断片に対して以下をループする、
−（ビット単位で）断片の大きさを読み取る、
−断片におけるループの終わり、
−アクセスユニットにおけるループの終わり。
【００１４】
【発明の実施の形態】
本発明の原理は、符号化する間に、断片化情報を別個に記憶することにある。この場合に、符号化プロセスは、１つのファイル（．ｍｐ４ファイル）しか生成しないのではなく、同時に２つのファイル、即ちメディアを備える．ｍｐ４ファイル及び断片構造ファイルを作成するであろう。コンテンツの符号化の後に、生産者が該コンテンツをストリーミングアプリケーションにおいて用いることを決定する場合には、ヒントの添付が必要とされる。通常、ブラインド・セグメンテーションしか行われ得ない。しかしながら、最適の（メディア固有の）断片化を含有する別個のファイルがアーカイブされている場合には、前記ファイルが、最適のヒントトラックを収容している新しい．ｍｐ４ファイルを生成するために−前記．ｍｐ４ファイルと共に−ヒント添付プログラムにより用いられ得る。その場合には、このヒント付きファイルが、多重再生（ｍｕｌｔｉｐｌｅ ｐｌａｙｂａｃｋ）のため、ビデオ・オン・デマンドサーバにより用いられ得る。
【００１５】
他の例において、放送アプリケーション（ｂｒｏａｄｃａｓｔｉｎｇ ａｐｐｌｉｃａｔｉｏｎ）は、コンテンツの「生」放送のためのヒント付きファイルを用いることができ、又は前記コンテンツの「生」放送のための断片構造ファイル及び元の（即ちヒントが添付されていない）．ｍｐ４ファイルも用いることが出来る。
【００１６】
提案したファイル構造は、以下に示すような構文を持つ。
−ＭＰＥＧ−４アクセスユニットにおいて、ファイルの終わりまで、各アクセスユニットに対して以下をループする、
−断片の数Ｎを読み取る、
−断片において、Ｎ個まで、各断片に対して以下をループする、
−（ビット単位で）断片の大きさを読み取る、
−断片におけるループの終わり、
−アクセスユニットにおけるループの終わり。
【００１７】
断片の大きさがビット単位であるべき理由は、幾つかのメディアが断片の大きさが８ビットの倍数ではない（即ちバイト数が整数ではない）最適の断片を持つことにある。斯様な状況の例は、ＭＰＥＧ−４ビデオの「データパーティション」のアクセスユニットの断片により与えられる。ファイルがバイナリファイルである場合には、断片の数が非常に大きくはなり得ないことから、Ｎに対しては１６ビットで十分であろう。同様に、断片の大きさに対しては１６ビットで十分であろう（最大の断片の大きさは８０００バイトより大きくなるであろう）。
【００１８】
他の方法は、分離文字（ｓｅｐａｒａｔｏｒ ｃｈａｒａｃｔｅｒ）、典型的にはスペース及び／又は行の終わりの符号（ｅｎｄ ｏｆ ｌｉｎｅ ｃｈａｒａｃｔｅｒ）での数のＡＳＣＩＩ（普通テキスト）表現を用いるものである。その場合には、ｆｓｃａｎｆ（“％ｄ”）などの標準的なＣ関数を用いることが出来るからである。
【国際公開パンフレット】
2004505519.tif 000002
2004505519.tif 000003
2004505519.tif 000004
2004505519.tif 000005
2004505519.tif 000006
2004505519.tif 000007
2004505519.tif 000008
【国際調査報告】
2004505519.tif 000009
2004505519.tif 000010
2004505519.tif 000011