Nothing Special   »   [go: up one dir, main page]

JP4715633B2 - 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム - Google Patents

記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム Download PDF

Info

Publication number
JP4715633B2
JP4715633B2 JP2006140839A JP2006140839A JP4715633B2 JP 4715633 B2 JP4715633 B2 JP 4715633B2 JP 2006140839 A JP2006140839 A JP 2006140839A JP 2006140839 A JP2006140839 A JP 2006140839A JP 4715633 B2 JP4715633 B2 JP 4715633B2
Authority
JP
Japan
Prior art keywords
group
recording
mark information
video data
unit
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
JP2006140839A
Other languages
English (en)
Other versions
JP2007312246A5 (ja
JP2007312246A (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.)
Sony Corp
Original Assignee
Sony Corp
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
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2006140839A priority Critical patent/JP4715633B2/ja
Priority to TW096113501A priority patent/TWI365447B/zh
Priority to EP07009174.9A priority patent/EP1858020B1/en
Priority to KR20070044670A priority patent/KR101364206B1/ko
Priority to US11/804,749 priority patent/US8229281B2/en
Priority to CN2007101041530A priority patent/CN101075462B/zh
Publication of JP2007312246A publication Critical patent/JP2007312246A/ja
Publication of JP2007312246A5 publication Critical patent/JP2007312246A5/ja
Application granted granted Critical
Publication of JP4715633B2 publication Critical patent/JP4715633B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/322—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier used signal is digitally coded
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/21—Disc-shaped record carriers characterised in that the disc is of read-only, rewritable, or recordable type
    • G11B2220/215—Recordable discs
    • G11B2220/218—Write-once discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Television Signal Processing For Recording (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)

Description

この発明は、ＡＶ(Audio/Video)ストリームデータからなるクリップに対する編集処理を行うようにした記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラムに関する。
従来から、記録可能で記録再生装置から取り外し可能とされると共に、記録容量が比較的大きく、ビデオデータとオーディオデータとからなるＡＶ(Audio/Video)データを記録するのに適した記録媒体として、４．７ＧＢ(Giga Byte)以上の記録容量を有するＤＶＤ(Digital Versatile Disc)が普及している。特許文献１には、記録可能なタイプのＤＶＤに対してＤＶＤ−Ｖｉｄｅｏフォーマットで記録する撮像装置が記載されている。
特開２００４−３５０２５１
このような記録可能な記録媒体においては、記録媒体に記録されたＡＶデータは、編集可能であることが望ましい。ＡＶデータに対する代表的な編集方法の例としては、所定単位のＡＶ(Audio/Video)データを分割編集することが挙げられる。ビデオデータおよびオーディオデータは、一般的には多重化された所定のデータ単位として記録される。
また、ビデオデータは、データ容量が膨大となるため、所定の方式で圧縮符号化されて記録媒体に記録されるのが一般的である。ビデオデータの圧縮符号化方式としては、ＭＰＥＧ２(Moving Picture Experts Group 2)方式が標準的な方式として知られている。また、近年では、ＭＰＥＧ２の圧縮符号化方式をさらに推し進めて効率的な符号化を行えるようにした、ＩＴＵ−Ｔ(International Telecommunication Union-Telecommunication Standarization Sector)勧告Ｈ．２６４あるいはＩＳＯ(International Organization for Standarization)／ＩＥＣ(International Electrotechnical Commission)国際標準１４４９６−１０（ＭＰＥＧ−４パート１０）Advanced Video Coding（以下、Ｈ．２６４｜ＡＶＣと略称する）も、普及してきている。
これらＭＰＥＧ２およびＨ．２６４｜ＡＶＣにおいては、直交変換などを用いたフレーム内符号化を行うと共に、動き補償を用いた予測符号化によるフレーム間符号化をさらに行い、圧縮率を高めている。以下、ＭＰＥＧ２を例にとって、予測符号化によるフレーム間圧縮について説明する。
先ず、ＭＰＥＧ２のデータストリーム構造について、概略的に説明する。ＭＰＥＧ２は、動き補償予測符号化と、ＤＣＴによる圧縮符号化とを組み合わせたものである。ＭＰＥＧ２のデータ構造は、階層構造をなしており、下位から、ブロック層、マクロブロック層、スライス層、ピクチャ層、ＧＯＰ層およびシーケンス層となっている。ブロック層は、ＤＣＴを行う単位であるＤＣＴブロックからなる。マクロブロック層は、複数のＤＣＴブロックで構成される。スライス層は、ヘッダ部と、１以上のマクロブロックより構成される。ピクチャ層は、ヘッダ部と、１以上のスライスとから構成される。ピクチャは、１画面に対応する。各層の境界は、それぞれ所定の識別符号で識別可能なようになっている。
ＧＯＰ層は、ヘッダ部と、フレーム内符号化に基づくピクチャであるＩ(Intra-coded)ピクチャと、予測符号化に基づくピクチャであるＰ(Predictive-coded)ピクチャＢ(Bi-directionally predictive coded)ピクチャとから構成される。Ｉピクチャは、それ自身の情報のみでデコードが可能であり、ＰおよびＢピクチャは、基準画像として前あるいは前後の画像が必要とされ、単独ではデコードされない。例えばＰピクチャは、自身より時間的に前のＩピクチャまたはＰピクチャを基準画像として用いてデコードされる。また、Ｂピクチャは、自身の前後のＩピクチャまたはＰピクチャの２枚のピクチャを基準画像として用いてデコードされる。最低１枚のＩピクチャを含むそれ自身で完結したグループをＧＯＰ(Group Of Picture)と呼び、ＭＰＥＧのストリームにおいて独立してアクセス可能な最小の単位とされる。
ＧＯＰは、１または複数のピクチャから構成される。以下では、ＧＯＰは、複数のピクチャから構成されるものとする。ＧＯＰにおいて、ＧＯＰ内で完全にデコードが可能な、ＧＯＰで閉じた構造を持つクローズドＧＯＰと、デコードの際に符号化順で１つ前のＧＯＰの情報を用いることができるオープンＧＯＰとの２種類がある。オープンＧＯＰは、クローズドＧＯＰと比較して、より多くの情報を用いてデコードできるため高画質を得られ、一般的に用いられている。
図３７を用いて、フレーム間圧縮を行ったデータのデコード処理について説明する。ここでは、１ＧＯＰが１枚のＩピクチャ、４枚のＰピクチャおよび１０枚のＢピクチャの、計１５枚のピクチャから構成されるものとする。ＧＯＰ内のＩ、ＰおよびＢピクチャの表示順は、図３７Ａに一例が示されるように、「Ｂ0Ｂ1Ｉ2Ｂ3Ｂ4Ｐ5Ｂ6Ｂ7Ｐ8Ｂ9Ｂ10Ｐ11Ｂ12Ｂ13Ｐ14」のようになる。なお、添え字は表示順を示す。
この例では、最初の２枚のＢ0ピクチャおよびＢ1ピクチャは、１つ前のＧＯＰにおける最後尾のＰ14ピクチャと、このＧＯＰ内のＩ2ピクチャを用いて予測されデコードされたピクチャである。ＧＯＰ内の最初のＰ5ピクチャは、Ｉ2ピクチャから予測されデコードされたピクチャである。他のＰ8ピクチャ、Ｐ11ピクチャおよびＰ14は、それぞれ１つ前のＰピクチャを用いて予測されデコードされたピクチャである。また、Ｉピクチャ以降の各Ｂピクチャは、それぞれ前後のＩおよび／またはＰピクチャから予測されデコードされたピクチャである。
一方、Ｂピクチャは、時間的に前後のＩまたはＰピクチャを用いて予測されデコードされるため、ストリームや記録媒体上におけるＩ、ＰおよびＢピクチャの並び順は、デコーダにおけるデコードの順序を考慮して決める必要がある。すなわち、ＢピクチャをデコードするためのＩおよび／またはＰピクチャは、当該Ｂピクチャよりも常に先にデコードされていなければならない。
上述の例では、ストリームや記録媒体上の各ピクチャの配列は、図３７Ｂに例示されるように、「Ｉ2Ｂ0Ｂ1Ｐ5Ｂ3Ｂ4Ｐ8Ｂ6Ｂ7Ｐ11Ｂ9Ｂ10Ｐ14Ｂ12Ｂ13」のようになり、この順でデコーダに入力される。なお、添え字は、図３７Ａに対応し、表示順を示す。
デコーダにおけるデコード処理は、図３７Ｃに示されるように、先ずＩ2ピクチャをデコードし、デコードされたこのＩ2ピクチャと１つ前のＧＯＰにおける最後尾（表示順）のＰ14ピクチャとによりＢ0ピクチャおよびＢ1ピクチャを予測しデコードする。そして、Ｂ0ピクチャおよびＢ1ピクチャをデコードされた順にデコーダから出力し、次にＩ2ピクチャを出力する。Ｂ1ピクチャが出力されると、次にＰ5ピクチャがＩ2ピクチャを用いて予測されデコードされる。そして、Ｉ2ピクチャおよびＰ5ピクチャを用いてＢ3ピクチャおよびＢ4ピクチャが予測されデコードされる。そして、デコードされたＢ3ピクチャおよびＢ4ピクチャをデコードされた順にデコーダから出力し、次にＰ5ピクチャを出力する。
以下、同様にして、Ｂピクチャの予測に用いるＰまたはＩピクチャをＢピクチャより先にデコードし、このデコードされたＰまたはＩピクチャを用いてＢピクチャを予測してデコードし、デコードされたＢピクチャを出力してから、当該Ｂピクチャをデコードするために用いたＰまたはＩピクチャを出力する処理が繰り返される。記録媒体上やストリームにおける図３７Ｂのようなピクチャ配列は、一般的に用いられるものである。
このように、ＧＯＰ構造で以てフレーム間圧縮を行ったビデオデータに対してアクセス位置を指定することにより、ビデオデータを分割編集しようとする場合、ＧＯＰの境界を指定して分割する第１の方法と、ＧＯＰ内のＩピクチャを指定して分割する第２の方法とが考えられる。第１の方法によれば、Ｉピクチャ以降のピクチャは、図３７を用いて説明したように、このＩピクチャを参照して順次、デコードできるので、再生時に、編集結果に基づき分割されたビデオデータの先頭へアクセスした際の、ジャンプ先のフレームの表示に遅延が少ない利点がある。
一方、この第１の方法では、分割指定された境界位置とＧＯＰの境界とが一致しないことになる。そのため、分割されたビデオデータの先頭へアクセスした場合、ＧＯＰの先頭のピクチャから再生することができないという問題点があった。
また、第１の方法によれば、分割されたビデオデータの後端部においても、後端とＧＯＰ境界とが一致しない。そのため、例えば分割されたビデオデータの後端のピクチャが含まれるＧＯＰが先行するＧＯＰとは異なるシーンとして生成されたＧＯＰである場合、再生時に、当該分割されたビデオデータの後端部において、シーン的に繋がりの無い映像が数フレーム分、再生されてしまうという問題点があった。
第２の方法では、ＧＯＰの先頭と編集により分割指定された境界とが一致するので、上述の第１の方法の場合のように、ＧＯＰの先頭側において再生されないピクチャが発生したり、分割されビデオデータの後端部においてシーン的に繋がりの無い映像が再生されてしまう問題は発生しない。
しかしながら、この第２の方法では、分割されたビデオデータの先頭のフレームが含まれるＧＯＰがオープンＧＯＰである場合、当該ＧＯＰの表示順がＩピクチャより前のＢピクチャは、図３７を用いて説明したように、当該ＧＯＰのＩピクチャと、直前のＧＯＰにおける最後のＰピクチャとを用いてデコードされる。そのため、当該分割されたビデオデータにジャンプされた際には、当該ＧＯＰの直前のＧＯＰの最後のＰピクチャをもデコードする必要があり、ジャンプ操作に応じた映像出力の遅延が大きくなってしまうという問題点があった。
このように、従来では、ＧＯＰ構造で以てフレーム間圧縮を行ったビデオデータに対して分割する編集を行う場合に、再生映像に問題が発生せず、ユーザの利便性を損なわないような方法が存在しなかったという問題点があった。
したがって、この発明の目的は、ＧＯＰ構造を有したビデオデータに対して分割編集を行う際のユーザの利便性を向上させることができるような記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラムを提供することにある。
上述した課題を解決するために、第１の発明は、ビデオデータを圧縮符号化して記録媒体に記録する記録装置において、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いてビデオデータを圧縮符号化する符号化部と、符号化部で圧縮符号化されたビデオデータを記録媒体に記録するのを制御する記録制御部と、ビデオデータに対してグループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成部とを有し、マーク情報生成部は、再生順で直前のグループの情報を用いずに復号可能なグループに対してアクセス位置を指定するときには、指定されるアクセス位置からグループの再生順の先頭に遡った位置を示すマーク情報を生成する記録装置である。
また、第２の発明は、ビデオデータを圧縮符号化して記録媒体に記録する記録方法において、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いてビデオデータを圧縮符号化する符号化のステップと、符号化のステップにより圧縮符号化されたビデオデータを記録媒体に記録するのを制御する記録制御のステップと、ビデオデータに対してグループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成のステップとを有し、マーク情報生成のステップは、再生順で直前のグループの情報を用いずに復号可能なグループに対してアクセス位置を指定するときには、指定されるアクセス位置から該グループの再生順の先頭に遡った位置を示すマーク情報を生成する記録方法である。
また、第３の発明は、ビデオデータを圧縮符号化して記録媒体に記録する記録方法をコンピュータ装置に実行させる記録プログラムにおいて、記録方法は、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いてビデオデータを圧縮符号化する符号化のステップと、符号化のステップにより圧縮符号化されたビデオデータを記録媒体に記録するのを制御する記録制御のステップと、ビデオデータに対してグループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成のステップとを有し、マーク情報生成のステップは、再生順で直前のグループの情報を用いずに復号可能なグループに対してアクセス位置を指定するときには、指定されるアクセス位置からグループの再生順の先頭に遡った位置を示すマーク情報を生成する記録プログラムである。
また、第４の発明は、ビデオデータに対してアクセス位置を指定するマーク情報を生成する編集装置において、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いて圧縮符号化されたビデオデータを復号する復号部と、ビデオデータに対してグループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成部とを有し、マーク情報生成部は、再生順で直前のグループの情報を用いずに復号可能なグループに対してアクセス位置を指定するときには、指定されるアクセス位置からグループの再生順の先頭に遡った位置を示すマーク情報を生成する編集装置である。
また、第５の発明は、ビデオデータに対してアクセス位置を指定するマーク情報を生成する編集方法において、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いて圧縮符号化されたビデオデータを復号する復号のステップと、ビデオデータに対してグループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成のステップとを有し、マーク情報生成のステップは、再生順で直前のグループの情報を用いずに復号可能なグループに対してアクセス位置を指定するときには、指定されるアクセス位置からグループの再生順の先頭に遡った位置を示すマーク情報を生成する編集方法である。
また、第６の発明は、ビデオデータに対してアクセス位置を指定するマーク情報を生成する編集方法をコンピュータ装置に実行させる編集プログラムにおいて、編集方法は、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いて圧縮符号化されたビデオデータを復号する復号のステップと、ビデオデータに対してグループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成のステップとを有し、マーク情報生成のステップは、再生順で直前のグループの情報を用いずに復号可能なグループに対してアクセス位置を指定するときには、指定されるアクセス位置から該グループの再生順の先頭に遡った位置を示すマーク情報を生成する編集プログラムである。
また、第７の発明は、ビデオデータを圧縮符号化して記録媒体に記録する記録装置において、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いてビデオデータを圧縮符号化する符号化部と、符号化部で圧縮符号化されたビデオデータを記録媒体に記録するのを制御する記録制御部と、ビデオデータに対してグループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成部とを有し、マーク情報生成部は、再生順で直前のグループの情報を用いて復号を行うグループに対してアクセス位置を指定するときには、グループに属する独立的に復号が可能なピクチャの位置を示すマーク情報を生成する記録装置である。
上述したように、第１、第２および第３の発明は、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いて圧縮符号化したビデオデータに対して、再生順で直前のグループの情報を用いずに復号可能なグループに対してアクセス位置を指定するときには、指定されるアクセス位置からグループの再生順の先頭に遡った位置を示すマーク情報を生成し、圧縮符号化されたビデオデータを記録媒体に記録するようにしているため、記録媒体からビデオデータを再生したときに、再生順で直前のグループの情報を用いずに復号可能なグループへのジャンプを指定した場合、ジャンプ先における表示の遅延を少なくできる。
また、第４、第５および第６の発明は、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いて圧縮符号化したビデオデータに対して、再生順で直前のグループの情報を用いずに復号可能なグループに対してアクセス位置を指定するときには、指定されるアクセス位置からグループの再生順の先頭に遡った位置を示すマーク情報を生成し、圧縮符号化されたビデオデータを記録媒体に記録するようにしているため、記録媒体からビデオデータを再生したときに、再生順で直前のグループの情報を用いずに復号可能なグループへのジャンプを指定した場合、ジャンプ先における表示の遅延を少なくできる。
また、第７の発明は、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いてビデオデータを圧縮符号化したビデオデータに対して、再生順で直前のグループの情報を用いて復号を行うグループに対してアクセス位置を指定するときには、グループに属する独立的に復号が可能なピクチャの位置を示すマーク情報を生成し、圧縮符号化されたビデオデータを記録媒体に記録するようにしているため、記録が停止された後に再び記録が開始された場合、記録の停止部分において表示すべき区間の終端とデコード区間の終端とが一致し、このプレイリストマークに基づくチャプタの終端で内容的に関連性のないフレームが表示されることがない。
第１、第２および第３の発明は、上述したように、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いて圧縮符号化したビデオデータに対して、再生順で直前のグループの情報を用いずに復号可能なグループに対してアクセス位置を指定するときには、指定されるアクセス位置からグループの再生順の先頭に遡った位置を示すマーク情報を生成し、圧縮符号化されたビデオデータを記録媒体に記録するようにしているため、記録媒体からビデオデータを再生したときに、再生順で直前のグループの情報を用いずに復号可能なグループへのジャンプを指定した場合、ジャンプ先における表示の遅延を少なくできる効果がある。
また、第４、第５および第６の発明は、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いて圧縮符号化したビデオデータに対して、再生順で直前のグループの情報を用いずに復号可能なグループに対してアクセス位置を指定するときには、指定されるアクセス位置からグループの再生順の先頭に遡った位置を示すマーク情報を生成し、圧縮符号化されたビデオデータを記録媒体に記録するようにしているため、記録媒体からビデオデータを再生したときに、再生順で直前のグループの情報を用いずに復号可能なグループへのジャンプを指定した場合、ジャンプ先における表示の遅延を少なくできる効果がある。
また、第７の発明は、少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いてビデオデータを圧縮符号化したビデオデータに対して、再生順で直前のグループの情報を用いて復号を行うグループに対してアクセス位置を指定するときには、グループに属する独立的に復号が可能なピクチャの位置を示すマーク情報を生成し、圧縮符号化されたビデオデータを記録媒体に記録するようにしているため、記録が停止された後に再び記録が開始された場合、記録の停止部分において表示すべき区間の終端とデコード区間の終端とが一致し、このプレイリストマークに基づくチャプタの終端で内容的に関連性のないフレームが表示されることがないという効果がある。
以下、この発明の実施の一形態を、図面を参照しながら説明する。先ず、理解を容易とするために、この発明に適用可能な一例のフォーマット（以下、ＡＶＣＨＤフォーマットと呼ぶ）について説明する。ＡＶＣＨＤフォーマットは、ビデオデータとオーディオデータとが所定に多重化されたＡＶ(Audio/Video)ストリームを記録可能な記録媒体に記録する記録フォーマットとして現在提案されているもので、記録媒体に記録されたＡＶストリームを、クリップ単位でプレイリストを用いて管理可能としている。
例えばＩＴＵ−Ｔ(International Telecommunication Union-Telecommunication Standarization Sector)勧告Ｈ．２６４あるいはＩＳＯ(International Organization for Standarization)／ＩＥＣ(International Electrotechnical Commission)国際標準１４４９６−１０（ＭＰＥＧ−４パート１０）Advanced Video Coding（以下、Ｈ．２６４｜ＡＶＣと略称する）に規定される符号化方式で符号化され、ＭＰＥＧ２システムズに従い多重化されたビットストリームは、クリップＡＶストリーム（またはＡＶストリーム）と称される。クリップＡＶストリームは、所定のファイルシステムによりファイルとしてディスクに記録される。このファイルを、クリップＡＶストリームファイル（またはＡＶストリームファイル）と称する。
クリップＡＶストリームファイルは、ファイルシステム上での管理単位であり、ユーザにとって必ずしも分かりやすい管理単位であるとは限らない。ユーザの利便性を考えた場合、複数のクリップＡＶストリームファイルに分割された映像コンテンツを一つにまとめて再生する仕組みや、クリップＡＶストリームファイルの一部だけを再生する仕組み、さらには、特殊再生や頭出し再生を滑らかに行うための情報などをデータベースとしてディスクに記録しておく必要がある。
図１は、この発明に適用可能なＡＶＣＨＤフォーマットに規定されるデータモデルを概略的に示す。このＡＶＣＨＤフォーマットによれば、データ構造は、図１に示されるように４層のレイヤよりなる。最も最下層のレイヤは、クリップＡＶストリームが配置されるレイヤである（便宜上、クリップレイヤと呼ぶ）。その上のレイヤは、クリップＡＶストリームに対する再生箇所を指定するための、プレイリスト(PlayList)と、プレイアイテム(PlayItem)とが配置されるレイヤである（便宜上、プレイリストレイヤと呼ぶ）。さらにその上のレイヤは、プレイリストに対して再生順などを指定するコマンドからなるムービーオブジェクト(Movie Object)などが配置されるレイヤである（便宜上、オブジェクトレイヤと呼ぶ）。最上層のレイヤは、記録媒体に格納されるタイトルなどを管理するインデックステーブルが配置される（便宜上、インデックスレイヤと呼ぶ）。
クリップレイヤについて説明する。クリップＡＶストリームは、ビデオデータやオーディオデータがＭＰＥＧ２ ＴＳ（トランスポートストリーム）の形式などに多重化されたビットストリームである。このクリップＡＶストリームに関する情報がクリップ情報(Clip Information)としてファイルに記録される。
また、クリップＡＶストリームには、字幕を表示するグラフィクスストリームであるＯＢストリーム(Overlay Bitmap stream)や、メニュー表示などに用いられるデータ（ボタン画像データなど）をストリームにしたＭＢストリーム(Menu Bitmap stream)ストリームを多重化することができる。
クリップＡＶストリームファイルと、対応するクリップ情報が記録されたクリップ情報ファイルとをひとまとまりのオブジェクトと見なし、クリップ(Clip)と称する。すなわち、クリップは、クリップＡＶストリームとクリップ情報とから構成される、一つのオブジェクトである。
ファイルは、一般的に、バイト列として扱われる。クリップＡＶストリームファイルのコンテンツは、時間軸上に展開され、クリップ中のエントリーポイントは、主に時間ベースで指定される。所定のクリップへのアクセスポイントのタイムスタンプが与えられた場合、クリップＡＶストリームファイルの中でデータの読み出しを開始すべきアドレス情報を見つけるために、クリップ情報ファイルを用いることができる。
プレイリストレイヤについて説明する。プレイリストは、再生するＡＶストリームファイルの指定と、指定されたＡＶストリームファイルの再生箇所を指定する再生開始点（ＩＮ点）と再生終了点（ＯＵＴ点）の集まりとから構成される。この再生開始点と再生終了点の情報を一組としたものは、プレイアイテム(PlayItem)と称される。プレイリストは、プレイアイテムの集合で構成される。プレイアイテムを再生するということは、そのプレイアイテムに参照されるＡＶストリームファイルの一部分を再生するということになる。すなわち、プレイアイテム中のＩＮ点およびＯＵＴ点情報に基づき、クリップ中の対応する区間が再生される。
オブジェクトレイヤについて説明する。ムービーオブジェクトは、ナビゲーションコマンドプログラムと、ムービーオブジェクトとを連携するターミナルインフォメーションを含む。ナビゲーションプログラムは、プレイリストの再生を制御するためのコマンド（ナビゲーションコマンド：navigation command）である。
インデックスレイヤについて説明する。インデックスレイヤは、インデックステーブル(Index Table)からなる。インデックステーブルは、記録媒体に記録されたコンテンツのタイトルを定義する、トップレベルのテーブルである。インデックステーブルに格納されているタイトル情報に基づき、プレーヤに常駐されるシステムソフトウェア中のモジュールマネージャにより記録媒体の再生が制御される。
すなわち、図２に概略的に示されるように、インデックステーブル中の任意のエントリは、タイトルと称され、インデックステーブルにエントリされるファーストプレイバックタイトル(First PlaybackTitle)、メニュータイトル(MenuTitle)およびムービータイトル(MovieTitle)＃１、＃２、・・・は、全てタイトルである。各タイトルは、ムービーオブジェクトに対するリンクを示す。
理解を容易とするため再生専用の記録媒体を例にとると、例えば、ファーストプレイバックタイトルは、当該記録媒体に格納されるコンテンツが映画であれば、映画本編に先立って映出される映画会社の宣伝用映像（トレーラ）に対応する。メニュータイトルは、例えばコンテンツが映画である場合、本編再生、チャプタサーチ、字幕や言語設定、特典映像再生などを選択するためのメニュー画面に対応する。また、ムービータイトルは、メニュータイトルから選択される各映像である。タイトルがさらにメニュー画面であるような構成も可能である。
図３は、上述のようなクリップＡＶストリーム、クリップ情報(Stream Attributes)、クリップ、プレイアイテムおよびプレイリストの関係を示すＵＭＬ(Unified Modeling Language)図である。プレイリストは、１または複数のプレイアイテムに対応付けられ、プレイアイテムは、１のクリップに対応付けられる。１のクリップに対して、それぞれ開始点および／または終了点が異なる複数のプレイアイテムを対応付けることができる。１のクリップから１のクリップＡＶストリームファイルが参照される。同様に、１のクリップから１のクリップ情報ファイルが参照される。また、クリップＡＶストリームファイルとクリップ情報ファイルとは、１対１の対応関係を有する。このような構造を定義することにより、クリップＡＶストリームファイルを変更することなく、任意の部分だけを再生する、非破壊の再生順序指定を行うことが可能となる。
また、図４のように、複数のプレイリストから同一のクリップを参照することもできる。また、１のプレイリストから複数のクリップを指定することもできる。クリップは、プレイリスト中のプレイアイテムに示されるＩＮ点およびＯＵＴ点により、参照される。図４の例では、クリップ３００は、プレイリスト３１０のプレイアイテム３２０から参照されると共に、プレイリスト３１１を構成するプレイアイテム３２１および３２２のうちプレイアイテム３２１から、ＩＮ点およびＯＵＴ点で示される区間が参照される。また、クリップ３０１は、プレイリスト３１１のプレイアイテム３２２からＩＮ点およびＯＵＴ点で示される区間が参照されると共に、プレイリスト３１２のプレイアイテム３２３および３２４のうち、プレイアイテム３２３のＩＮ点およびＯＵＴ点で示される区間が参照される。図４の例では、クリップ３０１は、さらに別のプレイリストからも参照されている。
次に、ＡＶＣＨＤフォーマットによる、記録媒体に記録されるファイルの管理構造について、図５を用いて説明する。ファイルは、ディレクトリ構造により階層的に管理される。記録媒体上には、先ず、１つのディレクトリ（図５の例ではルート(root)ディレクトリ）が作成される。このディレクトリの下が、１つの記録再生システムで管理される範囲とする。
ルートディレクトリの下に、ディレクトリ"BDMV"がおかれる。さらに、必要に応じてディレクトリ"AVCHDTN"が置かれる。ディレクトリ"AVCHDTN"には、例えばクリップの代表画像を所定サイズに縮小したサムネイルファイルが置かれる。ディレクトリ"BDMV"に、図１を用いて説明したデータ構造が格納される。
ディレクトリ"BDMV"の直下には、ファイルは、ファイル"index.bdmv"およびファイル"MovieObject.bdmv"の２つのみを置くことができる。また、ディレクトリ"BDMV"の下に、ディレクトリ"PLAYLIST"、ディレクトリ"CLIPINF"、ディレクトリ"STREAM"およびディレクトリ"BACKUP"が置かれる。ディレクトリ"BACKUP"は、各ディレクトリおよびファイルのバックアップが格納される。
ファイル"index.bdmv"は、ディレクトリBDMVの内容について記述される。すなわち、このファイル"index.bdmv"が上述した最上層のレイヤであるインデックスレイヤにおけるインデックステーブルに対応する。また、ファイルMovieObject.bdmvは、１つ以上のムービーオブジェクトの情報が格納される。すなわち、このファイル"MovieObject.bdmv"が上述したオブジェクトレイヤに対応する。
ディレクトリ"PLAYLIST"は、プレイリストのデータベースが置かれるディレクトリである。すなわち、ディレクトリ"PLAYLIST"は、プレイリストに関するファイルであるファイル"xxxxx.mpls"を含む。ファイル"xxxxx.mpls"は、プレイリストのそれぞれに対して作成されるファイルである。ファイル名において、"."（ピリオド）の前の"xxxxx"は、５桁の数字とされ、ピリオドの後ろの"mpls"は、このタイプのファイルに固定的とされた拡張子である。
ディレクトリ"CLIPINF"は、クリップのデータベースが置かれるディレクトリである。すなわち、ディレクトリCLIPINF"は、クリップＡＶストリームファイルのそれぞれに対するクリップインフォメーションファイルであるファイル"zzzzz.clpi"を含む。ファイル名において、"."（ピリオド）の前の"zzzzz"は、５桁の数字とされ、ピリオドの後ろの"clpi"は、このタイプのファイルに固定的とされた拡張子である。
ディレクトリ"STREAM"は、実体としてのＡＶストリームファイルが置かれるディレクトリである。すなわち、ディレクトリ"STREAM"は、クリップインフォメーションファイルのそれぞれに対応するクリップＡＶストリームファイルを含む。クリップＡＶストリームファイルは、ＭＰＥＧ２(Moving Pictures Experts Group 2)のトランスポートストリーム（以下、ＭＰＥＧ２ ＴＳと略称する）からなり、ファイル名が"zzzzz.m2ts"とされる。ファイル名において、ピリオドの前の"zzzzz"は、対応するクリップインフォメーションファイルと同一することで、クリップインフォメーションファイルとこのクリップＡＶストリームファイルとの対応関係を容易に把握することができる。
なお、ディレクトリ"AVCHDTN"は、２種類のサムネイルファイル"thumbnail.tidx"および"thumbnail.tdt2"を置くことができる。サムネイルファイル"thumbnail.tidx"は、所定の方式で暗号化されたサムネイル画像が格納される。サムネイルファイル"thumbnail.tdt2"は、暗号化されていないサムネイル画像が格納される。例えばビデオカメラでユーザが撮影したクリップに対応するサムネイル画像は、コピーフリーであって暗号化する必要が無いと考えられるため、このサムネイルファイル"thumbnail.tdt2"に格納される。
図５で示した各ファイルのうち、この発明に関わりの深いものについて、より詳細に説明する。先ず、ディレクトリ"BDMV"の直下に置かれるファイル"index.bdmv"について説明する。図６は、このファイル"index.bdmv"の一例の構造を表すシンタクスを示す。ここでは、シンタクスをコンピュータ装置などのプログラムの記述言語として用いられるＣ言語の記述法に基づき示す。これは、他のシンタクスを表す図において、同様である。
図６において、フィールドTypeIndicatorは、３２ビットのデータ長を有し、このファイルがインデックステーブルであることを示す。フィールドTypeIndicator2は、３２ビットのデータ長を有し、このファイル"index.bdmv"のバージョンを示す。フィールドIndexesStartAddressは、３２ビットのデータ長を有し、このシンタクス内にあるブロックblkIndexes()の開始アドレスを示す。
フィールドExtensionDataStartAddressは、３２ビットのデータ長を有し、このシンタクス内にあるブロックblkExtensionData()の開始アドレスを示す。ブロックblkExtensionData()は、所定の拡張データを格納可能とするためのブロックである。フィールドExtensionDataStartAddressは、このファイル"index.bdmv"の最初のバイトからの相対バイト数で、ブロックblkExtensionData()の開始アドレスを示す。相対バイト数は、"０"から開始される。若し、このフィールドExtensionDataStartAddressの値が"０"であれば、このファイル"index.bdmv"内に、ブロックblkExtensionData()が存在しないことを示す。
フィールドExtensionDataStartAddressに続けて、データ長が１９２バイトの領域reservedが配される。なお、領域reservedは、バイトアライメントや、将来的なフィールドの追加などのための領域である。これは、以下の説明においても同様である。ブロックblkAppInfoBDMV()は、コンテンツ制作者が任意の情報を記述できるブロックであって、プレーヤの動作などには影響を与えない。
ブロックblkIndexes()は、このファイル"index.bdmv"の実質的な内容であって、このファイル"index.bdmv"に記述された内容により、ディスクをプレーヤに装填した際に再生されるファーストプレイバックや、トップメニューから呼び出されるタイトル（ムービーオブジェクト）が指定される。インデックステーブルにより呼び出されたムービーオブジェクト等に記述されたコマンドに基づき、後述するプレイリストファイルが読み込まれる。
図７は、ブロックblkIndexes()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLength直後からこのブロックblkIndexes()の終わりまでのデータ長を示す。続けて、ブロックFirstPlaybackTitle()およびブロックMenuTitle()が配される。
ブロックFirstPlaybackTitle()は、ファーストプレイバックで用いられるオブジェクトに関する情報が記述される。ブロックFirstPlaybackTitle()は、１ビットのデータ長を有する領域reservedに続けて固定値"1"が記述される。さらに３１ビットのデータ長を有する領域reservedを介して固定値"1"が記述される。そして、１４ビットのデータ長を有する領域reservedを介して、１６ビットのデータ長を有するフィールドFirstPlaybackTitleMobjIDRefが配される。このフィールドFirstPlaybackTitleMobjIDRefにより、ファーストプレイバックタイトルで用いられるムービーオブジェクトのＩＤを示す。
ムービーオブジェクトのＩＤは、例えば、図８および図９を用いて後述するムービーオブジェクトのシンタクスに基づき、ムービーオブジェクトのforループ文においてループ変数として用いられる値mobj_idで示される。この例では、フィールドFirstPlaybackTitleMobjIDRefは、参照するムービーオブジェクトに対応する値mobj_idが格納される。
なお、ブロックblkIndexes()におけるブロックFirstPlaybackTitle()内のフィールドFirstPlaybackTitleMobjIDRefは、トップメニューのムービーオブジェクトを指していてもよいし、タイトルを指していてもよい。
ブロックMenuTitle()は、トップメニューで用いられるオブジェクトに関する情報が記述される。ブロックMenuTitle()は、１ビットのデータ長を有する領域reservedに続けて固定値"1"が記述される。さらに３１ビットのデータ長を有する領域reservedを介して固定値"1"が記述される。そして、１４ビットのデータ長を有する領域reservedを介して、１６ビットのデータ長を有するフィールドMenuTitleMobjIDRefが配される。フィールドMenuTitleMobjIDRefは、メニュータイトルで用いられるムービーオブジェクトのＩＤを示す。
ブロックMenuTitle()の次のフィールドNumberOfTitlesは、１６ビットのデータ長を有し、ユーザが選択、再生可能なタイトルの数を示す。次のforループ文に従い、このフィールドNumberOfTitlesに示される回数だけ、値title_idを引数として、ブロックMovieTitle[title_id]()が記述される。ブロックMovieTitle[title_id]()は、タイトル毎の情報が記述される。値title_idは、"０"からフィールドNumberOfTitlesで示される値までの数値であり、タイトルを識別する。
ブロックMovieTitle[title_id]()において、１ビットのデータ長を有する領域reservedを介して固定値"1"が記述され、さらに、４６ビットのデータ長を有する領域reservedを介してフィールドMovieTitleMobjIDRefが記述される。フィールドMovieTitleMobjIDRefは、１６ビットのデータ長を有し、このタイトルで用いられるムービーオブジェクトのＩＤを示す。フィールドMovieTitleMobjIDRefの後ろに、３２ビットのデータ長を有する領域reservedが配される。
図８は、ディレクトリ"BDMV"の直下に置かれるファイル"MovieObject.bdmv"の一例の構造を表すシンタクスを示す。フィールドTypeIndicatorは、３２ビット（４バイト）のデータ長を有し、このファイルがファイル"MovieObject.bdmv"であることを示す。フィールドTypeIndicatorは、ＩＳＯ(International Organization for Standarization)６４６に規定された符号化方式で符号化した４文字からなる文字列が記述される。この図８の例では、フィールドtype_indicatiorにＩＳＯ６４６に既定の方式で符号化された４文字の文字列"MOBJ"が記述され、このファイルがファイル"MovieObject.bdmv"であることが示される。
フィールドTypeIndicator2は、３２ビット（４バイト）のデータ長を有し、このファイル"MovieObject.bdmv"のバージョン番号を示す。このファイル"MovieObject.bdmv"では、フィールドTypeIndicator2は、ＩＳＯ６４６に規定された符号化方式で符号化した４文字の文字列"0100"でなければならない。
フィールドExtensionDataStartAddressは、３２ビットのデータ長を有し、このシンタクス内にあるブロックblkExtensionData()の開始アドレスを示す。フィールドExtensionDataStartAddressは、このファイル"MovieObject.bdmv"の最初のバイトからの相対バイト数で、ブロックblkExtensionData()の開始アドレスを示す。相対バイト数は、"０"から開始される。若し、このフィールドExtensionDataStartAddressの値が"０"であれば、このファイル"MovieObject.bdmv"内に、ブロックblkExtensionData()が存在しないことを示す。
なお、この図８に示すシンタクス内のフィールドpadding_wordは、１６ビットのデータ長を有し、このファイル"MovieObject.bdmv"のシンタクスに従いforループ文に値N1または値N2で示される回数だけ挿入される。値N1または値N2は、"０"または任意の正の整数である。また、フィールドpadding_wordは、任意の値を用いることができる。
フィールドExtensionDataStartAddressに続けてデータ長が２２４ビットの領域reservedが配され、その次に、このファイル"MovieObject.bdmv"の本体であるブロックblkMovieObjects()が格納される。
図９は、ブロックblkMovieObjects()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からこのブロックblkMovieObjects()の終わりまでのデータ長を示す。３２ビットのデータ長を有する領域reservedを介してフィールドNumberOfMobjsが配される。フィールドNumberOfMobjsは、直後のforループ文に従い格納されるムービーオブジェクトの数を示す。forループ文のループ変数として用いられる値mobj_idで、ムービーオブジェクトが一意に特定される。値mobj_idは、"０"から始まる値で、ムービーオブジェクトは、forループ文中に記述される順序により定義される。
forループ文中のブロックTerminalInfo()は、固定値"1"が記述され、次に１５ビットのデータ長を有する領域reservedが配される。その次に、１６ビットのデータ長を有するフィールドNumberOfNavigationCommands[mobj_id]が配される。このフィールドNumberOfNavigationCommands[mobj_id]は、値mobj_idによって指し示されるムービーオブジェクトMovieObject[mobj_id]()に含まれるナビゲーションコマンド(NavigationCommand)の数を表す。
次の、値command_idをループ変数とするforループ文により、フィールドNumberOfNavigationCommands[mobj_id]に示される数だけ、ナビゲーションコマンドが記述される。すなわち、このforループ文中に配されるフィールドNavigationCommand[mobj_id][command_id]は、値mobj_idによって指し示されるブロックMovieObject[mobj_id]()に含まれる、値command_idで示される順番のナビゲーションコマンドNavigationCommandを格納する。値command_idは、０から始まる値で、ナビゲーションコマンドNavigationCommandは、このforループ文中に記述される順序で定義される。
図１０は、プレイリストファイル"xxxxx.mpls"の一例の構造を表すシンタクスを示す。フィールドTypeIndicatorは、３２ビット（４バイト）のデータ長を有し、このファイルがプレイリストファイルであることを示す。フィールドTypeIndicator2は、３２ビット（４バイト）のデータ長を有し、このプレイリストファイルのバージョンを示す。フィールドPlayListStartAddressは、３２ビットのデータ長を有し、このシンタクス中のブロックblkPlayList()の開始アドレスを示す。
フィールドPlayListMarkStartAddressは、３２ビットのデータ長を有し、このシンタクス中のブロックblkPlayListMark()の開始アドレスを示す。フィールドExtensionDataStartAddressは、３２ビットのデータ長を有し、このシンタクス中のブロックblkExtensionData()の開始アドレスを示す。フィールドExtensionDataStartAddressは、ブロックblkExtensionData()の開始アドレスを、ファイル"xxxxx.mpls"の最初のバイトからの相対バイト数を表した値である。相対バイト数は、"０"から開始される。若し、このフィールドExtensionDataStartAddressの値が"０"であれば、このファイル"xxxxx.mpls"内に、ブロックblkExtensionData()が存在しないことを示す。
１６０ビットのデータ長を有する領域reservedを介してブロックblkAppInfoPlayList()が配される。ブロックblkAppInfoPlayList()は、次のブロックblkPlayList()に記述されるプレイリストのタイプ、再生制限などの情報が記述される。ブロックblkPlayList()は、プレイリストが記述される。ブロックblkPlayListMark()は、チャプタジャンプなどでジャンプされるポイントが記述される。ブロックblkExtensionData()は、所定の拡張データを格納可能とするためのブロックである。
図１１は、ブロックblkPlayList()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkPlayList()の最後までのデータ長を示す。フィールドLengthに続けて１６ビットのデータ長を有する領域reservedが配され、次にフィールドNumberOfPlayItemsが配される。フィールドNumberOfPlayItemsは、１６ビットのデータ長を有し、このブロックblkPlayList()に含まれるプレイアイテムの数を示す。フィールドNumberOfSubPathは、このブロックblkPlayList()に含まれるサブパスの数を示す。
次のforループ文に従い、フィールドNumberOfPlayItemsで示される数だけ、プレイアイテムが記述されるブロックblkPlayItem()が記述される。forループ文に基づくカウント数がブロックblkPlayItem()の識別子PlayItem_idとなる。さらに次のforループ文に従い、フィールドNumberOfSubPathで示される数だけ、ブロックblkSubPath()が記述される。forループ文に基づくカウント数がブロックblkSubPath()の識別子SubPath_idとなる。
なお、サブパスは、主として再生されるプレイアイテムに対応するメインパスに対して、サブプレイアイテムに対応して持つことができる。サブパスは、例えば、アフレコ用のオーディオデータの指定や、２枚の映像を合成する際に、プレイアイテムで指定されるクリップと同期して再生する副映像を指定するといった目的で用いられる。
図１２は、ブロックblkPlayItem()の一例の構造を表すシンタクスを示す。フィールドLengthは、１６ビットのデータ長を有し、このフィールドLengthの直後からブロックblkPlayItem()の最後までのデータ長を示す。
フィールドClipInformationFileNameは、４０ビット（５バイト）のデータ長を有し、このブロックblkPlayItem()が参照するクリップインフォメーションファイルのファイル名が示される。このプレイアイテムにおいて、フィールドClipInformationFileNameで示されるファイル名のクリップインフォメーションファイルが読み出される。フィールドClipCodecIdentifierは、３２ビット（４バイト）のデータ長を有し、このブロックblkPlayItem()によるプレイアイテムにおいて用いられるクリップＡＶストリームのコーデック方式を示す。
１２ビットのデータ長を有する領域reservedを介して、フィールドConnectionConditionが配される。フィールドConnectionConditionは、４ビットのデータ長を有し、クリップ間の接続状態に関する情報を示す。記録用途の記録媒体に対しては、フィールドConnectionConditionの値として"１"、"５"または"６"が用いられる。フィールドConnectionConditionの値が"１"で、そのプレイアイテムから参照されているクリップと手前のプレイアイテムから参照されているクリップとがシームレス接続しないことを示し、フィールドConnectionConditionの値が"５"または"６"で、そのプレイアイテムから参照されているクリップと手前のプレイアイテムから参照されているクリップとがシームレス接続することを示す。なお、シームレス接続とは、クリップと次のクリップとがフレームタイミングで連続的に再生されるように、クリップ間の再生制御を行うことをいう。
フィールドConnectionConditionの値が"５"で、当該プレイアイテムが参照するクリップにおいて、オーディオデータの記録長がビデオデータの記録長に対して長くされる（図１３Ａ参照）。これにより、クリップとクリップとを接続する際に、オーディオデータのフェイドアウト処理が可能とされる。例えば、ユーザによる記録停止操作によりクリップがクローズされる場合に、フィールドConnectionConditionの値が"５"とされる。以下、このフィールドConnectionConditionの値が"５"で示されるクリップの接続方法を、第１のシームレス接続と呼ぶ。
フィールドConnectionConditionの値が"６"で、当該プレイアイテムが参照するクリップにおいて、オーディオデータの記録長がビデオデータの記録長に対して同じにされる（図１３Ｂ参照）。これにより、クリップとクリップとの接続をシームレスに行うことが可能とされる。例えば、ユーザ操作に応じた記録停止以外の理由、例えばシステム要因に基づきクリップがクローズされる場合に、フィールドConnectionConditionの値が"６"とされる。以下、このフィールドConnectionConditionの値が"６"で示されるクリップの接続方法を、第２のシームレス接続と呼ぶ。
フィールドRefToSTCIDは、８ビットのデータ長を有し、システムタイムベース（ＳＴＣ）の不連続点に関する情報を示す。フィールドINTimeおよびフィールドOUTTimeは、それぞれ３２ビットのデータ長を有し、メインクリップＡＶストリームの再生範囲を示す。フィールドINTimeが開始点（ＩＮ点）を示し、フィールドOUTTimeが終了点（ＯＵＴ点）を示す。
ブロックblkUOMaskTable()は、ユーザ入力の受付制限が設定されるテーブルである。１ビットのデータ長を有するフラグPlayItemRandomAccessFlagは、このブロックblkPlayItem()によるプレイアイテムに対してランダムアクセスを許可するか否かを規定する。続けて、７ビットのデータ長を有する領域reservedを介してフィールドStillModeが配される。フィールドStillModeは、８ビットのデータ長を有し、ブロックblkPlayItem()によるプレイアイテムにおいて、最後に表示した映像を静止画として表示させるか否かを示す。フィールドStillModeの値が"0x01"（バイナリ）であれば、if文に基づき、１６ビットのデータ長を有するフィールドStillTimeにより静止時間が示される。フィールドStillModeの値が"0x01"以外であれば、当該１６ビットのデータ長を有する領域が領域reservedとされる。
なお、数値の記述において"0x"は、その数値が１６進表記されていることを示す。これは、以下の同様な表記について共通である。
ブロックblkSTNTable()は、このブロックblkPlayItem()によるプレイアイテムが管理しているクリップＡＶストリームの属性、ＰＩＤ番号、記録媒体上での記録位置などが管理される。
図１４は、ブロックblkPlayListMark()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkPlayListMark()の最後までのデータ長を示す。
フィールドNumberOfPlayListMarksは、１６ビットのデータ長を有し、このブロックblkPlayListMark()に含まれるプレイリストマークの数を示す。次のforループ文に従い、フィールドNumberOfPlayListMarksで示される数だけプレイリストマークの情報が記述される。
forループ文内において、８ビットのデータ長を有する領域reserveに続けてフィールドMarkTypeが配される。フィールドMarkTypeは、８ビットのデータ長を有し、マークのタイプを示す。プレイリストマークには、エントリマーク(Entry Mark)およびリンクポイント(Link Point)の２タイプが定義されており、このフィールドMarkTypeにより、何れのタイプであるかが示される。チャプタを定義するためには、エントリマークを用いる。リンクポイントは、この発明と関連性が薄いので、説明を省略する。上述したフィールドNumberOfPlayListMarksは、エントリマークおよびリンクポイントを合計した値を示す。
フィールドRefToPlayItemIDは、１６ビットのデータ長を有し、マークが打たれるプレイアイテムを参照する識別情報PlayItem_idが記述される。フィールドMarkTimeStampは、３２ビットのデータ長を有し、マークが打たれるポイントを示すタイムスタンプが記述される。フィールドEntryESPIDは、１６ビットのデータ長を有し、マークによって指し示されるエレメンタリストリームを含んでいるＴＳパケットのＰＩＤの値を示す。フィールドDurationは、４５ｋＨｚのクロックを単位とした計測による、３２ビットのデータ長を有する符号無し整数である。このフィールドDurationに格納される値が"０"であれば、このフィールドDurationは、意味を成さない。
図１５は、クリップインフォメーションファイルの一例の構造を表すシンタクスを示す。フィールドTypeIndicatorは、３２ビット（４バイト）のデータ長を有し、このファイルがクリップインフォメーションファイルであることを示す。フィールドTypeIndicator2は、３２ビット（４バイト）のデータ長を有し、このクリップインフォメーションファイルのバージョンを示す。
このクリップインフォメーションファイルは、ブロックblkClipInfo()、ブロックblkSequenceInfo()、ブロックblkProgramInfo()、ブロックblkCPI()、ブロックblkClipMark()およびブロックblkExtensionData()を有し、それぞれ３２ビットのデータ長を有するフィールドSequenceInfoStartAddress、フィールドProgramInfoStartAddress、フィールドCPIStartAddress、フィールドClipMarkStartAddressおよびフィールドExtensionDataStartAddressは、各々対応するブロックの開始アドレスを示す。
フィールドExtensionDataStartAddressは、このクリップインフォメーションファイルの最初のバイトからの相対バイト数で、ブロックblkExtensionData()の開始アドレスを示す。相対バイト数は、"０"から開始される。若し、このフィールドExtensionDataStartAddressの値が"０"であれば、このファイル"index.bdmv"内に、ブロックblkExtensionData()が存在しないことを示す。
ブロックblkClipInfo()は、これらの開始アドレスを示すフィールドに続く、９６ビットのデータ長を有する領域reservedの次から開始される。ブロックblkClipInfo()は、このクリップインフォメーションファイルが管理するクリップＡＶストリームに関する情報が記述される。ブロックblkSequenceInfo()は、ＳＴＣやＡＴＣ（アライバルタイムベース）が連続しているシーケンスをまとまりとして管理する情報が記述される。ブロックblkProgramInfo()は、このクリップインフォメーションファイルに管理されるクリップＡＶストリームの符号化方式、クリップＡＶストリーム中のビデオデータのアスペクト比などの情報が記述される。ブロックblkCPI()は、ランダムアクセス開始点などの、ＡＶストリーム中の特徴的な箇所を表す特徴点情報ＣＰＩに関する情報が格納される。
また、ブロックblkClipMark()は、チャプタ位置などの、クリップに付された頭出しのためのインデックス点（ジャンプポイント）が記述される。ブロックblkExtensionData()は、拡張データを格納することができる領域である。なお、クリップインフォメーションファイル内のブロックblkClipMark()およびブロックblkSequenceInfo()は、この発明との関連性が薄いので、詳細な説明を省略する。
図１６は、クリップインフォメーションファイルにおけるブロックblkCPI()の一例の構造を表すシンタクスを示す。ＭＰＥＧストリームのような、フレーム間圧縮を行っている符号化ストリームにおいては、デコード開始可能な箇所は、ＧＯＰ(Group Of Picture)の先頭など一部の箇所に限定されていることが多い。ＣＰＩ(Characteristic Point Information)とは、そのデコード可能な開始点の位置の情報を集めたデータベースで、再生時刻と、ファイル内アドレスとが対応付けられたテーブルになっている。すなわち、ＣＰＩは、デコード単位の先頭位置を示す情報がテーブル化されている。
このようにデータベースを定めることで、例えば、任意の時刻から再生したい場合、再生時刻を元にＣＰＩを参照することによって再生位置のファイル内アドレスがわかる。このアドレスは、デコード単位の先頭となっているため、プレーヤは、そこからデータを読み出してデコードし、素早く画像を表示することができる。
なお、このＣＰＩに格納される、デコード単位の先頭位置（この例ではＧＯＰの先頭位置）を、ＥＰ(Entry Point)エントリと称する。
図１６において、フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkCPI()の最後までのデータ長を示す。次のif文に従い、フィールドLengthの値が０でなければ、１２ビットのデータ長を有する領域reservedを介してフィールドCPITypeが配される。フィールドCPITypeは、４ビットのデータ長を有し、ＣＰＩの種類を示す。次のブロックblkEPMap()は、対応するクリップＡＶストリームファイルにおけるＰＴＳ値とバイトアドレスとの関連付けを行うテーブルが格納される。
図１７は、ブロックblkEPMap()の一例の構造を表すシンタクスを示す。８ビットのデータ長を有する領域reservedを介してフィールドNumberOfStreamPIDEntriesが配される。フィールドNumberOfStreamPIDEntriesは、８ビットのデータ長を有し、ブロックblkEPMap()におけるブロックblkEPMapForOneStreamPIDのエントリ数を示す。forループ文に従い、値[k]をループ変数として、フィールドNumberOfStreamPIDEntriesに示される数だけ、エントリポイントに関する情報が記述される。
forループ文内において、フィールドStreamPID[k]は、１６ビットのデータ長を有し、ブロックblkEPMap()の中で[k]番目にエントリされるブロックblkEPMapForOneStreamPID（以下、[k]番目のブロックblkEPMapForOneStreamPIDと記述する）によって参照されるエレメンタリストリームを伝送するトランスポートパケットのＰＩＤの値を示す。
１０ビットのデータ長を有する領域reservedを介してフィールドEPStreamType[k]が配される。フィールドEPStreamType[k]は、４ビットのデータ長を有し、[k]番目のブロックblkEPMapForOneStreamPIDによって参照されるエレメンタリストリームのタイプを示す。フィールドNumberOfEPCoarseEntries[k]は、１６ビットのデータ長を有し、[k]番目のブロックblkEPMapForOneStreamPIDの中にある粗い検索用のサブテーブル(EP coarse table)のエントリ数を示す。フィールドNumberOfEPFineEntries[k]は、１８ビットのデータ長を有し、[k]番目のブロックblkEPMapForOneStreamPIDの中にある精密な検索用のサブテーブル(EP fine table)のエントリ数を示す。フィールドEPMapForOneStreamPIDStartAddress[k]は、３２ビットのデータ長を有し、ブロックblkEPMap()の中で[k]番目のブロックblkEPMapForOneStreamPIDが始まる相対バイト位置を示す。この値は、ブロックblkEPMap()の第１バイト目からのバイト数で示される。
上述のforループ文による記述の後、１６ビットの整数倍のデータ長を有するパディングワードを挟んで記述されるforループ文に従い、値[k]をループ変数として、フィールドNumberOfStreamPIDEntriesに示される数だけ、ブロックblkEPMapForOneStreamPID(EPStreamType[k], NumberOfEPCoarseEntries[k], NumberOfEPFineEntries[k])が格納される。すなわち、引数NumberOfEPCoarseEntries[k]は、サブテーブル(EP coarse table)に格納されるエントリPTSEPCoarseおよびエントリSPNEPCoarseの数を示す。同様に、引数NumberOfEPFineEntries[k]は、サブテーブル(EP fine table)に格納されるエントリPTSEPFineおよびエントリSPNEPFineの数を示す。以下では、引数NumberOfEPCoarseEntries[k]および引数NumberOfEPFineEntries[k]を、それぞれ適宜、エントリ数Ncおよびエントリ数Nfと呼ぶ。
図１８は、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)の一例の構造を表すシンタクスを示す。ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)のセマンティクスを説明するために、先ず、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)に格納されるデータの元となるエントリである、エントリPTSEPStartおよびエントリSPNEPStartの意味について説明する。
エントリPTSEPStartと、エントリPTSEPStartに関連付けられたエントリSPNEPStartは、それぞれＡＶストリーム上のエントリポイントを指す。そして、エントリPTSEPFineと、エントリPTSEPFineに関連付けられたエントリPTSEPCoarseは、同一のエントリPTSEPStartから導かれる。また、エントリSPNEPFineと、エントリSPNEPFineに関連付けられたエントリSPNEPCoarseは、同一のエントリSPNEPStartから導かれる。
図１９は、エントリPTSEPCoarseおよびエントリPTSEPFineの一例のフォーマットについて示す。ＰＴＳすなわちエントリPTSEPStartは、データ長が３３ビットの値である。ＭＳＢのビットを第３２ビット、ＬＳＢのビットを第０ビットとするとき、この図１９の例では、大まかな単位で検索を行う際に用いられるエントリPTSEPCoarseは、エントリPTSEPStartの第３２ビットから第１９ビットまでの１４ビットが用いられる。エントリPTSEPCoarseにより、解像度が５．８秒で、２６．５時間までの範囲で検索が可能である。また、より精密な検索を行うためのエントリPTSEPFineは、エントリPTSEPStartの第１９ビットから第９ビットまでの１１ビットが用いられる。エントリPTSEPFineにより、解像度が５．７ミリ秒で、１１．５秒までの範囲で検索が可能である。なお、第１９ビットは、エントリPTSEPCoarseとエントリPTSEPFineとで共通して用いられる。また、ＬＳＢ側の第０ビットから第８ビットまでの９ビットは、用いられない。
図２０は、エントリSPNEPCoarseおよびエントリSPNEPFineの一例のフォーマットについて示す。ソースパケット番号すなわちエントリSPNEPStartは、データ長が３２ビットの値である。ＭＳＢのビットを第３１ビット、ＬＳＢのビットを第０ビットとするとき、この図２０の例では、大まかな単位で検索を行う際に用いられるエントリSPNEPCoarseは、エントリSPNEPStartの第３１ビットから第０ビットまでの全てのビットが用いられる。また、より精密な検索を行うためのエントリSPNEPFineは、エントリSPNEPStartの第１６ビットから第０ビットまでの１７ビットが用いられる。エントリSPNEPFineにより、例えば略２５ＭＢ(Mega Byte)のＡＶストリームファイルまでの範囲で、検索が可能である。
なお、ソースパケット番号の場合でも、エントリSPNEPCoarseとしてＭＳＢ側の所定ビット数の値だけ用いるようにしてもよい。例えば、エントリSPNEPCoarseとして、エントリSPNEPStartの第３１ビットから第１６ビットまでの１７ビットを用い、エントリSPNEPFineは、エントリSPNEPStartの第１６ビットから第０ビットまでの１７ビットを用いる。
上述に基づき、エントリPTSEPStartおよびエントリSPNEPStartは、次のように定義される。
エントリPTSEPStartは、図１９で示したように、データ長が３３ビットの符号無し整数であり、ＡＶストリーム中で、ランダムアクセスが可能なピクチャ（例えばＩＤＲ(Instantaneous Decoding Refresh)ピクチャやＩ(Intra)ピクチャ）から開始するビデオアクセスユニットの３３ビット長のＰＴＳを示す。
エントリSPNEPStartは、図２０で示したように、３２ビットの符号無し整数であり、エントリPTSEPStartに関連付けられたビデオアクセスユニットの第１バイト目を含むソースパケットの、ＡＶストリームの中でのアドレスを示す。エントリSPNEPStartは、ソースパケット番号の単位で表され、ＡＶストリームファイル中の最初のソースパケットから、値"０"を初期値として、ソースパケット毎に１ずつ増加する値としてカウントされる。
図１８を参照し、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)は、第１のforループ文により大まかな単位での検索を行うためのサブテーブル(EP coarse table)が記述され、第２のforループ文によりサブテーブル(EP coarse table)の検索結果に基づきより詳細な検索を行うためのサブテーブル(EP fine table)が記述される。
第１のforループ文の直前に、フィールドEPFineTableStartAddressが配される。フィールドEPFineTableStartAddressは、３２ビットのデータ長を有し、最初の第２のforループにおけるフィールドReservedEPFine[EP_fine_id]の第１バイト目の開始アドレスを、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)の第１バイト目からの相対バイト数で示す。相対バイト数は、値"０"から開始する。
第１のforループ文は、ループ変数[i]で以て、サブテーブル(EP coarse table)のエントリ数Ncまで繰り返され、エントリ数Ncの組数だけフィールドRefToEPFineID[i]、エントリPTSEPCoarse[i]およびエントリSPNEPCoarse[i]が格納される。第１のforループ文において、フィールドRefToEPFineID[i]は、１８ビットのデータ長を有し、フィールドRefToEPFineID[i]に続くフィールドPTSEPCoarse[i]が示すエントリPTSEPCoarseに関連付けられるエントリPTSEPFineを持つ、サブテーブル(EP fine table)内のエントリ番号を示す。エントリPTSEPFineと、このエントリPTSEPFineに関連付けられるエントリPTSEPCoarseとは、同一のエントリPTSEPStartから導かれる。フィールドRefToEPFineID[i]は、第２のforループ文中で記述される順番で定義されるループ変数[EP_fine_id]の値により与えられる。
第１のforループ文の後に、パディングワードを挟んで第２のforループ文による記述がなされる。第２のforループ文は、ループ変数[EP_fine_id]で以て、サブテーブル(EP fine table)のエントリ数Nfまで繰り返され、エントリ数Nfの組数だけ、１ビットのデータ長を有するフィールドReservedEPFine[EP_fine_id]と、３ビットのデータ長を有するフィールドIEndPositionOffset[EP_fine_id]と、１１ビットのデータ長を有するフィールドPTSEPFine[EP_fine_id]と、１７ビットのデータ長を有するフィールドSPNEPFine[EP_fine_id]とが格納される。これらのうち、フィールドPTSEPFine[EP_fine_id]およびフィールドSPNEPFine[EP_fine_id]は、ループ変数[EP_fine_id]に基づきサブテーブル(EP fine table)から参照されるエントリPTSEPFineおよびエントリSPNEPFineそれぞれが格納される。
エントリPTSEPCoarseおよびエントリPTSEPFine、ならびに、エントリSPNEPCoarseおよびエントリSPNEPFineは、次のように導かれる。サブテーブル(EP fine table)に、関連するデータSPNEPStartの値の昇順に並んでいるNf個のエントリがあるとする。それぞれのエントリPTSEPFineは、対応するエントリPTSEPStartから、次式（１）のように導かれる。
PTSEPFine[EP_fine_id]＝（PTSEPStart[EP_fine_id] >>９）／２11 ・・（１）
エントリPTSEPCoarseと、対応するエントリPTSEPFineとの関係は、次式（２）、（３）の通りである。
PTSEPCoarse[i]＝（PTSEPStart[RefToEPFineID[i]] >>１９）／２14 ・・（２）
PTSEPFine[RefToEPFineID[i]]＝（PTSEPStart[RefToEPFineID[i]] >>９）／２11 ・・（３）
それぞれのエントリSPNEPFineは、対応するエントリSPNEPStartから、次式（４）のように導かれる。
SPNEPFine[EP_fine_id]＝SPNEPStart[EP_fine_id]／２17 ・・（４）
エントリSPNEPCoarseと、対応するエントリSPNEPFineとの関係は、次式（５）、（６）の通りである。
SPNEPCoarse[i]＝SPNEPStart[RefToEPFineID[i]] ・・（５）
SPNEPFine[RefToEPFineID[i]]＝SPNEPStart[RefToEPFineID[i]]／２17 ・・（６）
なお、上述の式（１）〜（６）において、記号「>>ｘ」は、データのＬＳＢ側からｘビットを超える桁からビットを用いることを意味する。
次に、この発明の実施の一形態について説明する。この発明では、プレイリストに対してプレイリストマークを設けてクリップの分割編集を行う際に、プレイリストマークを設ける位置に対応するＧＯＰがクローズドＧＯＰであれば、アドレス情報すなわちＧＯＰ境界にプレイリストマークを設け、当該ＧＯＰがオープンＧＯＰであれば、再生時刻情報すなわち上述したエントリPTSEPStart（図２０参照）で示される位置にプレイリストマークを設ける。
例えば、記録開始位置は、それ以前のＧＯＰの情報を用いることができないので、通常はクローズドＧＯＰ構造となる。そのため、記録開始位置では、プレイリストマークをＧＯＰ境界に設ける。記録開始位置以外では、プレイリストマークをエントリPTSEPStartで示される位置に設ける。また、記録開始位置以外でも、プレイリストマークを設けようとする位置に対応するＧＯＰがクローズドＧＯＰおよびオープンＧＯＰのうち何れであるかが判別できれば、判別結果に応じて、ＧＯＰ境界またはエントリPTSEPStartのうち適合する方にプレイリストマークを設ける。
このように制御することで、チャプタジャンプ時に、ジャンプ先でのデコード範囲を最小限とすることが可能となると共に、チャプタ境界と本来の記録開始位置とが一致するようにできる。
なお、この発明の実施の一形態では、チャプタ分割位置を指定するためのプレイリストマークは、全てタイプがエントリマークであるものとする。
以下、この発明の実施の一形態によるチャプタ分割について、より詳細に説明する。なお、以下では、プレイリストマークの種類がエントリマークに固定的であるものとして説明する。
先ず、チャプタは、ユーザから見える最小の再生区間単位であって、隣接するプレイリストマークの間の区間を指す。ここで、プレイリストマークは、プレイリストで示される最後尾の位置には設けなくてもよいとされる。また、プレイリストで示される先頭の位置は、必ずプレイリストマークが設けられる。
さらに、この実施の一形態では、分割編集の時間的な粒度は、ＧＯＰ単位とする。また、記録開始位置が含まれるＧＯＰ以外のＧＯＰは、オープンＧＯＰであるものとする。これは、より高画質を実現するためである。
先ず、プレイリストに対してプレイリストマークを挿入する処理について説明する。図２１は、上述したこの発明に適用可能なフォーマットにおける、プレイリスト以下の一例のファイル構造を示す。この図２１の例では、プレイリスト＃１０は、それぞれ値PlayItem_id（図１１参照）で参照される３つのプレイアイテム＃０、＃１および＃２を含み、プレイアイテム＃０および＃１がクリップ＃２０の区間をそれぞれ参照し、プレイアイテム＃２がクリップ＃３１の区間を参照している。また、プレイリスト＃１１は、２つのプレイアイテム＃０および＃１を含み、これらプレイアイテム＃０および＃１がクリップ＃３１の区間をそれぞれ参照している。
上述したように、プレイアイテムは、時刻情報を用いて、クリップを構成するクリップインフォメーションに含まれるブロックblkEPMap()に記述されるエントリポイントを参照し、対応するクリップＡＶストリームファイル内のアドレスを指定する。これにより、プレイリストからクリップＡＶストリームファイルの部分を指定して所定の順序で再生させることができる。
さらに、図２１の例では、プレイリスト＃１０において、４個のプレイリストマークＰＬＭ＃０、ＰＬＭ＃１、ＰＬＭ＃２およびＰＬＭ＃３が設けられている。プレイリストにおいて、クリップ内のジャンプ可能なアクセス位置を示すマークを設定することができる。このマークを、プレイリストマーク（PlayListMark：ＰＬＭと適宜略称する）と呼ぶ。これらプレイリストマークは、プレイリストファイル中のブロックblkPlayListMark()において値PL_mark_idにより参照され、フィールドMarkTimeStampにより時刻情報で示される（図１４参照）。
次に、図２２を用いて、プレイリストを用いたクリップの分割編集について、概略的に説明する。図２２Ａは、プレイリストによってクリップが参照される様子を示す。記録媒体上に記録されたクリップ＃１およびクリップ＃２は、それぞれ、プレイリスト＃１内のプレイアイテム＃１およびプレイアイテム＃２から再生開始点（ＩＮ点）および再生終了点（ＯＵＴ点）を指定されて参照される。この図２２の例では、プレイアイテム＃１は、クリップ＃１の先頭（位置ａ）をＩＮ点とし、後端（位置ｂ）をＯＵＴ点としてクリップ＃１を参照している。プレイアイテム＃２についても同様に、クリップ＃２の先頭（位置ｃ）および後端（位置ｄ）をそれぞれＩＮ点およびＯＵＴ点として参照している。プレイリスト＃１は、プレイアイテム＃１およびプレイアイテム＃２の再生順を指定する。
したがって、この図２２Ａの例では、プレイリスト＃１により、クリップ＃１が位置ａから位置ｂまで再生され、クリップ＃１の位置ｂに続けてクリップ＃２が位置ｃから再生され、位置ｄで再生が終了する。すなわち、この図２２Ａの例では、プレイリスト＃１の指示により、クリップ＃１の先頭からクリップ＃２の最後までが連続的に再生される。
また、図２２Ａの例では、クリップ＃１の先頭の位置ａとクリップ＃２の先頭の位置ｃとに、プレイリストマークＰＬＭ＃１およびＰＬＭ＃２がそれぞれ設定されている。この場合、例えばプレイリスト＃１に従いクリップ＃１の位置ａから位置ｂの間の任意の位置で再生しているときにジャンプが指定されると、現在の再生位置に対して再生方向に向けて直近に設定されたプレイリストマークの位置（位置ａから位置ｂに向けて再生している場合、プレイリストマークＰＬＭ＃２の位置）に、再生位置がジャンプされ、プレイリストマークＰＬＭ＃２の位置から再生が継続されることになる。
クリップの途中にプレイリストマークを設定することで、当該クリップを仮想的に分割することができる。例えば、図２２Ｂに一例が示されるように、プレイリスト＃１に対し、クリップ＃２の所望の位置にプレイリストマークＰＬＭ＃３を設ける。これにより、図２２Ｃに一例が示されるように、クリップ＃２のプレイリストマークＰＬＭ＃３に対応する位置ｅをジャンプ位置として指定することが可能となり、クリップ＃２が位置ｅで仮想的に分割されたものと見なすことができるようになる。
なお、ユーザ側から見た場合、プレイリストで示される区間は、チャプタを単位として再生される。チャプタは、プレイリストに対してプレイリストマークを設けることで設定することができる。例えば、プレイリストで示される区間の先頭のみにプレイリストマークが設けられているか、プレイリストにプレイリストマークが全く設けられていなければ、当該プレイリスト全体が１のチャプタを構成する。
また、上述した図２２Ａの例ように、クリップ＃１の先頭の位置ａに対応する位置にプレイリストマークＰＬＭ＃１が設けられ、クリップ＃２の先頭の位置ｃに対応する位置にプレイリストマークＰＬＭ＃２が設けられていれば、プレイリストマークＰＬＭ＃１からＰＬＭ＃２までの区間がチャプタ＃１とされ、プレイリストマークＰＬＭ＃２からプレイリスト＃１の最後の位置までの区間がチャプタ＃２とされる。この場合は、プレイリスト＃１に示される全長がプレイリストマーク＃２により２のチャプタに分割されたことになる。
さらに、上述した図２２Ｃの例のように、クリップ＃２の途中の所望の位置ｅに対応するプレイリストマークＰＬＭ＃３が設けられた場合、図２２Ａのチャプタ＃２がプレイリストマークＰＬＭ＃３の位置でさらに分割され、プレイリストマークＰＬＭ＃２からプレイリストマークＰＬＭ＃３までの区間がチャプタ＃２とされ、プレイリストマークＰＬＭ＃３からプレイリスト＃１の最後の位置までの区間がチャプタ＃３とされる。
図２３は、プレイリストマークを追加挿入する一例の処理を示すフローチャートである。この処理では、プレイリスト内でプレイリストマークを格納するブロックblkPlayListMark()（図１４参照）を検索して、現在再生中の位置と既に設定されているプレイリストマークとの位置関係を求め、その結果に基づきプレイリストマークを追加挿入すると共に、ブロックblkPlayListMark()の情報を書き換える。
ステップＳ５０でカウント値ｉを値０として初期化し、次のステップＳ５１で現在再生中のプレイアイテム（図２３ではＰＩと表記）の番号がｉ番目のプレイリストマーク（図２３ではＰＬＭと表記）に参照されるプレイアイテムの番号より大きいか否かが判断される。
例えば、図１１のブロックblkPlayList()において、ループ変数PlayItem_idによるforループ文で記述されるブロックblkPlayItem()のうち、現在再生中のプレイアイテムに対応する値PlayItem_idを求め、求められた値PlayItem_idと、ブロックblkPlayListMark()におけるｉ番目の値RefToPlayItemIDとが比較される。若し、現在再生中のプレイアイテムの番号の方が大きいと判断されれば、カウント値ｉが１だけインクリメントされて処理がステップＳ５１に戻される。
一方、ステップＳ５１において、現在再生中のプレイアイテムの番号がｉ番目のプレイリストマークに参照されるプレイアイテムの番号より大きくない、すなわち、現在再生中のプレイアイテムとｉ番目のプレイリストマークに参照されるプレイアイテムの番号とが等しいか、若しくは、現在再生中のプレイアイテムの番号よりもｉ番目のプレイリストマークに参照されるプレイアイテムの番号の方が大きいと判断されると、処理はステップＳ５２に移行される。
ステップＳ５２では、現在再生中のプレイアイテムの番号と、ｉ番目のプレイリストマークに参照されるプレイアイテムの番号とが等しいか否かが判断される。若し、等しいと判断されれば、処理は次のステップＳ５３に移行される。一方、等しくないと判断されれば、処理は後述するステップＳ５４に移行される。
ステップＳ５３では、現在の再生時刻がｉ番目のプレイリストマークの指し示す再生刻よりも後であるか否かが判断される。現在の再生時刻は、例えばビデオストリームをデコードするデコーダから取得することができる。また、ｉ番目のプレイリストマークの指し示す再生時刻は、図１４を参照し、ブロックblkPlayListMark()におけるｉ番目の値MarkTimeStampに基づく。
若し、現在の再生時刻がｉ番目のプレイリストマークの指し示す時刻よりも後であると判断されたら、カウント値ｉが１だけインクリメントされて、処理がステップＳ５３に戻される。一方、現在の再生時刻がｉ番目のプレイリストマークの指し示す再生時刻より後ではない、すなわち、現在の再生時刻がｉ番目のプレイリストマークの指し示す再生時刻と等しいか、若しくは、現在の再生時刻がｉ番目のプレイリストマークが指し示す再生時刻より前であれば、処理はステップＳ５４に移行される。
ステップＳ５４では、ｉ番目の位置にプレイリストマーク（この場合はエントリマーク）を追加挿入する処理が行われる。ここでは、ブロックblkPlayListMark()において、既存のｉ番目のプレイリストマークと、（ｉ−１）番目のプレイリストマークとの間に、プレイリストマークが追加挿入されることになる。既存のｉ番目のプレイリストマークは、プレイリストマークの追加挿入処理後には、（ｉ＋１）番目のプレイリストマークとされる。
より詳細には、ブロックblkPlayListMark()において、現在再生中のプレイアイテムに対応する値PlayItem_idを、フィールドRefToPlayItemIDの値に設定する。また、フィールドMarkTimeStampの値は、現在の再生時刻を示す値とされる。さらに、フィールドNumberOfPlayListMarksの値が１だけインクリメントされ、フィールドLengthの値が再計算される。
なお、実際には、ブロックblkPlayListMark()はプレイリストファイルの一部なので、図１０に一例が示されるプレイリストファイルのシンタクスにおいて、フィールドExtensionDataStartAddressの値が、ブロックblkPlayListMark()におけるフィールドLengthの値に応じて書き換えられることになる。
図２４を用いてより具体的に説明する。なお、図２４Ａおよび図２４Ｂは、上述した図２１と同様の構造であるので、図そのものの詳細な説明は省略する。ここでは、図２４ＡにおいてプレイリストマークＰＬＭ＃２およびＰＬＭ＃３の間を再生中に、位置ａに対してプレイリストマークを追加挿入する場合について説明する。
カウント値ｉが初期化されて値が"０"とされ、位置ａに対応するプレイアイテムは、プレイアイテム＃２であるので、現在再生中のプレイアイテムの番号が２とされる。一方、ｉ番目すなわち０番目のプレイリストマーク＃０は、プレイアイテム＃０を参照しており、ｉ番目のプレイリストマークが参照するプレイアイテム番号が０とされる。ステップＳ５１の判断に基づき、現在再生中のプレイアイテムの番号がｉ番目のプレイリストマークが参照するプレイアイテム番号よりも大きいので、カウント値ｉが１だけインクリメントされて値が"１"とされ、再びステップＳ５１の判断がなされる。
２度目のステップＳ５１の判断では、ｉ番目すなわち１番目のプレイリストマークＰＬＭ＃１が参照するプレイアイテム番号と、現在再生中のプレイアイテム番号とが比較される。１番目のプレイリストマークＰＬＭ＃１は、プレイアイテム＃１を参照しており、参照するプレイアイテム番号が１とされる。ステップＳ５１の判断に基づき、現在再生中のプレイアイテムの番号がｉ番目のプレイリストマークが参照するプレイアイテム番号よりも大きいので、カウント値ｉが１だけインクリメントされて値が"２"とされ、再びステップＳ５１の判断がなされる。
３度目のステップＳ５１の判断において、ｉ番目すなわち２番目のプレイリストマークＰＬＭ＃２は、プレイアイテム＃１に指定される区間内にあり、２番目のプレイリストマークＰＬＭ＃２が参照するプレイアイテム番号が１とされる。したがって、現在再生中のプレイアイテム番号が、ｉ番目のプレイリストマークが参照するプレイアイテム番号よりも大きいとされ、カウント値ｉが１だけインクリメントされて値が"３"とされ、再びステップＳ５１の判断がなされる。
４度目のステップＳ５１の判断において、ｉ番目すなわち３番目のプレイリストマークＰＬＭ＃３は、プレイアイテム＃２に指定される区間内にあり、３番目のプレイリストマークが参照するプレイアイテム番号が"２"とされる。したがって、現在再生中のプレイアイテム番号がｉ番目のプレイリストマークが参照するプレイアイテム番号と等しいとされ、処理はステップＳ５２に移行される。そして、ステップＳ５２では、３番目のプレイリストマークＰＬＭ＃３が参照するプレイアイテム番号と、現在させ意中のプレイリストマークの番号とが等しいので、処理はステップＳ５３に移行される。
カウント値ｉは"３"なので、ｉ番目のプレイリストマークであるプレイリストマークＰＬＭ＃３の設定された時刻が現在再生中の位置ａの時刻よりも後となる。したがって、ステップＳ５３では、現在の再生時刻を示す値がｉ番目のプレイリストマークの設定された時刻を示す値よりも小さいとされ、処理はステップＳ５４に移行されて位置ａに対応するプレイリストマークが設定される。
すなわち、参照するプレイアイテム番号が"２"で、位置ａの再生時刻を示すプレイリストマークが３番目のプレイリストマークＰＬＭ＃３として追加挿入される。また、プレイリストマーク数が１だけインクリメントされ、このプレイリストマークＰＬＭ＃３が追加挿入される直前の、当該プレイリストマークＰＬＭ＃３が示す再生時刻以降に設けられたプレイリストマークの番号がそれぞれ１だけインクリメントされる。すなわち、図２４の例では、図２４Ａに示されるプレイリストマークＰＬＭ＃３は、プレイリストマークの追加挿入処理により図２４Ｂに例示されるようにプレイリストマークＰＬＭ＃４とされ、追加挿入されたプレイリストマークが、プレイリストマークＰＬＭ＃３とされる。
なお、ステップＳ５２において、現在再生中のプレイアイテム番号とｉ番目のプレイリストマークの参照するプレイアイテム番号とが等しくない場合、換言すれば、現在再生中のプレイアイテム番号がｉ番目のプレイリストマークの参照するプレイアイテム番号よりも小さい場合とは、例えば、それぞれ対応する区間にプレイリストマークが設けられている２つのプレイアイテムの間にある、プレイリストマークが設けられていないプレイアイテムに、新たにプレイリストマークを追加挿入する場合が考えられる。
一例として、図２５に例示されるように、プレイアイテム＃０、プレイアイテム＃１およびプレイアイテム＃２の３つのプレイアイテムを含むプレイリスト＃１２を考える。ここで、プレイアイテム＃０の先頭に対応する位置と、プレイアイテム＃２で示される区間内に、プレイリストマークＰＬＭ＃０およびプレイリストマークＰＬＭ＃１がそれぞれ設定されているものとする。
このような状態において、プレイアイテム＃１で示される区間内の位置ｂにプレイリストマークを追加挿入する場合、ステップＳ５１の判断では、カウント値ｉが"１"のときに、現在再生中のプレイアイテム番号が"１"、ｉ番目のプレイリストマークが参照しているプレイアイテム番号が"２"とされ、現在再生中のプレイアイテム番号よりもｉ番目のプレイリストマークが参照しているプレイアイテム番号の方が大きくなり、処理がステップＳ５２に移行される。そして、ステップＳ５２では、現在再生中のプレイアイテム番号が"１"、ｉ番目のプレイリストマークが参照しているプレイアイテム番号が"２"なので、両者が等しくないとされる。またこの場合、位置ｂに対応するプレイアイテム＃１には、他のプレイリストマークが存在しないので、ステップＳ５３による、プレイアイテム内での前後を判断する必要がない。したがって、処理はステップＳ５２からステップＳ５４に移行され、位置ｂに対応するプレイリストマークの追加挿入処理がなされる。
次に、この発明の主旨に関わる、プレイリストマークを設ける位置の決定方法について説明する。既に説明したように、エントリPTSEPStartで示される位置にプレイリストマークを設ける第１の方法と、ＧＯＰ境界の位置にプレイリストマークを設ける第２の方法との２通りの方法が考えられる。以下に、それぞれの場合における利点および欠点、ならびに、改善方法について説明する。
なお、エントリPTSEPStartで示される位置は、例えばＭＰＥＧ２方式のように、Ｉピクチャ、ＰピクチャおよびＢピクチャによりＧＯＰが構成される場合は、Ｉピクチャの位置に対応させることができる。また、例えばＭＰＥＧ４やＨ．２６４｜ＡＶＣ方式のように、ＩＤＲピクチャをさらに用いる場合には、ＩＤＲピクチャの位置に対応させることができる。
図２６は、第１および第２の方法におけるそれぞれのチャプタ境界の例を示す。プレイリストマークＰＬＭ＃１およびプレイリストマークＰＬＭ＃２によりチャプタの境界が示され、プレイリストマークＰＬＭ＃１およびＰＬＭ＃２の間がチャプタ＃２とされる。図２６Ａは、第１の方法における一例のチャプタ境界を示す。記録が開始される位置は、ＧＯＰの先頭になるので、エントリPTSEPStartで示される位置にプレイリストマークを設けると、ＧＯＰの先頭とプレイリストマークに基づくチャプタの先頭との間に、図２６Ａに例示されるように、不一致区間が発生する。
したがって、チャプタ先頭部の不一致区間の１乃至複数フレームが再生されないことになる。例えば、記録開始位置にプレイリストマークを設けようとした場合、記録開始位置から開始されるＧＯＰの、最初のＩピクチャ（ＭＰＥＧ２方式の場合）より表示順で前の、例えば１乃至複数のＢピクチャが再生されない不具合が生じる。
また、チャプタの後端部においては、不一致区間の１乃至複数フレームは、不一致区間の直前のＧＯＰとは異なるＧＯＰに属する。そのため、当該不一致区間の１乃至複数フレームは、当該不一致区間の直前のフレームと内容的に関連性が無いことがあり得る。例えば、不一致区間の直前のＧＯＰは、記録停止に応じて記録されたＧＯＰであって、不一致区間を含むＧＯＰは、次の若しくは別の記録開始で記録されたＧＯＰである場合などが考えられる。このような場合、チャプタの後端部において、シーン的に繋がりの無いフレームが数フレーム、再生されてしまう不具合が生じる。
図２６Ｂは、第２の方法における一例のチャプタ境界を示す。この第２の方法では、チャプタ境界がＧＯＰ境界と一致しているので、上述した第１の方法の場合のような不具合は、発生しない。
図２７は、第１および第２の方法におけるデコード区間の例を示す。プレイリストマークＰＬＭ＃１およびＰＬＭ＃２の間の区間が表示すべき区間である。図２７Ａは、第１の方法の場合の一例のデコード区間を示す。チャプタ先頭では、エントリPTSEPStartで示される位置にプレイリストマークが設けられているので、デコード開始位置は、このエントリPTSEPStartで示される位置に対応するピクチャが含まれるＧＯＰの先頭からとなる。すなわち、先頭側において、ＧＯＰ先頭からプレイリストマークＰＬＭ＃１までの区間が、表示すべき区間に対して余分にデコードする必要がある区間となる。再生時には、この余分にデコードされた区間は、マスクされる。
一方、第２の方法の場合は、図２７Ｂに一例が示されるように、プレイリストマークが設けられた位置の直前のＧＯＰからデコードを行う必要がある。これは、ＧＯＰがオープンＧＯＰおよびクローズドＧＯＰの何れであるかを判別できない場合、そのＧＯＰは、オープンＧＯＰとして、当該ＧＯＰの前のＧＯＰの情報も用いてデコードする必要があるからである。すなわち、先頭側において、表示すべき区間に対して１ＧＯＰ分、余分にデコードする区間が発生する。
また、時刻情報としては、エントリPTSEPStartで示される位置に対応した情報しか持っていないので、プレイリストマークは、実際には、当該プレイリストマークが設けられた位置の前後のエントリPTSEPStartで示される位置の間に存在するとしか認識できないことになる。この意味でも、プレイリストマークが設けられた位置の前のエントリPTSEPStartで示される位置のピクチャが含まれるＧＯＰからデコードを行う必要がある。
デコード終了位置は、第１の方法においては、チャプタ終端のフレームが含まれるＧＯＰの終端までとなる。また、第２の方法においては、上述した理由と同様にして、チャプタ終端を示すプレイリストマークの位置がその前後の何れのＧＯＰに含まれるかを認識することができないため、当該プレイリストマークの直後に現れるエントリPTSEPStartで示される位置に対応するピクチャを含むＧＯＰの終端までデコードを行う必要がある。このように、結果的には、第１の方法と第２の方法とで同じ位置までデコードを行う必要がある。
図２８は、ＧＯＰがオープンＧＯＰおよびクローズドＧＯＰの何れかを判別可能な場合の、第１および第２の方法によるデコード区間の例を示す。プレイリストマークＰＬＭ＃１およびＰＬＭ＃２の間の区間が表示すべき区間である。図２８Ａは、プレイリストマークをエントリPTSEPStartで示される位置に設けた場合の例であり、上述した図２７Ａと同等の図である。また、図２８Ｂは、プレイリストマークをオープンＧＯＰのＧＯＰ境界に設けた場合の例である。
既に説明したように、クローズドＧＯＰは、そのＧＯＰ内でデコードが完結し、直前のＧＯＰの情報を用いる必要が無い。そのため、図２８Ｃに一例が示されるように、ＧＯＰ境界にプレイリストマークを設けた場合でも、プレイリストマークを設けた位置からデコードを開始することができる。すなわち、プレイリストマークを設けるＧＯＰがクローズドＧＯＰであることが判別可能である場合には、先頭側において、表示すべき区間に対して余分にデコードする区間が発生しない。
また、記録が停止された後に再び記録が開始された場合、記録停止時のオープンＧＯＰの次のＧＯＰは、記録開始に伴いクローズドＧＯＰとなるため、記録開始位置であるＧＯＰ境界にプレイリストマークが設けられる。このため、図２８Ｂに一例が示されるように、記録の停止部分において表示すべき区間の終端とデコード区間の終端とが一致し、このプレイリストマークに基づくチャプタの終端で内容的に関連性のないフレームが表示されることがない。
なお、ＧＯＰがオープンＧＯＰおよびクローズドＧＯＰの何れであるかを判別する手段としては、幾通りかが考えられる。この発明の実施の一形態では、記録開始時は必ずクローズドＧＯＰ構成とされるので、記録開始位置に対応する位置でチャプタ分割を行う場合には、ＧＯＰ境界にプレイリストマークを設けるようにする。
これに限らず、例えばＭＰＥＧ２方式では、ビデオデータのエレメンタリストリームのヘッダに対して、ＧＯＰがクローズドＧＯＰか否かを示すフラグが格納されるので、これを用いることが考えられる。
また、記録を行った装置と同一の装置によりチャプタ分割編集を行い、さらに同一の装置で再生を行う場合には、クローズドＧＯＰで記録を行った位置を示す情報を装置内のメモリなどに記憶しておく方法が考えられる。さらに、装置の仕様としてクローズドＧＯＰを用いて記録を行うようにされている場合、同一機種の装置でチャプタ分割を行う場合には、プレイリストマークを常にＧＯＰ境界に設けるようにできる。
機種名を示す情報は、例えばインデックスファイル、ムービーオブジェクトファイル、プレイリストファイルおよびクリップインフォメーションファイルにそれぞれ設けることができる拡張データ領域（ブロックblkExtensionData()）に格納することができる。オープンＧＯＰおよびクローズドＧＯＰの何れを用いているかを示す情報を、これらの拡張データ領域に対して格納する方法も考えられる。
図２９は、図２６〜図２８を用いて説明した各条件に関する評価を纏めて示す。図２９中、「○」（丸印）が付された項目は、有用なモードであり、「×」（バツ印）が付された項目は、好ましくないモードである。また、「−」（横棒）が付された項目は、実質的に意味をなさないモードである。
この図２９では、チャプタ分割を行うように指定する位置が記録開始または停止位置に対応する位置であるか否かについて、それぞれ、記録と再生とにおけるチャプタ境界のずれの有無と、チャプタ先頭部および後端部のそれぞれで読み出しとデコードとが表示フレームに対してより多く必要な区間とで、プレイリストマークをエントリPTSEPStartの位置と、ＧＯＰ境界位置とに設けた場合について評価している。また、ＧＯＰ境界位置にプレイリストマークを設ける場合において、記録、編集および再生を同一の装置で行い装置独自の情報を利用できる場合（独自情報利用可能機とする）と、記録および編集を行った装置と再生を行う装置とが異なる場合（一般再生機とする）とのそれぞれについて評価している。
なお、図２９中で、Ｍ値は、間にＢピクチャがある場合の、基準ピクチャから次の基準ピクチャまでのピクチャの移動数、Ｎ値は、１ＧＯＰ内のピクチャ数を示す。例えば、ＧＯＰが「Ｉ2Ｂ0Ｂ1Ｐ5Ｂ3Ｂ4Ｐ8Ｂ6Ｂ7Ｐ11Ｂ9Ｂ10Ｐ14Ｂ12Ｂ13」の１５枚のピクチャで構成される場合、Ｍ＝３、Ｎ＝１５である。
記録開始または停止の境界位置に対応する位置でチャプタ分割を行うように指示した場合について説明する。このとき、記録と再生におけるチャプタ位置のずれに関しては、図２６を用いて説明したように、プレイリストマークをエントリPTSEPStartの位置に設ける場合にずれが生じ、ＧＯＰ境界位置に設ける場合には、ずれが生じない。
デコード区間は、デコード開始位置に関しては、図２８を用いて説明したように、プレイリストマークをエントリPTSEPStartの位置に設ける場合には、（Ｍ−１）フレーム分が表示フレームに対して多く必要となり、ＧＯＰ境界位置に設ける場合には、記録開始位置は必ずクローズドＧＯＰとなるため、一般再生機および独自情報利用可能機の何れにおいても、表示フレーム区間とデコード区間とが一致する。また、デコード終了位置に関しては、プレイリストマークをエントリPTSEPStartの位置に設ける場合には、（Ｎ−Ｍ＋１）フレーム分が表示フレームに対して必要となり、ＧＯＰ境界位置に設ける場合には、一般再生機および独自情報利用可能機の何れにおいても、表示フレーム区間とデコード区間とが一致する。
記録開始または停止の境界位置ではない位置でチャプタ分割を行うように指示した場合について説明する。この場合、記録と再生におけるチャプタ位置のずれに関する評価は意味をなさないので、図２９においては「−」（横棒）で示してある。
デコード区間は、図２８を用いて説明したように、デコード開始位置に関しては、プレイリストマークをエントリPTSEPStartの位置に設ける場合には、（Ｍ−１）フレーム分が表示フレームに対して多く必要となる。一方、ＧＯＰ境界位置にプレイリストマークを設ける場合には、一般再生機においては直前の１ＧＯＰ分すなわちＮフレーム分が表示フレームに対して必要となり、独自情報利用可能機においては、プレイリストマークが設けられるＧＯＰがオープンＧＯＰであると判別されれば１ＧＯＰ分すなわちＮフレーム分が表示フレームに対して必要になる。また、独自情報利用可能機では、当該ＧＯＰがクローズドＧＯＰであると判別できれば、表示開始フレームとデコード開始フレームとが一致する。
さらに、デコード終了位置に関しては、プレイリストマークをエントリPTSEPStartの位置に設ける場合には、（Ｎ−Ｍ＋１）フレーム分が表示フレームに対して多く必要となる。一方、ＧＯＰ境界位置にプレイリストマークを設ける場合には、一般再生機においては直後の１ＧＯＰ分すなわちＮフレーム分が表示フレームに対して必要となり、独自情報利用可能機においては、表示終了フレームとデコード終了位置とが一致する。
このように、記録開始または停止の境界位置でチャプタ分割を行う場合には、ＧＯＰ境界にプレイリストマークを設け、記録開始または停止の境界位置以外でチャプタ分割を行う場合には、エントリPTSEPStartに示される位置にプレイリストマークを設けるようにすることで、ユーザの利便性を最大にできることが分かる。
図３０は、チャプタ分割編集を行う際の、プレイリストマークの一例の挿入方法を示すフローチャートである。例えばプレイリストに従いクリップを再生中にチャプタ分割が指示されると、先ず、最初のステップＳ６０で、現在再生中の位置に対応するＧＯＰがクローズドＧＯＰであると判定可能か否かが判断される。現在再生中の位置は、例えばビデオストリームをデコードするデコーダから取得することができる。
若し、判定できないと判断されたら、処理はステップＳ６１に移行し、プレイリストマークを設ける現在時刻としてエントリPTSEPStartの値を用いるものとされる。一方、ステップＳ６０で判定可能であると判断されれば、処理はステップＳ６３に移行され、プレイリストマークを設ける現在時刻として、ＧＯＰ境界の値を用いるものとされる。
ステップＳ６１またはステップＳ６３の処理の後、処理はステップＳ６２に移行され、ステップＳ６１またはステップＳ６３で決定された現在時刻に基づきプレイリストマークを設ける処理がなされる。すなわち、このステップＳ６２において、上述の図２３においてステップＳ５４で説明した、ブロックblkPlayListMark()内のフィールドMarkTimeStampの値が、ステップＳ６１またはステップＳ６３の結果に応じて決定される。
なお、ＧＯＰ境界の位置は、例えばビデオストリームをデコードするデコーダから取得することができる。これに限らず、例えば上述したエントリPTSEPStartの値に基づき求めるようにもできる。この場合には、エントリPTSEPStartの位置からＧＯＰの構造に応じて所定フレーム分遡った位置を、ＧＯＰの先頭位置とする。
記録機が記録開始操作に応じて、記録開始位置に自動的にプレイリストマークを設ける構成も考えられる。このような構成とすることで、再生時に、クリップ分割編集処理を行わなくても記録開始および停止の単位でチャプタジャンプを行うことが可能とされる。
図３１は、このような、記録開始に応じて記録開始位置に自動的にプレイリストマークを設ける場合の一例の処理を示すフローチャートである。例えばユーザにより記録機に対して記録開始操作がなされると、クリップの記録が開始されると共に、プレイリストマークを設ける現在時刻として、ＧＯＰ境界の値を用いるように決定される。そして、次のステップＳ７１で、ステップＳ７０の結果に基づき、プレイリストマークを設ける処理が行われる。すなわち、このステップＳ７１において、記録が開始され最初に生成されたＧＯＰの先頭に対応する再生時刻がブロックblkPlayListMark()内のフィールドMarkTimeStampの値とされ、プレイリストマークが設けられる。
なお、記録開始位置すなわち記録が開始され最初に生成されたＧＯＰの先頭に対応する時刻は、例えばプレイリストに対して最初に記録されるクリップに関しては、値"０"に所定のオフセットを加えた値とされる。更なる記録開始および停止により生成されたクリップをプレイリストに追記するような仕様の場合には、例えば既に記録されたクリップの累積的な再生時刻に所定のオフセットを加えた値とされる。オフセットは、例えば、デコーダにストリームの供給が開始されてから当該ＧＯＰの先頭のフレームが表示される時間に対応する値であって、装置の仕様などに応じて固有の値とされる。
これは、例えば１のクリップが複数回の記録開始および停止操作を含めることができるような場合に、クリップＡＶストリームファイル、クリップインフォメーションファイルおよび当該クリップインフォメーションファイルに対応するプレイアイテムが１つのまま、プレイリストマークのみで、記録開始および停止操作に対応するチャプタ境界を設ける場合に用いて好適な方法である。
なお、１のプレイリストファイルに設けることができるプレイリストマークの数に対して、上限を設定することができる。プレイリストマーク数の上限を設定することで、無制限にプレイリストファイルの容量が増大するのが防がれる。また、例えば編集機や再生機におけるチャプタ表示数に、例えば３桁などの制限が設けられているような場合に、プレイリストマークの上限を設定することも考えられる。上述した図３０および図３１を用いて説明した処理は、それぞれ、現在設定しようとするプレイリストマークを設定することでこのプレイリスト内に設定可能なプレイリストマーク数の上限を超えないか否かの判断を行った上で、上限を超えないとの判断がなされた後に、行われる。
次に、この発明の実施の一形態に適用可能な一例の記録再生装置について説明する。先ず、記録再生装置の説明に先んじて、仮想プレーヤについて、概略的に説明する。上述したようなデータ構造を有するディスクがプレーヤに装填されると、プレーヤは、ディスクから読み出されたムービーオブジェクトなどに記述されたコマンドを、プレーヤ内部のハードウェアを制御するための固有のコマンドに変換する必要がある。プレーヤは、このような変換を行うためのソフトウェアを、プレーヤに内蔵されるＲＯＭ(Read Only Memory)にあらかじめ記憶している。このソフトウェアは、ディスクとプレーヤを仲介してプレーヤにこのフォーマットの規定に従った動作をさせることから、仮想プレーヤと称される。
図３２は、この仮想プレーヤの動作を概略的に示す。図３２Ａは、ディスクのローディング時の動作の例を示す。ディスクがプレーヤに装填されディスクに対するイニシャルアクセスがなされると（ステップＳ３０）、１のディスクにおいて共有的に用いられる共有パラメータが記憶されるレジスタが初期化される（ステップＳ３１）。そして、次のステップＳ３２で、ムービーオブジェクトなどに記述されたプログラムがディスクから読み込まれて実行される。なお、イニシャルアクセスは、ディスク装填時のように、ディスクの再生が初めて行われることをいう。
図３２Ｂは、プレーヤが停止状態からユーザにより例えばプレイキーが押下され再生が指示された場合の動作の例を示す。最初の停止状態（ステップＳ４０）に対して、ユーザにより、例えばリモートコントロールコマンダなどを用いて再生が指示される（ＵＯ：User Operation）。再生が指示されると、先ず、レジスタすなわち共通パラメータが初期化され（ステップＳ４１）、次のステップＳ４２で、ムービーオブジェクト実行フェイズに移行する。
ムービーオブジェクトの実行フェイズにおけるプレイリストの再生について、図３３を用いて説明する。ＵＯなどにより、タイトル番号＃１のコンテンツを再生開始する指示があった場合について考える。プレーヤは、コンテンツの再生開始指示に応じて、上述した図２に示されるインデックステーブル(Index Table)を参照し、タイトル＃１のコンテンツ再生に対応するオブジェクトの番号を取得する。例えばタイトル＃１のコンテンツ再生を実現するオブジェクトの番号が＃１であったとすると、プレーヤは、ムービーオブジェクト＃１の実行を開始する。
この図３３の例では、ムービーオブジェクト＃１に記述されたプログラムは２行からなり、１行目のコマンドが"Play PlayList(1)"であるとすると、プレーヤは、プレイリスト＃１の再生を開始する。プレイリスト＃１は、１以上のプレイアイテムから構成され、プレイアイテムが順次再生される。プレイリスト＃１中のプレイアイテムの再生が終了すると、ムービーオブジェクト＃１の実行に戻り、２行目のコマンドが実行される。図３３の例では、２行目のコマンドが"jump MenuTitle"であって、このコマンドが実行されインデックステーブルに記述されたメニュータイトル(MenuTitle)を実現するムービーオブジェクトの実行が開始される。
図３４は、この発明の実施の一形態に適用可能な記録再生装置の一例の構成を概略的に示す。この図３４に例示される記録装置は、外部から入力されるビデオデータおよびオーディオデータを記録媒体に記録し、記録媒体に記録されたビデオデータおよびオーディオデータを再生する、単独の記録再生装置として用いることもできるし、光学系や撮像素子などを備えたカメラブロックと組み合わせ、撮像した撮像信号に基づくビデオデータを記録媒体に記録する、ビデオカメラ装置の記録ブロックとして用いることもできる。
適用可能な圧縮符号化や多重化の方式としては、様々に考えられる。例えば、Ｈ．２６４｜ＡＶＣに規定される方式を、この発明の実施の一形態の圧縮符号化として適用することができる。これに限らず、ＭＰＥＧ２方式に基づき圧縮符号化を行うようにしてもよい。また、多重化方式は、例えばＭＰＥＧ２システムズを適用することができる。以下では、ビデオデータの圧縮符号化をＨ．２６４｜ＡＶＣに規定される方式に準じて行い、ビデオデータおよびオーディオデータの多重化を、ＭＰＥＧ２システムズに規定される方式に準じて行うものとして説明する。
制御部３０は、例えばＣＰＵ(Central Processing Unit)、ＲＡＭ(Random Access Memory)およびＲＯＭ(Read Only Memory)などからなり（図示しない）、ＲＯＭに予め記憶されたプログラムやデータに基づき、ＲＡＭをワークメモリとして用いてこの記録装置の記録部１０の各部を制御する。なお、制御部１０と記録部１０の各部とを接続する経路は、繁雑さを避けるために、図３４では省略している。
ＵＩ(User Interface)部３１は、この記録装置の動作をユーザが操作するための操作子が所定に設けられ、操作子に対する操作に応じた制御信号を出力する。この制御信号は、制御部３０に供給される。制御部３０は、ユーザ操作に応じてＵＩ部３１から供給された制御信号に基づきなされるプログラムの処理により、記録再生部１０の各部の動作を制御する。また、ＵＩ部３１は、簡易的な表示部を有し、後述する管理情報処理部１６から供給される情報に基づき、所定の表示、例えば記録再生装置における記録や再生の状態を示す表示を行うことができるようにされている。
例えば、ＵＩ部３１に対してなされた操作に応じて、記録再生装置による記録媒体３２に対してデータを記録する動作の開始および停止の動作や、記録媒体３２からデータを再生する再生動作が制御部３０により制御される。また例えば、編集動作時には、ＵＩ部３１に対してなされた操作に応じて記録媒体３２からデータが再生されると共に、操作に応じた位置でのチャプタ分割処理がなされる。
ビデオエンコーダ１１は、複数フレームのビデオデータを格納可能なバッファメモリを有し、供給されたベースバンドのディジタルビデオデータをバッファメモリに溜め込んで、所定の方式で以て圧縮符号化する。Ｈ．２６４｜ＡＶＣに規定される方式に準じて圧縮符号化がなされるこの例では、例えば、ＤＣＴ(Discrete Cosine Transform)と画面内予測とによりフレーム内圧縮を行うと共に、動きベクトルを用いたフレーム間圧縮を行い、さらにエントリピー符号化を行い圧縮効率を高める。ビデオエンコーダ１１で圧縮符号化されたディジタルビデオデータは、Ｈ．２６４｜ＡＶＣエレメンタリストリーム（ＥＳ）として出力される。
ビデオデコーダ２０は、複数フレームのビデオデータを格納可能なバッファメモリを有し、供給された圧縮ビデオデータをバッファメモリに溜め込んで、圧縮符号化方式に対応した復号化方式でデコードし、ベースバンドのディジタルビデオデータとして出力する。例えば、ビデオエンコーダ１１がＨ．２６４｜ＡＶＣに規定される方式に準じて圧縮符号化を行うこの例では、ビデオデコーダ２０もビデオエンコーダ１１に対応して、Ｈ．２６４｜ＡＶＣに規定される方式に準じてデコード処理を行う。ビデオデコーダ２０は、後述するマルチプレクサ／デマルチプレクサ１３（以下、ＭＵＸ／ＤＥＭＵＸ１３）で抽出される、ＤＴＳ(Decoding Time Stamp)およびＰＴＳ(Presentation Time Stamp)で示される時刻に基づき、デコードおよび出力を行うことができる。ビデオデコーダ２０でデコードされて得られたベースバンドのディジタルビデオデータは、端子４２から出力される。
オーディオエンコーダ１２は、端子４１から供給されたベースバンドのディジタルオーディオデータを所定の圧縮符号化方式、例えばドルビーディジタル(Dolby Digital：登録商標)方式により圧縮符号化する。オーディオデータの圧縮符号化方式は、これに限られるものではなく、さらに、オーディオデータを圧縮符号化せず、ベースバンドのデータのまま用いることも考えられる。
オーディオデコーダ２１は、供給された圧縮オーディオデータを圧縮符号化方式に対応した復号化方式でデコードし、ベースバンドのディジタルオーディオデータとして出力する。オーディオエンコーダ１２がドルビーディジタル方式により圧縮符号化されるこの例では、オーディオデコーダ２１もオーディオエンコーダ１２に対応して、ドルビーディジタル方式に準じた復号化方式でデコードがなされる。デコードされたオーディオデータは、ビデオデコーダ２０から出力されるビデオデータと同期的に、端子４３から出力される。
ＭＵＸ／ＤＥＭＵＸ１３は、それぞれ圧縮符号化されて供給されたディジタルビデオデータおよびディジタルオーディオデータを所定の方式で多重化し、１本のデータストリームとして出力するマルチプレクサ機能と、ディジタルビデオデータとディジタルオーディオデータとが所定に多重化されたデータストリームから、ディジタルビデオデータとディジタルオーディオデータとを分離してそれぞれ取り出す、デマルチプレクサ機能とを有する。
マルチプレクサ機能は、例えば、ＭＰＥＧ２システムズに準じて多重化が行われるこの例では、ＭＰＥＧ２のトランスポートストリームを用いて、供給された圧縮ビデオデータおよび圧縮オーディオデータを時分割で多重化する。例えば、ＭＵＸ／ＤＥＭＵＸ１３は、バッファメモリを有し、供給された圧縮ビデオデータおよび圧縮オーディオデータを一旦バッファメモリに格納する。バッファメモリに格納された圧縮ビデオデータは、所定サイズ毎に分割されヘッダが付加されて、ＰＥＳ(Packetized Elementary Stream)パケット化される。圧縮オーディオデータも同様に、所定サイズ毎に分割されヘッダが付加されてＰＥＳパケット化される。ヘッダには、パケットに格納されるデータの再生時刻を示すＰＴＳや復号時刻を示すＤＴＳ(Decoding Time Stanp)といった、ＭＰＥＧ２システムズに規定される所定の情報が格納される。ＰＥＳパケットは、さらに分割されてトランスポートパケット（ＴＳパケット）のペイロードに詰め込まれる。ＴＳパケットのヘッダには、ペイロードに詰め込まれたデータ種別などを識別するためのＰＩＤ(Packet Identification)が格納される。
デマルチプレクサ機能は、マルチプレクサ機能と逆の処理を行い、パケットから圧縮ビデオデータおよび圧縮オーディオデータを抽出する。例えば、供給されたＴＳパケットのヘッダからＰＩＤを検出し、ＴＳパケットをペイロードに格納されるデータ種別毎に振り分ける。そして、振り分けられたＴＳパケットのそれぞれについて、ペイロードに格納されたデータを取り出し、ＰＥＳパケットを再構築する。さらに、ＰＥＳパケットのペイロードに格納された圧縮ビデオデータや圧縮オーディオデータを取り出し、ＰＥＳヘッダに格納された情報などに基づきヘッダ情報などを付加し、それぞれ１本のエレメンタリストリームとして出力する。
ストリームバッファ１４は、ＭＵＸ／ＤＥＭＵＸ１３（記録時）または記録再生制御部１５（再生時）から供給されたＴＳパケットを一時的に格納する。ストリームバッファ１４に対するＴＳパケットの読み書きのタイミングを所定に制御することで、記録媒体３２に対するアクセス速度と、オーディオおよびビデオデータエンコードやデコードなどの信号処理速度との間の整合性をとる。
記録再生制御部１５は、記録媒体３２に対するデータの記録と、記録媒体３２からのデータの再生を制御する。すなわち、記録再生制御部１５は、例えば制御部３０といった上位からの命令に基づき、指定されたアドレスに対するデータの書き込みや、指定されたアドレスからのデータの読み出しを行う。
記録媒体３２としては、例えば記録可能なタイプのＤＶＤ(Digital Versatile Disc)を用いることができる。これに限らず、記録媒体３２としてハードディスクドライブを用いてもよいし、半導体メモリを記録媒体３２に適用することも可能である。また、記録媒体３２として、より大容量を実現したＢｌｕ−ｒａｙ Ｄｉｓｃ（ブルーレイディスク：登録商標）を適用することも考えられる。
管理情報処理部１６は、例えばＣＰＵ、ワークメモリとしてのＲＡＭおよびプログラム所定のデータが予め記憶されるＲＯＭからなる（図示しない）。これに限らず、管理情報処理部１６は、例えば制御部３０におけるプログラム処理で管理情報処理部１６の機能を実現することも可能である。この場合、例えば制御部３０の有するＲＡＭが揮発性メモリ１７として用いられると共に、不揮発性メモリ１８が制御部３０に接続される。
管理情報処理部１６は、例えば揮発性メモリ１７をワークメモリとして用いて、上述したインデックスファイル"index.bdmv"、ムービーオブジェクトファイル"MovieObject.bdmv"、プレイリストファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"に関する処理を行う。例えばこの発明の実施の一形態によるプレイリストマークの追加挿入処理は、制御部３０の制御に基づきこの管理情報処理部１６により行われる。
このような構成を有する記録再生装置における、記録時の動作について説明する。なお、以下では、ビデオデータは、Ｈ．２６４｜ＡＶＣに準じた方式で圧縮符号化され、オーディオデータは、ＡＡＣ方式で圧縮符号化されるものとする。
ベースバンドのディジタルビデオデータが端子４０から記録再生部１０に入力され、ビデオエンコーダ１１に供給される。例えば、ＵＩ部３１に対して記録開始の操作がなされると、ビデオエンコーダ１１は、供給されたディジタルビデオデータの圧縮符号化を開始する。ビデオエンコーダ１１は、ベースバンドのディジタルビデオデータを圧縮符号化してＨ．２６４｜ＡＶＣのエレメンタリストリーム（ＥＳ）として出力する。このエレメンタリストリームは、ＭＵＸ／ＤＥＭＵＸ１３に供給される。
ベースバンドのディジタルオーディオデータが端子４１から記録再生部１０に入力され、オーディオエンコーダ１２に供給される。オーディオエンコーダ１２は、上述のＵＩ部３１に対する記録開始の操作に応じたタイミングで供給されたオーディオデータの圧縮符号化を開始する。オーディオエンコーダ１２で圧縮符号化されたディジタルオーディオデータは、ＭＵＸ／ＤＥＭＵＸ１３に供給される。
ＭＵＸ／ＤＥＭＵＸ１３は、それぞれ圧縮符号化されて供給されたディジタルビデオデータおよびディジタルオーディオデータを所定の方式で多重化し、１本のデータストリームとして出力する。例えば、ＭＵＸ／ＤＥＭＵＸ１３は、バッファメモリを有し、供給された圧縮ビデオデータおよび圧縮オーディオデータを一旦バッファメモリに格納する。
バッファメモリに格納された圧縮ビデオデータは、所定構造毎に分割されヘッダが付加されて、ＰＥＳ(Packetized Elementary Stream)パケット化される。圧縮オーディオデータも同様に、所定サイズ毎に分割されヘッダが付加されてＰＥＳパケット化される。ヘッダには、パケットに格納されるデータの再生時刻を示すＰＴＳや復号時刻を示すＤＴＳ(Decoding Time Stanp)といった、ＭＰＥＧ２システムズに規定される所定の情報が格納される。ＰＥＳパケットは、さらに分割されてトランスポートパケット（ＴＳパケット）のペイロードに詰め込まれる。ＴＳパケットのヘッダには、ペイロードに詰め込まれたデータを識別するためのＰＩＤ(Packet Identification)が格納される。マルチプレクサ１３から出力されたＴＳパケットは、ストリームバッファ１４に一旦溜め込まれる。
なお、ＴＳパケットは、実際には、ＭＵＸ／ＤＥＭＵＸ１３においてさらに所定サイズのヘッダが付加されて出力される。この、ＴＳパケットに対して所定のヘッダを付加したパケットを、ソースパケットと呼ぶ。
記録制御部１５は、ストリームバッファ１４に溜め込まれたデータ量を監視し、ストリームバッファ１４に所定量以上のデータが溜め込まれると、ストリームバッファ１４から記録媒体３２の記録単位毎にデータを読み出して記録媒体３２に書き込む。
管理情報処理部１６は、記録データに基づき、揮発性メモリ１７をワークメモリとして用いて、上述したインデックスファイル"index.bdmv"、ムービーオブジェクトファイル"MovieObject.bdmv"、プレイリストファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"に格納するための情報を生成する。生成された情報は、所定のタイミングで記録媒体３２に書き込まれる。
一例として、管理情報処理部１６は、ＭＵＸ／ＤＥＭＵＸ１３から記録データの時刻情報を取得すると共に、記録制御部１５から記録データの記録媒体３２におけるアドレス情報を取得し、取得されたこれら時刻情報およびアドレス情報に基づきエントリPTSEPStartが生成される。また、ＵＩ部３１に対する記録開始、記録終了の操作に応じて制御部３０から出力される制御信号と、ＭＵＸ／ＤＥＭＵＸ１３および記録制御部１５からの記録データに関する情報とに基づき、プレイリストファイル"xxxxx.mpls"の生成または更新、クリップインフォメーションファイル"zzzzz.clpi"の生成などが行われる。
この記録再生装置が記録開始に伴い記録開始位置にプレイリストマークを設けるようにされている場合、ＵＩ部３１に対する記録開始操作に応じて生成される先頭のフレームに対応する再生時刻をフィールドMarkTimeStampの値として持つプレイリストマークが、管理情報処理部１６において作成され、プレイリストに対して追加される。
再生時の動作について説明する。記録媒体３２が例えば記録再生装置に対して装填されると、記録媒体３２から、インデックスファイル"index.bdmv"、ムービーオブジェクトファイル"MovieObject.bdmv"が読み込まれ、管理情報処理部１６に渡される。管理情報処理部１６は、これらの情報を、揮発性メモリ１７に記憶する。制御部３０は、管理情報処理部１６から揮発性メモリ１７に記憶された情報を取得し、取得された情報に基づき、例えば、ＵＩ部３１が有する表示部に対して記録媒体３２に記録されているクリップに関する情報を表示させる。ユーザは、この情報に基づきＵＩ部３１に対して所定の操作を行うことで、記録媒体３２に記録されているクリップの再生を指示することができる。なお、ここでは、簡単のために、クリップの先頭から再生を開始させるものとする。
制御部３０は、ＵＩ部３１に対する操作に応じて、管理情報処理部１６からプレイリストファイルの情報を取得し、このプレイリストファイルに基づき、記録再生制御部１５に対して、当該プレイリストファイルに格納されるプレイアイテムに参照されるクリップインフォメーションファイルと、対応するクリップＡＶストリームファイルを記録媒体３２から読み出すように命令を出す。記録再生制御部１５は、この命令に従い、記録媒体３２からクリップインフォメーションファイルとクリップＡＶストリームファイルとを読み出す。クリップＡＶストリームファイルは、記録媒体３２からＴＳパケット毎に読み出され、記録再生制御部１５を介してストリームバッファ１４に溜め込まれる。
なお、実際には、記録媒体３２から読み出されるＴＳパケットは、本来のＴＳパケットに対して所定サイズのヘッダが付加されたソースパケットである。
ＭＵＸ／ＤＥＭＵＸ１３は、ストリームバッファ１４に溜め込まれたデータ量を監視し、ストリームバッファ１４に所定量以上のＴＳパケットが溜め込まれると、ストリームバッファ１４からビデオデコーダ２０がデコードに必要とする分のデータを、ＴＳパケット単位で読み出す。読み出されたＴＳパケットは、ＭＵＸ／ＤＥＭＵＸ１３に供給されバッファメモリに一旦格納され、ＰＩＤに基づきデータ種類毎に振り分けられペイロードに格納されたデータからＰＥＳパケットが再構築される。さらに、ＰＥＳパケットのぺーロードからデータが取り出されると共に、ＰＥＳヘッダの情報に基づき、ＤＴＳやＰＴＳといったデコードや再生の時刻を指定する情報など、所定にヘッダ情報などが付加され、圧縮符号化されたビデオデータおよびオーディオデータのエレメンタリストリームがそれぞれ生成される。
圧縮ビデオデータは、ビデオデコーダ２０に供給される。ビデオデコーダ２０は、供給された圧縮ビデオデータをバッファメモリに溜め込み、所定ピクチャ分のデータが溜め込まれたら、バッファメモリに溜め込まれたデータに対してデコード処理を開始する。デコードされたビデオデータは、例えば図示されないシステムクロックから供給されるＳＴＣ(System Time Clock)に基づき、ＰＴＳに従いフレームタイミングで順次出力される。
一方、圧縮オーディオデータは、オーディオデコーダ２１に供給され、所定にデコード処理がなされる。デコードされたオーディオデータは、ビデオデコーダ２０から出力されるビデオデータと同期的に、オーディオデコーダ２１から出力される。
この記録再生装置は、記録媒体３２に記録されたクリップに対するチャプタ分割編集を行うことができる。上述のようにして記録媒体３２からクリップを再生中に、ＵＩ部３１に対して所定の操作を行い、チャプタ分割を行う位置を指定する。チャプタ分割の位置を指定する方法としては、クリップを通常通り、例えば順方向の１倍速再生で再生しながら所望の位置でクリップ分割の操作を行う方法や、高速再生、スロー再生、コマ送り再生といった可変速再生を用いて分割位置をフレーム単位で検索してチャプタ分割の操作を行う方法などが考えられる。
分割位置が指定されると、図２３を用いて説明した処理に従い、指定された分割位置に対応する現在の再生時刻と、プレイリスト中の他のプレイリストマークとの位置関係が判断される。それと共に、図３０を用いて説明した処理に従い、プレイリストマークを設ける値として、エントリPTSEPStartおよびＧＯＰ境界の何れの値を用いるかを判断する。
なお、プレイリストマークを設ける現在時刻としてエントリPTSEPStartの値を用いる場合で、分割位置をフレーム単位で任意に指定するとき、指定された分割位置が必ずしもエントリPTSEPStartで示されるフレームであるとは限らない。この場合、例えば指定された位置に最も近いエントリPTSEPStartの値を、指定された分割位置に対応するPTSEPStartの値として用いることが考えられる。これに限らず、指定された位置の直前または直後のエントリPTSEPStartの値を用いるようにしてもよい。
また、現在再生中の位置に対応するＧＯＰがクローズドＧＯＰであると判断できた場合は、クローズドＧＯＰの先頭のフレームの再生時刻は、例えばＭＵＸ／ＤＥＭＵＸ１３から取得することができる。これに限らず、エントリPTSEPStartの値を基点とし、ビデオデコーダ２０のバッファメモリに溜め込まれているデータとＳＴＣとに基づき、クローズドＧＯＰの先頭のフレームの再生時刻を求めることも考えられる。
図３５は、上述のようにして設けられたプレイリストマークに基づくチャプタジャンプ処理の一例の方法を示すフローチャートである。一例として、上述のようにしてプレイリストマークが設けられチャプタ分割編集されたプレイリストを再生中に、例えばＵＩ部３１に対してチャプタジャンプを行うような操作がなされる。制御部３０は、この操作に応じて、先ず、現在再生中の位置に対応する時刻情報を求める（ステップＳ８０）。例えば、制御部３０は、ＭＵＸ／ＤＥＭＵＸ１３との間でやりとりを行い、ＭＵＸ／ＤＥＭＵＸ１３で分離されるビデオデータのエレメンタリストリームに含まれるＰＴＳと、ＭＵＸ／ＤＥＭＵＸ１３におけるＳＴＣとに基づき、ビデオデコーダ２０でデコード中の任意のフレームの再生時刻を知ることができる。
なお、現在再生中の位置に対応する時刻情報を求める方法は、これに限られない。例えば、再生中、常にクリップインフォメーションファイル中のブロックblkEPMap()（図１７参照）の情報を用い、エントリPTSEPStartに基づきアドレス変換を行う方法が考えられる。再生中には、次のＧＯＰのデータを読み出す必要があり、この方法によれば、次のＧＯＰのデータを容易に取得することが可能となる。また、現在の再生位置と、プレイリストマークの位置との関係を常に更新しながら再生を行うことで、ＵＩ部３１の表示画面に対して現在再生中のチャプタの情報を表示することが可能となり、好ましい。
現在再生中の位置に対応する時刻情報が求められたら、次のステップＳ８１で、制御部３０により、当該時刻情報で示される時刻に対して再生方向に向けて最も近くにあるプレイリストマークが、再生中のプレイリストのブロックblkPlayListMark()から検索される。
該当するプレイリストマークが存在するとされれば（ステップＳ８２）、処理はステップＳ８３に移行され、制御部３０により、ステップＳ８１で検索されたプレイリストマークに基づき、当該プレイリストマークに対応するエントリPTSEPStartが検索される。
この実施の一形態では、プレイリストマークは、エントリPTSEPStartの位置またはＧＯＰ境界位置の何れかに設けられる。したがって、プレイリストマークに対応するエントリPTSEPStartは、プレイリストマークの再生時刻を示す値MarkTimeStampと値が一致するエントリPTSEPStartが存在すれば、そのエントリPTSEPStartとされる。一方、プレイリストマークの再生時刻を示す値MarkTimeStampと値が一致するエントリPTSEPStartが存在しない場合に、プレイリストマークがＧＯＰ境界に設けられ且つＧＯＰがクローズドＧＯＰであることが分かる場合には、値MarkTimeStampから再生時刻を再生方向に進めていったときに最初に現れるエントリPTSEPStartとされる。さらに、プレイリストマークの再生時刻を示す値MarkTimeStampと値が一致するエントリPTSEPStartが存在しない場合に、プレイリストマークがＧＯＰ境界に設けられていないか、または、ＧＯＰがクローズドＧＯＰであることが分からない場合は、再生方向とは逆方向に進めて次に現れるエントリPTSEPStartとされる。
次のステップＳ８４で、制御部３０により、再生中のプレイアイテムに対応するクリップインフォメーションファイル内のブロックblkEPMap()（図１７〜図２０参照）に基づき、ステップＳ８３で検索されたエントリPTSEPStartに対応するアドレス情報が求められる。そして、制御部３０から記録再生制御部１５に対して、記録媒体３２から当該アドレス情報で示されるアドレスからの読み出しを行うように命令される。
記録媒体３２から読み出されたデータは、記録再生制御部１５からストリームバッファ１４を介してＭＵＸ／ＤＥＭＵＸ１３に供給され、パケットを用いて時分割多重されたストリームからデータ種類毎の分離がなされる。分離されたデータうち圧縮ビデオデータのエレメンタリストリームは、ビデオデコーダ２０に供給される。ビデオデコーダ２０は、供給された圧縮ビデオデータのエレメンタリストリームのデコードを開始する（ステップＳ８５）。そして、プレイリストマークで示されるフレームがデコードされ出力可能となったら、そのフレームからの出力がなされ、表示が開始される（ステップＳ８６）。
このとき、プレイリストマークがエントリPTSEPStart位置に設けられている場合には、ＧＯＰにおいて、当該エントリPTSEPStartに対応するピクチャより前のピクチャは、デコードされるが表示は行わないようにされる。一方、プレイリストマークがＧＯＰ境界位置に設けられている場合には、ＧＯＰの先頭位置から表示が開始される。
なお、再生時刻で最後に設けられたプレイリストマークよりも後ろを再生中にチャプタジャンプを指示されることも考えられる。この場合、現在再生中の位置に対して再生方向に向けて最も近いプレイリストマークが、再生中のプレイリスト中に存在しないことになる。この場合、チャプタジャンプの指示が無視される。これに限らず、例えば図３５のステップＳ８７に一例が示されるように、当該プレイリストの終端までジャンプするようにしてもよい。
次に、この発明の実施の一形態の他の例について説明する。上述では、この発明が単体の記録装置に適用された例について説明した（図３４参照）。これに対し、この実施の一形態の他の例では、この発明を、撮像素子と、被写体からの光を撮像素子に入射させる光学系とを有し、撮像素子で撮像された撮像信号に基づきビデオデータを記録媒体に記録するようにした、ビデオカメラ装置に適用した。
図３６は、この発明の実施の一形態の他の例によるビデオカメラ装置１００の一例の構成を示す。ビデオカメラ装置１００において、記録系の構成は、図３４を用いて説明した記録装置の構成を略そのまま適用できるので、図３４と共通する部分には同一の符号を付し、詳細な説明を省略する。
図３６の構成において、カメラ部５０は、映像信号に関する構成として、光学系５１、撮像素子５２、撮像信号処理部５３、カメラ制御部５４、ビデオ信号処理部５８および表示部５５を有し、音声信号に関する構成として、マイクロフォン（ＭＩＣ）５６、音声信号処理部５７およびスピーカ部ＳＰ６０を有する。制御部３０は、カメラ部５０の各部との間で各種制御信号や情報のやりとりを行い、カメラ部５０の動作を制御する。また、制御部５０は、ユーザ操作に応じてＵＩ部３１から供給される制御信号に基づき、カメラ部５０の動作を制御する。
なお、ビデオカメラ装置１００として構成される場合、記録開始操作および記録停止操作は、例えば、ＵＩ部３１に設けられた単一の記録スイッチを用い、当該記録スイッチが押下される毎に記録開始および記録停止が交互に指示されるようになされるのが一般的である。また、このビデオカメラ装置１００では、記録媒体２０として、Ｂｌｕ−ｒａｙ Ｄｉｓｃや記録可能なタイプのＤＶＤといった、ディスク記録媒体を適用するものとする。
カメラ部５０において、光学系５１は、被写体からの光を撮像素子５２に導くためのレンズ系、絞り調整機構、フォーカス調整機構、ズーム機構、シャッタ機構などを備える。絞り調整機構、フォーカス調整機構、ズーム機構およびシャッタ機構の動作は、制御部３０から供給される制御信号に基づき、カメラ制御部５４により制御される。
撮像素子５２は、例えばＣＣＤ(Charge Coupled Device)からなり、光学系５１を介して照射された光を光電変換により電気信号に変換し、所定の信号処理を施し撮像信号として出力する。撮像信号処理部５３は、撮像素子から出力された撮像信号に対して所定の信号処理を施し、ベースバンドのディジタルビデオデータとして出力する。例えば撮像信号処理部５３は、撮像素子５２から出力された撮像信号に対して、ＣＤＳ(Correlated Double Sampling)回路により画像情報を有する信号だけをサンプリングすると共に、ノイズを除去し、ＡＧＣ(Auto Gain Control)回路によりゲインを調整する。そして、Ａ／Ｄ変換によりディジタル信号に変換する。
また、撮像信号処理部５３は、撮像素子５２から出力された撮像信号の情報を制御部３０に送る。制御部３０は、この情報に基づき光学系５１を制御するための制御信号を生成し、カメラ制御部５４に供給する。カメラ制御部５４は、この制御信号に基づきフォーカス調整機構や絞り調整機構などの制御を行う。
ビデオ信号処理部５８は、供給されたディジタル信号に対して所定の信号処理を施す。例えば、ビデオ信号処理部５８は、供給されたディジタル信号に対して検波系の信号処理を施し、Ｒ（赤色）、Ｇ（緑色）およびＢ（青色）各色の成分を取り出す。そして、取り出された各色成分に基づきγ補正やホワイトバランス補正などの処理を行い、最終的に１本のベースバンドのディジタルビデオデータとして出力する。
表示部５５は、例えばＬＣＤ(Liquid Crystal Display)を表示素子として用い、ビデオ信号処理部５８から供給されたディジタルビデオデータに基づく表示を行うことができる。表示部５５は、撮影時には撮影画像のモニタとして用いられ、再生時には、再生画像を映出させることができる。
音声信号処理部５７は、例えばマイクロフォンＭＩＣ５６から供給されるアナログ音声信号をＡ／Ｄ変換してディジタルオーディオデータとし、ノイズ除去や音質補正など所定の音声信号処理を施してベースバンドのディジタルオーディオデータとして出力する。また、音声信号処理部５７は、供給されるディジタルオーディオデータに対して音質補正や音量調整などの所定の音声信号処理を施してＤ／Ａ変換してアナログ音声信号とし、増幅処理などを行いスピーカ部ＳＰ６０に供給する。
する。
撮影時には、光学系５１を介して撮像素子５２に入射された光が光電変換により電気信号に変換され撮像信号として出力される。撮像信号は、撮像信号処理部５３で所定に信号処理され、Ａ／Ｄ変換されディジタルビデオ信号として出力される。このディジタルビデオ信号は、ビデオ信号処理部５８に供給される。ビデオ信号処理部５８は、供給されたディジタルビデオ信号に対して画質補正などの所定の信号処理を施してディジタルビデオデータとして出力する。このディジタルビデオデータは、記録再生部１０に供給され端子４０に入力される。
また、ビデオ信号処理部５８は、撮像信号処理部５３から供給されたディジタル信号に基づき、表示部５５に表示するためのディジタルビデオデータを生成する。さらに、ビデオ信号処理部５８は、制御部３０とやりとりを行い、制御部３０で所定に生成された表示制御信号に基づく画像を生成することができる。このディジタルビデオデータや画像は、表示部５５に供給され、映出される。
一方、マイクロフォン５６から出力された音声信号は、音声信号処理部５７でノイズ除去、リミッタ処理、音質補正などの所定の信号処理を施され、さらにＡ／Ｄ変換され、ディジタルオーディオデータとして出力される。このディジタルオーディオデータは、記録再生部１０に供給され、端子４１に入力される。
記録停止状態からＵＩ部３１に設けられた記録スイッチが押下されると、記録開始を指示する制御信号がＵＩ部３１から制御部３０に供給され、制御部３０の制御に基づきカメラ部５０から出力されたベースバンドのディジタルビデオデータおよびディジタルオーディオデータの記録媒体３２への記録が開始される。
すなわち、図３４を用いて既に説明したように、制御部３０の制御に基づきビデオエンコーダ１１およびオーディオエンコーダ１２の動作が開始され、ビデオデータおよびオーディオデータがそれぞれビデオエンコーダ１１およびオーディオエンコーダ１２で圧縮符号化され、マルチプレクサ１３で所定にパケット化され多重化されてＡＶストリームデータとされる。ＡＶストリームデータは、ストリームバッファ１４を介して、記録制御部１５に供給され、クリップＡＶストリームファイルとして記録媒体３２に記録される。
ここで、ビデオカメラ装置１００が記録開始に応じて記録開始位置に自動的にプレイリストを設けるようにされている場合、図３１を用いて説明した処理に従い、記録開始位置に対応する位置に対して自動的にプレイリストマークが設けられる。実際には、プレイリストファイルに格納される情報は、例えば揮発性メモリ１７上において生成される。このプレイリストマークも、この時点では、揮発性メモリ１７上の情報である。
ＵＩ部３１の記録スイッチが次に押下されると、記録が停止され、クリップインフォメーションファイルの作成や、プレイリストファイルの更新が行われる。管理情報処理部１６は、マルチプレクサ１３および記録制御部１５からの情報に基づき、記録媒体３２に記録されるクリップＡＶストリームファイルに対応するクリップインフォメーションファイルを作成する。また、管理情報処理部１６は、当該クリップインフォメーションファイルを参照するプレイアイテムを生成し、既にプレイリストが存在する場合には、生成されたプレイアイテムを当該プレイリストに対して追加すると共に、プレイリストに対してプレイリストマークの情報を格納する。
再生時には、記録媒体３２がビデオカメラ装置１００に装填されると、記録媒体３２に記録されているインデックスファイル、ムービーオブジェクトファイルなどのファイルが読み出され、管理情報処理部１６に供給される。制御部３０は、管理情報処理部１６からインデックスファイルの情報を取得し、取得された情報に基づき所定のメニュー画面を表示するための表示制御信号を生成する。この表示制御信号は、ビデオ信号処理部５８に供給され、表示部５５に表示される。この表示に応じてＵＩ部３１に対して所定の操作を行うと、例えば、記録媒体３２から再生が指示されたプレイリストファイルが読み出され、このプレイリストファイルの記述に従い、記録媒体３２に記録されたクリップの再生がなされる。
すなわち、図３４を用いて既に説明したように、制御部３０は、ＵＩ部３１に対する操作に応じて管理情報処理具１６からプレイリストファイルの情報を取得し、取得された情報に基づき、記録再生制御部１５に対して記録媒体３２からクリップインフォメーションファイルやクリップＡＶストリームファイルを読み出すように命令を出す。
記録媒体３２から読み出されたクリップＡＶストリームファイルは、ストリームバッファ１４を介してＭＵＸ／ＤＥＭＵＸ１３に供給され、パケットのヘッダ情報などに基づき多重化が分離され圧縮ビデオデータと圧縮オーディオデータとが取り出される。圧縮ビデオデータは、ビデオデコーダ２０に供給されデコードされて、例えばＰＴＳに従い端子４２から出力される。圧縮オーディオデータは、オーディオデコーダ２１に供給されデコードされ、ビデオデコーダ２０から出力されるビデオデータと同期的に端子４３から出力される。
端子４２から出力されたビデオデータは、ビデオ信号処理部５８で所定の信号処理を施され、表示部５５に供給される。表示部５５は、供給されたビデオデータに基づく画像を映出する。端子４３から出力されたオーディオデータは、音声信号処理部５７で所定に信号処理され、増幅処理なども行われ、スピーカ部６０に供給される。
なお、このビデオカメラ装置１００においても、クリップのチャプタ分割編集を行うことできる。チャプタ分割編集処理は、上述した実施の一形態による処理と何ら変わるところがないため、繁雑さを避けるために説明を省略する。また、チャプタジャンプの際の処理についても、上述した実施の一形態による処理と変わらないため、説明を省略する。
なお、上述では、図３４に示す記録装置や図３６に示すビデオカメラ装置１００の記録再生部１０がハードウェア的に構成されるように説明したが、これはこの例に限定されない。すなわち、記録再生部１０は、ソフトウェアとして構成することも可能である。この場合、ソフトウェアは、例えば制御部３０が有する図示されないＲＯＭに予め記憶される。これに限らず、記録再生部１０を、パーソナルコンピュータなどのコンピュータ装置上に構成することも可能である。この場合には、記録再生部１０をコンピュータ装置に実行させるソフトウェアは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭといった記録媒体に記録されて提供される。コンピュータ装置がネットワーク接続可能な場合、インターネットなどのネットワークを介して当該ソフトウェアを提供することも可能である。
さらに、上述では、この発明が記録媒体にコンテンツデータなどを記録する記録装置または記録再生装置に適用されるように説明したが、これはこの例に限定されない。この発明は、記録媒体に対するコンテンツデータの記録手段や記録媒体からのコンテンツデータの再生手段を持たない、例えばコンテンツデータおよび当該コンテンツデータの再生制御情報（インデックスファイル、ムービーオブジェクト、プレイリストおよびクリップインフォメーションファイルなど）を編集する編集装置などにも適用可能なものである。この場合には、例えば、記録媒体からのデータの読み出しや記録媒体に対する書き込みは、編集装置に接続された記録再生装置により行うことが考えられる。
この発明に適用可能なＡＶＣＨＤフォーマットに規定されるデータモデルを概略的に示す略線図である。 インデックステーブルを説明するための略線図である。 クリップＡＶストリーム、クリップ情報、クリップ、プレイアイテムおよびプレイリストの関係を示すＵＭＬ図である。 複数のプレイリストから同一のクリップを参照する方法を説明するための略線図である。 記録媒体に記録されるファイルの管理構造を説明するための略線図である。 ファイル"index.bdmv"の一例の構造を表すシンタクスを示す略線図である。 ブロックblkIndexes()の一例の構造を表すシンタクスを示す略線図である。 ファイル"MovieObject.bdmv"の一例の構造を表すシンタクスを示す略線図である。 ブロックblkMovieObjects()の一例の構造を表すシンタクスを示す略線図である。 プレイリストファイル"xxxxx.mpls"の一例の構造を表すシンタクスを示す略線図である。 ブロックblkPlayList()の一例の構造を表すシンタクスを示す略線図である。 ブロックblkPlayItem()の一例の構造を表すシンタクスを示す略線図である。 第１および第２のシームレス接続を説明するための略線図である。 ブロックblkPlayListMark()の一例の構造を表すシンタクスを示す略線図である。 クリップインフォメーションファイルの一例の構造を表すシンタクスを示す略線図である。 ブロックblkCPI()の一例の構造を表すシンタクスを示す略線図である。 ブロックblkEPMap()の一例の構造を表すシンタクスを示す略線図である。 ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)の一例の構造を表すシンタクスを示す略線図である。 エントリPTSEPCoarseおよびエントリPTSEPFineの一例のフォーマットについて示す略線図である。 エントリSPNEPCoarseおよびエントリSPNEPFineの一例のフォーマットについて示す略線図である。 プレイリスト以下の一例のファイル構造を示す略線図である。 プレイリストを用いたクリップの分割編集について概略的に説明するための略線図である。 プレイリストマークを追加挿入する一例の処理を示すフローチャートである。 プレイリストマークを追加挿入する処理を説明するための略線図である。 プレイリストマークを追加挿入する処理を説明するための略線図である。 プレイリストマークをエントリPTSEPStartで示される位置に設ける方法と、ＧＯＰ境界の位置に設ける方法とのそれぞれのチャプタ境界の例を示す略線図である。 プレイリストマークをエントリPTSEPStartで示される位置に設ける方法と、ＧＯＰ境界の位置に設ける方法とのそれぞれのデコード区間の例を示す略線図である。 ＧＯＰがオープンＧＯＰおよびクローズドＧＯＰの何れかを判別可能な場合の、プレイリストマークをエントリPTSEPStartで示される位置に設ける方法と、ＧＯＰ境界の位置に設ける方法とのそれぞれのデコード区間の例を示す略線図である。 プレイリストマークの設定について各条件に関する評価を纏めて示す略線図である。 チャプタ分割編集を行う際の、プレイリストマークの一例の挿入方法を示すフローチャートである。 記録開始に応じて記録開始位置に自動的にプレイリストを設ける場合の一例の処理を示すフローチャートである。 仮想プレーヤの動作を概略的に示すフローチャートである。 仮想プレーヤの動作を概略的に示す略線図である。 この発明の実施の一形態に適用可能な記録再生装置の一例の構成を概略的に示すブロック図である。 プレイリストマークに基づくチャプタジャンプ処理の一例の方法を示すフローチャートである。 この発明の実施の一形態の他の例によるビデオカメラ装置の一例の構成を示す。 フレーム間圧縮を行ったデータのデコード処理について説明するための略線図である。
１０ 記録再生部
１１ ビデオエンコーダ
１２ オーディオエンコーダ
１３ マルチプレクサ
１４ ストリームバッファ
１５ 記録制御部
１６ 管理情報処理部
１７ 揮発性メモリ
１８ 不揮発性メモリ
２０ ビデオデコーダ
２１ オーディオデコーダ
３０ 制御部
３１ ユーザインターフェイス部
３２ 記録媒体
５０ カメラ部
１００ ビデオカメラ装置

