WO2006054590A1 - データ処理装置 - Google Patents

データ処理装置 Download PDF

Info

Publication number
WO2006054590A1
WO2006054590A1 PCT/JP2005/021025 JP2005021025W WO2006054590A1 WO 2006054590 A1 WO2006054590 A1 WO 2006054590A1 JP 2005021025 W JP2005021025 W JP 2005021025W WO 2006054590 A1 WO2006054590 A1 WO 2006054590A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
picture
time
kpu
video
Prior art date
Application number
PCT/JP2005/021025
Other languages
English (en)
French (fr)
Inventor
Masanori Itoh
Hiroshi Yahata
Hideki Otaka
Hideaki Mita
Original Assignee
Matsushita Electric Industrial Co., Ltd.
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 Matsushita Electric Industrial Co., Ltd. filed Critical Matsushita Electric Industrial Co., Ltd.
Priority to US11/719,318 priority Critical patent/US20090080509A1/en
Publication of WO2006054590A1 publication Critical patent/WO2006054590A1/ja

Links

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/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
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440281—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by altering the temporal resolution, e.g. by frame skipping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/78—Television signal recording using magnetic recording
    • H04N5/781—Television signal recording using magnetic recording on disks or drums
    • 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/8042—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 involving data reduction
    • 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/2508—Magnetic discs
    • G11B2220/2516—Hard disks

