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

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

Info

Publication number
WO2007129652A1
WO2007129652A1 PCT/JP2007/059345 JP2007059345W WO2007129652A1 WO 2007129652 A1 WO2007129652 A1 WO 2007129652A1 JP 2007059345 W JP2007059345 W JP 2007059345W WO 2007129652 A1 WO2007129652 A1 WO 2007129652A1
Authority
WO
WIPO (PCT)
Prior art keywords
recording
file
playback
data
stream file
Prior art date
Application number
PCT/JP2007/059345
Other languages
English (en)
French (fr)
Inventor
Yukio Isobe
Kenichiro Aridome
Naoki Morimoto
Atsushi Mae
Tetsuhiro Maeda
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 US11/919,712 priority Critical patent/US8094996B2/en
Priority to KR1020077026689A priority patent/KR101353000B1/ko
Priority to CN200780000642XA priority patent/CN101326583B/zh
Priority to EP07742780.5A priority patent/EP2017841B1/en
Publication of WO2007129652A1 publication Critical patent/WO2007129652A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • 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/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G11B2020/10537—Audio or video recording
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G11B2020/1062—Data buffering arrangements, e.g. recording or playback buffers
    • G11B2020/1075—Data buffering arrangements, e.g. recording or playback buffers the usage of the buffer being restricted to a specific kind of data
    • G11B2020/10759—Data buffering arrangements, e.g. recording or playback buffers the usage of the buffer being restricted to a specific kind of data content data
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B2020/10935—Digital recording or reproducing wherein a time constraint must be met
    • G11B2020/10944—Real-time recording or reproducing, e.g. for ensuring seamless playback of AV data
    • 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
    • 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/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/806—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal
    • H04N9/8063—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal using time division multiplex of the PCM audio and PCM video signals
    • 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

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.
  • a format that can specify the playback interval and playback order for a predetermined unit that requires continuous playback of video data and audio data that is, playback that guarantees real-time playback.
  • the AV stream file which is an AV stream of a predetermined unit
  • the AV stream on the recording medium It is possible to easily edit the AV stream file playback section and playback order without modifying the file.
  • a recording format that can be edited is required. Disclosure of the invention
  • an object of the present invention is to provide a recording apparatus, a recording method and a recording program capable of recording an AV stream in which video data and audio data are multiplexed on a recording medium so that title management and editing are easy, and imaging.
  • An apparatus, an imaging method, and an imaging program are provided.
  • a first invention is a recording apparatus that multiplexes video data and audio data and records the data on a recording medium, a data input unit to which the video data and audio data are input, A recording instruction input unit for inputting instructions for starting and stopping recording of video data and audio, and recording for multiplexing video data and audio data and recording the multiplexed stream as a stream file on a recording medium
  • a stream file recorded on the recording medium at least an attribute file in which the playback time information and address information of the stream file are associated, and a playback start point and a playback end point for the stream file.
  • the control unit is a section from a recording start to a recording stop based on an instruction of the recording instruction input unit.
  • the recording section is controlled so that video data and audio data corresponding to the above are recorded on the recording medium as one stream file, and playback section data for specifying the entire one stream file as a playback section is generated.
  • the recording apparatus is characterized in that the management information generating unit is controlled so that mark information indicating time information corresponding to a reproduction start time designated by the data is stored in a reproduction list file.
  • 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 the recording medium as a stream file, and the stream recorded on the recording medium Specify the playback section by setting at least the attribute file that associates the playback time information and address information of the stream file with the file, and the playback start point and playback end point for the stream file 1
  • the above playback section data is stored and shows the playback time information for the stream file.
  • a recording program for causing a computer apparatus to execute a recording method for multiplexing video data and audio data and recording the recording data on a recording medium.
  • Recording instruction input step in which video data and audio data recording start and recording stop instructions are input, and recording step in which video data and audio data are multiplexed and the multiplexed stream is recorded on a recording medium as a stream file
  • At least an attribute file that associates the playback time information and address information of the stream file with the stream file recorded on the recording medium, and a playback start point and a playback end point for the stream file.
  • a management information generation step for generating a reproduction list file in which mark information indicating reproduction time information for the stream file can be stored
  • a control step for controlling a recording step and a management information generation step
  • the video data and the audio data corresponding to the section from the recording start to the recording stop based on the instruction by the recording instruction input step are recorded on the recording medium as one stream file.
  • it In addition to controlling the recording step, it generates a playback section that designates the entire stream file as the playback section, and plays back the mark information indicating the time information corresponding to the playback start time specified by the playback section data
  • the management information generation step is controlled to be stored in the list file. It is a recording program.
  • an imaging in which video data obtained by imaging an object by an imaging unit and audio data obtained by collecting audio by the sound collecting unit are multiplexed and recorded on a recording medium.
  • an image pickup unit that picks up an image of a subject and outputs video data
  • a sound pickup unit that picks up sound and outputs audio data
  • a video stream and audio data are multiplexed, and a multiplexed stream
  • an operation section for accepting a user operation for instructing start and stop of recording of video data and audio data to the recording medium, and a stream file recorded on the recording medium.
  • At least an attribute file that associates stream file playback time information with address information, and a stream file Specify the playback section by setting the playback start point and playback end point.
  • One or more playback section data is stored, and a playlist file that can store mark information indicating playback time information for the stream file is generated.
  • a management information generation unit that controls the operation of the recording unit in response to a user operation on the operation unit, and a control unit that controls the management information generation unit.
  • the control unit responds to an operation on the operation unit.
  • the recording unit is controlled to record the video data and audio data corresponding to the section from the recording start to the recording stop as a single stream file on the recording medium, and the entire stream file of one is recorded. Is generated as a playback section, and mark information indicating the time information corresponding to the playback start time specified by the playback section data is played back.
  • An imaging apparatus characterized that you control the management information generating unit to store in the list file.
  • the fifth 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 unit The video data obtained by capturing the image and the audio data obtained by collecting the sound at the sound collection unit are multiplexed, and the multiplexed stream is recorded on the recording medium as a stream file.
  • Step of generating management information to generate playback section data that specifies the entire stream file as a playback section, and to store mark information indicating time information corresponding to the playback start time specified by the playback section data in the playlist file It is an imaging method characterized by controlling.
  • the sixth 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.
  • the imaging program for causing the computer device to execute the imaging method of the imaging device the imaging method is obtained by collecting the video data obtained by imaging the subject with the imaging unit and the sound by the sound collecting unit.
  • the recording step of multiplexing the audio data and recording the multiplexed stream as a stream file on the recording medium, and the start and recording of the video data and audio data for the operation unit on the recording medium A step of accepting a user operation for instructing a stop, an attribute file in which at least the reproduction time information and address information of the stream file are associated with the stream file recorded on the recording medium, and the reproduction start of the stream file Specify playback point by setting point and playback end point Management information for generating a playlist file that stores one or more playback segment data and can store mark information indicating playback time information for the stream file Recording according to the generation step and user operation on the operation unit And a control step for controlling the management information generation step.
  • the control step corresponds to a section from the start of recording to the stop of recording according to the operation on the operation unit.
  • the recording step is controlled so that video data and audio data are recorded as a single stream file on a recording medium, and playback section data that designates the entire stream file as a playback section is generated.
  • An imaging program characterized by controlling a management information generation step so that mark information indicating time information corresponding to a reproduction start time specified by reproduction section data is stored in a reproduction list file.
  • the first, second and third inventions provide at least a stream file recorded on the recording medium by multiplexing the video data and audio data input to the data input unit.
  • Specify the playback section by setting the attribute file that associates the playback time information and address information of the stream file, and the playback start point and playback end point for the stream file. Evening is stored
  • a play list file that can store mark information indicating playback time information for the stream file is generated, and a video data and an audio data corresponding to the section from the start of recording to the stop of recording based on the instruction by the recording instruction input are generated.
  • the stream file is recorded on the recording medium with a management structure that manages the clip in units of the playlist. be able to.
  • the fourth, fifth and sixth inventions are streams obtained by multiplexing video data obtained by imaging a subject with an imaging unit and audio data obtained by collecting audio with the sound collection unit.
  • the playback section data that specifies the playback section is stored, and a playlist file that can store mark information indicating the playback time information for the stream file is generated, and recording starts according to the operation on the operation unit.
  • Video data and audio data corresponding to the interval from recording to recording stop are recorded on the recording medium as a single stream file.
  • the playback section data that specifies the entire stream file of 1 as the playback section is generated, and mark information indicating time information corresponding to the playback start time specified by the playback section data is generated in the playlist file. Since the video and audio data obtained by imaging the subject are used in units of clips, the playlist is used. Can be recorded on a recording medium with a management structure managed by
  • At least the stream file is recorded on the stream file recorded on the recording medium by multiplexing the video data and the audio data input to the data input unit.
  • a playlist file that can store mark information indicating playback time information for the stream file is generated, and video data and audio data corresponding to the section from the recording start to the recording stop based on the instruction by the recording instruction input Is recorded on the recording medium as one stream file, and one stream file is recorded.
  • the playback section data that specifies the entire playback section as the playback section is generated, and the mark information indicating the time information corresponding to the playback start time specified by the playback section data is stored in the playlist file.
  • stream files can be recorded on a recording medium with a management structure that manages them using a playlist in units of clips.
  • the video data obtained by imaging the subject by the imaging unit and the audio data obtained by collecting the audio by the sound collecting unit are multiplexed.
  • a stream file in which a stream is recorded on a recording medium at least an attribute file in which playback time information and address information of the stream file are associated, and a playback start point and a playback end point for the stream file.
  • the playback section one or more playback section data is stored, and a playlist file that can store the mark information indicating the playback time information for the stream file is generated.
  • recording starts and stops recording
  • the video data and audio data corresponding to the interval up to are controlled to be recorded on the recording medium as one stream file,
  • FIG. 1 is a schematic diagram schematically showing a data model defined in the A VCHD format applicable to the present invention
  • FIG. 2 is a schematic diagram for explaining an index table
  • Fig. 4 is a schematic diagram for explaining a method of referring to the same clip from a plurality of 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 a file "index, bdmv".
  • FIG. 1 is a schematic diagram schematically showing a data model defined in the A VCHD format applicable to the present invention
  • FIG. 2 is a schematic diagram for explaining an index table
  • FIG. Is a UML diagram showing the relationship between clip AV streams, clip information, clips, play items, and playlists.
  • Fig. 4 is a schematic
  • FIG. 7 is a schematic diagram showing a syntax representing an example structure of a block blklndexesO
  • FIG. 8 is a schematic diagram showing a syntax representing an example structure of a file “MovieObject.bdmv”
  • FIG. Block blkMovieObjectsO one Fig. 10 is a schematic diagram showing syntax of an example structure.
  • Fig. 10 is a schematic diagram showing syntax of an example of a playlist file "xxxxx.mpls”.
  • Fig. 11 is an example of a block blkPlayListO.
  • Fig. 14 is a schematic diagram for explaining the structure of an example of a block blkPlayLisiMarkO.
  • Fig. 14 is a schematic diagram for explaining the structure of an example of a clip information file.
  • Fig. 16 is a schematic diagram showing the syntax of an example of the block MkClipInfofo
  • Fig. 17 shows the syntax of an example of the block blkSequencelnfoO.
  • Fig. 18 is a schematic diagram showing a syntax representing an example of the structure of a block blkProgramlnfoO.
  • Fig. 19 is a schematic diagram showing a syntax showing an example of the structure of a block MkCPlO.
  • Fig. 20 Is a schematic diagram showing the syntax of an example of the block blkEPMapO
  • Fig. 21 is a schematic diagram showing the syntax of an example of the block blkE PMapForOneStreaiPID (EP_stream_type, Nc, Nf)
  • Fig. 2 is a schematic diagram showing an example format of entry PTSEPCoarse and Entry PTSEPFine.
  • Fig. 23 is a schematic diagram showing an example format of Entry SMEPCoarse and Entry SPNEPFine.
  • Fig. 24 is a block blkExtensionData.
  • () Is a schematic diagram showing the syntax of an example structure, Fig.
  • FIG. 25 is a schematic diagram schematically showing the reference relationship of each data in the block MkExtensionDataO
  • Fig. 26 is a block blkExtensionDataO Flow chart showing an example of processing when writing
  • Fig. 27 is a flowchart showing an example of processing when reading extension data from the block blkE xtensionDataO
  • Fig. 28 is in the file "index.bdmv”
  • Fig. 29 is a schematic diagram showing the syntax representing an example of the structure of the block DataBlockO in the field blkE xtensionDataO.
  • Fig. 29 shows the block blkTableOfPlayListO.
  • FIG. 30A and FIG. 30B are flowcharts schematically showing the operation of the virtual player
  • FIG. 30A and FIG. 30B are flowcharts schematically showing the operation of the virtual player
  • FIG. 30A and FIG. 30B are flowcharts schematically showing the operation of the virtual player
  • FIG. 30A and FIG. 30B are
  • FIG. 33 is a block diagram schematically showing the configuration of an example of a recording apparatus applicable to an embodiment of the invention of the invention;
  • FIG. 33 is a flowchart showing an example of a recording method of a clip according to an embodiment of the invention;
  • FIG. 34 is a schematic diagram showing an example of a file structure recorded by the method according to the embodiment of the present invention, and
  • FIG. 35 is an example of a video camera device according to another example of the embodiment of the present invention.
  • AVCHD format an example format (hereinafter referred to as AVCHD format) applicable to the present invention will be described.
  • the AVCHD format is currently proposed as a recording format for recording AV (Audio / Video) streams in which video data and audio data are multiplexed on a recordable recording medium.
  • AV streams recorded on recording media can be managed using playlists in clip units.
  • I TU-T International Telecommunication Union-Telecomunication Standar Izato ion Secret Recommendation H. 264 Alma ISO (Internal ional Organization for Standar izat ion; / I EC (International Electrotechnical Commiss ion) International Standard 14496 — 1 0 (MP EG— 4 part 1 0) Advanced video coding (hereinafter abbreviated as H. 2 64 I AVC), MPEG (Moving Pictures Experts Group) video, MPEG audio, etc.
  • the bit stream encoded by the encoding method and multiplexed according to MP EG 2 Systems is called a clip AV stream (or AV stream). Recorded on the disc as a file. 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 AVCHD 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 layer above it is a layer on which a movie object (Movie Object) composed of commands for specifying the playback order and the like for the 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).
  • a clip AV stream is a bit stream in which video data or audio data is multiplexed into the MP EG 2 TS (transport stream) format. This The information regarding the clip AV stream is recorded in the file as clip information (Clip Information).
  • the grip 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 contains data (such as button image data) used for menu display. stream) Streams can be multiplexed.
  • OB stream overlay Bitmap stream
  • MB stream Media Bitmap
  • data such as button image data
  • 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 one 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 a time stamp for access to a given clip, the clip information file can be used to find address information in the clip AV stream file where data reading should start. it can.
  • a playlist consists of a specification of the AV stream file to be played, and a collection of playback start points (IN points) and playback end points (OUT points) that specify the playback locations of the specified AV stream files.
  • a set of information of the 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 that the AV stream referenced by that play item This means that a part of the video file is played back. That is, the corresponding section in the clip is played based on the IN point and OUT point information in the play item.
  • the movie object includes terminal information that links the navigation command program and the movie object.
  • the navigation program is a command (navigation command) for controlling playback of a playlist.
  • Evening Minor Information contains information to allow interactive operation on the user's player. Based on this terminal information, user operations such as menu screen recall and title search are controlled.
  • 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.
  • First Playback Title (First Playback Title), Menu Title (MenuTitle) And Movie Title # l, # 2, ... are all titles. Each title represents a link to a movie object.
  • the first play pack title is stored in the recording medium.
  • the movie corresponds to the movie company's mission video (trailer) that is projected prior to the main movie.
  • the menu title corresponds to a menu screen for selecting main content playback, chapter search, subtitles, language settings, privilege video playback, and the like.
  • the movie title is each video selected from the menu title.
  • Fig. 3 shows the relationship between the clip AV stream, clip information (Stream Attri bu tes), clip, play item, and playlist as described above. It is a UML (Unified Modeling Language) diagram.
  • a playlist is associated with one or more play items, and a play item is associated with one clip. Multiple play items with different start points and / or end points can be associated with one clip. 1 clip to 1 clip AV stream file is referenced. Similarly, 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. By defining such a structure, it is possible to specify a non-destructive playback order that plays back only an arbitrary part without changing the clip AV stream file.
  • the same clip can be referenced from multiple playlists. You can also specify multiple clips from one playlist.
  • 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 by the play item 3 2 0 of the playlist 3 1 0 and the player constituting the playlist 3 1 1 Of items 3 2 1 and 3 2 2, the section indicated by IN point and OUT point is referred to from play item 3 2 1.
  • clip 3 0 1 refers to the section indicated by IN point and UT point from play item 3 2 2 of playlist 3 1 1 and play item 3 2 3 and 3 of playlist 3 1 2 Of 2 4, the section indicated by IN point and OUT point of play item 3 2 3 is referred.
  • Files are managed hierarchically according to the directory structure.
  • one directory root directory in the example of Fig. 5
  • the range under this directory is managed by one recording and playback system.
  • the directory “BDMV '” and the directory “AVCHDTN” are placed below the root directory.
  • the directory “AVCHDTN” for example, a thumbnail file obtained by reducing the representative image of the clip to a predetermined size is placed. The data structure described with reference to Fig. 1 is stored.
  • BDMV Directly under the directory “BDMV”, only two files can be placed: the file “index, bdm v” and the file “Movi eObj ec t. Bdmv”. Further, under the directory “BDMV”, the directory “PLAYL IST”, the directory “CL IPINF”, the directory “STREAM”, and the directory “BACK UP” are placed. The directory “BACKUP” stores the backup of each directory and file.
  • the file “index, bdmv” describes the contents of the directory “BDMV”. In other words, this file “index.bdmv” corresponds to the index table in the index layer which is the top layer described above. To do.
  • the file “MovieObject.bdmv” stores information on one or more movie objects. That is, this file “MovieObie ct.bdmv” corresponds to the object layer described above.
  • the directory “PLAYLIST” is a directory in which a playlist database is placed. That is, the directory “PLAYLIST” includes a file “xxxxx.mpls” that is a file related to the playlist.
  • the file “xxxxx. Immediate Is” 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” includes a file “zzzzz.clpi” which is a clip information file for each of the clip AV stream files. In the file name, "zzzzz” before “.” (Period) is a five-digit number, and "clpi" after the period is an extension that is fixed for this type of file. .
  • the directory “STREAM” is a directory in which AV stream files as entities are placed. That is, the directory “STREAM” includes a clip AV stream file corresponding to each clip information file.
  • a clip AV stream file consists of a transport stream (hereinafter abbreviated as MPEG2 TS) of MP EG 2 (Moving Pictures Experts Group 2), and the file name is “zzzzz.m2ts”. In the file name, "zzzzz" before the period is the same as the corresponding clip information file, so that the clip information file and this clip AV The correspondence relationship with the stream file can be easily grasped.
  • thumbnail files “thumbnail.tidx” and “thumbnail tdt2” can be placed.
  • the thumbnail file “thumbnail, tidx” stores thumbnail images that have been converted into a predetermined format.
  • the thumbnail file “thumbnail.tdt2” stores unencrypted thumbnail images. For example, a thumbnail image corresponding to a clip shot by the user with a video camera is a copy-free image and is considered unnecessary to be encrypted. Therefore, it is stored in the thumbnail file “thumbnail.tdt2”.
  • 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 Typelndicator has a 32-bit data length indicating that this file is an indexable table.
  • Field TypeIndicator2 has a 32-bit data length and indicates the version of this file "index.bdmv”.
  • the field IndexesStart Address has a data length of 32 bits and indicates the start address of the block blklndexesO 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 block blkExtensionDataO is a block for storing predetermined extension data.
  • Field ExtensionDataS tartAddress is the relative number of bytes from the first byte of this file "index, bdmv”, and indicates the start address of the block MkExtensionDataO. 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 blkAppInfoBD MV0 is a block that allows content creators to write arbitrary information and does not affect the operation of the player.
  • the block blklndexesO is the actual contents of this file "index, bdmv”. Based on the contents described in this block blklndexesO, the first playback that is played when the disk is loaded in the player, and the top menu The title (movie object) to be called is specified. A playlist file (to be described later) is read based on the command described in the movie object called by the index table.
  • FIG. 7 shows a syntax representing an example structure of the block blklndexesO.
  • 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 blklndexes (). Subsequently, a block FirstPlaybackTitleO and a block MenuTiUeO are arranged.
  • the block Firs laybackTiUeO describes information about the object used in the first playback.
  • the block FirstPlaybackTitleO is fixed following the area reserved having a data length of 1 bit. “Fixed value” is described. 3 Further, a fixed value “ ⁇ ” is described through an area “res erved” having a data length of 1 bit.
  • a field FirstPlaybackTitleMobjIDRef having a data length of 16 bits is arranged through an area reserved having a data length of 14 bits. This field F FirstPlaybackTitleMobjIDRef indicates the ID of the movie object used in the first playback title.
  • the movie object ID is indicated by the value m obj-id used as a loop variable in the movie object's for loop statement based on the syntax of the movie object described later with reference to FIGS. 8 and 9, for example. It is.
  • the field FirstPlaybackTitleMobj IDRef stores the value mob] '— id corresponding to the movie object to be referenced.
  • FirstPlaybackTitleMobj IDRef in the block Firs tPlaybackTitle 0 in the block blklndexesO may point to a movie object in the top menu or a title.
  • the block MenuT i U e 0 describes information about the object used in the top menu.
  • 'fixed value' ⁇ is described following 'reserved area with 1-bit data length. 3 Furthermore, fixed through area reserved with 1-bit data length'. The value " ⁇ " is described.
  • a field MenuTitleMobjl DRef having a data length of 16 bits is arranged through an area reserved having a data length of 14 bits.
  • Field MenuTiUeMobjlDRef indicates the ID of the movie object used in the menu title.
  • Block Next field of MenuTitleO NumberOfTitles 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] () is described with the value title—id as an argument as many times as indicated in this field NumberOfTitles.
  • the block MovieTitle [title—id] 0 describes information for each title.
  • Value title—id is a numeric value from “0” to the value indicated by the field NumberOf Titles, and identifies the title.
  • a fixed value “1” is described through an area reserved having a data length of 1 bit, and further, through an area reserved having a data length of 46 bits.
  • the field MovieTitle MobjlDRef is described.
  • Field MovieTitleMobj IDRef has a data length of 16 bits and indicates the ID of the movie object used in this title.
  • An area reserved having a data length of 32 bits is arranged after the field MovieTitleMobj IDRef.
  • 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 defined in ISO (International Organization for Standardization) 646 is described.
  • the field type—indicatior contains the four-character string “ ⁇ 0 ⁇ encoded in the default format in IS ⁇ 646, and this file is the file“ MovieOb ject.bdmv ”. Indicated.
  • Field TypeIndicator2 has a data length of 32 bits (4 bytes) and indicates the version number of this file “MovieObject.bdmv”.
  • the field TypeIndicator2 is a 4-character string encoded using the encoding method defined in ISO 646. Must be "0100”.
  • the field ExtensionDataStartAddress has a data length of 32 bits and indicates the start address of block 1] 11 ⁇ 611310110 () 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 ExtensionDataStartAddr ess is "0", it indicates that the block b 1 kEx t ens i onDa t a () does not exist in this file "MovieObject.bdmv".
  • the field padding_word in the syntax shown in FIG. 8 has a data length of 16 pits, and is inserted in the for loop statement by the number of times indicated by the value N1 or value 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.
  • the field padding-word can be any value.
  • an area reserved having a data length of 2 24 bits is arranged, and next, a block lkMovieObjec ts 0 which is the main body of this file “MovieObject. Bdiv” is stored.
  • FIG. 9 shows a syntax representing an example of the structure of the block MkMovieObjectsO.
  • 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
  • a field NumberOfMobjs is arranged through an area “reser rved” having a data length of 2 bits.
  • the field Numbe rOfMobjs indicates the number of movie objects stored according to the immediately following for loop statement.
  • a value used as a loop variable in a for loop statement]]]] obj—id uniquely identifies a movie object.
  • Value mobj— id is a value starting from "0", and movie object is described in the for loop statement. Defined by the order in which
  • the block TerminallnfoO in the for loop statement is described with a fixed value “1” and then 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 NumberOfNavigationCommands [mobj—id] represents the number of navigation commands included in the movie object MovieObject [mobj—id] () pointed to by the value mobj—id.
  • 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 has a data length of 32 bits (4 bytes) and indicates the version of this playlist file.
  • the field PlayListStartAddress has a data length of 32 bits and indicates the start address of the block blkPlayListO in this syntax.
  • Field PlayListMarkStartAddress is a 32-bit data And indicates the start address of the block MkPlayListMarkO 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 pite 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 “b 1 kExtension on Data a 0” does not exist in this file “xxxxx.mpls”.
  • Block bl kAppInfoPlayList 0 is arranged through area reserved having a data length of 60 bits.
  • the block blkAppInfoPlayList 0 describes information such as the type of play list described in the next block blkPlayListO 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 blkExtension_data_a 0 is a block for storing a predetermined extension data.
  • the field padding_word in the syntax shown in Fig. 10 has a data length of 16 bits. According to the syntax of this file "xxxxx.mpls", the value Nl, value N2, and value N3 Only the number of times indicated by is inserted. The value Nl, value N2 or value N3 is 0 or any positive integer.
  • the field padding_word can be any value.
  • FIG. 11 shows a syntax representing an example of the structure of the block MkPlayListO.
  • the field Length has a data length of 32 pits. The data from immediately after this field Length to the end of the block blkPlayListO —Indicates evening. Following the field Length, an area “reserved” having a data length of 16 bits is arranged, and then a field “NumberOfPlaysystems” is arranged.
  • a field NumberOfPlayltems has a data length of 16 bits, and indicates the number of play items included in the block blkPlayList 0.
  • a field NumberOfSubPath indicates the number of sub paths included in this block blkPlayList 0.
  • blocks b 1 kP 1 ay 11 em 0 in which play items are described are described by the number indicated in the field NumberOfPlayltems.
  • the count based on the for loop statement is the identifier Playltem-id of the block blkPlayltemO.
  • the block b 1 kSubPat h 0 is described in the number indicated by the field Number 0 f SubPat h.
  • 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.
  • the field Length has a data length of 16 bits, and indicates the data length from immediately after this field Length to the end of the block blkPlayltemO.
  • Field ClipInformationFileName [0] 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, it is indicated by the field ClipInformationFileName [0]. Clip information file with the same file name is read
  • Field ClipCodecIdentifier [0] has a data length of 32 bits (4 bytes) and indicates the codec system of the clip AV stream used in the play item by this block blkPyltemO.
  • Field CoimectionCondition [4, which has a data length of 4 bits, indicates information on the connection status between clips. For recording media for recording purposes, "1”, “5" or “6” is used as the value of the field ConnectionCondition.
  • the field ConnectionCondition value is “1”, indicating that the clip and the next clip are not connected seamlessly.
  • the field ConnectionCondition value is “5” or “6”. Indicates a seamless connection. Note that 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 is made longer than the recording length of the video data in the clip referenced by the play item (see FIG. 13A).
  • the fade-out process can be performed overnight.
  • 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 or shorter than 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 a clip is closed based on a reason other than recording stop according to a user operation, for example, a system factor.
  • the connection method of clips whose field CoimecUonCondiUon value is “6” is referred to as second seamless connection.
  • the field RefToSTCID [0] has an 8-bit data length and indicates information related to discontinuities in the system time base (STC).
  • Field INTime and Field OUTTime each have a data length of 32 bits and indicate the playback range of the main clip AV stream.
  • Field INTime indicates the start point (IN point) and field OUTTime indicates the end point (OUT point).
  • Block MkUOMaskTableO is a table where user input acceptance restrictions are set.
  • the flag PlayltemRandom AccessFlag with 1-bit data is used as a play item by this block blkPlayltemO. Whether to allow or not.
  • the field StillMode is arranged through the area reserved having the data length of the base.
  • the field StillMode has a data length of 8 bits 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 SU11Mode is "0x01" (binary), the still time is indicated by the field StillTinie having a data length of 16 pits based on the if statement. If the value of field StillMode is other than "0x01", the area having the 16-bit data length is reserved for word alignment. The area is reserved.
  • the block blkSTNTableO manages the clip AV stream attributes, PID numbers, recording positions on the recording medium, etc. managed by the play item of this block blkPlayLtemO.
  • FIG. 14 shows a syntax representing an example of the structure of the block blkPlayListMarkO.
  • Field Length has a 32-bit data length, and indicates the data length from immediately after this field Length to the end of block blkPlayListMarkO.
  • Field ⁇ 11111 ⁇ 1 1 0 1 & 1 ⁇ 313 ⁇ 4 ⁇ 3 has a data length of 16 bits and indicates the number of playlist marks included in this block blkPlayListMarkO. According to the following for loop statement, information of the playlist mark is described in the number indicated by the field NumberOfPlayListMarks.
  • the field MarkType is placed after the area reserve having an 8-bit data length.
  • Field MarkType has an 8-bit data length and indicates the mark type.
  • the field RefToPlayltemID has a data length of 16 bits and describes identification information P 1 ay 11 en and id that refer to the play item to be marked.
  • the field MarkTimeStamp has a data length of 32 bits and describes a time stamp indicating the point where the mark is to be placed.
  • Field EntryESP ID has a 16-bit data length 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 clock. If the value stored in this field Duration is "0", this field Duration does not make sense.
  • Figure 15 shows the structure of an example clip information file. Indicates the syntax to represent.
  • 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 blkProgramlnfo 0, a block blkCPI 0, a block blkClipMarkO and a block blkExtensionData (), each with a data length of 32 bits
  • the field SequencelnfoStart Address, the field ProgramInfoStartAddress, the field CPIStartAddress, the field CI ipMarkSta Address, and the field ExtensionDataStartAddress indicate the start address of the corresponding block.
  • 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 blkSequencelnfoO describes information that manages a sequence of 3 consecutive strings (: nya 1? 0 (arrival time base) as a group.)
  • the block blkProgramlnfoO contains this clip-in. Information such as the encoding method of the clip AV stream managed in the format file and the aspect ratio of the video data in the clip AV stream is described.
  • the block blkCPlO 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 MkExtensionDa O is an area where extension data can be stored. Since the block blkClipMarkO and the block blkExtensionData 0 in the clip information file are not related to the present invention, detailed description thereof is omitted.
  • Figure 16 shows a block! ) Indicates a syntax that represents an example of the structure of lkClipInfoO.
  • 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 blkClipInfoO.
  • 1 Field ClipStreamType is arranged through an area reserved having a 6-bit data length.
  • Field ClipStreamType has a data length of 8 bits and represents the type of clip AV stream.
  • the value of this field ClipStreamType is fixed to eg "1".
  • the field ApplicationType has a data length of 8 pits and indicates how the clip AV stream (file with the extension “m2 tsj”) is created.
  • the value of the field ApplicationType is “1”.
  • the corresponding clip AV stream is played back as a normal movie, followed by an area reserved with 3 1-bit data length.
  • the flag IsCC5 with a 1-bit data length is set between the corresponding clip and the next clip by blkPUyltemO in the playlist. Indicates whether or not the connection is made by the first seamless connection described above, that is, the method in which the value of the field Coimec UonCondition is “5”. 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 TSRecordingRate represents the recording rate of the clip A V stream file in bytes / second.
  • a field NumberOf SourcePackets represents the number of buckets included in the clip AV stream.
  • a block TSTypelnfoBlockO is arranged through a re-served area of 1024 bits reserved by the system.
  • the block TST ypelnfoBiockO stores information indicating the type of packet in which the clip A V stream is stored. Since this block TSTypelnfoBlockO has little relation to the present invention, a detailed explanation is omitted.
  • the field followingClipStreamType has a data length of 8 pits and is placed next to the clip corresponding to this clip information file. The type of clip is described.
  • the field Fol lowingClipInformationFile Name is arranged through an area reserved having an 8-bit data length.
  • the field name of the clip information file corresponding to the clip next to the clip corresponding to this clip information file has a data length of 40 pixels (5 bytes). Is done.
  • the next field, ClipCo decldentifier has a data length of 32 bits (4 bytes)
  • the encoding method of the next clip is shown.
  • the field ClipCode cldentiiier is fixed to the 4-character string value "M2TS" encoded in the default manner to IS 0646. Next, an area reserved having an 8-bit data length is allocated.
  • FIG. 17 shows a syntax representing an example of the structure of the block MkSequencelnfoO.
  • 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 MkSequencelnfo 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 next field SPNATCStart has a data length of 32 bits and represents the start of a sequence (referred to as the sequence ATCSequence) indicating that it was recorded at a continuous time by the packet number.
  • the value is set to "0" to match the beginning of the clip AV stream file
  • the field NumberOfSTCSequence represents the number of the sequence STCSequence on the sequence ATCSequence
  • the field NumberOfSTCSequence has the value "1" It is said above.
  • the sequence STCSequence represents a continuous range of PCR (Program Clock Reference), which is a time axis reference in MP EG 2 TS (Transport Stream).
  • the sequence STCSequence is assigned a unique number STC_id within the clip.
  • STC_id a continuous time axis without discontinuities can be defined, so that the start time and end time of play items can be uniquely determined. In other words, the start point and end point of each play item must be in the same sequence STCSequence.
  • the value stc id STCSequence is specified.
  • Field PCRPIDCstc—id] has a data length of 16 bits and represents the PID of a TS bucket including PCR (Program Clock Reference) in MPEG2TS.
  • the field SPNSTCS rUstc—id] has a data length of 32 bits and represents the start of the sequence STCSequence with a packet number.
  • the field PresentationStartTime and the field PresentationEndTime each have a 32-bit data length and represent a valid range in the clip AV stream.
  • Field Presen tationS rtTime and field? 361 ⁇ & 011811 The range indicated by 31 11 ⁇ is the range that can be referenced from the play item.
  • FIG. 18 shows a syntax representing an example 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 blkProgramlnfoO. 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.
  • Field SPNProgramSequenceSart has a data length of 32 bits and describes the number of the source packet at which the program sequence starts in the corresponding clip AV stream file.
  • Field ProgramMapPID has a 16-bit data length and indicates the value of the PID of the TS packet that is supposed to contain the program map section applicable to the program sequence.
  • Field NumberOfStreamsInPS has a data length of 8 bits and indicates the number of elementary lists defined in the program sequence. Following the field NumberOfStream slnPS, an area reserved having an 8-bit data length is arranged.
  • the value [stream—index] A field Strea mP ID [stream one index] and a block blkStreamCoding info (stream—index) are stored for the number indicated in the field NumberOfStreamsInPS.
  • Field StreamPID [stream one index] indicates the value of PID corresponding to the elementary stream described in PMT (Program Map Table) referenced by the program sequence.
  • the next block blkStreamCodinglnfo (stream—index) describes information about the encoding method of the elementary stream indicated by the corresponding field StreamPID [stream_index].
  • Figure 19 shows the syntax for an example structure of the block blkCPlO.
  • CP Consumer Point Information
  • CP Consumer Point Information
  • the CPI is a table of information indicating the start position of the decoding unit.
  • the start position of the decode unit (in this example, the start position of the GOP) stored in the CP I is referred to as an EP (Entry Point) entry.
  • field Length has a data length of 32 bits, from immediately after this field Length to the end of block blkCPlO. Shows the long evening.
  • 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 MkEPMapO stores a table for associating PTS values and byte addresses in the corresponding clip AV stream file.
  • FIG. 20 shows a syntax representing an example of the structure of the block MkEPMapO.
  • a field NumberOfStreamPIDEntries is arranged through an area reserved having an 8-bit data length.
  • Field HNumberOf StreamPI DEntries has an 8-bit data length and indicates the number of entries of block MkEPMapForOneStreamPID in block MkEPMap 0.
  • the value [k] is set as a loop variable, and the information related to the entity re-entry is described for the number indicated in the field NumberOfStreamPID Entries.
  • field StreamPIDDt has a data length of 16 bits, and is the block MkEPMapForOneStreamPID (hereinafter referred to as the [k] -th block bl kEPMapForOneStreamPID) that is the [k] -th entry in block MkEPMapO. ) Indicates the PID value of the transport bucket that carries the elementary stream referenced by.
  • a field EP StreamType [k] is arranged through an area reserved having a data length of 10 bits.
  • the field EPStreamType [k] has a data length of 4 bits and indicates the type of elementary stream referenced by the [k] -th block blkEPMapForOneStreamPID.
  • the field NumberOfEPCoarseEntries [k] has a data length of 16 bits and is a coarse search support in the [k] th block blkEPMapForOneStreamPID. Indicates the number of entries in the table (EP coarse table).
  • Field Numbe rOfEPFineEntries [k] has a data length of 18 bits and indicates the number of entries in the sub table (EP fine table) for fine search in the [k] -th block blkEPMapForOneStreamPID. .
  • the field EMapForOneStreamPIDStartAddress [k] has a data length of 32 bits and indicates the relative byte position where the [k] -th block blkEPMapForOneStreamPID starts in the block blkEPMap 0. This value is indicated by the number of bytes from the first byte of block blkEPMapO.
  • the value [k] is set as a loop variable in the field NumberOfStreamPIDEntries according to the for loop statement described with a padding field having a data length that is an integer multiple of 16 bits.
  • the number of blocks blkEPMapForOneStreamPID (EPStreamType [k], NumberOfEPCoarseEntries [k], NumberOfEPFineEntries [k]) is stored. That is, the argument NumberOfEPCoarseEntries [k] indicates the number of entries PTSEPCoarse and entries SMEPCoarse stored in the subtable (EP coarse table).
  • the argument NumberOfEPFineEntries [k] indicates the number of entry PTSEPFine and entry SMEPFine 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. 21 shows a syntax representing an example of the structure of a block blkEPMapForOneStreamPID (EP-stream-type, Nc, Nf).
  • EP_stream_type, Nc, Nf the entry PTS EPStart and the entry that is the source of the data stored in the block blkEPMapForOneStreamPID
  • the meaning of the entry SPNEPStart is explained.
  • 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 PTSEPStar t.
  • the entry SMEPFine and the entry SPNEPCoarse associated with the entry SPNEPFine are derived from the same entry SPNEPStart.
  • Figure 22 shows an example format of the entry PTSEPCoarse and the entry PTSEPFine.
  • PTS ie, entry PTSEPS rt is a straight line of 33 pits.
  • the entry PTSEPCoarse used when searching in rough units in the example of Fig. 22 is the 3rd bit of the entry PTSEPStart. 14 bits from 2 bits to 19th bit are used.
  • the entry PTSEPFine for more precise search uses the 11th bit of entry PTSEPStart and the 11th bit up to the 9th bit.
  • entry PTSE PFine With the entry PTSE PFine, it is possible to search within a resolution of 5.7 milliseconds and up to 11.5 seconds.
  • the 19th bit is used in common by entry PTSEPCoarse and entry PTSEPFine. Also, the 9 pits from the 0th bit to the 8th bit on the LSB side are not used.
  • Figure 23 shows an example format of the entry SPNEPCoarse and entry SPNEPFine.
  • the source bucket number ie the entry SPNEPStart
  • the MSB bit is the 31st bit
  • the LSB bit is the 0th bit
  • the example shown in Fig. 23 shows the entry SPNE used when searching in rough units.
  • PCoarse uses all bits from the 31st bit to the 0th bit of the entry SPNEPStart.
  • 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, for example, searching is possible within a range up to approximately 25 MB (Mega Byte) AV stream file.
  • the entry SPNEPCoarse uses 17 bits from the 31st bit to the 16th bit of the entry SPNEPStart, and the entry SPNEPFine uses 17 bits from the 16th bit to the 0th bit of the entry SPNEPStart.
  • entry PTSEPStart is an unsigned integer with a data length of 33 bits and is a picture that can be randomly accessed in an AV stream (for example, IDR (Instantaneous Decoding Refres h) picture Or I (Intra) picture) indicates a 33-bit PTS of video access unit.
  • Entry SPNEPStart is an unsigned integer of 3 bits, as shown in Figure 23. It is the entry PTSEPStarU in the AV stream of the source bucket including the first byte of the associated video packet unit. Indicates the address at.
  • the entry SPNEPStart is expressed in units of source packet number, 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 blkEPMapForOneStreamP ID (EP—stream—type, Nc, Nf) describes the sub table (EP coarse table) for searching in rough units by the first for loop statement. Then, the second for loop statement describes the 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 EPFineTableS rtAddress is placed immediately before the first for loop statement.
  • the field EPFineTableStartAddress 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 block blk EPMapForOneStreamPID (EP_stream_type, Nc, This is indicated by the relative number of bytes from the first byte of Nf). The relative number of bytes starts with the value "0".
  • the first for loop statement is repeated up to the number Nc of entries in the sub table (EP coarse table) with the loop variable [i].
  • the field RefToEPFineID [i] and the entry PTSEPCoarse [ i] and the entry PTSEPFine [i] are stored.
  • the field RefToEPFineID [i] has a length of 18 pits, and the entry PTSEPCoarse indicated by the field PTSEPCoarse [i] following the field HRefToEPFinelDti] Indicates the entry number in the subtable (EP fine table).
  • the entry PTSEPFine and the entry PTSEPCoarse associated with this entry PTSEPFine are derived from the same entry PTSEPStart.
  • the field Ref ToEPFinelD [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 the loop variable [EP — Fine_id] is repeated up to the number of entries Nf in the subtable (EP fine table), and the field ReservedEPFine [EP—fine-id], which has a data length of 1 bit, is equal to the number of entries Nf.
  • Field IEndPositionOffset [EP_fine—id] with 1 bit length, field PTSEPFineDEP—fine—id with 1 bit length, and field SPNEPFine [EP_nne_id] with 17 bit length And are stored.
  • the field PTSEPFine [EP—fine—id] and the field SPNEPFine [EP_fine—id] are entries PTSEPFine and entries referenced from the sub table (EP fine table) based on the loop variable [EP—fine—id]. Each SPNEPFine is stored.
  • Entry PTSEPCoarse and entry PTSEPFine, and entry SPNEPCoarse and entry SPNEPFine are derived as follows. Assume that there are Nf entries in the subtable (EP fine table) arranged in ascending order of the value of the related data SPNEPStart. Each entry 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 11 --(1)
  • PTSEPCoarse [i] (PTSEPStart [RefToEPFinelD [i]] ⁇ 1 9) / 2 14. ⁇ (2)
  • PTSEPFine [RefToEPFineID [i]] (PTSEPStart [RefToEPFineID [i]] »9) / 2" ⁇ ⁇ (3)
  • SPNEPFine [EP_fine_id] SPNEPStart [EP_fine_id] / 2 17 ⁇ ⁇ (4)
  • SPNEPCoarse [i] SPNEPStart [RefToEPFineID [i]] ⁇ ⁇ (5)
  • the symbol “>> x” means that bits are used from the digit exceeding the X bit from the LSB side.
  • This block blkExtensionDataO for storing extension data will be described.
  • This block blkExtensionDataO is defined so as to be able to store a predetermined extension data.
  • FIG. 24 shows a syntax representing 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 blkExtensionData 0. If the data length indicated by this field Length is not "0", the description following the if statement is made.
  • a field NumberOfExtDa Entries is arranged through an area reserved having a 24-bit data length.
  • the field HNumberOfExtDataEntry has an 8-bit data length and indicates the number of extension entries stored in the block DataBlockO of this block blkExtensionDataO.
  • the extension data entry stores information for acquiring the main body of the extension data.
  • the extension data entry is a block ext_data_entry () consisting of field ExDataType.
  • the field ExtDataType has a data length of 16 bits and represents that the extension data described in this block blkExtensionDataO is extension data for the recording device.
  • the value of this field ExtDataType is the first value that identifies the extension data, and can be defined as assigned by the licensor of the standard that includes this block blkExtensionData 0.
  • the field ExtDataVersion is a second value that identifies the extension data and can be defined to represent the purge number of this extension data. In this block blkExtensionDataO, there should be no more than two blocks ext_data—entryO with the same field ExtDataType and field ExtDataVersion values.
  • the field ExtDataStartAddress has a data length of 32 bits, and the extension data start address corresponding to the extension data entry (block ex data—entry 0) that includes this field ExtDataStartAddress. Show less.
  • 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 ex and data_entries O) containing this field ExtDataStartAddress.
  • the data length is indicated in bytes.
  • each field has a 6-bit data length and consists of an arbitrary data string. Is repeated any number of times L 1 with 2 fields as a set.
  • the block DataBlockO where the main body of the extended data is stored is described.
  • the block DataBlockO stores one or more extended data. Each extension data ex and data is extracted from the block DataBlockOcO based on the above-described field ExtData startAddress field ExtDataLength.
  • Fig. 25 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 blkExtensionDaO.
  • the field DataBlockStartAddress indicates the start position of the block DataBlock ().
  • the number of blocks indicated by the number indicated in the field NumberOfExtDataEntries is ex and data_entry is described.
  • a field padding_word with an arbitrary length is placed between the last block ext—data—entry and the block DataBlockO.
  • the extended data ex t-data indicated by the block ex data-entry 0 is placed.
  • each extension data ex and data are indicated by the field ExtDataStartAddress and field ExtDataLength in the corresponding block ext_data_entry (). Therefore, the arrangement order of the extension data ex and dat a in the block DataBlockO does not need to match the arrangement order of the corresponding block ex t_data_entry ().
  • FIG. 26 is a flowchart showing an example of processing when data is written to the block blkExtensionDataO.
  • Fig. 26 shows an example of rewriting block blkExtensionDataO by adding extension data as the (n + 1) th entry in block blkExtensionDataO.
  • step S10 the length of the extended data to be written is obtained and set to the value of the field ExtDa Length [n + l]. Note that the description “[n + l]” corresponds to the number of the (n + 1) th entry.
  • step S11 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 DataBlockOcO is obtained.
  • step S 1 2 the field ExtDataLen that is the data length of the extended data to be written in the block DataBlockO 07059345 It is determined whether or not there is a continuous free space equal to or longer than the data length indicated by gth [n + l]. 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 field Length value in the block blkExtensionDataO. Then, a continuous free space equal to or 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 extended data is written is determined, and the value of the start address is set to the field ExtDataStartAddress [n + l].
  • step S15 the extension data ext_data [n + l] having the length of the field ExtDa Length [n + l] set in the above step S 10 is written from the field ExiDataStartAddress [n + 1].
  • step S 16 When the data writing is completed, in step S 16, a field ExtDataLength [n + 1] and a field ExtDa StartAddress i + 1] are added to the block ext—data—entryO.
  • step S13 expansion of the block blkExtensionDataO by changing the value of the field Length is left to the system, and the system performs memory allocation appropriately.
  • FIG. 27 is a flowchart showing an example of processing when extension data is read from the block blkExtensionDataO. Note that the processing according to the flowchart in Fig. 27 consists of a read-only recording medium and recordable media. The present invention can be applied to both recording media.
  • the value of the field ExtDataType is obtained from the standard to which the extended data to be read conforms.
  • the field ExtDataVersion is set from the type of the extended data to be read. Get the value.
  • the blocks ex and data_entry () 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_entry () are the same as the field ExtD a Type and field acquired in step S 20 and step S 21 described above. It is determined whether it matches the value of ExtDataVersion.
  • step S 26 it is determined whether or not all the blocks ex_data_entry () listed in the block blkExtensionDataO have 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 blkExtensionDataO. 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 2 3 If it is determined in step S 2 3 described above that the values of the field ExtDataType and the field ExtDataVersion included in the block ex and data_entry () match the values of the acquired field ExtDataType and field ExtDataVersion, the process proceeds to step S. Migrated to 24. Here, it is assumed that the [i] -th entry in block blkExtensionDataO matches.
  • step S24 block [i] -th entry ext— data— entr Read the y () force, the value of the field ExtDataLength [i] and the value of the field ExtDataStar tAddress [i]. Then, in step S 25, data is read from the address indicated by field ExtDa StartAddress [i] read in step S 24 by the data length indicated by field ExtDa Length [i].
  • index file “index.bdmv”
  • movie object file “MovieObject.bdmv”
  • playlist file xxx xx.mpls
  • clip file zzzzz. Clpi
  • FIG. 28 shows a syntax that describes an example of the structure of a block DataBlockO (see FIG. 24) in the field blkExtensionDataO in the file “index.bdmv” for describing the playlist attribute.
  • the block DataBlockO is described as the block blklndexExtensionDaO.
  • the field ExtDataType is set to the value “0x1000”, and the field ExtDataVersion is set to the value “0x0100”.
  • the values described in these field ExtDa Type and 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.
  • Block blk in the area indicated by field ExtDataStartAdd ress and field ExtDa Length in block DataBlockO Stores IndexExtensionDataO.
  • "Ox" indicates that the numerical value is expressed in 1 hex.
  • the field Typelndicator describes the type of the following data, and describes a character string consisting of 4 characters encoded using the encoding method specified in ISO 646.
  • the field Typelndicator describes the 4-character string "IDEX” encoded in the default format in ISO 646, and the subsequent data type is "IndexExtensionData”. Is shown.
  • an area reserved having a data length of 32 bits is arranged, and then a field TableOfPlayListStartAddress having a data length of 32 bits is arranged.
  • the field Table OfPlayListStartAddress indicates the start address of the block blkTableOfPlayList 0 with reference to the head of this block blklndexExtensionDataO.
  • Block MkUIAppInfoAVCHD 0 is allocated through an area reserved having a bit length. 1 Padding word having a data length of 6 bits padding—The word is repeated as many times as indicated by the value N1, and then the block blkTab leOfPlayListsO is arranged.
  • the padding word “padding_word” having a data length of 16 bits is repeated as many times as indicated by the value N2, and then the block MkMakersPrivateDataO is arranged. After this block blkMakersPrivateDataO, a paddy word with a data length of 16 bits padding—word is repeated as many times as indicated by the value N3. It is.
  • block blkUIAppInfoAVCHDO and the block blkMakersPrivateDataO are not related to the present invention and will not be described.
  • FIG. 29 shows a syntax representing a structure example of the block blkTableOfPIayListsO 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 blkTableOfPlayListO.
  • Field LengtM This is followed by a block MkFirstPlaybackTitlePlayListsO in which information on the playlist for playing back the playback title is described, and a block blkMenTitlePlayListsO in which information on the menu title is described.
  • These block blkFirstPlaybackTitlePlayListsO and block MkMenuTUlePyListsO are not related to the present invention, so the description is omitted.
  • a field NumberOfTitlePrayListPair 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.
  • the block blkMovieTitlePlayLisiPairO is described in the number indicated by the field NumberOfTitlePlayListPair.
  • the block blkMovieTi UeP layListPairO includes a field PlayListFileName, a field PyListAttribute, and a field RefToTitlelD.
  • the block blkMovieT'itlePlayListPairO is the [i] -th playlist indicated in this for loop sentence, the file name of the playlist, the attribute assigned to the playlist, and the reference of the playlist This is a structured piece of information about a playlist ⁇ ⁇ consisting of a title ID.
  • the order of the for loop statements is the recording order. Ie 1 When the playlist is added, the value of the field NumberOfTitleP yListP air is incremented by 1, and the added playlist information is added after the existing playlist information.
  • the field PlayListFileName has a data length of 40 bits (5 kn), and the file name of the play list is described by being encoded by the encoding method defined in ISO 646.
  • a field PlayListAttribute is arranged through an area reserved having a 6-bit data length.
  • the field PlayListAttribute has a 2-pit length and indicates the attribute assigned to the play list.
  • 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. There are three types: the second type and the third type used to play the menu. Each playlist has a corresponding attribute “Real” (first) according to the type of playlist.
  • Attribute “Virtua 1” (second type) and attribute “Menu” (third type) are added.
  • playlists with the attribute “Real” are appropriately played in real play.
  • a playlist ⁇ ⁇ with the list and attribute “Virtual” is called a virtual playlist, and a playlist with the attribute “Menuj” is called a menu playlist.
  • the ID (number) of the title to which the play list indicated in the field PlayListFileName in the same loop belongs is described.
  • the corresponding value title-id in the block blklndexesO in the index file "index.bdmv” is described.
  • the playlist is the first playback
  • the value of the field RefToTitleld is the first fixed value, eg "OxFFFF”.
  • the value of the field RefToTiUe Id is a second fixed value, for example, “OxFFFE”.
  • the virtual player When a disc having a data structure as described above is loaded into the player, the player can use commands written in a movie object read from the disc to control the hardware inside the player. Must be converted to a specific command.
  • the player stores in advance software for performing such conversion 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 AVCHD format.
  • FIG. 30A and FIG. 30B schematically show the operation of this virtual player.
  • Fig. 30A shows an example of the operation during disk loading.
  • the register setting that stores the shared parameters used in the disc of 1 is initialized (step S). 3 1).
  • the program described in the movie object is read from the disc and executed.
  • Initial access means that the disc is played for the first time as when the disc is loaded.
  • FIG. 30B 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 stop state.
  • the user gives an instruction to play using, for example, a remote control commander (UO: User Ope). ration).
  • UO User Ope
  • ration When the reproduction is instructed, first, the registration evening, 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 explained using Fig. 31.
  • 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.
  • the program described in movie object # 1 consists of two lines. If the command on the first line is "Play PlayList (1)", the player will play list # 1. Start playing. Play list # 1 is made up of one or more play items, and the play items are played in sequence. When 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 "] 'unip MenuTitle", and this command is executed and the movie title that realizes the menu title (MenuTitle) described in the index table is displayed. The execution of the object is started.
  • the video signal recording start to recording end is defined as one recording unit, and the video stream generated in the one recording unit section is recorded on the recording medium as one stream file.
  • This strike 2007/059345 A stream file can contain audio signals that are recorded as video signals are recorded.
  • a clip is composed based on the stream file corresponding to one recording unit.
  • one clip is referred to from one play item, and each time a clip is generated, the play item referring to the generated clip is sequentially added to the playlist. To add. At this time, in the playlist, a playlist mark is placed for each play item, that is, for each clip. For example, only one playlist exists on one recording medium. However, the present invention is not limited to this, and a plurality of playlists may exist on the disc.
  • FIG. 32 schematically shows an example of the configuration of a recording apparatus applicable to the embodiment of the present invention.
  • This recording apparatus records an AV stream obtained by compressing and multiplexing input digital video data and digital audio data by a predetermined method on a recording medium.
  • a compression encoding and multiplexing method for example, the above-mentioned AVVCHD format can be applied.
  • the recording device illustrated in FIG. 32 can be used as a single recording device that records video data and audio data input from the outside on a recording medium, an optical system, an image sensor, etc. It can also be used as a recording block for a video power camera device that records video data based on the captured image signal on a recording medium in combination with a camera block equipped with the
  • Various compression coding and multiplexing methods can be considered.
  • a method defined in H. 2 6 4 IAVC 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 MPEG 2 system.
  • MP EG 2 Systems can be applied as the multiplexing method.
  • compression encoding of video data is performed in accordance with the method specified in H. 2 64 I AVC, and multiplexing of video data and audio data is performed in accordance with the method specified in MP EG 2 Systems.
  • the control unit 30 has power (not shown) such as a CPU (Central Processing Unit), a RAM (Random Access Memory), and a ROM (Read Only Memory), and is based on programs and data stored in advance in the ROM.
  • the RAM is used as a work memory to control each unit of the recording unit 1 0 of this recording apparatus. Note that the paths connecting the control unit 10 and each unit of the recording unit 10 are omitted in FIG. 32 in order to avoid complexity.
  • a UI (User Interface) unit 31 is provided with a predetermined operation element for the user to operate the operation of the recording apparatus, and outputs a control signal corresponding to the operation on the operation 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 a program based on a control signal supplied from the UI unit 31 in response to a user operation. For example, in response to an operation performed on the UI unit 31, the control unit 30 controls the start and stop operations of the recording operation by the recording device.
  • Baseband digital video data is input from terminal 40
  • baseband digital audio 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.
  • in-frame compression is performed using DCT (Discrete Cosine Transform) and intra-frame prediction
  • inter-frame compression using motion vectors is performed
  • entropy coding is further performed for compression.
  • MUX multiplexer
  • ES elementary stream
  • the digital audio data is input from the terminal 41 to the recording unit 10 and supplied to the audio encoder 12.
  • the audio encoder 12 is compression-encoded by a predetermined compression encoding method, for example, AAC (Advanced Audio Coding).
  • AAC Advanced Audio Coding
  • the compression encoding method for audio data is not limited to AAC. It is also possible to use the audio data as it is without compressing and encoding the baseband 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 MPEG-2 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 into packets of a predetermined size, added with headers, and packetized (PES CPacketized Elementary Sir eam).
  • compressed audio data is divided into predetermined sizes, and headers are added to form PES packets.
  • PES packet In the header Is stored with predetermined information defined in MP EG 2 systems such as PTS indicating decoding time stored in the packet and DTS (Decoding Time Stanp) indicating decoding time.
  • the PES 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 the multiplexer 13 is temporarily stored in the stream buffer 14.
  • the TS packet is actually output with a header of a predetermined size added by the multiplexer 13.
  • This bucket with a predetermined header added to the TS bucket is called a source bucket IV.
  • the recording control unit 15 controls data recording on the recording medium 20.
  • the recording medium 20 for example, a recordable type 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 data for the recording unit of the recording medium 20 is stored from the stream buffer 14. Read and write to recording medium 20.
  • the management information processing unit 16 includes, for example, a CPU, a RAM as a work 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 may be, for example, a control unit. It is also possible to realize the functions of the management information processing unit 16 by program processing at 30. In this case, for example, the RAM of 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, the index file “index, b dmv”, the movie object file “MovieObject.bdmv”, the playlist Generate information to be stored in the file “xxxxx.mpls” and the clip information file “zzzzz.clpi”. The generated information is written to the recording medium 20 at a predetermined timing.
  • the management information processing unit 16 acquires time information of recording data from the multiplexer 13, acquires address information of the recording data 20 from the recording control unit 15, and acquires these time information. EP-map information is generated based on the information and address information. Further, based on the control signal output from the control unit 30 in response to the recording start and recording end operations on the UI unit 31 and information on the recording data from the multiplexer 13 and the recording control unit 15, the playlist file is displayed. The file “xxxxx.mpls" is generated or updated, and the clip information file "zzzzz.clpi” is generated. In addition, when a new recording is performed on the recording medium 20, the index file “index, b dmv” or movie object file “3 ⁇ 410 ⁇ 601)] 6 ( ⁇ (111 ⁇ ” is generated or updated. Is called.
  • FIG. 33 is a flowchart showing a recording method of an example of a clip according to the embodiment of the present invention.
  • the recording medium 20 Prior to processing according to this flow chart, the recording medium 20 includes a clip and the clip.
  • Files that contain playback control information for playback such as clip information files, playlist files, movie object files, and index files, are already recorded on the recording medium 20
  • playback control information for playback such as clip information files, playlist files, movie object files, and index files
  • step S 50 When a recording start operation is performed in step S 50, recording of the clip AV stream to the recording medium 20 is started in the next step S 51.
  • the recording start operation is performed as follows, for example.
  • the UI unit 3 1 is provided with a recording start switch for instructing recording start and a recording stop switch for instructing recording stop.
  • the recording start switch is operated by the user.
  • a control signal instructing the start of recording is output from the UI unit 31 and supplied to the control unit 30.
  • the control unit 30 Based on the control signal for instructing the start of recording, the control unit 30 sends the baseband video data input from the terminal 40 and the input from the terminal 41 to each part of the recording unit 10. Control is performed so that the audio data of the subband is recorded on the recording medium 20.
  • the video encoder 1 1 and the audio encoder 12 2 are stopped in the recording stop state, and these video encoders 1 1 are stopped according to the recording start instruction. It is also possible to start the operation of the audio encoder 1 2. Not limited to this, the start and stop of recording can be controlled by controlling the start and stop of operations of the multiplexer 13, the stream buffer 14, and the recording control unit 15.
  • the clip AV stream is recorded on the recording medium 20 according to the recording start control (step S 51). That is, the input video data and audio data are compressed and encoded by the video encoder 1 1 and the audio encoder 1 2, respectively, and the multiplexer 1 3
  • the packet is converted into a TS bucket (actually, a source bucket with a predetermined header added) and supplied to the stream buffer 14.
  • a TS bucket actually, a source bucket 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.ni2 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.
  • a file name that does not overlap with the existing file is selected, for example, “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”. The same data can be stored in the nonvolatile memory 18 as a backup of the data.
  • step S 52 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 1 and determines that the recording is stopped, the process proceeds to step S 53. On the other hand, if the recording is not stopped, the process returns to step S 51 and the recording of the clip AV stream onto the recording medium 20 is continued.
  • step S 53 when recording stops, stream buffer 1 4 All the streams stored in are recorded on the recording medium 20.
  • 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.
  • the management information processing unit 16 In the next step S54 to step S58, the management information processing unit 16 generates a clip information file related to the clip AV stream file written to the recording medium 20, and updates the playlist file. Made.
  • step S 54 the management information processing unit 16 generates a clip information file “zzzzz. Clpi”.
  • the file name is, for example, a file name corresponding to the file name of the clip AV stream file indicated by the clip information file. If the file name of the clip AV stream file is “00002 ffl2ts”, the clip information file The file name is the same file name "00002 clpi" before the extension.
  • the values of the fields and flags are set and stored in accordance with the syntaxes illustrated in FIGS.
  • information on TS packets and information on playback time (PTS) are generated by the management information processing unit 16 based on information acquired from the multiplexer 13 during clip recording.
  • information on the recording address on the recording medium 20 PT / JP2007 / 059345 is generated by the management information processing unit 16 based on the information acquired from the recording control unit 15 during clip recording.
  • the system-specific value is
  • 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 • clpi”.
  • the flag IsCC5 in the block blkClipInfoO is set to 1 (binary value) when clip recording is stopped by a user operation.
  • the data indicated by the if statement in the block MkClipInfoO (see Fig. 16) is set to a predetermined value.
  • step S55 The processing from step S55 to step S58 is processing related to the playlist file.
  • the play item corresponding to the newly recorded clip AV stream file “00002.m2ts” is added to the playlist file already existing on the recording medium 20 by the processing of step S55 to step S58.
  • step S55 the value of field ConnectionConditi on in block blkP yl t em () in the playlist file is set to 5, and this clip is connected to the next clip in the first seamless connection. It is shown to do (see Fig. 12).
  • step S 56 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 field ClipInformaUonFileNanie, field INTime and field OUT in block blkPlayltemO Each time is set, and a block blkPIayltemO that is added as a clip is recorded is created.
  • the field CI iplnformationFileName the file name “00002 clpi” of the clip information file created in step S 55 described above is stored. Actually, since the extension of the clip information file is fixed, the part “00002” before the period is stored.
  • 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 “0000 2.m2ts”. For example, the clip information file “00002.c” Based on the information in block b IkEPMap () in block b lkCPI 0 in lpi ".
  • step S58 the value of the field Number 0 f P 1 ayL ist Marks in the block in the playlist file blkPlayL ist Mark 0 is incremented by 1, and the field added in the for loop statement is added accordingly.
  • the value of MarkTimeStamp is set to the value of field INTime in block blkPlay ItemO in step S57 described above.
  • a playlist mark is placed at the beginning of a newly recorded clip.
  • the clip information file “000 02.clpi” is created and the existing playlist file is updated for the newly recorded clip AV stream file “00002.m2ts”. It is done.
  • step S 53 the process of writing the data stored in the stream buffer 14 in step S 53 described above to the recording medium 20 may be performed after the process of step S 58.
  • step S 50 When the recording is stopped and the recording start operation is performed on the UI unit 31, the processing from step S 50 is started again, and a new clip is created. Record AV stream file to recording medium 20 and create corresponding clip information file, create play item referring to created clip information file, and play list of generated play item The additional processing is performed in the same way.
  • next recording is started after the recording is stopped, the next clip AV is recorded until the writing of the clip information file created in step S 54 described above to the recording medium 20 is completed. Do not start recording stream files.
  • the clip information file is held in the volatile memory 17 used as a work memory for generating the clip information file.
  • the recording device is turned off.
  • a clip information file held in the volatile memory 17 at a predetermined timing may be written to the recording medium 20.
  • next clip AV stream file is recorded with the clip AV stream file and the corresponding clip information file and playlist file already recorded on the recording medium 20.
  • processing described using the flowchart of FIG. 33 can be applied to the recording of the first clip AV stream file on the recording medium 20.
  • the index file and the movie object file can be automatically created.
  • FIG. 34 shows an example of the file structure created according to the procedure of FIG. 33 described above.
  • the first clip AV stream file “00001.m2ts” is recorded on the recording medium 20 (step S50 to step S53), and the corresponding clip information file “0 OOOl.clpi” is created. (Step S54).
  • step S55 the play item # 1 that refers to the clip information file “00001.
  • a playlist file storing the play item # 1 is created (step S55 to step S58).
  • a playlist mark Mark # l is struck for the playlist file at a time corresponding to the field INTime of the play item # 1 (step S58).
  • the movie object file that calls playlist # 1 is selected, and movie object # 1 is selected and played as title # 1.
  • An index file can be created for For movie object files and index files, templates can be created in advance and updated. The creation of these movie object files and index files is related to the gist of the present invention. Detailed description is omitted.
  • the clip AV stream file “00002 .m2 ts” and the corresponding clip information file “00002 .clpi” are additionally recorded on the recording medium 20.
  • Step S50 to Step S53, and Step S54 the clip clip information file “00002.clpi”
  • the reference play item # 2 is generated. This generated play item # 2 is added to the playlist file that has already been created. Furthermore, a playlist mark Mark # 2 is marked on the playlist file at the time corresponding to the field INTime of the playitem # 2 (step S58).
  • one clip AV stream file is recorded on the recording medium 20 by one set of recording start operation and recording stop operation, and a clip information file corresponding to the clip AV stream file is created accordingly. Is done. Also, a play item that refers to the clip information file is generated and added to the existing playlist, and a playlist mark is placed at the time indicated by the field INTime of the play item. A series of these processes is repeated for each set of recording start operation and recording stop operation. Also, as can be seen from the file structure illustrated in Fig. 34, a plurality of play items that refer to each of a plurality of clip AV stream files recorded by repeating a recording start operation and a recording stop operation are as follows: One playlist file is added and stored sequentially as the clip AV stream file is recorded.
  • This playlist The movie is called from one movie object in the movie object file, and this movie object is selected and played as one title from the index file. Therefore, a plurality of clip AV stream files recorded by repeating a series of recording start operations and recording stop operations are managed as one title on the index file.
  • 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, the video data was recorded on a recording medium.
  • FIG. 35 shows an example of the configuration of a video camera apparatus 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. 31, so the same reference numerals are assigned to the parts common to 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 a configuration related to the video signal.
  • a microphone (MIC) 56 and an audio signal processing unit 57 are provided.
  • the control unit 30 controls the operation of the camera unit 50 by exchanging various control signals and information with each unit 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.
  • a recording start operation is performed.
  • 2007/059345 Operation and recording stop operation uses, for example, a single recording switch provided in the UI unit 31 and every time the recording switch is pressed, recording start and recording stop are instructed alternately. It is common to be made to do so.
  • a disk recording medium such as a Blu-ray Disc or a recordable DVD 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 mechanism are controlled by the camera control unit 54 based on the control signal supplied from the control unit 30.
  • the image sensor 52 is composed of, for example, a CCD (Charge Coupled Device), converts the light irradiated through the optical system 51 into an electric signal by photoelectric conversion, performs predetermined signal processing, and outputs it as an image signal. .
  • the image pickup signal processing unit 53 performs predetermined signal processing on the image pickup signal output from the image pickup device and outputs it as a baseband digital video display.
  • the imaging signal processing unit 53 encodes only a signal having image information by a CDS (Correlated Doubly Sa immediately 1 ing) circuit with respect to the imaging signal output from the imaging element 52 and noise. And adjust the gain with an AGC (Au to Gain Control) circuit. Then, it is converted into a digital signal by A / D conversion.
  • the imaging signal processing unit 53 performs detection system signal processing on this digital signal, extracts the components of R (red), G (green) and B (blue), and corrects the white balance. Perform correction and other processing, and finally output as a single baseband digital video.
  • the imaging signal processor 5 3 receives the imaging signal output from the imaging device 52.
  • the information of the number is sent to the control unit 30.
  • 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 displayed on the display unit 55 using, for example, an LCD (Liquid Crystal Display) as a display element based on the imaging signal output from the imaging device 52.
  • a video signal to be output is generated.
  • 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 5 7 converts the supplied audio signal into digital audio by performing AZD conversion after passing through the limiter, and performs predetermined audio signal processing such as noise removal and sound quality correction to perform baseband processing.
  • the base-pound digital video data output from the imaging signal processing unit 53 of the camera unit 50 that is output as digital video data is supplied to the terminal 40 of the recording unit 10.
  • the baseband digital audio data output from the audio signal processing unit 57 is supplied to the terminal 41 of the recording unit 10.
  • a control signal instructing the start of recording 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 spanned 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 respectively stored in the video encoder 1. 1 and the audio encoder 12 are compression-encoded, and a predetermined bucket is multiplexed and multiplexed by the multiplexer 13 to be AV stream data.
  • the AV stream data is supplied to the recording control unit 15 via the stream buffer 14 and 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 the information from the multiplexer 13 and the recording control unit 15. In addition, the management information processing unit 16 generates a play item that refers to the clip information file, and when the playlist already exists, adds the generated play item to the playlist. , Put a playlist mark against the playlist.
  • the clip information file created when recording is stopped is written to the recording medium 20 immediately after creation, writing of the clip information file created immediately before to the recording medium 20 is completed. Until the next recording is controlled.
  • the video camera apparatus As another example of this embodiment, the video camera apparatus
  • the playlist file When applied to 1 0 0, it is conceivable to limit the playlist file so that only 1 file can exist for 1 recording medium 2 0. That is, unless editing processing is performed, only one title for reproducing the play list exists on one recording medium 20. In this way, the video camera device 100 using a disk as the recording medium 20 can be handled as if it were a video camera device using a conventional magnetic tape as the recording medium.
  • clip AV stream files recorded individually are managed by one playlist, and playback between each clip AV stream file is the first seamless. Since they are connected by connection, all the clip AV stream files recorded on the recording medium 20 can be reproduced continuously as in the case of reproducing a magnetic tape.
  • a playlist mark is placed at the position corresponding to the beginning of each clip AV stream file recorded individually for each playlist, making it easy to search by clip unit.
  • the recording device shown in FIG. 31 and the recording unit 10 of the video camera device 100 shown in FIG. 35 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 a CD— ROM and DVD—Provided after being recorded on ROM and other recording media. If the computer device can be connected to the network, the software can be provided via a network such as the Internet.

Landscapes

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

Abstract

ＢＤ−ＲＯＭ規格と互換性のあるクリップの管理構造でビデオデータの記録を可能とする。記録開始操作に応じて、ビデオ及びオーディオデータがパケット単位で時分割多重されたストリームの記録媒体への記録が開始される。記録停止操作に応じて、バッファに溜め込まれたストリームがストリームファイルとして記録媒体に書き込まれると共に、当該ストリームファイルに対応するクリップインフォメーションファイルが生成される。そして、当該クリップインフォメーションファイルの全体を示すプレイアイテムが生成され、記録媒体上の既存のプレイリストに追加されると共に、プレイリストに対してプレイアイテムのＩＮ点に対応する時刻にマークが打たれる。次に記録開始及び停止に伴い生成されるプレイアイテムも、同様にして既存のプレイリストにさらに追加され、ＩＮ点に対応する時刻にさらにマークが打たれる。

Description

明 細 書
記録装置、 記録方法および記録プログラム、 ならびに、 撮像装置、 撮像方法および撮像プログラム 技術分野
この発明は、 ビデオデータとオーディオデータとを多重化したスト リームデータを記録媒体に記録するのに適した記録装置、 記録方法お よび記録プログラム、 ならびに、 撮像装置、 撮像方法および撮像プロ グラムに関する。 背景技術
従来から、 記録可能で記録再生装置から取り外し可能とされると共 に、 記録容量が比較的大きく、 ビデオデータとォ一ディォデータとか らなる A V (Audio/Video)データを記録するのに適した記録媒体とし て、 4. 7 GB (Giga Byte)以上の記録容量を有する D VD (Digital Versatile Disc)が普及している。 特許文献 「特開 2004— 3 50 2 5 1」 には、 記録可能なタイプの D VDに対して D VD— V i d e oフォ一マツトで記録する撮像装置が記載されている。
このような大容量の記録媒体を、 例えばビデオカメラ装置のような 、 記録の開始および停止を頻繁に繰り返すような記録装置に適用した 場合に、 記録された A Vストリームのユーザによる取り扱い、 例えば 記録された AVス卜リームのタイトル管理や編集が容易な記録フォー マツトが求められている。
例えば、 ビデオデ一夕およびオーディオデータの連続同期再生、 す なわち実時間再生が保障された再生が必要な所定単位に対して再生区 間や再生順序を指定することが可能なフォーマツトにおいては、 記録 された所定単位の A Vストリームである A Vストリームファイルを、 当該 A Vストリームファイルの属性を示すファイルと、 当該所定単位 で再生区間などを指定するファイルとにより管理することで、 記録媒 体上の A Vストリームファイルを加工することなく、 当該 A Vストリ —ムファイルの再生区間や再生順序を自由に設定した編集を容易に行 うことができる。 このようなファイル管理形態において、 編集処理が 可能な記録フォ一マツトが求められている。 発明の開示
したがって、 この発明の目的は、 ビデオデータとオーディオデータ とが多重化された A Vストリームを、 タイトル管理や編集が容易なよ うに記録媒体に記録可能な記録装置、 記録方法および記録プログラム 、 ならびに、 撮像装置、 撮像方法および撮像プログラムを提供するこ とにある。
上述した課題を解決するために、 第 1の発明は、 ビデオデータとォ 一ディォデータとを多重化して記録媒体に記録する記録装置において 、 ビデオデータおよびオーディォデ一夕が入力されるデータ入力部と 、 ビデオデータおよびオーディォデ一夕の記録開始および記録停止の 指示が入力される記録指示入力部と、 ビデオデータおよびオーディォ データを多重化し、 多重化されたストリームをストリームファイルと して記録媒体に記録する記録部と、 記録媒体に記録されるストリ一ム ファイルに対し、 少なくとも、 ストリームファイルの再生時刻情報と アドレス情報とを対応付けた属性ファイルと、 ストリームファイルに 対して再生開始点と再生終了点とを設定することにより再生区間を指 定する 1以上の再生区間データが格納され、 ストリームファイルに対 する再生時刻情報を示すマーク情報が格納可能な再生リストファイル とを生成する管理情報生成部と、 記録部および管理情報生成部とを制 御する制御部とを有し、 制御部は、 記録指示入力部の指示に基づく記 録開始から記録停止までの区間に対応するビデオデータおよびオーデ ィォデータを 1のストリームファイルとして記録媒体に記録するよう に記録部を制御すると共に、 1のストリームファイルの全体を再生区 間として指定する再生区間データを生成し、 再生区間デ一夕が指定す る再生開始時刻に対応する時刻情報を示すマーク情報を再生リストフ アイルに格納するように管理情報生成部を制御することを特徴とする 記録装置である。
また、 第 2の発明は、 ビデオデータとオーディオデータとを多重化 して記録媒体に記録する記録方法において、 データ入力部に入力され たビデオデータおよびオーディオデータの記録開始および記録停止の 指示が入力される記録指示入力のステップと、 ビデオデ一夕およびォ 一ディォデータを多重化し、 多重化されたストリームをストリ一ムフ アイルとして記録媒体に記録する記録のステップと、 記録媒体に記録 されるストリ一ムファイルに対し、 少なくとも、 ストリームファイル の再生時刻情報とァドレス情報とを対応付けた属性ファイルと、 スト リームファイルに対して再生開始点と再生終了点とを設定することに より再生区間を指定する 1以上の再生区間データが格納され、 ストリ ームファイルに対する再生時刻情報を示すマーク情報が格納可能な再 生リストファイルとを生成する管理情報生成のステップと、 記録のス テップぉよび管理情報生成のステツプとを制御する制御のステップと を有し、 制御のステップは、 記録指示入力のステップによる指示に基 づく記録開始から記録停止までの区間に対応するビデオデ一夕おょぴ オーディォデータを 1のストリームファイルとして記録媒体に記録す るように記録のステップを制御すると共に、 1のストリームファイル の全体を再生区間として指定する再生区間データを生成し、 再生区間 データが指定する再生開始時刻に対応する時刻情報を示すマーク情報 を再生リストファイルに格納するように管理情報生成のステップを制 御することを特徴とする記録方法である。
また、 第 3の発明は、 ビデオデータとオーディオデ一夕とを多重化 して記録媒体に記録する記録方法をコンピュータ装置に実行させる記 録プログラムにおいて、 記録方法は、 データ入力部に入力されたビデ ォデータおよびオーディオデータの記録開始および記録停止の指示が 入力される記録指示入力のステップと、 ビデオデータおよびオーディ ォデータを多重化し、 多重化されたストリームをストリームファイル として記録媒体に記録する記録のステップと、 記録媒体に記録される ストリームファイルに対し、 少なくとも、 ストリームファイルの再生 時刻情報とアドレス情報とを対応付けた属性ファイルと、 ストリーム ファイルに対して再生開始点と再生終了点とを設定することにより再 生区間を指定する 1以上の再生区間データが格納され、 ストリームフ アイルに対する再生時刻情報を示すマーク情報が格納可能な再生リス トファイルとを生成する管理情報生成のステップと、 記録のステップ および管理情報生成のステップとを制御する制御のステップとを有し 、 制御のステップは、 記録指示入力のステップによる指示に基づく記 録開始から記録停止までの区間に対応するビデオデータおよびオーデ ィォデ一夕を 1のストリームファイルとして記録媒体に記録するよう に記録のステップを制御すると共に、 1のストリームファイルの全体 を再生区間として指定する再生区間デ一夕を生成し、 再生区間データ が指定する再生開始時刻に対応する時刻情報を示すマーク情報を再生 リストファイルに格納するように管理情報生成のステップを制御する ことを特徴とする記録プログラムである。 また、 第 4の発明は、 撮像部で被写体を撮像して得られたビデオデ 一夕と、 収音部で音声を収音して得られたオーディオデータとを多重 化して記録媒体に記録する撮像装置において、 被写体を撮像してビデ ォデータを出力する撮像部と、 音声を収音してオーディォデータを出 力する収音部と、 ビデオデ一夕およびオーディオデータを多重化し、 多重化されたストリームをストリームファイルとして記録媒体に記録 する記録部と、 ビデオデ一夕およびオーディォデータの記録媒体への 記録開始および記録停止を指示するユーザ操作を受け付ける操作部と 、 記録媒体に記録されるストリームファイルに対し、 少なくとも、 ス トリームフアイルの再生時刻情報とアドレス情報とを対応付けた属性 ファイルと、 ストリームファイルに対して再生開始点と再生終了点と を設定することにより再生区間を指定する 1以上の再生区間データが 格納され、 ストリームファイルに対する再生時刻情報を示すマーク情 報が格納可能な再生リストファイルとを生成する管理情報生成部と、 操作部に対するユーザ操作に応じて記録部の動作を制御すると共に、 管理情報生成部を制御する制御部とを有し、 制御部は、 操作部に対す る操作に応じて、 記録開始から記録停止までの区間に対応するビデオ データおよびオーディオデ一夕を 1のストリ一ムファイルとして記録 媒体に記録するように記録部を制御すると共に、 1のストリームファ ィルの全体を再生区間として指定する再生区間データを生成し、 再生 区間データが指定する再生開始時刻に対応する時刻情報を示すマーク 情報を再生リストファイルに格納するように管理情報生成部を制御す ることを特徴とする撮像装置である。
また、 第 5の発明は、 撮像部で被写体を撮像して得られたビデオデ 一夕と、 収音部で音声を収音して得られたオーディオデータとを多重 化して記録媒体に記録する撮像装置の撮像方法において、 撮像部で被 写体を撮像して得られたビデオデータと、 収音部で音声を収音して得 られたオーディオデータとを多重化し、 多重化されたストリームをス トリームファイルとして記録媒体に記録する記録のステップと、 操作 部に対するビデオデータおよびォ一ディォデータの記録媒体への記録 開始および記録停止を指示するュ一ザ操作を受け付けるステップと、 記録媒体に記録されるストリームファイルに対し、 少なくとも、 スト リームフアイルの再生時刻情報とアドレス情報とを対応付けた属性フ アイルと、 ストリームファイルに対して再生開始点と再生終了点とを 設定することにより再生区間を指定する 1以上の再生区間データが格 納され、 ストリームファイルに対する再生時刻情報を示すマーク情報 が格納可能な再生リストファイルとを生成する管理情報生成のステツ プと、 操作部に対するュ一ザ操作に応じて記録のステップの動作を制 御すると共に、 管理情報生成のステップを制御する制御のステップと を有し、 制御のステップは、 操作部に対する操作に応じて、 記録開始 から記録停止までの区間に対応するビデオデ一夕およびオーディォデ 一夕を 1のストリームファイルとして記録媒体に記録するように記録 のステップを制御すると共に、 1のストリームファイルの全体を再生 区間として指定する再生区間データを生成し、 再生区間データが指定 する再生開始時刻に対応する時刻情報を示すマーク情報を再生リスト ファイルに格納するように管理情報生成のステツプを制御することを 特徴とする撮像方法である。
また、 第 6の発明は、 撮像部で被写体を撮像して得られたビデオデ 一夕と、 収音部で音声を収音して得られたオーディオデ一夕とを多重 化して記録媒体に記録する撮像装置の撮像方法をコンピュータ装置に 実行させる撮像プログラムにおいて、 撮像方法は、 撮像部で被写体を 撮像して得られたビデオデータと、 収音部で音声を収音して得られた オーディォデ一夕とを多重化し、 多重化されたストリームをストリー ムファイルとして記録媒体に記録する記録のステップと、 操作部に対 するビデオデータおよびオーディオデ一夕の記録媒体への記録開始お よび記録停止を指示するユーザ操作を受け付けるステップと、 記録媒 体に記録されるストリームファイルに対し、 少なくとも、 ストリーム ファイルの再生時刻情報とアドレス情報とを対応付けた属性ファイル と、 ストリームファイルに対して再生開始点と再生終了点とを設定す ることにより再生区間を指定する 1以上の再生区間データが格納され 、 ストリームファイルに対する再生時刻情報を示すマーク情報が格納 可能な再生リストファイルとを生成する管理情報生成のステップと、 操作部に対するユーザ操作に応じて記録のステップの動作を制御する と共に、 管理情報生成のステップを制御する制御のステップとを有し 、 制御のステップは、 操作部に対する操作に応じて、 記録開始から記 録停止までの区間に対応するビデオデータおよびオーディォデータを 1のストリームファイルとして記録媒体に記録するように記録のステ ップを制御すると共に、 1のストリームファイルの全体を再生区間と して指定する再生区間データを生成し、 再生区間データが指定する再 生開始時刻に対応する時刻情報を示すマーク情報を再生リストフアイ ルに格納するように管理情報生成のステップを制御することを特徴と する撮像プログラムである。
上述したように、 第 1、 第 2および第 3の発明は、 デ一タ入力部に 入力されたビデオデ一夕およびオーディォデータを多重化して記録媒 体に記録されるストリームファイルに対し、 少なくとも、 ストリーム フアイルの再生時刻情報とアドレス情報とを対応付けた属性ファイル と、 ストリームファイルに対して再生開始点と再生終了点とを設定す ることにより再生区間を指定する 1以上の再生区間デ一夕が格納され 、 ストリームファイルに対する再生時刻情報を示すマーク情報が格納 可能な再生リストファイルとを生成し、 記録指示入力による指示に基 づく記録開始から記録停止までの区間に対応するビデオデ一夕および オーディオデ一夕を 1のストリームファイルとして記録媒体に記録す るように制御すると共に、 1のストリームファイルの全体を再生区間 として指定する再生区間データを生成し、 再生区間データが指定する 再生開始時刻に対応する時刻情報を示すマーク情報を再生リストファ ィルに格納するように制御するようにしているため、 ストリームファ ィルを、 クリップを単位としてプレイリストを用いて管理する管理構 造で記録媒体に記録することができる。
また、 第 4、 第 5および第 6の発明は、 撮像部で被写体を撮像して 得られたビデオデータと、 収音部で音声を収音して得られたオーディ ォデータとを多重化したストリームが記録媒体に記録されるストリー ムファイルに対し、 少なくとも、 ストリームファイルの再生時刻情報 とアドレス情報とを対応付けた属性ファイルと、 ストリームファイル に対して再生開始点と再生終了点とを設定することにより再生区間を 指定する 1以上の再生区間データが格納され、 ストリームファイルに 対する再生時刻情報を示すマーク情報が格納可能な再生リストフアイ ルとを生成し、 操作部に対する操作に応じて、 記録開始から記録停止 までの区間に対応するビデオデータおよびォ一ディォデータを 1のス トリームファイルとして記録媒体に記録するように制御すると共に、 1のストリームファイルの全体を再生区間として指定する再生区間デ 一夕を生成し、 再生区間データが指定する再生開始時刻に対応する時 刻情報を示すマーク情報を再生リストファイルに格納するように制御 するようにしているため、 被写体を撮像して得られたビデオデータお よびオーディオデータを、 クリップを単位としてプレイリストを用い て管理する管理構造で記録媒体に記録することができる。
上述のように、 第 1、 第 2および第 3の発明は、 データ入力部に入 力されたビデオデータおよびオーディォデー夕を多重化して記録媒体 に記録されるストリームファイルに対し、 少なくとも、 ストリームフ ァィルの再生時刻情報とアドレス情報とを対応付けた属性ファイルと 、 ストリームファイルに対して再生開始点と再生終了点とを設定する ことにより再生区間を指定する 1以上の再生区間デ一夕が格納され、 ストリームファイルに対する再生時刻情報を示すマーク情報が格納可 能な再生リストファイルとを生成し、 記録指示入力による指示に基づ く記録開始から記録停止までの区間に対応するビデオデータおよびォ 一ディォデータを 1のストリームファイルとして記録媒体に記録する ように制御すると共に、 1のストリ一ムファイルの全体を再生区間と して指定する再生区間データを生成し、 再生区間データが指定する再 生開始時刻に対応する時刻情報を示すマーク情報を再生リストフアイ ルに格納するように制御するようにしているため、 ストリームフアイ ルを、 クリップを単位としてプレイリストを用いて管理する管理構造 で記録媒体に記録することができる効果がある。
また、 第 4、 第 5および第 6の発明は、 撮像部で被写体を撮像して 得られたビデオデー夕と、 収音部で音声を収音して得られたオーディ ォデータとを多重化したストリ一ムが記録媒体に記録されるストリー ムファイルに対し、 少なくとも、 ストリームファイルの再生時刻情報 とアドレス情報とを対応付けた属性ファイルと、 ストリームファイル に対して再生開始点と再生終了点とを設定することにより再生区間を 指定する 1以上の再生区間データが格納され、 ストリ一ムファイルに 対する再生時刻情報を示すマ一ク情報が格納可能な再生リストフアイ ルとを生成し、 操作部に対する操作に応じて、 記録開始から記録停止 までの区間に対応するビデオデータおよびオーディオデータを 1のス トリームファイルとして記録媒体に記録するように制御すると共に、
1のストリームファイルの全体を再生区間として指定する再生区間デ 一夕を生成し、 再生区間データが指定する再生開始時刻に対応する時 刻情報を示すマーク情報を再生リストフアイルに格納するように制御 するようにしているため、 被写体を撮像して得られたビデオデータお よびオーディォデ一夕を、 クリップを単位としてプレイリストを用い て管理する管理構造で記録媒体に記録することができる効果がある。 図面の簡単な説明
第 1図は、 この発明に適用可能な A VCHDフォーマツトに規定さ れるデータモデルを概略的に示す略線図、 第 2図は、 インデックステ 一ブルを説明するための略線図、 第 3図は、 クリップ A Vストリーム 、 クリップ情報、 クリップ、 プレイアイテムおよびプレイリストの関 係を示す UML図、 第 4図は、 複数のプレイリストから同一のクリツ プを参照する方法を説明するための略線図、 第 5図は、 記録媒体に記 録されるファイルの管理構造を説明するための略線図、 第 6図は、 フ アイル" index, bdmv"の一例の構造を表すシンタクスを示す略線図、 第 7図は、 ブロック blklndexesOの一例の構造を表すシンタクスを示す 略線図、 第 8図は、 ファイル" MovieObject.bdmv"の一例の構造を表す シンタクスを示す略線図、 第 9図は、 ブロック blkMovieObjectsOの 一例の構造を表すシンタクスを示す略線図、 第 1 0図は、 プレイリス トファイル" xxxxx.mpls"の一例の構造を表すシンタクスを示す略線図 、 第 1 1図は、 ブロック blkPlayListOの一例の構造を表すシンタク スを示す略線図、 第 1 2図は、 ブロック blkPlayltemOの一例の構造 を表すシンタクスを示す略線図、 第 1 3図 Aおよび第 1 3図 Bは、 第 1および第 2のシームレス接続を説明するための略線図、 第 14図は 、 ブロック blkPlayLisiMarkOの一例の構造を表すシンタクスを示す 略線図、 第 1 5図は、 クリップインフォメーションファイルの一例の 構造を表すシンタクスを示す略線図、 第 1 6図は、 ブロック MkClipI nfoOの一例の構造を表すシンタクスを示す略線図、 第 1 7図は、 ブ 口ック blkSequencelnfoOの一例の構造を表すシンタクスを示す略線 図、 第 1 8図は、 ブロック blkProgramlnfoOの一例の構造を表すシン タクスを示す略線図、 第 1 9図は、 ブロック MkCPlOの一例の構造を 表すシンタクスを示す略線図、 第 20図は、 ブロック blkEPMapOの一 例の構造を表すシンタクスを示す略線図、 第 2 1図は、 ブロック blkE PMapForOneStreaiPID(EP_stream_type, Nc, Nf)の一例の構造を表す シンタクスを示す略線図、 第 22図は、 エントリ PTSEPCoarseおよび ェントリ PTSEPFineの一例のフォーマツトについて示す略線図、 第 2 3図は、 ェントリ SMEPCoarseおよびェントリ SPNEPFineの一例のフォ 一マットについて示す略線図、 第 24図は、 ブロック blkExtensionDa ta()の一例の構造を表すシンタクスを示す略線図、 第 2 5図は、 プロ ック MkExtensionDataOにおける各データの参照関係を模式的に示す 略線図、 第 26図は、 ブロック blkExtensionDataOにデータを書き込 む際の一例の処理を示すフロ一チャート、 第 27図は、 ブロック blkE xtensionDataOから拡張データを読み出す際の一例の処理を示すフロ 一チャート、 第 28図は、 ファイル" index. bdmv "内のフィールド blkE xtensionDataOにおけるブロック DataBlockOの一例の構造を表すシ ンタクスを示す略線図、 第 2 9図は、 ブロック blkTableOfPlayListO の一例の構造を表すシンタクスを示す略線図、 第 30図 Aおよび第 3 0図 Bは、 仮想プレーヤの動作を概略的に示すフローチャート、 第 3 1図は、 仮想プレーヤの動作を概略的に示す略線図、 第 3 2図は、 こ の発明の実施の一形態に適用可能な記録装置の一例の構成を概略的に 示すブロック図、 第 33図は、 この発明の実施の一形態によるクリツ プの一例の記録方法を示すフローチャート、 第 34図は、 この発明の 実施の一形態の方法により記録された一例のファイル構造を示す略線 図、 第 35図は、 この発明の実施の一形態の他の例によるビデオカメ ラ装置の一例の構成を示すプロック図である。 発明を実施するための最良の形態
以下、 この発明の実施の一形態を、 図面を参照しながら説明する。 先ず、 理解を容易とするために、 この発明に適用可能な一例のフォー マット （以下、 AVCHDフォーマットと呼ぶ） について説明する。 AVCHDフォーマツトは、 ビデオデ一夕とオーディオデータとが所 定に多重化された A V (Audio/Video)ストリームを記録可能な記録媒 体に記録する記録フォ一マツトとして現在提案されているもので、 記 録媒体に記録された A Vストリームを、 クリップ単位でプレイリスト を用いて管理可能としている。
例えは I TU— T (International Telecommunication Union - Telec ommunicat ion Standar izat ion Sec torリ勧告 H. 264あるレ ま I S O (Internal ional Organization for Standar izat ion; / I EC (Inte rnational Electrotechnical Commiss ion)国際標準 14496— 1 0 (MP E G— 4パート 1 0 ) Advanced Video Coding (以下、 H. 2 64 I AVCと略称する） に規定される符号化方式や、 MPEG(Mov ing Pictures Experts Group)ビデオや M P E Gオーディオといった 符号化方式で符号化され、 MP E G 2システムズに従い多重化された ビットストリームは、 クリップ AVストリーム （または A Vストリー ム） と称される。 クリップ AVストリームは、 所定のファイルシステ ムによりファイルとしてディスクに記録される。 このファイルを、 ク リップ AVストリームファイル （または AVストリームファイル） と 称する。
クリップ AVストリ一ムファイルは、 ファイルシステム上での管理 単位であり、 ュ一ザにとって必ずしも分かりやすい管理単位であると は限らない。 ユーザの利便性を考えた場合、 複数のクリップ AVスト リームファイルに分割された映像コンテンツを一つにまとめて再生す る仕組みや、 クリップ AVストリームファイルの一部だけを再生する 仕組み、 さらには、 特殊再生や頭出し再生を滑らかに行うための情報 などをデータベースとしてディスクに記録しておく必要がある。
第 1図は、 この発明に適用可能な AVCHDフォーマツトに規定さ れるデータモデルを概略的に示す。 この AVCHDフォーマツトによ れば、 データ構造は、 第 1図に示されるように 4層のレイヤよりなる 。 最も最下層のレイヤは、 クリップ AVストリームが配置されるレイ ャである （便宜上、 クリップレイヤと呼ぶ） 。 その上のレイヤは、 ク リップ AVストリームに対する再生箇所を指定するための、 プレイリ スト（PlayList)と、 プレイアイテム（Playltem)とが配置されるレイヤ である （便宜上、 プレイリストレイヤと呼ぶ） 。 さらにその上のレイ ャは、 プレイリストに対して再生順などを指定するコマンドからなる ムービーオブジェクト（Movie Obj ect)などが配置されるレイヤである (便宜上、 オブジェクトレイヤと呼ぶ） 。 最上層のレイヤは、 記録媒 体に格納されるタイトルなどを管理するィンデックステーブルが配置 される （便宜上、 インデックスレイヤと呼ぶ） 。
クリップレイヤについて説明する。 クリップ A Vストリームは、 ビ デォデ一夕やオーディオデータが MP E G 2 TS (トランスポート ストリ一ム） の形式などに多重化されたビットストリームである。 こ のクリップ A Vストリームに関する情報がクリップ情報（Clip Inform at ion)としてファイルに記録される。
また、 グリップ AVストリームには、 字幕を表示するグラフィクス ストリームである OBストリーム（Overlay Bitmap stream)や、 メニ ユー表示などに用いられるデータ （ポタン画像データなど） をストリ —ムにした MBストリーム（Menu Bitmap stream)ストリームを多重化 することができる。
クリップ A Vストリームファイルと、 対応するクリツプ情報が記録 されたクリップ情報ファイルとをひとまとまりのオブジェクトと見な し、 クリップ（Clip)と称する。 すなわち、 クリップは、 クリップ AV ストリームとクリップ情報とから構成される、 一つのオブジェク卜で ある。
ファイルは、 一般的に、 バイト列として扱われる。 クリップ A Vス トリームファイルのコンテンツは、 時間軸上に展開され、 クリップ中 のエントリーポイントは、 主に時間ベースで指定される。 所定のクリ ップへのアクセスボイン卜のタイムスタンプが与えられた場合、 クリ ップ AVストリームファイルの中でデータの読み出しを開始すべきァ ドレス情報を見つけるために、 クリップ情報ファイルを用いることが できる。
プレイリストレイヤについて説明する。 プレイリストは、 再生する AVストリームファイルの指定と、 指定された A Vストリームフアイ ルの再生箇所を指定する再生開始点 （ I N点） と再生終了点 （OUT 点） の集まりとから構成される。 この再生開始点と再生終了点の情報 を一組としたものは、 プレイアイテム（Playltem)と称される。 プレイ リストは、 プレイアイテムの集合で構成される。 プレイアイテムを再 生するということは、 そのプレイアイテムに参照される A Vストリー ムファイルの一部分を再生するということになる。 すなわち、 プレイ アイテム中の I N点および OUT点情報に基づき、 クリップ中の対応 する区間が再生される。
ォブジェクトレイヤについて説明する。 ムービーオブジェクトは、 ナビゲーシヨンコマンドプログラムと、 ムービーオブジェクトとを連 携するターミナルインフォメーションを含む。 ナビゲ一シヨンプログ ラムは、 プレイリストの再生を制御するためのコマンド （ナビゲ一シ ヨンコマンド ： navigation command) である。 夕一ミナリレインフォメ —ションは、 ユーザのプレーヤに対するィンタラクティブな操作を許 可するための情報を含んでいる。 このターミナルインフォメーション に基づき、 メニュー画面の呼び出しや、 タイトルサーチといったユー ザオペレ一ションが制御される。
インデックスレイヤについて説明する。 インデックスレイヤは、 ィ ンデックステーブル（Index Table)からなる。 インデックステーブル は、 記録媒体に記録されたコンテンツのタイトルを定義する、 トップ レベルのテーブルである。 ィンデックステーブルに格納されている夕 ィトル情報に基づき、 プレーヤに常駐されるシステムソフトウエア中 のモジュールマネージャにより記録媒体の再生が制御される。
すなわち、 第 2図に概略的に示されるように、 インデックステープ ル中の任意のエントリは、 タイトルと称され、 インデックステーブル にェントリされるファーストプレイバックタイトル（First PlaybackT itle)、 メニュータイトル（MenuTitle)およびム一ピ一タイトル（Movie Title) # l、 # 2、 · · ·は、 全てタイトルである。 各タイトルは、 ムービーオブジェクトに対するリンクを示す。
理解を容易とするため再生専用の記録媒体を例にとると、 例えば、 ファーストプレイパックタイトルは、 当該記録媒体に格納されるコン テンッが映画であれば、 映画本編に先立って映出される映画会社の宣 伝用映像 （トレーラ） に対応する。 メニュ一タイトルは、 例えばコン テンッが映画である場合、 本編再生、 チヤプタサーチ、 字幕や言語設 定、 特典映像再生などを選択するためのメニュー画面に対応する。 ま た、 ムービータイトルは、 メニュータイトルから選択される各映像で ある。 タイトルがさらにメニュー画面であるような構成も可能である 第 3図は、 上述のようなクリップ A Vストリーム、 クリップ情報（S t ream At t r i bu tes) , クリップ、 プレイアイテムおよびプレイリスト の関係を示す U M L (Uni f i ed Model ing Language)図である。 プレイ リストは、 1または複数のプレイアイテムに対応付けられ、 プレイァ ィテムは、 1のクリップに対応付けられる。 1のクリップに対して、 それぞれ開始点および/または終了点が異なる複数のプレイアイテム を対応付けることができる。 1のクリップから 1のクリップ A Vスト リームファイルが参照される。 同様に、 1のクリップから 1のクリツ プ情報ファイルが参照される。 また、 クリップ A Vストリームフアイ ルとクリップ情報ファイルとは、 1対 1の対応関係を有する。 このよ うな構造を定義することにより、 クリップ A Vストリームファイルを 変更することなく、 任意の部分だけを再生する、 非破壌の再生順序指 定を行うことが可能となる。
また、 第 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点および〇 U T点で示される区間が参照されると共に、 プレイリスト 3 1 2のプ レイアイテム 3 2 3および 3 2 4のうち、 プレイアイテム 3 2 3の I N点および O U T点で示される区間が参照される。
次に、 A V C H Dフォーマットによる、 記録媒体に記録されるファ ィルの管理構造について、 第 5図を用いて説明する。 ファイルは、 デ ィレクトリ構造により階層的に管理される。 記録媒体上には、 先ず、 1つのディレクトリ （第 5図の例ではルート（roo t)ディレクトリ） が 作成される。 このディレクトリの下が、 1つの記録再生システムで管 理される範囲とする。
ルートディレクトリの下に、 ディレクトリ" BDMV' 'およびディレクト リ " AVCHDTN"が置かれる。 ディレクトリ" AVCHDTN"には、 例えばクリッ プの代表画像を所定サイズに縮小したサムネイルファイルが置かれる 。 ディレクトリ" BDMV"に、 第 1図を用いて説明したデータ構造が格納 される。
ディレクトリ" BDMV"の直下には、 ファイルは、 ファイル" index, bdm v"およびファイル" Movi eObj ec t . bdmv"の 2つのみを置くことができる 。 また、 ディレクトリ" BDMV"の下に、 ディレクトリ " PLAYL IST"、 ディ レクトリ" CL IPINF"、 ディレクトリ" STREAM"およびディレクトリ" BACK UP"が置かれる。 ディレクトリ" BACKUP"は、 各ディレクトリおよびフ アイルのバックァップが格納される。
ファイル" index, bdmv"は、 ディレクトリ" BDMV"の内容について記述 される。 すなわち、 このファイル" index. bdmv"が上述した最上層のレ ィャであるィンデックスレイヤにおけるィンデックステ一ブルに対応 する。 また、 ファイル" MovieObject.bdmv"は、 1つ以上のムービーォ ブジェクトの情報が格納される。 すなわち、 このファイル" MovieObie ct.bdmv"が上述したオブジェクトレイヤに対応する。
ディレクトリ" PLAYLIST"は、 プレイリストのデータベースが置かれ るディレクトリである。 すなわち、 ディレクトリ" PLAYLIST"は、 プレ イリストに関するファイルであるファイル" xxxxx.mpls"を含む。 ファ ィル" xxxxx.即 Is"は、 プレイリストのそれぞれに対して作成されるフ アイルである。 ファイル名において、 "." （ピリオド） の前の" xxxxx" は、 5桁の数字とされ、 ピリオドの後ろの" mpls"は、 このタイプのフ アイルに固定的とされた拡張子である。
ディレクトリ" CLIPINF"は、 クリップのデータベースが置かれるデ ィレクトリである。 すなわち、 ディレクトリ" CLIPINF"は、 クリップ AVストリ一ムファイルのそれぞれに対するクリップインフォメーシ ョンファイルであるファイル" zzzzz.clpi"を含む。 ファイル名におい て、 "." （ピリオド） の前の" zzzzz"は、 5桁の数字とされ、 ピリオド の後ろの" c lpi"は、 このタイプのファイルに固定的とされた拡張子で ある。
ディレクトリ" STREAM"は、 実体としての A Vストリームファイルが 置かれるディレクトリである。 すなわち、 ディレクトリ" STREAM"は、 クリップインフォメーションファイルのそれぞれに対応するクリップ AVストリームファイルを含む。 クリップ AVストリームファイルは 、 MP E G 2 (Moving Pictures Experts Group 2)のトランスポート ストリーム （以下、 MPEG2 TSと略称する） からなり、 フアイ ル名が" zzzzz.m2ts"とされる。 ファイル名において、 ピリオドの前の "zzzzz"は、 対応するクリップインフォメーションファイルと同一す ることで、 クリップインフォメーションファイルとこのクリップ A V ストリームファイルとの対応関係を容易に把握することができる。 なお、 ディレクトリ" AVCHDTN"は、 2種類のサムネイルファイル" th umbnail. tidx"および" thumbnaiし tdt2"を置くことができる。 サムネ ィルファイル" thumbnail, tidx"は、 所定の方式で喑号化されたサムネ ィル画像が格納される。 サムネイルファイル" thumbnail. tdt2"は、 暗 号化されていないサムネイル画像が格納される。 例えばビデオカメラ でユーザが撮影したクリップ 対応するサムネイル画像は、 コピーフ リーであって暗号化する必要が無いと考えられるため、 このサムネィ ルファイル" thumbnail. tdt2"に格納される。
第 5図で示した各ファイルのうち、 この発明に関わりの深いものに ついて、 より詳細に説明する。 先ず、 ディレクトリ" BDMV"の直下に置 かれるファイル" index, bdmv"について説明する。 第 6図は、 このファ ィル" index, bdmv"の一例の構造を表すシンタクスを示す。 ここでは、 シンタクスをコンピュータ装置などのプログラムの記述言語として用 いられる C言語の記述法に基づき示す。 これは、 他のシンタクスを表 す図において、 同様である。
第 6図において、 フィールド Typelndicatorは、 32ビットのデ一 夕長を有し、 このファイルがィンデックステ一ブルであることを示す 。 フィ一ルド TypeIndicator2は、 32ビットのデ一夕長を有し、 この ファイル" index. bdmv"のバ一ジョンを示す。 フィールド IndexesStart Addressは、 32ビットのデータ長を有し、 このシンタクス内にある ブロック blklndexesOの開始ァドレスを示す。
フィ一ルド ExtensionDataStartAddressは、 32ビットのデータ長 を有し、 このシンタクス内にあるブロック blkExtensionDataOの開始 アドレスを示す。 ブロック blkExtensionDataOは、 所定の拡張データ を格納可能とするためのブロックである。 フィールド ExtensionDataS tartAddressは、 このファイル" index, bdmv"の最初のバイトからの相 対バイト数で、 ブロック MkExtensionDataOの開始アドレスを示す。 相対バイト数は、 " 0"から開始される。 若し、 このフィールド Extens ionDataStartAddressの値が" 0"であれば、 このフアイル" index, bdmv "内に、 ブロック blkExtensionDataOが存在しないことを示す。
フィールド ExtensionDataStartAddressに続けて、 データ長が 1 9 2バイトの領域 reservedが配される。 なお、 領域 reservedは、 バイト ァライメントゃ、 将来的なフィ一ルドの追加などのための領域である 。 これは、 以下の説明においても同様である。 ブロック blkAppInfoBD MV0は、 コンテンツ制作者が任意の情報を記述できるブロックであつ て、 プレーヤの動作などには影響を与えない。
ブロック blklndexesOは、 このファイル" index, bdmv"の実質的な内 容であって、 このブロック blklndexesOに記述された内容により、 デ イスクをプレーヤに装填した際に再生されるファーストプレイバック や、 トップメニューから呼び出されるタイトル （ムービーオブジェク ト） が指定される。 インデックステーブルにより呼び出されたムービ —オブジェクト等に記述されたコマンドに基づき、 後述するプレイリ ストファイルが読み込まれる。
第 7図は、 ブロック blklndexesOの一例の構造を表すシンタクスを 示す。 フィールド Lengthは、 32ビットのデータ長を有し、 このフィ —ルド Length直後からこのブロック blklndexes ()の終わりまでのデー 夕長を示す。 続けて、 ブロック FirstPlaybackTitleOおよびブロック MenuTiUeOが配される。
ブロック Firs laybackTiUeOは、 ファーストプレイバックで用い られるオブジェクトに関する情報が記述される。 ブロック FirstPlayb ackTitleOは、 1ビットのデータ長を有する領域 reservedに続けて固 定値" が記述される。 さらに 3 1ビットのデータ長を有する領域 res ervedを介して固定値" Γが記述される。 そして、 14ビットのデータ 長を有する領域 reservedを介して、 1 6ビットのデータ長を有するフ ィ一ルド FirstPlaybackTitleMobjIDRefが配される。 このフィールド F irstPlaybackTitleMobjIDRefにより、 ファーストプレイバックタイト ルで用いられるム一ビーオブジェクトの I Dを示す。
ムービーオブジェクトの I Dは、 例えば、 第 8図および第 9図を用 いて後述するム一ビーオブジェクトのシンタクスに基づき、 ム一ビー オブジェクトの forループ文においてループ変数として用いられる値 m obj— idで示される。 この例では、 フィールド FirstPlaybackTitleMobj IDRefは、 参照するムービーオブジェクトに対応する値 mob]'— idが格納 される。
なお、 ブロック blklndexesOにおけるブロック Firs tPlaybackTi t le 0内のフィ一ルド FirstPlaybackTitleMobj IDRefは、 トップメニュー のム一ビーオブジェクトを指していてもよいし、 タイトルを指してい てもよい。
ブロック MenuT i U e 0は、 トップメニューで用いられるオブジェク トに関する情報が記述される。 ブロック MenuT i U e 0は、 ' 1ビットの デ一夕長を有する領域 reservedに続けて固定値" Γが記述される。 さ らに 3 1ビッ卜のデータ長を有する領域 reservedを介して固定値" Γ が記述される。 そして、 14ビットのデータ長を有する領域 reserved を介して、 1 6ビットのデータ長を有するフィールド MenuTitleMobjl DRefが配される。 フィールド MenuTiUeMobjlDRefは、 メニュータイト ルで用いられるムービーオブジェクトの I Dを示す。
ブロック MenuTitleOの次のフィールド NumberOfTitlesは、 1 6ビ ットのデータ長を有し、 ユーザが選択、 再生可能なタイトルの数を示 す。 次の forループ文に従い、 このフィールド NumberOfTitlesに示さ れる回数だけ、 値 title— idを引数として、 ブロック MovieTitle[title — id] ()が記述される。 ブロック MovieTitle[title— id] 0は、 タイトル 毎の情報が記述される。 値 title— idは、 " 0"からフィールド NumberOf Titlesで示される値までの数値であり、 タイトルを識別する。
ブロック MovieTitle[title— id] 0において、 1ビットのデ一タ長を 有する領域 reservedを介して固定値" 1 "が記述され、 さらに、 46ビ ットのデ一夕長を有する領域 reservedを介してフィ一ルド MovieTitle MobjlDRefが記述される。 フィールド MovieTi t leMobj IDRefは、 1 6ビ ットのデータ長を有し、 このタイトルで用いられるム一ビーオブジェ クトの I Dを示す。 フィールド MovieTitleMobj IDRefの後ろに、 32 ビットのデータ長を有する領域 reservedが配される。
第 8図は、 ディレクトリ" BDMV"の直下に置かれるファイル" MovieOb ject.bdmv"の一例の構造を表すシンタクスを示す。 フィールド Typeln dicatorは、 32ビット （4バイト） のデータ長を有し、 このフアイ ルがファイル" MovieObject.bdmv"であることを示す。 フィールド Type Indicatorは、 I S O (International Organization for Standar izat ion) 646に規定された符号化方式で符号化した 4文字からなる文字 列が記述される。 この第 8図の例では、 フィールド type— indicatior に I S〇 646に既定の方式で符号化された 4文字の文字列" Μ0ΒΓが 記述され、 このファイルがファイル" MovieOb ject.bdmv"であることが 示される。
フィールド TypeIndicator2は、 32ビット （4バイト） のデータ長 を有し、 このファイル" MovieOb ject.bdmv"のバージョン番号を示す。 このファイル" MovieObject. bdmv"では、 フィールド TypeIndicator2は 、 I S O 646に規定された符号化方式で符号化した 4文字の文字列 " 0100 "でなければならない。
フィ一ルド ExtensionDataStartAddressは、 3 2ビッ卜のデータ長 を有し、 このシンタクス内にあるブロック1]11^ 611310110 （）の開始 アドレスを示す。 フィールド ExtensionDataStartAddressは、 このフ アイル" MovieObject.bdmv"の最初のバイトからの相対バイト数で、 ブ ロック blkExtensionDataOの開始アドレスを示す。 相対バイト数は、 " 0"から開始される。 若し、 このフィールド ExtensionDataStartAddr essの値が" 0 "であれば、 このファイル" MovieObject.bdmv"内に、 ブ ロック b 1 kEx t ens i onDa t a ()が存在しないことを示す。
なお、 この第 8図に示すシンタクス内のフィールド padding_wordは 、 1 6ピットのデータ長を有し、 このファイル" MovieObject.bdmv"の シンタクスに従い forループ文に値 N1または値 N2で示される回数だけ 挿入される。 値 N1または値 N2は、 0または任意の正の整数である。 ま た、 フィールド padding— wordは、 任意の値を用いることができる。 フィールド ExtensionDataStartAddressに続けてデ一タ長が 2 24 ビットの領域 reservedが配され、 その次に、 このファイル" MovieObje c t . bdiv"の本体であるブロック lkMovieObjec t s 0が格納される。 第 9図は、 ブロック MkMovieObjectsOの一例の構造を表すシン夕 クスを示す。 フィールド Lengthは、 3 2ビットのデータ長を有し、 こ のフィールド Lengthの直後からこのプロック blkMovieObjec ts 0の終 わりまでのデ一夕長を示す。 3 2ビットのデータ長を有する領域 rese rvedを介してフィールド NumberOfMobjsが配される。 フィールド Numbe rOfMobjsは、 直後の forループ文に従い格納されるムービーオブジェ ク卜の数を示す。 forループ文のループ変数として用いられる値]]] obj— idで、 ムービ一オブジェクトが一意に特定される。 値 mobj— idは、 " 0 "から始まる値で、 ムービーオブジェクトは、 forループ文中に記述さ れる順序により定義される。
forループ文中のブロック TerminallnfoOは、 固定値 "1 "が記述され 、 次に 1 5ビットのデータ長を有する領域 reservedが配される。 その 次に、 1 6ビットのデータ長を有するフィールド NumberOfNavigation Commands [mobj— id]が配される。 このフィールド NumberOfNavigationC ommands [mobj— id]は、 値 mobj— idによって指し示されるム一ビ一ォブ ジェクト MovieObject [mobj— id] ()に含まれるナビゲ一ションコマンド (Navigat ionCommand)の数を表す。
次の、 値 command_idをループ変数とする forループ文により、 フィ 一ルド NumberOfNavigationCommands [mobj_id]に示される数だけ、 ナ ピゲーシヨンコマンドが記述される。 すなわち、 この forループ文中 に酉己されるフィーリレド NavigaUonCommand [mobj— id] [command— id]【ま、 値 mob]'_idによって指し示されるブロック MovieObject [mobj— id] 0に 含まれる、 値 co匪 and_idで示される順番のナビゲーションコマンド Na vigationCommandを格納する。 値 command— idは、 0から始まる値で、 ナビゲーションコマンド Navigat ionCommandは、 この forループ文中に 記述される順序で定義される。
第 1 0図は、 プレイリストファイル" xxxxx.mpls"の一例の構造を表 すシンタクスを示す。 フィールド Typelndicatorは、 32ビット （4 バイト） のデータ長を有し、 このファイルがプレイリストファイルで あることを示す。 フィールド TypeIndicator2は、 32ビット （4バイ ト） のデータ長を有し、 このプレイリストファイルのバージョンを示 す。 フィールド PlayListStartAddressは、 32ビットのデータ長を有 し、 このシンタクス中のブロック blkPlayListOの開始ァドレスを示 す。
フィールド PlayListMarkStartAddressは、 32ビットのデ一夕長を 有し、 このシンタクス中のブロック MkPlayListMarkOの開始ァドレ スを示す。 フィールド ExtensionDataStartAddressは、 3 2ビットの データ長を有し、 このシンタクス中のブロック blkExtensionDataOの 開始アドレスを示す。 フィールド ExtensionDataStartAddressは、 ブ ロック blkExtensionDataOの開始アドレスを、 ファイル" xxxxx. mpls" の最初のパイトからの相対パイト数を表した値である。 相対バイト数 は、 " 0"から開始される。 若し、 このフィールド ExtensionDataStart Addressの値が" 0"であれば、 このファイル" xxxxx. mpls"内に、 ブロ ック b 1 kEx t ens i onDa ί a 0が存在しないことを示す。
1 60ビッ卜のデータ長を有する領域 reservedを介してブロック bl kAppInfoPlayList 0が配される。 ブロック blkAppInf oPlayList 0は、 次のブロック blkPlayListOに記述されるプレイリストのタイプ、 再 生制限などの情報が記述される。 ブロック blkPlayListOは、 プレイ リストが記述される。 ブロック blkPlayListMarkOは、 チヤプタジャ ンプなどでジャンプされるポイントが記述される。 ブロック blkExten s i onDat a 0は、 所定の拡張デ一夕を格納可能とするためのブロックで ある。
なお、 この第 10図に示すシンタクス内のフィ一ルド padding_word は、 1 6ビットのデータ長を有し、 このファイル" xxxxx.mpls"のシン タクスに従い forループ文に値 Nl、 値 N2および値 N3で示される回数だ け揷入される。 値 Nl、 値 N2または値 N3は、 0または任意の正の整数で ある。 また、 フィールド padding_wordは、 任意の値を用いることがで きる。
第 1 1図は、 ブロック MkPlayListOの一例の構造を表すシンタク スを示す。 フィールド Lengthは、 32ピットのデータ長を有し、 この フィールド Lengthの直後からブロック blkPlayListOの最後までのデ —夕長を示す。 フィ一ルド Lengthに続けて 1 6ビットのデータ長を有 する領域 reservedが配され、 次にフィールド NumberOfPlayl temsが配 される。 フィールド NumberOfPlayltemsは、 1 6ビットのデータ長を 有し、 このプロック blkPlayList 0に含まれるプレイアイテムの数を 示す。 フィールド NumberOfSubPathは、 このブロック blkPlayList 0に 含まれるサブパスの数を示す。
次の forループ文に従い、 フィ一ルド NumberOfPlayltemsで示される 数だけ、 プレイアイテムが記述されるブロック b 1 kP 1 a y 11 e m 0が記述 される。 forループ文に基づくカウント数がブロック blkPlayltemOの 識別子 Playltem— idとなる。 さらに次の forループ文に従い、 フィール ド Number 0 f SubPa t hで示される数だけ、 ブロック b 1 kSubPat h 0が記述 される。 forループ文に基づくカウント数がブロック blkSubPathOの 識別子 SubPath— idとなる。
なお、 サブパスは、 主として再生されるプレイアイテムに対応する メインパスに対して、 サブプレイアイテムに対応して持つことができ る。 サブパスは、 例えば、 アフレコ用のオーディオデータの指定や、 2枚の映像を合成する際に、 プレイアイテムで指定されるクリップと 同期して再生する副映像を指定するといつた目的で用いられる。
第 1 2図は、 ブロック blkPlayltemOの一例の構造を表すシンタク スを示す。 フィールド Lengthは、 1 6ビットのデータ長を有し、 この フィールド Lengthの直後からブロック blkPlayl temOの最後までのデ —タ長を示す。
フィールド ClipInformationFileName[0]は、 40ビット （5バイト ) のデータ長を有し、 このブロック blkPlayltemOが参照するクリツ プインフォメーションファイルのファイル名が示される。 このプレイ アイテムにおいて、 フィ一ルド ClipInformationFileName[0]で示され るファイル名のクリップインフォメ一ションファイルが読み出される
。 フィールド ClipCodecIdentifier[0]は、 32ビット （4バイト） の データ長を有し、 このブロック blkP yltemOによるプレイアイテム において用いられるクリップ AVストリームのコーデック方式を示す
1 2ピットのデータ長を有する領域 reservedを介して、 フィールド CormectionCoiiditioii}^ffi l 。 フィー レド CoimectionCondition【ま 、 4ビットのデータ長を有し、 クリップ間の接続状態に関する情報を 示す。 記録用途の記録媒体に対しては、 フィールド ConnectionCond it ionの値として " 1"、 " 5"または" 6"が用いられる。 フィールド Conne ctionConditionの値が" 1 "で、 そのクリップと次のクリップとがシー ムレス接続しないことを示し、 フィ一ルド ConnectionConditionの値 が" 5 "または" 6"で、 そのクリップと次のクリップとがシームレス接 続することを示す。 なお、 シームレス接続とは、 クリップと次のクリ ップとがフレームタイミングで連続的に再生されるように、 クリップ 間の再生制御を行うことをいう。
フィールド ConnectionConditionの値が" 5"で、 当該プレイアイテ ムが参照するクリップにおいて、 オーディォデータの記録長がビデオ データの記録長に対して長くされる （第 1 3図 A参照） 。 これにより 、 クリップとクリップとを接続する際に、 ォ一ディォデ一夕のフェイ ドアウト処理が可能とされる。 例えば、 ユーザによる記録停止操作に よりクリツプがクローズされる場合に、 フィ一ルド ConnectionCond it ionの値が" 5"とされる。 以下、 このフィールド ConnectionCondition の値が" 5"で示されるクリップの接続方法を、 第 1のシームレス接続 と呼ぶ。
フィールド ConnectionConditionの値が" 6 "で、 当該プレイアイテ ムが参照するクリップにおいて、 オーディオデータの記録長がビデオ データの記録長に対して同じか若しくは短いくされる （第 1 3図 B参 照） 。 これにより、 クリップとクリップとの接続をシームレスに行う ことが可能とされる。 例えば、 ユーザ操作に応じた記録停止以外の理 由、 例えばシステム要因に基づきクリップがクローズされる場合に、 フィールド ConnectionConditionの値が" 6"とされる。 以下、 このフ ィールド CoimecUonCondiUonの値が" 6"で示されるクリップの接続 方法を、 第 2のシームレス接続と呼ぶ。
フィールド RefToSTCID[0]は、 8ビットのデータ長を有し、 システ ムタイムべ一ス （STC) の不連続点に関する情報を示す。 フィ一ル ド INTimeおよびフィ一ルド OUTTimeは、 それぞれ 32ビットのデータ 長を有し、 メインクリップ AVストリームの再生範囲を示す。 フィー ルド INTimeが開始点 （ I N点） を示し、 フィールド OUTTimeが終了点 (OUT点） を示す。
ブロック MkUOMaskTableOは、 ユーザ入力の受付制限が設定される テーブルである。 1ビットのデ一夕長を有するフラグ PlayltemRandom AccessFlagは、 このブロック blkPlayltemOによるプレイアイテムに
Figure imgf000030_0001
を許可するか否かを規定する。 続けて、 ットのデータ長を有する領域 reservedを介してフィールド StillMode が配される。 フィールド StillModeは、 8ビットのデータ長を有し、 ブロック blkPlayltemOによるプレイアイテムにおいて、 最後に表示 した映像を静止画として表示させるか否かを示す。 フィールド SU11M odeの値が" 0x01" (バイナリ） であれば、 if文に基づき、 1 6ピット のデータ長を有するフィ一ルド StillTinieにより静止時間が示される 。 フィールド StillModeの値が" 0x01"以外であれば、 当該 16ビット のデータ長を有する領域がワードァライメントのために予約された領 域 reservedとされる。
ブロック blkSTNTableOは、 このブロック blkPlayl temOによるプレ ィアイテムが管理しているクリップ AVストリームの属性、 P I D番 号、 記録媒体上での記録位置などが管理される。
第 14図は、 ブロック blkPlayListMarkOの一例の構造を表すシン タクスを示す。 フィールド Lengthは、 32ビットのデ一夕長を有し、 このフィールド Lengthの直後からブロック blkPlayListMarkOの最後 までのデータ長を示す。
フィールド^11111^110 1& 1^31¾^ 3は、 1 6ビットのデータ長を有 し、 このブロック blkPlayListMarkOに含まれるプレイリストマーク の数を示す。 次の forループ文に従い、 フィールド NumberOfPlayListM arksで示される数だけプレイリストマークの情報が記述される。
forル一プ文内において、 8ビットのデータ長を有する領域 reserve に続けてフィールド MarkTypeが配される。 フィールド MarkTypeは、 8 ビットのデータ長を有し、 マークのタイプを示す。 フィールド RefToP layltemIDは、 1 6ビットのデータ長を有し、 マークが打たれるプレ ィアイテムを参照する識別情報 P 1 a y 11 e nし i dが記述される。 フィ一ル ド MarkTimeStampは、 32ビットのデータ長を有し、 マークが打たれ るボイントを示すタイムスタンプが記述される。 フィールド EntryESP IDは、 1 6ビットのデータ長を有し、 マークによって指し示されるェ レメンタリストリームを含んでいる T Sバケツトの P I Dの値を示す 。 フィールド Durationは、 45 k H zのクロックを単位とした計測に よる、 32ビットのデータ長を有する符号無し整数である。 このフィ ールド Durationに格納される値が" 0 "であれば、 このフィールド Dura tionは、 意味を成さない。
第 1 5図は、 クリップインフォメーションファイルの一例の構造を 表すシンタクスを示す。 フィールド Typelndicatorは、 32ビット （ 4バイト） のデータ長を有し、 このファイルがクリップインフォメー シヨンファイルであることを示す。 フィールド TypeIndicator2は、 3 2ビット （4バイト） のデータ長を有し、 このクリップインフォメ一 シヨンファイルのバ一ジョンを示す。
このクリップィンフオメ一ションファイルは、 ブロック blkClipInf o()、 ブロック blkSequenceInfo()、 ブロック blkProgramlnf o 0、 ブロ ック blkCPI 0、 ブロック blkClipMarkOおよびブロック blkExtensionD ata()を有し、 それぞれ 32ビットのデータ長を有するフィールド Seq uencelnfoSt art Address, フィールド ProgramInfoStartAddress、 フィ ールド CPIStartAddress、 フィ一ルド CI ipMarkSta Addressおよびフ ィ一ルド ExtensionDataStartAddressは、 各々対応するブロックの開 始ァドレスを示す。
フィ一ルド ExtensionDataStartAddressは、 このクリツプインフォ メ一シヨンファイルの最初のバイトからの相対バイト数で、 ブロック blkExtensionDataOの開始アドレスを示す。 相対バイト数は、 " 0"か ら開始される。 若し、 このフィールド ExtensionDataStartAddressの 値が" 0"であれば、 このファイル" index, bdmv"内に、 ブロック blkExt ensionDataOが存在しないことを示す。
ブロック MkClipInfoOは、 これらの開始アドレスを示すフィ一ル ドに続く、 96ビットのデータ長を有する領域 reservedの次から開始 される。 ブロック blkClipInfoOは、 このクリップインフォメ一ショ ンファイルが管理するクリップ AVストリームに関する情報が記述さ れる。 ブロック blkSequencelnfoOは、 3丁（：ゃ 1?0 (ァライバル タイムベース） が連続しているシーケンスをまとまりとして管理する 情報が記述される。 ブロック blkProgramlnfoOは、 このクリップイン フオメーシヨンファイルに管理されるクリップ AVストリームの符号 化方式、 クリップ AVストリーム中のビデオデータのァスぺクト比な どの情報が記述される。 ブロック blkCPlOは、 ランダムアクセス開始 点などの、 A Vストリーム中の特徴的な箇所を表す特徴点情報 CP I に関する情報が格納される。
また、 ブロック blkClipMarkOは、 チヤプタ位置などの、 クリップ に付された頭出しのためのインデックス点 （ジャンプポイント） が記 述される。 ブロック MkExtensionDa Oは、 拡張データを格納するこ とができる領域である。 なお、 これらブロック blkClipMarkOおよび クリツプインフォメーションファイル内のプロック blkExtensionData 0は、 この発明との関連性が薄いので、 詳細な説明を省略する。
第 1 6図は、 ブロック！) lkClipInfoOの一例の構造を表すシンタク スを示す。 フィールド Lengthは、 32ビットのデータ長を有し、 この フィールド Lengthの直後からブロック blkClipInfoOの最後までのデ —夕長を示す。 1 6ビットのデ一夕長を有する領域 reservedを介して 、 フィールド ClipStreamTypeが配される。
フィールド ClipStreamTypeは、 8ビットのデータ長を有し、 クリツ プ AVストリ一ムの種別を表す。 このフィールド ClipStreamTypeの値 は、 例えば " 1 "に固定的とされる。 フィールド ApplicationTypeは、 8ピットのデータ長を有し、 クリップ A Vストリーム （拡張子が 「m2 tsj のファイル） がどのような多重化によって作られているかを示す 。 フィールド ApplicationTypeの値が " 1 "で、 対応するクリップ AV ストリームは、 通常の動画が再生される。 続けて 3 1ビットのデータ 長を有する領域 reservedが配される。
デ一夕長が 1ビットのフラグ IsCC5は、 プレイリストにおけるプロ ック blkPUyltemOによって、 対応するクリップと次のクリップとの 接続を、 上述した第 1のシームレス接続、 すなわちフィールド Coimec UonConditionの値が" 5"で示される方法で行うか否かを示す。 フラ グ IsCC5の値が" 1" (バイナリ値） であれば、 クリップ間の接続が第 1のシームレス接続によりなされていることを示す。
フィールド TSRecordingRateは、 クリップ A Vストリームファイル の記録レ一トをバイト /秒で表したものである。 フィールド NumberOf SourcePacketsは、 クリップ AVストリームに含まれるバケツト数を 表す。 システムにより予約された 1024ビットのデ一夕長の領域 re servedを介してブロック TSTypelnfoBlockOが配される。 ブロック TST ypelnfoBiockOは、 クリップ A Vストリームが格納されるパケットの タイプを示す情報が格納される。 このプロック TSTypelnfoBlockOは 、 この発明との関連性が薄いので、 詳細な説明を省略する。
次の if文以下の情報は、 上述のフラグ IsCC5の値が " 1"、 すなわち 、 対応するクリップと次のクリップとの接続を第 1のシームレス接続 で行うとされた場合に記述される。 if文の次の 8ビットのデータ長を 有する領域 reservedを介してフィールド Fol lowingCl ipStreamTypeが 配されるフィールド FollowingClipStreamTypeは、 8ピットのデータ 長を有し、 このクリップインフォメーションフアイルに対応するクリ ップの次のクリップのタイプが記述される。 8ビットのデータ長を有 する領域 reservedを介してフィールド Fol lowingCl ipInformationFi le Nameが配される。
フィー Jレド Fol lowingCl iplnformat ionFi leNameW；、 40ピッ卜 （5 バイト） のデータ長を有し、 このクリップインフォメーションフアイ ルに対応するクリップの次のクリップに対応するクリップインフォメ —シヨンファイルのファイル名が記述される。 次のフィールド ClipCo decldentifierは、 32ビット （4バイト） のデータ長を有し、 当該 次のクリップの符号化方式を示す。 この例では、 フィールド ClipCode cldentiiierは、 I S 0646に既定の方式で符号化された 4文字の 文字列値" M2TS"に固定的とされる。 次に 8ビットのデータ長を有する 領域 reservedが配される。
第 1 7図は、 ブロック MkSequencelnfoOの一例の構造を表すシン タクスを示す。 フィールド Lengthは、 3 2ビットのデ一タ長を有し、 このフィールド Lengthの直後からブロック MkSequencelnfo 0の最後 までのデータ長を示す。 1 5ビッ卜のデータ長を有する領域 reserved を介してデータ長が 1ビットで固定値" 1"が記述される。
次のフィールド SPNATCStartは、 3 2ビットのデータ長を有し、 連 続した時間に記録されたことを表すシーケンス （シーケンス ATCSeque nceと呼ぶ〉 の開始をパケット番号で表す。 この第 1 7図の例では、 フィールド SMATCStartは、 値を" 0"としてクリップ AVストリーム ファイルの先頭と一致させている。 フィ一ルド NumberOfSTCSequence は、 シーケンス ATCSequence上のシーケンス STCSequenceの数を表す。 フィールド NumberOfSTCSequenceは、 値が" 1 "以上とされる。
次の forループ文に従い、 フィールド NumberOfSTCSequenceで示され る数だけ、 シーケンス STCSequenceの情報が記述される。 シーケンス S TCSequenceは、 MP EG 2 T S (Transport Stream)における時間軸 の基準である P C R (Program Clock Reference)が連続な範囲を表す 。 シーケンス STCSequenceには、 クリップ内で一意な番号 STC_idが割 り当てられる。 このシーケンス STCSequence内では、 不連続の無い一 貫した時間軸を定義できるので、 プレイアイテムの開始時刻および終 了時刻を一意に定めることができる。 つまり、 各プレイアイテムの開 始点と終了点は、 同一のシーケンス STCSequenceに存在していなけれ ばならない。 この forループ文においては、 値 stc idによりシ一ケン ス STCSequenceが指定される。
フィールド PCRPIDCstc— id]は、 1 6ビットのデータ長を有し、 MP E G 2 TSにおいて、 P C R (Program Clock Reference)が含まれ る TSバケツトの P I Dを表す。 フィールド SPNSTCS rUstc— id]は 、 32ビットのデータ長を有し、 シーケンス STCSequenceの開始をパ ケット番号で表す。 フィールド PresentationStartTimeおよびフィー ルド Presen tionEndTimeは、 それぞれ 32ビットのデ一夕長を有し 、 クリップ A Vストリーム中の有効な範囲を表す。 フィールド Presen tationS rtTimeおよびフィールド？ 361^& 011811(31 11^で示される範 囲がプレイアイテムから参照できる範囲となる。
第 1 8図は、 ブロック blkProgramlnfoOの一例の構造を表すシン夕 クスを示す。 フィールド Lengthは、 32ビットのデータ長を有し、 こ のフィ一ルド Lengthの直後からブロック blkProgramlnfoOの最後まで のデータ長を示す。 1 5ビットのデータ長を有する領域 reservedを介 して、 データ長が 1ビットで固定値" 1"が記述される。
フィールド SPNProgramSequenceS tartは、 32ビットのデータ長を 有し、 対応するクリップ AVストリームファイルにおいて、 プロダラ ムシーケンスが開始されるソースパケットの番号が記述される。 フィ —ルド ProgramMapPIDは、 1 6ビットのデータ長を有し、 プログラム シーケンスに適用可能なプログラムマップセクションを含むとされて いる T Sパケットの P I Dの値を示す。 フィールド NumberOfStreamsI nPSは、 8ビットのデータ長を有し、 プログラムシーケンスに定義さ れるエレメンタリストリ一ムの数を示す。 フィールド NumberOfStream slnPSに続けて、 8ビットのデ一夕長を有する領域 reservedが配され る。
次の forループ文に従い、 値 [stream— index]をループ変数として、 フィ一ルド NumberOfStreamsInPSで示される数だけ、 フィールド Strea mP ID [stream一 index]およびブロック blkStreamCod inglnfo (stream— ind ex)の組が格納される。 フィールド StreamPID[stream一 index]は、 プロ グラムシーケンスによって参照された PMT (Program Map Table)に 記述されたエレメンタリストリームに対応する P I Dの値を示す。 次 のブロック blkStreamCodinglnfo (st ream— index)は、 対応するフィ一 ルド StreamPID[stream_index]で示されるエレメンタリストリームの 符号化方式に関する情報が記述される。
第 1 9図は、 ブロック blkCPlOの一例の構造を表すシンタクスを示 す。 MPEGストリームのような、 フレーム間圧縮を行っている符号 化ストリームにおいては、 デコード開始可能な箇所は、 GO P (Group Of Picture)の先頭など一部の箇所に限定されていることが多い。 C P I (Characteristic Point Inf ormat ion)とは、 そのデコード可能な 開始点の位置の情報を集めたデータベースで、 再生時刻と、 ファイル 内アドレスとが対応付けられたテーブルになっている。 すなわち、 C P Iは、 デコード単位の先頭位置を示す情報がテーブル化されている このようにデータベースを定めることで、 例えば、 任意の時刻から 再生したい場合、 再生時刻を元に CP Iを参照することによって再生 位置のファイル内アドレスがわかる。 このアドレスは、 デコード単位 の先頭となっているため、 プレーヤは、 そこからデ一夕を読み出して デコードし、 素早く画像を表示することができる。
なお、 この CP Iに格納される、 デコード単位の先頭位置 （この例 では GO Pの先頭位置） を、 EP (Entry Point)エントリと称する。 第 1 9図において、 フィールド Lengthは、 32ビットのデータ長を 有し、 このフィールド Lengthの直後からブロック blkCPlOの最後まで のデ一夕長を示す。 次の if文に従い、 フィールド Lengthの値が 0でな ければ、 1 2ビットのデータ長を有する領域 reservedを介してフィー ルド CPITypeが配される。 フィールド CPITypeは、 4ビットのデータ長 を有し、 CP Iの種類を示す。 次のブロック MkEPMapOは、 対応する クリップ A Vストリームファイルにおける PTS値とバイトアドレス との関連付けを行うテーブルが格納される。
第 2 0図は、 ブロック MkEPMapOの一例の構造を表すシンタクスを 示す。 8ビットのデ一夕長を有する領域 reservedを介してフィールド NumberOfStreamPIDEntriesが配される。 フィール HNumberOf StreamPI DEntriesは、 8ビットのデ一夕長を有し、 ブロック MkEPMap 0におけ るブロック MkEPMapForOneStreamPIDのェントリ数を示す。 forループ 文に従い、 値 [k]をループ変数として、 フィールド NumberOfStreamPID Entriesに示される数だけ、 ェントリボイントに関する情報が記述さ れる。
forループ文内において、 フィールド StreamPIDDt]は、 1 6ビット のデータ長を有し、 ブロック MkEPMapOの中で [k]番目にェントリさ れるブロック MkEPMapForOneStreamPID (以下、 [k]番目のブロック bl kEPMapForOneStreamPIDと記述する） によって参照されるエレメンタ リストリ一ムを伝送するトランスポートバケツトの P I Dの値を示す 。
1 0ビットのデータ長を有する領域 reservedを介してフィール EP StreamType[k]が配される。 フィールド EPStreamType [k]は、 4ビット のデータ長を有し、 [k]番目のブロック blkEPMapForOneStreamPIDによ つて参照されるエレメンタリストリームのタイプを示す。 フィールド NumberOfEPCoarseEntries[k]は、 1 6ビットのデータ長を有し、 [k] 番目のブロック blkEPMapForOneStreamPIDの中にある粗い検索用のサ ブテーブル（EP coarse table)のエントリ数を示す。 フィールド Numbe rOfEPFineEntries[k]は、 1 8ビットのデータ長を有し、 [k]番目のブ 口ック blkEPMapForOneStreamPIDの中にある精密な検索用のサブテ一 ブル（EP fine table)のエントリ数を示す。 フィールド EMapForOneSt reamPIDStartAddress[k]は、 3 2ビットのデータ長を有し、 ブロック blkEPMap 0の中で [k]番目のブロック blkEPMapForOneStreamPIDが始ま る相対バイト位置を示す。 この値は、 ブロック blkEPMapOの第 1バイ ト目からのバイト数で示される。
上述の forループ文による記述の後、 1 6ビッ卜の整数倍のデータ 長を有するパディングヮ一ドを挟んで記述される forループ文に従い 、 値 [k]をループ変数として、 フィールド NumberOfStreamPIDEntries に示される数だけ、 ブロック blkEPMapForOneStreamPID(EPStreamType [k], NumberOfEPCoarseEntries [k], NumberOfEPFineEntries [k])が格 納される。 すなわち、 引数 NumberOfEPCoarseEntries [k]は、 サブテー ブル（EP coarse table)に格納されるエントリ PTSEPCoarseおよびェン トリ SMEPCoarseの数を示す。 同様に、 引数 NumberOfEPFineEntries [k ]は、 サブテーブル（EP fine table)に格納されるエントリ PTSEPFine およびエントリ SMEPFineの数を示す。 以下では、 引数 NumberOfEPCoa rseEntries [k]および引数 NumberOfEPFineEntries [k]を、 それぞれ適 宜、 エントリ数 Ncおよびエントリ数 Nfと呼ぶ。
第 2 1図は、 ブロック blkEPMapForOneStreamPID(EP— stream— type, Nc， Nf)の一例の構造を表すシンタクスを示す。 ブロック blkEPMapFor OneStreamPID(EP_stream_type, Nc, Nf)のセマンティクスを説明する ために、 先ず、 ブロック blkEPMapForOneStreamPID(EP— stream— type, Nc, Nf)に格納されるデータの元となるエントリである、 エントリ PTS EPStartおよびェントリ SPNEPStartの意味について説明する。 ェントリ PTSEPStartと、 ェントリ PTSEPStartに関連付けられたェン トリ SPNEPStartは、 それぞれ A Vストリーム上のェントリポイントを 指す。 そして、 エントリ PTSEPFineと、 エントリ PTSEPFineに関連付け られたェントリ PTSEPCoarseは、 同一のェントリ PTSEPStar tから導か れる。 また、 エントリ SMEPFineと、 エントリ SPNEPFineに関連付けら れたェントリ SPNEPCoarseは.、 同一のェントリ SPNEPStartから導かれ る。
第 2 2図は、 ェントリ PTSEPCoarseおよびェントリ PTSEPFineの一例 のフォーマツトについて示す。 P T Sすなわちエントリ PTSEPS rtは 、 デ一夕長が 3 3ピットの ί直である。 MS Bのビットを第 3 2ビット 、 L S Bのビットを第 0ビットとするとき、 この第 2 2図の例では、 大まかな単位で検索を行う際に用いられるェントリ PTSEPCoarseは、 ェントリ PTSEPStartの第 3 2ビッ卜から第 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 3図は、 ェントリ SPNEPCoarseおよびェントリ SPNEPFineの一例 のフォーマツトについて示す。 ソースバケツト番号すなわちェントリ SPNEPStartは、 デ一夕長が 3 2ビットの値である。 MS Bのビットを 第 3 1ビット、 L S Bのビットを第 0ビットとするとき、 この第 2 3 図の例では、 大まかな単位で検索を行う際に用いられるェントリ SPNE PCoarseは、 ェントリ SPNEPStar tの第 3 1ビットカ ら第 0ビットまで の全てのビットが用いられる。 また、 より精密な検索を行うためのェ ントリ SPNEPFineは、 エントリ SPNEPStartの第 1 6ビットから第 0ビ ットまでの 1 7ビットが用いられる。 エントリ SPNEPFineにより、 例 えば略 2 5 MB (Mega Byte)の AVストリームファイルまでの範囲で 、 検索が可能である。
なお、 ソースパケット番号の場合でも、 エントリ SPNEPCoarseとし て MS B側の所定ビット数の値だけ用いるようにしてもよい。 例えば 、 エントリ SPNEPCoarseとして、 エントリ SPNEPStartの第 3 1ビット から第 1 6ビットまでの 1 7ビットを用い、 エントリ SPNEPFineは、 ェントリ SPNEPStartの第 1 6ビットから第 0ビットまでの 1 7ビット を用いる。
上述に基づき、 ェントリ PTSEPStartおよびェントリ SMEPStartは、 次のように定義される。
エントリ PTSEPStartは、 第 2 2図で示したように、 データ長が 3 3 ビットの符号無し整数であり、 AVストリーム中で、 ランダムァクセ スが可能なピクチャ （例えば I D R (Instantaneous Decoding Refres h)ピクチャや I (Intra)ピクチャ） から開始するビデオアクセスュニ ットの 3 3ビット長の P T Sを示す。
エントリ SPNEPStartは、 第 2 3図で示したように、 3 2ビットの符 号無し整数であり、 ェントリ PTSEPStarUこ関連付けられたビデオァク セスュニットの第 1バイト目を含むソ一スバケツトの、 AVストリー ムの中でのアドレスを示す。 エントリ SPNEPStartは、 ソースパケット 番号の単位で表され、 AVストリームファイル中の最初のソ一スパケ ットから、 値" 0"を初期値として、 ソースパケット毎に 1ずつ増加す る値としてカウントされる。 第 2 1図を参照し、 ブロック blkEPMapForOneStreamP ID (EP— stream— type, Nc, Nf)は、 第 1の forループ文により大まかな単位での検索を 行うためのサブテーブル（EP coarse table)が記述され、 第 2の forル ープ文によりサブテーブル（EP coarse table)の検索結果に基づきよ り詳細な検索を行うためのサブテーブル（EP fine table)が記述され る。
第 1の forル一プ文の直前に、 フィ一ルド EPFineTableS rtAddress が配される。 フィールド EPFineTableStartAddressは、 3 2ビットの データ長を有し、 最初の第 2の forループにおけるフィ一ルド Reserve dEPFine[EP— fine_id]の第 1バイト目の開始アドレスを、 ブロック blk EPMapForOneStreamPID(EP_stream_type, Nc, Nf)の第 1バイト目から の相対バイト数で示す。 相対バイト数は、 値" 0"から開始する。
第 1の forループ文は、 ループ変数 [i]で以て、 サブテーブル（EP co arse table)のエントリ数 Ncまで繰り返され、 エントリ数 Ncの組数だ けフィールド RefToEPFineID[i]、 エントリ PTSEPCoarse [i]およびェン トリ PTSEPFine[i]が格納される。 第 1の forループ文において、 フィ —ルド RefToEPFineID[i]は、 1 8ピットのデ一夕長を有し、 フィール HRefToEPFinelDti]に続くフィ一ルド PTSEPCoarse [i]が示すェントリ PTSEPCoarseに関連付けられるェントリ PTSEPFineを持つ、 サブテープ ル（EP fine table)内のエントリ番号を示す。 エントリ PTSEPFineと、 このェントリ PTSEPFineに関連付けられるェントリ PTSEPCoarseとは、 同一のェントリ PTSEPStartから導かれる。 フィールド Ref ToEPFinelD [ i]は、 第 2の forループ文中で記述される順番で定義されるループ変 数 [EP_fine— id]の値により与えられる。
第 1の forループ文の後に、 パディングワードを挟んで第 2の forル —プ文による記述がなされる。 第 2の forループ文は、 ループ変数 [EP — fine_id]で以て、 サブテ一ブル（EP fine table)のエントリ数 Nfまで 繰り返され、 エントリ数 Nfの組数だけ、 1ビットのデータ長を有する フィールド ReservedEPFine[EP— fine— id]と、 3ビットのデ一夕長を有 するフィールド IEndPositionOffset [EP_fine— id]と、 1 1ビットのデ 一夕長を有するフィールド PTSEPFineDEP— fine— id]と、 1 7ビットの データ長を有するフィールド SPNEPFine[EP_nne_id]とが格納される 。 これらのうち、 フィールド PTSEPFine[EP— fine— id]およびフィール ド SPNEPFine[EP_fine— id]は、 ループ変数 [EP— fine— id]に基づきサブ テーブル（EP fine table)から参照されるエントリ PTSEPFineおよびェ ントリ SPNEPFineそれぞれが格納される。
エントリ PTSEPCoarseおよびエントリ PTSEPFine、 ならびに、 ェント リ SPNEPCoarseおよびエントリ SPNEPFineは、 次のように導かれる。 サ ブテ一ブル（EP fine table)に、 関連するデータ SPNEPStartの値の昇 順に並んでいる Nf個のェントリがあるとする。 それぞれのェントリ SEPFineは、 対応するエントリ PTSEPStartから、 次式 （1) のように 導かれる。
PTSEPFine [EP_fine_id]= (PTSEPStart [EP_fine_id] 》9) / 211 - - (1)
ェントリ PTSEPCoarseと、 対応するェントリ PTSEPFineとの関係は、 次式 （2) 、 (3) の通りである。
PTSEPCoarse[i]= (PTSEPStart [RefToEPFinelD [i] ] 》1 9) / 214 . · (2)
PTSEPFine [RefToEPFineID[i]]= (PTSEPStart [RefToEPFineID[i]] » 9) /2" · · (3)
それぞれのエントリ SMEPFineは、 対応するエントリ SPNEPStartか ら、 次式 （4) のように導かれる。 SPNEPFine[EP_fine_id]=SPNEPStart [EP_f ine_id] / 217 · · (4 )
ェントリ SPNEPCoarseと、 対応するェントリ SPNEPFineとの関係は、 次式 （5) 、 (6) の通りである。
SPNEPCoarse[i]=SPNEPStart [RefToEPFineID[i]] · · (5)
SPNEPFine[RefToEPFineID[i]]=SPNEPStart [RefToEPFineID[i]]/ 21 7 · · (6)
なお、 上述の式 （ 1) 〜 （6) において、 記号 「>>x」 は、 デ一夕 の L S B側から Xビットを超える桁からビットを用いることを意味す る。
次に、 拡張データを格納するためのブロック blkExtensionDataOに ついて説明する。 このブロック blkExtensionDataOは、 所定の拡張デ 一夕を格納可能なように定義され、 ィンデックステーブルが格納され るファイル" index, bdm '、 プレイリス卜が格納されるファイル" xxxxx .mpls"およびクリップィンフオメ一ションファイル" zzzzz. clpi"の各 ファイルに記述することができる。
第 24図は、 ブロック blkExtensionDataOの一例の構造を表すシン タクスを示す。 フィールド Lengthは、 32ビットのデータ長を有し、 このフィールド Lengthの直後からブロック blkExtens ionData 0の終わ りまでのデータ長をバイト数で示す。 このフィールド Lengthの示すデ 一夕長が" 0"でなければ、 if文以下の記述がなされる。
フィールド DataBlockStartAddressは、 32ビットのデ一夕長を有 し、 このシンタクス中の、 拡張データの本体が格納されるブロック Da taBlockOの開始ァドレスを、 このブロック blkExtensionDataOの先 頭バイトからの相対バイト数で示す。 すなわち、 相対バイト数は、 " 0"から開始される。 なお、 フィールド DataBlockStartAddressは、 次 に示す 3 2ビットァライメントの条件を満たさなければならない。 DataBlockStartAddress% 4 = 0
24ビットのデ一夕長を有する領域 reservedを介してフィールド Nu mberOfExtDa Entriesが配される。 フィール HNumberOfExtDataEntr i esは、 8ビットのデータ長を有し、 このブロック blkExtensionDataO のブロック DataBlockOに格納される拡張デ一夕のェントリ数を示す 。 拡張データのエントリは、 拡張データの本体を取得するための情報 が格納される。 この例では、 拡張データのエントリは、 フィールド Ex tDataType. フィールド ExtDataVers ion、 フィールド ExtDataStartAdd ressおよびフィ一ルド ExtDataLengthからなるブロック ext_data_entr y()であって、 ブロック blkExtensionDataOにおいて、 第 1の forル一 プ文に従いこのフィールド NumberOfExtDataEntriesに示される個数だ け、 このブロック ext— data— entry 0が存在する。
フィールド ExtDataTypeは、 1 6ビットのデータ長を有し、 このブ 口ック blkExtensionDataOに記述される拡張データが記録装置用の拡 張データであることを表す。 このフィ一ルド ExtDataTypeの値は、 拡 張デ一夕を識別する第 1の値であり、 このブロック blkExtensionData 0を含む規格書のライセンサ （使用認可者） が割り当てると定義する ことができる。 フィールド ExtDataVersionは、 拡張データを識別する 第 2の値であり、 この拡張データのパージヨン番号を表すものと定義 することができる。 なお、 このブロック blkExtensionDataOにおいて 、 フィ一ルド ExtDataTypeおよびフィールド ExtDataVers ionの値が同 一のブロック ext_data— entryOが 2以上、 存在してはならない。
フィ一ルド ExtDataStartAddressは、 3 2ビットのデータ長を有し 、 このフィールド ExtDataStartAddressが含まれる拡張データのェン トリ （ブロック exし data— entry 0) に対応する拡張データの開始アド レスを示す。 フィールド ExtDataStartAddressは、 ブロック blkExtens ionDataOの先頭バイトからの相対バイト数で、 拡張データ ext— data の開始アドレスを示す。 なお、 フィールド ExtDataS rtAddressは、 次に示す 3 2ビットァライメントの条件を満たさなければならない。 ExtDataStartAddress% 4 = 0
フィールド ExtDataLengthは、 3 2ビットのデータ長を有し、 この フィールド ExtDataStartAddressが含まれる拡張データのェントリ （ ブロック exし da t a_entr iesO) に対応する拡張デ一夕のデータ長を示 す。 データ長は、 バイト数で示される。
フィールド NumberOfExtDataEntriesで示された個数だけ、 拡張デー 夕のエントリ （ブロック ext_data_entry()) が記述されると、 それぞ れ 1 6ビッ卜のデータ長を有し任意のデータ列からなるフィールド pa dding— wordが、 2フィールドを組として任意の回数 L 1だけ繰り返さ れる。 その後、 拡張デ一夕の本体が格納されるブロック DataBlockO が記述される。 ブロック DataBlockOは、 1以上の拡張データが格納 される。 それぞれの拡張データ exし dataは、 上述したフィールド ExtD ataStartAddressフィールド ExtDataLengthに基づき、 ブロック DataBl ockOから取り出される。
第 2 5図は、 ブロック MkExtensionDataOにおける各データの参照 関係を模式的に示す。 フィールド Lengthにより、 フィ一ルド Length直 後の位置からプロック blkExtensionDa Oの最後までのデータ長が示 される。 フィールド DataBlockStartAddressにより、 ブロック DataBlo ck()の開始位置が示される。 フィ一ルド NumberOfExtDataEntriesで示 される個数だけ、 ブロック exし data_entryが記述される。 最後のプロ ック ext— data— entryからブロック DataBlockOの間には、 任意の長さ でフィ一ルド padding_wordが置かれる。 ブロック DataBlockO内には、 ブロック exし data— entry 0で示され る拡張データ ex t—d a t aが置かれる。 それぞれの拡張データ exし d a t aの 位置およびデータ長は、 対応するブロック ext_data_entry()内のフィ —ルド ExtDataStartAddressおよびフィ一ルド ExtDataLengthにより示 される。 したがって、 ブロック DataBlockO内での拡張データ exし dat aの並び順は、 対応するブロック ex t_dat a_entry ()の並び順と一致し ていなくてもよい。
このように、 拡張データを、 拡張デ一夕の本体が格納されるブロッ ク Da t aB lock 0と、 ブロック Da t aB lock 0内の拡張デー夕に対するァク セス情報などが格納されるブロック exし data— entryOとによる 2層構 造とすることで、 複数の拡張デー夕を格納することが可能となる。 次に、 上述の拡張データの一例の作成方法および読み出し方法につ いて説明する。 第 2 6図は、 ブロック blkExtensionDataOにデータを 書き込む際の一例の処理を示すフローチャートである。 この第 2 6図 は、 ブロック blkExtensionDataO中の （n + 1) 番目のエントリとし て、 拡張データを追加し、 ブロック blkExtensionDataOを書き換える 場合の例である。
先ず、 ステップ S 1 0で、 書き込もうとしている拡張データのデ一 夕長を取得し、 フィールド ExtDa Length[n+l]の値にセットする。 な お、 「[n+l]」 の記述は、 （n + 1 ) 番目のエントリの番号に対応す る。 次に、 ステップ S 1 1で、 現在のブロック blkExtensionDataOに 列挙されているブロック exし data_entry()のフィ一ルド ExtDataLengt hおよびフィ一ルド ExtDataStartAddressの値を調べ、 ブロック DataBl ockOの使用状況を取得する。
そして、 次のステップ S 1 2で、 ブロック DataBlockO中に、 書き 込もうとしている拡張データのデータ長であるフィールド ExtDataLen 07059345 gth[n+l]に示されるデ一夕長以上の、 連続した空き領域があるか否か が判断される。 若し、 あると判断されれば、 処理はステップ S 14に 移行される。
一方、 フィールド ExtDataLength[n+l]に示されるデータ長以上の連 続した空き領域が無いと判断されれば、 処理はステップ S 1 3に移行 され、 ブロック blkExtensionDataOにおけるフィ一ルド Lengthの値を 大きくし、 フィールド ExtDataLength[n+l]に示されるデ一夕長以上の 連続した空き領域をプロック DataBlockO内に作る。 空き領域ができ たら、 処理がステップ S 14に移行される。
ステップ S 14では、 拡張デ一夕を書き込む領域の先頭アドレスを 決め、 その先頭ァドレスの値をフィールド ExtDataStartAddress[n+l] とする。 次のステップ S 1 5で、 フィールド ExiDataStartAddress [n+ 1]から、 上述のステップ S 10でセットされたフィールド ExtDa Len gth[n+l]の長さの拡張データ ext_data[n+l]を書き込む。
データの書き込みが終了したら、 ステップ S 1 6で、 ブロック ext— data— entryOに対して、 フィールド ExtDataLength [n+1]と、 フィール ド ExtDa StartAddress i+1]とを追加する。
なお、 上述において、 書き換えを行うブロック blkExtensionDataO は、 すでにディスクなどの記録媒体から読み出されて記録装置のメモ リに記億されているものとする。 そのため、 ステップ S 1 3におけ 、 フィ一ルド Lengthの値の変更によるブロック blkExtensionDataOの 拡大は、 システムに任され、 システムがメモリアロケーションを適切 に行うことでなされる。
第 2 7図は、 ブロック blkExtensionDataOから拡張データを読み出 す際の一例の処理を示すフローチャートである。 なお、 この第 2 7図 のフローチャートによる処理は、 再生専用の記録媒体と、 記録可能な 記録媒体との両方に適用可能なものである。 先ず、 最初のステップ S 2 0で、 読み込もうとする拡張データが準拠する規格から、 フィール ド ExtDataTypeの値を取得し、 ステップ S 2 1で、 読み込もうとする 拡張デ一夕の種別から、 フィールド ExtDataVersionの値を取得する。 次のステップ S 2 2で、 ブロック blkExtensionDataOに列挙されて いるブロック exし data_entry()を 1つずつ順次、 読み込む。 そして、 ステップ S 2 3で、 読み込んだブロック ext—data_entry()に含まれる フィールド ExtDataTypeおよびフィールド ExtDataVers ionの値が、 上 述のステップ S 2 0およびステップ S 2 1で取得したフィールド ExtD a Typeおよびフィールド ExtDataVersionの値と一致するか否かが判 断される。
一致していないと判断されれば、 処理はステップ S 2 6に移行され 、 ブロック blkExtensionDataO内に列挙されるブロック exし data_ent ry()を全て読み終えたか否かが判断される。 全て読み終えたと判断さ れれば、 処理はステップ S 2 7に移行され、 このブロック blkExtensi onDataOには、 読み込もうとした拡張データが存在しないとして、 一 連の処理が終了される。 全て読み終えていないと判断されれば、 処理 はステップ S 2 2に戻され、 次のブロック ext— data— entryOが読み込 まれる。
上述のステップ S 2 3において、 ブロック exし data_entry()に含ま れるフィールド ExtDataTypeおよびフィールド ExtDataVersionの値が 、 取得したフィールド ExtDataTypeおよびフィールド ExtDataVersion の値と一致していると判断されれば、 処理はステップ S 24に移行さ れる。 ここでは、 ブロック blkExtensionDataO中の [i]番目のェント リで一致したものとする。
ステップ S 24では、 [i]番目のェントリのブロック ext— data— entr y()力、らフィ一ルド ExtDataLength[i]の値と、 フィ一ルド ExtDataStar tAddress[i]の値とを読み込む。 そして、 ステップ S 2 5で、 ステツ プ S 24で読み込んだフィールド ExtDa StartAddress[i]で示される ァドレスから、 フィールド ExtDa Length[i]で示されるデータ長だけ 、 データを読み出す。
次に、 上述した、 インデックスファイル" index. bdmv"、 ムービーォ ブジェクトファイル" MovieObject.bdmv"、 プレイリストファイル" xxx xx.mpls"およぴクリップィンフオメ一シヨンフアイル" zzzzz. clpi"に それぞれ定義可能な、 拡張データを格納する拡張デ一タブ口ック blkE xtensionDataOについて説明する。
先ず、 ィンデックスファイル" index, bdmv"に対して定義される一例 の拡張データブロックについて説明する。 ここでは、 プレイリスト毎 に記録可能な記録媒体に特有の属性情報を付加するようにした、 一例 の拡張デ一タブロックについて説明する。 第 2 8図は、 このプレイリ スト属性を記述するための、 ファイル" index. bdmv"内のフィールド bl kExtensionDataOにおけるブロック DataBlockO (第 24図参照） の 一例の構造を表すシンタクスを示す。 この第 2 8図の例では、 ブロッ ク DataBlockOがブロック blklndexExtensionDa Oとして記述されて いる。
先ず、 上述の第 24図を参照して、 ブロック MkExtensionDataOに おいてフィールド ExtDataTypeを値" 0x1000"、 フィ一ルド ExtDataVers ionを値" 0x0100"とする。 これらフィールド ExtDa Typeおよびフィ一 ルド ExtDataVersionに記述された値は、 例えば再生装置側において、 予め ROM (Read Only Memory)などに記憶されたテーブルが参照され て識別される。 ブロック DataBlockO内のフィールド ExtDataStartAdd ressおよびフィールド ExtDa Lengthで示される領域に、 ブロック blk IndexExtensionDataOが格納される。 なお、 数値の記述において" Ox" は、 その数値が 1 6進表記されていることを示す。
ブロック blklndexExtensionDataOにおいて、 フィールド Typelndic atorは、 次に続くデータの種類を示す、 I S〇 646に規定された符 号化方式で符号化した 4文字からなる文字列が記述される。 この第 2 8図の例では、 フィ一ルド Typelndicatorに I S O 646に既定の方 式で符号化された 4文字の文字列 "IDEX"が記述され、 次に続くデータ 種類が 「IndexExtensionData」 であることが示される。
フィ一ルド Typelndicatorに続けて 32ビットのデータ長を有する 領域 reservedが配され、 その次に、 32ビットのデ一夕長を有するフ ィ一ルド TableOfPlayListStartAddressが配される。 フィールド Table OfPlayListStartAddressは、 ブロック blkTableOfPlayList 0の、 この ブロック blklndexExtensionDataO先頭を基準とした開始ァドレスが 示される。
フィールド TableOfPlayListStartAddressの次に、 32ビットのデ 一夕長を有するフィ一ルド Maker sPri vat eDataS tart Addressが配され ブロック blkMakersPrivateDataOのこのプロック blklndexExtensionD at a ()先頭を基準とした開始ァドレスが示され、 1 92ビットのデ一 夕長を有する領域 reservedを介してプロック MkUIAppInf oAVCHD 0が 配される。 1 6ビットのデータ長を有するパディングワード padding— wordが値 N1で示される回数だけ回繰り返され、 次に、 ブロック blkTab leOfPlayListsOが配される。 さらに続けて、 1 6ビットのデータ長 を有するパディンダワード padding_wordが値 N2で示される回数だけ繰 り返され、 次にブロック MkMakersPrivateDataOが配される。 このブ ロック blkMakersPrivateDataOの後に、 1 6ビットのデータ長を有す るパディンダワード padd ing— wor dが値 N3で示される回数だけ繰り返さ れる。
なお、 ブロック blkUIAppInfoAVCHDOおよびプロック blkMakersPriv ateDataOは、 この発明と関連性が薄いので、 説明を省略する。
第 29図は、 上述したブロック blkTableOfPIayListsOの一例の構 造を表すシンタクスを示す。 フィールド Lengthは、 32ビットのデー タ長を有し、 このフィ一ルド Lengthの直後からブロック blkTableOfPl ayListOの最後のバイトまでのデータ長をバイト数で示す。 フィール ド LengtMこ続けて、 プレイバッグタイトルを再生するためのプレイリ ストに関する情報が記述されるプロック MkFirstPlaybackTitlePlayL istsOと、 メニュータイトルに関する情報が記述されるブロック blkM enuTitlePlayListsOとが配される。 これらブロック blkFirstPlaybac kTitlePlayListsOおよびブロック MkMenuTUleP yListsOは、 この 発明と関連性が薄いので、 説明を省略する。
次に、 16ビットのデータ長を有するフィ一ルド NumberOfTitlePla yListPairが配される。 フィールド NumberOfTitlePlayListPairは、 プ レイバックタイトルおよびメニュータイトル以外のタイトルを再生す るためのプレイリストの数が記述される。 次の forループ文に従い、 フィールド NumberOfTitlePlayListPairで示される数だけ、 ブロック b lkMovieTitlePlayLisiPairOが記述される。 ブロック blkMovieTi UeP layListPairOは、 フィールド PlayListFi leName、 フィールド P yLis tAttributeおよびフィールド RefToTitlelDを含む。 すなわち、 ブロッ ク blkMovieT'itlePlayListPairOは、 この forル一プ文で示される [i] 番目のプレイリストについて、 当該プレイリストのファイル名、 当該 プレイリストに付与された属性、 ならびに、 当該プレイリストの参照 タイトル I Dからなるプレイリス卜の情報を構造化したものである。 この forループ文による並び順は、 記録順とされる。 すなわち、 1 のプレイリストが追加されると、 フィールド NumberOfTitleP yListP airの値が 1だけインクリメントされ、 既存のプレイリストの情報の 後ろに、 追加されたプレイリストの情報が追記される。
フィールド PlayListFileNameは、 40ビット （5ノ ィト） のデータ 長を有し、 プレイリストのファイル名が I S O 646に規定された符 号化方式で符号化されて記述される。 フィールド P yListFileNameの 次に、 6ビットのデ一夕長を有する領域 reservedを介してフィールド PlayListAttributeが配される。 フィールド PlayListAttributeは、 2 ピットのデ一夕長を有し、 当該プレイリストに付与された属性を示す 。 プレイリストは、 その成因に基づき、 クリップの生成と共に生成さ れるプレイリストに対応する第 1の種類と、 既存のタイトルあるいは プレイリストの一部または全部を用いて作成されるプレイリストに対 応する第 2の種類と、 メニューを再生するために用いる第 3の種類と の 3種類に分けられ、 各プレイリストには、 プレイリストの種類に応 じて、 それぞれ対応する属性 「Real」 （第 1の種類） 、 属性 「Virtua 1」 （第 2の種類） および属性 「Menu」 （第 3の種類） が付与される なお、 以下では適宜、 属性 「Real」 が付与されたプレイリストをリ アルプレイリスト、 属性 「Virtual」 が付与されたプレイリス卜をバ 一チャルプレイリスト、 属性 「Menuj を付与されたプレイリストをメ ニュープレイリストと呼ぶ。
フィ一ルド RefToTitleldは、 同一ループ内のフィ一ルド PlayListFi leNameに示されるプレイリストが作成時に属するタイトルの I D (番 号） が記述される。 より具体的な例としては、 インデックスファイル " index.bdmv"内のブロック blklndexesOにおける、 対応する値 title— idが記述される。 なお、 当該プレイリストがファーストプレイバック タイトルのみから再生される場合、 フィールド RefToTitleldの値は、 第 1の固定値、 例えば" OxFFFF"とされる。 また、 当該プレイリストが メニュータイトルのみから再生される場合は、 フィールド RefToTiUe Idの値は、 第 2の固定値、 例えば" OxFFFE"とされる。
次に、 仮想プレーヤについて、 概略的に説明する。 上述したような デ一タ構造を有するディスクがプレーヤに装填されると、 プレーヤは 、 ディスクから読み出されたム一ビーオブジェクトなどに記述された コマンドを、 プレーヤ内部のハードウエアを制御するための固有のコ マンドに変換する必要がある。 プレーヤは、 このような変換を行うた めのソフトウェアを、 プレーヤに内蔵される ROM(Read Only Memor y)に予め記憶している。 このソフトウェアは、 ディスクとプレーヤを 仲介してプレーヤに AVCHDフォーマットの規定に従つた動作をさ せることから、 仮想プレーヤと称される。
第 30図 Aおよび第 30図 Bは、 この仮想プレーヤの動作を概略的 に示す。 第 30図 Aは、 ディスクのローデイング時の動作の例を示す 。 ディスクがプレーヤに装填されディスクに対するイニシャルァクセ スがなされると （ステップ S 30) 、 1のディスクにおいて共有的に 用いられる共有パラメ一タが記憶されるレジス夕が初期化される （ス テツプ S 3 1) 。 そして、 次のステップ S 32で、 ムービーオブジェ クトなどに記述されたプログラムがディスクから読み込まれて実行さ れる。 なお、 イニシャルアクセスは、 ディスク装填時のように、 ディ スクの再生が初めて行われることをいう。
第 30図 Bは、 プレーヤが停止状態からユーザにより例えばプレイ キーが押下され再生が指示された場合の動作の例を示す。 最初の停止 状態 （ステップ S 40) に対して、 ユーザにより、 例えばリモートコ ントロールコマンダなどを用いて再生が指示される （UO ： User Ope ration) 。 再生が指示されると、 先ず、 レジス夕すなわち共通パラメ 一夕が初期化され （ステップ S 41) 、 次のステップ S 42で、 ムー ビーオブジェク卜実行フェイズに移行する。
ムービーオブジェクトの実行フェイズにおけるプレイリストの再生 について、 第 3 1図を用いて説明する。 UOなどにより、 タイトル番 号 # 1のコンテンツを再生開始する指示があった場合について考える 。 プレーヤは、 コンテンツの再生開始指示に応じて、 上述した第 2図 に示されるインデックステーブル（Index Table)を参照し、 タイトル # 1のコンテンツ再生に対応するォブジェクトの番号を取得する。 例 えばタイトル # 1のコンテンツ再生を実現するォブジェクトの番号が # 1であったとすると、 プレーヤは、 ムービーオブジェクト # 1の実 行を開始する。
この第 3 1図の例では、 ムービーオブジェクト # 1に記述されたプ ログラムは 2行からなり、 1行目のコマンドが" Play PlayList (1)"で あるとすると、 プレーヤは、 プレイリスト # 1の再生を開始する。 プ レイリスト # 1は、 1以上のプレイアイテムから構成され、 プレイァ ィテムが順次再生される。 プレイリスト # 1中のプレイアイテムの再 生が終了すると、 ムービーオブジェクト # 1の実行に戻り、 2行目の コマンドが実行される。 第 3 1図の例では、 2行目のコマンドが"]' uni p MenuTitle"であって、 このコマンドが実行されインデックステープ ルに記述されたメニュータイトル（MenuTitle)を実現するム一ビ一ォ ブジェクトの実行が開始される。
次に、 この発明の実施の一形態について説明する。 この発明では、 映像信号の記録開始から記録終了までを 1つの記録単位として定義し 、 この 1記録単位の区間に生成されるビデオデ一夕からなるストリー ムを 1つのストリームファイルとして記録媒体に記録する。 このスト 2007/059345 リームファイルには、 映像信号の記録に伴い記録される音声信号を含 むことができる。 この 1記録単位に対応するストリームファイルに基 づきクリップが構成される。
また、 この発明の実施の一形態では、 1つのクリップを 1つのプレ ィアイテムから参照し、 クリップが生成される毎に、 生成されたクリ ップを参照するプレイアイテムを順次、 プレイリストに対して追加す る。 このとき、 プレイリストにおいて、 プレイアイテム毎すなわちク リップ毎にプレイリストマークを打つ。 そして、 例えば 1の記録媒体 に 1のプレイリストのみが存在するようにする。 これに限らず、 ディ スク上に複数のプレイリストを存在させてもよい。
第 3 2図は、 この発明の実施の一形態に適用可能な記録装置の一例 の構成を概略的に示す。 この記録装置は、 入力されたディジタルビデ ォデータおよびディジタルオーディォデータを、 所定の方式で圧縮符 号化および多重化した A Vストリームを記録媒体に記録するようにし ている。 圧縮符号化および多重化の方式としては、 例えば上述した A V C H Dフォ一マツトが適用できる。
この第 3 2図に例示される記録装置は、 外部から入力されるビデオ デ一夕およびオーディオデータを記録媒体に記録する、 単独の記録装 置として用いることもできるし、 光学系や撮像素子などを備えたカメ ラブロックと組み合わせ、 撮像した撮像信号に基づくビデオデータを 記録媒体に記録する、 ビデオ力メラ装置の記録プロックとして用いる こともできる。
適用可能な圧縮符号化や多重化の方式としては、 様々に考えられる 。 例えば、 H . 2 6 4 I A V Cに規定される方式を、 この発明の実施 の一形態の圧縮符号化として適用することができる。 これに限らず、 M P E G 2方式に基づき圧縮符号化を行うようにしてもよい。 また、 多重化方式は、 例えば MP E G 2システムズを適用することができる 。 以下では、 ビデオデータの圧縮符号化を H. 2 64 I AVCに規定 される方式に準じて行い、 ビデオデータおよびオーディオデータの多 重化を、 MP E G 2システムズに規定される方式に準じて行うものと して説明する。
制御部 30は、 例えば C PU(Central Processing Unit), RAM( Random Access Memory)および R OM (Read Only Memory)など力 らな り （図示しない） 、 ROMに予め記憶されたプログラムやデータに基 づき、 RAMをワークメモリとして用いてこの記録装置の記録部 1 0 の各部を制御する。 なお、 制御部 1 0と記録部 1 0の各部とを接続す る経路は、 繁雑さを避けるために、 第 32図では省略している。
U I (User Interface)部 3 1は、 この記録装置の動作をユーザが操 作するための操作子が所定に設けられ、 操作子に対する操作に応じた 制御信号を出力する。 この制御信号は、 制御部 30に供給される。 制 御部 30は、 ュ一ザ操作に応じて U I部 3 1から供給された制御信号 に基づきなされるプログラムの処理により、 記録部 1 0の各部の動作 を制御する。 例えば、 U I部 31に対してなされた操作に応じて、 記 録装置による記録動作の開始および停止の動作が制御部 30により制 御される。
ベースバンドのディジタルビデオデータが端子 40から入力される
。 また、 当該ディジタルビデオデータに伴い、 ベースバンドのデイジ タルオーディォデータが端子 41から入力される。
ディジタルビデオデ一夕は端子 40から記録部 1 0に入力され、 ピ デォエンコーダ 1 1に供給される。 ビデオエンコーダ 1 1は、 供給さ れたディジタルビデオデ一夕を、 所定の方式で以て圧縮符号化する。
MP EG4 AVC I H. 264に規定される方式に準じて圧縮符号 化がなされるこの例では、 例えば、 DCT (Discrete Cosine Transfo rm)と画面内予測とによりフレーム内圧縮を行うと共に、 動きべクト ルを用いたフレーム間圧縮を行い、 さらにェントロピー符号化を行い 圧縮効率を高める。 ビデオエンコーダ 1 1で圧縮符号化されたデイジ タルビデオデータは、 MP EG4のエレメンタリストリ一ム （E S) として、 マルチプレクサ （MUX) 1 3に供給される。
ディジタルオーディオデータは端子 41から記録部 1 0に入力され 、 オーディオエンコーダ 1 2に供給される。 オーディオエンコーダ 1 2は、 所定の圧縮符号化方式、 例えば A AC (Advanced Audio Coding )により圧縮符号化される。 オーディオデータの圧縮符号化方式は、 AACに限られるものではない。 オーディォデ一夕を圧縮符号化せず 、 ベースバンドのデータのまま用いることも考えられる。 圧縮符号化 されたディジタルオーディオデータは、 マルチプレクサ 1 3に供給さ れる。
マルチプレクサ 1 3は、 それぞれ圧縮符号化されて供給されたディ ジタルビデオデータおよびディジ夕ルオーディォデータを所定の方式 で多重化し、 1本のデータストリームとして出力する。 MPEG2シ ステムズに準じて多重化が行われるこの例では、 MPEG 2のトラン スポートストリームを用いて、 供給された圧縮ビデオデータおよび圧 縮オーディオデータを時分割で多重化する。 例えば、 マルチプレクサ 1 3は、 バッファメモリを有し、 供給された圧縮ビデオデータおよび 圧縮オーディォデ一夕をバッファメモリに溜め込む。
バッファメモリに溜め込まれた圧縮ビデオデータは、 所定サイズ毎 に分割されヘッダが付加されて、 P E S CPacketized Elementary Sir eam)パケット化される。 圧縮オーディオデータも同様に、 所定サイズ 毎に分割されへッダが付加されて P E Sパケット化される。 ヘッダに は、 パケットに格納されるデ一夕の再生時刻を示す PTSゃ復号時刻 を示す DT S (Decoding Time Stanp)といった、 MP E G 2システム ズに規定される所定の情報が格納される。 PESパケットは、 さらに 分割されてトランスポートパケット （TSパケット） のペイロードに 詰め込まれる。 T Sパケットのヘッダには、 ペイロードに詰め込まれ たデータを識別するための P I D (Packet Ident i fication)が格納さ れる。 マルチプレクサ 1 3から出力された TSパケットは、 ストリ一 ムバッファ 14に一旦溜め込まれる。
なお、 TSパケットは、 実際には、 マルチプレクサ 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は、 例えば C PU、 ワークメモリとしての RA Mおよびプログラム所定のデータが予め記憶される ROMからなる 、 図示しない） 。 これに限らず、 管理情報処理部 1 6は、 例えば制御部 30におけるプログラム処理で管理情報処理部 1 6の機能を実現する ことも可能である。 この場合、 例えば制御部 30の有する RAMが揮 発性メモリ 1 7として用いられると共に、 不揮発性メモリ 18が制御 部 30に接続される。
管理情報処理部 1 6は、 記録デ一夕に基づき、 揮発性メモリ 1 7を ワークメモリとして用いて、 上述したィンデックスファイル" index, b dmv"、 ムービーオブジェクトファイル" MovieObject.bdmv"、 プレイリ ストファイル" xxxxx.mpls"およびクリップインフォメーションフアイ ル" zzzzz.clpi"に格納するための情報を生成する。 生成された情報は 、 所定のタイミングで記録媒体 20に書き込まれる。
一例として、 管理情報処理部 1 6は、 マルチプレクサ 1 3から記録 データの時間情報を取得すると共に、 記録制御部 1 5から記録データ の記録媒体 20に対するアドレス情報を取得し、 取得されたこれら時 間情報およぴァドレス情報に基づき E P— m a p情報が生成される。 また、 U I部 3 1に対する記録開始、 記録終了の操作に応じて制御部 30から出力される制御信号と、 マルチプレクサ 1 3および記録制御 部 1 5からの記録データに関する情報とに基づき、 プレイリストファ ィル" xxxxx.mpls"の生成または更新、 クリップィンフオメーションフ アイル" zzzzz.clpi"の生成などが行われる。 さらに、 記録媒体 20に 対して新規に記録が行われる際には、 インデックスファイル" index, b dmv"やムービーオブジェクトファィル"¾10^601)】6(^ (111^"の生成また は更新が行われる。
次に、 この発明の実施の一形態によるクリップの記録方法について 説明する。 第 33図は、 この発明の実施の一形態によるクリップの一 例の記録方法を示すフローチャートである。 このフロ一チャートによ る処理に先立って、 記録媒体 20には、 クリップと、 当該クリップを 再生するための再生制御情報が格納されファイル （クリップィンフォ メ一シヨンファイル、 プレイリストファイル、 ム一ビ一オブジェクト ファイルおよびインデックスファイルなど） とが既に記録媒体 2 0上 に記録されているものとする。
ステップ S 5 0で記録開始操作が行われると、 次のステップ S 5 1 で、 クリップ A Vストリームの記録媒体 2 0への記録が開始される。 記録開始操作は、 例えば次のようになされる。 例えば、 U I部 3 1 に、 記録開始を指示する記録開始スィッチと、 記録停止を指示する記 録停止スィッチとが設けられる。 ステップ S 5 0では、 ュ一ザによつ て記録開始スィッチが操作される。 この操作に応じて、 記録開始を指 示する制御信号が U I部 3 1から出力され、 制御部 3 0に供給される 。 制御部 3 0は、 この記録開始を指示する制御信号に基づき、 記録部 1 0の各部に対し、 端子 4 0から入力されるベースバンドのビデオデ —夕と、 端子 4 1から入力されるべ一スバンドのオーディオデータと を記録媒体 2 0に記録するように制御する。
記録開始に関わる制御部 3 0の制御の一例として、 記録停止状態で はビデオエンコーダ 1 1およびオーディオエンコーダ 1 2の動作を停 止させておき、 記録開始の指示に応じて、 これらビデオエンコーダ 1 1およびオーディオエンコーダ 1 2の動作を開始させることが考えら れる。 これに限らず、 マルチプレクサ 1 3やストリ一ムバッファ 1 4 、 記録制御部 1 5の動作の開始、 停止を制御することで、 記録開始お よび停止の制御を行うこともできる。
記録開始の制御に応じて、 クリップ A Vストリームが記録媒体 2 0 に記録される （ステップ S 5 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. ni2 t s"であるクリツ プ A Vストリ一ムファイルが記録されている場合には、 新たに記録さ れるクリップ A Vストリームファイルのファイル名として既に記録さ れているファイルと重複しないファイル名が選ばれ、 例えばファイル 名" 00002. m2 t s"とされる。
なお、 クリップ A Vストリームの記録媒体 2 0への記録に伴い、 管 理情報処理部 1 6により、 記録されるデータの再生時間とアドレスと の対応関係を示す情報がリアルタイムに生成される。 このデータは、 上述したクリップィンフオメ一ションファイル" zzzzz. c lpi"内のブロ ック b lkEPMap Oに格納されるデータとして、 揮発性メモリ 1 7に記憶 される。 当該データのバックアップとして、 不揮発性メモリ 1 8にも 同一のデータを記憶することもできる。
次のステップ S 5 2で、 記録停止操作が行われたか否かが判断され る。 例えば、 ユーザにより U I部 3 1に設けられた記録停止スィッチ が操作され、 記録が停止されたと判断されれば、 処理はステップ S 5 3に移行される。 一方、 記録が停止されていなければ、 処理はステツ プ S 5 1に戻され、 クリップ A Vストリームの記録媒体 2 0への記録 が継続される。
ステップ S 5 3では、 記録の停止に伴い、 ストリームバッファ 1 4 に溜め込まれているストリームが全て記録媒体 20に書き込まれる。 例えば、 記録制御部 1 5は、 制御部 30からの記録停止の命令に応じ て、 ストリームバッファ 14に溜め込まれているストリーム （TSパ ケット） を全て読み出し、 記録媒体 20に書き込む。
また、 記録停止の命令に応じて、 例えばビデオエンコーダ 1 1およ ぴオーディオエンコーダ 1 2の動作が停止される。 このとき、 第 1 3 図 Aを用いて説明した第 1のシームレス接続を行うために、 例えば、 オーディオエンコーダ 1 2の動作がビデオエンコーダ 1 1の動作が停 止してから所定時間後に停止されるように制御される。
次のステップ S 54〜ステップ S 58で、 管理情報処理部 1 6によ り、 記録媒体 20に書き込まれたクリップ AVストリームファイルに 関するクリップインフォメーションファイルが生成されると共に、 プ レイリストファイルの更新が成される。
先ず、 ステップ S 54で、 管理情報処理部 1 6により、 クリップィ ンフオメ一ションファイル" zzzzz. clpi"が生成される。 ファイル名は 、 例えばこのクリップインフォメーションファイルが示すクリップ A Vストリームファイルのファイル名と対応するファイル名とされ、 当 該クリップ AVストリームファイルのファイル名が" 00002. ffl2ts"であ れば、 このクリップインフォメーションファイルのフアイル名は、 拡 張子より前の部分が同一のファイル名" 00002. clpi"とされる。
クリップインフォメーションファイル" 00002. clpi"に、 第 1 5図〜 第 2 1図に例示した各シンタクスに従い、 各フィールドやフラグの値 が所定に設定され格納される。 一例として、 TSパケットに関する情 報や、 再生時間 （PTS) に関する情報は、 管理情報処理部 1 6によ り、 クリップの記録中にマルチプレクサ 1 3から取得された情報に基 づき生成される。 また、 記録媒体 2 0上の記録アドレスに関する情報 P T/JP2007/059345 は、 管理情報処理部 1 6により、 クリツプの記録中に記録制御部 1 5 から取得された情報に基づき生成される。 システムにより固有の値は
、 例えば予め ROM (図示しない） などに記憶されている情報に基づ く。 さらに、 再生時間とアドレスとの対応関係を示す上述したブロッ ク blkEPMapOの情報が、 クリップインフォメーションファイル" 00002 • clpi"のブロック blkCPlOに格納される。
また、 ブロック blkClipInfoO内のフラグ IsCC5は、 ユーザ操作によ りクリップの記録が停止された場合、 値が 1 (バイナリ値） とされる 。 それに伴い、 ブロック MkClipInfoO内の if文 （第 1 6図参照） で 示されるデータが所定に設定される。
クリップィンフオメーションファイルの作成が完了したら、 処理は 次のステップ S 5 5に移行する。 ステップ S 5 5〜ステップ S 58の 処理は、 プレイリストファイルに関する処理である。 このステップ S 5 5〜ステップ S 58の処理により、 既に記録媒体 20上に存在する プレイリストファイルに対して、 新たに記録されたクリップ AVスト リームファイル" 00002. m2ts"に対応するプレイアイテムが追加される 先ず、 ステップ S 55で、 プレイリストファイル内のブロック blkP yl t em ()におけるフィールド Connec t i onCond i t i onの値が 5に設定さ れ、 このクリップが次のクリップと第 1のシームレス接続を行うこと が示される （第 1 2図参照） 。 次にステップ S 56で、 プレイアイテ ムファイルのフィールド NumberOfPlayltemsの値が 1だけィンクリメ ントされ、 当該プレイリストに対してプレイアイテムが 1つ、 追加さ れることが示される （第 1 1図参照） 。
次のステップ S 57で、 ブロック blkPlayltemOにおけるフィ一ル ド ClipInformaUonFileNanie、 フィールド INTimeおよびフィールド OUT Timeがそれぞれ設定され、 クリップの記録に伴い追加されるブロック blkPIayltemOが作成される。 フィールド CI iplnformat ionFi leNameは 、 上述のステップ S 5 5で作成されたクリップインフォメーションフ アイルのファイル名" 00002. clpi"が格納される。 実際には、 クリップ インフォメーションファイルの拡張子は固定的とされているので、 ピ リオドの前の部分" 00002"が格納される。 フィールド INTimeおよびフ ィールド OUTTimeは、 対応するクリップ AVストリームファイル" 0000 2.m2ts"に格納されるビデオストリームの先頭および終端の時間を示 す情報であって、 例えばクリップインフォメ一ションファイル" 00002 . c lpi"内のブロック b lkCPI 0におけるブロック b IkEPMap ()の情報に基 づく。
次のステツプ S 58で、 プレイリストファイル内のプロック blkPla yL i s t Mark 0におけるフィールド Numb e r 0 f P 1 ayL i s t Marksの値が 1だけ インクリメントされ、 それに伴い forループ文内に追加されたフィ一 ルド MarkTimeStampの値が、 上述のステップ S 5 7でブロック blkPlay ItemOにおけるフィールド INTimeの値に設定される。 すなわち、 新た に記録されたクリップの先頭に、 プレイリストマークが打たれる。 このようにして、 新たに記録されたクリップ AVストリームフアイ ル" 00002.m2ts"に対して、 クリップィンフオメ一ションファイル" 000 02.clpi"が作成されると共に、 既存のプレイリストファイルが更新さ れる。
なお、 上述したステップ S 5 3によるストリームバッファ 14に溜 め込まれたデータの記録媒体 2 0への書き込み処理は、 ステップ S 5 8の処理の後に行うようにしてもよい。
記録が停止された状態から、 U I部 3 1に対する記録開始操作を行 うことで、 再びステップ S 50からの処理が開始され、 新たなクリツ プ A Vストリームファイルの記録媒体 2 0への記録と、 対応するクリ ップインフォメ一ションファイルの作成、 作成されたクリッブインフ オメーションファイルを参照するプレイアイテムの生成、 ならびに、 生成されたプレイアイテムのプレイリストへの追加処理が同様にして 行われる。
なお、 一旦記録が停止されてから次の記録が開始される場合、 上述 したステップ S 5 4で作成したクリップィンフオメーシヨンファイル の記録媒体 2 0への書き込みが終了するまで、 次のクリップ A Vスト リームファイルの記録は、 開始しないようにする。
この場合、 記録が停止されてから次の記録を開始できない可能性が ある。 これを避けるために、 例えばクリップインフォメーションファ ィルを生成するためにワークメモリとして用いた揮発性メモリ 1 7に 、 当該クリップインフォメーションファイルを保持しておき、 例えば ディスクイジェクト時ゃ記録装置の電源 O F F時など所定のタイミン グで揮発性メモリ 1 7に保持されているクリップインフォメーション ファイルを記録媒体 2 0に書き込むことが考えられる。
なお、 ここでは、 記録媒体 2 0上に既にクリップ A Vストリームフ アイルと、 対応するクリップインフォメーションファイルおよびプレ ィリストファイルが記録されている状態で、 次のクリップ A Vス卜リ ームファイルを記録する例について説明したが、 第 3 3図のフローチ ャ一トを用いて説明した処理は、 記録媒体 2 0に最初のクリップ A V ストリームファイルを記録する際にも、 適用可能なものである。
ここで、 A V C H Dフォーマットによれば、 クリップ A Vストリ一 ムファイルを参照するプレイアイテムが格納されるプレイリストファ ィルと、 当該プレイリストファイルを呼び出すコマンドがムービーォ ブジェクトとして記述されたムービーオブジェクトファイルと、 ムー ピーオブジェク卜ファイル中のムービーオブジェクトをタイトルとし て呼び出すィンデックスファイルとが必要とされる。 記録媒体 20に 対して最初のクリップ AVストリームファイルを記録した際に、 これ らインデックスファイルおよびムービーオブジェクトファイルを自動 的に作成されるようにできる。
第 34図は、 上述の第 33図の手順に従い作成された一例のフアイ ル構造を示す。 一例として、 記録媒体 20に対して、 最初のクリップ AVストリームファイル" 00001. m2ts"が記録され （ステップ S 50〜 ステップ S 5 3) 、 対応するクリップインフォメーションファイル" 0 OOOl.clpi"が作成される （ステップ S 54) 。
クリップ AVストリームファイル" 00001.m2ts"およびクリップィン フオメ一ションファイル" 00001. cipi"の記録および作成に応じて、 次 に、 当該クリップインフォメ一ションファイル" 00001. clpi"を参照す るプレイアイテム # 1の情報が生成されると共に、 当該プレイアイテ ム# 1を格納するプレイリストファイルが作成される (ステップ S 5 5〜ステップ S 58) 。 また、 プレイリストファイルに対し、 プレイ アイテム # 1のフィールド INTimeに対応する時刻にプレイリストマ一 ク Mark#lが打たれる （ステップ S 58) 。
なお、 最初のクリップ AVストリームファイル" 00001. m2ts"の記録 に伴い、 プレイリスト # 1を呼び出すムービーオブジェクト # 1が記 述されるムービーオブジェクトファイルと、 ムービーオブジェクト # 1をタイトル # 1として選択および再生させるためのインデックスフ アイルを作成するようにできる。 ムービーオブジェクトファイルおよ びインデックスファイルは、 テンプレートを予め作成しておき、 それ を更新するようにもできる。 これらム一ビーオブジェクトファイルお よびィンデックスファイルの作成については、 この発明の主旨と関連 性が薄いので、 詳細な説明を省略する。
次に記録開始操作がなされると、 記録媒体 2 0に対して、 クリップ A Vストリームファイル" 00002. m2 t s"と、 対応するクリップインフォ メーションファイル" 00002. c lpi"とが追加して記録される （ステップ S 5 0〜ステップ S 5 3、 ならびに、 ステップ S 5 4 ) 。 クリップ A Vストリームファイル" 00002. m2 t s"およびクリップィンフオメーショ ンファイル" 00002. c lpi"の記録および作成に応じて、 次に、 当該クリ ップィンフオメーションファイル" 00002. c lpi"を参照するプレイアイ テム # 2が生成される。 この生成されたプレイアイテム # 2は、 既に 作成されているプレイリストファイルに対して追加される。 さらに、 プレイリストファイルに対し、 プレイアイテム # 2のフィールド INTi meに対応する時刻にプレイリストマーク Mark#2が打たれる （ステップ S 5 8 ) 。
このようにして、 1組の記録開始操作および記録停止操作により 1 個のクリップ A Vストリームファイルが記録媒体 2 0に記録され、 そ れに伴い、 当該クリップ A Vストリームファイルに対応するクリツプ インフォメーションファイルが作成される。 また、 当該クリップイン フオメーションファイルを参照するプレイアイテムが生成されて既存 のプレイリストに対して追加され、 当該プレイアイテムのフィールド INTimeで示される時刻にプレイリストマークが打たれる。 これら一連 の処理が記録開始操作および記録停止操作の組毎に、 繰り返される。 また、 第 3 4図に例示されるファイル構造から分かるように、 記録 開始操作および記録停止操作の組の繰り返しにより記録される複数の クリップ A Vストリームファイルのそれぞれを参照する複数のプレイ アイテムは、 1つのプレイリストファイルに、 クリップ A Vストリー ムファイルの記録に伴い順次、 追加して格納される。 このプレイリス トは、 ムービーオブジェク卜ファイル内の 1つのムービーオブジェク トから呼び出され、 このムービ一オブジェクトは、 インデックスファ ィルから 1つのタイトルとして選択および再生される。 したがって、 一連の記録開始操作および記録停止操作の組の繰り返しにより記録さ れる複数のクリップ A Vストリームファイルは、 インデックスフアイ ル上で、 1つのタイトルとして管理されることになる。
次に、 この発明の実施の一形態の他の例について説明する。 上述で は、 この発明が単体の記録装置に適用された例について説明した （第 3 2図参照） 。 これに対し、 この実施の一形態の他の例では、 この発 明を、 撮像素子と、 被写体からの光を撮像素子に入射させる光学系と を有し、 撮像素子で撮像された撮像信号に基づきビデオデータを記録 媒体に記録するようにした、 ビデオ力メラ装置に適用した。
第 3 5図は、 この発明の実施の一形態の他の例によるビデオカメラ 装置 1 0 0の一例の構成を示す。 ビデオカメラ装置 1 0 0において、 記録系の構成は、 第 3 1図を用いて説明した記録装置の構成を略その まま適用できるので、 第 3 1図と共通する部分には同一の符号を付し 、 詳細な説明を省略する。
第 3 5図の構成において、 カメラ部 5 0は、 映像信号に関する構成 として、 光学系 5 1、 撮像素子 5 2、 撮像信号処理部 5 3、 カメラ制 御部 5 4および表示部 5 5を有し、 音声信号に関する構成として、 マ イク口フォン （M I C ) 5 6および音声信号処理部 5 7を有する。 制 御部 3 0は、 カメラ部 5 0の各部との間で各種制御信号や情報のやり とりを行い、 カメラ部 5 0の動作を制御する。 また、 制御部 5 0は、 ユーザ操作に応じて U I部 3 1から供給される制御信号に基づき、 力 メラ部 5 0の動作を制御する。
なお、 ビデオカメラ装置 1 0 0として構成される場合、 記録開始操 2007/059345 作および記録停止操作は、 例えば、 U I部 3 1に設けられた単一の記 録スィツチを用い、 当該記録スィツチが押下される毎に記録開始およ び記録停止が交互に指示されるようになされるのが一般的である。 ま た、 このビデオカメラ装置 1 0 0では、 記録媒体 2 0として、 B l u - r a y D i s cや記録可能なタイプの D V Dといった、 ディスク 記録媒体を適用するものとする。
カメラ部 5 0において、 光学系 5 1は、 被写体からの光を撮像素子 5 2に導くためのレンズ系、 絞り調整機構、 フォーカス調整機構、 ズ ーム機構、 シャツ夕機構などを備える。 絞り調整機構、 フォーカス調 整機構、 ズーム機構およびシャツ夕機構の動作は、 制御部 3 0から供 給される制御信号に基づき、 カメラ制御部 5 4により制御される。
撮像素子 5 2は、 例えば C C D (Charge Coupl ed Devi ce)からなり 、 光学系 5 1を介して照射された光を光電変換により電気信号に変換 し、 所定の信号処理を施し撮像信号として出力する。 撮像信号処理部 5 3は、 撮像素子から出力された撮像信号に対して所定の信号処理を 施し、 ベースバンドのディジタルビデオデ一夕として出力する。
例えば撮像信号処理部 5 3は、 撮像素子 5 2から出力された撮像信 号に対して、 C D S (Correl ated Doub l e Sa即 1 ing)回路により画像情 報を有する信号だけをンプリングすると共に、 ノイズを除去し、 A G C (Au to Gain Cont ro l)回路によりゲインを調整する。 そして、 Aノ D変換によりディジタル信号に変換する。 また、 撮像信号処理部 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 iqui 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に供給される。
記録停止状態から 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ストリームファイルに対応するクリップィンフオメーション ファイルを作成する。 また、 管理情報処理部 1 6は、 当該クリップィ ンフオメーションファイルを参照するプレイアイテムを生成し、 既に プレイリストが存在する場合には、 生成されたプレイアイテムを当該 プレイリストに対して追加すると共に、 プレイリストに対してプレイ リストマークを打つ。
この状態からもう一度記録スィツチが押下されると、 再び記録開始 が指示され、 新たなクリップ A Vス卜リームファイルの記録媒体 2 0 への記録が開始されると共に、 対応するクリップインフォメーション ファイルの作成や、 当該クリップインフォメーションファイルを参照 するプレイアイテムの生成、 生成されたプレイアイテムのプレイリス トへの追加などの処理が行われる。 クリップ A Vストリームファイル 間の再生は、 第 1のシームレス接続により接続される。
なお、 記録停止に伴い作成されるクリップインフォメーションファ ィルを、 作成直後から記録媒体 2 0に書き込む方式の場合は、 直前に 作成されたクリップインフォメ一ションファイルの記録媒体 2 0への 書き込みが終了するまで、 次の記録が開始されないように制御される この実施の一形態の他の例のように、 この発明をビデオカメラ装置
1 0 0に適用する場合、 1の記録媒体 2 0に対して、 プレイリストフ アイルは 1ファイルのみが存在できるように制限することが考えられ る。 すなわち、 編集処理などがなされない限り、 1の記録媒体 2 0上 には、 当該プレイリストの再生を行うための 1のタイトルしか存在し ないようにする。 こうすることで、 記録媒体 2 0としてディスクを用 いたビデオカメラ装置 1 0 0を、 恰も従来の磁気テープを記録媒体に 用いたビデオカメラ装置であるかのように扱うことができる。
すなわち、 この実施の一形態の他の例によれば、 それぞれ個別に記 録されるクリップ A Vストリームファイルが 1のプレイリストにより 管理され、 各クリップ A Vストリームファイル間の再生が第 1のシ一 ムレス接続で接続されるため、 記録媒体 2 0に記録された全てのクリ ップ A Vストリームファイルを、 磁気テープを再生する場合のように 、 連続的に再生することができる。 また、 プレイリストに対し、 それ ぞれ個別に記録されるクリップ A Vストリームファイルの先頭に対応 する位置にプレイリストマークが打たれているため、 クリップ単位で の検索が容易である。
なお、 上述では、 第 3 1図に示す記録装置や第 3 5図に示すビデオ カメラ装置 1 0 0の記録部 1 0がハードウェア的に構成されるように 説明したが、 これはこの例に限定されない。 すなわち、 記録部 1 0は 、 ソフトウェアとして構成することも可能である。 この場合、 ソフト ウェアは、 例えば制御部 3 0が有する図示されない R O Mに予め記憶 される。 これに限らず、 記録部 1 0を、 パーソナルコンピュータなど のコンピュータ装置上に構成することも可能である。 この場合には、 記録部 1 0をコンピュータ装置に実行させるソフトウエアは、 C D— ROMや DVD— ROMといつた記録媒体に記録されて提供される。 コンピュータ装置がネットワーク接続可能な場合、 インターネットな どのネットワークを介して当該ソフトウェアを提供することも可能で ある。