Claims (14)

  1. ビデオデータを圧縮符号化して記録媒体に記録する記録装置において、
    少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いてビデオデータを圧縮符号化する符号化部と、
    上記符号化部で圧縮符号化されたビデオデータを記録媒体に記録するのを制御する記録制御部と、
    上記ビデオデータに対して上記グループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成部と
    を有し、
    上記マーク情報生成部は、
    再生順で直前のグループの情報を用いずに復号可能なグループに対して上記アクセス位置を指定するときには、上記指定されるアクセス位置から該グループの再生順の先頭に遡った位置を示す上記マーク情報を生成する
    記録装置。
  2. 請求項１に記載の記録装置において、
    上記マーク情報生成部は、
    再生順で直前のグループの情報を用いて復号を行うグループに対して上記アクセス位置を指定するときには、該グループに属する上記独立的に復号が可能なピクチャの位置を示す上記マーク情報を生成する
    記録装置。
  3. 請求項２に記載の記録装置において、
    指定しようとする上記アクセス位置の含まれるグループが再生順で直前のグループの情報を用いずに復号可能なグループであるか否かを判別する判別部をさらに有し、
    上記マーク情報生成部は、上記判別部による判別結果に応じて、上記グループの再生順の先頭位置を示す上記マーク情報を生成するか、上記グループに属する上記独立的に復号が可能なピクチャの位置を示す上記マーク情報を生成するかを決定する
    記録装置。
  4. 請求項３に記載の記録装置において、
    上記マーク情報生成部は、
    記録開始時に生成される上記グループの先頭の位置を示す上記マーク情報を自動的に生成する
    記録装置。
  5. 請求項４に記載の記録装置において、
    ユーザの操作を受け付け該操作に応じてアクセス位置を指定する操作部をさらに有し、
    上記マーク情報生成部は、
    上記操作部に対する操作により指定されたアクセス位置が記録開始位置以外の位置を示していれば該アクセス位置が含まれる上記グループに属する上記独立的に復号が可能なピクチャの位置を示す上記マーク情報を生成する
    記録装置。
  6. 請求項５に記載の記録装置において、
    上記ビデオデータの再生方法を示す再生制御情報を生成する再生制御情報生成部をさらに有し、
    上記マーク情報は、上記再生制御情報に格納される
    記録装置。
  7. ビデオデータを圧縮符号化して記録媒体に記録する記録方法において、
    少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いてビデオデータを圧縮符号化する符号化のステップと、
    上記符号化のステップにより圧縮符号化されたビデオデータを記録媒体に記録するのを制御する記録制御のステップと、
    上記ビデオデータに対して上記グループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成のステップと
    を有し、
    上記マーク情報生成のステップは、
    再生順で直前のグループの情報を用いずに復号可能なグループに対して上記アクセス位置を指定するときには、上記指定されるアクセス位置から該グループの再生順の先頭に遡った位置を示す上記マーク情報を生成する
    記録方法。
  8. ビデオデータを圧縮符号化して記録媒体に記録する記録方法をコンピュータ装置に実行させる記録プログラムにおいて、
    上記記録方法は、
    少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いてビデオデータを圧縮符号化する符号化のステップと、
    上記符号化のステップにより圧縮符号化されたビデオデータを記録媒体に記録するのを制御する記録制御のステップと、
    上記ビデオデータに対して上記グループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成のステップと
    を有し、
    上記マーク情報生成のステップは、
    再生順で直前のグループの情報を用いずに復号可能なグループに対して上記アクセス位置を指定するときには、上記指定されるアクセス位置から該グループの再生順の先頭に遡った位置を示す上記マーク情報を生成する
    記録プログラム。
  9. ビデオデータに対してアクセス位置を指定するマーク情報を生成する編集装置において、
    少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いて圧縮符号化されたビデオデータを復号する復号部と、
    上記ビデオデータに対して上記グループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成部と、
    を有し、
    上記マーク情報生成部は、
    再生順で直前のグループの情報を用いずに復号可能なグループに対して上記アクセス位置を指定するときには、上記指定されるアクセス位置から該グループの再生順の先頭に遡った位置を示す上記マーク情報を生成する
    編集装置。
  10. 請求項９に記載の編集装置において、
    上記マーク情報生成部は、
    再生順で直前のグループの情報を用いて復号を行うグループに対して上記アクセス位置を指定するときには、該グループに属する上記独立的に復号が可能なピクチャの位置を示す上記マーク情報を生成する
    編集装置。
  11. 請求項９または１０に記載の編集装置において、
    上記アクセス位置の含まれるグループが再生順で直前のグループの情報を用いずに復号可能なグループであるか否かを判別する判別部をさらに有し、
    上記マーク情報生成部は、上記判別部による判別結果に応じて、上記指定されるアクセス位置から該グループの再生順の先頭に遡った位置を示す上記マーク情報を生成するか、上記グループに属する上記独立的に復号が可能なピクチャの位置を示す上記マーク情報を生成するかを決定する
    編集装置。
  12. ビデオデータに対してアクセス位置を指定するマーク情報を生成する編集方法において、
    少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いて圧縮符号化されたビデオデータを復号する復号のステップと、
    上記ビデオデータに対して上記グループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成のステップと、
    を有し、
    上記マーク情報生成のステップは、
    再生順で直前のグループの情報を用いずに復号可能なグループに対して上記アクセス位置を指定するときには、上記指定されるアクセス位置から該グループの再生順の先頭に遡った位置を示す上記マーク情報を生成する
    編集方法。
  13. ビデオデータに対してアクセス位置を指定するマーク情報を生成する編集方法をコンピュータ装置に実行させる編集プログラムにおいて、
    上記編集方法は、
    少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いて圧縮符号化されたビデオデータを復号する復号のステップと、
    上記ビデオデータに対して上記グループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成のステップと、
    を有し、
    上記マーク情報生成のステップは、
    再生順で直前のグループの情報を用いずに復号可能なグループに対して上記アクセス位置を指定するときには、上記指定されるアクセス位置から該グループの再生順の先頭に遡った位置を示す上記マーク情報を生成する
    編集プログラム。
  14. ビデオデータを圧縮符号化して記録媒体に記録する記録装置において、
    少なくとも１枚の独立的に復号が可能なピクチャを含む複数枚のピクチャからなるグループを単位とし、予測符号化によるフレーム間圧縮を用いてビデオデータを圧縮符号化する符号化部と、
    上記符号化部で圧縮符号化されたビデオデータを記録媒体に記録するのを制御する記録制御部と、
    上記ビデオデータに対して上記グループ単位のアクセス位置を示すマーク情報を生成するマーク情報生成部と
    を有し、
    上記マーク情報生成部は、
    再生順で直前のグループの情報を用いて復号を行うグループに対して上記アクセス位置を指定するときには、該グループに属する上記独立的に復号が可能なピクチャの位置を示す上記マーク情報を生成する
    記録装置。