Definitions

  • the present invention relates to a technique for efficiently managing a data stream of content on a medium and facilitating reproduction and editing of the content.
  • optical disk recorders capable of writing and storing digital data of contents on media such as optical disks such as DVDs, magnetic disks such as hard disks, and semiconductor memories
  • Such content is, for example, video and audio shot by a broadcast program, a camcorder, or the like.
  • PCs can also be included in the above digital devices.
  • media such as hard disks, optical disks, and semiconductor memories have been used on PCs to record data such as document data. Therefore, such media employs a data management structure that can be linked with a PC, for example, a file system using FAT (File Allocation Table).
  • FAT32 file system which is currently widely used, can handle files with a maximum size of 4 gigabytes and can manage media with a maximum recordable capacity of 2 terabytes.
  • time map information that defines the correspondence between the reproduction time and the storage address of AV data reproduced at that time is generated at regular time intervals from the beginning of the data stream.
  • Each start time and end time specified by the user is converted to a start address and an end address by referring to the time map information, and stored at that address.
  • camcorders having a function of recording video at 24 frames per second have appeared. Since traditional movies are shot at 24 frames per second, the advent of such camcorders is making film production more accessible.
  • FIG. 37 shows the relationship of the display timing of each frame when the video of 24 frames per second is converted into the video of 60 frames per second using the 3: 2 pull-down technology.
  • Each frame is displayed for 1Z24 seconds before conversion and after 3Z60 seconds or 2Z60 seconds after conversion.
  • the latter display means that the frame displayed for 1Z60 seconds is output three times or twice continuously.
  • each frame of 60 frames per second is displayed with a time code updated 60 times per second. For example, if it is a start frame, it is displayed as 0 hours 0 minutes 0 seconds 0 frames. If it is 50 frames after the start point, it will be displayed as 0 hours 0 minutes 0 seconds 50 frames. In FIG. 37, only the numerical values corresponding to seconds and frames are shown.
  • Patent Document 1 JP-A-11 155130
  • the designated second IN force is the second of the three consecutively displayed frames. Think about when it was. At this time, the user who is editing is considered to be able to display the next different frame if the frame is advanced. Actually, the same frame is displayed for the next one frame period (1Z60 seconds). I feel uncomfortable. Furthermore, when the user deletes the video section after the second frame by editing, the first displayed frame is displayed because it has not been deleted. Therefore, the user had to edit to delete the first frame, which was very inconvenient and troublesome.
  • An object of the present invention is to allow a user to easily specify a frame before conversion when editing a video whose frame rate (vertical scanning frequency) has been converted.
  • EDL Edit Decision List
  • the data processing apparatus includes a receiving unit that receives a signal of a first video in which a plurality of pictures are displayed at a first frequency, and the plurality of pictures are based on the first frequency and the first frequency.
  • An encoder that generates a data stream of a second video displayed at a different second frequency, and a recording unit that records the data stream on a recording medium.
  • the encoder includes picture data corresponding to each of the plurality of pictures, first time information indicating a display time when displayed at a first frequency, and a first time indicating a display time when displayed at a second frequency. 2 time information is generated, and the picture data of each picture displayed based on the first time information, the second time information, and the first time information is stored in association with each other to generate the data stream .
  • the data processing device is a control unit that generates management information for reproducing the video, and the management information includes information corresponding to the first frequency and the second cycle.
  • a control unit that generates metadata storing information corresponding to the wave number may be further provided.
  • the data processing device is a control unit that generates management information for reproducing the video, and further includes a control unit that generates metadata that stores the first time information in the management information. Even more, be prepared.
  • the encoder generates a reproduction unit including the picture data relating to one or more pictures, the first time information, and the second time information, and the first time information and the picture for the picture in the reproduction unit are generated. Second time information may be generated.
  • the encoder includes data of a reference picture that can be decoded independently, data of one or more reference pictures that require decoding of the reference picture, the first time information, and the second time described above.
  • a reproduction unit including information may be generated, and the first time information and the second time information may be generated for at least the first reference picture in the reproduction unit.
  • the receiving unit receives a first video signal displayed by switching 24 pictures per second, and the encoder performs a data stream of a second video displayed by switching 60 pictures per second. You can generate
  • the present invention when converting the frame rate (vertical scanning frequency) of video, not only the time information based on the frequency after conversion but also the frequency before conversion for each frame data. Record based on the time information. For example, when a video of 24 frames per second is pulled down 3: 2 and a video of 60 frames per second is generated, a time code updated 24 times per second is added in addition to a time code updated 60 times per second. If the editor specifies the INZOUT point using the latter time code, the video can be edited based on the contents of the frame (for example, deletion of a frame, creation of a playlist). Therefore, the editing work time can be shortened.
  • FIG. 1 is a diagram showing a plurality of types of data processing devices that cooperate via removable media.
  • FIG. 2 is a diagram showing functional blocks of the camcorder 100.
  • FIG. 3 is a diagram showing a data structure of a transport stream (TS) 20.
  • FIG. 4 (a) is a diagram showing the data structure of a video TS packet 30, and (b) is an audio T
  • FIG. 3 is a diagram showing a data structure of S packet 31.
  • FIG. 6 is a diagram showing a data structure of a clip AV stream 60.
  • FIG. 7 is a diagram showing a functional block configuration of a TS processing unit 204.
  • FIG. 8 (a) is a diagram showing the concept of one content in this embodiment, (b) is a diagram showing the concept of a clip including content management information and stream data, and (c) is a diagram.
  • FIG. 3 is a diagram showing three removable HDDs 112.
  • FIG. 9 is a diagram showing a hierarchical directory structure in the removable HDD 112.
  • FIG. 10 is a diagram showing the contents of information included in clip metadata 94.
  • FIG. 11 is a diagram showing the relationship between key pictures and key picture units.
  • FIG. 12] (a) is a diagram showing a data structure of a clip timeline (ClipTimeLine) 95.
  • (B) is a diagram showing the data structure of the TimeEntry field 95g for one time entry
  • (c) is a diagram showing the data structure of the KPUEntry field 95h for one KPU entry.
  • FIG. 13 (a) is a diagram showing the relationship between time entries and fields included in clip timeline 95, and (b) shows the relationship between KPU entries and fields included in clip timeline 95.
  • FIG. 14 is a diagram showing management information and clip AV stream related to one shot of content stored separately in two removable HDDs.
  • FIG. 15 is a diagram showing a procedure of content recording processing by the camcorder 100.
  • FIG. 16 is a diagram showing a procedure for media switching processing.
  • FIG. 17 is a diagram showing a procedure of content reproduction processing by the camcorder 100.
  • FIG. 18 (a) and (b) are diagrams showing the relationship between the management information and the clip AV stream before and after deleting the head portion of the TTS file by editing.
  • FIG. 19 is a diagram showing a procedure of content partial deletion processing by the camcorder 100.
  • FIG. 20 is a diagram showing a data structure when 3: 2 pulldown is performed in the second embodiment.
  • FIG. 21] (a) to (c) are diagrams showing the PTS and time code storage locations in the stream.
  • FIG. 22 is a diagram showing a partially detailed functional block configuration of the camcorder 100 according to the second embodiment.
  • FIG. 23 is a diagram showing a data structure included in a clip metadata file in the second embodiment.
  • FIG. 24 is a diagram showing a processing procedure for identifying a picture corresponding to a time code value based on the time code value in the second embodiment.
  • FIG. 25 is a diagram showing management parameters when one shot in Embodiment 2 is composed of one TTS file.
  • FIG. 26 is a diagram showing the meaning of management parameters when one shot is composed of one TTS file with ClipTimeLineAddressOffset equal to 0 in Embodiment 2.
  • FIG. 27 is a diagram showing the meanings of management parameters when one shot in Embodiment 2 is composed of a chain of a plurality of TTS files.
  • FIG. 28 is a diagram showing a data structure when video of 24 frames per second is recorded in 3: 2 pull-down in Embodiment 3.
  • FIG. 29 is a diagram showing a data structure of a clip metadata file in the third embodiment.
  • FIG. 30 is a diagram showing a data structure of a ClipTimeLine file in the third embodiment.
  • FIG. 31 is a diagram showing a processing procedure for identifying a picture corresponding to a time code value based on the time code value in the third embodiment.
  • FIG. 32 shows the meanings of management parameters when one shot in Embodiment 3 is composed of one TTS file.
  • FIG. 33 is a diagram showing the meaning of management parameters when ClipTimeLineAddressOffset is not zero and one shot is composed of three TTS files in the third embodiment.
  • FIG. 34 is a diagram showing a schematic data structure of a time code conforming to the SMPTE M12 standard.
  • FIG. 35 is a diagram showing a data structure of a video stream compliant with the MPEG-4 AVC standard.
  • FIG. 36 is a diagram showing a data structure when pulling down 3: 2 in the third embodiment.
  • FIG. 37] 3 A diagram showing the relationship of the display timing of each frame when converting the video of 24 frames per second to the image of 60 frames per second using the 2 punore down technology.
  • FIG. 1 shows multiple types of data processing devices that work together via removable media.
  • the data processing apparatus is described as a camcorder 100-1, a camera-equipped cellular phone 100-2, and PC 108.
  • the camcorder 100-1 and the mobile phone with camera 100-2 receive the video and audio captured by the user, encode them as digital data streams, and write the data streams to the removable media 112-1 and 112-2, respectively.
  • Data written to each removable medium is handled as a “file” on the file system built on the removable medium.
  • FIG. 1 shows that a plurality of files are stored on the removable medium 112-2.
  • Removable media 112-1 and 112-2 are removable from the data processing device, such as optical disks such as DVDs and BDs (Blu-ray Discs), ultra-small hard disks such as microdrives, and semiconductor memories.
  • the PC 108 has a slot into which each removable medium 112-1 and 112-2 can be loaded. The PC 108 reads data from the loaded removable media 112-1, 112-2, and executes playback processing, editing processing, and the like.
  • the removable HDD 112 data management is performed by the FAT32 file system.
  • the maximum file size of a file is, for example, 4 gigabytes. Therefore, in the FAT32 file system, when the data size exceeds gigabytes, it is written in two or more files. For example, the capacity is 8GB
  • the removable HDD 112 can store two 4GB files.
  • a 16-gigabyte removable HDD 112 can store 4 gigabytes of files. Note that the unit to be divided and written may not be the maximum value of the file size, as long as it is less than the maximum value of the file size.
  • the data processing apparatus that writes the content data stream to the removable medium is a camcorder.
  • the data processing apparatus for playing back and editing the data stream stored on the removable medium is a PC.
  • the removable medium 112-1 is an ultra-small removable hard disk.
  • the removable medium includes a mechanism (drive mechanism) for driving a hard disk to write and read data, such as a known microdrive.
  • removable media 112-1 will be described as “Removable HDD112J.
  • the removable HDD112 has a capacity of 4 gigabytes.
  • content that exceeds 4 gigabytes has more than 2 removable media. Even if the capacity of the removable HDD is more than gigabyte and content exceeding 4 gigabytes is written to it, it is divided into two or more files and written to the same removable HDD.
  • cluster size is 32 kilobytes, for example, “cluster” means writing data and Which is the minimum of the access unit at the time of performing the out look.
  • FIG. 2 shows a functional block configuration of the camcorder 100.
  • the camcorder 100 can be loaded with a plurality of removable HDDs 112a, 112b, ..., 112c at the same time, and a data stream of video and audio content (clip AV stream) recorded by the user , Limuno Bnolet HDD 112a, 112b, ..., 112c
  • the camcorder 100 includes a CCD 201a, a microphone 20 lb, and a digital tuner 201c that receives digital broadcasting, an AD converter 202, an MPEG-2 encoder 203, a TS processing unit 204, a media control unit 205, and an MPEG-2.
  • Decoder 206 and graphic controller 207 A memory 208, a liquid crystal display (LCD) 209a and a speaker 209b, a CPU bus 213, a network control unit 214, an instruction receiving unit 215, an interface (IZF) unit 216, and a system control unit 250.
  • LCD liquid crystal display
  • IZF interface
  • the CCD 201a and the microphone 201b receive video and audio analog signals, respectively.
  • the CCD 201a outputs the video as a digital signal.
  • the microphone 201b outputs an audio analog signal.
  • the AD converter 202 converts the input analog audio signal into a digital signal and supplies it to the MPEG-2 encoder 203.
  • the digital tuner 201c functions as a receiving unit that receives a digital signal including one or more programs from an antenna (not shown).
  • a transport stream transmitted as a digital signal contains a plurality of program packets.
  • the digital tuner 201 c extracts and outputs a packet of the received transport stream power specific program (program of the recording target channel).
  • the output stream is also a transport stream, but is sometimes called a “partial transport stream” to distinguish it from the original stream.
  • the data structure of the transport stream will be described later with reference to FIGS.
  • the camcorder 100 includes the digital tuner 201c as a constituent element, but this is not an essential requirement.
  • the configuration of the camcorder 100 in FIG. 2 can be applied to the camera-equipped mobile phone 100-2 mentioned in FIG. 1, so it can be considered as a component of a camera-equipped cellular phone that can receive and view digital broadcasts. Good.
  • the MPEG-2 encoder 203 Upon receiving the recording start instruction, the MPEG-2 encoder 203 (hereinafter referred to as “encoder 203”) compresses and encodes the supplied digital video and audio data based on the MPEG standard. .
  • the encoder 203 generates a transport stream (hereinafter also referred to as “TS”) by compressing the video data into the MPEG-2 format, and sends the transport stream to the TS processing unit 204. This process is continued until the encoder 203 receives a recording end instruction.
  • the encoder 203 has a buffer (not shown) or the like that temporarily holds a reference picture or the like in order to perform bidirectional compression coding. It is not necessary to match the video and audio code formats. For example, video is compressed in MPEG format The audio may be compressed in AC- 3 format.
  • the camcorder 100 generates and processes a TS.
  • TS the data structure of TS will be described with reference to FIGS.
  • FIG. 3 shows the data structure of the transport stream (TS) 20.
  • the TS packet is, for example, a video TS packet (V—TSP) 30 in which compressed and encoded video data is stored, an audio TS packet (A_TSP) 31 in which encoded audio data is stored, and a program.
  • Packet in which table (program association table; PAT) is stored, bucket (PMT—TSP) in which program correspondence table (program map table; PMT) is stored and program clock Includes packets (PCR—TSP) that store reference (PCR).
  • the data amount of each TS packet is 188 bytes.
  • TS packets that describe the program structure of TS such as PAT-TSP and PMT-TSP are generally called PSIZS I packets.
  • FIG. 4 (a) shows the data structure of the video TS packet 30.
  • the video TS packet 30 generally has a 4-byte transport packet header 30a and a 184-byte transport packet payload 30b.
  • Video data 30b is stored in the payload 30b.
  • FIG. 4B shows the data structure of the audio TS packet 31.
  • the audio TS packet 31 generally has a 4-byte transport packet header 3 la and a 184-byte transport packet payload 31b.
  • Audio data 3 lb is stored in a transport packet payload 3 lb.
  • the TS packet header can be used to add data called an adaptation field. It is used to align data stored in a TS packet.
  • the payload (30b, 31b) of the TS packet is less than 184 bytes.
  • a TS packet generally consists of a 4-byte transport bucket header, 184-byte elementary data, and power.
  • a packet identifier (Packet IDentifier; PID) that identifies the type of the packet is described in the packet header. For example, the PID of the video TS packet is “0x0020”, and the PID of the audio TS packet is “0x0021”.
  • Elementary data includes video data and audio data. Content data such as data, control data for controlling playback, and the like. What data is stored depends on the type of packet.
  • Figures 5 (a) to 5 (d) show the relationship of the streams that are constructed when playing video pictures from video TS packets.
  • the TS 40 includes video TS packets 40a to 40d.
  • TS40 can include other packets.
  • Video TS packets are easily identified by the PID stored in header 40a-1.
  • a packetized elementary stream is composed of video data of each video TS packet such as video data 40a-2.
  • Figure 5 (b) shows the data structure of the packetary elementary stream (PES) 41.
  • the PES 41 is composed of a plurality of PES packets 41a, 41b and the like.
  • the PES packet 41a is composed of a PES header 41a-1 and a PES payload 41a-2, and these data are stored as video data of a video TS packet!
  • Each of the PES payloads 41a-2 includes data of one picture.
  • An elementary stream is composed of the PES payload 41a-2.
  • Figure 5 (c) shows the data structure of elementary stream (ES) 42.
  • the ES 42 has a plurality of sets of picture headers and picture data. Note that “picture” is generally used as a concept that includes frame and field shifts.
  • the picture header 42a shown in FIG. 5 (c) describes a picture coding type that specifies the picture type of the picture data 42b arranged thereafter, and the picture header 42c specifies the picture type of the picture data 42d.
  • the picture coding type to be described is described! The type indicates an I picture (Intra-coded picture), a P picture (Predictive-coded picture), 7 pictures, or a B picture (Biairectionaliy-predictive-coded picture). If the type is an I picture, the picture coding type is determined to be "001b", for example.
  • the picture data 42b, 42d, etc. are the data of one frame that can be constructed by the data alone or by the data and the data decoded before and after Z or after.
  • Figure 5 (d) shows a picture 43a in which the picture data 42b force is also constructed.
  • picture 43b constructed from picture data 42d.
  • camcorder 100 When video is played back based on TS, camcorder 100 acquires a video TS packet, acquires picture data according to the above-described processing, and acquires pictures constituting the video. As a result, the video can be reproduced on the LCD 209a.
  • the encoder 203 described above generates TS in the order shown in FIGS. 5D, 5C, 5B, and 5A with respect to video content.
  • the TS processing unit 204 receives a TS from the encoder 203 when recording a moving image, or receives a TS from the digital tuner 201c when recording a digital broadcast program, and generates a clip AV stream.
  • the clip AV stream is a data stream having a predetermined format for storage in the removable HDD 112a or the like.
  • the file extension of the clip AV stream stored in the removable HDD is given the extension TTS (meaning “Timed TS”).
  • the clip AV stream is realized as a TS to which arrival time information is added.
  • the TS processing unit 204 receives a clip AV stream read from the removable HDD 112a or the like from the media control unit 205 during content playback, generates a TS based on the clip AV stream, and generates an MPEG. — Output to 2 decoder 206.
  • FIG. 6 shows the data structure of the clip AV stream 60.
  • the clip AV stream 60 is composed of a plurality of TTS packets 61.
  • the TTS socket 61 includes a 4-byte TTS header 61a and a 188-byte TS packet 61b. That is, the TTS bucket 61 is generated by attaching the TTS header 61a to the TS packet 6 lb.
  • the TS packet 61b is the TS packet described in relation to FIGS. 3, 4 (a) and 4 (b), and the like.
  • the TTS header 61a includes a 2-bit reserved area 61a-1 and 30-bit arrival time information (Arrival Time Stamp; ATS) 61a-2.
  • the arrival time information 61a-2 indicates the time when the TS packet output from the encoder 203 arrives at the TS processing unit 204.
  • the TS processing unit 204 outputs a TS packet to the decoder 206 based on this time.
  • FIG. 7 shows a functional block configuration of the TS processing unit 204.
  • the TS processing unit 204 includes a TTS header attached car 261, a clock counter 262, a PLL circuit 263, a nother 264, and a TTS header removing unit 265.
  • the TTS header adding unit 261 receives the TS, attaches a TTS header to the TS packet constituting the TS, and outputs it as a TTS packet. Arrival time information in the TTS header 61 a-2 The arrival time of the TS packet described in 2 is specified based on the count value (count information) from the reference time given to the TTS header addition unit 261! / The
  • the clock counter 262 and the PLL circuit 263 generate information necessary for the TTS header-equipped card unit 261 to specify the arrival time of the TS packet.
  • the PLL circuit 263 extracts a PCR packet (PCR—TSP in FIG. 2) included in the TS, and obtains a PCR (Program Clock Reference: reference time) indicating the reference time.
  • PCR Program Clock Reference: reference time
  • STC System Time Clock
  • STC System Time Clock
  • the system clock frequency of the system reference time STC is 27 MHz.
  • the PLL circuit 263 outputs a 27 MHz clock signal to the clock counter 262.
  • the clock counter 262 receives the clock signal and outputs the clock signal to the TTS header adding unit 261 as count information.
  • the noffer 264 includes a write buffer 264a and a read buffer 264b.
  • the write buffer 264a sequentially holds the transmitted TTS packets, and outputs them to the media control unit 205 (to be described later) when the total data amount reaches a predetermined value (for example, the total capacity of the buffer).
  • a series of TTS packet sequences (data streams) output at this time is called a clip AV stream.
  • the read buffer 264b temporarily buffers the clip AV stream that has also been read by the media control unit 205, and outputs it in units of TTS packets.
  • the TTS header removal unit 265 receives the TTS packet, converts the TTS packet into a TS packet by removing the TTS header, and outputs the TS packet. It should be noted that the TTS header removal unit 265 extracts the arrival time information ATS of the TS packet included in the TTS header, and based on the arrival time information ATS and the timing information provided from the clock counter 262, Output TS packets at the timing (time interval) corresponding to the original arrival time Is Rukoto.
  • the removable HDD 112a and the like can be accessed randomly, and data is discontinuously arranged on the disk.
  • the TS processing unit 204 can output the TS packet at the same timing as the arrival timing of the TS packet at the time of recording regardless of the data storage position.
  • the TTS header removal unit 265 sends, for example, the arrival time specified in the first TTS packet to the clock counter 262 as an initial value in order to specify the reference time of the read TS.
  • the initial value of the clock counter 262 can also be counted, and the subsequent count result can be received as timing information.
  • the TS processing unit 204 is provided, and a clip AV stream is generated by attaching a TTS header to the TS.
  • the coding rate is fixed at a constant bit rate (CBR)
  • the TS processing unit 204 is omitted because the TS packet decoder input time is a fixed interval. Write TS to removable HDD112.
  • the media control unit 205 receives the TS processing unit 204 force clip AV stream, determines the output power to any of the limousine HDDs 12a ⁇ 112b ⁇ 112c ⁇ 112c, and sends it to the removable HDD. Output.
  • the media control unit 205 monitors the recordable capacity of the removable HD D being written, and when the remaining recordable capacity falls below the specified value, changes the output destination to another removable HDD, and the clip AV stream Continue to output. At this time, the clip AV stream constituting one content is stored across the two removable HDDs 112.
  • the media control unit 205 generates a clip timeline table which is one of the main features of the present invention.
  • a flag indicating whether or not a key picture unit that is a playback unit of the clip AV stream is stored across two files is described.
  • the detailed operation of the media control unit 205 and the detailed data structure of the clip timeline table generated by the media control unit 205 will be described later.
  • the process of writing the clip AV stream to the removable HDD 112 is a media control.
  • Removable HDDI 12 which has received the write instruction and the clip AV stream from the control unit 205 performs it.
  • the process of reading the clip AV stream is performed by the removable HDD 112 that has received a read instruction from the media control unit 205.
  • the media control unit 205 writes and reads the clip AV stream.
  • the MPEG-2 decoder 206 deciphers the supplied TS and acquires video and audio compression code data from the TS packet. Then, the compressed code key data of the video is decompressed and converted into uncompressed data, and is supplied to the graphic control unit 207. The decoder 206 decompresses the audio compression encoded data to generate an audio signal, and outputs the audio signal to the speaker 209b.
  • the decoder 206 is configured to meet the requirements of the system target decoder (T—STD) defined in the MPEG standard for TS.
  • a memory 208 for internal computation is connected to the graphic control unit 207, and an on-screen display (OSD) function can be realized.
  • the dynamic control unit 207 can output a video signal obtained by synthesizing various menu images and videos.
  • the liquid crystal display (LCD) 209a displays the video signal output from the graphic control unit 207 on the LCD.
  • the speaker 209b outputs an audio signal as sound. The content is played back via the LCD 209a and the speaker 209b and is subject to viewing.
  • the output destination of the video signal and the audio signal is not limited to the LCD 209a and the speaker 209b, respectively.
  • the video signal and the audio signal may be transmitted to a television or speaker separate from the camcorder 100 via an external output terminal (not shown).
  • the CPU bus 213 is a path for transmitting signals in the camcorder 100, and is connected to each functional block as shown in the figure. In addition, each component of a system control unit 250 described later is also connected to the CPU bus 213.
  • the network control unit 214 is an interface for connecting the camcorder 100 to the network 101 such as the Internet, and is, for example, a terminal and a controller compliant with the Ethernet (registered trademark) standard.
  • the network control unit 214 transmits and receives data via the network 101.
  • the network control unit 214 captures and generates a captured image.
  • the lip AV stream may be transmitted to the broadcast station via the network 101.
  • the network control unit 214 may receive the updated program via the network 101 when the software program for controlling the operation of the camcorder 100 is updated.
  • the instruction receiving unit 215 is an operation button provided on the main body of the camcorder 100.
  • the instruction receiving unit 215 receives instructions from the user, such as recording start Z stop, playback start Z stop, and the like.
  • the interface (IZF) unit 216 controls a connector for the camcorder 100 to communicate with other devices and its communication.
  • the IZF unit 216 includes, for example, a USB 2.0 standard terminal, an IE EE1394 standard terminal, and a controller that enables data communication according to each standard, and can exchange data in a manner compliant with each standard.
  • the camcorder 100 is connected to the PC 108, another camcorder (not shown), a BDZDVD recorder, a PC, etc. via a USB 2.0 standard or IEEE1394 standard terminal.
  • the system control unit 250 controls the overall processing including the signal flow in the camcorder 100.
  • the system control unit 250 includes a program ROM 210, a CPU 211, and a RAM 212. Each is connected to the CPU bus 213.
  • the program ROM 210 stores a software program for controlling the camcorder 100.
  • the CPU 211 is a central control unit that controls the overall operation of the camcorder 100.
  • the CPU 211 reads out and executes the program to generate a control signal for realizing processing defined based on the program, and outputs the control signal to each component via the CPU bus 213.
  • the memory 212 has a work area for storing data necessary for the CPU 211 to execute the program.
  • the CPU 211 reads the program from the program ROM 210 to the random access memory (RAM) 212 using the CPU bus 213, and executes the program.
  • the computer program is recorded on a recording medium such as a CD-ROM and distributed to the factory, or transmitted through an electric communication line such as the Internet.
  • FIG. 8 (a) shows the concept of one content in this embodiment.
  • the content obtained during the period until the end of shooting is completed is called one shot.
  • Figure 8 (b) shows the concept of a clip that includes content management information and stream data.
  • One shot, ie one content, has multiple clips a ⁇ .
  • Each clip can be stored in: 1100112 & ⁇ 112 ( : ( can be completed with one clip).
  • One clip consists of clip metadata 81, time map 82, and clip AV stream.
  • the clip AV stream 83 is composed of the partial streams 83a to 83c and is included in each of the clips a to c.
  • Figure 8 (b) shows three clips a Forces in which c is described Since the configuration of each clip is the same, description will be given here by taking clip a as an example.
  • Clip a includes clip metadata a, time map a, and partial stream a.
  • the clip metadata a and the time map a are management information
  • the partial stream a is data that constitutes the clip AV stream 83.
  • the clip AV stream 83 can be stored in multiple TTS files when it exceeds the maximum FAT32 file size in principle.
  • the three partial streams 83a, 83b and 83c are stored in separate files.
  • the file size of each partial stream is the maximum file size (4 gigabytes) in the FAT32 file system, the recordable capacity of the removable HDDs 112a to c is lost and management information cannot be written to the removable HDD 112.
  • the file size of each partial stream is smaller than 4 gigabytes.
  • the TTS file is composed of an integer number of TTS packets, and may be less than 4 gigabytes, which is the limit of the file system, and an integer multiple of the TTS packet (192 bytes).
  • the clip metadata a is described in XML format, and information necessary for content reproduction, for example, a video Z audio format and the like is defined. Details of the clip metadata a will be described later with reference to FIG.
  • Time map a is a table that defines the relationship between display time and storage position (address) for each playback unit.
  • this time map is referred to as the “clip timeline” ( It is called “ClipTimeLine”, and “CTL” is added to the extension of the file storing the clip timeline. Details of the clip timeline will be described later with reference to FIGS.
  • the partial stream a is composed of a plurality of TTS packets as shown in FIG.
  • the ATS clock counter 262 (Fig. 7) that determines the transfer timing of the TS packet is reset. Or a value that is unrelated to the previous count value is not set.
  • the clock counter 262 (Fig. 7) continuously counts based on the set reference time and outputs the count value. Therefore, the arrival time information ATS in each TTS packet constituting the clip AV stream 83 is continuously located at the boundary between two consecutive TTS files constituting one shot.
  • FIG. 8 (c) shows three removable 1100112 & 112. Indicates. Data files constituting each clip a to c are written to each removable HDD 112a to 112c.
  • FIG. 9 shows a hierarchical directory structure in the removable HDD 112.
  • Content management information and clip AV stream files are stored in the content folder 91 in the root (ROOT) 90 of the top layer.
  • the database folder 92 directly under the content folder 91 stores an XML format file of clip metadata 94 that is management information, and a CTL format file of the clip timeline 95.
  • a TTS folder 93 immediately below the content folder 91 stores a TTS format file of a clip AV stream (TimedTs) 96.
  • TimedTs TimedTs
  • the content folder 91 further includes a video folder (Video) for storing MXF format video stream data, a video folder (Audio) for storing MXF format audio stream data, and a BMP format. It can be compatible with existing camcorder recording formats, etc., even if an icon folder (Icon) for storing thumbnail images and a voice folder (Voice) for storing WAVE voice memo data are provided.
  • Video video folder
  • Audio for storing MXF format audio stream data
  • BMP format a BMP format. It can be compatible with existing camcorder recording formats, etc., even if an icon folder (Icon) for storing thumbnail images and a voice folder (Voice) for storing WAVE voice memo data are provided.
  • FIG. 10 shows the content of information included in the clip metadata 94.
  • Clip metadata 94 is classified into two types: configuration data (“Structural”) and description data (“Descriptive”).
  • the clip name is information for specifying the file, and for example, a well-known UMID (Unique Material IDentifier) is described.
  • UMID Unique Material IDentifier
  • the UMID is generated, for example, by combining the time when content is generated and the MAC (Media Access Control) address of the device that generated the content.
  • UMID is generated taking into account whether content has been newly generated. That is, a value different from the UMID of the original content is added to the content that has been added with UMID and then edited and processed. Therefore, when UMID is used, different values are defined for content existing all over the world, so the content can be uniquely identified.
  • the video information describes the format of video data, the compression encoding method, the frame rate, and the like.
  • the audio information describes the audio data format, sampling rate, and the like.
  • the compression code method is the MPEG-2 method.
  • the relation information defines the relationship between clips when there are a plurality of clips 81a to 81c as shown in FIG. 8 (b).
  • each clip metadata 94 describes information specifying the first clip of the shot and information specifying the clip immediately before and after the clip. That is, it can be said that the relation information defines the pre-relationship or playback order of playback of the clip AV stream (partial stream) corresponding to each of the plurality of clips.
  • the information for specifying the clip is defined by, for example, a UMID and a serial number unique to the removable HDD 112.
  • the description data includes access information, devices, shooting information, and the like.
  • the access information describes the person who last updated the clip and the date and time.
  • the device information includes the manufacturer name, the serial number of the recorded device, the model number, and so on.
  • Photography The information includes the photographer's name, shooting start date / time, end date / time, position, and the like.
  • Clip timeline 95 introduces the concept of key pictures and key picture units and provides information about them. First, the key picture and key picture unit will be described with reference to FIG.
  • FIG. 11 shows the relationship between key pictures and key picture units.
  • a key picture unit (KPU) is a data playback unit defined for video.
  • the display of the key picture unit KPU starts from the key picture 44 and ends at the B picture 45. This includes the MPEG standard group-of-picture (GOP) power S 1 or higher.
  • the display of the next key picture unit KPU starts from the I picture 46 next to the B picture 45.
  • the video playback time of each key picture unit is 0.4 seconds or more and 1 second or less. However, the last key picture unit of a shot should be less than 1 second. Depending on the shooting end timing, it may be less than 0.4 seconds.
  • KPU Period indicates the playback time of all pictures stored in the KPU.
  • the key pictures 44 and 46 located at the head of the key picture unit relate to a video including a sequence header code (sequence_header_code) and a gnole start code (group-start-code) in the MPEG standard.
  • Access unit for example, the key picture unit is an MPEG2 compression encoded I picture image (frame image or a set of two field images) or a compression encoded I field and P field image.
  • the KPU period (KPU period) is defined using the PTS added to the TS.
  • the KPU period is the difference between the display time (PTS) of the first picture displayed in the next key picture unit KPU and the display time (PTS) of the first picture displayed in that KPU. is there.
  • PTS display time
  • PTS display time
  • Fig. 11 when the time of key picture 44 is PTS (N) and the time of key picture 46 is PTS (N + 1), the KPU period (N) is PTS (N + 1) Defined as PTS (N) (both when key pictures are display start pictures).
  • the KPU period for a certain key picture unit KPU is determined after generation of the next key picture unit is started. Since the last KPU period may be required for a shot, it is also possible to add up the display time of the signed picture. In that case, it is possible to determine the KPU period without waiting for the start of generation of the next KPU.
  • FIG. 12 (a) shows the data structure of the clip timeline (ClipTimeLine) 95.
  • FIG. The clip timeline 95 is written to each removable HD D112 as a file having the extension “CTL”.
  • the clip timeline 95 is a table that defines the relationship between the display time and the storage position (address) for each playback unit.
  • “Reproduction unit” corresponds to the above-mentioned key picture unit KPU.
  • the clip timeline 95 defines a plurality of fields.
  • the clip timeline 95 includes a TimeEntryNumber field 95a, a KPUEntryNumber field 95b, a ClipTimeLineTimeOffset field 95c, a ClipTimeLineAddressOffset field 95d, a ClipTimeLineDuration field 95e, a StartKeySTC field 75f, a TimeEntry field 95g, a KPUEntry field 95h, and the like.
  • Each field is assigned a predetermined number of bytes, each with a specific meaning depending on its value.
  • the TimeEntryNumber field 95a describes the number of time entries
  • the KPUEntryNumber field 95b describes the number of KPU entries.
  • the data size of the Time Entry field 95g and the KPU Entry field 95h can vary depending on the number of time entries and the number of KPU entries described later.
  • FIG. 12 (b) shows the data structure of the TimeEntry field 95g for one time entry.
  • the TimeEntry field 95g contains information indicating attributes related to the corresponding time entry. Information is described in several fields (KPUEntryReferencelD field 97a, KPUEntryStart Address field 97b, and TimeEntryTimeOffset field 97c).
  • Fig. 12 (c) shows the data structure of the KPUEntry field 95h for 1KPU entry.
  • the KPUEntry field 95h information indicating attributes related to the corresponding key picture unit KPU is described in a plurality of fields (Overlapped KPUFlag field 98a, Key PictureSize field 98b, KPUPeriod field 98c, and KPUSize field 98d).
  • FIG. 13A shows the relationship between the time entry and the fields included in the clip timeline 95.
  • One scale on the horizontal axis in Fig. 13 (a) indicates one access unit time (Access Unit TiMe; AUTM). This corresponds to the display time of one picture.
  • ClipTimeLineDuration ⁇ KPUperiod
  • each KPU period field 98c corresponds to the sum of the video display times (AUTM values) of the pictures included in the key picture unit KPU (number
  • KPUperiod Total video display time in KPU
  • a "time entry" (TimeEntry) is set every certain fixed time (for example, 5 seconds) and indicates a jump point on the time axis at which the position force regeneration can be started.
  • the time offset up to the first time entry # 0 is set in the ClipTimeLineTimeOffset field 95c .
  • information for identifying the key picture unit KPU to be played at the set time of each time entry is described in the KPUEntryReferencelD field 97a, and the time from the start of the key picture unit KPU to the set time of the time entry.
  • Information indicating the offset is described in the TimeEntryTimeOffset field 97c.
  • time entry #t (time value of ClipTimeLineTimeOffset field 95c) + (time entry interval 't) is calculated. You can get the elapsed time from the beginning of the key unit KPU # 0.
  • playback can be started from an arbitrary playback time by the following method.
  • the time is converted into a PTS value, which is time information according to the MPEG standard, using a known conversion process.
  • Playback starts from the picture to which the PTS value is assigned.
  • the PTS value is described in the transport packet header 30a of the video TS packet (V_TSP) 30 (Fig. 4 (a)).
  • the playback start time (PTS) at the beginning of the partial stream in each clip may not be zero. Therefore, the 3 & 31 ⁇ field 95 of the clip timer 95 shows the playback time information (PTS) of the picture that is displayed first in the first KPU in the clip. . Based on the PTS value of the picture and the PTS value corresponding to the specified time, the PTS (AUTM) difference value up to the picture to be played back is obtained. In addition, it is expressed in 33 bits, for example, that it is preferable to match the data amount of the PTS value allocated to each picture with the data amount of the PTS value specified in the StartSTC field 95f.
  • FIG. 13 (b) shows the relationship between the KPU entry and the fields included in the clip timeline 95.
  • One scale on the horizontal axis in Fig. 13 (b) indicates one data unit length (TPBL). This means that one data unit is equal to the amount of TTS packet data (192 bytes).
  • One KPU entry is provided for each key picture unit KPU.
  • the data size of each KPU is described in the KPUSize field 98d, and the KPU start address corresponding to each time entry is described in the KPUEntryStartAddress field 97b.
  • the data size of each key picture unit KPU is determined from the first TTS packet storing the data of the first picture in the KPU, for example, as shown in KPUsize #k in Fig. 13 (b).
  • the data size up to the TTS packet immediately before the TTS packet storing the first picture of the first KPU is expressed as one data unit length (TPBL).
  • a fragment (data offset) from the beginning of the file to the beginning of the key picture unit KPU # 0 is set in the ClipTimeLineAddressOffset field 95d.
  • the reason for providing this field is as follows. For example, when one-shot clip AV stream data is stored in multiple files, a part of the KPU at the end of the previous file may be stored at the beginning of the second and subsequent files.
  • Key picture unit Each picture in the KPU must be decoded from the key picture at the head of the KPU, so the data existing at the head of the file cannot be decoded alone. Therefore, it is necessary to skip such data as meaningless data (fragments). Therefore, it is possible to skip reading by using the offset value in the offset field 95d described above.
  • Overlapped KPUFlag field 98a and the like when one-shot clip AV stream data is divided into a plurality of files and stored will be described with reference to FIG.
  • management information related to the content of one shot and the clip AV stream are stored in two removable HDDs # 1 and # 2, and do not mention clip metadata. .
  • Fig. 14 shows management information and clip AV stream related to one shot of content stored separately in two removable HDDs.
  • Removable HDDs # 1 and # 2 contain the clip timeline files (00001. CTL and 00002. CTL), clip AV stream finals (00001. TTS and 00002. TTS), and force S respectively. .
  • KPU entry # (d—1) on removable HDD # 1 is provided corresponding to key picture KPU # (d—1) specified in the clip AV stream in 00001. TTS.
  • KPU entry # (d-l) is set in the Overlapped KPUFlag field 98a of KPU entry # (d-1).
  • the key figure unit KPU #d shown in Figure 14 is a part of it (key figure unit KPU # dl) exists in 00001. TTS of removable HDD # 1 and the other part (key picture unit KPU # d2) exists in 00002. TTS of removable HDD # 2! /.
  • the reason is that the key picture unit KPU #d is stored separately on two removable HDDs !, for example, the remaining capacity that can be recorded during writing to the removable HDD # 1 falls below the specified value, and beyond This is because it becomes impossible to write.
  • lb is set in the Overlapped KPUFlag field 98a of KPU entry #d.
  • the Observed KPUFlag field 98a contains Ob Is set.
  • the playback time calculation process can be changed based on the value of the Overlapped KPUFlag field 98a. More specifically, with respect to the last KPU #d in the removable HDD # 1, the value of the Overlapped KPUFlag field 98a is "lb". In this case, the sum of the KPU period (KPU period) from the beginning to KPU # (dl) may be used as the value of the clip playback time (ClipTimeLineDuration95e) in the removable HDD # 1.
  • the value of the KPU period (KPU period) of the key picture unit KP U #d in the above equation 2 is not counted as the clip playback time!
  • the reason is that the actual playback time (up to the first KPU force KPU # (d-l)) and the playback time of one shot calculated based on Equation 2 (from the first KPU to KPU # d)
  • an error may occur for the playback time equivalent to the last KPU #d (0.4 seconds or more and less than 1 second). is there. It is absolutely impossible that the playback time including the device power includes such a large error, especially for business-use devices.
  • the KPU period (KPUperiod) of each key-bit KPU from the beginning to the end May be used as the value of the clip playback time (ClipTimeLineDuration95e). This is because the KPU period of the last KPU (KPUperiod) should be included in the clip playback time (ClipTimeLineDuration95e), since all pictures in the last key picture unit KPU can be played back.
  • the clip time line in the removable HDD # 1 can be corrected.
  • the clip timeline is modified by reducing the number of key-victure units KPU (KPUEntryNumber95b), deleting KPU entries for KPU #d, and setting the time entry (TimeEntry) 95g in key-picture unit KPU #dl. Including deletion. After modification, the last key picture unit of removable HDD # 1 is 00001.
  • TTS file is KPU # (d—l), and the playback time from the first KPU force to the last KPU # (d—l) The sum of is the playback time of one shot. Therefore, it is possible to obtain the accurate reproduction time by uniformly applying the above formulas 1 to 3.
  • Such rear part deletion can be performed in units of TTS packets (192 bytes) even on the FAT32 file system.
  • Other advantages are as follows. When playback starts from a specified playback time, use the time map (Clip TimeLine), which is table information of playback time and recording address, as shown in Fig. 13, to specify the key feature unit KPU to jump into. You can.
  • the head force data of the key HDD unit KPU # dl of the removable HDD # 1 is read so that it can be correctly decoded from the playback start picture.
  • the operation can be controlled. Since the head force of the removable HDD # 2 is accidentally read out, the reference picture cannot be obtained, and there is no need to perform the process of determining that decoding is impossible. It is possible to reduce the time required for processing and the processing load required for such processing. Alternatively, it is possible to prevent the display of a video that has failed to be decoded.
  • the key picture unit KPU # d2 is a fragment in the removable HDD # 2, and video cannot be decrypted only with the data. Therefore, the fragment (data offset) from the beginning of the clip AV stream file (00002. TTS) in the removable HDD # 2 to the beginning of the keystream KPU # 0 is set in the ClipTimeLineAddressOffset field 95d. In addition, the top of the key unit KPU # 0 To the first set time entry # 0 is set in the ClipTimeLineTimeOffset field 95c. Note that when the value of the ClipTimeLineAddressOffset field 95d is 0! /, This means that the key picture unit KPU from the previous removable HDD is stored.
  • the previous clip has a force. If the previous clip does not exist or cannot be accessed, rewind playback ends. If it is a clip in the middle of a shot and the previous clip is accessible, check whether the value of the ClipTimeLineAddressOffset field 95d is 0. If it is not 0, the last key of the previous removable HDD. By further checking the value of the Overlapped KPUFlag field 98a of the KPU entry corresponding to the unit KPU, it is also possible to reliably determine whether or not the key picture unit KPU straddles.
  • FIG. 15 shows the procedure of content recording processing by the camcorder 100.
  • step S151 a shooting start instruction is received from the user force via the CPU 211i indication receiver 215 of the camcorder 100.
  • step S152 based on the instruction from CPU 211, encoder 203 generates TS based on the input signal.
  • the instruction to start recording is received in step S151, and the digital tuner 201c is used in step S152 to extract the TS packet of the program to be recorded.
  • step S153 the media control unit 205 sequentially writes the TS (clip AV stream) to which the TTS header is added by the TS processing unit 204 to the removable HDD.
  • step S154 the media control unit 205 determines whether to create a new clip (TTS file). Whether or not to create a new file depends on the TTS file of the clip being recorded. It can be arbitrarily determined depending on whether the size of the disk is larger than the predetermined value or the remaining capacity of the removable HDD. If a new clip is not created, the process proceeds to step S155, and if a new clip is generated, the process proceeds to step S156.
  • step S 155 TS processing section 204 generates a KPU entry and a time entry every time a key picture unit KPU is generated.
  • the media control unit 205 sets “Ob” in the Overlapped KPUFlag field in the KPU entry.
  • step S157 the media control unit 205 writes the time / address conversion table (clip timeline ClipTimeLine) including the KPU entry and time entry to the removable media.
  • step S158 the CPU 211 determines whether or not the photographing end power is good. Shooting ends when, for example, a shooting end instruction is received via the instruction receiving unit 215, or when there is no removable HDD to which data is to be written next. When it is determined that the photographing is finished, the recording process is finished. When shooting is continued, the process returns to step S152, and the subsequent processes are repeated.
  • step S156 the TS processing unit 204 determines whether or not the key picture unit KPU is completed based on the last written data. If the key picture unit KPU is not completed, the remaining data of the key picture unit KPU will be stored in another removable HDD. Therefore, this kind of judgment is necessary to judge whether or not all the data of the key picture unit KPU has been written into the removable HDD.
  • the process proceeds to step S155, and when completed, the process proceeds to step S159.
  • step S159 the TS processing unit 204 performs clip switching processing.
  • the specific contents of this process are shown in Fig. 16.
  • FIG. 16 shows a procedure for clip switching processing.
  • the recording media of content (clips) is switched from one removable HDD to another removable HDD, or a new clip is created on the same removable HDD.
  • the switching power of the clip is a change in the recording media of the content. It is equivalent.
  • the removable HDD on which content has been recorded is called the “first removable HDD”
  • the removable HDD on which the content is recorded next is called the “second removable HDD”.
  • step S161 the CPU 211 determines a clip name of a clip generated on the second removable HDD.
  • step S162 the camcorder 100 generates TS until the key picture unit KPU that could not be completely recorded on the first removable HDD is completed.
  • the TS processing unit 204 attaches a TTS header, and the media control unit 205 writes the clip AV stream to the second removable HDD.
  • step S163 the media control unit 205 generates a KPU entry and time entry for the completed KPU.
  • the media control unit 205 sets “lb” in the Overlapped KPUFlag field in the KPU entry.
  • step S164 the media control unit 205 writes the time / address conversion table (clip timeline ClipTimeLine) including the generated KPU entry and time entry to the first removable HDD.
  • step S165 the clip 'metadata (relation information, etc.) on the first removable HDD is updated. For example, the media control unit 205 writes a UMID or the like that identifies the clip on the second removable HDD as the next clip in the clip metadata of the clip on the first removable HDD. Also, the UMID that identifies the clip on the first removable HDD is written as the previous clip in the clip metadata of the clip on the second removable HDD.
  • step S1 66 the media control unit 205 sets the future content write destination to the second removable HDD, and the process ends.
  • the camcorder 100 reproduces content from the removable HDD, more specifically, based on the designated reproduction start time, the content is reproduced from the position corresponding to that time.
  • the process to reproduce will be described. Note that the processing when playing from the beginning of the content is the same as the conventional processing that does not provide KPU entry, time entry, etc., and the description thereof is omitted.
  • FIG. 17 shows the procedure of content playback processing by the camcorder 100.
  • Step S17 In 1 the CPU 211 of the camcorder 100 receives an instruction for the playback start time from the user via the instruction receiving unit 215.
  • step S172 the media control unit 205 reads the time / address conversion table (clip timeline ClipTimeLine), and the CPU 211 identifies the key picture unit (KPU) including the picture at the reproduction start time.
  • step S173 the CPU 211 specifies the start position of the KPU corresponding to the playback start time.
  • the start position of this KPU represents the decoding start position (address) in the TTS file.
  • the CPU 211 identifies that the playback start time is between time entry #t and time entry # (t + 1), and further calculates m access unit time (AUTM) by counting from time entry #t. Specify how many units apart.
  • AUTM m access unit time
  • KPU #k a certain KPU (referred to as KPU #k) is specified based on the value of the KPUEntryReferencelD field 97a of time entry #t. Then, the time difference from the time indicated by time entry # to the start of playback of the first key picture of KPU #k is obtained based on the value of TimeEntryTimeOffset field 97c. As a result, it is determined how many AUTM after the picture power to be played first is displayed in KPU # k. Then, by adding the KPU period (KPUPeriod) for each KPU from KPU #k, the KPU that includes the picture to be played can be identified.
  • KPUPeriod KPU Period
  • the KPU corresponding to the playback start time is added to the KPU start address indicated by time entry #t.
  • the starting position can be specified.
  • the "KPU start address indicated by time entry #t" can be obtained by calculating the sum of the value of ClipTimeLineAddressOffset field 95d and the value of KP UEntryStartAddress field 97b of time entry #t.
  • the media control unit 205 reads the flag in the KPUEntry of the key picture unit (KPU), and determines whether or not the value of the Overlapped KPUFlag field 98a is "lb" in step S175.
  • the value is “lb”, it means that the key figure KPU extends over the first and second removable HDDs, and the process proceeds to step S176.
  • the value is “Ob”, it means that the value does not straddle and the process proceeds to step S177.
  • step S176 the media control unit 205 reads the data of the first picture data of the KPU stored in the first removable HDD, and when the TS processing unit 204 removes the TTS header, the decoder 206 starts decoding the data power. To do. At this time, depending on the specified picture, the data may be stored in the second removable HDD instead of the first removable HDD that started reading. Two taps (TTS file) for correct decoding Decoding is performed from the top key picture of KPU that straddles.
  • TTS file Two taps
  • step S177 the media control unit 205 reads data from the first picture data of the KPU, and when the TS processing unit 204 removes the TTS header, the decoder 206 starts decoding the data. All the picture data to be read is stored in the removable HDD.
  • step S178 after the decoding of the picture corresponding to the reproduction start time is completed, the graphic control unit 207 starts output from the picture.
  • the speaker 209b also starts its output. Thereafter, the content is played back until the end of the content or until playback is instructed, and then the process ends.
  • FIG. 18 (b) shows the relationship between the management information (clip timeline) after deleting the range D and the clip AV stream.
  • the management information clip timeline
  • not all of the range D is always deleted, but only the data amount n times (n: integer) of 96 kilobytes is deleted from the data amount falling within the range D.
  • n integer
  • p2—pi the first data position after deletion is address p2
  • p2—pi is (96 kilobytes) ⁇ n .
  • “96 kilobytes” is the least common multiple of the cluster size (32 kilobytes) employed in the present embodiment and the packet size (192 bytes) of the TTS packet.
  • the reason for this processing is that data deletion processing for removable HDDs can be executed in units of access by setting it as an integer multiple of the cluster size, and data deletion processing can be performed by setting it as an integer multiple of the packet size of the TTS packet. This is because the clip AV stream can be executed in units of TTS packets, so the processing can be performed quickly and easily.
  • the cluster size is 32 kilobytes
  • the deletion unit is determined based on 96 kilonoits. However, this value can change depending on the cluster size and the packet size of the clip AV stream to be used. .
  • the values of the ClipTimeLineTimeOffset field 95c and the ClipTime LineAddressOffset field 95d are also changed. These values are 0 before deletion.
  • the amount of data up to the first visible key unit KPU is described in the ClipTimeLineAddressOffset field 95d. If the storage address of the first KVC that appears for the first time is p3, the ClipTimeLineAddressOffset field 95d describes the value of (p3 – p2).
  • the ClipTimeLineTimeOffset field 95c the time difference from the playback time of the first key picture in the first key picture unit KPU to the first time entry is described in AUTM units. Note that the clip AV stream packets up to address p2 and power p3 are treated as fragments and are not subject to playback because there is no guarantee that they can be decoded independently.
  • FIG. 19 shows a procedure for content partial deletion processing by the camcorder 100.
  • the CPU 211 of the camcorder 100 receives a partial deletion instruction of the TTS file and designation of the deletion range D from the user via the instruction receiving unit 215.
  • the partial deletion instruction is an instruction to delete the head part and the Z or tail part of the TTS file.
  • “front part deletion process” for deleting the head part and “rear part deletion process” for deleting the Z or tail part are performed.
  • step S192 it is determined whether or not the front portion deletion processing power is acceptable. If forward part deletion processing is performed, the process proceeds to step S193, and if not forward part deletion, the process proceeds to step S195.
  • the media control unit 205 deletes the data amount that is an integral multiple of 96 kilobytes from the beginning of the data amount D corresponding to the deletion range.
  • the media control unit 205 sets the time offset value (the value of the ClipTimeLineTime Offset field 95c) for the first time entry and the address offset for the first KPU entry in the time 'address conversion table (clip time line). Correct the value (value in ClipTimeLineAddressOffset field 95d). Thereafter, the process proceeds to step S195.
  • step S195 it is determined whether or not the backward partial deletion processing power is acceptable. If the backward partial deletion process is performed, the process proceeds to step S196. If not, the process proceeds to step S197.
  • step S196 data is deleted in units of 192 bytes so that the end of the TTS file becomes a complete KPU out of the amount of data corresponding to the deletion range. This means that data with an integral multiple of 192 bytes is deleted. Thereafter, the process proceeds to step S197.
  • step S197 the number of time entries and the number of KPU entries changed by the partial deletion process are corrected. Specifically, in the time address conversion table (ClipTimeLine), the KPUEntry entry that no longer accompanies the actual data, and the TimeEntry entry that has lost the KPUEntry entry referenced by KPUEntryReferencelD are deleted. In addition, correction processing such as the value of the TimeEntryNumber field 95a and the value of the KPUEntryNumber field 95b is performed.
  • step S197 the process goes through step S197 also when neither the front part deletion process nor the rear part deletion process is performed. This is for example the process of deleting the middle part of a TTS file It is assumed that the correction process is also performed when. However, the removal process of the middle part is not particularly mentioned in this specification!
  • the partial deletion process is not limited to the top part of the TTS file, and a range including the end part of the TTS file may be deleted.
  • This processing is applied, for example, when deleting the above-mentioned incomplete key picture unit KPU (KPU # d1 in FIG. 14). Since the incomplete key-picture unit KPU exists at the end of one clip, it corresponds to “the range including the last part of the TTS file”.
  • the range to be deleted at this time is from the beginning of the incomplete key picture unit KPU to the end of the TTS file.
  • the range to be deleted may be determined in units of packet size (192 bytes) of the TTS packet. The cluster size need not be considered.
  • the last part of the TTS file is not limited to an incomplete key picture unit KPU, but can be arbitrarily determined by receiving a user power range designation. It should be noted that the deletion process of the head part and the deletion process of the tail part may be performed continuously, or only one process may be performed.
  • the data processing apparatus according to the present embodiment is a camcorder having the same hardware configuration as the camcorder according to the first embodiment (FIG. 2). Therefore, in the description of the present embodiment, reference numeral 100 is attached for explanation. A more detailed configuration will be described later with reference to FIG.
  • Embodiment 1 The main difference between this embodiment and Embodiment 1 is that the camcorder first records 24 frames per second video in the MPEG-2 stream at 60 frames per second by 3: 2 pull-down. Second, the time code value counted by the camcorder at 24 frames per second is recorded in the stream and in the clip metadata file.
  • Figures 20 (a) to 20 (c) show the relationship of the display timing of each frame when converting the video of 24 frames per second to 60 frames per second using the 3: 2 pull-down technology.
  • Video at 60 frames per second is recorded on a recording medium (for example, a removable HDD) as a data stream conforming to the MPEG-2 standard.
  • the number of horizontal and vertical pixels in this data stream is 1280 and 720, respectively.
  • the data stream is the clip AV stream described in the first embodiment.
  • FIG. 20 (a) shows the picture structure of the head portion of the clip AV stream and the corresponding management parameters.
  • the first KPU # 0 and the next KPU # 1 of the clip AV stream are composed of the following picture cameras (recording order is IB ⁇ ).
  • FIG. 20 (b) shows a time code counted at 24 frames per second. This time code indicates the display timing of each picture of the video before pull-down. Note that 24 frames per second video is realized by switching and displaying 24 frame pictures per second. Each picture is displayed for 1Z24 seconds. In other words, the vertical scanning frequency of the image is 24Hz.
  • FIG. 20 (c) shows a time code counted at 60 frames per second.
  • This time code indicates the display timing of each picture of the video after pull-down.
  • 60 frames per second video is realized by switching and displaying 60 frame pictures per second.
  • Each picture is displayed for 1Z60 seconds.
  • the vertical scanning frequency of the image is 60Hz.
  • each picture that was displayed for 1Z24 seconds is displayed for 3Z60 seconds or 2Z60 seconds by the 3: 2 pull-down process.
  • the latter display means that the frame displayed for 1/60 second is output three times or twice continuously.
  • Each frame before conversion is displayed alternately for 3Z60 seconds and 2Z60 seconds after conversion.
  • One of the features of the camcorder according to this embodiment is that a time code counted at 24 frames per second is recorded in the data stream after pull-down. More specifically, the conventional clip AV stream has at least one time code value shown in FIG. 20 (c). In the data stream according to the present embodiment, a time code value shown in FIG. 20B is described for each picture.
  • a transport stream is taken as an example.
  • a clip AV stream can be obtained by adding a TTS header to the transport stream.
  • FIGS. 21A to 21C show the data structure of the stream according to this embodiment.
  • Figure 21 (a) Each video TS packet 40a to 40d of the TS 40 shown includes the PES 41 shown in FIG. 21 (b).
  • PES41 consists of PES packets 41a and 41b.
  • Each PES packet may contain one video field or two video field pairs (ie, two video fields).
  • a presentation time stamp (PTS) indicating the display timing of the picture data stored in the PES payload is written in the header of the PES packet.
  • the PES header 41a-1 stores PTS-1 of the picture data stored in the PES payload 41a-2.
  • the PTS value indicates the display start timing of each picture on the time axis after pull-down in FIG.
  • the difference from the time code value that counts at 60 frame seconds per second is that it counts with a 90 kHz clock.
  • the timing for displaying a picture indicates the same time regardless of whether it is a PTS value or a time code value.
  • Figure 21 (c) shows the data structure of the PES payload.
  • the PES payload 41a-2 in this example includes a GOP header 42e, a picture header 42a, and picture data 42b.
  • the GOP header 42e is appended before the picture data arranged in the first picture of the GOP, and is not necessarily arranged before all the picture data.
  • the GOP header 42e records a time code that is counted at 60 frames per second in accordance with the MPEG-2 video standard.
  • FIG. 21 (c) the start time code tl of the picture to be displayed first is described.
  • values can be basically freely stored in the user data field. However, it is necessary to consider setting a specific bit to 1 in a 4-byte cycle so that it does not overlap with a specific 4-byte code (for example, 0x000001B3 which is a sequential header code).
  • the data structure of the time code is generally the SMPTE M12 standard.
  • FIG. 34 shows an outline of the time code data structure conforming to the SM PTE Ml 2 standard.
  • the time code shown in Fig. 34 is a total of 4 bytes of data, and is divided into addresses 00 to 03 in units of 1 byte. Each byte is further divided into two fields (4 bits each) to give meaning.
  • the figure describes the standard meaning of each field and the range of values for each field.
  • the standard further defines Drop Frame Flag, Binary User Group Bit, etc.
  • the camcorder 100 generates an MPEG-2 transport stream of 60 frames per second by the MPEG-2 encoder 203 from the video of 24 frames per second output from the CCD 201a, and records it as a shot on a removable HDD.
  • the MPEG-2 encoder 203 stores a time code that counts up every 24 frames per second in the user data field of the picture layer.
  • MPEG-2 encoders record a picture with a period of 1Z60 times for 3: 2 pulldown recording.
  • MPEG-2 video stream is generated so that it is displayed alternately for 3 periods or 2 periods.
  • Instructions for displaying 3 periods or 2 periods are stored in the picture header according to the MPEG standard. Specifically, if both the repeat-first-field and top-field-f irst values are 1, it means 3 periods, and if the values are 1 and 0, it means 2 periods.
  • the camcorder 100 reads the clip AV stream recorded on the removable HDD, and the decoder 206 performs the decoding process. At this time, the time code that counts at 24 frames per second recorded in the user data field of the picture layer is acquired, and the value is overlaid on the video.
  • FIG. 22 shows a configuration of partial functional blocks of the camcorder 100 according to the present embodiment. Compared with the hardware configuration diagram shown in FIG. 2, FIG. 22 shows the encoder 203, the TS processing unit 204, the media control unit 205, the decoder 206, and the system control unit 250 in detail.
  • the video compression unit 203a and the audio compression unit 203b of the encoder 203 compress the input video signal and audio signal to generate picture data and audio data under the control of the recording control unit 161 To do.
  • the system encoding unit 203c of the encoder 203 receives the picture data and the audio data and generates a transport stream.
  • the system encoding unit 203c generates the headers shown in FIGS. 21 (b) and (c). That is, the system encoding unit 203c generates picture headers 42a and 42c storing the time codes t2 and t3 shown in FIG. 21 (c). Time codes t2 and t3 are described in the user data (extention # and # user # data (2)) field in the picture header. Further, the system encoding unit 203c generates a GOP header 42e storing the time code tl shown in FIG. 21C, and generates a PES header 41a-1 storing the PTS-1 shown in FIG. 21B.
  • FIG. 35 shows a data structure of a video stream conforming to the MPEG-4 AVC standard.
  • a time code can be described as a Picture Timing SEI Message of the standard immediately before a picture composed of only I slices. This time code corresponds to the time code counted at 60 frames per second stored in the GOP header in the previous examples.
  • the time code counted at 24 frames per second in the picture header is MPEG
  • AU delimiter indicates a frame delimiter
  • SPS Sequence Parameter Set
  • PPS Picture Parameter Set
  • IDR pictures correspond to MPEG-2 video I pictures.
  • One frame of MPEG-4AVC video stream is recorded in one PES packet, and PTS is added to the PES header. While this PTS is given based on a period of 60 frames per second as shown in FIG. 21, a time code counted at 24 frames per second is recorded in the User Data Unregistered SEI Message.
  • the time code in the Picture Timing SEI Message may be described immediately before all frames, rather than just for the GOP header.
  • the Time Code that counts at 60 frames per second may not be described in the Picture Timing SEI Message.
  • the User Data Unregistered SEI Message may be described in parallel with the time code that counts at 24 frames per second.
  • a time code that counts at 24 frames per second may be described in the Binary Group area.
  • the Gorup area is an area in which a 4-byte free value specified by the time code standard (SMPTE 12M) can be set. Also, it is not necessary to record a time code of 60 frames per second in the video stream.
  • the TS processing unit 204 generates a clip AV stream from the transport stream.
  • the clip AV stream is sent to the hard disk 14 via the recording unit 205a and the magnetic head 141. Written to 0.
  • the recording control unit 161 activates the continuous data area detection unit 160 before starting the recording of the clip AV stream, and causes the empty area to disappear.
  • the continuous data area detection unit 160 searches the space bit map from which the optical disk power managed by the logical block management unit 163 is also read, and searches for a continuous free area. Then, the clip AV stream starts to be written in the empty area detected as a result of the search. Then, until the writing to the area is completed, the next empty area is continuously searched and the clip AV stream is continuously written.
  • the file management information of the UDF is written, and the writing of the clip AV stream (* .TTS file, that is, the file storing the video stream) is completed.
  • a stream management data file (* .clpi) corresponding to the clip AV stream that has been recorded is recorded.
  • the management information of the clip AV stream corresponding to the content is read out via the playback unit 205b under the control of the playback control unit 162.
  • the clip AV stream is further read out by referring to the address information described in the management file.
  • the TS processing unit 204 generates a transport stream from this clip AV stream.
  • the system decoding unit 206c separates the video data and the audio data
  • the video expansion unit 206a and the audio expansion unit 206b decode the video data and the audio data, respectively, and output them as a video signal and an audio signal.
  • the edit control unit 164 activates the recording unit 205a and the playback unit 205b when the user is instructed to partially delete recorded content, and the clip AV stream and its management data Control of editing processing such as reading or writing after modification.
  • the recorded content is instructed to be deleted by the user, the corresponding tag AV stream and stream management data file are deleted.
  • the camcorder according to the present embodiment also generates a clip metadata file corresponding to the clip AV stream file.
  • the clip metadata file may be generated by the media control unit 205 or the CPU 211 of the system control unit 250! ,.
  • FIG. 23 shows the data structure of the clip metadata file 300. Contains the following fields: clip name 30 Oa, playback time length 300b: EditUnit length 300c, relation 300d, and essence disc ⁇ 300e. Further, the essence list 300e includes a format type 300f, a peak bit rate 300g, and video fields 300h.
  • the video field 300h includes codec information 300i, profile Z level 300j, frame rate information 300k, number of pixels 3001, drop frame flag 300300m, pull-down information 300n, start time code 3 OOo, end time code 300p, aspect ratio 300q, and no playback Includes fields of section length 300r and top 3 frame flag 300s.
  • the playback time length field 300b represents the playback time length of one clip in EditUnit units.
  • the EditUnit length field 300c specifies the time length of one unit of EditUnit length. In Fig. 23, 1Z24 seconds is specified. This indicates that the original video is displayed at 24 frames per second.
  • the video frame rate of the clip AV stream file corresponding to the clip metadata file 300 is specified in the frame rate information 300k.
  • the name of the TTS file (MOV00002.TTS) of the subsequent clip in the same shot is recorded.
  • the format type field 300f the format type of the clip AV data is registered as Timed TS.
  • the peak bit rate Finored 300g registers that the peak bit rate of the MPEG-2 transport stream is 24Mbps.
  • the codec information, profile Z level information, frame rate information, pixel number information (horizontal X vertical), drop frame flag, pull-down information, and aspect ratio fields are MPEG-2 Video and MP respectively. @HL, 1/60, 1280 X 720, non-drop, 3: 2 pulldown, 16: 9, OEditUnit is recorded!
  • the time code (start time code) of the first picture to be played back in the clip is recorded in the field 300 ⁇
  • the time code (end time code) next to the last picture to be played back is recorded in the field 300 ⁇ .
  • Is recorded Is recorded.
  • These timecode values are recorded as hours: minutes: seconds: frame numbers.
  • the frame specified by this “frame number” is displayed at the rate specified in the frame rate information 300k. Therefore, the frame number is 5 Increases to 9, then returns to 0.
  • values of 00: 00: 00: 00: 00 and 00: 01: 00: 00 (length of 1 minute) are registered.
  • the end time code may be the time code value of the last picture.
  • the leading three frame flag 300s indicates whether the leading picture power corresponding to the start time code 300 ⁇ corresponds to a three-frame section or a two-frame section. In the former case, the value is 1, and in the latter case, the value is 0. In Figure 23, the value is assumed to be set to 1.
  • the camcorder 100 generates a clip AV stream file and a clip metadata file 300 having the above data structure.
  • a clip AV stream file and a clip metadata file 300 having the above data structure.
  • FIG. 24 shows a processing procedure for identifying a picture corresponding to a time code value based on the time code value. This process will be specifically described later.
  • FIG. 25 shows the management parameters when one shot is composed of one TTS file.
  • FIG. 25 shows the arrangement of each KPU as viewed from the display time.
  • the start time code (300 ⁇ ) and KPU period (298c) are as shown in Figure 20.
  • the playback time length, StartSTC, and ClipTimeLineDuration are the same as in the first embodiment.
  • Figure 26 shows the meanings of the management parameters when ClipTimeLineAddressOffset is not zero and one shot consists of one TTS file. Compared to Fig. 25, the point (which is specifically excluded from the playback time length) differs when the section length that is not replayed is zero and the second half of the last KPU is not replayed. P2, p3, and p4 in Fig. 26 correspond to p2, p3, and p4 in Fig. 18, respectively.
  • the upper and lower sections of the TTS file shown in Fig. 26 show the same clip AV stream.
  • the top row shows the arrangement of each KPU in the TTS file in terms of display time, and the horizontal axis is labeled “Time”.
  • the bottom row shows the array of each KPU in the TTS file in terms of data size, and the label on the horizontal axis is “data size”.
  • Figure 27 shows the management parameters when one shot consists of a chain of multiple TTS files. Indicates the meaning of the data.
  • ClipTimeLineDuration of each TTS file is the total of KPU period of KPUEntry (295h) of time map file corresponding to each TTS file.
  • the camcorder 100 acquires a time code that counts at 24 frames per second recorded in the user data field.
  • the graphic control unit 207 displays the value as an overlay on the video.
  • the user can confirm the time code value of the video to be handled as the IN point, the OUT point, or the point of interest by looking at the time code value displayed as an overlay on the video.
  • the camcorder acquires the time code value of the video, and sets the acquired time code value as the IN point and OUT point values in the playlist, for example.
  • the user inputs a time code value (S310).
  • the edit control unit 164 refers to the clip metadata file 300, and firstly adds a value obtained by adding the non-reproduced section length (300r) to the difference between the input time code value and the start time code value (295f).
  • the difference time code value is calculated (S311).
  • the non-reproduced section length (300r) is described in units of value power 3 ⁇ 4dit Unit indicating n frames when, for example, reproduction after the GOP head force (n + 1) frame is designated.
  • edit control section 164 uses the difference time code value to calculate a target STC value that is a corresponding STC value.
  • This target STC value is substantially the same as the PTS value of the picture to be specified.
  • the calculation formula when the value of the first 3 frame flag is 1 is shown in S312 of FIG.
  • the S312 Ceil (x) function (where X is a real number) takes an integer value that is greater than or equal to the value X and closest to X as the function value.
  • the reason why the differential time code value is multiplied by 5Z2 here is because it is recorded as an MPEG stream with a 3: 2 pulldown per second. If the value of the top 3 frame flag is 0, the target STC value can be obtained from the following equation.
  • the edit control unit 164 adds the KPU period (298c) of each KPUEntry (295h) in order from the KPUEntry of KPU # 0,
  • the first KPU number (which is assumed to be k) is derived (S313).
  • the address of the picture corresponding to the specified time code value is included in KPU # k.
  • the edit control unit 164 obtains the storage destination address of this KPU #k from the following equation (S314).
  • ⁇ KPUSize is from KPU # 0 to KPU # k. Furthermore, the edit control unit 164 obtains a difference STC between the first picture of KPU #k (however, in display order) and the picture corresponding to the time code value from the following equation (S315).
  • the data processing apparatus according to the present embodiment is a camcorder having the same hard- ware configuration as the camcorder according to the second embodiment (FIGS. 2 and 22).
  • the main difference between Embodiment 3 and Embodiment 2 is the data structure of the KPUEntry field generated by the camcorder.
  • the KPUEntry field is included in the clip timeline and is generated by the media control unit 205.
  • Figures 28 (a) to 28 (c) show the relationship between the display timing of each frame when 24 frames per second video is converted to 60 frames per second using 3: 2 pull-down technology. .
  • the number of horizontal and vertical pixels in this data stream is 1280 and 720, respectively.
  • FIG. 28 (a) to (c) are different from FIG. 20 (a) to (c) described in relation to Embodiment 2 as follows.
  • the first difference is that a field (398c) indicating a PTS difference (PTS Difference) is provided in the KPUEntry instead of the KPU period (KPUPeriod).
  • PTS Difference a value representing the difference between the PTSs of key structures between a certain KPU and the next KPU, that is, between adjacent KPUs, is described in AUTM units.
  • StartKeySTC 395f
  • StartSTC 295f
  • a value expressing the display timing of the first I picture in the first KPU (KPU # 0) in one TTS file in AUTM units is described.
  • TimeOffset (395i) is provided.
  • TimeOffset field a value expressing the time difference between the first picture displayed in the first KPU and the first I-picture in the KPU in AUTM units is described.
  • the time difference between the first B picture displayed in KP U # 0 and the first I picture in the same KPU # 0 is shown, that is, the 5-frame interval in 60 frames per second. The value is described in the TimeOffset field.
  • FIG. 29 shows the data structure of the clip metadata file 400 according to the third embodiment.
  • This clip metadata file 400 is one file when one shot consists of three clips. A clip metadata file corresponding to the eye clip is shown.
  • the 400 fields 400a to 400s correspond to the fields 300a to 300s shown in FIG. They are the same except for the setting value in the field 400b where the playback time length is described.
  • FIG. 30 shows the data structure of the ClipTimeLine file 395 in the present embodiment.
  • the difference between FIG. 28 and FIG. 20 is reflected in this ClipTimeLine file 395.
  • a field describing the PTS difference (398c) is provided in KPUEntry395h instead of the KPU period.
  • a field for describing StartKeySTC (395f) is provided instead of StartSTC (295f).
  • a field describing TimeOffset (395i) is provided. Note that the ClipTimeLine file 395 does not include the time entry field 95g shown in FIG. 12 described in relation to the first embodiment.
  • FIG. 31 shows a processing procedure for identifying a picture corresponding to a time code value based on the time code value. This process will be specifically described later.
  • Figure 32 shows the meaning of the management parameters when one shot is composed of one TTS file.
  • the meaning of the start time code (400 ⁇ ) is the same as the start time code (300 ⁇ ) in Fig. 25.
  • the meaning of the playback time length and ClipTimeLineDuration is as described in the first embodiment.
  • the difference from FIG. 25 is that the StartSTC field (295f) in FIG. 25 is changed to StartKeyS TC Finored (395f)!
  • FIG. 33 shows the meanings of the management parameters when ClipTimeLineAddressOffset in Embodiment 3 is not zero and one seat is composed of three TTS files. Compared to Fig. 32, the difference is that the section length that is not played back is not zero, and the second half of the last KPU is not played back (specifically, it is specified by the end time code and not included in the playback time length).
  • p2, p3, and p4 in FIG. 33 correspond to p2, p3, and p4 in FIG. 18, respectively.
  • the playback time length of the TTS file is from the playback start point referenced by the start time code to the key picture in the first complete KPU in the subsequent TTS file. It is a point that counts by EditUnit.
  • the playback time length of the second TTS file is the time difference from the first full KPU key picture in the TTS file to the first full KPU key picture in the subsequent TTS file. It is a point to count in tUnit.
  • the playback time length of the last TTS file of one shot is the point that counts from the first complete KPU key picture in the TTS file to the last picture to be played in EditUnit units.
  • the playback time length of the TTS file between the first file and the last file is Set the same value as the playback time length of the second TTS file of 32.
  • TimeOffset (395i) is specified only for the first TTS file in the TTS file chain.
  • the playback time length of one shot can be managed with picture accuracy.
  • the PTS difference since the PTS difference only needs to be detected for the MPEG-2 stream I picture, the processing is simpler than the case of counting the total number of pictures. Therefore, the PTS difference can be easily detected even in the external circuit of the MPEG encoder.
  • KPU entries can be easily created even when broadcasting waves are recorded via the camcorder's IEEE1394 interface or tuner.
  • TimeOffset can be easily set by detecting the number of frames before the I picture only at the head of the shot.
  • the TimeOffset value can be easily set by using a fixed value for the number of frames before the I picture only at the beginning of the MPEG encoder power shot.
  • the TimeOffset value can be set easily by analyzing the clip AV stream from an external device, etc.
  • TimeOffset is managed only at the beginning of the shot, even if the structure of the picture that composes the GOP of the MPEG-2 video stream changes in the middle of the stream, there are methods for generating TimeOffset and PTS differences. It does not affect. For example, even if the picture structure that constitutes one GOP changes (in the recording order) from IBBPBB force to IPBB or IPIP in the middle of the stream, it does not affect the management data generation procedure. As a result, the GOP structure of the stream can be freely changed, so the IPB B GOP structure can be temporarily set immediately after the scene change is detected, and the image quality can be improved. [0231] As described above, the value of TimeOffset is easy to set and can be detected by an external circuit of the MPEG encoder.
  • camcorder 100 The operation of the camcorder 100 according to the present embodiment will be described.
  • the specific operation for the camcorder 100 to generate the clip AV stream and the process for playing back the clip AV stream are the same as those of the camcorder according to the second embodiment. Therefore, the description is omitted.
  • the camcorder 100 generates a clip metadata file corresponding to the clip AV stream file.
  • the clip metadata file is generated by the media control unit 205 (or the CPU 211 of the system control unit 250).
  • the media control unit 205 describes the PTS difference value in the PTS difference field (398c) in the KPU Entry 395h, and describes StartKeySTC in the StartKeySTC (395f) field. Further, the media control unit 205 describes TimeOffset in the TimeOffset (395i) field.
  • the user can check the time code value of the video to be handled as the IN point, the OUT point, or the point of interest by looking at the time code value displayed as an overlay on the video.
  • the camcorder acquires the time code value of the video, and sets the acquired time code value as the IN and OUT point values in the playlist, for example.
  • edit control section 164 uses the difference time code value to calculate a target STC value that is a corresponding STC value. As described in connection with Embodiment 2, this target STC value is substantially the same as the PTS value of the specified picture.
  • the calculation formula when the value of the first three frame flags is 1 is shown in S412.
  • the S412 Ceil (x) function (where X is a real number) takes the integer value that is greater than or equal to the value X and closest to X as the function value. The reason why the differential time code value is multiplied by 5/2! / Is because it is recorded as a 3: 2 pull-down MPEG stream per second. If the value of the top 3 frame flag is 0, the target STC value can be obtained from the following equation.
  • Target STC value StartSTC (395f)
  • the floor (X) function (where X is a real number) takes the integer value that is less than or equal to the value X and is closest to X as the value of the function value.
  • the edit control unit 164 adds the PTS difference (398c) of each KPUEntry (395h) in order from the KPUEntry of KPU # 0,
  • the first KPU number (with that number as k) is derived (S413).
  • the address of the picture corresponding to the specified time code value is included in KPU # k.
  • the edit control unit 164 obtains the storage destination address of this KPU #k from the following equation (S414).
  • ⁇ KPUSize is from KPU # 0 to KPU # k.
  • the edit control unit 164 obtains a difference STC between the first picture of KPU #k (however, in display order) and the picture corresponding to the time code value from the following equation (S415).
  • Target STC value (StartKeySTC value + ⁇ KPUDiff erence)
  • the media control unit 205 can generate a clip metadata data file and a ClipTimeline file for realizing designation by time code without obtaining the information of the picture configuration constituting the GOP from the encoder 203. . Therefore, the media control unit 205 can generate the clip metadata data file 400 and the ClipTimeline file 395 even if the picture configuration constituting the GOP of the clip AV stream changes. Then, the editing control unit 164 can start editing and reproduction from the frame corresponding to the described time code.
  • TimeOffs et (3951) is managed in addition to PTS difference (398c)! Therefore, it is easy to accurately record the number of frames recorded in one shot. It can be calculated. As a result, the user can edit the video in units of frames.
  • the frame rate of the video input to the apparatus is 24 frames per second. But this is an example. As another example, it may be 23.97 frames per second (1001Z24000 frames). Also, the frame rate of the video generated by the device is 60 frames per second. Another example is 59.94 frames per second (1001Z60000 frames)! / ⁇ .
  • an example was given in which an image of 24 frames per second was subjected to 3: 2 pulldown processing to generate an MPE G-2 stream of 60 frames per second.
  • 24 frames per second time code is recorded in the stream only when a 24 frames per second video is generated and recorded as a 60 frames per second video stream. Even if 60 frames per second video is recorded in a video stream of 60 frames per second, for example, a time code of 60 frames per second may be recorded in the picture header.
  • the playback control unit can always display the overlay on the video by referring to the picture header without depending on the number of video frames.
  • processing may be performed based on a field that is not based on a video frame.
  • a video of 24 frames per second may be pulled down 3: 2 to generate an MPEG-2 video stream with 60 fields (or 59.94 fields) per second (eg, horizontal 1920xvertical 1080 pixels or horizontal 720xvertical). May be 480 pixels).
  • the flag generation standard described in the first 3 frame flags 300s, 400s.
  • the flag value may be set to 1 when it corresponds to 3 fields in 60 fields of picture power referenced by the start time code (300 ⁇ , 400 ⁇ ), and the flag value should be set to 0 when it corresponds to 2 fields. .
  • These flags are called the top 3 field flags rather than the top 3 frame flags.
  • Figures 36 (a) to (c) show the relationship of the display timing of each frame when converting the video of 24 frames per second to 60 frames per second using 3: 2 pull-down technology.
  • Video at 60 frames per second is recorded on a recording medium (for example, a removable HDD) as a data stream conforming to the MPEG-2 standard.
  • a recording medium for example, a removable HDD
  • This figure corresponds to Figure 20, which shows a 3: 2 pulldown to an MPEG-2 video stream at 60 frames per second.
  • Each frame shown in Fig. 36 (a) is recorded with a 3: 2 pull-down in order of 3 field periods, 2 field periods, and 3 field periods from the beginning.
  • the section of the first three-field period is recorded so as to be displayed in the order of the top field, bottom field, and top field of the first B picture (frame).
  • the next B picture is recorded so that it is displayed in the order of bottom field and top field.
  • Another example of processing based on the field is when 25 frames per second of video is recorded by 2: 2 pull-down processing. That is, one frame in 25 frames per second is encoded and recorded as 2 fields in an MPEG-2 video stream with 50 fields per second. You can record it.
  • Still another example of the processing based on the field is a case where one frame in a video of 30 frames per second is subjected to 2: 2 pull-down processing and recorded.
  • one frame in 30 frames per second may be recorded as 2 fields in an MPEG-2 video stream with 60 fields per second.
  • the top 3 frame flag is recorded. However, it may be determined in advance whether the picture referred to by the start time code (300 ⁇ , 400 ⁇ ) is compatible with 3 frame display or 2 frame display. In this case, however, care must be taken to always support 3 frames after editing the G stream.
  • the top 3 frame flag is information related to the picture referred to by the start time code. However, it may be information regarding a picture to be played back, in which only a picture corresponding to a section length (300r, 400r) not to be played is skipped. Furthermore, the playback start time (unit: PTM) of the playback start picture and the time code counted in 24 frames may be held as management data. At this time, the recording address of the corresponding picture can be specified from the time code value with reference to the reproduction start time and the time code of the reproduction start picture.
  • PTM playback start time
  • the top KPU of the clip AV stream starts with a frame corresponding to 3 frame display out of 60 frames per second, and is followed by a frame corresponding to 2 frame display.
  • a frame corresponding to 2 frames out of 60 frames per second may be started, followed by a frame corresponding to 3 frame display.
  • the playback time length (300b and 400b) may be a force AUTM unit specified in Edit Unit units. Both are convertible. Similarly, the section length (300r and 400r) not to be played can be specified in AUTM units.
  • the MPEG-2 transport stream in the clip AV stream is assumed to be continuous.
  • PTS, DTS, and PCR were assigned based on continuous STC. It is also assumed that 24 frames per second time code is given continuously.
  • Embodiments 2 and 3 it is assumed that the drop frame flag is off. It may be set to ON. Even when it is on, the rule for skipping the count value is fixed, so the conversion is uniquely possible between when it is off and when it is on.
  • Embodiments 2 and 3 an example is shown in which the time code of 24 frames per second starts at 00:00:00, but from the shooting start time (hour: minute: second: number of frames) You can start! / ⁇ , or you can start the value that is the serial number in the HDD.
  • the ability to customize the initial values of these timecodes is common for professional camcorders.
  • the MPEG-2 video stream uses an example in which two B pictures are played back before an I picture at the head of the KPU. However, it is also possible to sign so that the I picture is played back first at the top of the KPU.
  • the medium for storing the data stream or the like is a removable HDD.
  • the medium may be a non-exchangeable medium, for example, an HDD built in the data processing apparatus.
  • the data structure of the time map includes two layers, TimeEntry and KPUEntry. However, if the playback time and recording address can be converted, there is no need to limit this to the time map consisting of only one layer of KPUEntry.
  • the Overlapped KPUFlag field is provided, and based on the value, it is described that the key picture unit KPU is straddling multiple files! /. However, whether or not the force spans multiple files can be expressed even when there is no data corresponding to the time map.
  • clip metadata (relation information, etc.), clip file name naming rules (file name number in ascending order, etc.), all data of one shot in the same folder (all TTS files constituting at least one shot) It is possible to indicate that the KPU is or may be straddled, for example, by storing (recorded on the same recording medium).
  • each functional block in FIG. 2, FIG. 22 and the like is typically realized as a chip of an integrated circuit (Large Scale Integrated Circuit; LSI). These may be individually integrated into a single chip, or may be integrated into a single chip to include some or all of them.
  • LSI Large Scale Integrated Circuit
  • the system control unit 250 including the CPU 211 and the media control unit 205 are shown as separate functional blocks. Each of these may be mounted as a separate semiconductor chip, or may be realized by providing the function of the media control unit 205 to the system control unit 250 and physically using the same chip.
  • the functions of the media control unit 205 and the TS processing unit 204 may be integrated and realized as a single chip circuit, or as a chip circuit 217 with the functions of the encoder 203 and the decoder 206 added. It may be realized. However, for example, by excluding only the memory that stores the data to be encoded or decoded from the integration target, it is possible to easily cope with a plurality of encoding methods.
  • the system control unit 250 can implement the functions of the media control unit 205 described in the present specification by executing a computer program stored in the program ROM 210 or the like. At this time, the media control unit 205 is realized as a partial function of the system control unit 250.
  • LSI may be called IC, system LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or general-purpose processor.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable 'processor that can reconfigure the connection and settings of circuit cells inside the LSI may be used.
  • the storage medium is assumed to be a removable HDD.
  • the present invention is not limited to this.
  • it may be a recording medium such as an optical disk or a hard disk such as DVD-RAM, MO, DVD-R, DVD-RW, DVD + RW, CD-R, CD-RW.
  • It is also a semiconductor memory such as flash memory, FeRAM, or MRAM.
  • the clip AV stream includes a transport stream, but it conforms to other encoding formats such as a program stream and a PES stream. It may be a bitstream that includes the multimedia information that it relies on.
  • the video may be a force MP EG-4 video stream or an MPEG-4 AVC stream (H.264 stream) taking an MPEG-2 video stream as an example.
  • the audio may be a linear PCM audio stream, an AC-3 stream, or the like.
  • the force for recording StartSTC and StartKeySTC in the clip timeline file corresponding to the stream may be omitted.
  • the time code of the first frame when viewed in playback order is extracted and the time code is handled as Start STC.
  • the time code may be converted to PTS.
  • Embodiments 2 and 3 when the force pull-down process described mainly in the example of 3: 2 pull-down process is not performed (when recording normal 60 fields, 50 fields, 60 frames, or 50 frames, etc.) Even so, the time code value may be recorded at the same data position as in the pull-down processing example.
  • Embodiments 2 and 3 when 3: 2 pull-down processing is performed, the next of 3 frames is repeated as 2 frames.
  • the order may be changed as appropriate, for example, 3 frames, 2 frames, and 2 frames.
  • pull-down information Unknown.
  • the user can easily specify the INZOUT point when determining the IN point ZOUT point during video editing out of 24 frames per second. Moreover, in order to realize this, it can be realized without increasing the amount of communication with the MPEG encoder at the time of encoding of the moving image, and it is not necessary to use a special MPEG encoder. Therefore, it is useful in various devices and devices that handle 24 frames, Z seconds of AV data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Television Signal Processing For Recording (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)

Abstract

　フレームレート（垂直走査周波数）が変換された映像を編集するときにおいて、ユーザがフレームを簡易に指定できるようにする。 　データ処理装置は、複数のピクチャが第１周波数で表示される第１映像の信号を受け取る受信部と、信号に基づいて、複数のピクチャが第１周波数と異なる第２周波数で表示される第２映像のデータストリームを生成するエンコーダと、データストリームを記録媒体に記録する記録部とを備えている。エンコーダは、前記複数のピクチャの各々に対応するピクチャデータと、第１周波数で表示されるときの表示時刻を示す第１時刻情報と、第２周波数で表示されるときの表示時刻を示す第２時刻情報とを生成し、第１時刻情報、第２時刻情報および前記第１時刻情報に基づいて表示される各ピクチャのピクチャデータを対応付けて格納し、データストリームを生成する。                                                                         

Description

明 細 書
データ処理装置
技術分野
[0001] 本発明は、メディア上でコンテンツのデータストリームを効率的に管理し、そのコン テンッの再生および編集を容易にする技術に関する。
背景技術
[0002] 近年、 DVD等の光ディスク、ハードディスク等の磁気ディスク、半導体メモリ等のメ ディアにコンテンツのデジタルデータを書き込み、保存できるデジタル機器 (光デイス クレコーダ、カムコーダ等）の普及が進んでいる。このようなコンテンツは、例えば、放 送された番組やカムコーダ等によって撮影された映像および音声である。
[0003] 近年は PCにもコンテンツの記録、再生および編集機能が実装されており、 PCも上 述のデジタル機器に含めることができる。 PCでは、文書データなどのデータを記録 するために、従来力 ハードディスク、光ディスク、半導体メモリ等のメディアが利用さ れている。したがって、そのようなメディアでは、 PCと連携可能なデータ管理構造、例 えば FAT(File Allocation Table)を用いたファイルシステムが採用されている。現在 多く利用されて 、る FAT32ファイルシステムでは、最大 4ギガバイトのサイズを有する ファイルを取り扱うことができ、また最大記録可能容量が 2テラバイトのメディアを管理 することができる。
[0004] メディアの最大記録可能容量の増加に伴い、記録されるコンテンツの再生時間が 長くなつている。光ディスク、ハードディスク、半導体メモリ等はいわゆるランダムァク セスが可能なメディアであるため、そのようなメディアに長時間のコンテンツのデータ ストリームを格納するときには、コンテンツの任意の位置力も再生できると便利である
[0005] 例えば特許文献 1では、データストリームの先頭から一定の時間間隔ごとに、再生 時刻とその時刻に再生される AVデータの格納アドレスとの対応を規定したタイムマツ プ情報を生成している。ユーザ指定された開始時刻、終了時刻それぞれを、タイムマ ップ情報を参照して開始アドレス、終了アドレスに変換し、そのアドレスに格納されて いるデータを読み出すことにより、その時刻からコンテンツを再生することが可能にな つている。
[0006] 一方、近年、映像を毎秒 24フレームで記録する機能を持つカムコーダが登場して きた。従来の映画は毎秒 24フレームで撮影されているため、このようなカムコーダの 登場により、映画制作がより身近になりつつある。
[0007] 一般に、毎秒 24フレームの映像を MPEG— 2規格のフォーマットで記録する場合 には、 3 : 2プルダウン技術が利用される。 NTSC圏のテレビで再生可能なフレーム数 は毎秒 60フレームであるため、これに適合するように 3 : 2プルダウン処理が行われ、 映像が記録される。
[0008] 図 37は、 3 : 2プルダウン技術を利用して毎秒 24フレームの映像を毎秒 60フレーム の映像に変換したときの、各フレームの表示タイミングの関係を示す。各フレームは、 変換前は 1Z24秒間表示され、変換後は 3Z60秒間または 2Z60秒間表示される。 後者の表示は、 1Z60秒間表示されるフレームが 3回または 2回連続して出力される ことを意味する。
[0009] このとき、毎秒 60フレームの各フレームに対して、毎秒 60回更新されるタイムコード が付されて表示される。例えば、開始フレームであれば 0時間 0分 0秒 0フレームと表 示される。また、開始点から 50フレーム後であれば 0時間 0分 0秒 50フレームと表示 される。図 37では、秒およびフレームに対応する数値のみが示されている。
特許文献 1 :特開平 11 155130号公報
発明の開示
発明が解決しょうとする課題
[0010] 3 : 2プルダウン処理された映像を編集する際、毎秒 60回更新されるタイムコードで フレームを指定すると、何度も繰り返して編集しなければならないことがあった。その 理由は、指定されたタイムコードに対応するフレーム力 2回または 3回連続して表示 される同じフレームのうち何回目に表示されているフレームであるかの判断が困難だ 力 である。
[0011] たとえばユーザが映像区間の開始点を示す IN点をタイムコードで指定するときに おいて、指定した IN点力 3回連続して表示されるフレームのうちの 2番目のフレーム であったときを考える。このとき、編集中のユーザは、コマ送りすれば次の異なるフレ ームが表示されると考える力 実際にはその次の 1フレーム期間（1Z60秒間）は同じ フレームが表示されるため、ユーザは違和感を覚える。さらに、ユーザが編集によつ てその 2番目のフレーム以降の映像区間を削除したときにも、 1番目に表示されるフ レームは削除されていないために表示されてしまう。そのためユーザは、 1番目のフレ ームを削除する編集を行わなければならず、非常に不便で、かつ煩わしかった。
[0012] 本発明の目的は、フレームレート (垂直走査周波数)が変換された映像を編集する ときにおいて、ユーザが変換前のフレームを簡易に指定できるようにすることである。
[0013] ユーザがフレームの変換前のフレームレートを基準としたタイムコードを使って容易 に編集点を指定できることにより、タイムコードを使った EDL (Edit Decision List)等の 作成が容易になる。その結果、オンライン編集やノンリニア編集のいずれに対しても 編集効率が著しく向上する。また、タイムコードと SMIL言語の組み合わせによる編 集情報作成を行う場合も同様に作成が容易になる。
[0014] また、変換前のフレームレートを基準として編集を行うことにより、編集点周辺にお けるフレームまたはフィールドの繰り返しを一切意識する必要がなくなり編集が容易 になる。
課題を解決するための手段
[0015] 本発明によるデータ処理装置は、複数のピクチャが第 1周波数で表示される第 1映 像の信号を受け取る受信部と、前記信号に基づいて、前記複数のピクチャが前記第 1周波数と異なる第 2周波数で表示される第 2映像のデータストリームを生成するェン コーダと、前記データストリームを記録媒体に記録する記録部とを備えている。前記 エンコーダは、前記複数のピクチャの各々に対応するピクチャデータと、第 1周波数 で表示されるときの表示時刻を示す第 1時刻情報と、第 2周波数で表示されるときの 表示時刻を示す第 2時刻情報とを生成し、前記第 1時刻情報、前記第 2時刻情報お よび前記第 1時刻情報に基づいて表示される各ピクチャのピクチャデータを対応付け て格納し、前記データストリームを生成する。
[0016] 前記データ処理装置は、前記映像を再生するための管理情報を生成する制御部 であって、前記管理情報として、前記第 1周波数に対応する情報および前記第 2周 波数に対応する情報を格納したメタデータを生成する制御部をさらに備えていてもよ い。
[0017] 前記データ処理装置は、前記映像を再生するための管理情報を生成する制御部 であって、前記管理情報に、さらに前記第 1時刻情報を格納したメタデータを生成す る制御部をさらに備えて 、てもよ 、。
[0018] 前記エンコーダは、 1以上のピクチャに関する前記ピクチャデータ、前記第 1時刻情 報および前記第 2時刻情報を含む再生単位を生成し、前記再生単位における前記 ピクチャについて、前記第 1時刻情報および第 2時刻情報を生成してもよい。
[0019] 前記エンコーダは、単独で復号ィ匕が可能な基準ピクチヤのデータ、前記基準ピクチ ャカもの復号ィ匕を要する 1以上の参照ピクチヤのデータ、前記第 1時刻情報および前 記第 2時刻情報を含む再生単位を生成し、前記再生単位における少なくとも最初の 前記基準ピクチヤに対して、前記第 1時刻情報および第 2時刻情報を生成してもよい
[0020] 前記受信部は、毎秒 24枚のピクチヤが切り替えられて表示される第 1映像の信号を 受け取り、前記エンコーダは、毎秒 60枚のピクチヤが切り替えられて表示される第 2 映像のデータストリームを生成してもよ 、。
発明の効果
[0021] 本発明によれば、映像のフレームレート (垂直走査周波数)を変換するときに、各フ レームデータに対して、変換後の周波数に基づく時刻情報のみならず、変換前の周 波数に基づく時刻情報を付加して記録する。たとえば毎秒 24フレームの映像を 3： 2 プルダウンして毎秒 60フレームの映像を生成したときに、毎秒 60回更新されるタイム コードのみならず毎秒 24回更新されるタイムコードを付加する。編集者が、後者のタ ィムコードを利用して INZOUT点を指定すれば、フレームの内容を基準として映像 の編集 (たとえばフレームの削除、プレイリストの作成）ができる。よって編集作業時間 を短縮できる。
図面の簡単な説明
[0022] [図 1]リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す図で ある。 [図 2]カムコーダ 100の機能ブロックの示す図である。
[図 3]トランスポートストリーム (TS) 20のデータ構造を示す図である。
[図 4] (a)はビデオ TSパケット 30のデータ構造を示す図であり、 (b)は、オーディオ T
Sパケット 31のデータ構造を示す図である。
圆 5] (a)〜 (d)は、ビデオ TSパケットからビデオピクチャを再生する際に構築される ストリームの関係を示す図である。
[図 6]クリップ AVストリーム 60のデータ構造を示す図である。
[図 7]TS処理部 204の機能ブロックの構成を示す図である。
[図 8] (a)は本実施形態における 1コンテンツの概念を示す図であり、 (b)はコンテンツ の管理情報とストリームのデータとを含むクリップの概念を示す図であり、（c)は 3つの リムーバブル HDD112を示す図である。
[図 9]リムーバブル HDD112内の階層化されたディレクトリ構造を示す図である。
[図 10]クリップメタデータ 94に含まれる情報の内容を示す図である。
[図 11]キービクチャおよびキービクチャユニットの関係を示す図である。
[図 12] (a)は、クリップタイムライン（ClipTimeLine) 95のデータ構造を示す図であり
、 (b)は 1タイムエントリに関する TimeEntryフィールド 95gのデータ構造を示す図で あり、（c)は 1KPUエントリに関する KPUEntryフィールド 95hのデータ構造を示す 図である。
[図 13] (a)は、タイムエントリと、クリップタイムライン 95に含まれるフィールドとの関係 を示す図であり、（b)は KPUエントリと、クリップタイムライン 95に含まれるフィールドと の関係を示す図である。
[図 14]2つのリムーバブル HDDに分けて格納された、 1ショットのコンテンツに関する 管理情報とクリップ AVストリームとを示す図である。
[図 15]カムコーダ 100によるコンテンツの録画処理の手順を示す図である。
[図 16]メディア切り替え処理の手順を示す図である。
[図 17]カムコーダ 100によるコンテンツの再生処理の手順を示す図である。
[図 18] (a)および (b)は、編集によって TTSファイルの先頭部分を削除する前後の管 理情報およびクリップ AVストリームの関係を示す図である。 [図 19]カムコーダ 100によるコンテンツの部分削除処理の手順を示す図である。
[図 20]実施形態 2にお 、て 3： 2プルダウンする場合のデータ構造を示す図である。
[図 21] (a)〜（c)は、ストリーム中の PTSおよびタイムコードの格納位置を示す図であ る。
[図 22]実施形態 2によるカムコーダ 100の部分的に詳細な機能ブロックの構成を示す 図である。
[図 23]実施形態 2においてクリップメタデータファイルが含むデータ構造を示す図で ある。
[図 24]実施形態 2における、タイムコード値に基づいてそのタイムコード値に対応する ピクチャを特定する処理の手順を示す図である。
[図 25]実施形態 2における 1ショットが 1個の TTSファイルで構成される場合の管理パ ラメータを示す図である。
[図 26]実施形態 2における ClipTimeLineAddressOffsetが 0でなぐ 1ショットが 1 個の TTSファイルで構成されるときの管理パラメータの意味を示す図である。
[図 27]実施形態 2における 1ショットが複数の TTSファイルのチェーンで構成される場 合の管理パラメータの意味を示す図である。
[図 28]実施形態 3における毎秒 24フレームの映像を 3： 2プルダウン記録する場合の データ構造を示す図である。
[図 29]実施形態 3におけるクリップメタデータファイルのデータ構造を示す図である。
[図 30]実施形態 3における ClipTimeLineファイルのデータ構造を示す図である。
[図 31]実施形態 3における、タイムコード値に基づいてそのタイムコード値に対応する ピクチャを特定する処理の手順を示す図である。
[図 32]実施形態 3における 1ショットが 1個の TTSファイルで構成される場合の管理パ ラメータの意味を示す図である。
[図 33]実施形態 3における ClipTimeLineAddressOffsetが零でなぐかつ 1ショット が 3個の TTSファイルで構成される場合の管理パラメータの意味を示す図である。
[図 34]SMPTE M12規格に準拠したタイムコードの概略のデータ構造を示す図で ある。 [図 35]MPEG—4 AVC規格に準拠したビデオストリームのデータ構造を示す図で ある。
[図 36]実施形態 3にお 、て 3： 2プルダウンする場合のデータ構造を示す図である。
[図 37]3： 2プノレダウン技術を利用して毎秒 24フレームの映像を毎秒 60フレームの映 像に変換したときの、各フレームの表示タイミングの関係を示す図である。
符号の説明
100 カムコーダ
108 PC
112 リムーバブル HDD
201a CCD
201b マイク
202 ADコンバータ
203 MPEG— 2エンコーダ
204 TS処理部
205 メディア制御部
206 MPEG— 2デコーダ
207 グラフィック制御部
208 メモリ
209a LCD
209b スピーカ
210 プログラム ROM
211 CPU
212 RAM
213 CPUバス
214 ネットワーク制御部
215 指示受信部
216 インターフェース (IZF)部
250 システム制御部 261 TTSヘッダ付加部
262 クロックカウンタ
263 PLL回路
264 バッファ
265 TTSヘッダ除去部
発明を実施するための最良の形態
[0024] 以下、添付の図面を参照して、本発明によるデータ処理装置の実施形態を説明す る。
[0025] (実施形態 1)
図 1は、リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す 。図 1では、データ処理装置は、カムコーダ 100—1、カメラ付き携帯電話 100— 2、 P C108として記載されている。カムコーダ 100— 1およびカメラ付き携帯電話 100— 2 は、ユーザが撮影した映像および音声を受け取ってデジタルデータストリームとして 符号化し、そのデータストリームを、それぞれリムーバブルメディア 112— 1および 11 2— 2に書き込む。各リムーバブルメディアに書き込まれたデータは、リムーバブルメ ディア上に構築されたファイルシステム上の「ファイル」として取り扱われる。例えば図 1では、リムーバブルメディア 112— 2に複数のファイルが格納されていることが示さ れている。
[0026] 各リムーバブルメディア 112—1および 112— 2はデータ処理装置から取り外し可能 であり、例えば DVD、 BD (Blu-ray Disc)等の光ディスク、マイクロドライブ等の超 小型ハードディスク、半導体メモリ等である。 PC108は、各リムーバブルメディア 112 —1および 112— 2を装填することが可能なスロットを備えている。 PC108は、装填さ れたリムーバブルメディア 112—1、 112— 2からデータを読み出し、再生処理および 編集処理等を実行する。
[0027] リムーバブル HDD112では、 FAT32ファイルシステムによりデータ管理が行われ る。 FAT32ファイルシステムでは、 1ファイルのファイルサイズの最大値は、例えば 4 ギガバイトである。よって、 FAT32ファイルシステムではデータのサイズ力 ギガバイト を超えるときは 2以上のファイルに分けて書き込まれる。例えば、容量が 8ギガバイト のリムーバブル HDD112には 4ギガバイトのファイルが 2つ格納され得る。 16ギガバ イトのリムーバブル HDD112には 4ギガバイトのファイル力 つ格納され得る。なお、 分割して書き込まれる単位はファイルサイズの最大値でなくてもよぐファイルサイズ の最大値以下のサイズであればょ 、。
[0028] 以下の説明では、コンテンツのデータストリームをリムーバブルメディアに書き込む データ処理装置は、カムコーダであるとして説明する。また、リムーバブルメディアに 格納されたデータストリームを再生し編集するデータ処理装置は PCであるとして説明 する。
[0029] さらに、リムーバブルメディア 112—1は超小型のリムーバブルハードディスクである とする。リムーバブルメディアは、周知のマイクロドライブ等のようにハードディスクを駆 動してデータの書き込みおよび読み出しを行うための機構 (ドライブ機構)を含む。以 下では、リムーバブルメディア 112— 1を「リムーバブル HDD112Jと記述する。説明 を簡便化するため、リムーバブル HDD112は 4ギガバイトの容量を持つとする。この 結果、 4ギガバイトを超えるコンテンツは、 2以上のリムーバブル HDDに分けて書き込 まれる。し力しながら、リムーバブル HDD力 ギガバイト以上の容量を持ち、そこに 4 ギガバイトを超えるコンテンツが書き込まれる場合にも、 2以上のファイルに分割して 同じリムーバブル HDDに書き込めばよい。 1つのコンテンツが複数のファイルに分け て記録される本質的な点においては、いずれも同じである。単に記録するメディアが 同一であるか否かの違いにすぎない。リムーバブル HDD112のクラスタサイズは、例 えば 32キロバイトである。「クラスタ」とは、データの書き込みおよび読み出しを行う際 の最小のアクセス単位である。
[0030] 図 2は、カムコーダ 100の機能ブロックの構成を示す。カムコーダ 100には、複数の リムーノ ブル HDD112a、 112b, · · ·、 112cを同時に装填することが可能であり、ュ 一ザが撮影した映像および音声に関するコンテンツのデータストリーム (クリップ AVス 卜リーム）を、リムーノ ブノレ HDD 112a、 112b, · · ·、 112c【こ jl匿【こ書き込む。
[0031] カムコーダ 100は、 CCD201a、マイク 20 lbおよびデジタル放送を受信するデジタ ルチューナ 201cと、 ADコンバータ 202と、 MPEG— 2エンコーダ 203と、 TS処理部 204と、メディア制御部 205と、 MPEG— 2デコーダ 206と、グラフィック制御部 207と 、メモリ 208と、液晶表示装置（LCD) 209aおよびスピーカ 209bと、 CPUバス 213と 、ネットワーク制御部 214と、指示受信部 215と、インターフェース (IZF)部 216と、 システム制御部 250とを含む。
[0032] 以下、各構成要素の機能を説明する。 CCD201aおよびマイク 201bは、それぞれ 映像および音声のアナログ信号を受け取る。 CCD201aは、映像をデジタル信号とし て出力する。マイク 201bは、音声のアナログ信号を出力する。 ADコンバータ 202は 入力されたアナログ音声信号をデジタル信号に変換して MPEG— 2エンコーダ 203 に供給する。
[0033] デジタルチューナ 201cは、アンテナ（図示せず)から 1以上の番組が含まれるデジ タル信号を受け取る受信部として機能する。デジタル信号として伝送されるトランスポ 一トストリームには複数の番組のパケットが混在して 、る。デジタルチューナ 201 cは、 受信したトランスポートストリーム力 特定の番組 (録画対象のチャンネルの番組)の パケットを抜き出して出力する。出力されるストリームもまたトランスポートストリームで あるが、当初のストリームと区別するために「パーシャルトランスポートストリーム」と呼 ぶこともある。トランスポートストリームのデータ構造は、図 3〜図 5を参照しながら後述 する。
[0034] 本実施形態においては、カムコーダ 100はデジタルチューナ 201cを構成要素とし ているが、これは必須の要件ではない。図 2のカムコーダ 100の構成は、図 1におい て言及したカメラ付き携帯電話 100— 2等にも適用できるため、デジタル放送の受信 および視聴が可能なカメラ付き携帯電話等についての構成要素と考えればよい。
[0035] MPEG— 2エンコーダ 203 (以下「エンコーダ 203」と記述する）は、録画の開始指 示を受け取ると、供給された映像および音声の各デジタルデータを MPEG規格に基 づいて圧縮符号化する。本実施形態においては、エンコーダ 203は、映像データを MPEG— 2形式に圧縮符号ィ匕してトランスポートストリーム（以下「TS」とも記述する） を生成し、 TS処理部 204に送る。この処理は、エンコーダ 203が録画の終了指示を 受け取るまで継続される。エンコーダ 203は双方向圧縮符号ィ匕を行うために、参照ピ クチャ等を一時的に保持するバッファ（図示せず)等を有している。なお、映像および 音声の符号ィ匕形式を一致させる必要はない。例えば、映像は MPEG形式で圧縮符 号化し、音声は AC— 3形式で圧縮符号ィ匕するとしてもよ ヽ。
[0036] 本実施形態では、カムコーダ 100は TSを生成し処理する。そこでまず、図 3〜図 5 を参照しながら、 TSのデータ構造を説明する。
[0037] 図 3は、トランスポートストリーム (TS) 20のデータ構造を示す。 TSパケットは、例え ば、圧縮符号化されたビデオデータが格納されたビデオ TSパケット (V— TSP) 30、 符号ィ匕されたオーディオデータが格納されたオーディオ TSパケット (A_TSP) 31の 他、番組表（プログラム ·アソシエーション'テーブル； PAT)が格納されたパケット（P AT— TSP)、番組対応表（プログラム ·マップ ·テーブル； PMT)が格納されたバケツ ト（PMT— TSP)およびプログラム ·クロック ·リファレンス (PCR)が格納されたパケット (PCR— TSP)等を含む。各 TSパケットのデータ量は 188バイトである。また、 PAT — TSP、 PMT— TSP等の TSの番組構成を記述する TSパケットを一般に、 PSIZS Iパケットと呼ぶ。
[0038] 以下、本発明の処理に関連するビデオ TSパケットおよびオーディオ TSパケットを 説明する。図 4 (a)はビデオ TSパケット 30のデータ構造を示す。ビデオ TSパケット 3 0は、一般に 4バイトのトランスポートパケットヘッダ 30a、および、 184バイトのトランス ポートパケットペイロード 30bを有する。ペイロード 30bにはビデオデータ 30bが格納 されている。一方、図 4 (b)は、オーディオ TSパケット 31のデータ構造を示す。ォー ディォ TSパケット 31も同様に、一般に 4バイトのトランスポートパケットヘッダ 3 la、お よび、 184バイトのトランスポートパケットペイロード 31bを有する。
[0039] オーディオデータ 3 lbはトランスポートパケットペイロード 3 lbに格納されている。 T Sパケットヘッダにはァダプテーシヨンフィールドと呼ばれるデータを追カ卩してもよぐ TSパケットに格納するデータをァライメントする場合などに利用される。この場合 TS パケットのペイロード（30b、 31b)は 184バイト未満となる。
[0040] 上述の例から理解されるように、一般に TSパケットは 4バイトのトランスポートバケツ トヘッダと、 184バイトのエレメンタリデータと力も構成されている。パケットヘッダには 、そのパケットの種類を特定するパケット識別子（Packet IDentifier;PID)が記述 されている。例えば、ビデオ TSパケットの PIDは" 0x0020"であり、オーディオ TSパ ケットの PIDは" 0x0021"である。エレメンタリデータは、ビデオデータ、オーディオデ ータ等のコンテンツデータや、再生を制御するための制御データ等である。どのよう なデータが格納されて 、るかは、パケットの種類に応じて異なる。
[0041] 以下、ビデオデータを例に挙げて、映像を構成するピクチャとの関係を説明する。
図 5 (a)〜（d)は、ビデオ TSパケットからビデオピクチャを再生する際に構築されるス トリームの関係を示す。図 5 (a)に示すように、 TS40は、ビデオ TSパケット 40a〜40d を含む。なお、 TS40には、他のパケットも含まれ得る力 ここではビデオ TSパケット のみを示している。ビデオ TSパケットは、ヘッダ 40a— 1に格納された PIDによって容 易に特定される。
[0042] ビデオデータ 40a— 2等の各ビデオ TSパケットのビデオデータから、パケット化エレ メンタリストリームが構成される。図 5 (b)は、パケットィ匕エレメンタリストリーム（PES) 41 のデータ構造を示す。 PES41は、複数の PESパケット 41a、 41b等から構成される。 PESパケット 41aは、 PESヘッダ 41a— 1および PESペイロード 41a— 2から構成され ており、これらのデータがビデオ TSパケットのビデオデータとして格納されて!、る。
[0043] PESペイロード 41a— 2は、それぞれが 1つのピクチヤのデータを含んでいる。 PES ペイロード 41a— 2から、エレメンタリストリームが構成される。図 5 (c)は、エレメンタリ ストリーム（ES) 42のデータ構造を示す。 ES42は、ピクチャヘッダ、および、ピクチャ データの組を複数有している。なお、「ピクチャ」とは一般にフレームおよびフィールド の 、ずれも含む概念として用いられる。
[0044] 図 5 (c)に示すピクチャヘッダ 42aには、その後に配置されたピクチャデータ 42bの ピクチャ種別を特定するピクチャコーディングタイプが記述され、ピクチャヘッダ 42c にはピクチャデータ 42dのピクチャ種別を特定するピクチャコーディングタイプが記述 されて!/、る。種別とは、 Iピクチャ（Intra— coded picture)、 Pピクチャ（Predictive — coded picture)ま 7こ ίま Bヒクテャ (Biairectionaliy— predictive— coded pict ure)などを表す。種別が Iピクチャであれば、そのピクチャコーディングタイプは、例え ば" 001b"などと決められている。
[0045] ピクチャデータ 42b、 42d等は、そのデータのみによって、または、そのデータとそ の前および Zまたは後に復号ィ匕されるデータとによって構築可能な 1枚分のフレーム のデータである。例えば図 5 (d)は、ピクチャデータ 42b力も構築されるピクチャ 43a およびピクチャデータ 42dから構築されるピクチャ 43bを示す。
[0046] TSに基づいて映像を再生する際、カムコーダ 100はビデオ TSパケットを取得して 上述の処理にしたがってピクチャデータを取得し、映像を構成するピクチャを取得す る。これにより映像を LCD209a上に再生することができる。
[0047] 上述のエンコーダ 203は、映像コンテンツに関しては図 5 (d)、（c)、 （b)および（a) に示す順序で TSを生成すると 、える。
[0048] 次に、カムコーダ 100の TS処理部 204 (図 2)を説明する。 TS処理部 204は、動画 の記録時にはエンコーダ 203から TSを受け取り、またはデジタル放送番組の録画時 にはデジタルチューナ 201cから TSを受け取って、クリップ AVストリームを生成する。 クリップ AVストリームとは、リムーバブル HDD112a等への格納のために所定の形式 を有するデータストリームである。本明細書では、リムーバブル HDDに格納されたク リップ AVストリームのファイルには拡張子 TTS ("Timed TS"を意味する）を付して いる。クリップ AVストリームは、到着時刻情報を付加した TSとして実現される。また、 TS処理部 204は、コンテンツの再生時には、リムーバブル HDD 112a等から読み出 されたクリップ AVストリームをメディア制御部 205から受け取り、そのクリップ AVストリ ームに基づ 、て TSを生成して MPEG— 2デコーダ 206に出力する。
[0049] 以下では図 6を参照しながら、 TS処理部 204の処理に関連するクリップ AVストリー ムを説明する。図 6は、クリップ AVストリーム 60のデータ構造を示す。クリップ AVスト リーム 60は、複数の TTSパケット 61から構成される。 TTSノ ケット 61は、 4バイトの T TSヘッダ 61aと、 188バイトの TSパケット 61bとから構成される。すなわち TTSバケツ ト 61は、 TTSヘッダ 61aを TSパケット 6 lbに付カ卩して生成される。なお TSパケット 61 bは、図 3、図 4 (a)および (b)等に関連して説明した TSパケットである。
[0050] TTSヘッダ 61aは、 2ビットの予約領域 61a— 1と、 30ビットの到着時刻情報（Arriv al Time Stamp ; ATS) 61a— 2とから構成されている。この到着時刻情報 61a— 2 は、エンコーダ 203から出力された TSパケットが TS処理部 204に到着した時刻を示 している。 TS処理部 204は、この時刻に基づいてデコーダ 206に TSパケットを出力 する。
[0051] 次に、上述のクリップ AVストリーム 60を生成する TS処理部 204の構成を説明する 。図 7は、 TS処理部 204の機能ブロックの構成を示す。 TS処理部 204は、 TTSへッ ダ付カロ咅 261と、クロックカウンタ 262と、 PLL回路 263と、ノ ッファ 264と、 TTSへッ ダ除去部 265とを有する。
[0052] TTSヘッダ付加部 261は、 TSを受け取り、その TSを構成する TSパケットの前に T TSヘッダを付カ卩し、 TTSパケットとして出力する。 TTSヘッダ中の到着時刻情報 61 a— 2に記述される TSパケットの到着時刻は、 TTSヘッダ付加部 261に与えられる基 準時刻からのカウント値 (カウント情報）に基づ!/、て特定される。
[0053] クロックカウンタ 262および PLL回路 263は、 TTSヘッダ付カ卩部 261が TSパケット の到着時刻を特定するために必要な情報を生成する。まず PLL回路 263は、 TSに 含まれる PCRパケット（図 2の PCR— TSP)を抽出して、基準時刻を示す PCR (Prog ram Clock Reference :プログラム時刻基準参照値）を取得する。 PCRの値と同じ 値がカムコーダ 100のシステム基準時刻 STC (System Time Clock)として設定 され、 STCが基準時刻とされる。システム基準時刻 STCのシステムクロックの周波数 は 27MHzである。 PLL回路 263は、 27MHzのクロック信号をクロックカウンタ 262に 出力する。クロックカウンタ 262はクロック信号を受け取り、そのクロック信号をカウント 情報として TTSヘッダ付加部 261に出力する。
[0054] ノッファ 264は、ライトバッファ 264aおよびリードバッファ 264bを有する。ライトバッ ファ 264aは、送られてきた TTSパケットを逐次保持し、合計のデータ量が所定値 (例 えばバッファの全容量）になったときに、後述のメディア制御部 205に出力する。この とき出力される一連の TTSパケット列（データストリーム）を、クリップ AVストリームと呼 ぶ。一方、リードバッファ 264bは、メディア制御部 205によってリムーバブル HDD11 2a等力も読み出されたクリップ AVストリームを一時的にバッファして、 TTSパケット単 位で出力する。
[0055] TTSヘッダ除去部 265は、 TTSパケットを受け取って、 TTSヘッダを除去すること により TTSパケットを TSパケットに変換し、 TSとして出力する。留意すべきは、 TTS ヘッダ除去部 265は、 TTSヘッダに含まれて 、る TSパケットの到着時刻情報 ATSを 抽出して、到着時刻情報 ATSとクロックカウンタ 262から与えられるタイミング情報と に基づいて、元の到着時刻に対応するタイミング（時間間隔)で TSパケットを出力す ることである。リムーバブル HDD112a等はランダムアクセスが可能であり、データは 不連続にディスク上に配列される。よって、 TSパケットの到着時刻情報 ATSを利用 すれば、 TS処理部 204は、データの格納位置にかかわらず記録時の TSパケットの 到着タイミングと同じタイミングで TSパケットを出力することができる。なお TTSヘッダ 除去部 265は、読み出した TSの基準時刻を指定するために、例えば最初の TTSパ ケットにおいて指定されている到着時刻を初期値としてクロックカウンタ 262に送る。 これにより、クロックカウンタ 262においてその初期値力もカウントを開始させることが でき、よってその後のカウント結果をタイミング情報として受け取ることができる。
[0056] カムコーダ 100では、 TS処理部 204を設けて、 TSに TTSヘッダを付カ卩してクリップ AVストリームを生成するとした。し力し、符号化レートが固定されている CBR (Const ant Bit Rate)で符合ィ匕する場合には、 TSパケットのデコーダ入力時刻が固定間 隔であるため、 TS処理部 204を省略して TSをリムーバブル HDD112に書き込むこ とちでさる。
[0057] 再び図 2を参照しながら、カムコーダ 100の各構成要素を説明する。
[0058] メディア制御部 205は、 TS処理部 204力 クリップ AVストリームを受け取り、いずれ 力のリムーノ ブノレ HDDl 12aゝ 112bゝ · · ·ゝ 112cに出力する力を決定して、そのリム 一バブル HDDに出力する。メディア制御部 205は、書き込み中のリムーバブル HD Dの記録可能容量をモニタし、残された記録可能容量が所定値以下になったときに は出力先を他のリムーバブル HDDに変更し、クリップ AVストリームの出力を継続す る。このとき、 1つのコンテンツを構成するクリップ AVストリームが 2つのリムーバブル HDD112に跨って格納されることになる。
[0059] メディア制御部 205は、本発明の主要な特徴の 1つであるクリップタイムライン (Clip TimeLine)テーブルを生成する。そしてそのテーブルに、クリップ AVストリームの再 生単位であるキービクチャユニットが、 2つのファイルに跨って格納されて!、るか否か を示すフラグを記述する。なお、メディア制御部 205のより詳細な動作、および、メデ ィァ制御部 205によって生成されるクリップタイムラインテーブルの詳細なデータ構造 は後述する。
[0060] なお、クリップ AVストリームをリムーバブル HDD112に書き込む処理は、メディア制 御部 205から書き込み指示およびクリップ AVストリームを受け取ったリムーバブル H DDI 12が行っている。また、クリップ AVストリームを読み出す処理は、メディア制御 部 205から読み出し指示を受けたリムーバブル HDD112が行っている。しかし、説 明の便宜のため、以下ではメディア制御部 205がクリップ AVストリームを書き込み、 読み出すとして説明する。
[0061] MPEG— 2デコーダ 206 (以下「デコーダ 206」と記述する）は、供給された TSを解 祈して、 TSパケットから映像および音声の圧縮符号ィ匕データを取得する。そして、映 像の圧縮符号ィ匕データを伸長して非圧縮データに変換し、グラフィック制御部 207に 供給する。またデコーダ 206は、音声の圧縮符号化データを伸長して音声信号を生 成し、音声信号をスピーカ 209bに出力する。デコーダ 206は、 TSに関して MPEG 規格で規定されて 、るシステムターゲットデコーダ (T— STD)の要件を満たすように 構成されている。
[0062] グラフィック制御部 207には内部演算用のメモリ 208が接続されており、オン'スクリ ーン 'ディスプレイ（On Screen Display ;OSD)機能を実現できる。例えば、ダラ フィック制御部 207は種々のメニュー画像と映像とを合成した映像信号を出力するこ とができる。液晶表示装置 (LCD) 209aは、グラフィック制御部 207から出力された 映像信号を LCD上に表示する。スピーカ 209bは、音声信号を音として出力する。コ ンテンッは、 LCD209aおよびスピーカ 209bを介して再生され、視聴の対象となる。 なお、映像信号および音声信号の出力先は、それぞれ LCD209aおよびスピーカ 2 09bに限られない。例えば映像信号および音声信号は、外部出力端子（図示せず） を経てカムコーダ 100と別体のテレビやスピーカに伝送されてもよい。
[0063] CPUバス 213はカムコーダ 100内の信号を伝送する経路であり、図示されるように 各機能ブロックと接続されている。また、 CPUバス 213には、後述するシステム制御 部 250の各構成要素も接続されて 、る。
[0064] ネットワーク制御部 214は、カムコーダ 100をインターネット等のネットワーク 101に 接続するためのインターフェースであり、例えば、イーサネット（登録商標）規格に準 拠した端子およびコントローラである。ネットワーク制御部 214は、ネットワーク 101を 介してデータを授受する。例えば、ネットワーク制御部 214は、撮影され生成されたク リップ AVストリームを、ネットワーク 101を介して放送局に伝送してもよい。または、ネ ットワーク制御部 214は、カムコーダ 100の動作を制御するためのソフトウェアプログ ラムが更新されたときは、更新されたプログラムを、ネットワーク 101を介して受け取つ てもよい。
[0065] 指示受信部 215は、カムコーダ 100の本体部に設けられた操作ボタンである。指示 受信部 215は、ユーザから、例えば録画の開始 Z停止、再生の開始 Z停止等の指 示を受け取る。
[0066] インターフェース (IZF)部 216は、カムコーダ 100が他の機器と通信するためのコ ネクタおよびその通信を制御する。 IZF部 216は、例えば USB2. 0規格の端子、 IE EE1394規格の端子および各規格によるデータ通信を可能とするコントローラを含 み、各規格に準拠した方式でデータを授受することができる。例えば、カムコーダ 10 0は、 USB2. 0規格または IEEE1394規格の端子を介して PC108や、他のカムコ ーダ（図示せず）、 BDZDVDレコーダ、 PC等と接続される。
[0067] システム制御部 250は、カムコーダ 100内の信号の流れを含む全体的な処理を制 御する。システム制御部 250は、プログラム ROM210と、 CPU211と、 RAM212とを 有している。それぞれは CPUバス 213に接続されている。プログラム ROM210には カムコーダ 100を制御するためのソフトウェアプログラムが格納されている。
[0068] CPU211は、カムコーダ 100の全体の動作を制御する中央制御ユニットである。 C PU211は、プログラムを読み出して実行することにより、プログラムに基づいて規定さ れる処理を実現するための制御信号を生成し、 CPUバス 213を介して各構成要素 に出力する。メモリ 212は、 CPU211がプログラムを実行するために必要なデータを 格納するためのワーク領域を有する。例えば、 CPU211は、 CPUバス 213を使用し てプログラム ROM210からプログラムをランダムアクセスメモリ（RAM) 212に読み出 し、そのプログラムを実行する。なお、コンピュータプログラムは、 CD— ROM等の記 録媒体に記録して巿場に流通され、または、インターネット等の電気通信回線を通じ て伝送される。これにより、 PC、カメラ、マイク等を利用して構成されたコンピュータシ ステムを、本実施形態によるカムコーダ 100と同等の機能を有する機器として動作さ せることができる。本明細書では、そのような機器もまたデータ処理装置と呼ぶ。 [0069] 次に、図 8 (a)〜（c)を参照しながら、カムコーダ 100において撮影された、映像お よび音声に関するコンテンツのデータ管理構造を説明する。図 8 (a)は、本実施形態 における 1コンテンツの概念を示す。撮影の開始力も終了までの期間に得られたコン テンッを、 1ショットという。図 8 (b)は、コンテンツの管理情報とストリームのデータとを 含むクリップの概念を示す。 1ショット、すなわち 1つのコンテンツは、複数のクリップ a 〜。に分けて各リムーバブル1100112&〜112(：に格納することができる（1っのクリッ プで完結してもよい）。 1つのクリップは、クリップメタデータ 81と、タイムマップ 82と、ク リップ AVストリーム 83の一部（部分ストリーム）とを含む。クリップ AVストリーム 83は、 部分ストリーム 83a〜83cから構成されており、クリップ a〜cのそれぞれに含まれる。 図 8 (b)には 3つのクリップ a〜cが記載されている力 各クリップの構成は共通してい るため、ここではクリップ aを例に挙げて説明する。
[0070] クリップ aは、クリップメタデータ aと、タイムマップ aと、部分ストリーム aとを含む。このう ち、クリップメタデータ aおよびタイムマップ aは管理情報であり、部分ストリーム aがタリ ップ AVストリーム 83を構成するデータである。クリップ AVストリーム 83は原則として 1 つのファイルに格納される力 FAT32のファイルサイズの最大値を超えるときには複 数の TTSファイルに格納される。図 8 (b)では、 3つの部分ストリーム 83a、 83bおよび 83cが別個のファイルに格納される。なお本実施形態では、各部分ストリームのフアイ ルサイズを FAT32ファイルシステムにおけるファイルサイズの最大値（4ギガバイト）と すると、リムーバブル HDD112a〜cの記録可能容量がなくなって管理情報をリムー バブル HDD112に書き込みできなくなるため、各部分ストリームのファイルサイズは 4 ギガバイトよりも小さくなることに留意されたい。さら〖こ、 TTSファイルは整数個の TTS パケットから構成されるとし、上記ファイルシステム力もの制限である 4ギガバイト未満 であり、かつ、 TTSパケット（192バイト）の整数倍としてもよい。
[0071] クリップメタデータ aは XML形式で記述されており、コンテンツの再生に必要な情報 、例えば映像 Z音声フォーマット等が規定される。クリップメタデータ aの詳細は、後に 図 10を参照しながら詳述する。
[0072] タイムマップ aは、再生単位ごとの、表示時刻とその格納位置（アドレス）との関係を 規定したテーブルである。本明細書では、このタイムマップを「クリップタイムライン」 ( ClipTimeLine)と呼び、クリップタイムラインが格納されたファイルの拡張子に" CTL "を付して図示している。クリップタイムラインの詳細は、後に図 12〜14を参照しなが ら詳述する。
[0073] 部分ストリーム aは、図 6に示すように複数の TTSパケットから構成される。
[0074] なお、 1ショットの間にクリップ AVストリーム 83が複数の部分ストリーム 83a〜83cの ファイルに格納されたときには、 TSパケットの転送タイミングを決定する ATSのクロッ クカウンタ 262 (図 7)がリセットされたり、それまでのカウント値とは無関係な値が設定 されたりすることはない。クロックカウンタ 262 (図 7)は、設定されていた基準時刻に基 づくカウントを継続的に行ってカウント値を出力する。したがって、クリップ AVストリー ム 83を構成する各 TTSパケット中の到着時刻情報 ATSは、 1つのショットを構成する 連続する 2つの TTSファイルの境界にお!、て連続して 、る。
[0075] 図 8 (c)は、 3っのリムーバブル1100112&〜112。を示す。各クリップ a〜cを構成 するデータのファイルが各リムーバブル HDD 112a〜 112cに書き込まれる。
[0076] 次に、リムーバブル HDD112内にファイルがどのように格納されるかを説明する。
図 9は、リムーバブル HDD112内の階層化されたディレクトリ構造を示す。コンテンツ の管理情報とクリップ AVストリームのファイルは、最上層のルート（ROOT) 90内のコ ンテンッ（Contents)フォルダ 91以下に格納される。より具体的には、コンテンツフォ ルダ 91直下のデータベース（Database)フォルダ 92〖こは、管理情報であるクリップメ タデータ 94の XML形式ファイル、および、クリップタイムライン 95の CTL形式フアイ ルが格納される。一方、コンテンツフォルダ 91直下の TTSフォルダ 93には、クリップ AVストリーム（TimedTs) 96の TTS形式ファイルが格納される。
[0077] なお、コンテンツフォルダ 91には、さらに MXF形式の映像のストリームデータを格 納するビデオフォルダ (Video)、 MXF形式の音声のストリームデータを格納するォ 一ディオフオルダ（Audio)、 BMP形式のサムネイル画像を格納するアイコンフオル ダ（Icon)、 WAVE形式のボイスメモのデータを格納するボイスフォルダ（Voice)等 が設けられてもよぐ既存のカムコーダの記録フォーマット等に対応させることができ る。
[0078] 続いて、図 10〜 14を参照しながら、クリップメタデータ 94およびクリップタイムライン 95に記述されたデータの内容を説明する。
[0079] 図 10は、クリップメタデータ 94に含まれる情報の内容を示す。クリップメタデータ 94 は、構成データ（"Structural")および記述データ（"Descriptive")の 2種類に分類 される。
[0080] 構成データには、クリップ名、エッセンスリスト、リレーション情報等が記述される。ク リップ名は、そのファイルを特定するための情報であり、例えば周知の UMID (Uniq ue Material IDentifier)が記述される。 UMIDは、例えば、コンテンツが生成さ れた時刻とそれを生成した機器の MAC (Media AccessControl)アドレスを組み 合わせて生成される。さらに UMIDは、コンテンツが新たに生成されたか否かをも考 慮して生成される。すなわち、ー且 UMIDが付加され、その後に編集'加工等された コンテンツには、元のコンテンツの UMIDとは異なる値が付加される。よって UMID を利用すると世界中に存在するコンテンツに対して異なる値が定義されるため、コン テンッを一意に特定できる。
[0081] エッセンスリストには、映像および音声の復号化に必要な情報 (ビデオ情報および オーディオ情報）が記述されている。例えばビデオ情報には、ビデオデータのフォー マット、圧縮符号化方式、フレームレートなどが記述される。オーディオ情報には、ォ 一ディォデータのフォーマット、サンプリングレート等が記述される。本実施形態では 、圧縮符号ィ匕方式は MPEG— 2方式である。
[0082] リレーション情報は、図 8 (b)に示すような複数のクリップ 81a〜81cが存在するとき のクリップの間の関係を規定する。具体的には各クリップメタデータ 94には、そのショ ットの先頭のクリップを特定する情報、そのクリップの直前および直後のクリップを特 定する情報がそれぞれ記述される。すなわちリレーション情報は、複数クリップの各々 に対応するクリップ AVストリーム (部分ストリーム）の再生の先後関係または再生順序 を規定しているということができる。クリップを特定する情報は、例えば、 UMIDおよび そのリムーバブル HDD112固有のシリアル番号によって規定される。
[0083] 記述データには、アクセス情報、デバイス、撮影情報等が含まれて 、る。アクセス情 報には、そのクリップの最終更新者、 日時等が記述されている。デバイス情報には、 製造者名、記録した装置のシリアル番号、モデル番号等が記述されている。撮影情 報は、撮影者名、撮影開始日時、終了日時、位置などを含む。
[0084] 次に、クリップタイムライン 95を説明する。クリップタイムライン 95では、キービクチャ およびキービクチャユニットという概念を導入して、それらに関する情報を規定してい る。そこでまず図 11を参照しながら、キービクチャおよびキービクチャユニットを説明 する。
[0085] 図 11は、キービクチャおよびキービクチャユニットの関係を示す。図 11では、 I、 B および Pの各ピクチャを表示される順序で記載している。キービクチャユニット (Key Picture Unit ;KPU)は、映像に関して規定されるデータ再生単位である。図 11で は、キービクチャユニット KPUの表示は、キービクチャ 44から開始され、 Bピクチャ 45 にお 、て終了する。この間には MPEG規格のグループ ·ォブ ·ピクチャ（GOP)力 S 1以 上含まれている。 Bピクチャ 45の次の Iピクチャ 46から、次のキービクチャユニット KP Uの表示が始まる。各キービクチャユニットの映像再生時間は、 0. 4秒以上、かつ、 1 秒以下である。ただし、 1ショットの最後のキービクチャユニットは 1秒以下であればよ い。撮影の終了タイミングによっては 0. 4秒に満たないこともある力もである。上記は GOP先頭の Iピクチャ力も再生が開始されるとしている力 Bピクチャ力も再生が開始 される GOP構造の場合には、この限りではない。 KPU期間（KPUPeriod)は、その KPUに格納される全ピクチャの再生時間を示しているためである。
[0086] キービクチャユニットの先頭に位置するキービクチャ 44、 46は、 MPEG規格におけ るシーケンスヘッダコード (sequence _ header _ code)およびグノレープスタートコ一 ド（group— start— code)を含むビデオに関するアクセス単位である。例えば、キー ピクチャユニットは MPEG2圧縮符号ィ匕された Iピクチャの画像 (フレーム画像または 1 組の 2フィールド画像)または、圧縮符号ィ匕された Iフィールドおよび Pフィールドの画 像である。
[0087] また、本実施形態では、 TSに付加された PTSを用いて KPU期間（KPUperiod)を 定義している。 KPU期間は、次のキービクチャユニット KPUの中で最初に表示され るピクチャの表示時刻 (PTS)と、その KPUの中で最初に表示されるピクチャの表示 時刻（PTS)との差分値である。図 11では、キービクチャ 44の時刻を PTS (N)とし、 キービクチャ 46の時刻を PTS (N+ 1)としたとき、 KPU期間（N)は、 PTS (N+ 1) PTS (N)として定義される（ともにキービクチャが表示開始ピクチヤとなっている場合） 。なお、 KPU期間の定義から明らかなように、ある KPU期間の値を決定するために は、次のキービクチャユニット KPUのピクチャが圧縮符号ィ匕され、最初に表示される ピクチャの再生時刻（PTS)が確定しなければならない。よって、あるキービクチャュ ニット KPUに対する KPU期間は、次のキービクチャユニットの生成が開始された後 に定まる。なお、ショットで最後の KPU期間が必要な場合もあるため、符合ィ匕したピク チヤの表示時間を積算していく方法も可能である。その場合には、次の KPUの生成 開始を待たずとも KPU期間を決定することが可能である。
[0088] 次に、図 12 (a)〜（c)を参照しながら、クリップタイムライン（ClipTimeLine)を説明 する。図 12 (a)は、クリップタイムライン（ClipTimeLine) 95のデータ構造を示す。ク リップタイムライン 95は、拡張子に" CTL"を有するファイルとして各リムーバブル HD D112に書き込まれる。
[0089] クリップタイムライン 95は、再生単位ごとの、表示時刻とその格納位置 (アドレス）と の関係を規定したテーブルである。「再生単位」は、上述のキービクチャユニット KPU に対応する。
[0090] クリップタイムライン 95には、複数のフィールドが規定されている。例えば、クリップタ ィムライン 95には、 TimeEntryNumberフィールド 95a、 KPUEntryNumberフィー ノレド 95b、 ClipTimeLineTimeOffsetフィールド 95c、 ClipTimeLineAddressOff setフィールド 95d、 ClipTimeLineDurationフィールド 95e、 StartKeySTCフィー ルド 75f、 TimeEntryフィールド 95g、 KPUEntryフィールド 95h等を含む。各フィー ルドには所定のバイト数が割り当てられ、それぞれその値に応じた特定の意味を規定 している。
[0091] 例えば、 TimeEntryNumberフィールド 95aにはタイムエントリの数が記述され、 K PUEntryNumberフィールド 95bには KPUエントリの数が記述される。ただし Time Entryフィールド 95gおよび KPUEntryフィールド 95hは、後述のタイムエントリの数 および KPUエントリの数に応じてデータサイズが変動し得る。
[0092] 図 12 (b)は 1タイムエントリに関する TimeEntryフィールド 95gのデータ構造を示 す。 TimeEntryフィールド 95gには、対応するタイムエントリに関する属性を示す情 報が複数のフィールド（KPUEntryReferencelDフィールド 97a、 KPUEntryStart Addressフィールド 97bおよび TimeEntryTimeOffsetフィールド 97c)に記述され ている。
[0093] また、図 12 (c)は 1KPUエントリに関する KPUEntryフィールド 95hのデータ構造 を示す。 KPUEntryフィールド 95hには、対応するキービクチャユニット KPUに関す る属性を示す情報が複数のフィールド（OverlappedKPUFlagフィールド 98a、 Key PictureSizeフィールド 98b、KPUPeriodフィールド 98cおよび KPUSizeフィールド 98d)に記述されている。
[0094] ここで、図 13 (a)および (b)を参照しながら、クリップタイムライン 95に含まれる主要 なフィールドに規定されるデータの意味を説明する。
[0095] 図 13 (a)は、タイムエントリと、クリップタイムライン 95に含まれるフィールドとの関係 を示す。図 13 (a)の横軸の 1目盛りは 1アクセスユニット時間（Access Unit TiMe ； AUTM)を示している。これは 1ピクチャの表示時間に対応する。ここでいう「ピクチ ャ」とはどのようなビデオを対象とするかに応じて異なる。すなわち、「ピクチャ」は、プ ログレツシブビデオに対しては 1枚のプログレッシブ走査のフレーム画像に対応し、ィ ンターレースビデオに対してはインターレース走査のフィールド画像（1フィールド）に 対応する。例えば、 24000Z1001秒間隔で表示されるプログレッシブビデオ（つまり 23. 97p)では、 1AUTMは 1Z (24000Z1001) 秒 = 1126125 clocks/2 7MHzと表記される。
[0096] ここでまず、 1ショットに n個のクリップが含まれるとしたときの時間の関係を説明する 。まず各クリップの再生時間長は、それぞれの ClipTimeLineDurationフィールド 9 5eに記述される。この値は AUTMを利用して記述される。すべてのクリップについて の ClipTimeLineDurationフィールド 95eの値の和を計算すると、 1ショットの再生 時間長 (撮影時間長）が得られる（数 1)。この時間長もまた、 AUTMを利用して記述 される。
[0097] (数 1)
1ショットの再生時間長 =∑ ClipTimeLineDuration
[0098] 一方、図 13 (&)に示す1¾31；# 0から# (k+ 1)までが 1クリップに含まれるとすると、 上述の各クリップの ClipTimeLineDurationフィールド 95eは、そのクリップに含まれ る全てのキービクチャユニット KPUの KPU期間（KPUperiod)フィールド 98cの値の 総和として得られる（数 2)。上述のように、 KPU期間（KPUperiod)は AUTM値を 用いて表記されるため、 ClipTimeLineDurationフィールド 95eも AUTM表記であ る。
[0099] (数 2)
ClipTimeLineDuration =∑ KPUperiod
[0100] 各 KPU期間（KPUperiod)フィールド 98cの値は、上述のとおり、そのキービクチャ ユニット KPUに含まれるピクチャのビデオ表示時間（AUTM値）の和に対応する（数
3)。
[0101] (数 3)
KPUperiod=KPU内のビデオ総表示時間
[0102] 「タイムエントリ」 (TimeEntry)とは、一定の固定時間（例えば 5秒)ごとに設定され 、その位置力 再生を開始することが可能な時間軸上の飛び込み点を示す。タイム エントリの設定に関連して、先頭のキービクチャユニット KPU # 0の再生開始時刻を 0としたとき、最初に設定されたタイムエントリ # 0までの時間オフセットが ClipTimeLi neTimeOffsetフィールド 95cに設定される。また、各タイムエントリの設定時刻に再 生されるキービクチャユニット KPUを識別する情報が KPUEntryReferencelDフィ 一ルド 97aに記述され、そのキービクチャユニット KPUの先頭からそのタイムエントリ の設定時刻までの時間オフセットを示す情報が TimeEntryTimeOffsetフィールド 9 7cに記述される。
[0103] 例えば、タイムエントリ # tが指定されると、（ClipTimeLineTimeOffsetフィールド 95cの値） + (タイムエントリの間隔 't)を計算することにより、そのタイムエントリ # tが 設定された時刻、すなわち先頭キービクチャユニット KPU # 0の先頭からの経過時 間を得ることができる。
[0104] また、さらに以下の方法によって任意の再生時刻から再生を開始することもできる。
すなわち、ユーザ力も再生を開始したい時刻の指定を受け取ると、その時刻は、周知 の変換処理を利用して MPEG規格上の時間情報である PTS値に変換される。そし て、その PTS値が割り当てられたピクチャから、再生が開始される。なお PTS値は、 ビデオ TSパケット（V_TSP) 30のトランスポートパケットヘッダ 30a (図 4 (a) )内に記 述されている。
[0105] 本実施形態では、 1つのクリップ AVストリームが複数の部分ストリームに分けられて いるため、各クリップ内の部分ストリーム先頭の再生開始時刻 (PTS)が 0でないことが ある。そこで、クリップタィムラィン95の3 & 31^フィールド95 図12 (&) )には、そ のクリップ内の先頭 KPUの中で最初に表示されるピクチャの再生時刻情報（PTS) が記述されている。そのピクチャの PTS値と指定された時刻に対応する PTS値と〖こ 基づいて、再生開始すべきピクチャまでの PTS (AUTM)差分値が得られる。なお、 各ピクチャに割り振られている PTS値のデータ量と、 StartSTCフィールド 95fに規定 されている PTS値のデータ量とを一致させることが好ましぐ例えば 33ビットで表記さ れる。
[0106] 上述の差分値が ClipTimeLineDurationフィールド 95eの値よりも大きければ、再 生を開始すべきピクチャはそのクリップ内に存在せず、小さければそのクリップ内に 存在すると判断できる。後者のときは、さらにその PTS差分値に基づいて、どの程度 先の時刻かも容易に特定できる。
[0107] 図 13 (b)は、 KPUエントリと、クリップタイムライン 95に含まれるフィールドとの関係 を示す。図 13 (b)の横軸の 1目盛りは 1データユニット長（Timed TS Packet Byt e Length;TPBL)を示している。これは 1データユニットが TTSパケットのデータ量 (192バイト）と等しいことを意味する。
[0108] 各 KPUエントリは、各キービクチャユニット KPUに対して 1つ設けられている。 KPU エントリの設定に関連して、各 KPUのデータサイズが KPUSizeフィールド 98dに記 述され、各タイムエントリごとに対応する KPUの開始アドレスが KPUEntryStartAd dressフィールド 97bに記述される。なお、各キービクチャユニット KPUのデータサイ ズは、例えば図 13 (b)の KPUsize # kに示すように、その KPUの中で最初のピクチ ャのデータを格納した最初の TTSパケットから、次の KPUの最初のピクチャを格納し た TTSパケット直前の TTSパケットまでのデータサイズを 1データユニット長（TPBL) で示して表される。 [0109] さらに KPUエントリには、ファイルの最初から、キービクチャユニット KPU # 0の先 頭までのフラグメント（データオフセット）が ClipTimeLineAddressOffsetフィールド 95dに設定されている。このフィールドを設ける理由は以下のとおりである。例えば 1 ショットのクリップ AVストリームのデータが複数のファイルに分けて格納されたとき、 2 番目以降のファイルの先頭には先のファイル最後尾の KPUの一部が格納されること がある。キービクチャユニット KPU内の各ピクチャは、 KPU先頭のキービクチャから 復号ィ匕をしなければならな 、ため、ファイルの先頭に存在するデータは単独で復号 ィ匕できない。よってそのようなデータは、意味のないデータ（フラグメント）として読み 飛ばすことが必要になる。そこで上述のオフセットフィールド 95dにそのオフセット値 を利用して、読み飛ばしを可能にしている。
[0110] ここで、図 14を参照しながら、 1ショットのクリップ AVストリームデータが複数のフアイ ルに分けて格納されたときの OverlappedKPUFlagフィールド 98a等を説明する。説 明の簡単のために、ここでは 1ショットのコンテンツに関する管理情報とクリップ AVスト リームとが、 2つのリムーバブル HDD # 1および # 2に格納されるとして説明し、また クリップメタデータには言及しない。
[0111] 図 14は、 2つのリムーバブル HDDに分けて格納された、 1ショットのコンテンツに関 する管理情報とクリップ AVストリームとを示す。リムーバブル HDD # 1および # 2に は、それぞれクリップタイムラインのファイル（00001. CTLおよび 00002. CTL)と、 クリップ AVストリームのフアイノレ（00001. TTSおよび 00002. TTS)と力 S格糸内されて いる。
[0112] 以下では、 KPUエントリに注目する。まず、リムーバブル HDD # 1上の KPUェント リ # (d— 1)は、 00001. TTS内のクリップ AVストリームに規定されるキービクチャュ ニット KPU # (d—1)に対応して設けられている。図 14に示すように、キービクチャュ ニット KPU # (d—l)のすベてのデータは、 00001. TTS内に存在している。その場 合には、 KPUエントリ # (d— 1)の OverlappedKPUFlagフィールド 98aには Obが設 定される。
[0113] 次に、 KPUエントリ # dおよび対応するキービクチャユニット KPU # dに着目する。
図 14に示すキービクチャユニット KPU # dは、その一部（キービクチャユニット KPU # dl)がリムーバブル HDD # 1の 00001. TTS内に存在し、他の一部（キービクチ ャユニット KPU # d2)がリムーバブル HDD # 2の 00002. TTS内に存在して!/、る。 キービクチャユニット KPU # dが 2つのリムーバブル HDDに分けて格納されて!、る理 由は、例えばリムーバブル HDD # 1への書き込み中に、記録可能な残り容量が所定 値以下になり、それ以上の書き込みが不可能になったためである。この場合には、 K PUエントリ # dの OverlappedKPUFlagフィールド 98aには lbが設定される。
[0114] なお、リムーバブル HDD # 2内の KPUエントリ # 0に対応するキービクチャユニット KPUは、そのすベてのデータがリムーバブル HDD内に格納されているから、その O verlappedKPUFlagフィールド 98aには Obが設定される。
[0115] 上述のように KPUエントリ内の OverlappedKPUFlagフィールド 98aの値を調べる ことにより、そのキービクチャユニット KPUがそのメディア内のファイルに格納されて いる力否かが判断できる。この利点は、例えば以下の処理において非常に効果的で ある。
[0116] 図 14に示すように、 KPU # dを構成するデータが複数の TTSファイル（00001. T TSおよび 00002. TTS)に跨って格納されているときにおいて、リムーバブル HDD # 2内のデータを全て削除する編集処理を想定する。この編集処理の結果、リムー バブル HDD # 1に格納されたデータのみに基づいて 1ショットの再生が行われる。
[0117] 編集処理によって 1ショットの再生時間が変化するため、正確な再生時間を算出す る必要がある。そこで、 OverlappedKPUFlagフィールド 98aの値に基づいて再生時 間の算出処理を変化させることができる。具体的に説明すると、リムーバブル HDD # 1内の最後の KPU # dに関しては OverlappedKPUFlagフィールド 98aの値は" lb" である。このときは、先頭から KPU # (d—l)までの KPU期間（KPUperiod)の和を 、リムーバブル HDD # 1内のクリップの再生時間（ClipTimeLineDuration95e)の 値として採用すればよい。換言すれば、上述の数 2においてキービクチャユニット KP U # dの KPU期間（KPUperiod)の値はクリップの再生時間として算入しな!、。その 理由は、実際に再生可能な時間（最初の KPU力 KPU # (d—l)まで）と数 2に基 づいて算出した 1ショットの再生時間（最初の KPUから KPU # dまで）との間には、最 後の KPU # d相当の再生時間（0. 4秒以上 1秒未満)だけ誤差が発生し得るからで ある。機器力も提示された再生時間がこのような大きな誤差を含むことは、特に業務 用途の機器にぉ 、ては決してあってはならな 、ことは 、うまでもな!/、。
[0118] 一方、仮に、リムーバブル HDD # 1内の最後の KPUに対応する OverlappedKP UFlagフィールド 98aの値が" Ob"のときは、先頭から最後までの各キービクチャュ- ット KPUの KPU期間（KPUperiod)の和をクリップの再生時間（ClipTimeLineDur ation95e)の値として採用すればよい。最後のキービクチャユニット KPU内の全ての ピクチャが再生可能であるため、その KPUの KPU期間（KPUperiod)をクリップの 再生時間（ClipTimeLineDuration95e)に算入すべきだからである。
[0119] 以上説明したように、 OverlappedKPUFlagフィールド 98aの値に応じてクリップの 再生時間（ClipTimeLineDuration95e)の算出する処理を変化させることにより、 常に正確な再生時間長を算出できる。
[0120] また、 OverlappedKPUFlagフィールド 98aの値を利用して不完全なキービクチャ ユニット KPUを削除する力否かを決定し、削除したときには残されたクリップについて クリップタイムラインを修正してもよい。この「不完全なキービクチャユニット」とは、全て のピクチャのデータが存在しな ヽキービクチャユニットを 、 、、ここでは KPU # d2が 存在しな!ヽ KPU # dに相当する。
[0121] 具体的に説明すると、 OverlappedKPUFlagフィールド 98aの値が" lb"のときに は、不完全なキービクチャユニット KPU # dlをキービクチャユニット KPUとして取り 扱わないように、 TTSファイルから削除し、リムーバブル HDD # 1内のクリップタイム ラインを修正すればよい。クリップタイムラインの修正は、キービクチャユニット KPUの 数（KPUEntryNumber95b)を減少させること、 KPU # dの KPUエントリを削除す ること、キービクチャユニット KPU # dl内のタイムエントリ（TimeEntry) 95gを削除 すること等を含む。修正後は、リムーノ ブル HDD # 1の 00001. TTSファイルの最 後のキービクチャユニットは KPU # (d—l)になり、最初の KPU力 最後の KPU # ( d—l)までの再生時間の和が 1ショットの再生時間になる。よって、上述の数 1〜数 3 を画一的に適用して正確な再生時間を得ることができる。尚、このような後方部分削 除は FAT32ファイルシステム上においても、 TTSパケット（192バイト）単位で可能で ある。 [0122] 他の利点は以下のとおりである。所定の再生時刻から再生を開始するような場合、 図 13に示すような再生時刻と記録アドレスのテーブル情報であるタイムマップ (Clip TimeLine)を使って、飛び込むべきキービクチャユニット KPUを特定することができ る。し力しながら、 MPEG規格等に採用されている順方向符号ィ匕方式および双方向 符号ィ匕方式を利用して映像データを圧縮符号ィ匕する時、復号はイントラコーディング ピクチャ (Iピクチャ）から開始しなければ、後続のピクチャが正しく復号できない。従つ て、再生開始すべきピクチャが含まれるキービクチャユニット KPU (厳密には KPUP eriod)を特定できた場合であっても、そのピクチャ力 再生するためには、そのピク チヤが属するキービクチャユニット KPUの先頭であるキービクチャ力 復号を開始し なければならない。そこで、まず KPUエントリ # dの OverlappedKPUFlagフィール ド 98aの値を確認し、その KPUの先頭であるキービクチャが記録されて!、るファイル を確かめる必要がある。
[0123] 具体的には OverlappedKPUFlagフィールド 98aの値が" lb"のときは、再生開始 のピクチャから正しく復号できるようにリムーバブル HDD # 1のキービクチャユニット K PU # dlの先頭力 データを読み出すように動作を制御することができる。誤ってリム 一バブル HDD # 2の先頭力もデータを読み出し、参照ピクチヤが取得できず、デコ ードができないと判断する処理を行わなくてすむため、読み出し時間、デコードがで きる力否かの判断に要する時間およびそれらの処理に要する処理負荷を低減できる 。または、復号に失敗した映像を表示することを防ぐことができる。一方、値が" Ob"の ときは、その KPUエントリが存在するリムーバブル HDDと同じメディアからデータの 読み出しを開始すればよい。 OverlappedKPUFlagフィールドを設けることは、上記 のように例えばタイムマップを利用した飛び込み再生や、早送り再生や巻き戻し再生 のような高速かつ複雑な処理に特に有効である。
[0124] なお、キービクチャユニット KPU # d2は、リムーバブル HDD # 2内ではフラグメント であり、そのデータのみではビデオは復号化できない。よって、リムーバブル HDD # 2内のクリップ AVストリームファイル（00002. TTS)の最初から、キービクチャュ-ッ ト KPU # 0の先頭までのフラグメント（データオフセット）が ClipTimeLineAddressO ffsetフィールド 95dに設定される。さらに、そのキービクチャユニット KPU # 0の先頭 から、最初に設定されたタイムエントリ # 0までの時間オフセットが ClipTimeLineTi meOff setフィールド 95cに設定される。なお、 ClipTimeLineAddressOffsetフィ 一ルド 95dの値が 0でな!/、ときは、前のリムーバブル HDDからのキービクチャユニット KPUが格納されていることを表すため、上述の巻き戻し再生時にはまず、クリップメタ データ 94のリレーション情報を参照することで、直前のクリップがある力否かを特定す ることができる。直前のクリップが存在しないまたは、アクセスできない場合には、巻き 戻し再生は終了する。ショットの途中のクリップであって、前のクリップがアクセス可能 であった場合には、 ClipTimeLineAddressOffsetフィールド 95dの値が 0か否かを 確認し、 0でないときに前のリムーバブル HDDの最後のキービクチャユニット KPUに 対応する KPUエントリの OverlappedKPUFlagフィールド 98aの値をさらに確認して 、キービクチャユニット KPUの跨ぎが発生して ヽるカゝ否かを確実に判定することもで きる。
[0125] 次に、上述のデータ構造に基づいてコンテンツを録画し、そのデータ構造を利用し てコンテンツを再生するための処理を説明し、その後、そのようなコンテンツを編集す る際の処理を説明する。
[0126] まず図 15および図 16を参照しながら、コンテンツをリムーバブル HDDに録画する ときのカムコーダ 100の処理 (録画処理)を説明する。
[0127] 図 15は、カムコーダ 100によるコンテンツの録画処理の手順を示す。まずステップ S151にお!/ヽて、カムコーダ 100の CPU211iま旨示受信咅 215を介して、ユーザ力 ら撮影開始の指示を受け取る。そして、ステップ S152において、 CPU211からの指 示に基づいて、エンコーダ 203は入力信号に基づいて TSを生成する。なおデジタル 放送の録画時には、ステップ S151において録画開始の指示を受け取り、ステップ S 152にお!/、てデジタルチューナ 201 cを用!、て録画対象の番組の TSパケットを抽出 すると読み替えればよい。
[0128] ステップ S153では、メディア制御部 205は、 TS処理部 204において TTSヘッダが 付加された TS (クリップ AVストリーム）を、順次リムーバブル HDDに書き込む。そして メディア制御部 205は、ステップ S154において、クリップ (TTSファイル）を新規に作 成するか否かを判断する。新規に作成するか否かは、記録中のクリップの TTSフアイ ルのサイズが所定値よりも大きいか否力、あるいはリムーバブル HDDの残容量に応 じて任意に決定できる。新規にクリップを作成しない場合はステップ S 155に進み、新 規にクリップを生成するときはステップ S156に進む。
[0129] ステップ S 155では、 TS処理部 204は、キービクチャユニット KPUが生成されるごと に、 KPUエントリおよびタイムエントリを生成する。このとき、キービクチャユニット KP Uのすベてのデータはそのクリップの TTSファイル内に書き込まれるため、メディア制 御部 205は KPUエントリ中の OverlappedKPUFlagフィールドに" Ob"を設定する。 そしてメディア制御部 205は、ステップ S157において KPUエントリおよびタイムェン トリを含む時間 ·アドレス変換テーブル（クリップタイムライン ClipTimeLine)をリムー バブルメディアに書き込む。その後、ステップ S 158において、 CPU211は撮影終了 力否かを判断する。撮影は、例えば指示受信部 215を介して撮影終了指示を受信し たとき、次にデータを書き込むべきリムーバブル HDDが存在しないとき等に終了する 。撮影終了と判断されると録画処理は終了する。撮影が継続されるときには処理はス テツプ S152に戻り、それ以降の処理が繰り返される。
[0130] 一方ステップ S156では、 TS処理部 204は、最後に書き込まれたデータによってキ ーピクチャユニット KPUが完結した力否かを判断する。仮にキービクチャユニット KP Uが完結しなければ、そのキービクチャユニット KPUの残りのデータは他のリムーバ ブル HDDに格納されることになる。そのため、キービクチャユニット KPUのすベての データがそのリムーバブル HDD内に書き込まれた力否かを判断するために、このよ うな判断が必要になる。キービクチャユニット KPUが完結しているときには処理はス テツプ S 155に進み、完結して!/ヽな 、ときには処理はステップ S 159に進む。
[0131] ステップ S159では、 TS処理部 204によってクリップ切り替え処理が行われる。この 処理の具体的な内容を、図 16に示す。
[0132] 図 16は、クリップ切り替え処理の手順を示す。この処理は、コンテンツ（クリップ）の 録画先のメディアを、あるリムーバブル HDDから他のリムーバブル HDDに切り替え たり、同一リムーバブル HDD上で新規クリップを生成したりする処理である。以下で は説明を簡略ィ匕するために、クリップの切り替え力 コンテンツの録画先メディアの変 更であるとして説明するが、同一記録媒体で新規クリップに記録する場合と本質的に 同等である。また、便宜的にそれまでコンテンツが録画されていたリムーバブル HDD を「第 1リムーバブル HDD」と呼び、次にコンテンツが録画されるリムーバブル HDD を「第 2リムーバブル HDD」と呼ぶ。
[0133] まずステップ S161において、 CPU211は、第 2リムーバブル HDD上に生成される クリップのクリップ名を決定する。次に、ステップ S162において、カムコーダ 100は第 1リムーバブル HDDに完全に記録できなかったキービクチャユニット KPUが完結す るまで TSを生成する。そして、 TS処理部 204は TTSヘッダを付カ卩し、メディア制御 部 205はそのクリップ AVストリームを第 2リムーバブル HDDに書き込む。
[0134] 次にステップ S163において、メディア制御部 205は、完結した KPUの KPUェント リおよびタイムエントリを生成する。このとき、キービクチャユニット KPUは第 1リムーバ ブル HDDおよび第 2リムーバブル HDDに跨って書き込まれるため、メディア制御部 205は KPUエントリ中の OverlappedKPUFlagフィールドに" lb"を設定する。
[0135] ステップ S164において、メディア制御部 205は、生成した KPUエントリおよびタイ ムエントリを含む時間 ·アドレス変換テーブル（クリップタイムライン ClipTimeLine)を 、第 1リムーバブル HDDに書き込む。そして、ステップ S165において、第 1リムーバ ブル HDD上のクリップ 'メタデータ（リレーション情報等）を更新する。例えば、メディ ァ制御部 205は、第 1リムーバブル HDD上のクリップのクリップメタデータに、次のク リップとして第 2リムーバブル HDD上のクリップを特定する UMID等を書き込む。また 、第 2リムーバブル HDD上のクリップのクリップメタデータに、前のクリップとして第 1リ ムーバブル HDD上のクリップを特定する UMID等を書き込む。その後、ステップ S1 66において、メディア制御部 205は、今後のコンテンツの書き込み先を第 2リムーバ ブル HDDに設定し、処理が終了する。
[0136] 次に、図 17を参照しながら、カムコーダ 100がリムーバブル HDDからコンテンツを 再生する処理、より具体的には、指定された再生開始時刻に基づいて、その時刻に 対応する位置からコンテンツを再生する処理を説明する。なお、コンテンツの最初か ら再生するときの処理は、 KPUエントリ、タイムエントリ等を設けない従来の処理と同 じであるため、その説明は省略する。
[0137] 図 17は、カムコーダ 100によるコンテンツの再生処理の手順を示す。ステップ S17 1において、カムコーダ 100の CPU211は指示受信部 215を介して、ユーザから再 生開始時刻の指示を受け取る。
[0138] ステップ S172において、メディア制御部 205は時間.アドレス変換テーブル（クリツ プタイムライン ClipTimeLine)を読み出して、 CPU211が再生開始時刻のピクチャ を含むキービクチャユニット（KPU)を特定する。そして、ステップ S173において、 C PU211は、再生開始時刻に対応する KPUの開始位置を特定する。この KPUの開 始位置は、 TTSファイル内の復号開始位置（アドレス）を表して ヽる。
[0139] これらの処理の一例は以下のとおりである。すなわち、 CPU211は、再生開始時刻 がタイムエントリ # tとタイムエントリ # (t+ 1)の間の時刻であることを特定し、さらにタ ィムエントリ # tから起算して mアクセスユニット時間（AUTM)を 1単位として何単位 離れているかを特定する。
[0140] 具体的には、まずタイムエントリ # tの KPUEntryReferencelDフィールド 97aの値 に基づいて、ある KPU (KPU # kとする）が特定される。そして、タイムエントリ # が 指し示す時刻から KPU # kの先頭キービクチャの再生が開始されるまでの時間差が TimeEntryTimeOffsetフィールド 97cの値に基づいて取得される。その結果、再 生開始すべきピクチャが KPU # kの中で最初に表示されるピクチャ力 何 AUTM後 か判明する。すると、 KPU # kから KPUごとに KPU期間（KPUPeriod)を加算して いくことで、再生開始すべきピクチャを含む KPUが特定できる。また、タイムエントリ # tが指し示す KPUの先頭アドレスに KPU # kから再生開始すべきピクチャを含む KP Uの直前の KPUまでの KPUSizeを加算していくことで、再生開始時刻に対応する K PUの開始位置を特定できる。なお、「タイムエントリ # tが指し示す KPUの先頭アドレ ス」は、 ClipTimeLineAddressOffsetフィールド 95dの値とタイムエントリ # tの KP UEntryStartAddressフィールド 97bの値との和を計算することによって取得できる
[0141] なお、上述の説明は、説明の簡略ィ匕のため ClosedGOP構造 (GOP内の全てのピ クチャは GOP内のピクチャを参照するのみ）を前提としている。しかしながら、 Closed GOP構造が取れない場合や、保証できない場合には、特定された再生開始時刻を 含む KPUの一つ前の KPUから復号を開始してもよ!/、。 [0142] 次のステップ S174では、メディア制御部 205はそのキービクチャユニット（KPU)の KPUEntry中のフラグを読み出し、ステップ S 175において OverlappedKPUFlag フィールド 98aの値が" lb"か否かを判断する。値が" lb"のときは、キービクチャュ- ット KPUが第 1および第 2リムーバブル HDDにまたがることを意味しており、処理は ステップ S 176に進む。一方値が" Ob"のときは、跨らないことを意味しており、処理は ステップ S 177に進む。
[0143] ステップ S176において、メディア制御部 205は第 1リムーバブル HDDに格納され た KPUの先頭ピクチャデータ力もデータを読み出し、 TS処理部 204が TTSヘッダを 除去すると、デコーダ 206はそのデータ力もデコードを開始する。このとき、特定した ピクチャによっては、読み出しを開始した第 1リムーバブル HDDではなく第 2リムーバ ブル HDDにデータが格納されていることもある力 復号を正しく行うために 2つのタリ ップ (TTSファイル）を跨ぐ KPUの先頭キービクチャからデコードが行われる。
[0144] ステップ S177では、メディア制御部 205は KPUの先頭ピクチャデータからデータ を読み出し、 TS処理部 204が TTSヘッダを除去すると、デコーダ 206はそのデータ 力 デコードを開始する。読み出されるすべてのピクチャデータは、そのリムーバブル HDD内に格納されている。
[0145] その後、ステップ S178では、再生開始時刻に対応するピクチャのデコード終了後 に、グラフィック制御部 207はそのピクチヤから出力を開始する。対応する音声が存 在するときには、スピーカ 209bもまたその出力を開始する。その後は、コンテンツの 最後まで、または再生の終了指示があるまでコンテンツが再生され、その後処理は終 了する。
[0146] 次に、図 18および図 19を参照しながら、リムーバブル HDDに録画されたコンテン ッを編集する処理を説明する。この処理は、カムコーダ 100においても実行されると して説明するが、他には、コンテンツが録画されたリムーバブル HDDが装填された P C108 (図 1)等において実行されてもよい。
[0147] 図 18 (a)および (b)は、編集によって TTSファイルの先頭部分を削除する前後の管 理情報およびクリップ AVストリームの関係を示す。図 18 (a)に示される範囲 D力 削 除の対象となる部分である。この範囲 Dは、 TTSファイルの先頭部分を含む。先頭部 分のアドレスを piとし、 pl + D=p4とする。これまで説明したように、クリップ AVストリ ームは複数のファイルに分けて格納されることがある力 以下の処理は、各 TTSファ ィルの先頭部分を含む削除に対して適用される。
[0148] 図 18 (b)は、範囲 Dを削除した後の管理情報 (クリップタイムライン)およびクリップ A Vストリームの関係を示す。本実施形態では、範囲 Dのすベてを常に削除するのでは なぐ範囲 Dに収まるデータ量のうち、 96キロバイトの n倍（n:整数）のデータ量だけを 削除する。いま、削除後の先頭データ位置をアドレス p2とすると、（p2— pi)は、 (96 キロバイト） xnである。また、 p2≤p4である。
[0149] 「96キロバイト」は、本実施形態において採用するクラスタサイズ（32キロバイト）と、 TTSパケットのパケットサイズ（192バイト）との最小公倍数である。このように処理す る理由は、クラスタサイズの整数倍とすることによってリムーバブル HDDに対するデ ータ削除処理がアクセス単位で実行でき、また TTSパケットのパケットサイズの整数 倍とすることによってデータ削除処理がクリップ AVストリームの TTSパケット単位で実 行できるため、処理を高速ィ匕かつ簡易にできるからである。なお、本実施形態ではク ラスタサイズを 32キロバイトとしているため、 96キロノイトを基準として削除単位を決 定したが、この値はクラスタサイズや、採用するクリップ AVストリームのパケットサイズ に応じて変化し得る。
[0150] 削除処理では、さらに ClipTimeLineTimeOffsetフィールド 95cおよび ClipTime LineAddressOffsetフィールド 95dの値も変更される。これらの値は、削除前は 0で ある。削除後は、まず ClipTimeLineAddressOffsetフィールド 95dに、初めて現れ るキービクチャユニット KPUまでのデータ量が記述される。初めて現れるキービクチ ャユニット KPUの格納アドレスを p3とすると、 ClipTimeLineAddressOffsetフィー ルド 95dは（p3— p2)の値が記述される。また、 ClipTimeLineTimeOffsetフィール ド 95cに、最初のキービクチャユニット KPUの中で先頭のキービクチャの再生時刻か ら最初のタイムエントリまでの時間差が AUTM単位で記述される。なお、アドレス p2 力 p3までのクリップ AVストリームのパケットは、単独でデコードできるという保証がな いため、フラグメントとして扱われ、再生の対象とはされない。
[0151] 図 19は、カムコーダ 100によるコンテンツの部分削除処理の手順を示す。まずステ ップ S191において、カムコーダ 100の CPU211は指示受信部 215を介して、ユー ザから TTSファイルの部分削除指示、および、削除範囲 Dの指定を受け取る。部分 削除指示とは、 TTSファイルの先頭部分および Zまたは末尾部分を削除する指示で ある。指示の内容に応じて、先頭部分を削除する「前方部分削除処理」および Zまた は末尾部分を削除する「後方部分削除処理」が行われる。
[0152] ステップ S192において、前方部分削除処理力否かが判定される。前方部分削除 処理を行う場合にはステップ S193に進み、前方部分削除でない場合にはステップ S 195に進む。ステップ S193では、メディア制御部 205は、削除範囲に相当するデー タ量 Dのうち、 96キロバイトの整数倍のデータ量を先頭から削除する。そしてステップ S194において、メディア制御部 205は、時間 'アドレス変換テーブル（クリップタイム ライン）中の、最初のタイムエントリに対する時間オフセットの値（ClipTimeLineTim eOff setフィールド 95cの値）と最初の KPUエントリに対するアドレスオフセット値（Cli pTimeLineAddressOffsetフィールド 95dの値）とを修正する。その後、処理はステ ップ S 195に進む。
[0153] ステップ S195では、後方部分削除処理力否かが判定される。後方部分削除処理 を行う場合にはステップ S196に進み、行わない場合にはステップ S197に進む。ス テツプ S196では、削除範囲に相当するデータ量のうち、 TTSファイルの最後が完全 な KPUとなるよう 192バイト単位でデータが削除される。これはすなわち、 192バイト の整数倍のデータ量のデータが削除されることを意味する。その後処理はステップ S 197に進む。
[0154] ステップ S197では、部分削除処理によって変化したタイムエントリ数や KPUェント リ数等を修正する。具体的には、時間 'ァドレス変換テーブル (ClipTimeLine)中で 、実データを伴わなくなった KPUEntryエントリ、および KPUEntryReferencelD で参照して!/、た KPUEntryエントリを失った TimeEntryエントリが削除される。また、 TimeEntryNumberフィールド 95aの値、 KPUEntryNumberフィールド 95bの値 等の修正処理が行われる。
[0155] なお、前方部分削除処理および後方部分削除処理のいずれもが行われない場合 にもステップ S197を経由する。これは、例えば TTSファイルの中間部分の削除処理 が行われた場合にも修正処理が行われることを想定している。ただし、中間部分の削 除処理は本明細書にお!、ては特に言及しな!、。
[0156] なお、上述のように部分削除処理は TTSファイルの先頭部分に限られず、 TTSフ アイルの末尾部分を含む範囲の削除処理をしてもよい。この処理は、例えば上述の 不完全なキービクチャユニット KPU (図 14の KPU # d 1 )を削除する際に適用される 。不完全なキービクチャユニット KPUは 1クリップの最後に存在しているため、「TTS ファイルの最後の部分を含む範囲」に相当する。このとき削除される範囲は、不完全 なキービクチャユニット KPUの先頭から TTSファイルの最後までであり、例えば TTS パケットのパケットサイズ（192バイト）単位で削除する範囲を決定すればよい。クラス タサイズは特に考慮しなくてもよい。なお、 TTSファイルの最後の部分は不完全なキ ーピクチャユニット KPUに限られず、ユーザ力 範囲の指定を受けること等により、任 意に決定できる。なお、先頭部分の削除処理と末尾部分の削除処理とを連続して行 つてもよいし、一方の処理のみを行ってもよい。
[0157] (実施形態 2)
次に、本発明のデータ処理装置の第 2の実施形態を説明する。本実施形態による データ処理装置は、実施形態 1によるカムコーダ（図 2)と同じハードウェア構成を有 するカムコーダとする。したがって、本実施形態の説明においても、参照符号 100を 付して説明する。より詳細な構成は図 22を参照しながら後述する。
[0158] 本実施形態と実施形態 1との主な違いは、カムコーダが、第 1に毎秒 60フレームの MPEG— 2ストリーム中に毎秒 24フレームの映像を 3： 2プルダウンにより記録する点 である。第 2に、カムコーダが毎秒 24フレームでカウントしたタイムコード値をストリー ム内およびクリップメタデータファイル内に記録する点である。
[0159] 図 20 (a)〜（c)は、 3： 2プルダウン技術を利用して毎秒 24フレームの映像を毎秒 6 0フレームの映像に変換したときの、各フレームの表示タイミングの関係を示す。毎秒 60フレームの映像は、 MPEG— 2規格に準拠したデータストリームとして記録媒体（ たとえばリムーバブル HDD)記録される。このデータストリームの横と縦の画素数はそ れぞれ 1280および 720とする。以下では、データストリームは実施形態 1において説 明したクリップ AVストリームとする。 [0160] 図 20 (a)は、クリップ AVストリームの先頭部分のピクチャ構造および対応する管理 パラメータを示す。クリップ AVストリームの先頭 KPU # 0、および次の KPU # 1は、 表示順で記載した場合、 ΒΒΙΒΒΡΒΒ· · ·の各ピクチャカゝら構成される（記録順は、 IB ΒΡΒΒ· · · )。
[0161] 図 20 (b)は、毎秒 24フレームでカウントされるタイムコードを示す。このタイムコード は、プルダウン前の映像の各ピクチャの表示タイミングを示している。なお、毎秒 24フ レームの映像は、 1秒間に 24枚のフレームピクチャが次々と切り替えられて表示され ることによって実現されている。各ピクチャは 1Z24秒間表示される。換言すれば、映 像の垂直走査周波数は 24Hzである。
[0162] 一方、図 20 (c)は、毎秒 60フレームでカウントされるタイムコードを示す。このタイム コードは、プルダウン後の映像の各ピクチャの表示タイミングを示している。毎秒 60フ レームの映像は、 1秒間に 60枚のフレームピクチャが次々と切り替えられて表示され ることによって実現されている。各ピクチャは 1Z60秒間表示される。換言すれば、映 像の垂直走査周波数は 60Hzである。
[0163] 図 20 (b)および（c)によれば、 1Z24秒間表示されていた各ピクチャは、 3 : 2プル ダウン処理によって 3Z60秒間または 2Z60秒間表示される。後者の表示は、 1/6 0秒間表示されるフレームが 3回または 2回連続して出力されることを意味する。変換 前の各フレームは、変換後は交互に 3Z60秒間および 2Z60秒間表示される。
[0164] 本実施形態によるカムコーダの特徴のひとつは、プルダウン後のデータストリーム 中に、毎秒 24フレームでカウントされるタイムコードを記録する点にある。より詳しく説 明すると、従来のクリップ AVストリームは、図 20 (c)に示すタイムコード値を少なくとも 1つ有している。本実施形態によるデータストリームには、ピクチャごとに図 20 (b)し示 すタイムコード値が記述されて 、る。
[0165] 以下、図 21を参照しながら、本実施形態によるデータストリームのデータ構造を説 明する。なお、説明を簡単にするためトランスポートストリームを例に挙げる。図 6に示 すように、トランスポートストリームに TTSヘッダを付加すればクリップ AVストリームが 得られる。
[0166] 図 21 (a)〜（c)は、本実施形態によるストリームのデータ構造を示す。図 21 (a)に 示される TS40の各ビデオ TSパケット 40a〜40dには、図 21 (b)に示される PES41 が含まれている。 PES41は PESパケット 41aおよび 41b力 構成される。ここで各 PE Sパケットには 1枚のビデオフレームが格納されているとする。なお、各 PESパケットに 1枚のビデオフィールドまたは 2枚のビデオフィールドペア（すなわち 2枚のビデオフィ 一ルド）が格納されてもょ 、。
[0167] PESパケットのヘッダには、 PESペイロードに格納されたピクチャデータの表示タイ ミングを示すプレゼンテーション 'タイムスタンプ（PTS)が書き込まれている。たとえば PESヘッダ 41a— 1には、 PESペイロード 41a— 2に格納されたピクチャデータの PT S— 1が格納されている。 PTS値は図 20のプルダウン後の時間軸上において各ピク チヤの表示開始タイミングを示す。毎秒 60フレーム秒でカウントするタイムコード値と の違いは、 90kHzのクロックでカウントする点である。ピクチャを表示するタイミングは 、 PTS値であってもタイムコード値であっても同じ時刻を指し示す。
[0168] 図 21 (c)は、 PESペイロードのデータ構造を示す。この例の PESペイロード 41a— 2には、 GOPヘッダ 42e、ピクチャヘッダ 42aおよびピクチャデータ 42bが含まれてい る。 GOPヘッダ 42eは、 GOPの先頭ピクチヤに配置されたピクチャデータの前に付 カロされ、必ずしもすべてのピクチャデータの前に配置されない。
[0169] GOPヘッダ 42eには、 MPEG— 2ビデオ規格の規定に従って、毎秒 60フレームで カウントされるタイムコードが記録される。図 21 (c)では、最初に表示されるピクチャの 開始タイムコード tlが記述される。
[0170] そして、 GOPヘッダ 42eに続くピクチャヘッダ 42aのユーザデータフィールド（MPE G2ビデオ規格の extention— user— data (2) )には、毎秒 24フレームでカウントし たときのタイムコードが記述される。図 21 (c)では、最初に表示されるピクチャの開始 タイムコード t2が記述される。同様のタイムコード t3が次のピクチャデータ 42dの前に 付加されたピクチャヘッダ 42cにも記述される。
[0171] ここで、図 20 (b)および (c)に示す例と関連付けて説明する。
[0172] たとえば、 1つの KPUに 1つの GOPが含まれるとしたとき、 KPU # 0の GOPヘッダ には図 20 (a)の先頭の Bピクチャに対応する 00： 00： 00： 00が記録され、 KPU # 1 の GOPヘッダには KPU # 1の先頭ピクチヤに対応する 00： 00： 00： 30が記録される 。これらはそれぞれ、 0時間 0分 0秒 0フレームおよび 0時間 0分 0秒 30フレームを示す 。 GOPヘッダのタイムコードは、 00 : 00 : 00 : 59の次に桁上がりして 00 : 00 : 01 : 00 になる。図 20 (c)では秒およびフレームに対応する数値のみが示されている。
[0173] 一方、ピクチャヘッダ内のタイムコードには、最初に表示される先頭の Bピクチャに は 00 : 00 : 00 : 00が記録される。これは、 0時間 0分 0秒 0フレームを示す。次の Bピク チヤには 00 : 00 : 00 : 01が記録される。これは 0時間 0分 0秒 1フレームを示す。そし て次の Iピクチャには 00 : 00 : 00 : 02が記録される。
Figure imgf000042_0001
、ても同様 に記述される。毎秒 24フレームでカウントすると、 00 : 00 : 00 : 23の次は、桁が上がり 00 : 00 : 01 : 00となる。図 20 (a)では秒およびフレームに対応する数値のみが示され ている。
[0174] MPEG— 2ビデオ規格上、ユーザデータフィールド内には基本的に自由に値を格 納することができる。だだし、特定の 4バイトコード (たとえば、シーケンヘッダーコード である 0x000001B3)とは重複しないように、 4バイト周期で特定のビットを 1にする等 の配慮は必要である。
[0175] タイムコードのデータ構造としては SMPTE M12規格が一般的である。図 34は、 SM PTE Ml 2規格に準拠したタイムコードのデータ構造の概略を示す。図 34に示され るタイムコードは計 4バイトのデータであり、 1バイトを単位とするアドレス 00〜03に分 けられている。各バイトはさらに、 2つのフィールド (各 4ビット）に分けられで意味が与 えられている。図には、各フィールドの規格上の意味および各フィールドの値の範囲 が記述されている。なお、同規格ではさらに Drop Frame Flag, Binary User Group Bit 等を規定する。
[0176] 次に、本実施形態によるカムコーダ 100の動作を説明する。
[0177] カムコーダ 100は、 CCD201aが出力する毎秒 24フレームの映像を MPEG— 2ェ ンコーダ 203で毎秒 60フレームの MPEG— 2トランスポートストリームを生成し、ショッ トとしてリムーバブル HDDへ記録する。
[0178] このとき、 MPEG— 2エンコーダ 203は、ピクチャ層のユーザデータフィールド内に 毎秒 24フレーム毎にカウントアップするタイムコードを格納する。また、 MPEG— 2ェ ンコーダは、 3 : 2プルダウン記録するために、一枚のピクチャを 1Z60回の周期で数 えて 3周期分、もしくは 2周期分だけ交互に表示するように MPEG— 2ビデオストリー ムを生成する。 3周期分、もしくは 2周期分表示するための指示は、 MPEG規格に従 つてピクチャヘッダ内に格納する。具体的には repeat— first— fieldと top— field— f irstの値が両方共に 1の場合は、 3周期分を意味し、それぞれの値が 1と 0の場合は 2 周期分を意味する。
[0179] 再生時は、カムコーダ 100はリムーバブル HDDに記録されたクリップ AVストリーム を読み出し、デコーダ 206において復号処理を行う。このとき、ピクチャ層のユーザデ ータフィールド内に記録された毎秒 24フレームでカウントするタイムコードを取得し、 その値を映像上にオーバーレイ表示する。
[0180] ここで、図 22を参照しながら、図 21 (a)〜（c)に示すデータストリームを生成する力 ムコーダ 100の具体的な構成を説明する。
[0181] 図 22は、本実施形態によるカムコーダ 100の、部分的な機能ブロックの構成を示す 。図 2に示すハードウェア構成図と対比すると、図 22はエンコーダ 203、 TS処理部 2 04、メディア制御部 205、デコーダ 206およびシステム制御部 250を詳細に示してい る。
[0182] 動画記録時は、記録制御部 161の制御により、エンコーダ 203の映像圧縮部 203a 及び音声圧縮部 203bは、入力された映像信号及び音声信号を圧縮し、ピクチャデ ータおよびオーディオデータを生成する。エンコーダ 203のシステムエンコード部 20 3cは、ピクチャデータおよびオーディオデータを受け取ってトランスポートストリームを 生成する。
[0183] このときシステムエンコード部 203cは、図 21 (b)および（c)に示す各ヘッダを生成 する。すなわち、システムエンコード部 203cは、図 21 (c)に示すタイムコード t2およ び t3を格納したピクチャヘッダ 42aおよび 42cを生成する。タイムコード t2および t3 は、ピクチャヘッダ内のユーザデータ（extention#and#user#data(2))フィールドに記述 される。またシステムエンコード部 203cは、図 21 (c)に示すタイムコード tlを格納し た GOPヘッダ 42eを生成し、図 21 (b)に示す PTS— 1を格納した PESヘッダ 41a— 1を生成する。
[0184] MPEG -4 AVC規格に準拠したビデオストリーム（AVCストリーム）には、 GOPへ ッダは存在しない。しかし、 AVCストリームにおいても、図 21の説明は同様に適用で きる。
[0185] 図 35は、 MPEG— 4 AVC規格に準拠したビデオストリームのデータ構造を示す。
MPEG -4 AVC規格においては、 Iスライスのみから構成されるピクチャの直前に、 同規格の Picture Timing SEI Messageとしてタイムコードを記述できる。このタイムコー ドは、これまでの例における GOPヘッダ内に格納される毎秒 60フレームでカウントさ れるタイムコードに対応する。
[0186] 一方、ピクチャヘッダ内の毎秒 24フレームでカウントされるタイムコードは、 MPEG
-4 AVC規格の User Data unregistered SEI Messageとして記述される。なお、 AU delimiterはフレームの区切りを示し、 SPS (Sequence Parameter Set)、 PPS (Picture Parameter Set)はビデオストリームの仕様を格納する。 IDRピクチャは MPEG— 2ビ デォの Iピクチャに対応する。 1フレーム分の MPEG— 4AVCビデオストリームは 1個 の PESパケット内に記録され、その PESヘッダには PTSが付与される。この PTSは 図 21に示す毎秒 60フレームの周期を基準として付与されるのに対し、 User Data Un registered SEI Message内には毎秒 24フレームでカウントされるタイムコードが記録さ れる。
[0187] なおここで、 Picture Timing SEI Message内のタイムコードを GOPヘッダ相 当分だけ記述するのではなぐ全フレームの直前に記述してもよい。また、 Picture Timing SEI Message内に毎秒 60フレームでカウントするタイムコードを記述する のではなぐ User Data Unregistered SEI Message内に、毎秒 24フレームで カウントするタイムコードと並列して記述してもよい。また、毎秒 60フレームのタイムコ ードを User Data Unregistered SEI Message内に記述するときには、毎秒 24 フレームでカウントするタイムコードを Binary Group領域に記述してもよい。 Binary
Gorup領域は、タイムコード規格（SMPTE 12M)で規定される 4バイトの自由な 値設定が可能な領域である。また、毎秒 60フレームのタイムコードを動画ストリーム中 に一切記録しなくてもよい。
[0188] 次に、 TS処理部 204はトランスポートストリームからクリップ AVストリームを生成する 。クリップ AVストリームは、記録部 205a、磁気ヘッド 141を経由してハードディスク 14 0へ書き込まれる。
[0189] 記録制御部 161はクリップ AVストリームの記録を開始する前に、連続データ領域 検出部 160を起動して、空き領域を搜させる。連続データ領域検出部 160は、論理 ブロック管理部 163で管理されるあら力じめ光ディスク力も読出したスペースビットマ ップを調べて、連続した空き領域を探索する。そして探索の結果として検出された空 き領域にクリップ AVストリームを書き込みはじめる。そして、その領域への書き込みが 終了するまでに、次の空き領域を継続的に探索し、クリップ AVストリームを継続的に 書き込む。クリップ AVストリームの書き込みが完了すると、 UDFのファイル管理情報 を書き込み、クリップ AVストリーム（*.TTSファイル、すなわち動画ストリームを格納す るファイル)の書き込みを完了する。次に、記録完了したクリップ AVストリームに対応 するストリーム管理データファイル (*.clpi)を記録する。
[0190] また、再生時は、ユーザが再生すべきコンテンツを選択すると、再生制御部 162の 制御により、再生部 205bを経由して、コンテンツに対応するクリップ AVストリームの 管理情報を管理ファイル力 読み出し、その管理ファイルに記載されたアドレス情報 を参照して、さらにクリップ AVストリームを読み出す。 TS処理部 204は、このクリップ AVストリームからトランスポートストリームを生成する。システムデコード部 206cが映 像データと音声データとを分離すると、映像伸長部 206a及び音声伸長部 206bは、 それぞれ映像データおよび音声データを復号化し、映像信号及び音声信号として出 力する。
[0191] また、編集制御部 164は、記録済みのコンテンツに対してユーザ力も部分的な削除 が指示されたときに、記録部 205aおよび再生部 205bを起動してクリップ AVストリー ムやその管理データを読出したり、修正後に書き込む等の編集処理の制御を行う。ま た、記録済みのコンテンツに対してユーザから削除が指示された時に、対応するタリ ップ AVストリーム、ストリーム管理データファイルを削除する。
[0192] 実施形態 1によるカムコーダと同様、本実施形態によるカムコーダもまた、クリップ A Vストリームファイルに対応するクリップメタデータファイルを生成する。クリップメタデ ータファイルは、メディア制御部 205によって生成されてもよいし、システム制御部 25 0の CPU211によって生成されてもよ！、。 [0193] 図 23は、クリップメタデータファイル 300のデータ構造を示す。内部にクリップ名 30 Oa、再生時間長 300b、： EditUnit長 300c、リレーション 300d、エッセンスジス卜 300e の各フィールドを含む。さらにエッセンスリスト 300eは、フォーマット種別 300f、ピーク ビットレート 300g、映像の各フィールド 300hを含む。さらに映像フィールド 300hは、 コーデック情報 300i、プロファイル Zレベル 300j、フレームレート情報 300k、画素数 3001、ドロップフレームフラグ 300300m、プルダウン情報 300n、開始タイムコード 3 OOo、終了タイムコード 300p、アスペクト比 300q、再生しない区間長 300r、先頭 3フ レームフラグ 300sの各フィールドを含む。
[0194] 再生時間長フィールド 300bは、 1クリップの再生時間長を EditUnit単位で表現す る。 EditUnit長フィールド 300cは、 1単位の EditUnit長の時間長を指定する。図 2 3中では 1Z24秒が指定されている。これは、元の映像が毎秒 24フレームで表示さ れることを示す。一方、このクリップメタデータファイル 300に対応するクリップ AVスト リームファイルの映像のフレームレートは、フレームレート情報 300kにおいて特定さ れている。
[0195] リレーション情報フィールド 300dは、同じショット内の後続クリップの TTSファイルの 名前（MOV00002.TTS)が記録されている。フォーマット種別フィールド 300fには、ク リップの AVデータのフォーマット種別が Timed TSとして登録されている。ピークビ ットレートフィーノレド 300gには、 MPEG— 2トランスポートストリームのピークビットレー トが 24Mbpsであることが登録されている。映像フィールド 300hのうち、コーデック情 報、プロファイル Zレベル情報、フレームレート情報、画素数情報 (横 X縦)、ドロップ フレームフラグ、プルダウン情報、アスペクト比の各フィールドには、それぞれ MPEG - 2 Video, MP@HL、 1/60, 1280 X 720、ノンドロップ、 3 : 2プルダウン、 16 : 9、 OEditUnitが記録されて!、る。
[0196] また、フィールド 300οには、クリップ中で再生される先頭ピクチヤのタイムコード（開 始タイムコード）が記録され、フィールド 300ρには、再生される最終ピクチヤの次のタ ィムコード（終了タイムコード）が記録される。これらのタイムコード値は時：分:秒:フレ ーム番号として記録される。この「フレーム番号」によって特定されるフレームは、フレ ームレート情報 300kで指定されているレートで表示される。よって、フレーム番号は 5 9まで増加した後 0に戻る。図 23では、それぞれ 00 : 00 : 00 : 00、および 00 : 01 : 00 : 00 (1分の長さ）の値が登録されている。なお、終了タイムコードは最終ピクチヤのタイ ムコード値であってもよ ヽ。
[0197] 先頭 3フレームフラグ 300sは、開始タイムコード 300οに対応する先頭ピクチャ力 3 フレーム区間に対応するのか、または 2フレーム区間に対応するのかを示す。前者の 場合、値は 1であり、後者の場合値は 0である。図 23では、値は 1に設定されていると する。
[0198] 本実施形態によるカムコーダ 100は、上述のデータ構造を有するクリップ AVストリ ームファイルおよびクリップメタデータファイル 300を生成する。このようなデータ構造 を用いることにより、ユーザが映像を編集する時の処理が非常に簡単になる。以下、 その詳細を説明する。
[0199] 図 24は、タイムコード値に基づいてそのタイムコード値に対応するピクチャを特定 する処理の手順を示す。この処理は、後に具体的に詳述する。
[0200] 図 25は、 1ショットが 1個の TTSファイルで構成される場合の管理パラメータを示す 。この図 25は、表示時間でみたときの各 KPUの配列を示している。開始タイムコード (300ο)および KPU期間（298c)は図 20に示されるとおりである。また、再生時間長 、 StartSTC、および ClipTimeLineDurationは実施形態 1と同様である。
[0201] 図 26は、 ClipTimeLineAddressOffsetが零でなぐかつ 1ショットが 1個の TTSフ アイルで構成されるときの管理パラメータの意味を示す。図 25と較べて、再生しない 区間長が零でな 、点、および最後の KPUの後半を再生しな 、点（具体的には再生 時間長から除外している）が異なる。図 26中の p2、 p3、 p4は、それぞれ図 18の p2、 p3、 p4に対応する。
[0202] 図 26に示す TTSファイルの上段および下段は同じクリップ AVストリームを示してい る。上段は、表示時間でみた TTSファイル内の各 KPUの配列を示しており、横軸の ラベルは「時間」とされている。一方の下段は、データサイズでみた TTSファイル内の 各 KPUの配列を示しており、横軸のラベルは「データサイズ」とされている。これらは 以下では同じである。
[0203] 図 27は、 1ショットが複数の TTSファイルのチェーンで構成される場合の管理パラメ ータの意味を示す。各 TTSファイルの ClipTimeLineDurationは、それぞれの TT Sファイルに対応するタイムマップファイルの KPUEntry(295h)の KPU期間の合計 となる。
[0204] カムコーダ 100を利用した編集時の処理を説明する。上述のように、映像の再生時 には、カムコーダ 100は、ユーザデータフィールド内に記録された毎秒 24フレームで カウントするタイムコードを取得する。グラフィック制御部 207は、その値を映像上にォ 一バーレイ表示する。このとき、ユーザは映像上にオーバーレイ表示されたタイムコ 一ド値を見て、 IN点、 OUT点、もしくは注目点として取り扱いたい映像のタイムコード 値を確認可能である。また、カムコーダはその映像のタイムコード値を取得し、その取 得したタイムコード値を、たとえばプレイリスト内で IN点、 OUT点の値として設定する
[0205] 上述のプレイリストを再生するとき、毎秒 24フレーム毎にカウントされるタイムコード 値から、図 24に示す手順により、対応するピクチャを特定する処理が行われる。
[0206] ユーザがタイムコード値を入力する（S310)。すると編集制御部 164は、クリップメタ データファイル 300を参照して、まずその入力されたタイムコード値と開始タイムコー ド値 (295f)との差分に、再生しない区間長（300r)を加算した値を、差分タイムコー ド値として算出する（S311)。なお再生しない区間長（300r)は、たとえば GOP先頭 力 (n+ 1)フレーム目以降の再生が指定されたときに、 nフレームを示す値力 ¾ditU nit単位で記述される。
[0207] 次に編集制御部 164は、その差分タイムコード値を使って、対応する STC値である 目標 STC値を算出する。この目標 STC値は、特定したいピクチャの PTS値と実質的 には同じである。
[0208] 先頭 3フレームフラグの値が 1の場合の計算式を図 24の S312中に示す。 S312の Ceil (x)関数 (ここで Xは実数）は、値 X以上で、かつ最も Xに近い整数値を関数値と する。ここで差分タイムコード値を 5Z2倍している理由は、毎秒 3 : 2プルダウンした M PEGストリームとして記録しているためである。なお、先頭 3フレームフラグの値が 0の 場合は、目標 STC値は次式より求めることができる。
[0209] (数 4) 目標 STC値 =StartSTC値（295f)
+ floor (差分タイムコード X (5/2) X (27, 000, 000,60) )ここで、 floor (x) 関数 (ここで Xは実数）は、値 X以下で、かつ最も Xに近い整数値を関数値の値とする。
[0210] 次に編集制御部 164は、各 KPUEntry(295h)の KPU期間（298c)を、 KPU # 0 の KPUEntryから順に加算し、
(数 5)
目標 STC値≤StartSTC値（295f) + EKPUPeriod
となる初めての KPU番号 (その番号を kとする）を導出する（S313)。ここで、指定さ れたタイムコード値に対応するピクチャのアドレスは、 KPU # kに含まれることになる。 編集制御部 164は、次にこの KPU # kの格納先アドレスを次式より求める（S314)。
[0211] (数 6)
ClipTimeLineAddressOffset (295d) + EKPUSize
ただし、∑KPUSizeは KPU # 0から、 KPU # kまでである。編集制御部 164はさら に、 KPU # kの先頭ピクチャ (ただし表示順）と、タイムコード値に対応するピクチャと の間の差分 STCを次式より求める（S315)。
[0212] (数 7)
差分 STC=目標 STC値—（StartSTC値 + EKPUPeriod)
なお差分 STC>0の場合には、この時間差分だけ表示スキップする必要がある。
[0213] 上述の処理によって、ユーザが毎秒 24フレーム中の 1画像を IN点、 OUT点、もしく はチャプターの分割点として直接指定すると、そのフレームのタイムコードに基づい て、プレイリストを使った仮想編集や、クリップ AVストリームの分割編集を実施できる。 これにより、編集作業を効率的に進めることができる。
[0214] なお、実施形態 2においてショットの前方削除を実施する場合は、実施形態 1と同 様の処理が必要となることに加えて、開始タイムコード（300o)、および再生しない区 間長（300r)の変更が必要となる。
[0215] なお、 S315において差分 STCが求まると、その後は KPU内のデータを検索して、 差分 STCに対応する分だけフレームスキップして再生（出力）を開始する必要がある [0216] (実施形態 3)
次に、本発明のデータ処理装置の第 3の実施形態を説明する。本実施形態による データ処理装置は、実施形態 2によるカムコーダ（図 2および図 22)と同じハードゥエ ァ構成を有するカムコーダとする。実施形態 3と実施形態 2との主な違いは、カムコー ダによって生成される KPUEntryフィールドのデータ構造である。なお、 KPUEntry フィールドはクリップタイムラインに含まれており、メディア制御部 205によって生成さ れる。
[0217] 図 28 (a)〜（c)は、 3： 2プルダウン技術を利用して毎秒 24フレームの映像を毎秒 6 0フレームの映像に変換したときの、各フレームの表示タイミングの関係を示す。この データストリームの横と縦の画素数はそれぞれ 1280および 720とする。
[0218] 図 28 (a)〜 (c)が、実施形態 2に関連して説明した図 20 (a)〜 (c)と相違する点は 以下のとおりである。まず第 1の相違点は、 KPUEntry内に、 KPU期間（KPUPerio d)に代えて PTS差分（PTS Difference)を示すフィールド（398c)を設けた点であ る。 PTS差分フィールドには、ある KPUとその直後の KPUの間、すなわち隣接する KPUの間で、キービクチャの PTS間の差分を AUTM単位で表現した値が記述され る。
[0219] 第 2の相違点は、 StartSTC (295f)に代えて StartKeySTC (395f)のフィールド を設けた点である。 StartKeySTCフィールドには、ひとつの TTSファイル中の先頭 KPU (KPU # 0)内の最初の Iピクチャの表示タイミングを、 AUTM単位で表現した 値が記述される。
[0220] 第 3の相違点は、 TimeOff set (395i)を設けた点である。 TimeOff setフィールド には、先頭の KPUの中で最初に表示されるピクチャと、その KPU内の最初の Iピク チヤ間の時間差を AUTM単位で表現した値が記述される。図 28に示す例では、 KP U # 0の中で最初に表示される Bピクチヤと、同じ KPU # 0の中の最初の Iピクチャの 間の時間差、すなわち毎秒 60フレーム中の 5フレーム区間を示す値が TimeOffset フィールドに記述される。
[0221] 図 29は実施形態 3によるクリップメタデータファイル 400のデータ構造を示す。この クリップメタデータファイル 400は、 1ショットが 3個のクリップから構成されるときの 1個 目のクリップに対応するクリップメタデータファイルを示す。クリップメタデータファイル
400の各フィールド 400a〜400sは図 23に示す各フィールド 300a〜300sに対応し ている。再生時間長が記述されるフィールド 400bの設定値を除き、両者は同じであ る。
[0222] 図 30は本実施形態における ClipTimeLineファイル 395のデータ構造を示す。図 28と図 20との相違点は、この ClipTimeLineファイル 395に反映されている。すなわ ち、 KPUEntry395h内で KPU期間に代えて PTS差分（398c)を記述するフィール ドが設けられている。また、 StartSTC (295f)に代えて StartKeySTC (395f)を記 述するフィールドが設けられている。そして、 TimeOffset (395i)を記述するフィール ドが設けられている。なお、 ClipTimeLineファイル 395には、実施形態 1に関連して 説明した図 12に示すタイムエントリフィールド 95gは存在しない。
[0223] 図 31は、タイムコード値に基づいてそのタイムコード値に対応するピクチャを特定 する処理の手順を示す。この処理は、後に具体的に詳述する。
[0224] 図 32は、 1ショットが 1個の TTSファイルで構成される場合の管理パラメータの意味 を示す。開始タイムコード (400ο)の意味は図 25の開始タイムコード（300ο)と同じで ある。再生時間長および ClipTimeLineDurationの意味は実施形態 1で説明したと おりである。図 25と異なる点は、図 25の StartSTCフィールド（295f)が StartKeyS TCフィーノレド（395f)へ変更されて!ヽる点である。
[0225] 図 33は、実施形態 3における ClipTimeLineAddressOffsetが零でなぐかつ 1シ ヨットが 3個の TTSファイルで構成される場合の管理パラメータの意味を示す。図 32と 較べて、再生しない区間長が零でない点、および最後の KPUの後半を再生しない 点 (具体的には、終了タイムコードで指定し、かつ再生時間長に含めない）が異なる。 また、図 33中の p2、 p3、 p4は、それぞれ図 18の p2、 p3、 p4に対応する。
[0226] 実施形態 2と異なる点は、 TTSファイルの再生時間長が、開始タイムコードで参照 される再生開始点から、後続する次の TTSファイル内の最初の完全な KPU中のキ ーピクチャまでを EditUnit単位でカウントする点である。また、 2番目の TTSファイル の再生時間長は、同 TTSファイル内の最初の完全な KPU中のキービクチャから、後 続する次の TTSファイル中の最初の完全な KPUのキービクチャまでの時間差を Edi tUnit単位でカウントする点である。そして、 1ショットの最後の TTSファイルの再生時 間長は、同 TTSファイル中の最初の完全な KPU中のキービクチャから、最後の再生 すべきピクチャまでを EditUnit単位でカウントする点である。
[0227] なお、 1ショットが図 33のような 3個ではなぐ 4個以上の TTSファイルから構成され る場合、先頭のファイルと最後のファイルを除ぐその間の TTSファイルの再生時間 長は、図 32の 2番目の TTSファイルの再生時間長と同様の値を設定する。
[0228] 本実施形態の主要な特徴を以下に説明する。本実施形態においては、 TTSフアイ ルチェーンのうちの最初の TTSファイルにのみ、 TimeOffset (395i)を規定して!/、る 。そのファイルに対応する ClipTimeLineファイルにおいて、 TimeOffsetおよび PT S差分を管理することにより、 1ショットの再生時間長をピクチャ精度で管理することが できる。ここで、 PTS差分は、 MPEG— 2ストリームの Iピクチャのみ検出すればよいの で、全ピクチャ数をカウントする場合に較べて簡単な処理で済む。よって MPEGェン コーダの外部回路でも容易に PTS差分を検出できる。また、 PTS差分の導入により、 カムコーダの IEEE1394インターフェースやチューナ一等を介して放送波を記録す る場合であっても、 KPUエントリを容易に生成できる。
[0229] また一方、 TimeOffsetは、ショットの先頭部分だけ Iピクチャよりも前のフレーム数を 検出することにより、容易に設定可能である。もしくは、 MPEGエンコーダ部力 ショッ トの先頭部分だけ、 Iピクチャよりも前のフレーム数として固定値を使うことにより、容易 に TimeOffsetの値を設定可能である。または、外部機器等カゝらクリップ AVストリー ムをー且記録した後で解析することにより容易に TimeOffsetの値を設定可能である
[0230] なお、ショットの先頭部分だけ TimeOffsetを管理するため、 MPEG— 2ビデオスト リームの GOPを構成するピクチャの構造がストリームの途中で変化しても、 TimeOff setや PTS差分の生成方法には影響しない。例えば、 1個の GOPを構成するピクチ ャ構造が、ストリームの途中において、（記録順で) IBBPBB力ら IPBBへ、もしくは IPI Pへ変化したとしても、管理データの生成手順には影響しない。これによりストリーム の GOP構造は自由に変更できることになるので、シーンチェンジの検出直後に IPB Bの GOP構造を一時的にとることができ、画質の向上を図ることができる。 [0231] 上述のように、 TimeOffsetの値は設定容易であり、 MPEGエンコーダの外部回路 で検出可能なので、 KPU毎に KPU期間を MPEGエンコーダの外部に送出する必 要がな 、。よって MPEGエンコーダ LSIの API (アプリケーションインタフェース）を軽 くすることができる。また、汎用の MPEGエンコーダ LSIを使用できるため、導入する ためのコストの増加を抑えることができる。
[0232] 本実施形態によるカムコーダ 100の動作を説明する。なお、カムコーダ 100がクリツ プ AVストリームを生成する具体的な動作、そのクリップ AVストリームを再生する処理 は実施形態 2によるカムコーダと同じである。よってその説明は省略する。
[0233] 本実施形態によるカムコーダ 100は、クリップ AVストリームファイルに対応するクリツ プメタデータファイルを生成する。クリップメタデータファイルは、メディア制御部 205 ( またはシステム制御部 250の CPU211)によって生成される。
[0234] メディア制御部 205は、 KPUEntry395h内の PTS差分フィールド（398c)に PTS 差分値を記述し、 StartKeySTC (395f)フィールドに StartKeySTCを記述する。さ らにメディア制御部 205は、 TimeOffset (395i)フィールドに TimeOffsetを記述す る。
[0235] 編集時において、ユーザは映像上にオーバーレイ表示されたタイムコード値を見て 、 IN点、 OUT点、もしくは注目点として取り扱いたい映像のタイムコード値を確認可 能である。また、カムコーダはその映像のタイムコード値を取得し、その取得したタイ ムコード値を、たとえばプレイリスト内で IN点、 OUT点の値として設定する。
[0236] 上述のプレイリストを再生する場合、毎秒 24フレーム毎にカウントされるタイムコード 値から、図 31に示す手順により、対応するピクチャを特定する処理が行われる。すな わち、ユーザがタイムコード値を入力する（S410)。すると編集制御部 164はクリップ メタデータファイル 400を参照して、まずその入力されたタイムコード値と開始タイムコ ード値 (400ο)との差分に、再生しない区間長 (400r)を加算した値を、差分タイムコ ード値として算出する（S411)。
[0237] 次に編集制御部 164は、その差分タイムコード値を使って、対応する STC値である 目標 STC値を算出する。実施形態 2に関連して説明したように、この目標 STC値は、 特定した 、ピクチャの PTS値と実質的には同じである。 [0238] 先頭 3フレームフラグの値が 1の場合の計算式を S412中に示す。 S412 Ceil (x) 関数 (ここで Xは実数）は、値 X以上で、かつ最も Xに近い整数値を関数値とする。ここ で差分タイムコード値を 5/2倍して!/、る理由は、毎秒 3： 2プルダウンした MPEGスト リームとして記録しているためである。なお、先頭 3フレームフラグの値が 0の場合は、 目標 STC値は次式より求めることができる。
[0239] (数 8)
目標 STC値 = StartSTC (395f)
-TimeOffset (395i) X (27, OOO, 000/60)
+floor (差分タイムコード X (5/2) X (27, 000, 000/60) )
ここで、 floor (X)関数 (ここで Xは実数）は、値 X以下で、かつ最も Xに近い整数値を関 数値の値とする。
[0240] 次に編集制御部 164は、各 KPUEntry(395h)の PTS差分（398c)を、 KPU # 0 の KPUEntryから順に加算し、
(数 9)
目標 STC値≤ StartKeySTC値（395f)
+∑PTS Difference
となる初めての KPU番号 (その番号を kとする）を導出する（S413)。ここで、指定さ れたタイムコード値に対応するピクチャのアドレスは、 KPU # kに含まれることになる。 編集制御部 164は、次にこの KPU # kの格納先アドレスを次式より求める（S414)。
[0241] (数 10)
ClipTimeLineAddressOffset (395d) + EKPUSize
ただし、∑KPUSizeは KPU # 0から、 KPU # kまでである。編集制御部 164はさら に、 KPU # kの先頭ピクチャ (ただし表示順）と、タイムコード値に対応するピクチャと の間の差分 STCを次式より求める（S415)。
[0242] (数 11)
差分 STC =
目標 STC値—（StartKeySTC値 +∑ KPUDiff erence)
なお、差分 STC>0の場合には、この時間差分だけ表示をスキップする必要がある。 [0243] 上述の処理によって、ユーザが毎秒 24フレーム中の 1画像を IN点、 OUT点、もしく はチャプターの分割点として直接指定すると、そのフレームのタイムコードに基づい て、プレイリストを使った仮想編集や、クリップ AVストリームの分割等の実体編集を実 施できる。また、毎秒 24フレーム中のタイムコードを使ってプレイリストを利用した再生 も可能である。これにより、編集作業を効率的に進めることができる。
[0244] 本実施形態によるメディア制御部 205は、エンコーダ 203から GOPを構成するピク チヤ構成の情報を取得しなくとも、タイムコードによる指定を実現するためのクリップメ タデータファイルおよび ClipTimelineファイルを生成できる。よって、クリップ AVスト リームの GOPを構成するピクチャ構成が変化しても、メディア制御部 205はクリップメ タデータファイル 400および ClipTimelineファイル 395を生成することができる。そし て編集制御部 164は、記述されたタイムコードに対応するフレームから、編集および 再生を開始することができる。
[0245] 特に、 ClipTimelineファイル 395においては、 PTS差分（398c)の他に TimeOffs et (3951)が管理されて!、るので、 1ショット内に記録されて 、るフレームの正確な数 を容易に算出できる。これにより、ユーザはフレーム単位で映像を編集することが可 會 になる。
[0246] なお、実施形態 3においてショットの前方削除を実施する場合は、実施形態 1と同 様の処理が必要となることに加えて、開始タイムコード (400o)、および再生しない区 間長（400r)、 TimeOffset (395i)の変更が必要となる。
[0247] 以上、本発明の各実施形態を説明した。
[0248] 上述の実施形態 2および 3の説明においては、装置に入力される映像のフレームレ ートは毎秒 24フレームであるとした。しかしこれは一例である。他の例として、毎秒 23 . 97フレーム（1001Z24000フレーム）であってもよい。また、装置によって生成され る映像のフレームレートは毎秒 60フレームであるとした力 他の例として毎秒 59. 94 フレーム（1001Z60000フレーム）であってもよ!/ヽ。
[0249] また、毎秒 24フレームの映像を 3： 2プルダウン処理して、毎秒 60フレームの MPE G— 2ストリームを生成する例を挙げた。し力し、毎秒 30フレームの映像を 2 : 2ブルダ ゥン処理して毎秒 60フレームの MPEG - 2ストリームを生成してもよ!/、。 [0250] なお、実施の形態 2、および 3では、毎秒 24フレームの映像を生成して毎秒 60フレ ームの動画ストリームとして記録する場合のみ、毎秒 24フレームのタイムコードをスト リーム中に記録するものとした力 毎秒 60フレームの映像を毎秒 60フレームの動画 ストリーム内に記録する場合であっても、例えばピクチャヘッダ内に毎秒 60フレーム のタイムコードを記録してもよい。これにより、再生制御部は映像のフレーム数に依存 しないで常にピクチャヘッダを参照して映像の上にオーバレイ表示することができる。
[0251] また映像のフレームを基準としてではなぐフィールドを基準として処理を行ってもよ い。たとえば毎秒 24フレームの映像を 3 : 2プルダウン処理して、毎秒 60フィールド（ または 59. 94フィールド）の MPEG— 2ビデオストリームを生成してもよい（例えば、 横 1920x縦 1080画素や、横 720x縦 480画素の場合がある）。このとき、先頭 3フレーム フラグ（300s、 400s)に記述するフラグの生成基準を変更する必要がある。たとえば 、開始タイムコード（300ο、 400ο)で参照されるピクチャ力 60フィールド中の 3フィ 一ルドに対応する場合にフラグ値を 1とし、 2フィールドに対応する場合にフラグ値を 0とすればよい。なお、これらのフラグは先頭 3フレームフラグではなぐ先頭 3フィー ルドフラグと呼ぶのがふさわし 、。
[0252] 図 36 (a)〜（c)は、 3： 2プルダウン技術を利用して毎秒 24フレームの映像を毎秒 6 0フレームの映像に変換したときの、各フレームの表示タイミングの関係を示す。毎秒 60フレームの映像は、 MPEG— 2規格に準拠したデータストリームとして記録媒体（ たとえばリムーバブル HDD)記録される。この図は、毎秒 60フレームの MPEG— 2ビ デォストリームに 3： 2プルダウンした場合を示す図 20に対応する。
[0253] 図 36 (a)に示す各フレームは、先頭から 3フィールド周期、 2フィールド周期、 3フィ 一ルド周期の順になるように 3 : 2プルダウンして記録される。例えば、最初の 3フィー ルド周期の区間は、最初の Bピクチャ（フレーム）のトップフィールド、ボトムフィールド 、トップフィールドの順に表示されるように記録される。次の Bピクチャは、ボトムフィー ルド、トップフィールドの順に表示されるように記録される。
[0254] フィールドを基準とする処理の他の例は、毎秒 25フレームの映像を 2： 2プルダウン 処理して記録する場合である。すなわち、毎秒 25フレームの映像中の 1フレームが、 毎秒 50フィールドの MPEG— 2ビデオストリーム中の 2フィールドとして符号化して記 録してちよい。
[0255] フィールドを基準とする処理のさらに他の例は、毎秒 30フレームの映像中の 1フレ ームを 2 : 2プルダウン処理して記録する場合である。すなわち、毎秒 30フレームの映 像中の 1フレームを、毎秒 60フィールドの MPEG— 2ビデオストリーム中の 2フィール ドとして符号ィ匕して記録してもよ 、。
[0256] 実施形態 2および 3では、先頭 3フレームフラグを記録するとした。しかし、開始タイ ムコード（300ο、 400ο)で参照されるピクチャを 3フレーム表示に対応させる力、 2フ レーム表示に対応させるかをあらかじめ決めておいてもよい。ただしこの場合、 ΜΡΕ Gストリームの編集後において、常に 3フレームに対応するように注意が必要になる。
[0257] 実施形態 2および 3では先頭 3フレームフラグは、開始タイムコードで参照されるピク チヤに関する情報であるとした。しかし、再生しない区間長（300r、 400r)分のピクチ ャだけスキップした、再生を開始すべきピクチャに関する情報であってもよい。さらに 、その再生開始ピクチヤの再生開始時刻（単位は PTM)および 24フレームでカウント するタイムコードを管理データとして保持してもよい。このとき、その再生開始ピクチャ の再生開始時刻およびそのタイムコードを基準として、タイムコード値から対応するピ クチャの記録アドレスを特定できる。
[0258] また実施形態 2および 3では、クリップ AVストリームの先頭 KPUは毎秒 60フレーム 中の 3フレーム表示に対応するフレームから始まり、その次には 2フレーム表示に対 応するフレームが続くとした。し力し、逆に毎秒 60フレーム中の 2フレーム分に対応す るフレームから始まり、次に 3フレーム表示に対応するフレームが続いてもよい。
[0259] なお発明の実施形態 2および 3では、先頭 3フレームフラグを記録し、さらに参照す るとした。し力し、例えばクリップ AVストリームの先頭 KPUのピクチャの top— field— f irstフラグを解析し、その値が 1であれば先頭 3フレームフラグ = 1と同等の処理を実 施し、その値が 0であれば先頭フレームフラグ =0と同等の処理を実施するとしてもよ い。
[0260] 3： 2プルダウンで記録される場合、ピクチャヘッダ内の top— field— first = 1のピク チヤは、そのピクチャが 3フレーム周期分表示され、 top— field— first =0のピクチャ は 2フレーム周期分表示されるからである。ただし、この場合、ピクチャのデータ解析 が必要となることに留意されたい。
[0261] また、毎秒 24フレームの映像を 3： 2プルダウン処理して、毎秒 60フレームの MPE G— 2ストリームを生成する場合も同様である。
[0262] 例えば、クリップ AVストリームの先頭 KPUのピクチャの repeat— first— fieldフラグ を解析し、その値が 1であれば、先頭 3フィールドフラグ = 1と同等の処理を実施し、 その値力 ^であれば、先頭フィールドフラグ =0と同等の処理を実施するとしてもよい 。 3 : 2プルダウンで記録される場合、ピクチャヘッダ内の repeat— first— field= lの ピクチャは、そのピクチャが 3フィールド周期分表示され、 repeat— first— field = 0 のピクチャは 2フィールド周期分表示されるからである。ただし、この場合も、ピクチャ のデータ解析が必要となる。
[0263] さらに、毎秒 24フレームの映像を 3： 2プルダウン処理して、毎秒 60フレームのストリ ームを生成するとき、タイムコードのフレーム番号が偶数の場合は 3フレーム、奇数の 場合は 2フレームなどと関連性を固定ィ匕してもよい。これにより先頭 3フレームフラグを 省略できる。
[0264] また、タイムコードのフレーム番号が 0、 4、 8、 12、 16、 20の場合は、トップフィール ド、ボトムフィールド、トップフィードの順に 3フィールド周期分表示し、フレーム番号が 1、 5、 9、 13、 17、 21の場合は、ボトムフィールド、トップフィールドの順に 2フィールド 周期表示する様に対応を固定ィ匕してもよい。このとき他のフレーム番号も同様に固定 化する必要がある。
[0265] なお、本発明の実施形態 2および 3では、再生時間長（300bおよび 400b)を Edit Unit単位で指定した力 AUTM単位であってもよい。両者は変換可能だからである 。また再生しない区間長（300r、および 400r)も同様に AUTM単位で指定すること ちでさる。
[0266] なお、実施形態 2および 3では、クリップ AVストリーム中の MPEG— 2トランスポート ストリームは連続しているものとした。つまり、 PTS、 DTS、 PCRは連続した STCに基 づいて付与されているものとした。また、毎秒 24フレームのタイムコードも連続して付 与されているものとした。
[0267] なお、実施形態 2および 3では、ドロップフレームフラグがオフであるものとしたが、 オンの設定となっていてもよい。オンとなっている場合でも、カウント値をスキップする ルールは決まっているので、オフの時とオンの時の間で変換は一意に可能だ力 で ある。
[0268] 実施形態 2および 3では、毎秒 24フレームのタイムコードは 00： 00： 00： 00力ら開 始される例を示したが、撮影開始時刻（時:分:秒：フレーム数)からスタートしてもよ!/ヽ し、また、 HDDにおける通し番号となる値力 スタートしてもよい。これらのタイムコー ドの初期値をユーザ力 Sカスタマイズする機能は、業務用カムコーダでは一般的である
[0269] 実施形態 2および 3では、 MPEG— 2ビデオストリームは、 KPUの先頭で Iピクチャ よりも 2枚の Bピクチャが先に再生される例を用いた。しかし、 KPUの先頭で Iピクチャ の方が先に再生されるように符号ィ匕してもょ 、。
[0270] 各実施形態では、データストリーム等を格納するメディアはリムーバブル HDDであ るとした。しかし、上述したファイルシステムによりファイルを管理するメディアであれば 、非可換メディア、例えばデータ処理装置に内蔵された HDDであってもよい。
[0271] 実施形態 1では、タイムマップ（ClipTimeLine)のデータ構造は、 TimeEntryおよ び KPUEntryの 2層を含むとした。しかし、再生時間と記録アドレスの変換が可能で あればこれに限る必要は一切なぐ KPUEntryの 1層のみからなるタイムマップであ つても全く同様である。上述の説明では、 OverlappedKPUFlagフィールドを設け、 その値に基づ 、てキービクチャユニット KPUが複数のファイルを跨って!/、ることを示 すとして説明した。しかし、複数のファイルを跨っている力否かは、タイムマップに相 当するデータが存在しない場合であっても表すことができる。例えば、クリップメタデ ータ（リレーション情報など）、クリップのファイル名の命名規則（ファイル名の番号が 昇順など）、同一フォルダ内に 1ショットの全データ（少なくとも 1ショットを構成する全 T TSファイルの内、同一記録媒体上に記録されたもの）を格納する等によって、 KPU が跨っている、または、跨っている可能性があることを示してもよい。
[0272] なお、図 2、図 22等の各機能ブロックは典型的には集積回路 (Large Scale Inte grated Circuit; LSI)のチップとして実現される。これらは個別に 1チップ化されて もよ 、し、一部または全てを含むように 1チップィ匕されてもょ 、。 [0273] 例えば、図 2においては、 CPU211を含むシステム制御部 250とメディア制御部 20 5とは別個の機能ブロックとして示されている。これらはそれぞれ別個の半導体チップ として実装されてもよいし、システム制御部 250にメディア制御部 205の機能を与え、 物理的に同一のチップによって実現してもよい。また、メディア制御部 205および TS 処理部 204の機能を集積ィ匕して、 1つのチップ回路として実現してもよいし、さらにェ ンコーダ 203およびデコーダ 206の機能を付カ卩したチップ回路 217として実現しても よい。ただし、例えば符号ィ匕または復号ィ匕の対象となるデータを格納するメモリのみ を集積化の対象から除外することにより、複数の符合化方式に容易に対応できる。
[0274] システム制御部 250は、プログラム ROM210等に格納されたコンピュータプロダラ ムを実行することにより、本明細書に記載したメディア制御部 205の機能を実現する ことができる。このときは、メディア制御部 205はシステム制御部 250の一部の機能と して実現される。
[0275] なお、上述の「LSI」は、集積度の違いにより、 IC、システム LSI、スーパー LSI、ゥ ルトラ LSIと呼称されることもある。集積回路化の手法は LSIに限るものではなぐ専 用回路又は汎用プロセサで実現してもよい。 LSI製造後に、プログラムすることが可 能な FPGA (Field Programmable Gate Array)や、 LSI内部の回路セルの接 続や設定を再構成可能なリコンフィギユラブル'プロセッサーを利用してもよい。
[0276] さらには、半導体技術の進歩又は派生する別技術により LSIに置き換わる集積回 路化の技術が登場すれば、その技術を用いて機能ブロックの集積ィ匕を行ってもよい 。例えば、バイオテクノロジーを利用したいわゆるバイオ素子として集積ィ匕を行っても よい。
[0277] なお、各実施形態にお!、て、記憶媒体はリムーバブル HDDであるものとした力 特 にこれに限定するものではない。例えば DVD—RAM、 MO、 DVD-R, DVD-R W、 DVD+RW、 CD-R, CD—RW等の光ディスクやハードディスク等の記録媒体 であってもよい。また、フラッシュメモリ、 FeRAM、 MRAM等の半導体メモリであって ちょい。
[0278] また、各実施形態において、クリップ AVストリームはトランスポートストリームを含む ものとしてが、プログラムストリームや PESストリーム等の他の符号化フォーマットに準 拠したマルチメディア情報を含むビットストリームであってもよい。
[0279] なお、各実施形態にお!、て、映像は MPEG— 2ビデオストリームを例とした力 MP EG— 4ビデオストリームや MPEG— 4AVCストリーム（H. 264ストリーム）であっても よい。また、音声もリニア PCMオーディオストリームや AC— 3ストリーム等であっても よい。
[0280] なお、各実施形態において、ストリームに対応するクリップタイムラインファイルに、 S tartSTCや StartKeySTCを記録するとした力 省略してもよい。省略するときは、再 生順で見たときの先頭のフレームのタイムコードを抽出してそのタイムコードを Start STCとして取り扱う。タイムコードを PTSに変換を実施してもよい。
[0281] なお、実施の形態 2および 3では主として 3： 2プルダウン処理の例を説明した力 プ ルダウン処理をしない場合（通常の 60フィールド、 50フィールド、 60フレーム、または 50フレーム記録時等）であっても、タイムコード値をプルダウン処理の例と同じデータ 位置に記録してもよい。
[0282] なお、実施の形態 2および 3では、 3： 2プルダウン処理をする場合に 3フレームの次 は 2フレーム、と繰り返した。し力し、たとえば 3フレーム、 2フレーム、 2フレームのよう に順序は適宜変更してもよい。ただし、このような順序を採用すると、ユーザから指定 されたタイムコードに対し、対応するピクチャを含む GOPへジャンプする際のアドレス 計算に支障が発生する。したがって、このような変則的な順序を採用していることを識 別するために、プルダウン情報 =Unknownであることをクリップメタデータファイル内 に記録してもよい。一方、プルダウン情報 = 3 : 2の場合は、その繰り返しの順序は一 切変更されな 、ことが望ま 、。
産業上の利用可能性
[0283] 本発明の処理により得られた映像データストリームによれば、毎秒 24フレームの映 像のうち、映像編集時に IN点 ZOUT点を決める際に、ユーザが INZOUT点を簡 易に指定できる。また、これを実現するために、動画の符号ィ匕の際に MPEGェンコ ーダとの間で通信量を増やす事なく実現可能であり、特別な MPEGエンコーダを使 用する必要がない。従って、 24フレーム Z秒の AVデータを扱う種々の機器、装置等 において有用である。

