(57)【要約】【課題】再生互換の取れない符号化方式で記録したコンテンツは、他機器では内容が確認できない。【解決手段】第一の映像情報を符号化し情報記録媒体に記録する装置であって、前記第一の映像情報が所定の符号化条件を満たす場合には、前記第一の映像情報を示す第二の映像情報を前記情報記録媒体に記録する。すなわち、再生互換が取りにくい符号化方式で記録したコンテンツには、必ずその代替となる情報（サムネイルのような映像情報）を付与することで、ユーザーに識別させる。【選択図】図２２
2007129368.tif 000002
【特許請求の範囲】
【請求項１】
第一の映像情報を符号化し情報記録媒体に記録する装置であって、前記第一の映像情報が所定の符号化条件を満たす場合には、前記第一の映像情報を示す第二の映像情報を前記情報記録媒体に記録することを特徴とする情報記録装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動画データを記録可能な記録媒体に静止画データを記録して、そのデータを管理する技術に関する。
【背景技術】
【０００２】
近年、ＤＶＤ等の光ディスクに映像および音声のデジタルデータを記録し、保存できる光ディスクレコーダの普及が進んでいる。記録される対象は、例えば放送された番組のデータストリームや、カムコーダ等によって撮影された映像および音声のデータストリームである。ユーザは記録されたデータをランダムアクセス可能な状態でＤＶＤ等に記録し、保存しておくことができる。
【０００３】
光ディスクレコーダは、動画のデータストリームのみならず、静止画データもＤＶＤに記録することができる。ユーザがデジタルスチルカメラやカムコーダを用いて静止画を撮影すると、それらに装填された半導体メモリカードに静止画データが記録される。光ディスクレコーダの中には、そのような半導体メモリカードを装填するためのスロットが設けられているものが存在する。ユーザがカムコーダ等から取り外した半導体メモリカードをそのスロットに挿入し、静止画データを光ディスクレコーダに装填されたＤＶＤにコピーすることにより、静止画データがＤＶＤに記録される。
【０００４】
静止画データを記録媒体に記録する技術に関して、ＤＣＦ（Ｄｅｓｉｇｎ  ｒｕｌｅ  ｆｏｒ  Ｃａｍｅｒａ  Ｆｉｌｅ  ｓｙｓｔｅｍ）規格）が策定され普及が進んでいる。ＤＣＦ規格は記録媒体上に記録される静止画ファイルの名前やファイルフォーマットと、それらを格納するディレクトリ構造を規定している。例えば、特許文献１は、ＤＣＦ規格に基づくデータの蓄積に関する技術を開示している。ＤＣＦ規格に従ってディレクトリを構築し、静止画データを記録することにより、記録媒体の種類にかかわらず、また再生機器のメーカにかかわらず、静止画データが再生される。
【０００５】
上述のように、ＤＶＤには動画データおよび静止画データが記録され得るため、記録された種々のデータの内容を容易に把握することができればユーザは非常に便利である。そこで、多くの光ディスクレコーダは、再生対象を選択する際のメニュー画面に、動画データの一場面を示すサムネイルピクチャを表示したり、静止画データを縮小表示することにより、ユーザが所望のコンテンツへ非常に素早くアクセスできるように便宜を図っている。
【特許文献１】特開２００２−１１６９４６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
現在のＤＶＤカムコーダやＳＤカードを使ったモバイル向けムービー、もしくは放送を録画するレコーダでは、動画の圧縮符号化方式としてＤＶＤ−Ｖｉｄｅｏやデジタル放送で使用されているＭＰＥＧ−２  Ｖｉｄｅｏを使っていることが多い。
【０００７】
既に普及したＭＰＥＧ−２  Ｖｉｄｅｏのような符号化方式では再生互換の問題が表面化し難いが、ＭＰＥＧ−２  Ｖｉｄｅｏよりも圧縮効率が高いＭＰＥＧ−４  ＡＶＣ（MPEG-4 Advanced Video Coding）のように新しく、かつ複合処理の実装対応が難しい符号化方式をムービーやレコーダが使う場合には、撮影した動画を他のムービーやレコーダ（つまり再生装置）で再生できなくなる課題がある。
【０００８】
本発明の目的は、このように再生互換性の確保が難しい符号化処理を用いた映像（例えば動画）を拡張性の高いデータ構造に基づいて情報記録媒体（例えばＤＶＤ）に記録する場合に、その符号化処理に対応しておらず、映像を再生（複合）することができない他の再生装置であっても、ユーザーに記録されている映像の内容が識別できるような記録媒体（システム）を提供することである。
【課題を解決するための手段】
【０００９】
上記課題を解決するため、本発明による情報記録装置は、第一の映像情報を符号化し情報記録媒体に記録する装置であって、前記第一の映像情報が所定の符号化条件を満たす場合には、前記第一の映像情報を示す第二の映像情報を前記情報記録媒体に記録することを特徴とする情報記録装置としている。
【発明の効果】
【００１０】
本発明では、上記解決手段を講じる事によって、ディスク上に記録されているコンテンツがデコードできなくても、副映像を利用してユーザーが識別できるようになる。
【００１１】
また、ＤＶＤ−Ｖｉｄｅｏのようなディスクメニューを生成する場合においても、ムービー／レコーダが動画ストリームがデコードできない場合であっても、副映像（サムネイル）を使った分かりやすいメニューを生成することが可能となる。
【発明を実施するための最良の形態】
【００１２】
以下、添付の図面を参照して、本発明によるデータ処理装置の実施形態を説明する。実施形態においては、データ処理装置は光ディスクレコーダであるとして説明する。
【００１３】
図１は、本実施形態による光ディスクレコーダ１００と他の機器とによって形成されるシステムの構成を示す。光ディスクレコーダ１００（以下「レコーダ１００」と記述する）は、放送番組の映像および音声に関する動画のデータストリームをブルーレイディスク（Ｂｌｕ−ｒａｙ  Ｄｉｓｃ；ＢＤ）１１４に記録する録画機能を有する。またレコーダ１００は、ＢＤ１１４に記録されたデータストリームを読み出して動画を再生する再生機能も有する。図１では、レコーダ１００の録画機能および再生機能に関連して連携することが可能な他の機器を示している。レコーダ１００の録画機能および再生機能に関する処理は、リモコン１１６や、レコーダ１００本体のボタン（図示せず）等を利用してユーザが与えた指示に基づいて行われる。なお、ＢＤには青色半導体レーザを利用してデータが書き込まれ、読み出される。本明細書においてはＢＤの階層構造およびＢＤの記録／再生機能に関する装置の構成を説明する。しかしこれは例であり、ＢＤ以外の記録媒体、例えばＳＤメモリカードやＨＤＤ、ＤＶＤディスクなどを用いてもよい。
【００１４】
まず、レコーダ１００の録画機能に関連する処理を説明する。レコーダ１００は、デジタル放送番組に関するデジタル信号を受信するアンテナ１０２ａ、および、アナログ放送番組に関するアナログ信号を受信するアンテナ１０２ｂと接続され、デジタル信号およびアナログ信号を受信する。レコーダ１００は、例えば同軸ケーブル１０４を介してデジタル信号およびアナログ信号を受け取る。
【００１５】
デジタル信号は、ＭＰＥＧ−２トランスポートストリーム（以下「トランスポートストリーム」または「ＴＳ」と記述する）として伝送されている。ＴＳを受信した場合には、レコーダ１００は、そのＴＳに所定の処理を行い、後述するＴＳのパケット構造を保持しながらＢＤ１１４に記録する。アナログ信号を受信した場合には、レコーダ１００は、そのアナログ信号から得られた動画のデータを圧縮符号化してＴＳを生成し、そのＴＳをＢＤ１１４に記録する。さらにレコーダ１００は、ＳＤメモリカード等のメモリカード１１２に放送番組を録画することもでき、また、メモリカード１１２に記録された静止画データをＢＤ１１４にコピーすることもできる。
【００１６】
次に、レコーダ１００の再生機能に関連する処理を説明する。レコーダ１００はＢＤ１１４に記録された映像および音声を復号化し、ＴＶ１０６、スピーカ（図示せず）等を介して再生する。この映像および音声は放送番組に限られることはなく、例えばカムコーダ１１０やデジタルスチルカメラ、携帯電話の映像撮影機器によって記録された映像および音声であってもよい。なお、映像および音声が記録されたＢＤ１１４は、レコーダ１００から取り出されてＰＣ１０８等の他の機器に装填され、その機器が再生してもよい。
【００１７】
ここで、図２〜図４を参照しながら、デジタル放送信号として伝送されるトランスポートストリームのデータ構造を説明する。
【００１８】
図２は、トランスポートストリーム（ＴＳ）２０のデータ構造を示す。ＴＳパケットは、例えば、圧縮されたビデオデータが格納されたビデオＴＳパケット（Ｖ＿ＴＳＰ）３０、圧縮されたオーディオデータが格納されたオーディオＴＳパケット（Ａ＿ＴＳＰ）３１の他、番組表（プログラム・アソシエーション・テーブル；ＰＡＴ）が格納されたパケット（ＰＡＴ＿ＴＳＰ）、番組対応表（プログラム・マップ・テーブル；ＰＭＴ）が格納されたパケット（ＰＭＴ＿ＴＳＰ）およびプログラム・クロック・リファレンス（ＰＣＲ）が格納されたパケット（ＰＣＲ＿ＴＳＰ）等を含む。各ＴＳパケットのデータ量は１８８バイトである。また、ＰＡＴ＿ＴＳＰ、ＰＭＴ＿ＴＳＰ等のＴＳの番組構成を記述するＴＳパケットを一般に、ＰＳＩ／ＳＩパケットと呼ぶ。
【００１９】
以下、本発明の処理に関連するビデオＴＳパケットおよびオーディオＴＳパケットを説明する。図３（ａ）はビデオＴＳパケット３０のデータ構造を示す。ビデオＴＳパケット３０は、４バイトのトランスポートパケットヘッダ３０ａ、および、１８４バイトのトランスポートパケットペイロード３０ｂを有する。ペイロード３０ｂにはビデオデータ３０ｂが格納されている。一方、図３（ｂ）は、オーディオＴＳパケット３１のデータ構造を示す。オーディオＴＳパケット３１も同様に、４バイトのトランスポートパケットヘッダ３１ａ、および、１８４バイトのトランスポートパケットペイロード３１ｂを有する。
オーディオデータ３１ｂはトランスポートパケットペイロード３１ｂに格納されている。
【００２０】
上述の例から理解されるように、一般にＴＳパケットは４バイトのトランスポートパケットヘッダと、１８４バイトのエレメンタリデータとから構成されている。パケットヘッダには、そのパケットの種類を特定するパケット識別子（Ｐａｃｋｅｔ  ＩＤｅｎｔｉｆｉｅｒ；ＰＩＤ）が記述されている。例えば、ビデオＴＳパケットのＰＩＤは"０ｘ００２０"であり、オーディオＴＳパケットのＰＩＤは"０ｘ００２１"である。エレメンタリデータは、ビデオデータ、オーディオデータ等のコンテンツデータや、再生を制御するための制御データ等である。どのようなデータが格納されているかは、パケットの種類に応じて異なる。
【００２１】
以下、ビデオデータを例に挙げて、映像を構成するピクチャとの関係を説明する。図４（ａ）〜（ｄ）は、ビデオＴＳパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す。図４（ａ）に示すように、ＴＳ４０は、ビデオＴＳパケット４０ａ〜４０ｄを含む。なお、ＴＳ４０には、他のパケットも含まれ得るが、ここではビデオＴＳパケットのみを示している。ビデオＴＳパケットは、ヘッダ４０ａ−１に格納されたＰＩＤによって容易に特定される。
【００２２】
ビデオデータ４０ａ−２等の各ビデオＴＳパケットのビデオデータから、パケット化エレメンタリストリームが構成される。図４（ｂ）は、パケット化エレメンタリストリーム（ＰＥＳ）４１のデータ構造を示す。ＰＥＳ４１は、複数のＰＥＳパケット４１ａ、４１ｂ等から構成される。ＰＥＳパケット４１ａは、ＰＥＳヘッダ４１ａ−１およびＰＥＳペイロード４１ａ−２から構成されており、これらのデータがビデオＴＳパケットのビデオデータとして格納されている。
【００２３】
ＰＥＳペイロード４１ａ−２は、それぞれが１つのピクチャのデータを含んでいる。ＰＥＳペイロード４１ａ−２から、エレメンタリストリームが構成される。図４（ｃ）は、エレメンタリストリーム（ＥＳ）４２のデータ構造を示す。ＥＳ４２は、ピクチャヘッダ、および、ピクチャデータの組を複数有している。なお、「ピクチャ」とは一般にフレームおよびフィールドのいずれも含む概念として用いられる。
【００２４】
図４（ｃ）に示すピクチャヘッダ４２ａには、その後に配置されたピクチャデータ４２ｂのピクチャ種別を特定するピクチャコーディングタイプが記述され、ピクチャヘッダ４２ｃにはピクチャデータ４２ｄのピクチャ種別を特定するピクチャコーディングタイプが記述されている。種別とは、Ｉピクチャ（Ｉｎｔｒａ−ｃｏｄｅｄ  ｐｉｃｔｕｒｅ）、Ｐピクチャ（Ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ  ｐｉｃｔｕｒｅ）またはＢピクチャ（Ｂｉｄｉｒｅｃｔｉｏｎａｌｌｙ−ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ  ｐｉｃｔｕｒｅ）を表す。種別がＩピクチャであれば、そのピクチャコーディングタイプは、例えば"００１ｂ"である。
【００２５】
ピクチャデータ４２ｂ、４２ｄ等は、そのデータのみによって、または、そのデータとその前および／または後に復号化されるデータとによって構築可能な１枚分のフレームのデータである。例えば図４（ｄ）は、ピクチャデータ４２ｂから構築されるピクチャ４３ａおよびピクチャデータ４２ｄから構築されるピクチャ４３ｂを示す。
【００２６】
ＴＳに基づいて映像を再生する際、レコーダ１００はビデオＴＳパケットを取得して上述の処理にしたがってピクチャデータを取得し、映像を構成するピクチャを取得する。これにより映像をＴＶ１０６上に再生することができる。
【００２７】
次に、図５を参照しながら、本実施形態によるレコーダ１００の構成を説明する。図５は、レコーダ１００の機能ブロックの構成を示す。レコーダ１００は、記録媒体としてＢＤ２０５ａのみならず、ハードディスク２０５ｂをも有している。すなわちレコーダ１００は、ＨＤＤ２０５ｂを内蔵したＢＤレコーダである。
【００２８】
レコーダ１００は、デジタルチューナ２０１ａおよびアナログチューナ２０１ｂと、ＡＤコンバータ２０２と、ＭＰＥＧ−２エンコーダ２０３と、ＴＳ処理部２０４と、ＭＰＥＧ−２デコーダ２０６と、グラフィック制御部２０７と、メモリ２０８と、ＤＡコンバータ２０９と、ＣＰＵバス２１３と、ネットワーク制御部２１４と、指示受信部２１５と、インターフェース（Ｉ／Ｆ）部２１６と、メモリカード制御部２１７と、システム制御部２５０とを含む。なお、図５には、光ディスク２０５ａがレコーダ１００内に記載されているが、光ディスク２０５ａは光ディスクレコーダ１００から取り外し可能であり、レコーダ１００自体の構成要素ではない。
【００２９】
以下、各構成要素の機能を説明する。デジタルチューナ２０１ａは、アンテナ１０２ａ（図１）から１以上の番組が含まれるデジタル信号を受け取る。デジタル信号として伝送されるトランスポートストリームには複数の番組のパケットが混在している。複数の番組のパケットを含むトランスポートストリームは"フルＴＳ"と呼ばれる。デジタルチューナ２０１ａは、選局を行ってフルＴＳから必要な番組のパケットのみを取り出し、"パーシャルＴＳ"として出力する。
【００３０】
フルＴＳから所望のチャンネルのパケットを取り出す手順は以下のとおりである。いま、希望の番組の番組番号（チャンネル番号）をＸとする。まずはじめに、フルＴＳから番組表パケット（図２のＰＡＴ＿ＴＳＰ）が検索される。番組表パケットのパケットＩＤ（ＰＩＤ）には、必ず０が与えられているので、その値を有するパケットを検索すればよい。番組表パケット内の番組表には、各番組番号と、その番組番号に対応する各番組の番組対応表パケット（図２のＰＭＴ＿ＴＳＰ）のＰＩＤが格納されている。これにより、番組番号Ｘに対応する番組対応表ＰＭＴのパケットＩＤ（ＰＩＤ）を特定できる。番組対応表ＰＭＴのＰＩＤをＸＸとする。
【００３１】
次に、ＰＩＤ＝ＸＸが付された番組対応表パケット（図２のＰＭＴ＿ＴＳＰ）を抽出すると、番組番号Ｘに対応する番組対応表ＰＭＴが得られる。番組対応表ＰＭＴには、番組ごとに、視聴の対象として各番組を構成する映像・音声情報等が格納されたＴＳパケットのＰＩＤが格納されている。例えば、番組番号Ｘの映像情報のＰＩＤはＸＶであり、音声情報のＰＩＤはＸＡである。このようにして得られた映像情報を格納したパケットのＰＩＤ（＝ＸＶ）と、音声情報を格納したパケットのＰＩＤ（＝ＸＡ）とを利用して、フルＴＳから特定の番組に関する映像・音声のパケットを抽出できる。
【００３２】
なお、フルＴＳからパーシャルＴＳを生成する際には、必要な映像・音声情報を格納したパケットを取り出すだけでなく、ＰＳＩ（Ｐｒｏｇｒａｍ  Ｓｐｅｃｉｆｉｃ  Ｉｎｆｏｒｍａｔｉｏｎ）パケットおよびＳＩ（Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ）パケットも抽出および変更する必要がある。ＰＳＩパケットとは、図２に示す番組表パケット（ＰＡＴ＿ＴＳＰ）および番組対応表パケット（ＰＭＴ＿ＴＳＰ）等を総称するパケットである。ＰＳＩパケットを修正する理由は、フルＴＳとパーシャルＴＳとでは含まれる番組数等が異なるため、番組表および番組対応表をパーシャルＴＳに適合させる必要が生じるからである。一方、ＳＩパケットとは、フルＴＳに含まれる番組の内容、スケジュール／タイミング等を記述するデータ、独自に定義された拡張情報（これらは「番組配列情報」とも呼ばれる）等を含むパケットである。フルＴＳではＳＩパケットに含まれるデータは２０〜３０種類にも上る。これらのデータのうち、パーシャルＴＳの再生等に関して重要なデータのみが抽出されて１つのＳＩＴパケットが生成され、パーシャルＴＳ内に多重化される。またパーシャルＴＳでは、ＳＩＴパケットにはそのストリームがパーシャルＴＳであることを示す情報（ｐａｒｔｉａｌ  ｔｒａｎｓｐｏｒｔ  ｓｔｒｅａｍ  ｄｅｓｃｒｉｐｔｏｒ）が格納されている。パーシャルＴＳ内にＳＩＴパケットを多重化することは慣用されている。これは、欧州／日本のデジタル放送規定（ＤＶＢ／ＡＲＩＢ）との整合性のためである。
【００３３】
アナログチューナ２０１ｂは、アンテナ１０２ｂ（図１）からアナログ信号を受け取り、周波数に基づいて選局を行って必要な番組の信号を取り出す。そして番組の映像および音声信号をＡＤコンバータ２０２に出力する。なお、図１ではレコーダ１００は同軸ケーブル１０４を介してデジタル信号およびアナログ信号を取得しているため、図５に入力される信号系統は厳密には１本である。しかし、デジタル信号およびアナログ信号は周波数によって容易に分離できるため、図５ではデジタル信号およびアナログ信号が別系統で入力されているように記載している。
【００３４】
ＡＤコンバータ２０２は入力された信号をデジタル変換してＭＰＥＧ−２エンコーダ２０３に供給する。ＭＰＥＧ−２エンコーダ２０３（以下「エンコーダ２０３」と記述する）は、録画の開始指示を受け取ると、供給されたアナログ放送のデジタルデータをＭＰＥＧ−２形式に圧縮符号化してトランスポートストリームを生成し、ＴＳ処理部２０４に入力する。この処理は、エンコーダ２０３が録画の終了指示を受け取るまで継続される。エンコーダ２０３は圧縮符号化を行うために、参照ピクチャ等を一時的に保持するバッファ（図示せず）等を有している。
【００３５】
ＴＳ処理部２０４は、動画の記録時にはパーシャルＴＳを受け取り、クリップＡＶストリーム（ＣｌｉｐＡＶストリーム）を生成し、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録する。クリップＡＶストリームとは、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録するための形式を有するデータストリームである。クリップＡＶストリームは複数の「ソースパケット」から構成されており、「ソースパケット」はパーシャルＴＳを構成する各ＴＳパケットに所定のヘッダを付加して生成される。なお、クリップＡＶストリームを生成する際の処理の詳細は、図７（ａ）〜（ｅ）に関連して後述する。
【００３６】
ＴＳ処理部２０４は、動画の再生時には、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂからクリップＡＶストリームを読み出し、そのクリップＡＶストリームに基づいてパーシャルＴＳを生成してＭＰＥＧ−２デコーダ２０６に出力する。
【００３７】
また、ＴＳ処理部２０４は、後述するメモリカード制御部２１７からメモリカード１１２に格納された静止画データを受け取り、その静止画を加工することなくそのままＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録する。また、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録された静止画データを読み出してデコーダ２０６に出力することもできる。ＴＳ処理部２０４のさらに具体的な構成および動作は、後に図６および図７を参照しながら詳述する。なお、本明細書では、ＴＳ処理部２０４がＢＤ２０５ａおよび／またはＨＤＤ２０５ｂにデータを記録し、またはそれらからデータを読み出すとして説明しているが、これは説明の便宜のためである。ＢＤ２０５ａやＨＤＤ２０５ｂに対するストリームの書き込みや読み出しは、実際には、ディスクの回転、ヘッドの移動とともに各々のドライブ装置に設けられたコントローラ（図示せず）が行っている。
【００３８】
ＭＰＥＧ−２デコーダ２０６（以下「デコーダ２０６」と記述する）は、供給されたパーシャルＴＳを解析してＭＰＥＧ−２圧縮符号化データを取得する。そして、その圧縮符号化データを伸長して非圧縮データに変換し、グラフィック制御部２０７に供給する。また、デコーダ２０６は、ＭＰＥＧ−２規格の圧縮符号化データのみならず、例えばＪＰＥＧ規格に従った静止画データも非圧縮データに変換することができる。グラフィック制御部２０７には内部演算用のメモリ２０８が接続されており、オン・スクリーン・ディスプレイ（Ｏｎ  Ｓｃｒｅｅｎ  Ｄｉｓｐｌａｙ；ＯＳＤ）機能を実現できる。例えば、グラフィック制御部２０７は種々のメニュー画像と映像とを合成してＤＡコンバータ２０９に出力することができる。ＤＡコンバータ２０９は、入力されたＯＳＤ合成画像および音声データをアナログ変換して出力する。出力先は、例えばＴＶ１０６である。
【００３９】
ＣＰＵバス２１３はレコーダ１００内の信号を伝送する経路であり、図示されるように各機能ブロックと接続されている。また、ＣＰＵバス２１３には、後述するシステム制御部２５０の各構成要素も接続されている。
【００４０】
ネットワーク制御部２１４は、レコーダ１００をインターネット等のネットワーク１０１に接続するためのインターフェイスであり、例えば、イーサネット（登録商標）規格に準拠した端子およびコントローラである。ネットワーク制御部２１４は、ネットワーク１０１を介してデータを授受する。このデータは、例えば放送番組に関する番組表のデータや、レコーダ１００の動作を制御するためのソフトウェアプログラムの更新データである。
【００４１】
指示受信部２１５は、レコーダ１００の本体部に設けられた操作ボタン、または、リモートコントローラからの赤外線を受光する受光部である。指示受信部２１５は、ユーザから、例えば録画の開始／停止、録画した番組の再生の開始／停止等の指示や、装填されたメモリカード１１２の静止画をＢＤ２０５ａまたはＨＤＤ２０５ｂにコピーする指示を与える。
【００４２】
インターフェース（Ｉ／Ｆ）部２１６は、レコーダ１００が他の機器と通信するためのコネクタおよびその通信を制御する。Ｉ／Ｆ部２１６は、例えばＵＳＢ２．０規格の端子、ＩＥＥＥ１３９４規格の端子および各規格によるデータ通信を可能とするコントローラを含み、各規格に準拠した方式でデータを授受することができる。例えば、レコーダ１００は、ＵＳＢ２．０規格の端子を介してＰＣ１０８や、カムコーダ（図示せず）等と接続され、ＩＥＥＥ１３９４規格の端子の端子を介してデジタルハイビジョンチューナや、カムコーダ（図示せず）等と接続される。
【００４３】
メモリカード制御部２１７は、メモリカード１１２をレコーダ１００に装填するためのスロット、および、レコーダ１００とメモリカード１１２との間のデータ通信を制御するコントローラである。メモリカード制御部２１７は、装填されたメモリカード１１２から静止画データファイル、動画データファイル等を読み出して、ＣＰＵバス２１３に伝送する。
【００４４】
システム制御部２５０は、レコーダ１００内の信号の流れを含む全体的な処理を制御する。システム制御部２５０は、プログラムＲＯＭ２１０と、ＣＰＵ２１１と、ＲＡＭ２１２とを有している。それぞれはＣＰＵバス２１３に接続されている。プログラムＲＯＭ２１０にはレコーダ１００を制御するためのソフトウェアプログラムが格納されている。
【００４５】
ＣＰＵ２１１は、レコーダ１００の全体の動作を制御する中央制御ユニットである。ＣＰＵ２１１は、プログラムを読み出して実行することにより、プログラムに基づいて規定される処理を実現するための制御信号を生成し、ＣＰＵバス２１３を介して各構成要素に出力する。メモリ２１２は、ＣＰＵ２１１がプログラムを実行するために必要なデータを格納するためのワーク領域を有する。例えば、ＣＰＵ２１１は、ＣＰＵバス２１３を使用してプログラムＲＯＭ２１０からプログラムをランダムアクセスメモリ（ＲＡＭ）２１２に読み出し、そのプログラムを実行する。なお、コンピュータプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録して市場に流通され、または、インターネット等の電気通信回線を通じて伝送される。これにより、ＰＣ等を利用して構成されたコンピュータシステムを、本実施形態によるレコーダ１００と同等の機能を有するデータ処理装置として動作させることができる。
【００４６】
図６は、ＴＳ処理部２０４の詳細な機能ブロックの構成を示す。ＴＳ処理部２０４は、ソース・パケタイザ２６１と、クロックカウンタ２６２と、ＰＬＬ回路２６３と、バッファ２６４と、ソース・デ・パケタイザ２６５とを有する。
【００４７】
ソース・パケタイザ２６１は、パーシャルＴＳを受け取り、そのパーシャルＴＳを構成するＴＳパケットの前に所定のヘッダを付加してソースパケットを生成して出力する。ヘッダには、そのＴＳパケットを受信した時刻（すなわちそのＴＳパケットの到着時刻）を示す時刻情報ＡＴＳ（Ａｒｒｉｖａｌ  Ｔｉｍｅ  Ｓｔａｍｐ）が含まれている。ＴＳパケットの到着時刻は、ソース・パケタイザ２６１に与えられる基準時刻からのカウント値（カウント情報）に基づいて特定される。ＴＳパケットの到着時刻に関する情報を含める理由は、図７を参照しながら後述する。
【００４８】
クロックカウンタ２６２およびＰＬＬ回路２６３は、ソース・パケタイザ２６１がＴＳパケットの到着時刻を特定するために必要な情報を生成する。まずＰＬＬ回路２６３は、パーシャルＴＳに含まれるＰＣＲパケット（図２のＰＣＲ＿ＴＳＰ）を抽出して、基準時刻を示すＰＣＲ（Ｐｒｏｇｒａｍ  Ｃｌｏｃｋ    Ｒｅｆｅｒｅｎｃｅ：プログラム時刻基準参照値）を取得する。ＰＣＲの値と同じ値がレコーダ１００のシステム基準時刻ＳＴＣ（Ｓｙｓｔｅｍ  Ｔｉｍｅ  Ｃｌｏｃｋ）として設定され、ＳＴＣが基準時刻とされる。システム基準時刻ＳＴＣのシステムクロックの周波数は２７ＭＨｚである。ＰＬＬ回路２６３は、２７ＭＨｚのクロック信号をクロックカウンタ２６２に出力する。クロックカウンタ２６２はクロック信号を受け取り、そのクロック信号をカウント情報としてソース・パケタイザ２６１に出力される。
【００４９】
バッファ２６４は、ライトバッファ２６４ａおよびリードバッファ２６４ｂを有する。ライトバッファ２６４ａは、送られてきたソースパケットを逐次保持し、合計のデータ量が所定値（例えばバッファの全容量）になったときに、書き込みのためにＢＤ２０５ａ等に出力する。このとき出力される一連のソースパケット列（データストリーム）を、クリップＡＶストリームと呼ぶ。一方、リードバッファ２６４ｂは、ＢＤ２０５ａ等から読み出されたクリップＡＶストリームを一時的にバッファして、ソースパケット単位で出力する。
【００５０】
ソース・デ・パケタイザ２６５は、ソースパケットを受け取ってＴＳパケットに変換し、パーシャルＴＳとして出力する。留意すべきは、ソース・デ・パケタイザ２６５は、クロックカウンタ２６２から与えられるタイミング情報と、ソースパケットに含まれていたＴＳパケットの到着時刻情報ＡＴＳとに基づいて、元の到着時刻に対応する時間間隔でＴＳパケットを出力することである。これにより、ＴＳ処理部２０４は、記録時のＴＳパケットの到着タイミングと同じタイミングで、ＴＳパケットを出力することができる。なお、ソース・デ・パケタイザ２６５は、読み出したパーシャルＴＳの基準時刻を指定するために、例えば最初のソースパケットにおいて指定されている到着時刻を初期値としてクロックカウンタ２６２に送る。これにより、クロックカウンタ２６２においてその初期値からカウントを開始させることができ、よってその後のカウント結果をタイミング情報として受け取ることができる。
【００５１】
ここで、図７を参照しながら、ＴＳ処理部２０４において行われる処理を具体的に説明する。図７（ａ）〜（ｅ）は、トランスポートストリームとクリップＡＶストリームとの関係を示す。参考のため、図７（ａ）にフルＴＳ７０を示している。フルＴＳ７０は、ＴＳパケットが連続して配置されており、例えば３つの番組Ｘ，ＹおよびＺのデータを含む。図７（ｂ）は、デジタルチューナ２０１ａによってフルＴＳ７０から生成されたパーシャルＴＳ７１を示す。パーシャルＴＳ７１は、連続したフルＴＳから一部のパケットを取り出したストリームであるため、パケットが時間的に離散して存在している。このパケットの間隔は、フルＴＳの送信側によって調整されており、デコーダにおいてデコードが適正に行われるために必要な条件を満たす。この「条件」とは、ＭＰＥＧ−２ＴＳの理想モデルとして規定されたＴ−ＳＴＤ（ＴＳシステムターゲットデコーダ；ＴＳ  Ｓｙｓｔｅｍ  Ｔａｒｇｅｔ  Ｄｅｃｏｄｅｒ）のバッファメモリがオーバーフローおよびアンダーフローを引き起こさないためにＭＰＥＧ規格上定められた条件である。
【００５２】
パーシャルＴＳ７１は、例えば番組Ｘに関するＴＳパケットを含んでいる。
図７（ｃ）は、クリップＡＶストリーム７２を示す。クリップＡＶストリーム７２は、ソースパケットが連続して配列されている。各ソースパケットは、ソースパケット番号（ＳＰＮ）＃１、２、３・・・で区別される。
【００５３】
図７（ｄ）は、ソースパケット７３のデータ構造を示す。ソースパケット７３のデータ長は１９２バイトに固定されている。すなわち、各ソースパケット７３は、１８８バイトのＴＳパケット７５の前に、４バイトのＴＰエクストラヘッダ７４を付加して構成されている。ソース・パケタイザ２６１は、パーシャルＴＳを構成するＴＳパケットの前にＴＰエクストラヘッダ７４を付加することにより、ソースパケットを生成している。
【００５４】
図７（ｅ）は、ＴＰエクストラヘッダ７４のデータ構造を示す。ＴＰエクストラヘッダ７４は、２ビットのコピー許可インジケータ（ＣＰＩ）７６と、３０ビットの到着タイムスタンプＡＴＳ７７とから構成されている。コピー許可インジケータ（ＣＰＩ）７６は、そのビット値に応じて、クリップＡＶストリーム７２の全部または一部のコピー回数（０回（コピー不可）／１回のみ／制限なし等）を規定している。到着タイムスタンプＡＴＳ７７には、９０ｋＨｚ精度で時刻が記述される。
【００５５】
なお、図７（ｃ）に記載されたクリップＡＶストリーム７２は、例えば３２個のソースパケットの集合（６ＫＢ）を１つの単位としてＢＤ２０５ａ等に記録される。このような単位をアラインド・ユニットという。アラインド・ユニットを規定する理由は、ＢＤ２０５ａが１セクタ２ＫＢであるため、３２ソースパケットの単位でセクタとのアライメントが確保できるためである。
【００５６】
次に、図８を参照しながら、クリップＡＶストリームがどのようにＢＤ２０５ａ上に記録されるかを説明する。なお、クリップＡＶストリームはＨＤＤ２０５ｂにも記録され得るため、同様のデータ構造によって記録することができる。ただし、ＨＤＤ２０５ｂは一般にレコーダ１００から取り外されて他の機器に装填されることはないため、独自のデータ構造によってデータを記録してもよい。
【００５７】
図８は、ＢＤ２０５ａの記録領域と、そのディレクトリ／ファイル構造を示す。ＢＤ２０５ａは、ギャザード・ファイル領域８１とリアルタイム・データ領域８２とを有する。ギャザード・ファイル領域８１の記録容量は数百メガバイトである。ギャザード・ファイル領域８１には、クリップＡＶストリームの再生等を管理する管理情報のファイル（データベースファイル）が記録される。図８に示すように、データベースファイルは複数種類存在しており、例えば管理ファイル８２（Ｉｎｆｏ．ｂｄａｖ）、プレイリストファイル８３（０１００１．ｒｐｌｓ、１００００．ｖｐｌｓ）、クリップ情報ファイル８４（０１０００．ｃｌｐｉ）が存在する。これらはアクセスされる頻度が高い。よって、ギャザード・ファイル領域８１は効率的にアクセスが可能な、ＢＤ２０５ａの記録領域の中間部に設けられている。また、データベースファイルはクリップＡＶストリーム等の動画ストリームを再生するために必須であり、記録内容の誤りは重大な障害を引き起こす。そのため、データベースファイルは同じＢＤ２０５ａ上にバックアップされる。
【００５８】
一方、リアルタイム・データ領域８２の記録容量は２３〜２７ギガバイトである。リアルタイム・データ領域８２には、クリップＡＶストリームのストリームファイルが記録される。例えばクリップＡＶストリームファイル８５（０１０００．ｍ２ｔｓ）が記録される。先のデータベースファイルと異なり、ストリームファイルの再生誤りの影響は局所的であり、その一方、連続的な読み出しを確保する必要がある。よって、誤りの発生を低減するよりも、連続読み出しを保証する方に重点をおいた書き込み処理が行われる。具体的には、クリップＡＶストリームファイル８５は最小で１２Ｍバイトの連続領域（連続した論理セクタ）に記録される。この最小の記録データサイズは「エクステント」と呼ばれる。なお、リアルタイム・データ領域８２には、ＤＶストリームを記録することもできるが、以下ではクリップＡＶストリームが記録されているとして説明する。
【００５９】
次に、図９を参照しながら、上述の管理ファイル８２、プレイリストファイル８３、クリップ情報ファイル８４およびクリップＡＶストリームファイル８５相互の関係を説明する。図９（ａ）〜（ｄ）は、管理情報とストリームデータとの関係を示す。図９（ａ）〜（ｃ）が管理情報であり、図９（ｄ）がストリームデータである。図９（ａ）は管理ファイル８２（Ｉｎｆｏ．ｂｄａｖ）に記述されるプレイリストのテーブルを示す。すなわち、管理ファイル８２には、ＢＤ２０５ａ上に存在するプレイリストを特定するプレイリストファイル名のテーブルが格納されている。ここで「プレイリスト」とは、１以上のクリップＡＶストリームの一部または全部に跨る再生経路を規定した情報である。
【００６０】
図９（ｂ）は、プレイリストファイル８３（拡張子：ｒｐｌｓ／ｖｐｌｓ）に記述されるプレイリストを示す。プレイリストは、リアルプレイリストおよびバーチャルプレイリストに分類できる。リアルプレイリストは、例えば初めてストリームデータが記録されたときにレコーダ１００によって生成されるプレイリストであり、再生経路として動画の最初から最後までが指定される。一方、バーチャルプレイリストは、記録されたストリームデータに対してユーザが設定したプレイリストであり、ユーザの希望する任意の位置および区間が指定される。
【００６１】
プレイリストの各区間は、プレイリスト内の各プレイアイテムにおいて規定される。すなわち、プレイアイテムには、再生開始位置に対応する開始時刻（Ｉｎ＿ｔｉｍｅ）および再生終了位置に対応する終了時刻（Ｏｕｔ＿ｔｉｍｅ）が記述される。開始時刻および終了時刻は、映像のフレームの再生表示時刻や音声のフレームの再生出力時刻を特定するプレゼンテーションタイムスタンプ（ＰＴＳ）によって記述される。通常、記録直後のリアルプレイリストではプレイアイテムは１つだけ設けられ、動画の最初と最後の時刻が指定される。一方、バーチャルプレイリストではプレイアイテムの数は任意である。１つのバーチャルプレイリストに複数のプレイアイテムを設け、各プレイアイテムが異なる動画ストリームを指定するように記述することもできる。
【００６２】
図９（ｃ）はクリップ情報ファイル８４（拡張子：ｃｌｐｉ）に記述される時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）８４を示す。変換テーブル（ＥＰ＿ｍａｐ）８４は、クリップＡＶストリームの再生時刻と、その時刻に再生されるデータが格納されたアドレスとを対応付けたテーブルである。この変換テーブル８４を利用することにより、プレイアイテムにおいて指定される開始時刻（Ｉｎ＿ｔｉｍｅ）および終了時刻（Ｏｕｔ＿ｔｉｍｅ）から、その時刻に再生すべきデータが格納されたクリップＡＶストリームにおけるアドレスを特定することができる。なお、この変換テーブル８４を利用した変換の原理は、後に図１３から図１５を参照しながら詳述する。
【００６３】
図９（ｄ）は、クリップＡＶストリームファイル８５（拡張子：ｍ２ｔｓ）に格納される動画ストリームを示す。この図では、ファイル"０１０００．ｍ２ｔｓ"および"０２０００．ｍ２ｔｓ"の各々がクリップＡＶストリームファイルである。
【００６４】
図９（ｃ）および（ｄ）に示すように、ＢＤ２０５ａ上では、１つのクリップＡＶストリームファイルに対して１つのクリップ情報ファイルが設けられる。以下では、クリップＡＶストリームファイルと、クリップ情報ファイルの対を、クリップ（Ｃｌｉｐ）と称する。
【００６５】
図１０は、プレイリストファイル８３に格納される情報（エントリ）およびそのデータ構造を示す。拡張子"ｒｐｌｓ"および"ｖｐｌｓ"ファイル８３内にはＰｌａｙＬｉｓｔ（）として示すエントリが存在する。これが上述の「プレイリスト」に対応する。プレイリスト情報（ＰｌａｙＬｉｓｔ）の下位には、プレイアイテム（ＰｌａｙＩｔｅｍ）１、２・・・が記述される。各プレイアイテムには再生対象となるクリップ情報ファイルのファイル名（Ｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ）、ＳＴＣを特定するための識別子（ｒｅｆ＿ｔｏ＿ＳＴＣ＿ｉｄ）、開始時刻（Ｉｎ＿ｔｉｍｅ）、終了時刻（Ｏｕｔ＿ｔｉｍｅ）等が格納される。なお、プレイリストファイル８３には、"プレイリストマーク（ＰｌａｙＬｉｓｔＭａｒｋ）"として示すエントリを設けることもできる。プレイリストマークの機能は後述する。
【００６６】
図１１および図１２は、クリップ情報ファイル８４に格納される情報（エントリ）およびクリップ情報ファイルのエントリに関するデータ構造を示す図である。クリップ情報ファイル８４には、種々のエントリが設けられている。このうち、図１１にはさらに、クリップ関連情報（ＣｌｉｐＩｎｆｏ）の詳細なデータ構造とシーケンス情報（ＳｅｑｕｅｎｃｅＩｎｆｏ）の詳細なデータ構造とが示されている。クリップ関連情報（ＣｌｉｐＩｎｆｏ）にもまた、複数のエントリが存在する。図１１には、クリップ関連情報に含まれる１つのエントリ（ＴＳ＿ｔｙｐｅ＿ｉｎｆｏ＿ｂｌｏｃｋ）の詳細なデータ構造が示されている。また図１２によれば、特徴点情報（ＣＰＩ）内のエントリとして時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）が設けられていることが理解される。他のエントリ（ＣｌｉｐＭａｒｋ）等に関しては後述する。変換テーブル（ＥＰ＿ｍａｐ）は、録画した番組ごと、換言すれば記録したビデオＴＳパケットのＰＩＤごとに設けられる。
【００６７】
なお、図１２に示されるように、ＥＰ＿ｍａｐに代えてＴＵ＿ｍａｐを設けることもできる。ＴＵ＿ｍａｐとは、パケットの到着時刻（ＡＴＳ）とソースパケット番号との対応を示すテーブルである。パケットの到着時刻のエントリは、例えば１秒間隔で設けられる。そして、その時刻の直後に最初に受け取られたＴＳパケットから生成されたソースパケットの番号が、その時刻に対応付けられる。
【００６８】
次に、図１３から図１５を参照しながら、時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）のデータ構造と、変換テーブル８４を利用した時間−アドレス変換の原理を説明する。図１３は、時間・アドレス変換テーブルのデータ構造を示す。変換テーブルでは、時間を示すタイムスタンプ（ＰＴＳ）とアドレスを示すソースパケット番号（ＳＰＮ）とが対応付けられている。このタイムスタンプ（ＰＴＳ）は、映像に関していえばＭＰＥＧ規格のＧＯＰの先頭に配置される各ＩピクチャのＰＴＳを表す。またソースパケット番号（ＳＰＮ）とは、そのＰＴＳに対応する時刻に再生されるＩピクチャの先頭データが格納されたソースパケット番号（ＳＰＮ）である。ソースパケットのデータサイズは１９２バイトであるから、ソースパケット番号が特定されるとクリップＡＶストリームの先頭からのバイト数が特定され、そのデータに容易かつ確実にアクセスできる。なお、この変換テーブルにおけるソースパケット番号Ｘ１、Ｘ２等の実際の値は必ずしも連続する整数ではなく、飛び飛びに大きくなっていく整数値である。
【００６９】
図１４は、第１の例による時間とアドレスの対応を示す。上述のように、ＧＯＰの先頭に配置される各ＩピクチャのＰＴＳ値のみを時間・アドレス変換テーブルに記述しているため、そのＰＴＳ値以外のＰＴＳ値が開始時刻（Ｉｎ＿ｔｉｍｅ）および／または終了時刻（Ｏｕｔ＿ｔｉｍｅ）として指定されると、その時刻に対応するアドレス（ソースパケット番号）を直接得ることができない。しかし、ＭＰＥＧ−２ビデオの符号化圧縮方式では、ピクチャ間の差分を用いて圧縮処理を行うため、まず最初にＧＯＰ先頭のＩピクチャを復号しなければ、続くピクチャも復号できない。したがって、Ｉピクチャのエントリーが記述されていれば実際の再生には問題なく、それ以上のピクチャ単位の再生制御は、時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）で指定されるＩピクチャから復号を開始し、続くピクチャを解析／復号しながら、期待されるピクチャだけを表示処理すればよいことになる。
【００７０】
図１５は、第２の例による時間とアドレスの対応を示す。図１４の例と異なる点を説明する。放送番組の録画の対象は、１つの番組のみならず連続する複数の番組に亘る場合がある。このとき、各番組についてみればＰＴＳやソースパケット番号は一意に定められているが、番組間でみればそれらの値が重複する場合がある。したがって、そのような場合にも時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）によって確実に時間とアドレスとの変換を行えるようにする必要がある。そこで、特定の再生ポイントを一意に特定するための情報（ＳＴＣ＿ＩＤ）を規定し、時刻情報とともにソースパケット番号を特定するために利用する。
【００７１】
まず、最初に録画されている番組に対し、ＳＴＣ＿ＩＤ＝０を与える。図６に関連して説明したように、各パーシャルＴＳは独自のシステム時刻基準ＳＴＣに基づいて処理されるため、番組の切り替え点においてはシステム時刻基準ＳＴＣが不連続になる。図１５には、番組Ａ、ＢおよびＣを録画したときにおいて、番組ＡとＢ、および、番組ＢとＣとの間にＳＴＣ不連続点が存在する例を示す。各タイミングにおいて異なるＳＴＣ＿ＩＤを設定している。図１５では、最初の番組ＡはＳＴＣ＿ＩＤ＝０、次の番組ＢはＳＴＣ＿ＩＤ＝１、最後の番組ＣはＳＴＣ＿ＩＤ＝２である。さらに、１つのＳＴＣ＿ＩＤのストリームの最長再生時間を規定することで、同一のＳＴＣ＿ＩＤ内でも同一のＰＴＳが存在しないことを保証している。（ＭＰＥＧのＰＴＳは９０ＫＨｚ精度で３３ビット長であるため、約２６．５時間しか正しく表現できない。）
【００７２】
上述のようにＳＴＣ＿ＩＤを割り当てておくことにより、時刻情報（Ｉｎ＿ｔｉｍｅ／Ｏｕｔ＿ｔｉｍｅ）およびＳＴＣ＿ＩＤに基づいて、本来指定されたとおりの適切なソースパケット番号を得ることができる。図１０に示すＰｌａｙＩｔｅｍ（）には、開始時刻（ＩＮ＿ｔｉｍｅ）および終了時刻（ＯＵＴ＿ｔｉｍｅ）の情報とともにＳＴＣ＿ＩＤを特定するためのエントリ（ｒｅｆ＿ｔｏ＿ＳＴＣ＿ｉｄ）が設けられていることが理解される。
【００７３】
次に、図１６から図１９を参照しながら、バーチャルプレイリストを利用したクリップＡＶストリームの編集処理を説明する。図１６（ａ）は、リアルプレイリスト１および２と、対応するクリップ１および２を示す。クリップ１の一部およびクリップ２の一部を連続して再生するバーチャルプレイリストを生成することを考える。図１６（ｂ）は、ＩＮ１からＯＵＴ１までの第１区間およびＩＮ２からＯＵＴ２までの第２区間を連続して再生するバーチャルプレイリストを示す。第１区間および第２区間はそれぞれバーチャルプレイリスト内の別個のプレイアイテムによって指定される。バーチャルプレイリストによれば、リアルプレイリスト１および２およびクリップ１および２を直接加工することなく、別個のクリップの一部の再生区間を見かけ上つなぎ合わせることができる。
【００７４】
しかしながら、前述の通り、ＭＰＥＧ−２ビデオ圧縮方式はピクチャ間の差分を用いて圧縮しているため、ＩＮ２で飛び込んだ直後のピクチャは、そのピクチャの復号に必要な先行するピクチャのデータが取得されていないために通常復号できず、しばらく映像が表示されないことになる。
【００７５】
映像のみに関し、シームレスな再生を実現するためには、もともとのストリームを破壊編集し、接続点でのビデオの再エンコードする必要がある。このとき、プレイアイテムの接続情報（ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ）は「４」に設定される。しかしながら、破壊編集は元の映像が残らない編集である。そこで、破壊編集のような元のストリームの編集は行わずに、接合点付近のストリームを集め、シームレス接続できるように再エンコード処理した「ブリッジクリップ」というクリップを新たに設けることができる。再生時は、つなぎ目の直前でブリッジクリップに再生制御を切り替え、ブリッジクリップの再生後に第２区間の再生に移る。これにより、矛盾のない滑らかな場面の切り替えを実現することができる。なお、このブリッジクリップによる接続情報は「３」に設定される。
【００７６】
図１７（ａ）は、図１６（ｂ）のバーチャルプレイリストを分割するときの分割点の位置を示す。図１７（ｂ）は、分割されたバーチャルプレイリスト１および２を示す。バーチャルプレイリスト１は、リアルプレイリスト１の区間とリアルプレイリスト２の一部の区間の連続再生を規定する。一方、バーチャルプレイリスト２は、リアルプレイリスト２の残りの区間の再生を規定する。
【００７７】
図１７（ａ）および（ｂ）に示す処理とは逆の処理、すなわち複数のバーチャルプレイリストを併合することもできる。図１８（ａ）は、併合の対象であるバーチャルプレイリスト１および２を示す。図１８（ｂ）は、１つに併合されたバーチャルプレイリストを示す。
【００７８】
図１７（ａ）および（ｂ）の例においても、また図１８（ａ）および（ｂ）の例においても、バーチャルプレイリストを用いることにより、リアルプレイリスト１および２およびクリップ１および２を直接加工することなく、クリップを見かけ上分割し、または併合することができる。
【００７９】
一方、リアルプレイリストの部分削除の場合には、クリップおよびリアルプレイリストを直接加工する必要がある。図１９（ａ）は、区間Ａ−Ｂを削除の対象とするリアルプレリストおよびクリップを示す。そして、図１９（ｂ）は、区間Ａ−Ｂを削除して、点ＡおよびＢの位置を結合したリアルプレイリストおよびクリップを示す。リアルプレイリストの部分削除および削除の場合にのみクリップおよびリアルプレイリストを直接加工する理由は、リアルプレイリストのみが映像・音声データと直接の因果関係を持つためである。つまり、レコーダ上のユーザーインターフェースにおいて、ユーザーにクリップを認識させず、リアルプレイリスト（ユーザーにとって、クリップと同じ意味を持つ）とバーチャルプレイリスト（単なる再生経路情報）のみを提示することを想定しているためである。
【００８０】
次に、図２０を参照しながらサムネイルピクチャの管理を説明する。図２０は、ＢＤ２０５ａにおいて管理されるサムネイルピクチャと管理ファイルとの関係を示す。サムネイルピクチャとは、動画の一場面や静止画等の縮小されたピクチャであり、動画や静止画の内容を容易に確認する目的で設けられる。
【００８１】
サムネイルピクチャに関連するデータは、複数のファイルに格納される。図２０には、サムネイルピクチャを管理するメニューサムネイルファイル３０２およびマークサムネイルファイル３０４が示されている。メニューサムネイルファイル３０２は、ＢＤ２０５ａやプレイリストのサムネイルに関するインデクス情報を格納している。このインデクス情報は、メニューサムネイルファイル３０２において管理されるサムネイルピクチャ（サムネイルピクチャ３０２ａ、３０２ｂ等）の管理番号（ｍｅｎｕ＿ｔｈｕｍｂｎａｉｌ＿ｉｎｄｅｘ）を含む。サムネイルピクチャ３０２ａはバーチャルプレイリスト３１２の代表的な内容を示す。また、サムネイルピクチャ３０２ｂはボリュームサムネイルと呼ばれ、本ＢＤＡＶディレクトリの全体に関する代表的な内容を示す。なお図８には、メニューサムネイルファイル３０２に対応する"ｍｅｎｕ．ｔｉｄｘ"ファイルと、各サムネイルピクチャの実体データを示す"ｍｅｎｕ．ｔｄｔ（ｎ）"（ｎ＝１，２・・・）が示されている。
【００８２】
一方、マークサムネイルファイル３０４は、所望の映像の位置に付加され、しおりとして機能する「マーク」のサムネイルに関するインデクス情報を格納している。このインデクス情報も同様に、マークサムネイルファイル３０４において管理されるサムネイルピクチャ（サムネイルピクチャ３０４ａ、３０４ｂ、３０４ｃ等）の管理番号（ｍａｒｋ＿ｔｈｕｍｂｎａｉｌ＿ｉｎｄｅｘ）を含む。サムネイルピクチャ３０４ａはバーチャルプレイリスト３１２内のマークが付加された位置の縮小画像である。サムネイルピクチャ３０４ｂはリアルプレイリスト３１４内のマークが付加された位置の縮小画像である。また、サムネイルピクチャ３０４ｃはクリップ３１６内のクリップマークが付加された位置の縮小画像である。なお図８には、マークサムネイルファイルを管理する"ｍａｒｋ．ｔｉｄｘ"ファイルと、各サムネイルピクチャの実体データを示す"ｍａｒｋ．ｔｄｔ（ｎ）"（ｎ＝１，２）が示されている。上述の各サムネイルピクチャのデータは、ＪＰＥＧ規格に基づいて圧縮符号化され、各マークのサムネイル参照ＩＤ（ｒｅｆ＿ｔｏ＿ｍｅｎｕ／ｍａｒｋ＿ｔｈｕｍｂｎａｉｌ＿ｉｎｄｅｘ、図１２参照）によってボリューム内で一意にどのＪＰＥＧサムネイルピクチャか特定される。
【００８３】
上述のメニューサムネイルファイル３０２およびマークサムネイルファイル３０４を利用すると、サムネイルピクチャを一覧表示したり、特定のマークのみのサムネイルピクチャを選択的に表示させることができる。これにより、ユーザはそのＢＤ２０５ａで管理されている動画の概要、種々のプレイリストの概要、または、特定のプレイリストの複数の場面の概要を容易に把握できる。
【００８４】
図２１（ａ）〜（ｃ）は、それぞれ、マークが付加されたバーチャルプレイリスト３１２、リアルプレイリスト３１４およびクリップ３１６を示す。ＢＤ２０５ａではユーザは複数種類のマークを設定することができる。すなわち、所望の動画等（コンテンツ）の頭出し点を指定する「ブックマーク」、再生を飛ばす点（区間）を指定する「スキップマーク」、および、先に視聴を停止したコンテンツの位置を指定する「レジュームマーク」、チャプターの先頭を指定する「チャプターマーク」等である。
【００８５】
図２１（ａ）に示すバーチャルプレイリスト３１２には、ブックマークおよびレジュームマークが設定されている。これらのマークは、プレイリストファイル（拡張子：ｖｐｌｓ）の"ＰｌａｙＬｉｓｔＭａｒｋ"エントリに記述される。図１０には、"ＰｌａｙＬｉｓｔＭａｒｋ"エントリに対応するＰｌａｙＬｉｓｔＭａｒｋ（）が記載されている。ＰｌａｙＬｉｓｔＭａｒｋ（）において、"ｍａｒｋ＿ｔｙｐｅ"は、ブックマーク、レジュームマーク等のマークの種類を特定する情報である。"ｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐ"は、マークが設定されるピクチャのタイムスタンプ（ＰＴＳ）を特定する情報である。各マークにはサムネイルピクチャを対応付けることもできる。図２１（ａ）に示すサムネイルピクチャ３０４ａは、ブックマークが設定された場面の縮小画像である。バーチャルプレイリスト３１２に設定されたサムネイルピクチャ３０４ａは、マークサムネイルファイル３０４において管理される。
【００８６】
次に、図２１（ｂ）に示すリアルプレイリスト３１２には、ブックマーク、レジュームマークおよびスキップマークが設定されている。スキップマークについても、スキップ開始位置のサムネイルピクチャ３０４ｂを設定できる。またスキップする期間（ｄｕｒａｔｉｏｎ）もあわせて設定できる。
【００８７】
図２１（ｃ）に示すクリップ３１６には、クリップマークが設定されている。クリップマークは、クリップＡＶストリームを生成した際にレコーダ１００が付加するマークである。ユーザはクリップマークの生成に関与できず、また生成されたクリップマークの削除等にも関与できない。クリップマークは、クリップに直接付加されるため、プレイリスト３１２および３１４に基づく再生時にもその機能は有効である。なお、クリップマークにもサムネイルピクチャ３０４ｃが設定され得る。
【００８８】
上述の各マークには、録画機器（例えばレコーダ１００）のメーカごとのＩＤ（ｍａｋｅｒ＿ＩＤ）と独自情報（ｍａｋｅｒｓ＿ｐｒｉｖａｔｅ＿ｄａｔａ）を付加することもできる。これにより、マークを用いてメーカ独自に機器の機能を拡張することができる。
【００８９】
上述のように、マークを利用すると動画を代表するサムネイルピクチャをペアとして扱うことが可能である。以下、このサムネイルピクチャの利用方法について説明していく。
【００９０】
ムービーや携帯電話、デジタルスチルカメラなどのモバイル用途の小型軽量な映像記録／再生機器では、上記デジタル放送も記録できるような据え置きレコーダとは商品実装上の課題が異なる場合がある。例えば、ＭＰＥＧ−４  ＡＶＣのような新しく圧縮効率も極めて高いものの、符号／複合処理が極めて重い符号化方式を採用する際においても、ムービーでの省電力かつ小規模なＬＳＩでは全機能の対応が難しいが、レコーダのように消費電力の制約が少なく大規模なＬＳＩでは完全に全機能に対応できることがある。
【００９１】
このことは、ある映像記録／再生装置が全機能を搭載することが難しい場合には、上記のようなデータ構造で記録すると記録機器間で仕様を合わせたところで、他記録装置で撮影した映像が再生できない事態が起こりえることを意味している。
【００９２】
撮影した映像が他機器で再生できないことは問題であるが、上記データ構造にて動画とリンクされたサムネイルが記録されていない場合には、さらにその問題が大きくなる。
【００９３】
元々サムネイルが記録されていない場合には、その再生できない映像がどういうコンテンツなのかをユーザーに映像情報として表示することができず、撮影日時などでしか表すことができなくなり、コンテンツの識別性が極めて悪くなる。
【００９４】
したがって、ムービーの機器メニューとして撮影した動画のサムネイル一覧メニューを表示する時や、またはＤＶＤ−Ｖｉｄｅｏのようなディスクメニュー（作りこみのボタンやハイライトなどを利用してユーザーのコンテンツ再生を誘導するインタラクティブ性のあるメニュー）を追加する時には、このようなサムネイルが常に記録されていることが望ましい。
【００９５】
しかしながら、安価な記録機器に対しても撮影を行うたびに、常にサムネイルを作成し、記録することは実際には困難と思われるため、所定の（複雑でデコードが一般に困難と思われる）符号化処理を行った映像データに対しては、その映像を表す（どの機器でも再生が可能な映像である）サムネイルを生成することが考えられる。
【００９６】
例えば、ＭＰＥＧ−４  ＡＶＣを使うムービーを想定すると、以下の符号化パラメータをサムネイル必須とオプションの条件判断に使うことが想定される。
【００９７】
ｐｒｏｆｉｌｅ＿ｉｄｃ：プロファイル情報
ｌｅｖｅｌ＿ｉｄｃ：レベル情報
ｃｏｎｓｔｒａｉｎｔ＿ｓｅｔ（ｎ）＿ｆｌａｇ：符号化に所定の制限を加えているか否かを示すフラグ（ｎ＝１〜４）
ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｍｂｓ＿ｍｉｎｕｓ１：水平解像度の情報
ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｍａｐ＿ｕｎｉｔｓ＿ｍｉｎｕｓ１：垂直解像度の情報  ｍｂ＿ａｄａｐｔｉｖｅ＿ｆｒａｍｅ＿ｆｉｅｌｄ＿ｆｌａｇ：１ピクチャ内でのフレーム／フィールドマクロブロックの混在使用の有無
ｍａｘ＿ｄｅｃ＿ｆｒａｍｅ＿ｂｕｆｆｅｒｉｎｇ：デコードに必要なバッファサイズ（バッファとは、HRD decoded picture bufferを示す）
ｂｉｔ＿ｒａｔｅ＿ｖａｌｕｅ＿ｍｉｎｕｓ１：ｂｉｔ＿ｒａｔｅ＿ｓｃａｌｅと共に使われるバッファへの最大入力レート（バッファとは、HRD coded picture bufferを示す）
ｓｕｂ＿ｍｂ＿ｔｙｐｅ：サブマクロブロックのタイプ情報（8x8/4x8/8x4/4x4の夫々の使用有無）
ｗｅｉｇｈｔｅｄ＿ｐｒｅｄ＿ｆｌａｇ：重み付け予測使用の有無
【００９８】
例えば、上記パラメータの一部を使って、サムネイルを常に生成する条件を、ＭＰＥＧ−４  ＡＶＣで上位のＨｉｇｈプロファイル（profile_idc=100）でかつ、最大解像度の１９２０ｘ１０８０ｐの符号化画像サイズ（pic_width_in_mbs_minus1=119, pic_height_in_map_units_minus1=67）を持つ動画、としても良いし、上記パラメータの設定をいくつかのレベルに分割し、所定のレベル以上ではサムネイルを常に生成するとしても良い。重要なことは、ＭＰＥＧ−４  ＡＶＣの符号化条件に応じて代替情報であるサムネイルの記録を行う点である。
【００９９】
図２２に示すように、上記のようにサムネイルを生成する条件を規定することにより、記録装置のサムネイル処理の分岐が、撮影する映像データの符号化形式に応じて分かれることになる。これによって、安価な機器ではデコードできない動画ストリームに対しても常にサムネイルが記録されていることが保証でき、ユーザーは記録されているコンテンツを識別することが可能となる。
【０１００】
上記説明においては、ムービーを用いたためデコード互換性確保が困難な動画を記録する場合にサムネイル（静止画）を併記するとしたが、本発明はこれに限らず、所定の符号化条件を満たす静止画を記録する場合に、サムネイル（静止画）を併記しても良いし、所定の符号化条件を満たす静止画を記録する場合に、動画を併記しても良いし、所定の符号化条件を満たす動画を記録する場合に、動画を併記しても良く、その組み合わせは自由である。
【０１０１】
尚、所定のタイプのマークに対しては、常にサムネイルを生成するようにしても良いし、サムネイルの画像サイズやデータサイズを複数許可し、その中で所定のサムネイルだけを常に生成するようにしても良い。例えば、画像サイズが小さいサムネイルと大きいサムネイルの内、小さいサムネイルだけは必ず記録するなどとしても良い。
【産業上の利用可能性】
【０１０２】
本発明の撮影装置は再生互換性性が取りにくいと予想される映像情報に対して、その代替映像を再生互換性が取れる形で記録するため、記録機器間での再生互換が取りにくい環境においても、記録されているコンテンツをユーザーが識別できるようになる。
【図面の簡単な説明】
【０１０３】
【図１】システムの構成を示す図である。
【図２】トランスポートストリームのデータ構造を示す図である。
【図３】ＴＳパケットのデータ構造を示す図である。
【図４】ストリームの関係を示す図である。
【図５】レコーダの機能ブロックの構成を示す図である。
【図６】ＴＳ処理部の詳細な機能ブロックの構成を示す図である。
【図７】トランスポートストリームとクリップＡＶストリームとの関係を示す図である。
【図８】記録領域とディレクトリ／ファイル構造を示す図である。
【図９】管理情報とストリームデータとの関係を示す図である。
【図１０】プレイリストファイルに格納される情報に関するデータ構造を示す図である。
【図１１】クリップ情報ファイルに格納される情報に関するデータ構造を示す図である。
【図１２】クリップ情報ファイルに格納される情報に関するデータ構造を示す図である。
【図１３】時間・アドレス変換テーブルのデータ構造を示す図である。
【図１４】第１の例による時間とアドレスの対応を示す図である。
【図１５】第２の例による時間とアドレスの対応を示す図である。
【図１６】リアルプレイリストとバーチャルプレイリストを示す図である。
【図１７】バーチャルプレイリストの分割を示す図である。
【図１８】バーチャルプレイリストの結合を示す図である。
【図１９】リアルプレイリスト／クリップの結合を示す図である。
【図２０】サムネイルピクチャと管理ファイルとの関係を示す図である。
【図２１】マークが付加されたプレイリストとクリップを示す図である。
【図２２】サムネイル記録を説明するフォローチャートである。
【符号の説明】
【０１０４】
１００  ＨＤＤ内蔵ＢＤレコーダ
１０６  ＴＶ
１０８  ＰＣ
１１２  メモリカード
１１４  ＢＤ
２０１ａ  デジタルチューナ
２０１ｂ  アナログチューナ
２０２  ＡＤコンバータ
２０３  ＭＰＥＧ−２エンコーダ
２０４  ＴＳ処理部
２０５ａ  ＢＤ
２０５ｂ  ＨＤＤ
２０６  ＭＰＥＧ−２デコーダ
２０７  グラフィック制御部
２０８  メモリ
２０９  ＤＡコンバータ
２１０  プログラムＲＯＭ
２１１  ＣＰＵ
２１２  ＲＡＭ
２１３  ＣＰＵバス
２１４  ネットワーク制御部
２１５  指示受信部
２１６  インターフェース（Ｉ／Ｆ）部
２１７  メモリカード制御部
２５０  システム制御部
２６１  ソース・パケタイザ
２６２  クロックカウンタ
２６３  ＰＬＬ回路
２６４  バッファ
２６５  ソース・デ・パケタイザ
【図１】
2007129368.tif 000003
【図２】
2007129368.tif 000004
【図３】
2007129368.tif 000005
【図４】
2007129368.tif 000006
【図５】
2007129368.tif 000007
【図６】
2007129368.tif 000008
【図７】
2007129368.tif 000009
【図８】
2007129368.tif 000010
【図９】
2007129368.tif 000011
【図１０】
2007129368.tif 000012
【図１１】
2007129368.tif 000013
【図１２】
2007129368.tif 000014
【図１３】
2007129368.tif 000015
【図１４】
2007129368.tif 000016
【図１５】
2007129368.tif 000017
【図１６】
2007129368.tif 000018
【図１７】
2007129368.tif 000019
【図１８】
2007129368.tif 000020
【図１９】
2007129368.tif 000021
【図２０】
2007129368.tif 000022
【図２１】
2007129368.tif 000023
【図２２】
2007129368.tif 000024