JP6192902B2 - 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法 - Google Patents

画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法 Download PDF

Info

Publication number
JP6192902B2
JP6192902B2 JP2012148958A JP2012148958A JP6192902B2 JP 6192902 B2 JP6192902 B2 JP 6192902B2 JP 2012148958 A JP2012148958 A JP 2012148958A JP 2012148958 A JP2012148958 A JP 2012148958A JP 6192902 B2 JP6192902 B2 JP 6192902B2
Authority
JP
Japan
Prior art keywords
view
image data
stream
video stream
data
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
JP2012148958A
Other languages
English (en)
Other versions
JP2013255207A5 (ja
JP2013255207A (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.)
Saturn Licensing LLC
Original Assignee
Saturn Licensing LLC
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
Priority to JP2012148958A priority Critical patent/JP6192902B2/ja
Application filed by Saturn Licensing LLC filed Critical Saturn Licensing LLC
Priority to CN201810586327.XA priority patent/CN108471546A/zh
Priority to EP12848650.3A priority patent/EP2645725B1/en
Priority to PCT/JP2012/078621 priority patent/WO2013069604A1/ja
Priority to US13/997,575 priority patent/US20140071232A1/en
Priority to CN2012800046748A priority patent/CN103339945A/zh
Priority to KR1020137016729A priority patent/KR102009048B1/ko
Publication of JP2013255207A publication Critical patent/JP2013255207A/ja
Publication of JP2013255207A5 publication Critical patent/JP2013255207A5/ja
Application granted granted Critical
Publication of JP6192902B2 publication Critical patent/JP6192902B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/194—Transmission of image signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/161—Encoding, multiplexing or demultiplexing different image signal components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/172—Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/178—Metadata, e.g. disparity information
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • 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/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video

Description

本技術は、画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法に関する。
従来、動画像の符号化方式として、Ｈ．２６４／ＡＶＣ（Advanced Video Coding）が知られている（非特許文献１参照）。また、このＨ．２６４／ＡＶＣの拡張方式として、Ｈ．２６４／ＭＶＣ（Multi-view Video Coding）が知られている（非特許文献２参照）。ＭＶＣでは、マルチビューの画像データをまとめて符号化する仕組みが採用されている。ＭＶＣでは、マルチビュー画像データを、１個のベースビュー(base view)の画像データと、１個以上のノンベースビュー (non-baseview)の画像データとして符号化する。
なお、このＨ．２６４／ＡＶＣの拡張方式として、Ｈ．２６４／ＳＶＣ（Scalable Video Coding）も知られている（非特許文献３参照）。ＳＶＣは、画像を階層的に符号化する技術である。ＳＶＣでは、動画像を最低限の品質で復号化するのに必要な画像データを有する基本階層（最下位階層）と、この基本階層に付加することによって動画像の品質を高める画像データを有する拡張階層（上位階層）に分けられている。
「Draft Errata List with Revision-Marked Corrections for H.264/AVC」, JVT-1050, Thomas Wiegand et al., Joint Video Team (JVT) of ISO/IECMPEG & ITU-T VCEG, 2003 Joint Draft 4.0 on Multiview Video Coding, Joint Video Team ofISO/IEC MPEG & ITU-T VCEG,JVT-X209, July 2007 Heiko Schwarz, Detlev Marpe, and Thomas Wiegand,"Overview of the Scalable Video Coding Extension of the H.264/AVCStandard ", IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMSFOR VIDEO TECHNOLOGY, VOL.17, NO.9, SEPTEMBER 2007, pp.1103-1120.
ＡＶＣストリームとＭＶＣストリームとが、動的に切り替わる配信環境において、ＭＶＣに対応した受信機は、「Stream_Type=0x1B」のみのストリームか、「Stream_Type=0x1B」と「Stream_Type=0x20」の両方があるストリームかを判断して、受信モードの切換えを行うことが期待される。
通常のＡＶＣ（２Ｄ）のビデオエレメンタリストリームは、ＰＭＴ（Program Map Table）の「Stream_Type=0x1B」で送られる。また、ＭＶＣのベースビュー（Base view）のビデオエレメンタリストリーム（Base viewsub-bitstream）は、ＰＭＴの「Stream_Type=0x1B」で送られる場合がある。
トランスポートストリーム（Transport Stream）の中のセクション（Section）部分には、ＰＳＩ（Program Specific Information）としてのＰＭＴのレベルで、ＡＶＣストリームであるかＭＶＣストリームであるかが分かる仕組みが提供されている。すなわち、ビデオエレメンタリストリームが「Stream_Type=0x1B」のみのときは、２ＤＡＶＣストリームであることが分かる。また、ビデオエレメンタリストリームが「Stream_Type=0x1B」と「Stream_Type=0x20」の両方があるときは、ＭＶＣストリームであることが分かる。
しかし、ＰＭＴというのは、送信側設備によっては、必ずしも動的に更新されない場合がある。その場合には、配信内容が立体（３Ｄ）画像から２次元（２Ｄ）画像に切り替わる際に、以下の不都合が考えられる。すなわち、受信機は、ストリームタイプ（Stream_Type）が「0x1B」のエレメンタリストリームと共に、ストリームタイプ（Stream_Type）が「0x20」のストリームも継続受信するものとして、そのデータを待ち続けることが考えられる。
配信内容が２次元（２Ｄ）画像に切り替わった後には、「0x20」のエレメンタリストリームは受信されないわけだが、受信機内部では、「0x20」のエレメンタリストリームがくるものとして、待ち続ける。その結果、正しいデコードに至らず、正常な表示ができなくなるおそれがある。このように、受信機が、ＰＭＴの［Stream_type］の種類のみを当てにして自らのモードを決定した場合、そのモードが正しくなく、正しいストリーム受信でない可能性が出てくる。
図９４は、トランスポートストリーム内におけるビデオエレメンタリストリームとＰＭＴ（Program Map Table）の構成例を示している。ビデオエレメンタリストリームＥＳ１，ＥＳ２の「００１」〜「００９」のアクセスユニット（ＡＵ：Access Unit）の期間は、２本のビデオエレメンタリストリームが存在する期間である。この期間は、例えば３Ｄ番組の本体期間であり、この２本のストリームは立体（３Ｄ）画像データのストリームを構成している。
それに続く、ビデオエレメンタリストリームＥＳ１の「０１０」〜「０１４」のアクセスユニットの期間は、１本のビデオエレメンタリストリームのみ存在する期間である。この期間は、例えば、３Ｄ番組の本体期間の間に挿入されているＣＭ期間であり、この１本のストリームは２次元画像データのストリームを構成している。
さらに、それに続く、ビデオエレメンタリストリームＥＳ１，ＥＳ２の「０１５」〜「０１６」のアクセスユニットの期間は、２本のビデオエレメンタリストリームが存在する期間である。この期間は、例えば３Ｄ番組の本体期間であり、この２本のストリームは立体（３Ｄ）画像データのストリームを構成している。
ＰＭＴにおけるビデオエレメンタリストリームの登録をアップデートする周期（例えば、１００ｍｓｅｃ）は、ビデオのフレーム周期（例えば、３３．３ｍｓｅｃ）に追従できない。トランスポートストリームを構成するエレメンタリストリームの動的変化をＰＭＴによって知らせる方法では、エレメンタリストリームとＰＭＴのトランスポートストリーム内の構成が非同期なため、受信機に対して正しい動作を約束させるものにはならない。
また、既存の信号規格(ＭＰＥＧ)では、「Stream_Type=0x1B」のＭＶＣのベースビューのビデオエレメンタリストリーム（Base view sub-bitstream）には、ＰＭＴの記述子として、「MVC_extensiondescriptor」のデスクリプタを挿入することが必須とされている。このデスクリプタが存在すれば、ノンベースビューのビデオエレメンタリストリーム（Non-Base view sub-bitstream）の存在が分かる。
しかし、「Stream_Type=0x1B」が指す「Elementary PID」のビデオエレメンタリストリームは、上述のＭＶＣのベースビュー（Base view）のビデオエレメンタリストリーム（Base viewsub-bitstream）であるとは限らない。従来のＡＶＣ（この場合、多くはHigh Profile)のストリームである場合も考えられる。特に、既存の２Ｄ受信機との互換性を保証するために、立体（３Ｄ）画像データであるが、ベースビューのビデオエレメンタリストリームが、従来のＡＶＣ（２Ｄ）のビデオエレメンタリストリームそのままであることが推奨される場合がある。
この場合、立体画像データのストリームは、ＡＶＣ（２Ｄ）のビデオエレメンタリストリームと、ノンベースビューのビデオエレメンタリストリーム（Non-Base view sub-bitstream）とで構成される。その場合、「Stream_Type=0x1B」のビデオエレメンタリストリームには、「MVC_extension descriptor」の記述子は関連付けされない。そのため、ベースビューのビデオエレメンタリストリームに相当するＡＶＣ（２Ｄ）のビデオエレメンタリストリーム以外に、ノンベースビューのビデオエレメンタリストリーム（Non-Base view sub-bitstream）の存在が分からないことになる。
また、上述では、トランスポートストリームに含まれるエレメンタリストリームが立体（３Ｄ）画像データを構成しているか否かの判断が困難であること等を説明した。詳細説明は省略するが、これらの不都合は、ＡＶＣストリームと上述のＳＶＣストリームとを時分割的に送信する場合にも生じる。
本技術の目的は、受信側において、配信内容の動的な変化に的確に対応し、正しいストリーム受信を行い得るようにすることにある。
本技術の概念は、
所定数の画像データを含む１つまたは複数のビデオストリームを送信する送信部と、
複数の画像データを送信する第１の送信モードと単一の画像データを送信する第２の送信モードとを識別するための補助情報を、上記ビデオストリームに挿入する情報挿入部とを備える
画像データ送信装置。
本技術において、送信部により、所定数のビューの画像データを含む１つまたは複数のビデオストリームが送信される。そして、情報挿入部により、複数の画像データを送信する第１の送信モードと単一の画像データを送信する第２の送信モードとを識別するための補助情報がビデオストリームに挿入される。例えば、情報挿入部は、補助情報を、少なくとも、番組単位、シーン単位、ピクチャグループ単位、あるいはピクチャ単位で挿入する、ようにされてもよい。
例えば、第１の送信モードは、立体画像表示のための、ベースビューの画像データと、このベースビューの画像データと共に使用されるノンベースビューの画像データを送信する立体画像送信モードであり、第２の送信モードは、２次元画像データを送信する２次元画像送信モードである、ようにされてもよい。
そして、この場合、例えば、第１の送信モードは、ステレオ立体画像表示のための左眼ビューの画像データおよび右眼ビューの画像データを送信する立体画像送信モードである、ようにされてもよい。また、この場合、例えば、立体画像送信モードを示す補助情報は、各ビューの相対位置関係を示す情報を含んでいてもよい。
また、例えば、第１の送信モードは、スケーラブル符号化画像データを構成する、最下位階層の画像データと、該最下位階層以外の階層の画像データを送信する拡張画像送信モードであり、第２の送信モードは、基本画像データを送信する基本画像送信モードである、ようにされてもよい。
本技術において、例えば、情報挿入部は、第１の送信モードでは、ビデオストリームに、この第１の送信モードであることを示す補助情報を挿入し、第２のモードでは、ビデオストリームに、この第２の送信モードであることを示す補助情報を挿入する、ようにされてもよい。
また、本技術において、例えば、情報挿入部は、第１の送信モードでは、ビデオストリームに、この第１の送信モードであることを示す補助情報を挿入し、第２の送信モードでは、ビデオストリームに補助情報を挿入しない、ようにされてもよい。
また、情報挿入部は、第１の送信モードでは、ビデオストリームに補助情報を挿入せず、第２の送信モードでは、ビデオストリームに、この第２の送信モードであることを示す補助情報を挿入する、ようにされてもよい。
また、本技術において、例えば、送信部は、第１の送信モードでは、第１の画像データを含む基本ビデオストリームと、この第１の画像データと共に使用される第２の画像データを含む所定数の追加ビデオストリームを送信し、第２の送信モードでは、第１の画像データを含む１つのビデオストリームを送信する、ようにされてもよい。
また、本技術において、例えば、送信部は、第１の送信モードでは、第１の画像データを含む基本ビデオストリームと、この第１の画像データと共に使用される第２の画像データを含む所定数の追加ビデオストリームを送信し、第２の送信モードでは、第１の画像データを含む基本ビデオストリームと、この第１の画像データと同じ画像データを実質的に含む所定数の追加ビデオストリームとを送信する、ようにされてもよい。
このように本技術においては、所定数の画像データを含む１つまたは複数のビデオストリームを送信する際に、複数の画像データを送信する第１の送信モードと単一の画像データを送信する第２の送信モードとを識別するための補助情報をビデオストリームに挿入するものである。そのため、受信側では、この補助情報に基づいて、第１の送信モードであるか第２の送信モードであるかを容易に把握でき、ストリーム構成の変化、つまり、配信内容の動的な変化に的確に対応でき、正しいストリーム受信を行うことが可能となる。
なお、本技術において、例えば、送信部は、ビデオストリームを含む所定フォーマットのコンテナを送信し、このコンテナのレイヤに、第１の送信モードにあるか第２の送信モードにあるかを識別するための識別情報を挿入する識別情報挿入部をさらに備える、ようにされてもよい。このようにコンテナのレイヤに識別情報が挿入されることで、受信側において、フレキシブルな動作が可能となる。
また、本技術の他の概念は、
所定数の画像データを含む１つまたは複数のビデオストリームを受信する受信部と、
上記受信されたビデオストリームに挿入されている補助情報に基づいて、複数の画像データが送信される第１の送信モードであるか単一の画像データが送信される第２の画像データであるかを識別する送信モード識別部と、
上記受信されたビデオストリームを、上記モード識別結果に基づいて、各モードに応じた処理を行って、上記所定数の画像データを取得する処理部とを備える
画像データ受信装置にある。
本技術において、受信部により、所定数の画像データを含む１つまたは複数のビデオストリームが受信される。送信モード識別部により、受信されたビデオストリームに挿入されている補助情報に基づいて、複数の画像データが送信される第１の送信モードであるか単一の画像データが送信される第２の送信モードであるかが識別される。
例えば、第１の送信モードは、立体画像表示のための、ベースビューの画像データと、このベースビューの画像データと共に使用されるノンベースビューの画像データを送信する立体画像送信モードであり、第２の送信モードは、２次元画像データを送信する２次元画像送信モードであってもよい。また、例えば、第１の送信モードは、スケーラブル符号化画像データを構成する、最下位階層の画像データと、この最下位階層以外の階層の画像データを送信する拡張画像送信モードであり、第２の送信モードは、基本画像データを送信する基本画像送信モードである、ようにされてもよい。
本技術において、例えば、送信モード識別部は、受信されたビデオストリームに第１の送信モードであることを示す補助情報が挿入されているとき、この第１の送信モードであると識別し、受信されたビデオストリームに第２の送信モードであることを示す補助情報が挿入されているとき、この第２の送信モードであると識別する、ようにされてもよい。
また、本技術において、例えば、送信モード識別部は、受信されたビデオストリームに第１の送信モードであることを示す補助情報が挿入されているとき、この第１の送信モードであることを識別し、受信されたビデオストリームに補助情報の挿入がないとき、第２の送信モードであると識別する、ようにされてもよい。
また、本技術において、例えば、送信モード識別部は、受信されたビデオストリームに補助情報の挿入がないとき、第１の送信モードであると識別し、受信されたビデオストリームに第２の送信モードであることを示す補助情報が挿入されているとき、この第２の送信モードであることを識別する、ようにされてもよい。
また、本技術において、例えば、受信部は、第１の送信モードでは、第１の画像データを含む基本ビデオストリームと、この第１の画像データと共に使用される第２の画像データを含む所定数の追加ビデオストリームを受信し、第２の送信モードでは、第１の画像データを含む１つのビデオストリームを受信し、処理部は、第１の送信モードでは、基本ビデオストリームおよび所定数の追加のビデオストリームを処理して、第１の画像データおよび第２の画像データを取得し、第２の送信モードでは、１つのビデオストリームを処理して、第１の画像データを取得する、ようにされてもよい。
また、本技術において、例えば、受信部は、第１の送信モードでは、第１の画像データを含む基本ビデオストリームと、この第１の画像データと共に使用される第２の画像データを含む所定数の追加ビデオストリームを受信し、第２の送信モードでは、第１の画像データを含む基本ビデオストリームと、この第１の画像データと同じ画像データを実質的に含む所定数の追加ビデオストリームとを受信し、処理部は、第１の送信モードでは、基本ビデオストリームおよび所定数の追加のビデオストリームを処理して、第１の画像データおよび第２の画像データを取得し、第２の送信モードでは、所定数の追加のビデオストリームから第２の画像データを取得する処理を行うことなく、基本のビデオストリームを処理して、第１の画像データを取得する、ようにされてもよい。
このように本技術においては、受信されたビデオストリームに挿入されている補助情報に基づいて、複数の画像データが送信される第１の送信モードであるか単一の画像データが送信される第２の画像データであるかを識別するものである。そして、受信されたビデオストリームに対して、識別されたモードに応じた処理を行って、所定数の画像データを取得するものである。第１の送信モードであるか第２の送信モードであるかを容易に把握でき、ストリーム構成の変化、つまり、配信内容の動的な変化に的確に対応でき、正しいストリーム受信を行うことが可能となる。
なお、本技術において、例えば、受信部は、ビデオストリームを含む所定フォーマットのコンテナを受信し、コンテナには、第１の送信モードにあるか第２の送信モードにあるかを識別するための識別情報が挿入されており、送信モード識別部は、受信されたビデオストリームに挿入されている補助情報およびコンテナのレイヤに挿入されている識別情報に基づいて、複数の画像データが送信される第１の送信モードであるか単一の画像データが送信される第２の送信モードであるかを識別する、ようにされてもよい。
本技術によれば、受信側では、エレメンタリストリームの構成変化、つまり、配信内容の動的な変化に的確に対応でき、ストリーム受信を良好に行うことができる。
実施の形態としての画像送受信システムの構成例を示すブロック図である。 中央、左端および右端の各ビューの画像データがそれぞれ１つのピクチャのデータとして符号化される例を説明するための図である。 中央のビューの画像データは１つのピクチャのデータとして符号化され、左端および右端の２つのビューの画像データはインターリーブ処理されて１つのピクチャのデータとして符号化される例を説明するための図である。 複数のピクチャの符号化データを含むビデオストリームの一例を示す図である。 ３つのピクチャの符号化データが１つのビデオストリームに共存する場合の例を示す図である。 Ｎ個のビューのうち、左端および右端のビューと、それらの間に位置する中央のビューの画像データを伝送する方法において、ビュー数を５とした場合の受信機の表示部を概略的に示す図である。 トランスポートストリームを生成する送信データ生成部の構成例を示すブロック図である。 送信データ生成部内のビューセレクタにおけるビュー選択状態を示す図である。 ブロック（Block）毎の視差データ（視差ベクトル）の一例を示す図である。 ブロック単位の視差データの生成方法の一例を説明するための図である。 ブロック単位から画素単位への変換処理により画素単位の視差データを生成する方法を説明するための図である。 識別情報としてのマルチビュー・ストリーム・コンフィグレーション・デスクリプタの構造例を示す図である。 マルチビュー・ストリーム・コンフィグレーション・デスクリプタの構造例における主要な情報の内容を示す図である。 ビュー構成情報としてのマルチビュー・ストリーム・コンフィグレーション・インフォの構造例を示す図である。 マルチビュー・ストリーム・コンフィグレーション・インフォの構造例における主要な情報の内容を示す図である。 マルチビュー・ストリーム・コンフィグレーション・インフォの構造例における主要な情報の内容を示す図である。 マルチビュー・ストリーム・コンフィグレーション・インフォの構造例における主要な情報の内容を示す図である。 「view_count」が示すビュー数と、「view_pair_position_id」が示す２つのビューの位置との関係の一例を示す図である。 両端の２つのビューペアの画像データと共に、両端よりも内側の２つのビューペアの画像データを送信する場合において、送信側あるいは受信側における視差データの生成例を説明するための図である。 視差データに基づき、受信側で、各ビューの間に位置するビューの画像データを補間合成する例を説明するための図である。 マルチビュー・ストリーム・コンフィグレーション・ＳＥＩがアクセスユニットの“ＳＥＬｓ”の部分に挿入されることを説明するための図である。 「Multiview stream configuration SEI message」および「userdata_for_multiview_stream_configuration()」の構造例を示す図である。 「user_data()」の構造例を示す図である。 トランスポートストリームＴＳに３つのビデオストリームが含まれる場合の構成例を示す図である。 トランスポートストリームＴＳに２つのビデオストリームが含まれる場合の構成例を示す図である。 トランスポートストリームＴＳに１つのビデオストリームが含まれる場合の構成例を示す図である。 画像送受信システムを構成する受信機の構成例を示すブロック図である。 スケーリング比の算出例を示す図である。 ビュー補間部における補間合成処理の一例を概略的に示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ＣＰＵにおける動作モード切り替えの制御の処理手順の一例を示すフローチャートである。 トランスポートストリームに含まれるビデオストリームの一例を示す図である。 ３Ｄ期間（立体画像送信モード）と２Ｄ期間（２次元画像送信モード）が交互に連続する場合であって、モード識別のための補助情報（マルチビュー・ストリーム・コンフィグレーション・ＳＥＩメッセージ）がない場合を示す図である。 ３Ｄ期間と２Ｄ期間が交互に連続する場合であって、モード識別のための補助情報（マルチビュー・ストリーム・コンフィグレーション・ＳＥＩメッセージ）がある場合の一例を示す図である。 画像送受信システムを構成する受信機の他の構成例を示すブロック図である。 マルチビュー・ストリーム・コンフィグレーション・ＳＥＩメッセージに含まれるマルチビュー・ビュー・ポジション（Multiview view position（））の構造例（Syntax）を示す図である。 マルチビュー・ポジション・ＳＥＩがアクセスユニットの“ＳＥＩｓ”の部分に挿入されることを説明するための図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ＣＰＵにおける動作モード切り替えの制御の処理手順の一例を示すフローチャートである。 トランスポートストリームに含まれるビデオストリームの一例を示す図である。 ３Ｄ期間と２Ｄ期間が交互に連続する場合であって、モード識別のための補助情報（マルチビュー・ビュー・ポジション・ＳＥＩメッセージ）がある場合の一例を示す図である。 ＣＰＵにおける動作モード切り替えの制御の処理手順の一例を示すフローチャートである。 フレーム・パッキング・アレンジメント・データ（frame_packing_arrangement_data()）の構造例（Syntax）を示す図である。 「arrangement_type」の値とその意味を説明するための図である。 「user_data()」の構造例(Syntax)を示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ２Ｄモードを示す補助情報が、２Ｄ期間に、シーン単位あるいはピクチャグループ単位（ＧＯＰ単位）で挿入される場合を示す図である。 ＣＰＵにおける動作モード切り替えの制御の処理手順の一例を示すフローチャートである。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ３Ｄ期間と２Ｄ期間が交互に連続する場合であって、モード識別のための補助情報（新規定義の２Ｄモードであることを示すＳＥＩメッセージ）がある場合の一例を示す図である。 左眼および右眼の各ビューの画像データがそれぞれ１つのピクチャのデータとして符号化される例を説明するための図である。 トランスポートストリームを生成する送信データ生成部の他の構成例を示すブロック図である。 画像送受信システムを構成する受信機の他の構成例を示すブロック図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 トランスポートストリームに含まれるビデオストリームの一例を示す図である。 ３Ｄ期間に基本ストリームおよび追加ストリームが存在し、２Ｄ期間に基本ストリームのみが存在する場合において、３Ｄ期間と２Ｄ期間を識別するケースＡ、ケースＢ、ケースＣの方法をまとめて示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ＣＰＵにおける動作モード切り替えの制御の処理手順の一例を示すフローチャートである。 受信機における立体（３Ｄ）画像受信時の受信パケット処理の一例を示す図である。 ＮＡＬユニットヘッダ（NAL unit header MVC extension）の構成例（Syntax）を示す図である。 受信機における２次元（２Ｄ）画像受信時の受信パケット処理の一例を示す図である。 トランスポートストリームに含まれるビデオストリームの一例を示す図である。 ３Ｄ期間（３Ｄモード期間）と２Ｄ期間（２Ｄモード期間）が交互に連続する場合であって、モード識別のための補助情報（マルチビュー・ビュー・ポジション・ＳＥＩメッセージ）がある場合の一例を示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 トランスポートストリームに含まれるビデオストリームの一例を示す図である。 ３Ｄ期間（３Ｄモード期間）と２Ｄ期間（２Ｄモード期間）が交互に連続する場合であって、モード識別のための補助情報（マルチビュー・ビュー・ポジション・ＳＥＩメッセージ）がある場合の一例を示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 トランスポートストリームに含まれるビデオストリームの一例を示す図である。 ３Ｄ期間（３Ｄモード期間）と２Ｄ期間（２Ｄモード期間）が交互に連続する場合であって、モード識別のための補助情報（新規定義の２Ｄモードであることを示すＳＥＩメッセージ）がある場合の一例を示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 ３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示す図である。 トランスポートストリームに含まれるビデオストリームの一例を示す図である。 ３Ｄ期間および２Ｄ期間の双方に基本ストリームおよび追加ストリームが存在する場合において、３Ｄ期間と２Ｄ期間を識別するケースＤ、ケースＥ、ケースＦの方法をまとめて示す図である。 ３Ｄ期間（３Ｄ画像送信モード）で基本ビデオストリームおよび追加ビデオストリームが送信され、２Ｄ期間（２Ｄ画像送信モード）で単一のビデオストリーム（基本ビデオストリームのみ）が送信されるストリーム構成例１を示す図である。 ３Ｄ期間（３Ｄ画像送信モード）と２Ｄ期間（２Ｄ画像送信モード）の双方で基本ビデオストリームおよび追加ビデオストリームが送信されストリーム構成例２を示す図である。 ３Ｄ期間、２Ｄ期間の双方に基本ビデオストリームおよび追加ビデオストリームが存在し、ＰＭＴのプログラム・ループとビデオＥＳループの双方でシグナリングが行われる例を示す図である。 ステレオスコピック・プログラム・インフォ・デスクリプタ（Stereoscopic_program_info_descriptor）の構造例（Syntax）を示す図である。 ＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタの構造例（Syntax）を示す図である。 トランスポートストリームＴＳの構成例を示す図である。 ３Ｄ期間、２Ｄ期間の双方に基本ビデオストリームおよび追加ビデオストリームが存在し、ＰＭＴのビデオＥＳループでシグナリングが行われる例を示す図である。 ３Ｄ期間、２Ｄ期間の双方に基本ビデオストリームおよび追加ビデオストリームが存在し、ＰＭＴのプログラム・ループでシグナリングが行われる例を示す図である。 ３Ｄ期間に基本ビデオストリームおよび追加ビデオストリームが存在し、２Ｄ期間に基本ビデオストリームのみが存在し、ＰＭＴのプログラム・ループとビデオＥＳループの双方でシグナリングが行われる例を示す図である。 ３Ｄ期間に基本ビデオストリームおよび追加ビデオストリームが存在し、２Ｄ期間に基本ビデオストリームのみが存在し、ビデオＥＳループでシグナリングが行われる例を示す図である。 ３Ｄ期間に基本ビデオストリームおよび追加ビデオストリームが存在し、２Ｄ期間に基本ビデオストリームのみが存在し、ＰＭＴのプログラム・ループでシグナリングが行われる例を示す図である。 拡張画像受信時の受信パケット処理の一例を示す図である。 ＮＡＬユニットヘッダ（NAL unit header SVC extension）の構成例（Syntax）を示す図である。 基本画像送信モードの受信パケット処理の一例を示す図である。 トランスポートストリーム内におけるビデオエレメンタリストリームとＰＭＴ（Program Map Table）の構成例を示す図である。
以下、発明を実施するための形態（以下、「実施の形態」とする）について説明する。なお、説明は以下の順序で行う。
１．実施の形態
２．変形例
＜１．実施の形態＞
［画像送受信システム］
図１は、実施の形態としての画像送受信システム１０の構成例を示している。この画像送受信システム１０は、放送局１００および受信機２００により構成されている。放送局１００は、コンテナとしてのトランスポートストリームＴＳを放送波に載せて送信する。
立体（３Ｄ）画像送信時には、トランスポートストリームＴＳに、立体画像表示のための所定数、この実施の形態においては３つのビューの画像データを含む１つまたは複数のビデオストリームが含まれる。この場合、ビデオストリームは、例えば、ＭＶＣのベースビューのビデオエレメンタリストリーム（Base view sub-bitstream）、さらにはＭＶＣのノンベースビューのビデオエレメンタリストリーム（Non-Base view sub-bitstream）として送信される。
また、２次元（２Ｄ）画像表示時には、トランスポートストリームＴＳに、２次元画像データを含むビデオストリームが含まれる。この場合、ビデオストリームは、例えば、ＡＶＣ（２Ｄ）のビデオエレメンタリストリームとして送信される。
立体（３Ｄ）画像送信時に送信されるトランスポートストリームＴＳには、立体画像表示のための複数のビューのうち、少なくとも中央のビュー、左端のビューおよび右端のビューの画像データが符号化されて得られた１つまたは複数のビデオストリームが含まれる。この場合、中央のビューは、左端ビューおよび右端ビューの間に位置する中間ビューを構成している。
この立体（３Ｄ）画像送信時に送信されるトランスポートストリームＴＳに含まれるビデオストリームにおいて、図２に示すように、中央（Center）のビュー、左端（Left)のビューおよび右端（Right）のビューの画像データはそれぞれ１つのピクチャのデータとして符号化される。図示の例では、各ピクチャのデータは１９２０＊１０８０のフルＨＤのサイズとされる。
あるいは、立体（３Ｄ）画像送信時に送信されるトランスポートストリームＴＳに含まれるビデオストリームにおいて、図３（ａ）に示すように、中央（Center）のビューの画像データは１つのピクチャのデータとして符号化され、左端（Left)のビューおよび右端（Right）のビューの画像データはインターリーブ処理されて１つのピクチャのデータとして符号化される。図示の例では、各ピクチャのデータは１９２０＊１０８０のフルＨＤのサイズとされる。
なお、左端のビューおよび右端のビューの画像データがインターリーブ処理されて１つのピクチャのデータとして符号化される場合、各ビューの画像データは水平方向あるいは垂直方向に１／２に間引かれた状態となる。図示の例では、インターリーブのタイプがサイド・バイ・サイドであり、各ビューのサイズは９６０＊１０８０とされる。図示していないが、インターリーブのタイプとしてトップ・アンド・ボトムも考えられ、その場合には、各ビューのサイズは１９２０＊５４０とされる。
このように左端のビューおよび右端のビューの画像データがインターリーブ処理されて１つのピクチャのデータとして符号化される場合、受信側においては、図３（ｂ）に示すように、スケーリング処理され、左端のビューおよび右端のビューの画像データのサイズは１９２０＊１０８０のフルＨＤのサイズに戻される。
立体（３Ｄ）画像送信時に送信されるトランスポートストリームＴＳに含まれるビデオストリームは、１つまたは複数のピクチャのデータを含むものとされる。例えば、このトランスポートストリームＴＳには、以下の３つのビデオストリーム（ビデオエレメンタリストリーム）が含まれる。すなわち、中央のビュー、左端のビューおよび右端のビューの画像データがそれぞれ１つのピクチャとして符号化されて得られたビデオストリームである。
この場合、例えば、中央のビューの画像データが１つのピクチャとして符号化されて得られたビデオストリームは、ＭＶＣのベースビューのビデオエレメンタリストリーム（基本ビデオストリーム）とされる。また、左端のビューおよび右端のビューの画像データがそれぞれ１つのピクチャとして符号化されて得られた残りの２つのビデオストリームは、ＭＶＣのノンベースビューのビデオエレメンタリストリーム（追加ビデオストリーム）とされる。
また、例えば、このトランスポートストリームＴＳには、以下の２つのビデオストリーム（ビデオエレメンタリストリーム）が含まれる。すなわち、中央のビューの画像データが１つのピクチャとして符号化されて得られたビデオストリームと、左端のビューおよび右端のビューの画像データがインターリーブ処理されて１つのピクチャとして符号化されて得られたビデオストリームである。
この場合、例えば、中央のビューの画像データが１つのピクチャとして符号化されて得られたビデオストリームは、ＭＶＣのベースビューのビデオエレメンタリストリーム（基本ビデオストリーム）とされる。また、左端のビューおよび右端のビューの画像データがインターリーブ処理されて１つのピクチャとして符号化されて得られた残りの１つのビデオストリームは、ＭＶＣのノンベースビューのビデオエレメンタリストリーム（追加ビデオストリームとされる。
また、例えば、このトランスポートストリームＴＳには、以下の１つのビデオストリーム（ビデオエレメンタリストリーム）が含まれる。すなわち、この１つのビデオストリームには、中央のビュー、左端のビューおよび右端のビューの画像データがそれぞれ１つのピクチャのデータとして符号化されたデータが含まれる。この場合、この１つのビデオストリームは、ＭＶＣのベースビューのビデオエレメンタリストリーム（基本ビデオストリーム）とされる。
図４（ａ），（ｂ）は、複数のピクチャの符号化データを含むビデオストリームの一例を示している。各アクセスユニットに、各ピクチャの符号化データが順次配置される。この場合、最初のピクチャの符号化データは、“SPS 〜 Coded Slice”で構成され、２番目以降のピクチャの符号化データは、“Subset SPS 〜 Coded Slice”で構成される。なお、この例は、ＭＰＥＧ４−ＡＶＣの符号化がされている例であるが、他の符号化方式でも適用可能である。なお、図中の１６進数字は「 NAL unit type 」を示している。
各ピクチャの符号化データが１つのビデオストリームに共存する場合、各ピクチャの境界が瞬時に識別可能なことが要求される。しかし、ＡＵＤ(access unit delimiter)は、一つのアクセスユニットの先頭にのみ付すことが可能である。そこで、図４（ｂ）に示すように、各ピクチャの符号化データの間に、「View Separation Marker」という境界を示す新たな“NAL unit”を定義して配置することが考えられる。これにより、各ピクチャの先頭データに瞬時にアクセスすることが可能となる。なお、図４（ａ）は、２つのビューのデータの間に、「View Separation Marker」が配置されていない例を示している。
図５（ａ），（ｂ）は、３つのピクチャの符号化データが１つのビデオストリームに共存する場合の例を示している。ここでは、各ピクチャの符号化データをサブストリーム（sub stream）として示している。図５（ａ）は、ＧＯＰ（Group OfPictures）の先頭のアクセスユニットを示しており、図５（ｂ）は、ＧＯＰの先頭以外のアクセスユニットを示している。
ビデオストリームのレイヤ（ピクチャレイヤ、シーケンスレイヤなど）に、このビデオストリーム内の画像データに関するビュー構成情報が挿入される。このビュー構成情報は、立体情報の要素を提示する補助情報を構成している。このビュー構成情報には、当該ビデオストリームに含まれる画像データが３Ｄを構成する一部のビューの画像データであるか否かを示す情報、さらに、３Ｄを構成する一部のビューの画像データである場合には、当該ビデオストリームに含まれる画像データがどのビューの画像データであるかを示す情報（各ビューの相対位置関係を示す情報）、当該ビデオストリームの１アクセスユニット内に複数のピクチャのデータが符号化されているかを示す情報等が含まれている。
このビュー構成情報は、例えば、ビデオストリームのピクチャヘッダまたはシーケンスヘッダのユーザデータ領域などに挿入される。このビュー構成情報は、少なくとも、番組単位、シーン単位、ピクチャグループ単位、あるいはピクチャ単位で挿入される。このビュー構成情報により、受信側では、３Ｄ表示処理または２Ｄ表示処理が行われる。また、このビュー構成情報により、受信側では、３Ｄ表示処理を行う場合に、複数のビューの画像データによる３次元画像（立体画像）の裸眼観賞を行うための適切かつ効率的な処理が可能となる。このビュー構成情報の詳細については後述する。
また、トランスポートストリームＴＳのレイヤに、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを識別するための識別情報が挿入される。この識別情報は、例えば、トランスポートストリームＴＳに含まれるプログラム・マップ・テーブル（ＰＭＴ：Program Map Table）のビデオエレメンタリ・ループ（Video ESloop）の配下、あるいはイベント・インフォメーション・テーブル（ＥＩＴ：Event InformationTable）の配下などに挿入される。この識別情報により、受信側では、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを容易に識別可能となる。この識別情報の詳細については後述する。
受信機２００は、放送局１００から放送波に載せて送られてくるトランスポートストリームＴＳを受信する。また、受信機２００は、立体（３Ｄ）画像送信時には、このトランスポートストリームＴＳに含まれるビデオストリームをデコードして、中央のビュー、左端のビューおよび右端のビューの画像データを取得する。この際、受信機２００は、ビデオストリームのレイヤに含まれるビュー構成情報により、各ビデオストリームに含まれる画像データが、どのビュー位置の画像データであるかを知ることができる。
受信機２００は、中央のビューおよび左端ビューの間の視差データと、中央のビューおよび右端ビューの間の視差データとに基づいて、中央のビューおよび左端ビューの間と、中央のビューおよび右端ビューの間とに位置する所定数のビューの画像データを補間処理で取得する。この際、受信機２００は、ビデオストリームのレイヤに含まれるビュー構成情報により、ビュー数を知ることができ、どの位置のビューが伝送されなかったかを容易に把握できる。
また、受信機２００は、放送局１００からビデオストリームと共に送られてくる視差データストリームをデコードして、上述の視差データを取得する。あるいは、受信機２００は、取得された中央のビュー、左端のビューおよび右端のビューの画像データに基づいて、上述の視差データを生成する。
受信機２００は、放送局１００から送られてくる中央、左端および右端の各ビューの画像データと、上述の補間処理で取得される各ビューの画像データとに基づき、３次元画像（立体画像）の裸眼観賞のために、各ビューの画像を表示部に合成表示する。
図６は、ビュー数を５とした場合の受信機２００の表示部を概略的に示している。ここで、「View_0」は中央のビュー、「View_1」は中央から１つ右のビュー、「View_2」は中央から１つ左のビュー、「View_3」は中央から２つ右、つまり右端のビュー、「View_4」は中央から２つ左、つまり左端のビューを示している。この場合、放送局１００から「View_0」、「View_3」、「View_4」のビューの画像データのみが送信され、受信機２００では「View_0」、「View_3」、「View_4」のビューの画像データが受信され、その他の「View_1」、「View_2」のビューの画像データは補間処理で求められる。そして、受信機２００では、３次元画像（立体画像）の裸眼観賞のために、これらの５つのビューの画像が表示部に合成表示される。なお、図６には、レンチキュラーレンズを示しているが、この代わりにパララックスバリアなどであってもよい。
受信機２００は、２次元（２Ｄ）画像送信時には、このトランスポートストリームＴＳに含まれるビデオストリームをデコードして、２次元画像データを取得する。そして、受信機２００は、この２次元画像データに基づき、２次元画像を表示部に表示する。
「送信データ生成部の構成例」
図７は、放送局１００において、上述したトランスポートストリームＴＳを生成する送信データ生成部１１０の構成例を示している。この送信データ生成部１１０は、Ｎ個の画像データ出力部１１１-1〜１１１-Nと、ビューセレクタ１１２と、スケーラ１１３-1，１１３-2，１１３-3と、ビデオエンコーダ１１４-1，１１４-2，１１４-3と、マルチプレクサ１１５を有している。また、この送信データ生成部１１０は、視差データ生成部１１６と、視差エンコーダ１１７と、グラフィクスデータ出力部１１８と、グラフィクスエンコーダ１１９と、音声データ出力部１２０と、オーディオエンコーダ１２１を有している。
最初に、立体（３Ｄ）画像送信時の場合について説明する。画像データ出力部１１１-1〜１１１-Nは、立体画像表示のためのＮ個のビュー（View 1・・・View N）の画像データを出力する。この画像データ出力部は、例えば、被写体を撮像して画像データを出力するカメラ、あるいは記憶媒体から画像データを読み出して出力する画像データ読み出し部などにより構成される。なお、伝送されないビューの画像データは、実際にはなくてもよい。
また、ビューセレクタ１１２は、Ｎ個のビュー（View 1・・・View N）の画像データから、少なくとも左端のビューおよび右端のビューの画像データと、左端および右端の間に位置する中間のビュー（１つまたは２つ以上）の画像データを選択的に取り出す。この実施の形態において、ビューセレクタ１１２は、左端のビューの画像データＶＬおよび右端のビューの画像データＶＲを取り出すと共に、中央のビューの画像データＶＣを取り出す。図８は、ビューセレクタ１１２におけるビュー選択状態を示している。
また、スケーラ１１３-1，１１３-2，１１３-3は、それぞれ、画像データＶＣ，ＶＬ，ＶＲに対してスケーリング処理を施して、例えば、１９２０＊１０８０のフルＨＤのサイズの画像データＶＣ′，ＶＬ′，ＶＲ′を得る。この場合、画像データＶＣ，ＶＬ，ＶＲが１９２０＊１０８０のフルＨＤのサイズであるときは、そのまま出力する。また、画像データＶＣ，ＶＬ，ＶＲが１９２０＊１０８０のサイズより大きいときは、スケールダウンして出力する。
ビデオエンコーダ１１４-1は、中央のビューの画像データＶＣ′に対して、例えば、ＭＰＥＧ４−ＡＶＣ（ＭＶＣ）、ＭＰＥＧ２ｖｉｄｅｏなどの符号化を施して、符号化ビデオデータを得る。そして、このビデオエンコーダ１１４-1は、後段に備えるストリームフォーマッタ（図示せず）により、この符号化データをサブストリーム（sub stream 1）として含むビデオストリームを生成する。
また、ビデオエンコーダ１１４-2は、左端のビューの画像データＶＬ′に対して、例えば、ＭＰＥＧ４−ＡＶＣ（ＭＶＣ）、ＭＰＥＧ２ｖｉｄｅｏなどの符号化を施して、符号化ビデオデータを得る。そして、このビデオエンコーダ１１４-2は、後段に備えるストリームフォーマッタ（図示せず）により、この符号化データをサブストリーム（sub stream 2）として含むビデオストリームを生成する。
さらに、ビデオエンコーダ１１４-3は、右端のビューの画像データＶＲ′に対して、例えば、ＭＰＥＧ４−ＡＶＣ（ＭＶＣ）、ＭＰＥＧ２ｖｉｄｅｏなどの符号化を施して、符号化ビデオデータを得る。そして、このビデオエンコーダ１１４-3は、後段に備えるストリームフォーマッタ（図示せず）により、この符号化データをサブストリーム（sub stream 3）として含むビデオストリームを生成する。
ビデオエンコーダ１１４-1，１１４-2，１１４-3は、ビデオストリームのレイヤに、上述したビュー構成情報を挿入する。このビュー構成情報には、上述したように、当該ビデオストリームに含まれる画像データが３Ｄを構成する一部のビューの画像データであるか否かを示す情報が含まれている。ここでは、この情報は、当該ビデオストリームに含まれる画像データが３Ｄを構成する一部のビューの画像データであることを示すものとされる。
そして、このビュー構成情報には、当該ビデオストリームに含まれる画像データがどのビューの画像データであるかを示す情報、当該ビデオストリームの１アクセスユニット内に複数のピクチャのデータが符号化されているかを示す情報等が含まれるものとなる。このビュー構成情報は、例えば、ビデオストリームのピクチャヘッダまたはシーケンスヘッダのユーザデータ領域などに挿入される。
視差データ生成部１１６は、ビューセレクタ１１２から出力される中央、左端および右端の各ビューの画像データに基づいて、視差データ（disparity data）を生成する。この視差データには、例えば、中央のビューおよび左端のビューの間の視差データと、中央のビューおよび右端のビューの間の視差データが含まれている。この場合、画素単位、あるいはブロック（Block）単位で、視差データが生成される。図９は、ブロック（Block）毎の視差データ（視差ベクトル）の一例を示している。
図１０は、ブロック単位の視差データの生成方法の一例を示している。この例は、ｉ番目のビューからｊ番目のビューを指し示す視差データを求める例である。この場合、ｉ番目のビューのピクチャに、例えば４＊４、８＊８あるいは１６＊１６などの画素ブロック（視差検出ブロック）が設定される。
図示のように、ｉ番目のビューのピクチャが検出画像とされ、ｊ番目のビューのピクチャが参照画像とされて、ｉ番目のビューのピクチャのブロック毎に、画素間の差分絶対値和が最小となるように、ｊ番目のビューのピクチャのブロック探索がされて、視差データが求められる。
すなわち、Ｎ番目のブロックの視差データＤＰｎは、例えば、以下の（１）式に示すように、当該Ｎ番目のブロックにおける差分絶対値和が最小となるようにブロック探索されて求められる。なお、この（１）式において、Ｄｊはｊ番目のビューのピクチャにおける画素値、Ｄｉはｉ番目のビューのピクチャにおける画素値を示している。
ＤＰｎ ＝ min ( Σ abs( differ (Dj - Di))) ・・・（１）
図１１は、画素単位の視差データの生成方法の一例を示している。この例は、ブロック単位から画素単位へ交換により画素単位の視差データを生成する方法である。図１１（ａ）における“Ａ”、“Ｂ”、“Ｃ”、“Ｄ”、“Ｘ”は、それぞれ、ブロックの領域を示している。
これらのブロックの視差データから、図１１（ｂ）に示すように、“Ｘ”のブロックを４分割した各領域の視差データは、以下の（２）式で求められる。例えば、“Ａ”、“Ｂ”に隣接する分割領域の視差データＸ（Ａ，Ｂ）は、“Ａ”、“Ｂ”、“Ｘ”のブロックの視差データの中央値とされる。その他の分割領域においても、同様にして、視差データが求められる。
Ｘ（Ａ，Ｂ）＝median（Ｘ，Ａ，Ｂ）
Ｘ（Ａ，Ｃ）＝median（Ｘ，Ａ，Ｃ）
Ｘ（Ｂ，Ｄ）＝median（Ｘ，Ｂ，Ｄ）
Ｘ（Ｃ，Ｄ）＝median（Ｘ，Ｃ，Ｄ）
・・・（２）
上述の一度の変換で、視差データの占める領域は、元の縦横サイズの１／２のサイズに狭まる。ブロックサイズにより、この変換を所定回数繰り返すことによって、画素単位の視差データが求まる。なお、テクスチャにエッジを含んでいたりして画面内オブジェクトの複雑度が他の部分よりも高い場合などには、適宜、ブロックサイズを小さくとって、初期のブロック単位の視差データ自体のテクスチャ追従性を向上することも可能である。
視差エンコーダ１１７は、視差データ生成部１１６で生成された視差データに符号化を施して視差ストリーム（視差データエレメンタリストリーム）を生成する。この視差ストリームには、画素単位、またはブロック単位の視差データが含まれることとなる。視差データが画素単位である場合には、画素データと同様に、圧縮符号化して伝送できる。
なお、この視差ストリームにブロック単位の視差データが含まれる場合には、受信側で、上述した変換処理を行うことで、画素単位に変換することも可能である。また、このような視差ストリームの送信がない場合、受信側で、上述したように各ビュー間におけるブロック単位の視差データを求め、さらに画素単位に変換することが可能である。
グラフィクスデータ出力部１１８は、画像に重畳するグラフィクス（字幕としてのサブタイトルも含む）のデータを出力する。グラフィクスエンコーダ１１９は、グラフィクスデータ出力部１１８から出力されたグラフィクスデータを含むグラフィクスストリーム（グラフィクスエレメンタリストリーム）を生成する。ここで、グラフィクスは、重畳情報を構成し、例えば、ロゴ、字幕などである。
なお、グラフィクスデータ出力部１１８から出力されるグラフィクスデータは、例えば、中央のビューの画像に重畳するグラフィクスのデータである。グラフィクスデータ１１９は、視差データ生成部１１６で生成された視差データに基づいて、左端および右端のビューに重畳するグラフィクスのデータを作成して、これらのグラフィクスデータを含むグラフィクスストリームを生成してもよい。この場合には、受信側において左端および右端のビューに重畳するグラフィクスのデータを作成することが不要となる。
グラフィクスデータは、主にはビットマップデータである。このグラフィクスデータには、画像上の重畳位置を示すアイドリングオフセット情報が付加されている。このアイドリングオフセット情報は、例えば、画像の左上の原点から、グラフィクスの重畳位置の左上の画素までの垂直方向、水平方向のオフセット値を示す。なお、字幕データをビットマップデータとして伝送する規格は、例えば、ヨーロッパのデジタル放送規格であるＤＶＢで「DVB_Subtitling」として規格化され、運用されている。
音声データ出力部１２０は、画像データに対応した音声データを出力する。この音声データ出力部１２０は、例えば、マイクロホン、あるいは記憶媒体から音声データを読み出して出力する音声データ読み出し部などにより構成される。オーディオエンコーダ１２１は、音声データ出力部１２０から出力される音声データに対して、ＭＰＥＧ−２Ａｕｄｉｏ、ＡＡＣ等の符号化を施し、オーディオストリーム（オーディオエレメンタリストリーム）を生成する。
マルチプレクサ１１５は、ビデオエンコーダ１１４-1，１１４-2，１１４-3、視差エンコーダ１１７、グラフィクスエンコーダ１１９およびオーディオエンコーダ１２１で生成された各エレメンタリストリームをパケット化して多重し、トランスポートストリームＴＳを生成する。この場合、それぞれのＰＥＳ(Packetized Elementary Stream)のヘッダには、受信側における同期再生のために、ＰＴＳ（Presentation Time Stamp）が挿入される。
マルチプレクサ１１５は、トランスポートストリームＴＳのレイヤに、上述した識別情報を挿入する。この識別情報は、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを識別するための情報である。この識別情報は、例えば、トランスポートストリームＴＳに含まれるプログラム・マップ・テーブル（ＰＭＴ：Program Map Table）のビデオエレメンタリ・ループ（Video ESloop）の配下、あるいはイベント・インフォメーション・テーブル（ＥＩＴ：Event InformationTable）の配下などに挿入される。
次に、２次元（２Ｄ）画像送信時の場合について説明する。画像データ出力部１１１-1〜１１１-Nのいずれかは、２次元画像データを出力する。ビュータセレクタ１１２は、その２次元画像データを取り出す。スケーラ１１３-1は、ビューセレクタ１１２で取り出された２次元画像データに対してスケーリング処理を施して、例えば、１９２０＊１０８０のフルＨＤのサイズの２次元画像データを得る。この場合、スケーラ１１３-1，１１３-2は非動作状態におかれる。
ビデオエンコーダ１１4-1は、２次元画像データに対して、例えば、ＭＰＥＧ４−ＡＶＣ（ＭＶＣ）、ＭＰＥＧ２ｖｉｄｅｏなどの符号化を施して、符号化ビデオデータを得る。そして、このビデオエンコーダ１１４-1は、後段に備えるストリームフォーマッタ（図示せず）により、この符号化データをサブストリーム（sub stream 1）として含むビデオストリームを生成する。この場合、ビデオエンコーダ１１４-1，１１４-2は非動作状態におかれる。
ビデオエンコーダ１１４-1は、ビデオストリームのレイヤに、上述したビュー構成情報を挿入する。このビュー構成情報には、上述したように、当該ビデオストリームに含まれる画像データが３Ｄを構成する一部のビューの画像データであるか否かを示す情報が含まれている。ここでは、この情報は、当該ビデオストリームに含まれる画像データが３Ｄを構成する一部のビューの画像データでないことを示すものとされる。そのため、このビュー構成情報には、その他の情報は含まれないことになる。なお、この２次元（２Ｄ）画像送信時には、ビデオストリームのレイヤに、上述したビュー構成情報を挿入しないことも考えられる。
詳細説明は省略するが、グラフィクスデータ出力部１１８、グラフィクスエンコーダ１１９、音声データ出力部１２０およびオーディオデコーダ１２１に関しては、立体（３Ｄ）画像送信時の場合と同様である。また、視差データ生成部１１６および視差エンコーダ１１７も、非動作状態におかれる。
マルチプレクサ１１５は、ビデオエンコーダ１１４-1、グラフィクスエンコーダ１１９およびオーディオエンコーダ１２１で生成された各エレメンタリストリームをパケット化して多重し、トランスポートストリームＴＳを生成する。この場合、それぞれのＰＥＳ(Packetized Elementary Stream)のヘッダには、受信側における同期再生のために、ＰＴＳ（Presentation Time Stamp）が挿入される。
図７に示す送信データ生成部１１０の動作を簡単に説明する。最初に、立体（３Ｄ）画像送信時の動作を説明する。Ｎ個の画像データ出力部１１１-1〜１１１-Nから出力される立体画像表示のためのＮ個のビュー（View 1・・・View N）の画像データは、ビューセレクタ１１２に供給される。ビューセレクタ１１２では、Ｎ個のビューの画像データから、中央のビューの画像データＶＣ、左端のビューの画像データＶＬおよび右端のビューの画像データＶＲが取り出される。
ビューセレクタ１１２で取り出された中央のビューの画像データＶＣはスケーラ１１３-1に供給され、例えば、１９２０＊１０８０のフルＨＤのサイズにスケーリング処理される。スケーリング処理後の画像データＶＣ′は、ビデオエンコーダ１１４-1に供給される。
ビデオエンコーダ１１４-1では、この画像データＶＣ′に対して符号化が施されて符号化ビデオデータが得られ、この符号化データをサブストリーム（sub stream 1）として含むビデオストリームが生成される。また、このビデオエンコーダ１１４-1では、ビデオストリームのピクチャヘッダまたはシーケンスヘッダのユーザデータ領域などに、ビュー構成情報が挿入される。このビデオストリームは、マルチプレクサ１１５に供給される。
また、ビューセレクタ１１２で取り出された左端のビューの画像データＶＬはスケーラ１１３-2に供給され、例えば、１９２０＊１０８０のフルＨＤのサイズにスケーリング処理される。スケーリング処理後の画像データＶＬ′は、ビデオエンコーダ１１４-2に供給される。
ビデオエンコーダ１１４-2では、この画像データＶＬ′に対して符号化が施されて符号化ビデオデータが得られ、この符号化データをサブストリーム（sub stream 2）として含むビデオストリームが生成される。また、このビデオエンコーダ１１４-2では、ビデオストリームのピクチャヘッダまたはシーケンスヘッダのユーザデータ領域などに、ビュー構成情報が挿入される。このビデオストリームは、マルチプレクサ１１５に供給される。
さらに、ビューセレクタ１１２で取り出された右端のビューの画像データＶＲはスケーラ１１３-3に供給され、例えば、１９２０＊１０８０のフルＨＤのサイズにスケーリング処理される。スケーリング処理後の画像データＶＲ′は、ビデオエンコーダ１１４-3に供給される。
ビデオエンコーダ１１４-3では、この画像データＶＲ′に対して符号化が施されて符号化ビデオデータが得られ、この符号化データをサブストリーム（sub stream 3）として含むビデオストリームが生成される。また、このビデオエンコーダ１１４-3では、ビデオストリームのピクチャヘッダまたはシーケンスヘッダのユーザデータ領域などに、ビュー構成情報が挿入される。このビデオストリームは、マルチプレクサ１１５に供給される。
また、ビューセレクタ１１２から出力される中央、左端および右端の各ビューの画像データは視差データ生成部１１６に供給される。この視差データ生成部１１６では、各ビューの画像データに基づいて、視差データ（disparity data）が生成される。この視差データには、中央のビューおよび左端のビューの間の視差データと、中央のビューおよび右端のビューの間の視差データが含まれる。この場合、画素単位、あるいはブロック（Block）単位で、視差データが生成される。
視差データ生成部１１６で生成された視差データは、視差エンコーダ１１７に供給される。この視差エンコーダ１１７では、視差データに符号化処理が施されて、視差ストリームが生成される。この視差ストリームは、マルチプレクサ１１５に供給される。
また、グラフィクスデータ出力部１１８から出力されるグラフィクスデータ（サブタイトルデータも含む）は、グラフィクスエンコーダ１１９に供給される。このグラフィクスエンコーダ１１９では、グラフィクスデータを含むグラフィクスストリームが生成される。このグラフィクスストリームは、マルチプレクサ１１５に供給される。
また、音声データ出力部１１８から出力される音声データは、オーディオエンコーダ１２１に供給される。このオーディオエンコーダ１２１では、音声データに対して、ＭＰＥＧ−２Ａｕｄｉｏ、ＡＡＣ等の符号化が施され、オーディオストリームが生成される。このオーディオストリームは、マルチプレクサ１１５に供給される。
マルチプレクサ１１５では、各エンコーダから供給されるエレメンタリストリームがパケット化されて多重され、トランスポートストリームＴＳが生成される。この場合、それぞれのＰＥＳヘッダには、受信側における同期再生のために、ＰＴＳが挿入される。また、マルチプレクサ１１５では、ＰＭＴの配下、あるいはＥＩＴの配下などに、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを識別するための識別情報が挿入される。
なお、図７に示す送信データ生成部１１０は、トランスポートストリームＴＳに３つのビデオストリームが含まれる場合を示している。すなわち、トランスポートストリームＴＳには、中央、左端および右端の各ビューの画像データがそれぞれ１つのピクチャとして符号化されて得られた３つのビデオストリームが含まれる。
詳細説明は省略するが、上述したように、トランスポートストリームＴＳに２つ、あるいは１つのビデオストリームが含まれる場合も、同様に構成できる。トランスポートストリームＴＳに２つのビデオストリームが含まれる場合には、例えば、以下のビデオストリームが含まれる。すなわち、中央のビューの画像データが１つのピクチャとして符号化されて得られたビデオストリームと、左端のビューおよび右端のビューの画像データがインターリーブ処理されて１つのピクチャとして符号化されて得られたビデオストリームが含まれる。
また、トランスポートストリームＴＳに１つのビデオストリームが含まれる場合には、例えば、以下のビデオストリームが含まれる。すなわち、中央、左端および右端の各ビューの画像データがそれぞれ１つのピクチャのデータとして符号化されたデータを含むビデオストリームが含まれる。
次に、２次元（２Ｄ）画像送信時の動作を説明する。画像データ出力部１１１-1〜１１１-Nのいずれかから２次元画像データが出力される。ビュータセレクタ１１２では、その２次元画像データが取り出されて、スケーラ１１３-1に供給される。スケーラ１１３-1では、ビューセレクタ１１２で取り出された２次元画像データに対してスケーリング処理が施されて、例えば、１９２０＊１０８０のフルＨＤのサイズの２次元画像データが得られる。スケーリング後の２次元画像データは、ビデオエンコーダ１１４-1に供給される。
ビデオエンコーダ１１4-1では、２次元画像データに対して、例えば、ＭＰＥＧ４−ＡＶＣ（ＭＶＣ）、ＭＰＥＧ２ｖｉｄｅｏなどの符号化が施されて、符号化ビデオデータが得られる。そして、このビデオエンコーダ１１４-1では、後段に備えるストリームフォーマッタ（図示せず）により、この符号化データをサブストリーム（sub stream 1）として含むビデオストリームが生成される。
ビデオエンコーダ１１４-1では、ビデオストリームのレイヤに、上述したビュー構成情報が挿入される。このビュー構成情報には、上述したように、当該ビデオストリームに含まれる画像データが３Ｄを構成する一部のビューの画像データであるか否かを示す情報が含まれている。ここでは、この情報は、当該ビデオストリームに含まれる画像データが３Ｄを構成する一部のビューの画像データでないこと、つまり２次元画像データを示すものとされる。マルチプレクサ１１５では、ビデオエンコーダ１１４-1、グラフィクスエンコーダ１１９およびオーディオエンコーダ１２１で生成された各エレメンタリストリームがパケット化されて多重され、トランスポートストリームＴＳが生成される。
［識別情報およびビュー構成情報の構造と、ＴＳ構成］
上述したように、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを識別するための識別情報が、トランスポートストリームＴＳのレイヤに挿入される。図１２は、この識別情報としてのマルチビュー・ストリーム・コンフィグレーション・デスクリプタ（multiview_stream_configuration_descriptor）の構造例（Syntax）を示している。また、図１３は、図１２に示す構造例における主要な情報の内容（Semantics）を示している。
「multiview_stream_configuration_tag」は、デスクリプタタイプを示す８ビットのデータであり、ここでは、マルチビュー・ストリーム・コンフィグレーション・デスクリプタであることを示す。「multiview_stream_configuration_length」は、デスクリプタの長さ（サイズ）を示す８ビットのデータである。このデータは、デスクリプタの長さとして、以降のバイト数を示す。
「multiview_stream_checkflag」の１ビットフィールドは、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを示す。“１”は、ビデオストリームのレイヤにビュー構成情報の挿入があることを示し、“０”はその挿入がないことを示す。“１”であるとき、受信側（デコーダ）では、ユーザデータ領域に存在するビュー構成情報をチェックすることとなる。
また、上述したように、当該ビデオストリームに含まれる画像データが３Ｄを構成する一部のビューの画像データであるか否かを示す情報などを持つビュー構成情報が、ビデオストリームのレイヤに挿入される。このビュー構成情報は、上述したように、立体（３Ｄ）画像送信時には必ず挿入されるが、２次元（２Ｄ）画像送信時には挿入されないこともある。図１４は、このビュー構成情報としてのマルチビュー・ストリーム・コンフィグレーション・インフォ（multiview_stream_configuration_info()）の構造例（Syntax）を示している。また、図１５、図１６、図１７は、図１４に示す構造例における主要な情報の内容（Semantics）を示している。
「3D_flag」の１ビットフィールドは、符号化されるビデオストリームに含まれる画像データが３Ｄを構成する一部のビューの画像データであるか否かを示す。“１”は一部のビューの画像データであることを示し、“０”は一部を示す画像データでないことを示す。
「3D_flag=1」であるとき、「view_count」、「single_view_es_flag」、「view_interleaving_flag」の各情報が存在する。「view_count」の４ビットフィールドは、３Ｄサービスを構成するビュー数を示す。最小値は１で、最大値は１５である。「single_view_es_flag 」の１ビットフィールドは、当該ビデオストリームの１アクセスユニット内に複数のピクチャのデータが符号化されているか否かを示す。“１”は１つのピクチャのデータのみが符号化されていることを示し、“０”は２つ以上のピクチャのデータが符号化されていることを示す。
「view_interleaving_flag」の１ビットフィールドは、当該ビデオストリームにおいて、２つのビューの画像データがインターリーブ処理されて１つのピクチャのデータとして符号化されているか否かを示す。“１”はインターリーブ処理されていて画面スプリットの構成であることを示し、“０”はインターリーブ処理されていないことを示す。
「view_interleaving_flag= 0」であるとき、「view_allocation」の情報が存在する。「view_allocation」の４ビットフィールドは、当該ビデオストリームに含まれる画像データがどのビューの画像データであるか、つまりビュー割り当てを示す。例えば、“0000”は、中央のビュー（center view）であることを示す。また、例えば、“0001”は、中央から左側に１つ隣りのビュー(1st left view next tocenter)であることを示す。また、例えば、“0010”は、中央から右側に１つ隣りのビュー(1st right view next to center)であることを示す。この「view_allocation」は、各ビューの相対位置関係を示す情報を構成している。
「view_interleaving_flag= 1」であるとき、「view_pair_position_id」、「view_interleaving_type」の情報が存在する。「view_pair_position_id」の３ビットフィールドは、全ビューにおける２つのビューの相対的なビュー位置を示す。この場合、例えば、スキャン順で早い位置が左（left）、遅い位置が右（right）とする。例えば、“000”は、両端の２つのビューペアであることを示す。また、例えば、“001”は、両端から１つ内側の２つのビューペアであることを示す。また、例えば、“010”は、両端から１つ内側の２つのビューペアであることを示す。
「view_interleaving_type」の１ビットフィールドは、インターリーブのタイプ（type）を示している。“１”はインターリーブのタイプがサイド・バイ・サイド（Side-by-Side）であることを示し、“０”はインターリーブのタイプがトップ・アンド・ボトム（Top & Bottom）であることを示す。
また、「3D_flag= 1」であるとき、「display_flag」、「indication_of_picture_size_scaling_horizontal」、「indication_of_picture_size_scaling_vertical」の各情報が存在する。「display_flag」の１ビットフィールドは、当該ビューは画像表示を行わせる際に表示必須か否かを示す。“１”は、表示必須であることを示す。一方、“０”は、表示必須でないことを示す。
「indication_of_picture_size_scaling_horizontal 」の４ビットフィールドは、フルＨＤ（１９２０）に対してのデコード画の水平画素比率を示している。“0000”は１００％、“0001”は８０％、“0010”は７５％、“0011”は６６％、“0100”は５０％、“0101”は３３％、“0110”は２５％、“0111”は２０％をそれぞれ示す。
「indication_of_picture_size_scaling_vertical 」の４ビットフィールドは、フルＨＤ（１０８０）に対してのデコード画の垂直画素比率を示している。0000”は１００％、“0001”は８０％、“0010”は７５％、“0011”は６６％、“0100”は５０％、“0101”は３３％、“0110”は２５％、“0111”は２０％をそれぞれ示す。
図１８は、「view_count」が示すビュー数と、「view_pair_position_id」が示す２つのビュー（ここでは、“View 1”, “View 2”としている）の位置との関係の一例を示している。（１）の例は、「view_count」が示すビュー数が２であって、「view_pair_position_id= 000」であって両端の２つのビューであることを示している場合である。また、（２）の例は、「view_count」が示すビュー数が４であって、「view_pair_position_id = 000」であって両端の２つのビューであることを示している場合である。
また、（３）の例は、「view_count」が示すビュー数が４であって、「view_pair_position_id= 001」であって両端から１つ内側の２つのビューであることを示している場合である。また、（４）の例は、「view_count」が示すビュー数が５であって、「view_pair_position_id = 000」であって両端の２つのビューであることを示している場合である。
また、（５）の例は、「view_count」が示すビュー数が９であって、「view_pair_position_id= 000」であって両端の２つのビューであることを示している場合である。さらに、（６）の例は、「view_count」が示すビュー数が９であって、「view_pair_position_id = 010」であって両端から２つ内側の２つのビューであることを示している場合である。
両端よりも内側のビューペアは、受信側でビュー合成を行う際に両端の２つのビューでは十分に画質が満足できないような場合に、補間合成の性能を向上させるために、両端のビューペアに追加で伝送されることが可能である。その際、追加で伝送されるビューペアの符号化ビデオデータは、両端のビューペアのストリームの中に、アクセスユニット（Access Unit）を共有するように符号化されてもよいし、あるいは、別のストリームとして符号化されてもよい。
図１９は、上述のように両端の２つのビューペアの画像データと共に、両端よりも内側の２つのビューペアの画像データを送信する場合において、送信側あるいは受信側における視差データ（disparity data）の生成例を示している。図示の例では、view_count」が示すビュー数が９とされている。そして、両端の２つのビュー（View 1, View 2）の画像データが含まれるサブストリーム（substream1）と、それよりも内側の２つのビュー（View 3, View 4）の画像データが含まれるサブストリーム（substream 2）とが存在するものとしている。
この場合、最初に、「View 1」と「View 3」とで視差データを計算する。次に、「View 2」と「View 4」とで視差データを計算する。最後に、「View 3」と「View 4」とで視差データを計算する。なお、サブストリーム間で、ビューの解像度が異なる場合は、どちらかの解像度に合わせた上で、視差データの計算を行う。
図２０は、上述したように計算された視差データに基づき、受信側で、各ビューの間に位置するビューの画像データを補間合成する例を示している。この場合、最初に、「View 1」と「View 3」との間の視差データを用いて、「View 1」と「View 3」の間に位置する「View_A」を補間合成する。
次に、「View 2」と「View 4」との間の視差データを用いて、「View 2」と「View 4」の間に位置する「View_B」を補間合成する。最後に、「View 3」と「View 4」との間の視差データを用いて、「View 3」と「View 4」の間に位置する「View_C」、「View_D」、「View_Ｅ」を補間合成する。
次に、ビュー構成情報としてのマルチビュー・ストリーム・コンフィグレーション・インフォ（multiview_stream_configuration_info()）を、ビデオストリーム（ビデオエレメンタリストリーム）のユーザデータ領域に挿入する場合について説明する。この場合、マルチビュー・ストリーム・コンフィグレーション・インフォは、ユーザデータ領域を利用して、例えば、ピクチャ単位あるいはＧＯＰ単位で挿入される。
例えば、符号化方式がＡＶＣあるいはＭＶＣである場合、または、ＨＥＶＣのような、ＮＡＬパケットなどの符号化構造が似通っている符号化方式である場合にも、マルチビュー・ストリーム・コンフィグレーション・インフォは、アクセスユニットの“ＳＥＩｓ”の部分に、「Multiview stream configuration SEI message」として、挿入される。図２１（ａ）は、ＧＯＰ（Group Of Pictures）の先頭のアクセスユニットを示しており、図２１（ｂ）は、ＧＯＰの先頭以外のアクセスユニットを示している。マルチビュー・ストリーム・コンフィグレーション・インフォがＧＯＰ単位で挿入される場合、ＧＯＰの先頭のアクセスユニットにのみ「Multiview stream configuration SEI message」が挿入される。
図２２（ａ）は、「Multiview stream configuration SEI message」の構造例(Syntax)を示している。「uuid_iso_iec_11578」は、“ISO/IEC 11578:1996 AnnexA.”で示されるUUID値をもつ。「user_data_payload_byte」のフィールドに、「userdata_for_multiview_stream_configuration()」が挿入される。図２２（ｂ）は、「userdata_for_multiview_stream _configuration()」の構造例(Syntax)を示している。この中に、マルチビュー・ストリーム・コンフィグレーション・インフォ（multiview_stream_configuration_info()）が挿入される（図１４参照）。「userdata_id」は、符号なし１６ビットで示されるマルチビュー・ストリーム・コンフィグレーション・インフォの識別子である。
また、例えば、符号化方式がＭＰＥＧ２ ｖｉｄｅｏである場合、マルチビュー・ストリーム・コンフィグレーション・インフォは、ピクチャヘッダ部のユーザデータ領域に、ユーザデータ「user_data()」として挿入される。図２３（ａ）は、「user_data()」の構造例(Syntax)を示している。「user_data_start_code」の３２ビットフィールドは、ユーザデータ（user_data）の開始コードであり、“0x000001B2”の固定値とされる。
この開始コードに続く３２ビットフィールドは、ユーザデータの内容を識別する識別子である。ここでは、「Stereo_Video_Format_Signaling_identifier」とされ、ユーザデータが、マルチビュー・ストリーム・コンフィグレーション・インフォであることを識別可能とする。この識別子の後のデータ本体として、ストリーム関連付け情報としての「Multiview_stream_configuration()」が挿入される。図２３（ｂ）は、Multiview_stream_configuration()」の構造例(Syntax)を示している。この中に、マルチビュー・ストリーム・コンフィグレーション・インフォ（multiview_stream_configuration_info()）が挿入される（図１４参照）。
上述の図１２に示す識別情報としてのマルチビュー・ストリーム・コンフィグレーション・デスクリプタ（multiview_stream_configuration_descriptor）は、トランスポートストリームＴＳのレイヤ、例えばＰＭＴの配下、あるいはＥＩＴの配下などに挿入される。すなわち、このデスクリプタは、イベント単位あるいは時間的に静的ないし動的なユースケースに置いて最適な位置に配置される。
図２４は、立体（３Ｄ）画像送信時におけるトランスポートストリームＴＳの構成例を示している。なお、この構成例では、図面の簡単化のために、視差データ、オーディオ、およびグラフィクスなどに関しては、その図示を省略している。この構成例は、トランスポートストリームＴＳに３つのビデオストリームが含まれる場合を示している。すなわち、トランスポートストリームＴＳには、中央、左端および右端の各ビューの画像データがそれぞれ１つのピクチャとして符号化されて得られた３つのビデオストリームが含まれている。また、この構成例は、ビュー数が５である場合を示している。
この図２４の構成例では、中央ビューの画像データＶＣ′が１つのピクチャとして符号化されているビデオストリームのＰＥＳパケット「video PES1」が含まれている。このビデオストリームのユーザデータ領域に挿入されるマルチビュー・ストリーム・コンフィグレーション・インフォにおいては、「View_count」が示すビュー数が５であることが示されている。
また、このインフォにおいては、「single_view_es_flag = 1」とされ、このビデオストリームにおいて、１アクセスユニット内に１つのピクチャのデータのみが符号化されていることが示されている。また、このインフォにおいては、「View_interleaving_flag= 0」とされ、このビデオストリームにおいて、２つのビューの画像データがインターリーブ処理されて１つのピクチャのデータとして符号化されていないことが示されている。さらに、「view_allocation = 0000」とされ、このビデオストリームに含まれる画像データが中央のビューの画像データであることが示されている。
また、この図２４の構成例では、左端ビューの画像データＶＬ′が１つのピクチャとして符号化されているビデオストリームのＰＥＳパケット「video PES2」が含まれている。このビデオストリームのユーザデータ領域に挿入されるマルチビュー・ストリーム・コンフィグレーション・インフォにおいては、「View_count」が示すビュー数が５であることが示されている。
また、このインフォにおいては、「single_view_es_flag = 1」とされ、このビデオストリームにおいて、１アクセスユニット内に１つのピクチャのデータのみが符号化されていることが示されている。また、このインフォにおいては、「View_interleaving_flag= 0」とされ、このビデオストリームにおいて、２つのビューの画像データがインターリーブ処理されて１つのピクチャのデータとして符号化されていないことが示されている。さらに、「view_allocation = 0011」とされ、このビデオストリームに含まれる画像データが中央から左側に２つ隣りのビュー、つまり左端ビューの画像データであることが示されている。
また、この図２４の構成例では、左端ビューの画像データＶＲ′が１つのピクチャとして符号化されているビデオストリームのＰＥＳパケット「video PES3」が含まれている。このビデオストリームのユーザデータ領域に挿入されるマルチビュー・ストリーム・コンフィグレーション・インフォにおいては、「View_count」が示すビュー数が５であることが示されている。
また、このインフォにおいては、「single_view_es_flag = 1」とされ、このビデオストリームにおいて、１アクセスユニット内に１つのピクチャのデータのみが符号化されていることが示されている。また、このインフォにおいては、「View_interleaving_flag= 0」とされ、このビデオストリームにおいて、２つのビューの画像データがインターリーブ処理されて１つのピクチャのデータとして符号化されていないことが示されている。さらに、「view_allocation = 0100」とされ、このビデオストリームに含まれる画像データが中央から右側に２つ隣りのビュー、つまり右端ビューの画像データであることが示されている。
また、トランスポートストリームＴＳには、ＰＳＩ（Program Specific Information）として、ＰＭＴ（ProgramMap Table）が含まれている。このＰＳＩは、トランスポートストリームに含まれる各エレメンタリストリームがどのプログラムに属しているかを記した情報である。また、トランスポートストリームには、イベント単位の管理を行うＳＩ（Serviced Information）としてのＥＩＴ(EventInformation Table)が含まれている。
ＰＭＴには、各エレメンタリストリームに関連した情報を持つエレメンタリ・ループが存在する。この構成例では、ビデオエレメンタリ・ループ（Video ES loop）が存在する。このエレメンタリ・ループには、ストリーム毎に、パケット識別子（PID）等の情報が配置されると共に、そのエレメンタリストリームに関連する情報を記述するデスクリプタも配置される。
この構成例では、ＰＭＴのビデオエレメンタリ・ループ（Video ES loop）の配下に、各ビデオストリームに関連して、マルチビュー・ストリーム・コンフィグレーション・デスクリプタ（multiview_stream_configuration_descriptor）が挿入されている。このデスクリプタで「multiview_stream_checkflag = 1」とされ、ビデオストリームのユーザ領域におけるビュー構成情報としてのマルチビュー・ストリーム・コンフィグレーション・インフォの存在が示されている。なお、このデスクリプタを、破線図示するように、ＥＩＴの配下に挿入することも考えられる。
また、図２５も、立体（３Ｄ）画像送信時におけるトランスポートストリームＴＳの構成例を示している。なお、この構成例でも、図面の簡単化のために、視差データ、オーディオ、およびグラフィクスなどに関しては、その図示を省略している。この構成例は、トランスポートストリームＴＳに２つのビデオストリームが含まれる場合を示している。すなわち、トランスポートストリームＴＳには、中央のビューの画像データが１つのピクチャとして符号化されて得られたビデオストリームとが含まれている。また、このトランスポートストリームＴＳには、左端のビューおよび右端のビューの画像データがインターリーブ処理されて１つのピクチャとして符号化されて得られたビデオストリームが含まれている。また、この構成例も、ビュー数が５である場合を示している。
この図２５の構成例では、中央ビューの画像データＶＣ′が１つのピクチャとして符号化されているビデオストリームのＰＥＳパケット「video PES1」が含まれている。このビデオストリームのユーザデータ領域に挿入されるマルチビュー・ストリーム・コンフィグレーション・インフォにおいては、「View_count」が示すビュー数が５であることが示されている。
また、このインフォにおいては、「single_view_es_flag = 1」とされ、このビデオストリームにおいて、１アクセスユニット内に１つのピクチャのデータのみが符号化されていることが示されている。また、このインフォにおいては、「View_interleaving_flag= 0」とされ、このビデオストリームにおいて、２つのビューの画像データがインターリーブ処理されて１つのピクチャのデータとして符号化されているものではないことが示されている。さらに、「view_allocation = 0000」とされ、このビデオストリームに含まれる画像データが中央のビューの画像データであることが示されている。
また、この図２５の構成例では、左端ビューの画像データＶＬ′および右端ビューの画像データＶＲ′が１つのピクチャとして符号化されているビデオストリームのＰＥＳパケット「video PES2」が含まれている。このビデオストリームのユーザデータ領域に挿入されるマルチビュー・ストリーム・コンフィグレーション・インフォにおいては、「View_count」が示すビュー数が５であることが示されている。
また、このインフォにおいては、「single_view_es_flag = 1」とされ、このビデオストリームにおいて、１アクセスユニット内に１つのピクチャのデータのみが符号化されていることが示されている。また、このインフォにおいては、「View_interleaving_flag= 1」とされ、このビデオストリームにおいて、２つのビューの画像データがインターリーブ処理されて１つのピクチャのデータとして符号化されていることが示されている。さらに、「view_pair_position_id= 000」とされ、両端の２つのビューペアであることが示されている。さらに、「view_interleaving_type= 1」とされ、インターリーブのタイプがサイド・バイ・サイド（Side-by-Side）であることが示されている。
また、この構成例では、ＰＭＴのビデオエレメンタリ・ループ（Video ES loop）の配下に、各ビデオストリームに関連して、マルチビュー・ストリーム・コンフィグレーション・デスクリプタ（multiview_stream_configuration_descriptor）が挿入されている。このデスクリプタで「multiview_stream_checkflag = 1」とされ、ビデオストリームのユーザ領域におけるビュー構成情報としてのマルチビュー・ストリーム・コンフィグレーション・インフォの存在が示されている。なお、このデスクリプタを、破線図示するように、ＥＩＴの配下に挿入することも考えられる。
また、図２６も、立体（３Ｄ）画像送信時におけるトランスポートストリームＴＳの構成例を示している。なお、この構成例でも、図面の簡単化のために、視差データ、オーディオ、およびグラフィクスなどに関しては、その図示を省略している。この構成例は、トランスポートストリームＴＳに１つのビデオストリームが含まれる場合を示している。すなわち、トランスポートストリームＴＳには、中央、左端および右端の各ビューの画像データがそれぞれ１つのピクチャのデータとして符号化されたデータを含むビデオストリームが含まれている。また、この構成例も、ビュー数が５である場合を示している。
この図２６の構成例では、１つのビデオストリームのＰＥＳパケット「video PES1」が含まれている。このビデオストリームには、中央、左端および右端の各ビューの画像データがそれぞれ１アクセスユニット内に１つのピクチャのデータとして符号化されたデータが含まれており、各ピクチャに対応してユーザデータ領域が存在する。そして、それぞれに、マルチビュー・ストリーム・コンフィグレーション・インフォが挿入されている。
中央ビューの画像データが符号化されたピクチャデータに対応するインフォにおいては、「View_count」が示すビュー数が５であることが示されている。また、このインフォにおいては、「single_view_es_flag = 0」とされ、このビデオストリームにおいて、１アクセスユニット内に複数のピクチャのデータが符号化されていることが示されている。また、このインフォにおいては、「View_interleaving_flag= 0」とされ、このピクチャデータが２つのビューの画像データがインターリーブ処理されて符号化されたものでないことが示されている。さらに、「view_allocation = 0000」とされ、このピクチャデータに含まれる画像データが中央のビューの画像データであることが示されている。
また、左端ビューの画像データが符号化されたピクチャデータに対応するインフォにおいては、「View_count」が示すビュー数が５であることが示されている。また、このインフォにおいては、「single_view_es_flag = 0」とされ、このビデオストリームにおいて、１アクセスユニット内に複数のピクチャのデータが符号化されていることが示されている。また、このインフォにおいては、「View_interleaving_flag= 0」とされ、このピクチャデータが２つのビューの画像データがインターリーブ処理されて符号化されたものでないことが示されている。さらに、「view_allocation = 0011」とされ、このピクチャデータに含まれる画像データが中央から左側に２つ隣りのビュー、つまり左端ビューの画像データであることが示されている。
また、右端ビューの画像データが符号化されたピクチャデータに対応するインフォにおいては、「View_count」が示すビュー数が５であることが示されている。また、このインフォにおいては、「single_view_es_flag = 0」とされ、このビデオストリームにおいて、１アクセスユニット内に複数のピクチャのデータが符号化されていることが示されている。また、このインフォにおいては、「View_interleaving_flag= 0」とされ、このピクチャデータが２つのビューの画像データがインターリーブ処理されて符号化されたものでないことが示されている。さらに、「view_allocation = 0100」とされ、このピクチャデータに含まれる画像データが中央から右側に２つ隣りのビュー、つまり右端ビューの画像データであることが示されている。
また、この構成例では、ＰＭＴのビデオエレメンタリ・ループ（Video ES loop）の配下に、１つのビデオストリームに関連して、マルチビュー・ストリーム・コンフィグレーション・デスクリプタ（multiview_stream_configuration_descriptor）が挿入されている。このデスクリプタで「multiview_stream_checkflag = 1」とされ、ビデオストリームのユーザ領域におけるビュー構成情報としてのマルチビュー・ストリーム・コンフィグレーション・インフォの存在が示されている。なお、このデスクリプタを、破線図示するように、ＥＩＴの配下に挿入することも考えられる。
上述したように、図７に示す送信データ生成部１１０においては、立体（３Ｄ）画像送信時においては、立体画像表示のための複数のビューのうち、少なくとも左端のビューおよび右端のビューの画像データと、左端および右端の間に位置する中間のビューの画像データとが符号化されて得られたビデオストリームを含むトランスポートストリームＴＳが生成される。そのため、マルチビュー構成による立体画像の裸眼観賞を行うための画像データ伝送を効果的に行うことができる。
すなわち、左端のビューおよび右端のビューの画像データだけでなく、中間のビューの画像データも送信されるので、ビュー間の相対視差が小さく、その他のビューの画像データを補間する際の細かな部分の処理に伴うオクルージョン周辺の補間が容易になり、再生画像の品質向上を図ることができる。また、左端のビューおよび右端のビューの画像データが送信されるので、伝送されないビューの画像データの補間は全て内挿処理によって合成でき、オクルージョンなどの端点処理に関して高画質を維持することが容易となる。
また、図７に示す送信データ生成部１１０においては、立体（３Ｄ）画像送信時においては、必ず、ビデオストリームのレイヤに、ビュー構成情報としてのマルチビュー・ストリーム・コンフィグレーション・インフォ（multiview_stream_configuration_info()）が挿入される。そのため、受信側では、このビュー構成情報により、複数のビューの画像データによる３次元画像（立体画像）の裸眼観賞を行うための適切かつ効率的な処理が可能となる。
また、図７に示す送信データ生成部１１０においては、トランスポートストリームＴＳのレイヤに、マルチビュー・ストリーム・コンフィグレーション・デスクリプタ（multiview_stream_configuration_descriptor）が挿入される。このデスクリプタは、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを識別するための識別情報を構成している。この識別情報により、受信側では、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを容易に識別可能となる。そのため、ビデオストリームのユーザデータ領域からのビュー構成情報の効率的な抽出が可能となる。
また、図７に示す送信データ生成部１１０においては、視差データ生成部１１６で各ビュー間の視差データが生成され、この視差データが符号化されて得られた視差ストリームが、ビデオストリームと共に、トランスポートストリームＴＳに含まれる。そのため、受信側では、受信された各ビューの画像データから視差データを生成する処理を行うことなく、送られてくる視差データに基づいて、伝送されない各ビューの画像データを容易に補間合成することが可能となる。
「受信機の構成例」
図２７は、受信機２００の構成例を示している。この受信機２００は、ＣＰＵ２０１と、フラッシュＲＯＭ２０２と、ＤＲＡＭ２０３と、内部バス２０４と、リモートコントロール受信部（ＲＣ受信部）２０５と、リモートコントロール送信機（ＲＣ送信機）２０６を有している。また、この受信機２００は、アンテナ端子２１１と、デジタルチューナ２１２と、トランスポートストリームバッファ（ＴＳバッファ）２１３と、デマルチプレクサ２１４を有している。
また、受信機２００は、コーデッドバッファ２１５-1，２１５-2，２１５-3と、ビデオデコーダ２１6-1，２１６-2，２１６-3と、デコーデッドバッファ２１７-1，２１７-2，２１７-3と、スケーラ２１８-1，２１８-2，２１８-3を有している。また、受信機２００は、ビュー補間部２１９と、ピクセルインターリーブ／重畳部２２０を有している。また、受信機２００は、コーデッドバッファ２２１と、視差デコーダ２２２と、視差バッファ２２３と、視差データ変換部２２４を有している。
また、受信機２００は、コーデッドバッファ２２５と、グラフィクスデコーダ２２６と、ピクセルバッファ２２７と、スケーラ２２８と、グラフィクスシフタ２２９を有している。さらに、受信機２００は、コーデッドバッファ２３０と、オーディオデコーダ２３１と、チャネルミキシング部２３２を有している。
ＣＰＵ２０１は、受信機２００の各部の動作を制御する。フラッシュＲＯＭ２０２は、制御ソフトウェアの格納およびデータの保管を行う。ＤＲＡＭ２０３は、ＣＰＵ２０１のワークエリアを構成する。ＣＰＵ２０１は、フラッシュＲＯＭ２０２から読み出したソフトウェアやデータをＤＲＡＭ２０３上に展開してソフトウェアを起動させ、受信機２００の各部を制御する。ＲＣ受信部２０５は、ＲＣ送信機２０６から送信されたリモーコントロール信号（リモコンコード）を受信し、ＣＰＵ２０１に供給する。ＣＰＵ２０１は、このリモコンコードに基づいて、受信機２００の各部を制御する。ＣＰＵ２０１、フラッシュＲＯＭ２０２およびＤＲＡＭ２０３は、内部バス２０４に接続されている。
以下、最初に、立体（３Ｄ）画像受信時の場合について説明する。アンテナ端子２１１は、受信アンテナ（図示せず）で受信されたテレビ放送信号を入力する端子である。デジタルチューナ２１２は、アンテナ端子２１１に入力されたテレビ放送信号を処理して、ユーザの選択チャネルに対応した所定のトランスポートストリーム（ビットストリームデータ）ＴＳを出力する。トランスポートストリームバッファ（ＴＳバッファ）２１３は、デジタルチューナ２１２から出力されたトランスポートストリームＴＳを一時的に蓄積する。
このトランスポートストリームＴＳに、立体画像表示のための複数のビューのうち、左端のビューおよび右端のビューの画像データと、左端および右端の間に位置する中間のビューとしての中央のビューの画像データとが符号化されて得られたビデオストリームが含まれている。
この場合、トランスポートストリームＴＳに、３つ、２つ、あるいは１つのビデオストリームが含まれる場合等がある（図２４、図２５、図２６参照）。ここでは、説明を簡単にするために、トランスポートストリームＴＳに、中央、左端および右端の各ビューの画像データがそれぞれ１つのピクチャとして符号化されて得られた３つのビデオストリームが含まれるものとして説明を行うものとする。
このトランスポートストリームＴＳには、上述したように、ＰＭＴの配下、あるいはＥＩＴの配下などに、マルチビュー・ストリーム・コンフィグレーション・デスクリプタ（multiview_stream_configuration_descriptor）が挿入されている。このデスクリプタは、ビデオストリームのレイヤにビュー構成情報、つまりマルチビュー・ストリーム・コンフィグレーション・インフォ（multiview_stream_configuration_info()）の挿入があるか否かを識別するための識別情報である。
デマルチプレクサ２１４は、ＴＳバッファ２１３に一時的に蓄積されたトランスポートストリームＴＳから、ビデオ、視差、グラフィクスおよびオーディオの各エレメンタリストリームを抽出する。また、デマルチプレクサ２１４は、このトランスポートストリームＴＳから、上述したマルチビュー・ストリーム・コンフィグレーション・デスクリプタを抽出し、ＣＰＵ２０１に送る。ＣＰＵ２０１は、このデスクリプタの「multiview_stream_checkflag」の１ビットフィールドにより、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを容易に判断できる。
コーデッドバッファ２１５-1，２１５-2，２１５-3は、それぞれ、デマルチプレクサ２１４で抽出される中央、左端および右端の各ビューの画像データがそれぞれ１つのピクチャとして符号化されて得られたビデオストリームを一時的に蓄積する。ビデオデコーダ２１６-1，２１６-2，２１６-3は、ＣＰＵ２０１の制御のもと、それぞれ、コーデッドバッファ２１５-1，２１５-2，２１５-3に記憶されているビデオストリームの復号化処理を行って、中央、左端および右端の各ビューの画像データを取得する。
ここで、ビデオデコーダ２１６-1は、圧縮データバッファを使用した復号化処理を行って中央ビュー（center view）の画像データを取得する。また、ビデオデコーダ２１６-2は、圧縮データバッファを使用した復号化処理を行って左端ビュー（left view）の画像データを取得する。さらに、ビデオデコーダ２１６-3は、圧縮データバッファを使用した復号化処理を行って右端ビュー（right view）の画像データを取得する。なお、２つ以上のビューがインターリーブされて符号化されている場合は、ストリーム単位で、コーデッドバッファ、ビデオデコーダ、デコーデッドバッファ、スケ―ラが割り当てられることになる。
各ビデオデコーダは、ビデオストリームのピクチャヘッダまたはシーケンスヘッダのユーザデータ領域などに挿入されているビュー構成情報としてのマルチビュー・ストリーム・コンフィグレーション・インフォ（multiview_stream_configuration_info()）を抽出し、ＣＰＵ２０１に送る。ＣＰＵ２０１は、このビュー構成情報により、複数のビューの画像データによる３次元画像（立体画像）の裸眼観賞を行うための適切かつ効率的な処理を行う。
すなわち、ＣＰＵ２０１は、このビュー構成情報に基づいて、番組単位、シーン単位、ピクチャグループ単位、あるいはピクチャ単位で、デマルチプレクサ２１４、ビデオデコーダ２１６-1，２１６-2，２１６-3、スケーラ２１８-1，２１８-2，２１８-3、ビュー補間部２１９等の動作を制御する。例えば、ＣＰＵ２０１は、「view_count」の４ビットフィールドにより、３Ｄサービスを構成するビュー数を認識できる。
また、例えば、ＣＰＵ２０１は、「single_view_es_flag 」の１ビットフィールドにより、ビデオストリームの１アクセスユニット内に複数のピクチャのデータが符号化されているか否かを識別できる。また、例えば、ＣＰＵ２０１は、「view_interleaving_flag」の１ビットフィールドにより、ビデオストリームにおいて、２つのビューの画像データがインターリーブ処理されて１つのピクチャのデータとして符号化されているか否かを識別できる。
また、例えば、ＣＰＵ２０１は、ビデオストリームにおいて、２つのビューの画像データがインターリーブ処理されて１つのピクチャのデータとして符号化されていないとき、「view_allocation」の４ビットフィールドにより、ビデオストリームに含まれる画像データがどのビューの画像データであるかを認識できる。
また、例えば、ＣＰＵ２０１は、ビデオストリームにおいて、２つのビューの画像データがインターリーブ処理されて１つのピクチャのデータとして符号化されているとき、「view_pair_position_id」の３ビットフィールドにより、全ビューにおける２つのビューの相対的なビュー位置を認識できる。さらに、このとき、ＣＰＵ２０１は、「view_interleaving_type」の１ビットフィールドにより、インターリーブのタイプ（type）を知ることができる。
また、例えば、ＣＰＵ２０１は、「indication_of_picture_size_scaling _horizontal 」の４ビットフィールドおよび「indication_of_picture_size_scaling _vertical 」の４ビットフィールドにより、フルＨＤに対してのデコード画の水平画素比率を認識できる。
デコーデッドバッファ２１７-1，２１７-2，２１７-3は、それぞれ、ビデオデコーダ２１６-1，２１６-2，２１６-3で取得された各ビューの画像データを一時的に蓄積する。スケーラ２１８-1，２１８-2，２１８-3は、それぞれ、デコーデッドバッファ２１７-1，２１７-2，２１７-3から出力される各ビューの画像データの出力解像度が、所定の解像度となるように調整する。
マルチビュー・ストリーム・コンフィグレーション・インフォには、デコード画の水平画素比率を示す「indication_of_picture_size_scaling _horizontal 」の４ビットフィールドおよびデコード画の垂直画素比率を示す「indication_of_picture_size_scaling _vertical 」の４ビットフィールドが存在する。ＣＰＵ２０１は、この画素比率情報に基づいて、スケーラ２１８-1，２１８-2，２１８-3におけるスケーリング比率を制御し、所定の解像度が得られるようにする。
この場合、ＣＰＵ２０１は、デコードした画像データの解像度、モニタの解像度およびビュー（view）の数に基づいて、デコーデッドバッファに蓄積されている画像データに対するスケーリング比を算出し、スケーラ２１８-1，２１８-2，２１８-3に指示を行う。図２８は、スケーリング比の算出例を示している。
例えば、デコードした画像データの解像度が９６０＊１０８０で、モニタ解像度が１９２０＊１０８０で、表示するビューの数が４である場合には、スケーリング比は１／２とされる。また、例えば、デコードした画像データの解像度が１９２０＊１０８０で、モニタ解像度が１９２０＊１０８０で、表示するビューの数が４である場合には、スケーリング比は１／４とされる。さらに、例えば、デコードした画像データの解像度が１９２０＊２１６０で、モニタ解像度が３８４０＊２１６０で、表示するビューの数が８である場合には、スケーリング比は１／４とされる。
コーデッドバッファ２２１は、デマルチプレクサ２１４で抽出される視差ストリームを一時的に蓄積する。視差デコーダ２２２は、上述の送信データ生成部１１０の視差エンコーダ１１７（図７参照）とは逆の処理を行う。すなわち、視差デコーダ２２３は、コーデッドバッファ２２１に記憶されている視差ストリームの復号化処理を行って、視差データを得る。この視差データには、中央ビューと左端ビューとの間の視差データと、中央ビューと右端ビューとの間の視差データが含まれている。また、この視差データは、画素単位、あるいはブロック単位の視差データである。視差バッファ２２３は、視差デコーダ２２２で取得された視差データを一時的に蓄積する。
視差データ変換部２２４は、視差バッファ２２３に蓄積されている視差データに基づいて、スケーリング後の画像データのサイズに合った画素単位の視差データを生成する。例えば、送信されてくる視差データがブロック単位である場合には、画素単位の視差データに変換する（図１１参照）。また、例えば、送信されてくる視差データが画素単位であるが、スケーリング後の画像データのサイズに合っていない場合には、適宜、スケーリングされる。
ビュー補間部２１９は、スケーリング後の中央、左端および右端の各ビューの画像データから、視差データ変換部２２４で得られた各ビュー間の視差データに基づいて、伝送されてこない所定数のビューの画像データを補間合成する。すなわち、ビュー補間部２１９は、中央ビューと左端ビューとの間に位置する各ビューの画像データを補間合成して出力する。また、ビュー補間部２１９は、中央ビューと右端ビューとの間に位置する各ビューの画像データを補間合成して出力する。
図２９は、ビュー補間部２１９における補間合成処理の一例を概略的に示している。図示の例において、例えば、カレントビュー（Current view）は上述の中央ビューに相当し、ターゲットビュー１（Targetview 1）は上述の左端ビューに相当し、ターゲットビュー２（Target view 2）は上述の右端ビューに相当する。
カレントビューとターゲットビュー１との間に位置するビューの補間合成と、カレントビューとターゲットビュー２との間に位置するビューの補間合成とは、同様に行われる。以下では、カレントビューとターゲットビュー１との間に位置するビューの補間合成について説明する。
カレントビューとターゲットビュー１との間に位置する補間合成するビューの画素は、以下のように割り当てられる。この場合、カレントビューからターゲットビュー１を指し示す視差データと、逆に、ターゲットビュー１からカレントビューを指し示す視差データとの、２方向の視差データが用いられる。まず、補間合成するビューの画素として、カレントビューの画素を、視差データをベクターとしてずらすことで、割り当てる（カレントビューからターゲットビュー１に向いた実線矢印および破線矢印と、黒丸を参照）。
この際に、ターゲットビュー１においてターゲット・オクルーデッド（target occluded）となる部分では、以下の画素割り当てを行う。すなわち、補間合成するビューの画素として、ターゲットビュー１の画素を、視差データをベクターとしてずらすことで、割り当てる（ターゲットビュー１からカレントビューに向いた一点鎖線矢印と、白丸を参照）。
このように、ターゲット・オクルーデッドとなる部分では、双方向の視差データを持つことで、補間合成されるビューの画素を、バックグランド（background）と見なせるビューからの画素で充当できる。なお、双方向で対応できないオクルージョン（Occlusion）領域は、ポスト（Post）処理で値を充当する。
また、図示の矢印の先端が重なっているターゲット・オーバーラップド（target overlapped）となる部分は、ターゲットビュー１において、視差（disparity）によるシフトが重なる部分である。この部分においては、２つの視差のうち、どちらがカレントビューのフォグランド（fore ground）に相当するかを、視差データの値で判断し、選択する。この場合には、主には値の小さな方が選択される。
図２７に戻って、コーデッドバッファ２２５は、デマルチプレクサ２１４で抽出されるグラフィクスストリームを一時的に蓄積する。グラフィクスデコーダ２２６は、上述の送信データ生成部１１０のグラフィクスエンコーダ１１９（図７参照）とは逆の処理を行う。すなわち、グラフィクスデコーダ２２６は、コーデッドバッファ２２５に記憶されているグラフィクスストリームの復号化処理を行って、復号化されたグラフィクスデータ（サブタイトルデータを含む）を得る。また、グラフィクスデコーダ２２６は、このグラフィクスデータに基づいて、ビュー（画像）に重畳するグラフィクスのビットマップデータを発生する。
ピクセルバッファ２２７は、グラフィクスデコーダ２２６で発生されるグラフィクスのビットマップデータを一時的に蓄積する。スケーラ２２８は、ピクセルバッファ２２７に蓄積されているグラフィクスのビットマップデータのサイズを、スケーリング後の画像データのサイズに対応するように調整する。グラフィクスシフタ２２９は、サイズ調整後のグラフィクスのビットマップデータに対して、視差データ変換部２２４で得られる視差データに基づいてシフト処理を施す。そして、グラフィクスシフタ２２９は、ビュー補間部２１９から出力されるＮ個のビュー（View1, View2,・・・,ViewN ）の画像データにそれぞれ重畳するＮ個のグラフィクスのビットマップデータを生成する。
ピクセルインターリーブ／重畳部２２０は、ビュー補間部２１９から出力されるＮ個のビュー（View1, View2,・・・,ViewN ）の画像データにそれぞれ対応するグラフィクスのビットマップデータを重畳する。さらに、ピクセルインターリーブ／重畳部２２０は、Ｎ個のビュー（View1, View2,・・・,ViewN ）の画像データに対してピクセルインターリーブ処理を行って、３次元画像（立体画像）の裸眼観賞のための表示用画像データを生成する。
コーデッドバッファ２３０は、デマルチプレクサ２１４で抽出されるオーディオストリームを一時的に蓄積する。オーディオデコーダ２３１は、上述の送信データ生成部１１０のオーディオエンコーダ１２１（図７参照）とは逆の処理を行う。すなわち、オーディオデコーダ２３１は、コーデッドバッファ２３０に記憶されているオーディオスストリームの復号化処理を行って、復号化された音声データを得る。チャネルミキシング部２３２は、オーディオデコーダ２３１で得られる音声データに対して、例えば５．１chサラウンド等を実現するための各チャネルの音声データを生成して出力する。
なお、デコーデッドバッファ２１７-1，２１７-2，２１７-2からの各ビューの画像データの読み出しと、視差バッファ２２３からの視差データの読み出しと、ピクセルバッファ２２７からのグラフィクスのビットマップデータの読み出しとは、ＰＴＳに基づいて行われ、転送同期が取られる。
次に、２次元（２Ｄ）画像受信時の場合について説明する。なお、上述した立体（３Ｄ）画像受信時の場合と同一である場合には、適宜、その説明を省略する。トランスポートストリームバッファ（ＴＳバッファ）２１３は、デジタルチューナ２１２から出力されたトランスポートストリームＴＳを一時的に蓄積する。このトランスポートストリームＴＳに、２次元画像データが符号化されて得られたビデオストリームが含まれている。
ビデオストリームのレイヤにビュー構成情報、つまりマルチビュー・ストリーム・コンフィグレーション・インフォ（multiview_stream_configuration_info()）の挿入があるとき、トランスポートストリームバッファ（ＴＳバッファ）２１３には、上述したように、ＰＭＴの配下、あるいはＥＩＴの配下などに、マルチビュー・ストリーム・コンフィグレーション・デスクリプタ（multiview_stream_configuration_descriptor）が挿入されている。
デマルチプレクサ２１４は、ＴＳバッファ２１３に一時的に蓄積されたトランスポートストリームＴＳから、ビデオ、グラフィクスおよびオーディオの各エレメンタリストリームを抽出する。また、デマルチプレクサ２１４は、このトランスポートストリームＴＳから、上述したマルチビュー・ストリーム・コンフィグレーション・デスクリプタを抽出し、ＣＰＵ２０１に送る。ＣＰＵ２０１は、このデスクリプタの「multiview_stream_checkflag」の１ビットフィールドにより、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを容易に判断できる。
コーデッドバッファ２１５-1は、デマルチプレクサ２１４で抽出される２次元画像データが符号化されて得られたビデオストリームを一時的に蓄積する。ビデオデコーダ２１６-1は、ＣＰＵ２０１の制御のもと、コーデッドバッファ２１５-1に記憶されているビデオストリームの復号化処理を行って、２次元画像データを取得する。デコーデッドバッファ２１７-1は、ビデオデコーダ２１６-1で取得された２次元画像データを一時的に蓄積する。
スケーラ２１８-1は、デコーデッドバッファ２１７-1から出力される２次元画像データの出力解像度を、所定の解像度となるように調整する。ビュー補間部２１９は、スケーラ２１８-1で得られるスケーリング後の２次元画像データを、そのまま、例えばビュー１（View 1）の画像データとして出力する。この場合、ビュー補間部２１９は、２次元画像データのみを出力する。
この場合、コーデッドバッファ２１５-2，２１５-3、ビデオデコーダ２１６-2，２１６-3、デコーデッドバッファ２１７-2，２１７-3およびスケーラ２１８-2，２１８-3は、非動作状態におかれる。また、デマルチプレクサ２１４では視差のエレメンタリストリームの抽出はなく、コーデッドバッファ２２１、視差デコーダ２２２、視差バッファ２２３および視差データ変換部２２４は、非動作状態におかれる。
グラフィクスシフタ２２９は、スケーラ２２８で得られるサイズ調整後のグラフィクスのビットマップデータを、そのまま出力する。ピクセルインターリーブ／重畳部２２０は、ビュー補間部２１９から出力される２次元画像データに、グラフィクスシフタ２２９から出力されるグラフィクスのビットマップデータを重畳して、２次元画像の表示用画像データを生成する。
詳細説明は省略するが、音声系に関しては、立体（３Ｄ）画像送信時の場合と同様である。
受信機２００の動作を簡単に説明する。最初に、立体（３Ｄ）画像受信時の動作を説明する。アンテナ端子２１１に入力されたテレビ放送信号はデジタルチューナ２１２に供給される。このデジタルチューナ２１２では、テレビ放送信号が処理されて、ユーザの選択チャネルに対応した所定のトランスポートストリームＴＳが出力される。このトランスポートストリームＴＳは、ＴＳバッファ２１３に一時的に蓄積される。
このトランスポートストリームＴＳには、立体画像表示のための複数のビューのうち、左端のビューおよび右端のビューの画像データと、左端および右端の間に位置する中間のビューとしての中央のビューの画像データとが符号化されて得られたビデオストリームが含まれている。
デマルチプレクサ２１４では、ＴＳバッファ２１３に一時的に蓄積されたトランスポートストリームＴＳから、ビデオ、視差、グラフィクスおよびオーディオの各エレメンタリストリームが抽出される。また、デマルチプレクサ２１４では、このトランスポートストリームＴＳから、識別情報としてのマルチビュー・ストリーム・コンフィグレーション・デスクリプタが抽出され、ＣＰＵ２０１に送られる。ＣＰＵ２０１では、このデスクリプタの「multiview_stream_checkflag」の１ビットフィールドにより、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを容易に判断できる
デマルチプレクサ２１４で抽出される中央、左端および右端の各ビューの画像データが符号化されているビデオストリームは、それぞれ、コーデッドバッファ２１５-1，２１５-2，２１５-3に供給されて一時的に蓄積する。そして、ビデオデコーダ２１６-1，２１６-2，２１６-3では、ＣＰＵ２０１の制御のもと、それぞれ、コーデッドバッファ２１５-1，２１５-2，２１５-3に記憶されているビデオストリームの復号化処理が行われて、中央、左端および右端の各ビューの画像データが取得される。
また、各ビデオデコーダでは、ビデオストリームのピクチャヘッダまたはシーケンスヘッダのユーザデータ領域などに挿入されているビュー構成情報としてのマルチビュー・ストリーム・コンフィグレーション・インフォ（multiview_stream_configuration_info()）が抽出され、ＣＰＵ２０１に送られる。ＣＰＵ２０１は、このビュー構成情報に基づいて、立体（３Ｄ）画像受信時の動作を行うように、つまり立体（３Ｄ）表示処理を行うように、各部の動作を制御する。
ビデオデコーダ２１６-1，２１６-2，２１６-3で取得された各ビューの画像データは、それぞれ、デコーデッドバッファ２１７-1，２１７-2，２１７-3に供給されて一時的に蓄積される。スケーラ２１８-1，２１８-2，２１８-3では、それぞれ、デコーデッドバッファ２１７-1，２１７-2，２１７-3から出力される各ビューの画像データの出力解像度が所定の解像度となるように調整される。
また、デマルチプレクサ２１４で抽出される視差ストリームは、コーデッドバッファ２２１に供給されて一時的に蓄積される。視差デコーダ２２２では、コーデッドバッファ２２１に記憶されている視差ストリームの復号化処理が行われて、視差データが得られる。この視差データには、中央ビューと左端ビューとの間の視差データと、中央ビューと右端ビューとの間の視差データが含まれている。また、この視差データは、画素単位、あるいはブロック単位の視差データである。
視差デコーダ２２２で取得された視差データは、視差バッファ２２３に供給されて一時的に蓄積される。視差データ変換部２２４は、視差バッファ２２３に蓄積されている視差データに基づいて、スケーリング後の画像データのサイズに合った画素単位の視差データが生成される。この場合、送信されてくる視差データがブロック単位である場合には、画素単位の視差データに変換される。また、この場合、送信されてくる視差データが画素単位であるが、スケーリング後の画像データのサイズに合っていない場合には、適宜、スケーリングされる。
ビュー補間部２１９では、スケーリング後の中央、左端および右端の各ビューの画像データから、視差データ変換部２２４で得られた各ビュー間の視差データに基づいて、伝送されてこない所定数のビューの画像データが補間合成される。このビュー補間部２１９からは、３次元画像（立体画像）を裸眼観賞するためのＮ個のビュー（View1, View2,・・・,ViewN ）の画像データが得られる。なお、中央、左端および右端の各ビューの画像データも含まれる。
また、デマルチプレクサ２１４で抽出されるグラフィクスストリームは、コーデッドバッファ２２５に供給されて一時的に蓄積される。グラフィクスデコーダ２２６では、コーデッドバッファ２２５に記憶されているグラフィクスストリームの復号化処理が行われて、復号化されたグラフィクスデータ（サブタイトルデータを含む）が得られる。また、このグラフィクスデコーダ２２６では、このグラフィクスデータに基づいて、ビュー（画像）に重畳するグラフィクスのビットマップデータが発生される。
グラフィクスデコーダ２２６で発生されるグラフィクスのビットマップデータは、ピクセルバッファ２２７に供給されて一時的に蓄積される。スケーラ２２８では、ピクセルバッファ２２７に蓄積されているグラフィクスのビットマップデータのサイズが、スケーリング後の画像データのサイズに対応するように調整される。
グラフィクスシフタ２２９では、サイズ調整後のグラフィクスのビットマップデータに対して、視差データ変換部２２４で得られる視差データに基づいてシフト処理が施される。そして、グラフィクスシフタ２２９では、ビュー補間部２１９から出力されるＮ個のビュー（View1, View2,・・・,ViewN ）の画像データにそれぞれ重畳するＮ個のグラフィクスのビットマップデータが生成され、ピクセルインターリーブ／重畳部２２０に供給される。
ピクセルインターリーブ／重畳部２２０では、Ｎ個のビュー（View1, View2,・・・,ViewN ）の画像データにそれぞれ対応するグラフィクスのビットマップデータが重畳される。また、ピクセルインターリーブ／重畳部２２０では、Ｎ個のビュー（View1, View2,・・・,ViewN ）の画像データに対してピクセルインターリーブ処理が行われて、３次元画像（立体画像）の裸眼観賞のための表示用画像データが生成される。この表示用画像データがディスプレイに供給されることで、３次元画像（立体画像）の裸眼観賞のための、画像表示が行われる。
また、デマルチプレクサ２１４で抽出されるオーディオストリームは、コーデッドバッファ２３０に供給されて一時的に蓄積される。オーディオデコーダ２３１では、コーデッドバッファ２３０に記憶されているオーディオスストリームの復号化処理が行われて、復号化された音声データが得られ。この音声データはチャネルミキシング部２３２に供給される。チャネルミキシング部２３２では、音声データに対して、例えば５．１chサラウンド等を実現するための各チャネルの音声データが生成される。この音声データは例えばスピーカに供給され、画像表示に合わせた音声出力がなされる。
次に、２次元（２Ｄ）画像受信時の動作を説明する。アンテナ端子２１１に入力されたテレビ放送信号はデジタルチューナ２１２に供給される。このデジタルチューナ２１２では、テレビ放送信号が処理されて、ユーザの選択チャネルに対応した所定のトランスポートストリームＴＳが出力される。このトランスポートストリームＴＳは、ＴＳバッファ２１３に一時的に蓄積される。このトランスポートストリームＴＳには、２次元画像データが符号化されて得られたビデオストリームが含まれている。
デマルチプレクサ２１４では、ＴＳバッファ２１３に一時的に蓄積されたトランスポートストリームＴＳから、ビデオ、グラフィクスおよびオーディオの各エレメンタリストリームが抽出される。また、デマルチプレクサ２１４では、挿入されている場合には、このトランスポートストリームＴＳから、識別情報としてのマルチビュー・ストリーム・コンフィグレーション・デスクリプタが抽出され、ＣＰＵ２０１に送られる。ＣＰＵ２０１では、このデスクリプタの「multiview_stream_checkflag」の１ビットフィールドにより、ビデオストリームのレイヤにビュー構成情報の挿入があるか否かを容易に判断できる
デマルチプレクサ２１４で抽出される２次元画像データが符号化されているビデオストリームは、コーデッドバッファ２１５-1に供給されて一時的に蓄積する。そして、ビデオデコーダ２１６-1では、ＣＰＵ２０１の制御のもと、コーデッドバッファ２１５-1に記憶されているビデオストリームの復号化処理が行われて、２次元画像データが取得される。
また、ビデオデコーダ２１６-1では、挿入されている場合には、ビデオストリームのピクチャヘッダまたはシーケンスヘッダのユーザデータ領域などに挿入されているビュー構成情報としてのマルチビュー・ストリーム・コンフィグレーション・インフォ（multiview_stream_configuration_info()）が抽出され、ＣＰＵ２０１に送られる。ＣＰＵ２０１は、この抽出されたビュー構成情報に基づいて、あるいはこのビュー構成情報が抽出されないことに基づいて、２次元（２Ｄ）画像受信時の動作を行うように、つまり２次元（２Ｄ）表示処理を行うように、各部の動作を制御する。
ビデオデコーダ２１６-1で取得された２次元画像データは、デコーデッドバッファ２１７-1に供給されて一時的に蓄積される。スケーラ２１８-1では、それぞれ、デコーデッドバッファ２１７-1から出力される２次元画像データの出力解像度が所定の解像度となるように調整される。スケーリング後の２次元画像データは、ビュー補間部２１９から、そのまま、例えばビュー１（View 1）の画像データとして出力される。
また、デマルチプレクサ２１４で抽出されるグラフィクスストリームは、コーデッドバッファ２２５に供給されて一時的に蓄積される。グラフィクスデコーダ２２６では、コーデッドバッファ２２５に記憶されているグラフィクスストリームの復号化処理が行われて、復号化されたグラフィクスデータ（サブタイトルデータを含む）が得られる。また、このグラフィクスデコーダ２２６では、このグラフィクスデータに基づいて、ビュー（画像）に重畳するグラフィクスのビットマップデータが発生される。
グラフィクスデコーダ２２６で発生されるグラフィクスのビットマップデータは、ピクセルバッファ２２７に供給されて一時的に蓄積される。スケーラ２２８では、ピクセルバッファ２２７に蓄積されているグラフィクスのビットマップデータのサイズが、スケーリング後の画像データのサイズに対応するように調整される。スケーラ２２８で得られるサイズ調整後のグラフィクスのビットマップデータは、グラフィクスシフタ２２９からそのまま出力される。
ピクセルインターリーブ／重畳部２２０では、ビュー補間部２１９から出力される２次元画像データに、グラフィクスシフタ２２９から出力されるグラフィクスのビットマップデータが重畳されて、２次元画像の表示用画像データが生成される。この表示用画像データがディスプレイに供給されることで、２次元画像の画像表示が行われる。
［３Ｄ期間、２Ｄ期間のシグナリング］
次に、図２７に示す受信機２００における立体（３Ｄ）表示処理と２次元（２Ｄ）の表示処理との動作モード切り替え制御について説明する。この切り替えは、ＣＰＵ２０１により行われる。立体（３Ｄ）画像受信時には、各ビデオデコーダ２１６-1，２１６-2，２１６-3で抽出されるマルチビュー・ストリーム・コンフィグレーション・インフォがＣＰＵ２０１に供給される。また、２次元（２Ｄ）画像受信時には、挿入されている場合には、ビデオデコーダ２１６-1で抽出されるマルチビュー・ストリーム・コンフィグレーション・インフォがＣＰＵ２０１に供給される。ＣＰＵ２０１は、このインフォの有無やその内容に基づいて、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを制御する。
図３０、図３１は、３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示している各期間は、例えば、番組単位、あるいはシーン単位である。３Ｄ期間には、基本ビデオストリームとしての中間ビューのビデオストリームＥＳ１が存在する他に、追加ビデオストリームとしての左端ビューおよび右端ビューの２つのビデオストリームＥＳ２，ＥＳ３が存在する。２Ｄ期間には、基本ビデオストリームとしてのビデオストリームＥＳ１のみが存在する。
図３０の例は、マルチビュー・ストリーム・コンフィグレーション・インフォを含むＳＥＩメッセージが、３Ｄ期間および２Ｄ期間の双方に、ピクチャ単位で挿入される場合を示している。また、図３１の例は、マルチビュー・ストリーム・コンフィグレーション・インフォを含むＳＥＩメッセージが、各期間に、シーン単位あるいはピクチャグループ単位（ＧＯＰ単位）で挿入される場合を示している。
３Ｄ期間に挿入されているＳＥＩメッセージにおいては、「3D_flag= 1」とされ、３Ｄモード（立体画像送信モード）を示す。また、２Ｄ期間に挿入されているＳＥＩメッセージにおいては、「3D_flag= 0」とされ、３Ｄモードでないこと、従って２Ｄモード（２次元画像送信モード）を示す。なお、このＳＥＩメッセージは、ビデオストリームＥＳ１だけではなく、ビデオストリームＥＳ２，ＥＳ３にも挿入されるが、図面の簡単化のために、その図示は省略している。
図３２のフローチャートは、ＣＰＵ２０１における動作モード切り替えの制御の処理手順の一例を示している。この例は、符号化方式がＡＶＣあるいはＭＶＣである場合の例である。上述したように、マルチビュー・ストリーム・コンフィグレーション・インフォが、アクセスユニットの“ＳＥＩｓ”の部分に、「Multiview stream configuration SEI message」として挿入される（図２１、図１４参照）。この場合、立体（３Ｄ）画像受信時には、ＭＶＣのベースビューストリーム（基本ビデオストリーム）およびノンベースビューストリーム（追加ビデオストリーム）が受信され、２次元（２Ｄ）画像受信時には、ＡＶＣ（２Ｄ）ストリーム（基本ビデオストリーム）が受信される。
ＣＰＵ２０１は、ピクチャフレーム毎に、このフローチャートに従った制御を行う。しかし、ＳＥＩメッセージがピクチャ単位で挿入されていない場合、例えばＧＯＰ単位で挿入されている場合（図３１参照）、ＣＰＵ２０１は、現在のＧＯＰのＳＥＩ情報が次のＧＯＰのＳＥＩ情報で置き換わるまでの間、現在のＳＥＩ情報を維持するようにされる。
まず、ＣＰＵ２０１は、ステップＳＴ１において、処理を開始し、その後に、ステップＳＴ２の処理に移る。このステップＳＴ２において、ＣＰＵ２０１は、基本ビデオストリームにＳＥＩ（「Multiview stream configuration SEI message」）の挿入があるか否かを判断する。このＳＥＩの挿入があるとき、ＣＰＵ２０１は、ステップＳＴ３において、ＳＥＩの中の情報が３Ｄモードを示すか、つまり「3D_flag= 1」であるかを判断する。
ＳＥＩの中の情報が３Ｄモードを示すとき、つまり、立体（３Ｄ）画像受信時には、ＣＰＵ２０１は、ステップＳＴ４の処理に移る。ＣＰＵ２０１は、このステップＳＴ４において、基本ビデオストリームおよび追加ビデオストリームの各々の入力バッファ（コーデッドバッファ）の管理を行い、ステップＳＴ５において、デコーダ（ビデオデコーダ）で基本ビデオストリーム、追加ビデオストリームの各々のデコードを行う。そして、ＣＰＵ２０１は、さらに、ステップＳＴ６において、受信機２００のその他も立体（３Ｄ）表示処理を行うように制御する。
また、ＣＰＵ２０１は、ステップＳＴ２でＳＥIの挿入がないとき、あるいはステップＳＴ３でＳＥＩの中の情報が３Ｄモードを示していないとき、つまり、２次元（２Ｄ）画像受信時には、ステップＳＴ７の処理に移る。ＣＰＵ２０１は、このステップＳＴ７の処理に移る。ＣＰＵ２０１は、ステップＳＴ７において、基本ビデオストリームの入力バッファ（コーデッドバッファ）の管理を行い、ステップＳＴ８において、デコーダ（ビデオデコーダ）で基本ビデオストリームのデコードを行う。そして、ＣＰＵ２０１は、さらに、ステップＳＴ９において、受信機２００のその他も２次元（２Ｄ）表示処理を行うように制御する。
上述したように、図２７に示す受信機２００においては、マルチビュー・ストリーム・コンフィグレーション・インフォを含むＳＥＩメッセージの有無やその内容に基づいて、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えが制御されるものである。そのため、配信内容の動的な変化に的確に対応でき、正しいストリーム受信を行うことができる。
図３３は、トランスポートストリームＴＳに、「Stream_Type=0x1B」で、「ＰＩＤ＝01」であるＡＶＣのベースビューの基本ビデオストリームＥＳ１が連続して含まれ、「Stream_Type=0x20」で、「ＰＩＤ＝10」、「ＰＩＤ＝11」であるＭＶＣの追加ビデオストリームＥＳ２，ＥＳ３が間欠的に含まれる場合の例を示している。この場合、ストリームＥＳ１に、マルチビュー・ストリーム・コンフィグレーション・ＳＥＩメッセージが挿入されている。
ｔn-1，ｔn+1の期間には、ＳＥＩメッセージが存在し、しかも、「3D_flag= 1 」であって、３Ｄモードを示す。そのため、この期間において、受信機２００は、立体（３Ｄ）表示処理を行う。つまり、ストリームＥＳ１の他に、ストリームＥＳ２，ＥＳ３も抽出されてデコードされ、立体（３Ｄ）表示が行われる。一方、ｔnの期間には、ＳＥＩメッセージが存在するものの、「3D_flag= 0 」であって、２Ｄモードを示す。そのため、この期間において、受信機２００は、２次元（２Ｄ）表示処理を行う。つまり、ストリームＥＳ１のみが抽出されてデコードされ、２次元（２Ｄ）表示が行われる。
図３４は、３Ｄ期間（３Ｄモード期間）と２Ｄ期間（２Ｄモード期間）が交互に連続する場合であって、モード識別のための補助情報（マルチビュー・ストリーム・コンフィグレーション・ＳＥＩメッセージ）がない場合の一例を示している。期間Ｔ１，Ｔ３は３Ｄ期間を示し、期間Ｔ２は２Ｄ期間を示している。各期間は、例えば、番組単位、あるいはシーン単位を表す。
３Ｄ期間には、「Stream_Type=0x1B」のＭＶＣのベースビューの基本ビデオストリームが存在すると共に、「Stream_Type=0x20」のＭＶＣのノンベースビューの追加ビデオストリームが存在する。また、２Ｄ期間には、「Stream_Type=0x1B」のＡＶＣストリームが存在する。なお、基本ビデオストリームは、ＳＰＳを先頭として、所定数のアクセスユニット（ＡＵ）が続く構成となっている。また、追加ビデオストリームは、サブセットＳＰＳ（ＳＳＳＰＳ）を先頭として、所定数のアクセスユニット（ＡＵ）が続く構成となっている。また、アクセスユニット（ＡＵ）は、“PPS, Substream SEIs, Coded Slice”で構成されている。
モード識別のための補助情報がない場合、受信機は、３Ｄ期間から２Ｄ期間に切り替わったことを、受信機の入力バッファへのデータ入力が一定期間行われていないことで知る。しかし、入力バッファに追加ビデオストリームのデータ入力がないことは、伝送上あるいは符号化時のエラーが原因なのか、あるいは２Ｄ期間に切り換わったからなのか、Ｔ１の時点では分からない。したがって、受信機が２Ｄの処理モードに切り替わるのに時間的猶予が必要になる。
図３５は、３Ｄ期間と２Ｄ期間が交互に連続する場合であって、モード識別のための補助情報（マルチビュー・ストリーム・コンフィグレーション・ＳＥＩメッセージ）がある場合の一例を示している。期間Ｔ１，Ｔ３は３Ｄ期間を示し、期間Ｔ２は２Ｄ期間を示している。各期間は、例えば、番組単位、あるいはシーン単位を表す。
３Ｄ期間には、「Stream_Type=0x1B」のＭＶＣのベースビューの基本ビデオストリームが存在すると共に、「Stream_Type=0x20」のＭＶＣのノンベースビューの追加ビデオストリームが存在する。また、２Ｄ期間には、「Stream_Type=0x1B」のＡＶＣストリームが存在する。なお、基本ビデオストリームは、「ＳＰＳ」を先頭として、所定数のアクセスユニット（ＡＵ）が続く構成となっている。また、追加ビデオストリームは、「ＳＳＳＰＳ」を先頭として、所定数のアクセスユニット（ＡＵ）が続く構成となっている。また、アクセスユニット（ＡＵ）は、“PPS, Substream SEIs, Coded Slice”で構成されている。
モード識別のための補助情報（マルチビュー・ストリーム・コンフィグレーション・ＳＥＩメッセージ）がアクセスユニット（ＡＵ）毎に挿入されている。３Ｄ期間のアクセスユニットに挿入される補助情報は、「３Ｄ」で表しているが、「3D_flag= 1」とされて、３Ｄモード（立体画像送信モード）を示すものとされている。一方、２Ｄ期間のアクセスユニットに挿入される補助情報は、「２Ｄ」で表しているが、「3D_flag= 0」とされて、２Ｄモード（２次元画像送信モード）を示すものとされている。
このようにモード識別のための補助情報（マルチビュー・ストリーム・コンフィグレーション・ＳＥＩメッセージ）がある場合、受信機は、補助情報の要素「3D_flag」を検査して、その要素が３Ｄモードを示すか、あるいは２Ｄモードを示すかを即座に判別でき、デコード、そして表示処理を迅速に切換えることができる。受信機は、３Ｄ期間から２Ｄ期間に切り替わった場合、最初のアクセスユニットに挿入されている補助情報の要素「3D_flag」が２Ｄモードを示すとの判別タイミングＴ２で、３Ｄ期間から２Ｄ期間に切り替わったことを判定でき、受信機の３Ｄから２Ｄへのモード切り替えを迅速に行うことができる。
また、図２７に示す受信機２００においては、立体（３Ｄ）画像受信時には、立体画像表示のための複数のビューのうち、少なくとも左端のビューおよび右端のビューの画像データと、左端および右端の間に位置する中間のビューの画像データとが受信されるものである。そして、この受信機２００において、その他のビューは視差データに基づいて補間処理で得るものである。そのため、マルチビュー構成による立体画像の裸眼観賞を良好に行うことができる。
すなわち、左端のビューおよび右端のビューの画像データだけでなく、中央のビューの画像データも受信される。そのため、ビュー間の相対視差が小さく、伝送されないビューの画像データを補間する際の細かな部分の処理に伴うオクルージョン周辺の補間が容易になり、再生画像の品質向上を図ることができる。また、左端のビューおよび右端のビューの画像データが受信されるので、伝送されないビューの画像データの補間は全て内挿処理によって合成でき、オクルージョンなどの端点処理に関して高画質を維持することが容易となる。
なお、図２７に示す受信機２００は、トランスポートストリームＴＳに視差データが符号化されて得られた視差ストリームが含まれる場合の構成例を示している。トランスポートストリームＴＳに視差ストリームが含まれていない場合には、受信された各ビューの画像データから視差データを生成して用いることになる。
図３６は、その場合における受信機２００Ａの構成例を示している。この図３６において、図２７と対応する部分には同一符号を付し、その詳細説明は省略する。この受信機２００Ａは、視差データ生成部２３３を有している。この視差データ生成部２３３は、スケーリング処理された中央、左端および右端の各ビューの画像データに基づいて、視差データを生成する。
詳細説明は省略するが、この場合における視差データの生成方法は、上述した送信データ生成部１１０における視差データ生成部１１６における視差データ生成方法と同様である。なお、この視差データ生成部２３３は、図２７に示す受信機２００の視差データ変換部２２４で生成される画素単位の視差データと同様の視差データを生成して出力する。視差データ生成部２３３で生成された視差データは、ビュー補間部２１９に供給されると共に、フラフィクスシフタ２２９に供給されて用いられる。
なお、図３６に示す受信機２００Ａにおいては、図２７に示す受信機２００におけるコーデッドバッファ２２１、視差デコーダ２２２、視差バッファ２２３および視差データ変換部２２４は、省略される。この図３６に示す受信機２００Ａにおけるその他の構成は、図２７に示す受信機２００の構成と同様とされる。
［モード識別のための補助情報の他の例］
上述では、モード識別のための補助情報として、マルチビュー・ストリーム・コンフィグレーション・ＳＥＩメッセージを利用し、受信機は、その設定内容に基づいて、３Ｄ期間か２Ｄ期間かをフレーム精度で判別する例を示した。モード識別のための補助情報として、既存のマルチビュー・ビュー・ポジション・ＳＥＩメッセージ（multiview_view_position SEI message ）」を利用することも考えられる。このマルチビュー・ビュー・ポジション・ＳＥＩメッセージを挿入する際には、送信側は、ビデオシーケンス全体にわたって、イントラリフレッシュ（圧縮バッファを空にする）を行うイントラピクチャーに挿入する必要がある。
図３７は、このＳＥＩメッセージに含まれるマルチビュー・ビュー・ポジション（Multiview view position（））の構造例（Syntax）を示している。「num_views_minus1」のフィールドは、ビュー数から１引いた値（０〜１０２３）を示す。「view_position[i]」のフィールドは、各ビューの表示の際の相対的な位置関係を示す。つまり、各ビューを表示する際のレフトビュー（left view）からライトビュー（Right view）への順次相対位置を０から順次増加する値で示す。
上述の図７に示す送信データ生成部１１０は、３Ｄモード（立体画像送信モード）では、中間ビューの画像データが符号化されて得られたビデオストリーム（基本ビデオストリーム）に、マルチビュー・ビュー・ポジション・ＳＥＩメッセージを挿入する。このマルチビュー・ビュー・ポジション・ＳＥＩメッセージは、３Ｄモードであることを示す識別情報を構成する。この場合、少なくとも、番組単位、シーン単位、ピクチャグループ単位、あるいはピクチャ単位で挿入する。
図３８（ａ）は、ＧＯＰ（Group Of Pictures）の先頭のアクセスユニットを示しており、図３８（ｂ）は、ＧＯＰの先頭以外のアクセスユニットを示している。マルチビュー・ビュー・ポジションＳＥＩがＧＯＰ単位で挿入される場合、ＧＯＰの先頭のアクセスユニットにのみ「multiview_view_position SEI message」が挿入される。
左端（Left）、中央（Center）、右端（Right）の３つのビューに当てはめると、このマルチビュー・ビュー・ポジション・ＳＥＩメッセージに含まれるマルチビュー・ビュー・ポジション（Multiview view position（））（図３７参照）においては、「view_position[0]= 1」とされ、基本ビデオストリームであるベースビューのビデオストリームが中央のビューの画像データが符号化されて得られたビデオストリームであることが示される。
また、「view_position[1] = 0」とされ、追加ビデオストリームであるノンベースビューの第１のビデオストリームが左端のビューの画像データが符号化されて得られたビデオストリームであることが示される。さらに、「view_position[2] = 2」とされ、追加ビデオストリームであるノンベースビューの第２のビデオストリームが右端のビューの画像データが符号化されて得られたビデオストリームであることが示される。
マルチビュー・ビュー・ポジション・ＳＥＩメッセージ（multiview_view_position message）を利用する場合における、図２７に示す受信機２００における立体（３Ｄ）表示処理と２次元（２Ｄ）の表示処理との動作モード切り替え制御について説明する。この切り替えは、ＣＰＵ２０１により行われる。立体（３Ｄ）画像受信時には、ビデオデコーダ２１６-1でマルチビュー・ビュー・ポジション・ＳＥＩメッセージが抽出されてＣＰＵ２０１に供給される。しかし、２次元（２Ｄ）画像受信時には、ビデオデコーダ２１６-1でこのＳＥＩメッセージが抽出されることはなく、ＣＰＵ２０１に供給されない。ＣＰＵ２０１は、このＳＥＩメッセージの有無に基づいて、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを制御する。
図３９、図４０は、３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示している。各期間は、例えば、番組単位、あるいはシーン単位である。３Ｄ期間には、基本ビデオストリームとしての中央のビューのビデオストリームＥＳ１が存在する他に、追加ビデオストリームとしての左端ビューおよび右端ビューの２つのビデオストリームＥＳ２，ＥＳ３が存在する。２Ｄ期間には、基本ビデオストリームとしてのビデオストリームＥＳ１のみが存在する。
図３９の例は、マルチビュー・ビュー・ポジション・ＳＥＩメッセージが、３Ｄ期間に、ピクチャ単位で挿入される場合を示している。また、図４０の例は、マルチビュー・ビュー・ポジション・ＳＥＩが、３Ｄ期間に、シーン単位あるいはピクチャグループ単位（ＧＯＰ単位）で挿入される場合を示している。
図４１のフローチャートは、ＣＰＵ２０１における動作モード切り替えの制御の処理手順の一例を示している。ＣＰＵ２０１は、ピクチャフレーム毎に、このフローチャートに従った制御を行う。しかし、ＳＥＩがピクチャ単位で挿入されていない場合、例えばＧＯＰ単位で挿入されている場合（図４０参照）、ＣＰＵ２０１は、現在のＧＯＰのＳＥＩの有無の情報が、次のＧＯＰのＳＥＩの有無の情報で置き換わるまでの間維持するようにされる。
まず、ＣＰＵ２０１は、ステップＳＴ１１において、処理を開始し、その後に、ステップＳＴ１２の処理に移る。このステップＳＴ１２において、ＣＰＵ２０１は、基本ビデオストリームにＳＥＩ（「Multiview Position SEI message」）の挿入があるか否かを判断する。このＳＥＩの挿入があるとき、ＣＰＵ２０１は、ステップＳＴ１３の処理に移る。つまり、立体（３Ｄ）画像受信時には基本ビデオストリームにこのＳＥＩが挿入されているので、ＣＰＵ２０１は、ステップＳＴ１３の処理に移る。
ＣＰＵ２０１は、ステップＳＴ１３において、基本ビデオストリームおよび追加ビデオストリームの各々の入力バッファ（コーデッドバッファ）の管理を行い、ステップＳＴ１４において、デコーダ（ビデオデコーダ）で基本ビデオストリーム、追加ビデオストリームの各々のデコードを行う。そして、ＣＰＵ２０１は、さらに、ステップＳＴ１５において、受信機２００のその他も立体（３Ｄ）表示処理を行うように制御する。
この場合、マルチビュー・ビュー・ポジション・ＳＥＩが挿入されていないビデオストリーム（追加ビデオストリーム）に関しては、このＳＥＩの要素で指定される定義に従って処理が行われる。すなわち、この例では「view_position[i]」で指定される各ビューの表示の際の相対的な位置関係に従って、各追加ビデオストリームの処理も行われ、各ビューの画像データが適切に取得される。
また、ＣＰＵ２０１は、ステップＳＴ１２でＳＥＩ（「multiview_view_position ＳＥＩ message」）の挿入がないとき、ステップＳＴ１６の処理に移る。つまり、２次元（２Ｄ）画像受信時には基本ビデオストリームにこのＳＥＩが挿入されていないので、ＣＰＵ２０１は、ステップＳＴ１６の処理に移る。ＣＰＵ２０１は、ステップＳＴ１６において、基本ビデオストリームの入力バッファ（コーデッドバッファ）の管理を行い、ステップＳＴ１７において、デコーダ（ビデオデコーダ）で基本ビデオストリームのデコードを行う。そして、ＣＰＵ２０１は、さらに、ステップＳＴ１８において、受信機２００のその他も２次元（２Ｄ）表示処理を行うように制御する。
上述したように、マルチビュー・ビュー・ポジション・ＳＥＩメッセージを利用することでも、受信側において、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを良好に行うことができる。そのため、配信内容の動的な変化に的確に対応でき、正しいストリーム受信を行うことができる。
図４２は、トランスポートストリームＴＳに、「Stream_Type=0x1B」で、「ＰＩＤ＝01」であるＡＶＣのベースビューの基本ビデオストリームＥＳ１が連続して含まれ、「Stream_Type=0x20」で、「ＰＩＤ＝10」、「ＰＩＤ＝11」であるＭＶＣの追加ビデオストリームＥＳ２，ＥＳ３が間欠的に含まれる場合の例を示している。この場合、ストリームＥＳ１の、３Ｄ期間には、マルチビュー・ビュー・ポジション・ＳＥＩが挿入されている。
ｔn-1，ｔn+1の期間には、マルチビュー・ビュー・ポジション・ＳＥＩが存在する。そのため、この期間において、受信機２００は、立体（３Ｄ）表示処理を行う。つまり、ストリームＥＳ１の他に、ストリームＥＳ２，ＥＳ３も抽出されてデコードされ、立体（３Ｄ）表示が行われる。一方、ｔnの期間には、マルチビュー・ビュー・ポジション・ＳＥＩが存在しない。そのため、この期間において、受信機２００は、２次元（２Ｄ）表示処理を行う。つまり、ストリームＥＳ１のみが抽出されてデコードされ、２次元（２Ｄ）表示が行われる。
また、送信側が送信するビデオストリームに、上述したマルチビュー・ストリーム・コンフィグレーション・ＳＥＩと、マルチビュー・ビュー・ポジション・ＳＥＩの少なくとも一方を挿入することが考えられる。その場合、受信側においては、少なくともいずれかのＳＥＩを利用して、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを制御することも考えられる。
図４３は、３Ｄ期間と２Ｄ期間が交互に連続する場合であって、モード識別のための補助情報（マルチビュー・ビュー・ポジション・ＳＥＩメッセージ）がある場合の一例を示している。期間Ｔ１，Ｔ３は３Ｄ期間を示し、期間Ｔ２は２Ｄ期間を示している。各期間は、例えば、番組単位、あるいはシーン単位を表す。
３Ｄ期間には、「Stream_Type=0x1B」のＭＶＣのベースビューの基本ビデオストリームが存在すると共に、「Stream_Type=0x20」のＭＶＣのノンベースビューの追加ビデオストリームが存在する。また、２Ｄ期間には、「Stream_Type=0x1B」のＡＶＣストリームが存在する。なお、基本ビデオストリームは、「ＳＰＳ」を先頭として、所定数のアクセスユニット（ＡＵ）が続く構成となっている。また、追加ビデオストリームは、「ＳＳＳＰＳ」を先頭として、所定数のアクセスユニット（ＡＵ）が続く構成となっている。また、アクセスユニット（ＡＵ）は、“PPS, Substream SEIs, Coded Slice”で構成されている。
モード識別のための補助情報（マルチビュー・ビュー・ポジション・ＳＥＩメッセージ）が、３Ｄ期間の各アクセスユニット（ＡＵ）に挿入されている。この補助情報は３Ｄモードであることを示し、「３Ｄ」で表している。なお、２Ｄ期間の各アクセスユニット（ＡＵ）には、このような補助情報の挿入はない。
このようにモード識別のための補助情報がある場合、受信機は、補助情報の存在の有無により、３Ｄ期間か２Ｄ期間かを即座に判別でき、デコード、そして表示処理を迅速に切換えることができる。受信機は、３Ｄ期間から２Ｄ期間に切り替わった場合、最初のアクセスユニットに補助情報がないとの判別タイミングＴ２で、３Ｄ期間から２Ｄ期間に切り替わったことを判定でき、受信機の３Ｄから２Ｄへのモード切り替えを迅速に行うことができる。
図４４のフローチャートは、ＣＰＵ２０１における動作モード切り替えの制御の処理手順の一例を示している。ＣＰＵ２０１は、ピクチャフレーム毎に、このフローチャートに従った制御を行う。しかし、ＳＥＩメッセージがピクチャ単位で挿入されていない場合、例えばＧＯＰ単位で挿入されている場合、ＣＰＵ２０１は、現在のＧＯＰのＳＥＩ情報が次のＧＯＰのＳＥＩ情報で置き換わるまでの間、現在のＳＥＩ情報を維持するようにされる。以下では、マルチビュー・ストリーム・コンフィグレーション・ＳＥＩをＡタイプＳＥＩとし、マルチビュー・ビュー・ポジション・ＳＥＩをＢタイプＳＥＩとして説明する。
まず、ＣＰＵ２０１は、ステップＳＴ２１において、処理を開始し、その後に、ステップＳＴ２２の処理に移る。このステップＳＴ２２において、ＣＰＵ２０１は、基本ビデオストリームにＡタイプＳＥＩの挿入があるか否かを判断する。このＡタイプＳＥＩの挿入があるとき、ＣＰＵ２０１は、ステップＳＴ２３において、ＡタイプＳＥＩの中の情報が３Ｄモードを示すか、つまり「3D_flag= 1」であるかを判断する。
ＳＥＩの中の情報が３Ｄモードを示すとき、つまり、立体（３Ｄ）画像受信時には、ＣＰＵ２０１は、ステップＳＴ２４の処理に移る。ＣＰＵ２０１は、このステップＳＴ２４において、基本ビデオストリームおよび追加ビデオストリームの各々の入力バッファ（コーデッドバッファ）の管理を行い、ステップＳＴ２５において、デコーダ（ビデオデコーダ）で基本ビデオストリーム、追加ビデオストリームの各々のデコードを行う。そして、ＣＰＵ２０１は、さらに、ステップＳＴ６において、受信機２００のその他も立体（３Ｄ）表示処理を行うように制御する。
また、ＣＰＵ２０１は、ステップＳＴ２３でＡタイプＳＥＩの中の情報が３Ｄモードを示していないとき、つまり、２次元（２Ｄ）画像受信時には、ステップＳＴ２８の処理に移る。ＣＰＵ２０１は、このステップＳＴ２８において、基本ビデオストリームの入力バッファ（コーデッドバッファ）の管理を行い、ステップＳＴ２９において、デコーダ（ビデオデコーダ）で基本ビデオストリームのデコードを行う。そして、ＣＰＵ２０１は、さらに、ステップＳＴ３０において、受信機２００のその他も２次元（２Ｄ）表示処理を行うように制御する。
また、ＣＰＵ２０１は、ステップＳＴ２２でＡタイプＳＥIの挿入がないとき、ステップＳＴ２７において、基本ビデオストリームにＢタイプＳＥＩの挿入があるか否かを判断する。このＢタイプＳＥＩの挿入があるとき、ＣＰＵ２０１は、ステップＳＴ２４の処理に移り、上述したように、受信機２００が立体（３Ｄ）表示処理を行うように制御する。一方、基本ビデオストリームにＢタイプＳＥＩの挿入がないとき、ＣＰＵ２０１は、ステップＳＴ２８の処理に移り、上述したように、受信機２００が２次元（２Ｄ）表示処理を行うように制御する。
上述したように、送信ビデオストリームにマルチビュー・ストリーム・コンフィグレーション・ＳＥＩと、マルチビュー・ビュー・ポジション・ＳＥＩの少なくとも一方が挿入される場合、受信側において、少なくともいずれかを利用する構成とできる。これにより、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを良好に行うことができる。そのため、配信内容の動的な変化に的確に対応でき、正しいストリーム受信を行うことができる。
［モード識別のための補助情報のさらに他の例］
上述では、モード識別のための補助情報として、マルチビュー・ストリーム・コンフィグレーション・ＳＥＩメッセージ、あるいはマルチビュー・ビュー・ポジション・ＳＥＩメッセージを利用し、受信機は、その設定内容や有無に基づいて３Ｄ期間か２Ｄ期間かをフレーム精度で判別する例を示した。モード識別のための補助情報として、さらに別の補助情報を利用することも考えられる。すなわち、２Ｄモードを示す補助情報を利用するものである。
２Ｄモードを示す識別情報として、新規定義のＳＥＩメッセージを使用できる。また、ＭＰＥＧ２ストリームの場合には、既存のフレーム・パッキング・アレンジメント・データ（frame_packing_arrangement_data()）を使用できる。
図４５は、フレーム・パッキング・アレンジメント・データ（frame_packing_arrangement_data()）の構造例（Syntax）を示している。「frame_packing_user_data_identifier」の３２ビットフィールドは、このユーザデータがフレーム・パッキング・アレンジメント・データであることを識別可能とする。「arrangement_type」の７ビットフィールドは、ステレオ・ビデオ・フォーマット・タイプ（stereo_video_format_type）を示す。図４６に示すように、「０００００１１」はステレオ・サイド・バイ・サイドを示し、「００００１００」はステレオ・トップ・アンド・ボトムを示し、「０００１０００」は２Ｄビデオを示す。
上述の図７に示す送信データ生成部１１０は、２Ｄモード（立体画像送信モード）では、中間ビューの画像データが符号化されて得られたビデオストリーム（基本ビデオストリーム）に、２Ｄモードを示す補助情報を挿入する。例えば、このストリームがＭＰＥＧ２ストリームである場合、ユーザデータ領域に、上述のフレーム・パッキング・アレンジメント・データ（arrangement_type = 0001000）を挿入する。この場合、少なくとも、番組単位、シーン単位、ピクチャグループ単位、あるいはピクチャ単位で挿入する。
フレーム・パッキング・アレンジメント・データ（frame_packing_arrangement_data()）は、ピクチャヘッダ部のユーザデータ領域に、ユーザデータ「user_data()」として挿入される。図４７は、「user_data()」の構造例(Syntax)を示している。「user_data_start_code」の３２ビットフィールドは、ユーザデータ（user_data）の開始コードであり、“0x000001B2”の固定値とされる。この開始コードの後のデータ本体として、「frame_packing_arrangement_data()」が挿入される。
２Ｄモードを示す補助情報を利用する場合における、図２７に示す受信機２００における立体（３Ｄ）表示処理と２次元（２Ｄ）の表示処理との動作モード切り替え制御について説明する。この切り替えは、ＣＰＵ２０１により行われる。２次元（２Ｄ）画像受信時には、ビデオデコーダ２１６-1で２Ｄモードを示す補助情報が抽出されてＣＰＵ２０１に供給される。しかし、立体（３Ｄ）画像受信時には、ビデオデコーダ２１６-1でこの補助情報が抽出されることはなく、ＣＰＵ２０１に供給されない。ＣＰＵ２０１は、この補助情報の有無に基づいて、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを制御する。
図４８、図４９は、３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示している。各期間は、例えば、番組単位、あるいはシーン単位である。３Ｄ期間には、基本ビデオストリームとしての中央のビューのビデオストリームＥＳ１が存在する他に、追加ビデオストリームとしての左端ビューおよび右端ビューの２つのビデオストリームＥＳ２，ＥＳ３が存在する。２Ｄ期間には、基本ビデオストリームとしてのビデオストリームＥＳ１のみが存在する。図４８の例は、２Ｄモードを示す補助情報が、２Ｄ期間に、ピクチャ単位で挿入される場合を示している。また、図４９の例は、２Ｄモードを示す補助情報が、２Ｄ期間に、シーン単位あるいはピクチャグループ単位（ＧＯＰ単位）で挿入される場合を示している。
図５０のフローチャートは、ＣＰＵ２０１における動作モード切り替えの制御の処理手順の一例を示している。ＣＰＵ２０１は、ピクチャフレーム毎に、このフローチャートに従った制御を行う。しかし、補助情報がピクチャ単位で挿入されていない場合、例えばＧＯＰ単位で挿入されている場合（図４９参照）、ＣＰＵ２０１は、現在のＧＯＰの補助情報の有無の情報が、次のＧＯＰの補助情報の有無の情報で置き換わるまでの間は維持するようにされる。
まず、ＣＰＵ２０１は、ステップＳＴ３１において、処理を開始し、その後に、ステップＳＴ３２の処理に移る。このステップＳＴ３２において、ＣＰＵ２０１は、基本ビデオストリームに２Ｄモードを示す補助情報の挿入があるか否かを判断する。この補助情報の挿入がないとき、ＣＰＵ２０１は、ステップＳＴ３３の処理に移る。つまり、立体（３Ｄ）画像受信時には基本ビデオストリームにこの補助情報の挿入がされていないので、ＣＰＵ２０１は、ステップＳＴ３３の処理に移る。
ＣＰＵ２０１は、ステップＳＴ３３において、基本ビデオストリームおよび追加ビデオストリームの各々の入力バッファ（コーデッドバッファ）の管理を行い、ステップＳＴ３４において、デコーダ（ビデオデコーダ）で基本ビデオストリーム、追加ビデオストリームの各々のデコードを行う。そして、ＣＰＵ２０１は、さらに、ステップＳＴ３５において、受信機２００のその他も立体（３Ｄ）表示処理を行うように制御する。
また、ＣＰＵ２０１は、ステップＳＴ３２で補助情報の挿入があるとき、ステップＳＴ３６の処理に移る。つまり、２次元（２Ｄ）画像受信時には基本ビデオストリームにこの補助情報が挿入されているので、ＣＰＵ２０１は、ステップＳＴ３６の処理に移る。ＣＰＵ２０１は、ステップＳＴ３６において、基本ビデオストリームの入力バッファ（コーデッドバッファ）の管理を行い、ステップＳＴ３７において、デコーダ（ビデオデコーダ）で基本ビデオストリームのデコードを行う。そして、ＣＰＵ２０１は、さらに、ステップＳＴ３８において、受信機２００のその他も２次元（２Ｄ）表示処理を行うように制御する。
上述したように、２Ｄモードを示す補助情報を利用することでも、受信側において、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを良好に行うことができる。そのため、配信内容の動的な変化に的確に対応でき、正しいストリーム受信を行うことができる。
図５１は、トランスポートストリームＴＳに、「Stream_Type=0x02」で、「ＰＩＤ＝01」であるＭＰＥＧ２のベースビューの基本ビデオストリームＥＳ１が連続して含まれ、「Stream_Type=0x23」で、「ＰＩＤ＝10」、「ＰＩＤ＝11」であるＡＶＣの追加ビデオストリームＥＳ２，ＥＳ３が間欠的に含まれる場合の例を示している。この場合、ストリームＥＳ１の２Ｄ期間には、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が挿入されている。
ｔn-1，ｔn+1の期間には、フレーム・パッキング・アレンジメント・データ（arrangement_type= “2D”）が存在しない。そのため、この期間において、受信機２００は、立体（３Ｄ）表示処理を行う。つまり、ストリームＥＳ１の他に、ストリームＥＳ２，ＥＳ３も抽出されてデコードされ、立体（３Ｄ）表示が行われる。一方、ｔnの期間には、フレーム・パッキング・アレンジメント・データ（arrangement_type= “2D”）が存在する。そのため、この期間において、受信機２００は、２次元（２Ｄ）表示処理を行う。つまり、ストリームＥＳ１のみが抽出されてデコードされ、２次元（２Ｄ）表示が行われる。
図５２は、３Ｄ期間と２Ｄ期間が交互に連続する場合であって、モード識別のための補助情報（新規定義の２Ｄモードであることを示すＳＥＩメッセージ）がある場合の一例を示している。期間Ｔ１，Ｔ３は３Ｄ期間を示し、期間Ｔ２は２Ｄ期間を示している。各期間は、例えば、番組単位、あるいはシーン単位を表す。
３Ｄ期間には、「Stream_Type=0x1B」のＭＶＣのベースビューの基本ビデオストリームが存在すると共に、「Stream_Type=0x20」のＭＶＣのノンベースビューの追加ビデオストリームが存在する。また、２Ｄ期間には、「Stream_Type=0x1B」のＡＶＣストリームが存在する。なお、基本ビデオストリームは、「ＳＰＳ」を先頭として、所定数のアクセスユニット（ＡＵ）が続く構成となっている。また、追加ビデオストリームは、「ＳＳＳＰＳ」を先頭として、所定数のアクセスユニット（ＡＵ）が続く構成となっている。また、アクセスユニット（ＡＵ）は、“PPS, Substream SEIs, Coded Slice”で構成されている。
モード識別のための補助情報が２Ｄ期間の各アクセスユニット（ＡＵ）に挿入されている。この補助情報は２Ｄモードであることを示し、「２Ｄ」で表している。なお、３Ｄ期間の各アクセスユニット（ＡＵ）には、このような補助情報の挿入はない。
このようにモード識別のための補助情報がある場合、受信機は、補助情報の存在の有無により、３Ｄ期間か２Ｄ期間かを即座に判別でき、デコード、そして表示処理を迅速に切換えることができる。受信機は、３Ｄ期間から２Ｄ期間に切り替わった場合、最初のアクセスユニットに補助情報があるとの判別タイミングＴ２で、３Ｄ期間から２Ｄ期間に切り替わったことを判定でき、受信機の３Ｄから２Ｄへのモード切り替えを迅速に行うことができる。
［ステレオ立体画像の場合］
また、上述では、立体（３Ｄ）画像送信時に、マルチビュー立体画像を表示するための中央ビュー、左端ビュー、右端ビューの画像データを、放送局１００から受信機２００に送信する例を示した。本技術は、立体（３Ｄ）画像送信時に、ステレオ立体画像を表示するための左眼ビューおよび右眼ビューの画像データを放送局１００から受信機２００に送信する場合であっても同様に適用できる。
この場合、トランスポートストリームＴＳに含まれるビデオストリームにおいて、図５３に示すように、左眼（Left)のビューおよび右眼（Right）のビューの画像データはそれぞれ１つのピクチャのデータとして符号化される。図示の例では、各ピクチャのデータは１９２０＊１０８０のフルＨＤのサイズとされる。その場合、例えば、マルチビュー・ビュー・ポジション・ＳＥＩは、左眼ビューおよび右眼ビューの画像データがそれぞれ符号化されて得られた基本ビデオストリームおよび追加ビデオストリームのうち、基本ビデオストリームに挿入される。
図５４は、放送局１００において、ステレオ立体画像を表示するための左眼ビューおよび右眼ビューの画像データを送信する送信データ生成部１１０Ｂの構成例を示している。この図５４において、図７と対応する部分には同一符号を付し、適宜、その詳細説明は省略する。
画像データ出力部１１１-1から出力される左眼ビューの画像データ（左眼画像データ）ＶＬはスケーラ１１３-1で、例えば、１９２０＊１０８０のフルＨＤのサイズにスケーリング処理される。そして、スケーリング処理後の画像データＶＬ′は、ビデオエンコーダ１１４-1に供給される。ビデオエンコーダ１１４-1では、この画像データＶＬ′に対して符号化が施されて符号化ビデオデータが得られ、この符号化データをサブストリーム（sub stream 1）として含むビデオストリーム（基本ビデオストリーム）が生成される。
なお、この場合、ビデオエンコーダ１１４-1では、このビデオストリーム（基本ビデオストリーム）に、マルチビュー・ビュー・ポジション・ＳＥＩメッセージを、少なくとも、番組単位、シーン単位、ピクチャグループ単位、あるいはピクチャ単位で挿入する。このマルチビュー・ビュー・ポジション・ＳＥＩメッセージに含まれるマルチビュー・ビュー・ポジション（Multiview view position（））（図３７参照）においては、例えば、「view_position[0]= 0」、「view_position[1] = 1」とされる。
これにより、基本ビデオストリームであるベースビューのビデオストリームが左端のビューの画像データが符号化されて得られたビデオストリームであることが示される。また、追加ビデオストリームであるノンベースビューのビデオストリームが右端のビューの画像データが符号化されて得られたビデオストリームであることが示される。
また、画像データ出力部１１１-2から出力される右眼ビューの画像データ（右眼画像データ）ＶＲはスケーラ１１３-2で、例えば、１９２０＊１０８０のフルＨＤのサイズにスケーリング処理される。そして、スケーリング処理後の画像データＶＲ′は、ビデオエンコーダ１１４-2に供給される。ビデオエンコーダ１１４-2では、この画像データＶＲ′に対して符号化が施されて符号化ビデオデータが得られ、この符号化データをサブストリーム（sub stream ２）として含むビデオストリーム（追加ビデオストリーム）が生成される。
マルチプレクサ１１５では、各エンコーダから供給されるエレメンタリストリームがパケット化されて多重され、トランスポートストリームＴＳが生成される。この場合、左眼画像データが符号化されたビデオストリーム（基本ビデオストリーム）は、例えば、ＭＶＣのベースビューのビデオエレメンタリストリーム（Base view sub-bitstream）として送信される。また、右眼画像データが符号化されたビデオストリーム（追加ビデオストリーム）は、例えば、ＭＶＣのノンベースビューのビデオエレメンタリストリーム（Non-Base view sub-bitstream）として送信される。また、この場合、それぞれのＰＥＳヘッダには、受信側における同期再生のために、ＰＴＳが挿入される。詳細説明は省略するが、図５４に示す送信データ生成部１１０Ｂのその他は、図７に示す送信データ生成部１１０と同様に構成される。
図５５は、ステレオ立体画像の受信機２００Ｂの構成例を示している。この図５５において、図２７と対応する部分には同一符号を付し、適宜、その詳細説明は省略する。デマルチプレクサ２１４では、ＴＳバッファ２１３に一時的に蓄積されたトランスポートストリームＴＳから、ビデオ、視差、グラフィクスおよびオーディオの各エレメンタリストリームが抽出される。
デマルチプレクサ２１４で抽出される左眼画像データ、右眼画像データがそれぞれ符号化されているビデオストリームは、それぞれ、コーデッドバッファ２１５-1，２１５-2に供給されて一時的に蓄積される。そして、ビデオデコーダ２１６-1，２１６-2では、ＣＰＵ２０１の制御のもと、それぞれ、コーデッドバッファ２１５-1，２１５-2に記憶されているビデオストリームの復号化処理が行われて、左眼画像データおよび右眼画像データが取得される。
この場合、ビデオデコーダ２１６-1では、ビデオストリーム（基本ビデオストリーム）に、上述したように挿入されているマルチビュー・ビュー・ポジション・ＳＥＩメッセージ（図３８、図３７参照）が抽出され、ＣＰＵ２０１に送られる。ＣＰＵ２０１は、このＳＥＩ情報に基づいて、立体（３Ｄ）画像受信時の動作を行うように、つまり立体（３Ｄ）表示処理を行うように、各部の動作を制御する。
ビデオデコーダ２１６-1，２１６-2で取得された各ビューの画像データは、それぞれ、デコーデッドバッファ２１７-1，２１７-2に供給されて一時的に蓄積される。スケーラ２１８-1，２１８-2では、それぞれ、デコーデッドバッファ２１７-1，２１７-2から出力される各ビューの画像データの出力解像度が所定の解像度となるように調整される。
重畳部２２０Ｂでは、左眼画像データおよび右眼画像データにそれぞれ対応するグラフィクスのビットマップデータが重畳され、ステレオ立体画像表示のための表示用画像データが生成される。この表示用画像データがディスプレイに供給されることで、ステレオ立体（３Ｄ）画像の表示が行われる。詳細説明は省略するが、図５５に示す送信データ生成部２００Ｂのその他は、図２７に示す送信データ生成部２００と同様に構成される。
このように、立体画像としてステレオ立体（３Ｄ）画像の送信を行う場合にあっても、受信機２００Ｂにおいては、立体画像の要素を提示する補助情報、例えば上述のマルチビュー・ビュー・ポジション・ＳＥＩを利用して、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを良好に行うことができる。そのため、配信内容の動的な変化に的確に対応でき、正しいストリーム受信を行うことができる。
図５６、図５７は、３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示している。各期間は、例えば、番組単位、あるいはシーン単位である。３Ｄ期間には、基本ビデオストリームとしての左眼ビューの画像データを含むビデオストリームＥＳ１が存在する他に、追加ビデオストリームとしての右眼ビューの画像データを含むビデオストリームＥＳ２が存在する。２Ｄ期間には、基本ビデオストリームとしての２次元画像データを含むビデオストリームＥＳ１のみが存在する。
図５６の例は、マルチビュー・ビュー・ポジション・ＳＥＩメッセージが、３Ｄ期間に、ピクチャ単位で挿入される場合を示している。また、図５７の例は、マルチビュー・ビュー・ポジション・ＳＥＩが、３Ｄ期間に、シーン単位あるいはピクチャグループ単位（ＧＯＰ単位）で挿入される場合を示している。
図５８は、トランスポートストリームＴＳに、「Stream_Type=0x1B」で、「ＰＩＤ＝01」であるＡＶＣのベースビューの基本ビデオストリームＥＳ１が連続して含まれ、「Stream_Type=0x20」で、「ＰＩＤ＝11」であるＭＶＣの追加ビデオストリームＥＳ２が間欠的に含まれる場合の例を示している。この場合、ストリームＥＳ１の、３Ｄ期間には、マルチビュー・ビュー・ポジション・ＳＥＩが挿入されている。
ｔn-1，ｔn+1の期間には、マルチビュー・ビュー・ポジション・ＳＥＩが存在する。そのため、この期間において、受信機２００Ｂは、ステレオ立体（３Ｄ）表示処理を行う。つまり、ストリームＥＳ１の他に、ストリームＥＳ２も抽出されてデコードされ、ステレオ立体（３Ｄ）画像の表示が行われる。
一方、ｔnの期間には、マルチビュー・ビュー・ポジション・ＳＥＩが存在しない。そのため、この期間において、受信機２００Ｂは、２次元（２Ｄ）表示処理を行う。つまり、ストリームＥＳ１のみが抽出されてデコードされ、２次元（２Ｄ）表示が行われる。この際、３Ｄの処理モードから２Ｄの処理モードへ迅速に移行するために、バッファ管理モードは３Ｄモードを維持したまま、基本ビデオストリームのデコードのみを行い、表示処理を２Ｄ表示とする、というような処理方法も可能である。
上述のステレオ立体画像表示の例では、マルチビュー・ビュー・ポジション・ＳＥＩをモード識別のための補助情報として使用している。しかし、詳細説明は省略するが、マルチビュー立体画像の例と同様に、マルチビュー・ストリーム・コンフィグレーション・ＳＥＩを使用する構成、２Ｄモードを示す補助情報（フレーム・パッキング・アレンジメント・データなど）を使用する構成も考えられる。
図５９は、上述した、３Ｄ期間に基本ストリーム（Base stream）および追加ストリーム（Additional stream）が存在し、２Ｄ期間に基本ストリームのみが存在する場合において、３Ｄ期間と２Ｄ期間を識別する、ケースＡ、ケースＢ、ケースＣの方法をまとめて示している。
図５９（ａ）に示すケースＡの方法は、３Ｄ期間および２Ｄ期間の双方において基本ストリームにモード識別のための補助情報を挿入し、この補助情報の設定内容により３Ｄ期間であるか２Ｄ期間であるかを識別可能とする方法である。このケースＡの方法は、上述のマルチビュー・ストリーム・コンフィグレーション・ＳＥＩを使用した例に対応する。
図５９（ｂ）に示すケースＢの方法は、３Ｄ期間のみ基本ストリームに３Ｄモードであることを示す補助情報を挿入し、この補助情報の有無により３Ｄ期間であるか２Ｄ期間であるかを識別可能とする方法である。このケースＢの方法は、上述のマルチビュー・ビュー・ポジション・ＳＥＩを使用した例に対応する。
図５９（ｃ）に示すケースＣの方法は、２Ｄ期間のみ基本ストリームに２Ｄモードであることを示す補助情報を挿入し、この補助情報の有無により３Ｄ期間であるか２Ｄ期間であるかを識別可能とする方法である。このケースＣの方法は、上述の２Ｄモードを示す補助情報（新規定義のＳＥＩ、フレーム・パッキング・アレンジメント・データなど）を使用した例に対応する。
［２Ｄ期間にも追加ストリームが存在する場合］
上述では、２Ｄ期間には基本ストリームのみが存在する例を示した。しかし、２Ｄ期間にあっても、３Ｄ期間と同様のストリーム構成とすることも考えられる。すなわち、３Ｄ期間、２Ｄ期間の双方とも、基本ストリーム（Base stream）および追加ストリーム（Additional stream）が存在する例である。
上述の図７に示す送信データ生成部１１０では、立体（３Ｄ）画像送信時に、ＭＶＣのベースビューの基本ビデオストリームと、ＭＶＣのノンベースビューの２つの追加ビデオストリームが、送信ビデオストリームとして生成される。すなわち、スケーリング処理後の中央（Center）のビューの画像データＶＣ′が符号化されてＭＶＣのベースビューの基本ビデオストリームが得られる。また、スケーリング処理後の左端（Left）、右端（Right）の２つのビューの画像データＶＬ′，ＶＲ′がそれぞれ符号化されてＭＶＣのノンベースビューの追加ビデオストリームが得られる。
そして、上述の図７に示す送信データ生成部１１０では、例えば、２次元（２Ｄ）画像送信時にも、ＭＶＣのベースビューの基本ビデオストリームと、ＭＶＣのノンベースビューの２つの追加ビデオストリームが、送信ビデオストリームとして生成される。すなわち、スケーリング処理後の２次元画像データが符号化されてＭＶＣのベースビューの基本ビデオストリームが得られる。また、基本ビデオストリームを参照した結果のビュー間差分がゼロであるという符号化モード（Skipped Macro Block）で符号化されて、２次元画像データと同じ画像データを実質的に含む２つの追加ビデオストリームが得られる。
このように２次元（２Ｄ）画像送信時にも、立体（３Ｄ）画像送信時と同様に、ＭＶＣのベースビューの基本ビデオストリームと、ＭＶＣのノンベースビューの２つの追加ビデオストリームというストリーム構成とすることで、エンコーダの運用として、ＭＶＣを継続できる。そのため、送信データ生成部１１０としては、安定した動作が期待される。
ここで、モード識別のための補助情報として、上述のマルチビュー・ビュー・ポジション・ＳＥＩメッセージ（multiview_view_position SEI message ）が利用される。上述の図７に示す送信データ生成部１１０は、立体（３Ｄ）画像送信時および２次元（２Ｄ）画像送信時に、基本ビデオストリームに、マルチビュー・ビュー・ポジション・ＳＥＩメッセージを、少なくとも、番組単位、シーン単位、ピクチャグループ単位、あるいはピクチャ単位で挿入する。
立体（３Ｄ）画像送信時に挿入されるマルチビュー・ビュー・ポジション・ＳＥＩメッセージにおいて、「view_position[i]」は、以下のように設定される。すなわち、「view_position[0]= 1」とされ、基本ビデオストリームであるベースビューのビデオストリームが中央のビューの画像データが符号化されて得られたビデオストリームであることが示される。
また、「view_position[1] = 0」とされ、追加ビデオストリームであるノンベースビューの第１のビデオストリームが左端のビューの画像データが符号化されて得られたビデオストリームであることが示される。さらに、「view_position[2] = 2」とされ、追加ビデオストリームであるノンベースビューの第２のビデオストリームが右端のビューの画像データが符号化されて得られたビデオストリームであることが示される。
一方、２次元（２Ｄ）画像送信時に挿入されるマルチビュー・ビュー・ポジション・ＳＥＩメッセージにおいて、「view_position[i]」は、以下のように設定される。すなわち、「view_position[0]」、「view_position[1]」、「view_position[2]」の全てが、「０」、「１」あるいは「２」とされる。
このように「view_position[i]」が設定されることで、受信側は、基本ビデオストリームと２本の追加ビデオストリームが送信される場合であっても、追加ビデオストリームは基本ビデオストリームとの差分がゼロであることが分かる。つまり、受信側は、この「view_position[i]」の設定から、複数ストリームの伝送であっても、２次元（２Ｄ）画像送信時であることを検知できる。
図２７に示す受信機２００における立体（３Ｄ）表示処理と２次元（２Ｄ）の表示処理との動作モード切り替え制御について説明する。この切り替えは、ＣＰＵ２０１により行われる。立体（３Ｄ）画像受信時には、ビデオデコーダ２１６-1でマルチビュー・ビュー・ポジション・ＳＥＩメッセージが抽出されてＣＰＵ２０１に供給される。ＣＰＵ２０１は、このＳＥＩメッセージの「view_position[i]」の設定内容に基づいて、立体画像送信モードか２次元画像送信モードのいずれかを識別し、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを制御する。
図６０、図６１は、３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示している。各期間は、例えば、番組単位、あるいはシーン単位である。３Ｄ期間および２Ｄ期間のいずれにも、基本ビデオストリームとしての中央のビューのビデオストリームＥＳ１が存在する他に、追加ビデオストリームとしての左端ビューおよび右端ビューの２つのビデオストリームＥＳ２，ＥＳ３が存在する。
図６０の例は、マルチビュー・ビュー・ポジション・ＳＥＩメッセージが、３Ｄ期間および２Ｄ期間に、ピクチャ単位で挿入される場合を示している。また、図６１の例は、マルチビュー・ビュー・ポジション・ＳＥＩが、３Ｄ期間および２Ｄ期間に、シーン単位あるいはピクチャグループ単位（ＧＯＰ単位）で挿入される場合を示している。
図６２のフローチャートは、ＣＰＵ２０１における動作モード切り替えの制御の処理手順の一例を示している。ＣＰＵ２０１は、ピクチャフレーム毎に、このフローチャートに従った制御を行う。しかし、ＳＥＩがピクチャ単位で挿入されていない場合、例えばＧＯＰ単位で挿入されている場合（図６１参照）、ＣＰＵ２０１は、現在のＧＯＰのＳＥＩ情報が次のＧＯＰのＳＥＩ情報で置き換わるまでの間、現在のＳＥＩ情報を維持するようにされる。
まず、ＣＰＵ２０１は、ステップＳＴ４１において、処理を開始し、その後に、ステップＳＴ４２の処理に移る。このステップＳＴ４２において、ＣＰＵ２０１は、基本ビデオストリームにＳＥＩ（「multiview_view_position SEI message」）の挿入があるか否かを判断する。このＳＥＩの挿入があるとき、ＣＰＵ２０１は、ステップＳＴ４３において、ＳＥＩの中の情報、つまり「view_position[i]」の設定内容が３Ｄモードを示すかを判断する。
ＳＥＩの中の「view_position[i]」の設定内容が３Ｄモードを示すとき、つまり、立体（３Ｄ）画像受信時には、ＣＰＵ２０１は、ステップＳＴ４４の処理に移る。ＣＰＵ２０１は、このステップＳＴ４４において、基本ビデオストリームおよび追加ビデオストリームの各々の入力バッファ（コーデッドバッファ）の管理を行い、ステップＳＴ４５において、デコーダ（ビデオデコーダ）で基本ビデオストリーム、追加ビデオストリームの各々のデコードを行う。そして、ＣＰＵ２０１は、さらに、ステップＳＴ４６において、受信機２００のその他も立体（３Ｄ）表示処理を行うように制御する。
また、ＣＰＵ２０１は、ステップＳＴ４２でＳＥIの挿入がないとき、あるいはステップＳＴ４３でＳＥＩの中の「view_position[i]」の設定内容が３Ｄモードを示していないとき、つまり、２次元（２Ｄ）画像受信時には、ステップＳＴ４７の処理に移る。ＣＰＵ２０１は、ステップＳＴ４７において、基本ビデオストリームの入力バッファ（コーデッドバッファ）の管理を行い、ステップＳＴ４８において、デコーダ（ビデオデコーダ）で基本ビデオストリームのデコードを行う。そして、ＣＰＵ２０１は、さらに、ステップＳＴ４９において、受信機２００のその他も２次元（２Ｄ）表示処理を行うように制御する。
図６３は、図２７に示す受信機２００における、立体（３Ｄ）画像受信時の受信パケット処理の一例を示している。基本ビデオストリームと追加ビデオストリームのＮＡＬパケットが混在して伝送されてくる。図６４は、ＮＡＬユニットヘッダおよびＮＡＬユニットヘッダのＭＶＣ拡張（NAL unit header MVC extension）の構成例（Syntax）を示している。「view_id」のフィールドは、該当するビューが何番目のビューかを示す。受信機２００は、図６３に示すように、ＮＡＬユニットタイプ（NAL unit type）の値と、ＮＡＬユニットヘッダのＭＶＣ拡張（Headermvc extension ）のビューＩＤ(view_id)の組み合わせに基づいて、混在して伝送されてくるＮＡＬパケットをストリーム毎に振り分け、各ストリームをデコードする。
図６５は、図２７に示す受信機２００における、２次元（２Ｄ）画像受信時の受信パケット処理の一例を示している。基本ビデオストリームと追加ビデオストリームのＮＡＬパケットが混在して伝送されてくる。受信機２００は、図６５に示すように、ＮＡＬユニットタイプ（NAL unit type）の値と、ＮＡＬユニットヘッダのＭＶＣ拡張（Headermvc extension ）のビューＩＤ(view_id)の組み合わせに基づいて、混在して伝送されてくるＮＡＬパケットをストリーム毎に振り分け、基本ビデオストリームのみデコードする。
すなわち、受信機２００は、２次元（２Ｄ）画像受信時にも、立体（３Ｄ）画像受信時と同様に、基本ビデオストリームおよび追加ビデオストリームを受信するが、マルチビュー・ビュー・ポジション・ＳＥＩメッセージの「view_position[i]」の設定内容に基づいて、従来のようなＳＥＩに続くピクチャ全体のスライス（slice）のデコードを行うことなく、２次元（２Ｄ）画像処理を行う。
このように、追加ビデオストリームの符号化データのデコードを行うことなく、パケット（ＮＡＬパケット）レベルでの識別ができるので、受信機２００で、２Ｄ表示モードへの移行を迅速に行うことが可能となる。また、スライス・レイヤ（Slice layer）以下をデコードせずに破棄できるので、その分メモリ消費を抑制でき、省電力化、あるいは他のフィーチャー（例えば、グラフィックスの高性能化）に、システムのＣＰＵバジェット、メモリスペースバンド幅等を割り当てることが可能となり、多機能化が可能となる。
また、受信機２００は、２次元（２Ｄ）画像受信時には、立体（３Ｄ）画像受信時と同様に、基本ビデオストリームおよび追加ビデオストリームを受信するが、立体（３Ｄ）画像処理を行うことなく、２次元（２Ｄ）画像処理を行う。そのため、従来型の２Ｄ表示と同等の表示画質を得ることが可能となる。
すなわち、２次元（２Ｄ）画像受信時に、立体（３Ｄ）画像処理を行った場合、基本ビデオストリームをデコードして得られた画像データと、追加ビデオストリームをデコードして得られた画像データとは、同じになる。そのため、３Ｄモードで表示を行うと、表示がフラットな、つまり視差が付かない表示となり、従来型の２Ｄ表示を行う場合に比べて、画質が劣る可能性がある。これは、例えば、ステレオ立体画像表示を考えると、３Ｄモニタがパッシブ（passive）型（偏光メガネによる）、アクティブ（active）型（シャッターメガネによる）のいずれでも起こり得る。
パッシブ型の多くのタイプのモニタは、３Ｄ表示は垂直方向に表示ライン単位で、左眼ビュー（Left view）と、右眼ビュー（Right view）のデータが交互に表示されることで３Ｄとするものであるが、２つのビューの画像データが同じ場合は、単に垂直解像度が従来の２Ｄ表示に比べ半分になる。一方、アクティブ型のモニタは、３Ｄ表示は時間方向にフレームを左眼ビュー、右眼ビューと交互に切り換えて表示するものであるが、２つのビューの画像データが同じ場合は、時間方向の分解能が従来の２Ｄ表示に比べ半分になる。
図６６は、トランスポートストリームＴＳに、「Stream_Type=0x1B」で、「ＰＩＤ＝01」であるＭＶＣのベースビューの基本ビデオストリームＥＳ１が連続して含まれ、さらに、「Stream_Type=0x20」で、「ＰＩＤ＝10」、「ＰＩＤ＝11」であるＭＶＣの追加ビデオストリームＥＳ２，ＥＳ３も連続的に含まれる場合の例を示している。この場合、ストリームＥＳ１の、３Ｄ期間および２Ｄ期間には、マルチビュー・ビュー・ポジション・ＳＥＩが挿入されている。
ｔn-1，ｔn+1の期間では、例えば、「view_position[0] = 1」、「view_position[1] = 0」、「view_position[2] = 2」とされており、３Ｄモードを示す。そのため、この期間において、受信機２００は、立体（３Ｄ）表示処理を行う。つまり、ストリームＥＳ１の他に、ストリームＥＳ２，ＥＳ３も抽出されてデコードされ、立体（３Ｄ）表示が行われる。
一方、ｔnの期間では、例えば、「view_position[0] = 0」、「view_position[1] = 0」、「view_position[2] = 0」とされており、２Ｄモードを示す。そのため、この期間において、受信機２００は、２次元（２Ｄ）表示処理を行う。つまり、ストリームＥＳ１のみが抽出されてデコードされ、２次元（２Ｄ）表示が行われる。
図６７は、３Ｄ期間（３Ｄモード期間）と２Ｄ期間（２Ｄモード期間）が交互に連続する場合であって、モード識別のための補助情報（マルチビュー・ビュー・ポジション・ＳＥＩメッセージ）がある場合の一例を示している。期間Ｔ１，Ｔ３は３Ｄ期間を示し、期間Ｔ２は２Ｄ期間を示している。各期間は、例えば、番組単位、あるいはシーン単位を表す。
３Ｄ期間および２Ｄ期間の双方に、「Stream_Type=0x1B」のＭＶＣのベースビューの基本ビデオストリームが存在すると共に、「Stream_Type=0x20」のＭＶＣのノンベースビューの追加ビデオストリームが存在する。なお、基本ビデオストリームは、「ＳＰＳ」を先頭として、所定数のアクセスユニット（ＡＵ）が続く構成となっている。
また、追加ビデオストリームは、「ＳＳＳＰＳ」を先頭として、所定数のアクセスユニット（ＡＵ）が続く構成となっている。アクセスユニット（ＡＵ）は、“PPS, Substream SEIs, Coded Slice”で構成されている。ただし、２Ｄ期間の追加ビデオストリームは、基本ビデオストリームを参照した結果のビュー間差分がゼロであるという符号化モード（Skipped Macro Block）で符号化されている。この期間の追加ビデオストリームは、「ＳＳＳＰＳ」を先頭として、所定数のアクセスユニット（ＡＶ）が続く構成となっている。アクセスユニット（ＡＶ）は、“PPS, Substream SEIs, Slice Skipped MB”で構成されている。
モード識別のための補助情報（マルチビュー・ビュー・ポジション・ＳＥＩメッセージ）がアクセスユニット（ＡＵ）毎に挿入されている。３Ｄ期間のアクセスユニットに挿入される補助情報は、「３Ｄ」で表しているが、「view_position[i]」が各ビューの相対位置関係を示す値とされ、３Ｄモード（立体画像送信モード）を示すものとされている。一方、２Ｄ期間のアクセスユニットに挿入される補助情報は、「２Ｄ」で表しているが、「view_position[i]」が各ビューで同じ値とされ、２Ｄモード（２次元画像送信モード）を示すものとされている。つまり、この場合、受信側で３Ｄ表示処理が行われる場合には、フラットな３Ｄ表示がされることを意味している。
このようにモード識別のための補助情報（マルチビュー・ビュー・ポジション・ＳＥＩメッセージ）がある場合、受信機は、補助情報の要素「view_position[i]」を検査して、その要素が３Ｄモードを示すか、あるいは２Ｄモードを示すかを即座に判別でき、デコード、そして表示処理を迅速に切換えることができる。受信機は、３Ｄ期間から２Ｄ期間に切り替わった場合、最初のアクセスユニットに挿入されている補助情報の要素「view_position[i]」が２Ｄモードを示すとの判別タイミングＴ２で、３Ｄ期間から２Ｄ期間に切り替わったことを判定でき、受信機の３Ｄから２Ｄへのモード切り替えを迅速に行うことができる。
なお、上述では、モード識別のための補助情報としてマルチビュー・ビュー・ポジション・ＳＥＩメッセージを使用する例を示した。詳細説明は省略するが、その他の補助情報、例えばマルチビュー・ストリーム・コンフィグレーション・ＳＥＩメッセージ（図２１、図１４参照）などを利用することも考えられる。
［モード識別のための補助情報の他の例］
上述では、モード識別のための補助情報、例えば、マルチビュー・ビュー・ポジション・ＳＥＩメッセージを３Ｄ期間および２Ｄ期間の双方に挿入し、受信機は、その設定内容に基づいて、３Ｄ期間か２Ｄ期間かをフレーム精度で判別する例を示した。しかし、３Ｄモードであることを示す補助情報を３Ｄ期間のみに挿入し、その有無に基づいて、３Ｄ期間か２Ｄ期間かをフレーム精度で判別することも考えられる。この場合も、補助情報として、例えば、マルチビュー・ビュー・ポジション・ＳＥＩメッセージを用いることができる。
上述の図７に示す送信データ生成部１１０は、３Ｄモード（立体画像送信モード）では、中間ビューの画像データが符号化されて得られたビデオストリーム（基本ビデオストリーム）に、マルチビュー・ビュー・ポジション・ＳＥＩメッセージを挿入する。このマルチビュー・ビュー・ポジション・ＳＥＩメッセージは、３Ｄモードであることを示す識別情報を構成する。この場合、少なくとも、番組単位、シーン単位、ピクチャグループ単位、あるいはピクチャ単位で挿入する。
図６８、図６９は、３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示している。各期間は、例えば、番組単位、あるいはシーン単位である。３Ｄ期間および２Ｄ期間のいずれにも、基本ビデオストリームとしての中央のビューのビデオストリームＥＳ１が存在する他に、追加ビデオストリームとしての左端ビューおよび右端ビューの２つのビデオストリームＥＳ２，ＥＳ３が存在する。
図６８の例は、マルチビュー・ビュー・ポジション・ＳＥＩメッセージが、３Ｄ期間に、ピクチャ単位で挿入される場合を示している。また、図６９の例は、マルチビュー・ビュー・ポジション・ＳＥＩが、３Ｄ期間に、シーン単位あるいはピクチャグループ単位（ＧＯＰ単位）で挿入される場合を示している。
詳細説明は省略するが、この場合におけるＣＰＵ２０１における動作モード切り替えの制御の処理手順も、例えば、上述の図４１のフローチャートで示される。ＣＰＵ２０１は、ピクチャフレーム毎に、このフローチャートに従った制御を行う。しかし、ＳＥＩがピクチャ単位で挿入されていない場合、例えばＧＯＰ単位で挿入されている場合（図６９参照）、ＣＰＵ２０１は、現在のＧＯＰのＳＥＩの有無の情報が、次のＧＯＰのＳＥＩの有無の情報で置き換わるまでの間維持するようにされる。
上述したように、マルチビュー・ビュー・ポジション・ＳＥＩメッセージを３Ｄ期間のみに挿入することでも、受信側において、そのＳＥＩメッセージの有無に基づいて、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを良好に行うことができる。そのため、配信内容の動的な変化に的確に対応でき、正しいストリーム受信を行うことができる。
図７０は、トランスポートストリームＴＳに、「Stream_Type=0x1B」で、「ＰＩＤ＝01」であるＭＶＣのベースビューの基本ビデオストリームＥＳ１が連続して含まれ、さらに、「Stream_Type=0x20」で、「ＰＩＤ＝10」、「ＰＩＤ＝11」であるＭＶＣの追加ビデオストリームＥＳ２，ＥＳ３も連続的に含まれる場合の例を示している。この場合、ストリームＥＳ１の３Ｄ期間には、マルチビュー・ビュー・ポジション・ＳＥＩが挿入されている。
ｔn-1，ｔn+1の期間には、マルチビュー・ビュー・ポジション・ＳＥＩが存在する。そのため、この期間において、受信機２００は、立体（３Ｄ）表示処理を行う。つまり、ストリームＥＳ１の他に、ストリームＥＳ２，ＥＳ３も抽出されてデコードされ、立体（３Ｄ）表示が行われる。一方、ｔnの期間には、マルチビュー・ビュー・ポジション・ＳＥＩが存在しない。そのため、この期間において、受信機２００は、２次元（２Ｄ）表示処理を行う。つまり、ストリームＥＳ１のみが抽出されてデコードされ、２次元（２Ｄ）表示が行われる。
図７１は、３Ｄ期間（３Ｄモード期間）と２Ｄ期間（２Ｄモード期間）が交互に連続する場合であって、モード識別のための補助情報（マルチビュー・ビュー・ポジション・ＳＥＩメッセージ）がある場合の一例を示している。期間Ｔ１，Ｔ３は３Ｄ期間を示し、期間Ｔ２は２Ｄ期間を示している。各期間は、例えば、番組単位、あるいはシーン単位を表す。上述の図６７の例と同様に、３Ｄ期間および２Ｄ期間の双方に、「Stream_Type=0x1B」のＭＶＣのベースビューの基本ビデオストリームが存在すると共に、「Stream_Type=0x20」のＭＶＣのノンベースビューの追加ビデオストリームが存在する。
モード識別のための補助情報（マルチビュー・ビュー・ポジション・ＳＥＩメッセージ）が、３Ｄ期間の各アクセスユニット（ＡＵ）に挿入されている。この補助情報は３Ｄモードであることを示し、「３Ｄ」で表している。なお、２Ｄ期間の各アクセスユニット（ＡＵ）には、このような補助情報の挿入はない。
このようにモード識別のための補助情報がある場合、受信機は、補助情報の存在の有無により、３Ｄ期間か２Ｄ期間かを即座に判別でき、デコード、そして表示処理を迅速に切換えることができる。受信機は、３Ｄ期間から２Ｄ期間に切り替わった場合、最初のアクセスユニットに補助情報がないとの判別タイミングＴ２で、３Ｄ期間から２Ｄ期間に切り替わったことを判定でき、受信機の３Ｄから２Ｄへのモード切り替えを迅速に行うことができる。
［モード識別のための補助情報のさらに他の例］
上述では、モード識別のための補助情報として、マルチビュー・ビュー・ポジション・ＳＥＩメッセージを利用し、受信機は、その設定内容や有無に基づいて３Ｄ期間か２Ｄ期間かをフレーム精度で判別する例を示した。モード識別のための補助情報として、さらに別の補助情報を利用することも考えられる。すなわち、２Ｄモードを示す補助情報を利用するものである。
２Ｄモードを示す識別情報として、新規定義のＳＥＩメッセージを使用できる。また、ＭＰＥＧ２ストリームの場合には、既存のフレーム・パッキング・アレンジメント・データ（frame_packing_arrangement_data()）を使用できる（図４５、図４６参照）。
上述の図７に示す送信データ生成部１１０は、２Ｄモード（立体画像送信モード）では、中間ビューの画像データが符号化されて得られたビデオストリーム（基本ビデオストリーム）に、２Ｄモードを示す補助情報を挿入する。例えば、このストリームがＭＰＥＧ２ストリームである場合、ユーザデータ領域に、上述のフレーム・パッキング・アレンジメント・データ（arrangement_type = 0001000）を挿入する。この場合、少なくとも、番組単位、シーン単位、ピクチャグループ単位、あるいはピクチャ単位で挿入する。
２Ｄモードを示す補助情報を利用する場合における、図２７に示す受信機２００における立体（３Ｄ）表示処理と２次元（２Ｄ）の表示処理との動作モード切り替え制御について説明する。この切り替えは、ＣＰＵ２０１により行われる。２次元（２Ｄ）画像受信時には、ビデオデコーダ２１６-1で２Ｄモードを示す補助情報が抽出されてＣＰＵ２０１に供給される。しかし、立体（３Ｄ）画像受信時には、ビデオデコーダ２１６-1でこの補助情報が抽出されることはなく、ＣＰＵ２０１に供給されない。ＣＰＵ２０１は、この補助情報の有無に基づいて、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを制御する。
図７２、図７３は、３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示している。各期間は、例えば、番組単位、あるいはシーン単位である。３Ｄ期間および２Ｄ期間のいずれにも、基本ビデオストリームとしての中央のビューのビデオストリームＥＳ１が存在する他に、追加ビデオストリームとしての左端ビューおよび右端ビューの２つのビデオストリームＥＳ２，ＥＳ３が存在する。図７２の例は、２Ｄモードを示す補助情報が、２Ｄ期間に、ピクチャ単位で挿入される場合を示している。また、図７３の例は、２Ｄモードを示す補助情報が、２Ｄ期間に、シーン単位あるいはピクチャグループ単位（ＧＯＰ単位）で挿入される場合を示している。
詳細説明は省略するが、この場合におけるＣＰＵ２０１における動作モード切り替えの制御の処理手順も、例えば、上述の図５０のフローチャートで示される。ＣＰＵ２０１は、ピクチャフレーム毎に、このフローチャートに従った制御を行う。しかし、ＳＥＩがピクチャ単位で挿入されていない場合、例えばＧＯＰ単位で挿入されている場合（図７３参照）、ＣＰＵ２０１は、現在のＧＯＰのＳＥＩの有無の情報が、次のＧＯＰのＳＥＩの有無の情報で置き換わるまでの間維持するようにされる。
上述したように、２Ｄモードを示す補助情報を２Ｄ期間のみに挿入することでも、その識別情報の有無に基づいて、立体（３Ｄ）表示処理と２次元（２Ｄ）表示処理との切り替えを良好に行うことができる。そのため、配信内容の動的な変化に的確に対応でき、正しいストリーム受信を行うことができる。
図７４は、トランスポートストリームＴＳに、「Stream_Type=0x02」で、「ＰＩＤ＝01」であるＭＰＥＧ２のベースビューの基本ビデオストリームＥＳ１が連続して含まれ、「Stream_Type=0x23」で、「ＰＩＤ＝10」、「ＰＩＤ＝11」であるＡＶＣの追加ビデオストリームＥＳ２，ＥＳ３も連続的に含まれる場合の例を示している。
ｔn-1，ｔn+1の期間には、フレーム・パッキング・アレンジメント・データ（arrangement_type= “2D”）が存在しない。そのため、この期間において、受信機２００は、立体（３Ｄ）表示処理を行う。つまり、ストリームＥＳ１の他に、ストリームＥＳ２，ＥＳ３も抽出されてデコードされ、立体（３Ｄ）表示が行われる。一方、ｔnの期間には、フレーム・パッキング・アレンジメント・データ（arrangement_type= “2D”）が存在する。そのため、この期間において、受信機２００は、２次元（２Ｄ）表示処理を行う。つまり、ストリームＥＳ１のみが抽出されてデコードされ、２次元（２Ｄ）表示が行われる。
図７５は、３Ｄ期間（３Ｄモード期間）と２Ｄ期間（２Ｄモード期間）が交互に連続する場合であって、モード識別のための補助情報（新規定義の２Ｄモードであることを示すＳＥＩメッセージ）がある場合の一例を示している。期間Ｔ１，Ｔ３は３Ｄ期間を示し、期間Ｔ２は２Ｄ期間を示している。各期間は、例えば、番組単位、あるいはシーン単位を表す。上述の図６７の例を同様に、３Ｄ期間および２Ｄ期間の双方に、「Stream_Type=0x1B」のＭＶＣのベースビューの基本ビデオストリームが存在すると共に、「Stream_Type=0x20」のＭＶＣのノンベースビューの追加ビデオストリームが存在する。
モード識別のための補助情報が２Ｄ期間の各アクセスユニット（ＡＵ）に挿入されている。この補助情報は２Ｄモードであることを示し、「２Ｄ」で表している。なお、３Ｄ期間の各アクセスユニット（ＡＵ）には、このような補助情報の挿入はない。
このようにモード識別のための補助情報がある場合、受信機は、補助情報の存在の有無により、３Ｄ期間か２Ｄ期間かを即座に判別でき、デコード、そして表示処理を迅速に切換えることができる。受信機は、３Ｄ期間から２Ｄ期間に切り替わった場合、最初のアクセスユニットに補助情報があるとの判別タイミングＴ２で、３Ｄ期間から２Ｄ期間に切り替わったことを判定でき、受信機の３Ｄから２Ｄへのモード切り替えを迅速に行うことができる。
［ステレオ立体画像の場合］
図７６、図７７は、３Ｄ期間（立体画像受信時）と２Ｄ期間(２次元画像受信時)が交互に連続する場合における受信ストリームの一例を示している。ただし、この例は、立体（３Ｄ）画像表示がステレオ立体画像表示である場合の例である（図５４、図５５参照）。各期間は、例えば、番組単位、あるいはシーン単位である。３Ｄ期間および２Ｄ期間のいずれにも、基本ビデオストリームとしての左眼ビューの画像データを含むビデオストリームＥＳ１が存在する他に、追加ビデオストリームとしての右眼ビューの画像データを含むビデオストリームＥＳ２が存在する。
図７６の例は、マルチビュー・ビュー・ポジション・ＳＥＩメッセージが、３Ｄ期間および２Ｄ期間に、ピクチャ単位で挿入される場合を示している。また、図７７の例は、マルチビュー・ビュー・ポジション・ＳＥＩが、３Ｄ期間および２Ｄ期間に、シーン単位あるいはピクチャグループ単位（ＧＯＰ単位）で挿入される場合を示している。
図７８は、トランスポートストリームＴＳに、「Stream_Type=0x1B」で、「ＰＩＤ＝01」であるＭＶＣのベースビューの基本ビデオストリームＥＳ１が連続して含まれ、さらに、「Stream_Type=0x20」で、「ＰＩＤ＝10」であるＭＶＣの追加ビデオストリームＥＳ２も連続的に含まれる場合の例を示している。この場合、ストリームＥＳ１の、３Ｄ期間および２Ｄ期間には、マルチビュー・ビュー・ポジション・ＳＥＩが挿入されている。
ｔn-1，ｔn+1の期間では、例えば、「view_position[0] = 0」、「view_position[1] = 1」とされており、３Ｄモードを示す。そのため、この期間において、受信機２００は、立体（３Ｄ）表示処理を行う。つまり、ストリームＥＳ１の他に、ストリームＥＳ２も抽出されてデコードされ、立体（３Ｄ）表示が行われる。
一方、ｔnの期間では、例えば、「view_position[0] = 0」、「view_position[1] = 0」とされており、２Ｄモードを示す。そのため、この期間において、受信機２００は、２次元（２Ｄ）表示処理を行う。つまり、ストリームＥＳ１のみが抽出されてデコードされ、２次元（２Ｄ）表示が行われる。
上述のステレオ立体画像表示の例では、マルチビュー・ビュー・ポジション・ＳＥＩをモード識別のための補助情報として３Ｄ期間および２Ｄ期間の双方に挿入し、受信機において、その設定内容に基づいて３Ｄ期間か２Ｄ期間かを識別するものである。詳細説明は、省略するが、３Ｄモードであることを示す補助情報を３Ｄ期間のみに挿入する例、あるいは２Ｄモードであることを示す補助情報を２Ｄ期間のみに挿入する例も同様に考えることができる。
図７９は、上述した、３Ｄ期間および２Ｄ期間の双方に基本ストリーム（Base stream）および追加ストリーム（Additional stream）が存在する場合において、３Ｄ期間と２Ｄ期間を識別する、ケースＤ、ケースＥ、ケースＦの方法をまとめて示している。
図７９（ａ）に示すケースＤの方法は、３Ｄ期間および２Ｄ期間の双方において基本ストリームにモード識別のための補助情報を挿入し、この補助情報の設定内容により３Ｄ期間であるか２Ｄ期間であるかを識別可能とする方法である。上述では、補助情報として、例えば、マルチビュー・ビュー・ポジション・ＳＥＩを使用する例を示した。
図７９（ｂ）に示すケースＥの方法は、３Ｄ期間のみ基本ストリームに３Ｄモードであることを示す補助情報を挿入し、この補助情報の有無により３Ｄ期間であるか２Ｄ期間であるかを識別可能とする方法である。上述では、補助情報として、例えば、マルチビュー・ビュー・ポジション・ＳＥＩを使用する例を示した。
図７９（ｃ）に示すケースＦの方法は、２Ｄ期間のみ基本ストリームに２Ｄモードであることを示す補助情報を挿入し、この補助情報の有無により３Ｄ期間であるか２Ｄ期間であるかを識別可能とする方法である。上述では、補助情報として、例えば、新規定義のＳＥＩ、フレーム・パッキング・アレンジメント・データなどを使用する例を示した。
上述したように、本技術においては、図８０、図８１に示すようなストリーム構成において、受信側で、３Ｄ画像送信モードであるか２Ｄ画像送信モードであるかというモード識別を、迅速に行うことができる。
図８０は、３Ｄ期間（３Ｄ画像送信モード）で基本ビデオストリームおよび追加ビデオストリームが送信され、２Ｄ期間（２Ｄ画像送信モード）で単一のビデオストリーム（基本ビデオストリームのみ）が送信されるストリーム構成例１である。また、図８１は、３Ｄ期間（３Ｄ画像送信モード）と２Ｄ期間（２Ｄ画像送信モード）の双方で基本ビデオストリームおよび追加ビデオストリームが送信されストリーム構成例２である。ただし、２Ｄ期間において、追加ビデオストリームは、基本ビデオストリームを参照した結果のビュー間差分がゼロであるという符号化モード（Skipped Macro Block）で符号化されている。これらの構成例１，２において、上述したように、本技術により、３Ｄ期間、２Ｄ期間の識別をフレーム精度で行うことができる。
［ビデオレイヤのシグナリング情報とシステムレイヤの３Ｄ，２Ｄの識別情報］
上述では、ビデオストリームに挿入される補助情報、つまりビデオレイヤの補助情報（シグナリング情報）で３Ｄ期間であるか２Ｄ期間であるかをフレーム精度で判定する例を示した。この場合、受信機は、常に該当する補助情報に相当する部分をチェックすることが必要となる。
このビデオレイヤの補助情報（シグナリング情報）とシステムレイヤの３Ｄ，２Ｄの識別情報（シグナリング情報）との組み合わせで、３Ｄ期間であるか２Ｄ期間であるかを判定することも考えられる。この場合、受信機は、システムレイヤの識別情報をまず検知し、該当するビデオレイヤの補助情報に相当する部分をチェックすることが可能となる。
「構成例１」
図８２は、３Ｄ期間、２Ｄ期間の双方に基本ビデオストリームおよび追加ビデオストリームが存在し、ＰＭＴ（プログラム・マップ・テーブル）のプログラム・ループ（Program_loop）とビデオＥＳループ（video ES_loop）の双方でシグナリングが行われる例である。
この例の場合、３Ｄ期間（イベント１）および２Ｄ期間（イベント２）の双方に、「Stream_Type=0x02」のＭＰＥＦＧ２のベースビューの基本ビデオストリームが存在すると共に、「Stream_Type=0x23」のＡＶＣのノンベースビューの追加ビデオストリームが存在する。この例において、「Ｌ」は左眼画像データを示し、「Ｒ」は右眼画像データ示すものとする。基本ビデオストリームが「Ｌ」で追加ビデオストリームが「Ｒ」であるときは通常の３Ｄ表示が可能となるが、基本ビデオストリームが「Ｌ」で追加ビデオストリームが「Ｌ」であるときはフラットな３Ｄ表示となる。
この例の場合、図５４に示す送信データ生成部１１０Ｂでは、２Ｄ期間に、基本ビデオストリームのユーザデータ領域に、ピクチャ単位で、２Ｄモードであることを示すフレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が挿入される。これにより、受信機では、ビデオレイヤにおいて、フレーム精度で、２Ｄ期間か３Ｄ期間かの判定が可能となる。
また、この例の場合、ＰＭＴ（プログラム・マップ・テーブル）のプログラム・ループ（Program_loop）とビデオＥＳループ（Video ES_loop）の双方でシグナリングが行われる。プログラム・ループには、ステレオスコピック・プログラム・インフォ・デスクリプタ（Stereoscopic_program_info_descriptor）が配置される。
図８３（ａ）は、ステレオスコピック・プログラム・インフォ・デスクリプタの構造例（Syntax）を示している。「descriptor_tag」は、デスクリプタタイプを示す８ビットのデータであり、ここでは、ステレオスコピック・プログラム・インフォ・デスクリプタであることを示す。「descriptor_length」は、デスクリプタの長さ（サイズ）を示す８ビットのデータである。このデータは、デスクリプタの長さとして、以降のバイト数を示す。
「stereoscopic_service_type」の３ビットフィールドは、サービスのタイプを指定する。図８３（ｂ）は、「stereoscopic_service_type」の値とサービスタイプとの関係を示している。例えば、“０１１”はサービスコンパチブル・ステレオスコピック・３Ｄサービスを示し、“００１”は２Ｄサービス示す。
図８２の例に戻って、ＰＭＴ（プログラム・マップ・テーブル）のプログラム・ループに配置されるステレオスコピック・プログラム・インフォ・デスクリプタの「stereoscopic_service_type」の値は、３Ｄ期間では“０１１”とされ、２Ｄ期間では“００１”とされる。
また、２Ｄ期間には、ビデオＥＳループに、ＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（MPEG2_stereoscopic_video_format descriptor）が配置される。図８４は、ＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタの構造例（Syntax）を示している。「descriptor_tag」は、デスクリプタタイプを示す８ビットのデータであり、ここでは、ＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタであることを示す。「descriptor_length」は、デスクリプタの長さ（サイズ）を示す８ビットのデータである。このデータは、デスクリプタの長さとして、以降のバイト数を示す。
「Stereo_video_arrangement_type_present」は、“１”の場合、これに続く７ビットの「arrangement_type」が「stereo_video_format_type」であることを示す。これは、上述したようにユーザ領域に挿入されるフレーム・パッキング・アレンジメント・データ（frame_packing_arrangement_data()）における「arramgement_type」の定義と同様である（図４６参照）。一方、「Stereo_video_arrangement_type_present」は、“０”の場合、これに続く７ビットには何の情報もないリザーブ（reserved）領域であることを示す。
上述したように、２Ｄ期間にビデオＥＳループに配置されるＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタにおいては、「Stereo_video_arrangement_type_present」は“１”とされ、しかも「arramgement_type」は“２Ｄ”を示すものとされる。
図８２に示すようにビデオレイヤおよびシステムレイヤでシグナリングが行われる場合における、図５５に示す受信機２００Ｂにおける立体（３Ｄ）表示処理と２次元（２Ｄ）の表示処理との動作モード切り替え制御について説明する。この切り替えは、ＣＰＵ２０１により行われる。
２次元（２Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “001”）およびＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（arrangement_type = “2D”）が抽出されて、ＣＰＵ２０１に供給される。また、この２次元（２Ｄ）画像受信時には、ビデオデコーダ２１６-1で、フレーム・パッキング・アレンジメント・データ（arrangement_type= “2D”）抽出されて、ＣＰＵ２０１に供給される。一方、立体（３Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）が抽出されて、ＣＰＵ２０１に供給される。
ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）のみが抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されないフレーム（ピクチャ）のタイミング（「Ｔａ」で図示）で、２次元（２Ｄ）表示処理から立体（３Ｄ）表示処理に切り替える制御を行う。
また、ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “001”）およびＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（arrangement_type = “2D”）が抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されるフレーム（ピクチャ）のタイミング（「Ｔｂ」で図示）で、立体（３Ｄ）表示処理から２次元（２Ｄ）表示処理に切り替える制御を行う。
図８５は、トランスポートストリームＴＳの構成例を示している。なお、この構成例では、図面の簡単化のために、視差データ、オーディオ、およびグラフィクスなどに関しては、その図示を省略している。トランスポートストリームＴＳには、「ＰＩＤ１」の基本ビデオストリーム（ＭＰＥＧ２ストリーム）のＰＥＳパケット「video PES1」が含まれていると共に、「ＰＩＤ２」の追加ビデオストリーム（ＡＶＣストリーム）のＰＥＳパケット「video PES1」が含まれている。２Ｄ期間の場合のみ、基本ビデオストリームのユーザデータ領域には、ピクチャ単位で、２Ｄモードであることを示すフレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が挿入される
また、ＰＭＴ配下のプログラム・ループには、ステレオスコピック・プログラム・インフォ・デスクリプタ（Stereoscopic_program_info_descriptor）が配置されている。このデスクリプタの「stereoscopic_service_type」は、３Ｄ期間の場合には“０１１”とされ３Ｄサービスであることが示され、２Ｄ期間の場合には“００１”とされ２Ｄサービスであることが示される。
また、ＰＭＴ配下のビデオＥＳループには、基本ビデオストリームに関する情報として、２Ｄ期間の場合のみ、ＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（MPEG2_stereoscopic_video_format descriptor）が配置される。このデスクリプタの「arramgement_type」は“２Ｄ”とされている。これにより、２Ｄサービスであることが示される。逆に、このデスクリプタがないことで、３Ｄサービスであることが示されることになる。
「構成例２」
図８６は、３Ｄ期間、２Ｄ期間の双方に基本ビデオストリームおよび追加ビデオストリームが存在し、ＰＭＴのビデオＥＳループ（video ES_loop）でシグナリングが行われる例である。なお、この図８６において、図８２と対応する部分については、適宜、その説明を省略する。
この例の場合、図５４に示す送信データ生成部１１０Ｂでは、２Ｄ期間に、基本ビデオストリームのユーザデータ領域に、ピクチャ単位で、２Ｄモードであることを示すフレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が挿入される。これにより、受信機では、ビデオレイヤにおいて、フレーム精度で、２Ｄ期間か３Ｄ期間かの判定が可能となる。
また、この例の場合、ＰＭＴのプログラム・ループに、ステレオスコピック・プログラム・インフォ・デスクリプタ（Stereoscopic_program_info_descriptor）が配置される。このデスクリプタの「stereoscopic_service_type」の値は、３Ｄ期間および２Ｄ期間の双方ともに“０１１”とされる。また、この例の場合、２Ｄ期間には、ビデオＥＳループに、ＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（MPEG2_stereoscopic_video_format descriptor）が配置される。このデスクリプタにおいては、「arramgement_type」は“２Ｄ”を示すものとされる。
図８６に示すようにビデオレイヤおよびシステムレイヤでシグナリングが行われる場合における、図５５に示す受信機２００Ｂにおける立体（３Ｄ）表示処理と２次元（２Ｄ）の表示処理との動作モード切り替え制御について説明する。この切り替えは、ＣＰＵ２０１により行われる。
２次元（２Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）およびＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（arrangement_type = “2D”）が抽出されて、ＣＰＵ２０１に供給される。また、この２次元（２Ｄ）画像受信時には、ビデオデコーダ２１６-1で、フレーム・パッキング・アレンジメント・データ（arrangement_type= “2D”）抽出されて、ＣＰＵ２０１に供給される。一方、立体（３Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）のみが抽出されて、ＣＰＵ２０１に供給される。
ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）のみが抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されないフレーム（ピクチャ）のタイミング（「Ｔａ」で図示）で、２次元（２Ｄ）表示処理から立体（３Ｄ）表示処理に切り替える制御を行う。
また、ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）およびＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（arrangement_type = “2D”）が抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されるフレーム（ピクチャ）のタイミング（「Ｔｂ」で図示）で、立体（３Ｄ）表示処理から２次元（２Ｄ）表示処理に切り替える制御を行う。
「構成例３」
図８７は、３Ｄ期間、２Ｄ期間の双方に基本ビデオストリームおよび追加ビデオストリームが存在し、ＰＭＴのプログラム・ループ（Program_loop）でシグナリングが行われる例である。なお、この図８７において、図８２と対応する部分については、適宜、その説明を省略する。
この例の場合、図５４に示す送信データ生成部１１０Ｂでは、２Ｄ期間に、基本ビデオストリームのユーザデータ領域に、ピクチャ単位で、２Ｄモードであることを示すフレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が挿入される。これにより、受信機では、ビデオレイヤにおいて、フレーム精度で、２Ｄ期間か３Ｄ期間かの判定が可能となる。
また、この例の場合、ＰＭＴのプログラム・ループに、ステレオスコピック・プログラム・インフォ・デスクリプタ（Stereoscopic_program_info_descriptor）が配置される。このデスクリプタの値は、３Ｄ期間では“０１１”とされ、２Ｄ期間では“００１”とされる。
図８７に示すようにビデオレイヤおよびシステムレイヤでシグナリングが行われる場合における、図５５に示す受信機２００Ｂにおける立体（３Ｄ）表示処理と２次元（２Ｄ）の表示処理との動作モード切り替え制御について説明する。この切り替えは、ＣＰＵ２０１により行われる。
２次元（２Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “001”）が抽出されて、ＣＰＵ２０１に供給される。また、この２次元（２Ｄ）画像受信時には、ビデオデコーダ２１６-1で、フレーム・パッキング・アレンジメント・データ（arrangement_type= “2D”）抽出されて、ＣＰＵ２０１に供給される。一方、立体（３Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）が抽出されて、ＣＰＵ２０１に供給される。
ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）が抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されないフレーム（ピクチャ）のタイミング（「Ｔａ」で図示）で、２次元（２Ｄ）表示処理から立体（３Ｄ）表示処理に切り替える制御を行う。
また、ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “001”）が抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されるフレーム（ピクチャ）のタイミング（「Ｔｂ」で図示）で、立体（３Ｄ）表示処理から２次元（２Ｄ）表示処理に切り替える制御を行う。
「構成例４」
図８８は、３Ｄ期間に基本ビデオストリームおよび追加ビデオストリームが存在し、２Ｄ期間に基本ビデオストリームのみが存在し、ＰＭＴのプログラム・ループ（Program_loop）とビデオＥＳループ（video ES_loop）の双方でシグナリングが行われる例である。なお、この図８８において、図８２と対応する部分については、適宜、その説明を省略する。
この例の場合、図５４に示す送信データ生成部１１０Ｂでは、２Ｄ期間に、基本ビデオストリームのユーザデータ領域に、ピクチャ単位で、２Ｄモードであることを示すフレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が挿入される。これにより、受信機では、ビデオレイヤにおいて、フレーム精度で、２Ｄ期間か３Ｄ期間かの判定が可能となる。
また、この例の場合、ＰＭＴのプログラム・ループに、ステレオスコピック・プログラム・インフォ・デスクリプタ（Stereoscopic_program_info_descriptor）が配置される。このデスクリプタの「stereoscopic_service_type」の値は、３Ｄ期間では“０１１”とされ、２Ｄ期間では“００１”とされる。また、この例の場合、２Ｄ期間には、ビデオＥＳループに、ＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（MPEG2_stereoscopic_video_format descriptor）が配置される。このデスクリプタにおいて、「arrangement_type」は“２Ｄ”を示すものとされる。
図８８に示すようにビデオレイヤおよびシステムレイヤでシグナリングが行われる場合における、図５５に示す受信機２００Ｂにおける立体（３Ｄ）表示処理と２次元（２Ｄ）の表示処理との動作モード切り替え制御について説明する。この切り替えは、ＣＰＵ２０１により行われる。
２次元（２Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “001”）およびＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（arrangement_type = “2D”）が抽出されて、ＣＰＵ２０１に供給される。また、この２次元（２Ｄ）画像受信時には、ビデオデコーダ２１６-1で、フレーム・パッキング・アレンジメント・データ（arrangement_type= “2D”）抽出されて、ＣＰＵ２０１に供給される。一方、立体（３Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）が抽出されて、ＣＰＵ２０１に供給される。
ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）のみが抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されないフレーム（ピクチャ）のタイミング（「Ｔａ」で図示）で、２次元（２Ｄ）表示処理から立体（３Ｄ）表示処理に切り替える制御を行う。
また、ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “001”）およびＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（arrangement_type = “2D”）が抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されるフレーム（ピクチャ）のタイミング（「Ｔｂ」で図示）で、立体（３Ｄ）表示処理から２次元（２Ｄ）表示処理に切り替える制御を行う。
「構成例５」
図８９は、３Ｄ期間に基本ビデオストリームおよび追加ビデオストリームが存在し、２Ｄ期間に基本ビデオストリームのみが存在し、ビデオＥＳループ（video ES_loop）でシグナリングが行われる例である。なお、この図８９において、図８２と対応する部分については、適宜、その説明を省略する。
この例の場合、図５４に示す送信データ生成部１１０Ｂでは、２Ｄ期間に、基本ビデオストリームのユーザデータ領域に、ピクチャ単位で、２Ｄモードであることを示すフレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が挿入される。これにより、受信機では、ビデオレイヤにおいて、フレーム精度で、２Ｄ期間か３Ｄ期間かの判定が可能となる。
また、この例の場合、ＰＭＴのプログラム・ループに、ステレオスコピック・プログラム・インフォ・デスクリプタ（Stereoscopic_program_info_descriptor）が配置される。このデスクリプタの「stereoscopic_service_type」の値は、３Ｄ期間および２Ｄ期間の双方ともに“０１１”とされる。また、この例の場合、２Ｄ期間には、ビデオＥＳループに、ＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（MPEG2_stereoscopic_video_format descriptor）が配置される。このデスクリプタにおいては、「arramgement_type」は“２Ｄ”を示すものとされる。
図８９に示すようにビデオレイヤおよびシステムレイヤでシグナリングが行われる場合における、図５５に示す受信機２００Ｂにおける立体（３Ｄ）表示処理と２次元（２Ｄ）の表示処理との動作モード切り替え制御について説明する。この切り替えは、ＣＰＵ２０１により行われる。
２次元（２Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）およびＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（arrangement_type = “2D”）が抽出されて、ＣＰＵ２０１に供給される。また、この２次元（２Ｄ）画像受信時には、ビデオデコーダ２１６-1で、フレーム・パッキング・アレンジメント・データ（arrangement_type= “2D”）抽出されて、ＣＰＵ２０１に供給される。一方、立体（３Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）のみが抽出されて、ＣＰＵ２０１に供給される。
ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）のみが抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されないフレーム（ピクチャ）のタイミング（「Ｔａ」で図示）で、２次元（２Ｄ）表示処理から立体（３Ｄ）表示処理に切り替える制御を行う。
また、ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）およびＭＰＥＧ２・ステレオスコピック・ビデオ・デスクリプタ（arrangement_type = “2D”）が抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されるフレーム（ピクチャ）のタイミング（「Ｔｂ」で図示）で、立体（３Ｄ）表示処理から２次元（２Ｄ）表示処理に切り替える制御を行う。
「構成例６」
図９０は、３Ｄ期間に基本ビデオストリームおよび追加ビデオストリームが存在し、２Ｄ期間に基本ビデオストリームのみが存在し、ＰＭＴのプログラム・ループ（Program_loop）でシグナリングが行われる例である。なお、この図９０において、図８２と対応する部分については、適宜、その説明を省略する。
この例の場合、図５４に示す送信データ生成部１１０Ｂでは、２Ｄ期間に、基本ビデオストリームのユーザデータ領域に、ピクチャ単位で、２Ｄモードであることを示すフレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が挿入される。これにより、受信機では、ビデオレイヤにおいて、フレーム精度で、２Ｄ期間か３Ｄ期間かの判定が可能となる。
また、この例の場合、ＰＭＴのプログラム・ループに、ステレオスコピック・プログラム・インフォ・デスクリプタ（Stereoscopic_program_info_descriptor）が配置される。このデスクリプタの値は、３Ｄ期間では“０１１”とされ、２Ｄ期間では“００１”とされる。
図９０に示すようにビデオレイヤおよびシステムレイヤでシグナリングが行われる場合における、図５５に示す受信機２００Ｂにおける立体（３Ｄ）表示処理と２次元（２Ｄ）の表示処理との動作モード切り替え制御について説明する。この切り替えは、ＣＰＵ２０１により行われる。
２次元（２Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “001”）が抽出されて、ＣＰＵ２０１に供給される。また、この２次元（２Ｄ）画像受信時には、ビデオデコーダ２１６-1で、フレーム・パッキング・アレンジメント・データ（arrangement_type= “2D”）抽出されて、ＣＰＵ２０１に供給される。一方、立体（３Ｄ）画像受信時には、デマルチプレクサ２１５で、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）が抽出されて、ＣＰＵ２０１に供給される。
ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “011”）が抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されないフレーム（ピクチャ）のタイミング（「Ｔａ」で図示）で、２次元（２Ｄ）表示処理から立体（３Ｄ）表示処理に切り替える制御を行う。
また、ＣＰＵ２０１は、ステレオスコピック・プログラム・インフォ・デスクリプタ（stereoscopic_service_type = “001”）が抽出された後、フレーム・パッキング・アレンジメント・データ（arrangement_type = “2D”）が抽出されるフレーム（ピクチャ）のタイミング（「Ｔｂ」で図示）で、立体（３Ｄ）表示処理から２次元（２Ｄ）表示処理に切り替える制御を行う。
「その他の構成例」
上述の構成例１から構成例６は、２Ｄ期間のビデオストリームの各ピクチャに２Ｄモードであることを示す補助情報（例えば、フレーム・パッキング・アレンジメント・データ）を挿入する例を示した。詳細説明は、省略するが、２Ｄ期間および３Ｄ期間のビデオストリームの各ピクチャにモード識別を行うための補助情報を挿入する場合、さらには３Ｄ期間のビデオストリームの各ピクチャに３Ｄモードであることを示す補助情報を挿入する場合にも、同様の構成とすることができる。
＜２．変形例＞
［ＳＶＣストリーム］
なお、上述実施の形態においては、本技術をＭＶＣストリームに適用した例を示した。すなわち、第１の送信モードが、立体画像表示のための、ベースビューの画像データと、このベースビューの画像データと共に使用されるノンベースビューの画像データを送信する立体画像送信モードであり、第２の送信モードが、２次元画像データを送信する２次元画像送信モードである、例である。
しかし、本技術は、ＳＶＣストリームにも同様に適用できる。ＳＶＣストリームには、スケーラブル符号化画像データを構成する最下位階層の画像データのビデオエレメンタリストリームが含まれる。さらに、このＳＶＣストリームには、スケーラブル符号化画像データを構成する最下位階層以外の所定数の上位階層の画像データのビデオエレメンタリストリームが含まれる。
このＳＶＣストリームの場合、第１の送信モードは、スケーラブル符号化画像データを構成する、最下位階層の画像データと、この最下位階層以外の階層の画像データを送信する拡張画像送信モードであり、第２の送信モードが、基本画像データを送信する基本画像送信モードである。このＳＶＣストリームの場合も、上述したＭＶＣストリームと同様にして、受信側で、モード識別を、迅速に行うことができる。
このＳＶＣストリームの場合、拡張画像送信モードで基本ビデオストリームおよび追加ビデオストリームが送信され、基本画像送信モードで単一のビデオストリーム（基本ビデオストリームのみ）が送信されるストリーム構成例１が考えられる（図８０参照）。この場合には、上述したＭＶＣストリームの場合と同様にして、モード識別を行うことができる。
また、このＳＶＣストリームの場合、拡張画像送信モードと基本画像送信モードの双方で基本ビデオストリームおよび追加ビデオストリームが送信されストリーム構成例２が考えられる（図８１参照）。ただし、基本画像送信モードにおいて、追加ビデオストリームは、基本ビデオストリームを参照した結果のビュー間差分がゼロであるという符号化モード（Skipped Macro Block）で符号化される。この場合にも、上述したＭＶＣストリームの場合と同様に、モード識別を行うことができる。
図９１は、拡張画像受信時の受信パケット処理の一例を示している。基本ビデオストリームと追加ビデオストリームのＮＡＬパケットが混在して伝送されてくる。図９２は、ＮＡＬユニットヘッダおよびＮＡＬユニットヘッダのＳＶＣ拡張（NAL unit header SVC extension）の構成例（Syntax）を示している。「dependency_id」のフィールドは、該当する階層が何番目の階層かを示す。受信機は、図９１に示すように、ＮＡＬユニットタイプ（NAL unit type）の値と、ＮＡＬユニットヘッダのＳＶＣ拡張（Headersvc extension ）のデペンデンシィーＩＤ(dependency_id)の組み合わせに基づいて、混在して伝送されてくるＮＡＬパケットをストリーム毎に振り分け、各ストリームをデコードする。
図９３は、基本画像送信モードの受信パケット処理の一例を示している。基本ビデオストリームと追加ビデオストリームのＮＡＬパケットが混在して伝送されてくる。受信機は、図９３に示すように、ＮＡＬユニットタイプ（NAL unit type）の値と、ＮＡＬユニットヘッダのＳＶＣ拡張（Headersvc extension ）のデペンデンシィーＩＤ(dependency_id)の組み合わせに基づいて、混在して伝送されてくるＮＡＬパケットをストリーム毎に振り分け、基本ビデオストリームのみデコードする。
すなわち、受信機は、基本画像送信モードにも、拡張画像送信モードと同様に、基本ビデオストリームおよび追加ビデオストリームを受信するが、拡張画像受信処理を行うことなく、マルチビュー・ビュー・ポジション・ＳＥＩメッセージの「view_position[i]」と同種のＩＤ値の情報、つまり、複数のストリームのデペンデンシィー（dependency）が同値であるような設定内容に基づいて、基本画像受信処理を行う。
このように、追加ビデオストリームの符号化データのデコードを行うことなく、パケット（ＮＡＬパケット）レベルでの識別ができるので、受信機で、拡張画像送信モードから基本画像送信モードへの移行を迅速に行うことが可能となる。また、スライス・レイヤ（Slice layer）以下をデコードせずに破棄できるので、その分メモリ消費を抑制でき、省電力化、あるいは他のフィーチャー（例えば、グラフィックスの高性能化）に、システムのＣＰＵバジェット、メモリスペースバンド幅等を割り当てることが可能となり、多機能化が可能となる。
［その他］
また、上述実施の形態においては、放送局１００と受信機２００からなる画像送受信システム１０を示したが、本技術を適用し得る画像送受信システムの構成は、これに限定されるものではない。例えば、受信機２００の部分が、例えば、（ＨＤＭＩ（High-Definition Multimedia Interface）などのデジタルインタフェースで接続されたセットトップボックスおよびモニタの構成などであってもよい。
また、上述実施の形態においては、コンテナがトランスポートストリーム（ＭＰＥＧ−２ ＴＳ）である例を示した。しかし、本技術は、インターネット等のネットワークを利用して受信端末に配信される構成のシステムにも同様に適用できる。インターネットの配信では、ＭＰ４やそれ以外のフォーマットのコンテナで配信されることが多い。つまり、コンテナとしては、デジタル放送規格で採用されているトランスポートストリーム（ＭＰＥＧ−２ ＴＳ）、インターネット配信で使用されているＭＰ４などの種々のフォーマットのコンテナが該当する。
また、本技術は、以下のような構成を取ることもできる。
（１）所定数の画像データを含む１つまたは複数のビデオストリームを送信する送信部と、
複数の画像データを送信する第１の送信モードと単一の画像データを送信する第２の送信モードとを識別するための補助情報を、上記ビデオストリームに挿入する補助情報挿入部とを備える
画像データ送信装置。
（２）上記情報挿入部は、
上記第１の送信モードでは、上記ビデオストリームに、該第１の送信モードであることを示す補助情報を挿入し、上記第２のモードでは、上記ビデオストリームに、該第２の送信モードであることを示す補助情報を挿入する
前記（１）に記載の画像データ送信装置。
（３）上記情報挿入部は、
上記第１の送信モードでは、上記ビデオストリームに、該第１の送信モードであることを示す補助情報を挿入し、上記第２の送信モードでは、上記ビデオストリームに上記補助情報を挿入しない
前記（１）に記載の画像データ送信装置。
（４）上記情報挿入部は、
上記第１の送信モードでは、上記ビデオストリームに上記補助情報を挿入せず、上記第２の送信モードでは、上記ビデオストリームに、該第２の送信モードであることを示す補助情報を挿入する
前記（１）に記載の画像データ送信装置。
（５）上記情報挿入部は、
上記ビデオストリームに、上記補助情報を、少なくとも、番組単位、シーン単位、ピクチャグループ単位、あるいはピクチャ単位で挿入する
前記（１）から（４）のいずれかに記載の画像データ送信装置。
（６）上記送信部は、
上記第１の送信モードでは、第１の画像データを含む基本ビデオストリームと、該第１の画像データと共に使用される第２の画像データを含む所定数の追加ビデオストリームを送信し、
上記第２の送信モードでは、上記第１の画像データを含む１つのビデオストリームを送信する
前記（１）から（５）のいずれかに記載の画像データ送信装置。
（７）上記送信部は、
上記第１の送信モードでは、第１の画像データを含む基本ビデオストリームと、該第１の画像データと共に使用される第２の画像データを含む所定数の追加ビデオストリームを送信し、
上記第２の送信モードでは、第１の画像データを含む基本ビデオストリームと、該第１の画像データと同じ画像データを実質的に含む所定数の追加ビデオストリームとを送信する
前記（１）から（５）のいずれかに記載の画像データ送信装置。
（８）上記第１の送信モードは、立体画像表示のための、ベースビューの画像データと、該ベースビューの画像データと共に使用されるノンベースビューの画像データを送信する立体画像送信モードであり、
上記第２の送信モードは、２次元画像データを送信する２次元画像送信モードである
前記（１）から（７）のいずれかに記載の画像データ送信装置。
（９）上記立体画像送信モードを示す上記補助情報は、上記各ビューの相対位置関係を示す情報を含む
前記（８）に記載の画像データ送信装置。
（１０）上記第１の送信モードは、スケーラブル符号化画像データを構成する、最下位階層の画像データと、該最下位階層以外の階層の画像データを送信する拡張画像送信モードであり、
上記第２の送信モードは、基本画像データを送信する基本画像送信モードである
前記（１）から（７）のいずれかに記載の画像データ送信装置。
（１１）上記送信部は、上記ビデオストリームを含む所定フォーマットのコンテナを送信し、
上記コンテナのレイヤに、上記第１の送信モードにあるか上記第２の送信モードにあるかを識別するための識別情報を挿入する識別情報挿入部をさらに備える
前記（１）から（１０）のいずれかに記載の画像データ送信装置。
（１２）所定数の画像データを含む１つまたは複数のビデオストリームを送信する送信ステップと、
複数の画像データを送信する第１の送信モードと単一の画像データを送信する第２の送信モードとを識別するための補助情報を、上記ビデオストリームに挿入する情報挿入ステップとを備える
画像データ送信方法。
（１３）所定数の画像データを含む１つまたは複数のビデオストリームを受信する受信部と、
上記受信されたビデオストリームに挿入されている補助情報に基づいて、複数の画像データが送信される第１の送信モードであるか単一の画像データが送信される第２の送信モードであるかを識別する送信モード識別部と、
上記受信されたビデオストリームを、上記モード識別結果に基づいて、各モードに応じた処理を行って、上記所定数の画像データを取得する処理部とを備える
画像データ受信装置。
（１４）上記送信モード識別部は、
上記受信されたビデオストリームに第１の送信モードであることを示す補助情報が挿入されているとき、該第１の送信モードであると識別し、
上記受信されたビデオストリームに第２の送信モードであることを示す補助情報が挿入されているとき、該第２の送信モードであると識別する
前記（１３）に記載の画像データ受信装置。
（１５）上記送信モード識別部は、
上記受信されたビデオストリームに第１の送信モードであることを示す補助情報が挿入されているとき、該第１の送信モードであることを識別し、
上記受信されたビデオストリームに上記補助情報の挿入がないとき、上記第２の送信モードであると識別する
前記（１３）に記載画像データ受信装置。
（１６）上記送信モード識別部は、
上記受信されたビデオストリームに上記補助情報の挿入がないとき、上記第１の送信モードであると識別し、
上記受信されたビデオストリームに第２の送信モードであることを示す補助情報が挿入されているとき、該第２の送信モードであることを識別する
前記（１３）に記載画像データ受信装置。
（１７）上記受信部は、
上記第１の送信モードでは、第１の画像データを含む基本ビデオストリームと、該第１の画像データと共に使用される第２の画像データを含む所定数の追加ビデオストリームを受信し、上記第２の送信モードでは、第１の画像データを含む１つのビデオストリームを受信し、
上記処理部は、
上記第１の送信モードでは、上記基本ビデオストリームおよび上記所定数の追加のビデオストリームを処理して、上記第１の画像データおよび上記第２の画像データを取得し、上記第２の送信モードでは、上記１つのビデオストリームを処理して、上記第１の画像データを取得する
前記（１３）から（１６）のいずれかに記載の画像データ受信装置。
（１８）上記受信部は、
上記第１の送信モードでは、第１の画像データを含む基本ビデオストリームと、該第１の画像データと共に使用される第２の画像データを含む所定数の追加ビデオストリームを受信し、上記第２の送信モードでは、第１の画像データを含む基本ビデオストリームと、該第１の画像データと同じ画像データを実質的に含む所定数の追加ビデオストリームとを受信し、
上記処理部は、
上記第１の送信モードでは、上記基本ビデオストリームおよび上記所定数の追加のビデオストリームを処理して、上記第１の画像データおよび上記第２の画像データを取得し、上記第２の送信モードでは、上記所定数の追加のビデオストリームから上記第２の画像データを取得する処理を行うことなく、上記基本のビデオストリームを処理して、上記第１の画像データを取得する
前記（１３）から（１６）のいずれかに記載の画像データ受信装置。
（１９）上記受信部は、
上記ビデオストリームを含む所定フォーマットのコンテナを受信し、
上記コンテナには、上記コンテナのレイヤに、上記第１の送信モードにあるか上記第２の送信モードにあるかを識別するための識別情報が挿入されており、
上記送信モード識別部は、上記受信されたビデオストリームに挿入されている補助情報および上記コンテナのレイヤに挿入されている識別情報に基づいて、複数の画像データが送信される第１の送信モードであるか単一の画像データが送信される第２の送信モードであるかを識別する
前記（１３）から（１８）のいずれかに記載の画像データ受信装置。
（２０）上記第１の送信モードは、立体画像表示のための、ベースビューの画像データと、該ベースビューの画像データと共に使用されるノンベースビューの画像データを送信する立体画像送信モードであり、
上記第２の送信モードは、２次元画像データを送信する２次元画像送信モードである
前記（１３）から（１９）のいずれかに記載の画像データ受信装置。
本技術の主な特徴は、送信ビデオストリームに、３Ｄ期間および２Ｄ期間、３Ｄ期間のみ、あるいは２Ｄ期間のみに挿入される補助情報(ＳＥＩメッセージ、ユーザデータなど)に基づき、受信側で、３Ｄ期間か２Ｄ期間かの識別をフレーム精度で可能とすることで、配信内容の動的な変化に的確に対応でき、正しいストリーム受信を可能にしたことである（図５９、図７９参照）。
１０・・・画像送受信システム
１００・・・放送局
１１０・・・送信データ生成部
１１１-1〜１１１-N・・・画像データ出力部
１１２・・・ビューセレクタ
１１３-1，１１３-2，１１３-3・・・スケーラ
１１４-1，１１４-2，１１４-3・・・ビデオエンコーダ
１１５・・・マルチプレクサ
１１６・・・視差データ生成部
１１７・・・視差エンコーダ
１１８・・・グラフィクスデータ出力部
１１９・・・グラフィクスエンコーダ
１２０・・・音声データ出力部
１２１・・・オーディオエンコーダ
２００，２００Ａ・・・受信機
２０１・・・ＣＰＵ
２１１・・・アンテナ端子
２１２・・・デジタルチューナ
２１３・・・トランスポートストリームバッファ（ＴＳバッファ）
２１４・・・デマルチプレクサ
２１５-1，２１５-2，２１５-3，２２１，２２５，２３０・・・コーデッドバッファ
２１６-1，２１６-2，２１６-3・・・ビデオデコーダ
２１７-1，２１７-2，２１７-3・・・ビューバッファ
２１８-1，２１８-2，２１８-3，２２８・・・スケーラ
２１９・・・ビュー補間部
２２０・・・ピクセルインターリーブ／重畳部
２２２・・・視差デコーダ
２２３・・・視差バッファ
２２４・・・視差データ変換部
２２６・・・グラフィクスデコーダ
２２７・・・ピクセルバッファ
２２９・・・グラフィクスシフタ
２３１・・・オーディオデコーダ
２３２・・・チャネルミキシング部
２３３・・・視差データ生成部