JP2006140839A 2006-05-19 2006-05-19 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム Expired - Fee Related JP4715633B2 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2006140839A JP4715633B2 (ja) 2006-05-19 2006-05-19 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム
TW096113501A TWI365447B (en) 2006-05-19 2007-04-17 Recording apparatus, recording method, recording program, recording/reproducing apparatus, recording/reproducing method, recording/reproducing program, editing apparatus, editing method, and editing
EP07009174.9A EP1858020B1 (en) 2006-05-19 2007-05-07 Recording/reproducing or editing apparatus and corresponding method and program
KR20070044670A KR101364206B1 (ko) 2006-05-19 2007-05-08 기록 장치, 기록 방법 및 기록 프로그램, 기록 재생장치,기록 재생 방법 및 기록 재생 프로그램, 및, 편집 장치,편집 방법 및 편집 프로그램
US11/804,749 US8229281B2 (en) 2006-05-19 2007-05-18 Recording apparatus, recording method, recording program, recording/reproducing apparatus, recording/reproducing method, recording/reproducing program, editing apparatus, editing method, and editing program
CN2007101041530A CN101075462B (zh) 2006-05-19 2007-05-21 记录/再现/编辑装置、方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006140839A JP4715633B2 (ja) 2006-05-19 2006-05-19 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム

Publications (3)

Publication Number Publication Date
JP2007312246A JP2007312246A (ja) 2007-11-29
JP2007312246A5 JP2007312246A5 (ja) 2009-05-21
JP4715633B2 true JP4715633B2 (ja) 2011-07-06

Family

ID=38474252

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006140839A Expired - Fee Related JP4715633B2 (ja) 2006-05-19 2006-05-19 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム

Country Status (6)

Country Link
US (1) US8229281B2 (ja)
EP (1) EP1858020B1 (ja)
JP (1) JP4715633B2 (ja)
KR (1) KR101364206B1 (ja)
CN (1) CN101075462B (ja)
TW (1) TWI365447B (ja)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7480512B2 (en) 2004-01-16 2009-01-20 Bones In Motion, Inc. Wireless device, program products and methods of using a wireless device to deliver services
US12105208B2 (en) 2004-06-30 2024-10-01 Adidas Ag Systems and methods for providing a health coaching message
JP4972933B2 (ja) * 2005-12-28 2012-07-11 ソニー株式会社 データ構造、記録装置、記録方法、記録プログラム、再生装置、再生方法および再生プログラム
JP4656021B2 (ja) * 2006-08-10 2011-03-23 ソニー株式会社 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
JP4779921B2 (ja) * 2006-10-05 2011-09-28 ソニー株式会社 データ処理装置及びデータ処理方法、並びにコンピュータ・プログラム
JP2008311871A (ja) * 2007-06-13 2008-12-25 Hitachi Ltd 情報記録再生装置及びビデオカメラ装置
US8702430B2 (en) 2007-08-17 2014-04-22 Adidas International Marketing B.V. Sports electronic training system, and applications thereof
US8221290B2 (en) 2007-08-17 2012-07-17 Adidas International Marketing B.V. Sports electronic training system with electronic gaming features, and applications thereof
US8360904B2 (en) 2007-08-17 2013-01-29 Adidas International Marketing Bv Sports electronic training system with sport ball, and applications thereof
JP5191294B2 (ja) * 2008-07-16 2013-05-08 Ｎｅｃパーソナルコンピュータ株式会社 情報処理装置及びプログラム
JP5085462B2 (ja) 2008-08-11 2012-11-28 ソニー株式会社 情報記録装置、撮像装置、情報記録方法およびプログラム
JP4924633B2 (ja) * 2009-02-27 2012-04-25 ソニー株式会社 情報処理装置、情報処理方法およびプログラム
JP4957823B2 (ja) * 2009-04-08 2012-06-20 ソニー株式会社 再生装置および再生方法
US9392941B2 (en) 2010-07-14 2016-07-19 Adidas Ag Fitness monitoring methods, systems, and program products, and applications thereof
US10039970B2 (en) 2010-07-14 2018-08-07 Adidas Ag Location-aware fitness monitoring methods, systems, and program products, and applications thereof
JP5671949B2 (ja) * 2010-11-04 2015-02-18 ソニー株式会社 情報処理装置、および情報記録媒体、並びに情報処理方法
US20120258433A1 (en) 2011-04-05 2012-10-11 Adidas Ag Fitness Monitoring Methods, Systems, And Program Products, And Applications Thereof
EP2887663B1 (en) 2012-09-29 2017-02-22 Huawei Technologies Co., Ltd. Method, apparatus and system for encoding and decoding video
US20140223286A1 (en) * 2013-02-07 2014-08-07 Infopower Corporation Method of Displaying Multimedia Contents
TWI578763B (zh) * 2013-02-28 2017-04-11 英特爾股份有限公司 編碼單元位元數限制
TWI548266B (zh) * 2014-06-24 2016-09-01 愛爾達科技股份有限公司 多媒體檔案儲存系統與相關裝置
EP3206408B1 (en) 2014-10-10 2020-12-30 Sony Corporation Encoding device and method, playback device and method, and program
KR101868203B1 (ko) * 2015-01-28 2018-07-20 한국전자통신연구원 스트림 처리 방법 및 장치
KR102444044B1 (ko) * 2015-09-25 2022-09-19 삼성전자주식회사 이미지 처리장치 및 방법
US11040246B2 (en) 2018-02-06 2021-06-22 Adidas Ag Increasing accuracy in workout autodetection systems and methods

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005101827A1 (ja) * 2004-04-16 2005-10-27 Matsushita Electric Industrial Co., Ltd. 記録媒体、再生装置、プログラム
JP2006506763A (ja) * 2002-11-12 2006-02-23 エルジー エレクトロニクス インコーポレーテッド 記録された多重再生経路ビデオデータの再生を管理するためのデータ構造を有する記録媒体とそれによる記録及び再生方法及び装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3491365B2 (ja) * 1995-01-31 2004-01-26 ソニー株式会社 符号化データ復号方法および復号装置
JPH08242452A (ja) * 1995-03-02 1996-09-17 Matsushita Electric Ind Co Ltd 映像信号圧縮符号化装置
JP3873463B2 (ja) * 1998-07-15 2007-01-24 株式会社日立製作所 情報記録装置
EP1206135B1 (en) * 1999-07-29 2011-08-24 Sharp Kabushiki Kaisha Method of determining access position on recording medium and method of managing recording medium
US7570866B2 (en) * 2002-11-12 2009-08-04 Lg Electronics Inc. Recording medium having data structure for managing reproduction of multiple reproduction path video data recorded thereon and recording and reproducing methods and apparatuses
US7852919B2 (en) * 2003-09-07 2010-12-14 Microsoft Corporation Field start code for entry point frames with predicted first field
US7609762B2 (en) * 2003-09-07 2009-10-27 Microsoft Corporation Signaling for entry point frames with predicted first field
KR101058007B1 (ko) * 2004-05-18 2011-08-19 삼성전자주식회사 기록 매체에 저장된 데이터를 삭제하는 방법 및 삭제된데이터를 복원하는 방법
JP2007243907A (ja) * 2006-02-10 2007-09-20 Sony Corp 記録装置、記録方法、記録方法のプログラム、記録方法のプログラムを記録した記録媒体、再生装置、再生方法、再生方法のプログラム及び再生方法のプログラムを記録した記録媒体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006506763A (ja) * 2002-11-12 2006-02-23 エルジー エレクトロニクス インコーポレーテッド 記録された多重再生経路ビデオデータの再生を管理するためのデータ構造を有する記録媒体とそれによる記録及び再生方法及び装置
WO2005101827A1 (ja) * 2004-04-16 2005-10-27 Matsushita Electric Industrial Co., Ltd. 記録媒体、再生装置、プログラム