Claims

請求の範囲
[1] 複数のピクチャが第 1周波数で表示される第 1映像の信号を受け取る受信部と、 前記信号に基づいて、前記複数のピクチャが前記第 1周波数と異なる第 2周波数で 表示される第 2映像のデータストリームを生成するエンコーダと、
前記データストリームを記録媒体に記録する記録部と
を備えたデータ処理装置であって、
前記エンコーダは、前記複数のピクチャの各々に対応するピクチャデータと、第 1周 波数で表示されるときの表示時刻を示す第 1時刻情報と、第 2周波数で表示されると きの表示時刻を示す第 2時刻情報とを生成し、前記第 1時刻情報、前記第 2時刻情 報および前記第 1時刻情報に基づいて表示される各ピクチャのピクチャデータを対 応付けて格納し、前記データストリームを生成する、データ処理装置。
[2] 前記映像を再生するための管理情報を生成する制御部であって、前記管理情報と して、前記第 1周波数に対応する情報および前記第 2周波数に対応する情報を格納 したメタデータを生成する制御部をさらに備えた、請求項 1に記載のデータ処理装置
[3] 前記映像を再生するための管理情報を生成する制御部であって、前記管理情報に 、さらに前記第 1時刻情報を格納したメタデータを生成する制御部をさらに備えた、 請求項 2に記載のデータ処理装置。
[4] 前記エンコーダは、
1以上のピクチャに関する前記ピクチャデータ、前記第 1時刻情報および前記第 2 時刻情報を含む再生単位を生成し、
前記再生単位における前記ピクチヤについて、前記第 1時刻情報および第 2時刻 情報を生成する、請求項 1に記載のデータ処理装置。
[5] 前記エンコーダは、単独で復号ィ匕が可能な基準ピクチヤのデータ、前記基準ピクチ ャカもの復号ィ匕を要する 1以上の参照ピクチヤのデータ、前記第 1時刻情報および前 記第 2時刻情報を含む再生単位を生成し、
前記再生単位における少なくとも最初の前記基準ピクチヤに対して、前記第 1時刻 情報および第 2時刻情報を生成する、請求項 1に記載のデータ処理装置。 前記受信部は、毎秒 24枚のピクチヤが切り替えられて表示される第 1映像の信号を 受け取り、
前記エンコーダは、毎秒 60枚のピクチヤが切り替えられて表示される第 2映像のデ 一タストリームを生成する、請求項 1に記載のデータ処理装置。
PCT/JP2005/021025 2004-11-16 2005-11-16 データ処理装置 WO2006054590A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/719,318 US20090080509A1 (en) 2004-11-16 2005-11-16 Data processor

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2004-331515 2004-11-16
JP2004331515 2004-11-16
JP2005-149048 2005-05-23
JP2005149048A JP2008053763A (ja) 2004-11-16 2005-05-23 Ａｖデータ記録装置及び方法、ａｖデータ再生装置及び方法、当該ａｖデータ記録装置又は方法で記録された記録媒体

Publications (1)

Publication Number Publication Date
WO2006054590A1 true WO2006054590A1 (ja) 2006-05-26

Family

ID=36407131

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/021025 WO2006054590A1 (ja) 2004-11-16 2005-11-16 データ処理装置

Country Status (3)

Country Link
US (1) US20090080509A1 (ja)
JP (1) JP2008053763A (ja)
WO (1) WO2006054590A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2234392A1 (en) * 2008-01-07 2010-09-29 Kabushiki Kaisha Toshiba Material processing apparatus and material processing method
CN107835455A (zh) * 2017-11-07 2018-03-23 晶晨半导体(上海)股份有限公司 一种时钟频率的自动调节方法
CN110267053A (zh) * 2019-06-27 2019-09-20 广州酷狗计算机科技有限公司 直播方法、装置及系统

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101381476B1 (ko) * 2006-02-14 2014-04-10 삼성전자주식회사 디지털 방송 시스템에서 방송 서비스 정보를 수신하기 위한방법 및 장치
JP2012074756A (ja) * 2009-01-26 2012-04-12 Panasonic Corp 映像記録装置
JP2010245756A (ja) * 2009-04-03 2010-10-28 Victor Co Of Japan Ltd 通信ネットワークシステム、コンテンツ再生方法、及びサーバ
JP2010245754A (ja) * 2009-04-03 2010-10-28 Victor Co Of Japan Ltd 通信ネットワークシステム、コンテンツ再生方法、及びサーバ
JP2010245755A (ja) * 2009-04-03 2010-10-28 Victor Co Of Japan Ltd 通信ネットワークシステム、コンテンツ再生方法、及びサーバ
JP5375298B2 (ja) * 2009-04-16 2013-12-25 パナソニック株式会社 映像処理装置
JP5504761B2 (ja) * 2009-09-01 2014-05-28 富士通株式会社 受信装置、及びその使用方法
US9699431B2 (en) * 2010-02-10 2017-07-04 Satarii, Inc. Automatic tracking, recording, and teleprompting device using multimedia stream with video and digital slide
US9549196B2 (en) * 2014-02-04 2017-01-17 Microsoft Technology Licensing, Llc Data unit identification for compressed video streams
EP3288272A4 (en) * 2015-04-23 2018-09-12 LG Electronics Inc. Apparatus for transmitting broadcasting signal, apparatus for receiving broadcasting signal, method for transmitting broadcasting signal, and method for receiving broadcasting signal
AU2021303296A1 (en) * 2020-06-30 2023-02-02 Seff Technology Corporation System and method for digital information management
CN112188284B (zh) * 2020-10-23 2022-10-04 武汉长江通信智联技术有限公司 一种基于无线视频监控系统的客户端低延时平滑播放方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11155130A (ja) * 1997-09-17 1999-06-08 Matsushita Electric Ind Co Ltd 光ディスク、録画装置、プログラム記憶媒体
JP2000308022A (ja) * 1999-04-16 2000-11-02 Sony Corp 再生基準信号生成方法およびデータ受信装置
JP2002125192A (ja) * 2000-08-10 2002-04-26 Sony Corp ビデオ信号処理装置、ビデオ信号処理方法、ビデオデータ処理装置、ビデオデータ処理方法、ビデオデータ編集装置およびビデオデータ編集方法。
JP2004215143A (ja) * 2003-01-08 2004-07-29 Matsushita Electric Ind Co Ltd タイムコード情報変換装置およびタイムコード情報変換方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3443867B2 (ja) * 1992-06-26 2003-09-08 ソニー株式会社 画像信号符号化、復号化方法及び画像信号記録媒体
US5845303A (en) * 1994-12-06 1998-12-01 Netpodium, Inc. Document processing using frame-based templates with hierarchical tagging
US6385240B2 (en) * 1997-07-15 2002-05-07 Matsushita Electric Industrial Co, Ltd. Progressive image signal transmitter, progressive image signal receiver and, medium
GB2349288B (en) * 1999-04-16 2003-10-22 Quantel Ltd A video editing system
KR100831768B1 (ko) * 2000-02-04 2008-05-27 리슨.컴 .인크. 매체 데이터 획득 방법, 분산 매체 네트워크 및 메타 데이타 서버를 위한 시스템
US7058130B2 (en) * 2000-12-11 2006-06-06 Sony Corporation Scene change detection
WO2005076576A2 (en) * 2004-02-03 2005-08-18 Sandisk Secure Content Solutions, Inc. Protection of digital data content
US20060109899A1 (en) * 2004-11-24 2006-05-25 Joshua Kablotsky Video data encoder employing telecine detection

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11155130A (ja) * 1997-09-17 1999-06-08 Matsushita Electric Ind Co Ltd 光ディスク、録画装置、プログラム記憶媒体
JP2000308022A (ja) * 1999-04-16 2000-11-02 Sony Corp 再生基準信号生成方法およびデータ受信装置
JP2002125192A (ja) * 2000-08-10 2002-04-26 Sony Corp ビデオ信号処理装置、ビデオ信号処理方法、ビデオデータ処理装置、ビデオデータ処理方法、ビデオデータ編集装置およびビデオデータ編集方法。
JP2004215143A (ja) * 2003-01-08 2004-07-29 Matsushita Electric Ind Co Ltd タイムコード情報変換装置およびタイムコード情報変換方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2234392A1 (en) * 2008-01-07 2010-09-29 Kabushiki Kaisha Toshiba Material processing apparatus and material processing method
EP2234392A4 (en) * 2008-01-07 2011-11-30 Toshiba Kk MATERIAL PROCESSING APPARATUS AND MATERIAL PROCESSING METHOD
CN107835455A (zh) * 2017-11-07 2018-03-23 晶晨半导体(上海)股份有限公司 一种时钟频率的自动调节方法
CN110267053A (zh) * 2019-06-27 2019-09-20 广州酷狗计算机科技有限公司 直播方法、装置及系统