Claims (7)

  1. 所定数の画像データを含む１つまたは複数のビデオストリームを受信する受信部と、
    上記受信されたビデオストリームに挿入されている補助情報に基づいて、複数の画像データが送信される第１の送信モードであるか単一の画像データが送信される第２の送信モードであるかを識別する送信モード識別部と、
    上記受信されたビデオストリームを、上記モード識別結果に基づいて、各モードに応じた処理を行って、上記所定数の画像データを取得する処理部とを備え、
    上記受信部は、
    上記第１の送信モードでは、第１の画像データを含む基本ビデオストリームと、該第１の画像データと共に使用される第２の画像データを含む所定数の追加ビデオストリームを受信し、上記第２の送信モードでは、第１の画像データを含む基本ビデオストリームと、該第１の画像データと同じ画像データを実質的に含む所定数の追加ビデオストリームとを受信し、
    上記処理部は、
    上記第１の送信モードでは、上記基本ビデオストリームおよび上記所定数の追加のビデオストリームを処理して、上記第１の画像データおよび上記第２の画像データを取得し、上記第２の送信モードでは、上記所定数の追加のビデオストリームから上記第２の画像データを取得する処理を行うことなく、上記基本のビデオストリームを処理して、上記第１の画像データを取得する
    画像データ受信装置。
  2. 上記送信モード識別部は、
    上記受信されたビデオストリームに第１の送信モードであることを示す補助情報が挿入されているとき、該第１の送信モードであると識別し、
    上記受信されたビデオストリームに第２の送信モードであることを示す補助情報が挿入されているとき、該第２の送信モードであると識別する
    請求項１に記載の画像データ受信装置。
  3. 上記送信モード識別部は、
    上記受信されたビデオストリームに第１の送信モードであることを示す補助情報が挿入されているとき、該第１の送信モードであることを識別し、
    上記受信されたビデオストリームに上記補助情報の挿入がないとき、上記第２の送信モードであると識別する
    請求項１に記載の画像データ受信装置。
  4. 上記送信モード識別部は、
    上記受信されたビデオストリームに上記補助情報の挿入がないとき、上記第１の送信モードであると識別し、
    上記受信されたビデオストリームに第２の送信モードであることを示す補助情報が挿入されているとき、該第２の送信モードであることを識別する
    請求項１に記載の画像データ受信装置。
  5. 上記受信部は、
    上記ビデオストリームを含む所定フォーマットのコンテナを受信し、
    上記コンテナには、上記コンテナのレイヤに、上記第１の送信モードにあるか上記第２の送信モードにあるかを識別するための識別情報が挿入されており、
    上記送信モード識別部は、上記受信されたビデオストリームに挿入されている補助情報および上記コンテナのレイヤに挿入されている識別情報に基づいて、複数の画像データが送信される第１の送信モードであるか単一の画像データが送信される第２の送信モードであるかを識別する
    請求項１に記載の画像データ受信装置。
  6. 上記第１の送信モードは、立体画像表示のための、ベースビューの画像データと、該ベースビューの画像データと共に使用されるノンベースビューの画像データを送信する立体画像送信モードであり、
    上記第２の送信モードは、２次元画像データを送信する２次元画像送信モードである
    請求項１に記載の画像データ受信装置。
  7. 受信部が、所定数の画像データを含む１つまたは複数のビデオストリームを受信する受信ステップと、
    送信モード識別部が、上記受信されたビデオストリームに挿入されている補助情報に基づいて、複数の画像データが送信される第１の送信モードであるか単一の画像データが送信される第２の送信モードであるかを識別する送信モード識別ステップと、
    処理部が、上記受信されたビデオストリームを、上記モード識別結果に基づいて、各モードに応じた処理を行って、上記所定数の画像データを取得する処理部とを有し、
    上記受信ステップにおいて、
    上記第１の送信モードでは、第１の画像データを含む基本ビデオストリームと、該第１の画像データと共に使用される第２の画像データを含む所定数の追加ビデオストリームを受信し、上記第２の送信モードでは、第１の画像データを含む基本ビデオストリームと、該第１の画像データと同じ画像データを実質的に含む所定数の追加ビデオストリームとを受信し、
    上記処理ステップにおいて、
    上記第１の送信モードでは、上記基本ビデオストリームおよび上記所定数の追加のビデオストリームを処理して、上記第１の画像データおよび上記第２の画像データを取得し、上記第２の送信モードでは、上記所定数の追加のビデオストリームから上記第２の画像データを取得する処理を行うことなく、上記基本のビデオストリームを処理して、上記第１の画像データを取得する
    画像データ受信方法。
JP2012148958A 2011-11-11 2012-07-02 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法 Expired - Fee Related JP6192902B2 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
JP2012148958A JP6192902B2 (ja) 2011-11-11 2012-07-02 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法
EP12848650.3A EP2645725B1 (en) 2011-11-11 2012-11-05 Image data transmission device, image data transmission method, and image data receiving device
PCT/JP2012/078621 WO2013069604A1 (ja) 2011-11-11 2012-11-05 画像データ送信装置、画像データ送信方法および画像データ受信装置
US13/997,575 US20140071232A1 (en) 2011-11-11 2012-11-05 Image data transmission device, image data transmission method, and image data reception device
CN201810586327.XA CN108471546A (zh) 2011-11-11 2012-11-05 图像数据发送装置和方法、图像数据接收装置
CN2012800046748A CN103339945A (zh) 2011-11-11 2012-11-05 图像数据发送装置、图像数据发送方法和图像数据接收装置
KR1020137016729A KR102009048B1 (ko) 2011-11-11 2012-11-05 화상 데이터 송신 장치, 화상 데이터 송신 방법 및 화상 데이터 수신 장치

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
JP2011248114 2011-11-11
JP2011248114 2011-11-11
JP2012089769 2012-04-10
JP2012089769 2012-04-10
JP2012108961 2012-05-10
JP2012108961 2012-05-10
JP2012148958A JP6192902B2 (ja) 2011-11-11 2012-07-02 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法

Publications (3)

Publication Number Publication Date
JP2013255207A JP2013255207A (ja) 2013-12-19
JP2013255207A5 JP2013255207A5 (ja) 2015-03-19
JP6192902B2 true JP6192902B2 (ja) 2017-09-06

Family

ID=48289978

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012148958A Expired - Fee Related JP6192902B2 (ja) 2011-11-11 2012-07-02 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法

Country Status (6)

Country Link
US (1) US20140071232A1 (ja)
EP (1) EP2645725B1 (ja)
JP (1) JP6192902B2 (ja)
KR (1) KR102009048B1 (ja)
CN (2) CN108471546A (ja)
WO (1) WO2013069604A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5594002B2 (ja) * 2010-04-06 2014-09-24 ソニー株式会社 画像データ送信装置、画像データ送信方法および画像データ受信装置
US9693033B2 (en) 2011-11-11 2017-06-27 Saturn Licensing Llc Transmitting apparatus, transmitting method, receiving apparatus and receiving method for transmission and reception of image data for stereoscopic display using multiview configuration and container with predetermined format
CN103457973B (zh) * 2012-06-01 2016-04-27 深圳市腾讯计算机系统有限公司 一种图片上传方法、系统、图片上传客户端及网络服务器
CN104584562B (zh) * 2012-08-27 2018-10-09 索尼公司 发送设备、发送方法、接收设备和接收方法
CN105313898B (zh) 2014-07-23 2018-03-20 现代摩比斯株式会社 驾驶员状态感应装置及其方法
US10652284B2 (en) * 2016-10-12 2020-05-12 Samsung Electronics Co., Ltd. Method and apparatus for session control support for field of view virtual reality streaming
JP6969572B2 (ja) * 2016-10-25 2021-11-24 ソニーグループ株式会社 送信装置、送信方法、受信装置および受信方法
US9918135B1 (en) * 2017-02-07 2018-03-13 The Directv Group, Inc. Single button selection to facilitate actions in a communications network
CN109218821A (zh) * 2017-07-04 2019-01-15 阿里巴巴集团控股有限公司 视频的处理方法、装置、设备和计算机存储介质
US10630976B2 (en) * 2018-08-17 2020-04-21 Qualcomm Incorporated Display refresh blocks determination for video coding
CN110012310B (zh) * 2019-03-28 2020-09-25 北京大学深圳研究生院 一种基于自由视点的编解码方法及装置
US11373406B2 (en) * 2019-06-28 2022-06-28 Intel Corporation Transmission, caching, and searching of video streams based on frame dependencies and content
CN111479162B (zh) * 2020-04-07 2022-05-13 成都酷狗创业孵化器管理有限公司 直播数据传输方法、装置以及计算机可读存储介质

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100397511B1 (ko) * 2001-11-21 2003-09-13 한국전자통신연구원 양안식/다시점 3차원 동영상 처리 시스템 및 그 방법
JPWO2003092303A1 (ja) * 2002-04-25 2005-09-08 シャープ株式会社 マルチメディア情報生成装置およびマルチメディア情報再生装置
KR100585966B1 (ko) * 2004-05-21 2006-06-01 한국전자통신연구원 3차원 입체 영상 부가 데이터를 이용한 3차원 입체 디지털방송 송/수신 장치 및 그 방법
KR100636785B1 (ko) * 2005-05-31 2006-10-20 삼성전자주식회사 다시점 입체 영상 시스템 및 이에 적용되는 압축 및 복원방법
KR100747550B1 (ko) * 2005-12-09 2007-08-08 한국전자통신연구원 Ｄｍｂ 기반의 3차원 입체영상 서비스 제공 방법과, ｄｍｂ기반의 3차원 입체영상 서비스를 위한 복호화 장치 및 그방법
US20080043832A1 (en) * 2006-08-16 2008-02-21 Microsoft Corporation Techniques for variable resolution encoding and decoding of digital video
EP2393301A1 (en) * 2007-06-11 2011-12-07 Samsung Electronics Co., Ltd. Method and apparatus for generating header information of stereoscopic image
WO2008156318A2 (en) * 2007-06-19 2008-12-24 Electronics And Telecommunications Research Institute Metadata structure for storing and playing stereoscopic data, and method for storing stereoscopic content file using this metadata
KR100993428B1 (ko) * 2007-12-12 2010-11-09 한국전자통신연구원 Ｄｍｂ 연동형 스테레오스코픽 데이터 처리방법 및스테레오스코픽 데이터 처리장치
BRPI0820739B1 (pt) * 2007-12-14 2020-10-20 Koninklijke Philips N.V. método de reprodução de informação de vídeo, dispositivo de reprodução para reproduzir a informação de vídeo, sinal, e, portador de gravação
KR101506219B1 (ko) * 2008-03-25 2015-03-27 삼성전자주식회사 3차원 영상 컨텐츠 제공 방법, 재생 방법, 그 장치 및 그기록매체
KR20100040640A (ko) * 2008-10-10 2010-04-20 엘지전자 주식회사 수신 시스템 및 데이터 처리 방법
BRPI0922722A2 (pt) * 2008-12-09 2016-01-05 Sony Corp dispositivo e método de processamento de imagem
US8797231B2 (en) * 2009-04-15 2014-08-05 Nlt Technologies, Ltd. Display controller, display device, image processing method, and image processing program for a multiple viewpoint display
JP5416271B2 (ja) * 2009-04-20 2014-02-12 ドルビー ラボラトリーズ ライセンシング コーポレイション 多層映像配信のための適応補間フィルタ
US20110012993A1 (en) * 2009-07-14 2011-01-20 Panasonic Corporation Image reproducing apparatus
JP2011010255A (ja) * 2009-10-29 2011-01-13 Sony Corp 立体画像データ送信方法、立体画像データ受信装置および立体画像データ受信方法
JP4823349B2 (ja) * 2009-11-11 2011-11-24 パナソニック株式会社 三次元映像復号装置及び三次元映像復号方法
TW201234833A (en) * 2010-10-25 2012-08-16 Panasonic Corp Encoding method, display apparatus, and decoding method

Also Published As

Publication number Publication date
WO2013069604A1 (ja) 2013-05-16
CN103339945A (zh) 2013-10-02
EP2645725A4 (en) 2014-08-27
KR20140093168A (ko) 2014-07-25
JP2013255207A (ja) 2013-12-19
US20140071232A1 (en) 2014-03-13
EP2645725B1 (en) 2018-05-23
CN108471546A (zh) 2018-08-31
EP2645725A1 (en) 2013-10-02
KR102009048B1 (ko) 2019-08-08

Similar Documents

Publication Publication Date Title
JP6192902B2 (ja) 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法
JP5594002B2 (ja) 画像データ送信装置、画像データ送信方法および画像データ受信装置
US9756380B2 (en) Broadcast receiver and 3D video data processing method thereof
WO2013105401A1 (ja) 送信装置、送信方法、受信装置および受信方法
KR20110088334A (ko) 3차원 멀티미디어 서비스를 제공하기 위한 데이터스트림 생성 방법 및 장치, 3차원 멀티미디어 서비스를 제공하기 위한 데이터스트림 수신 방법 및 장치
US9485490B2 (en) Broadcast receiver and 3D video data processing method thereof
WO2013161442A1 (ja) 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法
KR101977260B1 (ko) 입체영상 디스플레이가 가능한 디지털 방송 수신방법 및 수신장치
WO2013073455A1 (ja) 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法
US9693033B2 (en) Transmitting apparatus, transmitting method, receiving apparatus and receiving method for transmission and reception of image data for stereoscopic display using multiview configuration and container with predetermined format
WO2013054775A1 (ja) 送信装置、送信方法、受信装置および受信方法
JP5928118B2 (ja) 送信装置、送信方法、受信装置および受信方法
WO2012147596A1 (ja) 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150128

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150128

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160510

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160704

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20160929

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170110

AA91 Notification that invitation to amend document was cancelled

Free format text: JAPANESE INTERMEDIATE CODE: A971091

Effective date: 20170124

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170131

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20170427

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170621

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170809

R150 Certificate of patent or registration of utility model

Ref document number: 6192902

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

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