Claims

請 求 の 範 囲
1 . ビデオデータとォ一ディォデータとを多重化して記録媒体に記録 する記録装置において、
ビデオデータおよびオーディォデータが入力されるデータ入力部と 、
上記ビデオデータおよびオーディオデータの記録開始および記録停 止の指示が入力される記録指示入力部と、
上記ビデオデータおよびオーディォデータを多重化し、 多重化され たストリームをストリームファイルとして記録媒体に記録する記録部 と、
上記記録媒体に記録される上記ストリームファイルに対し： 少なく とも、 該ストリ一ムフアイルの再生時刻情報とアドレス情報とを対応 付けた属性ファイルと、
該ストリームファイルに対して再生開始点と再生終了点とを設定す ることにより再生区間を指定する 1以上の再生区間データが格納され 、 上記ストリームファイルに対する再生時刻情報を示すマーク情報が 格納可能な再生リストファイルと
を生成する管理情報生成部と、
上記記録部および上記管理情報生成部とを制御する制御部と を有し、
上記制御部は、
上記記録指示入力部の指示に基づく記録開始から記録停止までの区 間に対応する上記ビデオデータおよびオーディオデータを 1の上記ス トリームファイルとして上記記録媒体に記録するように上記記録部を 制御すると共に、 該 1のストリームファイルの全体を再生区間として 指定する上記再生区間データを生成し、 該再生区間データが指定する 再生開始時刻に対応する時刻情報を示す上記マーク情報を上記再生リ ス卜ファイルに格納するように上記管理情報生成部を制御する ことを特徴とする記録装置。
2 . 請求の範囲 1に記載の記録装置において、
上記記録指示入力部は、 ユーザの操作を受け付ける
ことを特徴とする記録装置。
3 . 請求の範囲 2に記載の記録装置において、
上記制御部は、
上記ストリームファイルを上記記録媒体に記録した直後に対応する 上記属性ファイルを記録する際には、 該属性ファイルの記録が完了す るまで上記記録指示入力部に対する上記記録開始の上記操作を受け付 けないように制御する
ことを特徴とする記録装置。
4 . 請求の範囲 1に記載の記録装置において、
上記制御部は、
上記記録指示入力部による記録停止の指示に基づき、 記録された上 記ストリームファイルを再生区間として指定する上記再生区間データ 内に、 該ストリームファイルと該ストリ一ムファイルに対して後続す るストリームファイルとがフレームタイミングで連続的に再生される ことを示す情報を設定して上記再生区間データを上記記録媒体に記録 するように制御する
ことを特徴とする記録装置。
5 . 請求の範囲 1に記載の記録装置において、
上記制御部は、
上記ストリームファイル内で、 上記ビデオデータの先端の再生時刻 と上記オーディオデータの先端の再生時刻とがー致し、 上記ビデオデ —夕の終端の再生時刻よりも上記オーディォデータの終端の再生時刻 が後になるように上記記録部を制御する
ことを特徴とする記録装置。
6 . 請求の範囲 1に記載の記録装置において、
上記制御部は、
新たな上記ストリームファイルが上記記録媒体に記録された際には 、 該新たなストリームファイルに対応する上記再生区間デ一夕を上記 再生リストファイルに追加するように上記管理情報生成部を制御する ことを特徴とする記録装置。
7 . 請求の範囲 6に記載の記録装置において、
上記制御部は、
1の上記記録媒体に対して唯一つの上記再生リストファイルを生成 するように制御する
ことを特徴とする記録装置。
8 . ビデオデータとオーディオデータとを多重化して記録媒体に記録 する記録方法において、
データ入力部に入力されたビデオデータおよびオーディォデ一夕の 記録開始および記録停止の指示が入力される記録指示入力のステップ と、
上記ビデオデータおよびオーディオデータを多重化し、 多重化され たストリームをストリ一ムフアイルとして記録媒体に記録する記録の ステップと、
上記記録媒体に記録される上記ストリームファイルに対し、 少なく とも、 該ストリームフアイルの再生時刻情報とアドレス情報とを対応 付けた属性ファイルと、
該ストリームファイルに対して再生開始点と再生終了点とを設定す ることにより再生区間を指定する 1以上の再生区間データが格納され
、 上記ストリームファイルに対する再生時刻情報を示すマーク情報が 格納可能な再生リストファイルと
を生成する管理情報生成のステップと、
上記記録のステップおよび上記管理情報生成のステップとを制御す る制御のステップと
を有し、
上記制御のステップは、
上記記録指示入力のステップによる指示に基づく記録開始から記録 停止までの区間に対応する上記ビデオデ一夕およびオーディォデ一夕 を 1の上記ストリームファイルとして上記記録媒体に記録するように 上記記録のステップを制御すると共に、 該 1のストリームファイルの 全体を再生区間として指定する上記再生区間データを生成し、 該再生 区間データが指定する再生開始時刻に対応する時刻情報を示す上記マ —ク情報を上記再生リストファイルに格納するように上記管理情報生 成のステップを制御する
ことを特徴とする記録方法。
9 . ビデオデータとオーディォデータとを多重化して記録媒体に記録 する記録方法をコンピュータ装置に実行させる記録プログラムにおい て、
上記記録方法は、
デ一夕入力部に入力されたビデオデ一夕およびオーディォデータの 記録開始および記録停止の指示が入力される記録指示入力のステップ と、
上記ビデオデータおよびオーディオデータを多重化し、 多重化され たストリ一ムをストリ一ムファイルとして記録媒体に記録する記録の ステップと、
上記記録媒体に記録される上記ストリームファイルに対し、 少なく とも、 該ストリームフアイルの再生時刻情報とアドレス情報とを対応 付けた属性ファイルと、
該ストリームファイルに対して再生開始点と再生終了点と ¾設定す ることにより再生区間を指定する 1以上の再生区間デ一夕が格納され 、 上記ストリームファイルに対する再生時刻情報を示すマーク情報が 格納可能な再生リス卜ファイルと
を生成する管理情報生成のステップと、
上記記録のステップおよび上記管理情報生成のステップとを制御す る制御のステップと
を有し、
上記制御のステップは、
上記記録指示入力のステップによる指示に基づく記録開始から記録 停止までの区間に対応する上記ビデオデータおよびオーディォデータ を 1の上記ストリームファイルとして上記記録媒体に記録するように 上記記録のステップを制御すると共に、 該 1のストリームファイルの 全体を再生区間として指定する上記再生区間データを生成し、 該再生 区間データが指定する再生開始時刻に対応する時刻情報を示す上記マ ーク情報を上記再生リストファイルに格納するように上記管理情報生 成のステップを制御する
ことを特徴とする記録プログラム。
1 0 . 撮像部で被写体を撮像して得られたビデオデ一夕と、 収音部で 音声を収音して得られたオーディオデータとを多重化して記録媒体に 記録する撮像装置において、
被写体を撮像してビデオデータを出力する撮像部と、 音声を収音してオーディオデータを出力する収音部と、
上記ビデオデ一夕および上記オーディォデ一夕を多重化し、 多重化 されたストリームをストリ一ムファイルとして記録媒体に記録する記 録部と、
上記ビデオデ一夕および上記オーディオデータの上記記録媒体への 記録開始および記録停止を指示するュ一ザ操作を受け付ける操作部と 上記記録媒体に記録される上記ストリームファイルに対し、 少なく とも、 該ストリ一ムフアイルの再生時刻情報とアドレス情報とを対応 付けた属性ファイルと、
該ストリームファイルに対して再生開始点と再生終了点とを設定す ることにより再生区間を指定する 1以上の再生区間データが格納され
、 上記ストリームファイルに対する再生時刻情報を示すマーク情報が 格納可能な再生リストファイルと
を生成する管理情報生成部と、
上記操作部に対するユーザ操作に応じて上記記録部の動作を制御す ると共に、 上記管理情報生成部を制御する制御部と
を有し、
上記制御部は、
上記操作部に対する操作に応じて、 上記記録開始から上記記録停止 までの区間に対応する上記ビデオデータおよび上記オーディオデータ を 1の上記ストリ一ムファイルとして上記記録媒体に記録するように 上記記録部を制御すると共に、 該 1のストリームファイルの全体を再 生区間として指定する上記再生区間デ一夕を生成し、 該再生区間デー 夕が指定する再生開始時刻に対応する時刻情報を示す上記マーク情報 を上記再生リストフアイルに格納するように上記管理情報生成部を制 御する
ことを特徴とする撮像装置。
1 1 . 請求の範囲 1 0に記載の撮像装置において、
上記制御部は、
上記ストリームファイルを上記記録媒体に記録した直後に対応する 上記属性ファイルを記録する際には、 該属性ファイルの記録が完了す るまで上記操作部に対する上記記録開始の上記操作を受け付けないよ うに制御する
ことを特徴とする撮像装置。
1 2 . 請求の範囲 1 0に記載の撮像装置において、
上記制御部は、
上記操作部による記録停止の指示に基づき、 記録された上記ストリ ームファイルを再生区間として指定する上記再生区間データ内に、 該 ストリームファイルと該ストリームファイルに対して後続するストリ ームファイルとがフレームタイミングで連続的に再生されることを示 す情報を設定して上記再生区間データを上記記録媒体に記録するよう に制御する
ことを特徴とする撮像装置。
1 3 . 請求の範囲 1 0に記載の撮像装置において、
上記制御部は、
上記ストリームファイル内で、 上記ビデオデータの先端の再生時刻 と上記オーディオデ一夕の先端の再生時刻とがー致し、 上記ビデオデ 一夕の終端の再生時刻よりも上記オーディォデータの終端の再生時刻 が後になるように上記記録部を制御する
ことを特徴とする撮像装置。
1 4 . 請求の範囲 1 0に記載の撮像装置において、 上記制御部は、
新たな上記ストリ一ムファイルが上記記録媒体に記録された際には 、 該新たなストリームファイルに対応する上記再生区間データを上記 再生リストファイルに追加するように上記管理情報生成部を制御する ことを特徴とする撮像装置。
1 5 . 請求の範囲 1 4に記載の撮像装置において、
上記制御部は、
1の上記記録媒体に対して唯一つの上記再生リストファイルを生成 するように制御する
ことを特徴とする撮像装置。
1 6 . 撮像部で被写体を撮像して得られたビデオデータと、 収音部で 音声を収音して得られたオーディオデータとを多重化して記録媒体に 記録する撮像装置の撮像方法において、
撮像部で被写体を撮像して得られたビデオデータと、 収音部で音声 を収音して得られたオーディオデータとを多重化し、 多重化されたス トリームをストリームファイルとして記録媒体に記録する記録のステ ップと、
操作部に対する上記ビデオデ一夕および上記オーディオデータの上 記記録媒体への記録開始および記録停止を指示するュ一ザ操作を受け 付けるステップと、
' 上記記録媒体に記録される上記ストリームファイルに対し、 少なく とも、 該ストリームファイルの再生時刻情報とァドレス情報とを対応 付けた属性ファイルと、
該ストリームファイルに対して再生開始点と再生終了点とを設定す ることにより再生区間を指定する 1以上の再生区間データが格納され 、 上記ストリームファイルに対する再生時刻情報を示すマーク情報が 格納可能な再生リストファイルと
を生成する管理情報生成のステップと、
上記操作部に対するユーザ操作に応じて上記記録のステップの動作 を制御すると共に、 上記管理情報生成のステップを制御する制御のス テツプと
を有し、
上記制御のステップは、
上記操作部に対する操作に応じて、 上記記録開始から上記記録停止 までの区間に対応する上記ビデオデー夕および上記オーディォデータ を 1の上記ストリームファイルとして上記記録媒体に記録するように 上記記録のステップを制御すると共に、 該 1のストリームファイルの 全体を再生区間として指定する上記再生区間データを生成し、 該再生 区間データが指定する再生開始時刻に対応する時刻情報を示す上記マ 一ク情報を上記再生リストフアイルに格納するように上記管理情報生 成のステップを制御する
ことを特徴とする撮像方法。
1 7 . 撮像部で被写体を撮像して得られたビデオデータと、 収音部で 音声を収音して得られたオーディォデータとを多重化して記録媒体に 記録する撮像装置の撮像方法をコンピュータ装置に実行させる撮像プ ログラムにおいて、
上記撮像方法は、
撮像部で被写体を撮像して得られたビデオデータと、 収音部で音声 を収音して得られたオーディォデータとを多重化し、 多重化されたス トリームをストリームファイルとして記録媒体に記録する記録のステ ップと、
操作部に対する上記ビデオデータおよび上記オーディオデ一夕の上 記記録媒体への記録開始および記録停止を指示するユーザ操作を受け 付けるステップと、
上記記録媒体に記録される上記ストリームファイルに対し、 少なく とも、 該ストリームフアイルの再生時刻情報とアドレス情報とを対応 付けた属性ファイルと、
該ストリームフアイルに対して再生開始点と再生終了点とを設定す ることにより再生区間を指定する 1以上の再生区間データが格納され 、 上記ストリームファイルに対する再生時刻情報を示すマーク情報が 格納可能な再生リストファイルと
を生成する管理情報生成のステップと、
上記操作部に対するユーザ操作に応じて上記記録のステップの動作 を制御すると共に、 上記管理情報生成のステップを制御する制御のス テツプと
を有し、
上記制御のステップは、
上記操作部に対する操作に応じて、 上記記録開始から上記記録停止 までの区間に対応する上記ビデオデ一夕および上記オーディォデー夕 を 1の上記ストリームファイルとして上記記録媒体に記録するように 上記記録のステップを制御すると共に、 該 1のストリームファイルの 全体を再生区間として指定する上記再生区間データを生成し、 該再生 区間データが指定する再生開始時刻に対応する時刻情報を示す上記マ 一ク情報を上記再生リストフアイルに格納するように上記管理情報生 成のステップを制御する
ことを特徴とする撮像プログラム。
PCT/JP2007/059345 2006-05-10 2007-04-24 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム WO2007129652A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US11/919,712 US8094996B2 (en) 2006-05-10 2007-04-24 Recording apparatus, recording method, recording program, image pickup apparatus, image pickup method, and image pickup program
KR1020077026689A KR101353000B1 (ko) 2006-05-10 2007-04-24 기록장치, 기록방법 및 기록 프로그램과 촬상장치,촬상방법 및 촬상 프로그램
CN200780000642XA CN101326583B (zh) 2006-05-10 2007-04-24 记录设备、记录方法、成像设备、成像方法
EP07742780.5A EP2017841B1 (en) 2006-05-10 2007-04-24 Recording device, recording method, recording program, imaging device, imaging method, and imaging program

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO2007129652A1 true WO2007129652A1 (ja) 2007-11-15

