JP6699564B2 - 送信装置、送信方法、受信装置および受信方法 - Google Patents

Description

本技術は、送信装置、送信方法、受信装置および受信方法に関し、特に、オーディオストリームを取り扱う送信装置等に関する。

従来、立体（３Ｄ）音響技術として、符号化サンプルデータをメタデータに基づいて任意の位置に存在するスピーカにマッピングさせてレンダリングする技術が提案されている（例えば、特許文献１参照）。

特表２０１４−５２０４９１号公報

例えば、５．１チャネル、７．１チャネルなどのチャネルデータと共に、符号化サンプルデータおよびメタデータからなるオブジェクトデータを送信し、受信側において臨場感を高めた音響再生を可能とすることが考えられる。従来、チャネルデータおよびオブジェクトデータを３Ｄオーディオ（MPEG-H 3D Audio）の符号化方式で符号化して得られた符号化データを含むオーディオストリームを受信側に送信することが提案されている。

このオーディオストリームを構成するオーディオフレームは、符号化データをペイロード情報として持つ“Ｆｒａｍｅ”のパケット（第１のパケット）と、この“Ｆｒａｍｅ”のパケットのペイロード情報の構成を示す構成情報をペイロード情報として持つ“Ｃｏｎｆｉｇ”のパケット（第２のパケット）を含む構成とされている。

従来、“Ｆｒａｍｅ”のパケットに、対応する“Ｃｏｎｆｉｇ”のパケットとの関連づけ情報が挿入されていない。そのため、オーディオフレームに含める複数の“Ｆｒａｍｅ”のパケットの順番には、デコード処理を適切に行うために、ペイロードが持つ符号化データの種類に応じた制約がある。従って、例えば、受信側で複数のオーディオストリームを統合して１つのオーディオストリームに統合する際、この制約を守る必要があり、処理負荷は大きくなる。

本技術の目的は、受信側で複数のオーディオストリームを統合する際の処理負荷の軽減を図ることにある。

本技術の概念は、
所定数のオーディオストリームを生成するエンコード部と、
上記所定数のオーディオストリームを含む所定フォーマットのコンテナを送信する送信部を備え、
上記オーディオストリームは、符号化データをペイロード情報として持つ第１のパケットと、該第１のパケットのペイロード情報の構成を示す構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなり、
関連する上記第１のパケットおよび上記第２のパケットのペイロードには共通のインデックス情報が挿入される
送信装置にある。

本技術において、エンコード部により、所定数のオーディオストリームが生成される。オーディオストリームは、符号化データをペイロード情報として持つ第１のパケットと、この第１のパケットのペイロード情報の構成を示す構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなっている。例えば、第１のパケットがペイロード情報として持つ符号化データは、チャネル符号化データまたはオフジェクト符号化データである、ようにされてもよい。関連する第１のパケットおよび第２のパケットのペイロードには共通のインデックス情報が挿入される。

送信部により、この所定数のオーディオストリームを含む所定フォーマットのコンテナが送信される。例えば、コンテナは、デジタル放送規格で採用されているトランスポートストリーム（ＭＰＥＧ−２ ＴＳ）であってもよい。また、例えば、コンテナは、インターネットの配信などで用いられるＭＰ４、あるいはそれ以外のフォーマットのコンテナであってもよい。

このように本技術においては、関連する第１のパケットおよび第２のパケットのペイロードには共通のインデックス情報が挿入されるものである。そのため、オーディオフレームに含める複数の第１のパケットの順番が、ペイロードが持つ符号化データの種類に応じた順番の規定によって制限されなくなる。従って、例えば、受信側で複数のオーディオストリームを統合して１つのオーディオストリームを生成する際、順番の規定を守る必要がなく、処理負荷の軽減を図ることが可能となる。

また、本技術の他の概念は、
所定数のオーディオストリームを含む所定フォーマットのコンテナを受信する受信部を備え、
上記オーディオストリームは、符号化データをペイロード情報として持つ第１のパケットと、該第１のパケットのペイロード情報の構成を示す構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなり、
関連する上記第１のパケットおよび上記第２のパケットのペイロードには共通のインデックス情報が挿入されており、
上記所定数のオーディオストリームから一部または全部の上記第１のパケットおよび上記第２のパケットを取り出し、上記第１のパケットおよび上記第２のパケットのペイロード部に挿入されている上記インデックス情報を利用して１つのオーディオストリームに統合するストリーム統合部と、
上記１つのオーディオストリームを処理する処理部をさらに備える
受信装置にある。

本技術において、受信部により、所定数のオーディオストリームを含む所定フォーマットのコンテナが受信される。オーディオストリームは、符号化データをペイロード情報として持つ第１のパケットと、この第１のパケットのペイロード情報の構成を示す構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなっている。そして、関連する第１のパケットおよび第２のパケットのペイロードには共通のインデックス情報が挿入されている。

ストリーム統合部により、所定数のオーディオストリームから一部または全部の第１のパケットおよび第２のパケットが取り出され、第１のパケットおよび第２のパケットのペイロード部に挿入されているインデックス情報が利用されて１つのオーディオストリームに統合される。この場合、関連する第１のパケットおよび第２のパケットのペイロードには共通のインデックス情報の挿入があることから、オーディオフレームに含める複数の第１のパケットの順番が、ペイロードが持つ符号化データの種類に応じた順番の規定に制限されず、各オーディオストリームの構成を分解することなく統合される。

処理部により、１つのオーディオストリームが処理される。例えば、処理部は、１つのオーディオストリームに対してデコード処理を施す、ようにされてもよい。また、処理部は、１つのオーディオストリームを外部機器に送信する、ようにされてもよい。

このように本技術においては、所定数のオーディオストリームから取り出された一部または全部の第１のパケットおよび第２のパケットが、第１のパケットおよび第２のパケットのペイロード部に挿入されているインデックス情報が利用されて１つのオーディオストリームに統合される。そのため、各オーディオストリームの構成を分解することなく統合でき、処理負荷の軽減を図ることが可能となる。

本技術によれば、受信側で複数のオーディオストリームを統合する際の処理負荷の軽減を図ることができる。なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。

実施の形態としての送受信システムの構成例を示すブロック図である。 ３Ｄオーディオの伝送データにおけるオーディオフレーム（１０２４サンプル）の構造を示す図である。 従来および実施の形態におけるオーディオストリームの構成例を説明するための図である。 “Ｃｏｎｆｉｇ”および“Ｆｒａｍｅ”の構成例を概略的に示す図である。 ３Ｄオーディオの伝送データの構成例を示す図である。 ３ストリームで送信する場合におけるオーディオフレームの構成例を概略的に示す図である。 サービス送信機が備えるストリーム生成部の構成例を示すブロック図である。 各オーディオストリームを構成するオーディオフレームを説明するための図である。 サービス受信機の構成例を示すブロック図である。 エレメント毎に“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”がインデックス情報で紐づけされていない場合の統合処理の一例を説明するための図である。 エレメント毎に“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”がインデックス情報で紐づけされている場合の統合処理の一例を説明するための図である。

以下、発明を実施するための形態（以下、「実施の形態」とする）について説明する。なお、説明を以下の順序で行う。
１．実施の形態
２．変形例

＜１．実施の形態＞
［送受信システムの構成例］
図１は、実施の形態としての送受信システム１０の構成例を示している。この送受信システム１０は、サービス送信機１００とサービス受信機２００により構成されている。サービス送信機１００は、トランスポートストリームＴＳを、放送波あるいはネットのパケットに載せて送信する。このトランスポートストリームＴＳは、ビデオストリームの他に、所定数、つまり１つまたは複数のオーディオストリームを有している。

ここで、オーディオストリームは、符号化データをペイロード情報として持つ第１のパケット（“Ｆｒａｍｅ”のパケット）と、この第１のパケットのペイロード情報の構成を示す構成情報をペイロード情報として持つ第２のパケット（“Ｃｏｎｆｉｇ”のパケット）を含むオーディオフレームからなり、関連する第１のパケットおよび第２のパケットのペイロードには共通のインデックス情報が挿入されている。

図２は、この実施の形態で取り扱う３Ｄオーディオの伝送データにおけるオーディオフレーム（１０２４サンプル）の構造例を示している。このオーディオフレームは、複数のＭＰＥＧオーディオストリームパケット（mpeg Audio Stream Packet）からなっている。各ＭＰＥＧオーディオストリームパケットは、ヘッダ（Header）とペイロード（Payload）により構成されている。

ヘッダは、パケットタイプ（Packet Type）、パケットラベル（Packet Label）、パケットレングス（Packet Length）などの情報を持つ。ペイロードには、ヘッダのパケットタイプで定義されたペイロード情報が配置される。このペイロード情報には、同期スタートコードに相当する“ＳＹＮＣ”と、３Ｄオーディオの伝送データの実際のデータである“Ｆｒａｍｅ”と、この“Ｆｒａｍｅ”の構成を示す“Ｃｏｎｆｉｇ”が存在する。

“Ｆｒａｍｅ”には、３Ｄオーディオの伝送データを構成するチャネル符号化データとオブジェクト符号化データが含まれる。なお、チャネル符号化データのみが含まれる場合、あるいはオブジェクト符号化データのみが含まれる場合もある。

ここで、チャネル符号化データは、ＳＣＥ（Single Channel Element）、ＣＰＥ（Channel Pair Element）、ＬＦＥ（Low Frequency Element）などの符号化サンプルデータで構成される。また、オブジェクト符号化データは、ＳＣＥ（Single Channel Element）の符号化サンプルデータと、それを任意の位置に存在するスピーカにマッピングさせてレンダリングするためのメタデータにより構成される。このメタデータは、エクステンションエレメント（Ext_element）として含まれる。

この実施の形態において、“Ｆｒａｍｅ”のそれぞれに、関連する“Ｃｏｎｆｉｇ”を識別するための識別情報が挿入される。すなわち、関連する“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”には、共通のインデックス情報が挿入される。

図３（ａ）は、従来のオーディオストリームの構成例を示している。“Ｃｏｎｆｉｇ”として、ＳＣＥの“Ｆｒａｍｅ”のエレメントに対応する構成情報“ＳＣＥ＿ｃｏｎｆｉｇ”が存在する。また、“Ｃｏｎｆｉｇ”として、ＣＰＥの“Ｆｒａｍｅ”に対応する構成情報“ＣＰＥ＿ｃoｎｆｉｇ”が存在する。さらに、“Ｃｏｎｆｉｇ”として、ＥＸＥの“Ｆｒａｍｅ”に対応する構成情報“ＥＸＥ＿ｃoｎｆｉｇ”が存在する。

この場合、各エレメントに対応した“Ｃｏｎｆｉｇ”と、各エレメントの“Ｆｒａｍｅ”を関連づける情報が、当該“Ｃｏｎｆｉｇ”や“Ｆｒａｍｅ”には挿入されていない。そのため、デコード処理が適切に行われるようにするために、エレメントの順番が、ＳＣＥ→ＣＰＥ→ＥＸＥのように規定される。つまり、図３（ａ´）に示すようなＣＰＥ→ＳＣＥ→ＥＸＥのような順番とすることはできない。

図３（ｂ）は、この実施の形態におけるオーディオストリームの構成例を示している。“Ｃｏｎｆｉｇ”として、ＳＣＥの“Ｆｒａｍｅ”のエレメントに対応する構成情報“ＳＣＥ＿ｃｏｎｆｉｇ”が存在し、この構成情報“ＳＣＥ＿ｃｏｎｆｉｇ”には、エレメントインデックスとして“Ｉｄ０”が付加される。

また、“Ｃｏｎｆｉｇ”として、ＣＰＥの“Ｆｒａｍｅ”に対応する構成情報“ＣＰＥ＿ｃｏｎｆｉｇ”が存在し、この構成情報“ＣＰＥ＿ｃｏｎｆｉｇ”には、エレメントインデックスとして“Ｉｄ１”が付加される。また、“Ｃｏｎｆｉｇ”として、ＥＸＥの“Ｆｒａｍｅ”に対応する構成情報“ＥＸＥ＿ｃｏｎｆｉｇ”が存在し、この構成情報“ＥＸＥ＿ｃoｎｆｉｇ”には、エレメントインデックスとして“Ｉｄ２”が付加される。

また、各“Ｆｒａｍｅ”には、関連する“Ｃｏｎｆｉｇ”と共通のエレメントインデックスが付加される。すなわち、ＳＣＥの“Ｆｒａｍｅ”には、エレメントインデックスとして“Ｉｄ０”が付加される。また、ＣＰＥの“Ｆｒａｍｅ”には、エレメントインデックスとして“Ｉｄ１”が付加される。また、また、ＥＸＥの“Ｆｒａｍｅ”には、エレメントインデックスとして“Ｉｄ２”が付加される。

この場合、エレメント毎に“Ｃｏｎｆｉｇ”と“Ｆｒａｍｅ”がインデックス情報で紐づけされるので、エレメントの順番が、順番の規定によって制限されることがなくなる。したがって、ＳＣＥ→ＣＰＥ→ＥＸＥのような順番とするだけでなく、図３（ｂ´）に示すようなＣＰＥ→ＳＣＥ→ＥＸＥのような順番とすることも可能となる。

図４（ａ）は、“Ｃｏｎｆｉｇ”の構成例を概略的に示している。“mpeg3daConfig()”が最上位の概念で、その下にデコードするための“mpeg3daDecoderConfig()”がある。さらに、その下に、“Ｆｒａｍｅ”に格納される各エレメントに対応した“Config()”が存在し、それぞれにエレメントインデックス（Element_index）が挿入される。

例えば、“mpegh3daSingleChannelElementConfig()”はＳＣＥのエレメントに対応し、“mpegh3daChannelPairElementConfig()”はＣＰＥのエレメントに対応し、“mpegh3daLfeElementConfig()”はＬＦＥのエレメントに対応し、“mpegh3daExtElementConfig()”はＥＸＥのエレメントに対応している。

図４（ｂ）は、“Ｆｒａｍｅ”の構成例を概略的に示している。“mpeg3daFrame()”が最上位の概念で、その下に、各エレメントの実体である“Element()”が存在し、それぞれにエレメントインデックス（Element_index）が挿入される。例えば、“mpegh3daSingleChannelElement()”はＳＣＥのエレメントであり、“mpegh3daChannlePairElement()”はＣＰＥのエレメントであり、“mpegh3daLfeElement()”はＬＦＥのエレメントであり、“mpegh3daExtElement()”はＥＸＥのエレメントである。

図５は、３Ｄオーディオの伝送データの構成例を示している。この例では、チャネル符号化データのみからなる第１のデータと、オブジェクト符号化データのみからなる第２のデータと、チャネル符号化データおよびオフジェクト符号化データからなる第３のデータとからなっている。

第１のデータのチャネル符号化データは、５．１チャネルのチャネル符号化データであり、ＳＣＥ１，ＣＰＥ１，ＣＰＥ２，ＬＦＥ１の各符号化サンプルデータからなっている。

第２のデータのオブジェクト符号化データは、イマーシブオーディオオブジェクト（Immersive audio object）の符号化データである。このイマーシブオーディオオブジェクト符号化データは、イマーシブサウンドのためのオブジェクト符号化データであり、符号化サンプルデータＳＣＥ２と、それを任意の位置に存在するスピーカにマッピングさせてレンダリングするためのメタデータＥＸＥｌとからなっている。

第３のデータに含まれるチャネル符号化データは、２チャネル（ステレオ）のチャネル符号化データであり、ＣＰＥ３の符号化サンプルデータからなっている。また、この第３のデータに含まれるオブジェクト符号化データは、スピーチランゲージオブジェクト符号化データであり、符号化サンプルデータＳＣＥ３と、それを任意の位置に存在するスピーカにマッピングさせてレンダリングするためのメタデータＥＸＥ２とからなっている。

符号化データは、種類別にグループ（Group）という概念で区別される。図示の例では、５．１チャネルの符号化チャネルデータはグループ１とされ、イマーシブオーディオオブジェクト符号化データはグループ２とされ、２チャネル（ステレオ）のチャネル符号化データはグループ３とされ、スピーチランゲージオブジェクト符号化データはグループ４とされている。

また、受信側においてグループ間で選択できるものはスイッチグループ（SW Group）に登録されて符号化される。また、グループを束ねてプリセットグループ（preset Group）とされ、ユースケースに応じた再生が可能とされる。図示の例では、グループ１、グループ２およびグループ３が束ねられてプリセットグループ１とされ、グループ１、グループ２およびグループ４が束ねられてプリセットグループ２とされている。

図１に戻って、サービス送信機１００は、上述したように複数のグループの符号化データを含む３Ｄオーディオの伝送データを、１ストリーム、あるいは複数ストリーム（Multiple stream）で送信する。この実施の形態では、３ストリームで送信する。

図６は、図５の３Ｄオーディオの伝送データの構成例において、３ストリームで送信する場合におけるオーディオフレームの構成例を概略的に示している。この場合、ＰＩＤ１で識別される第１のストリームに、“ＳＹＮＣ”および“Ｃｏｎｆｉｇ”と共に、チャネル符号化データのみからなる第１のデータが含まれる。

また、ＰＩＤ２で識別される第２のストリームに、“ＳＹＮＣ”および“Ｃｏｎｆｉｇ”と共に、オブジェクト符号化データのみからなる第２のデータが含まれる。また、ＰＩＤ３で識別される第３のストリームに、“ＳＹＮＣ”および“Ｃｏｎｆｉｇ”と共に、チャネル符号化データおよびオフジェクと符号化データからなる第３のデータが含まれる。

図１に戻って、サービス受信機２００は、サービス送信機１００から放送波あるいはネットのパケットに載せて送られてくるトランスポートストリームＴＳを受信する。このトランスポートストリームＴＳは、ビデオストリームの他に、所定数、この実施の形態では、３つのオーディオストリームを有している。

上述したように、オーディオストリームは、符号化データをペイロード情報として持つ第１のパケット（“Ｆｒａｍｅ”のパケット）と、この第１のパケットのペイロード情報の構成を示す構成情報をペイロード情報として持つ第２のパケット（“Ｃｏｎｆｉｇ”のパケット）を含むオーディオフレームからなり、関連する第１のパケットおよび第２のパケットのペイロードには共通のインデックス情報が挿入されている。

サービス受信機２００は、３つのオーディオストリームから一部または全部の第１のパケットおよび第２のパケットを取り出し、第１のパケットおよび第２のパケットのペイロード部に挿入されているインデックス情報を利用して１つのオーディオストリームに統合する。そして、サービス受信機２００は、この１つのオーディオストリームを処理する。例えば、この１つのオーディオストリームに対してデコード処理を施し、３Ｄオーディオのオーディオ出力を得る。また、例えば、この１つのオーディオストリームを外部機器に送信する。

［サービス送信機のストリーム生成部］
図７は、サービス送信機１００が備えるストリーム生成部１１０の構成例を示している。このストリーム生成部１１０は、ビデオエンコーダ１１２と、３Ｄオーディオエンコーダ１１３と、マルチプレクサ１１４を有している。

ビデオエンコーダ１１２は、ビデオデータＳＶを入力し、このビデオデータＳＶに対して符号化を施し、ビデオストリーム（ビデオエレメンタリストリーム）を生成する。３Ｄオーディオエンコーダ１１３は、オーディオデータＳＡとして、必要とするチャネルデータおよびオブジェクトデータを入力する。

３Ｄオーディオエンコーダ１１３は、オーディオデータＳＡに対して符号化を施し、３Ｄオーディオの伝送データを得る。この３Ｄオーディオの伝送データには、図５に示すように、チャネル符号化データのみからなる第１のデータ（グループ１のデータ）と、オブジェクト符号化データのみからなる第２のデータ（グループ２のデータ）と、チャネル符号化データおよびオフジェクと符号化データからなる第３のデータ（グループ３，４のデータ）が含まれる。

そして、３Ｄオーディオエンコーダ１１３は、第１のデータを含む第１のオーディオストリーム（Stream 1）と、第２のデータを含む第２のオーディオストリーム（Stream 2）と、第３のデータを含む第３のオーディオストリーム（Stream 3）を生成する（図６参照）。

図８（ａ）は、第１のオーディオストリーム（Stream 1）を構成するオーディオフレーム（Audio Frame）の構成を示している。ＳＣＥ１，ＣＰＥ１，ＣＰＥ２，ＬＦＥ１の“Ｆｒａｍｅ”と、各“Ｆｒａｍｅ”に対応した“Ｃｏｎｆｉｇ”が存在する。ＳＣＥ１の“Ｆｒａｍｅ”と、それに対応した“Ｃｏｎｆｉｇ”には、共通のエレメントインデックスとして“Ｉｄ０”が挿入される。ＣＰＥ１の“Ｆｒａｍｅ”と、それに対応した“Ｃｏｎｆｉｇ”には、共通のエレメントインデックスとして“Ｉｄ１”が挿入付加される。

また、ＣＰＥ２の“Ｆｒａｍｅ”と、それに対応した“Ｃｏｎｆｉｇ”には、共通のエレメントインデックスとして“Ｉｄ２”が挿入される。また、ＬＦＥ１の“Ｆｒａｍｅ”と、それに対応した“Ｃｏｎｆｉｇ”には、共通のエレメントインデックスとして“Ｉｄ３”が挿入される。なお、“Ｃｏｎｆｉｇ”および“Ｆｒａｍｅ”のパケットラベル（ＰＬ）の値は、この第１のオーディオストリーム（Stream 1）では全て“ＰＬ１”とされる。

図８（ｂ）は、第２のオーディオストリーム（Stream 2）を構成するオーディオフレーム（Audio Frame）の構成を示している。ＳＣＥ２，ＥＸＥ１の“Ｆｒａｍｅ”と、それらの“Ｆｒａｍｅ”に対応した“Ｃｏｎｆｉｇ”が存在する。これらの“Ｆｒａｍｅ”、“Ｃｏｎｆｉｇ”には、共通のエレメントインデックスとして“Ｉｄ４”が挿入される。なお、“Ｃｏｎｆｉｇ”および“Ｆｒａｍｅ”のパケットラベル（ＰＬ）の値は、この第２のオーディオストリーム（Stream 2）では全て“ＰＬ２”とされる。

図８（ｃ）は、第３のオーディオストリーム（Stream 3）を構成するオーディオフレーム（Audio Frame）の構成を示している。ＣＰＥ３，ＳＣＥ３，ＥＸＥ２の“Ｆｒａｍｅ”と、ＣＰＥ３の“Ｆｒａｍｅ”に対応した“Ｃｏｎｆｉｇ”と、ＳＣＥ３，ＥＸＥ２の“Ｆｒａｍｅ”に対応した“Ｃｏｎｆｉｇ”が存在する。ＣＰＥ３の“Ｆｒａｍｅ”と、それに対応した“Ｃｏｎｆｉｇ”には、共通のエレメントインデックスとして“Ｉｄ５”が挿入される。

また、ＳＣＥ３，ＥＸＥ２“Ｆｒａｍｅ”と、それらの“Ｆｒａｍｅ”に対応した“Ｃｏｎｆｉｇ”には、共通のエレメントインデックスとして“Ｉｄ６”が挿入される。なお、“Ｃｏｎｆｉｇ”および“Ｆｒａｍｅ”のパケットラベル（ＰＬ）の値は、この第３のオーディオストリーム（Stream 3）では全て“ＰＬ３”とされる。

図７に戻って、マルチプレクサ１１４は、ビデオエンコーダ１１２から出力されるビデオストリームおよびオーディオエンコーダ１１３から出力される３つのオーディオストリームを、それぞれ、ＰＥＳパケット化し、さらにトランスポートパケット化して多重し、多重化ストリームとしてのトランスポートストリームＴＳを得る。

図７に示すストリーム生成部１１０の動作を簡単に説明する。ビデオデータは、ビデオエンコーダ１１２に供給される。このビデオエンコーダ１１２では、ビデオデータＳＶに対して符号化が施され、符号化ビデオデータを含むビデオストリームが生成される。

オーディオデータＳＡは、３Ｄオーディオエンコーダ１１３に供給される。このオーディオデータＳＡには、チャネルデータと、オブジェクトデータが含まれる。３Ｄオーディオエンコーダ１１３では、オーディオデータＳＡに対して符号化が施され、３Ｄオーディオの伝送データが得られる。

この３Ｄオーディオの伝送データには、チャネル符号化データのみからなる第１のデータ（グループ１のデータ）と、オブジェクト符号化データのみからなる第２のデータ（グループ２のデータ）と、チャネル符号化データおよびオフジェクと符号化データからなる第３のデータ（グループ３，４のデータ）が含まれる（図５参照）。

そして、この３Ｄオーディオエンコーダ１１３では、３つのオーディオストリームが生成される（図６、図８参照）。この場合、各オーディオストリームにおいて、同一のエレメントに係る“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”に共通のインデックス情報が挿入される。これにより、エレメント毎に“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”がインデックス情報で紐づけされる。

ビデオエンコーダ１１２で生成されたビデオストリームは、マルチプレクサ１１４に供給される。また、オーディオエンコーダ１１３で生成された３つのオーディオストリームは、マルチプレクサ１１４に供給される。マルチプレクサ１１４では、各エンコーダから供給されるストリームがＰＥＳパケット化され、さらにトランスポートパケット化されて多重され、多重化ストリームとしてのトランスポートストリームＴＳが得られる。

［サービス受信機の構成例］
図９は、サービス受信機２００の構成例を示している。このサービス受信機２００は、ＣＰＵ２２１と、フラッシュＲＯＭ２２２と、ＤＲＡＭ２２３と、内部バス２２４と、リモコン受信部２２５と、リモコン送信機２２６を有している。

また、このサービス受信機２００は、受信部２０１と、デマルチプレクサ２０２と、ビデオデコーダ２０３と、映像処理回路２０４と、パネル駆動回路２０５と、表示パネル２０６を有している。また、このサービス受信機２００は、多重化バッファ２１１-1〜２１１-Nと、コンバイナ２１２と、３Ｄオーディオデコーダ２１３と、音声出力処理回路２１４と、スピーカシステム２１５と、配信インタフェース２３２を有している。

ＣＰＵ２２１は、サービス受信機２００の各部の動作を制御する。フラッシュＲＯＭ２２２は、制御ソフトウェアの格納およびデータの保管を行う。ＤＲＡＭ２２３は、ＣＰＵ２２１のワークエリアを構成する。ＣＰＵ２２１は、フラッシュＲＯＭ２２２から読み出したソフトウェアやデータをＤＲＡＭ２２３上に展開してソフトウェアを起動させ、サービス受信機２００の各部を制御する。

リモコン受信部２２５は、リモコン送信機２２６から送信されたリモートコントロール信号（リモコンコード）を受信し、ＣＰＵ２２１に供給する。ＣＰＵ２２１は、このリモコンコードに基づいて、サービス受信機２００の各部を制御する。ＣＰＵ２２１、フラッシュＲＯＭ２２２およびＤＲＡＭ２２３は、内部バス２２４に接続されている。

受信部２０１は、サービス送信機１００から放送波あるいはネットのパケットに載せて送られてくるトランスポートストリームＴＳを受信する。このトランスポートストリームＴＳは、ビデオストリームの他に、３Ｄオーディオの伝送データを構成する３つのオーディオストリームを有している（図６、図８参照）。

デマルチプレクサ２０２は、トランスポートストリームＴＳからビデオストリームのパケットを抽出し、ビデオデコーダ２０３に送る。ビデオデコーダ２０３は、デマルチプレクサ２０２で抽出されたビデオのパケットからビデオストリームを再構成し、デコード処理を行って非圧縮のビデオデータを得る。

映像処理回路２０４は、ビデオデコーダ２０３で得られたビデオデータに対してスケーリング処理、画質調整処理などを行って、表示用のビデオデータを得る。パネル駆動回路２０５は、映像処理回路２０４で得られる表示用の画像データに基づいて、表示パネル２０６を駆動する。表示パネル２０６は、例えば、ＬＣＤ(Liquid Crystal Display)、有機ＥＬディスプレイ（organic electroluminescence display）などで構成されている。

また、デマルチプレクサ２０２は、ＣＰＵ２２１の制御のもと、トランスポートストリームＴＳが有する所定数のオーディオストリームのうち、スピーカ構成および視聴者（ユーザ）選択情報に適合するグループの符号化データを含む一つまたは複数のオーディオストリームのパケットをＰＩＤフィルタで選択的に取り出す。

多重化バッファ２１１-1〜２１１-Nは、それぞれ、デマルチプレクサ２０２で取り出される各オーディオストリームを取り込む。ここで、多重化バッファ２１１-1〜２１１-Nの個数Ｎとしては必要十分な個数とされるが、実際の動作では、デマルチプレクサ２０２で取り出されるオーディオストリームの数だけ用いられることになる。

コンバイナ２１２は、多重化バッファ２１１-1〜２１１-Nのうちデマルチプレクサ２０２で取り出される各オーディオストリームがそれぞれ取り込まれた多重化バッファから、オーディオフレーム毎に、一部または全部の“Ｃｏｎｆｉｇ”、“Ｆｒａｍｅ”のパケットを取り出し、１つのオーディオストリームに統合する。

この場合、各オーディオストリームにおいて、同一のエレメントに係る“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”に共通のインデックス情報が挿入されている、つまりエレメント毎に“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”がインデックス情報で紐づけされている。そのため、エレメントの順番が規定によって制限されることがなくなることから、コンバイナ２１２は、エレメントの順番が規定通りとするためにオーディオストリームの構成を分解するということが必要なく、簡便なストリーム合成が可能となる。

図１０は、エレメント毎に“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”がインデックス情報で紐づけされていない場合の統合処理の一例を示している。この例は、第１のオーディオストリーム（Stream 1）に含まれるグループ１のデータと、第２のオーディオストリーム（Stream 2）に含まれるグループ２のデータと、第３のオーディオストリーム（Stream 3）に含まれるグループ３のデータを統合する例である。

この場合、エレメント毎に“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”が紐づけされていないので、エレメントの順番が、順番の規定に制限される。図１０（a１）の合成ストリームは、各オーディオストリームの構成を分解することなく統合した例である。この場合、矢印で示したＬＦＥ１とＣＰＥ３の箇所で、エレメントの順番の規定に違反したものとなる。この場合には、各エレメントを解析し、図１０（a２）の合成ストリームに示すように、第１のオーディオストリームの構成を分解し、第３のオーディオストリームのエレメントを割り込ませて、ＣＰＥ３→ＬＦＥ１の順番とされる必要がある。

図１１は、エレメント毎に“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”がインデックス情報で紐づけされている場合の統合処理の一例を示している。この例も、第１のオーディオストリーム（Stream 1）に含まれるグループ１のデータと、第２のオーディオストリーム（Stream 2）に含まれるグループ２のデータと、第３のオーディオストリーム（Stream 3）に含まれるグループ３のデータを統合する例である。

この場合、エレメント毎に“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”がインデックス情報で紐づけされているので、エレメントの順番が、順番の規定に制限されない。図１１（a１）の合成ストリームは、各オーディオストリームの構成を分解することなく統合した一例である。図１１（a１）の合成ストリームは、各オーディオストリームの構成を分解することなく統合した他の一例である。

図９に戻って、３Ｄオーディオデコーダ２１３は、コンバイナ２１２で統合して得られた１つのオーディオストリームにデコード処理を施し、各スピーカを駆動するためのオーディオデータを得る。音声出力処理回路２１４は、各スピーカを駆動するためのオーディオデータに対して、Ｄ／Ａ変換や増幅等の必要な処理を行って、スピーカシステム２１５に供給する。スピーカシステム２１５は、複数チャネル、例えば２チャネル、５．１チャネル、７．１チャネル、２２．２チャネルなどの複数のスピーカを備える。

配信インタフェース２３２は、コンバイナ２１２で統合して得られた１つのオーディオストリームを、例えば、構内ネットワーク接続されたデバイス３００に配信（送信）する。この構内ネットワーク接続は、イーサネット接続、“ＷｉＦｉ”あるいは“Ｂｌｕｅｔｏｏｔｈ”などのワイヤレス接続を含む。なお、「ＷｉＦｉ」、「Ｂｌｕｅｔｏｏｔｈ」は、登録商標である。

また、デバイス３００は、サラウンドスピーカ、セカンドディスプレイ、ネットワーク端末に付属のオーディオ出力装置を含む。このデバイス３００は、３Ｄオーディオデコーダ２１３と同様のデコード処理を行って、所定数のスピーカを駆動するためのオーディオデータを得る。

図９に示すサービス受信機２００の動作を簡単に説明する。受信部２０１では、サービス送信機１００から放送波あるいはネットのパケットに載せて送られてくるトランスポートストリームＴＳが受信される。このトランスポートストリームＴＳには、ビデオストリームの他に、３Ｄオーディオの伝送データを構成する３つのオーディオストリームが含まれている（図６、図８参照）。このトランスポートストリームＴＳは、デマルチプレクサ２０２に供給される。

デマルチプレクサ２０２では、トランスポートストリームＴＳからビデオストリームのパケットが抽出され、ビデオデコーダ２０３に供給される。ビデオデコーダ２０３では、デマルチプレクサ２０２で抽出されたビデオのパケットからビデオストリームが再構成され、デコード処理が行われて、非圧縮のビデオデータが得られる。このビデオデータは、映像処理回路２０４に供給される。

映像処理回路２０４では、ビデオデコーダ２０３で得られたビデオデータに対してスケーリング処理、画質調整処理などが行われて、表示用のビデオデータが得られる。この表示用のビデオデータはパネル駆動回路２０５に供給される。パネル駆動回路２０５では、表示用のビデオデータに基づいて、表示パネル２０６を駆動することが行われる。これにより、表示パネル２０６には、表示用のビデオデータに対応した画像が表示される。

また、デマルチプレクサ２０２では、ＣＰＵ２２１の制御のもと、トランスポートストリームＴＳが有する所定数のオーディオストリームのうち、スピーカ構成および視聴者選択情報に適合するグループの符号化データを含む１つまたは複数のオーディオストリームのパケットがＰＩＤフィルタで選択的に取り出される。

デマルチプレクサ２０２で取り出されたオーディオストリームは、多重化バッファ２１１-1〜２１１-Nのうち対応する多重化バッファに取り込まれる。コンバイナ２１２では、多重化バッファ２１１-1〜２１１-Nのうちデマルチプレクサ２０２で取り出される各オーディオストリームがそれぞれ取り込まれた多重化バッファから、オーディオフレーム毎に、一部または全部の“Ｃｏｎｆｉｇ”、“Ｆｒａｍｅ”のパケットが取り出されて、１つのオーディオストリームに統合される。

この場合、各オーディオストリームにおいて、エレメント毎に“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”がインデックス情報で紐づけされているので、エレメントの順番が規定によって制限されない。そのため、コンバイナ２１２では、エレメントの順番を規定通りとするためにオーディオストリームの構成を分解するということが必要なく、簡便なストリーム合成が行われる（図１１（ｂ１），（ｂ２）参照）。

コンバイナ２１２で統合して得られた１つのオーディオストリームは、３Ｄオーディオデコーダ２１３に供給される。３Ｄオーディオデコーダ２１３では、このオーディオストリームにデコード処理が施されて、スピーカシステム２１５を構成する各スピーカを駆動するためのオーディオデータが得られる。

このオーディオデータは、音声出力処理回路２１４に供給される。この音声出力処理回路２１４では、各スピーカを駆動するためのオーディオデータに対して、Ｄ／Ａ変換や増幅等の必要な処理が行われる。そして、処理後のオーディオデータはスピーカシステム２１５に供給される。これにより、スピーカシステム２１５からは表示パネル２０６の表示画像に対応した音響出力が得られる。

また、コンバイナ２１２で統合して得られたオーディオストリームは配信インタフェース２３２に供給される。配信インタフェース２３２では、このオーディオストリームが、構内ネットワーク接続されたデバイス３００に配信（送信）される。デバイス３００では、オーディオストリームに対してデコード処理が施され、所定数のスピーカを駆動するためのオーディオデータが得られる。

上述したように、図１に示す送受信システム１０において、サービス送信機１００は、３Ｄオーディオエンコードでオーディオストリームを生成するに当たって、同一のエレメントに係る“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”に共通のインデックス情報を挿入するものである。そのため、受信側で複数のオーディオストリームを統合して１つのオーディオストリームにする際、順番の規定を守る必要がなく、処理負荷の軽減を図ることが可能となる。

＜２．変形例＞
なお、上述実施の形態においては、コンテナがトランスポートストリーム（ＭＰＥＧ−２ ＴＳ）である例を示した。しかし、本技術は、ＭＰ４やそれ以外のフォーマットのコンテナで配信されるシステムにも同様に適用できる。例えば、ＭＰＥＧ−ＤＡＳＨベースのストリーム配信システム、あるいは、ＭＭＴ（MPEG Media Transport）構造伝送ストリームを扱う送受信システムなどである。

なお、本技術は、以下のような構成もとることができる。
（１）所定数のオーディオストリームを生成するエンコード部と、
上記所定数のオーディオストリームを含む所定フォーマットのコンテナを送信する送信部を備え、
上記オーディオストリームは、符号化データをペイロード情報として持つ第１のパケットと、該第１のパケットのペイロード情報の構成を示す構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなり、
関連する上記第１のパケットおよび上記第２のパケットのペイロードには共通のインデックス情報が挿入される
送信装置にある。
（２）上記第１のパケットがペイロード情報として持つ符号化データは、チャネル符号化データまたはオブジェクト符号化データである
前記（１）に記載の送信装置。
（３）所定数のオーディオストリームを生成するエンコードステップと、
送信部により、上記所定数のオーディオストリームを含む所定フォーマットのコンテナを送信する送信ステップを有し、
上記オーディオストリームは、符号化データをペイロード情報として持つ第１のパケットと、該第１のパケットのペイロード情報の構成を示す構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなり、
関連する上記第１のパケットおよび上記第２のパケットのペイロードには共通のインデックス情報が挿入される
送信方法。
（４）所定数のオーディオストリームを含む所定フォーマットのコンテナを受信する受信部を備え、
上記オーディオストリームは、符号化データをペイロード情報として持つ第１のパケットと、該第１のパケットのペイロード情報の構成を示す構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなり、
関連する上記第１のパケットおよび上記第２のパケットのペイロードには共通のインデックス情報が挿入されており、
上記所定数のオーディオストリームから一部または全部の上記第１のパケットおよび上記第２のパケットを取り出し、上記第１のパケットおよび上記第２のパケットのペイロード部に挿入されている上記インデックス情報を利用して１つのオーディオストリームに統合するストリーム統合部と、
上記１つのオーディオストリームを処理する処理部をさらに備える
受信装置。
（５）上記処理部は、上記１つのオーディオストリームに対してデコード処理を施す
前記（４）に記載の受信装置。
（６）上記処理部は、上記１つのオーディオストリームを外部機器に送信する
前記（４）または（５）に記載の受信装置。
（７）受信部により、所定数のオーディオストリームを含む所定フォーマットのコンテナを受信する受信ステップを有し、
上記オーディオストリームは、符号化データをペイロード情報として持つ第１のパケットと、該第１のパケットのペイロード情報の構成を示す構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなり、
関連する上記第１のパケットおよび上記第２のパケットのペイロードには共通のインデックス情報が挿入されており、
上記所定数のオーディオストリームから一部または全部の上記第１のパケットおよび上記第２のパケットを取り出し、上記第１のパケットおよび上記第２のパケットのペイロード部に挿入されている上記インデックス情報を利用して１つのオーディオストリームに統合するストリーム統合ステップと、
上記１つのオーディオストリームを処理する処理ステップをさらに有する
受信方法。

本技術の主な特徴は、３Ｄオーディオエンコードでオーディオストリームを生成するに当たって、同一のエレメントに係る“Ｆｒａｍｅ”と“Ｃｏｎｆｉｇ”に共通のインデックス情報を挿入することで、受信側のストリーム統合処理の処理負荷を軽減可能としたことである（図３、図８参照）。

１０・・・送受信システム
１００・・・サービス送信機
１１０・・・ストリーム生成部
１１２・・・ビデオエンコーダ
１１３・・・３Ｄオーディオエンコーダ
１１４・・・マルチプレクサ
２００・・・サービス受信機
２０１・・・受信部
２０２・・・デマルチプレクサ
２０３・・・ビデオデコーダ
２０４・・・映像処理回路
２０５・・・パネル駆動回路
２０６・・・表示パネル
２１１-1〜２１１-N・・・多重化バッファ
２１２・・・コンバイナ
２１３・・・３Ｄオーディオデコーダ
２１４・・・音声出力処理回路
２１５・・・スピーカシステム
２２１・・・ＣＰＵ
２２２・・・フラッシュＲＯＭ
２２３・・・ＤＲＡＭ
２２４・・・内部バス
２２５・・・リモコン受信部
２２６・・・リモコン送信機
２３２・・・配信インタフェース
３００・・・デバイス

Claims (7)

1. 所定数のオーディオストリームを生成するエンコード部と、
   上記所定数のオーディオストリームを含む所定フォーマットのコンテナを送信する送信部を備え、
   上記オーディオストリームは、符号化データを構成するエレメントをペイロード情報として持つ１つ以上の第１のパケットと、上記１つ以上の第１のパケットが持つ各エレメントに対応する構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなり、
   上記１つ以上の第１のパケットおよび上記第２のパケットのペイロードには上記各エレメントと上記各エレメントに対応する構成情報を紐づけるための共通のインデックス情報が挿入される
   送信装置。
2. 上記第１のパケットがペイロード情報として持つ符号化データは、チャネル符号化データまたはオブジェクト符号化データである
   請求項１に記載の送信装置。
3. 所定数のオーディオストリームを生成するエンコードステップと、
   送信部により、上記所定数のオーディオストリームを含む所定フォーマットのコンテナを送信する送信ステップを有し、
   上記オーディオストリームは、符号化データを構成するエレメントをペイロード情報として持つ１つ以上の第１のパケットと、上記１つ以上の第１のパケットが持つ各エレメントに対応する構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなり、
   上記１つ以上の第１のパケットおよび上記第２のパケットのペイロードには上記各エレメントと上記各エレメントに対応する構成情報を紐づけるための共通のインデックス情報が挿入される
   送信方法。
4. 所定数のオーディオストリームを含む所定フォーマットのコンテナを受信する受信部を備え、
   上記オーディオストリームは、符号化データを構成するエレメントをペイロード情報として持つ１つ以上の第１のパケットと、上記１つ以上の第１のパケットが持つ各エレメントに対応する構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなり、
   上記１つ以上の第１のパケットおよび上記第２のパケットのペイロードには上記各エレメントと上記各エレメントに対応する構成情報を紐づけるための共通のインデックス情報が挿入されており、
   上記所定数のオーディオストリームから一部または全部の上記第１のパケットおよび上記第２のパケットを取り出し、上記第１のパケットおよび上記第２のパケットのペイロード部に挿入されている上記インデックス情報を利用して１つのオーディオストリームに統合するストリーム統合部と、
   上記１つのオーディオストリームを処理する処理部をさらに備える
   受信装置。
5. 上記処理部は、上記１つのオーディオストリームに対してデコード処理を施す
   請求項４に記載の受信装置。
6. 上記処理部は、上記１つのオーディオストリームを外部機器に送信する
   請求項４に記載の受信装置。
7. 受信部により、所定数のオーディオストリームを含む所定フォーマットのコンテナを受信する受信ステップを有し、
   上記オーディオストリームは、符号化データを構成するエレメントをペイロード情報として持つ１つ以上の第１のパケットと、上記１つ以上の第１のパケットが持つ各エレメントに対応する構成情報をペイロード情報として持つ第２のパケットを含むオーディオフレームからなり、
   上記１つ以上の第１のパケットおよび上記第２のパケットのペイロードには上記各エレメントと上記各エレメントに対応する構成情報を紐づけるための共通のインデックス情報が挿入されており、
   上記所定数のオーディオストリームから一部または全部の上記第１のパケットおよび上記第２のパケットを取り出し、上記第１のパケットおよび上記第２のパケットのペイロード部に挿入されている上記インデックス情報を利用して１つのオーディオストリームに統合するストリーム統合ステップと、
   上記１つのオーディオストリームを処理する処理ステップをさらに有する
   受信方法。

Images