Also Published As

Publication number Publication date
US20090080509A1 (en) 2009-03-26
JP2008053763A (ja) 2008-03-06

Similar Documents

Publication Publication Date Title
WO2006054590A1 (ja) データ処理装置
US6122436A (en) Optical disc, optical disc recording method and apparatus, and optical disc reproducing method and apparatus
WO2006033279A1 (ja) データ処理装置
JP4299836B2 (ja) データ処理装置
JP4479968B2 (ja) 情報記録媒体、データ分別装置、データ再生装置及び記録方法
JP4481991B2 (ja) 情報記録媒体、データ分別装置、データ再生装置及び記録方法
JP4527164B2 (ja) 記録媒体、記録装置、及び再生装置
US20080301380A1 (en) Data Processor
JPWO2002080541A1 (ja) Ａｖデータ記録再生装置及び方法、当該ａｖデータ記録再生装置又は方法で記録されたディスク
JP2000041212A (ja) 光ディスク、記録装置および方法、並びに再生装置および方法
US8824864B2 (en) Data processor
JPWO2005015907A1 (ja) データ処理装置
US20100142929A1 (en) Recording device and reproduction device
WO2006088100A1 (ja) データ処理装置
JP4284073B2 (ja) Ａｖデータ記録再生装置及び方法、並びに当該ａｖデータ記録再生装置又は方法で記録された記録媒体
JP3986973B2 (ja) Ａｖデータ記録方法、ａｖデータ記録装置、データ記録媒体、及びプログラム
JP3901555B2 (ja) Ａｖデータ記録装置及び方法、当該ａｖデータ記録装置又は方法で記録されたディスク、並びに当該ディスクを再生するａｖデータ再生装置及び方法又はａｖデータ記録再生装置及び方法
JP2004005934A (ja) 記録媒体、記録装置、再生装置、記録方法、再生方法、及びプログラム
US20060153540A1 (en) Data stream reocrding method and device
JP2006140992A (ja) データ処理装置
JP2002152666A (ja) チャプタ作成ガイド機能付き記録再生装置
JP2004088267A (ja) データ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録のためのプログラムおよびそのプログラムを記録した記録媒体
WO2004032501A1 (ja) 情報再生装置及び方法、並びに情報再生プログラム

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 11719318

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05807013

Country of ref document: EP

Kind code of ref document: A1