WO2007135932A1 - 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム - Google Patents

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

Info

Publication number
WO2007135932A1
WO2007135932A1 PCT/JP2007/060081 JP2007060081W WO2007135932A1 WO 2007135932 A1 WO2007135932 A1 WO 2007135932A1 JP 2007060081 W JP2007060081 W JP 2007060081W WO 2007135932 A1 WO2007135932 A1 WO 2007135932A1
Authority
WO
WIPO (PCT)
Prior art keywords
management information
recording
information
stream file
predetermined
Prior art date
Application number
PCT/JP2007/060081
Other languages
English (en)
French (fr)
Inventor
Atsushi Mae
Kenichiro Aridome
Yukio Isobe
Naoki Morimoto
Original Assignee
Sony Corporation
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 Corporation filed Critical Sony Corporation
Priority to EP07743516.2A priority Critical patent/EP2023629A4/en
Priority to KR1020087000499A priority patent/KR101379034B1/ko
Priority to CN2007800007225A priority patent/CN101331764B/zh
Priority to US11/988,978 priority patent/US8995816B2/en
Publication of WO2007135932A1 publication Critical patent/WO2007135932A1/ja

Links

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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • 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

Definitions

  • the present invention relates to a recording apparatus, a recording method and a recording program suitable for recording stream data obtained by multiplexing video data and audio data on a recording medium, as well as an imaging apparatus, an imaging method, and an imaging program.
  • video data and audio recording on a recording medium are generally performed in units of video data generated between a recording start operation and a recording stop operation.
  • the playback section and the playback order are specified using the playback list information for the video data generated between the recording start operation and the recording stop operation.
  • video data and audio data are recorded as files in units of data generated between a recording start operation and a recording stop operation.
  • video data and audio data are recorded as files in units of data generated between a recording start operation and a recording stop operation.
  • the playback list file is once read into the memory, and the video data and audio data recorded as the file are read. It is conceivable to perform overnight playback control.
  • Other management information for managing video data and audio data recorded on the recording medium is also read into the memory, so if the size of the playlist file increases, the memory capacity will be compressed, and other processing will be performed. There was a problem that there was a risk of trouble.
  • the system may force the system to stop recording video data and audio data, or the system may hang up. There was a problem.
  • the types of video formats commonly used have become more diverse.
  • the number of lines in the interlaced scanning format, the number of lines is 4880, 4880 i, the number of lines is 576, 576 6i, and the number of lines is 1080.
  • the number of lines in the progressive scan format, the number of lines is 4 80, 5 7 6, 7 20 and 1 0 80, 4 8 0 p 5 7 6 p, 7 2 0 p and 1 0 8 0 ⁇ are specified
  • the recording apparatus is also required to be able to perform recording corresponding to the various types of formats described above. At the same time, it is required to be able to record video data in multiple formats on a single recording medium.
  • an object of the present invention is to provide a recording apparatus and a recording apparatus capable of improving user convenience when recording video data and audio data generated between a recording start operation and a recording stop operation as a file.
  • a method and a recording program, an imaging device, an imaging method, and an imaging program are examples of a recording apparatus and a recording apparatus.
  • a first invention includes a data input unit to which video data and audio data are input in a recording apparatus that multiplexes video data and audio data and records the data on a recording medium.
  • Recording instruction input unit for inputting video data and audio recording start / stop instructions, video data and audio data are multiplexed, and the multiplexed stream is a stream file.
  • the first management information indicating the attribute information of the stream file, and the second management information including information indicating the reproduction method of the stream file.
  • a management information generating unit that generates playback management information for controlling the playback of the stream file.
  • the management information generating unit records according to the recording start instruction from the recording instruction input unit based on the existing playback management information. It is determined whether or not additional information can be added as to whether or not information indicating the reproduction method for the stream file recorded on the medium is added to the predetermined second management information included in the existing reproduction management information. It is a recording device.
  • the second aspect of the invention relates to a recording method for multiplexing video data and audio data and recording them on a recording medium.
  • the recording method instructions for recording start and stop of video data and audio data input to the data input unit are input.
  • Recording instruction input step video data and audio data are multiplexed, the multiplexed stream is recorded on a recording medium as a stream file, and stream file attribute information is shown.
  • Management information generation for generating playback management information for controlling playback of a stream file recorded on a recording medium, comprising first management information and second management information including information indicating a playback method of the stream file
  • the management information generation step is based on the existing playback management information and the recording instruction Whether to add information indicating the playback method for the stream file recorded on the recording medium in accordance with the recording start instruction in the step of recording to the predetermined second management information included in the existing playback management information. This is a recording method characterized by determining whether additional writing is possible.
  • the recording method for causing a computer apparatus to execute a recording method for multiplexing video data and audio data and recording the multiplexed data on a recording medium.
  • the recording method includes a recording instruction input step in which an instruction to start and stop recording video and audio data input to the data input unit, video data and audio recording are input.
  • a management information generation step for generating playback management information for controlling playback of the stream file recorded on the recording medium, and the management information generation step is added to the existing playback management information.
  • the stream file recorded on the recording medium is Information indicating a reproducing method for a recording program and performs whether write-once permission determination to add serial to a predetermined second management information included in the existing reproduction management information.
  • the fourth aspect of the invention multiplexes the video data obtained by imaging the subject with the imaging unit and the audio data obtained by collecting the audio with the sound collecting unit and records them on the recording medium.
  • an image pickup unit that picks up an image of a subject and outputs a video image
  • a sound pickup unit that picks up sound and outputs audio data
  • multiplexes and multiplexes video data and audio data
  • a recording unit that records the recorded stream as a stream file on a recording medium
  • an operation unit that assigns a user operation that instructs recording start and stop of recording of video data and audio data on the recording medium, and attribute information of the stream file
  • a stream file recorded on a recording medium including first management information to be displayed and second management information including information indicating a stream file playback method.
  • a management information generation unit for generating playback control information for controlling the reproduction, management information generation unit, Based on the existing playback management information, information indicating the playback method for the stream file recorded on the recording medium in accordance with the recording start instruction according to the user operation to the operation unit is stored in the predetermined playback management information.
  • the imaging apparatus is characterized by determining whether or not to add information to the second management information.
  • the fifth aspect of the invention multiplexes the video data obtained by imaging the subject with the imaging unit and the audio data obtained by collecting the audio with the sound collecting unit and records them on the recording medium.
  • video data obtained by imaging a subject with an imaging unit and audio data obtained by collecting sound by a sound collection unit are multiplexed, and a multiplexed stream is obtained.
  • a management information generation step for generating playback management information for controlling playback, and the management information generation step is based on the instruction to start recording according to the user operation to the operation unit based on the existing playback management information. It is characterized in that it is possible to determine whether or not additional information indicating whether or not information indicating a reproduction method for a stream file recorded on a recording medium is to be added to predetermined second management information included in existing reproduction management information. This is an imaging method.
  • the sixth aspect of the invention is an image pickup that multiplexes the video data obtained by picking up the subject with the image pickup unit and the audio data obtained by picking up the sound with the sound pickup unit and records them on the recording medium.
  • the imaging method includes: A recording step of multiplexing video data obtained by imaging and audio data obtained by collecting sound by a sound collecting unit, and recording the multiplexed stream as a stream file on a recording medium; A step of accepting a user operation for instructing the operation unit to start and stop recording of video data and audio data to a recording medium, first management information indicating stream file attribute information, and stream file playback Management information generating step for generating playback management information for controlling playback of a stream file recorded on the recording medium, comprising second management information including information indicating a method.
  • the information generation step is based on the existing playback management information and follows the recording start instruction according to the user operation to the operation unit. It is characterized in that it is determined whether or not additional information indicating whether or not information indicating a reproduction method for the recorded stream file is to be added to the predetermined second management information included in the existing reproduction management information.
  • An imaging program is based on the existing playback management information and follows the recording start instruction according to the user operation to the operation unit. It is characterized in that it is determined whether or not additional information indicating whether or not information indicating a reproduction method for the recorded stream file is to be added to the predetermined second management information included in the existing reproduction management information.
  • the first management information indicating the attribute information of the stream file including the stream in which the video data and the audio data are multiplexed, and the reproduction of the stream file are provided.
  • Playback management information for controlling playback of a stream file recorded on a recording medium comprising second management information including information indicating a method, and based on the existing playback management information. Addition of whether or not to add information indicating the playback method for the stream file recorded on the recording medium in accordance with the data recording start instruction to the predetermined second management information included in the existing playback management information Since it is determined whether it is possible or not, even if the recording start operation and the recording stop operation are repeated, the second tube is not conscious of the user.
  • the fourth, fifth and sixth inventions show stream file attribute information comprising a stream in which video data obtained by imaging and audio data obtained by sound collection are multiplexed.
  • Reproduction management information for controlling the reproduction of the stream file recorded on the recording medium which includes the first management information and the second management information including information indicating the reproduction method of the stream file, is generated.
  • the existing playback management information in accordance with a recording start instruction corresponding to a user operation to the operation unit, information indicating a playback method for a stream file made up of video data obtained by photographing a subject recorded on a recording medium. Since it is determined whether or not to append to the predetermined second management information included in the existing playback management information, Even when repeatedly recording start operation and recording stop operation when the shadow, the user without the consciousness child, generation of the second management information is appropriately controlled.
  • the first management information indicating the attribute information of the stream file composed of the stream in which the video data and the audio data are multiplexed, and the stream file Reproduction management information for controlling the reproduction of the stream file recorded on the recording medium, which includes second management information including information indicating the reproduction method, is generated.
  • the existing reproduction management information Whether or not to add information indicating the playback method for the stream file recorded on the recording medium in accordance with the instruction to start recording video data to the predetermined second management information included in the existing playback management information. Since it is determined whether or not additional recording is possible, even when the recording start operation and recording stop operation are repeatedly performed, the second pipe is not conscious of the user. This has the effect of properly controlling the generation of physical information.
  • the fourth, fifth, and sixth inventions are imaged.
  • 1st management information indicating the attribute information of the stream file consisting of the stream in which the video data obtained in the above and the audio data obtained by collecting the sound are multiplexed, and information indicating the playback method of the stream file are included.
  • the second management information is generated to generate playback management information for controlling the playback of the stream file recorded on the recording medium.
  • the user for the operation unit is generated.
  • information indicating a playback method for a stream file composed of video data obtained by photographing a subject recorded on a recording medium is stored in a predetermined number of pieces included in the existing playback management information.
  • FIG. 1 is a schematic diagram schematically showing a data model defined in the AVCHD format applicable to the present invention
  • FIG. 2 is a schematic diagram for explaining an index table
  • FIG. Fig. 4 is a UML diagram showing the relationship between clip AV streams, clip information, clips, play items, and playlists.
  • Fig. 4 is an abbreviation for explaining how to refer to the same clip from multiple playlists.
  • Fig. 5 is a schematic diagram for explaining the management structure of a file recorded on a recording medium.
  • Fig. 6 is a schematic diagram showing a syntax representing an example of the structure of the file "index, bdmv”.
  • Fig. 7 is a schematic diagram showing the syntax of an example of a block blklndexes O.
  • FIG. 8 is a schematic diagram showing the syntax of an example of a file "MovieObj ec t. Bdmv”.
  • Figure 9 shows the block b ikMovi eObj ec i s o
  • Fig. 10 is a schematic diagram showing the syntax of an example structure
  • Fig. 10 is a schematic diagram showing the syntax of an example of the playlist file "xxxxx. Immediate Is”
  • Fig. 11 is an example of the block blkPIayUstO.
  • Fig. 12 is a schematic diagram showing the structure representing an example of the structure of an example of the block blkPlayltemO.
  • Fig. 13 A and Fig. 13 B are the first and second diagrams.
  • Fig. 13 A and Fig. 13 B are the first and second diagrams.
  • FIG. 14 is a schematic diagram illustrating the syntax of an example of a block MkPlayListMarkO.
  • Fig. 15 is a schematic diagram illustrating the structure of an example of a clip information file.
  • Fig. 16 is a schematic diagram showing a syntax representing an example structure of a block blkClipI ⁇
  • Fig. 17 is a schematic diagram showing a syntax representing an example structure of a block blkProgramlnfoO
  • Figure 18 Block diagram showing the syntax of an example of the structure of block blkStreamCodingInfo (stream—index)
  • Fig. 19 is a diagram showing a list of formats of an example of video data indicated by the field VideoFormat, Fig. 20 Fig.
  • Fig. 21 is a schematic diagram showing a list of example frame rates indicated by the field FrameRate
  • Fig. 21 is a schematic diagram showing a list of example frame rates indicated by the field AspectRatio
  • Fig. 22 is a block MkCPlO
  • Fig. 23 is a schematic diagram showing the syntax of an example of the structure of the block blkEPMapO
  • Fig. 24 is a schematic diagram of the syntax of the block blkEPMapForOneStreamPID (EP_streafflJy pe, Nc, Nf).
  • Fig. 25 is a schematic diagram showing the syntax for an example structure.
  • Fig. 25 is a schematic diagram showing an example format of an entry PTSEPCoarse and an entry PTSEPFine.
  • FIG. 26 is an entry diagram.
  • Fig. 27 is a schematic diagram showing the syntax of an example of the structure of a block blkExtensionDataO.
  • Fig. 28 is a schematic diagram showing the structure of an example of a block blkExtensionDataO.
  • Fig. 29 is a schematic diagram showing the data reference relationship.
  • Fig. 29 is a flow chart showing an example of processing when data is written to the block blkE xtensionDataO.
  • Fig. 30 is for reading extension data from the block blkExtensionDataO.
  • FIG. 27 is a schematic diagram showing the syntax of an example of the structure of a block blkExtensionDataO.
  • Fig. 28 is a schematic diagram showing the structure of an example of a block blkExtensionDataO.
  • Fig. 29 is a schematic diagram showing the data reference relationship.
  • Fig. 29 is a flow chart showing an example of processing when data is written to the block blkE x
  • FIG. 31 is a schematic diagram showing a syntax indicating an example of a structure of a block DataBlockO in the field HblkExtensionDataO in the file “index, bdmv”, and FIG. 32 is a block blkTableOfPlayListO.
  • Fig. 33 is a schematic diagram showing syntax of an example structure
  • Fig. 33 is a schematic diagram showing syntax of an example of a block DataBlockO in a block blkExtensionDataO in a playlist file "xxxxx.mpls”
  • Fig. 35 is a schematic diagram showing a syntax representing an example of the structure of the block blkPlayListMeta ().
  • Fig. 35 is a block in the playlist file.
  • FIG. 36 is a schematic diagram showing the syntax of an example of the structure of MkMakersPrivateDataO.
  • Fig. 36 is a schematic diagram showing the syntax of an example of the structure of block Da BlockO in block blkExtensionDataO in the clip information file.
  • Fig. 38 is a schematic diagram showing the syntax of an example of the block blkProgramlnfoExt 0,
  • Fig. 38 is a schematic diagram showing the syntax of an example of the block blkStreamCodingInfoExt (i, j)
  • Fig. 39A and FIG. 39 is a flowchart schematically showing the operation of the virtual player
  • FIG. 40 is a schematic diagram schematically showing the operation of the virtual player
  • FIG. 41 is applicable to one embodiment of the present invention.
  • FIG. 42 is a block diagram schematically showing the structure of an example of a recording apparatus
  • FIG. 42 is a schematic diagram showing an example data structure applicable to one embodiment of the present invention
  • FIG. Fig. 44 is a flowchart showing an example of a process for determining whether or not an additional file can be added to the list file.
  • FIG. 46 is a flowchart showing an example of additional write permission / inhibition based on video attributes
  • FIG. 48 is a flowchart showing an example of determination processing.
  • FIG. 48 is a flowchart showing an example of processing for determining whether additional writing is possible based on the total file size of clip information files referred to from the additional writing candidate playlist file.
  • Fig. 50 is a flowchart showing an example of a process for determining whether or not additional recording is possible based on the total number of entry points stored in the clip information file referenced from the additional recording candidate playlist file.
  • Figure 5 shows the flowchart of an example process for determining whether additional writing is possible based on the presence or absence of unique extension data.
  • FIG. 52 is a flowchart showing an example of the appendability determination process based on the last updater of the appending candidate playlist file.
  • FIG. 52 is a flowchart showing an example recording method of a clip according to the embodiment of the present invention.
  • FIG. 53 is a block diagram showing a configuration of an example of a video camera apparatus according to another example of the embodiment of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION
  • AVCHD format is currently proposed as a recording format that records AV (Audio / Video) streams in which video data and audio data are multiplexed on a recordable recording medium.
  • the AV stream recorded on the recording medium can be managed using a playlist in clip units.
  • I TU-T International Telecommunication Union-Telecomunication Standarization Sector
  • H.264 A bitstream encoded with the encoding method specified in Advanced Video Coding
  • a clip AV stream (or AV Stream).
  • the clip AV stream is recorded on the disc as a file by a predetermined file system. This file is called a clip AV stream file (or AV stream file).
  • a clip AV stream file is a management unit on the file system, and is not necessarily a management unit that is easily understood by the user.
  • a mechanism that plays video content divided into multiple clip AV stream files together a mechanism that plays back only part of a clip AV stream file, It is necessary to record information for smooth special playback and cue playback on the disc as a database.
  • FIG. 1 schematically shows a data model defined in the A VCHD format applicable to the present invention.
  • the data structure consists of four layers as shown in FIG.
  • the lowest layer is a layer in which the clip AV stream is arranged (referred to as a clip layer for convenience).
  • the layer above it is a layer in which a playlist (PlayList) and a play item (Playltem) for designating a playback position for the clip AV stream are arranged (referred to as a playlist layer for convenience).
  • the ray above it A layer is a layer in which a movie object (Movie Object) composed of commands for specifying a playback order and the like for a playlist is arranged (referred to as an object layer for convenience).
  • an index table for managing titles stored in the recording medium is arranged (referred to as an index layer for convenience).
  • the clip layer will be described.
  • the clip AV stream is a bit stream in which video data and audio data are multiplexed in the format of MP EG 2 TS (transport stream). Information about this clip AV stream is recorded in a file as clip information (Clip Information).
  • the clip AV stream also includes an OB stream (Overlay Bitmap stream), which is a graphics stream that displays subtitles, and an MB stream (Menu Bitmap) that uses data (such as button image data) used for menu display. stream) can be multiplexed.
  • OB stream overlay Bitmap stream
  • MB stream Ma Bitmap
  • a clip AV stream file and a clip information file in which corresponding clip information is recorded are regarded as a group of objects and are called a clip. That is, a clip is an object composed of a clip AV stream and clip information.
  • Clips are generally treated as bytes.
  • the content of the clip AV stream file is expanded on the time axis, and the entry points in the clip are specified mainly on a time basis.
  • the clip information file Given the time stamp of an access point to a given clip, the clip information file can be used to find the address information in the clip AV stream file where data reading should start. it can. -Explain the playlist layer. Play a playlist
  • a playback start point and playback end point is called a play item.
  • a playlist consists of a set of play items. Playing a play item means playing a part of the AV stream file referenced by the play item. That is, the corresponding section in the clip is played based on the IN point and OUT point information in the play item.
  • a movie object includes terminal information that links a navigation command program and a movie object.
  • the navigation program is a command (navigation command) for controlling playback of a playlist.
  • the index layer will be described.
  • the index layer consists of an index table.
  • the index table is a top-level table that defines the title of the content recorded on the recording medium. Based on the title information stored in the index table, the playback of the recording medium is controlled by the module manager in the system software resident in the player.
  • an arbitrary entry in the index table is called a title, and a first playback title (First Playback Title) and a menu title (MenuTiUe) entered in the index table.
  • movie title (Movie Title) # l, # 2, ... are all titles. Each title represents a link to a movie object.
  • a playback-only recording medium For ease of understanding, take a playback-only recording medium as an example.
  • the content stored on the recording medium is a movie
  • the movie company will be shown before the main movie
  • the menu title corresponds to a menu screen for selecting main content playback, chapter search, subtitle and language settings, privilege video playback, and the like.
  • the movie title is each video selected from the menu title.
  • Fig. 3 shows the UML (Unified Modeling) that shows the relationship between the clip AV stream, clip information (Stream Attributes), clips, play items, and playlists as described above. Language) diagram.
  • a playlist is associated with one or more play items, and a play item is associated with one clip.
  • a single clip can be associated with a plurality of play items having different start points and end points.
  • 1 clip to 1 clip AV stream file is referenced.
  • one clip information file is referenced from one clip.
  • a clip AV stream file and a clip information file have a one-to-one correspondence.
  • the same clip can be referenced from multiple playlists. Also, multiple clips from one playlist Can also be specified.
  • a clip is referenced by the IN and OUT points indicated on the play item in the playlist.
  • the clip 3 0 0 is referred to from the play item 3 2 0 of the play list 3 1 0 and the play items 3 2 1 and 3 2 2 constituting the play list 3 1 1 are played.
  • Item 3 2 1 refers to the section indicated by the IN and OUT points.
  • clip 3 0 1 refers to the section indicated by IN point and OUT point from play item 3 2 2 of playlist 3 1 1, and play item 3 2 3 and 3 2 of playlist 3 1 2 Of the four, the section indicated by the IN point and OUT point of play item 3 2 3 is referenced. In the example of FIG. 4, the clip 3 0 1 is also referenced from another playlist.
  • Files are managed hierarchically according to the directory structure. First, one directory (the root directory in the example of Fig. 5) is created on the recording medium. The range under this directory is managed by one recording and playback system.
  • the directory “BDMV” is placed under the root directory.
  • a directory "AVCHDTN” is placed under the root directory.
  • AVCHDTN thumbnail file obtained by reducing a representative image of a clip to a predetermined size is placed in the directory “AVCHDTN”.
  • the directory “BDMV” stores the data structure described with reference to FIG. Directly under the directory “BDMV”, only two files can be placed: the file “index, bdm v" and the file “MovieObject.bdmv”. Also, under the directory “BDMV”, the directory “PLAYL IST:”, the directory “CL IP INF”, the directory “STREAM” and the directory “BACK”. m »" is placed.
  • the directory “BACK” stores the backup of each directory and file.
  • the file “index, bdmv” describes the contents of the directory BDMV. That is, this file “index.bdmv” corresponds to the index table in the index layer that is the uppermost layer described above.
  • the file MovieObject.bdmv stores information on one or more movie objects. That is, this file “MovieObject.b dmv” corresponds to the object layer described above.
  • the directory “PLAYLIST” is a directory in which a playlist base is placed. That is, the directory “PLAYLIST” includes a file “xxxxx. Immediately Is” that is a file related to the playlist.
  • the file “xxxxx.mpls” is a file created for each playlist. In the file name, the “xxxxx” before the “.” (Period) is a five-digit number, and the “mpls” after the period is an extension that is fixed for this type of file.
  • the directory “CLIPINF” is a directory where a database of clips is placed. That is, the directory CLIPINF "is the clip information for each clip AV stream file. including "zzzzz. clpi" In the file name, “zzzzz” before “.” (period) is a five-digit number, and "clpi" after the period is fixed to this type of file. Extension.
  • the directory “STREAM” is a directory in which AV stream files as entities are placed. That is, the directory “STREAM” includes clip AV stream files corresponding to the clip information files.
  • the directory “AVCHDTN” can contain two types of thumbnail files thumbnail.tidx and thumbnail.tdt2.
  • the thumbnail file thumbnail.Udx stores thumbnail images encrypted by a predetermined method.
  • the thumbnail file thumbnail.tdt2 stores unencrypted thumbnail images. For example, a thumbnail image corresponding to a clip shot by a user with a video camera is considered to be copy-free and does not need to be encrypted, so it is stored in this thumbnail file;
  • FIG. 6 shows a syntax representing an example of the structure of this file “index, bdmv”.
  • the syntax is shown based on the C language description method used as a program description language for computer devices. This is the same in diagrams representing other syntaxes.
  • the field TypeindicsLtor has a 32-bit data length and indicates that this file is an index table.
  • Field TypeIndicator2 has a data length of 32 bits and indicates the purge of this file “index, bdmv”.
  • the field IndexesStart Address has a data length of 32 bits and is in this syntax.
  • Plock Shows the starting address of blklndexesO.
  • the field ExtensionDataStartAddress has a length of 32 pits and indicates the start address of the block blkExtensionDataO in this syntax.
  • the block blkExtensionDataO is a block for storing predetermined extension data.
  • the field ExtensionDataSartAddress indicates the start address of the block blkExtensionDataO in the relative number of bytes from the first byte of this file "index, bdmv”. The relative number of bytes starts from "0”. If the value of this field “ExtensionDataStartAddress” is “0”, it indicates that the block “blkExtensionDataO” does not exist in this file “index, bdmv”.
  • Block MkAppInfoBD MV0 is a block that allows content creators to write arbitrary information, and does not affect the operation of the player.
  • Block blklndexes 0 is the actual contents of this file "index, bdmv", and the first play that is played when the disk is loaded into the player according to the contents described in this file "index, bdmv"
  • the title (movie object) called from the back or top menu is specified.
  • a playlist file described later is read.
  • FIG. 7 shows a syntax representing an example of the structure of the block blklndexesO.
  • the field Length has a data length of 32 bits. The length from immediately after this field to the end of this block blklndexes 0 Indicates evening. Subsequently, a block FirstPlaybackTitleO and a block MenuTitleO are arranged.
  • the block FirstPlaybackTitleO describes information related to objects used in the first playback.
  • a fixed value “ ⁇ ” is described following an area reserved having a data length of 1 bit. Further, a fixed value“ ⁇ is described via an area res erved having a data length of 1 bit.
  • a field Firs laybackTitleMobjlDRef having a 16-pit data length is arranged through an area reserved having a data length of 14 bits. This field F irstPIaybackTitleMobjlDRef indicates the ID of the movie object used in the first playback title.
  • the ID of the movie object is indicated by the value m obj-id that is used as a loop variable in the for loop statement of the movie object based on the syntax of the movie object described later with reference to FIGS. 8 and 9, for example.
  • the field FirstPlaybackTitleMobj IDRei stores the value mobj-id corresponding to the referenced movie object.
  • FirstPlaybackTitleMobjlDRef in the block FirstPybackTi Ue 0 in the block blklndexesO may point to the movie object of the top menu or the title.
  • Block MenuTitleO describes information about the object used in the top menu.
  • a fixed value “1” is described following an area reserved having a data length of 1 bit.
  • a fixed value “ ⁇ ” is described through an area reserved having a 1-bit data length of 3 bits.
  • an area having a data length of 14 bits is reserved.
  • a field MenuTitleMobjl DRef having a data length of 16 bits is arranged.
  • Field MenuTitleMobjIDRef indicates the ID of the movie object used in the menu title.
  • the next field NumberOfTitles of the block MenuTitleO has a data length of 16 bits and indicates the number of titles that can be selected and played by the user.
  • the block MovieTitle [title_id] 0 is described with the value title_id as an argument for the number of times indicated in this field NumberOfTiUes.
  • the block MovieTiUe [tiUe_id] () describes information for each title.
  • the value title—id is a numerical value from “0” to the value indicated by the field NumberOf Titles, and identifies the title.
  • a fixed value “ ⁇ ” is described through an area reserved having a data length of 1 pit, and the field MovieTitle is input through an area reserved having a data length of 46 bits.
  • MobjIDRef is described Field MovieTi UeMobj IDRef has a data length of 16 bits and indicates the ID of the movie object used in this title Field 32 MovieDeUeMobjIDRef Area reserved with evening length is arranged.
  • FIG. 8 shows a syntax representing an example of a structure of a file “MovieObject.bdmv” placed immediately under the directory “BDMV”.
  • the field TypeIndicator has a data length of 32 bits (4 bytes) and indicates that this file is the file “MovieObject.bdmv”.
  • a character string consisting of four characters encoded by the encoding method stipulated in ISO (International Organization for Standardization) 646 is described.
  • the field Typelndicator contains a 4-character string " ⁇ 0 ⁇ encoded in the format specified in IS 0646, indicating that this file is the file" MovieObject.bdmv ". Is done.
  • Field TypeIndicator2 has a data length of 32 bits (4 bytes) and indicates the version number of this file “MovieObject.bdmv”. In this file “MovieObiect.bdmv”, the field TypeIndicator2 must be a 4-character string “0100” encoded by the encoding method defined in IS 0646.
  • the field ExtensionDataStartAddress has a 32-bit data length and indicates the start address of the block b IkExtensionData () in this syntax.
  • the field ExtensionDataStartAddress is the relative number of bytes from the first byte of this file “MovieObject.bdmv” and indicates the start address of the block blkExtensionDataO. The relative number of bytes starts from "0”. If the value of this field ExtensionDataStartAddress is “0”, it indicates that there is no bookmark MkExtensionDataO in this file “MovieObject.bdmv”.
  • the field padding_word in the syntax shown in Fig. 8 has a data length of 16 bits, and is inserted in the for loop statement by the number of times indicated by the value N1 or N2 according to the syntax of this file "MovieObject.bdmv”. Is done.
  • the value N1 or the value N2 is “0” or any positive integer.
  • An arbitrary value can be used for the field padding_word.
  • an area reserved with a data length of 2 24 pits is arranged, and then the block MkMovieObjectsO which is the main body of this file “MovieObject.bdmv” is stored.
  • FIG. 9 shows a syntax representing an example structure of the block blkMovieObjectsO.
  • the field Length has a data length of 32 bits, and indicates the data length from immediately after this field Length to the end of this block blkMovieObjects 0. 3 Rese with 2 bit length
  • the field NumberOfMobjs is arranged via rved.
  • the field NumbeOfMobjs indicates the number of movie objects stored according to the immediately following for loop statement.
  • the value mobj—id used as the loop variable in the for loop statement uniquely identifies the movie object.
  • the value mobjjd starts with "0", and movie objects are defined by the order described in the for loop statement.
  • the block TerminallnfoO in the for loop statement is described with a fixed value “1”, followed by an area reserved having a data length of 15 bits.
  • a field NumberOfNavigation Commands [mobj_id] having a data length of 16 bits is arranged.
  • This field NumberOfNavigationComands [mobj_id] represents the number of navigation commands (NavigationCommand) included in the movie object MovieObject [mobj—id] 0 pointed to by the value mobj_id.
  • the following command loop with the value command—id as a loop variable describes the number of navigation commands for the number indicated in the field NumberOfNavigationCotranslation ands [mob and id]. That is, the value NavigationCommand [mobj—id] [command-id] f placed in this for-loop statement, the block indicated by the value mobj—id MovieObject [mobsid] 0, the value command_id Stores navigation commands NavigationCommand in the order indicated by.
  • Value command id is a value starting from 0, and the navigation command NavigationCommand is defined in the order described in this for loop statement.
  • FIG. 10 shows a syntax representing an example of the structure of the playlist file “xxxxx.mpls”.
  • Field Typelndicator has a data length of 32 bits (4 bytes) and indicates that this file is a playlist file.
  • Field TypeIndicator2 is 32 bits (4 bytes (G) indicates the purge length of this playlist file.
  • Field PlayListStartAddress has a data length of 32 bits and indicates the start address of block MkPlayListO in this syntax.
  • Field PlayListMarkStartAddress has a data length of 32 bits and indicates the start address of block blkPlayListMarkO in this syntax.
  • the field ExtensionDataStartAddress has a data length of 32 bits and indicates the start address of the block blkExtensionDataO in this syntax.
  • the field ExtensionDataStartAddress represents the start address of the block blkExtensionDataO and the relative number of peats from the first byte of the file "xxxxx.mpls". The relative number of bytes starts from "0”. If the value of this field ExtensionDataStart Address is "0", it indicates that the block blkExtensionDataO does not exist in this file "xxxxx.mpls”.
  • a block bl kAppInfoPlayList 0 is arranged through an area reserved having a data length of 160 bits.
  • Block MkAppInfoPlayList 0 describes information such as the type of play list described in the next block (MkPlayLis) and playback restrictions.
  • a block blkPlayListO describes a play list.
  • the block blkPlayListMarkO describes the point to be jumped by a chapter jump.
  • the block blkExten sionDa t a 0 is a block for making it possible to store a predetermined extension data.
  • FIG. 11 shows a syntax representing an example of the structure of the block blkPlayListO.
  • the field Length has a data length of 32 bits, and indicates the length of data from immediately after this field Length to the end of the block blkPlayList 0. 1 6 bits data length following field Length The reserved area is placed, followed by the field NumberOfPlayltems.
  • a field NumberOfPlayltems has a data length of 16 bits and indicates the number of play items included in this block blkPlayListO.
  • a field NumberOfSubPath indicates the number of subpaths included in this block MkPlayLis).
  • the block MkPlayltemO in which the play item is described is described as many times as indicated by the field NumberOfPlayltems.
  • the count based on the for loop statement is the identifier Playltem-id of the block blkPlayltemO.
  • the block MkSubPath 0 is described as many times as indicated by the field NumberOfSubPath.
  • the count based on the for loop statement is the identifier SubPath—id of the block blkSubPathO.
  • a sub-path can be held corresponding to a sub-play item with respect to a main path corresponding mainly to a play item to be played.
  • the sub-path is used for the purpose of specifying audio data for post-recording, or specifying a sub-video to be played back in synchronization with the clip specified by the play item when combining two images.
  • FIG. 12 shows a syntax representing an example of the structure of the block blkPlayltemO.
  • Field Length has a data length of 16 bits, and indicates the length of data from immediately after this field Length to the end of block blkPlayltemO.
  • the field ClipIniormationFileName has a data length of 40 bits (5 bytes) and indicates the file name of the clip information file referenced by this block blkPlayltemO. In this play item, the clip information file having the file name indicated by the field ClipInformationFileName is read.
  • F The field ClipCodecIdentifier has a data length of 32 pits (4 bytes) and indicates the code system of the clip AV stream used in the play item by this block blkPlayltemO.
  • a Field ConnectionCondition is arranged through reserved area with 2 bits of data length.
  • a field “Connect ionCondition” has a data length of 4 bits and indicates information on a connection state between clips.
  • “1”, "5" or “6” is used as the value of the field ConnectionCondition.
  • the field Conne cUonCondition value is “1”, indicating that the clip referenced from the play item and the clip referenced from the previous play item are not seamlessly connected, and the field ConnectionCondition value is “5” or “6” indicates that the clip referenced from the play item is seamlessly connected to the clip referenced from the previous play item.
  • seamless connection refers to performing playback control between clips so that the clip and the next clip are played back continuously at the frame timing.
  • the recording length of the audio data in the clip referenced by the play item is made longer than the recording length of the video display (see FIG. 13A).
  • the audio data can be faded out when the clips are connected.
  • the clip connection method whose field ConnectionCondition value is “5” is referred to as a first seamless connection.
  • the play item The audio data recording length is the same as the video data recording length in the clip referenced by the video (see Fig. 13B). This makes it possible to connect the clips seamlessly.
  • the value of the field ConnectionCondition is set to “6” when the clip is closed based on a reason other than the recording stop according to the user operation, for example, due to a system factor.
  • the clip connection method in which the value of the field Connection Condition is “6” is referred to as a second seamless connection.
  • the field RefToSTCID has a data length of 8 bits and indicates information related to the discontinuity of the system time base (STC).
  • Field IN Time and Field OUTTime each have a 32-bit data length and indicate the playback range of the main clip AV stream.
  • Field INTime indicates the start point (IN point)
  • field OUTTime indicates the end point (OUT point).
  • the block blkUOMaskTableO is a table in which user input acceptance restrictions are set.
  • the flag PlayltemRandoin AccessFlag with one pit delay specifies whether to allow random access to play items by this block blkPlayltemO.
  • field StillMode is arranged through area reserved having a data length of 7 bits.
  • the field StillMode has an 8-bit data length and indicates whether or not to display the last displayed video as a still image in the play item by the block blkPlayltemO. If the value of the field StillMode is "0x01" (binary), the still time is indicated by the field StillTime having a data length of 16 bits based on the if statement.
  • the block blkSTNTableO manages the attributes of the clip AV stream, the PID number, the recording position on the recording medium, etc. managed by the play item of this block MkPlayltemO.
  • FIG. 14 shows a syntax representing an example of the structure of the block blkPlayListMarkO.
  • the field Length has a data length of 32 bits, and indicates the data length from immediately after this field Length to the end of the block blkPlayUstMarkO.
  • Field NumberOfPlayListMarks has a data length of 16 bits and indicates the number of playlist marks included in this block blkPlayUstMarkO. According to the following for loop statement, the number of playlist mark information described in the field NumberOfPlayListMarks is described.
  • the field MarkType is placed following the area reserve having an 8-bit data length.
  • the field MarkType has an 8-bit data length and indicates the mark type.
  • the field NumberOiPlayListMarks mentioned above indicates the total value of entry marks and link points.
  • Field ReiToPyltemlD has a data length of 16 bits and describes identification information P 1 ay 11 em—id that refers to a play item to be marked.
  • Field MarkTimeSta Immediately, it has a data length of 32 pits, and a time stamp indicating the point at which the mark is placed is described.
  • 2007/060081 Field EntryESPID has a data length of 16 bits and indicates the value of the PID of the TS bucket that contains the elementary stream pointed to by the mark.
  • the field Duration is an unsigned integer with a data length of 32 bits, measured in units of 45 kHz clocks. If the value stored in this field Duration is "0", this field Duration has no meaning.
  • Fig. 15 shows the syntax representing the structure of an example of a clip information file.
  • Field Typelndicator has a data length of 32 bits (4 bytes) and indicates that this file is a clip information file.
  • Field TypeIndicator2 has a data length of 32 bits (4 bytes) and indicates the version of this clip information file.
  • This clip information file has a block blkClipInfo (), a block blkSequenceInfo (), a block MkProgramlnfo 0, a block blkCPI (), a block blkClipMarkO, and a block blkExtensionDataO, each of which has a 32-bit length.
  • Seq uencelnfoStartAddress, field ProgramInfoSta Address, field CPIStartAddress, field CI ipMarkStartAddress, and field ExtensionDataStartAddress indicate the start address of the corresponding block.
  • the field ExtensionDataStartAddress is the relative number of bytes from the first byte of this clip information file and indicates the start address of the block blkExtensionDataO. The relative number of bytes starts from "0". If the value of this field ExtensionDataStartAddress is "0", it indicates that the block blkExtensionDataO does not exist in this file "index, bdmv”.
  • the block MkClipInfoO starts after the area reserved having a data length of 96 bits following the field indicating these start addresses.
  • the block blkClipInfoO describes information related to the clip AV stream managed by this clip information file.
  • the block kSequencelnfoO describes information that manages a sequence of consecutive STC ATC (Alipal Time Base) as a group.
  • the block blk rogramlnfoO describes information such as the encoding method of the clip AV stream managed in the clip information file and the aspect ratio of the video data in the clip AV stream.
  • the block MkCPlO stores information on feature point information CPI that represents a characteristic location in the AV stream, such as a random access start point.
  • the block blkClipMarkO describes the index point (jump point) for cueing attached to the clip, such as the chapter position.
  • the block blkExtensionDataO is an area where extension data can be stored. Note that the block b 1 kC 1 ipMar k () and the block b 1 kSequeN Inf 00 in the clip information file are not related to this invention, and thus detailed description thereof is omitted.
  • FIG. 16 shows a block representing the structure of an example of a block! LkClipInfoO.
  • the field Length has a data length of 32 bits, and indicates the data length from immediately after this field Length to the end of the block MkClipInioO.
  • the field ClipStreamType is arranged through a reserved area with a data length of 16 pits.
  • Field ClipStreamType has an 8-bit data length and indicates the type of clip AV stream.
  • the value of this field ClipStreamType is fixed to eg "1".
  • the field ApplicationType is Indicates the multiplexing method of the clip AV stream (file with the extension “m2 tsj”) that has a data length of 8 bits. Normal video is played back in the stream, followed by an area reserved with a data length of 31 bits.
  • the flag IsCC5 with a data length of 1 bit indicates that the connection between the corresponding clip and the next clip is made by the block blkPlayltefflO in the playlist, the first seamless connection described above, that is, the value of the field Comiec UonCondition is "5" Whether or not to perform by the method shown in. If the value of the flag IsCC5 is "1" (binary value), it indicates that the connection between clips is made by the first seamless connection.
  • the field 31 ⁇ (; 0 ⁇ 11 ⁇ 1 ⁇ ⁇ 6 is the recording rate of the clip AV stream file in bytes per second.
  • the field NumberOf SourcePackets is the source packet included in the clip AV stream.
  • the block TSTypelnioBlockO is arranged through an area reserved having a data length of 1024 bits ⁇
  • Block TSTypelnfoBlock 0 stores information indicating the type of packet in which the clip AV stream is stored. Since the connection with this invention is thin, detailed description is omitted.
  • the field FollowingClipStreamType is allocated via the reserved area with the next 8-bit data length of the if statement.
  • the field FollowingClipStreamType has a data length of 8 bits, and describes the type of the clip next to the clip corresponding to this clip information file.
  • a field FollowingClipInformationFileName is arranged.
  • the field FoHowingClipInformaiionFileName has a data length of 40 bits (5 bytes) and describes the file name of the clip information file corresponding to the clip next to the clip corresponding to this clip information file.
  • the next field, ClipCodedentifier has a data length of 32 bits (4 bytes) and indicates the encoding method of the next clip. In this example, the field ClipCode cldentifier is fixed to the 4-character string value “M2TS” encoded in the manner specified in IS 0646. Next, an area reserved having an 8-bit data length is allocated.
  • FIG. 17 shows a syntax that represents an example of the structure of the block blkProgramlnfoO.
  • the field Length has a data length of 32 bits and indicates the data length from immediately after this field Length to the end of the block blkProgramlnfo 0. 1
  • a fixed value “1” is described with a data length of 1 bit via an area reserved having a data length of 5 bits.
  • the field SPNProgramSeQuenceStart has a data length of 32 bits and describes the source bucket number at which the program sequence starts in the corresponding clip AV stream file.
  • the field ProgramMapPID indicates the value of the PID of the TS packet that has a 16-bit data length and is supposed to contain a program map section applicable to the program sequence.
  • the field NumberOfStreamsInPS has an 8-bit data length and indicates the number of elementary lists defined in the program sequence. Following the field NimberOfStream slnPS, an area reserved having a data length of 8 bits is arranged.
  • the value [stream_index] is set as the loop variable, and the number indicated in the field NumberOfS eamsInPS is the field Strea.
  • a set of mP ID [stream one index] and block MkStreamCodinglnfo (stream one index) is stored.
  • Field StreamPID [stream_iii (3ex] indicates the value of PID corresponding to the elementary stream described in the PMT (Program Map Table) referenced by the program sequence.
  • the next block blkStreamCodingInfo (stream_inde ⁇ ⁇ > is This field describes information about the encoding method of the elementary stream indicated by StreamPID [stream_index].
  • FIG. 18 shows syntax that represents an example of the structure of the block blkSireamCodingInfo (sireani_index).
  • the field Length has an 8-bit data length and indicates the data length from immediately after this field Length to the end of the block blkStreamCordingInfo (stream_index).
  • the field StreamCodingType indicates the type of encoding of the elementary stream indicated by the value [streamjndex].
  • the value "Ox IB”, the value “0x80”, the value “0x81”, the value “0x90” and the value "0x91” are defined as the value of the field StreamCodingType, and the encoding type of the stream is the value "OxlB"
  • a video stream, a value “0x80” or a value “0x81” indicates an audio stream, a value “0x90” indicates an OB stream, and a value “0x91” indicates an MB stream. According to the following if statement, the description according to the value of this field StreamCodingType is made.
  • the field VideoFormat is "OxlB" and the elementary stream indicated by the value [str eam-index] is a video stream
  • the field VideoFormat, the field FrameRate, and the field according to the if statement AspectRatio is described, and flag CCFIag is further described through an area reserved having a 2-bit data length. It is. After the flag CCFlag, an area re served having a data length of 17 bits and an area reserved having a data length of 128 bits are arranged.
  • _index] indicates the format of the video data.
  • FIG. 19 shows a list of formats of an example of video data indicated by the field VideoFormat. As illustrated in Fig.
  • the format of video data is identified by the value “0 '" to value “1 5" that can be expressed by 4 bits, and the value “0" and the value “8”” ⁇ Value” 1 5 "is reserved.
  • Values “1” to “7” indicate video data formats of 480 i, 576 i, 480 p, 1 080 i, 720 p, 1 080 p, and 576 p, respectively.
  • “i” and “p” at the end indicate in-race scanning and progressive scanning, respectively.
  • the numbers indicate the number of lines.
  • These video formats are I TU (International Telecommunication Union; —R BT.60 1—4 (480 i and 576 i), I TU—RB T. 1 358 (576 p), SMPTE (Society of Motion Picture and Televisio n Engineers) Formats standardized by 293 M (48 Op), SMPTE 274M (10 80 i and 1 080 p) and SMPTE 296M (720 p).
  • the field FrameRate has a data length of 4 bits and indicates the frame rate of the video data indicated by the value [streamjndex].
  • FIG. 20 shows a list of frame rates of an example indicated by the field FrameRate. As illustrated in Fig. 20, the frame rate of video data is 4 bits. The values “0” to “1 5” that can be represented by “0”, “0”, “5”, and “8” to “1 5” are reserved.
  • the frame rate (field frequency) is (24000/1 00 1) Hz, ie approximately 23.97 Hz, 24 Hz, 25 Hz, and (3000 0/1 00 1) Hz, ie approximately Indicates 29.97 Hz.
  • the value 6 and the value 7 indicate that the frame rate is 50 Hz and (60000/100 1) Hz, ie approximately 59.94 Hz, respectively.
  • the field AspectRatio has a data length of 4 bits and indicates the aspect ratio of the video data indicated by the value [stream one index].
  • Figure 21 shows a list of example frame rates indicated by the field AspectRatio. As illustrated in Fig. 21, the aspect ratio of video data is identified by the value "0" to the value "15" that can be expressed by 4 bits, the value "0" and the value "1", In addition, values "4" to "1 5" are reserved.
  • a value of 2 indicates an aspect ratio of 4: 3.
  • a value of “3” indicates an aspect ratio of 16: 9.
  • FIG. 22 shows a syntax representing an example structure of the block blkCPlO in the clip information file.
  • decoding can be started only at certain locations such as the beginning of GO P (Group Of Picture).
  • CP I Chargeristic Point Information
  • CP I is a database that collects information on the position of the start point that can be decoded, and is a table that associates playback times with addresses in files. That is, the CP I is a table of information indicating the start position of the decoding unit.
  • the file address of the playback position can be determined by referring to the CP I based on the playback time. Since this address is the head of the decoding unit, the player can read and decode the data from it and display the image quickly.
  • the starting position of the decoding unit (in this example, the starting position of the GOP) stored in the CP I is called an E P (Entry Point) entry.
  • E P Entry Point
  • field Length has a data length of 32 bits, and indicates the data length from immediately after this field Length to the end of block blkCP10.
  • the field CPIType is allocated via the area reserved having a data length of 12 bits.
  • Field CPIType has a data length of 4 bits and indicates the type of CPI.
  • the next block blkEPMapO stores a table for associating the PTS value and the pate address in the corresponding clip AV stream file.
  • FIG. 23 shows syntax that represents an example of the structure of the block blkEPMapO.
  • a field NumberOfStreamPIDEntries is arranged through an area reserved having an 8-bit data length.
  • the field HNumberOfStreamPI DEntries has a length of 8 pits and indicates the number of entries in the block blkEPMapForOneStream D in the block blkEPMapO.
  • the value [k] is used as a loop variable, and the information about the endpoint is described by the number indicated in the field NumberOfStreamPID Entries. It is.
  • the field StreamPID [k] has a data length of 16 bits, and is the block MkEPMapForOneStreamnD (hereinafter referred to as the [k] -th block bl kEPMapForOneStreamPID) in the block blkEPMapO. Describes the PID value of the transport packet carrying the elementary stream referenced by
  • a field EP StreamType [k] is arranged through an area reserved having a 10-bit data length.
  • Field EPStreamType [k] has a data length of 4 bits and indicates the type of elementary stream referenced by the [k] -th block MkEPMapForOneStreamPID.
  • Field NumberOfEPCoarseEntries [k] has a data length of 16 bits and indicates the number of entries in the coarse search sub table (EP coarse table) in the [k] -th block MkEPMapForOneStreamPID.
  • Field Numbe rOfEPFineEntries [k] has a data length of 18 bits and indicates the number of entries in the fine table sub table (EP fine table) in the [k] -th block MkEPMapForOneStreamPID. .
  • the field EPMapForOneStreamPIDStartAddress [k] has a data length of 32 bits, and indicates the relative byte position at which the [k] -th block b IkEPMapForOneStreamP ID starts in the block blkEPMap 0. This value is indicated by the number of bytes from the first pipe of the block blkEPMapO.
  • the argument NumberOfEPFineEntries [k] indicates the number of entries PTSEPFine and entry SPNEPFine stored in the sub table (EP fine table).
  • the argument NumberOfEPCoarseEntries [k] and the argument NumberOfEPFineEntries [k] are called the entry number Nc and the entry number Nf, respectively, as appropriate.
  • FIG. 24 shows syntax that represents an example of the structure of a block blkEPMapForOneStreamPID (EP-stream-type, Nc, Nf). To explain the semantics of the block MkEPMapForOneStreamPID (EP_stream_type, Nc, Nf) Will be described.
  • the entry PTSEPStart and the entry SPNEPStart associated with the entry PTSEPStart indicate entry points on the AV stream.
  • the entry PTSEPFine and the entry PTSEPCoarse associated with the entry PTSEPFine are derived from the same entry PTSEPStart.
  • the entry SMEPFine and the entry SPNEPCoarse associated with the entry SPNEPFine are derived from the same entry SPNEPStart.
  • Figure 25 shows an example format for the entry PTSEPCoarse and entry PTSEPFine.
  • PTS ie, entry PTSEPStart
  • the entry PTSEPCoarse used when searching in rough units is the 3rd bit of the entry PTSEPStart.
  • a kite is used. With the entry PTSEPCoarse, it is possible to search within a resolution of 5.8 seconds and up to 26.5 hours.
  • PTSEPFine uses 11 bits from the 9th bit to the 9th bit of the entry PTSEPStart for the more precise search: PTSEPFine.
  • the resolution is 5.7 milliseconds and searches can be made in the range up to 11.5 seconds.
  • the 19th bit is used in common by entry PTSEPCoarse and entry PTSEPFine.
  • the 9 bits from the 0th bit to the 8th bit on the LSB side are not used.
  • Figure 26 shows an example format of entry SMEPCoarse and entry SPNEPFine.
  • the source packet number that is, the entry SPNEPStart
  • the source packet number has a data length of 32 bits.
  • the MS B pit is the 31st bit and the LSB bit is the 0th bit, in the example in Fig. 26, the entry SPNE PCoarse used when searching in rough units is the entry of the entry SPNEPStart. 3 All bits from bit 1 to bit 0 are used.
  • the entry SPNEPFine for more precise search uses the 17th bit from the 1st 6th bit to the 0th bit of the entry SPNEPStart. With the entry SPNEPFine, it is possible to search within a range up to approximately 25 MB (Mega Byte) AV stream file.
  • the entry SPNCTCoarse uses 17 bits from the 3rd 1st bit to the 16th bit of the entry SPNEPStart, and the entry SPNEPFine uses 17 bits from the 1st 6th bit to the 0th pit of the entry SPNEPStart.
  • ENTRY PTSEPStart and ENTRY SPNEPSiari are It is defined as follows:
  • the entry PTSEPStart is an unsigned integer with a data length of 33 bits and can be randomly accessed in an AV stream (for example, an IDR (Instantaneous Decoding Refres h) picture or I Indicates a 33-bit PTS of a video access unit starting from (Intra) picture.
  • an IDR Intelligent Decoding Refres h
  • I Indicates a 33-bit PTS of a video access unit starting from (Intra) picture.
  • the entry SPNEPStarU is a 32-bit unsigned integer in the AV stream of the source bucket that contains the first byte of the video successor associated with the entry PTSEPS tart. Indicates the address.
  • the entry SPNEPStart is expressed in units of source packet numbers, and is counted from the first source packet in the AV stream file as a value incremented by 1 for each source packet, with the value “0” as the initial value.
  • the block blkEPMapForOneStreamPID (EP—stream—type, Nc, Nf) describes the sub table (EP coarse table) for searching in rough units by the first for loop statement.
  • the second for loop statement describes a sub table (EP fine table) for performing a more detailed search based on the search result of the sub table (EP coarse table).
  • the field EPFineTableStartAddress is placed immediately before the first ior loop statement.
  • the field EPFineTableSta Address has a data length of 32 bits, and the start address of the first byte of the field Reserve dEPFine [EP_fine_id] in the first second for loop is the first address of the block blk EPMapForOneStreamPID (EP_stream_type, Nc, ⁇ ) It is indicated by the relative number of bytes from the first byte. The relative number of bytes starts with the value "0".
  • the first for loop statement uses the loop variable [i] and the subtable (EP co The number of entries in the arse table) is repeated up to Nc, and fields RefToEPFineID [i], entry PTSEPCoarse [i], and entry SPNEPCoarse [i] are stored for the number of entries Nc.
  • the field RefToEPFineID [i] has a data length of 18 bits and the entry PTSEPCoarse associated with the entry PTSEPCoarse indicated by the field PTSEPCoarse [i] following the field RefToEPFineID [i]. Indicates the entry number in the sub table (EP fine table).
  • the entry PTSEPFine and the entry PTSEPCoarse associated with this entry PTSEPFine are derived from the same entry PTSEPStart.
  • the field RefToEPFinel D [i] is given by the value of the loop variable [EP—fine_id] defined in the order described in the second for loop statement.
  • the second for loop statement is described with a padding word in between.
  • the second for loop statement is repeated up to the number of entries Nf in the subtable (EP fine table) with the loop variable [EP — fine_id], and has a data length of 1 bit for the number of entries Nf.
  • 1 field ReservedEPFineCEPJine—id] 3 bits data length field IEndPositionOffset [EP—fine_id], 1 1 pit field field—PTSEPFine [EP—fine_id], 17 bits data length
  • a field SPNEPFine [EP_fine_id] having “” is stored.
  • the field PTSEPFine [EPJine—id] and the field SPNEPF ine [EP—fine_id] are entries SEPFine and EP that are referenced from the sub table (EP fine table) based on the loop variable [EP— ⁇ i ne_id]. Each entry SPNEPF ine is stored.
  • Entry PTSEPCoarse and entry PTSEPFine, and entry SPNEPCoarse and entry SPNEPFine are derived as follows.
  • the associated SPNEPStart value increases Suppose that there are Nf entries in order.
  • Each entry PT SEPFine is derived from the corresponding entry PTSEPStart as shown in the following equation (1).
  • PTSEPFine [EP_fine_id] (PTSEPStart [EP_fine_id] »9) / 2 n --(1)
  • PTSEPCoarse [i] (PTSEPStart [RefToEPFineID [i]] ⁇ 1 9) / 2 14 • ⁇ (2)
  • PTSEPFine [RefToEPFineID [i]] (PTSEPStart [RefToEPFineID [i]] »9) / 2 11 ⁇ ⁇ (3)
  • Each entry SPNEPFine is derived from the corresponding entry SPNEPStart as shown in the following equation (4).
  • SPNEPCoarse [i] SPNEPStart [RefToEPFinelDLi]] ⁇ ⁇ (5)
  • This block MkExtensionDaUO for storing the extension data will be explained.
  • This block blkExtensionDataO is defined so as to be able to store a predetermined extension data, and an index table is stored.
  • Bdmv The file “xxxxx.mpls” where the playlist is stored and the clip information file “ZZZZZ, clpi” can be described.
  • FIG. 27 shows a syntax that represents an example of the structure of the block blkExtensionDataO.
  • the field Length has a data length of 32 bits, and indicates the data length in bytes from immediately after this field Length to the end of the block blkExtensionDataO. If the length indicated by this field Length is not "0", the description following the if statement is made.
  • the field DataBlockStartAddress has a length of 32 bits, and the start address of the block DataBlockO in which the main body of the extension data is stored in this syntax is the relative number of bytes from the first byte of this block MkExtensionDataO. Show. That is, the relative number of bytes starts from "0".
  • a field NumberOfExtDataEntries is arranged through an area reserved having a data length of 24 bits.
  • Field NumberOfExtDa Entries has a data length of 8 bits and indicates the number of entries of extension data stored in block DataBlockO of this block MkExtensionDataO.
  • the extension data entry stores information for acquiring the main body of the extension data.
  • the extension data entry is a block ext_data—entr y () consisting of the field ExDataType, the field ExtDataVersion, the field ExtDataStartAdd ress, and the field ExtDataLength.
  • the field ExtDataType has a data length of 16 bits, and indicates that the extended data described in the block b IkExtensionData0 is extended data for the recording apparatus.
  • the value of this field ExtDataType is the first value that identifies the extension data, and can be defined to be assigned by the licensor of the standard that includes this block blkExtensionData 0.
  • the field ExtDataVersion is a second value that identifies extension data, and can be defined to represent the version number of this extension data. In this block MkExtensionDataO, the value of field ExtDataType and field ExtDataVersion must be ex.
  • the field ExtDataStartAddress has a data length of 32 bits, and indicates the start address of the extended data corresponding to the extended data entry (block ex_data_entry ()) including this field ExtDataStartAddress.
  • the field ExtDataStartAddress is the relative number of bytes from the first byte of the block blkExtensionDataO and indicates the start address of the extension data ext_data.
  • the field ExtDataLength has a data length of 32 bits, and indicates the data length of the extended data corresponding to the extended data entry (block ext—data_entriesO) including this field ExtDataStartAddress.
  • the data length is indicated in bytes.
  • each field has a 6-bit data length and consists of an arbitrary data field. — The word is repeated as many times L1 as 2 fields.
  • the block DataBlockO stores one or more extended data. Each extension data ex and data is extracted from the block DataBlock () based on the above-described field ExtDataStartAddress field ExtDataLength.
  • Fig. 28 schematically shows the reference relationship of each data in block MkExtensionDataO.
  • the field Length indicates the data length from the position immediately after the field Length to the end of the block blkExtensionDataO.
  • the field DataBlockStartAddress indicates the start position of the block]) a Block ().
  • the extended data ext_da indicated by the block ex and data_entry () is placed.
  • the position and data length of each extension data ex and data are indicated by the field ExtDataStartAddress and the field ExtDataLength in the corresponding block ext-data one entryO. Therefore, the arrangement order of the extension data ext_data in the block DataBlockO does not have to match the arrangement order of the corresponding block ex t_data_entry ().
  • Figure 29 shows the block MkExtensionDataO It is a flowchart which shows an example process at the time of writing. Fig. 29 shows an example of rewriting block blkExtensionDataO by adding extension data as the (n + 1) th entry in block blkExtensionDataO.
  • step S10 the data length of the extended data to be written is obtained and set to the value of the field ExtDataLength [n + l].
  • the description of “[n + l]” corresponds to the number of the (n + 1) th entry.
  • step S I 1 the values of the field ExtDataLengt h and the field ExtDataStartAddress of the block ex_data_entry () enumerated in the current block blkExtensionDataO are examined, and the usage status of the block DataBlockO is obtained.
  • step S 1 2 a continuous free area having a length equal to or longer than the data length indicated in the field ExtDataLength [n + l] which is the data length of the extended data to be written is included in the block DataBlockO. It is judged whether or not there is. If it is determined that there is, the process proceeds to step S14.
  • step S 1 3 the process proceeds to step S 1 3 to increase the value of the field Length in the block blkExtensionDataO. Then, a continuous empty area that is longer than the data length indicated in the field ExtDataLength [n + l] is created in the block DataBlockO. When free space is created, the process proceeds to step S14.
  • step S14 the start address of the area in which the extension data is written is determined, and the value of the start address is set to the field ExtDataStartAddress [n + 1].
  • step S 1 5 from the field ExtDataStartAddress [n + 1], the field ExtDataLen set in step S 1 0 above Write extension data ext_data [nH] of length gth [nH].
  • step S 16 When the data writing is completed, in step S 16, the field “ExtDataLength [n + 1]” and the field “ExtDataStar address [n + l]” are added to the block ex and data_entry ().
  • step S 13 the expansion of the block MkExtensionDataO by changing the value of the field Length is left to the system, and the system performs memory allocation appropriately.
  • FIG. 30 is a flowchart showing an example of processing when reading extension data from the block MkExtensionDataO.
  • the processing according to the flowchart of FIG. 30 can be applied to both a reproduction-only recording medium and a recordable recording medium.
  • the value of the field ExtDataType is obtained from the standard to which the extended data to be read complies
  • the field ExtDataVersion is set from the type of the extended data to be read. Get the value.
  • the blocks ext_data—entryO listed in the block blkExtensionDataO are read one by one.
  • step S 2 3 the values of the field ExtDataType and field ExtDataVersion included in the read block ext_data—entn () are the field ExiD ataType and field obtained in step S 20 and step S 21 above. It is determined whether it matches the value of ExtDataVersion.
  • step S 26 the block ext data ent listed in the block blkExtensionDataO It is determined whether or not all of ry () has been read. If it is determined that all of the data has been read, the process proceeds to step S 27, and a series of processes are terminated assuming that there is no extension data to be read in this block MkExtensionDataO. If it is determined that all have not been read, the process returns to step S 22 and the next block ext-data-entryO is read.
  • step S 23 If it is determined in step S 23 described above that the values of the field ExtDataType and the field ExtDataVersion included in the entry O of the block ext_data match the values of the acquired field ExtDataType and field ExtDataVersion, the process proceeds to step S 24. It is moved to. Here, it is assumed that the [i] -th entry in the block blkExtensionDataO matches.
  • step S 24 the value of the field ExtDataLength i] and the value of the field ExtDataStar tAddress [i] are read from the block ext—data—entr y () of the [i] th entry.
  • step S 25 data is read from the address indicated by field ExtDataStartAddressCi] read in step S 24 by the data length indicated by field ExtDataLength [i].
  • index file “index.bdmv”, movie object file “MovieObject.bdmV ', playlist file“ xx.mpls ”, and clip file“ zzzzz.clpi ” can be defined.
  • the extension data block blkE xtensionDataO for storing data will be described.
  • FIG. 31 shows the syntax for describing the structure of an example of the block DataBlockO (see Fig. 27) in the field MkExtensionDataO in the file "index, bdmv” to describe this playlist attribute.
  • the block DataBlockO is described as block blklndexExtensionData 0.
  • the field ExtDataType is set to the value “0x1000”, and the field ExtDataVersion is set to the value “0x0100”.
  • the values described in the field ExtDataType and the field ExtDataVersion are identified by referring to a table stored in advance in a ROM (Read Only Memory) or the like, for example, on the playback device side.
  • the block blk IndexExtensionData0 is stored in the area indicated by the field ExtDataStartAdd ress and the field ExtDataLength in the block DataBlockO.
  • the field Typelndicator describes a character string consisting of four characters encoded by the encoding method stipulated in ISO 646, indicating the type of data that follows.
  • the field Typelndicator describes the 4-character string '' IDEX 'encoded in the format specified in IS ⁇ 646, and the subsequent data type is the extended data in the index file. Is shown.
  • an area reserved having a 32-bit data length is arranged, followed by a field TableOiayListStar address which has a 32-bit data length.
  • the field Table OfPlayListStartAddress is the start address of the block blkTableOfPlayList 0 based on the start of this block blklndexExtensionDa O. Indicated.
  • padding word padding_TOrd having a data length of 16 bits is repeated as many times as indicated by value N2, and then block MkMakersPrivateDataO is arranged. After this block blkMakersPrivateDataO, the padding word padding-word having a data length of 16 bits is repeated as many times as indicated by the value N3.
  • block blkUIAppInfoAVCHDO and the block blkMakersPrivateDataO are not related to the present invention, so the description is omitted.
  • FIG. 32 shows a syntax representing a structure example of the block MkTableOfPlayListsO described above.
  • the field Length has a data length of 32 bits, and indicates the data length in bytes from immediately after this field Length to the last byte of the block blkTableOfPlayListsO.
  • a block b 1 kF irs tP 1 aybackTitlePlaysListsO in which information about the playlist for playing the play pack title is described, and a block bl kMenuTitlePlayListsO in which information about the menu title is described are arranged.
  • Block blkFirstPlaybuckTitlePlayListsO and block blkMenuTitlePlayLisisO are not related to this invention, so the description is omitted.
  • a field NumberOfTiUePlayListPair having a data length of 16 bits is arranged.
  • a field NumberOfTitlePlayListPair describes the number of playlists for playing titles other than the playback title and menu title. According to the following for loop statement, the block b IkMovieTitlePlayListPair 0 is described in the number indicated by the field NumberOfTitlePlayLis air.
  • the block blkMovieTi UeP layListPairO includes a field PlayListFileName, a field PlayListAttribute, and a field RefToTitleld. That is, the block blkMovieTitlePlayListPairO is the playlist that consists of the file name of the playlist, the attribute assigned to the playlist, and the reference title ID of the playlist for the second playlist indicated by this for loop statement. This information is structured.
  • the order of the for loop statements is the recording order. That is, when 1 playlist is added, the value of the field NumberOfTiUePlayListPair is incremented by “1”, and the information of the added playlist is added after the information of the existing playlist.
  • the field PlayListFileName has a data length of 40 bits (5 bytes), and the play list file name is encoded and described by the encoding method defined in ISO 646.
  • a field PlayListAUribute is arranged through an area reserved having a data length of 6 bits.
  • a field PlayListAttribute has a data length of 2 bits and indicates an attribute assigned to the play list. Based on its origin, the playlist ⁇ ⁇ corresponds to the first type corresponding to the playlist generated when the clip is generated and the playlist created using part or all of the existing title or playlist ⁇ ⁇ ⁇ .
  • Each playlist has a corresponding attribute “Realj (first type)”, attribute “Virtua U (second type), and attribute“ Menu ”according to the type of playlist. (Third type) is assigned.
  • a playlist with the attribute “Real” is assigned as a real playlist
  • a playlist with the attribute “Virtual” is assigned as a partial playlist
  • an attribute A playlist with “Menu” attached is called a menu playlist.
  • the field RefToTitleld describes the ID (number) of the title to which the playlist shown in the field PlayListFileName in the same loop belongs when it is created.
  • the corresponding value title-id in the block blklndexes () in the index file "index.bdmv" is described.
  • the value of the field RefToTitleld is a first fixed value, for example, “OxFFFF”.
  • the value of the field RefToTitle Id is a second fixed value, for example, “OxFFFE”.
  • a real playlist with the attribute “Real” is generated when a clip is generated and recorded on a disc.
  • Real Playlist ⁇ is also called the original playlist because it is the first playlist that points to the material.
  • the real playlist specifies the beginning of the generated clip as the IN point and the end as the OUT point.
  • a real playlist is a playlist that refers to a clip that is a stream entity, and is created when a new clip is created.
  • a real playlist that refers to the clip is always created. In other words, there are no clips on the disc that are not referenced by any real playlist. Therefore, the total playback time of the real playlist on the disc matches the total playback time of the clips recorded on the disc. In other words, the remaining recordable time on the disc is the same as the recordable time of a title composed of a real play list or only a real play list when viewed from the user. ⁇
  • a real playlist always has a one-to-one correspondence with the material clip.
  • the corresponding clip is also deleted from the disc.
  • a part of the reference section of a clip is deleted in the real playlist
  • a part of the clip corresponding to the real playlist is also deleted according to the deleted part.
  • editing for a real playlist is called editing or real editing because it involves editing the substance of the clip recorded on the disk.
  • a virtual playlist with the attribute “Virtual” is a playlist created using part or all of an existing title or playlist.
  • a partial playlist is a playlist created by setting an I N point and an O U T point for an existing clip and referring to a section defined by the I N point and the O U T point.
  • a partial playlist specifies the IN and OUT points for the above-mentioned real playlist. For example, for multiple real playlists, specify the IN and OUT points, respectively, and specify the playback order of multiple sections specified by the IN and OUT points, respectively. Based on the partial playlist, You can also create a playlist. That is, it is possible to create a partial playlist that specifies the IN point and OUT point for one or more partial playlists.
  • a partial playlist can be created at high speed without changing, for example, a large clip (stream entity) during editing.
  • a large clip stream entity
  • the editing of the virtual playlist is an editing that does not involve alteration of the clip body, and is therefore referred to as virtual editing or virtual editing.
  • Menu playlists with the attribute “Menu” are playlists used to play back menus, and are created when menus are created and updated.
  • the menu playlist is a playlist called from the movie object for playing the menu title.
  • FIG. 33 shows syntax that represents an example of the structure of a block DataBlockO (see FIG. 27) in the block blkExtensionDataO in the playlist file “xxxxx.mpls”.
  • the block DataMockO is described as the block blk MayListExtensionDataO.
  • the field ExiDaiaType and the field ExtDataVersion each have a predetermined value, for example, the value “0x1000” as described above.
  • the value is “0x0100”.
  • a field PlayListMarkExtStartAddress having a data length of 32 bits is arranged via an area reserved having a data length of 32 bits (4 bytes), followed by a data length of 32 bits.
  • Field MakersPrivateDataStartAddress is placed.
  • the field PlayListMarkExtStartAddress and the field MakersPrivateDataStartAddress indicate the start address of the block blkPlay ListMarkExt () and the block blkMakersPrivateDataO relative to the head of this block MkPlayListExtensionDataO, respectively.
  • a block blkPlayListMeta () is arranged via an area reserved having a 192-bit data length. 1 A padding word having a data length of 6 bits is repeated as many times as indicated by the value N1, and then a block blkPrayListMarkExtO is arranged. Further, the padding_word padding_word having a data length of 16 pits is repeated as many times as indicated by the value N2, and then the block MMakersPrivateDataO is arranged. Following the block bl kMakersPrivateDataO, a padding grid with a data length of 16 bits padd i ng—word is repeated as many times as indicated by the value N3. FIG.
  • Field Length has a data length of 32 bits, Indicates the data length from immediately after this field Length to the end of this block 1) 11 ⁇ 1 & 1 ⁇ 3 (3 ⁇ 416 ⁇ & ().
  • a field Maker having a data length of 16 bits each.
  • the ID and field Maker ModelCode are arranged in the field MakerlD and field MakerMod elCode, respectively, which describes the manufacturer who updated this playlist file and the information identifying the model of the corresponding power.
  • a field ReiToMenuThumbnaillndex having a data length of 16 bits is arranged through an area reserved having a data length of 32 bits.
  • this field RefToMenu Thumbnail ndndex if there is a thumbnail image representing a series of clips reproduced by this playlist file, a thumbnail number for identifying the thumbnail image is described.
  • a block blkTiraeZoneO having an 8-bit data length is arranged, and when this playlist file is updated, information indicating the time zone set in the device is described.
  • a field “RecordTime AndDate” having a data length of 56 bits is arranged, and the time and date when this playlist file is updated are described.
  • field ayListCharacterSet and field PlayListNameLength each having 8-bit data length are arranged via area reserved having 8-bit data length, followed by 255-byte data length.
  • the field PlayListName that is provided is arranged.
  • the field PlayListCharacterSet, the field ayListNameLength, and the field PlayListName describe information related to the name assigned to the playlist indicated by the playlist file.
  • the field PlayUstCharacterSet Indicates the character set of the character string described in stName.
  • Field PlayListNameLength indicates the byte length of the playlist name described in field PlayListName.
  • the field PlayListName describes the name assigned to this playlist. In this field PlayListName, from the left, the number of bytes shown in the field PlayListNameLength is a valid character string, and this is the name of this playlist. In the field PlayListName, any value may be contained in the peat string after the valid character string indicated by the field PlayListNameLength.
  • This block Additiona and dataO is an area reserved for storing additional information, and an area having a data length corresponding to the number of bytes of the value indicated in the field Length2 having a data length of 32 bits. Reserved.
  • FIG. 35 shows a syntax representing an example of the structure of the block blkMakersPrivateDataAta 0 in the playlist file.
  • Block b 1 kMaker sPrivateDataO is a block in which information unique to the manufacturer is described for this playlist file.
  • the field Length has a 32-bit data length and indicates the data length from immediately after this field length to the end of this block blkMakersPrivateDataO. This field Length is the value "0", indicating that no information is described in this 3 ⁇ 4 ⁇ 1 ⁇ ? 1 " ⁇ & 160 & (). The field Length is other than the value" 0 ". A statement is made.
  • the field DataBlockStartAddress has a 32-bit data length, and the start address of the block DataBlockO that stores the manufacturer-specific information body in this syntax is set to this block blkMakersPrivateData ( 1
  • a field NberOfMakerEntries having a data length of 8 pits is arranged through an area reserved having a data length of 24 bits.
  • the extended data entries ie, the field MakerID, the field HMakerModelCode, the field MpdStartAddress, and the field MpdLength are described in the number indicated by the field NumberOfMakerEntries.
  • Field MakerlD and Field MakerModelCode each have a data length of 16 pits, and describe manufacturer identification information and model identification information by the manufacturer.
  • the field MpdStartAddress and the field MpdLength each have a data length of 32 bits.
  • the start address of the block DataBlockO in which the main body of the extension data is stored and the start address based on the relative number of peats from the first byte of this block blkExtensionDataO and the data Indicates the length.
  • each field padding one word having a data length of 16 bits and consisting of an arbitrary data group consists of two fields. Repeated any number of times L1.
  • the block DataBIockO stores one or more extension data ext—data.
  • extension data unique to each device is stored in the block DataBlockO.
  • Each extension data is extracted from the block DataBlockO based on the field MpdStartAddress and the field MpdLength described above.
  • the block MkPlayListMarkExt () in the extension data block blkPlayL istExtensionDataO in the playlist file is the present invention. The explanation is omitted because it is not relevant.
  • FIG. 36 shows a syntax representing an example of the structure of the block DataBlockO (see FIG. 27) in the block blkExtensionData () in the clip information file.
  • the block DataBlock () is described as the block blkClipExtensionDataO.
  • the field Typelndica tor describes a predetermined character string consisting of four characters encoded by the encoding method stipulated in IS0646, indicating the type of data that follows.
  • the character string described in this field Typelndicator indicates that the next data type is the extended data in the clip information file.
  • a field ProgramlnfoExtStartAddress and a field MarkersPrivateDataStartAddress each having a data length of 32 bits are arranged via an area reserved having a data length of 32 bits (4 pitots).
  • the field ProgramlnfoExtStartAddress and field MakersPrivateDataStariAddressW indicate the start address of the block blkProgramlnfoExt 0 and the block MkMakersPrivateDataO in this block blkClipExtensionDataO with reference to the start of this block blkClipExtensionDataO.
  • a block blkCl ipInfoExt 0 is arranged via an area reserved having a data length of 192 bits.
  • a padding table having a data length of 16 pits is repeated as many times as indicated by the value N1, and then a block MkProgramlnfoExtO is arranged.
  • the padding field is repeated as many times as indicated by the value N2, and then the block MkMakersPrivateDataO is placed.
  • a padding word having a 16-bit data length is repeated as many times as indicated by the value N3.
  • the field Length has a data length of 32 bits and indicates the data length from immediately after this field Length to the end of the block blkProgramlnfoExt ().
  • the field NumberOfProgramSequence is arranged through an area reserved having a data length of 8 pits.
  • the number of program sequences described in this block blkProgramlnfoExtO is indicated.
  • the value of the field NmnberOfProg ramSequence is "1".
  • the field NumberOiStreafflCodingInioExtInPs [i] and the next second for loop statement are repeated as many times as indicated by the field NumberOfProgramSequence.
  • a field with 8-bit data length NumberOfStreamCodingInfoExUnPs [The number of fields StrreamP ID [i] [j] and the block b lk StreamCodinglnfoExt (i, j) Is stored.
  • Field StreamPID [i] [j] with 6-bit data length constitutes the table pointed to by value [i] and value [] '], and was referenced by the [i] th program sequence Indicates the PID value corresponding to the elementary stream described in the PMT (Program Map Table).
  • the next block blkStreamCodinglnfoExt i,] ') describes information about the encoding method of the elementary stream indicated by value [i] and value [j].
  • FIG. 38 shows a syntax that describes an example of the structure of the block blkStreamCodingInfoExt (i, j).
  • Field Length has a data length of 8 bits, and indicates the data length from immediately after this field Length to the end of the block blkStreamCodinginfoExt (i, j).
  • the next field StreamCodingType has a data length of 8 bits and indicates the type of encoding of the corresponding stream.
  • This field StreamCodingType has the value “OxlB” and is described below the if statement.
  • the field with the first 8-bit data length, HorizontalSize indicates the vertical size of the screen, that is, the number of lines. In the block blkStreamCodinglnfoExt (i, j), the information below the field HorizontalSize is not related to the present invention, so the description is omitted.
  • block CI ipEnfoExt 0 and the block blkMakersPrivateDataO in the extension data block ⁇ blkClipExtensionDataO in the clip information file are not related to the present invention and will not be described.
  • the virtual player When a disc having the data structure as described above is loaded into the player, the player can execute a command described in a movie object read from the disc, etc., with a specific command for controlling the hardware inside the player. Must be converted to a command.
  • the player stores the software for performing such conversion in advance in a ROM (Read Only Memory) built in the player.
  • This software is called a virtual player because it mediates between the disc and the player and allows the player to operate according to the A VCHD format.
  • FIG. 39A and FIG. 39B schematically show the operation of this virtual player.
  • Figure 39A shows an example of the operation during disk loading.
  • a registry parameter that stores the shared parameters used in a shared manner in the disc 1 is initialized (step S). 3 1).
  • the program described in the movie object is read from the disk and executed.
  • Initial access means that the disc is played for the first time as when the disc is loaded.
  • FIG. 39B shows an example of the operation in the case where, for example, the play key is pressed and playback is instructed by the user from the stopped state.
  • the user instructs playback using, for example, a remote control commander (UO: User Operation).
  • UO User Operation
  • the register that is, the common parameter-evening is initialized (step S 41), and in the next step S 42, the process proceeds to the movie object execution phase.
  • Playing back a playlist during the movie object execution phase is described with reference to FIG.
  • the player refers to the index table (Index Table) shown in FIG. 2 and obtains the object number corresponding to the content playback of title # 1. For example, if the number of an object that realizes the content playback of title # 1 is # 1, the player starts executing movie object # 1.
  • Fig. 40 if the program described in movie object # 1 consists of two lines, and the command on the first line is "Play PlayList (l)", the player Start playback.
  • the Raylist # 1 is composed of one or more play items, and the play items are played sequentially.
  • the play item in playlist # 1 finishes playing it returns to the execution of movie object # 1, and the command on the second line is executed.
  • the command on the second line is "j um p MenuTitle", and this command is executed and a movie object that realizes the menu title (MenuTi Ue) described in the index table. The execution of is started.
  • a chapter based on the recorded clip is added to an existing playlist. Then, when the chapter is added to the existing playlist, it is determined whether or not the chapter based on the clip can be added to the playlist based on a predetermined restriction in the playlist. If it is determined that additional writing is possible, the chapter based on the clip is added to the playlist. On the other hand, if it is determined that additional writing is impossible, a new playlist is created, and a chapter based on the recorded clip is registered for the newly created playlist.
  • FIG. 41 schematically shows a configuration of an example of a recording apparatus applicable to the embodiment of the present invention.
  • This recording apparatus records an AV stream obtained by compressing and multiplexing the input digital video and digital audio data by a predetermined method on a recording medium.
  • the recording device illustrated in Fig. 41 is a video input from the outside. It can be used as a stand-alone recording device that records data and audio data on a recording medium, or it can be combined with a camera block equipped with an optical system, an image sensor, etc., and video data based on the captured image signal can be recorded on the recording medium. It can also be used as a recording block for a video camera device.
  • compression coding and multiplexing methods can be considered.
  • the method defined in H. 2 64 I AVC can be applied as the compression encoding according to the embodiment of the present invention.
  • the present invention is not limited to this, and compression encoding may be performed based on the MP E G 2 system.
  • MP EG 2 Systems can be applied as a multiplexing method.
  • video data compression and encoding will be performed in accordance with the method specified in H. 2 64 I AVC, and video data and audio will be multiplexed in accordance with the method specified in MP EG 2 Systems. Explain as what to do.
  • the control unit 30 includes, for example, a CPU (Central Processing Unit), a RAM (Random Access Memory), and an ROM (Read Only Memory) (not shown), and is based on programs and data stored in advance in the ROM. Therefore, the RAM is used as a work memory to control each unit of the recording unit 10 of this recording apparatus, and the path connecting the control unit 30 and each unit of the recording unit 10 is to avoid complexity. It is omitted in Fig. 41.
  • a CPU Central Processing Unit
  • RAM Random Access Memory
  • ROM Read Only Memory
  • a UI (User Interface) unit 31 is provided with a predetermined operating element for the user to operate the operation of the recording apparatus, and outputs a control signal corresponding to the operation on the operating element. This control signal is supplied to the control unit 30.
  • the control unit 30 controls the operation of each unit of the recording unit 10 by processing of a program based on a control signal supplied from the UI unit 31 according to a user operation. For example, depending on the operations performed on the UI part 31, The control unit 30 controls the start and stop operations of the recording operation by the recording device.
  • control unit 30 is an application that provides a user interface and controls each unit of the recording unit 10 on an OS (Operating System) that consists of a predetermined program and provides the basic functions of the software. And the driver software that mediates between the software and the actual hardware of each unit.
  • the OS further provides a file system for managing files and data recorded on the recording medium 20 described later.
  • the application software accesses a file recorded on the recording medium 20 through a file system provided by the OS.
  • Base span digital video data is input from terminal 40.
  • baseband digital video data is input from terminal 41 along with the digital video data.
  • the digital video data is input from the terminal 40 to the recording unit 10 and supplied to the video encoder 11.
  • the video encoder 11 compresses and encodes the supplied digital video data by a predetermined method.
  • compression coding is performed according to the method specified in H.264 1 AVC.
  • DCT Discrete Cosine Transform
  • intra-frame prediction are used, and motion vectors are used.
  • Inter-frame compression is performed, and entry-pei coding is further performed to increase the compression efficiency.
  • the digital video data compressed and encoded by the video encoder 11 is supplied to the multiplexer (MUX) 13 as an elementary stream (ES) of H.264 I AVC.
  • MUX multiplexer
  • Digital audio data is input from the terminal 41 to the recording unit 10 Supplied to audio encoder 1 2.
  • the audio encoder 12 is compression-encoded by a predetermined compression encoding method, for example, AC 3 (Audio Code number 3).
  • the compression encoding method of audio data is not limited to AC 3. It is also conceivable to use the baseband data without compressing and encoding the audio data.
  • the compressed and encoded digital audio data is supplied to the multiplexer 13.
  • the multiplexer 13 multiplexes the digital video data and digital audio data supplied after being compressed and encoded by a predetermined method, and outputs the multiplexed data as one data stream.
  • the supplied compressed video data and compressed audio data are multiplexed in a time division manner using an MPEG2 transport stream.
  • the multiplexer 13 has a buffer memory, and stores the supplied compressed video data and compressed audio data in the buffer memory.
  • the compressed video data stored in the buffer memory is divided for each predetermined size, added with a header, and packetized into PES (Packeiized Elementary Str earn) packets.
  • PES Packeiized Elementary Str earn
  • the compressed audio data is divided into predetermined sizes, and headers are added to form PES packets.
  • the header stores predetermined information defined by MPEG2 Systems such as PTS indicating the reproduction time of data stored in the packet and DTS (Decoding Time Stanp) indicating the decoding time.
  • the PE S packet is further divided and packed into the payload of the transport packet (TS packet).
  • the header of the TS packet stores a PID (Packet Identification) for identifying the data packed in the payload.
  • the TS packet output from multiplexer 1 3 is Is temporarily stored in the buffer 14.
  • the TS packet is actually output with a header of a predetermined size added in MUX 13.
  • This packet with a predetermined header added to the TS packet is called a source packet.
  • the recording control unit 15 controls data recording on the recording medium 20.
  • the recording medium 20 for example, a recordable DVD (Digital Versatile Disc) can be used.
  • the present invention is not limited to this, and a hard disk drive may be used as the recording medium 20, and a semiconductor memory may be applied to the recording medium 20.
  • B1u-rayDisc Blu-ray Disc: registered trademark
  • B1u-ray Disc Blu-ray Disc: registered trademark
  • the recording control unit 15 monitors the amount of data stored in the stream buffer 14, and when a predetermined amount or more of data is stored in the stream buffer 14, the recording control unit 15 records the recording unit 20 of the recording medium 20 from the stream buffer 14. Is read and written to the recording medium 20.
  • the management information processing unit 16 includes, for example, a CPU, a ROM as a unique memory, and a ROM in which program predetermined data is stored in advance (not shown). Not limited to this, the management information processing unit 16 can also realize the function of the management information processing unit 16 by program processing in the control unit 30, for example. In this case, for example, the RAM included in the control unit 30 is used as the volatile memory 17 and the nonvolatile memory 18 is connected to the control unit 30.
  • the management information processing unit 16 uses the volatile memory 17 as a work memory, and the above-described index file “index.b dmv”, movie object file “MovieObject.bdmv”, playlist file “xxxxx. rapls "and clip-in formation P2007 / 060081 Information to be stored in the “zzzzz.dpi” is generated.
  • the generated information is written to the recording medium 20 at a predetermined timing.
  • the management information processing unit 16 acquires the time information of the recording data from the multiplexer 13 and acquires the address information of the recording data 20 from the recording control unit 15.
  • EP-map information is generated based on the interval information and address information.
  • clip info The file “zzzzz.clpi” is generated and the information of the generated clip information file is added to the playlist file, and the playlist file “xxxxx.mpls” is updated.
  • the information of the clip file is added to the playlist file, and it is judged whether or not the predetermined restrictions are satisfied for the playlist file. If it is determined that the constraints are not satisfied, a new playlist file is created, and the information of the generated clip information file is recorded in the newly created playlist file.
  • the index file “index, bdmv” and the movie object file “Mov i eOb ct. B dfflv” are generated or updated. .
  • FIG. 42 shows an example of a data structure applicable to one embodiment of the present invention.
  • the index file “index.bdmv” has one or more titles. Movie Object 7 7 "Movi e0bj ec i. Bdmv '
  • the index file “index, bdniv” includes one or more movie objects corresponding to the titles included in the index file “index, bdniv”.
  • Each movie object calls one playlist file "xxxxx.mpls”.
  • the playlist file “xxxxx.mpls” includes one or more play items, and each play item refers to the clip information file “zzzzz.dpi”.
  • the clip information file “zzzzz.clpi” has a one-to-one relationship with the clip AV stream file “zzzzz.m2ts”, which is the actual clip.
  • the user can see the clip recorded on the recording medium in the title unit of the index file “index.bdmv”.
  • the movie object corresponding to the title is referenced from the movie object file “MovieObject.bdmv”.
  • the playlist file “xxxxx.mpls” described in the referenced movie object is called, and the clip information file “zzzzz.clpi” is referenced according to the play item included in the playlist file.
  • Clip AV stream file “zzzzz.m2ts” is played.
  • the jump position can be set by providing a mark (playlist mark) indicating time information for the playlist file “xxxxx.mpls”.
  • the mark is defined by the mark.
  • a chapter is a playback unit in a title that can be seen from the user.
  • a mark is always provided at the recording start position. Marks can be placed at positions other than the recording start position.
  • a playlist mark is set at the start of recording, and a play item that refers to a clip is registered in the playlist file.
  • a chapter is formed. In other words, it can be said that by recording a play list mark and a play item for a play list file, a chapter is recorded for the play list file.
  • playlist files “00000.mpls”, “00200.mpls”, and “00018.fflpls” have real playlist attributes.
  • the playlist file “OOOOO.mpls” is an example of adding and recording information about newly created clips to the playlist. For example, for a playlist file “OOOOO.mpls” that already contains a clip # 0 that references the clip information file “00001. clpi” corresponding to the clip AV stream file “00001.
  • Play item # 1 that refers to the clip information file “00125 ⁇ m2ts” corresponding to the recorded clip AV stream file “00125.m2ts” is additionally recorded. A mark is provided at the start time indicated by the play item.
  • this playlist file “00000.Immediate Is” is played back, the clip AV stream file “00001.m2is” is played back based on the play item # 0, followed by the clip AV stream file “001 25” based on the play item # 1. .m2ts "is played.
  • the playlist file “00200.mpls” is an example in which one playlist file is generated for one clip, and the playlist file includes only one play item.
  • playlist file “00018. Immediate Is” is an example in which a plurality of play items refer to one clip.
  • play items are created by recording start and stop, and for one clip 60081 It is conceivable to perform control such that data is additionally written. Play item #
  • a mark is provided at the head of 0, and play item # 0 and play item # 1 are continuously played, so that the entire clip AV stream file “00002.m2ts” is played.
  • the virtual play list designates a playback section for a clip that already exists, as shown in FIG. 42 as a play list file “00005. Immediate Is”.
  • play item # 0 included in playlist file "00005.mpis” refers to clip information file "00028.clpi” to specify the section
  • play item # 1 is clip information file "00002.
  • the interval is specified with reference to "clpi”.
  • a mark is provided at the beginning of play item # 0 and play item # 1.
  • Restriction (1) Maximum number of play items that can exist in one playlist file.
  • Constraint (2) Upper limit of the number of playlist marks that can exist in one playlist file.
  • Restriction (4) Upper limit of file size of playlist file of 1.
  • Restriction (5) Upper limit of total file size of clip information file that can be related to playlist file of 1.
  • Constraint (6) Upper limit of total entry points to be searched in coarse units in the clip information file related to one playlist file.
  • Constraint (7) The upper limit of the total number of entreprines that are searched in precise units within the clip information file associated with one playlist file.
  • the upper limit of the number of play items that can exist in one play list file is, for example, 99 9 on the format.
  • the upper limit of the number of playlist marks that can exist in one playlist file is set to 9 9 9. Therefore, when a new clip is recorded, it is necessary to determine whether or not these restrictions are satisfied when adding a chapter to a playlist file in which a chapter based on the clip is to be added. .
  • the video format such as the frame size, scanning method, aspect ratio, frame rate, codec type, etc. Attributes related to evening encoding are unchanged Are specified in the format. Therefore, when a new clip is recorded, these attributes in the clip that is referenced by the play item already recorded in the playlist file to which the chapter based on the clip is to be added are newly recorded. You need to compare these attributes with the clip you are trying to use.
  • the file size of one playlist file in restriction (4) and the total file size of clip information files related to one playlist file in restriction (5) are upper limits on the format. Is stipulated. This file size specification is related to the memory capacity of the recording and playback devices.
  • the clip information file of the recorded clip is temporarily stored in the memory of the recording device, and is recorded on the memory.
  • the playlist file is updated to the clip information file.
  • the upper limit of the file size of the playlist file is, for example, 6 00 kB (kilobytes). Also, if the upper limit of the file size of one clip information file is 1 MB (megabytes), for example, the upper limit of the total file size of the clip information file related to one playlist file is , For example, 2MB.
  • the upper limit of entry points in restrictions (6) and (7) is related to the upper limit of the file size of the clip information file described above. That is, as described above, the entry point for searching in coarse units and the entry point for searching in precise units are information stored in the block MkEPMapO in the block MkCPlO in the clip information file. In other words, the entry points that are searched in coarse units are the field PTSEPCoarse and field SPNEPCoarse in the block MkEPMapO, and the entry points that perform the precise search are the field PTSE PFine and field SPNEP ine in the block MkEPMapO.
  • the total number of clip information files related to one playlist file is calculated.
  • An upper limit is defined. Therefore, when a new clip is recorded, whether or not these restrictions are satisfied when a play item is added in a playlist file to which a play item that refers to the clip is added. It is necessary to judge.
  • a block in an extended data block in a playlist file Lock blkMakersPrivateDat a O as shown in the block DataBlock () in Fig. 35, because the data size is not particularly limited.
  • a specification to write data size data is also conceivable.
  • the playlist file may be updated or edited by taking over the information of such a large block recorded by other devices due to factors such as memory capacity limitations, etc.
  • b lkMakersPr ivat eDat a O This may be difficult.
  • a stationary recording / playback device such as a video deck
  • one program is one playlist
  • playlist marks are automatically provided at 5-minute intervals.
  • the stationary recording / playback device displays the thumbnail image only at the top of the playlist and does not display the thumbnail image for each chapter. Under these conditions, a recording medium on which a playlist file created by a stationary recording / reproducing device is recorded is loaded into the video camera device, and a play item that refers to a clip recorded by the video camera device is used.
  • an upper limit is set for the total number of entrepreneurs in the clip information file related to one playlist in the format. For example, even if there is enough free space on the recording medium, in a playlist file to which a play item that refers to a newly recorded clip is to be added, the total number of entry points and the number of entries in the clip information file that has already been referenced. There may be cases where it is not possible to secure the number of reincents for a specified time to be guaranteed, based on the upper limit specified for one pine. Therefore, when attempting to record a new clip, continuous recording for a predetermined time or longer is performed based on the number of entry points associated with the playlist file to which a play item that refers to the clip is to be added. It is necessary to judge whether it is possible.
  • FIG. 43 is a flowchart showing an example of a process for determining whether or not additional information can be added to a playlist file based on a clip to be newly recorded.
  • the recording medium 20 is a disc-shaped recording medium (hereinafter referred to as a disc) such as a DVD capable of recording.
  • a disc a disc-shaped recording medium
  • Each determination process described below is performed by the control unit 30 in the recording apparatus described with reference to FIG.
  • the recording control unit 15 is controlled by the control unit 30, and the index file “index.bdmv” is read from the recording medium 20 (step S100).
  • the read index file “index, bdmv” is stored in the volatile memory 17 via the management information processing unit 16, for example.
  • the control unit 30 determines the chapter based on the next recorded clip based on the information described in the index file “index, bdmv” stored in the volatile memory 17. Specify a playlist (playlist file) candidate to add to.
  • the file name of the real playlist is searched by searching the most recently recorded real playlist. To get.
  • the block blklndexExtensionD Among the blocks blkMovieTitlePlayListPairO enumerated in ataO, the block blkMovieTitlePIayListPairO that is described at the end of the block blk MovieTitlePlayListPairO whose field PlayListAttribute indicates the attribute ⁇ RealJ '' is searched, and the searched block blkMovievieUe ayListPair 0 Get data of field PlayListFileName from.
  • step S 102 the playlist file of the additional recording candidate specified in step S 101 is read from the recording medium 20 and stored in the volatile memory 17. Then, all the clip information files related to the read-list candidate playlist file that has been read are read from the recording medium 20. The read clip information file is stored in the volatile memory 17.
  • step S104 whether or not additional writing is possible is determined based on the number of play items included in the additional writing candidate playlist file acquired in step S101, corresponding to the restriction (1) described above.
  • step S 105 corresponding to the restriction (2) described above, Based on the number of playlist marks included in the playlist file as a candidate for additional recording, whether or not additional recording is possible is determined.
  • step S 10 06 based on the video attribute of the clip to be newly recorded and the video attribute of the clip to be newly recorded, corresponding to the restriction (3) described above. Judgment of whether additional writing is possible.
  • next step S 10 07 it is determined whether or not additional writing is possible based on the file size of the playlist file as a candidate for additional writing, corresponding to the restriction (4) described above.
  • next step S 1 0 8 it is determined whether or not additional writing is possible based on the total file size of the clip formation files referenced from the playlist file that is a candidate for additional writing, corresponding to the restriction (5) described above.
  • the next step S 1 0 9 the total entry points stored in the clip information file corresponding to the above-mentioned restriction (6) and restriction (7) and referenced from the playlist file that is a candidate for additional writing Judge whether additional writing is possible based on the number.
  • next step S 110 it is determined whether or not additional writing is possible based on the presence or absence of a unique extension data by another device in the playlist file that is a candidate for additional writing, corresponding to the restriction (8) described above. Further, in the next step S 11 1 1, it is determined whether or not additional writing is possible based on the last updater of the playlist file as a candidate for additional writing, corresponding to the restriction (9) described above.
  • step S 1 1 2 the playlist based on the newly recorded clip as a candidate for additional writing based on the determination results of the respective determination processes from step S 1 0 4 to step S 1 1 1 described above.
  • a final decision is made as to whether or not to append to the file.
  • the determination result of each processing from step S1104 to step S111 is held in a register or the like included in the control unit 30 and is held in the register in step S1 1 2. Judgment is made based on the result of each process.
  • step SI 1 2 if it is determined that additional writing is possible in all of the processes from step S 1 0 4 to step S 1 1 1, the step based on the newly recorded clip is changed to step S 1 0. Judge that it should be appended to the playlist file of the candidate for appending obtained in 1.
  • step S 1 0 4 in each of the processes from step S 1 0 4 to step S 1 1 1 described above, if there is at least one process that is determined not to be able to be additionally written, the additional writing acquired in step S 1 0 1 described above It is determined that appending of chapters based on the candidate playlist file is not possible. In this case, a new playlist file of the real playlist is created, and a chapter based on the newly recorded clip is recorded in the new playlist file.
  • steps S 10 04 to S 11 1 described above is not limited to this order. That is, each process from step S 1 0 4 to step S 1 1 1 can be performed in an arbitrary order. It is also possible to perform each processing from step S 104 to step S 11 1 1 in parallel. Furthermore, one or more of the processes may be selectively performed without performing all of the processes in steps S 1 0 4 to S 1 1 1.
  • FIG. 44 shows an example of a process for determining whether or not additional writing is possible based on the number of play items included in the playlist file as a candidate for additional writing, corresponding to the restriction (1), in step S 104.
  • step S 1 2 block MkP layL ist O (see Fig. 1 1) )
  • step S 1 2 block MkP layL ist O (see Fig. 1 1) )
  • the value of the field NumberOfPlayltems is less than the predetermined upper limit value, it is determined that appending to the playlist file of the supplementary recording candidate based on the newly recorded clip is possible.
  • the value of the field NumberOfPlayltems is equal to or greater than a predetermined upper limit value, it is determined that additional writing to the playlist file as a candidate for additional writing of the corresponding chapter is impossible.
  • FIG. 45 shows an example of processing for determining whether or not additional writing is possible based on the number of playlist marks included in the playlist file of the additional writing candidate, corresponding to the restriction (2), in step S 105.
  • the value of the field NumberOfPlayListMarks is obtained by referring to the block blkPlayListMarkO (see FIG. 14) in the playlist file of the additional write candidate, and the obtained field NumberOf
  • the value of PlayListMarks is compared with a predetermined upper limit value set for the number of playlist marks that can exist in one playlist file, for example, the value “999”.
  • the value of the field NumberOiPlayListMarks is less than the predetermined upper limit value, it is determined that additional recording can be performed on the playlist file as a candidate for additional recording based on a clip to be newly recorded.
  • the value of the field NumberOfPlayListMarks is equal to or greater than a predetermined upper limit value, it is determined that additional writing to the playlist file of the additional writing candidate for the current chapter is impossible.
  • the playlist mark has an entry mark. There are two types of tokens and link points.
  • step S 1 30 it is determined whether or not the total number of entry marks and link points is less than the upper limit value.
  • Fig. 46 is based on the video attributes described in the playlist file as a candidate for appending and the video attributes of the clip to be newly recorded, corresponding to the restriction (3) in step S1 06.
  • An example of the process for determining whether additional writing is possible is shown below.
  • the attribute information of the video to be recorded is acquired.
  • the image frame size, aspect ratio, frame rate, and scan type are recorded as attribute information of video data to be recorded based on the recording mode currently set for the recording apparatus. To obtain.
  • step S 1 4 1 to S 1 4 4 the video attribute of the clip related to the playlist file as the candidate for additional recording is acquired.
  • the video attribute is acquired from the clip information file that is referenced by the play item that is recorded first.
  • the image width is obtained in step S 1 4 1
  • the image height (number of lines) and scan type are obtained in step S 1 4 2
  • the aspect ratio is obtained in step S 1 4 3.
  • step S 1 4 4 the frame rate is obtained.
  • step S141 the block blkProgramlnioExtO (see Fig. 37) in the block blkCUpExtensionDataO, which is the extension data in the clip information file, is referenced.
  • the block blkProgramlnfoExt 0 the block blkStreamCodinglnfoExtd, j) (Fig. 38 Reference) is referred to.
  • the value of the field HorizontalSize in the block bl kStreamCodinglnfoExt (i, j) is obtained.
  • step S142 the block MkStreamCodinglnfoO (see FIG. 18) in the block blkProgramlnfoO (see FIG. 17) in the clip information file is referred to, and the value of the field Video Format is acquired.
  • the field VideoFooiai as already explained with reference to Fig. 19, the combination of the number of lines of video data and the scanning method (interlace / progressive) is shown using values that can be expressed in 4 bits. ing.
  • step S13 the block blkStrameCodinglnfoO is referred to in the same manner as in step S142, and the value of the field AspectRatio is obtained.
  • the field AspectRatio indicates the aspect ratio of the image frame of the video data using values that can be expressed in 4 bits, as already explained using Fig. 21.
  • step S144 similarly to step S143 and step S143, the block blkSireamCodinglnioO is referred to, and the value of the field FrameRate is obtained.
  • Field FrameRate uses Figure 20 As already explained, the frame rate of video data is shown using a value that can be expressed in 4 bits.
  • step S 1 45 each of the attribute information of the video data to be recorded acquired from the recorder in step S 1 40 and the additional write candidate play acquired in steps S 11 to S 14 4 Each of the clip's video attributes associated with the list file is compared.
  • FIG. 47 shows an example of the process for determining whether or not additional recording is possible based on the file size of the playlist file as a candidate for additional recording, corresponding to the restriction (4), in step S 110.
  • this process even if at least the specified number of caps is added to the play list for additional write, the upper limit of the file size of one playlist file is not exceeded, and whether or not additional write is possible is determined.
  • the number of predetermined chapters may vary depending on the design concept of the recorder, such as one chapter, multiple chapters, or the number of remaining chapters for the maximum number of chapters that can exist in one playlist file.
  • the predetermined number of chapters is the number of remaining chapters with respect to the maximum number of chapters that can exist in one playlist file.
  • field StillMod e and field StillTime, and block blkUOMaskTable 0 and block b 1 kSTNTab I e 0 are data whose data length may vary, In the meantime, these data are fixed lengths depending on the recording mode and recorder.
  • the value of each field is fixed length with reference to Fig. 14. In this way, the play item and playlist size generated when one clip is recorded can be calculated in advance. Also, the calculated value is of a nature that does not depend on the recording time.
  • the value of the size increase of the playlist file per chapter, SIZE-1CHAP is calculated in advance and stored, for example, in the ROM of the recorder.
  • the calculation may be performed each time the process according to the flowchart of FIG. 47 is executed.
  • the play item and the playlist mark increase. Therefore, when adding a chapter to a playlist, it is necessary to take into account the number of play items and playlist marks that can exist in one playlist file under constraints (1) and (2). is there.
  • step S 1 5 the number of play items that can be additionally written in the play list file of the additional write candidate ⁇ —REMAIN is calculated.
  • the value of the field NumberOfPlayltems is obtained by referring to the block MkPlayListO (see Fig. 11) in the playlist file of the additional write candidate, The number of play items included in the playlist is obtained.
  • the number of play items included in the add-on candidate play list is reduced to a predetermined upper limit P set for the number of play items that can exist in one play list file, for example, “999”. , P for the number of play items that can be added to the playlist of candidate additions and calculate REMAIN.
  • the number of play items that can be added to the playlist file as a candidate for additional recording P and REMAIN are obtained by the following equation (1).
  • PI_REMAIN PI_MAX-NumberOf Play Items ⁇ ⁇ ⁇ (1)
  • step S 1 52 the number of mark marks MARK — REMAIN that can be added to the playlist file as a candidate for additional writing is calculated. That is, the value of the field NumberOfPlayListMarks is obtained by referring to the block blkPlayListMarkO (see Fig. 14) in the playlist file of the additional write candidate, and the number of playlist marks included in the playlist ⁇ of the additional write candidate is obtained. I will. Then, the number of play list marks included in the play list candidate for addition is subtracted from a predetermined upper limit value MARK 1 MAX set to the number of play items that can exist in one play list ⁇ , for example, “999”. , Add the number of playlist marks MARK_REMAIN that can be added to the candidate playlist.
  • the number of playlist marks that can be added to the playlist file as a candidate for additional recording is obtained by the following equation (2).
  • M ARK_REMA IN MARK_M AX-NumberOfPlayListMarks ⁇ ⁇ (2)
  • the smaller of the number of playlist marks MARK — REMAIN that can be added to the playlist file of the candidate for additional writing obtained in step S 1 52 is the number of chapters CHAP — REMAIN that can be added to the additional recording.
  • the number of chapters CHAP-REMAIN that can be added to a playlist file as a candidate for additional writing indicates that the smaller one of the values in parentheses is selected for “MIN”.
  • the following equation (3) is obtained. “MIN” indicates that the smallest value among the values in parentheses is selected.
  • CHAP_REMAIN MI (PI—REMAIN, MARK—REMAIN) ⁇ ⁇ ⁇ ⁇ (3)
  • the file size of the playlist file to be added is obtained, and the playlist file of 1 in Constraint (4)
  • the upper limit of the file size of PL-SIZE-MAX is obtained for the remaining data size SIZE-REMAIN.
  • the file size of a playlist file can be obtained by using a function provided by, for example, ⁇ S file system.
  • Data size SIZE_REMAIN (kB) is obtained by the following equation (4). Note that the file size of the playlist file that is a candidate for additional recording is FILE-SIZE (kB).
  • SIZE—REMAIN (kB) PL—SIZE_MAX (kB) —FILE— SIZE (kB) ⁇ ⁇ ⁇ (4)
  • the number of chapters that can be added to the playlist file as a candidate for additional writing it is determined whether the file size of the playlist file as a candidate for addition does not exceed the maximum file size of one playlist file.
  • FIG. 48 shows the constraints (5 ) Corresponds to an example of a process for determining whether or not additional recording is possible based on the total file size of clip information files referenced from a playlist file that is a candidate for additional recording.
  • the upper limit CLIP_SUM-MAX is set, for example, 2 MB, for the total file size of the clip information file that is referred to from the playlist file that is a candidate for additional writing.
  • the total size of the clip information file related to the playlist file for that additional recording is the upper limit CL.
  • step S 1 60 the maximum size SI ZE — 1 CLIP of 1 clip information file calculated in advance is acquired.
  • entry point information that associates the PTS value with the byte address of the clip AV stream file is stored in the block MkEPMap O (see FIGS. 23 to 26). This entry point information varies depending on the recording time. Other information stored in the clip information file is a fixed value regardless of the recording time, depending on the encoding method.
  • the minimum time for guaranteeing continuous recording is set as the specifications of the recorder. The number of entry points for the minimum time that guarantees continuous recording is determined by the video and audio encoding methods in the encoder. Communicating Calculate the total data size of the entry points for the minimum time to guarantee continuous recording, and obtain the maximum size SIZE_1CLIP based on the calculation result.
  • the file size is obtained for all clip information files that are referenced from the playlist file that is a candidate for additional recording, and the total size SIZE_TOTAL__CLIP is calculated. That is, all the blocks MkPlayltemO (see Fig. 12) in the playlist file that is a candidate for additional writing are referenced, and the data of the field ClipInformationFileName is obtained for each block blkPlayltem (). Then, the file size of the clip information file indicated in the data of the acquired field ClipInformationFileName is obtained for all the blocks blkPlayltemO in the playlist file as a candidate for addition, and totaled.
  • the file size of the clip information file can be obtained by using the function provided by the file system of ⁇ S, for example.
  • step S 1 62 the additional candidates calculated in step S 1 6 1 from the upper limit of the total file size of clip information files that can be related to the playlist file 1
  • Fig. 49 shows the entry points stored in the clip information file referenced from the play list file that is the candidate for additional recording corresponding to the constraints (6) and (7) in step S1009 described above. The process of an example of the appendability permission judgment based on the total number is shown.
  • Constraint (6) and Constraint (7) search is performed in coarse units. There is an upper limit for each entry point and entry point that searches in precise units. Therefore, the judgment must also be made for each entry point that searches in coarse units stored in the clip information file and each entry point that searches in precise units.
  • the upper limit MAX_EP_C0ARSE of the total value of the entry reentries to be searched in coarse units in the clip information file related to the playlist file 1 is, for example, 2 4 5 7 6.
  • the upper limit value MAX-EP-FINE of the total value of entreboints that are searched in precise units is, for example, 1800 0 00 0.
  • step S 1 70 the maximum number of entry points per one cap calculated in advance is acquired.
  • the minimum time for which continuous recording is guaranteed is generally set as a recording machine specification.
  • the maximum number of entry points when recording for the minimum time for which continuous recording is guaranteed is calculated in advance, and this value is obtained in step S 1700.
  • the entry point to be searched in coarse units is 11.5 seconds (PTS: entry PTSEPC oarse) or 25 MB (source packet number: Entry SPNEPCoar se).
  • the minimum time for which continuous recording is guaranteed is the time Ml N_TIME (hr)
  • the data amount of the clip AV stream file generated when recording for the minimum time is determined MilSIZE (MB)
  • the maximum number of entry points per chapter for the entry points to be searched in coarse units NEEDED—EP_C0ARSE is obtained by the following equation (7).
  • CE IL indicates that the value in parentheses is rounded up.
  • NEEDED—EP 1 CO ARSE CEIL (3600 [sec] XMIN—TIME [hr] ⁇ 11.5 [sec]) + CEIL (MIN_SIZE [MB] ⁇ 25 [MB]) ⁇ ⁇ ⁇ (7)
  • the entry point to be searched in precise units is set for each GOP with PTS accuracy (entry PTSEPFine) or source packet accuracy (entry SPNEPFine).
  • PTS accuracy entity PTSEPFine
  • source packet accuracy entity SPNEPFine
  • the frame frequency is 29.997 Hz
  • 1 GOP is composed of 15 frames
  • the entry points to be searched in precise units The maximum number of entry points per evening NE EDED_EP—FINE is given by the following equation (8).
  • “90 [kHz] ⁇ 3003” indicates the frame frequency (29.97 Hz) based on PTS accuracy.
  • next step SI 71 for all clip information files that are referenced from the playlist file that is a candidate for appending, an entry point that searches in coarse units and an entry point that searches in precise units Are obtained, and the total number of entry points T0TAL—EP_C0ARSE for searching in coarse units and the total number of entry points T0TAL_EP for searching in fine units are obtained.
  • the field NumberOfEPCoarseEnries [k], and the field NumberOfEPFineEiitries [k] the total number of entries to be searched in coarse units TOTAL—EP—COARSE It is possible to obtain the total T0TAL_EP_FINE of entry points to be searched in precise units.
  • the next step S 1 7 2 it is determined whether or not the upper limit MAX—EP_C0ARSE is exceeded for the entry to be searched in coarse units when appending a chapter to a candidate playlist file. Is done.
  • Maximum entry point number of entry points to be searched NEEDED_EP_COARSE is searched in coarse units of the clip information file related to the playlist file of 1.
  • the upper limit of the total value of the entry reboint MAX_EP one COARSE and the playlist list of additional candidates If the total of the entry points to be searched in coarse units of the clip information file related to the file is larger than the difference from TOTAL—EP_C0ARSE, it is determined that additional writing to the playlist file as a candidate for additional writing of the corresponding chapter is impossible.
  • step S 1 7 3 the same determination is made for entry points that are searched in precise units. That is, the maximum number of endpoints per chapter of the endpoints to be searched in precise units obtained in step S 1 70 above NEEDED—EP_FINE and the precise units determined in step S 1 7 1 Total entry points to be searched TOTAL JP—Upper limit value of entry points to be searched in coarse units using TO — About EP_FINE Judgment is made based on the following equation (1 0).
  • FIG. 50 shows an example of processing for determining whether or not additional recording is possible based on the presence or absence of unique extension data by another device in the playlist file that is a candidate for additional recording, corresponding to the restriction (8) in step S 1 1 0 described above. Indicates.
  • the extended data compliant with the AVCDH format is searched from the extended data of the playlist file as the additional write candidate.
  • the value of the field ExtensionDataStartAddress of the playlist file that is a candidate for additional writing is acquired, and it is determined whether or not the acquired value is “0” (not shown). If the value is not “0”, the extension data block blkExtensionData 0 exists in the playlist file, so the block blkExtensionDataO is referred to based on the value of the field ExtensionDataStartAddress. Then, with reference to FIG. 33, it is checked whether or not the field ExtDataType and the field ExtDataVersion in the extension data block MkPlayListExextensionDataO in the playlist file have values specified in the AVCHD format.
  • step S 1 8 based on the search result in step S 1 80, it is determined whether or not there is extension data that conforms to the AVCHD format in the extension data of the playlist file that is the candidate for additional writing. . That is, based on the search result of step S 1 80, the value of the field ExtensionDataSrtAddress in the playlist file as a candidate for additional writing is “0” or the field ExtDataType and field in the extension data block MkPlayListExtensionData (). If the ExtDataVersion field is not a value specified in the AVCHD format, it is determined that there is no extension data that conforms to the AVCHD format in the extension data of the addendum candidate playlist file. In this case, it is determined that appending to the playlist file of the appending candidate for the relevant chapter is impossible.
  • step S 1 8 1 it is determined whether or not extension data exists in the extension data of the play list file that is a candidate for additional recording, in addition to the extension data that conforms to the AVCHD format. If it is determined that it exists, it is determined that the appending to the playlist file that is the candidate for additional recording for the current chapter is impossible.
  • step S 182 If it is determined in step S 182 that there is no extension data other than the extension data compliant with the AVCHD format in the extension data of the playlist file that is a candidate for additional recording, the process proceeds to step S 183.
  • step S 183 the data of the own device is searched by referring to the extension data block blkPyListExtensionDataO of the playlist file that is the candidate for additional writing that has been searched. In other words, referring to Fig. 35, the field in block blkMakersPrivateDataO 3 ⁇ 4 ⁇ 1 ⁇ 1 "10 field 3 ⁇ 4 ⁇ 0 ( ⁇ 1 (: 0 (16 Data is retrieved.
  • step S 184 a determination is made based on the search result of step S 1 83.
  • step S 1 84 if it is determined that there is no extended data of the own device based on the search result of step S 1 83, it is not possible to add to the playlist file as a candidate for additional recording for that chapter. Judge that there is. On the other hand, if it is determined in step S 1 84 that the extension data of the own device exists based on the search result of step S 1 83, the process proceeds to step S 185.
  • step S 185 based on the search result in step S 183, it is determined whether or not extension data by a device other than the own device exists in the block blkMakersPrivateDa O. That is, if there is data other than the data indicating the own device in the field MakerlD and the field MakerModelCode in the block blkMakersPrivateDataO, it can be determined that the extended data from the device other than the own device exists in the block MkMakersPrivateDataO.
  • step S 1 85 If it is determined in step S 1 85 that there is extension data from a device other than the own device in the block blkMakersPrivateDataO, it is determined that appending to the playlist file as a candidate for appending to the chapter is impossible. On the other hand, if it is determined that only the extension data of the own device exists in the block blkMakersPrivateDataO, it is determined that the appending to the playlist file of the appending candidate for the chapter is possible.
  • step S 1 8 1 if there is no extension data that conforms to the AVCHD format in the playlist file of the appending candidate, appending to the playlist file of the appending candidate for the appendix is impossible.
  • this is not limited to this example.
  • FIG. 51 shows an example of the process of determining whether or not additional writing is possible based on the last updater of the playlist file of the additional writing candidate corresponding to the restriction (9) in step S 11 1 described above. If the last updater of the playlist file for additional recording is not the player's own device, the concept of titles and chapters in the playlist file for additional writing candidates is different from that of the own device, which may cause inconvenience during playback. Based on the last updater information of the playlist file of the additional write candidate, only when the final updater is the device itself, control is performed so that the appending is added to the playlist file of the additional write candidate. It is possible to avoid inconveniences due to differences in title and chapter concepts in the playlist file.
  • step S 1 90 the extension data compliant with the AV C D H format is searched from the extension data of the playlist file as the additional write candidate. Then, in the next step S 1 91, based on the search result of step S 1 90, it is determined whether or not the extended data compliant with the AVCHD format exists in the extended data of the playlist file as the additional write candidate. . Note that the processing in step S 1 90 and step S 1 91 is the same as the processing in step S 1 80 and step S 1 8 1 described with reference to FIG. 50, so that complexity is avoided. Detailed explanation is omitted.
  • step S 1 9 1 If it is determined in step S 1 9 1 that no extension data conforming to the AVCHD format exists in the extension data of the playlist file of the additional write candidate, no additional data can be added to the playlist file of the additional write candidate of the relevant chapter. It is judged that.
  • step S 1 9 based on the search result of step S 1 9 0 If it is determined that the extension data conforming to the AVCHD format exists in the extension data of the playlist file as a candidate for additional recording, the process proceeds to step S 1 92.
  • step S 1 92 the last updater of the postscript list file is confirmed. That is, the block MkPlayListMe () of the extension data block blkPlayListExtensionDataO is referred to, and the data of the field MakerlD and the field MakerModelCode are acquired.
  • step S 193 determines whether or not the confirmed last updater is the own device. . That is, if the data of the field MakerlD and the field MakerModelCode in the block MkPlayLis iMeta () of the extended data block blkPlayLisiExiensionDataO indicates the own device, it can be determined that the last updater is the own device.
  • step S 193 if it is determined that the last updater of the playlist file of the additional writing candidate is its own device, it is determined that additional writing can be performed on the playlist candidate file of the additional writing of the evening. On the other hand, if it is determined that the last updater of the play list file of the additional write candidate is not its own device, it is determined that additional write to the play list file of the additional write candidate of the corresponding chapter is impossible.
  • Information about the last updater can also be stored in the index file. For example, it may be possible to store the last updated information in the block blkMakersPrivateDaO in the extension data block MklndexExtensionDataO in the index file. In this case, the determination by the flowchart of FIG. 51 may be made using the last updater information stored in the index file.
  • the recording medium 20 determines the series of determinations regarding whether to add a chapter to a playlist file as a candidate for additional recording or to create a new playlist file described with reference to FIG. Although described as being performed when loaded in the recorder, this is not limited to this example. For example, the determination may be made for each additional write of a chapter, for example, for each recording start operation.
  • Fig. 52 is a flowchart showing an example of processing for adding a chapter to a playlist file.
  • step S 2 0 When the recording start operation is performed in step S 2 0 0, the recording of the clip AV stream to the recording medium 20 is started in the next step S 2 0 1.
  • a recording start switch instructing the start of recording provided in the UI unit 31
  • a control signal instructing the start of recording is supplied from the UI unit 31 to the control unit 30.
  • baseband video data input from terminal 40 and baseband input from terminal 4 1.
  • the audio data is controlled to be recorded on the recording medium 20.
  • the clip AV stream is recorded on the recording medium 20 (step S 2 0 1).
  • the input video Overnight and audio over night are compressed and encoded by video encoder 1 1 and audio encoder 1 2 respectively, and then bucketed by multiplexer 1 3 and TS bucket (actually a source packet with a predetermined header added) and And supplied to the stream buffer 14.
  • TS bucket actually a source packet with a predetermined header added
  • the TS packet is read from the stream buffer 14 by the recording control unit 15.
  • the read TS packet is stored in a clip AV stream file with a predetermined file name and recorded on the recording medium 20.
  • a clip AV stream file with the file name “00001.m2 ts” has already been recorded on the recording medium 20, it is already recorded as the file name of the newly recorded clip AV stream file.
  • the file name is selected so that it does not overlap with the existing file. For example, the file name is “00002. m2 ts”.
  • the management information processing unit 16 As the clip AV stream is recorded on the recording medium 20, the management information processing unit 16 generates information indicating the correspondence between the reproduction time of recorded data and the address in real time. This data is stored in the volatile memory 17 as data stored in the block blEPEPMap O in the above-described clip information file “zzzzz.clpi”.
  • step S 2 0 2 it is determined whether or not a recording stop operation has been performed. For example, if the user operates the recording stop switch provided in the UI unit 31 and determines that the recording is stopped, the process proceeds to step S 2 0 3. On the other hand, if the recording is not stopped, the process is returned to step S 2 0 1, and the recording of the clip AV stream onto the recording medium 20 is continued. In step S 2 0 3, all the streams stored in the stream buffer 14 are written to the recording medium 20 as recording is stopped. For example, the recording control unit 15 reads all the streams (TS packets) stored in the stream buffer 14 and writes them to the recording medium 20 in response to a recording stop command from the control unit 30.
  • the operations of the video encoder 11 and the audio encoder 12 are stopped in response to a recording stop command.
  • the operation of the audio encoder 12 is stopped a predetermined time after the operation of the video encoder 11 1 stops. To be controlled.
  • step S 2 0 4 to step S 2 0 8 the management information processing unit 1 6 generates a clip information file related to the clip AV stream file written to the recording medium 2 0, and additional write candidates The playlist file is updated.
  • step S 2 0 4 the management information processing unit 16 generates a clip information file “zzzzz.clpi”.
  • the file name is, for example, the file name corresponding to the file name of the clip AV stream file indicated by this clip information file. If the file name of the clip AV stream file is “00002 m2 ts'”, this clip information file The file name of “00002.clpi” is the same as the file name before the extension.
  • the values of fields and flags are set and stored in accordance with the syntaxes illustrated in FIGS. 15 to 21.
  • information on TS packets and information on playback time (PTS) are based on information acquired from the multiplexer 13 during clip recording by the management information processing unit 16.
  • PTS information on playback time
  • information regarding the recording address on the recording medium 20 is generated by the management information processing unit 16 based on information acquired from the recording control unit 15 during recording of the clip.
  • the value unique to the system is based on information stored in advance in a ROM (not shown), for example.
  • the information of the above-mentioned block blkEPMapO indicating the correspondence between the reproduction time and the address is stored in the block blkCPlO of the clip information file “00002 .dpi”.
  • the flag IsCC5 in the block blkClipInioO is set to 1 (binary value) when clip recording is stopped by a user operation.
  • the data indicated by the ii sentence (see Fig. 16) in the block MkClipInfoO is set to a predetermined value.
  • step S205 The processing from step S205 to step S208 is processing related to the playlist file.
  • the playlist file that already exists on the recording medium 20 is played and the clip corresponding to the newly recorded clip AV stream file “00002 m2ts” is played. An item is added.
  • step S205 the value of the field Connection ionCondition in the block blkPlayltemO in the playlist file is set to “5”, and this clip makes the first seamless connection with the next clip. Shown (see Figure 12).
  • step S206 the value of the field NumberOfPlayltems in the play item file is incremented by “1”, indicating that one play item is added to the playlist (see FIG. 11).
  • the fee in block MkPlayltemO The field ClipInformationFileName, field INTime, and field 0 UTTime are set, and the block blkPlayltemO that is added when the clip is recorded is created.
  • the field CI iplnformationFileName is stored the file name “00002 clpi” of the clip information file created in step S 205 described above.
  • the field INTime and the field OUTTime are information indicating the start and end times of the video stream stored in the corresponding clip AV stream file “00002.m2ts”, for example, in the clip information file “00002.clpi”. Based on block blkEPMap () information in block blkCPI ().
  • the field ⁇ NumberOfPlayListMarks in the block blkPlayListMarkO in the playlist file of the additional write candidate is incremented by "1", and the field MarkTimeStamp added in the for loop statement accordingly.
  • the clip information file “000 02.clpi” is created for the newly recorded clip AV stream file “00002.m2ts”, and the playlist file that is a candidate for additional recording is updated.
  • step S 2 0 3 the writing process to the recording medium 20 stored in the stream buffer 14 in step S 2 0 3 described above may be performed after the process in step S 2 0 8.
  • step S 205 onward When creating a playlist by creating a new playlist file, the processing from step S 205 onward is slightly different from the above processing. In other words, each field data in the playlist file is newly generated. Not limited to this, for example, it is also possible to prepare a playlist file template and change the template data.
  • the present invention is converted into an imaging signal having an imaging element and an optical system that makes light from a subject incident on the imaging element. Based on this, it was applied to a video camera device that recorded video data on a recording medium.
  • FIG. 53 shows a configuration of an example of a video camera device 100 according to another example of the embodiment of the present invention.
  • the recording system configuration can be applied as it is with the configuration of the recording apparatus described with reference to FIG. 41. Therefore, parts common to those in FIG. Detailed description will be omitted.
  • the camera unit 50 has an optical system 51, an image sensor 52, an image signal processing unit 53, a camera control unit 54, and a display unit 55 as the configuration related to the video signal.
  • a microphone (MIC) 56 and an audio signal processing unit 57 are provided.
  • the control unit 30 exchanges various control signals and information with each unit of the camera unit 50. Control the operation of the camera unit 50. Further, the control unit 50 controls the operation of the power control unit 50 based on a control signal supplied from the UI unit 31 according to a user operation.
  • the recording start operation and the recording stop operation are performed using, for example, a single recording switch provided in the UI unit 31 and each time the recording switch is pressed. Generally, recording start and recording stop are instructed alternately. Further, in this video camera device 100, a disc recording medium such as a recordable type DVD or Blu-ray Disc is used as the recording medium 20.
  • the optical system 51 includes a lens system for guiding light from the subject to the image sensor 52, an aperture adjustment mechanism, a focus adjustment mechanism, a zoom mechanism, a shirt mechanism, and the like.
  • the operations of the aperture adjustment mechanism, the focus adjustment mechanism, the zoom mechanism, and the shirt evening mechanism are controlled by the camera control unit 54 based on a control signal supplied from the control unit 30.
  • the imaging element 52 is made of, for example, a CCD (Charge Coupled Device), converts the light irradiated through the optical system 51 into an electrical signal by photoelectric conversion, performs predetermined signal processing, and outputs it as an imaging signal.
  • CCD Charge Coupled Device
  • the imaging signal processing unit 53 performs predetermined signal processing on the imaging signal output from the imaging device, and outputs the resultant as baseband digital video data.
  • the imaging signal processing unit 53 samples only a signal having image information by a CD S (Correlated Double Sampling) circuit with respect to the imaging signal output from the imaging element 52, removes noise, and The gain is adjusted by the GC (Auto Gain Control) circuit. Then, it is converted into a digital signal by AZD conversion.
  • the imaging signal processing unit 53 performs detection system signal processing on this digital signal, and R (red Color), G (green) and B (blue) components are extracted, processed with key correction and white balance correction, and finally output as one baseband digital video data.
  • the imaging signal processing unit 53 sends the information of the imaging signal output from the imaging element 52 to the control unit 30. Based on this information, the control unit 30 generates a control signal for controlling the optical system 51 and supplies it to the camera control unit 54.
  • the camera control unit 54 controls the focus adjustment mechanism, the aperture adjustment mechanism, and the like based on this control signal.
  • the imaging signal processing unit 53 is based on the imaging signal output from the imaging element 52, and displays, for example, a display unit 55 using an LCD (Liquid Crystal Display) as a display element. A video signal to be projected is generated.
  • LCD Liquid Crystal Display
  • the microphone 56 picks up the surrounding sound, converts it into an electrical signal, and outputs it.
  • the audio signal output from the microphone 56 is supplied to the audio signal processing unit 57.
  • the audio signal processing unit 57 converts the supplied audio signal through a limiter and then performs AZD conversion to digital audio overnight, and performs predetermined audio signal processing such as noise removal and sound quality correction to perform baseband
  • the baseband digital video data output from the imaging signal processing unit 53 of the camera unit 50 that is output as digital audio data is supplied to the terminal 40 of the recording unit 10.
  • the baseband digital video output from the audio signal processing unit 57 is supplied to the terminal 41 of the recording unit 10.
  • an index file recorded on the recording medium 20 is read based on the control of the control unit 30 and stored in the volatile memory 17 via the management information processing unit 16.
  • the control unit 30 identifies a playlist file as an additional write candidate based on the index file information stored in the volatile memory 17, and sends the additional file candidate playlist file to the recording control unit 15.
  • a command is issued to read from the recording medium 20.
  • the playlist file of the additional recording candidate read from the recording medium 20 based on this command is stored in the volatile memory 17 via the management information processing unit 16.
  • the control unit 30 Based on the information of the playlist file of the additional write candidate stored in the volatile memory 17, the control unit 30 sends all clip information related to the play list file of the additional write candidate to the recording control unit 15. A command is issued to read one scene file from the recording medium 20. The clip information file read from the recording medium 20 based on this command is stored in the volatile memory 17. Based on the playlist file of the additional write candidate stored in the volatile memory 17 and all clip information files related to the play list file of the additional write candidate, the control unit 30 Each determination from step S 1 0 4 to step S 1 1 1 in the flowchart of the figure is performed. The result of each determination is held in, for example, a register of the control unit 30.
  • the control unit 30 performs steps S 1 0 4 to S 1 1 through the processing in step S 1 1 2 in FIG. A comprehensive judgment is made on the judgment result of each judgment of 1 to judge whether or not a chapter based on the video data obtained by shooting is to be added to the playlist file as a candidate for additional recording.
  • the control unit 30 Based on the result of this determination, if it is determined that the appending is to be added, the appendix is appended to the playlist file of the appending candidate stored in the volatile memory 17 and if it is determined not to append, the new The management information processing unit 16 is controlled so that a playlist file is generated and recorded for this new playlist file.
  • a control signal for instructing the recording start is supplied from the UI unit 31 to the control unit 30 and based on the control of the control unit 30. Recording of the baseband digital video signal and digital audio data output from the camera unit 50 to the recording medium 20 is started.
  • the operations of the video encoder 1 1 and the audio encoder 1 2 are started based on the control of the control unit 30, and the video data and the audio data are compressed by the video encoder 1 1 and the audio encoder 1 2, respectively.
  • the AV stream data is supplied to the recording control unit 15 via the stream buffer 14 and is recorded on the recording medium 20 as a clip AV stream file.
  • the management information processing unit 16 creates a clip information file corresponding to the clip AV stream file recorded on the recording medium 20 based on information from the multiplexer 13 and the recording control unit 15, and Create a play item that references the clip information file.
  • the recording switch When the recording switch is pressed again from this state, it is instructed to start recording again, and recording of a new clip AV stream file to the recording medium 20 is started. At the start of this re-recording, it is advisable to determine whether or not to allow additional recording based on the new recording for the playlist file as a candidate for additional recording, according to the flow chart in Fig. 43.
  • the recording device shown in FIG. 41 and the recording unit 10 of the video camera device 100 shown in FIG. 53 are configured as hardware. It is not limited. That is, the recording unit 10 can also be configured as software. In this case, the software is stored in advance in a ROM (not shown) included in the control unit 30, for example. The present invention is not limited to this, and the recording unit 10 can be configured on a computer device such as a personal computer. In this case, software for causing the computer unit to execute the recording unit 10 is provided by being recorded on a recording medium such as CD-ROM or DV-ROM. If the computer device can be connected to the network, the software can be provided via a network such as the Internet.

Abstract

記録開始から停止の間に生成されるＡＶデータをファイルとして記録する際のユーザの利便性を向上させる。記録開始から停止の間に生成されるＡＶデータをファイルとして記録し、再生区間を示す情報とジャンプ位置を示すマーク情報とを再生リストファイルに追記する。このとき、追記候補の再生リストファイルと、ＡＶデータの再生時刻とアドレスとを対応付ける属性ファイルとに基づき、追記に際して、再生リストファイルや属性ファイルに予め設定された制約を満足するか否かが判断される。満足すると判断されれば、再生区間情報とマーク情報とが追記候補の再生リストファウルに追記される。満足しないと判断されれば、新規に再生リストファイルが生成される。ユーザは、再生リストファイルや属性ファイルに予め設定された制約を意識せずに、ＡＶデータの記録操作を行うことができる。

Description

明 細 書
記録装置、 記録方法および記録プログラム、 ならびに、 撮像装置、 撮像方法および撮像プログラム 技術分野
この発明は、 ビデオデータとオーディオデータとを多重化したスト リームデータを記録媒体に記録するのに適した記録装置、 記録方法お よび記録プログラム、 ならびに、 撮像装置、 撮像方法および撮像プロ グラムに関する。 背景技術
従来から、 記録可能で記録再生装置から取り外し可能とされると共 に、 記録容量が比較的大きく、 ビデオデータとオーディオデータとか らなる A V (Aud i o/Vi deo)データを記録するのに適した記録媒体とし て、 4 . 7 G B (Giga Byte)以上の記録容量を有する D V D (Digi t al Versat i l e Di sc)が普及している。 特許文献 「特開 2 0 0 4 - 3 5 0 2 5 1」 には、 記録可能なタイプの D V Dに対して D V D— V i d e oフォーマツトで記録する撮像装置が記載されている。
ところで、 記録媒体に対するビデオデータおよびオーディォデ一夕 の記録は、 一般的には、 記録開始操作から記録停止操作の間に生成さ れるビデオデータを単位として行われる。 そして、 記録開始操作から 記録停止操作の間に生成されるビデオデータ対して、 再生リスト情報 を用いて再生区間や再生順序を指定することが一般的に行われている 。 記録された A Vストリームを、 記録開始操作から記録停止操作の間 に生成されるビデオデ一夕を単位として、 再生リスト情報を用いて管 理することで、 記録媒体上の A Vストリームを加工することなく、 当 該 A Vストリームの再生区間や再生順序を自在に設定した編集を容易 に行うことができる。
ここで、 ビデオデータおよびオーディォデ一夕をファイルとして記 録媒体に記録することを考える。 例えば、 ビデオデータおよびオーデ ィォデータを、 記録開始操作から記録停止操作の間に生成されるデー 夕を単位としてファイルとして記録する。 ビデオデータおよびオーデ ィォデータをファイルとして記録することで、 コンピュータ装置など の他の装置との親和性が増し、 記録されたデータをより有効に活用す ることができることが期待される。
このように、 ビデオデータおよびオーディオデータをファイルとし て記録する場合、 一連の記録開始および停止の操作に伴い 1の記録媒 体に順次記録されていく複数単位のビデオデータおよびオーディオデ 一夕を記録順に連続的に再生するためには、 何らかの工夫が必要とな る。 例えば、 一連の記録開始および停止の操作に伴い 1の記録媒体に 順次記録されていく複数単位のビデオデータおよびオーディォデ一夕 の情報を、 再生リスト情報が格納される 1の再生リス卜ファイルに対 して順次、 追記していくように制御することが考えられる。 このよう に記録制御を行うことで、 記録媒体に単位毎に記録された一連の複数 単位のビデオデータおよびオーディオデータを連続的に再生するのが 容易となる。
記録開始操作および停止操作毎に順次記録されるビデオデータおよ びオーディオデータの情報を再生リストファイルに対して追記してい くように制御する場合、 記録開始および停止の操作が繰り返される度 に、 再生リストファイルのデータサイズが増大することになる。 一方 、 記録装置や再生装置では、 再生リス卜ファイルを一旦メモリに読み 込んで、 ファイルとして記録されたビデオデータおよびオーディオデ 一夕の再生制御を行うことが考えられる。 メモリには、 記録媒体に記 録されるビデオデータおよびオーディオデータを管理する他の管理情 報も読み込まれるため、 再生リストファイルのサイズが増大するとメ モリの容量を圧迫してしまい、 他の処理に支障が出るおそれがあると いう問題点があった。
また、 ビデオデ一夕およびオーディォデータをファイルとして記録 する場合、 再生時にビデオデータ内のフレームを検索したり、 フレー ム単位での編集を容易に行えるような仕組みを提供する必要がある。 このためには、 例えばビデオデータにおける再生時間情報と、 ビデオ データが格納されるファイル内のァドレスとを対応付けることが考え られる。 この再生時間情報とファイル内ァドレスとの対応関係を示す データは、 記録に伴い増加するため、 この場合においても、 記録時や 再生時においてメモリ容量を圧迫してしまい、 他の処理に支障が出る おそれがあるという問題点があった。
さらに、 メモリ容量が圧迫された状態で例えば記録を続行しようと した場合、 システムによって強制的にビデオデータおよびオーディオ デ一タの記録が停止されたり、 システムがハングアップしてしまう可 能性があるという問題点があつた。
また、 近年では、 一般的に用いられるビデオフォーマットの種類が より多彩になってきている。 例えば、 ライン数と走査方法に関しては 、 インタレース走査のフォーマットでは、 ライン数が 4 8 0本の 4 8 0 i、 ライン数が 5 7 6本の 5 7 6 i、 ライン数が 1 0 8 0本の 1 0 8 0 iなどがあり、 プログレッシブ走査のフォーマットでは、 ライン 数がそれぞれ 4 8 0本、 5 7 6本、 7 2 0本および 1 0 8 0本の、 4 8 0 p 5 7 6 p , 7 2 0 pおよび 1 0 8 0 ρなどが規定されている 記録装置においても、 上述のような多種類のフォーマツトに対応し た記録が可能なことが求められる。 それと共に、 1の記録媒体に対し て複数種類のフォーマットによるビデオデータを混在して記録可能な ことが求められる。 しかしながら、 上述したように、 記録媒体にファ ィルとして順次記録されるビデオデータおよびオーディォデータの情 報を、 1の再生リストファイルに対して追記していくように記録制御 を行う場合、 当該記録媒体を再生する再生装置側で問題が発生する可 能性がある。 例えば、 再生リストファイルに従い順次、 ファイルとし て記録されたビデオデータおよびオーディオデータを再生していく際 に、 今まで再生していたビデオデータとフォーマットが異なるビデオ データを次に連続的に再生しょうとしても、 デコーダの処理の切り換 えが間に合わなかったり、 デコーダが八ングアップして動作が停止し てしまうおそれがあるという問題点があった。 . 発明の開示
したがって、 この発明の目的は、 記録開始操作から記録停止操作の 間に生成されるビデオデー夕およびオーディォデータをファイルとし て記録する際のユーザの利便性を向上させることができる記録装置、 記録方法および記録プログラム、 ならびに、 撮像装置、 撮像方法およ び撮像プログラムを提供することにある。
上述した課題を解決するために、 第 1の発明は、 ビデオデータとォ 一ディォデ一夕とを多重化して記録媒体に記録する記録装置において ビデオデータおよびオーディォデータが入力されるデータ入力部と ビデオデータおよびオーディォデ一夕の記録開始および記録停止の 指示が入力される記録指示入力部と、 ビデオデータおよびオーディオ データを多重化し、 多重化されたストリームをストリームファイルと して記録媒体に記録する記録部と、 ストリームファイルの属性情報を 示す第 1の管理情報と、 ストリームファイルの再生方法を示す情報を 含む第 2の管理情報とからなる、 記録媒体に記録されるストリームフ アイルの再生を制御するための再生管理情報を生成する管理情報生成 部とを有し、 管理情報生成部は、 既存の再生管理情報に基づき、 記録 指示入力部による記録開始の指示に従い記録媒体に記録されるストリ —ムファイルに対する再生方法を示す情報を、 既存の再生管理情報に 含まれる所定の第 2の管理情報に対して追記するか否かの追記可否判 断を行うことを特徴とする記録装置である。
また、 第 2の発明は、 ビデオデータとオーディオデータとを多重化 して記録媒体に記録する記録方法において、 データ入力部に入力され たビデオデータおよびオーディオデータの記録開始および記録停止の 指示が入力される記録指示入力のステップと、 ビデオデー夕およびォ 一ディォデータを多重化し、 多重化されたストリームをストリ一ムフ アイルとして記録媒体に記録する記録のステップと、 ストリームファ ィルの属性情報を示す第 1の管理情報と、 ストリームファイルの再生 方法を示す情報を含む第 2の管理情報とからなる、 記録媒体に記録さ れるストリームファイルの再生を制御するための再生管理情報を生成 する管理情報生成のステップとを有し、 管理情報生成のステップは、 既存の再生管理情報に基づき、 記録指示入力のステップによる記録開 始の指示に従い記録媒体に記録されるストリームファイルに対する再 生方法を示す情報を、 既存の再生管理情報に含まれる所定の第 2の管 理情報に対して追記するか否かの追記可否判断を行うことを特徴とす る記録方法である。
また、 第 3の発明は、 ビデオデータとオーディオデータとを多重化 して記録媒体に記録する記録方法をコンピュータ装置に実行させる記 録プログラムにおいて、 記録方法は、 データ入力部に入力されたビデ ォデ一夕およびオーディォデータの記録開始および記録停止の指示が 入力される記録指示入力のステップと、 ビデオデータおよびオーディ ォデ一夕を多重化し、 多重化されたストリームをストリームファイル として記録媒体に記録する記録のステップと、 ストリームファイルの 属性情報を示す第 1の管理情報と、 ストリームファイルの再生方法を 示す第 2の管理情報とからなる、 記録媒体に記録されるストリームフ アイルの再生を制御するための再生管理情報を生成する管理情報生成 のステップとを有し、 管理情報生成のステップは、 既存の再生管理情 報に基づき、 記録指示入力のステップによる記録開始の指示に従い記 録媒体に記録されるストリームファイルに対する再生方法を示す情報 を、 既存の再生管理情報に含まれる所定の第 2の管理情報に対して追 記するか否かの追記可否判断を行うことを特徴とする記録プログラム である。
また、 第 4の発明は、 撮像部で被写体を撮像して得られたビデオデ 一夕と、 収音部で音声を収音して得られたオーディォデ一夕とを多重 化して記録媒体に記録する撮像装置において、 被写体を撮像してビデ ォデ一夕を出力する撮像部と、 音声を収音してオーディオデータを出 力する収音部と、 ビデオデータおよびオーディォデータを多重化し、 多重化されたストリームをストリームファイルとして記録媒体に記録 する記録部と、 ビデオデータおよびオーディォデータの記録媒体への 記録開始および記録停止を指示するユーザ操作を け付ける操作部と 、 ストリームファイルの属性情報を示す第 1の管理情報と、 ストリー ムファイルの再生方法を示す情報を含む第 2.の管理情報とからなる、 記録媒体に記録されるストリームファイルの再生を制御するための再 生管理情報を生成する管理情報生成部とを有し、 管理情報生成部は、 既存の再生管理情報に基づき、 操作部に対するユーザ操作に応じた記 録開始の指示に従い記録媒体に記録されるストリームファイルに対す る再生方法を示す情報を、 既存の再生管理情報に含まれる所定の第 2 の管理情報に対して追記するか否かの追記可否判断を行うことを特徴 とする撮像装置である。
また、 第 5の発明は、 撮像部で被写体を撮像して得られたビデオデ —夕と、 収音部で音声を収音して得られたォ一ディォデータとを多重 化して記録媒体に記録する撮像装置の撮像方法において、 撮像部で被 写体を撮像して得られたビデオデータと、 収音部で音声を収音して得 られたオーディオデータとを多重化し、 多重化されたストリームをス トリームファイルとして記録媒体に記録する記録のステップと、 操作 部に対するビデオデータおよびオーディオデ一夕の記録媒体への記録 開始および記録停止を指示するユーザ操作を受け付けるステップと、 ストリームファイルの属性情報を示す第 1の管理情報と、 ストリーム ファイルの再生方法を示す情報を含む第 2の管理情報とからなる、 記 録媒体に記録されるストリームファイルの再生を制御するための再生 管理情報を生成する管理情報生成のステップとを有し、 管理情報生成 のステップは、 既存の再生管理情報に基づき、 操作部に対するユーザ 操作に応じた記録開始の指示に従い記録媒体に記録されるストリーム ファイルに対する再生方法を示す情報を、 既存の再生管理情報に含ま れる所定の第 2の管理情報に対して追記するか否かの追記可否判断を 行うことを特徴とする撮像方法である。
また、 第 6の発明は、 撮像部で被写体を撮像して得られたビデオデ 一夕と、 収音部で音声を収音して得られたオーディオデータとを多重 化して記録媒体に記録する撮像装置の撮像方法をコンピュータ装置に 実行させる撮像プログラムにおいて、 撮像方法は、 撮像部で被写体を 撮像して得られたビデオデータと、 収音部で音声を収音して得られた オーディオデータとを多重化し、 多重化されたストリームをストリー ムファイルとして記録媒体に記録する記録のステップと、 操作部に対 するビデオデータおよびオーディオデータの記録媒体への記録開始お よび記録停止を指示するユーザ操作を受け付けるステップと、 ストリ ームフアイルの属性情報を示す第 1の管理情報と、 ストリームフアイ ルの再生方法を示す情報を含む第 2の管理情報とからなる、 記録媒体 に記録されるス卜リームファイルの再生を制御するための再生管理情 報を生成する管理情報生成のステップとを有し、 管理情報生成のステ ップは、 既存の再生管理情報に基づき、 操作部に対するユーザ操作に 応じた記録開始の指示に従い記録媒体に記録されるストリームフアイ ルに対する再生方法を示す情報を、 既存の再生管理情報に含まれる所 定の第 2の管理情報に対して追記するか否かの追記可否判断を行うこ とを特徴とする撮像プログラムである。
上述したように、 第 1、 第 2および第 3の発明は、 ビデオデータお よびオーディォデ一夕が多重化されたストリームからなるストリーム ファイルの属性情報を示す第 1の管理情報と、 ストリームファイルの 再生方法を示す情報を含む第 2の管理情報とからなる、 記録媒体に記 録されるストリームファイルの再生を制御するための再生管理情報を 生成するようにされ、 既存の再生管理情報に基づき、 ビデオデータの 記録開始の指示に従い記録媒体に記録されるストリームファイルに対 する再生方法を示す情報を、 既存の再生管理情報に含まれる所定の第 2の管理情報に対して追記するか否かの追記可否判断を行うようにし ているため、 記録開始操作および記録停止操作を繰り返し行つた場合 でも、 ュ一ザが意識することなく、 第 2の管理情報の生成が適切に制 御される。 また、 第 4、 第 5および第 6の発明は、 撮像されて得られたビデオ データと収音されて得られたオーディオデータとが多重化されたス卜 リームからなるストリームフアイルの属性情報を示す第 1の管理情報 と、 ストリームファイルの再生方法を示す情報を含む第 2の管理情報 とからなる、 記録媒体に記録されるストリームファイルの再生を制御 するための再生管理情報を生成するようにされ、 既存の再生管理情報 に基づき、 操作部に対するユーザ操作に応じた記録開始の指示に従い 、 記録媒体に記録される被写体を撮影して得られたビデオデータから なるストリームファイルに対する再生方法を示す情報を、 既存の再生 管理情報に含まれる所定の第 2の管理情報に対して追記するか否かの 追記可否判断を行うようにしているため、 撮影に際して記録開始操作 および記録停止操作を繰り返し行った場合でも、 ユーザが意識するこ となく、 第 2の管理情報の生成が適切に制御される。
第 1、 第 2および第 3の発明は、 上述したように、 ビデオデ一夕お よびオーディォデータが多重化されたストリームからなるストリーム ファイルの属性情報を示す第 1の管理情報と、 ストリームファイルの 再生方法を示す情報を含む第 2の管理情報とからなる、 記録媒体に記 録されるストリームファイルの再生を制御するための再生管理情報を 生成するようにされ、 既存の再生管理情報に基づき、 ビデオデータの 記録開始の指示に従い記録媒体に記録されるストリームファイルに対 する再生方法を示す情報を、 既存の再生管理情報に含まれる所定の第 2の管理情報に対して追記するか否かの追記可否判断を行うようにし ているため、 記録開始操作および記録停止操作を繰り返し行った場合 でも、 ユーザが意識することなく、 第 2の管理情報の生成が適切に制 御される効果がある。
また、 第 4、 第 5および第 6の発明は、 上述したように、 撮像され て得られたビデオデータと収音されて得られたオーディオデータとが 多重化されたストリームからなるストリームファイルの属性情報を示 す第 1の管理情報と、 ストリームファイルの再生方法を示す情報を含 む第 2の管理情報とからなる、 記録媒体に記録されるストリームファ ィルの再生を制御するための再生管理情報を生成するようにされ、 既 存の再生管理情報に基づき、 操作部に対するユーザ操作に応じた記録 開始の指示に従い、 記録媒体に記録される被写体を撮影して得られた ビデオデータからなるストリームファイルに対する再生方法を示す情 報を、 既存の再生管理情報に含まれる所定の第 2の管理情報に対して 追記するか否かの追記可否判断を行うようにしているため、 撮影に際 して記録開始操作および記録停止操作を繰り返し行った場合でも、 ュ 一ザが意識することなく、 第 2の管理情報の生成が適切に制御される 効果がある。 図面の簡単な説明
第 1図は、 この発明に適用可能な A V C H Dフォーマツトに規定さ れるデ一夕モデルを概略的に示す略線図、 第 2図は、 インデックステ 一ブルを説明するための略線図、 第 3図は、 クリップ A Vストリーム 、 クリップ情報、 クリップ、 プレイアイテムおよびプレイリストの関 係を示す UM L図、 第 4図は、 複数のプレイリストから同一のクリツ プを参照する方法を説明するための略線図、 第 5図は、 記録媒体に記 録されるファイルの管理構造を説明するための略線図、 第 6図は、 フ アイル" index, bdmv"の一例の構造を表すシンタクスを示す略線図、 第 7図は、 プロック blklndexes Oの一例の構造を表すシンタクスを示す 略線図、 第 8図は、 ファイル" MovieObj ec t . bdmv"の一例の構造を表す シンタクスを示す略線図、 第 9図は、 ブロック b ikMovi eObj ec is Oの 一例の構造を表すシンタクスを示す略線図、 第 10図は、 プレイリス トファイル" xxxxx.即 Is"の一例の構造を表すシンタクスを示す略線図 、 第 1 1図は、 ブロック blkPIayUstOの一例の構造を表すシンタク スを示す略線図、 第 1 2図は、 ブロック blkPlayltemOの一例の構造 を表すシンタクスを示す略線図、 第 1 3図 Aおよび第 1 3図 Bは、 第 1および第 2のシームレス接続を説明するための略線図、 第 14図は 、 ブロック MkPlayListMarkOの一例の構造を表すシンタクスを示す 略線図、 第 1 5図は、 クリップインフォメーションファイルの一例の 構造を表すシンタクスを示す赂線図、 第 1 6図は、 プロック blkClipI ηίοθの一例の構造を表すシンタクスを示す略線図、 第 1 7図は、 ブ 口ック blkProgramlnfoOの一例の構造を表すシンタクスを示す略線図 、 第 1 8図は、 ブロック blkStreamCodingInfo(stream— index)の一例 の構造を表すシンタクスを示す略線図、 第 1 9図は、 フィールド Vide oFormatで示されるビデオデータの一例のフォーマツトを一覧で示す 略線図、 第 20図は、 フィールド FrameRateで示される一例のフレー ムレートを一覧で示す略線図、 第 2 1図は、 フィールド AspectRatio で示される一例のフレームレ一トを一覧で示す略線図、 第 22図は、 ブロック MkCPlOの一例の構造を表すシンタクスを示す略線図、 第 2 3図は、 ブロック blkEPMapOの一例の構造を表すシンタクスを示す略 線図、 第 24図は、 ブロック blkEPMapForOneStreamPID(EP_streafflJy pe， Nc, Nf)の一例の構造を表すシンタクスを示す略線図、 第 2 5図 は、 ェントリ PTSEPCoarseおよびェントリ PTSEPFineの一例のフォーマ ットについて示す略線図、 第 26図は、 エントリ SPNEPCoarseおよび ェントリ SPNEPFineの一例のフォーマツトについて示す略線図、 第 2 7図は、 ブロック blkExtensionDataOの一例の構造を表すシンタクス を示す略線図、 第 28図は、 ブロック MkExtensionDataOにおける各 データの参照関係を模式的に示す略線図、 第 29図は、 ブロック blkE xtensionDataOにデータを書き込む際の一例の処理を示すフローチヤ ート、 第 30図は、 ブロック blkExtensionDataOから拡張データを読 み出す際の一例の処理を示すフローチャート、 第 3 1図は、 ファイル " index, bdmv"内のフィール HblkExtensionDataOにおけるプロック Da taBlockOの一例の構造を表すシンタクスを示す略線図、 第 32図は 、 ブロック blkTableOfPlayListOの一例の構造を表すシンタクスを示 す略線図、 第 33図は、 プレイリストファイル" xxxxx.mpls"内のプロ ック blkExtensionDataOにおけるブロック DataBlockOの一例の構造 を表すシンタクスを示す略線図、 第 34図は、 ブロック blkPlayListM eta()の一例の構造を表すシンタクスを示す略線図、 第 35図は、 プ レイリストファイルにおけるブロック MkMakersPrivateDataOの一例 の構造を表すシンタクスを示す略線図、 第 36図は、 クリップインフ オメーションファイル内のブロック blkExtensionDataOにおけるブロ ック Da BlockOの一例の構造を表すシンタクスを示す略線図、 第 3 7図は、 ブロック blkProgramlnfoExt 0の一例の構造を表すシンタク スを示す略線図、 第 38図は、 ブロック blkStreamCodingInfoExt(i，j )の一例の構造を表すシンタクスを示す略線図、 第 39図 Aおよび第 39図8は、 仮想プレーヤの動作を概略的に示すフローチャート、 第 40図は、 仮想プレーヤの動作を概略的に示す略線図、 第 41図は、 この発明の実施の一形態に適用可能な記録装置の一例の構成を概略的 に示すプロック図、 第 42図は、 この発明の実施の一形態に適用可能 な一例のデータ構造を示す略線図、 第 43図は、 チヤプ夕のプレイリ ストファイルへの追記可否を判定する一例の処理を示すフローチヤ一 ト、 第 44図は、 プレイアイテム数に基づく追記可否判断の一例の処 理を示すフローチャート、 第 45図は、 プレイリストマーク数に基づ P2007/060081 く追記可否判断の一例の処理を示すフローチャート、 第 4 6図は、 ビ デォ属性に基づく追記可否判断の一例の処理を示すフローチャート、 第 4 7図は、 ファイルサイズに基づく追記可否判断の一例の処理を示 すフローチャート、 第 4 8図は、 追記候補プレイリストファイルから 参照されるクリップインフォメーションファイルの合計ファイルサイ ズに基づく追記可否判断の一例の処理を示すフローチャート、 第 4 9 図は、 追記候補プレイリストファイルから参照されるクリップィンフ オメーシヨンファイルに格納されるェン卜リポイントの合計数に基づ く追記可否判断の一例の処理を示すフローチャート、 第 5 0図は、 他 機による独自の拡張データの有無に基づく追記可否判定の一例の処理 を示すフロ一チヤ一ト、 第 5 1図は、 追記候補プレイリストファイル の最終更新者に基づく追記可否判定の一例の処理を示すフローチヤ一 ト、 第 5 2図は、 この発明の実施の一形態によるクリップの一例の記 録方法を示すフローチャート、 第 5 3図は、 この発明の実施の一形態 の他の例によるビデオカメラ装置の一例の構成を示すブロック図であ る。 発明を実施するための最良の形態
以下、 この発明の実施の一形態を、 図面を参照しながら説明する。 先ず、 理解を容易とするために、 この発明に適用可能な一例のフォー マット （以下、 A V C H Dフォーマットと呼ぶ） について説明する。 A V C H Dフォ一マツトは、 ビデオデ一夕とオーディォデータとが所 定に多重化された A V (Audi o/Vi deo)ストリームを記録可能な記録媒 体に記録する記録フォ一マツトとして現在提案されているもので、 記 録媒体に記録された A Vストリームを、 クリップ単位でプレイリスト を用いて管理可能としている。 例えば I TU— T (International Telecommunication Union - Telec ommunicat ion Standarization Sector)勧告 H. 264あるレ は I S O (Internat ional Organization for Standarization)/ I E C (Inte rnational Electrotechnical Commission)国際標準 14496- 10 (MP EG— 4パート 10) Advanced Video Coding (以下、 H. 2 64 I AVCと略称する） に規定される符号化方式で符号化され、 M PEG 2システムズに従い多重化されたビットストリームは、 クリツ プ A Vストリーム （または A Vストリーム） と称される。 クリップ A Vストリームは、 所定のファイルシステムによりファイルとしてディ スクに記録される。 このファイルを、 クリップ AVストリームフアイ ル （または AVストリームファイル） と称する。
クリップ AVストリームファイルは、 ファイルシステム上での管理 単位であり、 ユーザにとつて必ずしも分かりやすい管理単位であると は限らない。 ユーザの利便性を考えた場合、 複数のクリップ AVスト リームファイルに分割された映像コンテンツを一つにまとめて再生す る仕組みや、 クリップ AVストリームファイルの一部だけを再生する 仕組み、 さらには、 特殊再生や頭出し再生を滑らかに行うための情報 などをデータベースとしてディスクに記録しておく必要がある。
第 1図は、 この発明に適用可能な A VCHDフォーマツトに規定さ れるデータモデルを概略的に示す。 この AVCHDフォーマットによ れぱ、 データ構造は、 第 1図に示されるように 4層のレイヤよりなる 。 最も最下層のレイヤは、 クリップ AVストリームが配置されるレイ ャである （便宜上、 クリップレイヤと呼ぶ） 。 その上のレイヤは、 ク リップ AVストリームに対する再生箇所を指定するための、 プレイリ スト（PlayList)と、 プレイアイテム（Playltem)とが配置されるレイヤ である （便宜上、 プレイリストレイヤと呼ぶ） 。 さらにその上のレイ ャは、 プレイリストに対して再生順などを指定するコマンドからなる ムービーオブジェクト（Movie Object)などが配置されるレイヤである (便宜上、 オブジェクトレイヤと呼ぶ） 。 最上層のレイヤは、 記録媒 体に格納されるタイトルなどを管理するィンデックステ一ブルが配置 される （便宜上、 インデックスレイ'ャと呼ぶ） 。
クリップレイヤについて説明する。 クリップ A Vストリームは、 ビ デォデータやオーディオデータが MP EG 2 TS (トランスポート ストリーム） の形式などに多重化されたビットストリームである。 こ のクリップ AVストリームに関する情報がクリップ情報（Clip Inform ation)としてファイルに記録される。
また、 クリップ AVストリームには、 字幕を表示するグラフィクス ストリームである OBストリーム（Overlay Bitmap stream)や、 メニ ユー表示などに用いられるデータ （ポタン画像データなど） をストリ ームにした MBストリーム（Menu Bitmap stream)を多重化することが できる。
クリップ AVストリームファイルと、 対応するクリップ情報が記録 されたクリップ情報ファイルとをひとまとまりのオブジェクトと見な し、 クリップ（Clip)と称する。 すなわち、 クリップは、 クリップ AV ストリームとクリップ情報とから構成される、 一つのオブジェクトで ある。
ファイルは、 一般的に、 バイト列として扱われる。 クリップ AVス 卜リームファイルのコンテンツは、 時間軸上に展開され、 クリップ中 のエントリーポイントは、 主に時間ベースで指定される。 所定のクリ ップへのアクセスボイントのタイムスタンプが与えられた場合、 クリ ップ AVストリームファイルの中でデータの読み出しを開始すべきァ ドレス情報を見つけるために、 クリップ情報ファイルを用いることが できる。 - プレイリストレイヤについて説明する。 プレイリストは、 再生する
AVストリームファイルの指定と、 指定された A Vストリームフアイ ルの再生箇所を指定する再生開始点 （ I N点） と再生終了点 （OUT 点） の集まりとから構成される。 この再生開始点と再生終了点の情報 を一組としたものは、 プレイアイテム（Playltem)と称される。 プレイ リストは、 プレイアイテムの集合で構成される。 プレイアイテムを再 生するということは、 そのプレイアイテムに参照される A Vストリー ムファイルの一部分を再生するということになる。 すなわち、 プレイ アイテム中の I N点および OUT点情報に基づき、 クリップ中の対応 する区間が再生される。
オブジェクトレイヤについて説明する。 ムービーォブジェクトは、 ナビゲーションコマンドプログラムと、 ムービーオブジェクトとを連 携するターミナルインフォメーションを含む。 ナピゲ一ションプログ ラムは、 プレイリストの再生を制御するためのコマンド （ナビゲーシ ョンコマンド ： navigation command) である。
ィンデックスレイヤについて説明する。 インデックスレイヤは、 ィ ンデックステ一ブル（Index Table)からなる。 インデックステーブル は、 記録媒体に記録されたコンテンツのタイトルを定義する、 トップ レベルのテーブルである。 インデックステ一ブルに格納されている夕 ィトル情報に基づき、 プレーヤに常駐されるシステムソフトウェア中 のモジュールマネージャにより記録媒体の再生が制御される。
すなわち、 第 2図に概略的に示されるように、 インデックステープ ル中の任意のエントリは、 タイトルと称され、 インデックステーブル にエントリされるファーストプレイバックタイトル（First PlaybackT itle)、 メニュータイトル（MenuTiUe)およびムービータイトル（Movie Title)# l、 # 2、 · · ·は、 全てタイトルである。 各タイトルは、 ムービーオブジェク卜に対するリンクを示す。
理解を容易とするため再生専用の記録媒体を例にとると、 例えば、 ファーストプレイバックタイトルは、 当該記録媒体に格納されるコン テンッが映画であれば、 映画本編に先立って映出される映画会社の宣 伝用映像 （トレーラ） に対応する。 メニュータイトルは、 例えばコン テンッが映画である場合、 本編再生、 チヤプタサーチ、 字幕や言語設 定、 特典映像再生などを選択するためのメニュー画面に対応する。 ま た、 ムービータイトルは、 メニュータイトルから選択される各映像で ある。 タイトルがさらにメニュー画面であるような構成も可能である 第 3図は、 上述のようなクリップ A Vストリーム、 クリップ情報（S tream Attributes), クリップ、 プレイアイテムおよびプレイリスト の関係を示す UML (Unified Modeling Language)図である。 プレイ リストは、 1または複数のプレイアイテムに対応付けられ、 プレイァ ィテムは、 1のクリップに対応付けられる。 1のクリップに対して、 それぞれ開始点およびノまたは終了点が異なる複数のプレイアイテム を対応付けることができる。 1のクリップから 1のクリップ AVスト リームファイルが参照される。 同様に、 1のクリップから 1のクリツ プ情報ファイルが参照される。 また、 クリップ A Vストリームフアイ ルとクリップ情報ファイルとは、 1対 1の対応関係を有する。 このよ うな構造を定義することにより、 クリップ AVス卜リームファイルを 変更することなく、 任意の部分だけを再生する、 非破壊の再生順序指 定を行うことが可能となる。
また、 第 4図のように、 複数のプレイリストから同一のクリップを 参照することもできる。 また、 1のプレイリストから複数のクリップ を指定することもできる。 クリップは、 プレイリスト中のプレイアイ テムに示される I N点および O U T点により、 参照される。 第 4図の 例では、 クリップ 3 0 0は、 プレイリスト 3 1 0のプレイアイテム 3 2 0から参照されると共に、 プレイリスト 3 1 1を構成するプレイァ ィテム 3 2 1および 3 2 2のうちプレイアイテム 3 2 1から、 I N点 および O U T点で示される区間が参照される。 また、 クリップ 3 0 1 は、 プレイリスト 3 1 1のプレイアイテム 3 2 2から I N点および O U T点で示される区間が参照されると共に、 プレイリスト 3 1 2のプ レイアイテム 3 2 3および 3 2 4のうち、 プレイアイテム 3 2 3の I N点および O U T点で示される区間が参照される。 第 4図の例では、 クリップ 3 0 1は、 さらに別のプレイリストからも参照されている。 次に、 A V C H Dフォーマットによる、 記録媒体に記録されるファ ィルの管理構造について、 第 5図を用いて説明する。 ファイルは、 デ ィレクトリ構造により階層的に管理される。 記録媒体上には、 先ず、 1つのディレクトリ (第 5図の例ではルート（roo t)ディレクトリ） が 作成される。 このディレクトリの下が、 1つの記録再生システムで管 理される範囲とする。
ルートディレクトリの下に、 ディレクトリ" BDMV"が置かれる。 さら に必要に応じて、 ルートディレクトリの下にディレクトリ" AVCHDTN" がおかれる。 ディレクトリ " AVCHDTN"には、 例えばクリップの代表画 像を所定サイズに縮小したサムネイルファイルが置かれる。 ディレク トリ" BDMV"に、 第 1図を用いて説明したデータ構造が格納される。 ディレクトリ" BDMV"の直下には、 ファイルは、 ファイル" index, bdm v"およびファイル" MovieObj ec t . bdmv"の 2つのみを置くことができる 。 また、 ディレクトリ" BDMV"の下に、 ディレクトリ" PLAYL IST："、 ディ レクトリ" CL IP INF"、 ディレクトリ" STREAM"およびディレクトリ" BACK m»"が置かれる。 ディレクトリ" BACK "は、 各ディレクトリおよびフ アイルのバックァップが格納される。
ファイル "index, bdmv"は、 ディレクトリ BDMVの内容について記述さ れる。 すなわち、 このファイル" index. bdmv"が上述した最上層のレイ ャであるィンデックスレイヤにおけるィンデックステーブルに対応す る。 また、 ファイル MovieObject.bdmvは、 1つ以上のムービーォブジ ェクトの情報が格納される。 すなわち、 このファイル" MovieObject.b dmv"が上述したオブジェクトレイヤに対応する。
ディレクトリ" PLAYLIST"は、 プレイリストのデ一夕ベースが置かれ るディレクトリである。 すなわち、 ディレクトリ "PLAYLIST"は、 プレ ィリストに関するファイルであるファイル" xxxxx.即 Is"を含む。 ファ ィル" xxxxx.mpls"は、 プレイリス卜のそれぞれに対して作成されるフ アイルである。 ファイル名において、 "." （ピリオド） の前の" xxxxx" は、 5桁の数字とされ、 ピリオドの後ろの" mpls"は、 このタイプのフ アイルに固定的とされた拡張子である。
ディレクトリ" CLIPINF"は、 クリップのデータベースが置かれるデ ィレクトリである。 すなわち、 ディレクトリ CLIPINF"は、 クリップ A Vストリームファイルのそれぞれに対するクリップィンフオメ一ショ
Figure imgf000021_0001
zzzzz. clpi"を含む。 ファイル名において 、 "." (ピリオド） の前の" zzzzz"は、 5桁の数字とされ、 ピリオドの 後ろの" clpi"は、 このタイプのファイルに固定的とされた拡張子であ る。
ディレクトリ" STREAM"は、 実体としての AVストリームファイルが 置かれるディレクトリである。 すなわち、 ディレクトリ" STREAM"は、 クリップインフォメーションフアイルのそれぞれに対応するクリツプ AVストリームファイルを含む。 クリップ A ストリームファイルは 、 MP E G 2 (Moving Pictures Experts Group 2)のトランスポート ストリーム （以下、 MPEG2 TSと略称する） からなり、 フアイ ル名が" zzzzz.iii2ts"とされる。 ファイル名において、 リオドの前の "zzzzz"は、 対応するクリップインフォメーションファイルと同一す ることで、 クリップインフォメーションファイルとこのクリップ AV ス卜リームファイルとの対応閼係を容易に把握することができる。 なお、 ディレクトリ" AVCHDTN"は、 2種類のサムネイルファイル thu mbnail. tidxおよび thumbnail. tdt2を置くことができる。 サムネイル ファイル thumbnail. Udxは、 所定の方式で暗号化されたサムネイル画 像が格納される。 サムネイルファイル thumbnail. tdt2は、 暗号化され ていないサムネイル画像が格納される。 例えばビデオカメラでユーザ が撮影したクリップに対応するサムネイル画像は、 コピーフリーであ つて暗号化する必要が無いと考えられるため、 このサムネイルフアイ ；!/ thumbnail. tdt2に格納される。
第 5図で示した各ファイルのうち、 この発明に関わりの深いものに ついて、 より詳細に説明する。 先ず、 ディレクトリ" BDMV"の直下に置 かれるファイル" index. bdmv"について説明する。 第 6図は、 このファ ィル" index, bdmv"の一例の構造を表すシンタクスを示す。 ここでは、 シンタクスをコンピュータ装置などのプログラムの記述言語として用 いられる C言語の記述法に基づき示す。 これは、 他のシンタクスを表 す図において、 同様である。
第 6図において、 フィールド TypeindicsLtorは、 32ビットのデー 夕長を有し、 このファイルがィンデックステ一ブルであることを示す 。 フィールド TypeIndicator2は、 32ビットのデータ長を有し、 この ファイル" index, bdmv"のパージヨンを示す。 フィールド IndexesStart Addressは、 32ビットのデ一タ長を有し、 このシンタクス内にある プロック blklndexesOの開始ァドレスを示す。
フィールド ExtensionDataStartAddressは、 3 2ピットのデ一夕長 を有し、 このシンタクス内にあるブロック blkExtensionDataOの開始 アドレスを示す。 ブロック blkExtensionDataOは、 所定の拡張データ を格納可能とするためのブロックである。 フィールド ExtensionDataS tartAddressは、 このファイル" index, bdmv"の最初のバイ卜からの相 対バイト数で、 ブロック blkExtensionDataOの開始ァドレスを示す。 相対バイト数は、 " 0"から開始される。 若し、 このフィールド Extens ionDataStartAddressの値が" 0"であれば、 このファイル" index, bdmv "内に、 ブロック blkExtensionDataOが存在しないことを示す。
フィールド ExtensionDataStartAddressに続けて、 データ長が 1 9 2バイトの領域 reservedが配される。 なお、 領域 reservedは、 バイト ァライメン卜や、 将来的なフィールドの追加などのための領域である 。 これは、 以下の説明においても同様である。 ブロック MkAppInfoBD MV0は、 コンテンツ制作者が任意の情報を記述できるブロックであつ て、 プレーヤの動作などには影響を与えない。
プロック blklndexes 0は、 このフアイル" index, bdmv"の実質的な内 容であって、 このファイル" index, bdmv"に記述された内容により、 デ イスクをプレーヤに装填した際に再生されるファーストプレイバック や、 トップメニューから呼び出されるタイトル （ムービーオブジェク ト） が指定される。 インデックステーブルにより呼び出されたムービ 一才ブジェクト等に記述されたコマンドに基づき、.後述するプレイリ ストファイルが読み込まれる。
第 7図は、 ブロック blklndexesOの一例の構造を表すシンタクスを 示す。 フィールド Lengthは、 3 2ビットのデータ長を有し、 このフィ ールド Length直後からこのプロック blklndexes 0の終わりまでのデ一 夕長を示す。 続けて、 ブロック FirstPlaybackTitleOおよびブロック MenuTitleOが配される。
ブロック FirstPlaybackTitleOは、 ファーストプレイバックで用い られるォブジェク卜に関する情報が記述される。 ブロック Firs layb ackTitleOは、 1ビットのデータ長を有する領域 reservedに続けて固 定値 "Γが記述される。 さらに 3 1ビットのデータ長を有する領域 res ervedを介して固定値" Γが記述される。 そして、 14ビットのデータ 長を有する領域 reservedを介して、 1 6ピットのデ一夕長を有するフ ィ一ルド Firs laybackTitleMobjlDRefが配される。 このフィールド F irstPIaybackTitleMobjlDRefにより、 ファーストプレイバックタイト ルで用いられるムービーオブジェクトの I Dを示す。
ム一ビーオブジェクトの I Dは、 例えば、 第 8図および第 9図を用 いて後述するムービーオブジェクトのシンタクスに基づき、 ムービー オブジェクトの forループ文においてループ変数として用いられる値 m obj— idで示される。 この例では、 フィールド FirstPlaybackTitleMobj IDReiは、 参照するムービーオブジェクトに対応する値 mobj— idが格納 される。
なお、 ブロック blklndexesOにおけるブロック FirstP ybackTi Ue 0内のフィールド FirstPlaybackTitleMobjlDRefは、 トップメニュー のムービーオブジェクトを指していてもよいし、 タイトルを指してい てもよい。
ブロック MenuTitleOは、 トップメニューで用い.られるォブジェク トに関する情報が記述される。 ブロック MenuTitleOは、 1ビットの データ長を有する領域 reservedに続けて固定値" 1 "が記述される。 さ らに 3 1ビットのデ一夕長を有する領域 reservedを介して固定値" Γ が記述される。 そして、 14ビットのデータ長を有する領域 reserved を介して、 1 6ビットのデータ長を有するフィールド MenuTitleMobjl DRefが配される。 フィールド MenuTitleMobjIDRefは、 メニュータイト ルで用いられるムービーォブジェクトの I Dを示す。
ブロック MenuTitleOの次のフィールド NumberOfTitlesは、 1 6ビ ットのデータ長を有し、 ユーザが選択、 再生可能なタイトルの数を示 す。 次の forループ文に従い、 このフィールド NumberOfTiUesに示さ れる回数だけ、 値 title_idを引数として、 ブロック MovieTitle[title _id] 0が記述される。 ブロック MovieTiUe[tiUe_id] ()は、 タイトル 毎の情報が記述される。 値 title—idは、 " 0"からフィールド NumberOf Titlesで示される値までの数値であり、 タイトルを識別する。
ブロック MovieTitle[title一 id] 0において、 1ピットのデータ長を 有する領域 reservedを介して固定値 "Γが記述され、 さらに、 46ビ ットのデ一夕長を有する領域 reservedを介してフィールド MovieTitle MobjIDRefが記述される。 フィールド MovieTi UeMobj IDRefは、 1 6ビ ットのデータ長を有し、 このタイトルで用いられるム一ビーオブジェ クトの I Dを示す。 フィールド MovieTiUeMobjIDRefの後ろに、 32 ビットのデ一夕長を有する領域 reservedが配される。
第 8図は、 ディレクトリ" BDMV"の直下に置かれるファイル" MovieOb ject.bdmv"の一例の構造を表すシンタクスを示す。 フィールド Typeln dicatorは、 32ビット （4バイト） のデータ長を有し、 このフアイ ルがファイル" MovieObject.bdmv"であることを示す。 フィ一ルド Type Indicatorは、 I SO (International Organization for Standarizat ion) 646に規定された符号化方式で符号化した 4文字からなる文字 列が記述される。 この第 8図の例では、 フィールド Typelndicatorに I S 0646に規定の方式で符号化された 4文字の文字列" Μ0ΒΓが記 述され、 このファイルがファイル" MovieObject. bdmv"であることが示 される。
フィールド TypeIndicator2は、 3 2ビット （4バイト） のデータ長 を有し、 このファイル" MovieObject.bdmv"のバージョン番号を示す。 このファイル" MovieObiect.bdmv"では、 フィールド TypeIndicator2は 、 I S 0646に規定された符号化方式で符号化した 4文字の文字列 " 0100 "でなければならない。
フィールド ExtensionDataStartAddressは、 3 2ビットのデ一夕長 を有し、 このシンタクス内にあるブロック b IkEx tens i onData ()の開始 アドレスを示す。 フィールド ExtensionDataStartAddressは、 このフ アイル" MovieObject.bdmv"の最初のバイトからの相対バイト数で、 ブ ロック blkExtensionDataOの開始アドレスを示す。 相対バイト数は、 " 0"から開始される。 若し、 このフィールド ExtensionDataStartAddr essの値が" 0"であれば、 このファイル" MovieObject.bdmv"内に、 ブ 口ック MkExtensionDataOが存在しないことを示す。
なお、 この第 8図に示すシンタクス内のフィールド padding_wordは 、 1 6ビットのデータ長を有し、 このファイル" MovieObject.bdmv"の シンタクスに従い forループ文に値 N1または値 N2で示される回数だけ 挿入される。 値 N1または値 N2は、 " 0"または任意の正の整数である。 また、 フィールド padding_wordは、 任意の値を用いることができる。 フィールド ExiensionDataStartAddressに続けてデータ長が 2 24 ピットの領域 reservedが配され、 その次に、 このファイル" MovieObje ct.bdmv"の本体であるブロック MkMovieObjectsO 格納される。 第 9図は、 プロック blkMovieObjectsOの一例の構造を表すシン夕 クスを示す。 フィールド Lengthは、 3 2ビットのデータ長を有し、 こ のフィ一ルド Lengthの直後からこのプロック blkMovieObjects 0の終 わりまでのデ一タ長を示す。 3 2ビットのデ一夕長を有する領域 rese rvedを介してフィ一ルド NumberOfMobjsが配される。 フィ一ルド Numbe rOfMobjsは、 直後の forループ文に従い格納されるムービーオブジェ クトの数を示す。 forループ文のループ変数として用いられる値 mobj— idで、 ムービーオブジェクトが一意に特定される。 値 mobjjdは、 " 0 "から始まる値で、 ムービーオブジェクトは、 forループ文中に記述さ れる順序により定義される。
forループ文中のブロック TerminallnfoOは、 固定値 "1"が記述され 、 次に 1 5ビットのデータ長を有する領域 reservedが配される。 その 次に、 1 6ビットのデータ長を有するフィールド NumberOfNavigation Commands [mobj_id]が配される。 このフィールド NumberOfNavigat ionC ommands [mobj_id]は、 値 mobj_idによって指し示されるムービーォブ ジェクト MovieObject [mobj—id] 0に含まれるナビゲ一ションコマンド (Navigat ionCommand)の数を表す。
次の、 値 command— idをループ変数とする forル一プ文により、 フィ 一ルド NumberOfNavigationCo翻 ands [mobし id]に示される数だけ、 ナ ピゲーシヨンコマンドが記述される。 すなわち、 この forループ文中 に配されるフィ一レド Navigat ionCommand [mobj— id] [command— id] fま、 値 mobj— idによって指し示されるブロック MovieObject [mobし id] 0に 含まれる、 値 command_idで示される順番のナビゲーションコマンド Na vigat ionCommandを格納する。 値 command一 idは、 0から始まる値で、 ナビゲーションコマンド Navigat ionCommandは、 この forループ文中に 記述される順序で定義される。
第 10図は、 プレイリストファイル" xxxxx.mpls"の一例の構造を表 すシンタクスを示す。 フィールド Typelndicatorは、 32ビット （4 パイト） のデータ長を有し、 このファイルがプレイリストファイルで あることを示す。 フィールド TypeIndicator2は、 32ビット （4バイ ト） のデータ長を有し、 このプレイリストファイルのパージヨンを示 す。 フィールド PlayListStartAddressは、 32ビットのデータ長を有 し、 このシンタクス中のブロック MkPlayListOの開始ァドレスを示 す。
フィールド PlayListMarkStartAddressは、 32ビットのデータ長を 有し、 このシンタクス中のブロック blkPlayListMarkOの開始ァドレ スを示す。 フィールド ExtensionDataStartAddressは、 32ビットの データ長を有し、 このシンタクス中のブロック blkExtensionDataOの 開始アドレスを示す。 フィールド ExtensionDataStartAddressは、 ブ ロック blkExtensionDataOの開始アドレスを、 ファイル" xxxxx. mpls" の最初のバイ卜からの相対パイト数を表した値である。 相対バイト数 は、 " 0"から開始される。 若し、 このフィールド ExtensionDataStart Addressの値が" 0"であれば、 このファイル" xxxxx.mpls"内に、 ブロ ック blkExtensionDataOが存在しないことを示す。
160ビットのデータ長を有する領域 reservedを介してブロック bl kAppInfoPlayList 0が配される。 ブロック MkAppInfoPlayList 0は、 次のブロック MkPlayLis )に記述されるプレイリストのタイプ、 再 生制限などの情報が記述される。 ブロック blkPlayListOは、 プレイ リストが記述される。 ブロック blkPlayListMarkOは、 チヤプタジャ ンプなどでジャンプされるポイントが記述される。 ブロック blkExten s i onDa t a 0は、 所定の拡張デ一夕を格納可能とするためのブロックで ある。
第 1 1図は、 ブロック blkPlayListOの一例の構造を表すシンタク スを示す。 フィールド Lengthは、 32ビットのデータ長を有し、 この フィールド Lengthの直後からプロック blkPlayList 0の最後までのデ 一夕長を示す。 フィールド Lengthに続けて 1 6ビットのデータ長を有 する領域 reservedが配され、 次にフィールド NumberOfPlayl temsが配 される。 フィールド NumberOfPlayltemsは、 16ビットのデータ長を 有し、 このブロック blkPlayListOに含まれるプレイアイテムの数を 示す。 フィールド NumberOfSubPathは、 このブロック MkPlayLis )に 含まれるサブパスの数を示す。
次の forループ文に従い、 フィールド NumberOfPlayltemsで示される 数だけ、 プレイアイテムが記述されるブロック MkPlayltemOが記述 される。 forループ文に基づくカウント数がブロック blkPlayltemOの 識別子 Playltem— idとなる。 さらに次の forループ文に従い、 フィ一ル ド NumberOfSubPathで示される数だけ、 ブロック MkSubPath 0が記述 される。 forループ文に基づくカウント数がブロック blkSubPathOの 識別子 SubPath— idとなる。
なお、 サブパスは、 主として再生されるプレイアイテムに対応する メインパスに対して、 サブプレイアイテムに対応して持つことができ る。 サブパスは、 例えば、 アフレコ用のオーディオデータの指定や、 2枚の映像を合成する際に、 プレイアイテムで指定されるクリップと 同期して再生する副映像を指定するといつた目的で用いられる。 第 12図は、 ブロック blkPlayltemOの一例の構造を表すシンタク スを示す。 フィールド Lengthは、 16ビットのデータ長を有し、 この フィ一ルド Lengthの直後からブロック blkPlayltemOの最後までのデ 一夕長を示す。
フィールド ClipIniormationFileNameは、 40ビット （5バイト） のデータ長を有し、 このブロック blkPlayltemOが参照するクリップ インフォメ一ションファイルのファイル名が示される。 このプレイァ ィテムにおいて、 フィールド ClipInformationFileNameで示されるフ アイル名のクリップィンフオメーシヨンファイルが読み出される。 フ ィールド ClipCodecIdentifierは、 32ピット （4バイト） のデータ 長を有し、 このブロック blkPlayltemOによるプレイアイテムにおい て用いられるクリップ AVス卜リームのコ一デック方式を示す。
1 2ビットのデ一夕長を有する領域 reservedを介して、 フィールド ConnectionConditionが配される。 フィールド Connect ionCondi t ionは 、 4ビットのデータ長を有し、 クリップ間の接続状態に関する情報を 示す。 記録用途の記録媒体に対しては、 フィールド ConnectionCondit ionの値として " 1"、 " 5"または" 6"が用いられる。 フィールド Conne cUonConditionの値が" 1 "で、 そのプレイアイテムから参照されてい るクリップと手前のプレイアイテムから参照されているクリップとが シームレス接続しないことを示し、 フィー レド ConnectionCondition の値が" 5 "または" 6 "で、 そのプレイアイテムから参照されているク リップと手前のプレイアイテムから参照されているクリップとがシー ムレス接続することを示す。 なお、 シームレス接続とは、 クリップと 次のクリップとがフレームタイミングで連続的に再生されるように、 クリップ間の再生制御を行うことをいう。
フィールド Connect ionCondiUonの値が" 5"で、 当該プレイアイテ ムが参照するクリップにおいて、 オーディオデータの記録長がビデオ デ一夕の記録長に対して長くされる （第 1 3図 A参照） 。 これにより 、 クリップとクリップとを接続する際に、 オーディオデータのフェイ ドアウト処理が可能とされる。 例えば、 ユーザによる記録停止操作に よりクリップがクローズされる塲合に、 フィールド ConnectionCondit ionの値が" 5"とざれる。 以下、 このフィールド ConnectionCondition の値が" 5"で示されるクリップの接続方法を、 第 1のシームレス接続 と呼ぶ。
フィールド ConnectionConditionの値が" 6"で、 当該プレイアイテ ムが参照するクリップにおいて、 オーディォデータの記録長がビデオ データの記録長に対して同じにされる （第 1 3図 B参照） 。 これによ り、 クリップとクリップとの接続をシームレスに行うことが可能とさ れる。 例えば、 ユーザ操作に応じた記録停止以外の理由、 例えばシス テム要因に基づきクリップがクローズされる場合に、 フィールド Conn ectionConditionの値が" 6"とされる。 以下、 このフィールド Connect ionConditionの値が" 6"で示されるクリップの接続方法を、 第 2のシ ームレス接続と呼ぶ。
フィールド RefToSTCIDは、 8ビットのデータ長を有し、 システム夕 ィムベース （STC) の不連続点に関する情報を示す。 フィールド IN Timeおよびフィールド OUTTimeは、 それぞれ 32ビットのデータ長を 有し、 メインクリップ AVストリームの再生範囲を示す。 フィールド INTimeが開始点 （ I N点） を示し、 フィールド OUTTimeが終了点 （O UT点） を示す。
ブロック blkUOMaskTableOは、 ユーザ入力の受付制限が設定される テーブルである。 1ピットのデ一夕長を有するフラグ PlayltemRandoin AccessFlagは、 このブロック blkPlayltemOによるプレイアイテムに 対してランダムアクセスを許可するか否かを規定する。 続けて、 7ビ ットのデータ長を有する領域 reservedを介してフィールド StillMode が配される。 フィールド StillModeは、 8ビットのデ一タ長を有し、 ブロック blkPlayltemOによるプレイアイテムにおいて、 最後に表示 した映像を静止画として表示させるか否かを示す。 .フィールド StillM odeの値が" 0x01" (バイナリ） であれば、 if文に基づき、 16ビット のデータ長を有するフィールド St illTimeにより静止時間が示される 。 フィールド StillModeの値が" 0x01 "以外であれば、 当該 1 6ピット のデータ長を有する領域が領域 reservedとされる。 なお、 数値の記述において" Ox"は、 その数値が 1 6進表記されてい ることを示す。 これは、 以下の同様な表記について共通である。
ブロック blkSTNTableOは、 このブロック MkPlayltemOによるプレ ィアイテムが管理しているクリップ AVストリームの属性、 P I D番 号、 記録媒体上での記録位置などが管理される。
第 14図は、 ブロック blkPlayListMarkOの一例の構造を表すシン 夕クスを示す。 フィールド Lengthは、 32ビットのデータ長を有し、 このフィールド Lengthの直後からブロック blkPlayUstMarkOの最後 までのデータ長を示す。
フィールド NumberOfPlayListMarksは、 1 6ビットのデ一タ長を有 し、 このブロック blkPlayUstMarkOに含まれるプレイリストマ一ク の数を示す。 次の forル一プ文に従い、 フィールド NumberOfPlayListM arksで示される数だけプレイリストマークの情報が記述される。
forループ文内において、 8ビットのデータ長を有する領域 reserve に続けてフィールド MarkTypeが配される。 フィ一ルド MarkTypeは、 8 ビットのデータ長を有し、 マークのタイプを示す。 プレイリストマー クには、 エントリマーク（Entry Mark)およびリンクポイント（Link Po int)の 2タイプが定義されており、 このフィールド MarkTypeにより、 何れのタイプであるかが示される。 チヤプ夕を定義するためには、 ェ ントリマークを用いる。 リンクポイントは、 この発明と関連性が薄い ので、 説明を省略する。 上述したフィールド NumberOiPlayListMarks は、 エントリマークおよびリンクポイントを合計した値を示す。
フィールド ReiToP yltemlDは、 16ビットのデータ長を有し、 マ 一クが打たれるプレイアイテムを参照する識別情報 P 1 ay 11 em— i dが記 述される。 フィールド MarkTimeSta即は、 32ピットのデ一タ長を有 し、 マークが打たれるポイントを示すタイムスタンプが記述される。 2007/060081 フィールド EntryESPIDは、 1 6ビットのデータ長を有し、 マークによ つて指し示されるエレメン夕リストリームを含んでいる T Sバケツト の P I Dの値を示す。 フィールド Durationは、 45 kHzのクロック を単位とした計測による、 32ビットのデータ長を有する符号無し整 数である。 このフィールド Durationに格納される値が" 0"であれば、 このフィールド Durationは、 意味を成さない。
第 1 5図は、 クリップインフォメーションファイルの一例の構造を 表すシンタクスを示す。 フィールド Typelndicatorは、 32ビット （ 4バイト） のデータ長を有し、 このファイルがクリップインフォメー シヨンファイルであることを示す。 フィールド TypeIndicator2は、 3 2ビット （4バイト） のデータ長を有し、 このクリップインフォメ一 ションファイルのパージョンを示す。
このクリップインフォメーションファイルは、 ブロック blkClipInf o()、 プロック blkSequenceInfo()、 ブロック MkProgramlnfo 0、 ブロ ック blkCPI()、 ブロック blkClipMarkOおよびブロック blkExtensionD ataOを有し、 それぞれ 32ビッ卜のデ一夕長を有するフィールド Seq uencelnfoStartAddress, フィ一ルド ProgramInfoSta Address、 フィ ールド CPIStartAddress、 フィ一ルド CI ipMarkStartAddressおよびフ ィ一ルド ExtensionDataStartAddressは、 各々対応するブロックの開 始アドレスを示す。
フィールド ExtensionDataStartAddressは、 このクリップィンフォ メ一ションファイルの最初のバイ卜からの相対バイト数で、 ブロック blkExtensionDataOの開始アドレスを示す。 相対バイト数は、 " 0"か ら開始される。 若し、 このフィールド ExtensionDataStartAddressの 値が" 0"であれば、 このファイル" index, bdmv"内に、 ブロック blkExt ensionDataOが存在しないことを示す。 ブロック MkClipInfoOは、 これらの開始ァドレスを示すフィール ドに続く、 96ビットのデータ長を有する領域 reservedの次から開始 される。 ブロック blkClipInfoOは、 このクリップインフォメーショ ンファイルが管理するクリップ AVストリームに関する情報が記述さ れる。 ブロック kSequencelnfoOは、 STC ATC (ァライパル タイムべ一ス） が連続しているシーケンスをまとまりとして管理する 情報が記述される。 ブロック blk rogramlnfoOは、 このクリップイン フオメ一シヨンファイルに管理されるクリップ AVストリームの符号 化方式、 クリップ AVストリーム中のビデオデータのァスぺクト比な どの情報が記述される。 ブロック MkCPlOは、 ランダムアクセス開始 点などの、 A Vストリーム中の特徴的な箇所を表す特徴点情報 CP I に関する情報が格納される。
また、 ブロック blkClipMarkOは、 チヤプタ位置などの、 クリップ に付された頭出しのためのインデックス点 （ジャンプポイント） が記 述される。 ブロック blkExtensionDataOは、 拡張データを格納するこ とができる領域である。 なお、 クリップインフォメーションファイル 内のブロック b 1 kC 1 i pMar k ()およびブロック b 1 kSequenc e I n f 00は、 こ の発明との関連性が薄いので、 詳細な説明を省略する。
第 16図は、 ブロック!) lkClipInfoOの一例の構造を表すシンタク スを示す。 フィールド Lengthは、 32ビットのデータ長を有し、 この フィールド Lengthの直後からブロック MkClipInioOの最後までのデ —タ長を示す。 16ピットのデータ長を有する領^ reservedを介して 、 フィ一ルド ClipStreamTypeが配される。
フィールド ClipStreamTypeは、 8ビットのデ一夕長を有し、 クリツ プ A Vストリームの種別を表す。 このフィールド ClipStreamTypeの値 は、 例えば " 1 "に固定的とされる。 フィールド ApplicationTypeは、 8ビットのデータ長を有し、 クリップ AVストリーム （拡張子が 「m2 tsj のファイル） がどのような多重化によって作られているかを示す 。 フィールド ApplicationTypeの値が" 1"で、 対応するクリップ A V ストリームは、 通常の動画が再生される。 続けて 31ビットのデータ 長を有する領域 reservedが配される。
データ長が 1ビッ卜のフラグ IsCC5は、 プレイリストにおけるプロ ック blkPlayltefflOによって、 対応するクリップと次のクリップとの 接続を、 上述した第 1のシームレス接続、 すなわちフィールド Comiec UonConditionの値が" 5"で示される方法で行うか否かを示す。 フラ グ IsCC5の値が" 1" (バイナリ値） であれば、 クリップ間の接続が第 1のシームレス接続によりなされていることを示す。
フィ一ルド 31^(；0^11^1^{6は、 クリップ AVストリ一ムファイル の記録レートをバイトノ秒で表したものである。 フィールド NumberOf SourcePacketsは、 クリップ AVストリームに含まれるソースパケッ ト数を表す。 1024ビットのデータ長を有する領域 reservedを介し てブロック TSTypelnioBlockOが配される。 ·ブロック TSTypelnfoBlock 0は、 クリップ AVストリームが格納されるパケットのタイプを示す 情報が格納される。 このブロック TSTypelnioBlockOは、 この発明と の閼連性が薄いので、 詳細な説明を省略する。
次の if文以下の情報は、 上述のフラグ IsCC5の値が' ' 1"である場合 に記述される。 if文の次の 8ビッ卜のデータ長を有する領域 reserved を介してフィールド FollowingClipStreamTypeが配されるフィ一ルド F ollowingClipStreamTypeは、 8ビットのデータ長を有し、 このクリツ プインフォメ一ションファイルに対応するクリップの次のクリップの タイプが記述される。 32ビッ卜のデータ長を有する領域 reservedを 介してフィールド FollowingClipInformationFileNameが配される。 フィールド FoHowingClipInformaiionFileNameは、 40ビット ( 5 バイト） のデータ長を有し、 このクリップインフォメーションフアイ ルに対応するクリップの次のクリップに対応するクリップィンフオメ ーションファイルのファイル名が記述される。 次のフィールド ClipCo decldentifierは、 32ビット （4ノ イト） のデータ長を有し、 当該 次のクリップの符号化方式を示す。 この例では、 フィールド ClipCode cldentifierは、 I S 0646に規定の方式で符号化された 4文字の 文字列値" M2TS"に固定的とされる。 次に 8ビットのデータ長を有する 領域 reservedが配される。
第 1 7図は、 ブロック blkProgramlnfoOの一例の構造を表すシン夕 クスを示す。 フィールド Lengthは、 32ビットのデータ長を有し、 こ のフィールド Lengthの直後からプロック blkProgramlnfo 0の最後まで のデータ長を示す。 1 5ビットのデータ長を有する領域 reservedを介 して、 データ長が 1ビッ卜で固定値" 1 "が記述される。
フィ一ルド SPNProgramSeQuenceStartは、 32ビットのデータ長を 有し、 対応するクリップ AVストリームファイルにおいて、 プロダラ ムシーケンスが開始されるソースバケツトの番号が記述される。 フィ 一ルド ProgramMapPIDは、 1 6ビットのデータ長を有し、 プログラム シーケンスに適用可能なプログラムマップセクションを含むとされて いる T Sパケットの P I Dの値を示す。 フィールド NumberOfStreamsI nPSは、 8ビットのデ一タ長を有し、 プログラムシーケンスに定義さ れるエレメンタリストリ一ムの数を示す。 フィールド NimberOfStream slnPSに続けて、 8ビッ卜のデータ長を有する領域 reservedが配され る。
次の forループ文に従い、 値 [stream_index]をループ変数として、 フィールド NumberOfS eamsInPSで示される数だけ、 フィ一ルド Strea mP ID [stream一 index]およびブロック MkStreamCodinglnfo (stream一 ind ex)の組が格納される。 フィールド StreamPID[stream_iii(3ex]は、 プロ グラムシーケンスによって参照された PMT (Program Map Table)に 記述されたエレメンタリストリームに対応する P I Dの値を示す。 次 のブロック blkStreamCodingInfo(stream_inde}{〉は、 対応するフィー ルド StreamPID[stream_index]で示されるエレメン夕リストリームの 符号化方式に関する情報が記述される。
第 1 8図は、 ブロック blkSireamCodingInfo(sireani_index)の一例 の構造を表すシンタクスを示す。 フィールド Lengthは、 8ビットのデ 一夕長を有し、 このフィールド Lengthの直後からブロック blkStreamC odingInfo(stream_index)の終わりまでのデータ長を示す。
フィールド Lengthの次に、 8ビットのデ一夕長を有するフィールド StreamCodingTypeが配される。 フィールド StreamCodingTypeでは、 値 [streamjndex]で示されるエレメン夕リストリームの符号化のタイプ が示される。 一例として、 フィールド StreamCodingTypeの値として値 "Ox IB", 値" 0x80"、 値" 0x81"、 値" 0x90 "および値" 0x91 "が定義され、 当該ストリームの符号化タイプは、 値" OxlB"でビデオストリーム、 値 "0x80"または値" 0x81 "でオーディオストリーム、 値" 0x90"で OBスト リーム、 値" 0x91 "で MBストリームであることがそれぞれ示される。 次の if文に従い、 このフィールド StreamCodingTypeの値に応じた記述 がなされる。
フィールド StreamCodingTypeの値が例えば" OxlB"であって、 値 [str eam— index]で示されるエレメンタリストリームがビデオストリームで あることが示されれば、 if文に従いフィールド VideoFormat、 フィ一 ルド FrameRateおよびフィールド AspectRatioが記述され、 2ビットの デ一夕長を有する領域 reservedを介してさらにフラグ CCFIagが記述さ れる。 フラグ CCFlagの後には、 1 7ビットのデータ長を有する領域 re servedと、 1 28ビッ卜のデータ長を有する領域 reservedが配される フィールド VideoForiaatは、 4ビットのデータ長を有し、 値 [stream _index]で示されるビデオデータのフォーマツトを示す。 第 1 9図は 、 フィールド VideoFormatで示されるビデオデータの一例のフォーマ ットを一覧で示す。 第 1 9図に例示されるように、 ビデオデータのフ ォーマツトは、 4ビットで表現可能な値" 0' '〜値'' 1 5"で識別され、 値" 0 "およぴ値" 8 "〜値" 1 5 "は、 予約とされている。 値" 1"〜値" 7"で、 それぞれビデオデータのフォーマットの 480 i、 576 i 、 480 p、 1 080 i、 720 p、 1 080 pおよび 576 pを示 す。
なお、 このビデオフォーマットの表記において、 末尾の 「 i」 およ び 「p」 は、 それぞれイン夕レース走査およびプログレッシブ走査を 示す。 また、 数字はライン数を示す。 これらのビデオフォーマットは 、 I TU (International Telecommunication Union;— R BT.60 1— 4 (480 iおよび 576 i ) 、 I TU— R B T. 1 358 ( 576 p) 、 SMPTE (Society of Motion Picture and Televisio n Engineers) 293 M (48 O p) 、 SMPTE 274M (1 0 80 iおよび 1 080 p) および SMPTE 296M (7 20 p) により標準化されたフォーマツトである。
ブロック blkStreamCodingInio(stream— index)において、 フィール ド FrameRateは、 4ビットのデータ長を有し、 値 [streamjndex]で示 されるビデオデータのフレームレートを示す。 第 20図は、 フィール ド FrameRateで示される一例のフレームレートを一覧で示す。 第 20 図に例示されるように、 ビデオデータのフレームレートは、 4ビット で表現可能な値" 0"〜" 1 5"で識別され、 値" 0"、 値" 5 "および値" 8"〜値" 1 5"は、 予約とされている。 値" 1"〜値" 4"で、 それぞれ フレームレート （フィールド周波数） が （24000/1 00 1) H zすなわち略 23.97 Hz、 24Hz、 2 5 Hzおよび （3000 0 / 1 00 1 ) Hzすなわち略 29.97 Hzを示す。 また、 値 6お よび値 7で、 それぞれフレームレートが 50H zおよび （60000 /1 00 1) Hzすなわち略 59.94Hzを示す。
ブロック blkStreamCodingInfo(stream— index)において、 フィール ド AspectRatioは、 4ビットのデータ長を有し、 値 [stream一 index]で 示されるビデオデータのアスペクト比を示す。 第 2 1図は、 フィール ド AspectRatioで示される一例のフレームレートを一覧で示す。 第 2 1図に例示されるように、 ビデオデータのアスペクト比は、 4ビット で表現可能な値" 0"〜値" 1 5"で識別され、 値" 0"およぴ値" 1"、 な らびに、 値" 4"〜値" 1 5"は、 予約とされている。 値" 2"でァスぺク ト比が 4 ： 3を示す。 値" 3"でアスペクト比が 1 6 ： 9を示す。
ブロック blkStreamCodingInfo(stream— index)において、 フィール ド StreamCodingTypeの値が例えば" 0x80" " 0x81"、 " 0x90"または" 0x9 1 "の場合も、 if文における 「else ifj の記述に従い、 それぞれの値 が示す符号化タイプに応じた記述がなされる。 なお、 ビデオストリー ム以外の符号化タイプのストリームに関する記述は、 この発明と関連 性が薄いので、 詳細な説明を省略する
第 22図は、 クリップィンフオメーションファイルにおけるプロッ ク blkCPlOの一例の構造を表すシンタクスを示す。 MP EGストリ一 ムのような、 フレーム間圧縮を行っている符号化ストリームにおいて は、 デコード開始可能な箇所は、 GO P (Group Of Picture)の先頭な ど一部の箇所に限定されていることが多い。 CP I (Characteristic Point Information)とは、 そのデコード可能な開始点の位置の情報を 集めたデータベースで、 再生時刻と、 ファイル内アドレスとが対応付 けられたテーブルになっている。 すなわち、 CP Iは、 デコード単位 の先頭位置を示す情報がテーブル化されている。
このようにデータベースを定めることで、 例えば、 任意の時刻から 再生したい場合、 再生時刻を元に CP Iを参照することによって再生 位置のファイル内アドレスがわかる。 このアドレスは、 デコード単位 の先頭となっているため、 プレーヤは、 そこからデータを読み出して デコードし、 素早く画像を表示することができる。
なお、 この CP Iに格納される、 デコード単位の先頭位置 （この例 では GOPの先頭位置） を、 E P (Entry Point)エントリと称する。 第 22図において、 フィールド Lengthは、 32ビットのデータ長を 有し、 このフィ一ルド Lengthの直後からブロック blkCPlOの最後まで のデータ長を示す。 次の if文に従い、 フィールド Lengthの値が 0でな ければ、 1 2ビットのデータ長を有する領域 reservedを介してフィー ルド CPITypeが配される。 フィールド CPITypeは、 4ビットのデータ長 を有し、 CP Iの種類を示す。 次のブロック blkEPMapOは、 対応する クリップ AVストリームファイルにおける PTS値とパイトアドレス との関連付けを行うテーブルが格納される。
第 23図は、 ブロック blkEPMapOの一例の構造を表すシンタクスを 示す。 8ビッ卜のデータ長を有する領域 reservedを介してフィ一ルド NumberOfStreamPIDEntriesが配される。 フィール HNumberOfStreamPI DEntriesは、 8ピットのデ一夕長を有し、 ブロック blkEPMapOにおけ るブロック blkEPMapForOneStream Dのェントリ数を示す。 forループ 文に従い、 値 [k]をループ変数として、 フィールド NumberOfStreamPID Entriesに示される数だけ、 ェントリポィントに関する情報が記述さ れる。
forループ文内において、 フィールド StreamPID[k]は、 1 6ビット のデータ長を有し、 ブロック blkEPMapOの中で [k]番目にェントリさ れるブロック MkEPMapForOneStreamnD (以下、 [k]番目のブロック bl kEPMapForOneStreamPIDと記述する） によって参照されるエレメン夕 リストリームを伝送するトランスポ一トパケットの P I Dの値を示す
1 0ビットのデ一夕長を有する領域 reservedを介してフィールド EP StreamType[k]が配される。 フィールド EPStreamType [k]は、 4ビット のデータ長を有し、 [k]番目のブロック MkEPMapForOneStreamPIDによ つて参照されるエレメン夕リストリームのタイプを示す。 フィールド NumberOfEPCoarseEntries[k]は、 1 6ビットのデータ長を有し、 [k] 番目のブロック MkEPMapForOneStreamPIDの中にある粗い検索用のサ ブテーブル（EP coarse table)のエントリ数を示す。 フィールド Numbe rOfEPFineEntries[k]は、 1 8ビットのデータ長を有し、 [k]番目のブ 口ック MkEPMapForOneStreamPIDの中にある精密な検索用のサブテ一 ブル（EP fine table)のエントリ数を示す。 フィ一ルド EPMapForOneSt reamPIDStartAddress[k]は、 3 2ビットのデータ長を有し、 ブロック blkEPMap 0の中で [k]番目のブロック b IkEPMapForOneS t r eamP IDが始ま る相対バイト位置を示す。 この値は、 ブロック blkEPMapOの第 1パイ ト目からのバイト数で示される。
上述の forループ文による記述の後、 1 6ビットの整数倍のデータ 長を有するパディンダワードを挟んで記述される forループ文に従い 、 値 [k]をループ変数として、 フィールド NmnberOfStreamPIDEntries に示される数だけ、 ブロック blk:EPMapForOneStreamPID(EPStreamType [k], NumberOfEPCoarseEntriesCk], NumberOfEPFineEntr ies [k])が格 納される。 すなわち、 引数 NumberOfEPCoarseEntries[k]は、 サブテー ブル（EP coarse table)に格納されるエントリ PTSEPCoarseおよびェン トリ SPNEPCoarseの数を示す。 同様に、 引数 NumberOfEPFineEntries [k ]は、 サブテーブル（EP fine table)に格納されるエントリ PTSEPFine およびエントリ SPNEPFineの数を示す。 以下では、 引数 NumberOfEPCoa rseEntries [k]および引数 NumberOfEPFineEntries [k]を、 それぞれ適 宜、 エントリ数 Ncおよびエントリ数 Nfと呼ぶ。
第 24図は、 ブロック blkEPMapForOneStreamPID(EP— stream— type, Nc, Nf)の一例の構造を表すシンタクスを示す。 ブロック MkEPMapFor OneStreamPID(EP_stream_type, Nc, Nf)のセマンティクスを説明する ために、 先ず、 ブロック blkEPMapForOneStreamPID(EP_streamJype， Nc, Nf)に格納されるデータの元となるエントリである、 エントリ PTS EPStartおよびェントリ SPNEPStartの意味について説明する。
ェントリ PTSEPStartと、 ェントリ PTSEPStartに関連付けられたェン トリ SPNEPStartは、 それぞれ A Vストリーム上のエントリポイントを 指す。 そして、 エントリ PTSEPFineと、 エントリ PTSEPFineに関連付け られたェントリ PTSEPCoarseは、 同一のェントリ PTSEPStartから導か れる。 また、 エントリ SMEPFineと、 エントリ SPNEPFineに関連付けら れたェントリ SPNEPCoarseは、 同一のェントリ SPNEPStartから導かれ る。
第 25図は、 ェントリ PTSEPCoarseおよびェントリ PTSEPFineの一例 のフォーマツトについて示す。 P T Sすなわちェントリ PTSEPStartは 、 データ長が 33ビットの値である。 MS Bのビットを第 32ビット 、 L S Bのビットを第 0ビットとするとき、 この第 2 5図の例では、 大まかな単位で検索を行う際に用いられるェントリ PTSEPCoarseは、 ェントリ PTSEPStartの第 3 ビットから第 1 9ビットまでの 14ビッ 卜が用いられる。 エントリ PTSEPCoarseにより、 解像度が 5. 8秒で 、 2 6. 5時間までの範囲で検索が可能である。 また、 より精密な検 索を行うためのエントリ: PTSEPFineは、 エントリ PTSEPStartの第 1 9 ビットから第 9ビットまでの 1 1ビットが用いられる。 ェントリ PTSE PFineにより、 解像度が 5. 7ミリ秒で、 1 1. 5秒までの範囲で検 索が可能である。 なお、 第 1 9ビットは、 エントリ PTSEPCoarseとェ ントリ PTSEPFineとで共通して用いられる。 また、 L S B側の第 0ビ ットから第 8ビットまでの 9ビットは、 用いられない。
第 2 6図は、 エントリ SMEPCoarseおよびエントリ SPNEPFineの一例 のフォーマットについて示す。 ソースパケット番号すなわちエントリ SPNEPStartは、 データ長が 3 2ビットの値である。 MS Bのピットを 第 3 1ビット、 L S Bのビットを第 0ビットとするとき、 この第 2 6 図の例では、 大まかな単位で検索を行う際に用いられるェントリ SPNE PCoarseは、 ェントリ SPNEPStartの第 3 1ビットから第 0ビットまで の全てのビットが用いられる。 また、 より精密な検索を行うためのェ ントリ SPNEPFineは、 エントリ SPNEPStartの第 1 6ビットから第 0ビ ットまでの 1 7ビットが用いられる。 エントリ SPNEPFineにより、 例 えば略 2 5 MB (Mega Byte)の A Vストリームファイルまでの範囲で 、 検索が可能である。
なお、 ソースパケット番号の場合でも、 エントリ SPNCTCoarseとし て MS B側の所定ビット数の値だけ用いるようにしてもよい。 例えば 、 エントリ SMEPCoarseとして、 エントリ SPNEPStartの第 3 1ビット から第 1 6ビットまでの 1 7ビットを用い、 ェントリ SPNEPFineは、 ェントリ SPNEPStartの第 1 6ビットから第 0ピットまでの 1 7ビット を用いる。
上述に基づき、 ェントリ PTSEPStartおよびェントリ SPNEPSiariは、 次のように定義される。
エントリ PTSEPStartは、 第 25図で示したように、 データ長が 33 ビットの符号無し整数であり、 AVストリーム中で、 ランダムァクセ スが可能なピクチャ （例えば I D R (Instantaneous Decoding Refres h)ピクチャや I (Intra)ピクチャ） から開始するビデオアクセスュニ ットの 33ビット長の P T Sを示す。
エントリ SPNEPStarUま、 第 26図で示したように、 32ビットの符 号無し整数であり、 ェントリ PTSEPS tartに関連付けられたビデオァク セスュニットの第 1バイト目を含むソースバケツトの、 AVストリー ムの中でのアドレスを示す。 エントリ SPNEPStartは、 ソースパケット 番号の単位で表され、 AVストリームファイル中の最初のソースパケ ットから、 値" 0"を初期値として、 ソースパケット毎に 1ずつ増加す る値としてカウントされる。
第 24図を参照し、 ブロック blkEPMapForOneStreamPID(EP— stream— type, Nc, Nf)は、 第 1の forループ文により大まかな単位での検索を 行うためのサブテーブル（EP coarse table)が記述され、 第 2の forル ープ文によりサブテーブル（EP coarse table)の検索結果に基づきよ り詳細な検索を行うためのサプテーブル（EP fine table)が記述され る。
第 1の iorループ文の直前に、 フィールド EPFineTableStartAddress が配される。 フィールド EPFineTableSta Addressは、 32ビットの データ長を有し、 最初の第 2の forループにおけるフィールド Reserve dEPFine[EP_fine_id]の第 1バイト目の開始ァドレスを、 ブロック blk EPMapForOneStreamPID(EP_stream_type, Nc, Νί)の第 1バイト目から の相対バイト数で示す。 相対バイト数は、 値" 0"から開始する。
第 1の forループ文は、 ループ変数 [i]で以て、 サブテーブル（EP co arse table)のエントリ数 Ncまで繰り返され、 エントリ数 Ncの組数だ けフィールド RefToEPFineID[i]、 ェントリ PTSEPCoarse [i]およびェン トリ SPNEPCoarse[i]が格納される。 第 1の forループ文において、 フ ィールド RefToEPFineID[i]は、 1 8ビットのデータ長を有し、 フィー ルド RefToEPFineID[i]に続くフィールド PTSEPCoarse [i]が示すェント リ PTSEPCoarseに関連付けられるェントリ PTSEPFineを持つ、 サブテー ブル（EP fine table)内のエントリ番号を示す。 エントリ PTSEPFineと 、 このェントリ PTSEPFineに関連付けられるェントリ PTSEPCoarseとは 、 同一のエントリ PTSEPStartから導かれる。 フィールド RefToEPFinel D[i]は、 第 2の forループ文中で記述される順番で定義されるループ 変数 [EP— fine_id]の値により与えられる。
第 1の forループ文の後に、 パディングワードを挟んで第 2の forル ープ文による記述がなされる。 第 2の forループ文は、 ループ変数 [EP — fine_id]で以て、 サブテーブル（EP fine table)のエントリ数 Nfまで 繰り返され、 エントリ数 Nfの組数だけ、 1ビットのデータ長を有する フィ一ルド ReservedEPFineCEPJine— id]と、 3ビットのデータ長を有 するフィールド IEndPositionOffset[EP— fine_id]と、 1 1ピットのデ —夕長を有するフィールド PTSEPFine[EP—fine_id]と、 1 7ビットの データ長を有するフィールド SPNEPFine[EP_fine_id]とが格納される 。 これらのうち、 フィールド PTSEPFine [EPJine— id]およびフィール ド SPNEPF ine [EP— f i ne_id]は、 ループ変数 [EP— ί i ne_i d]に基づきサブ テーブル（EP fine table)から参照されるエントリ SEPFineおよびェ ントリ SPNEPF ineそれぞれが格納される。
エントリ PTSEPCoarseおよびエントリ PTSEPFine、 ならびに、 ェント リ SPNEPCoarseおよびエントリ SPNEPFineは、 次のように導かれる。 サ ブテーブル（EP fine table)に、 関連するデ一夕 SPNEPStartの値の昇 順に並んでいる Nf個のェントリがあるとする。 それぞれのェントリ PT SEPFineは、 対応するエントリ PTSEPStartから、 次式 （1) のように 導かれる。
PTSEPFine[EP_fine_id]= (PTSEPStart [EP_fine_id] »9) / 2n - - (1)
ェントリ PTSEPCoarseと、 対応するェントリ PTSEPFineとの関係は、 次式 （2) 、 (3) の通りである。
PTSEPCoarse[i]= (PTSEPStart [RefToEPFineID[i]] 》1 9) / 214 • · (2)
PTSEPFine[RefToEPFineID[i]]= (PTSEPStart [RefToEPFineID[i]] » 9) /211 · · (3)
それぞれのェントリ SPNEPFineは、 対応するェントリ SPNEPStar tか ら、 次式 （4) のように導かれる。
SPNEPF ine [EP_f ine_i d] = SPNEPS t ar t [EP_f i ne_i d] / 217 · · (4 )
ェントリ SMEPCoarseと、 対応するェントリ SPNEPFineとの関係は、 次式 （5) 、 (6) の通りである。
SPNEPCoarse[i]=SPNEPStart [RefToEPFinelDLi]] · · (5)
SPNEPF i ne [Re f T oEPF i ne I D [ i ] ] = SPNEP Start [RefToEPFinelDLi]] / 21 7 · · (6)
なお、 上述の式 （1) 〜 （6) において、 記号 「;>>x」 は、 データ の L S B側から Xビットを超える桁からビットを用いることを意味す る。
次に、 拡張デ一夕を格納するためのプロック MkExtensionDaUOに ついて説明する。 このブロック blkExtensionDataOは、 所定の拡張デ 一夕を格納可能なように定義され、 インデックステーブルが格納され るファイル" index. bdmv\ プレイリストが格納されるファイル" xxxxx .mpls"およびクリップインフォメーションファイル" ZZZZZ, clpi"の各 ファイルに記述することができる。
第 2 7図は、 ブロック blkExtensionDataOの一例の構造を表すシン 夕クスを示す。 フィールド Lengthは、 3 2ビットのデータ長を有し、 このフィ一ルド Lengthの直後からブロック blkExtensionDataOの終わ りまでのデータ長をバイト数で示す。 このフィールド Lengthの示すデ —夕長が" 0"でなければ、 if文以下の記述がなされる。
フィールド DataBlockStartAddressは、 3 2ビットのデ一夕長を有 し、 このシンタクス中の、 拡張データの本体が格納されるブロック Da taBlockOの開始ァドレスを、 このブロック MkExtensionDataOの先 頭バイトからの相対バイト数で示す。 すなわち、 相対バイト数は、 " 0"から開始される。 なお、 フィールド DaiaBlockSiartAddressは、 次 に示す 3 2ビットァライメントの条件を満たさなければならない。 DataBlockStartAddress% 4= 0
24ビットのデータ長を有する領域 reservedを介してフィールド Nu mberOfExtDataEntriesが配される。 フィールド NumberOfExtDa Entri esは、 8ビットのデータ長を有し、 このブロック MkExtensionDataO のブロック DataBlockOに格納される拡張データのェントリ数を示す 。 拡張データのエントリは、 拡張データの本体を取得するための情報 が格納される。 この例では、 拡張データのエントリは、 フィールド Ex tDataType, フィールド ExtDataVersion、 フィール.ド ExtDataStartAdd ressおよびフィ一ルド ExtDataLengthからなるブロック ext_data— entr y()であって、 ブロック blkExtensionDataOにおいて、 第 1の forルー プ文に従いこのフィールド NumberOfExtDataEntriesに示される個数だ け、 このブロック exし data entry 0が存在する。 フィールド ExtDataTypeは、 1 6ビットのデータ長を有し、 このブ ロック b IkEx t ens i onDa t a 0に記述される拡張データが記録装置用の拡 張データであることを表す。 このフィールド ExtDataTypeの値は、 拡 張データを識別する第 1の値であり、 このブロック blkExtensionData 0を含む規格書のライセンサ （使用認可者） が割り当てると定義する ことができる。 フィールド ExtDataVersionは、 拡張データを識別する 第 2の値であり、 この拡張データのバージョン番号を表すものと定義 することができる。 なお、 このブロック MkExtensionDataOにおいて 、 フィールド ExtDataTypeおよびフィールド ExtDataVersionの値が同 一のブロック exし data一 entryOが 2以上、 存在してはならない。
フィールド ExtDataStartAddressは、 3 2ビッ卜のデータ長を有し 、 このフィールド ExtDataStartAddressが含まれる拡張デ一夕のェン トリ （ブロック exし data_entry()) に対応する拡張データの開始アド レスを示す。 フィールド ExtDataStartAddressは、 ブロック blkExtens ionDataOの先頭バイトからの相対バイト数で、 拡張データ ext_data の開始アドレスを示す。 なお、 フィールド ExtDataStartAddressは、 次に示す 3 2ビットァライメントの条件を満たさなければならない。 ExtDataStartAddress% 4 = 0
フィールド ExtDataLengthは、 3 2ビットのデータ長を有し、 この フィールド ExtDataStartAddressが含まれる拡張データのエントリ （ プロック ext— data_entriesO) に対応する拡張データのデータ長を示 す。 データ長は、 バイト数で示される。
フィールド NumberOfExtDataEntriesで示された個数だけ、 拡張デ一 夕のエントリ （ブロック ext_(kta_entryO) が記述されると、 それぞ れ 1 6ビットのデータ長を有し任意のデ一夕列からなるフィールド pa dding— wordが、 2フィールドを組として任意の回数 L1だけ繰り返され る。 その後、 拡張データの本体が格納されるブ αック DataBlockOが 記述される。 ブロック DataBlockOは、 1以上の拡張データが格納さ れる。 それぞれの拡張データ exし dataは、 上述したフィールド ExtDat aStartAddressフィールド ExtDataLengthに基づき、 ブロック DataBloc k()から取り出される。
第 2 8図は、 ブロック MkExtensionDataOにおける各データの参照 関係を模式的に示す。 フィールド Lengthにより、 フィールド Length直 後の位置からブロック blkExtensionDataOの最後までのデータ長が示 される。 フィールド DataBlockStartAddressにより、 ブロック]) a Blo ck()の開始位置が示される。 フィールド NumberOfExtDataEntriesで示 される個数だけ、 ブロック ext— data一 entryが記述される。 最後のプロ ック ext— data_entryからブロック DataBlockOの間には、 任意の長さ でフィールド padding— wordが置かれる。
ブロック DataBlockO内には、 ブロック exし data_entry()で示され る拡張データ ext_da が置かれる。 それぞれの拡張データ exし dataの 位置およびデータ長は、 対応するブロック ext— data一 entryO内のフィ —ルド ExtDataStartAddressおよびフィールド ExtDataLengthにより示 される。 したがって、 ブロック DataBlockO内での拡張データ ext_dat aの並び順は、 対応するブロック ex t_dat a_en t ry ()の並び順と一致し ていなくてもよい。
このように、 拡張データを、 拡張データの本体が格納されるプロッ ク DataBlockOと、 プロック Da BlockO内の拡張データに対するァク セス情報などが格鈉されるブロック exし da t a_en t ry 0とによる 2層構 造とすることで、 複数の拡張データを格納することが可能となる。 次に、 上述の拡張データの一例の作成方法および読み出し方法につ いて説明する。 第 2 9図は、 ブロック MkExtensionDataOにデ一夕を 書き込む際の一例の処理を示すフローチャートである。 この第 2 9図 は、 ブロック blkExtensionDataO中の （n+ 1) 番目のエントリとし て、 拡張データを追加し、 ブロック blkExtensionDataOを書き換える 場合の例である。
先ず、 ステップ S 10で、 書き込もうとしている拡張データのデー 夕長を取得し、 フィールド ExtDataLength[n+l]の値にセットする。 な お、 「[n+l]」 の記述は、 （n+ 1) 番目のエントリの番号に対応す る。 次に、 ステップ S I 1で、 現在のブロック blkExtensionDataOに 列挙されているブロック exし data_entry()のフィールド ExtDataLengt hおよびフィールド ExtDataStartAddressの値を調べ、 ブロック DataBl ockOの使用状況を取得する。
そして、 次のステップ S 1 2で、 ブロック DataBlockO中に、 書き 込もうとしている拡張データのデータ長であるフィールド ExtDataLen gth[n+l]に示されるデ一夕長以上の、 連続した空き領域があるか否か が判断される。 若し、 あると判断されれば、 処理はステップ S 14に 移行される。
一方、 フィールド ExtDataLength[n+l]に示されるデ一夕長以上の連 続した空き領域が無いと判断されれば、 処理はステップ S 1 3に移行 され、 ブロック blkExtensionDataOにおけるフィールド Lengthの値を 大きくし、 フィールド ExtDataLength[n+l]に示されるデータ長以上の 連続した空き領域をブロック DataBlockO内に作る。 空き領域ができ たら、 処理がステップ S 14に移行される。
ステップ S 14では、 拡張データを書き込む領域の先頭ァドレスを 決め、 その先頭ァドレスの値をフィールド ExtDataStartAddress [n+1] とする。 次のステップ S 1 5で、 フィールド ExtDataStartAddress [n+ 1]から、 上述のステップ S 1 0でセットされたフィールド ExtDataLen gth[nH]の長さの拡張データ ext_data[nH]を書き込む。
データの書き込みが終了したら、 ステップ S 1 6で、 ブロック exし data_entry()に対して、 'フィールド ExtDataLength [n+1]と、 フィール ド ExtDataStar ddress[n+l]とを追加する。
なお、 上述において、 書き換えを行うブロック MkExtensionDataO は、 すでにディスクなどの記録媒体から読み出されて記録装置のメモ リに記憶されているものとする。 そのため、 ステップ S 1 3における 、 フィールド Lengthの値の変更によるブロック MkExtensionDataOの 拡大は、 システムに任され、 システムがメモリアロケーションを適切 に行うことでなされる。
第 3 0図は、 ブロック MkExtensionDataOから拡張データを読み出 す際の一例の処理を示すフローチャートである。 なお、 この第 3 0図 のフローチャートによる処理は、 再生専用の記録媒体と、 記録可能な 記録媒体との両方に適用可能なものである。 先ず、 最初のステップ S 2 0で、 読み込もうとする拡張デ一夕が準拠する規格から、 フィール ド ExtDataTypeの値を取得し、 ステップ S 2 1で、 読み込もうとする 拡張データの種別から、 フィールド ExtDataVersionの値を取得する。 次のステップ S 2 2で、 ブロック blkExtensionDataOに列挙されて いるブロック ext_data— entryOを 1つずつ順次、 読み込む。 そして、 ステップ S 2 3で、 読み込んだブロック ext_data—entn()に含まれる フィールド ExtDataTypeおよびフィールド ExtDataVersionの値が、 上 述のステップ S 20およびステップ S 2 1で取得レたフィ一ルド ExiD ataTypeおよびフィールド ExtDataVersionの値と一致するか否かが判 断される。
一致していないと判断されれば、 処理はステップ S 2 6に移行され 、 ブロック blkExtensionDataO内に列挙されるブロック ext data ent ry()を全て読み終えたか否かが判断される。 全て読み終えたと判断さ れれば、 処理はステップ S 2 7に移行され、 このブロック MkExtensi onDataOには、 読み込もうとした拡張データが存在しないとして、 一 連の処理が終了される。 全て読み終えていないと判断されれば、 処理 はステップ S 2 2に戻され、 次のブロック ext— data— entryOが読み込 まれる。
上述のステップ S 2 3において、 ブロック ext_data一 entryOに含ま れるフィールド ExtDataTypeおよびフィールド ExtDataVers ionの値が 、 取得したフィールド ExtDataTypeおよびフィールド ExtDataVersion の値と一致していると判断されれば、 処理はステップ S 24に移行さ れる。 ここでは、 プロック blkExtensionDataO中の [i]番目のェント リで一致したものとする。
ステップ S 24では、 [i]番目のェントリのブロック ext— data— entr y()からフィ一ルド ExtDataLength i]の値と、 フィールド ExtDataStar tAddress[i]の値とを読み込む。 そして、 ステップ S 2 5で、 ステツ プ S 24で読み込んだフィールド ExtDataStartAddressCi]で示される ァドレスから、 フィールド ExtDataLength[i]で示されるデータ長だけ 、 データを読み出す。
次に、 上述した、 インデックスファイル" index. bdmv"、 ムービーォ ブジェクトファイル" MovieObject.bdmV'、 プレイリストファイル" xx.mpls"およびクリップィンフオメーシヨンフアイル" zzzzz. clpi"に それぞれ定義可能な、 拡張データを格納する拡張データブロック blkE xtensionDataOについて説明する。
先ず、 ィンデックスファイル" index. bdmv"に対して定義される一例 の拡張データブロックについて説明する。 ここでは、 プレイリスト毎 に記録可能な記録媒体に特有の属性情報を付加するようにした、 一例 の拡張デ一夕ブロックについて説明する。 第 3 1図は、 このプレイリ スト属性を記述するための、 ファイル" index, bdmv"内のフィールド M kExtensionDataOにおけるブロック DataBlockO (第 27図参照） の 一例の構造を表すシンタクスを示す。 この第 3 1図の例では、 ブロッ ク DataBlockOがプロック blklndexExtens ionData 0として記述されて いる。
先ず、 上述の第 27図を参照して、 ブロック blkExtensionDataOに おいてフィールド ExtDataTypeを値" 0x1000"、 フィール ExtDataVers ionを値" 0x0100"とする。 これらフィールド ExtDataTypeおよびフィー ルド ExtDataVersionに記述された値は、 例えば再生装置側において、 予め ROM (Read Only Memory)などに記憶されたテーブルが参照され て識別される。 ブロック DataBlockO内のフィールド ExtDataStartAdd ressおよびフィールド ExtDataLengthで示される領域に、 ブロック blk IndexEx tensi onDa t a 0が格納される。
ブロック MklndexExtensionDataOにおいて、 フィールド Typelndic atorは、 次に続くデータの種類を示す、 I SO 646に規定された符 号化方式で符号化した 4文字からなる文字列が記述される。 この第 3 1図の例では、 フィールド Typelndicatorに I S〇 646に規定の方 式で符号化された 4文字の文字列' 'IDEX"が記述され、 次に続くデータ 種類がィンデックスファイルにおける拡張データであることが示され る。
フィールド Typelndicatorに続けて 32ビットのデ一夕長を有する 領域 reservedが配され、 その次に、 32ビットのデータ長を有するフ ィールド TableOi ayListStar ddressが配される。 フィ一ルド Table OfPlayListStartAddressは、 ブロック blkTableOfPlayList 0の、 この ブロック blklndexExtensionDa O先頭を基準とした開始ァドレスが 示される。
フィールド TableOfPlayListSta Addressの次に、 32ビットのデ —夕長を有するフィ一ルド MakersPrivateDaiaStariAddressが配され ブロック! 3lkMakersPrivateData()のこのブロック blklndexExtens ionD ata()先頭を基準とした開始アドレスが示され、 192ビットのデー 夕長を有する領域 reservedを介してブロック blkUIAppInfoAVCHDOが 配される。 16ビットのデータ長を有するパディングワード padding_ wordが値 N1で示される回数だけ繰り返され、 次に、 ブロック blkTable OfPlayListsOが配される。 さらに続けて、 16ビットのデータ長を 有するパディングワード padding_TOrdが値 N2で示される回数だけ繰り 返され、 次にプロック MkMakersPrivateDataOが配される。 このブロ ック blkMakersPrivateDataOの後に、 16ビットのデータ長を有する パデイングワード padd i ng—wor dが値 N3で示される回数だけ繰り返され る。
なお、 ブロック blkUIAppInfoAVCHDOおよびブロック blkMakersPriv ateDataOは、 この発明と関連性が薄いので、 説明を省略する。
第 32図は、 上述したブロック MkTableOfPlayListsOの一例の構 造を表すシンタクスを示す。 フィールド Lengthは、 32ビットのデ一 タ長を有し、 このフィールド Lengthの直後からブロック blkTableOfPl ayListsOの最後のバイトまでのデータ長をバイト数で示す。 フィー ルド Lengthに続けて、 プレイパックタイトルを再生するためのプレイ リストに関する情報が記述されるブロック b 1 kF i r s tP 1 aybackT itlePla yListsOと、 メニュータイトルに関する情報が記述されるブロック bl kMenuTitlePlayListsOとが配される。 これらブロック blkFirstPlayb ackTitlePlayListsOおよびブロック blkMenuTitlePlayLisisOは、 こ の発明と関連性が薄いので、 説明を省略する。 次に、 16ビットのデータ長を有するフィールド NumberOfTiUePla yListPairが配される。 フィールド NumberOfTitlePlayListPairは、 プ レイバックタイトルおよびメニュータイトル以外のタイトルを再生す るためのプレイリス卜の数が記述される。 次の forループ文に従い、 フィ一ルド NumberOfTitlePlayLis airで示される数だけ、 ブロック b IkMovieTitlePlayListPair 0が記述される。 ブロック blkMovieTi UeP layListPairOは、 フィールド PlayListFileName、 フィールド PlayLis tAttributeおよびフィールド RefToTitleldを含む。 すなわち、 ブロッ ク blkMovieTitlePlayListPairOは、 この forループ文で示される ΕΠ 番目のプレイリストについて、 当該プレイリストのファイル名、 当該 プレイリストに付与された属性、 ならびに、 当該プレイリストの参照 タイトル I Dからなるプレイリストの情報を構造化したものである。 この forループ文による並び順は、 記録順とされる。 すなわち、 1 のプレイリス卜が追加されると、 フィール NumberOfTiUePlayListP airの値が " 1 "だけインクリメントされ、 既存のプレイリストの情報 の後ろに、 追加されたプレイリストの情報が追記される。
フィールド PlayListFileNameは、 40ビット （5バイト） のデータ 長を有し、 プレイリストのファイル名が I S O 646に規定された符 号化方式で符号化されて記述される。 フィールド PlayListFileNameの 次に、 6ビットのデータ長を有する領域 reservedを介してフィ一ルド PlayListAUributeが配される。 フィールド PlayListAttributeは、 2 ビットのデータ長を有し、 当該プレイリストに付与された属性を示す 。 プレイリス卜は、 その成因に基づき、 クリップの生成と共に生成さ れるプレイリストに対応する第 1の種類と、 既存のタイトルあるいは プレイリス卜の一部または全部を用いて作成されるプレイリストに対 応する第 2の種類と、 メニュ一を再生するために用いる第 3の種類と の 3種類に分けられ、 各プレイリストには、 プレイリストの種類に応 じて、 それぞれ対応する属性 「Realj (第 1の種類） 、 属性 「Virtua U (第 2の種類） および属性 「Menu」 （第 3の種類） が付与される なお、 以下では適宜、 属性 「Real」 が付与されたプレイリストをリ アルプレイリスト、 属性 「Virtual」 が付与されたプレイリストをパ 一チャルプレイリスト、 属性 「Menu」 を付与されたプレイリストをメ ニュープレイリストと呼ぶ。
フィールド RefToTitleldは、 同一ループ内のフィールド PlayListFi leNameに示されるプレイリストが作成時に属するタイトルの I D (番 号） が記述される。 より具体的な例としては、 インデックスファイル " index.bdmv"内のブロック blklndexes ()における、 対応する値 title— idが記述される。 なお、 当該プレイリストがファーストプレイバック タイトルのみから再生される場合、 フィールド RefToTitleldの値は、 第 1の固定値、 例えば" OxFFFF"とされる。 また、 当該プレイリストが メニュータイトルのみから再生される場合は、 フィールド RefToTitle Idの値は、 第 2の固定値、 例えば" OxFFFE"とされる。
ここで、 リアルプレイリスト、 バーチャルプレイリストおよびメニ ユープレイリストについて、 概略的に説明する。 属性 「Real」 が付さ れるリアルプレイリストは、 例えばクリップの生成と共に生成され、 ディスクに記録される。 リアルプレイリス卜は、 素材を指す最初のプ レイリストとなることから、 オリジナルのプレイリストとも呼ばれる 。 一例として、 リアルプレイリストは、 生成されたクリップの先頭を I N点、 最後尾を OUT点としてそれぞれ指定する。
リアルプレイリストは、 ストリーム実体であるクリップを参照した プレイリストであって、 新規にクリップが作成されると、 作成された クリップを参照するリアルプレイリストが必ず作成される。 換言すれ ば、 ディスク上において、 どのリアルプレイリストからも参照されて いないクリップは存在しない。 したがって、 ディスク上におけるリア ルプレイリストの総再生時間は、 当該ディスク上に記録されたクリッ プの総再生時間に一致することになる。 すなわち、 ディスク上におけ る記録可能な残り時間は、 ユーザから見ると、 リアルプレイリストま たはリアルプレイリストのみから構成されるタイトルの記録可能時間 に一致する。 ·
リアルプレイリストは、 素材であるクリップと常に 1対 1の対応関 係を有し、 リアルプレイリスト,を編集などにより削除すると、 対応す るクリップも、 ディスク上から削除される。 また、 リアルプレイリス トにおいて、 クリップの参照区間の一部を削除すると、 削除された部 分に応じて、 当該リアルプレイリストに対応するクリップの一部も削 除される。 このように、 リアルプレイリストに対する編集は、 デイス ク上に記録されるクリップの実体の改変を伴う編集であるため、 実体 編集あるいはリアル編集などと呼ばれる。
属性 「Vi r tual」 が付されるバーチャルプレイリストは、 既存の夕 ィトルあるいはプレイリストの一部または全部を用いて作成されるプ レイリストである。 パーチャルプレイリストは、 既存のクリップに対 して I N点および O U T点を設定し、 I N点および O U T点で定義さ れる区間を参照して作成したプレイリストである。
—例として、 パ一チャルプレイリストは、 上述レたリアルプレイリ ストに対して I N点および O U T点を指定する。 例えば、 複数のリア ルプレイリストに対し、 それぞれ I N点および O U T点を指定すると 共に、 それぞれ I N点および O U T点で指定される複数の区間の再生 順を指定する。 パーチャルプレイリストを元にして、 さらにパ一チヤ ルプレイリストを作成することもできる。 すなわち、 1または複数の パーチャルプレイリストに対して、 I N点および OUT点を指定する パーチャルプレイリストを作成することができる。
パーチャルプレイリストは、 編集において、 例えばサイズの大きな クリップ （ストリーム実体） を変更すること無しに、 高速に作成可能 である。 また、 パ一チャルプレイリストは、 削除する際も、 クリップ に対する参照関係のみを削除すればよく、 クリップ実体に対して変更 を加える必要が無い。 このように、 バーチャルプレイリストの編集は 、 クリップの実体の改変を伴わない編集であるため、 仮想編集あるい はバーチャル編集などと呼ばれる。
属性 「Menu」 が付されるメニュープレイリストは、 メニューを再生 するために用いるプレイリストであり、 メニューの作成および更新時 に生成される。 メニュープレイリストは、 すなわち、 メニュータイト ルを再生するためのム一ビーオブジェク卜から呼び出されるプレイリ ストである。
次に、 プレイリストファイル" xxxxx.mpls"に対して定義される一例 の拡張データブロックについて説明する。 第 33図は、 プレイリスト ファイル" xxxxx.mpls"内のブロック blkExtensionDataOにおけるブロ ック DataBlockO (第 27図参照） の一例の構造を表すシンタクスを 示す。 この第 33図の例では、 ブロック DataMockOがブロック blkM ayListExtensionDataOとして記述されている。
先ず、 上述の第 27図を参照し、 プレイリストファイル" xxxxx.mpl s"内のブロック MkJExtensionDataOにおいて、 フィール ExiDaiaTyp eおよびフィ一ルド ExtDataVersionがそれぞれ所定の値、 例えば上述 と同様にそれぞれ値" 0x1000"、 値" 0x0100"とする。
ブロック blkPlayListExtensionDataOにおいて、 フィール H Type In dicatorは、 次に続くデータの種類を示す、 I S0646に規定され た符号化方式で符号化した 4文字からなる所定の文字列が記述される 。 このフィールド Typelndicatorに記述される文字列によって、 次に 続くデータ種類がプレイリストファイルにおける拡張デー夕であるこ とが示される。
フィールド Typelndicatorの次に、 32ビット （4バイト） のデー 夕長を有する領域 reservedを介して 32ビットのデータ長を有するフ ィールド PlayListMarkExtStartAddressが配され、 その次に、 32ビ ッ卜のデータ長を有するフィールド MakersPrivateDataStartAddress が配される。 フィールド PlayListMarkExtStartAddressおよびフィー ルド MakersPrivateDataStartAddressは、 それぞれ、 ブロック blkPlay ListMarkExt ()およびブロック blkMakersPrivateDataOの、 このプロ ック MkPlayListExtensionDataO先頭を基準とした開始ァドレスが示 される。
フィ一ルド MakersPrivateDataStartAddressの次に、 1 92ビット のデ一夕長を有する領域 reservedを介してブロック blkPlayListMeta( )が配される。 1 6ビットのデータ長を有するパディングワード paddi ng一 wordが値 N1で示される回数だけ繰り返され、 次に、 ブロック blkPl ayListMarkExtOが配される。 さらに、 1 6ピットのデータ長を有す るパディングヮ一ド padding_wordが値 N2で示される回数だけ繰り返さ れ、 次に、 ブロック MMakersPrivateDataOが配される。 プロック bl kMakersPrivateDataOの後ろには、 1 6ビットのデータ長を有するパ ディングヮ一ド padd i ng— wor dが値 N3で示される回数だけ繰り返される 第 34図は、 ブロック blk ayListMetaOの一例の構造を表すシン タクスを示す。 フィールド Lengthは、 32ビットのデータ長を有し、 このフィールド Length直後からこのプロック1)11^1& 1^3(¾16{&()の終 わりまでのデータ長を示す。 フィールド Lengthの次に、 それぞれ 1 6 ビットのデータ長を有するフィ一ルド Maker IDおよぴフィールド Maker ModelCodeが配される。 フィールド MakerlDおよびフィールド MakerMod elCodeは、 このプレイリストファイルを更新したメーカおよび当該メ 一力の機種を識別する情報がそれぞれ記述される。
フィールド MakerModelCodeの次に、 32ビットのデータ長を有する 領域 reservedを介して 1 6ビットのデータ長を有するフィールド ReiT oMenuThumbnaillndexが配される。 このフィールド RefToMenuThumbnai llndexは、 このプレイリストファイルにより再生される一連のクリツ プを代表するサムネイル画像が存在する場合、 そのサムネイル画像を 特定するサムネイル番号が記述される。 次に 8ビッ卜のデータ長を有 するブロック blkTiraeZoneOが配され、 このプレイリストファイルを 更新した際に、 装置に設定されているタイムゾーンを示す情報が記述 される。 さらに 56ビットのデータ長を有するフィールド RecordTime AndDateが配され、 このプレイリストファイルを更新した時刻および 日付が記述される。
フィールド RecordTimeAndDateの次に、 8ビットのデータ長を有す る領域 reservedを介して、 それぞれ 8ビットのデータ長を有するフィ ールド ayListCharacterSetおよびフィールド PlayListNameLengthが 配され、 さらに続けて、 25 5バイトのデータ長を有するフィールド PlayListNameが配される。 これらフィールド PlayListCharacterSet、 フィールド ayListNameLengthおよびフィールド PlayListNameにより 、 このプレイリストファイルにより示されるプレイリストに付された 名前に関する情報が記述される。
すなわち、 フィールド PlayUstCharacterSetは、 フィールド PlayLi stNameに記述されている文字列の文字セットが示される。 フィールド PlayListNameLengthは、 フィールド PlayLis tNameに記述されるプレイ リスト名のバイト長を示す。 フィールド PlayListNameは、 このプレイ リストに付された名前が記述される。 このフィールド PlayListNameに おいて、 左から、 フィールド PlayListNameLengthに示されるだけのパ ィト数が有効な文字列であり、 それがこのプレイリストの名前とされ る。 フィールド PlayListNameの中で、 フィールド PlayListNameLength で示された有効な文字列の後のパイト列には、 どのような値が入って いてもよい。
フィールド PlayListNameの次に、 ブロック Addi tionaし data 0が配 される。 このブロック Additionaし dataOは、 追加的な情報を格納す るために予約された領域であって、 32ビットのデータ長を有するフ ィールド Length2に示される値のバイト数分のデータ長を有する領域 が予約される。
第 3 5図は、 プレイリストファイルにおけるブロック blkMakersPri va t eDa t a 0の一例の構造を表すシンタクスを示す。 ブロック b 1 kMake r sPrivateDataOは、 このプレイリストファイルに関して、 メーカ独自 の情報が記述されるブロックである。 フィールド Lengthは、 32ビッ トのデ一夕長を有し、 このフィ一ルド Length直後からこのプロック bl kMakersPrivateDataOの終わりまでのデータ長を示す。 このフィール ド Lengthは、 値" 0"でこの¾^1^^?1"^&160& （）に情報が記述されて いないことを示す。 フィールド Lengthが値" 0"以外で、 if文以下の記 述がなされる。
フィールド DataBlockStartAddressは、 3 2ビットのデ一夕長を有 し、 このシンタクス中の、 メーカ独自情報本体が格納されるブロック DataBlockOの開始ァドレスを、 このブロック blkMakersPrivateData( 1
)の先頭バイトからの相対バイト数で示す。 24ビットのデータ長を 有する領域 reservedを介して、 8ピットのデータ長を有するフィ一ル ド N berOfMakerEntriesが配される。
次の for文に従い、 フィールド NumberOfMakerEntriesで示される個 数だけ拡張データのエントリ、 すなわち、 フィールド MakerID、 フィ ール HMakerModelCode フィールド MpdStartAddressおよびフィール ド MpdLengthが記述される。 フィールド MakerlDおよびフィ一ルド Make rModelCodeは、 それぞれ 1 6ピットのデータ長を有し、 メーカの識別 情報および当該メーカによる機種の識別情報が記述される。 また、 フ ィールド MpdStartAddressおよびフィールド MpdLengthは、 それぞれ 3 2ビットのデータ長を有し、 拡張データの本体が格納されるブロック DataBlockOの、 このブロック blkExtensionDataOの先頭バイトから の相対パイト数による開始ァドレスと、 データ長とを示す。
フィールド NumberOfMakerEniriesで示される個数だけ拡張データの エントリが記述されると、 それぞれ 1 6ビットのデータ長を有し任意 のデ一夕列からなるフィールド padding一 wordが、 2フィ一ルドを組と して任意の回数 L1だけ繰り返される。 その後、 拡張データの本体が格 納されるブロック DataBlockOが記述される。 ブロック DataBIockOは 、 1以上の拡張データ ext— dataが格納される。 すなわち、 フィールド MakerlDおよびフィールド MakerModelCodeで示されるメーカおよび機 種毎に、 メ一力独自の拡張データがプロック DataBlockOに格納され る。 それぞれの拡張データは、 上述したフィールド MpdStartAddress およびフィ一ルド MpdLengthに基づき、 ブロック DataBlockOから取り 出される。
なお、 プレイリストファイルにおける拡張データブロック blkPlayL istExtensionDataO内のブロヅク MkPlayListMarkExt ()は、 この発明 と関連性が薄いので、 説明を省略する。
次に、 クリップィンフオメーションファイル" zzzzz.clpi"に対して 定義される一例の拡張データブロックについて説明する。 第 36図は 、 クリップィンフオメーションファイル内のブロック blkExtensionDa ta()におけるブロック DataBlockO (第 27図参照） の一例の構造を 表すシンタクスを示す。 この第 36図の例では、 ブロック DataBlock( )がブロック blkClipExtensionDataOとして記述されている。
ブロック blkClipExtensionDataOにおいて、 フィールド Typelndica torは、 次に続くデータの種類を示す、 I S0646に規定された符 号化方式で符号化した 4文字からなる所定の文字列が記述される。 こ のフィ一ルド Typelndicatorに記述される文字列によって、 次に続く データ種類がクリップインフォメーションファイルにおける拡張デー 夕であることが示される。
フィ一ルド Typelndicatorの次に、 32ビット （4パイト） のデ一 タ長を有する領域 reservedを介して、 それぞれ 32ビットのデータ長 を有するフィールド ProgramlnfoExtStartAddressおよびフィールド Ma kersPrivateDataStartAddressが配される。 フィー レド ProgramlnfoEx tStartAddressおよびフィー レド MakersPrivateDataStariAddressW；、 それぞれ、 このブロック blkClipExtensionDataO内のプロック blkPro gramlnfoExt 0およびブロック MkMakersPrivateDataOの、 このブロ ック blkClipExtensionDataO先頭を基準とした開始ァドレスを示す。 フィールド MakersPrivateDataStartAddressの次に、 1 92ビット のデータ長を有する領域 reservedを介してブロック blkCl ipInfoExt 0 が配される。 16ピットのデータ長を有するパディングヮ一ド paddin g— wordが値 N1で示される回数だけ繰り返され、 次に、 ブロック MkPro gramlnfoExtOが配される。 続けて、 16ビットのデ一夕長を有する パディングヮ一ド padding一 wordが値 N2で示される回数だけ繰り返され 、 次に、 ブロック MkMakersPrivateDataOが配される。 ブロック blkM akersPrivateDataOの後ろには、 1 6ビットのデ一夕長を有するパデ ィングヮ一ド padding一 wordが値 N3で示される回数だけ繰り返される。 第 37図は、 ブロック blkProgramlnfoExtOの一例の構造を表すシ ンタクスを示す。 フィールド Lengthは、 32ビットのデータ長を有し 、 このフィールド Lengthの直後からブロック blkProgramlnfoExt ()の 最後までのデータ長を示す。 次に、 8ピットのデータ長を有する領域 reservedを介して、 フィールド NumberOfProgramSequenceが配される 。
フィ一レド NumberOfProgramSequenceま、 8ヒッ卜のつ "一タ を有 し、 このブロック blkProgramlnfoExtOに記述されるプログラムシ一 ケンスの情報の数が示される。 この例では、 フィールド NmnberOfProg ramSequenceの値が" 1"に固定的とされている。 次の第 1の forループ 文に従い、 フィールド NumberOfProgramSequenceで示される数だけ、 フィ一ルド NumberOiStreafflCodingInioExtInPs[i]およびさらに次の第 2の forループ文が繰り返される。 第 2の forループ文により、 8ビッ トのデ一夕長を有するフィ一ルド NumberOfStreamCodingInfoExUnPs[ Πで示される数だけ、 フィールド S t reamP ID [i] [j ]およびブロック b lk StreamCodinglnfoExt (i， j)の組が格納される。
1 6ビットのデータ長を有するフィールド StreamPID[i] [j]は、 値 [ i]および値 []']で指し示されるテーブルを構成し、 [i]番目のプロダラ ムシ一ケンスによって参照された PMT (Program Map Table)に記述 されたエレメン夕リストリームに対応する P I Dの値を示す。 次のブ ロック blkStreamCodinglnfoExt i,]')は、 値 [i]および値 [j]で示され るエレメン夕リストリームの符号化方式に関する情報が記述される。 第 38図は、 ブロック blkStreamCodingInfoExt(i，j)の一例の構造 を表すシンタクスを示す。 フィールド Lengthは、 8ビットのデータ長 を有し、 このフィールド Lengthの直後からプロック blkStreamCodingl nfoExt(i, j)の最後までのデータ長を示す。 次のフィールド StreamCod ingTypeは、 8ビットのデータ長を有し、 対応するストリームの符号 化の種類を示す。 このフィールド StreamCodingTypeが値" OxlB"で、 if 文以下の記述がなされ、 最初の 8ビットのデ一夕長を有するフィール ド HorizontalSizeにより、 画面の垂直方向のサイズすなわちライン数 を示す。 なお、 ブロック blkStreamCodinglnfoExt (i， j)において、 フ ィールド HorizontalSize以下の情報は、 この発明と関連性が薄いので 、 説明を省略する。
また、 クリップィンフオメーションファイル内の拡張データブロッ ^blkClipExtensionDataOにおけるブロック CI ipEnfoExt 0およびブ ロック blkMakersPrivateDataOは、 この発明と関連性が薄いので、 説 明を省略する。
次に、 仮想プレーヤについて、 概略的に説明する。 上述したような データ構造を有するディスクがプレーヤに装填されると、 プレーヤは 、 ディスクから読み出されたムービーオブジェク卜などに記述された コマンドを、 プレーヤ内部のハードウエアを制御するための固有のコ マンドに変換する必要がある。 プレーヤは、 このような変換を行うた めのソフトウエアを、 プレーヤに内蔵される ROM(Read Only Me or y)に予め記憶している。 このソフトウェアは、 ディスクとプレーヤを 仲介してプレーヤに A VCHDフォーマツトの規定に従った動作をさ せることから、 仮想プレーヤと称される。
第 39図 Aおよび第 39図 Bは、 この仮想プレーヤの動作を概略的 に示す。 第 39図 Aは、 ディスクのローデイング時の動作の例を示す 。 ディスクがプレーヤに装填されディスクに対するイニシャルァクセ スがなされると （ステップ S 30) 、 1のディスクにおいて共有的に 用いられる共有パラメ一夕が記憶されるレジス夕が初期化される （ス テツプ S 3 1) 。 そして、 次のステップ S 32で、 ム一ビーオブジェ クトなどに記述されたプログラムがディスクから読み込まれて実行さ れる。 なお、 イニシャルアクセスは、 ディスク装填時のように、 ディ スクの再生が初めて行われることをいう。
第 3 9図 Bは、 プレーヤが停止状態からユーザにより例えばプレイ キーが押下され再生が指示された場合の動作の例を示す。 最初の停止 状態 （ステップ S 40) に対して、 ユーザにより、 例えばリモートコ ントロールコマンダなどを用いて再生が指示される （UO ： User Ope ration) 。 再生が指示されると、 先ず、 レジスタすなわち共通パラメ —夕が初期化され （ステップ S 41) 、 次のステップ S 42で、 ムー ビーオブジェクト実行フェイズに移行する。
ムービーオブジェクトの実行フェイズにおけるプレイリストの再生 について、 第 40図を用いて説明する。 UOなどにより、 タイトル番 号 # 1のコンテンツを再生開始する指示があった場合について考える 。 プレーヤは、 コンテンツの再生開始指示に応じて、 上述した第 2図 に示されるインデックステーブル（Index Table)を参照し、 タイトル # 1のコンテンツ再生に対応するオブジェクトの番号を取得する。 例 えばタイトル # 1のコンテンツ再生を実現するォブジェクトの番号が # 1であったとすると、 プレーヤは、 ムービーオブジェクト # 1の実 行を開始する。
この第 40図の例では、 ムービーオブジェクト # 1に記述されたプ ログラムは 2行からなり、 1行目のコマンドが" Play PlayList(l)"で あるとすると、 プレーヤは、 プレイリスト # 1の再生を開始する。 プ レイリスト # 1は、 1以上のプレイアイテムから構成され、 プレイァ ィテムが順次再生される。 プレイリスト # 1中のプレイアイテムの再 生が終了すると、 ムービーオブジェクト # 1の実行に戻り、 2行目の コマンドが実行される。 第 4 0図の例では、 2行目のコマンドが" j um p MenuTi t le"であって、 このコマンドが実行されインデックステープ ルに記述されたメニュータイトル（MenuTi Ue)を実現するムービーォ ブジェク卜の実行が開始される。
次に、 この発明の実施の一形態について説明する。 この発明では、 記録媒体にクリップが記録される際に、 記録されるクリップに基づく チヤプ夕を既存のプレイリストに対して追記するようにされる。 そし て、 チヤプタを既存のプレイリストに対して追記する際に、 プレイリ ストに所定に設けられた制約に基づき当該クリップに基づくチヤプタ が当該プレイリストに追記可能か否かを判断する。 判断の結果、 追記 が可能であるとされれば、 当該クリップに基づくチヤプ夕を当該プレ イリストに対して追記する。 一方、 追記が不可であると判断されれば 、 新規にプレイリストを作成し、 この新規に作成されたプレイリスト に対して、 記録されたクリップに基づくチヤプ夕を登録する。
このように記録制御を行うことで、 ユーザは、 プレイリストに設け られた制約を意識することなくクリップの記録を行うことができ、 記 録に際する操作性が向上され、 利便性に優れる。
第 4 1図は、 この発明の実施の一形態に適用可能な記録装置の一例 の構成を概略的に示す。 この記録装置は、 入力されたディジタルビデ ォデ一夕およびディジ夕ルオーディォデ一夕を、 所定の方式で圧縮符 号化および多重化した A Vストリームを記録媒体に記録するようにし ている。
この第 4 1図に例示される記録装置は、 外部から入力されるビデオ データおよびオーディォデ一夕を記録媒体に記録する、 単独の記録装 置として用いることもできるし、 光学系や撮像素子などを備えたカメ ラブロックと組み合わせ、 撮像した撮像信号に基づくビデオデータを 記録媒体に記録する、 ビデオカメラ装置の記録ブロックとして用いる こともできる。
適用可能な圧縮符号化や多重化の方式としては、 様々に考えられる 。 例えば、 H. 2 64 I AVCに規定される方式を、 この発明の実施 の一形態の圧縮符号化として適用することができる。 これに限らず、 MP E G 2方式に基づき圧縮符号化を行うようにしてもよい。 また、 多重化方式は、 例えば MP EG 2システムズを適用することができる 。 以下では、 ビデオデータの圧縮符号化を H. 2 64 I AVCに規定 される方式に準じて行い、 ビデオデータおよびオーディォデ一夕の多 重化を、 MP E G 2システムズに規定される方式に準じて行うものと して説明する。
制御部 30は、 例えば C PU(Central Processing Unit)、 R AM( Random Access Memory)および R〇 M (Read Only Memory など力 らな り （図示しない） 、 ROMに予め記憶されたプログラムやデータに基 づき、 RAMをワークメモリとして用いてこの記録装置の記録部 1 0 の各部を制御する。 なお、 制御部 3 0と記録部 1 0の各部とを接続す る経路は、 繁雑さを避けるために、 第 41図では省略している。
U I (User Inter face)部 3 1は、 この記録装置の動作をュ一ザが操 作するための操作子が所定に設けられ、 操作子に対する操作に応じた 制御信号を出力する。 この制御信号は、 制御部 30に供給される。 制 御部 3 0は、 ユーザ操作に応じて U I部 3 1から供給された制御信号 に基づきなされるプログラムの処理により、 記録部 1 0の各部の動作 を制御する。 例えば、 U I部 3 1に対してなされた操作に応じて、 記 録装置による記録動作の開始および停止の動作が制御部 30により制 御される。
一例として、 制御部 30は、 所定のプログラムからなりソフトゥェ ァの基本的な機能を提供する OS (Operating System)上で、 ユーザィ ン夕ーフェイスの提供や記録部 1 0の各部の制御を提供するアプリケ ーションソフトウェアを実行させると共に、 ソフトウェアと記録部 1 0各部の実際のハードウエアとの間の仲介を行うドライバソフトウェ ァを実行させる。 OSは、 さらに、 後述する記録媒体 20上に記録さ れたファイルやデータを管理するためのファイルシステムを提供する 。 アプリケーションソフトウェアは、 OSにより提供されるファイル システムを介して、 記録媒体 20上に記録されたファイルにアクセス する。
ベ一スパンドのディジタルビデオデータが端子 40から入力される 。 また、 当該ディジタルビデオデータに伴い、 ベースバンドのデイジ タルォ一ディォデ一夕が端子 41から入力される。
ディジタルビデオデータは端子 40から記録部 1 0に入力され、 ビ デォエンコーダ 1 1に供給される。 ビデオエンコーダ 1 1は、 供給さ れたディジタルビデオデータを、 所定の方式で以て圧縮符号化する。 H. 264 1 AVCに規定される方式に準じて圧縮符号化がなされる この例では、 例えば、 D C T (Discrete Cosine Transform)と画面内 予測とによりフレーム内圧縮を行うと共に、 動きべクトルを用いたフ レーム間圧縮を行い、 さらにエントリピー符号化 ¾行い圧縮効率を高 める。 ビデオエンコーダ 1 1で圧縮符号化されたディジタルビデオデ —夕は、 H. 264 I AVCのエレメン夕リス卜リーム （E S) とし て、 マルチプレクサ （MUX) 1 3に供給される。
ディジタルオーディオデータは端子 41から記録部 1 0に入力され 、 オーディオエンコーダ 1 2に供給される。 オーディオエンコーダ 1 2は、 所定の圧縮符号化方式、 例えば AC 3 (Audio Code number 3) により圧縮符号化される。 オーディオデータの圧縮符号化方式は、 A C 3に限られるものではない。 オーディオデータを圧縮符号化せず、 ベースバンドのデータのまま用いることも考えられる。 圧縮符号化さ れたディジタルオーディオデータは、 マルチプレクサ 1 3に供給され る。
マルチプレクサ 1 3は、 それぞれ圧縮符号化されて供給されたディ ジタルビデオデータおよびディジ夕ルオーディオデータを所定の方式 で多重化し、 1本のデータストリームとして出力する。 MPEG2シ ステムズに準じて多重化が行われるこの例では、 MPEG2のトラン スポートストリームを用いて、 供給された圧縮ビデオデータおよび圧 縮オーディオデータを時分割で多重化する。 例えば、 マルチプレクサ 1 3は、 バッファメモリを有し、 供給された圧縮ビデオデ一タおよび 圧縮オーディオデータをバッファメモリに溜め込む。
バッファメモリに溜め込まれた圧縮ビデオデ一夕は、 所定サイズ毎 に分割されヘッダが付加されて、 P E S (Packeiized Elementary Str earn)パケット化される。 圧縮オーディオデ一夕も同様に、 所定サイズ 毎に分割されへッダが付加されて P E Sパケット化される。 ヘッダに は、 パケットに格納されるデータの再生時刻を示す PT Sゃ復号時刻 を示す DTS (Decoding Time Stanp)といった、 MPEG2システム ズに規定される所定の情報が格納される。 PE Sパケットは、 さらに 分割されてトランスポートパケット （TSパケット） のペイロードに 詰め込まれる。 T Sパケットのヘッダには、 ペイロードに詰め込まれ たデータを識別するための P I D (Packet Identification)が格納さ れる。 マルチプレクサ 1 3から出力された TSパケットは、 ストリー ムバッファ 14に一旦溜め込まれる。
なお、 TSパケットは、 実際には、 MUX 1 3においてさらに所定 サイズのヘッダが付加されて出力される。 この、 TSパケットに対し て所定のヘッダを付加したパケットを、 ソースパケットと呼ぶ。
記録制御部 1 5は、 記録媒体 20に対するデータの記録を制御する 。 記録媒体 20としては、 例えば記録可能なタイプの DVD(Digital Versatile Disc)を用いることができる。 これに限らず、 記録媒体 2 0としてハ一ドディスクドライブを用いてもよいし、 半導体メモリを 記録媒体 20に適用することも可能である。 また、 記録媒体 20とし て、 より大容量を実現した B 1 u— r a y D i s c (ブルーレイデ イスク ：登録商標） を適用することも考えられる。
記録制御部 1 5は、 ストリ一ムパッファ 14に溜め込まれたデータ 量を監視し、 ストリームバッファ 14に所定量以上のデ一夕が溜め込 まれると、 ストリームバッファ 14から記録媒体 20の記録単位分の データを読み出して記録媒体 20に書き込む。
管理情報処理部 1 6は、 例えば CPU、 ヮ一クメモリとしての R A Mおよびプログラム所定のデータが予め記憶される ROMからなる （ 図示しない） 。 これに限らず、 管理情報処理部 1 6は、 例えば制御部 30におけるプログラム処理で管理情報処理部 16の機能を実現する ことも可能である。 この場合、 例えば制御部 30の有する RAMが揮 発性メモリ 1 7として用いられると共に、 不揮発性メモリ 1 8が制御 部 30に接続される。
管理情報処理部 16は、 記録データに基づき、 揮発性メモリ 1 7を ワークメモリとして用いて、 上述したインデックスファイル" index. b dmv" , ムービーオブジェクトファイル" MovieObject.bdmv"、 プレイリ ストファイル" xxxxx.rapls"およびクリップィンフオメーションフアイ P2007/060081 ル" zzzzz. dpi"に格納するための情報を生成する。 生成された情報は 、 所定のタイミングで記録媒体 2 0に書き込まれる。
一例として、 管理情報処理部 1 6は、 マルチプレクサ 1 3から記録 データの時間情報を取得すると共に、 記録制御部 1 5から記録データ の記録媒体 2 0に対するアドレス情報を取得し、 取得されたこれら時 間情報およびアドレス情報に基づき E P— m a p情報が生成される。 また、 U I部 3 1に対する記録開始、 記録終了の操作に応じて制御部 3 0から出力される制御信号と、 マルチプレクサ 1 3および記録制御 部 1 5からの記録データに関する情報とに基づき、 クリップインフォ メ一シヨンファイル" zzzzz. clpi"の生成が行われると共に、 生成され たクリップインフォメーションファイルの情報がプレイリストフアイ ルに追記され、 プレイリストファイル" xxxxx. mpls"の更新が行われる プレイリストファイルの更新の際に、 クリップィンフオメーシヨン ファイルの情報がプレイリストファイルに追記されることでプレイリ ストファイルに対して所定に設けられた制約を満足するか否かを判断 する。 判断の結果、 制約を満足しないと判断されれば、 新規にプレイ リストファイルが作成され、 生成されたクリップィンフオメ一シヨン ファイルの情報が新規に作成されたプレイリストファイルに記録され る。
さらに、 記録媒体 2 0に対して新規に記録が行われる際には、 イン デックスファイル" index, bdmv"やム一ビ一オブジェクトファイル" Mov i eOb c t . b dfflv"の生成または更新が行われる。
第 4 2図は、 この発明の実施の一形態に適用可能な一例のデータ構 造を示す。 インデックスファイル" index. bdmv"は、 1乃至複数のタイ トルを有する。 ムービーオブジェク 7 7 "Movi e0bj ec i . bdmv' 、 ィンデックスファイル" index, bdniv"が有する夕ィトルに対応して、 1乃至複数のムービーオブジェクトを含む。 ムービーオブジェクトの それぞれは、 1つのプレイリストファイル" xxxxx.mpls"を呼び出す。 プレイリストファイル" xxxxx.mpls"は、 1乃至複数のプレイアイテム を含み、 プレイアイテムのそれぞれは、 クリップインフォメーション ファイル" zzzzz. dpi"を参照する。 クリップィンフオメイションファ ィル" zzzzz.clpi"は、 クリップの実体であるクリップ AVストリーム ファイル" zzzzz.m2ts"と 1対 1の関係にある。
このような構造において、 ュ一ザには、 インデックスファイル" ind ex.bdmv"が有するタイトル単位で、 記録媒体に記録されたクリップが 見えることになる。 ユーザが所望のタイトルを選択すると、 ムービー オブジェクトファイル" MovieObject.bdmv"から当該タイトルに対応す るムービーオブジェクトが参照される。 そして、 参照されたム一ビー オブジェクトに記述されたプレイリストファイル" xxxxx.mpls"が呼び 出され、 プレイリストファイルに含まれるプレイアイテムに従いクリ ップインフォメーションフアイル" zzzzz.clpi"が参照され対応するク リップ AVストリームファイル" zzzzz.m2ts"が再生される。
プレイリストファイル" xxxxx.mpls"に対して時刻情報を示すマーク (プレイリストマーク） を設けることで、 ジャンプ位置を設定するこ とができる。 マークによってチヤプ夕が定義される。 チヤプ夕は、 ュ 一ザから見えるタイトル内の再生単位である。 記録開始位置には、 必 ずマークが設けられる。 記録開始位置以外の位置にマークを設けるこ ともできる。
すなわち、 プレイリストファイル" xxxxx.mpls"に対して、 例えば記 録開始に伴いプレイリストマークを設定すると共に、 クリップを参照 するプレイアイテムを登録することで、 当該プレイリストファイルに 対してチヤプタが形成される。 換言すれば、 プレイリストファイルに 対してプレイリストマークを記録すると共に、 プレイアイテムを記録 することで、 当該プレイリストファイルに対してチヤプ夕が記録され るといえる。
上述したように、 リアルプレイリストは、 クリップと共に生成され る。 第 42図の例では、 プレイリストファイル" 00000. mpls"、 " 00200 .mpls"および" 00018. fflpls"がリアルプレイリストの属性を有する。 これらのうち、 プレイリストファイル" OOOOO.mpls"は、 新規に生成 されたクリップの情報をプレイリス卜に追記記録していく例である。 例えば、 クリップ AVストリームファイル" 00001. m2ts"に対応するク リップインフォメーションファイル" 00001. clpi"を参照するプレイァ ィテム # 0が既に格納されているプレイリストファイル" OOOOO.mpls" に対して、 新規に記録されたクリップ AVストリームファイル" 00125 .m2ts"に対応するクリップインフォメ一ションファイル" 00125· m2ts" を参照するプレイアイテム # 1が追記記録される。 プレイアイテムが 示す先頭の時刻には、 それぞれマークが設けられる。 このプレイリス トファイル" 00000.即 Is"を再生すると、 ますプレイアイテム # 0に基 づきクリップ AVストリームファイル" 00001. m2is"が再生され、 続け てプレイアイテム # 1に基づきクリップ AVストリームファイル" 001 25.m2ts"が再生される。
プレイリストファイル" 00200.mpls"は、 1のクリップに対して 1の プレイリストファイルが生成され、 プレイリストファイルが唯一つの プレイアイテムのみを含む例である。
さらに、 プレイリストファイル" 00018.即 Is"は、 複数のプレイアイ テムが 1のクリップを参照する例である。 例えば、 記録開始および停 止によりプレイアイテムが生成されると共に、 1のクリツプに対して 60081 データが追記されていくような制御が考えられる。 プレイアイテム #
0の先頭にマークが設けられ、 プレイアイテム # 0およびプレイアイ テム # 1を連続的に再生することで、 クリップ AVストリームフ 7ィ ル" 00002. m2ts"の全体が再生される。
一方、 バ一チャルプレイリストは、 第 42図にプレイリストフアイ ル" 00005.即 Is"として示されるように、 既に存在するクリップに対し て再生区間を指定する。 この例では、 プレイリストファイル" 00005. m pis"に含まれるプレイアイテム # 0がクリップインフォメーションフ アイル" 00028. clpi"を参照して区間を指定し、 プレイアイテム # 1が クリップインフォメーションファイル" 00002. clpi"を参照して区間を 指定している。 また、 プレイアイテム # 0およびプレイアイテム # 1 の先頭に、 マークが設けられている。 プレイリストファイル" 00005. m Pis"を再生すると、 先ずプレイアイテム # 0に基づきクリップ AVス トリームファイル" 00028.m2ts"の指定区間が再生され、 続けて、 プレ ィアイテム # 1に基づきクリップ AVストリームファイル" 00002. m2t s"が再生される。
この発明では、 上述したように、 新規に記録されるクリップに基づ くチヤプタを、 既存のプレイリストファイルに追記するか、 新規プレ ィリストファイルを作成して記録するかを、 プレイリストファイルに 所定に設けられた制約に基づき判断している。 プレイリストファイル に設けられる制約の一例を以下に示す。 制約には、 フォーマット上の 制約、 実装仕様上の制約、 商品仕様上の制約などが考えられる。
フォーマット上の制約としては、 以下の制約 （1) 〜制約 （7) の 各項目が考えられる。
制約 （1) ： 1のプレイリストファイルに存在可能なプレイアイテム 数の上限。 制約 （2 ) ： 1のプレイリストファイルに存在可能なプレイリストマ ーク数の上限。
制約 （3 ) ： 1のプレイリストファイルが複数のクリップを参照する 場合に、 参照される複数のクリップそれぞれの所定のビデオ属性が一 致していなければならない。
制約 （4〉 ： 1のプレイリストファイルのファイルサイズの上限。 制約 （5 ) ： 1のプレイリストファイルに関連できるクリップインフ オメ一シヨンファイルの合計ファイルサイズの上限。
制約 （6 ) ： 1のプレイリストファイルに関連しているクリップイン フオメ一ションファイル内の粗い単位で検索を行うェントリポイント の合計の上限。
制約 （7 ) ： 1のプレイリストファイルに関連しているクリップイン フオメ一ションファイル内の精密な単位で検索を行うェントリポイン 卜の合計の上限。
これらのうち、 制約 （1 ) のプレイアイテム数および制約 （2 ) の プレイリストマーク数に関して、 フォーマット上、 1のプレイリスト ファイルに存在可能なプレイアイテム数の上限が例えば 9 9 9個とさ れ、 1のプレイリストファイルに存在可能なプレイリストマーク数の 上限が例えば 9 9 9個とされる。 したがって、 新規にクリップを記録 する際に、 当該クリップに基づくチヤプタを追記しょうとするプレイ リストファイルにおいて、 チヤプ夕を追記した際にこれらの制約が満 足されるか否かを判断する必要がある。
制約 （3〉 のビデオ属性に関して、 1のプレイリストファイルが参 照する複数のクリップ A Vストリームファイルにおいて、 例えば、 画 枠サイズ、 走査方式、 アスペクト比、 フレームレート、 コ一デックの 種別といった、 ビデオデ一夕の符号化に関わる属性が不変であるよう に、 フォーマットにおいて規定されている。 したがって、 新規にクリ ップを記録する際に、 当該クリップに基づくチヤプタを追記しようと するプレイリス卜ファイルに既に記録されているプレイアイテムによ り参照されるクリップにおけるこれらの属性と、 新規に記録しようと するクリップにおけるこれらの属性とを比較する必要がある。
制約 （4 ) の 1のプレイリストファイルのファイルサイズと、 制約 ( 5 ) の 1のプレイリストファイルに関連しているクリップインフォ メ一ションファイルの合計ファイルサイズとに対して、 フォーマツト 上、 それぞれ上限が規定されている。 このファイルサイズの規定は、 記録装置および再生装置のメモリ容量に関連する。
すなわち、 例えば記録時に、 記録されているクリップに対応するプ レイリストゃ、 記録されているクリップのクリップィンフオメーショ ンファイルは、 一旦、 記録装置のメモリに格納され、 メモリ上で記録 に伴うプレイリストファイルゃクリップィンフオメーションファイル の更新処理がなされる。 そして、 メモリに格納されたこれらプレイリ ストファイルゃクリップインフォメーションファイルは、 所定のタイ ミングで記録媒体に書き込まれる。 プレイリストファイルや、 1のプ レイリストファイルに関連しているクリップインフォメーションファ ィルの合計ファイルサイズに制限を設けることで、 例えば記録中にメ モリに空き容量が無くなってしまい記録が強制的に停止されるなどの 状態になることが防がれる。
プレイリストファイルのファイルサイズの上限は、 例えば 6 0 0 k B (キロバイト） が上限とされる。 また、 1のクリップインフォメー シヨンファイルのファイルサイズの上限が例えば 1 M B (メガバイト ) とされている場合、 1のプレイリストファイルに関連しているクリ ップインフォメーションファイルの合計のフアイルサイズの上限は、 例えば 2MBとされる。
制約 （6) および制約 （7) の、 エントリポイントの上限は、 上述 のクリップインフォメーションファイルのファイルサイズの上限に関 連する。 すなわち、 既に説明したように、 粗い単位で検索を行うェン トリポイントおよび精密な単位で検索を行うエントリポイントは、 ク リップインフォメーションファイル内のブロック MkCPlOにおけるブ ロック MkEPMapOに格納される情報である。 すなわち、 粗い単位で検 索を行うェントリポィントは、 ブロック MkEPMapOにおけるフィール ド PTSEPCoarseおよびフィールド SPNEPCoarseであり、 精密な検索を行 うエントリポイントは、 ブロック MkEPMapOにおけるフィールド PTSE PFineおよびフィ一ルド SPNEP ineである。
フォーマット上、 粗い単位で検索を行うエントリポイントと、 精密 な単位で検索を行うエントリポイントとのそれぞれに対し、 1のプレ ィリストファイルに関連しているクリップインフォメーションフアイ ルについて合計した数に対して上限が規定されている。 したがって、 新規にクリップを記録しょうとする際に、 当該クリップを参照するプ レイアイテムを追記しょうとするプレイリストファイルにおいて、 プ レイアイテムを追記した際にこれらの制約が満足されるか否かを判断 する必要がある。
実装仕様上の制約としては、 以下の項目が考えられる。
制約 （8) ：プレイリストファイルにおける拡張データブロック内の ブロック blkMakersPrivateDataOについて、 他機で記録したプレイリ ストファイルのブ Ciック blkMakersPrivateDataOの情報を引き継ぐこ とができない場合は、 当該プレイリストファイルを更新してはならな い。
例えば、 プレイリストファイルにおける拡張データブロック内のブ ロック b lkMakersPr ivateDat a Oは、 第 3 5図においてブロック Dat aBl ock ()に示されるように、 特にデータサイズが制限されていないため 、 機器によっては、 数 1 0 0 k Bといった、 比較的大きなデータサイ ズのデータを書き込む仕様も考えられる。 機器の実装によっては、 例 えばメモリ容量の制限などの要因により、 他機で記録されたこのよう な大きなサイズのブロック b lkMakersPr ivat eDat a Oの情報を引き継い でプレイリストファイルの更新や編集を行うことが困難であることも 考えられる。
商品仕様上の制約としては、 以下の項目が考えられる。
制約 （9 ) ：タイトルやチヤプタに関して他機と概念が異なる場合で も、 ユーザの混乱を招かないようにする必要がある。
制約 （1 0 ) ：規定時間以上の連続撮影および記録可能である必要が ある。
制約 （9 ) のタイトルおよびチヤプタに関して、 機器によって、 プ レイリストおよびチヤプ夕の構成方法が異なることが考えられる。 こ のような機器間で、 クリップの記録された記録媒体を交換した場合に 、 例えば再生時におけるタイトルの表示などに不都合が生じる可能性 がある。
一例として、 テレビジョン放送を録画するようにされた据置型の記 録再生装置 （ビデオデッキなど） では、 1番組が 1プレイリストとし 、 5分間隔で自動的にプレイリストマークを設けてチヤプ夕を構成す る仕様とされ、 ビデオカメラ装置では 1撮影毎、 すなわち記録開始時 にプレイリストマークを設けてチヤプ夕を構成し、 複数のチヤプタを 1プレイリストに登録する仕様であるものとする。 また、 据置型の記 録再生機器ではプレイリストの先頭のみサムネイル画像を表示し、 チ ャプタ毎のサムネイル画像を表示しないような仕様であるとする。 このような条件において、 据置型の記録再生装置で作成されたプレ ィリストファイルが記録された記録媒体を、 ビデオカメラ装置に装填 し、 ビデオカメラ装置で記録されたクリップを参照するプレイアイテ ムを、 据置型の記録再生装置で作成されたプレイリストファイルに追 記して記録することを考える。 この場合、 据置型の記録再生装置で記 録されたある番組の最後の方のシーンとして、 ビデオカメラ装置で撮 影された映像がチヤプ夕として登録されることになる。 この記録媒体 を、 ビデオカメラ装置から再び据置型の記録再生装置に装填して再生 させると、 ビデオカメラ装置で撮影された映像によるチヤプ夕は、 サ ムネイル画像として表示されず、 以前に据置型の記録再生装置で記録 された番組の最後のシーンとして再生されてしまい、 不自然である。 制約 （1 0 ) の規定時間以上の連続撮影および記録に関して、 記録 機の仕様として、 所定時間以上の連続記録が保証されるのが一般的で ある。 一方、 上述のように、 フォーマット上、 1のプレイリストに関 連するクリップインフォメ一ションファイルのェントリポィン卜の合 計数に対して上限が設けられている。 例えば、 記録媒体の空き容量が 十分であっても、 新規に記録するクリップを参照するプレイアイテム を追記しょうとするプレイリストファイルにおいて、 既に参照されて いるクリップインフォメーションファイルにおけるエントリポイント の合計数とフォ一マツ卜上規定されている上限とから、 保証すべき所 定時間分のェン卜リボイント数を確保できない場合があり得る。 した がって、 新規にクリップを記録しょうとする際に、.当該クリップを参 照するプレイアイテムを追記しょうとするプレイリストファイルに関 連するェントリポイント数に基づき所定時間以上の連続記録が可能か 否かを判断する必要がある。
次に、 この発明の実施の一形態による、 新規記録するクリップに基 づくチヤプ夕の、 プレイリストファイルへの追記可否を判断する処理 について説明する。 上述した制約 （1) 〜制約 （1 0) の各項目につ いてそれぞれ判断を行い、 1項目でも追記不可の判断がなされた場合 には、 新規にプレイリストを作成し、 新規記録するクリップに基づく チヤプタを、 新規に作成されたプレイリストに対して記録する。
第 43図は、 新規記録するクリップに基づくチヤプ夕のプレイリス 卜ファイルへの追記可否を判定する一例の処理を示すフローチャート である。 先ず、 この第 43図のフローチャートを用いて全体的な処理 の流れを概略的に説明する。 ここでは、 記録媒体 20を記録可能なタ イブの DVDといった、 ディスク状記録媒体 （以下、 ディスク） であ るものとする。 また、 以下に説明する各判断処理などは、 第 41図を 用いて説明した記録装置においては、 制御部 30において行われる。 記録媒体 20が記録装置に装填されると、 制御部 30により記録制 御部 1 5が制御され、 記録媒体 20からインデックスファイル" index .bdmv"が読み込まれる （ステップ S 1 00) 。 読み込まれたインデッ クスファイル" index, bdmv"は、 例えば管理情報処理部 1 6を介して揮 発性メモリ 1 7に記憶される。
次のステップ S 1 0 1で、 制御部 30は、 揮発性メモリ 1 7に記憶 されたインデックスフアイル" index, bdmv"内に記述された情報に基づ き、 次に記録されるクリップに基づくチヤプタを追記するためのプレ イリスト （プレイリストファイル） の候補を特定する。
例えば、 インデックスフアイル" index, bdmv"における拡張デー夕ブ 口ックであるブロック blklndexExtensioiiDataO内のブロック blkTabl eOfPlayListsOを参照して、 最も新しく記録されたリアルプレイリス トを検索してそのリアルプレイリストのファイル名を取得する。
より具体的には、 第 29図を参照し、 ブロック blklndexExtensionD ataOに列挙されたブロック blkMovieTitlePlayListPairOの中で、 フ ィールド PlayListAttributeが属性 「RealJ を示しているブロック blk MovieTitlePlayListPairOのうち、 最も後ろに記述されているブロッ ク blkMovieTitlePIayListPairOを検索し、 検索されたブロック blkMo vieTiUe ayListPair 0からフィールド PlayListFi leNameのデータを 取得する。
次のステップ S 102で、 ステップ S 101で特定された追記候補 のプレイリストファイルが記録媒体 20から読み込まれ、 揮発性メモ リ 17に記憶される。 そして、 読み込まれた追記候補のプレイリスト ファイルに関連する全てのクリップインフォメーションファイルが記 録媒体 20から読み込まれる。 読み出されたクリップインフォメーシ ヨンファイルは、 揮発性メモリ 17に記憶される。
より具体的には、 第 10図〜第 12図を参照して、 追記候補のプレ ィリストファイルにおいて、 ブロック blkPlayListO内の全てのブロ ック blkPlayltemOが参照され、 ブロック MkPlayltemOに記述される フィ一ルド ClipInformationFileNameのデータが全て取得される。 そ して、 取得されたフィールド ClipInformationFileNameのデータに示 されるクリップィンフオメーシヨンファイルを、 記録媒体 20から全 て読み出す。
以下のステップ S 104〜ステップ S 111で、 揮発性メモリ 17 に記憶された追記候補のプレイリストファイルおよびクリップィンフ オメ一シヨンファイルに基づき、 上述した各制約に基づくチヤプ夕の 追記可否の判定がなされる。 すなわち、 ステップ S 104で、 上述の 制約 （1) に対応し、 ステップ S 101で取得された追記候補のプレ ィリストファイルに含まれるプレイアイテム数に基づき追記可否の判 定を行う。 次のステップ S 105で、 上述した制約 （2) に対応し、 追記候補のプレイリストファイルに含まれるプレイリストマーク数に 基づき追記可否の判定を行う。 次のステップ S 1 0 6で、 上述した制 約 （3 ) に対応し、 追記候補のプレイリストファイルに記述されるビ デォ属性と、 新規に記録しょうとするクリップのビデオ属性とに基づ き追記可否の判定を行う。
次のステップ S 1 0 7で、 上述した制約 （4 ) に対応し、 追記候補 のプレイリストファイルのファイルサイズに基づき追記可否の判定を 行う。 次のステップ S 1 0 8で、 上述した制約 （5 ) に対応し、 追記 候補とされたプレイリストファイルから参照されるクリップィンフォ メーシヨンファイルの合計ファイルサイズに基づき追記可否の判定を 行う。 次のステップ S 1 0 9で、 上述した制約 （6 ) および制約 （7 ) に対応し、 追記候補とされたプレイリストファイルから参照される クリップインフォメ一ションファイルに格納されるェントリポイント の合計数に基づく追記可否の判定を行う。
次のステップ S 1 1 0で、 上述した制約 （8 ) に対応し、 追記候補 とされたプレイリストファイル内における他機による独自の拡張デー 夕の有無に基づく追記可否の判定を行う。 さらに、 次のステップ S 1 1 1で、 上述した制約 （9 ) に対応し、 追記候補のプレイリストファ ィルの最終更新者に基づく追記可否の判定を行う。
次のステップ S 1 1 2では、 上述したステップ S 1 0 4〜ステップ S 1 1 1までの各判断処理による判定結果に基づき、 新規記録される クリップに基づくチヤプタを、 追記候補とされたプレイリストフアイ ルに対して追記するか否かの最終的な判断がなされる。 例えば、 ステ ップ S 1 0 4〜ステップ S 1 1 1の各処理による判定結果を、 制御部 3 0が有するレジスタなどにそれぞれ保持し、 ステップ S 1 1 2にお いて、 レジス夕に保持された各処理による判定結果に基づき判断を行 う。
すなわち、 ステップ S I 1 2では、 ステップ S 1 0 4〜ステップ S 1 1 1までの各処理の全てにおいて追記可能であると判定されたら、 新規記録するクリップにに基づくチヤプ夕を、 ステップ S 1 0 1で取 得された追記候補のプレイリストファイルに対して追記するように判 断する。
—方、 上述したステップ S 1 0 4〜ステップ S 1 1 1までの各処理 において、 追記不可と判定された処理が一つでもあれば、 上述のステ ップ S 1 0 1で取得された追記候補のプレイリストファイルに基づく チヤプ夕の追記が不可であると判断する。 この場合、 新規にリアルプ レイリストのプレイリストファイルを作成し、 この新規のプレイリス トファイルに対して、 新規に記録されるクリップに基づくチヤプ夕を 記録する。
なお、 上述したステップ S 1 0 4〜ステップ S 1 1 1の各処理の順 序は、 この順序に限られない。 すなわち、 ステップ S 1 0 4〜ステツ プ S 1 1 1の各処理は、 任意の順序で行うことができる。 また、 ステ ップ S 1 0 4〜ステップ S 1 1 1の各処理を並列的に行うことも可能 である。 さらに、 ステップ S 1 0 4〜ステップ S 1 1 1の各処理の全 てを行わず、 各処理のうち 1または複数の処理を選択的に行ってもよ い。
以下に、 上述したステップ S 1 0 4〜ステップ S 1 1 1の各処理の それぞれを、 より詳細に説明する。 第 4 4図は、 ステップ S 1 0 4に よる、 制約 （1 ) に対応した、 追記候補のプレイリストファイルに含 まれるプレイアイテム数に基づく追記可否判断の一例の処理を示す。 この処理では、 ステップ S 1 2 0に一例が示されるように、 追記候補 のプレイリストファイル内のブロック MkP l ayL i s t O (第 1 1図参照 ) を参照してフィールド NumberOfPlayltemsの値を取得し、 取得され たフィールド NumberOfPlayltemsの値と、 1のプレイリストファイル に存在可能なプレイアイテム数に対して設定された処理の上限値、 例 えば値" 999"とを比較する。
比較の結果、 フィールド NumberOfPlayltemsの値が所定の上限値未 満であれば、 新規記録するクリップに基づくチヤプ夕の追記候補のプ レイリストファイルに対する追記が可能であると判断する。 一方、 フ ィールド NumberOfPlayltemsの値が所定の上限値以上であれば、 当該 チヤプ夕の追記候補のプレイリストファイルに対する追記が不可であ ると判断する。
第 45図は、 ステップ S 1 05による、 制約 （2) に対応した、 追 記候補のプレイリストファイルに含まれるプレイリストマーク数に基 づく追記可否判断の一例の処理を示す。 この処理では、 ステップ S 1 30に一例が示されるように、 追記候補のプレイリストファイル内の ブロック blkPlayListMarkO (第 14図参照） を参照してフィールド N umberOfPlayListMarksの値を取得し、 取得されたフィールド NumberOf PlayListMarksの値と、 1のプレイリストファイルに存在可能なプレ イリストマーク数に対して設定された所定の上限値、 例えば値" 99 9"とを比較する。
比較の結果、 フィールド NumberOiPlayListMarksの値が所定の上限 値未満であれば、 新規記録するクリップに基づくチヤプ夕の追記候補 のプレイリストファイルに対する追記が可能であると判断する。 一方 、 フィールド NumberOfPlayListMarksの値が所定の上限値以上であれ ば、 当該チヤプ夕の追記候補のプレイリストファイルに対する追記が 不可であると判断する。
なお、 既に説明したように、 プレイリストマークには、 エントリマ ークおよびリンクボイントの 2タイプが存在する。 このステップ S 1 3 0においては、 これらエントリマークおよびリンクポイントの合計 数に対して上限値未満であるか否かが判定される。
第 4 6図は、 ステップ S 1 0 6による、 制約 （3 ) に対応した、 追 記候補のプレイリストファイルに記述されるビデオ属性と、 新規に記 録しょうとするクリップのビデオ属性とに基づく追記可否判断の一例 の処理を示す。 先ず、 最初のステップ S 1 4 0において、 記録するビ デォデ一夕の属性情報を取得する。 この実施の一形態では、 記録装置 に対して現在設定されている撮影モードゃ録画モードに基づき、 記録 するビデオデータの属性情報として画枠サイズ、 アスペクト比、 フレ ームレートおよび走査種別 （インターレースノプログレッシブ） を取 得する。
以下のステップ S 1 4 1〜ステップ S 1 4 4で、 追記候補のプレイ リストファイルに関連するクリップのビデオ属性が取得される。 この 実施の一形態では、 追記候補のプレイリストファイルに対して複数の プレイアイテムが格納されている場合、 最も最初に記録されたプレイ アイテムが参照するクリップインフォメーションファイルから、 ビデ ォ属性を取得する。 概略的には、 ビデオ属性として、 ステップ S 1 4 1で画像幅を取得し、 ステップ S 1 4 2で画像高 （ライン数） および 走査種別を取得し、 ステップ S 1 4 3でアスペクト比を取得し、 ステ ップ S 1 4 4でフレームレートを取得する。
より具体的には、 追記候補のプレイリストファイル内のブロック bl kPlayLi st O (第 1 1図参照） において、 最も先頭側に格納されるブ ロック blkP layl tem O (第 1 2図参照） を参照し、 フィールド Cl iplnf ormat ionFi leNameのデータを取得し当該プレイアイテムが参照するク リップィンフオメーシヨンファイルのファイル名を取得する。 上述し た第 43図のフローチャートにおけるステップ S 1 0 3の処理により 読み込まれた、 追記候補のプレイリストに関連する全てのクリップィ ンフオメーシヨンファイルのうち、 取得されたファイル名に対応する クリップィンフオメーシヨンファイルを参照する。
ステップ S 141では、 当該クリップインフォメーションファイル における拡張データであるブロック blkCUpExtensionDataO内のプロ ック blkProgramlnioExtO (第 37図参照） が参照され、 当該ブロッ ク blkProgramlnfoExt 0において、 さらにブロック blkStreamCodingln foExtd, j) (第 38図参照） が参照される。 そして、 当該プロック bl kStreamCodinglnfoExt (i， j)内のフィールド HorizontalSizeの値が取 得される。
ステップ S 142では、 当該クリップインフォメーションファイル におけるブロック blkProgramlnfoO (第 1 7図参照） 内のブロック M kStreamCodinglnfoO (第 1 8図参照） が参照され、 フィールド Video Formatの値が取得される。 フィールド VideoFooiaiは、 第 1 9図を用 いて既に説明したように、 4ビットで表現可能な値を用いて、 ビデオ データのライン数と走査方式 (ィン夕ーレース/プログレッシブ) と の組み合わせが示されている。
ステップ S 1 3では、 ステップ S 142と同様にブロック blkStr eamCodinglnfoOが参照され、 フィールド AspectRatioの値が取得され る。 フィールド AspectRatioは、 第 2 1図を用いて既に説明したよう に、 4ビットで表現可能な値を用いて、 ビデオデータの画枠のァスぺ クト比が示されている。
ステップ S 144では、 ステップ S 143およびステップ S 143 と同様に、 ブロック blkSireamCodinglnioOが参照され、 フィールド F rameRateの値が取得される。 フィールド FrameRateは、 第 20図を用 いて既に説明したように、 4ビットで表現可能な値を用いて、 ビデオ データのフレームレートが示されている。
ステップ S 1 4 5では、 ステップ S 1 4 0で記録機から取得された 、 記録するビデオデータの属性情報のそれぞれと、 ステップ S 1 1 〜ステップ S 1 4 4で取得された、 追記候補のプレイリストファイル に関連するクリップのビデオ属性のそれぞれとが比較される。
比較の結果、 記録するビデオデータの属性情報のそれぞれと、 追記 候補のプレイリストファイルに関連するクリップのビデオ属性のそれ ぞれとが全て一致していれば、 新規記録するクリップに基づくチヤプ 夕の追記候補のプレイリストファイルに対する追記が可能であると判 断する。 一方、 記録するビデオデータの属性情報のそれぞれと、 追記 候補のプレイリストファイルに関連するクリップのビデオ属性のそれ ぞれとにおいて、 一つでも不一致の属性がある場合、 当該チヤプタの 追記候補のプレイリストファイルに対する追記が不可であると判断す る。
第 4 7図は、 ステップ S 1 0 7による、 制約 （4 ) に対応した、 追 記候補のプレイリストファイルのファイルサイズに基づく追記可否判 断の一例の処理を示す。 この処理においては、 追記候補のプレイリス トに対して少なくとも所定チヤプ夕数を追記しても、 1のプレイリス トファイルのファイルサイズの上限を超えないことを以て、 追記の可 否を判断する。
なお、 所定チヤプタ数は、 1チヤプ夕、 複数チヤプ夕、 1のプレイ リストファイルに存在可能な最大チヤプ夕数に対する残りのチヤプタ 数など、 記録機の設計思想などにより様々に考えられる。 ここでは、 所定のチヤプタ数を、 1のプレイリストファイルに存在可能な最大チ ャプ夕数に対する残りのチヤプタ数であるものとする。 先ず、 ステップ S 1 50において、 予め計算しておいた、 1チヤプ 夕当たりのプレイリストファイルのサイズ増加分 SIZE_1CHAPを取得す る。 すなわち、 このステップ S 1 50では、 例えば 1のチヤプ夕を形 成するためのプレイアイテムおよびプレイリストマークのデータ量を 計算する。
第 1 2図を参照し、 プレイアイテムにおいて、 フィールド StillMod eおよびフィールド StillTime、 ならびに、 ブロック blkUOMaskTable 0 およびブロック b 1 kSTNTab I e 0は、 デー夕長が変動する可能性のある データであるが、 実際には、 これらのデータは、 記録モードや記録機 によって固定長とされる。 また、 プレイリストマークは、 第 14図を 参照し、 各フィールドの値が固定長とされている。 このように、 1の クリップを記録する際に生成されるプレイアイテムおよびプレイリス トマ一クのデ一夕サイズは、 予め計算することができる。 また、 計算 された値は、 記録時間に依らない性質のものである。 この 1チヤプタ 当たりのプレイリストファイルのサイズ増加分 SIZE一 1CHAPの値は、 予 め計算され例えば記録機が有する ROMなどに記憶される。 この第 4 7図のフローチャートによる処理を実行する毎に計算してもよい。 プレイリストに対してチヤプタを追記する場合には、 プレイアイテ ムとプレイリス卜マークとが増加することになる。 したがって、 プレ イリストに対してチヤプ夕を追記する際には、 制約 （1) および制約 (2) の、 1のプレイリストファイルに存在可能なプレイアイテムお よびプレイリストマーク数も考慮に入れる必要がある。
ステップ S 1 5 1では、 追記候補のプレイリストファイルに追記可 能なプレイアイテム数 Π— REMAINを計算する。 すなわち、 追記候補の プレイリストファイル内のブロック MkPlayListO (第 1 1図参照） を参照してフィ一ルド NumberOfPlayltemsの値を取得し、 追記候補の プレイリストに含まれるプレイアイテム数を求める。 そして、 追記候 補のプレイリストに含まれるプレイアイテム数を、 1のプレイリスト ファイルに存在可能なプレイアイテム数に対して設定された所定の上 限値 Pし MAX、 例えば" 999 "から減じて、 追記候補のプレイリストに 追記可能なプレイアイテム数 Pし REMAINを求める。
すなわち、 追記候補のプレイリストファイル追記可能なプレイアイ テム数 Pし REMAINは、 下記の式 （1) により求められる。
PI_REMAIN=PI_MAX-NumberOf Play Items · · · (1)
ステップ S 1 52では、 追記候補のプレイリストファイルに追記可 能なプレイリストマーク数 MARK— REMAINを計算する。 すなわち、 追記 候補のプレイリストファイル内のブロック blkPlayListMarkO (第 1 4図参照） を参照してフィールド NumberO f P layLis tMarksの値を取得 し、 追記候補のプレイリス卜に含まれるプレイリストマークの数を求 める。 そして、 追記候補のプレイリストに含まれるプレイリストマー ク数を、 1のプレイリス卜に存在可能なプレイアイテム数に対して設 定された所定の上限値 MARK一 MAX、 例えば" 999"から減じて、 追記候 補のプレイリストに追記可能なプレイリストマーク数 MARK_REMAINを 求める。
すなわち、 追記候補のプレイリストファイルに追記可能なプレイリ ストマーク数 MARK— REMAINは、 下記の式 （2) により求められる。 M ARK_REMA I N = MARK_M AX - NumberOfPlayListMarks . · · (2) 次のステップ S 153では、 ステップ S 1 5 1で求められた追記候 補のプレイリストに追記可能なプレイアイテム数 PI— REMAINと、 ステ ップ S 1 52で求められた追記候補のプレイリストファイルに追記可 能なプレイリストマーク数 MARK— REMAINとのうち小さい方を、 追記候 捕に追記可能なチヤプ夕数 CHAP— REMAINとする。 すなわち、 追記候補のプレイリストファイルに追記可能なチヤプ夕 数 CHAP— REMAINは、 「MIN」 を括弧内の値のうち小さい方を選択するこ とを表すものとして、 上述の式 （1) および式 （2) の結果を用いて 、 下記の式 （3) により求められる。 なお、 「MIN」 は、 括弧内の値 のうち最小の値を選択することを示す。
CHAP_REMAIN=MI ( PI— REMAIN, MARK— REMAIN ) · · · (3) 次のステップ S 1 54では、 追記候補のプレイリストファイルのフ アイルサイズを取得し、 制約 （4) の 1のプレイリストファイルのフ アイルサイズの上限 PL— SIZE—MAXに対して残されたデータサイズ SIZE— REMAINを求める。 プレイリストファイルのファイルサイズは、 例えば 〇 Sのファイルシステムにより提供されるファンクションを利用して 取得することができる。 データサイズ SIZE_REMAIN(kB)は、 下記の式 (4) により求められる。 なお、 追記候補のプレイリストファイルの ファイルサイズを FILE— SIZE(kB)とする。
SIZE— REMAIN (kB)=PL— SIZE_MAX (kB)—FILE— SIZE (kB) · · · (4) 次のステップ S 1 55で、 追記候補のプレイリストファイルに対し て追記可能なチヤプタ数分のプレイアイテムおよびプレイリストマー クを追記した場合に、 追記候補のプレイリストファイルのファイルサ ィズが 1のプレイリストファイルのファイルサイズの上限を超えない か否かが判断される。
すなわち、 ステップ S 1 50で求めた 1チヤプタ当たりのプレイリ ストファイルのサイズ増加分 SIZE_1CHAPと、 式 （3) および式 （4) の結果とを用いて、 下記の式 （5) を満足するか否かが判断される。 SIZE— 1 CHAP X CHAP— REMAINS SIZE— REMAIN · · · (5)
若し、 式 （5) が満足されれば、 新規記録のクリップに基づくチヤ プ夕の追記候補のプレイリストファイルに対する追記が可能であると 判断される。 一方、 式 （5 ) が満足されなければ、 当該チヤプ夕の追 記候補のプレイリストファイルに対する追記が不可であると判断する 第 4 8図は、 上述のステップ S 1 0 8の、 制約 （5 ) に対応した、 追記候補とされたプレイリストファイルから参照されるクリップィン フオメ一シヨンファイルの合計ファイルサイズに基づく追記可否判断 の一例の処理を示す。
上述の制約 （5 ) によれば、 追記候補とされたプレイリストフアイ ルから参照されるクリップインフォメーションファイルの合計フアイ ルサイズには、 例えば 2 M Bといったように、 上限値 CLIP_SUM— MAXが 設定される。 チヤプ夕の追記により追記候補のプレイリストに対して クリップインフォメーションファイルが追加された際に、 当該追記候 補のプレイリストファイルに関連するクリップィンフオメーシヨンフ アイルの合計サイズが、 この上限値 CL IP— SUM— MAXを超えないようにす る必要がある。
ステップ S 1 6 0で、 予め計算しておいた、 1のクリップインフォ メーションファイルの最大サイズ SI ZE— 1 CLIPを取得する。 クリップィ ンフオメ一シヨンファイルは、 ブロック MkEPMap Oに、 P T S値とク リップ A Vストリームファイルのバイトアドレスとを関連付けるェン トリポイントの情報が格納される （第 2 3図〜第 2 6図参照） 。 この エントリポイントの情報は、 記録時間により変化する値である。 クリ ップィンフオメーションファイルに格納されるその他の情報は、 符号 化方式などにより記録時間に依らず固定的な値である。 一方、 上述し たように、 記録機の仕様として、 連続記録を保証する最低時間が設定 される。 エンコーダにおけるビデオやオーディォの符号化方式により 、 連続記録を保証する最低時間分のエントリポイント数が決まる。 連 続記録を保証する最低時間分のェントリポイントの合計データサイズ を計算し、 計算結果に基づき最大サイズ SIZE_1CLIPを求める。
次のステップ S 1 6 1で、 追記候補のプレイリストファイルから参 照されている全てのクリップインフォメーションファイルについてフ アイルサイズを取得し、 合計サイズ SIZE_TOTAL__CLIPを計算する。 すなわち、 追記候補のプレイリストファイル内の全てのブロック M kPlayltemO (第 1 2図参照） を参照し、 各ブロック blkPlayl tem()に ついてフィールド ClipInformationFileNameのデータを取得する。 そ して、 取得されたフィールド ClipInformationFileNameのデータに示 されるクリップインフォメ一ションファイルのファイルサイズを、 追 記候補のプレイリストファイル内の全てのブロック blkPlayltemOに ついてそれぞれ求め、 合計する。 クリップインフォメーションフアイ ルのフアイルサイズは、 例えば〇 Sのファイルシステムにより提供さ れるファンクションを利用して取得することができる。
次のステップ S 1 62で、 下記の式 （6) に従い、 1のプレイリス トファイルに関連できるクリップインフォメ一ションファイルの合計 ファイルサイズの上限値から、 ステップ S 1 6 1で計算された、 追記 候補のプレイリストファイルから参照されている全てのクリップィン フオメ一ションファイルの合計サイズ SIZE— TOTAL— CLIPを減じた値と 、 ステップ S 160で計算された、 1のクリップインフォメーション ファイルの最大サイズ SIZE— 1CLIPとが比較され、 追記候補のプレイリ ストファイルに対して最大サイズ SIZE一 1CLIPのクリップィンフオメ一 シヨンファイルを追加可能であるか否かが判定される。
CLIP一 SUM— MAX— SIZE— TOTAL— CLIP≥SIZE—1CLIP · · · (6)
比較の結果、 若し、 1のプレイリストファイルに関連できるクリツ プインフォメーションファイルの合計ファイルサイズの上限値から、 追記候補のプレイリストファイルから参照されている全てのクリップ ィンフオメーシヨンファイルの合計サイズ SIZE— TOTAL_CL IPを減じた 値が、 1のクリップインフォメーションファイルの最大サイズ S I ZE_1 CL IPよりも大きいと判定されれば、 新規記録のクリップに基づくチヤ プ夕の追記候補のプレイリストファイルに対する追記が可能であると 判断される。
一方、 1のプレイリストファイルに関連できるクリップインフォメ ーシヨンファイルの合計ファイルサイズの上限値から、 追記候補のプ レイリストファイルから参照されている全てのクリップインフォメー シヨンファイルの合計サイズ S IZE_JOTAL_CLIPを減じた値が、 1のク リップインフォメーションファイルの最大サイズ S I ZEJ CLIPよりも小 さければ、 当該チヤプ夕の追記候補のプレイリストファイルに対する 追記が不可であると判断する。
第 4 9図は、 上述のステップ S 1 0 9の、 制約 （6 ) および制約 （ 7 ) に対応した、 追記候補とされたプレイリストファイルから参照さ れるクリップインフォメーションファイルに格納されるェントリポィ ントの合計数に基づく追記可否判断の一例の処理を示す。
既に説明したように、 1のプレイリストファイルから参照されるク リップインフォメ一ションファイルに関し、 ブロック MkEPMap Oに格 納されるェントリポィントの合計数に対して上限が設けられている。 チヤプタの追記により追記候補のプレイリスト（こ対してクリップィン フオメ一シヨンファイルが追加された際に、 当該追記候補のプレイリ ストファイルに関連するクリップィンフオメーシヨンファイルに格納 されるエントリボイントの合計数が、 この上限値を超えないようにす る必要がある。
なお、 制約 （6 ) および制約 （7 ) によれば、 粗い単位で検索を行 うエントリポイントと、 精密な単位で検索を行うェントリポイントと のそれぞれに対して上限が設けられている。 したがって、 判定も、 ク リップインフォメーションファイルに格納される粗い単位で検索を行 うエントリボイントおよび精密な単位で検索を行うェントリポイント のそれぞれについて、 行う必要がある。
1のプレイリストファイルに関連しているクリップィンフオメーシ ョンファイル内の、 粗い単位で検索を行うェントリボイントの合計値 の上限値 MAX— EP_C0ARSEは、 例えば 2 4 5 7 6個とされる。 また、 精 密な単位で検索を行うェントリボイントの合計値の上限値 MAX— EP—FIN Eは、 例えば 1 8 0 0 0 0個とされる。
先ず、 ステップ S 1 7 0で、 予め計算しておいた 1チヤプ夕当たり の最大エントリポイント数を取得する。 上述したように、 記録機の仕 様として、 一般的に、 連続記録が保証される最低時間が設定される。 この連続記録が保証される最低時間分の記録を行った際の、 最大のェ ントリポイント数を予め計算しておき、 このステップ S 1 7 0で、 こ の値を取得する。
第 2 5図および第 2 6図を用いて説明したように、 粗い単位で検索 を行うエントリポイントは、 1 1 . 5秒毎 （P T S ：エントリ PTSEPC oarse) または 2 5 M B毎 （ソースパケット番号：エントリ SPNEPCoar se) に設けられる。 ここで、 連続記録が保証される最低時間を時間 Ml N_TIME (hr) , 当該最低時間分の記録を行った場合に生成されるクリッ プ A Vストリームファイルのデータ量をデ一夕量 MilSIZE (MB)とした 場合、 粗い単位で検索を行うエントリポイントについて、 1チヤプ夕 当たりの最大エントリポイント数 NEEDED— EP_C0ARSEは、 次式 （7 ) に より求められる。 なお、 式 （7 ) および後述する式 （8 ) において、 「CE IL」 は、 括弧内の値について小数点を切り上げることを示す。 NEEDED— EP一 CO ARSE = CEIL ( 3600 [sec] XMIN— TIME [hr] ÷ 11.5 [sec] ) + CEIL ( MIN_SIZE[MB]÷25[MB] ) · · · (7)
また、 精密な単位で検索を行うエントリポイントは、 GOP毎に、 PTSの精度 （エントリ PTSEPFine) またはソースパケットの精度 （ エントリ SPNEPFine) で設けられる。 この実施の一形態では、 精密な 用いるものとし、 フレーム周波数を 2 9. 9 7H z、 1 GOPが 1 5 フレームから構成されるとした場合、 精密な単位で検索を行うェン卜 リポイントについて、 1チヤプ夕当たりの最大ェントリポイント数 NE EDED_EP— FINEは、 次式 （8) により求められる。 なお、 式 （8) 中、 「90[kHz]÷3003」 は、 P T S精度に基づくフレーム周波数 （ 2 9. 9 7H z) を示す。
NEEDED— EP— FINE = CEIL ( 3600 [sec] XMIN_TIME [hr] X 90 [kHz] ÷3003 ÷15 [Frame/GOP] ) · · · (8)
次のステップ S I 7 1で、 追記候補のプレイリストファイルから参 照されている全てのクリップインフォメ一ションファイルについて、 粗い単位で検索を行うェントリポイントと、 精密な単位で検索を行う エントリポイントとをそれぞれ取得し、 粗い単位で検索を行うェント リポィントの合計 T0TAL—EP_C0ARSEと、 精密な単位で検索を行うェン トリポィントの合計 T0TAL_EP一 FINEとをそれぞれ求める。
より具体的には、 クリップインフォメーションファイル内のフィ一 ルド NumberOfStreamPIDEntriesと、 フィ一ル NumberOfEPCoarseEntr ies[k]およびフィールド NumberOfEPFineEiitries[k]とに基づき、 粗い 単位で検索を行うェントリポィントの合計 TOTAL— EP— COARSEと、 精密 な単位で検索を行うェントリポィントの合計 T0TAL_EP_FINEとを求め ることができる。 次のステップ S 1 7 2では、 追記候補のプレイリストファイルに対 してチヤプ夕を追記した際に、 粗い単位で検索を行うェントリポィン トについて、 上限値 MAX— EP_C0ARSEを超えないか否かが判定される。 すなわち、 上述のステップ S 1 7 0で取得された、 粗い単位で検索を 行うエントリポイントの 1チヤプ夕当たりの最大ェントリポイント数 NEEDED一 EP— COARSEと、 ステップ S 1 7 1で求められた粗い単位で検索 を行うエントリポイントの合計 T0TAL_EP_C0ARSEとを用いて、 次式 （ 9 ) に基づき判定がなされる。
MAX— EP— COARSE— T0TAに EP— COARSE≥ NEEDED— EP_C0ARSE · · · ( 9 ) 若し、 各値の関係がこの式 （9 ) を満たしていない、 すなわち、 1 チヤプ夕当たりの粗い単位で検索を行うェントリポィントの最大ェン トリポイント数 NEEDED_EP_COARSEが、 1のプレイリストファイルに関 連するクリップインフォメーションファイルの粗い単位で検索を行う ェントリボイントの合計値の上限値 MAX_EP一 COARSEと、 追記候補のプ レイリストファイルに関連するクリップインフォメーションファイル の粗い単位で検索を行うェントリポィントの合計 TOTAL— EP_C0ARSEと の差分より大きければ、 当該チヤプタの追記候補のプレイリストファ ィルに対する追記が不可であると判断する。
一方、 各値の関係が式 （9 ) を満たしていると判定されれば、 処理 は次のステップ S 1 7 3に移行される。 ステップ S 1 7 3では、 精密 な単位で検索を行うエントリボイントについて、 同様の判定がなされ る。 すなわち、 上述のステップ S 1 7 0で取得された、 精密な単位で 検索を行うェントリポィントの 1チヤプ夕当たりの最大ェントリポィ ント数 NEEDED— EP_FINEと、 ステップ S 1 7 1で求められた精密な単位 で検索を行うエントリポイントの合計 TOTAL JP— FINEとを用いて、 粗 い単位で検索を行うェントリポィントの上限値 MAX— EP_FINEについて 、 次式 （ 1 0) に基づき判定がなされる。
MAX_EP_F I E - T0TAL_EP_F I NEE≥ NEEDED_EP_F I E - · · (1 0) 若し、 各値の関係がこの式 （ 1 0) を満たしていないと判定されれ ば、 当該チヤプ夕の追記候補のプレイリストファイルに対する追記が 不可であると判断する。 一方、 各値の関係がこの式 （ 1 0) を満たし ていると判定されれば、 当該チヤプ夕の追記候補のプレイリストファ ィルに対する追記が可能であると判断する。
第 50図は、 上述のステップ S 1 1 0の、 制約 （8) に対応した、 追記候補とされたプレイリストファイル内における他機による独自の 拡張データの有無に基づく追記可否判定の一例の処理を示す。
先ず、 最初のステップ S 1 80で、 追記候補のプレイリストフアイ ルの拡張データから、 AVCDHフォーマツトに準拠した拡張データ を検索する。
すなわち、 第 1 0図を参照し、 追記候補のプレイリストファイルの フィールド ExtensionDataStartAddressの値が取得され、 取得された 値が" 0"か否かが判断される （図示しない） 。 値が" 0"でなければ、 当該プレイリストファイル内に拡張データブロック blkExtensionData 0が存在するので、 フィールド ExtensionDataStartAddressの値に基 づきブロック blkExtensionDataOが参照される。 そして、 第 3 3図を 参照し、 プレイリストファイル内の拡張データブロック MkPlayListE xtensionDataOにおいて、 フィールド ExtDataTypeおよびフィール E xtDataVersionが AVCHDフォーマツトに規定されている値になつ ているか否かを調べる。
次のステップ S 1 8 1では、 ステップ S 1 8 0の検索結果に基づき 、 追記候補のプレイリストファイルの拡張データに、 AVCHDフォ 一マツトに準拠した拡張データが存在するか否かが判断される。 すなわち、 ステップ S 1 80の検索結果に基づき、 追記候補のプレ イリストファイル内のフィールド ExtensionDataS rtAddressの値が" 0"であるか、 若しくは、 拡張データブロック MkPlayListExtensionD ata()内のフィールド ExtDataTypeおよびフィ一ルド ExtDataVersionが AVCHDフォーマットに規定されている値ではない場合は、 追記候 補のプレイリストファイルの拡張データに、 AVCHDフォーマツト に準拠した拡張データが存在しないと判断される。 この場合、 当該チ ャプ夕の追記候補のプレイリストファイルに対する追記が不可である と判断する。
一方、 ステップ S 1 8 1で、 ステップ S 1 80の検索結果に基づき 、 追記候補のプレイリストファイルの拡張データに、 AVCHDフォ 一マツトに準拠した拡張データが存在すると判断されれば、 処理はス テツプ S 182に移行される。 ステップ S 1 82では、 追記候補のプ レイリストファイルの拡張データに、 AVCHDフォーマツトに準拠 した拡張データ以外に、 さらに拡張データが存在するか否かが判断さ れる。 若し、 存在すると判断されれば、 当該チヤプ夕の追記候補のプ レイリストファイルに対する追記が不可であると判断する。
ステップ S 182で、 追記候補のプレイリストファイルの拡張デー 夕に、 AVCHDフォーマツトに準拠した拡張データ以外の拡張デ一 夕が存在しないと判断されれば、 処理はステップ S 1 83に移行され る。 ステップ S 1 83では、 検索された、 追記候補のプレイリストフ アイルの拡張データプロック blkP yListExtensionDataOのプロック blkMakersPrivateDataOが参照され、 自機のデータが検索される。 す なわち、 第 35図を参照し、 ブロック blkMakersPrivateDataO内のフ ィ一ルド ¾^1^1"10ぉょびフィールド¾^^^0(^1(：0(16に基づき、 自機を 示すデータが検索される。 次のステップ S 184で、 ステップ S 1 83の検索結果に基づく判 断がなされる。 ステップ S 1 84では、 ステップ S 1 8 3の検索結果 に基づき、 若し、 自機の拡張データが存在しないと判断されれば、 当 該チヤプ夕の追記候補のプレイリストファイルに対する追記が不可で あると判断する。 一方、 ステップ S 1 84で、 ステップ S 1 83の検 索結果に基づき自機の拡張データが存在すると判断されれば、 処理は ステップ S 185に移行される。
ステップ S 185では、 ステップ S 1 83の検索結果に基づき、 ブ ロック blkMakersPrivateDa O内に自機以外の機器による拡張データ が存在するか否かが判断される。 すなわち、 ブロック blkMakersPriva teDataO内のフィールド MakerlDおよびフィールド MakerModelCodeに 、 自機を示すデータ以外のデータが存在すれば、 ブロック MkMakersP rivateDataO内に自機以外の機器による拡張データが存在すると判断 することができる。
ステップ S 1 85で、 ブロック blkMakersPrivateDataO内に自機以 外の機器による拡張データが存在すると判断されれば、 チヤプ夕の追 記候補のプレイリストファイルに対する追記が不可であると判断する 。 一方、 ブロック blkMakersPrivateDataO内に自機による拡張データ のみが存在すると判断されれば、 チヤプ夕の追記候補のプレイリスト ファイルに対する追記が可能であると判断する。
なお、 上述のステップ S 1 8 1では、 追記候補のプレイリストファ ィルに AVCHDフォーマツトに準拠した拡張データが存在しない場 合に、 チヤプ夕の追記候補のプレイリストファイルに対する追記が不 可であるとしていたが、 これはこの例に限定されない。 すなわち、 記 録機の仕様によっては、 追記候補のプレイリストファイルに、 拡張デ 一夕ブロック b 1 kMakersPriva t eDa t aが全く存在しない場合に、 チヤプ 夕の追記候補のプレイリストファイルに対する追記が可能とすること も考えられる。
第 5 1図は、 上述したステップ S 1 1 1の、 制約 （9 ) に対応した 、 追記候補のプレイリストフアイルの最終更新者に基づく追記可否判 定の一例の処理を示す。 追記候補のプレイリストファイルの最終更新 者が自機でない場合には、 追記候補のプレイリストファイルにおける タイトルやチヤプ夕の概念が自機とは異なり、 再生時に不都合が生じ る可能性がある。 追記候補のプレイリストファイルの最終更新者情報 に基づき、 最終更新者が自機である場合にのみ、 追記候補のプレイリ ストファイルに対してチヤプ夕の追記をするように制御することで、 1のプレイリス卜ファイル内でのタイトルやチヤプ夕の概念の差異に よる不都合を回避することが可能である。
先ず、 最初のステップ S 1 9 0で、 追記候補のプレイリストフアイ ルの拡張データから、 A V C D Hフォーマツトに準拠した拡張データ を検索する。 そして、 次のステップ S 1 9 1で、 ステップ S 1 9 0の 検索結果に基づき、 追記候補のプレイリストファイルの拡張データに 、 A V C H Dフォーマツトに準拠した拡張データが存在するか否かが 判断される。 なお、 これらステップ S 1 9 0およびステップ S 1 9 1 の処理は、 第 5 0図を用いて説明したステップ S 1 8 0およびステツ プ S 1 8 1の処理と同一なので、 繁雑さを避けるために詳細な説明を 省略する。
ステップ S 1 9 1で、 追記候補のプレイリストファイルの拡張デー 夕に、 A V C H Dフォーマツトに準拠した拡張データが存在しないと された場合、 当該チヤプ夕の追記候補のプレイリストファイルに対す る追記が不可であると判断する。
一方、 ステップ S 1 9 1で、 ステップ S 1 9 0の検索結果に基づき 、 追記候補のプレイリストファイルの拡張データに、 AVCHDフォ 一マツトに準拠した拡張データが存在すると判断されれば、 処理はス テツプ S 1 92に移行される。 ステップ S 1 92では、 追記候捕のプ レイリストファイルの最終更新者が確認される。 すなわち、 拡張デー 夕ブロック blkPlayListExtensionDataOのプロック MkPlayListMe ( )が参照され、 フィールド MakerlDおよびフィールド MakerModelCodeの データが取得される。
ステップ S 1 92で追記候補のプレイリストファイルの最終更新者 が確認されると、 処理はステップ S 1 93に移行され、 確認された最 終更新者が自機であるか否かが判断される。 すなわち、 拡張データブ 口ック blkPlayLisiExiensionDataOのブロック MkPlayLis iMeta ()に おけるフィールド MakerlDおよびフィールド MakerModelCodeのデータ が自機を示していれば、 最終更新者が自機であると判断できる。
ステップ S 1 93で、 追記候補のプレイリストファイルの最終更新 者が自機であると判断されれば、 チヤプ夕の追記候補のプレイリス卜 ファイルに対する追記が可能であると判断する。 一方、 追記候補のプ レイリストファイルの最終更新者が自機ではないと判断されれば、 当 該チヤプタの追記候補のプレイリストファイルに対する追記が不可で あると判断する。
なお、 最終更新者の情報は、 インデックスファイルにも格納するこ とができる。 例えば、 インデックスファイルにおける拡張データプロ ック MklndexExtensionDataO内のブロック blkMakersPrivateDa O に最終更新者の情報を格納することが考えられる。 この場合、 このィ ンデックスファイルに格納された最終更新者情報を用いて、 この第 5 1図のフローチャートによる判断を行ってもよい。
上述した制約 （1 0) の、 規定時間以上の連続撮影および記録に関 しては、 第 4 3図のステップ S 1 0 8および第 4 8図を用いて説明し たクリップィンフオメーションファイルのファイルサイズに関する処 理、 ならびに、 第 4 3図のステップ S 1 0 9および第 4 9図を用いて 説明したクリップインフォメーションファイルにおけるエントリボイ ントに関する処理に含まれるため、 詳細な説明を省略する。
上述では、 第 4 3図'を用いて説明した、 追記候補のプレイリストフ アイルに対してチヤプタを追記するか、 新規にプレイリス卜ファイル を作成するかの一連の判断を、 記録媒体 2 0が記録機に装填された際 に行われるように説明したが、 これはこの例に限定されない。 例えば 、 チヤプ夕の追記毎、 例えば記録開始操作毎に判断を行うようにして もよい。
次に、 上述した第 4 3図〜第 5 1図を用いて説明した処理の結果、 追記候補のプレイリストファイルに対してチヤプ夕を追記する際の処 理について説明する。 第 5 2図は、 プレイリストファイルに対してチ ャプ夕を追記する一例の処理を示すフローチヤ一トである。
ステップ S 2 0 0で記録開始操作が行われると、 次のステップ S 2 0 1で、 クリップ A Vストリームの記録媒体 2 0への記録が開始され る。 例えば、 U I部 3 1に設けられた記録開始を指示する記録開始ス ィツチが操作されることで、 記録開始を指示する制御信号が U I部 3 1から制御部 3 0に供給され、 制御部 3 0により、 この記録開始を指 示する制御信号に基づき、 記録部 1 0の各部に対し、 端子 4 0から入 力されるベースバンドのビデオデータと、 端子 4 1.から入力されるべ ースパンドのオーディオデータとを記録媒体 2 0に記録するように制 御する。
記録開始の制御に応じて、 クリップ A Vストリームが記録媒体 2 0 に記録される （ステップ S 2 0 1 ) 。 すなわち、 入力されたビデオデ 一夕およびオーディォデ一夕がビデオエンコーダ 1 1およびオーディ ォエンコーダ 1 2でそれぞれ圧縮符号化され、 マルチプレクサ 1 3で バケツト化され T Sバケツト （実際にはさらに所定のヘッダが付加さ れたソースパケット） とされてストリームバッファ 1 4に供給される 。 ストリームバッファ 1 4に所定量以上の T Sパケットが溜め込まれ たら、 記録制御部 1 5によりストリームバッファ 1 4から T Sバケツ トが読み出される。 読み出された T Sパケットは、 所定にファイル名 が付されたクリップ A Vストリームファイルに格納されて記録媒体 2 0に記録される。
例えば、 記録媒体 2 0に既にファイル名" 00001. m2 t s"であるクリツ プ A Vストリームファイルが記録されている場合には、 新たに記録さ れるクリップ A Vストリームファイルのファイル名として既に記録さ れているファイルと重複しないフアイル名が選ばれ、 例えばフアイル 名" 00002. m2 ts"とされる。
なお、 クリップ A Vストリームの記録媒体 2 0への記録に伴い、 管 理情報処理部 1 6により、 記録されるデータの再生時間とアドレスと の対応関係を示す情報がリアルタイムに生成される。 このデータは、 上述したクリップインフォメーションファイル" zzzzz. c lpi"内のブロ ック b lkEPMap Oに格納されるデータとして、 揮発性メモリ 1 7に記憶 される。
次のステップ S 2 0 2で、 記録停止操作が行われたか否かが判断さ れる。 例えば、 ユーザにより U I部 3 1に設けられた記録停止スイツ チが操作され、 記録が停止されたと判断されれば、 処理はステップ S 2 0 3に移行される。 一方、 記録が停止されていなければ、 処理はス テツプ S 2 0 1に戻され、 クリップ A Vストリームの記録媒体 2 0へ の記録が継続される。 ステップ S 2 0 3では、 記録の停止に伴い、 ストリームバッファ 1 4に溜め込まれているストリームが全て記録媒体 2 0に書き込まれる 。 例えば、 記録制御部 1 5は、.制御部 3 0からの記録停止の命令に応 じて、 ストリームバッファ 1 4に溜め込まれているストリーム （T S パケット） を全て読み出し、 記録媒体 2 0に書き込む。
また、 記録停止の命令に応じて、 例えばビデオエンコーダ 1 1およ びオーディオエンコーダ 1 2の動作が停止される。 このとき、 第 1 3 図 Aを用いて説明した第 1のシームレス接続を行うために、 例えば、 オーディオエンコーダ 1 2の動作がビデオエンコーダ 1 1の動作が停 止してから所定時間後に停止されるように制御される。
次のステップ S 2 0 4〜ステップ S 2 0 8で、 管理情報処理部 1 6 により、 記録媒体 2 0に書き込まれたクリップ A Vストリームフアイ ルに関するクリップインフォメ一ションファイルが生成されると共に 、 追記候補のプレイリストファイルの更新が成される。
先ず、 ステップ S 2 0 4で、 管理情報処理部 1 6により、 クリップ インフォメーションファイル" zzzzz. c lpi "が生成される。 ファイル名 は、 例えばこのクリップインフォメーションファイルが示すクリップ A Vストリームファイルのフアイル名と対応するフアイル名とされ、 当該クリップ A Vストリームファイルのファイル名が" 00002. m2 t s' 'で あれば、 このクリップインフォメーションファイルのファイル名は、 拡張子より前の部分が同一のファイル名" 00002. c lpi"とされる。
クリップィンフオメーションファイル" 00002. c lpi"に、 第 1 5図〜 第 2 1図に例示した各シンタクスに従い、 各フィールドやフラグの値 が所定に設定され格納される。 一例として、 T Sパケットに関する情 報や、 再生時間 （P T S ) に関する情報は、 管理情報処理部 1 6によ り、 クリップの記録中にマルチプレクサ 1 3から取得された情報に基 づき生成される。 また、 記録媒体 20上の記録アドレスに関する情報 は、 管理情報処理部 16により、 クリップの記録中に記録制御部 15 から取得された情報に基づき生成される。 システムにより固有の値は 、 例えば予め ROM (図示しない） などに記憶されている情報に基づ く。 さらに、 再生時間とアドレスとの対応関係を示す上述したブロッ ク blkEPMapOの情報が、 クリップインフォメーションファイル" 00002 .dpi"のプロック blkCPlOに格納される。
また、 ブロック blkClipInioO内のフラグ IsCC5は、 ユーザ操作によ りクリップの記録が停止された場合、 値が 1 (バイナリ値） とされる 。 それに伴い、 ブロック MkClipInfoO内の ii文 （第 16図参照） で 示されるデータが所定に設定される。
クリップィンフオメーシヨンファイルの作成が完了したら、 処理は 次のステップ S 205に移行する。 ステップ S 205〜ステップ S 2 08の処理は、 プレイリストファイルに関する処理である。 このステ ップ S 205〜ステップ S 208の処理により、 既に記録媒体 20上 に存在するプレイリストファイルに対して、 新たに記録されたクリッ プ AVストリ一ムファイル" 00002. m2ts"に対応するプレイアイテムが 追加される。
先ず、 ステップ S 205で、 プレイリストファイル内のブロック bl kPlayltemOにおけるフィ一ルド Connect ionCondi t ionの値が" 5"に設 定され、 このクリップが次のクリップと第 1のシームレス接続を行う ことが示される （第 12図参照） 。 次にステップ S 206で、 プレイ アイテムファイルのフィールド NumberOfPlayltemsの値が" 1 "だけィ ンクリメントされ、 当該プレイリストに対してプレイアイテムが 1つ 、 追加されることが示される （第 11図参照） 。
次のステップ S 207で、 ブロック MkPlayltemOにおけるフィー ルド ClipInformationFileName、 フィールド INTimeおよびフィ一ルド 0 UTTimeがそれぞれ設定され、 クリップの記録に伴い追加されるブロッ ク blkPlayltemOが作成される。 フィールド CI iplnformat ionFi leName は、 上述のステップ S 20 5で作成されたクリップィンフオメーショ ンファイルのファイル名" 00002. clpi"が格納される。 実際には、 クリ ップインフォメーションファイルの拡張子は固定的とされているので 、 ピリオドの前の部分" 00002"が格納される。 フィールド INTimeおよ びフィールド OUTTimeは、 対応するクリップ AVストリームファイル" 00002. m2ts"に格納されるビデオストリームの先頭および終端の時間 を示す情報であって、 例えばクリップインフォメーションファイル" 0 0002. clpi"内のブロック blkCPI ()におけるブロック blkEPMap ()の情報 に基づく。
次のステップ S 20 8で、 追記候補のプレイリストファイル内のブ 口ック blkPlayListMarkOにおけるフィ一ル ^NumberOfPlayListMarks の値が" 1"だけインクリメントされ、 それに伴い forループ文内に追 加されたフィールド MarkTimeStampの値が、 上述のステップ S 207 でブロック blkPlayltemOにおけるフィールド INTimeの値に設定され る。 すなわち、 新たに記録されたクリップの先頭に、 プレイリストマ 一クが打たれる。 プレイリストマークが打たれることにより、 チャフ。 夕が形成される。 すなわち、 これにより、 追記候補のプレイリストフ アイルに対してチヤプタが追記される。
このようにして、 新たに記録されたクリップ AVストリームフアイ ル" 00002. m2ts"に対して、 クリップインフォメーションファイル" 000 02.clpi"が作成されると共に、 追記候補のプレイリストファイルの更 新がなされる。 またこのとき、 プレイリストファイルにおける拡張デ 一タブ口ック1]11^1& 1^31£ 611310110& &0内のブロック blkPlayListM e t a ()の情報を更新するようにしてもよい。
なお、 上述したステップ S 2 0 3によるストリームバッファ 1 4に 溜め込まれたデ一夕の記録媒体 2 0への書き込み処理は、 ステップ S 2 0 8の処理の後に行うようにしてもよい。
プレイリストファイルを新規に作成してチヤプ夕を形成する場合に は、 上述の処理のうち、 ステップ S 2 0 5以下の処理が若干、 異なる ことになる。 すなわち、 プレイリストファイルにおける各フィールド のデータは、 それぞれ新規に生成されることになる。 これに限らず、 例えばプレイリストファイルのテンプレートを用意しておき、 テンプ レートのデータを変更することも考えられる。
次に、 この発明の実施の一形態の他の例について説明する。 上述で は、 この発明が単体の記録装置に適用された例について説明した （第 4 1図参照） 。 これに対し、 この実施の一形態の他の例では、 この発 明を、 撮像素子と、 被写体からの光を撮像素子に入射させる光学系と を有し、 撮像素子で撮像された撮像信号に基づきビデオデータを記録 媒体に記録するようにした、 ビデォカメラ装置に適用した。
第 5 3図は、 この発明の実施の一形態の他の例によるビデオカメラ 装置 1 0 0の一例の構成を示す。 ビデオカメラ装置 1 0 0において、 記録系の構成は、 第 4 1図を用いて説明した記録装置の構成を略その まま適用できるので、 第 4 1図と共通する部分には同一の符号を付し 、 詳細な説明を省略する。
第 5 3図の構成において、 カメラ部 5 0は、 映像信号に関する構成 として、 光学系 5 1、 撮像素子 5 2、 撮像信号処理部 5 3、 カメラ制 御部 5 4および表示部 5 5を有し、 音声信号に関する構成として、 マ イク口フォン （M I C ) 5 6および音声信号処理部 5 7を有する。 制 御部 3 0は、 カメラ部 5 0の各部との間で各種制御信号や情報のやり とりを行い、 カメラ部 50の動作を制御する。 また、 制御部 50は、 ユーザ操作に応じて U I部 3 1から供給される制御信号に基づき、 力 メラ部 50の動作を制御する。
なお、 ビデオカメラ装置 100として構成される場合、 記録開始操 作および記録停止操作は、 例えば、 U I部 3 1に設けられた単一の記 録スィツチを用い、 当該記録スィツチが押下される毎に記録開始およ び記録停止が交互に指示されるようになされるのが一般的である。 ま た、 このビデオカメラ装置 100では、 記録媒体 20として、 記録可 能なタイプの D VDや B l u— r a y D i s cといった、 ディスク 記録媒体を適用するものとする。
カメラ部 50において、 光学系 5 1は、 被写体からの光を撮像素子 52に導くためのレンズ系、 絞り調整機構、 フォーカス調整機構、 ズ ーム機構、 シャツ夕機構などを備える。 絞り調整機構、 フォーカス調 整機構、 ズーム機構およびシャツ夕機構の動作は、 制御部 30から供 給される制御信号に基づき、 カメラ制御部 54により制御される。 撮像素子 52は、 例えば C CD (Charge Coupled Device)からなり 、 光学系 5 1を介して照射された光を光電変換により電気信号に変換 し、 所定の信号処理を施し撮像信号として出力する。 撮像信号処理部 53は、 撮像素子から出力された撮像信号に対して所定の信号処理を 施し、 ベースバンドのディジタルビデオデータとして出力する。 例えば撮像信号処理部 53は、 撮像素子 52から出力された撮像信 号に対して、 CD S (Correlated Double Sampl ing)回路により画像情 報を有する信号だけをサンプリングすると共に、 ノイズを除去し、 A GC (Auto Gain Control)回路によりゲインを調整する。 そして、 A ZD変換によりディジタル信号に変換する。 また、 撮像信号処理部 5 3は、 このディジタル信号に対して検波系の信号処理を施し、 R (赤 色） 、 G (緑色） および B (青色） 各色の成分を取り出し、 ァ補正や ホワイトバランス補正などの処理を行い、 最終的に 1本のベースバン ドのディジ夕ルビデオデータとして出力する。
また、 撮像信号処理部 5 3は、 撮像素子 5 2から出力された撮像信 号の情報を制御部 3 0に送る。 制御部 3 0は、 この情報に基づき光学 系 5 1を制御するための制御信号を生成し、 カメラ制御部 5 4に供給 する。 カメラ制御部 5 4は、 この制御信号に基づきフォ一カス調整機 構や絞り調整機構などの制御を行う。
さらに、 撮像信号処理部 5 3は、 撮像素子 5 2から出力された撮像 信号に基づき、 例えば L C D (L i qui d Crys t al Di spl ay)を表示素子と して用いた表示部 5 5に映出させる映像信号を生成する。
一方、 マイクロフォン 5 6は、 周囲の音声を収音して電気信号に変 換して出力する。 マイクロフォン 5 6から出力された音声信号は、 音 声信号処理部 5 7に供給される。 音声信号処理部 5 7は、 供給された 音声信号を、 リミッタを介してから AZD変換を施してディジタルォ 一ディォデ一夕とし、 ノイズ除去や音質補正など所定の音声信号処理 を施してベースバンドのディジタルオーディォデータとして出力する カメラ部 5 0の撮像信号処理部 5 3から出力されたベースバンドの ディジタルビデオデータは、 記録部 1 0の端子 4 0に供給される。 ま た、 音声信号処理部 5 7から出力されたベースバンドのディジタルォ 一ディォデ一夕は、 記録部 1 0の端子 4 1に供給される。
撮影時に、 記録媒体 2 0がビデオカメラ装置 1 0 0に所定に装填さ れると、 第 4 3図を用いて説明した処理に従い、 撮影して得られるビ デォデ一夕に基づくチヤプ夕の追記候補のプレイリストファイルが特 定されると共に、 特定された追記候補のプレイリストファイルに対し てチヤプ夕を追記可能か否かが判断される。
例えば、 制御部 3 0の制御に基づき記録媒体 2 0に記録されている インデックスファイルが読み込まれ、 管理情報処理部 1 6を介して揮 発性メモリ 1 7に記憶される。 制御部 3 0は、 揮発性メモリ 1 7に記 憶されたインデックスファイルの情報に基づき追記候補のプレイリス トファイルを特定し、 記録制御部 1 5に対して、 当該追記候補のプレ ィリストファイルを記録媒体 2 0から読み出すように命令を出す。 こ の命令に基づき記録媒体 2 0から読み出された追記候補のプレイリス トファイルは、 管理情報処理部 1 6を介して揮発性メモリ 1 7に記憶 される。
制御部 3 0は、 揮発性メモリ 1 7に記憶された追記候補のプレイリ ストファイルの情報に基づき、 記録制御部 1 5に対して、 当該追記候 補のプレイリストファイルに関連する全てのクリップインフォメ一シ ョンファイルを記録媒体 2 0から読み出すように命令を出す。 この命 令に基づき記録媒体 2 0から読み出されたクリップインフォメーショ ンファイルは、 揮発性メモリ 1 7に記憶される。 制御部 3 0は、 揮発 性メモリ 1 7に記憶された追記候補のプレイリストファイルと、 当該 追記候補のプレイリストファイルに関連する全てのクリップィンフォ メ一ションファイルとに基づき、 第 4 3図のフローチャートにおける ステップ S 1 0 4〜ステップ S 1 1 1までの各判断を行う。 各判断の 結果は、 それぞれ、 例えば制御部 3 0のレジスタに保持される。
制御部 3 0は、 ステップ S 1 0 4〜ステップ S 1. 1 1の各判断が終 了すると、 第 4 3図のステップ S 1 1 2の処理により、 ステップ S 1 0 4〜ステップ S 1 1 1の各判断の判断結果に対して総合的な判断を 行い、 撮影され得られるビデオデータに基づくチヤプタを追記候補の プレイリストファイルに追記するか否かを判断する。 制御部 3 0は、 この判断結果に基づき、 追記すると判断された場合は、 チヤプ夕を揮 発性メモリ 1 7に記憶されている追記候補のプレイリストファイルに 対して追記し、 追記しないと判断された場合は、 新規にプレイリスト ファイルを生成してこの新規のプレイリストファイルに対して記録す るように、 管理情報処理部 1 6を制御する。
記録停止状態から U I部 3 1に設けられた記録スィッチが押下され ると、 記録開始を指示する制御信号が U I部 3 1から制御部 3 0に供 給され、 制御部 3 0の制御に基づきカメラ部 5 0から出力されたべ一 スバンドのディジタルビデオ信号およびディジ夕ルオーディォデータ の記録媒体 2 0への記録が開始される。
すなわち、 既に説明したように、 制御部 3 0の制御に基づきビデオ エンコーダ 1 1およびオーディオエンコーダ 1 2の動作が開始され、 ビデオデータおよびオーディオデータがそれぞれビデオエンコーダ 1 1およびオーディオエンコーダ 1 2で圧縮符号化され、 マルチプレク サ 1 3で所定にバケツト化され多重化されて A Vストリームデータと される。 A Vストリームデータは、 ストリームバッファ 1 4を介して 、 記録制御部 1 5に供給され、 クリップ A Vストリームファイルとし て記録媒体 2 0に記録される。
U I部 3 1の記録スィッチが再び押下されると、 記録が停止され、 クリップインフォメーションファイルの作成や、 プレイリストフアイ ルの更新が行われる。 管理情報処理部 1 6は、 マルチプレクサ 1 3お よび記録制御部 1 5からの情報に基づき、 記録媒侔 2 0に記録される クリップ A Vストリームファイルに対応するクリップインフォメーシ ヨンファイルを作成すると共に、 当該クリップインフォメーションフ アイルを参照するプレイアイテムを生成する。
追記候補のプレイリストファイルにチヤプタを追記するように判断 されている場合には、 当該追記候補のプレイリストファイルに対して 、 生成されたプレイアイテムを追加すると共プレイリストマークを打 ち、 チヤプ夕を形成する。 追記候補のプレイリストファイルに対する チヤプ夕の追加が不可と判断されている場合には、 新規に作成された プレイリストファイルに対して、 生成されたプレイアイテムの追加お よびプレイリストマークの設定を行う。
この状態からもう一度記録スィッチが押下されると、 再び記録開始 が指示され、 新たなクリップ A Vストリームファイルの記録媒体 2 0 への記録が開始される。 この再度の記録開始の際に、 第 4 3図のフロ 一チャートに従い再び追記候補のプレイリストファイルに対する新た な記録に基づくチヤプ夕の追記可否判断を行うとよい。
なお、 上述では、 第 4 1図に示す記録装置や第 5 3図に示すビデオ カメラ装置 1 0 0の記録部 1 0がハードウェア的に構成されるように 説明したが、 これはこの例に限定されない。 すなわち、 記録部 1 0は 、 ソフトウェアとして構成することも可能である。 この場合、 ソフト ウェアは、 例えば制御部 3 0が有する図示されない R O Mに予め記憶 される。 これに限らず、 記録部 1 0を、 パーソナルコンピュータなど のコンピュータ装置上に構成することも可能である。 この場合には、 記録部 1 0をコンピュータ装置に実行させるソフトウエアは、 C D— R O Mや D V D— R O Mといった記録媒体に記録されて提供される。 コンピュータ装置がネットワーク接続可能な場合、 インターネットな どのネッ卜ワークを介して当該ソフトウエアを提供することも可能で ある。

Claims

請 求 の 範 囲
1 . ビデオデータとオーディオデータとを多重化して記録媒体に記録 • する記録装置において、
ビデオデータおょぴオーディオデータが入力されるデータ入力部と 、
上記ビデオデータおよびオーディオデータの記録開始および記録停 止の指示が入力される記録指示入力部と、
上記ビデオデー夕およびオーディォデータを多重化し、 多重化され たストリームをストリームファイルとして記録媒体に記録する記録部 と、
上記ストリームファイルの属性情報を示す第 1の管理情報と、 上記 ストリームファイルの再生方法を示す情報を含む第 2の管理情報とか らなる、 上記記録媒体に記録される上記ストリームファイルの再生を 制御するための再生管理情報を生成する管理情報生成部と
を有し、
上記管理情報生成部は、
既存の上記再生管理情報に基づき、 上記記録指示入力部による上記 記録開始の指示に従い上記記録媒体に記録される上記ストリームファ ィルに対する上記再生方法を示す情報を、 上記既存の再生管理情報に 含まれる所定の上記第 2の管理情報に対して追記するか否かの追記可 否判断を行う
ことを特徴とする記録装置。
2 . 請求の範囲 1に記載の記録装置において、
上記管理情報生成部は、
上記記録指示入力部による上記記録開始の指示に従い上記記録媒体 に記録される上記ストリームファイルに対する上記再生方法を示す情 報を上記既存の再生管理情報に含まれる上記所定の第 2の管理情報に 対して追記しないと判断した場合、 上記記録指示入力部による上記記 録開始の指示に従い上記記録媒体に記録される上記ストリームフアイ ルに対する上記再生方法を示す情報を含む上記第 2の管理情報を新規 に生成する
ことを特徴とする記録装置。
3 . 請求の範囲 1に記載の記録装置において、
上記管理情報生成部は、
上記ストリームフアイルの記録に伴い更新されるようにされた上記 第 2の管理情報のうち、 最も新しく更新された該第 2の管理情報を、 上記所定の第 2の管理情報とする
ことを特徴とする記録装置。
4 . 請求の範囲 1に記載の記録装置において、
上記第 1の管 情報は、
上記記録媒体に記録される上記ストリームファイルに対し、 少なく とも、 該ストリームフアイルの再生時刻情報とアドレス情報との対応 関係を示す情報が格納されたフアイルからなり、
上記第 2の管理情報は、
該ストリームファイルに対して再生開始点と再生終了点とを設定す ることにより再生区間を指定する 1以上の再生区間情報が格納され、 上記ストリームファイルに対する再生時刻情報を示すマーク情報が格 納可能とされたファイルからなり、
上記第 2の管理情報は、 上記再生区間情報から上記第 1の管理情報 を参照することで上記ストリ一ムファイルの再生方法を示すようにさ れた
ことを特徴とする記録装置。
5 . 請求の範囲 4に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報に格納される上記再生区間情報の数に基 づく
ことを特徴とする記録装置。
6 . 請求の範囲 5に記載の記録装置において、
上記管理情報生成部は、
上記所定の第 2の管理情報に既に格納された上記再生区間情報の数 が予め設定された上限未満であると判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする記録装置。
7 . 請求の範囲 4に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報に格納される上記マーク情報の数に基づ
<
ことを特徴とする記録装置。
8 . 請求の範囲 7に記載の記録装置において、
上記管理情報生成部は、
上記所定の第 2の管理情報に既に格納された上記マーク情報の数が 予め設定された上限未満であると判断したら、
上記記録媒体に記録される上記ストリ一ムファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする記録装置。
9 . 請求の範囲 4に記載の記録装置において、
上記第 1の管理情報は、 対応する上記ストリームファイルに格納さ れる上記ビデオデータの属性を示すビデオ属性情報をさらに格納し、 上記管理情報生成部による上記追記可否判断は、
上記第 1の管理情報に格納される上記ビデオ属性情報に基づく ことを特徴とする記録装置。
1 0 . 請求の範囲 9に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
現在の記録モードに基づくビデオ属性と、 上記所定の第 2の管理情 報から参照される上記第 1の管理情報のうち少なくとも 1の上記管理 情報に格納されるビデオ属性とに基づきなされる
ことを特徴とする記録装置。
1 1 . 請求の範囲 1 0に記載の記録装置において、
上記管理情報生成部は、
上記記録モードに基づくビデオ属性と、 上記 1の第 1の管理情報に 格納されるビデオ属性との間で、 画枠サイズ、 アスペクト比、 フレー ムレートおよび走査方式のうち少なくとも 1つが一致しない場合に、 上記記録指示入力部による上記記録開始の指示に従い上記記録媒体 に記録される上記ストリームファイルに対する上記再生方法を示す情 報を、 上記所定の第 2の管理情報に対して追記しないように上記追記 可否判断を行う
ことを特徴とする記録装置。
1 2 . 請求の範囲 4に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報のファィルサイズに基づく
ことを特徴とする記録装置。
1 3 . 請求の範囲 1 2に記載の記録装置において、 上記管理情報生成部は、
1の上記ストリームファイルの記録に伴い生成される上記再生区間 情報および上記マーク情報のデータサイズに基づき、 1の上記ストリ ームファイルが記録されることで上記第 2の管理情報のファイルサイ ズが予め設定された上限を超えないと判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする記録装置。
1 4 . 請求の範囲 4に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報から参照される全ての上記第 1の管理情 報の合計ファィ レサィズに基づく
ことを特徴とする記録装置。
1 5 . 請求の範囲 1 4に記載の記録装置において、
上記管理情報生成部は、
1の上記ストリームファイルの保証された最低連続時間の記録に伴 い生成される上記第 1の管理情報のデータサイズに基づき、 1の上記 ストリームファイルが記録されることで、 上記所定の第 2の管理情報 から参照される上記第 1の管理情報の合計ファイルサイズが予め設定 された上限を越えないと判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする記録装置。
1 6 . 請求の範囲 4に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報から参照される全ての上記第 1の管理情 報に含まれる再生時刻情報とアドレス情報との対応関係を示す情報の 数に基づく
ことを特徴とする記録装置。
1 7 . 請求の範囲 1 6に記載の記録装置において、
上記管理情報生成部は、
1の上記ストリームファイルの保証された最低連続時間の記録に伴 い生成される上記第 1の管理情報に含まれる上記再生時刻情報とァド レス情報との対応関係を示す情報の数に基づき、 1の上記ストリーム ファイルが記録されることで、 上記第 2の管理情報から参照される全 ての上記第 1の管理情報での合計が上記第 2の管理情報に対して予め 設けられた上限 ¾越えないと判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする記録装置。
1 8 . 請求の範囲 4に記載の記録装置において、
上記第 2の管理情報は、 機器独自の情報をさらに格納可能とされ、 上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報に格納される上記機舉独自の情報に基づ
<
ことを特徴とする記録装置。
1 9 . 請求の範囲 1 8に記載の記録装置において、
上記管理情報生成部は、 上記所定の第 2の管理情報に上記機器独自の情報が格納される場合 に、 該機器独自の情報が自機または自機と同等の機器により生成され たと判断されたら、
上記記録媒体に記録される上記ストリームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする記録装置。
2 0 . 請求の範囲 4に記載の記録装置において、
上記第 2の管理情報は、 該第 2の管理情報の最終更新者を示す情報 をさらに格納可能とされ、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報に格納される上記最終更新者情報に基づ ぐ
ことを特徴とする記録装置。
2 1 . 請求の範囲 2 0に記載の記録装置において、
上記所定の第 2の管理情報に上記最終更新者情報が格納される場合 に、 該最終更新者情報が自機を示していると判断されたら、
上記記録媒体に記録される上記ストリームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする記録装置。
2 2 . 請求の範囲 1に記載の記録装置において、
上記管理情報生成部は、
1または複数の項目について上記追記可否判断を行い、 該追記可否 判断の結果、 該 1または複数の項目のうち 1つでも追記不可を示して いれば、 上記記録媒体に記録される上記ストリームファイルに対応す る上記第 2の管理情報を、 上記所定の第 2の管理情報に対して追記し ないように上記追記可否判断を行う
ことを特徴とする記録装置。
2 3 . 請求の範囲 2 2に記載の記録装置において、
上記 1または複数の項目は、
上記所定の第 2の管理情報に格納される再生区間情報の数と、 上記 所定の第 2の管理情報に格納されるマーク情報の数と、 上記第 1の管 理情報に格納されるビデオ属性情報と、 上記所定の第 2の管理情報の ファイルサイズと、 上記所定の第 2の管理情報から参照される全ての 上記第 1の管理情報の合計ファイルサイズと、 上記所定の第 2の管理 情報から参照される全ての上記第 1の管理情報に含まれる再生時刻情 報とアドレス情報との対応関係を示す情報の数と、 上記所定の第 2の 管理情報に格納される機器独自の情報と、 上記所定の第 2の管理情報 に格納される最終更新者情報とのうち、 少なくとも 1の項目を含む ことを特徴とする記録装置。
2 4 . ビデオデータとオーディオデータとを多重化して記録媒体に記 録する記録方法において、
データ入力部に入力されたビデオデ一夕およびオーディオデ一夕の 記録開始および記録停止の指示が入力される記録指示入力のステップ と、
上記ビデオデ一タおよびオーディォデー夕を多重化し、 多重化され たストリ一ムをストリームファイルとして記録媒体に記録する記録の ステップと、
上記ストリームファイルの属性情報を示す第 1の管理情報と、 上記 ストリームファイルの再生方法を示す情報を含む第 2の管理情報とか らなる、 上記記録媒体に記録される上記ストリームファイルの再生を 制御するための再生管理情報を生成する管理情報生成のステップと を有し、
上記管理情報生成のステップは、
既存の上記再生管理情報に基づき、 上記記録指示入力のステップに よる上記記録開始の指示に従い上記記録媒体に記録される上記ストリ ームファイルに対する上記再生方法を示す情報を、 上記既存の再生管 理情報に含まれる所定の上記第 2の管理情報に対して追記するか否か の追記可否判断を行う
ことを特徴とする記録方法。
2 5 . ビデオデータとオーディオデータとを多重化して記録媒体に記 録する記録方法をコンピュータ装置に実行させる記録プログラムにお いて、
上記記録方法は、
データ入力部に入力されたビデオデ一夕およびオーディオデ一夕の 記録開始および記録停止の指示が入力される記録指示入力のステップ と、
上記ビデオデータおよびオーディオデータを多重化し、 多重化され たストリームをストリ一ムファイルとして記録媒体に記録する記録の ステッフと、
上記ストリームファイルの属性情報を示す第 1の管理情報と、 上記 ストリームファイルの再生方法を示す第 2の管理情報とからなる、 上 記記録媒体に記録される上記ストリームファイルの再生を制御するた めの再生管理情報を生成する管理情報生成のステップと
を有し、
上記管理情報生成のステップは、
既存の上記再生管理情報に基づき、 上記記録指示入力のステップに よる上記記録開始の指示に従い上記記録媒体に記録される上記ストリ ームファイルに対する上記再生方法を示す情報を、 上記既存の再生管 理情報に含まれる所定の上記第 2の管理情報に対して追記するか否か の追記可否判断を行う
ことを特徴とする記録プログラム。
2 6 . 撮像部で被写体を撮像して得られたビデオデータと、 収音部で 音声を収音して得られたオーディオデータとを多重化して記録媒体に 記録する撮像装置において、
被写体を撮像してビデオデータを出力する撮像部と、
音声を収音してオーディオデータを出力する収音部と、
上記ビデオデータおよび上記オーディオデータを多重化し、 多重化 されたストリ一ムをストリームファイルとして記録媒体に記録する記 録部と、
上記ビデオデータおよび上記オーディオデータの上記記録媒体への 記録開始および記録停止を指示するユーザ操作を受け付ける操作部と 上記ストリームファイルの属性情報を示す第 1の管理情報と、 上記 ストリームファイルの再生方法を示す情報を含む第 2の管理情報とか らなる、 上記記録媒体に記録される上記ストリームファイルの再生を 制御するための再生管理情報を生成する管理情報生成部と
を有し、
上記管理情報生成部は、
既存の上記再生管理情報に基づき、 上記操作部に対する上記ユーザ 操作に応じた上記記録開始の指示に従い上記記録媒体に記録される上 記ストリームファイルに対する上記再生方法を示す情報を、 上記既存 の再生管理情報に含まれる所定の上記第 2の管理情報に対して追記す るか否かの追記可否判断を行う
ことを特徴とする撮像装置。
2 7 . 請求の範囲 2 6に記載の撮像装置において、
上記管理情報生成部は、
上記操作部による上記記録開始の指示に従い上記記録媒体に記録さ れる上記ストリームファイルに対する上記再生方法を示す情報を上記 既存の再生管理情報に含まれる上記所定の第 2の管理情報に対して追 記しないと判断した場合、 上記記録指示入力部による上記記録開始の 指示に従い上記記録媒体に記録される上記ストリームファイルに対す る上記再生方法を示す情報を含む上記第 2の管理情報を新規に生成す る
ことを特徴とする撮像装置。
2 8 . 請求の範囲 2 6に記載の撮像装置において、
上記管理情報生成部は、
上記ストリームファイルの記録に伴い更新されるようにされた上記 第 2の管理情報のうち、 最も新しく更新された該第 2の管理情報を、 上記所定の第 2の管理情報とする
ことを特徴とする撮像装置。
2 9 . 請求の範囲 2 6に記載の撮像装置において、
上記第 1の管理情報は、
上記記録媒体に記録される上記ストリームファイルに対し、 少なく とも、 該ストリームファイルの再生時刻情報とァドレス情報との対応 関係を示す情報が格納されたファイルからなり、
該ストリームファイルに対して再生開始点と再生終了点とを設定す ることにより再生区間を指定する 1以上の再生区間情報が格納され、 上記ストリームファイルに対する再生時刻情報を示すマーク情報が格 納可能とされたファイルからなり、
上記第 2の管理情報は、 上記再生区間情報から上記第 1の管理情報 を参照することで上記ストリームファイルの再生方法を示すようにさ れた
ことを特徴とする撮像装置。
3 0 . 請求の範囲 2 9に記載の撮像装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報に格納される上記再生区間情報の数に基 づく
ことを特徴とする撮像装置。
3 1 . 請求の範囲 3 0に記載の撮像装置において、
上記管理情報生成部は、
上記所定の第 2の管理情報に既に格納された上記再生区間情報の数 が予め設定された上限未満であると判断したら、
上記記録媒体に記録される上記ス卜リームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする撮像装置。
3 2 . 請求の範囲 2 9に記載の撮像装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報に格納される上記マーク情報の数に基づ
<
ことを特徴とする撮像装置。
3 3 . 請求の範囲 3 2に記載の撮像装置において、
上記管理情報生成部は、
上記所定の第 2の管理情報に既に格納された上記マーク情報の数が 予め設定された上限未満であると判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする撮像装置。
3 4 . 請求の範囲 2 9に記載の撮像装置において、
上記第 1の管理情報は、 対応する上記ストリームファイルに格納さ れる上記ビデオデータの属性を示すビデオ属性情報をさらに格納し、 上記管理情報生成部による上記追記可否判断は、
上記第 1の管理情報に格納される上記ビデオ属性情報に基づく ことを特徴とする撮像装置。
3 5 . 請求の範囲 3 4に記載の撮像装置において、
上記管理情報生成部による上記追記可否判断は、
現在の記録モードに基づくビデオ属性と、 上記所定の第 2の管理情 報から参照される上記第 1の管理情報のうち少なくとも 1の上記管理 情報に格納されるビデオ属性とに基づきなされる
ことを特徴とする撮像装置。
3 6 . 請求の範囲 3 5に記載の撮像装置において、
上記管理情報生成部は、
上記記録モードに基づくビデオ属性と、 上記 1の第 1の管理情報に 格納されるビデオ属性との間で、 画枠サイズ、 アスペクト比、 フレー ムレートおよび走査方式のうち少なくとも 1つが一致しない場合に、 上記記録指示入力部による上記記録開始の指示に従い上記記録媒体 に記録される上記ストリームファイルに対上記再生方法を示す情報を 、 上記所定の第 2の管理情報に対して追記しないように上記追記可否 判断を行う ことを特徴とする撮像装置。
3 7 . 請求の範囲 2 9に記載の撮像装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報のファイルサイズに基づく
ことを特徴とする撮像装置。
3 8 . 請求の範囲 3 7に記載の撮像装置において、
上記管理情報生成部は、
1の上記ストリームファイルの記録に伴い生成される上記再生区間 情報および上記マーク情報のデータサイズに基づき、 1の上記ストリ ームフアイルが記録されることで上記第 2の管理情報のフアイルサイ ズが予め設定された上限を超えないと判断したら、 ，
上記記録媒体に記録される上記ストリームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする撮像装置。
3 9 . 請求の範囲 2 9に記載の撮像装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報から参照される全ての上記第 1の管理情 報の合計ファイルサイズに基づく
ことを特徴とする撮像装置。
4 0 . 請求の範囲 3 9に記載の撮像装置において、
上記管理情報生成部は、
1の上記ストリームファイルの保証された最低連続時間の記録に伴 い生成される上記第 1の管理情報のデータサイズに基づき、 1の上記 ストリームファイルが記録されることで、 上記所定の第 2の管理情報 から参照される上記第 1の管理情報の合計ファイルサイズが予め設定 された上限のサイズを越えないと判断したら、
上記記録媒体に記録される上記ス卜リームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする撮像装置。
4 1 . 請求の範囲 2 9に記載の撮像装置において、
上記第 2の管理情報は、 上記再生区間情報から上記第 1の管理情報 を参照することで、 上記ストリームファイルの再生を制御するように され、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報から参照される全ての上記第 1の管理情 報に含まれる再生時刻情報とァドレス情報との対応関係を示す情報の 数に基づく
ことを特徴とする撮像装置。
4 2 . 請求の範囲 4 1に記載の撮像装置において、
上記管理情報生成部は、
1の上記ストリームファイルの保証された最低連続時間の記録に伴 い生成される上記第 1の管理情報に含まれる再生時刻情報とァドレス 情報との対応関係を示す情報の数に基づき、 1の上記ストリームファ ィルが記録されることで、 上記第 2の管理情報から参照される全ての 上記第 1の管理情報での合計が上記第 2の管理情報に対して予め設け られた上限を越えないと判断したら、
上記記録媒体に記録される上記ストリ一ムファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする撮像装置。
4 3 . 請求の範囲 2 9に記載の撮像装置において、 上記第 2の管理情報は、 機器独自の情報をさらに格納可能とされ、 上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報に格納される上記機器独自の情報に基づ <
ことを特徴とする撮像装置。
4 4 . 請求の範囲 4 3に記載の撮像装置において、
上記管理情報生成部は、
上記所定の第 2の管理情報に上記機器独自の情報が格納される場合 に、 該機器独自の情報が自機または自機と同等の機器により生成され たと判断されたら、
上記記録媒体に記録される上記ストリームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする撮像装置。
4 5 . 請求の範囲 2 9に記載の撮像装置において、
上記第 2の管理情報は、 該第 2の管理情報の最終更新者を示す情報 をさらに格納可能とされ、
上記管理情報生成部による上記追記可否判断は、
上記所定の第 2の管理情報に格納される上記最終更新者情報に基づ <
ことを特徴とする撮像装置。
4 6 . 請求の範囲 4 5に記載の撮像装置において、
上記所定の第 2の管理情報に上記最終更新者情報が格納される場合 に、 該最終更新者情報が自機を示していると判断されたら、
上記記録媒体に記録される上記ストリームファイルに対する上記再 生方法を示す情報を、 上記所定の第 2の管理情報に対して追記するよ うに上記追記可否判断を行う
ことを特徴とする撮像装置。 ■ 4 7 . 請求の範囲 2 6に記載の撮像装置において、
上記管理情報生成部は、
1または複数の項目について上記追記可否判断を行い、 該追記可否 判断の結果、 該 1または複数の項目のうち 1つでも追記不可を示して いれば、 上記記録媒体に記録される上記ストリームファイルに対応す る上記第 2の管理情報を、 上記所定の第 2の管理情報に対して追記し ないように上記追記可否判断を行う
ことを特徴とする撮像装置。
4 8 . 請求の範囲 4 7に記載の撮像装置において、
上記 1または複数の項目は、
上記所定の第 2の管理情報に格納される再生区間情報の数と、 上記 所定の第 2の管理情報に格納されるマーク情報の数と、 上記第 1の管 理情報に格納されるビデオ属性情報と、 上記所定の第 2の管理情報の ファイルサイズと、 上記所定の第 2の管理情報から参照される全ての 上記第 1の管理情報の合計ファイルサイズと、 上記所定の第 2の管理 情報から参照される全ての上記第 1の管理情報に含まれる再生時刻情 報とアドレス情報との対応関係を示す情報の数と、 上記所定の第 2の 管理情報に格納される機器独自の情報と、 上記所定の第 2の管理情報 に格納される最終更新者情報とのうち、 少なくとも 1の項目を含む ことを特徴とする撮像装置。
4 9 . 撮像部で被写体を撮像して得られたビデオデータと、 収音部で 音声を収音して得られたオーディオデータとを多重化して記録媒体に 記録する撮像装置の撮像方法において、 撮像部で被写体を撮像して得られたビデオデー夕と、 収音部で音声 を収音して得られたオーディオデータとを多重化し、 多重化されたス トリームをストリームファイルとして記録媒体に記録する記録のステ ップと、
操作部に対する上記ビデオデータおよび上記オーディォデ一夕の上 記記録媒体への記録開始および記録停止を指示するユーザ操作を受け 付けるステップと、
上記ストリームファイルの属性情報を示す第 1の管理情報と、 上記 ストリームファイルの再生方法を示す情報を含む第 2の管理情報とか らなる、 上記記録媒体に記録される上記ストリームファイルの再生を 制御するための再生管理情報を生成する管理情報生成のステップと を有し、
上記管理情報生成のステップは、
既存の上記再生管理情報に基づき、 上記操作部に対する上記ユーザ 操作に応じた上記記録開始の指示に従い上記記録媒体に 3録される上 記ストリームファイルに対する上記再生方法を示す情報を、 上記既存 の再生管理情報に含まれる所定の上記第 2の管理情報に対して追記す るか否かの追記可否判断を行う
ことを特徴とする撮像方法。
5 0 . 撮像部で被写体を撮像して得られたビデオデ一夕と、 収音部で 音声を収音して得られたオーディオデータとを多重化して記録媒体に 記録する撮像装置の撮像方法をコンピュータ装置に実行させる撮像プ ログラムにおいて、
上記撮像方法は、
撮像部で被写体を撮像して得られたビデオデータと、 収音部で音声 を収音して得られたオーディオデ一夕とを多重化し、 多重化されたス トリームをストリームファイルとして記録媒体に記録する記録のステ ップと、
操作部に対する上記ビデオデータおよび上記オーディオデータの上 記記録媒体への記録開始および記録停止を指示するユーザ操作を受け 付けるステップと、
上記ストリームファイルの属性情報を示す第 1の管理情報と、 上記 ストリームファイルの再生方法を示す情報を含む第 2の管理情報とか らなる、 上記記録媒体に記録される上記ストリームファイルの再生を 制御するための再生管理情報を生成する管理情報生成のステップと を有し、
上記管理情報生成のステップは、
既存の上記再生管理情報に基づき、 上記操作部に対する上記ユーザ 操作に応じた上記記録開始の指示に従い上記記録媒体に記録される上 記ストリームファイルに対する上記再生方法を示す情報を、 上記既存 の再生管理情報に含まれる所定の上記第 2の管理情報に対して追記す るか否かの追記可否判断を行う
ことを特徴とする撮像プログラム。
PCT/JP2007/060081 2006-05-18 2007-05-10 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム WO2007135932A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP07743516.2A EP2023629A4 (en) 2006-05-18 2007-05-10 Storage device, recording method, recording program, imaging device, imaging method, and imaging program
KR1020087000499A KR101379034B1 (ko) 2006-05-18 2007-05-10 기록 장치, 기록 방법 및 기록 프로그램과 촬상 장치, 촬상방법 및 촬상 프로그램
CN2007800007225A CN101331764B (zh) 2006-05-18 2007-05-10 记录装置、记录方法、记录程序、摄像装置、摄像方法和摄像程序
US11/988,978 US8995816B2 (en) 2006-05-18 2007-05-10 Recording apparatus, recording method, and recording program, and image capturing apparatus, image capturing method and image capturing program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2006138701A JP4910475B2 (ja) 2006-05-18 2006-05-18 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
JP2006-138701 2006-05-18

Publications (1)

Publication Number Publication Date
WO2007135932A1 true WO2007135932A1 (ja) 2007-11-29

Family

ID=38723245

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2007/060081 WO2007135932A1 (ja) 2006-05-18 2007-05-10 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム

Country Status (7)

Country Link
US (1) US8995816B2 (ja)
EP (1) EP2023629A4 (ja)
JP (1) JP4910475B2 (ja)
KR (1) KR101379034B1 (ja)
CN (1) CN101331764B (ja)
TW (1) TW200805293A (ja)
WO (1) WO2007135932A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008204560A (ja) * 2007-02-21 2008-09-04 D & M Holdings Inc 再生装置、再生方法、プログラム及び記録媒体
KR101777347B1 (ko) * 2009-11-13 2017-09-11 삼성전자주식회사 부분화에 기초한 적응적인 스트리밍 방법 및 장치
JP5634057B2 (ja) * 2009-12-16 2014-12-03 キヤノン株式会社 記録装置及び記録方法
JP2013051607A (ja) * 2011-08-31 2013-03-14 Canon Inc データ処理装置、方法および制御プログラム
CN103226602B (zh) * 2013-04-26 2016-08-10 福建联迪商用设备有限公司 一种实现在单个文件中循环存储记录的定位读取偏移方法
WO2015018063A1 (zh) * 2013-08-09 2015-02-12 华为技术有限公司 频谱更新使用方法、系统及白频谱设备
JP5779684B2 (ja) * 2014-03-24 2015-09-16 日立マクセル株式会社 映像記録再生装置及び映像記録再生方法
JP6463967B2 (ja) * 2014-12-25 2019-02-06 キヤノン株式会社 撮像装置及びその制御方法
CN108786113B (zh) * 2018-05-25 2021-06-25 腾讯科技(成都)有限公司 数据播放方法和装置、存储介质及电子装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004350251A (ja) 2003-03-25 2004-12-09 Sony Corp 記録方法、記録装置、記録媒体、再生方法、再生装置および撮像装置
JP2005027159A (ja) * 2003-07-04 2005-01-27 Canon Inc 記録装置及び方法
JP2005317076A (ja) * 2004-04-28 2005-11-10 Matsushita Electric Ind Co Ltd コンテンツ結合管理装置、コンテンツ結合管理方法、コンテンツ結合管理プログラム、及びコンピュータ読み取り可能な記録媒体
WO2006030767A1 (ja) * 2004-09-13 2006-03-23 Matsushita Electric Industrial Co., Ltd. データ処理装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69636648T2 (de) 1995-04-14 2007-12-06 Kabushiki Kaisha Toshiba, Kawasaki Gerät zur Wiedergabe von einem Aufzeichnungsmedium
US5986979A (en) * 1997-10-16 1999-11-16 Delco Electronics Corporation Play list control method and system for
WO2004001749A1 (en) * 2002-06-21 2003-12-31 Lg Electronics Inc. Recording medium having data structure for managing reproduction of video data recorded thereon
JP4425138B2 (ja) 2002-07-12 2010-03-03 パナソニック株式会社 再生装置
US7668842B2 (en) * 2002-10-16 2010-02-23 Microsoft Corporation Playlist structure for large playlists
JP3937223B2 (ja) 2003-01-21 2007-06-27 ソニー株式会社 記録装置、再生装置、記録方法及び再生方法
JP4026518B2 (ja) * 2003-03-12 2007-12-26 ソニー株式会社 記録媒体、記録装置、記録方法
KR20040083632A (ko) * 2003-03-24 2004-10-06 엘지전자 주식회사 고밀도 광디스크의 멀티 타이틀 관리 및 재생방법
JP4228767B2 (ja) * 2003-04-25 2009-02-25 ソニー株式会社 再生装置、再生方法、再生プログラムおよび記録媒体
US7660512B2 (en) * 2003-10-16 2010-02-09 Microsoft Corporation Systems and methods for managing frame rates during multimedia playback
US8180770B2 (en) * 2005-02-28 2012-05-15 Yahoo! Inc. System and method for creating a playlist
US7840178B2 (en) * 2005-07-12 2010-11-23 Martin E. Hellman FM broadcast system competitive with satellite radio

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004350251A (ja) 2003-03-25 2004-12-09 Sony Corp 記録方法、記録装置、記録媒体、再生方法、再生装置および撮像装置
JP2005027159A (ja) * 2003-07-04 2005-01-27 Canon Inc 記録装置及び方法
JP2005317076A (ja) * 2004-04-28 2005-11-10 Matsushita Electric Ind Co Ltd コンテンツ結合管理装置、コンテンツ結合管理方法、コンテンツ結合管理プログラム、及びコンピュータ読み取り可能な記録媒体
WO2006030767A1 (ja) * 2004-09-13 2006-03-23 Matsushita Electric Industrial Co., Ltd. データ処理装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2023629A4 *

Also Published As

Publication number Publication date
JP2007312071A (ja) 2007-11-29
CN101331764A (zh) 2008-12-24
US8995816B2 (en) 2015-03-31
KR101379034B1 (ko) 2014-04-10
EP2023629A1 (en) 2009-02-11
JP4910475B2 (ja) 2012-04-04
EP2023629A4 (en) 2017-04-12
TW200805293A (en) 2008-01-16
US20090263103A1 (en) 2009-10-22
TWI377565B (ja) 2012-11-21
KR20090009769A (ko) 2009-01-23
CN101331764B (zh) 2010-12-22

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
JP5314097B2 (ja) 記録装置および情報記録方法
WO2007135932A1 (ja) 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
RU2334286C2 (ru) Носитель записи со структурой данных для управления записью и воспроизведением записанных на нем данных нескольких каналов и способы и устройства записи и воспроизведения
JP4622950B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
JP4552889B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、撮像装置および撮像方法
JP2010226278A (ja) 記録装置、方法、プログラム、及び媒体
JP4827642B2 (ja) 記録装置、記録方法、プログラムおよび集積回路

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200780000722.5

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 1020087000499

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 11988978

Country of ref document: US

Ref document number: 2007743516

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07743516

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE