(57)【要約】【課題】  多重化すべきデータの入力が途絶えた場合にも、エンコーダとの間で互いに情報をやり取りすることなく、独立して正常に多重化処理を実行し続けるようにする。【解決手段】  ＭＵＸ２０のデータサイズ判定部２１は、ビデオＩｎｆｏバッファ１５から読み出したＡＵ＿Ｉｎｆｏを基にして、パック内のペイロード領域を満たすだけのアクセスユニットのデータがビデオＥＳバッファ１３に格納されているか否かを判定し、パック生成部２２は、データサイズ判定部２１により条件を満たすと判定された場合に、必要なアクセスユニットのデータをビデオＥＳバッファ１３から読み出して、１つのパックを生成して出力する。【選択図】  図１
2006135603.tif 000002
【特許請求の範囲】
【請求項１】
複数のエンコーダによってそれぞれ生成された符号化ストリームが、デコード時のアクセス単位であるアクセスユニットごとに一時的に格納される符号化ストリームバッファと、前記符号化ストリームバッファに格納された前記アクセスユニットに関するユニット情報が格納されるユニット情報バッファとから、データを受け取って多重化ストリームを生成するストリーム多重化装置において、
前記ユニット情報バッファから読み出した前記ユニット情報を基にして、前記多重化ストリームを構成するデータ群のペイロード領域を満たすだけの前記アクセスユニットのデータが前記符号化ストリームバッファに格納されているか否かを判定するデータサイズ判定手段と、
前記データサイズ判定手段により条件を満たすと判定された場合に、必要な前記アクセスユニットのデータを前記符号化ストリームバッファから読み出し、１つの前記データ群を生成して出力するデータ群生成手段と、
を有することを特徴とするストリーム多重化装置。
【請求項２】
前記データサイズ判定手段は、前記ユニット情報バッファから読み出した前記ユニット情報のうち、対応する前記アクセスユニットのデータサイズの情報を基にして判定処理を行うことを特徴とする請求項１記載のストリーム多重化装置。
【請求項３】
前記データ群生成手段により前記アクセスユニットのデータの一部が前記データ群のペイロード領域に格納しきれなかった場合、前記データサイズ判定手段は、格納されなかった残りのデータが次の前記データ群のペイロード領域を満たすか否かを判定し、満たす場合は、前記データサイズ判定手段が前記残りのデータを用いて前記データ群を生成し、満たさない場合は、前記データサイズ判定手段が、次の前記アクセスユニットに対応する前記ユニット情報が前記ユニット情報バッファに格納されるのを待機し、当該ユニット情報が格納されると、当該ユニット情報に対応する前記アクセスユニットのデータと前記残りのデータとにより前記ペイロード領域を満たすか否かを判定することを特徴とする請求項１記載のストリーム多重化装置。
【請求項４】
前記データサイズ判定手段は、前記符号化ストリームバッファ内の現在の先頭の前記アクセスユニットのデータにより前記データ群のペイロード領域を満たすことができないと判定した場合には、次の前記アクセスユニットに対応する前記ユニット情報が前記ユニット情報バッファに格納されるのを待機し、当該ユニット情報が格納されると、当該ユニット情報および先頭の前記アクセスユニットに対応する前記ユニット情報に基づいて、先頭およびその次の前記アクセスユニットの各データにより前記ペイロード領域を満たすか否かを判定することを特徴とする請求項１記載のストリーム多重化装置。
【請求項５】
多重化ストリームを生成して記録媒体に記録するストリーム記録装置において、
個別の符号化ストリームをそれぞれ生成する複数の符号化手段と、
前記符号化手段によって生成された前記符号化ストリームを、デコード時のアクセス単位であるアクセスユニットごとに一時的に記憶する符号化ストリームバッファと、
前記符号化ストリームバッファに格納された前記アクセスユニットに関するユニット情報を前記符号化手段から受け取って一時的に記憶するユニット情報バッファと、
前記ユニット情報バッファから読み出した前記ユニット情報を基にして、前記多重化ストリームを構成するデータ群のペイロード領域を満たすだけの前記アクセスユニットのデータが前記符号化ストリームバッファに格納されているか否かを判定するデータサイズ判定手段と、
前記データサイズ判定手段により条件を満たすと判定された場合に、必要な前記アクセスユニットのデータを前記符号化ストリームバッファから読み出し、１つの前記データ群を生成して前記多重化ストリームとして出力するデータ群生成手段と、
を有することを特徴とするストリーム記録装置。
【請求項６】
複数のエンコーダによってそれぞれ生成された符号化ストリームが、デコード時のアクセス単位であるアクセスユニットごとに一時的に格納される符号化ストリームバッファと、前記符号化ストリームバッファに格納された前記アクセスユニットに関するユニット情報が格納されるユニット情報バッファとから、データを受け取って多重化ストリームを生成するためのストリーム多重化方法において、
データサイズ判定手段が、前記ユニット情報バッファから読み出した前記ユニット情報を基にして、前記多重化ストリームを構成するデータ群のペイロード領域を満たすだけの前記アクセスユニットのデータが前記符号化ストリームバッファに格納されているか否かを判定するデータサイズ判定ステップと、
前記データサイズ判定ステップで条件を満たすと判定された場合に、データ群生成手段が、必要な前記アクセスユニットのデータを前記符号化ストリームバッファから読み出し、１つの前記データ群を生成して出力するデータ群生成ステップと、
を含むことを特徴とするストリーム多重化方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の符号化ストリームを多重化するストリーム多重化装置、これを備えたストリーム記録装置、およびストリーム多重化方法に関し、特に、符号化ストリームを生成するエンコーダとは独立して動作することが可能なストリーム多重化装置、これを備えたストリーム記録装置、およびストリーム多重化方法に関する。
【背景技術】
【０００２】
近年、ＭＰＥＧ（Moving Picture Experts Group）方式などの画像圧縮技術の進歩などに伴い、画像信号をデジタル化して取り扱うことが一般的になっている。例えば、光ディスクなどの各種記録媒体に対して動画像をデジタルデータとして記録するデジタルビデオレコーダなどが広く普及している。
【０００３】
ＭＰＥＧ方式では、圧縮符号化したビデオやオーディオのデータ（ＥＳ：Elementary Stream）を時分割多重化して、１つのストリーム（ＰＳ：Program Stream）が生成される。ＰＳは、パックおよびパケットという階層構造により構成されており、ビデオＥＳ，オーディオＥＳのデータはそれぞれビデオパケット，オーディオパケットに分割して格納され、これらの複数のパケットによってパックが構成される。また、パケットのヘッダには、復号時刻や再生時刻などの時刻管理情報が記録され、これによりエンコーダ側で意図したタイミングでストリームを同期再生することが可能となる。
【０００４】
図６は、ＭＰＥＧ方式を用いた従来のストリーム生成装置の要部構成を示す図である。
ストリーム生成装置は、図６に示すように、ビデオエンコーダ１０１、オーディオエンコーダ１０２、ビデオＥＳバッファ１０３、ビデオＩｎｆｏバッファ１０４、オーディオＥＳバッファ１０５、オーディオＩｎｆｏバッファ１０６、およびＭＵＸ（Multiplexer）１０７を備える。
【０００５】
ビデオエンコーダ１０１およびオーディオエンコーダ１０２は、それぞれビデオデータおよびオーディオデータを圧縮符号化し、符号化後のＥＳのデータをアクセスユニット（ＡＵ）単位でビデオＥＳバッファ１０３およびオーディオＥＳバッファ１０５に順次格納する。１つのアクセスユニットは、ビデオでは１フレームまたは１フィールドのピクチャ、オーディオではオーディオフレームによりそれぞれ構成される。
【０００６】
また、ビデオエンコーダ１０１およびオーディオエンコーダ１０２は、出力したＡＵに関する情報（ＡＵ＿Ｉｎｆｏ）をそれぞれビデオＩｎｆｏバッファ１０４、オーディオＩｎｆｏバッファ１０６に格納する。ＡＵ＿Ｉｎｆｏとしては、ＡＵの各Ｉｎｆｏバッファ上の位置情報、データサイズ、再生出力時刻の管理情報であるＰＴＳ（Presentation Time Stamp）、デコード時刻の管理情報であるＤＴＳ（Decoding Time Stamp）などが記録される。
【０００７】
ＭＵＸ１０７は、各Ｉｎｆｏバッファの情報を参照しながら、ビデオＥＳバッファ１０３およびオーディオＥＳバッファ１０５からデータを読み出してそれぞれビデオパケット、オーディオパケットに格納していき、これらのパケットをパックに多重化してＰＳを完成させ、出力する。このとき、ＡＵの先頭データを含むパケットヘッダに時刻管理情報（ＤＴＳ，ＰＴＳ）を記録するとともに、これらの時刻の基準参照値であるＳＣＲ（System Clock Reference）をパックのシステムヘッダに記録する。
【０００８】
このような情報をストリーム中に記録しておくことにより、再生装置は、ＳＣＲの値を参照して、符号器側で意図した基準時刻を復号器内部のＳＴＣ（System Time Clock）といわれる同期信号において再現し、このＳＴＣの値とＰＴＳおよびＤＴＳとを基に対応するＡＵのデコードおよび再生出力のタイミングを制御して、ビデオおよびオーディオの同期再生を行うことが可能となる。
【０００９】
また、ＥＳの多重化に際しては、Ｐ−ＳＴＤ（Program-System Target Decoder）といわれる標準的なデコーダのモデルが定義されており、符号器側ではこのＰ−ＳＴＤにおいて正しくデコード処理できるようにする必要がある。具体的には、ＭＵＸ１０７は、符号器側で想定されているＰ−ＳＴＤバッファがオーバフローしたりアンダフローしたりしないように符号量を管理しながら多重化する（例えば、特許文献１参照）。さらに、上記のバッファ管理のためのスケジューリング処理と、その処理に従ったデータの多重化処理との処理時間の差を吸収するために、スケジュール情報と多重化すべき付加データとをスケジューラとＭＵＸとの間の中間バッファを格納するようにしたものがあった（例えば、特許文献２参照）。
【特許文献１】特開平８−３３５３７１号公報（段落番号〔００１３〕〜〔００１７〕、図１１）
【特許文献２】特開平１０−２７６１６４号公報（段落番号〔００５７〕〜〔００７６〕、図１）
【発明の開示】
【発明が解決しようとする課題】
【００１０】
ところで、上述したようなストリーム生成装置を具備するビデオレコーダなどの機器では、多くの機能が要求され、制御処理が徐々に複雑化する傾向にある。このため、例えばエンコーダやＭＵＸなどの個々の機能の制御をそれぞれリアルタイムＯＳ（Operating System）上のタスクとして実装し、各機能の開発や検証の効率を向上させることが考えられている。
【００１１】
しかし、エンコーダとＭＵＸの各制御を個別のタスクとした場合には、エンコーダは入力データに応じて決まるタイミングで動作するのに対し、ＭＵＸは多重化レートに基づくタイミングで動作する。このため、多重化すべきデータがＥＳバッファにない場合でも、ＭＵＸはこのことに関係なく動作し続けて、データの格納されていない不要なパケットを出力し続けるといった異常な事態が生じてしまう。
【００１２】
例えば、ビデオデータやオーディオデータのエンコード中は、基本的に、エンコーダに対する入力データが途切れることはない。このため、ＭＵＸの動作が遅い場合、ＭＵＸで何らかの障害が発生した場合、ＥＳバッファの容量が足りない場合などには、エンコードしたＡＵのデータをＥＳバッファに格納することができない、あるいは読み出し前のデータを上書きしてしまうといった障害が発生する。このような障害はシステムにとって致命的なものであるため、その発生を防止するためには、ＥＳバッファの容量を増やすか、あるいは十分な速度でＥＳバッファからデータを取り出して多重化ストリームを生成するようにＭＵＸを設計する必要がある。
【００１３】
しかし、ＭＵＸの読み出し速度を高めた場合には、ＡＵごとのエンコード処理に要する時間の変動により、ＥＳバッファに多重化すべきＡＵが存在しない状態が生じる可能性がある。従来のＭＵＸでは、エンコーダ側と通信して同期動作することでこのような状態を検出し、不要なパケットの生成を防止していたが、それでは各部の制御を個別のタスクとすることができない。また例えば、ＭＵＸがＥＳバッファ内の入力データサイズなどを検出して管理しながら動作することで、各部が通信することなく上記事態を回避できるが、この場合にはＭＵＸによるＥＳバッファへのアクセス回数が増加し、異常判定の処理が複雑になることが問題となる。
【００１４】
本発明はこのような点に鑑みてなされたものであり、多重化すべきデータの入力が途絶えた場合にも、エンコーダとの間で互いに情報をやり取りすることなく、独立して正常に動作し続けることが可能なストリーム多重化装置を提供することを目的とする。
【００１５】
また、本発明の他の目的は、多重化すべきデータの入力が途絶えた場合にも、エンコーダとの間で互いに情報をやり取りすることなく、独立して正常に動作し続けることが可能なストリーム多重化装置を備えたストリーム記録装置を提供することである。
【００１６】
さらに、本発明の他の目的は、多重化すべきデータの入力が途絶えた場合にも、エンコーダとの間で互いに情報をやり取りすることなく、独立して正常に動作し続けることが可能なストリーム多重化方法を提供することである。
【課題を解決するための手段】
【００１７】
本発明では上記課題を解決するために、複数のエンコーダによってそれぞれ生成された符号化ストリームが、デコード時のアクセス単位であるアクセスユニットごとに一時的に格納される符号化ストリームバッファと、前記符号化ストリームバッファに格納された前記アクセスユニットに関するユニット情報が格納されるユニット情報バッファとから、データを受け取って多重化ストリームを生成するストリーム多重化装置において、前記ユニット情報バッファから読み出した前記ユニット情報を基にして、前記多重化ストリームを構成するデータ群のペイロード領域を満たすだけの前記アクセスユニットのデータが前記符号化ストリームバッファに格納されているか否かを判定するデータサイズ判定手段と、前記データサイズ判定手段により条件を満たすと判定された場合に、必要な前記アクセスユニットのデータを前記符号化ストリームバッファから読み出し、１つの前記データ群を生成して出力するデータ群生成手段とを有することを特徴とするストリーム多重化装置が提供される。
【００１８】
このようなストリーム多重化装置では、データサイズ判定手段によって、多重化ストリームを構成するデータ群のペイロード領域を満たすだけのアクセスユニットのデータが符号化ストリームバッファに格納されていると判定された場合にのみ、データ群生成手段が、そのアクセスユニットのデータを符号化ストリームバッファから読み出して１つのデータ群を生成する。このため、エンコーダとの処理速度の違いやエンコーダでの障害発生などにより、多重化するための十分なアクセスユニットが生成されていない場合に、余分なデータ群を出力し続けるという異常な動作を行うことがなくなる。そして、データサイズ判定手段は、上記の判定をユニット情報バッファ内のユニット情報を基にして行うので、エンコーダとの間でデータのやり取りを行うことなく、エンコーダとは独立して多重化処理を正常に実行し続けるようになる。
【００１９】
また、本発明では、複数のエンコーダによってそれぞれ生成された符号化ストリームが、デコード時のアクセス単位であるアクセスユニットごとに一時的に格納される符号化ストリームバッファと、前記符号化ストリームバッファに格納された前記アクセスユニットに関するユニット情報が格納されるユニット情報バッファとから、データを受け取って多重化ストリームを生成するためのストリーム多重化方法において、データサイズ判定手段が、前記ユニット情報バッファから読み出した前記ユニット情報を基にして、前記多重化ストリームを構成するデータ群のペイロード領域を満たすだけの前記アクセスユニットのデータが前記符号化ストリームバッファに格納されているか否かを判定するデータサイズ判定ステップと、前記データサイズ判定ステップで条件を満たすと判定された場合に、データ群生成手段が、必要な前記アクセスユニットのデータを前記符号化ストリームバッファから読み出し、１つの前記データ群を生成して出力するデータ群生成ステップと含むことを特徴とするストリーム多重化方法が提供される。
【００２０】
このようなストリーム多重化方法では、データサイズ判定ステップにおいて、多重化ストリームを構成するデータ群のペイロード領域を満たすだけのアクセスユニットのデータが符号化ストリームバッファに格納されていると判定された場合にのみ、データ群生成ステップが実行されて、アクセスユニットのデータが符号化ストリームバッファから読み出されて１つのデータ群が生成される。このため、エンコーダとの処理速度の違いやエンコーダでの障害発生などにより、多重化するための十分なアクセスユニットが生成されていない場合に、余分なデータ群を出力し続けるという異常な動作を行うことがなくなる。そして、データサイズ判定ステップでは、上記の判定をユニット情報バッファ内のユニット情報を基にして行うので、エンコーダとの間でデータのやり取りを行うことなく、エンコーダとは独立して多重化処理を正常に実行し続けるようになる。
【発明の効果】
【００２１】
本発明によれば、データ群のペイロード領域を満たすだけのアクセスユニットのデータが用意されていると判定された場合にのみ、アクセスユニットのデータを符号化ストリームバッファから読み出して１つのデータ群を生成するため、エンコーダとの処理速度の違いやエンコーダでの障害発生などにより、多重化するための十分なアクセスユニットが生成されていない場合に、余分なデータ群を出力し続けるという異常な動作を行うことがなくなる。そして、上記の判定をユニット情報バッファ内のユニット情報を基にして行うので、エンコーダとの間でデータのやり取りを行うことなく、エンコーダとは独立して多重化処理を正常に実行し続けることができる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の実施の形態について図面を参照して詳細に説明する。
ここでは、ＭＰＥＧストリームを生成して記録媒体に記録するストリーム記録装置に、本発明を適用した場合を想定して説明する。このようなストリーム記録装置としては、例えば、デジタルビデオレコーダ、デジタルビデオカメラなどがある。
【００２３】
図１は、実施の形態に係るストリーム記録装置の構成を示すブロック図である。
図１に示すストリーム記録装置は、ビデオ信号、オーディオ信号をそれぞれＭＰＥＧ方式で圧縮符号化するビデオエンコーダ１１およびオーディオエンコーダ１２、生成されたビデオＥＳ、オーディオＥＳをそれぞれ一時的に記憶するビデオＥＳバッファ１３およびオーディオＥＳバッファ１４と、ビデオＥＳおよびオーディオＥＳに関する情報がそれぞれ格納されるビデオＩｎｆｏバッファ１５およびオーディオＩｎｆｏバッファ１６と、ビデオＥＳおよびオーディオＥＳを時分割多重化するＭＵＸ２０と、多重化されたＭＰＥＧストリームの記録処理を行う記録処理部３１と、ＭＰＥＧストリームが記録される記録媒体３２と、これらを統括的に制御するシステムコントローラ４０とを具備する。
【００２４】
ビデオエンコーダ１１およびオーディオエンコーダ１２には、例えばテレビチューナや外部入力端子、ネットワークＩ／Ｆなどからのビデオ信号、オーディオ信号が、それぞれデジタルデータとして入力される。あるいは、固体撮像素子により撮像されたビデオ信号や、マイクにより収音されたオーディオ信号がそれぞれ入力されてもよい。
【００２５】
ビデオエンコーダ１１は、入力されたビデオ信号を圧縮符号化し、符号化したビデオＥＳのＡＵ（ピクチャ）をビデオＥＳバッファ１３に順次格納する。これとともに、出力したＡＵに関する情報（ＡＵ＿Ｉｎｆｏ）をビデオＩｎｆｏバッファ１５に格納する。オーディオエンコーダ１２は、入力されたオーディオ信号を圧縮符号化し、符号化したオーディオＥＳのＡＵ（オーディオフレーム）をオーディオＥＳバッファ１４に順次格納する。これとともに、出力したＡＵに関するＡＵ＿ＩｎｆｏをオーディオＩｎｆｏバッファ１６に格納する。なお、ＡＵ＿Ｉｎｆｏとしては、ＡＵの各Ｉｎｆｏバッファ上の位置情報、データサイズ、ＰＴＳ、ＤＴＳなどが記録される。
【００２６】
ＭＵＸ２０は、ビデオＥＳバッファ１３およびオーディオＥＳバッファ１４からのビデオＥＳおよびオーディオＥＳをＡＵ単位で読み出し、パケットに分割して格納し、さらに複数のパケットによりパックを生成して各ＥＳを多重化し、多重化ストリーム（ＰＳ）を出力する。このとき、必要に応じてビデオＩｎｆｏバッファ１５およびオーディオＩｎｆｏバッファ１６内のＡＵ＿Ｉｎｆｏを読み出し、さらにＳＣＲやストリームＩＤなどの情報を生成して、パケットヘッダやパックヘッダに格納する。
【００２７】
記録処理部３１は、ＭＵＸ２０からのＰＳに対して誤り訂正符号などを付加し、さらに記録媒体３２に記録可能な形式にデータを変換・変調して、ＰＳを記録媒体３２に順次格納する。記録媒体３２としては、ＤＶＤ（Digital Versatile Disk）などの光ディスク、ＨＤＤ（Hard Disk Drive）、磁気テープ、半導体メモリなどが適用可能である。
【００２８】
システムコントローラ４０は、ＣＰＵやメモリなどからなり、上記の各ブロックを統括的に制御する。本実施の形態では、システムコントローラ４０はリアルタイムＯＳ上で各ブロックの制御処理を実行し、特に、ビデオエンコーダ１１、オーディオエンコーダ１２、ＭＵＸ２０のそれぞれの制御機能をリアルタイムＯＳの個別のタスクとして実装している。
【００２９】
このような構成により、ビデオエンコーダ１１、オーディオエンコーダ１２、ＭＵＸ２０のそれぞれはお互いの同期をとることなく動作する。このため例えば、ビデオエンコーダ１１やオーディオエンコーダ１２が、ＭＵＸ２０との処理速度の差や障害の発生、録画の一時停止への移行などにより、ビデオＥＳおよびオーディオＥＳを後段のバッファに出力しなくなったときにも、ＭＵＸ２０がこのことを検出することなく、パケットを生成し続けるという事態が発生しうる。
【００３０】
このような事態を防止するために、ＭＵＸ２０は、データサイズ判定部２１およびパック生成部２２を備えている。データサイズ判定部２１は、ビデオＩｎｆｏバッファ１５およびオーディオＩｎｆｏバッファ１６にアクセスして、データサイズなどのＡＵ＿Ｉｎｆｏを取得し、取得した情報を基に、出力するパックを満たすだけのＡＵがＥＳバッファ内に用意されているか否かを判定する。
【００３１】
パック生成部２２は、データサイズ判定部２１によって十分なＡＵがＥＳバッファ内に用意されていると判定された場合に、各ＥＳバッファから必要なＡＵを読み出し、またデータサイズ判定部２１からヘッダに格納すべき情報を取得してパックを生成し、記録処理部３１に出力する。逆に、データサイズ判定部２１により十分なＡＵがＥＳバッファに用意されていないと判定された場合には、パック生成部２２はパックの生成を停止する「ＥＳ待ち状態」となる。
【００３２】
このように、ＭＵＸ２０は、実際にパックを生成する前に、各Ｉｎｆｏバッファに記録されたＡＵ＿Ｉｎｆｏを基に、次のパックを満たすだけのＡＵのデータがＥＳバッファに用意されているか否かを判定する。これにより、ビデオエンコーダ１１およびオーディオエンコーダ１２とデータのやり取りをすることなく、ＥＳの生成停止状態を検出できるので、常に正常な動作をし続けるようになる。
【００３３】
以下、ＭＵＸ２０の処理について詳しく説明する。
図２は、ＭＵＸ２０による多重化処理全体の流れを示すフローチャートである。
〔ステップＳ１０１〕ＭＵＸ２０は、Ｐ−ＳＴＤバッファモデルのシミュレートを行う。その結果、ビデオのパック（Ｖパック）を生成することが可能と判定した場合には、ステップＳ１０３以後の処理を実行する。また、不可能と判定した場合にはステップＳ１０２に進む。
【００３４】
〔ステップＳ１０２〕多重化処理を終了するか否かを判定する。例えば、ユーザの操作入力などによりビデオ録画が停止された場合などに処理の終了と判定し、また終了要求がない場合にはステップＳ１０１に戻る。
【００３５】
〔ステップＳ１０３〕データサイズ判定部２１は、前回の多重化処理（パック生成処理）で、ＡＵ内のデータを最後までパックのペイロードの領域に格納したか否かを判定する。格納したと判定した場合にはステップＳ１０５に進む。また、ＡＵのデータのうち未格納のデータが残っていると判定した場合はステップＳ１０４に進む。
【００３６】
〔ステップＳ１０４〕ペイロードに格納されなかったＡＵの残りのデータサイズが、ペイロードの容量以上であるか否かを判定する。ペイロードの容量以上である場合には、その残りのＡＵのデータにより新たなパックのペイロードを満たしたパックを生成することができるので、ステップＳ１０９に進んで、パック生成部２２に新たなパックの生成処理を開始させる。また、残りのデータサイズがペイロードより小さい場合には、ステップＳ１０５に進む。
【００３７】
〔ステップＳ１０５〕データサイズ判定部２１は、Ｉｎｆｏバッファに次のＡＵについてのＡＵ＿Ｉｎｆｏが存在するか否かを判定する。これはすなわち、次に多重化すべきＡＵがＥＳバッファに存在するか否かを判定することを意味する。ＡＵ＿Ｉｎｆｏが存在する場合はステップＳ１０６に進む。また、存在しない場合はＥＳ待ち状態となって、ステップＳ１０８に進む。
【００３８】
〔ステップＳ１０６〕データサイズ判定部２１は、Ｉｎｆｏバッファを検索して、次のＡＵについてのＤＴＳ、ＰＴＳ、データサイズなどの情報を取得する。
〔ステップＳ１０７〕データサイズ判定部２１は、ステップＳ１０６で取得したデータサイズに基づき、次のＡＵを格納した場合にペイロードが満たされるか否かを判定する。満たされる場合はパックを生成することができるので、ステップＳ１０９に進んで、パック生成部２２に新たなパックの生成を開始させる。また、満たされない場合はステップＳ１０５に戻り、ペイロードの残りの領域に格納すべき次のＡＵのＡＵ＿ＩｎｆｏがＩｎｆｏバッファに存在するか否かを再び判定する。
【００３９】
〔ステップＳ１０８〕ＥＳ待ち状態になると、データサイズ判定部２１は、多重化処理を終了するか否かを判定する。例えば、ユーザの操作入力などによりビデオ録画が停止された場合などに処理の終了と判定する。また、終了要求がない場合にはステップＳ１０５に戻って、次のＡＵのＡＵ＿ＩｎｆｏがＩｎｆｏバッファに格納されたか否かを判定し、これにより、残りのペイロードに格納すべき新たなＡＵがエンコーダによって生成されるまで判定動作が停止され、ＥＳ待ち状態が継続される。
【００４０】
〔ステップＳ１０９〕パック生成部２２は、上記ステップでペイロードに格納すると判定されたＡＵをＥＳバッファから読み出し、パックを生成して出力する。このとき、データサイズ判定部２１がステップＳ１０６で取得した情報のうち必要なものをヘッダに格納する。なお、このステップＳ１０９の処理については、次の図３において詳しく説明する。
【００４１】
〔ステップＳ１１０〕ＭＵＸ２０は、ステップＳ１０９で格納した時刻管理情報に対応するように現在時刻（ＳＣＲ）を進める。そして、ステップＳ１０１に戻る。
図３は、パック生成部２２によるパック生成処理（ステップＳ１０９に対応）の流れを示すフローチャートである。
【００４２】
〔ステップＳ２０１〕パックヘッダやパケットヘッダ、システムヘッダなどが必要か否かを判定し、必要である場合はステップＳ２０２に進み、そうでない場合はステップＳ２０３に進む。
【００４３】
〔ステップＳ２０２〕ヘッダを作成する。例えば、図２のステップＳ１０６でデータサイズ判定部２１が取得したデータのうち必要なデータをヘッダに格納する。また、必要に応じて新たなデータを作成して格納する。
【００４４】
〔ステップＳ２０３〕ＥＳバッファにアクセスして新たなＡＵを読み出し、取得する。
〔ステップＳ２０４〕取得したＡＵのデータをペイロードに格納する。
〔ステップＳ２０５〕ペイロードが完成したか（データが満たされたか）を判定する。完成してない場合はステップＳ２０３に戻り、次のＡＵをＥＳバッファから取得する。また、ペイロードが完成した場合にはステップＳ２０６に進む。
【００４５】
〔ステップＳ２０６〕生成されたパックを出力する。このパックは、常にペイロードにＡＵのデータが満たされたものになる。
次に、ＥＳ待ち状態となる場合の具体的なパック生成例を挙げ、上記のフローチャートの処理に対応付けてその動作を説明する。以下の例では、ＩＳＯ／ＩＥＣ（International Organization for Standardization／International Electrotechnical Commission）１３８１８−１で規定された“Ｔｈｅ  Ｓｙｓｔｅｍ  Ｐａｒｔ  ｏｆ  ｔｈｅ  ＭＰＥＧ−２  Ｓｔａｎｄａｒｄ”に準拠した２Ｋｂｙｔｅ（２０４８ｂｙｔｅ）の固定長のパックを生成するものとする。このようなパックでは、パックヘッダおよびパケットヘッダを除いた残りの２０２０ｂｙｔｅが、ＡＵのデータを格納するペイロードとされる。なお、ここでは説明を簡単にするために、ビデオデータが格納されるＶパックの生成についてのみ説明する。
【００４６】
図４は、エンコードされたＡＵのサイズが十分に大きい場合のパック生成の様子を示す図である。
図４では、ビデオＥＳバッファ１３に、ｎ番目のＡＵであるＡＵ（ｎ）が格納されている。このＡＵ（ｎ）はパック内のペイロードより大きなデータサイズを有している。ＭＵＸ２０は、このＡＵ（ｎ）を多重化するにあたって、まず、ＡＵ（ｎ）のうちの先頭の２０２０ｂｙｔｅのデータを読み出し、最初のＶパックに格納して出力する。この場合、ステップＳ１０１でのＰ−ＳＴＤのシミュレートによりパックの生成可能と判定すると、以後、ステップＳ１０３、Ｓ１０５、Ｓ１０６、Ｓ１０７と進み、ステップＳ１０７でペイロードが満たされると判定して、ステップＳ１０９で最初のＶパックを生成する。
【００４７】
この後さらに、次のパックを生成するための処理を開始するが、このときは、ステップＳ１０１の判定後に、ステップＳ１０３でＡＵ（ｎ）の残りがビデオＥＳバッファ１３に存在すると判定してステップＳ１０４に進み、残りのＡＵ（ｎ）のデータサイズが２０２０ｂｙｔｅ以上である間は、そのままステップＳ１０９に進む。すなわち、ビデオＥＳバッファ１３内のＡＵ（ｎ）の残りから２０２０ｂｙｔｅずつデータを読み出し、Ｖパックを順次満たして出力していく。
【００４８】
ここで、ＡＵ（ｎ）の最後の７６０ｂｙｔｅのデータがビデオＥＳバッファ１３に残ったものとすると、ＭＵＸ２０は、その残りの７６０ｂｙｔｅのデータを次のＶパックに格納しようとする。このとき、ステップＳ１０１、Ｓ１０３、Ｓ１０４と進み、ステップＳ１０４において残りのＡＵ（ｎ）が２０２０ｂｙｔｅ未満と判定されて、ステップＳ１０５に進む。そして、ステップＳ１０５でのビデオＩｎｆｏバッファ１５の検索により、次のＡＵであるＡＵ（ｎ＋１）（図示せず）がビデオＥＳバッファ１３に格納されていないと判定した場合には、ペイロードの残りの領域を満たせないので、ＥＳ待ち状態となって処理を一旦停止する。
【００４９】
この後、ステップＳ１０５でのビデオＩｎｆｏバッファ１５の検索により新たなＡＵ（ｎ＋１）の生成が確認されると、ステップＳ１０６に進んでそのＡＵ（ｎ＋１）についてのＡＵ＿Ｉｎｆｏを取得し、ペイロードを満たすだけのＡＵのデータ量がビデオＥＳバッファ１３に格納されたことを確認すると（ステップＳ１０７）、それらのデータを用いてパックの生成を開始する（ステップＳ１０９）。
【００５０】
図５は、エンコードされたＡＵのサイズが小さい場合のパック生成の様子を示す図である。
図５では、ｎ番目から（ｎ＋３）番目までのＡＵ（ｎ）〜ＡＵ（ｎ＋３）がビデオＥＳバッファ１３に格納されているが、これらの総データサイズはペイロードの容量よりも小さいものとする。ＭＵＸ２０は、これらを多重化するにあたって、まず先頭のＡＵ（ｎ）によりペイロードを満たすことができるか否かを判定する。すなわち、ステップＳ１０１、Ｓ１０３、Ｓ１０５、Ｓ１０６と進み、ステップＳ１０６においてビデオＩｎｆｏバッファ１５から取得したデータサイズに基づき、ステップＳ１０７でペイロードを満たすことができないと判定する。
【００５１】
これにより、再びステップＳ１０５に戻ってビデオＩｎｆｏバッファ１５を検索し、次のＡＵ（ｎ＋１）の存在を確認して、ステップＳ１０６で対応するＡＵ＿Ｉｎｆｏを取得する。これにより、ステップＳ１０７では再びペイロードを満たすことができないと判定され、ステップＳ１０５に戻る。以後、ＡＵ（ｎ＋２）およびＡＵ（ｎ＋３）について同様の処理を繰り返し、これらのデータでもペイロードを満たすことができないので、ステップＳ１０５に戻り、次のＡＵ（ｎ＋４）（図示せず）がビデオＥＳバッファ１３に存在するか否かを判定する。ここで、次のＡＵ（ｎ＋４）が存在しない場合に、ＥＳ待ち状態となって処理を一旦停止する。
【００５２】
この後、ステップＳ１０５でのビデオＩｎｆｏバッファ１５の検索により新たなＡＵ（ｎ＋４）の生成が確認されると、ステップＳ１０６に進んでそのＡＵ（ｎ＋４）についてのＡＵ＿Ｉｎｆｏを取得する。そして、ＡＵ（ｎ）〜ＡＵ（ｎ＋４）によりペイロードを満たすと判定した場合に（ステップＳ１０７）、それらのデータを用いてパックの生成を開始する（ステップＳ１０９）。
【００５３】
以上説明したように、本実施の形態では、次のパックのペイロードがＡＵのデータで満たされることが保証されるまで、すなわち、パックのペイロードの領域を満たすだけのＡＵがエンコーダにより生成され、ＥＳバッファに格納されたことを確認するまでは、それらのＡＵの多重化を行わず、パックを出力しない。このため、ＭＵＸ２０との処理速度の違いによりビデオエンコーダ１１やオーディオエンコーダ１２によるＥＳのエンコードタイミングが遅れた場合や、障害発生や録画停止命令などによりＥＳのエンコードが停止した場合にも、ＭＵＸ２０が動作し続けて余分なパックを出力される事態が回避される。
【００５４】
これとともに、多重化すべきデータを事前に認識しているので、ＭＵＸ２０がＥＳバッファから同じデータを何度も読み出すことがなくなり、ＭＵＸ２０からＥＳバッファへのアクセス回数が最小限に留められ、データ転送に要する時間が短縮されて、処理が効率化される。
【００５５】
また、ＭＵＸ２０は、多重化するＡＵのデータサイズを、ＩｎｆｏバッファのＡＵ＿Ｉｎｆｏから取得することにより、そのＡＵでペイロードが満たされるか否かを判定する。このため、ＭＵＸ２０はビデオエンコーダ１１やオーディオエンコーダ１２との間で通信することなく、余分なパックを出力する事態を回避して正常に動作し続けることが可能となる。
【００５６】
従って、各エンコーダとＭＵＸ２０とを完全に独立して正常動作させることができ、各エンコーダとＭＵＸ２０のそれぞれの制御をリアルタイムＯＳ上の個別タスクとして実装することが可能となる。各制御を個別タスクとすることにより、エンコーダやＭＵＸ２０の機能を個別に開発することが可能となり、仕様変更などに柔軟に対応し、また制御対象の機能ごとに不具合を検証して検証効率を高めることもできる。
【００５７】
また、Ｉｎｆｏバッファの情報を基に上記判定処理を行うことにより、例えばＥＳバッファ上のＡＵを読み出してデータサイズを調べることで上記判定処理を行う場合と比較して、処理を単純化し、データの転送時間や処理時間を短縮することができる。
【００５８】
なお、以上の実施の形態では、ストリーム記録装置に本発明を適用した場合について説明したが、これに限らず、例えば、ストリームを生成してネットワークなどを通じて伝送、配信する装置などにも本発明を適用することができる。
【図面の簡単な説明】
【００５９】
【図１】実施の形態に係るストリーム記録装置の構成を示すブロック図である。
【図２】ＭＵＸによる多重化処理全体の流れを示すフローチャートである。
【図３】パック生成部によるパック生成処理の流れを示すフローチャートである。
【図４】エンコードされたＡＵのサイズが十分に大きい場合のパック生成の様子を示す図である。
【図５】エンコードされたＡＵのサイズが小さい場合のパック生成の様子を示す図である。
【図６】ＭＰＥＧ方式を用いた従来のストリーム生成装置の要部構成を示す図である。
【符号の説明】
【００６０】
１１……ビデオエンコーダ、２２……オーディオエンコーダ、１３……ビデオＥＳバッファ、１４……オーディオＥＳバッファ、１５……ビデオＩｎｆｏバッファ、１６……オーディオＩｎｆｏバッファ、２０……ＭＵＸ、２１……データサイズ判定部、２２……パック生成部、３１……記録処理部、３２……記録媒体、４０……システムコントローラ
【図１】
2006135603.tif 000003
【図２】
2006135603.tif 000004
【図３】
2006135603.tif 000005
【図４】
2006135603.tif 000006
【図５】
2006135603.tif 000007
【図６】
2006135603.tif 000008