Family

ID=38667761

Family Applications (1)

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

Country Status (7)

Country Link
US (1) US8094996B2 (ja)
EP (1) EP2017841B1 (ja)
JP (1) JP4552889B2 (ja)
KR (1) KR101353000B1 (ja)
CN (1) CN101326583B (ja)
TW (1) TWI410962B (ja)
WO (1) WO2007129652A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010045505A (ja) * 2008-08-11 2010-02-25 Sony Corp 情報記録装置、撮像装置、情報記録方法およびプログラム

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4850605B2 (ja) 2006-07-18 2012-01-11 株式会社日立製作所 映像記録方法
JP5268569B2 (ja) * 2007-12-21 2013-08-21 キヤノン株式会社 記録装置及び記録方法
JP4934105B2 (ja) 2008-06-09 2012-05-16 ソニー株式会社 信号処理装置、マーク付与方法、プログラム
JP4788739B2 (ja) 2008-06-09 2011-10-05 ソニー株式会社 端末装置、情報送信方法
JP5458073B2 (ja) * 2011-09-09 2014-04-02 日立コンシューマエレクトロニクス株式会社 映像記録装置及び映像記録方法
JP5610495B2 (ja) * 2013-02-04 2014-10-22 日立コンシューマエレクトロニクス株式会社 映像記録再生装置及び映像記録再生方法
WO2016129303A1 (ja) * 2015-02-10 2016-08-18 ソニー株式会社 画像処理装置、撮像装置、画像処理方法、および、プログラム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11317014A (ja) * 1998-04-30 1999-11-16 Sony Corp 記録再生装置および方法、並びに提供媒体
JP2002290917A (ja) * 2001-01-16 2002-10-04 Matsushita Electric Ind Co Ltd 情報記録媒体、情報記録媒体に情報を記録、再生する装置及び方法
JP2003230104A (ja) * 2001-11-30 2003-08-15 Sony Corp 情報処理装置および方法、プログラム格納媒体、プログラム、並びに情報記録媒体
JP2004350251A (ja) 2003-03-25 2004-12-09 Sony Corp 記録方法、記録装置、記録媒体、再生方法、再生装置および撮像装置
JP2005216382A (ja) * 2004-01-29 2005-08-11 Victor Co Of Japan Ltd デジタルオーディオ信号録音再生装置
JP2005353212A (ja) * 2004-06-11 2005-12-22 Sony Corp データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、並びにデータ記録媒体

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6009433A (en) * 1995-04-14 1999-12-28 Kabushiki Kaisha Toshiba Information storage and information transmission media with parental control
WO1997039451A1 (fr) * 1996-04-12 1997-10-23 Matsushita Electric Industrial Co., Ltd. Disque optique multimedia contenant des titres d'images de sorte qu'il soit possible de determiner instantanement si des fonctions av sont necessaires pour leur reproduction, appareil et procede pour reproduire ceux-ci
US20020131761A1 (en) * 2001-01-16 2002-09-19 Kojiro Kawasaki Information recording medium, apparatus and method for recording/reproducing information to/from the medium
TW200300928A (en) * 2001-11-30 2003-06-16 Sony Corportion Information processing method and apparatus, program storage medium, program and information recording medium
EP1604356A4 (en) * 2003-02-28 2009-12-16 Lg Electronics Inc RECORD MEDIUM WITH A DATA STRUCTURE FOR MANAGING THE RANDOM / SHUFFLE PLAYBACK OF RECORDED VIDEO DATA, AND METHOD AND DEVICES FOR RECORDING AND PLAYING
WO2004095285A1 (ja) * 2003-03-28 2004-11-04 Matsushita Electric Industrial Co.,Ltd. 記録媒体およびこれを用いる記録装置並びに再生装置
JP4323870B2 (ja) * 2003-06-10 2009-09-02 キヤノン株式会社 記録装置
KR20050091944A (ko) * 2004-03-13 2005-09-16 엘지전자 주식회사 고밀도 광디스크의 데이터 파일 구성 방법 및 재생 방법과재생 장치
WO2005081643A2 (en) * 2004-02-26 2005-09-09 Lg Electronics Inc. Recording medium and method and apparatus for reproducing and recording text subtitle streams
JP2005303943A (ja) * 2004-04-16 2005-10-27 Sony Corp 映像記録装置
US7835615B2 (en) * 2004-10-12 2010-11-16 Panasonic Corporation Data processing apparatus
WO2006109718A1 (ja) * 2005-04-07 2006-10-19 Matsushita Electric Industrial Co., Ltd. 記録媒体、再生装置、記録方法、再生方法
EP2574049B1 (en) * 2005-08-10 2016-08-31 Mitsubishi Electric Corporation Recording medium, reproducing apparatus, and reproducing method
JP4715623B2 (ja) * 2006-05-08 2011-07-06 ソニー株式会社 データ記録装置及びデータ記録方法、並びにコンピュータ・プログラム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11317014A (ja) * 1998-04-30 1999-11-16 Sony Corp 記録再生装置および方法、並びに提供媒体
JP2002290917A (ja) * 2001-01-16 2002-10-04 Matsushita Electric Ind Co Ltd 情報記録媒体、情報記録媒体に情報を記録、再生する装置及び方法
JP2003230104A (ja) * 2001-11-30 2003-08-15 Sony Corp 情報処理装置および方法、プログラム格納媒体、プログラム、並びに情報記録媒体
JP2004350251A (ja) 2003-03-25 2004-12-09 Sony Corp 記録方法、記録装置、記録媒体、再生方法、再生装置および撮像装置
JP2005216382A (ja) * 2004-01-29 2005-08-11 Victor Co Of Japan Ltd デジタルオーディオ信号録音再生装置
JP2005353212A (ja) * 2004-06-11 2005-12-22 Sony Corp データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、並びにデータ記録媒体