Also Published As

Publication number Publication date
CN101075462A (zh) 2007-11-21
TWI365447B (en) 2012-06-01
US8229281B2 (en) 2012-07-24
KR101364206B1 (ko) 2014-02-21
TW200813993A (en) 2008-03-16
EP1858020A1 (en) 2007-11-21
KR20070111984A (ko) 2007-11-22
US20070269187A1 (en) 2007-11-22
CN101075462B (zh) 2010-09-29
EP1858020B1 (en) 2020-05-06
JP2007312246A (ja) 2007-11-29

Similar Documents

Publication Publication Date Title
JP4715633B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム
JP4337849B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
US8554055B2 (en) Editing device, editing method and editing program, and data processing device, data processing method and data processing program
WO2005122567A1 (ja) データ記録装置、方法およびプログラム、データ再生装置、方法およびプログラム、記録媒体、ならびに、データ構造
JP4622950B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
US8995816B2 (en) Recording apparatus, recording method, and recording program, and image capturing apparatus, image capturing method and image capturing program
KR101353000B1 (ko) 기록장치, 기록방법 및 기록 프로그램과 촬상장치,촬상방법 및 촬상 프로그램
JP2008282471A (ja) 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090402

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090402

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20101207

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101214

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110210

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110314

R151 Written notification of patent or utility model registration

Ref document number: 4715633

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140408

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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