Non-Patent Citations (1)

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

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010045505A (ja) * 2008-08-11 2010-02-25 Sony Corp 情報記録装置、撮像装置、情報記録方法およびプログラム
US8466985B2 (en) 2008-08-11 2013-06-18 Sony Corporation Information recording apparatus, imaging apparatus, information recording method and medium storing a program generating a transport data stream and utilizing a modified digital video pack

Also Published As

Publication number Publication date
US20090317067A1 (en) 2009-12-24
KR101353000B1 (ko) 2014-01-21
TW200743098A (en) 2007-11-16
US8094996B2 (en) 2012-01-10
JP4552889B2 (ja) 2010-09-29
EP2017841A1 (en) 2009-01-21
CN101326583B (zh) 2012-01-11
CN101326583A (zh) 2008-12-17
JP2007305213A (ja) 2007-11-22
EP2017841A4 (en) 2014-01-01
KR20090007521A (ko) 2009-01-19
TWI410962B (zh) 2013-10-01
EP2017841B1 (en) 2015-06-03

Similar Documents

Publication Publication Date Title
US8554055B2 (en) Editing device, editing method and editing program, and data processing device, data processing method and data processing program
JP4715633B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム
JP4337849B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
JP4622950B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
US8995816B2 (en) Recording apparatus, recording method, and recording program, and image capturing apparatus, image capturing method and image capturing program
WO2007129652A1 (ja) 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
EP1518240A4 (en) RECORDING MEDIUM HAVING A DATA STRUCTURE FOR MANAGING THE RECORDING AND READING OF MULTIPLE PATH DATA RECORDED ON THIS MEDIUM, AND METHODS AND APPARATUS FOR RECORDING AND READING
JP2008282471A (ja) 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム
JP2010226278A (ja) 記録装置、方法、プログラム、及び媒体

Legal Events

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

Ref document number: 200780000642.X

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 11919712

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 1020077026689

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2007742780

Country of ref document: EP

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

Ref document number: 07742780

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE