WO2001082605A1 - Encoding device and method, recorded medium, and program - Google Patents

Encoding device and method, recorded medium, and program Download PDF

Info

Publication number
WO2001082605A1
WO2001082605A1 PCT/JP2001/003412 JP0103412W WO0182605A1 WO 2001082605 A1 WO2001082605 A1 WO 2001082605A1 JP 0103412 W JP0103412 W JP 0103412W WO 0182605 A1 WO0182605 A1 WO 0182605A1
Authority
WO
WIPO (PCT)
Prior art keywords
stream
time
encoding
video data
data
Prior art date
Application number
PCT/JP2001/003412
Other languages
English (en)
French (fr)
Inventor
Motoki Kato
Toshiya Hamada
Original Assignee
Sony Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corporation filed Critical Sony Corporation
Priority to US10/018,836 priority Critical patent/US7236687B2/en
Priority to EP01921962A priority patent/EP1198132A4/en
Priority to MXPA01013110A priority patent/MXPA01013110A/es
Publication of WO2001082605A1 publication Critical patent/WO2001082605A1/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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • 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/036—Insert-editing
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • 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/30—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 the same track as the main recording
    • G11B27/3027—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 the same track as the main recording used signal is digitally coded
    • 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]
    • 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/34—Indicating arrangements 
    • 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/36—Monitoring, i.e. supervising the progress of recording or reproducing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/127—Prioritisation of hardware or computational resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H04N19/15—Data rate or code amount at the encoder output by monitoring actual compressed data size at the memory before deciding storage at the transmission buffer
    • 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/21—Disc-shaped record carriers characterised in that the disc is of read-only, rewritable, or recordable type
    • G11B2220/213—Read-only discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2545—CDs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • 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/7921—Processing of colour television signals in connection with recording for more than one processing mode

Definitions

  • the present invention relates to an encoding device and method, a recording medium, and a program, and in particular, stores management information of data content recorded on a recording medium as a file.
  • the present invention relates to an encoding device and method for recording data, a recording medium, and a program.
  • the digital video signals supplied from these sources are generally subjected to image compression by the MPEG (Moving Picture Experts Group) 2 system.
  • a recording rate specific to the recording apparatus is defined.
  • the digital video signals are decoded and then recorded with limited bandwidth.
  • a digital recording system such as the MPEG 1 Video, MPEG 2 Video, or DV system, after being decoded once, it is re-encoded at a recording rate and encoding system specific to the device, and recorded. It is.
  • the supplied bit stream is decoded once, and then subjected to band limitation and re-encoding, and is recorded.
  • the supplied bit stream can be decoded without re-encoding.
  • the method of recording as it is has the least deterioration in image quality.
  • the transmission rate of the image-compressed digital signal exceeds the recording rate of the disc as the recording medium, the transmission rate will be lower than the upper limit of the disc recording rate after decoding by the recording / reproducing device. At the same time, it is necessary to record again.
  • the recording rate is fixed because the rotating head has a fixed number of rotations.
  • a disk recording device capable of storing data in a buffer once and recording in a burst can utilize the capacity of the recording medium more efficiently.
  • broadcast signals can be recorded as digital signals without decoding or re-encoding as in the case of data streams, and recording using discs as recording media It is expected that a playback device will be required.
  • an object of the present invention is to create a file of management information of the contents of data recorded on a recording medium and record the data, so that the data recorded on the recording medium can be recorded. To be able to properly manage evening content and playback information It is in.
  • An encoding device includes an encoder that encodes video data at a variable rate, and a control unit that controls the amount of video encoded data to be approximately proportional to the time elapsed.
  • the control unit can control so as to encode the scanning bytes when the amount of video encoded data generated per unit time is less than a predetermined amount.
  • the control unit can determine whether or not to encode the sparing bytes according to the amount of data generated at the time of encoding each picture.
  • the control unit can control to encode the stuffing byte so that the VBV buffer does not overflow.
  • the control unit can perform control so as to perform encoding in one of the encoding mode in which the encoded data amount is substantially proportional to the passage of time and the ordinary encoding mode.
  • the control unit can generate additional information indicating whether or not the encoding mode is a mode in which encoding is performed so that the amount of encoded data is approximately proportional to time.
  • An encoding method includes an encoding step of encoding video data at a variable rate, and a control step of controlling the amount of encoded video data to be substantially proportional to time.
  • the program of the recording medium according to the present invention includes an encoding step of encoding video data at a variable rate, and a control step of controlling the amount of video encoded data to be substantially proportional to the passage of time.
  • a program according to the present invention executes an encoding step of encoding video data at a variable rate, and a control step of controlling the amount of video encoded data to be approximately proportional to the passage of time. .
  • video data is encoded at a variable rate, and the amount of encoded video data is controlled so as to be approximately proportional to time.
  • a recording medium includes a video data, an AV stream file including audio data corresponding to the video data, and a recording mode of the AV stream file. Are recorded.
  • the flag can be time_control led_flag.
  • the flag may indicate that the mode is such that the file size is recorded in such a manner that the file size is proportional to the elapsed time from the recording.
  • video data an AV stream file including an audio stream corresponding to the video stream, and a flag indicating a recording mode of the AV stream file are recorded.
  • FIG. 1 is a diagram showing a configuration of a recording / reproducing apparatus to which the present invention is applied.
  • FIG. 2 is a diagram for explaining the format of data recorded on a recording medium by the recording / reproducing apparatus 1.
  • FIG. 3 is a diagram illustrating the Real PlayList and the Virtual PlayList.
  • 4A to 4C are diagrams for explaining creation of a Real PlayList.
  • FIGS. 5A to 5C are diagrams illustrating the deletion of the Real PlayList.
  • 6 and 6B are diagrams for explaining assemble editing.
  • FIG. 7 is a diagram illustrating a case where a sub path is provided in the Virtual PlayList.
  • C is a diagram illustrating a change in the playback order of the PlayList.
  • FIG. 9 is a diagram illustrating marks on the PlayList and marks on the Clip.
  • FIG. 10 is a diagram illustrating menu thumbnails.
  • FIG. 11 is a diagram illustrating marks added to the PlayList.
  • FIG. 12 is a diagram for explaining a mark added to a clip.
  • FIG. 13 is a diagram for explaining the relationship between PlayList, Clip, and thumbnail files.
  • FIG. 14 is a diagram illustrating a directory structure.
  • FIG. 15 is a diagram illustrating the syntax of info.dvr.
  • FIG. 16 is a diagram illustrating the syntax of the DVR volume.
  • FIG. 17 is a diagram illustrating the syntax of Resumevolume.
  • FIG. 18 is a diagram illustrating the syntax of UIAppInfovolume.
  • FIG. 19 is a diagram showing a table of Character set value.
  • FIG. 20 is a diagram illustrating the syntax of TableOfPlayList.
  • FIG. 21 is a diagram illustrating another syntax of the TableOfPlayList.
  • FIG. 22 is a diagram illustrating the syntax of MakersPrivateData.
  • FIG. 23 is a diagram illustrating the syntax of xxxxx. Rpls and yyyyy.vpls.
  • FIGS. 24A to 24C are diagrams illustrating PlayList.
  • FIG. 25 is a diagram illustrating the syntax of PlayList.
  • FIG. 26 is a diagram showing the PlayList_type table.
  • FIG. 27 is a diagram illustrating the syntax of UIAppinfoPlayList.
  • FIGS. 28A to 28C are diagrams illustrating flags in the syntax of UIAppinfoPlayList shown in FIG. 27.
  • FIG. 29 is a diagram illustrating Playltem.
  • FIG. 30 is a diagram illustrating Playltem.
  • FIG. 31 is a diagram illustrating Playltem.
  • FIG. 32 is a diagram showing Playltem syntax.
  • FIG. 33 is a diagram for explaining IN_time.
  • FIG. 34 is a view for explaining 0UT_time.
  • FIG. 35 shows a table of Connection One Condition.
  • FIG. 36A to FIG. 36D are diagrams illustrating Connection-Condition.
  • FIG. 37 is a view for explaining BridgeSequencelnfo.
  • FIG. 38 is a diagram illustrating the syntax of BridgeSequencelnfo.
  • FIG. 39 is a view for explaining SubPlayltem.
  • FIG. 40 is a diagram illustrating the syntax of SubPlayltem.
  • FIG. 41 is a diagram showing a table of SubPath_type.
  • FIG. 42 is a diagram illustrating the syntax of PlayListMark.
  • FIG. 43 is a diagram showing a table of the Mark type.
  • FIG. 44 is a diagram for explaining Mark_time_staiiip.
  • FIG. 45 is a diagram illustrating the syntax of zzzzz.clip.
  • FIG. 46 is a diagram illustrating the syntax of Cl iplnfo.
  • FIG. 47 is a diagram showing a table of Clip_stream_type.
  • FIG. 48 is a view for explaining offset_SPN.
  • FIG. 49 is a view for explaining offset_SPN.
  • FIGS. 50A and 50B are diagrams illustrating the STC section.
  • FIG. 51 is a diagram for describing STC_Info.
  • FIG. 52 is a diagram illustrating the syntax of STC_Info.
  • FIG. 53 is a diagram for explaining Programlnfo.
  • FIG. 54 is a diagram showing the syntax of Programlnfo.
  • FIG. 55 is a diagram illustrating the syntax of VideoCondinglnfo.
  • FIG. 56 shows a table of Video_format.
  • FIG. 57 is a diagram showing a table of frame_rate.
  • FIG. 58 is a diagram showing a table of display_aspect-ratio.
  • FIG. 59 is a diagram illustrating the syntax of AudioCondinglnfo.
  • FIG. 60 is a diagram showing an audio-coding table.
  • FIG. 61 is a diagram showing an audio-component-one type table.
  • FIG. 62 is a diagram showing a table of sampling_frequency.
  • FIG. 63 is a diagram illustrating the CPI.
  • FIG. 64 is a diagram illustrating the CPI.
  • Figure 65 is a diagram showing the syntax of CPI.
  • FIG. 66 is a diagram showing a table of CPI_type.
  • FIG. 67 is a view for explaining the video EP_map.
  • FIG. 68 is a view for explaining EPjnap.
  • FIG. 69 is a view for explaining the EP-one map.
  • FIG. 70 is a diagram illustrating the syntax of the EP_map.
  • FIG. 71 is a diagram showing a table of EP_type values.
  • FIG. 72 is a diagram illustrating the syntax of the EP map_for_one stream PID.
  • FIG. 73 is a view for explaining TlLmap.
  • FIG. 74 is a diagram illustrating the syntax of TUjnap.
  • FIG. 75 is a diagram showing the syntax of ClipMark.
  • FIG. 76 is a diagram showing a table of mark_type.
  • FIG. 77 is a diagram illustrating a table of mark—type_stamp.
  • Fig. 78 is a diagram showing the syntax of menu.thmb and mark.thmb.
  • FIG. 79 is a diagram illustrating the syntax of Thumbnails.
  • FIG. 80 is a diagram showing a table of thumb_picture_format.
  • FIG. 81A and FIG. 8IB are diagrams illustrating tn_block.
  • FIG. 82 is a view for explaining the structure of a DVR MPEG-2 transport stream.
  • FIG. 83 is a diagram illustrating a recorder model of a DVR MPEG-2 transport stream.
  • FIG. 84 is a diagram showing a player model of a transport stream of DVR MPEG2.
  • FIG. 85 is a diagram illustrating the syntax of the source packet.
  • FIG. 86 is a diagram illustrating the syntax of TP_extra_header.
  • FIG. 87 is a diagram showing a table of the copy permission indicator.
  • FIG. 88 is a diagram illustrating seamless connection.
  • FIG. 89 illustrates the seamless connection.
  • FIG. 90 is a diagram for explaining a seamless connection.
  • FIG. 91 is a diagram illustrating seamless connection.
  • Fig. 92 illustrates the seamless connection.
  • FIG. 93 is a diagram illustrating audio overlap.
  • FIG. 94 is a diagram illustrating a seamless connection using BridgeSequence.
  • C FIG. 95 is a diagram illustrating a seamless connection without using BridgeSequence.
  • FIG. 96 is a diagram showing a DVR STD model.
  • FIG. 97 is a diagram showing an evening chart for decoding and displaying.
  • FIG. 98 is a diagram illustrating the operation of the AV encoder in FIG.
  • FIG. 99 is a flowchart illustrating an operation of recording a video stream by encoding a video at a variable bit rate.
  • FIG. 100 is a diagram for explaining the Video Buffering Verifier.
  • FIG. 101 is a diagram for explaining VBV control.
  • FIG. 102 is a diagram illustrating VBV control.
  • FIG. 103 is a diagram illustrating an example of a case where a variable bit rate is controlled.
  • FIG. 104 is a diagram showing an example of variable bit rate control.
  • FIG. 105 is a flowchart illustrating details of step S21 in FIG.
  • FIG. 106 is a flowchart for explaining the details of step S205 in FIG. 106.
  • FIG. 107 is a view for explaining the relationship between the elapsed time of the AV stream and the amount of data bytes of the AV stream.
  • FIG. 108 is a flowchart illustrating an operation of recording a video stream by encoding a video at a variable bit rate.
  • FIG. 109 is a flowchart illustrating details of step S ⁇ b> 400 in FIG. 108.
  • FIG. 110 is a flowchart illustrating an encoding mode that guarantees that the relationship between the time lapse of the A stream and the amount of data bytes of the AV stream is proportional.
  • FIG. 11 is a diagram illustrating an example of minimizing operation.
  • FIG. 112 is a diagram showing an example of deleting unnecessary stream data before IN 1 time at the time of minimizing.
  • FIG. 13 is a diagram showing an example of deleting unnecessary stream data after 0UT_time at the time of minimization.
  • FIG. 114 is a flowchart showing an operation example of creating an EPjiiap.
  • FIG. 115 illustrates the medium.
  • BEST MODE FOR CARRYING OUT THE INVENTION an encoding device and method, a recording medium, and a program to which the present invention is applied will be described with reference to the drawings.
  • FIG. 1 is a diagram showing an example of the internal configuration of a recording / reproducing apparatus 1 to which the present invention is applied. First, the configuration of a part that performs an operation of recording an externally input signal on a recording medium will be described.
  • the recording / reproducing device 1 can input and record analog data or digital data.
  • Terminal 11 receives analog video signals, and terminal 12 receives analog audio signals.
  • the video signal input to terminal 11 is output to analyzer 14 and AV encoder 15 respectively.
  • the audio signal input to the terminal 12 is output to the AV encoder 15.
  • the analysis unit 14 extracts a feature point such as a scene change from the input video signal.
  • the AV encoder 15 encodes the input video signal and audio signal, and encodes the encoded video stream (V), the encoded audio stream (A), and system information (S) such as AV synchronization into the multiplexer 1. Output to 6.
  • the coded video stream is, for example, a video stream coded according to the MPEG (Moving Picture Expert Group) 2 method.
  • the coded audio stream is, for example, an audio stream coded according to the MPEG 1 method, It is an audio stream or the like encoded by the Dolby AC 3 system.
  • the multiplexer 16 multiplexes the input video and audio streams based on the input system information, and outputs the multiplexed stream to the multiplexed stream analyzer 18 and the source packetizer 19 via the switch 17. .
  • the multiplexed stream is, for example, an MPEG 2 transport stream or an MPEG 2 program stream.
  • the source packetizer 19 encodes the input multiplexed stream into an AV stream composed of source packets in accordance with an application format of a recording medium 100 for recording the stream.
  • the AV stream is subjected to predetermined processing in an ECC (error correction) encoding unit 20 and a modulation unit 21, and is output to a writing unit 22.
  • the writing unit 22 writes (records) the AV stream file on the recording medium 100 based on the control signal output from the control unit 23.
  • a transport stream such as a digital television broadcast input from a digital television interface or a digital television tuner is input to terminal 13.
  • the instruction information of the recording method is input to the control section 23 from the terminal 24 as a user interface.
  • the transport stream input to the terminal 13 is output to the multiplexed stream analyzer 18 and the source packetizer 19.
  • the subsequent processing until the AV stream is recorded on the recording medium 100 is the same as the above-described processing in which the input audio permeation and the video signal are encoded and recorded, and a description thereof will be omitted.
  • the transport stream input to terminal 13 is input to demultiplexer 26.
  • the demultiplexer 26 performs demultiplex processing on the input transport stream to extract a video stream (V), an audio stream (A), and system information (S).
  • the video stream is output to the AV decoder 27, and the audio stream and system information are output to the multiplexer 16 respectively.
  • the AV decoder 27 decodes the input video stream and outputs the reproduced video signal to the AV encoder 15.
  • the AV encoder 15 encodes the input video signal and outputs an encoded video stream (V) to the multiplexer 16.
  • the audio stream and system information output from the demultiplexer 26 and input to the multiplexer 16 and the video stream output from the AV encoder 15 are multiplexed and multiplexed based on the input system information.
  • the multiplexed stream is output to the multiplexed stream analyzer 18 and the source packet analyzer 19 via the switch 11.
  • the subsequent processing until the AV stream is recorded on the recording medium 100 is performed by encoding the input audio signal and the video signal described above. Since this is the same process as when recording, the description is omitted.
  • the recording / reproducing apparatus 1 of the present example records an AV stream file on the recording medium 100, and also records application data pace information describing the file.
  • the application base information is created by the control unit 23.
  • the input information to the control unit 23 includes the moving image feature information from the analysis unit 14, the AV stream feature information from the multiplexed stream analysis unit 18, and the user input from the terminal 24. This is the instruction information from.
  • the moving image feature information supplied from the analysis unit 14 is information relating to a characteristic image in the input moving image signal. For example, a program start point, a scene change point, and a commercial (CM) start 'Specified information (mark) such as the end point, and also includes information on the thumbnail image of the image at the specified location.
  • CM commercial start 'Specified information
  • the characteristic information of the AV stream from the multiplexing stream analyzer 18 is information related to the encoded information of the AV stream to be recorded. For example, address information of an I picture in the AV stream, The information includes coding parameters of the AV stream, information on the changing points of the coding parameters in the AV stream, and information (marks) related to characteristic images in the video stream. .
  • the user's instruction information from the terminal 24 includes, in the AV stream, specification information of a reproduction section specified by the user, one character describing the contents of the reproduction section, and a bookmark for setting the user's favorite scene. This is information on the resume point.
  • the control unit 23 controls the data pace of the AV stream (Gip).
  • the application database information composed of these pieces of information is processed by the ECC encoding unit 20 and the modulation unit 21 in the same manner as the AV stream, and is input to the writing unit 22.
  • the writing unit 22 records a database file on the recording medium 100 based on the control signal output from the control unit 23. c
  • the details of the application database information described above will be described later.
  • the control unit 23 instructs the reading unit 28 to read the ablation database information from the recording medium 100.
  • the reading unit 28 reads the application database information from the recording medium 100, and the application database information is processed by the demodulation unit 29 and the ECC decoding unit 30, and then is read by the control unit 23. Is input to
  • the control unit 23 outputs a list of PlayLists recorded on the recording medium 100 to the user terminal of the terminal 24 based on the application data base information.
  • the user selects a PlayList to be reproduced from the list of PlayLists, and information relating to the PlayList designated to be reproduced is input to the control unit 23.
  • the control unit 23 instructs the reading unit 28 to read an AV stream file necessary for reproducing the Play List.
  • the reading unit 28 reads the corresponding AV stream from the recording medium 100 according to the instruction, and outputs it to the demodulation unit 29.
  • the AV stream input to the demodulation unit 29 is demodulated by performing predetermined processing, and is further output to the source depacketizer 31 through the processing of the ECC decoding unit 30.
  • the source depacketizer 31 converts an application format AV stream read from the recording medium 100 and subjected to predetermined processing into a stream that can be output to the demultiplexer 26.
  • the demultiplexer 26 includes a video stream (V), an audio stream (A), and system information (such as AV synchronization) constituting a playback section (Playltem) of the AV stream specified by the control section 23.
  • S is output to the AV decoder 27.
  • the AV decoder 27 decodes the video stream and the audio stream, and outputs the reproduced video signal and the reproduced audio signal from the corresponding terminals 32 and 33, respectively.
  • the control unit 23 when information for instructing random access playback or special playback is input from the terminal 24 as a user interface, the control unit 23 performs processing based on the contents of the AV stream data base (Cl ip). Then, it determines the reading position of the AV stream from the storage medium 100 and instructs the reading unit 28 to read the AV stream. For example, when the PlayList selected by the user is reproduced from a predetermined time, the control unit 23 reads the data from the I picture having the time stamp closest to the specified time so as to read the data from the I picture. Instruct 8 Also, when fast-forward playback is instructed by the user, the control unit 23 sets the I-picture data in the AV stream on the basis of the AV stream data base (Cl ip).
  • the reading unit 28 is instructed to read data continuously and sequentially.
  • the reading unit 28 reads the data of the AV stream from the designated random access point, and the read data is reproduced through the processing of each unit at the subsequent stage.
  • the user edits the AV stream recorded on the recording medium 100 will be described.
  • the control unit 23 creates a data base of a playback section (PlayList) of the AV stream grouped (PlayList).
  • the control unit 23 changes the data rate of the PlayList so as to refer to only the necessary AV stream portion. Also, it instructs the writing section 22 to delete unnecessary stream portions of the AV stream.
  • control unit 23 creates a data base of a group (PlayList) of the playback section (Playltem) of the AV stream, and furthermore, creates a partial stream of the video stream near the connection point of the playback section. Re-encoding and re-multiplexing.
  • information on the picture at the in-point of the playback section and information on the picture at the out-point are input to the control unit 23 from the terminal 24.
  • the control unit 23 instructs the reading unit 28 to read out the data necessary for reproducing the picture on the in-point side and the picture on the art point side.
  • the reading unit 28 reads out the data from the recording medium 100, and the data is passed through the demodulation unit 29, the ECC decoding unit 30, the source depacketizer 31, and Output to chipplexer 26.
  • the control unit 23 analyzes the data input to the demultiplexer 26, and re-encodes the video stream (change of picture-coding-type, allocation of the number of coded bits to be re-encoded), and re-encoding.
  • the multiplexing method is determined, and the multiplexing method is supplied to the AV encoder 15 and the multiplexer 16.
  • the demultiplexer 26 separates the input stream into a video stream (V), an audio stream (A), and system information (S).
  • the video stream includes "data input to the AV decoder 27" and "data input to the multiplexer 16".
  • the former data is necessary for re-encoding, and is decoded by the AV decoder 27, and the decoded picture is re-encoded by the AV encoder 15 to be a video stream.
  • the latter data is data that is copied from the original stream without re-encoding. Audio streams and system information are input directly to the multiplexer 16.
  • the multiplexer 16 multiplexes the input stream based on the information input from the control unit 23, and outputs a multiplexed stream.
  • the multiplexed stream is processed by the ECC encoder 20 and the modulator 21 and input to the writer 22.
  • the writing unit 22 records the AV stream on the recording medium 100 based on the control signal supplied from the control unit 23.
  • FIG. 2 is a diagram illustrating the structure of the application format.
  • the application format has two layers, PlayList and Clip, for AV stream management.
  • Volume Information manages all Clips and PlayLists on the disc.
  • a pair of one AV stream and its attached information is considered as one object, and it is called Clip.
  • the AV stream file is called Cl ip AV stream file, and its additional information is called Cl ip Info rmation: i le.
  • One Clip AV stream file stores the MPEG-2 transport stream arranged in a structure specified by the application format. Generally, the file is treated as a byte sequence, but the contents of the Cl ip AV stream file are expanded on the time axis, and the entry points in the Cl ip are mainly specified on a time basis. Is done. When a given stamp of the access point to the Cl ip is given, the Cl ip Information file is used to find the address information to start the data read in the Cl ip AV stream file. Useful.
  • the PlayList will be described with reference to FIG.
  • the PlayList is provided so that the user can select a playback section from the Clip and easily edit it.
  • One PlayList is a group of playback sections in the Clip.
  • One playback section in a given Clip is called a Playltem, which is represented by a pair of an in point (IN) and an out point (OUT) on the time axis. Therefore, the PlayList is configured by collecting a plurality of Playltems.
  • PlayList has two types. One is Real PlayList and the other is Virtual PlayList. Real PlayList shares the stream portion of the Clip it references. That is, the Real PlayList occupies the data capacity corresponding to the stream portion of the C Lip referenced by the disk in the disk, and when the Real PlayList is erased, The stream portion is also deleted.
  • FIG. 4A is a diagram related to the creation of a Real PlayList. When an AV stream is recorded as a new Clip, a Real PlayList that refers to the entire Clip is newly created. is there.
  • FIG. 4B is a diagram relating to the division of the Real PlayList, and is an operation in which the Rea 1 PlayList is divided at desired points and divided into two Real PlayLists. This division operation is performed, for example, when two programs are managed in one clip managed by one PlayList, and the user re-registers (records) each program as one program. This is done when you want to. This operation does not change the contents of Cl ip (the Cl ip itself is divided).
  • FIG. 4C is a diagram relating to a combine of Real PlayLists, and is an operation of combining two Real PlayLists into one new Real PlayList. This operation of combining is performed, for example, when the user wants to reregister two programs as one program. This operation does not change Cl ip (Cl ip itself becomes one).
  • FIG. 5A is a diagram relating to the deletion of the entire Real PlayList.
  • the corresponding stream of the Clip referenced by the deleted Real PlayList is referred to.
  • the part is also deleted.
  • FIG. 5B is a diagram relating to the partial deletion of the Real PlayList.
  • the corresponding Playltem is changed so as to refer to only the necessary Clip stream portion. .
  • the corresponding stream portion of Clip is deleted.
  • FIG. 5C is a diagram related to minimization of the Real PlayList, in which the Playltem corresponding to the Real PlayList is referred to only the stream portion of the Clip required for the Virtual PlayList. .
  • the corresponding stream portion of the Clip that is unnecessary for the Virtual PlayList is deleted.
  • the user is informed that the operation “delete” includes a request that “a Virtual PlayList that refers to the stream portion of the Clip referenced by the Real PlayList exists.
  • the Real PlayList is deleted, the Virtual Play List will also be deleted. Is this OK? ”, Prompting confirmation (warning), and then prompting the user to confirm. Execute or cancel the deletion process.
  • the minimizing operation is performed on the Real PlayList.
  • FIG. 6 shows This is a diagram related to assemble editing (IN-OUT editing). This operation is performed when a user creates a Playltem for a desired playback section and creates a Virtual PlayList. Seamless connection between Playlteni is supported by the application format (described later).
  • FIG. 6A when there are two Real PlayLists 1 and 2 and Clips 1 and 2 corresponding to the respective RealPlayLists, the user can enter a predetermined section (In 1 Section from Play 1 to Out 1: Playltem 1) is designated as a playback section, and as a section to be continuously played, a predetermined section in the Real PlayList2 (section from In2 to 0ut2: Playltem2) is designated as a playback section.
  • a predetermined section in the Real PlayList2 section from In2 to 0ut2: Playltem2
  • FIG. 6B one Virtual PlayList composed of Playltem 1 and Playltem 2 is created.
  • Re-editing includes changing the In and Out points in the Virtual PlayList, inserting and adding a new Playltem to the Virtual PlayList, and removing the Playltem in the Virtual PlayList. Also, the Virtual PlayList itself can be deleted.
  • FIG. 7 is a diagram related to audio dubbing (audio dubbing) to a Virtual PlayList, and refers to an operation of registering an audio dubbing to a Virtual PlayList as a sub path. This audio dubbing is done by application format. An additional audio stream is added as a sub path to the AV stream on the main path of the Virtual PlayList.
  • This operation is a change in the playback order of the PlayList in the disc (volume), and is supported by the Table Of PlayList (described later with reference to FIG. 20, etc.) defined in the application format. This operation does not change the contents of the Clip.
  • Marks are provided to specify highlights and characteristic times in Clips and PlayLists.
  • the mark added to the Clip designates a characteristic scene caused by the content of the AV stream, for example, a scene change point.
  • the PlayList references You can use it by referring to the Cl mark.
  • the mark added to the PlayList is mainly set by the user, for example, a bookmark mark point.
  • Setting a mark in Clip or PlayList is performed by adding a time stamp indicating the time of the mark to the mark list. Deleting a mark means removing the time stamp of the mark from the mark list. Therefore, the AV stream is not changed by setting or deleting the mark.
  • the thumbnail is a still image added to Volume, PlayList, and Clip.
  • a representative image of Volume is a disc (the recording medium 100, hereinafter, the recording medium 100 is assumed to be disc-shaped, and is appropriately described as a disc) set at a predetermined location of the recording / reproducing apparatus 1. It is supposed to be used when displaying a still image representing the contents of the disc first. It is assumed that the representative image of Playlist is used as a still image for representing the contents of Playlist on a menu screen for selecting Playlist.
  • the first picture of Playlist As a representative picture of Playlist, it is conceivable to use the first picture of Playlist as a thumbnail (representative picture), but the first picture at playback time 0 is not necessarily the most suitable picture for representing the content. Therefore, the user can set an arbitrary image as the thumbnail of Playlist.
  • the above two types of thumbnails are called menu thumbnails. Since menu thumbnails are displayed frequently, they need to be read from the disk at high speed. For this reason, it is efficient to store all menu thumbnails in one file.
  • the menu thumbnail does not necessarily need to be a picture extracted from a video in the volume, but may be an image captured from a personal computer or a digital still camera as shown in FIG.
  • Clip and Playlist must be marked with multiple marks, It is necessary to be able to easily see the image of the mark point in order to know the contents of the mark.
  • a picture representing such a mark point is called a mark thumbnail (Mark Thumbnails). Therefore, the image that is the source of the thumbnail is mainly an image extracted from the mark point, rather than an image imported from outside.
  • FIG. 11 is a diagram showing the relationship between the mark attached to the PlayList and the mark thumbnail
  • FIG. 12 is a diagram showing the relationship between the mark attached to the Clip and the maximum thumbnail.
  • mark thumbnails are used in submenus and the like to indicate details of Playlist, so mark thumbnails are not required to be read in a short access time. Therefore, it does not matter if the recording / reproducing apparatus 1 opens the file each time a thumbnail is needed and reads a part of the file, which takes some time. .
  • Playlist can have one menu thumbnail and multiple mark thumbnails, but there is no need to provide a menu thumbnail since CI ip does not need to be directly selected by the user (usually specified via Playlist).
  • FIG. 13 is a diagram showing a relationship between a menu thumbnail, a mark thumbnail, a PlayList, and a Clip in consideration of the above.
  • the menu thumbnail file menu thumbnails provided for each PlayList are stored.
  • the menu thumbnail file contains a volume thumbnail representing the contents of the data recorded on the disc.
  • the mark thumbnail file contains thumbnails created for each PlayList and each Clip.
  • CPI Charge Point Information
  • the CPI is the data contained in the Clip information file. It is mainly the data to start reading data in the Clip AV stream file when the time stamp of the access point to the Clip is given. Used to find overnight addresses.
  • two types of CPI are used. One is EP map and the other is TUjnap.
  • EP_map is a list of entry point (EP) data, which is Evening Extracted from the list stream and transport stream. It has address information to find the location of the event point in the AV stream where decoding should start.
  • One EP data is composed of a presentation time stamp (PTS) and a data address pair in the AV stream of the access unit corresponding to the PTS.
  • PTS presentation time stamp
  • EPjnap is mainly used for two purposes. First, it is used to find the overnight address in the AV stream of the access unit referenced by the presentation time stamp in the PlayList. Second, it is used for fast-forward playback and fast reverse playback.
  • an EP_map is created and recorded on a disc when the syntax of the stream can be analyzed.
  • TILmap has a list of evening data (TU) data based on the arrival time of the transport packets input through the digital interface. This gives a relation between the time based on arrival time and the overnight address in the AV stream.
  • TU_map is created and recorded on a disc.
  • SESF self-encoded stream format
  • SESF defines the elementary stream coding restrictions for the MPEG-2 transport and AV streams.
  • an EP_map is created and recorded on a disc.
  • the stream of digital broadcasting is recorded on the recording medium 100 using any of the following methods.
  • the stream of digital broadcasting is transcoded into the SESF stream.
  • the recorded stream must comply with SESF.
  • an EP_map is created and recorded on the disc. Must be recorded.
  • the elementary stream constituting the digital broadcast stream is transcoded into a new elementary stream, and the stream is converted to a stream format determined by the standardization organization of the digital broadcast stream. Remultiplex to a new compliant transport stream. In this case, an EPjiiap must be created and recorded on the disc.
  • the input stream is a MPEG-2 transport stream conforming to ISDB (standard name for digital BS broadcasting in Japan), which includes an HD TV video stream and an MPEG AAC audio stream. And Transcode the HDTV video stream to the SD TV video stream and remultiplex the SDTV video stream and the original AAC audio stream into the TS.
  • the transport stream recorded as the SDTV stream must conform to the ISDB format.
  • the input transport stream is recorded transparently (recording the input transport stream without any change). At that time, an EP_map is created and recorded on the disc.
  • the input transport stream is recorded transparently (recording the input transport stream without any changes), at which time a TU_map is created and recorded on the disc.
  • FIG. 14 is a diagram showing an example of a directory structure on a disk.
  • the required directories on the DVR's disk are the root directory, including the “DVR” directory, the “PLAYLIST” directory, the “CLIPINF” directory, and the “M2TS” directory, as shown in Figure 14.
  • This is the "DVR” directory, including the "directory” and the "DATA” directory.
  • Other directories may be created under the root directory, but they will be ignored in the application format of this example.
  • the "DVR" directory stores the following files.
  • the "info. dvr” file is
  • the "mark. thmb" file stores information related to the mark thumbnail image. Under the DVR directory there must be zero or one mark thumbnail. It is assumed that the file name is fixed at mark. ThmM. If there is no menu thumbnail image, this file need not exist.
  • the "PLAYLIST” directory stores two types of PlayList files, Real PlayList and Virtual PlayList.
  • the "xxxxx. rpls” file stores information related to one Real PlayList. One file is created for each Real Play List.
  • the file name is "xxxxx. Rpls”.
  • "xxxxx” is five numbers from 0 to 9.
  • the file extension must be "rpls”.
  • the "yyyyy.vpls" file stores information related to one Virtual PlayList. One file is created for each Virtual PlayList. file name Is "yyyyy.vpls". Here, “yyyyy” is five numbers from 0 to 9. Assume that the file extension must be "vpl s”.
  • the "CLIPINF” directory stores one file, corresponding to each AV stream file.
  • the “zzzzz. clpi” file is a Clip Information file corresponding to one AV stream file (Cl ip AV stream file or Bridge-Cl ip AV stream file).
  • the file name is "zzzzz.clpi", and "zzzzz ,,” are five numbers from 0 to 9.
  • the file extension shall be "clpi”.
  • the "M2TS” directory stores AV stream files.
  • the “zzzzz.m2ts” file is an AV stream file handled by the DVR system. This is a Cl ip AV stream file or a Bridge-Cl ip AV stream.
  • the file name is "zzzzz.ni2ts", and "zzzzz” is five numbers from 0 to 9. Assume that the file extension must be "m2ts”.
  • the "DATA" directory stores data transmitted from data broadcasting.
  • the data directory is, for example, an XML file or MHEG file.
  • Fig. 15 shows the syntax of the "info. Dvr” file.
  • the “info.dvr” file is composed of three objects, DVRVolumeO, TableOfPlayLists (), and MakerPrivateData ().
  • TableOfPlayLists_Start one address indicates the start address of TableOfPlayListO in units of the number of bytes relative to the first byte of the info.dvr file. Relative bytes are counted from 0.
  • MakerPrivateData_Start_address ⁇ i N info top
  • the relative bytes are counted from 0.
  • padding_word is inserted according to the syntax of info.
  • d vr. 1 and 2 are ⁇ or any positive integer. Each padding word may take any value.
  • DVRVolumeO stores information describing the contents of a volume (disk).
  • FIG. 16 is a diagram illustrating the syntax of DVRVolume (). To explain the syntax of the DVR Volume () shown in FIG. 16, version_number indicates one character of four characters indicating the version number of the DVR Volume (). The version number is encoded as "0045" according to ISO6464.
  • the length is represented by a 32-bit unsigned integer indicating the number of bytes of the DVRVolume () from immediately after the length field to the end of the DVRVolume ().
  • Resume Volume stores the file name of the Real PlayList or Virtual PlayList that was played last in the volume. However, the playback position when the user interrupts the playback of Real PlayList or Virtual PIayList is stored in resume-mark defined in PlayListMark ().
  • FIG. 17 is a diagram illustrating the syntax of ResumeVolume ().
  • val id_flag indicates that the r * esume_PlayList_name field is valid when this 1-bit flag is set to 1, and this flag Is set to 0, 3 6? 1 & 1 ⁇ 31 _11 ⁇ 21116 Indicates that the field is invalid.
  • the 10-byte field of resume_PlayList_naiiie indicates the file name of Real PlayList or Virtual PlayList to be resumed.
  • FIG. 18 is a diagram showing the syntax of UIAppInfoVolume.
  • an 8-bit field of character_set is a method of encoding one character encoded in the Volume-name field. Is shown. The encoding method corresponds to the values shown in FIG.
  • the 8-bit field of name_length indicates the byte length of the volume name indicated in the Volume_name field.
  • the Volume-name field indicates the name of the volume.
  • the number of name_length bytes from the left in this field is a valid character, indicating the name of the volume.
  • the value after each valid character in the Volume_name field can be any value.
  • the Voluiae_protect flag is a flag indicating whether the contents in the volume can be shown to the user without restriction. If this flag is set, the user is allowed to show (play) the contents of the volume only if the user has successfully entered the PIN (password). If this flag is set to 0, the user is allowed to show the contents of the volume without having to enter the PIN number.
  • the recording / reproducing device 1 displays a list of PlayLists in the disc.
  • the playback restriction of each PlayList is independent of the volume_protect_flag, which is indicated by the playback-control-flag defined in UIAppInfoPlayList ().
  • the ref_thumbnail_index field indicates the information of the thumbnail image added to the volume. If the ref-thumbnail and index fields are not OxFFFF, a thumbnail image is added to the volume, and the thumbnail image is stored in the menu.thum file. The image is referenced in the menu.thum file using the value of ref-thumbnail_index. If the ref—thumtmail—index field is OxFFFF, it indicates that no thumbnail image is attached to the volume.
  • TableOfPlayLists () in the syntax of info. Dvr shown in Fig. 15 is explained.
  • TableOfPlayLists () stores the file names of PlayList (Real PlayList and Virtual PlayList). All PlayList files recorded in the Polyume are included in TableOfPlayList ().
  • TableOfPlayLists () indicates the default playback order of the PlayList in the volume.
  • FIG. 20 is a diagram illustrating the syntax of TableOfPlayLists ().
  • the version—number of TableOfPlayLists indicates four characters each indicating the version number of the TableOfPlayLists.
  • length is a 32-bit unsigned integer indicating the number of bytes of TableOfPlayListsO from immediately after this length field to the end of TableOfPlayListsO.
  • the 16-bit field of the number_of_PlayLists indicates the number of for-1 oop loops including the PlayList_file_name. This number must be equal to the number of PlayLists recorded in the volume.
  • the 10-byte number of PlayList_file-name indicates the file name of PlayList.
  • FIG. 21 is a diagram illustrating another example of the syntax of TableOfPlayListsO.
  • the syntax shown in FIG. 21 has a configuration in which UIAppinfoPlayList (described later) is included in the syntax shown in FIG. In this way, by including the UIAppinfoPlayList, it is possible to create a menu screen simply by reading TableOfPlayLists.
  • UIAppinfoPlayList described later
  • MakersPrivateData that describes MakersPrivateData in the syntax of info.dvr shown in Fig. 15 It is provided so that private data can be inserted. Each manufacturer's private date is standardized to identify the force that defined it].
  • MakersPrivateData () may include one or more maker_IDs.
  • MakersPrivateData If a given manufacturer wants to insert private data, and if the private data of another manufacturer is already included in MakersPrivateData (), the other manufacturer may erase the old private data that already exists. Instead, add a new private date to MakersPrivateData (). Thus, in this example, private data from a plurality of manufacturers can be included in one MakersPrivateData ().
  • FIG. 22 is a diagram illustrating the syntax of MakersPrivateData.
  • version—band ber indicates one character of four characters indicating the version number of MakersPrivateData ().
  • version_number must be encoded as "0045" according to ISO 646.
  • length is from immediately after this length field to the end of MakersPrivateData ()
  • One mp locks-Start address indicates the first byte address of the first mpd_block () in units of the number of bytes relative to the first note of MakersPrivateData ().
  • the relative number of bytes is counted from 0.o mimber_o: _maker one entry is the 16-bit code that gives the number of entries for each manufacturer's private data contained in MakersPrivateData (). None is an integer. In MakersPrivateData (), there must not be two or more maker private data with the same maker_ID value.
  • number_of_mpd_blocks is a 16-bit unsigned integer giving the number of mpd-blocks contained in MakersPrivateData ().
  • nakerjD is a 16-bit unsigned integer indicating the manufacturer of the DVR system that created the manufacturer private data. maker—The value encoded in the ID is specified by the licensor in this DVR format.
  • the maker_mode code is a 16-bit unsigned integer indicating the model number code of the DVR system that created the maker private data.
  • the value encoded in the makerjiiode and code is set by the manufacturer that has licensed this format.
  • start_mpd_block_number is a 16-bit unsigned integer indicating the number of the mpd-block at which the manufacturer's private data starts. The first data of the manufacturer's private data must be aligned to the top of the nipd_block 1 / ⁇ .
  • nipd_length is a 32-bit unsigned integer indicating the size of the manufacturer private data in byte units.
  • mpdjlock is an area where the manufacturer private data is stored. All mpd_blocks in MakersPrivateData () must be the same size.
  • FIG. 23 shows xxxxx.r ls (Real PlayLi It is a figure which shows the syntax of st) or yyyyy.vpls (Virtual PlayList).
  • xx xxx, rpls and yyyyy, vpls is 0 xxxx with the same thin evening box construction.
  • PlayListMark_Start_address indicates the start address of PlayListMarkO in units of the number of bytes relative to the first byte of the PlayList file. Relative bytes are counted from zero.
  • MakerPrivateData Start One address indicates the start address of MakerPrivateData () in units of relative bytes from the first note power in the PlayList file. The relative bytes are counted from 0.
  • padding_ ord (padding word) is inserted according to the syntax of the PlayList file, and 1 and 2 are 0 or any positive integer. Each padding word may take any value.
  • PlayList has been described briefly, but the PlayList will be further described. All Real PlayLists on the disc must refer to playback sections in all clips except Bridge-Clip (described later). Also, two or more Real PI ay Lists must not cause the playback section indicated by their Playltems to overlap within the same Clip.
  • every Clip has a corresponding Real PlayList. This rule is maintained even after editing has been performed, as shown in Figure 24B. Therefore, all clips can always be viewed by referring to any Real PlayList.
  • the playback section of the Virtual PlayList must be included in the playback section of the Real PlayList or the playback section of the Bridge-Clip.
  • a Bridge-Clip that is not referenced in any Vir tual PlayList must not be present on the disc.
  • Real PlayList contains a list of Playltems, but must not contain SubPlayltems.
  • Virtual PlayList includes a list of Playltems, CPI_type shown in PlayList () is EP_map type, and PlayList type is 0 (including video and audio).
  • Virtual PlayList can include one SubPlayltem. In the PlayList () in this example, SubPlaylte is used only for the purpose of audio dubbing, and the number of SubPlayltems in one Virtual PlayList must be 0 or 1.
  • FIG. 25 is a diagram illustrating the syntax of the PlayList.
  • version_number is one character of four characters indicating the version number of this PlayList ().
  • the versation_number must be encoded as "0045" according to ISO 646.
  • t length is a 32-bit data indicating the number of bytes of HayList () from immediately after this length field to the end of PlayList (). It is an unsigned integer.
  • PlayList_type is an 8-bit field indicating the type of this PlayList, and an example is shown in FIG.
  • CPI_type is a 1-bit flag, and indicates the value of the CP type of the Clip referenced by Playltem () and SubPlayItem (). All Clips referenced by one PlayList must have the same CP and type values defined in their CPI (). number—of_PlayItems is a 16-bit field indicating the number of Playltems in the PlayList.
  • Playltem_id corresponding to a predetermined Playltem is defined by the order in which the Playltem () appears in a for-loop including the Playltem ().
  • Playltemjd starts from 0.
  • the number—of_SubPlay Items is a 16-bit field indicating the number of SubPlayltems in the PlayList. This value is 0 or 1.
  • the additional audio stream path is a type of sub-path.
  • FIG. 27 is a diagram illustrating the syntax of UIAppInfoPlayList.
  • character_set is an 8-bit field, and indicates the encoding method for one character encoded in the PlayList-name field. The encoding method corresponds to the values based on the table shown in FIG.
  • name_length is an 8-bit field
  • the PlayList—name field Indicates the byte length of the indicated PlayList name.
  • the field of PlayList__name indicates the name of PlayList.
  • the number of bytes of the namejength number from the left in this field is a valid character, which indicates the name of the PlayList.
  • the value after those valid characters may be any value.
  • record_time_and_date is a 56-bit field that stores the date and time when the PlayList was recorded.
  • This field is a four-bit Binary Coded Decimal (BCD) encoding of 14 numbers for year / month / day / hour / minute / second. For example, 2001/12/23: 01:02:03 is encoded as "0x20011223010203".
  • BCD Binary Coded Decimal
  • the duration is a 24-bit field indicating the total playback time of the PlayList in units of hours / minutes / seconds.
  • This field is a 6-bit binary coded decimal (BCD) code. For example, 01:45:30 is encoded as "0x014530".
  • “valid_period” is a 32 bit field indicating a period during which the PlayList is valid. This field is a set of 8 numbers encoded in a 4-bit Binary Coded Decimal (BCD).
  • BCD Binary Coded Decimal
  • the recording / reproducing apparatus 1 is used to automatically delete a PlayList whose validity period has passed. For example, 2001/01/07 is encoded as "0x20010507".
  • maker_id is a 16-bit unsigned integer indicating the maker of the DVR player (recording / reproducing apparatus 1) that last updated the PlayList.
  • the value encoded in makerjd is assigned by the licensor in DVR format.
  • maker_code is a 16-bit unsigned integer indicating the model number of the DVR player that last updated the PlayList.
  • the value encoded in the maker_code is determined by the manufacturer licensed in the DVR format.
  • the PlayList is played only when the user can correctly input the PIN number. If this flag is set to 0, the user can view the PlayList even if the user does not enter the PIN number.
  • the write_protect_flag is set to 1 as shown in the table of FIG. 28A, the contents of the PlayList are not deleted or changed except for the write_protect_flag. If this flag is set to 0, the user is free to delete and modify the PlayList.
  • the recording / reproducing apparatus 1 displays a message for reconfirming the user before the user deletes, edits, or overwrites the PlayList.
  • a Real PlayList with write_protect flag set to 0 exists, a Virtual PlayList that references the Clip of the Real PlayList exists, and write_protect_flag of the Virtual PlayList is set to 1 Is also good.
  • the recording / reproducing apparatus 1 warns the user of the existence of the Virtual PlayList before deleting the RealPlayList, or sets the RealPlayList to "Minimize ' 'Yes.
  • play6d_flag is set to 0 if the flag is set to 1 as shown in Figure 28B, indicating that the PlayList has been played once since it was recorded In that case, the PlayList indicates that it has never been played since it was recorded.
  • the ref_thunibnai and inde X fields indicate information of thumbnail images representing the PlayList.
  • ref_thum bnai l If the index field is not OxFFFF, a thumbnail image representing PlayList is added to the PlayList, and the thumbnail image is stored in the menu.thum file. The image is referenced using the re: Lthumbnai index value in the menu.thuiii file. If the ref—thumbnail—index field is OxFFFF, the PlayList does not include a thumbnail image representing the PlayList.
  • Playltem basically contains the following data.
  • Cl ip_information_file_name for specifying the file name of Cl ip
  • a pair of IN_time and 0UT_time for specifying the playback section of Cl ip
  • CP time type defined in PlayList () if the EP type is EP map type
  • 0UT_time refer to STC_sequence_id and connect_condition 0 indicating the connection status between the preceding Playltem and the current Playltem 0
  • Playlteia When a PlayList consists of two or more Playltems, their Playlteia are arranged in a single row on the global timeline of the PlayList without time gaps or overlaps.
  • CPI_type defined in PlayList () is EP-map type and the current Playltem does not have BridgeSequence ()
  • the pair of IN_time and 0UT_time defined in that Playltem is specified by STC_sequence-id It must point to a time on the same STC contiguous interval that is being performed.
  • Figure 29 shows such an example.
  • FIG. 30 shows a case where the following rules are applied when the CP type defined in PlayList () is EPjnap type and the current Playltem has BridgeSequence ().
  • the IN_time of the Playltem that precedes the current Playltem refers to the time on the STC continuous section specified by the STC_sequence-id of the preceding Playltem.
  • Leading? 1711: 6111 0111 1 _ ⁇ ] 116 (shown as 0UT_timel in the figure) refers to the time in the Bridge-Clip specified in BridgeSequencelnfo () of the current Playltem. I have. This OUT-time must conform to the encoding restrictions described below.
  • the IN-time of the current PlayItem indicates the time in the Bridge-Clip specified in BridgeSequenceInfo () of the current Playltem. This IN_time must also conform to the encoding restrictions described later.
  • the OUT—time of the P1ayItem of P1ayIten in Langlang is on the STC continuous section specified by the STC—sequence_id of the current Playltem. Time.
  • the pair of Play_tem IN_time and OUT-time points to the time on the same Clip AV stream.
  • Playltem syntax is shown in Figure 32.
  • the field of Clip_Information_file_name indicates the file name of Clip Information file.
  • Cliplnfo of this Clip Information file Cl ip_stream_type defined in () must indicate Cl ip AV stream.
  • STC_sequence_id is an 8-bit field, and indicates STC-sequence-id of the STC continuous section referenced by the Playltem. If the CPI.type specified in PlayList () is TU_map type, this 8-bit field has no meaning and is set to 0. IN_time is a 32-bit field and stores the playback start time of Playltem. As shown in Fig. 33, the semantics of IN_tinie differ depending on the type of CPI defined in PlayList ().
  • OUT-time is a 32-bit field that stores the playback end time of Playltem.
  • the semantics of 0UT_time differs depending on the CPI_type defined in PlayList (), as shown in Figure 34.
  • Connection—Condition is a 2-bit field indicating the connection state between the preceding Playltem and the current Playltem as shown in FIG. 35.
  • FIGS. 36A to 36D are diagrams illustrating each state of the Connection_Condition shown in FIG. 35.
  • BridgeSequenceInfo is attached information of the current Playltem, and has the following information.
  • this is the address of the source packet on the ClIP AV stream referenced by the preceding Playltem, and the first source packet of the Bridge-Clip AV stream file is connected following this source packet.
  • This address is called RSPN—exit_froia_previous—C1 ip.
  • it is the address of the source packet on the ClIP AV stream referred to by the current Playltem, and the last source packet of the Bridge Clip AV stream file is connected before this source packet. This address is called RSPN-enter-current_Clip.
  • FIG. 38 is a diagram illustrating the syntax of BridgeSequenceinfo.
  • the field of Bridge_C1ip_Inf ormat ion on_fi1e-name is a file of Cl ip Information file corresponding to Bridge-Cl ip AV stream file. Indicates the name.
  • Cl ip_stream_type defined in ClipInfo () of this Cl ip Information file must indicate 'Bridge-Cl ip AV stream.
  • RSPN_exit_froni_previous_Cl ip The 32 bit field of RSPN_exit_froni_previous_Cl ip is the relative address of the source packet on the Cl ip AV stream referenced by the preceding Playltem, and the first source packet of the Bridge-Cl ip AV stream file follows this source packet. Connected.
  • RSPN_exit_from_previous_Clip is a size in units of the source packet number, and the initial value of offset_SPN defined in Cl ipInfo () from the first source packet of the Cl ip AV stream file referenced by the preceding Playltem is used. Be counted.
  • RSPILenter_to_current The 32-bit field of the Cl ip is the relative address of the source packet on the Cl ip AV stream referenced by the current Playltem, and the last source packet of the Bridge-Cl ip AV stream file is preceded by this source packet.
  • RSPN_exit—from_previous_Clip is a size in units of source packet number, and is the offset—SPN value defined in ClipInfo () from the first source packet of the Cl ip AV stream file referenced by the current Playltem. Is counted as the initial value.
  • SubPlayltem will be described with reference to FIG. Use of SulayItem () is allowed only when the PlayList () CP type is EP_map type. In this example, it is assumed that SubPlayltem is used only for audio dubbing purposes.
  • SubPlayItem () includes the following data. First, it includes a Cl ip_inforniation_file_name for designating a Cl ip referenced by a sub path in the PlayList.
  • SubPath-IN_time and SubPath_OUT_time for specifying the playback section of the sub path in the Clip. Furthermore, it includes sync_PlayItem_id and sync_start_PTS_of_PlayItem for specifying the time at which the sub path starts playing on the time axis of the main path.
  • the audio Cl ip AV stream referred to by the sub path is Time discontinuity).
  • the audio sample clock of the Clip used for the sub path is locked to the audio sample clock of the main path.
  • FIG. 40 is a diagram illustrating the syntax of SubPlayltem.
  • the field of Cl ip_Infoi> mation-file_name indicates the file name of the Cl ip Information file, which is used by the sub path in the PlayList.
  • the Cl ip_stream_type defined in the Cl ipInfo () of the Cl ip Information file must indicate the Cl ip AV stream.
  • SubPath The 8-bit field of type indicates the type of sub path. Here, as shown in Fig. 41, only '0x00' is set, and other values are reserved for the future.
  • the 8-bit field of sync—Playltem—id indicates the Playltem-id of the Playltem that includes the time at which the subpattern starts playing on the time axis of the ain path.
  • the value of Playltem_id corresponding to a predetermined Playltem is defined in PlayList () (see FIG. 25).
  • sync_s start_PTS_of _P 1 ay Item ⁇ 32 2 bit field indicates the time at which the sub path starts playing on the time axis of the main path, and the PTS (Presentaiotn Time Stamp) on Playlt em referenced by sync_PlayItem_id Indicates the upper 32 bits of.
  • SubPath The 32 bit field of IN_time stores the playback start time of the Sub path.
  • SubPath_IN_time indicates the upper 32 bits of a 33-bit long PTS corresponding to the first presentation unit in the Sub Path.
  • the 32-bit field of SubPath_0UT_tine stores the playback end time of the Sub path.
  • SubPath-OUT-time indicates the upper 32 bits of the value of Presenation_end_TS calculated by the following equation.
  • PTS_out is a 33-bit long PTS corresponding to the last presentation unit of SubPath.
  • AU—duration is the display duration in 90 kHz units of the last presentation unit of SubPath.
  • FIG. 42 is a diagram illustrating the syntax of PlayListMark.
  • version-number is one of four characters indicating the version number of this PI ayListMark ().
  • the conversation_number has to be encoded as "0045" according to ISO 646.
  • length indicates the number of bits of PlayListMark () from immediately after the length field to the end of PlayListMark (), and is a 32-bit unsigned integer.
  • number—of_PlayList_marks is a 16-bit unsigned integer indicating the number of marks stored in PlayListMark.
  • nuniber_of_PlayList_] iiarks may be zero.
  • mark_type is an 8-bit field indicating the type of mark, and is encoded according to the table shown in FIG.
  • the 32-bit field of mark_time_stanip stores an evening stamp indicating the point designated by the mark.
  • the semantics of mark-time-stamp differs depending on the CPI-type defined in PlayList ().
  • Playltem — id is an 8-bit field that specifies the Playltem where the mark is located.
  • the value of Playltem_id corresponding to a predetermined Playltem is defined in PlayList () (see FIG. 25).
  • the 8-bit field of the character_set indicates the encoding method of one character encoded in the mark_name field.
  • the encoding method corresponds to the values shown in FIG.
  • An 8-bit field of name_length indicates the byte length of the mark name indicated in the Mark_name field.
  • the ref_thumbnail_index field indicates information on the thumbnail image added to the mark. If ref_tlmmbnai and the index field are not OxFFFF, a thumbnail image is added to the mark, and the thumbnail image is stored in the mark.
  • thmb file The image is referred to in the mark. Thmb file using the value of ref_tlmmb_nail_index (described later). If r * ef_thumbnai and the index field is OxFFFF, it indicates that no thumbnail image is added to the mark. 82605 ⁇ one
  • zzzzz.clpi (Clip information file) is composed of six objects as shown in FIG. These are ClipInfo (), STC_Info () ProgramInfo (), CPI (), ClipMark (>, and MakerPrivateDataO.
  • the AV stream (Clip AV stream or Bridge-Clip AV stream) and the corresponding Clip Information file are The same digit string "z zzzz" is used.
  • Cliplnfo—Start_address is based on the number of bytes relative to the first byte of the zzzzz.clpi file, and is used for ClipInio (). Indicates the start address. Relative bytes are counted from zero.
  • STC_Info_Start-address indicates the start address of STC-Info () in units of the number of bytes from the first byte of the zzzzz.clpi file. The relative number of bytes is counted from ⁇ .
  • ProgramInfo_Start_address indicates the start address of ProgramInfo () in units of the number of bytes relative to the first bit of the zzzzz.clpi file. The number of bytes is counted from 0.
  • the CP_Start_address is counted from 0, with the relative byte count indicating the start address of CPI () in units of the relative byte count from the first byte of the zzzzz.clpi file.
  • ClipMark—Start_address indicates the start address of ClipMark () in units of the number of bytes relative to the first byte of the zzzzz.clpi file. The relative byte count is 0 or 'counted.
  • the padding is counted from 0.
  • padding_woi «d is inserted according to the syntax of the zzzzz.clpi file.Nl, N2N3, N4s and N5 are 0 or any positive It must be an integer.
  • the padding pad of ⁇ ? May take any value.
  • FIG. 46 shows the syntax of Cliplnfo.
  • ClipInfo stores the attribute information of the corresponding AV stream file (Clip AV stream or Bridge-Clip AV stream file).
  • version_number is four characters indicating the version number of this ClipInfo ().
  • the version_number must be encoded as "0045" according to ISO 646 ⁇ length indicates the number of bytes of Cl ipInfo () from immediately after this length field to the end of Cl ipInfo () It is a 32-bit unsigned integer.
  • the 8-bit field of the Clip_stream_type indicates the type of the AV stream corresponding to the Clip Information file. The stream type of each type of AV stream will be described later.
  • offset_SPN The 32 bit field of the SPN gives the offset value of the source packet number for the first source packet of the AV stream (Clip AV stream or Bridge-ClIP AV stream) file. This offset_SPN must be 0 when the AV stream file is first recorded on the disc.
  • offset_SPN when the first part of the AV stream file is deleted by editing, offset_SPN may take a value other than 0.
  • the relative source packet number (relative address) referring to offset_SPN is often described in the syntax in the form of RSPN_x XX (XXX is deformed, eg, RSPN_EP_start).
  • the relative source packet number is a size in units of the source packet number, and is counted from the first source packet of the AV stream file with the value of offset_SPN as an initial value.
  • the number of source packets (SPN_xxx) from the first source packet of the AV stream file to the source packet referenced by the relative source packet number is calculated by the following equation.
  • FIG. 48 shows an example in which offset_SPN is 4.
  • TS—recording_rate is a 24-bit unsigned integer. This value is used to input an AV stream to a DVR drive (writing unit 22) or a DVR drive (reading unit 28). Gives the output bit rate.
  • record_tinie_and_date is a 56-bit field that stores the date and time when the AV stream corresponding to Clip was recorded, with 14 numbers for year / month / day / hour / minute / second.
  • the 4-bit Bina It is encoded with ry Coded Decimal (B CD). For example, 2001/12/23: 01: 02:03 is encoded as 0x20011223010203 ".
  • duration is a 24-bit field indicating the total playback time of the Clip in units of time Z minutes / second based on the arrival time clock. This field is obtained by encoding six numbers using a 4-bit Binary Coded Decimal (BCD). For example, 01:45:30 is encoded as 0x014530 ".
  • BCD Binary Coded Decimal
  • time-controllecLflag indicates the recording mode of the AV stream file. If this time_controlled_: flag is 1, this indicates that the recording mode is a mode in which the file size is proportional to the elapsed time since recording, and the condition shown in the following formula must be satisfied. Must.
  • TS_average-rate represents the average bit rate of the transport stream of the AV stream file in units of bytes / second.
  • t indicates a time expressed in seconds
  • start_time is a time when the first source packet of the A stream file is recorded, and is expressed in seconds
  • size-clip (t) represents the size of the AV stream file at time t in bytes.For example, if 10 source packets are recorded from start_time to time t, size-clip (t) t) is 10 * 192 bytes.
  • Hi is a constant that depends on TS_average_rate.
  • time_controlled_flag is set to 0, it indicates that the recording mode is not controlling the time lapse of recording and the file size of the AV stream to be proportional. For example, this is the case when the input transport stream is recorded transparently.
  • TS_average_rate indicates the value of TS_average_rate used in the above equation when the time_controlled_flag is set to 1. If time_controlled_flag is set to 0, this field has no meaning and must be set to 0.
  • a transport stream with a variable bit rate is encoded according to the following procedure. First transport Set the rate to the value of TS—recording_rate. Next, the video stream is encoded at a variable bit rate. Then, transport packets are intermittently encoded by not using null packets.
  • RSPN_arrival_time is the relative address of the location where discontinuity of the arrival time base occurs in the Bridge-Clip AV stream file.
  • RSPN_arrival_time is a unit of source packet number, and is counted from the first source packet of the Bridge-Cl ip AV stream file using the value of off set_SPN defined in Cl ipInfo () as the initial value c
  • the absolute address in the Bridge-Cl ip AV stream file is
  • reserved_for_system_use ⁇ 144-bit field is reserved for system.
  • the 32 bit field of the foriiat_identifier has the format-identifier value of the registration deascriotor (defined by ISO / IEC138818-1) in the transport stream.
  • the 16-bit field of the origin and network ID indicates the value of the original-network-ID defined in the transport stream.
  • the 16-bit field of transport_stream_ID indicates the value of transport_stream-ID defined in the transport stream.
  • the 16-bit field of servece_ID indicates the value of servecejm defined in the transport stream.
  • the 24-bit field of country_code indicates a country code defined by IS031666. Each character One character is encoded by IS 088559-1. For example, Japan is represented as "JPN” and encoded as "0x4A 0x50 0x4E”.
  • stream_: ormat—name is the ISO—name of the format authority that defines the stream in the transport stream.
  • format—1 dent if ier, original_networK-ID, transport_stream_ID servece_ID, country-code, and stream—format—name indicate the service provider of the transport stream, and thus the audio or video stream. It can recognize the encoding restrictions, the SI (Service Information) standard, and the stream definition of the private data stream other than the audio / video stream. This information can be used to determine whether the decoder can decode the stream and, if so, to initialize the decoder system before decoding starts.
  • SI Service Information
  • STC_sequence the time section in the MPEG-2 transport stream that does not include STC discontinuities (discontinuities in the system time pace) is called STC_sequence
  • STC_sequence STC_sequence — Specified by the value of id.
  • FIG. 5OA and FIG. 50B are diagrams illustrating a continuous STC section. The same STC value in the same STC sequence never appears (however, the maximum time length of Cip is limited as described later). Therefore, the same value of PTS in the same STC_sequence also never appears.
  • the system time base of Clip is divided into (N + 1) STC sequences.
  • STC_Info stores the address of the place where STC discontinuity (system timebase discontinuity) occurs.
  • RSPN-STC_start indicates the address
  • the last STC_sequence starts at the time when the source packet referenced by the last RSPN_STC-start arrives and ends at the time when the last source packet arrives I do.
  • FIG. 52 is a diagram showing the syntax of STC-Info. To describe the syntax of STC-Info shown in FIG. 52, it is four characters per character indicating the version number of this STC_Info (). The vers ion—number must be encoded as “0045” according to ISO 6646.
  • the length is a 32-bit unsigned integer indicating the number of bytes of STC-Info () from immediately after the length field to the end of STC_Info ().
  • the length field may be set to 0.
  • CPI (type) of CPI () indicates EP_map type, num—of— ST sequences must have a value of 1 or more.
  • the num—of_STC_sequences 8-bit unsigned integer indicates the number of STC—sequences in the CI ip. This value follows this field: Indicates the number of loops in the for-loop.
  • the STC_sequence_id corresponding to the predetermined STC_sequence is defined by the order in which the RSPN_STC_start corresponding to the STC-sequence appears in the for-1 oop including the RSPN-STC-sart. STC_sequence_id starts from 0.
  • RSPN_STC-start indicates the address where STC-sequence starts on the AV stream file.
  • RSPN_STC-start indicates the address at which a system-imimum-based discontinuous point occurs in the AV stream file.
  • RSPN_STC_start may be the relative address of the source packet with the first PCR of the new system time pace in the AV stream.
  • RSPN—STC_start is a size in units of source packet number, and is counted from the first source packet of the AV stream file with the initial value of off set_SPN defined in CI iplnfo (). The absolute address in the AV stream file is already described above.
  • SPN_xxx RSPN— XXX-offset_SPN
  • prograin_sequence a time section having the following characteristics in the clip is referred to as prograin_sequence.
  • the value of PCR_P ID does not change.
  • the number of video elementary streams does not change.
  • each video story The PID value of the system and the coding information defined by its VideoCodinglnfo do not change.
  • the number of audio elementary streams does not change.
  • the PID value for each audio stream and the encoding information defined by its AudioCodinglnfo do not change.
  • ProgramInfo stores the address where program_sequence starts.
  • RSPN_program_sequence_start indicates the address.
  • FIG. 54 is a diagram showing the syntax of Programlnfo. To explain the synchronization of Program Info shown in FIG. 54, version_nuiiiber is one of four characters indicating the version number of ProgramInfo (). version_n TM ber must be encoded as “0045” according to ISO 6646.
  • the length is a 32-bit unsigned integer indicating the number of bytes of ProgramInfo () from immediately after the length field to the end of ProgramInfo ().
  • the CPI_type of the CPI () indicates the TU_map type
  • the length field may be set to 0. If the CPI (type) of CPI () indicates EP_map type, nuniber_oiLprograms must be a value of 1 or more.
  • An 8-bit unsigned integer in the number-of-program sequences indicates the number of program sequences in the Cl ip This value indicates the number of loops in the for-loop following this field. If the program-sequence does not change in the ip, the number-of-one-program-sequence must be set to 1.
  • RSPN-program The 32-bit field of sequence—start is the AV stream file This is the relative address where the program sequence starts above.
  • am_sequence—start is a size in units of source packet number, and is counted from the first source packet of the AV stream file using the offset_SPN value defined in ClipInfo () as the initial value. You.
  • the absolute address in the AV stream file is
  • SPN_xxx RSPN— XXX-offset_SPN
  • the 16-bit field of the PCR_PID indicates the PID of a transport packet including a valid PCR field in the pr> ogram_sequence.
  • the 8-bit field of number—of—audios indicates the number of loops of the for-loop including audio_stream_PID and AudioCodingInfo () .6 video—The 16-bit field of stream_PID indicates the transport packet of a transport packet containing a valid video stream for that prograin_sequence. Indicates PID.
  • VideoCodinglnfo () following this field shall describe the content of the video stream referenced by the video-stream-PID.
  • AudioCodingInfo () following this field shall describe the content of the video stream referenced by the audio_stream_PID.
  • the order in which the value of video_stream_PID appears in the syntax for-loop must be the same as the order in which the PIDs of the video stream are encoded in the PMT valid for that program_sequence.
  • the order in which the audio_streai_P ID value appears in the syntax for-loop must be the same as the order in which the PID of the audio stream is encoded in the PMT valid for that program_sequence.
  • FIG. 55 is a diagram showing the syntax of VideoCodinglnfo in the syntax of Programinfo shown in FIG.
  • the 8-bit field of the video_format indicates the video format corresponding to the video_stream_PID in the Programlnfo (), as shown in FIG.
  • the 8-bit field of frame_rate indicates the video frame rate corresponding to video_stream_PID in ProgramInfo ().
  • an 8-bit field of display_aspect-ratio indicates a display aspect ratio of a video corresponding to video_stream_PID in ProgramlnfoO.
  • FIG. 59 is a diagram showing the syntax of AudioCodinglnfo in the syntax of Programinfo shown in FIG.
  • the syntax of AudioCodinglnfo shown in Fig. 59 is explained.
  • the 8-bit field of audio_coding indicates an audio encoding method corresponding to audio_stream_PID in Programlnfo ().
  • an audio-component-type 8-bit field indicates an audio component type corresponding to audio_stream_PID in ProgramInfo ().
  • the sampling-frequency 8-bit field indicates the audio sampling frequency corresponding to audio_stream_PID in ProgramInfo ().
  • CPI Charge Point Information
  • CPI is used to associate the time information in the AV stream with the address in the file.
  • CP I has two evenings, EPjaap and ⁇ —map.
  • the CPI () includes an EP_map.
  • the CPI () includes TU_map.
  • One AV stream has one EP_map or one TU_map. If the AV stream is a SESF transport stream, the corresponding Clip must have EPjnap.
  • FIG. 65 is a diagram showing the syntax of CPI.
  • versioiummber is one character of four characters indicating the version number of this CPI ().
  • version_number must be encoded as "0045" according to ISO 646.
  • length is a 32-bit unsigned integer indicating the number of bytes of CPI () from immediately after this length field to the end of CPI ().
  • the CPI—type is a 1-bit flag, and represents the CPI type of the Clip.
  • EPjnap in the CPI syntax shown in FIG. 65 will be described.
  • EP_map has two evenings: EP_map for video stream and EPjnap for audio stream.
  • the EP_map for the video stream has a stream_PID, PTS_EP_start, and RSPN_EP_start.
  • stream_PID indicates a PID of a transport packet for transmitting a video stream.
  • PTS_EP-start indicates PTS of an access unit starting from a sequence header of a video stream.
  • RSPN_EP_start indicates the address of the source pocket including the first byte of the access unit referenced by PTS_EP_start in the AV stream.
  • EP_niap_for_one-stream_PID A sub-table called EP_niap_for_one-stream_PID () is created for each video stream transmitted by a transport packet having the same PID. If there are multiple video streams in the Clip, the EP-map may include multiple EP_niap_for-one-stream-PID ().
  • An EP-map for an audio stream has data of stream_PID, PTS_EP_start, and RSPN-EP-start.
  • stream_PID indicates a PID of a transport packet for transmitting an audio stream.
  • PTS_EP_start indicates the PTS of the access unit of the free stream.
  • RSPN-EP_start indicates the address of the source packet including the first byte of the access unit referenced by PTS_EP-start in the AV stream.
  • EP_map_for_one_stream_PID A sub-table called EP_map_for_one_stream_PID () is created for each audio stream transmitted by transport packets having the same PID. If there are multiple audio streams in the Clip, the EP_map may include multiple EP-maps for_one-stream_PID ().
  • EP_map one EPjnap-for-one_stream-PID () is created in one table regardless of STC discontinuities.
  • the boundary of the EP_map data belonging to each STC_sequence can be found (see Fig. 68).
  • the EP-map must have one EP_inap_for_one-stream_PID for the range of continuous streams transmitted with the same PID.
  • program # 1 and program # 3 have the same video PID, but the data range is not continuous. Therefore, each program must have an EP_map_for_one—stream_P ID.
  • Figure 70 is a diagram showing the syntax of EP-map.
  • the EP_type is a 4-bit field and indicates the entry point type of the EP_map as shown in Fig. 71.
  • the EP_type indicates the semantics of a data field following this field. If more than one video stream is included, EP_type shall be set to 0 ('video'), or if Clip contains no video stream but one or more audio streams, EP _type must be set to l ('audio').
  • EP_map_for_one_stream_PID (num_EP_entries (k)), indicating a 16-bit field of num—EP—entries (k).
  • EP_map_for_one_streai_P ID_Start_address (k): Indicates the relative byte position at which EP_map_for_one—stream_P ID (numj: P—entries (k)) starts in the 32-bit fino redd f or EP_map (). This value is indicated by the size from the first byte of EP_iiiap ().
  • padding_word must be inserted according to the syntax of EP_map (). X and Y must be 0 or any positive integer. Each padding code may take any value.
  • FIG. 72 is a diagram illustrating the syntax of EP_map_for_one_stream_PID.
  • EP_map_for_one_stream_PID the syntax of EPjnap-for_one_stream_P ID shown in Fig. 72.
  • the semantics of the 32-bit field of PTS_EP-start differs depending on EP_type defined in EP_map (). If EP_type is equal to 0 (, video '), this field shall be the 33-bit precision Punit of the access unit beginning with the sequence header of the video stream. It has the upper 32 bits of TS. If EP_type is equal to 1 (, audio '), this field has the upper 32 bits of the 33-bit precision PTS of the audio stream access unit.
  • EP_type defined in EP_niap (). If EP_type is equal to 0 ('video'), this field contains the relative address of the source pocket containing the first byte of the header to the sequence of the access unit referenced by PTS_EP_start in the AV stream. Show. Or, if EP_type is equal to 1 ('audio'), this field indicates the relative address of the source packet containing the first byte of the audio frame of the access unit referenced by PTS_EP_start in the A stream. .
  • RSPN-EP-start is a size in units of source packet number, and is 0861 defined from 01 1 11 ⁇ 0 () from the first source packet of the AV stream file;
  • the value of _SPN is counted as the initial value.
  • the absolute address in the AV stream file is
  • TU_map creates one time axis based on the arrival time clock (arrival time based clock) of the source packet.
  • the time axis is called TU_map_time_axis.
  • the origin of TUjnap_time_axis is indicated by offset_time in TU__map ().
  • TU—map—time—axis is divided into fixed units from offset_time. The unit is called time-unit.
  • the address of the first complete source packet on the AV stream file is stored in the TU_map. These addresses are called RSPN_time_miit-start.
  • FIG. 75 is a diagram illustrating the syntax of TUjnap.
  • the field 3121311: 0361: _ ⁇ 1116 gives the offset time for TU_inap_time_axis. This value indicates the offset time for the first time_unit in the Clip.
  • the off set-time is a magnitude in units of a 45 kHz clock derived from a 27 MHz accurate arrival time clock. If the AV stream is recorded as a new Clip, the offset-time must be set to 0.
  • the 32-bit field of number—of—time—unit—entries indicates the number of time_unit entries stored in the TU_map ().
  • RSPN time—unit_start indicates the relative address of the place in the AV stream at which the time_unit starts to fly.
  • RSPN time_unit—start is a size in units of the source packet number, and is output from the first source packet of the AV stream file using the offset_SPN value defined in ClipInfo () as the initial value.
  • the absolute address in the AV stream file is
  • SPN_xxx RSPN— XXX-offset_SPN
  • RSPN_time_unit_start Is calculated by The values of RSPN_time_unit_start must appear in ascending order in the for-loop of the Shinx. If there are no source packets in the (k + 1) th time_unit, the (k + 1) th RSPN—time—unit—start must be equal to the kth RSPN_time—unit—start.
  • Cl ip Mark in the syntax of zzzzz. Cl ip shown in Fig. 45 will be described.
  • Cl ip Mark is mark information about the clip, and is stored in Cl ipMark. This mark is set by the recorder (recording / reproducing device 1), and is not set by the user.
  • FIG. 75 is a diagram showing the syntax of ClipMark.
  • version_nu] iiber is one character of four characters indicating the version number of this Cl ipMark (). version number is in ISO 6 4 6 Therefore, it must be encoded as "0045".
  • mark_type is an 8-bit field indicating the type of the mark, and is encoded according to the table shown in FIG.
  • mark_tiiiie_stamp is a 32-bit field and stores a time stamp indicating a point designated by a mark. As shown in FIG. 77, the semantics of mark_time-stamp differs depending on the CP type in PlayList ().
  • the STC_sequence_id indicates the STC_sequence_id of the continuous STC section where the mark is placed.
  • the CPI_type in the CPI () indicates the TU—map type, this 8-bit field has no meaning and is set to 0.
  • the 8-bit field of the character—set indicates how to encode each character encoded in the mark_name field.
  • the encoding method corresponds to the values shown in FIG.
  • An 8-bit field of name—1 ength indicates the byte length of the mark name indicated in the Mark_imiiie field.
  • the mark_name field indicates the name of the mark.
  • the number of name-length bytes from the left in this field is a valid character, which indicates the name of the mark.
  • the value after each valid character in the mark_name field can be any value.
  • _thumbnai and index fields indicate the information of the thumbnail image added to the mark. If the ref_thumbnail_index field has a value other than OxFFFF, a thumbnail image is added to the mark, and the thumbnail image is stored in the mark.thmb file. The image is referenced using ref_thumb nai and index values in the mark. Thmb file. i> ef_thumbnail — If the index field is OxFFF F, no thumbnail image is added to the mark.
  • Thumbnail images are stored in the menu. Thmb file or mark. Thmb file. These files have the same syntax structure and have only one Thumbnails ().
  • the menu.thmb file stores menu thumbnail images, that is, images that represent Volume, and images that represent each PlayList. All menu thumbnails are stored in only one menu. Thmb file.
  • the mark.thmb file stores mark thumbnail images, that is, pictures representing mark points. All mark thumbnails for all PlayLists and Clips are stored in only one mark. Thmb file. Thumbnails are frequently added and deleted, so the addition and partial deletion operations must be easily and quickly performed. For this reason, Thumbnai U) has a block structure.
  • the image data is divided into several parts, and each part is stored in one tn_block. One image is stored in a continuous tnjalock. There may be unused tn_blocks in the tn_block column. The byte length of one thumbnail image is variable.
  • Fig. 78 shows the syntax of menu. Thmb and mark. Thmb
  • Fig. 79 shows the syntax of Thumbnai 1 in the syntax of nenu. Thm and mark. Thmb.
  • the length is a 32-bit unsigned integer indicating the number of bytes of MakersPrivateData () from immediately after this length field to the end of Thumbnai 1 ().
  • tn_blocks The start_address is a 32-bit unsigned integer indicating the first byte address of the first tnjalock in units of bytes relative to the first byte of Thumbnai 1 (). Relative bytes are counted from zero.
  • number_of_thuinbnails is a 16-bit unsigned integer giving the number of entries of thumbnail images contained in Thumbnai).
  • thumbnai index is re: f_tlmiiibnai in UIAppInfoVolume (), UIAppInfoPlayList (), PlayListMarkO, and ClipMark () and is referred to by index. Is an unsigned integer and takes a value as shown in Figure 80. DCF and PNG in the table are only allowed in "menu.thmb". The mark thumbnail must take the value "0x00" (MPEG-2 Video Image).
  • picture_data_size is a 32-bit unsigned integer indicating the byte length of the thumbnail image in bytes.
  • start_tn_block_mimber is a 16-bit unsigned integer representing the tn_block number of the tnjDlock at which the thumbnail image data starts. The start of the thumbnail image data must match the start of tb_block. The tn—block number starts at 0 and is related to the value of the variable k in the tnjalock for-loop.
  • x_picture_length is a 16-bit unsigned integer representing the number of pixels in the horizontal direction of the frame picture frame of the thumbnail image.
  • y_picture_length is a 16-bit unsigned integer representing the number of pixels in the vertical direction of the frame picture frame of the thumbnail image.
  • tn_block is an area in which thumbnail images are stored. All tn-blocks in Thumbnai 1 () have the same size (fixed length), and the size is defined by tn_block_size.
  • FIGS. 81A and 81B are diagrams schematically showing how thumbnail images are stored in a tn-block. As shown in Fig. 81A and Fig. 81B, each thumbnail image data starts from the beginning of the tn_block, and if the size exceeds 1 tn_block, the next tnjDock is used. Stored. This makes it possible to manage the variable-length picture data as a fixed-length picture data, and to cope with editing such as deletion by simple processing. You.
  • AV stream files are Stored in the "M2TS" directory ( Figure 14).
  • Both AV streams must have the structure of a DVR MPEG-2 Transport Stream file as defined hereafter.
  • DVR MPEG-2 transport stream will be described.
  • the structure of the transport stream is as shown in Figure 82.
  • the AV stream file has the structure of the DVR MPEG 2 transport stream.
  • the DVR MPEG 2 transport stream consists of an integer number of aligned units.
  • the size of the Aligned unit is 6 144 bytes (204 8 * 3 bytes).
  • the Aligned unit starts from the first byte of the source packet.
  • the source packet is 192 bytes long.
  • One source packet is composed of TP_extra_header, transport knob, and software.
  • TP_extra_headery is 4 bytes long, and the transport packet is 188 bytes long.
  • One Aligned unit is composed of 32 source packets.
  • the last Aligned unit in the DVR MPEG 2 transport stream also consists of 32 source packets.
  • the file system shall not add extra information to the DVR MPEG 2 transport stream.
  • Figure 83 shows the recorder model of the DVR MPEG-2 transport stream.
  • the recorder shown in Figure 83 is a conceptual model for specifying the recording process.
  • the DVR MPEG-2 transport stream follows this model.
  • the input MPE G2 transport stream is a full transport stream or a partial transport stream.
  • the MPEG2 transport stream to be input is ISO / IEC 138 188-1 or ISO / IEC 138 You must follow 1 8 -9.
  • the i-th byte of the MPEG-2 transport stream is transmitted to the T-STD (Transport stream system target decoder specified in ISO / IEC13818_l) and the source decoder. Input simultaneously at time t (i).
  • Rpk is the instantaneous maximum value of the input rate of the transport packet.
  • the 27 MHz PLL 52 generates a frequency of 27 MHz clock.
  • the frequency of the 27 MHz clock is locked to the value of the PCR (Program Clock Reference) of the MPEG-2 transport stream.
  • the arrival time clock counter 53 is a binary counter that counts pulses at a frequency of 27 MHz.
  • Arrival time_clock (i) is the count value of the Arrival time clock counter at time t (i).
  • Arrival_time-stamp represents the time at which the first byte of the transport packet arrives at both the TSTD and the source packet.
  • the difference between the arrival_time_stamp of the two transport packets is 230/27000000 Should be set to seconds.
  • the recorder is prepared for such a case.
  • the smoothing buffer 55 smoothes the beam trades of the input transport stream.
  • the smoothing buffer must not overflow.
  • Rmax is the output bit rate of the source packet from the smoothing buffer when the smoothing buffer is not empty. When the smoothing buffer is empty, the output bit rate from the smoothing buffer is zero.
  • Rmax is given by the TS recording rate defined in ClipInfo () corresponding to the AV stream file. This value is It is calculated by the following equation.
  • TS_recording_rate is in units of bytes / second.
  • Rpk must be equal to TS_re cording_rate defined in ClipInfo () corresponding to the AV stream file. If the input transport stream is not a SESF transport stream, this value refers to the MPEG-2 transport stream descriptor, for example, the value defined in maximum-bitrate one descriptor, partial-wake sport_stream am_descriptor, etc. May be.
  • the smoothing buffer size is 0 if the input transport stream is a SESF transport stream. If the input transport stream is not a SESF transport stream, the size of the smoothing buffer is the MPEG-2 transport stream descriptor, for example, smoothing—buffer—descriptor short—smoothing—buffer_descriptor, partial_t ransport—stream—descriptor For example, you may refer to a value defined as:
  • FIG. 84 is a diagram showing a player model of the DVR MPEG-2 transport stream. This is a conceptual model for specifying the regeneration process.
  • the DVR MPEG-2 transport stream follows this model ⁇
  • the arrival time clock counter 62 is a binary counter that counts pulses at a frequency of 27 MHz.
  • Arrival—time—clock (i) is the count value of the Arrival time clock counter at time t (i).
  • Rmax is the input bit rate of the source packet to the smoothing buffer when the smoothing buffer is not full. When the smoothing buffer is full, the input bit rate to the smoothing buffer is The default is 0.
  • the arrival-tinie_stamp of the current source packet is equal to the value of the LSB 30-bit of the arrival-time-ciock (i).
  • Transport packets are withdrawn from the smoothing buffer.
  • Rpk is the instantaneous maximum value of the transport packet rate.
  • the smoothing buffer must not underflow.
  • the parameters of the player model of the DVR MPEG-2 transport stream are the same as those of the recorder model of the DVR MPEG-2 transport stream described above.
  • FIG. 85 is a diagram illustrating the syntax of the source packet.
  • transport_packet () is an MPEG-2 transport packet defined by IS0 / IEC138818-1.
  • Fig. 86 shows the syntax of TP_Extra_header in the syntax of the source packet shown in Fig. 85.
  • copy_peruiission_indicator is an integer representing the copy restriction of the pay mouth of the transport packet. The copy restrictions can be copy free, no more copy, copy once ⁇ , or copy prohibited.
  • FIG. 87 shows the relationship between the values of (1) copy_permission_indicator and the mode specified by them.
  • copy_per nission_iiidicator is added to all transport packets.
  • the copy—permission—indicator value is associated with the EMI (Encryption Mode Indicator) value in the IEEE1394 isochronous packet header. Is also good.
  • the value of the copy_permission-indicator may be associated with the value of the CCI embedded in the transport packet.
  • the value of copy_permission_indicator may be associated with the CGMS-A value of the analog signal.
  • arrival time_stamp (k) arrival time clock (K% 230 Is an integer value with the value specified by tiiie_stamp.
  • the Clip AV stream In order to define a Clip AV stream, the Clip AV stream must have the structure of a DVR MPEG-2 transport stream as defined above. arriva time_clock (i) must increase continuously in the Clip AV stream. Even if there is a discontinuity of the system time base (STC base) in the Clip AV stream, the air time and clock (i) of the Clip AV stream must increase continuously.
  • STC base system time base
  • the maximum value of the difference between arrival_time and clock (i) between the start and end in the Clip AV stream shall be 26 hours.
  • the limitation is that if there is no system time base (STC based) discontinuity in the MPEG2 transport stream, the same value of PTS (Presentation Time Stamp) in the Clip AV stream will never occur. Guarantee not to appear.
  • STC based system time base
  • PTS Presentation Time Stamp
  • the MPEG2 Systems standard specifies that the PTS live-around period is 233 / 90,000 seconds (approximately 26.5 hours).
  • the Bridge-Clip AV stream In order to define the Bridge-Clip AV stream, the Bridge-Clip AV stream must have the structure of the DVR MPEG-2 transport stream as defined above.
  • the Bridge-Clip AV stream must contain one arrival time base discontinuity.
  • the transport stream before and after the discontinuity of the arrival time pace must conform to the encoding restrictions described later, and must conform to DVR-STD described later.
  • This example supports seamless video and audio connections between Playltems in editing. Making a seamless connection between Playltems guarantees “continuous supply of data” and “seamless decoding" to the player / recorder. "Continuous supply of data” means that the file system can guarantee that the decoder supplies data at the required bit rate so as not to cause the buffer to underflow. Ensure that the data is stored in large blocks of contiguous blocks so that the data can be read from disk, ensuring the real-time performance of the data.
  • “Seamless decoding” means that a player can play back audio-video data recorded on a disc without causing pauses and gaps in the playback output of the decoder. It can be displayed.
  • the AV stream referred to by the seamlessly connected Playltem will be described. Whether the connection between the preceding Playltem and the current Playltem is guaranteed to allow seamless display can be determined from the connection_condition field defined in the current Playltem.
  • the seamless connection between Playltems can be done with or without Bridge-Clip.
  • FIG. 88 shows the relationship between the preceding Playltem and the current Playltem when using Bridge-Clip.
  • stream data read by the player is shown with a shadow.
  • TS 1 shown in Fig. 88 is composed of stream data shaded by Cl ipl (Cl ip AV stream) and stream shaded before RS-PN_arrival_time_discontinuity of Bridge-Cl ip. Become.
  • the TS 1 Clipl shaded stream data is derived from the stream address needed to decode the presentation unit corresponding to the preceding Playltem IN-time (illustrated as IN_timel in Figure 88).
  • RSPN_exit from _previous—Stream to the source packet referenced by Clip.
  • the shaded stream data before the RSPN—arrival—time_discontinuity of the Bridge-Clip included in TS 1 is referenced by the RSPN—arrival and time—discontinuity from the first source packet of the Bridge-Clip. Stream data up to the source packet immediately before the source packet to be transmitted.
  • TS 2 in Fig. 88 is based on the stream data shaded by Cl ip2 (Cl ip AV stream) and the stream data shaded after time_discontinuity after RSPN_arriva of Bridge-Cl ip. Become.
  • the shaded stream data after the RSP N_arrival_time—discontinuity of the Bridge-Clip included in TS 2 is obtained from the source packet referenced by RSPN—arrival—time—discontinuity. This is stream data up to the source packet.
  • the stream data shaded by TS 2 Cl ip2 is from the source packet referenced by RSPN—enter_to_current_Clip to the current PlayItem OUT—time (illustrated as 0IIT_tinie2 in FIG. 88). This is the stream data up to the address of the stream required to decode the corresponding presentation unit.
  • FIG. 89 shows the relationship between the preceding Playltem and the current Playlte in when the Bridge-Clip is not used. In this case, the stream data read by the player is shown with a shadow.
  • TS1 in FIG. 89 is composed of stream data with a shadow of Clipl (Clip AV stream).
  • the TS1 Clipl shaded stream data is the stream needed to decode the presentation unit corresponding to the preceding Playltem IN_time (illustrated as IN_timel in Figure 89).
  • the data starting from the address of the Clipl to the last source packet of the Clipl. S2 in FIG. 89 is composed of a stream data with a shadow of Clip2 (Clip AV stream).
  • the shaded stream data of Clip2 of TS2 starts with the first source packet of Clip2 and decodes the presentation unit corresponding to the current Playltem's 0UT_time (illustrated as 0UT_time2 in Figure 89). This is a stream to the stream address necessary for the stream.
  • the dashes 31 and 32 are continuous streams of the source packet.
  • the stream specifications of T S1 and T S2 and the connection conditions between them are considered.
  • the number of programs included in the avenues 31 and 32 must be one.
  • the number of video streams contained in 31 and 32 must be one.
  • the number of audio streams contained in 31 and 32 should not be more than two.
  • the number of audio streams contained in T S1 and T S2 must be equal.
  • T S1 and Z or T S2 an elementary stream other than the above or a private stream may be included.
  • FIG. 90 is a diagram showing an example of seamless connection shown in the display order of pictures. Unnecessary pictures displayed after 0UT_timel (0UT_tiine of Clipl) and before IN_time2 (IN_time of CI ip2) are required for the seamless display of the video stream at the connection point. It must be removed by the process of re-encoding a partial stream.
  • FIG. 91 shows an example in which seamless connection is realized using BridgeSequence in the case shown in FIG.
  • the bridge-clipped video stream before the RSPN_arrival-time discontinuity consists of the coded video stream up to the picture corresponding to the Cl-ipl OUT-timel in Fig. 90. Then, the video stream is connected to the preceding Clipl video stream, and re-encoded so as to become an elementary stream according to the MPEG 2 standard in one continuous stream.
  • the video stream of Bridge-Clip after RSPN_arrival-time-discontinuity consists of the coded video stream after the picture corresponding to IN-time2 of Cl ip2 in FIG. Then, the video stream can start decoding correctly, is connected to the subsequent Clip2 video stream, and is re-encoded so as to be an elementary stream according to the MPEG 2 standard in one continuous stream. I have. In order to make a Bridge-Clip, a few pictures generally have to be re-encoded, and the other pictures can be copied from the original Clip.
  • FIG. 92 shows an example in which seamless connection is realized without using BridgeSequence in the case of the example shown in FIG.
  • the Clipl video stream consists of the coded video stream up to the picture corresponding to 0UT_timel in Fig. 90, which is re-encoded into one continuous elementary stream according to the MPEG2 standard. I have.
  • the video stream of Cl ip2 consists of an encoded video stream after the picture corresponding to IN_time2 of Cl ip2 in Fig. 90, and it is an elementary stream according to the MPEG 2 standard in one continuous stream. It has been re-encoded.
  • the frame rates of the video streams in the sections 31 and 32 must be equal.
  • the video stream of TS1 must end with sequence_end_code.
  • the TS2 video stream must start with a Sequence Header, a GOP Header ⁇ and an I-picture.
  • the TS2 video stream must start with a closed GOP.
  • Video presentation unit (frame) defined in the bitstream Or field) must be continuous across the connection point. There must be no frame or field gaps at the connection points. At the junction, the toe bottom field sequence must be continuous. For encoding using 3-2 pulldown, the "top_field—first” and “repeat_first--field” flags may need to be rewritten, or re-encoded locally to prevent field gaps from occurring. You may do so.
  • the audio sampling frequencies of T S1 and T S2 must be the same.
  • the encoding method for TS1 and TS2 audio eg, MPEG1 Layer 2, AC-3, SESFLPCM, AAC must be the same.
  • the last audio frame of the audio stream of TS1 has the same display time at the end of the display of the last display picture of TS1.
  • the first audio frame of the TS2 audio stream must contain audio samples with a display time equal to the beginning of the display battle of the first display picture of TS2.
  • the first packet transmitting the TS2 elementary stream must be a video packet.
  • the transport stream at the connection point must follow DVR-STD described later.
  • T S1 and T S2 must not include an arrival time base discontinuity in each.
  • Bridge-Clip Only at the junction of the last source packet of TS1 and the first source packet of TS2, the Bridge-Clip AV stream has only one arrival time base discontinuity.
  • RSPN defined in ClipInfo () — arrival time_discontinuity indicates the address of the discontinuity, which is the address that refers to the first source packet of TS2 Must be indicated.
  • the source packet referenced by RSPN—exit—from one previous—CI ip defined in Bridge Sequence Info () may be any source packet in Cl ipl. It does not need to be the boundary of an aligned unit.
  • the source packet referred to by RSPN_ente to_currentJUip defined in BridgeSequenceInfo () may be any source packet in C1 ip2. It does not need to be the boundary of an Aligned unit.
  • the preceding Playltem ⁇ —time (OUT_tiniel shown in FIGS. 88 and 89) must indicate the display end time of the last video presentation unit of TS1.
  • the IN_time of the current Playltem (IN_time2 shown in FIGS. 88 and 89) shall indicate the display start time of the first video presentation unit of TS2.
  • RSPN—exit—from_previous_C lip RSPN_exit_from—previous_Cl ip is selected so that the stream portion of the Cl ipl (Cl ip AV stream file) before it is located in a continuous area that is equal to or greater than a half fragment. There must be.
  • the length of the Bridge-Clip AV stream must be selected so that it is located in a contiguous area of half a fragment or more.
  • RSPN_enter_to_current_Clip must be selected so that the stream portion of Cl ip2 (Cl ip AV stream file) after RSPN—enter—to_current_Clip is located in a continuous area of half a fragment or more.
  • the last stream part of Clipl (Clip AV stream file) must be located in a continuous area equal to or greater than half fragment.
  • the first stream part of Clip2 (Clip AV stream file) must be located in a contiguous area of half fragment or more.
  • DVR—STD is a conceptual model for modeling the decoding process when generating and verifying the DVR MPE G2 transport stream.
  • the DVR-STD is also a conceptual model for modeling a decoding process in generating and verifying an AV stream referred to by the two seamlessly connected Playltems described above.
  • Figure 96 shows the DVR-STD model.
  • the DVR MPEG-2 transport stream player model is included as a component 0 ⁇ , ⁇ , ⁇ , EBn, TBsys, Bsys, Rxn, Rbxn, Rxsys, Dn, Dsys , On, and Pn (k) are represented in the same way as defined in T-STD of ISO / IEC 138 18-1. That is, it is as follows.
  • n is the index number of the element list stream.
  • TBn is a transport buffer for elementary stream n.
  • MBn is a multiplex buffer for element list stream n. Only present for video streams.
  • EBn is an elementary evening list buffer for elementary evening stream n. Only present for video streams.
  • TBsys is the input buffer for the system information of the program being decrypted.
  • Bsys is a main buffer in the system gate decoder for system information of the program being decoded.
  • Rxn is the transmission rate at which data is stripped from TBn.
  • Rbxn is a transmission rate at which the PES packet payload is removed from MBn. Only present for video streams.
  • Rxsys is the transmission rate at which data is removed from TBsys.
  • Dn is the decoder for element list n.
  • Dsys provides the system information of the program being decrypted Decoder.
  • On is the reordering buffer of video stream n ⁇ Pn (k) is the k-th presentation unit of elementary stream n,
  • DVR Describe the STD decoding process. While playing back a single DVR MPEG-2 transport stream, the timing of inputting a transport packet to the TB1, TBn or TBsys buffer is determined by the arrival_time—stamp of the source packet .
  • the specification of the buffering operation of TBI, MBl, EBl, TBn, Bn, Bsys, and TBsys is the same as that of TSTD specified in IS OZI E 138 188-1.
  • the specifications of the decoding operation and the display operation are also the same as the T-STD specified in IS0 / 1EC13818-1.
  • the playback of two AV streams referred to by the seamlessly connected Playltem will be described.
  • the playback of TS1 and TS2 described above will be described. Will be described.
  • T S1 is the preceding stream and T S2 is the current stream.
  • Figure 97 shows a timing chart of input, decoding, and display of a transport packet when moving from one AV stream (TS 1) to the next AV stream (TS 2) that is seamlessly connected to it. Show. During the transition from a given AV stream (TS1) to the next AV stream (TS2) that is seamlessly connected to it, the time axis of the TS2's arrival time base (ATC2 in Figure 97). Is not the same as the time axis of the arrival time base of TS 1 (indicated by ATC 1 in FIG. 97).
  • the time axis of the system time base of TS 2 (indicated by STC 2 in FIG. 97) is not the same as the time axis of the system time base of TS 1 (indicated by ST C 1 in FIG. 97).
  • Video display must be seamless and continuous. There may be overlap in the presentation time of the audio presentation unit.
  • the input timing to DVR-STD is explained. Until the time until time T1, that is, until the last video packet of TS1 has been input to TB1 of DVR-STD, the input timing to the buffer of TB1, TBn or TBsys of DVR-STD is completed. The packet is determined by the arrival_tiine_stamp of the source packet of TS1.
  • T S1 The remaining packets of T S1 must be input to the DVR_STD TBn or TBsys buffer at a bit rate of TS_recording-rate (T S1).
  • TS_recording_rate (TS1) is a value of TS_recording-rate defined in ClipInfo () corresponding to Clipl.
  • the time at which the last byte of T S1 enters the buffer is time T2. Therefore, in the section from time T1 to T2, arrival-time-stamp of the source packet is ignored.
  • N1 is the number of transport packet bytes of TS1 following the last video packet of TS1
  • the time DT1 from time T1 to T2 is N1 bytes at the bit rate of TS_recording_rate (TS1). This is the time required to complete the input, and is calculated by the following equation.
  • the arrival time clock counter is reset to the value of arrival-time_stafflp of the first source packet of TS2.
  • the input timing to the DVR-STD TB1, TBn or TBsys buffer is determined by the TS_2 source packet arrival_time_stamp. Both n and RXsys change to the values defined in T-STD.
  • the audio decoder and the system decoder should be able to process the input buffer in the interval from time T1 to T2 so that T_S In addition to the buffer amount defined by TD, an additional buffer amount (about 1 second worth of data) is required.
  • STC 1 is the time axis of the system time base of TS 1 (illustrated as STC 1 in FIG. 97)
  • STC 2 is the time axis of the system time base of TS 2 (STC 2 in FIG. 97).
  • STC 2 is The battle begins at the time when the first PCR of TS 2 enters the T-STD. ).
  • the offset between STC1 and STC2 is determined as follows.
  • PTSlend is the PTS on STC1 corresponding to the last video presentation unit of TS1
  • PTS2start is the PTS on STC2 corresponding to the first video presentation unit of TS2
  • Tpp is Assuming that the display period of the last video presentation unit of TS 1 is, an offset STC_delta between two system time paces is calculated by the following equation.
  • the DVR-STD switches the system time clock between the old time base value (STC 1) and the new time base value (ST C 2).
  • STC 1 old time base value
  • ST C 2 new time base value
  • STCllvideo_end is the value of STC on the system time base STC1 when the last byte of the last video packet of TS1 arrives at TB1 of DVR-STD.
  • STC22video_start is the value of STC on the system time base STC2 when the first byte of the first video packet of TS2 arrives at TB1 of the DVR-STD.
  • STC21video_end is a value obtained by converting the value of STCllvideo_end into a value on the system time base STC2 ( STC21video_end is calculated by the following equation.
  • STC21video one end STCllvideo— end ⁇ STC— delta
  • the arrival timing of the first video packet of TS2 at TB1 must satisfy the following inequality. And the following inequality must be satisfied.
  • the contents of data recorded on the recording medium, reproduction information, and the like can be appropriately managed, so that the user can appropriately record on the recording medium during reproduction. It is possible to confirm the contents of the data being stored and to easily reproduce the desired data.
  • time_controlled_flag indicates that the elapsed time of the AV stream and the amount of bytes of the AV stream have the following relationship. That is, it is ensured that the relationship between the time lapse of the AV stream and the amount of data bytes of the AV stream is proportional within a predetermined error range.
  • Equation (1) The above equation is a little different from the equation shown in the description of time_controlled_flag of Cliplnfo in FIG. 46, but is essentially the same.
  • TS_average rate is the AV stream file (DVR transport).
  • the average bit rate of the stream file is expressed in the unit of bytes / second, and is indicated by the field of the same name in Cliplnfo.
  • t indicates the elapsed time of the arrival lime pace from the first source packet of the AV stream file in seconds.
  • AV—file_size (t) represents the size of the AV stream file at time 7 in bytes.
  • ⁇ is a predetermined constant value, for example, 300 seconds.
  • TS_average_rate is determined to a predetermined value by the application of the recorder.
  • the TS average_rate value for each mode is determined according to the recording mode, such as long-time recording mode (LP mode), standard recording mode (SP mode), or high-quality recording mode (HQ mode).
  • LP mode long-time recording mode
  • SP mode standard recording mode
  • HQ mode high-quality recording mode
  • FIG. 98 shows the case where the variable bit rate is controlled so that the relationship between the time lapse of the AV stream and the amount of data bytes of the AV stream is proportional within a predetermined error range.
  • FIG. 3 is a block diagram illustrating an operation of an AV encoder 15 of the recording / reproducing apparatus 1.
  • the blocks with the same numbers are the same.
  • the user inputs a recording mode such as LP mode or SP mode to the control unit 23 through the user interface 24.
  • the control unit 23 sets the multiplex bit rate of the AV stream (DVR transport stream) to be recorded and the average bit rate of video coding according to the recording mode (see step S 20 in the flowchart of FIG. 99). ).
  • the control unit 23 sets the time_control_flag to 1, sets the average bit rate of the multiplexed stream to TS_average__rate, and sets the multiplexed bit rate to TS_recording_rate.
  • the control unit 23 outputs the database of the Cl ip Information file in which time control led_flag, TS_recording_rate and TS_average_rate are set to Cl iplnfo. Power.
  • the Clip Information file is recorded on the recording medium through the processing of the ECC encoder 20 as described in FIG.
  • video When encoding analog video input, video is input from terminal 11. Or, when transcoding a digital broadcast input video, the video from the AV decoder 27 is input. Input video is input to video encoder 15 1.
  • the control unit 23 calculates the amount of coded bits to be allocated to the video per predetermined time, and designates it to the video encoder.
  • the video encoder 115 encodes video per predetermined time and inputs an actually generated encoded bit amount to the control unit 23.
  • the size of the predetermined time is the GOP of the video, which is 0.5 second.
  • the control unit 23 calculates the elapsed time of the AV stream and the amount of data bytes of the AV stream based on the cumulative value of the actually generated encoded bits input from the encoder after the start of encoding.
  • variable bit rate of video coding is controlled so that the relationship is proportional within a predetermined error range, and the amount of coding bits to be allocated to video for the next predetermined time is calculated.
  • the control unit 23 may be supplied with the video encoding difficulty (the magnitude of the prediction residual of the motion vector prediction, the magnitude of the quantization scale of the DCT coefficient, etc.) from the encoder. If possible, a higher quality variable bit rate can be realized. That is, control is performed such that the higher the video coding difficulty level, the larger the amount of coded bits allocated to video per predetermined time.
  • the video encoder 115 inputs the video stream to the multiplexer 16.
  • the audio stream and system information (S) such as AV synchronization are also input to the multiplexer 16.
  • the flow of the audio input encoding process and the system information (S) such as AV synchronization are the same as those described in FIG.
  • the multiplexer 16 multiplexes the video and audio streams into a transport stream having a predetermined multiplex bit rate.
  • video and audio packetization must be controlled so as not to break down the system evening decoder (T-STD) of the MPEG-2 transport stream. Due to T-STD restrictions, video access units (coded I, P, B pictures) and audio access units (audio frames) are packetized.
  • the multiplexer 16 performs multiplexing so as not to generate a null packet (a packet having a packet ID of OxlFFF). Due to this multiplexing control, the time interval between successive transport packets becomes irregular, and packets occur intermittently.
  • the transport packet output from the multiplexer 16 is input to the source packetizer 19.
  • the source packetizer 19 adds an arrival time stamp to each transport packet and converts it into a source packet. Then, the source stream string is left-justified, and an AV stream file is generated.
  • the AV stream file is recorded on the recording medium through the processing of the ECC encoding unit 20 as described with reference to FIG.
  • 5 is a flowchart illustrating an operation of recording an AV stream by performing bit rate encoding.
  • step S20 the control unit 23 sets the multiplex bit rate TS_recording-rate of the transport stream and the average bit rate of video encoding.
  • the average bit rate of video coding is a value obtained by subtracting a constant bit rate of audio coding and a bit rate of over-multiplexing from TS_average_rate.
  • TS_average-rate is determined to a predetermined value by the application of the recorder (LP, SP mode, etc.).
  • TS_recording_rate is a value greater than the maximum bit rate of variable bit rate coding of video plus the fixed bit rate of audio coding and the bit rate of multiplexing overhead.
  • step S21 the control unit 23 encodes the video stream so as to encode the video stream at a variable bit rate so that a predetermined average bit rate is guaranteed at predetermined time intervals. Control one.
  • step S22 the control unit 23 controls the multiplexer 16 so as not to generate a null packet when there is no elementary stream to be transported.
  • the control unit 23 controls the multiplexer 16 so as not to generate a null packet when there is no elementary stream to be transported.
  • step S23 the control unit 23 controls the source packet analyzer 19 so as to add an arrival time stamp to each transport packet and to convert the source packet into a source packet. Control to record as AV stream file.
  • VBV Vide 0 Buffering Verifier
  • the MPEG video encoder must encode the video stream for VBV to work properly. This limits the encoding method (mainly the quantization control and the bit amount of the picture).
  • the buffer that VBV has is called a VBV buffer. This is the minimum required buffer size in theory for a real decoder. In the case of the MPEG 2 main profile main level, the VBV buffer size is 1.75 Mbits.
  • FIG. 101 In general, the method shown in FIG. 101 is widely known for VBV of MPEG at a variable bit rate. That is, in FIG. 101, when the VB V buffer has a free space, the input bit rate to the buffer is the maximum bit rate of VBR (Variable Bit Rate).
  • FIG. 7 is a diagram for explaining VBV control when the bit rate of input to the buffer becomes 0 when the bit occupancy of the VBV buffer is full.
  • the slope of the upward-sloping line indicates the maximum bit rate of the VBR, and when there is a vacancy in the VBV buffer, the buffer occupancy increases at the maximum bit rate of the VBR.
  • the bit occupancy of the VBV buffer is full, the input bit rate to the buffer becomes 0, and the buffer occupancy does not change.
  • the horizontal axis is the time axis, and T1 indicates one decoding time.
  • T1 indicates one decoding time.
  • the picture at the time T1 shown in the figure is instantaneously decoded, and the buffer occupancy decreases. Thereafter, in a similar manner at predetermined time intervals, the picture is decoded, and the buffer occupancy is reduced.
  • the video encoder does not generate a swimming byte during the video stream.
  • VB V is controlled as shown in FIG. Sand That is, at a variable bit rate that changes the bit rate every predetermined time (for example, GOP), VBV control of CBR (Constant Bit-Rate, fixed bit rate) is performed within the predetermined time.
  • FIG. 102 shows VBV control in the case of CBR within a GOP (eg, a 0.5 second video sequence). That is, FIG. 4 is a diagram illustrating VBV control when the input bit rate to the VBV buffer is the current G0P encoding bit rate and a scanning byte is inserted so that the VBV buffer does not overflow. .
  • VBV— BUFFER_SIZE 1.75 * 1024 * 1024 bit
  • gop_bit_rate Bit rate for each GOP [bit / second]
  • the picture at time d1 in FIG. 102 will be described as an example.
  • the bit occupancy vbvj) of the VBV buffer immediately before the VBV decodes the picture at time d 1 is obtained.
  • the bit amount input at the bit rate gop_bit—rate is added to the bit occupation amount vbv—b from the time d1 to the decod time d2 of the next picture (tau).
  • tmp the minimum bit amount of a picture to be coded
  • min_picture_bit can be calculated from tmp and VBV_BUFFER_SIZE as follows.
  • nui_stuff ing_byte (min_picture bit-gen picture_bit + 4) / 8
  • the input bit rate to the VBV buffer is set to the code of the current GOP.
  • the video encoder generates a scanning byte so that the VBV buffer does not overflow.
  • the VBV control shown in FIG. 102 is a concept of the present invention, in which the relationship between the time lapse of the AV stream and the amount of data bytes of the AV stream is within a predetermined error range as shown in FIG. It is effective to guarantee that it is proportional to When the VBV control shown in FIG. 101 is used, if there is a long-time still image in the input video, the relationship of FIG. 103 cannot be guaranteed. That is, since the amount of information in a still image is relatively small, even if the amount of bits allocated for encoding is larger than the amount of information, the amount of bits actually generated by encoding is saturated to a relatively small value. .
  • the relationship between the time lapse of the A stream and the amount of data bits of the AV stream is not proportional, as shown in FIG.
  • the VBV control shown in FIG. 102 the input video to the VBV buffer is controlled for the purpose of controlling the video encoder to use the bit amount allocated to the video for a predetermined time.
  • the rate is the current GOP coding bit trade, and the video encoder generates a scanning byte so that the VBV buffer does not overflow, so the relationship between the time lapse of the AV stream and the amount of data bytes of the AV stream is As shown in FIG. 103, it can be guaranteed that the values are approximately proportional within a predetermined error range.
  • FIG. 105 is a flowchart for explaining the details of the video variable bit rate control process in the above-described process of step S21 in FIG. 01/82605 I
  • step S200 the initial value SV1 is set in the VBR margin sv_now.
  • the VBR margin sv_now is The control is performed so that the maximum value becomes SVMAX from 0.
  • the average coding bit rate of the video is the value determined in step S20 in FIG. 99 (see FIG. 107).
  • step S201 it is checked whether or not the following inequality holds in c step S202 in which the allocation map b_alloc of the current GOP is calculated.
  • step Si This step Si; ⁇ ⁇ ⁇ ⁇ It is a check to see if the VBR margin becomes negative.
  • b-av is the average value of the allocated bit amount of GOP; i encoding, which is calculated from the average encoding bit rate of video. Assuming that the time length of the GOP is 0.5: I, b_av is the following value.
  • step S202 If Yes in step S202, the process proceeds to step S203. If No in step S02, the process proceeds to step S204, b_alloc is set to b_av, and the process proceeds to step ': 205.
  • step S203 it is checked whether the following inequality holds.
  • This step :: 1 checks whether the VBR margin does not exceed the maximum value SVMAX.
  • step S203 the process proceeds to step S205. If No in step 03, the process proceeds to step S204, where b_alloc is set to b_av, and the process proceeds to steps 205 and 205.
  • step S205 the current GOP is encoded. Then, the current G is encoded with the allocated bit amount b-alloc, and the VB V control at that time is as follows: the input bit rate to the V: E buffer is set to the coding bit rate of the current GOP, and V r Control to insert stuffing bytes so that the buffer does not overflow. Details of this processing will be described with reference to FIG.
  • step S206 the margin sv_now of VBR is updated as in the following equation.
  • b_gen is the current G ⁇ P encoded bit amount obtained as a result of encoding the current G0P in step S205.
  • step S207 it is checked whether the current GOP is the last GOP. If Yes in step S207, the process ends. If No in step S207, the process returns to step S201.
  • FIG. 106 is a flowchart illustrating details of the VBV control process in the process of step S205 in FIG. 105 described above.
  • step S300 the coded bit amount allocated to the current GOP is converted into a coded bit rate gopjDit-rate as in the following equation.
  • gop—bit—rate b—alloc / (15 / 29.97)
  • step S301 the minimum bit amount min_picture1 bit of the picture currently coded in the current GOP is calculated by the following equation.
  • iin_picture_bit tip-VBV_BUFFER_SIZE
  • vbvj is the bit occupancy of the VBV buffer immediately before the VBV decodes the picture to be currently encoded (see FIG. 102).
  • tau is the difference between the decoding time of the picture to be currently encoded and the decoding time of the next picture (see Fig. 102).
  • VBV—BUFFER—SIZE is the VBV buffer size, which is 1.75 Mbit for MPEG 2 MP @ ML.
  • step S302 the current picture is encoded, and the generated bit amount gen_picture—bit is obtained.
  • step S303 the following inequality is checked.
  • step S303 If Yes in step S303, the process proceeds to step S304. Step S 3 If No in 03, go to step S305.
  • step S304 the video encoder currently encodes the num-stuffing-byte number of bytes after the currently encoded picture, and appends them to the end of the encoded picture (Fig. 102). See).
  • num_stufnng_byte (min_picture_t) it-gen_picture_bit + 4) / 8
  • step S305 it is checked whether or not the picture is the last picture of GOP. In step S305, in the case of Yes, the process ends. If No in step S305, the process returns to step S301.
  • the relationship between the time lapse of the AV stream and the amount of data bytes of the AV stream is within a predetermined error range. Can be guaranteed to be proportional within By this means, if a stream is partially erased for a certain time of the stream, it is possible to guarantee that an empty area recordable at the bit rate indicated by TS_average_rate of the stream can be created on the disk for the erased time.
  • the AV stream therein generally has a variable bit rate. In general, it is not guaranteed that the relationship between the time lapse of the AV stream and the amount of data bytes of the AV stream is proportional. In this case, when the AV stream is transparently recorded and the Cl ip is created, Set time_control led — flag to 0
  • the video stream is set to be equal to or less than a predetermined average bit rate for each predetermined time interval set in advance.
  • encoding is performed at a variable bit rate. This is because the VBV control of video coding, as explained in FIG. If there is room in the buffer, set the input bit rate to the buffer to the maximum bit rate of the Variable Bit Rate, and if the bit occupancy of the VB V buffer is full, input the bit rate to the buffer. This is the case when the trait is set to 0.
  • the recording method of the AV stream in this case will be described with reference to FIG. 108 and FIG.
  • 5 is a flowchart illustrating an operation of recording an AV stream.
  • step S400 Except for step S400, it is the same as FIG. 99.
  • step S400 the video encoder 1515 is controlled so that the video stream is encoded at a variable bit rate such that the video stream is equal to or less than a predetermined average bit rate for each predetermined time interval.
  • FIG. 109 is a flowchart for explaining the details of the video variable bit rate control process in the process of step S400 in FIG. 108 described above.
  • step S500 the initial value SV1 is set in the margin sv_now of VBR.
  • the variable bit rate control is performed such that the VBR margin sv_now does not become a negative value.
  • step S501 an allocation allocation b_alloc of the current GOP is calculated.
  • step S502 it is checked whether the following inequality holds. This step S is a check to determine whether or not the excess amount of VBR becomes negative.
  • ID-av is the average value of the allocated bit amount of encoding per GOP, calculated from the average encoding bit rate of video. Assuming that the time length of the GOP is 0.5 seconds, b_av is the following value.
  • step S502 the process proceeds to step S504. If No in step S502, the process advances to step S504 to set b_alloc to b_av, and the process advances to step S504.
  • step S504 the current GOP is entered. And the current GO P Is encoded by the allocated bit amount b_alloc, and the VBV control at that time is based on VBV (Variable Bit-Rate) when the VBV buffer has free space.
  • VBV Very Bit-Rate
  • VBV control is performed to set the input bit rate to the buffer to 0 (see FIG. 101).
  • a video byte is not encoded with a short byte.
  • step S505 the VBR margin sv_now is updated as in the following equation.
  • b_gen is the encoded bit amount of the current GOP obtained as a result of encoding the current GOP in step S504.
  • step S506 it is checked whether the current GOP is the last G ⁇ P. If Yes in step S 506, the process ends. If No in step S506, the process returns to step S501.
  • the relationship between the elapsed time of the AV stream and the amount of data bytes of the AV stream is proportional within a predetermined error range. For example, if there is a long-time still image in the input video, the relationship between the time lapse of the stream and the amount of data bytes of the AV stream is as shown in FIG. That is, since the amount of information in a still image is relatively small, even if the amount of bits allocated for encoding is larger than the amount of information, the amount of bits actually generated by encoding is saturated to a relatively small value. . Therefore, in this case, the relationship between the time lapse of the AV stream and the amount of data bytes of the AV stream is not uniform.
  • the input bit rate to the VBV buffer is the current encoding bit rate of the GOP, and the VBV buffer does not overflow. If the video encoder is controlled so as to generate stuffing bytes, it can be ensured that the relationship between the time lapse of the AV stream and the amount of data bytes of the AV stream is substantially proportional within a predetermined error range.
  • the relationship between the elapsed time of the AV stream and the amount of data bytes of the AV stream Is the encoding mode (time—conti> oI
  • time—conti> oI As a method of easily realizing this, it is conceivable to record a transport stream of a constant bit rate by inserting a null packet when multiplexing the transport stream.
  • This is an encoding method mainly used for tape recording media (D-VHS, etc.).
  • a null packet is a transport packet whose packet ID (PID) is set to Ox1FFF and has no meaning as information.
  • FIG. 110 encodes a transport stream of a predetermined constant bit rate, thereby estimating the time lapse of the AV stream and the data stream of the AV stream.
  • the flowchart of the encoding mode which guarantees that the relationship with the amount of bytes is proportional is shown.
  • step S600 the multiplex bit rate of the transport stream and the bit rate of the video encoding are set.
  • step S601 the video stream is set to a predetermined constant bit rate, or Encode at the bit rate or less.
  • step S602 when there is no elementary stream to be converted into a transport packet, a null packet (a transport packet having no meaning as information) is generated and multiplexed, and a predetermined constant Encode a multiplex bit rate transport stream.
  • a null packet a transport packet having no meaning as information
  • step S603 an arrival time stamp is added to each transport packet to make a source packet. Record the source packet on the recording medium.
  • the time—control led_flag of the Cl ip is set to 1.
  • this method uses a null packet and does not efficiently use code bits for video encoding, there is a problem that the video quality is inferior to the encoding method of FIG. Is described in detail in, for example, the section of the prior art in Japanese Patent Application No. 11-22027). Therefore, the recording method of FIG. 110 is not recommended in the present invention.
  • FIG. 11 shows an example of an original AV stream file and an AV stream file after editing to delete a stream in a partial playback range of the original stream.
  • the Virtual PlayList points to IN-time and 0UT_time on the original AV stream.
  • an edit minimize edit
  • the data from the beginning of the original AV stream to point X and the data from point Y to end are erased.
  • FIG. 112 is a diagram for explaining a method of deleting unnecessary data before the IN point without analyzing the contents of the AV stream.
  • PlayList points to the IN point on the original AV stream.
  • EPjnap of the AV stream is shown.
  • RSPN_EP_start PTS for ISA1 is ptsl
  • RSPN_EP—start PTS for ISA2 is pts2. If the time difference between the system timings of ptsl and pts2 is 100 ms or more, there are PAT, PMT and PCR packets between addresses ISA1 and ISA2 (at least for SESF, DVB, ATSC and ISDB). is there) .
  • the X point is determined before address ISA1. And the X point must be the boundary of the alignment unit.
  • the recorder can determine the X point in the next step using the EP_map without analyzing the contents of the AV stream.
  • This method reads the data of the AV stream to determine the X point, It is simple because it does not need to analyze the contents. However, the edited AV stream may leave unnecessary data for playback of the PlayList. If the data of the AV stream is read to determine the X point and its contents are analyzed, data unnecessary for playing the PlayList can be deleted more efficiently.
  • FIG. 11 is a diagram for explaining a method of erasing unnecessary data after the OUT point without analyzing the contents of the AV stream.
  • PlayList points to the OUT point on the original AV stream. Also, the EPjnap of the AV stream is shown.
  • SPN_EP_start The video sequence starting from ISA4 is assumed to be as follows.
  • I, P, and B represent an I picture, a P picture, and a B picture, respectively.
  • the numbers represent the display order.
  • the recording device does not analyze the contents of the AV stream, the recording device does not know the picture information (picture coding type, temporal reference, etc.) referenced by the PTS of 0UT_time. 0
  • the PTS of the UT_tiine may refer to picture B0 or B1 (if the recording device does not-analyze the contents of the AV stream, this is not known). In this case, the picture B0, B1 I 2 is needed to decode.
  • PTS of 2 is greater than PTS of OUT time (0UT_time ⁇ pts4, where pts4 is I2: PTS) (PTS of I 2 is greater than OUT-time PTS, but B 0, B 1 is needed for l.
  • the Y point is determined after the address ISA5 shown in the figure.
  • ISA5 is the value of SPN_EP—start immediately after ISA4 in EP_map.
  • the Y point must also be at the boundary of the alignment unit.
  • the recording device can determine the Y point in the next step using EPjaap without analyzing the contents of the AV stream.
  • This method is simple because it does not need to read the data of the AV stream to determine the Y point and analyze its contents. However, the edited AV stream may leave unnecessary data for playing the PlayList. If the data in the AV stream is read to determine the Y point and its contents are analyzed, data unnecessary for playback of the PlayList can be deleted more efficiently.
  • an operation example of creating an EP_map will be described with reference to the flowchart in FIG. This process is performed by the multiplexed stream analyzer 18 of the recording / reproducing apparatus shown in FIG.
  • step S11 the stream analysis unit 18 sets the PID of the video of the AV program to be recorded. If the transport stream contains more than one video, set the video PID for each.
  • step S12 the stream analyzer 18 receives a video transport packet.
  • step S13 the stream analysis unit checks whether the payload of the transport packet (the data portion following the packet header) starts from the first byte of the PES packet (PES packet). Is a packet specified by MPEG2, which is used to packetize the elementary stream.) This can be seen by examining the value of the "payload_unit_start-indicator" in the transport packet header, and if this value is 1, the transport packet payload will be broken from the first byte of the PES packet. Start. If No in step S13, the process returns to step S12. If Yes, the process proceeds to step S14.
  • PES packet the data portion following the packet header
  • step S14 the stream analysis unit determines whether the payload of the PES packet starts to splatter from the first byte of the MPEG video sequence_header_code (32-bit length code "0 ⁇ 00 ⁇ 0 ⁇ 1 ⁇ 3"). Find out. If No in step S14, return to step S12. If Yes, go to step S15.
  • step S15 the current transport packet is set as an entry point.
  • step S16 the stream analysis unit determines the packet number of the above packet. Then, the PTS of the I picture starting from the sequencejieade code and the PID of the video to which the entry point belongs are obtained, and input to the control unit 23. The control unit 23 creates EPjnap.
  • step S17 it is determined whether or not the current packet is the last input transport packet. If it is not the last packet, the process returns to step S12. If it is the last packet, the processing ends.
  • the above-described series of processing can be executed by hardware, but can also be executed by software.
  • various functions must be executed by installing a computer in which the programs constituting the software are incorporated in dedicated hardware, or by installing various programs. It can be installed from a recording medium, for example, at a general-purpose personal computer.
  • this recording medium is a magnetic disk 221 (including a floppy disk) on which the program is written, which is distributed to provide the program to the user separately from the computer.
  • Optical disk 22 including CD-ROM (Compact Disk-Read Only Memory), DVD (Digital Versatile Disk)), magneto-optical disk 22 (including MD (Mini-Disk)), or semiconductor memory
  • a package medium consisting of 222 and the like, but also a ROM 202 and a storage unit 208 that store programs that are provided to the user in a state of being pre-installed in the computer. It consists of a hard disk included.
  • step S describing a program provided by a medium may be performed in a chronological order according to the described order. It also includes processes that are executed individually.
  • a system refers to an entire device including a plurality of devices.
  • Industrial applicability As described above, when encoding and recording an AV stream, time_controlled_flag and TS_average_rate are recorded as attribute information of the AV stream. When the time_control led flag is set to 1, it is guaranteed that the relationship between the time lapse of the AV stream and the amount of data bytes of the AV stream is proportional within a predetermined error.
  • TS_average_rate represents the average bit rate of an AV stream file (transport stream) in units of bytes / second.
  • TS_average_rate is determined to a predetermined value by the application of the recorder. For example, the value of TS-ave rage-rate for each mode is determined according to the recording mode such as long-time recording mode (LP mode), standard recording mode (SP mode), and high-quality recording mode (HQ mode).
  • time_control_flag of the AV stream file is set to 1
  • the bit indicated by TS_average_rate of the stream for the erased time This guarantees that there is enough free space available on the disc for recording at the rate. For example, if a stream is partially erased by a certain amount of an AV stream file in the SP mode, it is possible to create free space on the disk that can be recorded in the same SP mode for the erased time.
  • VBV Video Buffering Verifier
  • the VBV control of the MPEG video encoding is performed so that the input bit rate to the VBV buffer is the current bit rate for the purpose of controlling the video encoder to use the bit amount allocated to the video for a predetermined time.
  • This is an encoding bit rate, and causes the video encoder to generate a swimming byte so that the VBV buffer does not overflow.
  • An arrival time stamp is added to each transport packet to make a source packet, and the source packet row is left-justified and recorded as an AV stream file.

Landscapes

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

Description

明細書 符号化装置及び方法、 記録媒体、 並びにプログラム 技術分野 本発明は、 符号化装置及び方法、 記録媒体、 並びにプログラムに関し、 特に、 記録媒体に記録されているデータの内容の管理情報をファイル化して記録する符 号化装置及び方法、 記録媒体、 並びにプログラムに関する。
背景技術 近年、 記録再生装置から取り外し可能なディスク型の記録媒体として、 各種の 光ディスクが提案されつつある。 このような記録可能な光ディスクは、 数ギガバ ィ トの大容量メディアとして提案されており、 ビデオ信号等の AV(Audio Visua 1)信号を記録するメディアとしての期待が高い。 この記録可能な光ディスクに記 録するディジタルの A V信号のソース （供給源） としては、 C Sディジタル衛星 放送や B Sディジタル放送があり、 また、 将来はディジタル方式の地上波テレビ ジョン放送等も提案されている。
ここで、 これらのソースから供給されるディジタルビデオ信号は、 通常 MPE G (Moving Picture Experts Group) 2方式で画像圧縮されているのが一般的で ある。 また、 記録装置には、 その装置固有の記録レートが定められている。 従来 の民生用映像蓄積メディアで、 ディジタル放送由来のディジタルビデオ信号を記 録する場合、 アナログ記録方式であれば、 ディジタルビデオ信号をデコード後、 帯域制限をして記録する。 あるいは、 MPEG 1 Vi d e o、 MPEG 2 V i d e o、 DV方式をはじめとするディジタル記録方式であれば、 1度デコードさ れた後に、 その装置固有の記録レート ·符号化方式で再エンコードされて記録さ れる。
しかしながら、 このような記録方法は、 供給されたビヅ トストリームを 1度デ コードし、 その後で帯域制限や再エンコードを行って記録するため、 画質の劣化 を伴う。 画像圧縮されたディジタル信号の記録をする場合、 入力されたデイジ夕 ル信号の伝送レートが記録再生装置の記録レートを超えない場合には、 供給され たビッ トストリームをデコードゃ再エンコードすることなく、 そのまま記録する 方法が最も画質の劣化が少ない。 但し、 画像圧縮されたディジタル信号の伝送レ ートが記録媒体としてのディスクの記録レートを超える場合には、 記録再生装置 でデコード後、 伝送レ一トがディスクの記録レートの上限以下になるように、 再 ェンコ一ドをして記録する必要はある。
また、 入力ディジタル信号のビットレートが時間により増減する可変レート方 式によって伝送されている場合には、 回転へッドが固定回転数であるために記録 レートが固定レートになるテープ記録方式に比べ、 1度バッファにデータを蓄積 し、 バースト的に記録ができるディスク記録装置が記録媒体の容量をより無駄な く利用できる。
以上のように、 ディジタル放送が主流となる将来においては、 データストリ一 マのように放送信号をディジタル信号のまま、 デコードや再ェンコ一ドすること なく記録し、 記録媒体としてディスクを使用した記録再生装置が求められると予 測される。
上述したように、 記録媒体の容量が増大することにより、 その記録媒体には、 多くのデ一夕 （この場合、 番組に関する映像や音声など） が記録できるようにな る。 したがって、 1枚のディスクに多くの番組が記録されることになり、 ユーザ が、 それらのディスク内に記録されている多くの番組から視聴したい 1番組を選 択するといつたような操作が煩雑になってしまう。 そこで、 ユーザがディスクの 再生時に、 簡便に記録されているデータを確認し、 所望の番組 （デ一夕） が選択 できるようにする必要があるといつた課題があつた。 発明の開示 本発明の目的は、 このような状況に鑑みて、 記録媒体に記録されているデ一夕 の内容の管理情報をファイル化して記録することにより、 記録媒体に記録されて いるデ一夕内容、 及び、 再生情報を適切に管理することができるようにすること にある。
本発明に係る符号化装置は、 映像データを可変レートにより符号化する符号化 器と、 時間経過に対して映像符号化デ一夕量がほぼ比例するように制御する制御 部とを有する。
制御部は、 単位時間あたりの映像符号化デ一夕発生量が所定量に満たないとき にはス夕ヅフィングバイ トを符号化するよう制御することができる。
制御部は、 各々のピクチャの符号化の際に発生するデータ量に応じてス夕ヅフ ィングバイ トを符号化するか否かを判定することができる。
制御部は、 V B Vバッファがォ一バーフローしないようにスタッフイングバイ トを符号化するよう制御することができる。
制御部は、 時間経過に対して符号化データ量がほぼ比例するように符号化する 符号化モードと通常の符号化モードのどちらか一方で符号化するように制御する ことができる。
制御部は、 符号化モードが、 時間経過に対して符号化データ量がほぼ比例する ように符号化するモードか否かを示す付加情報を生成することができる。
本発明に係る符号化方法は、 映像データを可変レートにより符号化する符号化 ステップと、 時間経過に対して映像符号化データ量がほぼ比例するように制御す る制御ステヅプとを含む。
本発明に係る記録媒体のプログラムは、 映像データを可変レートにより符号化 する符号化ステップと、 時間経過に対して映像符号化デ一夕量がほぼ比例するよ うに制御する制御ステツプとを含む。
本発明に係るプログラムは、 映像デ一夕を可変レートにより符号化する符号化 ステップと、 時間経過に対して映像符号化デ一夕量がほぼ比例するように制御す る制御ステツプとを実行させる。
本発明に係る符号化装置及び方法、 記録媒体、 並びにプログラムにおいては、 映像データが可変レートによって符号化され、 時間経過に対して映像符号化デー 夕量がほぼ比例するように制御される。
本発明に係る記録媒体は、 映像データと、 映像データに対応するオーディオデ 一夕を含む A Vストリームファイルと、 A Vストリームファイルの記録モードを 示すフラグとが記録されている。
フラグは、 time_control led_f lagとすることができる。
フラグは、 記録してからの時間経過に対してファイルサイズが比例するように して記録されるモードであることを示すようにすることができる。
本発明に係る記録媒体においては、 映像データと、 映像デ一夕に対応するォー ディォデ一夕を含む A Vストリームファイルと、 A Vストリームファイルの記録 モードを示すフラグとが記録されている。
本発明の更に他の g的、 特徴や利点は、 後述する本発明の実施例や添付する図 面に基づくより詳細な説明によって明らかになるであろう。 図面の簡単な説明 図 1は、 本発明を適用した記録再生装置の構成を示す図である。
図 2は、 記録再生装置 1により記録媒体に記録されるデ一夕のフォ一マツトに ついて説明する図である。
図 3は、 Real PlayListと Virtual PlayListについて説明する図である。
図 4 A〜図 4 Cは、 Real PlayListの作成について説明する図である。
図 5 A〜図 5 Cは、 Real PlayListの削除について説明する図である。
図 6及び図 6 Bは、 アセンブル編集について説明する図である。
図 7は、 Virtual PlayListにサブパスを設ける場合について説明する図である c 図 8は、 PlayListの再生順序の変更について説明する図である。
図 9は、 PlayList上のマークと Cl ip上のマークについて説明する図である。 図 1 0は、 メニューサムネイルについて説明する図である。
図 1 1は、 PlayListに付加されるマークについて説明する図である。
図 1 2は、 クリヅプに付加されるマークについて説明する図である。
図 1 3は、 PlayList、 Cl ip, サムネイルファイルの関係について説明する図で ある。
図 1 4は、 ディレクトリ構造について説明する図である。
図 1 5は、 info. dvrのシンタクスを示す図である。 図 1 6は、 DVR volumeのシンタクスを示す図である。
図 1 7は、 Resumevolumeのシンタクスを示す図である。
図 1 8は、 UIAppInfovolumeのシンタクスを示す図である。
図 1 9は、 Character set valueのテーブルを示す図である。
図 2 0は、 TableOfPlayListのシンタクスを示す図である。
図 2 1は、 TableOfPlayListの他のシンタクスを示す図である。
図 2 2は、 MakersPrivateDataのシンタクスを示す図である。
図 2 3は、 xxxxx. rplsと yyyyy.vplsのシンタクスを示す図である。
図 2 4 A〜図 2 4 Cは、 PlayListについて説明する図である。
図 2 5は、 PlayListのシンタクスを示す図である。
図 2 6は、 PlayList_typeのテ一ブルを示す図である。
図 2 7は、 UIAppinfoPlayListのシンタクスを示す図である。
図 2 8 A〜図 2 8 Cは、 図 2 7に示した UIAppinfoPlayListのシンタクス内のフ ラグについて説明する図である。
図 2 9は、 Playltemについて説明する図である。
図 3 0は、 Playltemについて説明する図である。
図 3 1は、 Playltemについて説明する図である。
図 3 2は、 Playltemのシンタクスを示す図である。
図 3 3は、 IN_timeについて説明する図である。
図 3 4は、 0UT_timeについて説明する図である。
図 3 5は、 Connection一 Conditionのテーブルを示す図である。
図 3 6 A〜図 3 6 Dは、 Connection— Conditionについて説明する図である。 図 3 7は、 BridgeSequencelnfoを説明する図である。
図 3 8は、 BridgeSequencelnfoのシンタクスを示す図である。
図 3 9は、 SubPlayltemについて説明する図である。
図 4 0は、 SubPlayltemのシンタクスを示す図である。
図 4 1は、 SubPath_typeのテーブルを示す図である。
図 4 2は、 PlayListMarkのシンタクスを示す図である。
図 4 3は、 Mark typeのテーブルを示す図である。 図 4 4は、 Mark_time_staiiipを説明する図である。
図 4 5は、 zzzzz . cl ipのシンタクスを示す図である。
図 4 6は、 Cl iplnfoのシンタクスを示す図である。
図 4 7は、 Cl ip_stream_typeのテーブルを示す図である。
図 4 8は、 offset_SPNについて説明する図である。
図 4 9は、 offset_SPNについて説明する図である。
図 5 0 A及び図 5 0 Bは、 STC区間について説明する図である。
図 5 1は、 STC_Infoについて説明する図である。
図 5 2は、 STC_Infoのシンタクスを示す図である。
図 5 3は、 Programlnfoを説明する図である。
図 5 4は、 Programlnfoのシンタクスを示す図である。
図 5 5は、 VideoCondinglnfoのシンタクスを示す図である。
図 5 6は、 Video_formatのテーブルを示す図である。
図 5 7は、 frame_rateのテーブルを示す図である。
図 5 8は、 display_aspect— ratioのテーブルを示す図である。
図 5 9は、 AudioCondinglnfoのシンタクスを示す図である。
図 6 0は、 audio—codingのテーブルを示す図である。
図 6 1は、 audio—component一 typeのテーブルを示す図である。
図 6 2は、 sampl ing_frequencyのテーブルを示す図である。
図 6 3は、 CPIについて説明する図である。
図 6 4は、 CPIについて説明する図である。
図 6 5は、 CPIのシンタクスを示す図である。
図 6 6は、 CPI_typeのテーブルを示す図である。
図 6 7は、 ビデオ EP_mapについて説明する図である。
図 6 8は、 EPjnapについて説明する図である。
図 6 9は、 EP一 mapについて説明する図である。
図 7 0は、 EP_mapのシンタクスを示す図である。
図 7 1は、 EP_type valuesのテーブルを示す図である。
図 7 2は、 EP map_for_one stream PIDのシンタクスを示す図である。 図 7 3は、 TlLmapについて説明する図である。
図 7 4は、 TUjnapのシンタクスを示す図である。
図 7 5は、 Cl ipMarkのシンタクスを示す図である。
図 7 6は、 mark_typeのテーブルを示す図である。
図 7 7は、 mark一 type_stampのテーブルを示す図である。
図 7 8は、 menu. thmbと mark.thmbのシンタクスを示す図である。
図 7 9は、 Thumbnai lのシンタクスを示す図である。
図 8 0は、 thumbnaiし picture_formatのテーブルを示す図である。
図 8 1 A及ぴ図 8 I Bは、 tn_blockについて説明する図である。
図 8 2は、 DVR MPEG 2のトランスポートストリームの構造について説明する図 である。
図 8 3は、 DVR MPEG 2のトランスポートストリームのレコーダモデルを示す図 である。
図 8 4は、 DVR MPEG 2のトランスポートストリームのプレーヤモデルを示す図 である。
図 8 5は、 source packetのシンタクスを示す図である。
図 8 6は、 TP_extra_headerのシンタクスを示す図である。
図 8 7は、 copy permission indicatorのテーブルを示す図である。
図 8 8は、 シームレス接続について説明する図である。
図 8 9は、 シームレス接続について説明する図である。
図 9 0は、 シームレス接続について説明する図である
図 9 1は、 シームレス接続について説明する図である。
図 9 2は、 シームレス接続について説明する図である
図 9 3は、 オーディオのオーバーラップについて説明する図である。
図 9 4は、 BridgeSequenceを用いたシームレス接続について説明する図である c 図 9 5は、 BridgeSequenceを用いないシームレス接続について説明する図であ る。
図 9 6は、 DVR STDモデルを示す図である。
図 9 7は、 復号、 表示の夕ィミングチヤ一トを示す図である。 図 9 8は、 図 1の A Vエンコーダの動作を説明する図である。
図 9 9は、 ビデオを可変ビットレート符号化して、 A Vストリームを記録する 動作を説明するフローチャートである。
図 1 0 0は、 Video Buffering Verifierを説明する図である。
図 1 0 1は、 VBV制御を説明する図である。
図 1 0 2は、 VBV制御を説明する図である。
図 1 0 3は、 可変ビットレートを制御する場合の例を示す図である。
図 1 0 4は、 可変ビットレ一ト制御の場合の例を示す図である。
図 1 0 5は、 図 9 9のステップ S 2 1の詳細を説明するフローチヤ一トである。 図 1 0 6は、 図 1 0 6のステップ S 2 0 5の詳細を説明するフローチャートで ある。
図 1 0 7は、 A Vス ト リームの時間経過と A Vストリームのデータバイ ト量と の関係を説明する図である。
図 1 0 8は、 ビデオを可変ビットレート符号化して、 A Vストリームを記録す る動作を説明するフローチヤ一トである。
図 1 0 9は、 図 1 0 8のステヅプ S 4 0 0の詳細を説明するフローチヤ一トで ある。
図 1 1 0は、 A ストリームの時間経過と A Vストリームのデータバイ ト量と の関係が、 比例することを保証する符号化モードを説明するフローチヤ一トであ る。
図 1 1 1は、 ミニマイズのオペレーションの例を示す図である。
図 1 1 2は、 ミ二マイズのときに IN一 timeの前の不要なストリ一ムデ一夕を消去 する例を示す図である。
図 1 1 3は、 ミニマイズのときに 0UT_timeの後ろの不要なストリームデ一夕を 消去する例を示す図である。
図 1 1 4は、 EPjiiapの作成の動作例を示すフローチャートである。
図 1 1 5は、 媒体を説明する図である。 発明を実施するための最良の形態 以下に、 本発明が適用された符号化装置及び方法、 記録媒体、 並びにプログラ ムについて、 図面を参照して説明する。 図 1は、 本発明を適用した記録再生装置 1の内部構成例を示す図である。 先ず、 外部から入力された信号を記録媒体に記 録する動作を行う部分の構成について説明する。 記録再生装置 1は、 アナログデ 一夕、 又は、 ディジタルデ一夕を入力し、 記録することができる。
端子 1 1には、 アナログのビデオ信号が、 端子 1 2には、 アナログのオーディ ォ信号が、 それそれ入力される。 端子 1 1に入力されたビデオ信号は、 解析部 1 4と A Vエンコーダ 1 5に、 それそれ出力される。 端子 1 2に入力されたオーデ ィォ信号は、 A Vエンコーダ 1 5に出力される。 解析部 1 4は、 入力されたビデ ォ信号からシーンチェンジなどの特徴点を抽出する。
A Vエンコーダ 1 5は、 入力されたビデオ信号とオーディオ信号を、 それそれ 符号化し、 符号化ビデオストリーム （V ) 、 符号化オーディオストリーム （A ) 、 及び A V同期等のシステム情報 （S ) をマルチプレクサ 1 6に出力する。
符号化ビデオストリームは、 例えば、 M P E G (Moving Picture Expert Grou p) 2方式により符号化されたビデオストリームであり、 符号化オーディオストリ —ムは、 例えば、 M P E G 1方式により符号化されたオーディオストリームや、 ドルビー A C 3方式により符号化されたオーディオストリーム等である。 マルチ プレクサ 1 6は、 入力されたビデオ及びオーディオのストリームを、 入力システ ム情報に基づいて多重化して、 スイッチ 1 7を介して多重化ストリーム解析部 1 8とソースパケヅ夕ィザ 1 9に出力する。
多重化ストリームは、 例えば、 M P E G 2 トランスポ一トストリームや M P E G 2プログラムストリームである。 ソースパケヅ夕ィザ 1 9は、 入力された多重 化ストリームを、 そのストリームを記録させる記録媒体 1 0 0のアプリケーショ ンフォーマヅトに従って、 ソースパケヅトから構成される A Vストリームを符号 化する。 A Vストリームは、 E C C (誤り訂正） 符号化部 2 0、 変調部 2 1で所 定の処理が施され、 書込部 2 2に出力される。 書込部 2 2は、 制御部 2 3から出 力される制御信号に基づいて、 記録媒体 1 0 0に A Vストリームファイルを書き 込む （記録する） 。 ディジ夕ルイン夕フェース又はディジ夕ルテレビジョンチューナから入力され るディジタルテレビジョン放送等のトランスポートストリームは、 端子 1 3に入 力される。 端子 1 3に入力されたトランスポートストリームの記録方式には、 2 通りあり、 それらは、 トランスペアレントに記録する方式と、 記録ビットレート を下げるなどの目的のために再ェンコ一ドをした後に記録する方式である。 記録 方式の指示情報は、 ユーザイン夕フェースとしての端子 2 4から制御部 2 3へ入 力される。
入力トランスポートストリームをトランスペアレントに記録する場合、 端子 1 3に入力されたトランスポートストリームは、 多重化ストリーム解析部 1 8と、 ソースパケヅタイザ 1 9に出力される。 これ以降の記録媒体 1 0 0へ A Vストリ ームが記録されるまでの処理は、 上述の入力オーディオ浸透とビデオ信号を符号 化して記録する場合と同一の処理なので、 その説明は省略する。
入力トランスポートストリームを再ェンコ一ドした後に記録する場合、 端子 1 3に入力されたトランスポートストリームは、 デマルチプレクサ 2 6に入力され る。 デマルチプレクサ 2 6は、 入力されたトランスポートストリームに対してデ マルチプレクス処理を施し、 ビデオストリーム （V ) 、 オーディオストリーム ( A ) 、 及びシステム情報 （S ) を抽出する。
デマルチプレクサ 2 6により抽出されたストリーム （情報） の内、 ビデオスト リームは A Vデコーダ 2 7に、 オーディオストリームとシステム情報はマルチプ レクサ 1 6に、 それそれ出力される。 A Vデコーダ 2 7は、 入力されたビデオス トリームを復号し、 その再生ビデオ信号を A Vエンコーダ 1 5に出力する。 A V エンコーダ 1 5は、 入力ビデオ信号を符号化し、 符号化ビデオストリーム （V ) をマルチプレクサ 1 6に出力する。
一方、 デマルチプレクサ 2 6から出力され、 マルチプレクサ 1 6に入力された オーディオストリームとシステム情報、 及び、 A Vエンコーダ 1 5から出力され たビデオストリームは、 入力システム情報に基づいて、 多重化されて、 多重化ス トリームとして多重化ストリーム解析部 1 8とソースパケット夕ィザ 1 9にスィ ツチ 1 Ίを介して出力される。 これ以後の記録媒体 1 0 0へ A Vストリームが記 録されるまでの処理は、 上述の入力オーディオ信号とビデオ信号を符号化して記 録する場合と同一の処理なので、 その説明は省略する。
本例の記録再生装置 1は、 A Vストリームのファイルを記録媒体 1 0 0に記録 すると共に、 そのファイルを説明するアプリケーションデ一夕ペース情報も記録 する。 アプリケーションデ一夕ベース情報は、 制御部 2 3により作成される。 制 御部 2 3への入力情報は、 解析部 1 4からの動画像の特徴情報、 多重化ストリー ム解析部 1 8からの A Vストリームの特徴情報、 及び端子 2 4から入力されるュ 一ザからの指示情報である。
解析部 1 4から供給される動画像の特徴情報は、 入力動画像信号の中の特徴的 な画像に関係する情報であり、 例えば、 プログラムの開始点、 シーンチェンジ点、 コマーシャル （C M) の開始 '終了点などの指定情報 （マーク） であり、 また、 その指定場所の画像のサムネイル画像の情報も含まれる。
多重化ストリ一ム解析部 1 8からの A Vストリームの特徴情報は、 記録される A Vス ト リームの符号化情報に関係する情報であり、 例えば、 A Vス ト リーム内 の I ピクチャのアドレス情報、 A Vス ト リームの符号化パラメ一タ、 A Vス ト リ ームの中の符号化パラメ一夕の変化点情報、 ビデオストリームの中の特徴的な画 像に関係する情報 （マーク） などである。
端子 2 4からのユーザの指示情報は、 A Vストリームの中の、 ユーザが指定し た再生区間の指定情報、 その再生区間の内容を説明するキャラクタ一文字、 ユー ザが好みのシーンにセヅトするブックマークゃリジユーム点の情報などである。 制御部 2 3は、 上記の入力情報に基づいて、 A Vス トリームのデータペース（G l ip). A Vストリームの再生区間（Playltem)をグル一プ化したもの （HayList) のデータペース、 記録媒体 1 0 0の記録内容の管理情報（info.dvr)、 及びサムネ ィル画像の情報を作成する。 これらの情報から構成されるアプリケーションデー 夕ベース情報は、 A Vストリームと同様にして、 E C C符号化部 2 0、 変調部 2 1で処理されて、 書込部 2 2へ入力される。 書込部 2 2は、 制御部 2 3から出力 される制御信号に基づいて、 記録媒体 1 0 0へデータベースファイルを記録する c 上述したアプリケ一シヨンデータベース情報についての詳細は後述する。
このようにして記録媒体 1 0 0に記録された A Vストリームファイル （画像デ 一夕と音声データのファイル） と、 アプリケーションデータベース情報が再生さ れる場合、 先ず、 制御部 2 3は、 読出部 2 8に対して、 記録媒体 1 0 0からアブ リケーシヨンデータベース情報を読み出すように指示する。 そして、 読出部 2 8 は、 記録媒体 1 0 0からアプリケー ョンデータベース情報を読み出し、 そのァ プリケーシヨンデータベース情報は、 復調部 2 9、 E C C復号部 3 0の処理を経 て、 制御部 2 3へ入力される。
制御部 2 3は、 アプリケーションデ一夕ベース情報に基づいて、 記録媒体 1 0 0に記録されている PlayListの一覧を端子 2 4のユーザィン夕フヱ一スへ出力す る。 ユーザは、 PlayListの一覧から再生したい PlayListを選択し、 再生を指定さ れた PlayListに関する情報が制御部 2 3へ入力される。 制御部 2 3は、 その Play Listの再生に必要な A Vストリームファイルの読み出しを、 読出部 2 8に指示す る。 読出部 2 8は、 その指示に従い、 記録媒体 1 0 0から対応する A Vストリー ムを読み出し復調部 2 9に出力する。 復調部 2 9に入力された A Vストリームは、 所定の処理が施されることにより復調され、 更に E C C復号部 3 0の処理を経て、 ソ一スデパケッタイザ 3 1出力される。
ソースデパケッタイザ 3 1は、 記録媒体 1 0 0から読み出され、 所定の処理が 施されたアプリケ一シヨンフォーマットの A Vストリームを、 デマルチプレクサ 2 6に出力できるストリームに変換する。 デマルチプレクサ 2 6は、 制御部 2 3 により指定された A Vストリームの再生区間（Playltem)を構成するビデオストリ ーム （V ) 、 ォ一ディォストリ一ム （A ) 、 及び A V同期等のシステム情報 ( S ) を、 A Vデコーダ 2 7に出力する。 A Vデコーダ 2 7は、 ビデオストリー ムとオーディオストリームを復号し、 再生ビデオ信号と再生オーディオ信号を、 それそれ対応する端子 3 2と端子 3 3から出力する。
また、 ユーザインタフェースとしての端子 2 4から、 ランダムアクセス再生や 特殊再生を指示する情報が入力された場合、 制御部 2 3は、 A Vスト リームのデ 一夕ベース（Cl ip)の内容に基づいて、 記憶媒体 1 0 0からの A Vスト リ一ムの読 み出し位置を決定し、 その A Vス ト リームの読み出しを、 読出部 2 8に指示する。 例えば、 ユーザにより選択された PlayListを、 所定の時刻から再生する場合、 制 御部 2 3は、 指定された時刻に最も近いタイムスタンプを持つ Iピクチャからの デ一夕を読み出すように読出部 2 8に指示する。 また、 ユーザによって高速再生（Fast- forward playback)が指示された場合、 制 御部 2 3は、 A Vストリームのデ一夕ベース（Cl ip)に基づいて、 A Vストリーム の中の I -ピクチャデ一夕を順次連続して読み出すように読出部 2 8に指示する。 読出部 2 8は、 指定されたランダムアクセスボイントから A Vストリームのデ 一夕を読み出し、 読み出されたデータは、 後段の各部の処理を経て再生される。 次に、 ユーザが、 記録媒体 1 0 0に記録されている A Vストリームの編集をす る場合を説明する。 ュ一ザが、 記録媒体 1 0 0に記録されている A Vストリーム の再生区間を指定して新しい再生経路を作成したい場合、 例えば、 番組 Aという 歌番組から歌手 Aの部分を再生し、 その後続けて、 番組 Bという歌番組の歌手 A の部分を再生したいといった再生経路を作成したい場合、 ユーザィン夕フェース としての端子 2 4から再生区間の鬨始点 （イン点） と終了点 （アウト点） の情報 が制御部 2 3に入力される。 制御部 2 3は、 A Vストリームの再生区間（Playlte m)をグループ化したもの （PlayList) のデ一夕べ一スを作成する。
ユーザが、 記録媒体 1 0 0に記録されている A Vス ト リームの一部を消去した い場合、 ユーザィン夕フヱースとしての端子 2 4から消去区間のィン点とァゥト 点の情報が制御部 2 3に入力される。 制御部 2 3は、 必要な A Vストリーム部分 だけを参照するように PlayListのデータペースを変更する。 また、 A Vストリー ムの不必要なストリーム部分を消去するように、 書込部 2 2に指示する。
ュ一ザが、 記録媒体 1 0 0に記録されている A Vストリームの再生区間を指定 して新しい再生経路を作成したい場合であり、 且つ、 それそれの再生区間をシー ムレスに接続したい場合について説明する。 このような場合、 制御部 2 3は、 A Vストリームの再生区間（Playltem)をグループ化したもの （PlayList) のデ一夕 ベースを作成し、 更に、 再生区間の接続点付近のビデオストリームの部分的な再 エンコードと再多重化を行う。
先ず、 端子 2 4から再生区間のイン点のピクチャの情報と、 アウト点のピクチ ャの情報が制御部 2 3へ入力される。 制御部 2 3は、 読出部 2 8にイン点側ピク チヤとァゥト点側のピクチャを再生するために必要なデ一夕の読み出しを指示す る。 そして、 読出部 2 8は、 記録媒体 1 0 0からデ一夕を読み出し、 そのデ一夕 は、 復調部 2 9、 E C C復号部 3 0、 ソースデパケヅ夕ィザ 3 1を経て、 デマル チプレクサ 2 6に出力される。
制御部 2 3は、 デマルチプレクサ 2 6に入力されたデ一夕を解析して、 ビデオ ストリームの再エンコード方法 （picture— coding— typeの変更、 再エンコードする 符号化ビット量の割り当て） と、 再多重化方式を決定し、 その方式を A Vェンコ —ダ 1 5とマルチプレクサ 1 6に供給する。
次に、 デマルチプレクサ 2 6は、 入力されたストリームをビデオストリーム ( V ) 、 オーディオストリーム （A ) 、 及びシステム情報 （S ) に分離する。 ビ デォストリームは、 「A Vデコーダ 2 7に入力されるデ一夕」 と 「マルチプレク サ 1 6に入力されるデータ」 がある。 前者のデータは、 再エンコードするために 必要なデータであり、 これは A Vデコーダ 2 7で復号され、 復号されたピクチャ は A Vエンコーダ 1 5で再エンコードされて、 ビデオストリームにされる。 後者 のデータは、 再ェンコ一ドをしないで、 オリジナルのストリームからコピーされ るデ一夕である。 オーディオストリーム、 システム情報については、 直接、 マル チプレクサ 1 6に入力される。
マルチプレクサ 1 6は、 制御部 2 3から入力された情報に基づいて、 入力スト リームを多重化し、 多重化ストリームを出力する。 多重化ストリームは、 E C C 符号化部 2 0、 変調部 2 1で処理されて、 書込部 2 2に入力される。 書込部 2 2 は、 制御部 2 3から供給される制御信号に基づいて、 記録媒体 1 0 0に A Vスト リームを記録する。
以下に、 アプリケーションデータベース情報や、 その情報に基づく再生、 編集 といった操作に関する説明をする。 図 2は、 アプリケーションフォーマヅ トの構 造を説明する図である。 アプリケーションフォーマットは、 A Vストリームの管 理のために PlayListと Cl ipの 2つのレイヤを持つ。 Volume Informationは、 ディ スク内の全ての Cl ipと PlayListの管理をする。 ここでは、 1つの A Vストリーム とその付属情報のペアを 1つのオブジェクトと考え、 それを Cl ipと称する。 A V ストリームファイルは Cl ip AV stream fi leと称し、 その付属情報は、 Cl ip Info rmation ： i leと称する。
1つの Cl ip AV stream f i leは、 M P E G 2 トランスポートストリームをアプリ ケーシヨンフォーマツトによって規定される構造に配置したデ一夕をストァする。 一般的に、 ファイルは、 バイ ト列として扱われるが、 Cl ip AV stream fi leのコン テンッは、 時間軸上に展開され、 Cl ipの中のエントリポイントは、 主に時間べ一 スで指定される。 所定の Cl ipへのアクセスポィントの夕ィムスタンプが与えられ たとき、 Cl ip Information f i leは、 Cl ip AV stream fi leの中でデ一夕の読み出 しを開始すべきアドレス情報を見つけるために役立つ。
PlayListについて、 図 3を参照して説明する。 PlayListは、 Cl ipの中からユー ザが見たい再生区間を選択し、 それを簡単に編集することができるようにするた めに設けられている。 1つの PlayListは、 Cl ipの中の再生区間の集まりである。 所定の Cl ipの中の 1つの再生区間は、 Playltemと呼ばれ、 それは、 時間軸上のィ ン点 （I N ) とアウト点 （O U T ) の対で表される。 したがって、 PlayListは、 複数の Playltemが集まることにより構成される。
PlayListには、 2つのタイプがある。 1つは、 Real PlayListであり、 もう 1つ は、 Virtual PlayListである。 Real PlayListは、 それが参照している Cl ipのスト リーム部分を共有している。 すなわち、 Real PlayListは、 それの参照している C l ipのストリ一ム部分に相当するデータ容量をディスクの中で占め、 Real PlayLi stが消去された場合、 それが参照している Cl ipのストリーム部分もまたデ一夕が 消去される。
Virtual PlayListは、 Cl ipのデ一夕を共有していない。 したがって、 Virtual PlayListが変更又は消去されたとしても、 Cl ipの内容には何も変化が生じない。 次に、 Real PlayListの編集について説明する。 図 4 Aは、 Real PlayListのク リエイ ト（create：作成）に関する図であり、 A Vストリームが新しい Cl ipとして 記録される場合、 その Cl ip全体を参照する Real PlayListが新たに作成される操作 である。
図 4 Bは、 Real PlayListのディバイ ド（divide：分割）に関する図であり、 Rea 1 PlayListが所望な点で分けられて、 2つの Real PlayListに分割される操作であ る。 この分割という操作は、 例えば、 1つの PlayListにより管理される 1つのク リップ内に、 2つの番組が管理されているような場合に、 ユーザが 1つ 1つの番 組として登録 （記録） し直したいといったようなときに行われる。 この操作によ り、 Cl ipの内容が変更される （Cl ip自体が分割される） ことはない。 図 4 Cは、 Real PlayListのコンバイン（combine：結合）に関する図であり、 2 つの Real P layListを結合して、 1つの新しい Real PlayListにする操作である。 この結合という操作は、 例えば、 ユーザが 2つの番組を 1つの番組として登録し 直したいといったようなときに行われる。 この操作により、 Cl ipが変更される (Cl ip自体が 1つにされる） ことはない。
図 5 Aは、 Real PlayList全体のデリート（delete：削除）に関する図であり、 所 定の Real PlayList全体を消去する操作がされた場合、 削除された Real PlayList が参照する Cl ipの、 対応するストリーム部分も削除される。
図 5 Bは、 Real PlayListの部分的な削除に関する図であり、 Real PlayListの 所望な部分が削除された場合、 対応する Playltemが、 必要な Clipのストリーム部 分だけを参照するように変更される。 そして、 Cl ipの対応するストリーム部分は 削除される。
図 5 Cは、 Real PlayListのミニマイズ（Minimize：最小化）に関する図であり、 Real PlayListに対応する Playltemを、 Virtual PlayListに必要な Cl ipのストリ一 ム部分だけを参照するようにする操作である。 Virtual PlayList にとつて不必要 な Cl ipの、 対応するストリーム部分は削除される。
上述したような操作により、 Real PlayListが変更されて、 その Real PlayList が参照する Clipのス トリーム部分が削除された場合、 その削除された Cl ipを使用 している Virtual PlayListが存在し、 その Virtual PlayListにおいて、 削除され た Cl ipにより問題が生じる可能性がある。
そのようなことが生じないように、 ユーザに、 削除という操作に対して、 「そ の Real PlayListが参照している Cl ipのストリーム部分を参照している Virtual P layListが存在し、 もし、 その Real PlayListが消去されると、 その Virtual Play Listもまた消去されることになるが、 それでも良いか？」 といったメヅセージな どを表示させることにより、 確認 （警告） を促した後に、 ユーザの指示により削 除の処理を実行、 又は、 キャンセルする。 又は、 Virtual PlayListを削除する代 わりに、 Real PlayListに対してミニマイズの操作が行われるようにする。
次に、 Virtual PlayListに対する操作について説明する。 Virtual PlayListに 対して操作が行われたとしても、 Cl ipの内容が変更されることはない。 図 6は、 アセンブル（Assemble) 編集 （IN-OUT 編集）に関する図であり、 ユーザが見たいと 所望した再生区間の Playltemを作り、 Virtual PlayListを作成するといつた操作 である。 Playlteni間のシームレス接続が、 アプリケーションフォーマヅ トにより サポートされている （後述） 。
図 6 Aに示したように、 2つの Real PlayList 1 , 2と、 それそれの RealPlayL istに対応する Clip 1， 2が存在している場合に、 ユーザが Real PlayListl内の 所定の区間 （In 1乃至 Out 1までの区間： Playltem 1 ) を再生区間として指示し、 続けて再生する区間として、 Real PlayList2内の所定の区間 （In2乃至 0ut2ま での区間： Playltem2) を再生区間として指示したとき、 図 6 Bに示すように、 Playltem 1と Playltem 2から構成される 1つの Virtual PlayListが作成される。 次に、 Virtual PlayList の再編集（Re- editing)について説明する。 再編集には、 Virtual PlayListの中のイン点やアウト点の変更、 Virtual PlayListへの新しい Playltemの挿入（insert)や追加（append)、 Virtual PlayListの中の Playltemの肖 [J 除などがある。 また、 Virtual PlayListそのものを削除することもできる。
図 7は、 Virtual PlayListへのオーディオのアフレコ（Audio dubbing (post r ecording))に関する図であり、 Virtual PlayListへのオーディオのアフレコをサ ブパスとして登録する操作のことである。 このオーディオのアフレコは、 アプリ ケーションフォーマヅトによりサボ一トされている。 Virtual PlayListのメイン パスの A Vストリームに、 付加的なオーディオストリームが、 サブパスとして付 加される。
Real PlayListと Virtual PlayListで共通の操作として、 図 8に示すような Pla yListの再生順序の変更（Moving)がある。 この操作は、 ディスク（ボリューム）の中 での PlayListの再生順序の変更であり、 アプリケーションフォーマツ トにおいて 定義される Table Of PlayList (図 20などを参照して後述する） によってサポ一 トされる。 この操作により、 Clipの内容が変更されるようなことはない。
次に、 マーク （Mark) について説明する。 マ一クは、 Clip及び PlayListの中の ハイライ トゃ特徴的な時間を指定するために設けられている。 Clipに付加される マークは、 A Vストリームの内容に起因する特徴的なシーンを指定する、 例えば、 シーンチェンジ点などである。 PlayListを再生するとき、 その PlayListが参照す る Cl ipのマークを参照して、 使用することができる。
PlayListに付加され'るマ一クは、 主にユーザによってセヅ トされる、 例えば、 ブヅクマークゃリジユーム点などである。 Cl ip又は PlayListにマークをセヅトす ることは、 マークの時刻を示すタイムスタンプをマークリストに追加することに より行われる。 また、 マークを削除することは、 マークリストの中から、 そのマ ークのタイムスタンプを除去することである。 したがって、 マークの設定や削除 により、 A Vストリームは何の変更もされない。
次に、 サムネイルについて説明する。 サムネイルは、 Volume、 PlayList, 及び Cl ipに付加される静止画である。 サムネイルには、 2つの種類があり、 1つは、 内容を表す代表画としてのサムネイルである。 これは主としてュ一ザがカーソル (不図示） などを操作して見たいものを選択するためのメニュー画面で使われる ものである。 もう 1つは、 マークが指しているシーンを表す画像である。
Volumeと各 Playl istは代表画を持つことができるようにする必要がある。 Volu meの代表画は、 ディスク （記録媒体 1 0 0、 以下、 記録媒体 1 0 0はディスク状 のものであるとし、 適宜、 ディスクと記述する） を記録再生装置 1の所定の場所 にセットしたときに、 そのディスクの内容を表す静止画を最初に表示する場合な どに用いられることを想定している。 Playl istの代表画は、 Playl istを選択する メニュー画面において、 Playl istの内容を表すための静止画として用いられるこ とを想定している。
Playl istの代表画として、 Playl istの最初の画像をサムネイル （代表画） にす ることが考えられるが、 必ずしも再生時刻 0の先頭の画像が内容を表す上で最適 な画像とは限らない。 そこで、 Playl istのサムネイルとして、 任意の画像をユー ザが設定できるようにする。 以上 2種類のサムネイルをメニューサムネイルと称 する。 メニューサムネイルは頻繁に表示されるため、 ディスクから高速に読み出 される必要がある。 このため、 全てのメニュ一サムネイルを 1つのファイルに格 納することが効率的である。 メニューサムネイルは、 必ずしもボリューム内の動 画から抜き出したピクチャである必要はなく、 図 1 0に示すように、 パーソナル コンピュータやディジタルスチルカメラから取り込まれた画像でもよい。
一方、 Cl ipと Playl istには、 複数個のマークを打てる必要があり、 マ一ク位置 の内容を知るためにマーク点の画像を容易に見ることができるようにする必要が ある。 このようなマ一ク点を表すピクチャをマークサムネイル （Mark Thumbnai l s) と称する。 したがって、 サムネイルの元となる画像は、 外部から取り込んだ画 像よりも、 マーク点の画像を抜き出したものが主となる。
図 1 1は、 PlayListに付けられるマークと、 そのマークサムネイルの関係につ いて示す図であり、 図 1 2は、 Cl ipに付けられるマークと、 そのマ一クサムネィ ルの関係について示す図である。 マークサムネイルは、 メニューサムネイルと異 なり、 Playl istの詳細を表すときに、 サブメニュー等で使われるため、 短いァク セス時間で読み出されるようなことは要求されない。 そのため、 サムネイルが必 要になる度に、 記録再生装置 1がファイルを開き、 そのファイルの一部を読み出 すことで多少時間がかかっても、 問題にはならない。 .
また、 ボリューム内に存在するファイル数を減らすために、 全てのマークサム ネイルは 1つのファイルに格納するのがよい。 Playl istはメニューサムネイル 1 つと複数のマークサムネイルを有することができるが、 CI ipは直接ユーザが選択 する必要性がない （通常、 Playl ist経由で指定する） ため、 メニューサムネイル を設ける必要はない。
図 1 3は、 上述したことを考慮した場合のメニューサムネイル、 マークサムネ ィル、 PlayList、 及び Cl ipの関係について示した図である。 メニューサムネイル ファイルには、 PlayList毎に設けられたメニューサムネイルがファイルされてい る。 メニューサムネイルファイルには、 ディスクに記録されているデータの内容 を代表するポリュームサムネイルが含まれている。 マークサムネイルファイルは、 各 PlayList毎と各 Cl ip毎に作成されたサムネイルがファイルされている。
次に、 C P I (Characteristic Point Information) について説明する。 C P Iは、 Cl ipインフォメーションファイルに含まれるデータであり、 主に、 それは Cl ipへのアクセスボイントのタイムスタンプが与えられたとき、 Cl ip AV stream fi leの中でデータの読み出しを開始すべきデ一夕アドレスを見つけるために用い られる。 本例では、 2種類の C P Iを用いる。 1つは、 EP一 mapであり、 もう一つ は、 TUjnapである。
EP_mapは、 エントリポイント （E P ) データのリストであり、 それはエレメン 夕 リス ト リーム及びトランスポートス ト リームから抽出されたものである。 これ は、 AVス トリームの中でデコードを開始すべきェント リポィン卜の場所を見つ けるためのアドレス情報を持つ。 1つの EPデ一夕は、 プレゼンテーション夕ィ ムスタンプ （PTS) と、 その PT Sに対応するアクセスュニヅ 卜の A Vス ト リ ームの中のデ一夕ァドレスの対で構成される。
EPjnapは、 主に 2つの目的のために使用される。 第 1に、 PlayListの中でプレ ゼンテーシヨンタイムスタンプによって参照されるアクセスュニヅ トの AVスト リームの中のデ一夕アドレスを見つけるために使用される。 第 2に、 ファース ト フォヮ一ド再生やファーストリバース再生のために使用される。 記録再生装置 1 が、 入力 AVス トリームを記録する場合、 そのス ト リームのシンタクスを解析す ることができるとき、 EP_mapが作成され、 ディスクに記録される。
TILmapは、 ディジ夕ルイン夕フェースを通して入力される トランスポートパケ ヅ トの到着時刻に基づいた夕ィムュニヅ ト （TU) デ一夕のリストを持つ。 これ は、 到着時刻ベースの時間と A Vス ト リームの中のデ一夕アドレスとの関係を与 える。 記録再生装置 1が、 入力 AVスト リームを記録する場合、 そのス トリーム のシンタクスを解析することができないとき、 TU_mapが作成され、 ディスクに記 録される。
本例では、 セルフエンコードのス ト リームフォーマッ ト （SE S F) を定義す る。 SE SFは、 アナログ入力信号を符号化する目的、 及びディジタル入力信号 (例えば DV) をデコードしてから MPEG 2トランスポートストリームに符号化 する場合に用いられる。
SE S Fは、 MPEG— 2 トランスポートス ト リーム及び A Vス ト リームにつ いてのエレメン夕リス ト リームの符号化制限を定義する。 記録再生装置 1が、 S E S Fス トリームをエンコードし、 記録する場合、 EP_mapが作成され、 ディスク に記録される。
ディジタル放送のスト リームは、 次に示す方式の内のいずれかが用いられて記 録媒体 1 00に記録される。 先ず、 ディジタル放送のス ト リームを SE SFス ト リームにトランスコーディングする。 この場合、 記録されたス トリームは、 SE S Fに準拠しなければならない。 この場合、 EP_mapが作成されて、 ディスクに記 録されなければならない。
あるいは、 ディジ夕ル放送ス ト リームを構成するエレメン夕リス トリ一ムを新 しいエレメン夕リストリームにトランスコーディングし、 そのディジ夕ル放送ス ト リームの規格化組織が定めるス トリームフォーマヅ トに準拠した新しいトラン スポートス ト リームに再多重化する。 この場合、 EPjiiapが作成されて、 ディスク に記録されなければならない。
例えば、 入力ス トリームが I SDB (日本のディジタル B S放送の規格名称） 準拠の MP E G- 2 トランスボートス ト リームであり、 それが HD TVビデオス ト リームと MP EG A A Cオーディオス ト リームを含むとする。 HDTVビデオ ス ト リームを SD TVビデオス ト リームにトランスコーディングし、 その SDT Vビデオストリームとオリジナルの A ACオーディオストリームを TSに再多重化 する。 SDTVス トリームと記録される トランスポートス トリームは、 共に I S DBフォーマヅ トに準拠しなければならない。
ディジタル放送のス ト リームが、 記録媒体 1 00に記録される際の他の方式と して、 入力トランスポートストリームをトランスペアレントに記録する （入力ト ランスポートス ト リームを何も変更しないで記録する） 場合であり、 そのときに EP_mapが作成されてディスクに記録される。
又は、 入力トランスポートストリ一ムをトランスペアレントに記録する （入力 トランスポートス ト リームを何も変更しないで記録する） 場合であり、 そのとき に TU_mapが作成されてディスクに記録される。
次に、 ディレク トリとファイルについて説明する。 以下、 記録再生装置 1を D VR (Digital Video Recording) と適宜記述する。 図 14はディスク上のディレ ク ト リ構造め一例を示す図である。 DVRのディスク上に必要なディレク トリは、 図 14に示したように、 "DVR"ディ レク ト リを含む rootディ レク ト リ、 "PLAYLIST "ディレク ト リ、 "CLIPINF"ディレク ト リ、 "M2TS"ディ レク トリ、 及び" DATA"ディ レク ト リを含む" DVR"ディ レク ト リである。 rootディレク ト リの下に、 これら以外 のディ レク ト リを作成されるようにしてもよいが、 それらは、 本例のアプリケー シヨンフォーマッ トでは、 無視されるとする。
"DVR"ディ レク ト リの下には、 D VRアプリケーシヨンフォ一マヅ トによって 規定される全てのファイルとディレクトリがストアされる。 "DVR"ディレクトリは、 4個のディレクトリを含む。 "PLAYLIST"ディレクトリの下には、 Real PlayListと Virtual PlayListのデ一夕ベースファイルが置かれる。 このディレクトリは、 PI ayListが 1つもなくても存在する。
"CLIPINF"ディレクトリの下には、 Cl ipのデータベースが置かれる。 このディレ クトリも、 Cl ipが 1つもなくても存在する。 "M2TS"ディレクトリの下には、 A V ストリームファイルが置かれる。 このディレクトリは、 A Vストリームファイル が 1つもなくても存在する。 "DATA"ディレクトリは、 ディジタル V放送などの デ一夕放送のファイルがストァされる。
"DVR"ディレクトリは、 次に示すファイルをストアする。 " info. dvr"ファイルは、
D V Rディレクトリの下に作られ、 アブリケ一シヨンレイヤの全体的な情報をス トァする。 D V Rディレクトリの下には、 ただ 1つの info . dvrがなければならな い。 ファイル名は、 info . dvrに固定されるとする。 "menu. thmb"ファイルは、 メニ ユーサムネイル画像に関連する情報をストァする。 D V Rディレクトリの下には、 0又は 1つのメニューサムネイルがなければならない。 ファイル名は、 meuiu. thm bに固定されるとする。 メニューサムネイル画像が 1つもない場合、 このファイル は、 存在しなくてもよい。
"mark. thmb"ファイルは、 マークサムネイル画像に関連する情報をストァする。 D V Rディレクトリの下には、 0又は 1つのマークサムネイルがなければならな い。 ファイル名は、 mark. thmMこ固定されるとする。 メニューサムネイル画像が 1 つもない場合、 このファイルは、 存在しなくてもよい。
"PLAYLIST"ディレクトリは、 2種類の PlayListファイルをストァするものであ り、 それらは、 Real PlayListと Virtual PlayListである。 " xxxxx. rpls" フアイ ルは、 1つの Real PlayListに閧連する情報をストアする。 それそれの Real Play List毎に、 1つのファイルが作られる。 ファイル名は、 "xxxxx. rpls"である。 こ こで、 "xxxxx"は、 5個の 0乃至 9まで数字である。 ファイル拡張子は、 "rpls"で なければならないとする。
"yyyyy.vpls"ファイルは、 1つの Virtual PlayListに関連する情報をストアす る。 それぞれの Virtual PlayList毎に、 1つのファイルが作られる。 ファイル名 は、 "yyyyy.vpls"である。 ここで、 "yyyyy"は、 5個の 0乃至 9まで数字である。 フアイル拡張子は、 "vpl s"でなければならないとする。
"CLIPINF"ディレクトリは、 それそれの A Vストリームファイルに対応して、 1 つのファイルをストァする。 "zzzzz. clpi" ファイルは、 1つの A Vストリームフ アイル（Cl ip AV stream fi le 又は Bridge-Cl ip AV stream fi le)に対応する Cl i p Information fi leである。 ファイル名は、 "zzzzz. clpi"であり、 "zzzzz，，は、 5 個の 0乃至 9までの数字である。 ファイル拡張子は、 "clpi"でなければならない とする。
"M2TS"ディレクトリは、 A Vストリームのファイルをストアする。 "zzzzz.m2t s"ファイルは、 D V Rシステムにより扱われる A Vストリームファイルである。 これは、 Cl ip AV stream f i le又は Bridge- Cl ip AV streamである。 ファイル名は、 "zzzzz .ni2ts"であり、 "zzzzz"は、 5個の 0乃至 9までの数字である。 ファイル拡 張子は、 "m2ts"でなければならないとする。
" DATA" ディレクトリは、 データ放送から伝送されるデ一夕をストァするもの であり、 デ一夕とは、 例えば、 XML fi leや MHEGファイルなどである。
次に、 各ディレクトリ （ファイル） のシンタクスとセマンティクスを説明する。 先ず、 " info. dvr" ファイルについて説明する。 図 1 5は、 " info. dvr" フアイ ルのシンタクスを示す図である。 " info . dvr" ファイルは、 3個のオブジェクト から構成され、 それらは、 DVRVolumeO, TableOfPlayLists( )、 及ぴ MakerPrivat eData( )である。
図 1 5に示した info. dvrのシンタクスについて説明するに、 TableOfPlayLists _Start一 addressは、 info. dvrファイルの先頭のバイ トからの相対バイ ト数を単位 として、 TableOfPlayListOの先頭アドレスを示す。 相対バイ ト数は 0からカウン トされる。
MakerPrivateData_Start_address{iN info. dvrファイスレの先頭のノ ィ ト；^らの 相対バイ ト数を単位として、 MakerPrivateData( )の先頭アドレスを示す。 相対バ ィ ト数は 0からカウントされる。 padding_word (パディングワード） は、 info. d vrのシンタクスに従って挿入される。 1と 2は、 ◦又は任意の正の整数であ る。 それそれのパディングワードは、 任意の値を取るようにしてもよい。 DVRVolumeOは、 ポリューム （ディスク） の内容を記述する情報をストアする。 図 1 6は、 DVRVolume( )のシンタクスを示す図である。 図 1 6に示した DVR Volum e( )のシンタクスを説明するに、 version_numberは、 この DVRVolume( )のバージョ ンナンバ一を示す 4個のキャラク夕一文字を示す。 version一 numberは、 I S O 6 4 6に従って、 "0045"と符号化される。
lengthは、 この lengthフィールドの直後から DVRVolume( )の最後までの DVRVolu me( )のバイ ト数を示す 3 2 ビヅ トの符号なし整数で表される。
Resume Volume( )は、 ポリュームの中で最後に再生した Real PlayList又は Virtu al PlayListのファイル名を記憶している。 但し、 Real PlayList又は Virtual PI ayListの再生をユーザが中断したときの再生位置は、 PlayListMark( )において定 義される resume-markにストァされる。
図 1 7は、 ResumeVolume( )のシンタクスを示す図である。 図 1 7に示した Resu meVolume( )のシンタクスを説明するに、 val id_f lagは、 この 1ビヅトのフラグが 1にセヅトされている場合、 r*esume_PlayList_nameフィールドが有効であること を示し、 このフラグが 0にセットされている場合、 3 6ー？1 & 1^ 31 _1½1116フィー ルドが無効であることを示す。
resume_PlayList_naiiieの 1 0バイ トのフィ一ルドは、 リジュームされるべき Re al PlayList又は Virtual PlayListのファイル名を示す。
図 1 6に示した DVRVolumeOのシンタクスの中の、 UIApp Info Volume は、 ボリュ ームについてのユーザィン夕フェースアプリケ一ションのパラメ一夕をストアす る。 図 1 8は、 UIAppInfoVolumeのシンタクスを示す図であり、 そのセマンテイク スを説明するに、 character_setの 8ビヅトのフィ一ルドは、 Volume— nameフィ一 ルドに符号化されているキャラクタ一文字の符号化方法を示す。 その符号化方法 は、 図 1 9に示される値に対応する。
name_l engthの 8ビヅ トフィールドは、 Vo lume_nameフィールドの中に示されるボ リューム名のバイ ト長を示す。 Volume—nameのフィールドは、 ボリュームの名称を 示す。 このフィールドの中の左から name_length数のバイ ト数が、 有効なキャラク ター文字であり、 それはボリュームの名称を示す。 Volume_nameフィールドの中で、 それら有効なキャラクタ一文字の後の値は、 どんな値が入っていてもよい。 Voluiae_protect一 flagは、 ボリュームの中のコンテンヅを、 ユーザに制限するこ となしに見せてよいかどうかを示すフラグである。 このフラグが 1にセットされ ている場合、 ユーザが正しく P I N番号 （パスワード） を入力できたときだけ、 そのボリュームのコンテンヅを、 ユーザに見せること （再生されること） が許可 される。 このフラグが 0にセットされている場合、 ユーザが P I N番号を入力し なくても、 そのボリュームのコンテンヅを、 ュ一ザに見せることが許可される。 最初に、 ユーザが、 ディスクをプレーヤへ挿入した時点において、 もしこのフ ラグが 0にセヅトされているか、 又は、 このフラグが 1にセットされていてもュ 一ザが P I N番号を正しく入力できたならば、 記録再生装置 1は、 そのディスク の中の PlayListの一覧を表示させる。 それそれの PlayListの再生制限は、 volume _protect_flagとは無関係であり、 それは UIAppInfoPlayList( )の中に定義される playback— control— flagによって示される。
P I Nは、 4個の 0乃至 9までの数字で構成され、 それそれの数字は、 I S O / I E C 6 4 6に従って符号化される。 ref_thumbnai l_indexのフィールドは、 ボリユームに付加されるサムネイル画像の情報を示す。 ref一 thumbnaiし indexフィ 一ルドが、 OxFFFFでない値の場合、 そのボリュームにはサムネイル画像が付加さ れており、 そのサムネイル画像は、 menu. thumファイルの中にストアされている。 その画像は、 menu. thumファイルの中で ref— thumbnai l_indexの値を用いて参照さ れる。 ref— thumtmail— indexフィールドが、 OxFFFF である場合、 そのボリューム にはサムネィル画像が付加されていないことを示す。
次に図 1 5に示した info. dvrのシンタクス内の TableOfPlayLists( )について説 明する。 TableOfPlayLists( )は、 PlayList(Real PlayListと Virtual PlayList)の ファイル名をストアする。 ポリユームに記録されている全ての PlayListファイル は、 TableOfPlayList( )の中に含まれる。 TableOfPlayLists( )は、 ボリュームの中 の PlayListのデフォルトの再生順序を示す。
図 2 0は、 TableOfPlayLists( )のシンタクスを示す図であり、 そのシンタクス について説明するに、 TableOfPlayListsの version— numberは、 この TableOfPlayL istsのパージョンナンバーを示す 4個のキャラク夕一文字を示す。 version—numb erは、 I S O 6 4 6に従って、 " 0045"と符号化されなければならない。 lengthは、 この lengthフィールドの直後から TableOfPlayListsOの最後までの TableOfPlayListsOのバイ ト数を示す 3 2ビットの符号なしの整数である。 numb er_of_PlayListsの 1 6ビットのフィールドは、 PlayList_f i le_nameを含む for-1 oopのループ回数を示す。 この数字は、 ボリュ一ムに記録されている PlayListの数 に等しくなければならない。 PlayList_f i le— nameの 1 0バイ トの数字は、 PlayLi stのファイル名を示す。
図 2 1は、 TableOfPlayListsOのシンタクスを別の例を示す図である。 図 2 1 に示したシンタクスは、 図 2 0に示したシンタクスに、 UIAppinfoPlayList (後 述） を含ませた構成とされている。 このように、 UIAppinfoPlayListを含ませた構 成とすることで、 TableOfPlayListsを読み出すだけで、 メニュー画面を作成する ことが可能となる。 ここでは、 図 2 0に示したシンタクスを用いるとして以下の 説明をする。
図 1 5に示した info. dvrのシン夕クス内の MakersPrivateDataについて説明する c MakersPrivateDataは、 記録再生装置 1のメーカが、 各社の特別なアプリケ一ショ ンのために、 MakersPrivateData( )の中にメーカのプライべ一トデータを挿入でき るように設けられている。 各メーカのプライペートデ一夕は、 それを定義したメ —力を識別するために標準化された] aaker一 IDを持つ。 MakersPrivateData( )は、 1 つ以上の maker_IDを含んでもよい。
所定のメーカが、 プライペートデータを挿入したいときに、 既に他のメーカの プライべ一トデ一夕が MakersPrivateData( )に含まれていた場合、 他のメーカは、 既にある古いプライベートデータを消去するのではなく、 新しいプライべ一トデ 一夕を MakersPrivateData( )の中に追加するようにする。 このように、 本例におい ては、 複数のメーカのプライべ一トデ一夕が、 1つの MakersPrivateData( )に含ま れることが可能であるようにする。
図 2 2は、 MakersPrivateDataのシンタクスを示す図である。 図 2 2に示した M akersPrivateDataのシンタクスについて説明するに、 vers ion—匪 berは、 この Ma kersPrivateData( )のバージョンナンパ一を示す 4個のキャラクタ一文字を示す。 version_numberは、 I S O 6 4 6に従って、 " 0045"と符号化されなければならな い。 lengthは、 この lengthフィールドの直後から MakersPrivateData( )の最後まで の MakersPrivateData( )のバイ ト数を示す 3 2 ビッ トの符号なし整数を示す。 mp locks-Start一 addressは、 MakersPrivateData( )の先頭のノ イ 卜からの相対 バイ ト数を単位として、 最初の mpd_block( )の先頭バイ トアドレスを示す。 相対バ ィ 卜数は 0からカウン卜される o mimber_o: _maker一 entriesはヽ MakersPrivateDa ta( )の中に含まれているメーカプライべ一トデ一夕のェントリ数を与える 1 6ビ ヅ トの符号なし整数である。 MakersPrivateData( )の中に、 同じ maker_IDの値を持 つメーカプライペートデ一夕が 2個以上存在してはならない。
mpd_block_sizeは、 1◦ 2 4バイ トを単位として、 1つの mpd_blockの大きさを 与える 1 6ビッ トの符号なし整数である。 例えば、 mpd_block_size= lならば、 そ れは 1つの mpd— Mockの大きさが 1 ◦ 2 4バイ トであることを示す。 number_of_m pd_blocksは、 MakersPrivateData( )の中に含まれる mpd—blockの数を与える 1 6ビ ヅ トの符号なし整数である。 nakerjDは、 そのメーカプライベートデータを作成 した D V Rシステムの製造メーカを示す 16ビヅ トの符号なし整数である。 maker— IDに符号化される値は、 この D V Rフォーマヅトのライセンサによって指定され る。
maker_modeし codeは、 そのメーカプライべ一トデータを作成した D V Rシステ ムのモデルナンバーコードを示す 1 6ビヅトの符号なし整数である。 makerjiiode し codeに符号化される値は、 このフォーマヅ トのライセンスを受けた製造メーカ によって設定される。 start_mpd_block_numberは、 そのメーカブライべ一トデ一 夕が開始される mpd一 blockの番号を示す 1 6ビッ トの符号なし整数である。 メーカ プライべ一トデ一夕の先頭データは、 nipd_blockの先頭にァラインされなければな らな 1/ヽ。 start_mpd— block—numberiま、 mpd_blockの for— loopの中の変数 j【こ対応す る。
nipd_lengthは、 バイ ト単位でメーカプライペートデータの大きさを示す 3 2ビ ヅ トの符号なし整数である。 mpdjlockは、 メーカプライベートデ一夕がストアさ れる領域である。 MakersPrivateData( )の中の全ての mpd_blockは、 同じサイズで なければならない。
次に、 Real PlayList fi leと Virtual PlayList fi leについて、 換言すれば、 x xxxx.rplsと yyyyy.vplsについて説明する。 図 2 3は、 xxxxx. r ls (Real PlayLi st) 、 又は、 yyyyy.vpls (Virtual PlayList) のシンタクスを示す図である。 xx xxx, rplsと yyyyy,vplsは、 同一のシン夕クス構成を持つ 0 xxxx . r 1 s yyy . vp Isは、 それそれ、 3個のオブジェクトから構成され、 それらは、 PlayList( )、 PI ayL i s tMark ( )、 及ぴ Make rP r i vat eD ata ( )である。
PlayListMark_Start_addressは、 PlayListファイルの先頭のバイ 卜からの相対 バイ ト数を単位として、 PlayListMarkOの先頭アドレスを示す。 相対バイ ト数は 0からカウントされる。
MakerPrivateData—Start一 addressま、 PlayListファィノレの先頭のノ イ ト力 らの 相対バイ ト数を単位として、 MakerPrivateData( )の先頭アドレスを示す。 相対バ ィ ト数は 0からカウントされる。
padding_ ord (パディングワード） は、 PlayListファイルのシンタクスに従つ て挿入され、 1と 2は、 0又は任意の正の整数である。 それそれのパディン グワードは、 任意の値を取るようにしてもよい。
ここで、 既に、 簡便に説明したが、 PlayListについて更に説明する。 ディスク 内にある全ての Real PlayListによって、 Bridge-Cl ip (後述） を除く全ての Cl ip の中の再生区間が参照されていなければならない。 且つ、 2つ以上の Real PI ayL istが、 それらの Playltemで示される再生区間を同一の Cl ipの中でォ一パーラヅプ させてはならない。
図 2 4を参照して更に説明するに、 図 2 4 Aに示したように、 全ての Cl ipは、 対応する Real PlayListが存在する。 この規則は、 図 2 4 Bに示したように、 編集 作業が行われた後においても守られる。 したがって、 全ての Cl ipは、 どれかしら の Real PlayListを参照することにより、 必ず視聴することが可能である。
図 2 4 Cに示したように、 Virtual PlayListの再生区間は、 Real PlayListの再 生区間又は Bridge- Cl ipの再生区間の中に含まれていなければならない。 どの Vir tual PlayListにも参照されない Bridge- Cl ipがディスクの中に存在してはならな い。
Real PlayListは、 Playltemのリストを含むが、 SubPlayltemを含んではならな い。 Virtual PlayListは、 Playltemのリストを含み、 PlayList( )の中に示される CPI_typeが EP_map typeであり、 且つ PlayList typeが 0 (ビデオとオーディオを含 む PlayList) である場合、 Virtual PlayListは、 1つの SubPlayltemを含むことが できる。 本例における PlayList( )では、 SubPlaylteはオーディオのアフレコの目 的にだけに使用される、 そして、 1つの Virtual PlayListが持つ SubPlayltemの数 は、 0又は 1でなければならない。
次に、 PlayListについて説明する。 図 2 5は、 PlayListのシンタクスを示す図 である。 図 2 5に示した PlayListのシンタクスを説明するに、 version_numberは、 この PlayList( )のバ一ジョンナンバーを示す 4個のキャラクタ一文字である。 ve rsion_numberは、 I S O 6 4 6に従って、 " 0045"と符号化されなければならない t lengthは、 この lengthフィールドの直後から PlayList( )の最後までの HayList( ) のバイ ト数を示す 3 2ビヅトの符号なし整数である。 PlayList_typeは、 この Pla yListの夕ィプを示す 8ビヅトのフィールドであり、 その一例を図 2 6に示す。
CPI_typeは、 1ビットのフラグであり、 Playltem( )及び SubPlayItem( )によって 参照される Cl ipの CPし typeの値を示す。 1つの PlayListによって参照される全て の Cl ipは、 それらの CPI ( )の中に定義される CPし typeの値が同じでなければならな い。 number— of_PlayItemsは、 PlayListの中にある Playltemの数を示す 1 6ビヅ ト のフィールドである。
所定の Playltem( )に対応する Playltem_idは、 Playltem( )を含む for- loopの中で、 その Playltem( )の現れる順番により定義される。 Playltemjdは、 0から開始され る。 number— of _SubP lay Itemsは、 PlayListの中にある SubPlayltemの数を示す 1 6 ビヅ トのフィールドである。 この値は、 0又は 1である。 付加的なオーディオス トリ一ムのパス （オーディオストリームパス） は、 サブパスの一種である。
次に、 図 2 5に示した PlayListのシンタクスの UIAppInfoPlayListについて説明 する。 UIAppInfoPlayListは、 PlayListについてのユーザインタフヱ一スアプリケ ーシヨンのパラメ一夕をストアする。 図 2 7は、 UIAppInfoPlayListのシンタクス を示す図である。 図 2 7に示した UIAppInfoPlayListのシンタクスを説明するに、 character_setは、 8ビットのフィールドであり、 PlayList— nameフィールドに符 号化されているキャラクタ一文字の符号化方法を示す。 その符号化方法は、 図 1 9に示したテーブルに準拠する値に対応する。
name_lengthは、 8ビヅトフィールドであり、 PlayList— nameフィールドの中に 示される PlayList名のバイ ト長を示す。 PlayList__nameのフィールドは、 PlayLis tの名称を示す。 このフィールドの中の左から namejength数のバイ ト数が、 有効 なキャラク夕一文字であり、 それは PlayListの名称を示す。 PlayList_nameフィー ルドの中で、 それら有効なキャラク夕一文字の後の値は、 どんな値が入っていて もよい。
record_time_and_dateは、 PlayListが記録されたときの日時をストァする 5 6 ビッ トのフィールドである。 このフィールドは、 年/月/日/時/分/秒につい て、 1 4個の数字を 4ビットの Binary Coded Decimal ( B C D ) で符号化したも のである。 例えば、 2001/12/23: 01 : 02 : 03 は、 "0x20011223010203"と符号化され る。
durationは、 PlayListの総再生時間を時間/分/秒の単位で示した 2 4ビヅ ト のフィールドである。 このフィールドは、 6個の数字を 4ビットの Binary Coded Decimal ( B C D ) で符号化したものである。 例えば、 01 :45 :30は、 "0x014530" と符号化される。
val id— periodは、 PlayListが有効である期間を示す 3 2 ビヅ トのフィールドで ある。 このフィールドは、 8個の数字を 4ビットの Binary Coded Decimal ( B C D ) で符号化したものである。 例えば、 記録再生装置 1は、 この有効期間の過ぎ た PlayListを自動消去する、 といったように用いられる。 例えば、 2001/05/07 は、 "0x20010507"と符号化される。
maker_idは、 その PlayListを最後に更新した D V Rプレーヤ （記録再生装置 1 ) の製造者を示す 1 6ビッ トの符号なし整数である。 makerjdに符号化される 値は、 D V Rフォーマヅトのライセンサによって割り当てられる。 maker_codeは、 その PlayListを最後に更新した D V Rプレーヤのモデル番号を示す 1 6ビットの . 符号なし整数である。 maker_codeに符号化される値は、 D V Rフォーマットのラ ィセンスを受けた製造者によって決められる。
playback_controし； f lagのフラグが 1にセヅトされている場合、 ユーザが正しく P I N番号を入力できた場合にだけ、 その PlayListは再生される。 このフラグが 0にセットされている場合、 ユーザが P I N番号を入力しなくても、 ユーザは、 その PlayListを視聴することができる。 write_protect_flagは、 図 2 8 Aにテーブルを示すように、 1にセッ トされて いる場合、 write_protect_flagを除いて、 その PlayListの内容は、 消去及ぴ変更 されない。 このフラグが 0にセットされている場合、 ユーザは、 その PlayListを 自由に消去及び変更できる。 このフラグが 1にセヅ トされている場合、 ユーザが、 その PlayListを消去、 編集、 又は上書きする前に、 記録再生装置 1はユーザに再 確認するようなメッセージを表示させる。
write_protect一 f lagが 0にセットされている Real PlayListが存在し、 且つ、 そ の Real PlayListの Cl ipを参照する Virtual PlayListが存在し、 その Virtual Pla yListの write_protect_f lagが 1にセッ トされていてもよい。 ユーザが、 RealPla yListを消去しょうとする場合、 記録再生装置 1は、 その Real PlayListを消去す る前に、 上記 Virtual PlayListの存在をユーザに警告するか、 又は、 その Real P layListを" Minimize'' する。
is— play6d_flagは、 図 2 8 Bに示すように、 フラグが 1にセットされている場 合、 その PlayListは、 記録されてから 1度は再生されたことを示し、 0にセッ ト されている場合、 その PlayListは、 記録されてから 1度も再生されたことがない ことを示す。
archiveは、 図 2 8 Cに示すように、 その PlayListがオリジナルであるか、 コピ —されたものであるかを示す 2ビットのフィ一ルドである。 ref_thunibnaiし inde X のフィールドは、 PlayListを代表するサムネイル画像の情報を示す。 ref_thum bnai l— indexフィールドが、 OxFFFFでない値の場合、 その PlayListには、 PlayLis tを代表するサムネイル画像が付加されており、 そのサムネイル画像は、 menu.th um ファイルの中にストアされている。 その画像は、 menu. thuiiiファイルの中で re ： Lthumbnaiし indexの値を用いて参照される。 ref— thumbnai l— indexフィールドが、 OxFFFF である場合、 その PlayListには、 PlayListを代表するサムネイル画像が付 加されていない。
次に Playltemについて説明する。 1つの Playltem( )は、 基本的に次のデータを 含む。 Cl ipのファイル名を指定するための Cl ip_information_fi le_name、 Cl ipの 再生区間を特定するための IN_timeと 0UT_timeのペア、 PlayList( )において定義さ れる CPし typeが EP map typeである場合、 IN timeと 0UT_timeが参照するところの STC_sequence_id、 及び、 先行する Playltemと現在の Playltemとの接続の状態を示 すところの connect ion_condit ionである 0
PlayListが 2つ以上の Playltemから構成されるとき、 それらの Playlteiaは Play Listのグローバル時間軸上に、 時間のギヤヅプ又はオーバーラップなしに 1列に 並べられる。 PlayList()において定義される CPI_typeが EP— map typeであり、 且つ 現在の Playltemが BridgeSequence()を持たないとき、 その Playltemにおいて定義 される IN_timeと 0UT_t imeのペアは、 STC_sequence— idによつて指定される同じ S T C連続区間上の時間を指していなければならない。 そのような例を図 29に示 す。
図 30は、 PlayList()において定義される CPし typeが EPjnap typeであり、 且つ 現在の Playltemが BridgeSequence()を持つとき、 次に説明する規則が適用される 場合を示している。 現在の Playltemに先行する Playltemの IN_time (図の中で IN— timelと示されているもの）は、 先行する Playltemの STC_sequence— idによつて指定 される S T C連続区間上の時間を指している。 先行する？1 711：6111の01111_^]116 (図 の中で 0UT_timelと示されているもの） は、 現在の Playltemの BridgeSequencelnf o()の中で指定される Bridge-Clipの中の時間を指している。 この OUT一 timeは、 後 述する符号化制限に従っていなければならない。
現在の Play Itemの IN— time (図の中で IN_time2と示されているもの） は、 現在の Playltemの BridgeSequenceInfo()の中で指定される Bridge-Clipの中の時間を指し ている。 この IN_timeも、 後述する符号化制限に従っていなければならない。 琅在 の P 1 ay I tenの P 1 ay I temの OUT— t ime (図の中で 0UT_t ime2と示されているもの）は、 現在の Playltemの STC—sequence_idによって指定される S T C連続区間上の時間を 指している。
図 3 1に示すように、 PlayList()の CPし typeが TUjnap typeである場合、 Playl temの IN_timeと OUT一 timeのペアは、 同じ Clip A Vストリーム上の時間を指してい る。
Playltemのシンタクスは、 図 32に示すようになる。 図 32に示した Playltem のシンタクスを説明するに、 Clip_Information_file_nameのフィ一ルドは、 Clip Information f i leのファイル名を示す。 この Clip Information fileの Cliplnfo ( )において定義される Cl ip_stream_typeは、 Cl ip AV streamを示していなければ ならない。
STC_sequence_idは、 8ビットのフィールドであり、 Playltemが参照する S T C 連続区間の STC一 s equence一 i dを示す。 PlayList( )の中で指定される CPI.typeが TU_ map typeである場合、 この 8ビッ トフィールドは何も意味を持たず、 0にセヅト される。 IN_timeは、 3 2ビヅ トフィールドであり、 Playltemの再生開始時刻をス トァする。 IN_tinieのセマンティクスは、 図 3 3に示すように、 PlayList( )におい て定義される CPI一 typeによって異なる。
OUT—timeは、 3 2 ビヅ トフィールドであり、 Playltemの再生終了時刻をス トア する。 0UT_timeのセマンティクスは、 図 3 4に示すように、 PlayList( )において 定義される CPI_typeによって異なる。
Connection— Conditionは、 図 3 5に示したような先行する P layltemと、 現在の Playltemとの間の接続状態を示す 2ビヅトのフィールドである.。 図 3 6 A〜図 3 6 Dは、 図 3 5に示した Connection_Conditionの各状態について説明する図であ る。
次に、 BridgeSequencelnfoについて、 図 3 7を参照して説明する。 BridgeSequ enceInfo( )は、 現在の Playltemの付属情報であり、 次に示す情報を持つ。 Bridge -Cl ip AV streamファイルとそれに対応する Cl ip Information fi leを指定する Br i dge^G 1 i p_ I nf ormat i on_f i 1 e_nameを含む。
また、 先行する Playltemが参照する Cl ip AV stream上のソースパケヅトのアド レスであり、 このソースパケットに続いて Bridge-Cl ip AV streamファイルの最初 のソースパケッ トが接続される。 このアドレスは、 RSPN一 exit_froia_previous一 C1 ipと称される。 更に現在の Playltemが参照する Cl ip AV stream上のソースパケヅ トのァドレスであり、 このソースパケヅトの前に Bridge- Cl ip AV streamファイル の最後のソースパケヅ トが接続される。 このアドレスは、 RSPN—enter— to_curren t_Cl ipと称される。
図 3 7において、 RSPN— arrival— time— discontinuityは、 the Bridge-Cl ip AVs treamファイルの中でァライバル夕ィムベースの不連続点があるところのソースパ ケヅトのアドレスを示す。 このアドレスは、 Cl ipInfoOの中において定義される。 図 3 8は、 BridgeSequenceinfoのシンタクスを示す図である。 図 3 8に示した BridgeSequenceinfoのシンタクスを説明するに、 B r i dge_C 1 i p_I nf ormat i on_f i 1 e —nameのフィールドは、 Bridge-Cl ip AV streamファイルに対応する Cl ip Informa tion fileのファイル名を示す。 この Cl ip Information f i leの ClipInfo( )におい て定義される Cl ip_stream_typeは、 ' Bridge-Cl ip AV stream，を示していなければ ならない。
RSPN_exit_froni_previous_Cl ipの 3 2 ビヅ トフィールドは、 先行する Playltem が参照する Cl ip AV stream上のソースパケヅトの相対ァドレスであり、 このソー スパケットに続いて Bridge-Cl ip AV streamファイルの最初のソースパケットが接 続される。 RSPN_exit_from_previous_Cl ipは、 ソースパケット番号を単位とする 大きさであり、 先行する Playltemが参照する Cl ip AV streamファイルの最初のソ —スパケヅ トから Cl ipInfo( )において定義される offset_SPNの値を初期値として カウントされる。
RSPILenter_to_current— Cl ipの 3 2 ビヅトフィールドは、 現在の Playltemが参 照する Cl ip AV stream上のソースパケヅ 卜の相対ァドレスであり、 このソースパ ケヅトの前に Bridge-Cl ip AV streamファイルの最後のソースパケットが接続され る。 RSPN_exit— from_previous_Cl ipは、 ソースパケッ ト番号を単位とする大きさ であり、 現在の Playltemが参照する Cl ip AV streamファイルの最初のソースパケ ヅトから Cl ipInfo( )において定義される offset— SPNの値を初期値としてカウント される。
次に、 SubPlayltemについて、 図 3 9を参照して説明する。 Su layItem( )の使 用は、 PlayList( )の CPし typeが EP_map typeである場合だけに許される。 本例にお いては、 SubPlayltemはオーディオのアフレコの目的のためだけに使用されるとす る。 SubPlayItem( )は、 次に示すデータを含む。 先ず、 PlayListの中の sub pathが 参照する Cl ipを指定するための Cl ip_inforniation_fi le_ nameを含む。
また、 Cl ipの中の sub pathの再生区間を指定するための SubPath— IN_time と S ubPath_OUT_timeを含む。 更に、 main pathの時間軸上で sub pathが再生開始する 時刻を指定するための sync_PlayItem_id と sync_start_PTS_of_PlayItemを含む。 sub pathに参照されるオーディオの Cl ip AV streamは、 S T C不連続点 （システ ムタイムペースの不連続点） を含んではならない。 sub pathに使われる Cl ipのォ —ディオサンプルのクロヅクは、 main pathのオーディオサンプルのクロヅクに口 ヅクされている。
図 4 0は、 SubPlayltemのシンタクスを示す図である。 図 4 0に示した SubPlay Itemのシンタクスを説明するに、 Cl ip_Infoi>mation一 f i le_nameのフィールドは、 Cl ip Information fi leのファイル名を示し、 それは PlayListの中で sub pathによ つて使用される。 この Cl ip Information f i leの Cl ipInfo( )において定義される C l ip_stream_typeは、 Cl ip AV streamを示していなければならない。
SubPath— typeの 8ビヅトのフィールドは、 sub pathのタイプを示す。 ここでは、 図 4 1に示すように、 ' 0x00'しか設定されておらず、 他の値は、 将来のために確 保されている。
sync— Playltem— idの 8 ビヅ トのフィールドは、 ain pathの時間軸上で sub pat hが再生開始する時刻が含まれる Playltemの Playltem一 idを示す。 所定の Playltem に対応する Playltem_idの値は、 PlayList( )において定義される （図 2 5参照） 。 sync_s tar t_PTS_of _P 1 ay I tem© 3 2 ビヅ トのフィールドは、 main pathの時間軸 上で sub pathが再生開始する時刻を示し、 sync_PlayItem_idで参照される Playlt em上の P T S (Presentaiotn Time Stamp)の上位 3 2ビットを示す。 SubPath— IN_ timeの 3 2ビヅトフィールドは、 Sub pathの再生鬨始時刻をストアする。 SubPat h_IN_timeは、 Sub Pathの中で最初のプレゼンテーションュニヅトに対応する 3 3 ビヅト長の P T Sの上位 3 2ビッ トを示す。
SubPath_0UT_tineの 3 2ビットフィ一ルドは、 Sub pathの再生終了時刻をスト ァする。 SubPath—OUT— timeは、 次式によって算出される Presenation_end_TSの値 の上位 3 2 ビッ トを示す。
Presentation_end_TS = PTS_out + AU_duration
ここで、 PTS_outは、 SubPathの最後のプレゼンテーションュニヅ卜に対応する 33 ビヅ ト長の P T Sである。 AU— durationは、 SubPathの最後のプレゼンテーション ュニッ卜の 9 0 k H z単位の表示期間である。
次に、 図 2 3に示した xxxxx. rplsと yyyyy.vplsのシンタクス内の PlayListMark ( )について説明する。 PlayListについてのマーク情報は、 この PlayListMarkにス トァされる。 図 4 2は、 PlayListMarkのシンタクスを示す図である。 図 4 2に示 した PlayListMarkのシンタクスについて説明するに、 version— numberは、 この PI ayListMark( )のバ一ジョンナンバーを示す 4個のキャラクタ一文字である。 vers ion_numberは、 I S O 6 4 6に従って、 " 0045"と符号化されなければならない。 lengthは、 この lengthフィールドの直後から P layListMark( )の最後までの Play ListMark( )のパイ ト数を示す.3 2 ビヅ トの符号なし整数である。 number— of _P lay List_marksは、 PlayListMarkの中にストアされているマークの個数を示す 1 6ビ ヅ トの符号なし整数である。 nuniber_of_PlayList_]iiarks は、 0であってもよい。 mark_typeは、 マークのタイプを示す 8ビットのフィールドであり、 図 4 3に示す テーブルに従って符号化される。
mark_time_stanipの 3 2ビヅトフィールドは、 マークが指定されたポィントを示 す夕ィムスタンプをストァする。 mark— time— stampのセマンティクスは、 図 4 4に 示すように、 PlayList( )において定義される CPI— typeによって異なる。 Playltem —idは、 マ一クが置かれているところの Playltemを指定する 8 ビヅ トのフィールド である。 所定の Playltemに対応する Playltem_idの値は、 PlayList( )において定義 される （図 2 5参照） 。
character_setの 8ビヅ トのフィールドは、 mark_nameフィールドに符号化され ているキャラクタ一文字の符号化方法を示す。 その符号化方法は、 図 1 9に示し た値に対応する。 name_lengthの 8ビヅ トフィールドは、 Mark_nameフィールドの 中に示されるマーク名のバイ ト長を示す。 mark— nameのフィールドは、 マークの名 称を示す。 このフィールドの中の左から name_length数のバイ ト数が、 有効なキヤ ラク夕一文字であり、 それはマークの名称を示す。 Mark_nameフィールドの中で、 それら有効なキャラクタ一文字の後の値は、 どのような値が設定されてもよい。 ref_thumbnai l_indexのフィールドは、 マークに付加されるサムネイル画像の情 報を示す。 ref_tlmmbnaiし indexフィールドが、 OxFFFFでない値の場合、 そのマー クにはサムネイル画像が付加されており、 そのサムネイル画像は、 mark. thmbファ ィルの中にストアされている。 その画像は、 mark. thmbファイルの中で ref_tlmmb nai l— indexの値を用いて参照される （後述） 。 r*ef_thumbnaiし indexフィールドが、 OxFFFF である場合、 そのマークにはサムネイル画像が付加されていないことを示 82605^一
PCT/JP01/03412
37 す。
次に、 Clip information fileについて説明する。 zzzzz.clpi (Clip informat ion fileファイル） は、 図 45に示すように 6個のオブジェクトから構成される。 それらは、 ClipInfo()、 STC_Info() ProgramInfo( )、 CPI()、 ClipMark(〉、 及び MakerPrivateDataOである。 A Vストリーム（Clip A Vストリーム又は Bridge-C lip AV stream)とそれに対応する Clip Informationファイルは、 同じ数字列の" z zzzz"が使用される。
図 45に示した zzzzz.clpi (Clip information fileファイル） のシンタクス ついて説明するに、 Cliplnfo— Start_addressは、 zzzzz.clpiファイルの先頭のバ ィ トからの相対バイ ト数を単位として、 ClipInio()の先頭アドレスを示す。 相対 バイ ト数は 0からカウントされる。
STC_Info_Start—addressは、 zzzzz.clpiファイルの先頭のバイ トからの枏対 ィ ト数を単位として、 STC—Info()の先頭アドレスを示す。 相対バイ ト数は◦から カウントされる。 ProgramInfo_Start_addressは、 zzzzz.clpiファイルの先頭の ィ トからの相対バイ ト数を単位として、 ProgramInfo()の先頭アドレスを示す。 対バイ ト数は 0からカウントされる。 CPし Start_addressは、 zzzzz.clpiフアイ の先頭のバイ トからの相対バイ ト数を単位として、 CPI()の先頭アドレスを示す 相対バイ ト数は 0からカウントされる。
ClipMark— Start_addressは、 zzzzz.clpiファイルの先頭のバイ トからの相対. ) イ ト数を単位として、 ClipMark()の先頭アドレスを示す。 相対バイ ト数は 0か ' カウントされる o MakerPrivateData一 Start_addressiま、 zzzzz.clpiフアイノレの ； 頭のバイ トからの相対バイ ト数を単位として、 MakerPrivateData (〉の先頭ァ ' スを示す。 相対バイ ト数は 0からカウントされる。 padding_woi«d (パディング ' —ド） は、 zzzzz.clpiファイルのシンタクスに従って挿入される。 N l， N2 N 3 , N 4s 及び N 5は、 0又は任意の正の整数でなければならない。 それ^ ？ のパディングヮ一ドは、 任意の値がとられるようにしてもよい。
次に、 Cliplnfoについて説明する。 図 46は、 Cliplnfoのシンタクスを示 \ である。 ClipInfo()は、 それに対応する AVストリームファイル （Clip AV リーム又は Bridge-Clip AVストリームファイル） の属性情報をストアする < > 図 4 6に示した Cl iplnfoのシンタクスについて説明するに、 version_numberは、 この Cl ipInfo( )のパージョンナンバーを示す 4個のキャラク夕一文字である。 ve rsion_numberは、 I S O 6 4 6に従って、 " 0045"と符号化されなければならない < lengthは、 この lengthフィ一ルドの直後から Cl ipInfo( )の最後までの Cl ipInfo( ) のバイ ト数を示す 3 2 ビヅトの符号なし整数である。 Cl ip_stream_typeの 8 ビヅ トのフィールドは、 図 4 7に示すように、 Cl ip Informationファイルに対応する A Vストリームの夕ィプを示す。 それそれのタイプの A Vストリームのストリー ム夕ィプについては後述する。
offset— SPNの 3 2 ビヅ トのフィールドは、 A Vス トリーム （Cl ip A Vス ト リー ム又は Bridge- Cl ip A Vストリーム） ファイルの最初のソースパケヅ トについて のソースパケヅ ト番号のオフセヅト値を与える。 A Vストリームファイルが最初 にディスクに記録されるとき、. この offset_SPNは 0でなければならない。
図 4 8に示すように、 A Vストリームファイルのはじめの部分が編集によって 消去されたとき、 offset_SPNは、 0以外の値をとつてもよい。 本例では、 offset _SPNを参照する相対ソースパケヅ ト番号 （相対アドレス） が、 しばしば、 RSPN_x XX ( XXXは変形する。 例. RSPN_EP_start) の形式でシンタクスの中に記述されて いる。 相対ソースパケヅ ト番号は、 ソースパケヅ ト番号を単位とする大きさであ り、 A Vストリームファイルの最初のソースパケヅトから offset_SPNの値を初期 値としてカウントされる。
A Vストリームファイルの最初のソースパケヅトから相対ソースパケヅト番号 で参照されるソースパケットまでのソースパケヅトの数 （SPN_xxx) は、 次式で算 出される。
SPN_xxx = RSPN_xxx - offset_SPN
図 4 8に、 offset_SPN が、 4である場合の例を示す。
TS—recording_rateは、 2 4ビヅ トの符号なし整数であり、 この値は、 D V R ド ライブ （書込部 2 2 ) へ又は D V Rドライブ （読出部 2 8 ) からの A Vストリー ムの必要な入出力のビッ トレートを与える。 record_tinie_and_dateは、 Cl ipに対 応する A Vストリームが記録されたときの日時をストァする 5 6ビヅ トのフィー ルドであり、 年/月/日/時/分/秒について、 1 4個の数字を 4ビヅ トの Bina ry Coded Decimal (B CD) で符号化したものである。 例えば、 2001/12/23:01: 02:03 は、 0x20011223010203"と符号化される。
durationは、 Clipの総再生時間をァライバルタイムクロックに基づいた時間 Z 分/秒の単位で示した 24ビッ トのフィールドである。 このフィールドは、 6個 の数字を 4ビヅ トの Binary Coded Decimal (B CD) で符号化したものである。 例えば、 01 :45 :30は、 0x014530"と符号化される。
time一 controllecLflag:のフラグは、 AVス ト リームファイルの記録モードを示 す。 この time_controlled_:flagが 1である場合、 記録モードは、 記録してからの 時間経過に対してファイルサイズが比例するようにして記録されるモードである ことを示し、 次式に示す条件を満たさなければならない。
TS_average_rate*192/188*(t - start—time)—" <= size_cl ip(t)
<= TS_average_rate*192/188*(t - start_time) + a
ここで、 TS_average— rateは、 A Vスト リームファイルのトランスポートス トリー ムの平均ビヅトレートを bytes/second の単位で表したものである。
また、 上式において、 tは、 秒単位で表される時間を示し、 start_timeは、 A ストリームファイルの最初のソースパケヅトが記録されたときの時刻であり、 秒単位で表される。 size一 clip(t)は、 時刻 tにおける A Vストリームファイルの サイズをバイ ト単位で表したものであり、 例えば、 start_timeから時刻 tまでに 1 0個のソースパケヅトが記録された場合、 size一 clip(t)は 10*192バイ トである。 ひは、 TS_average_rateに依存する定数である。
time_controlled_flagが 0にセットされている場合、 記録モードは、 記録の時間 経過と AVストリームのファイルサイズが比例するように制御していないことを 示す。 例えば、 これは入力トランスポ一トストリームをトランスペアレント記録 する場合である。
TS— average— rateは、 time_controlled_flagが 1にセヅ トされている場合、 この 24ビットのフィールドは、 上式で用いている TS_average_rateの値を示す。 tim e_controlled_flagが 0にセヅトされている場合、 このフィールドは、 何も意味を 持たず、 0にセッ トされなければならない。 例えば、 可変ビットレートのトラン スポートストリームは、 次に示す手順により符号化される。 先ずトランスポート レートを TS— recording_rateの値にセヅトする。 次に、 ビデオストリームを可変ビ ヅ トレートで符号化する。 そして、 ヌルパケットを使用しないことによって、 間 欠的にトランスポートパケットを符号化する。
RSPN—arrival_time— discontinuityの 3 2 ビヅ トフィールドは、 Bridge-Cl ip A V streamファイル上でァライバルタイムベースの不連続が発生する場所の相対ァ ドレスである。 RSPN_arrival_time— discontinuityは、 ソースパケット番号を単位 とする大きさであり、 Bridge-Cl ip AV streamファイルの最初のソースパケヅトか ら Cl ipInfo( ) において定義される off set_SPNの値を初期値としてカウン卜される c その Bridge-Cl ip AV streamファイルの中での絶対アドレスは、 上述した
SPN_xxx = RSPN_xxx - offset_SPN
に基づいて算出される。
reserved_for_system_use© 1 4 4ビヅトのフィールドは、 システム用にリザ一 ブされている。 is— format— identifier_val idのフラグが 1であるとき、 format_i dentifierのフィールドが有効であることを示す。 is_original— network_ID_val i dのフラグが 1である場合、 originaし network_IDのフィ一ルドが有効であること 示す。 is一 transport—stream一 ID_val idのフラクが 1である場合、 transport一 st ream_IDのフィールドが有効であることを示す。 is_servece_ID_val idのフラグが 1である場合、 servece_IDのフィールドが有効であることを示す。
is— country_code一 val idのフラクが 1であるとき、 country_codeのフィール F が有効であることを示す。 foriiat_identif ierの 3 2ビヅトフィールドは、 トラン スポートス トリームの中で registration deascriotor ( I S O / I E C 1 3 8 1 8— 1で定義されている） が持つ: format—identifierの値を示す。 originaし netw ork一 IDの 1 6ビヅトフィールドは、 トランスポートストリームの中で定義されて いる original—network— IDの値を示す。 transport— stream_IDの 1 6ビヅ トフィー ルドは、 トランスポートストリ一ムの中で定義されている transport_stream— IDの 値を示す。
servece_IDの 1 6ビヅトフィ一ルドは、 トランスポートストリームの中で定義 されている servecejmの値を示す。 country_codeの 2 4ビヅトのフィールドは、 I S 0 3 1 6 6によって定義されるカントリーコードを示す。 それぞれのキャラ クタ一文字は、 I S 0 8 8 5 9— 1で符号化される。 例えば、 日本は" JPN"と表さ れ、 "0x4A 0x50 0x4E"と符号化される。 stream_: ormat— nameは、 トランスポート ス ト リームのストリーム定義をしているフォーマヅト機関の名称を示す I S O—
6 4 6の 1 6個のキャラクターコードである。 このフィ一ルドの中の無効なバイ トは、 値' OxFF，がセッ トされる。
format— 1 dent if ier、 original_networK一 ID、 transport_stream_ID servece_ ID, country一 code 、 及び stream— format— nameは、 トランスポートストリームのサ 一ビスプロバイダを示すものであり、 これにより、 オーディオやビデオストリ一 ムの符号化制限、 SI (サービスィンフオメーシヨン）の規格やオーディオビデオス トリーム以外のプライべ一トデ一夕ストリームのストリーム定義を認識すること ができる。 これらの情報は、 デコーダが、 そのストリームをデコードできるか否 か、 そしてデコードできる場合にデコード開始前にデコーダシステムの初期設定 を行うために用いることが可能である。
次に、 STC一 Infoについて説明する。 ここでは、 M P E G— 2 トランスポートス トリームの中で S T Cの不連続点 （システムタイムペースの不連続点） を含まな い時間区間を STC_sequenceと称し、 Cl ipの中で、 STC—sequenceは、 STC_sequence —idの値によって特定される。 図 5 O A及び図 5 0 Bは、 連続な S T C区間につい て説明する図である。 同じ STC一 sequenceの中で同じ S T Cの値は、 決して現れな い （但し、 後述するように、 C l ipの最大時間長は制限されている） 。 したがって、 同じ STC_sequenceの中で同じ P T Sの値もまた、 決して現れない。 A Vストリー ムが、 N(N>0 )個の S T C不連続点を含む場合、 C l ipのシステムタイムべ一スは、 ( N+ 1 )個の STC一 sequenceに分割される。
STC_Infoは、 S T Cの不連続 （システムタイムベースの不連続） が発生する場 所のアドレスをストアする。 図 5 1を参照して説明するように、 RSPN— STC_start が、 そのアドレスを示し、 最後の STC_sequenceを除く k番目 （k>=0) の STC_seque nceは、 k番目の RSPN— STC_startで参照されるソースパケヅトが到着した時刻から 始まり、 （k+1 )番目の RSPN_ST startで参照されるソースパケヅトが到着した時刻 で終わる。 最後の STC_sequenceは、 最後の RSPN_STC一 startで参照されるソースパ ケヅトが到着した時刻から始まり、 最後のソースパケヅトが到着した時刻で終了 する。
図 5 2は、 STC— Infoのシンタクスを示す図である。 図 5 2に示した STC一 Infoの シンタクスについて説明するに、 vers ion_nuiiibe ま、 この STC_Info( )のパージョ ンナンバーを示す 4個のキャラクタ一文字である。 vers ion— numberは、 I S O 6 4 6に従って、 "0045"と符号化されなければならない。
lengthは、 この lengthフィ一ルドの直後から STC_Info( )の最後までの STC— Info ( )のバイ ト数を示す 3 2 ビヅ トの符号なし整数である。 CP I Oの CP I_typeが TU_ma P typeを示す場合、 この lengthフィールドは 0をセヅトしてもよい。 CPI ( )の CP I — typeが EP_map typeを示す場合、 num— of— ST sequencesは 1以上の値でなければな らない。
num— of_STC_sequencesの 8ビットの符号なし整数は、 CI ipの中での STC— sequen ceの数を示す。 この値は、 このフィールドに続く: for- loopのループ回数を示す。 所定の STC_sequenceに対応する STC_sequence_idは、 RSPN— STC一 s tartを含む for- 1 oopの中で、 その STC一 sequenceに対応する RSPN_STC_startの現れる順番により定義 されるものである。 STC_sequence_idは、 0から開始される。
RSPN_STC— startの 3 2ビットフィールドは、 A Vストリ一ムファイル上で STC— sequenceが開始するアドレスを示す。 RSPN_STC一 startは、 A Vストリームフアイ ルの中でシステム夕ィムベースの不連続点が発生するァドレスを示す。 RSPN_STC _startは、 A Vストリームの中で新しいシステムタイムペースの最初の P C Rを 持つソースパケットの相対アドレスとしてもよい。 RSPN— STC_startは、 ソースパ ケヅ ト番号を単位とする大きさであり、 A Vストリームファイルの最初のソース パケットから CI iplnf o( )において定義される of f set_SPNの値を初期値としてカウ ントされる。 その A V streamファイルの中での絶対アドレスは、 既に上述した
SPN_xxx = RSPN— XXX - offset_SPN
により算出される。
次に、 図 4 5に示した zzzzz . c l ipのシンタクス内の Programlnfoについて説明す る。 図 5 3を参照しながら説明するに、 ここでは、 Cl ipの中で次の特徴を持つ時 間区間を prograin_sequenceと呼ぶ。 先ず、 PCR_P IDの値が変わらない。 次に、 ビデ ォエレメン夕リストリームの数が変化しない。 また、 それそれのビデオストリー ムについての P I Dの値とその VideoCodinglnfoによって定義される符号化情報が 変化しない。 更に、 ォ一ディォエレメンタリストリームの数が変化しない。 また、 それぞれのオーディォストリームについての P I Dの値とその AudioCodinglnfoに よって定義される符号化情報が変化しない。
program— sequenceは、 同一の時刻において、 ただ 1つのシステムタイムべ一ス を持つ。 program— sequenceは、 同一の時刻において、 ただ 1つの PMTを持つ。 Pro gramInfo( )は、 program_sequenceが開始する場所のアドレスをストアする。 RSPN _program_sequence_startが、 そのアドレスを示す。
図 5 4は、 Programlnfoのシンタクスを示す図である。 図 5 4に示した Program Infoのシン夕クを説明するに、 version_nuiiiberは、 この ProgramInfo( )のバージョ ンナンバーを示す 4個のキャラクタ一文字である。 version_n™berは、 I S O 6 4 6に従って、 "0045"と符号化されなければならない。
lengthは、 この lengthフィールドの直後から ProgramInfo( )の最後までの Progr amInfo( )のバイ ト数を示す 3 2 ビヅ トの符号なし整数である。 CPI( )の CPI_typeが TU_map typeを示す場合、 この lengthフィールドは 0にセヅ 卜されてもよい。 CPI ( )の CPI— typeが EP_map typeを示す場合、 nuniber_oiLprogramsは 1以上の値でなけ ればならない。
number—of— program一 sequencesの 8ビヅトの符号なし整数は、 Cl ipの中での pro gram„sequenceの数を示す。 この値は、 このフィールドに続く for-loopのループ回 数 ¾示す。 Cl ipの中で program一 sequenceが変ィ匕しない場合、 number一 of一 program一 seq猶 cesは 1をセヅ卜されなければならない。 RSPN一 program— sequence— startの 3 2ビヅトフィールドは、 A Vストリームファイル上でプログラムシーケンスが 開始する場所の相対ァドレスである。
HSPN— progr>am_sequence— startは、 ソースパケッ ト番号を単位とする大きさであ り、 A Vストリームファイルの最初のソースパケットから Cl ipInfo( )において定 義される offset_SPNの値を初期値としてカウントされる。 その A Vストリームフ アイルの中での絶対ァドレスは、
SPN_xxx = RSPN— XXX - offset_SPN
により算出される。 シンタクスの for-loopの中で RSPILprogram sequence start値 は、 昇順に現れなければならない。
PCR_PIDの 1 6ビットフィールドは、 その pr>ogram_sequenceに有効な P C Rフィ ールドを含むトランスポ一トパケヅトの P I Dを示す。 number— o:f_videosの 8ビ ヅ トフィーノレド fま、 video— stream— PIDと VideoCodingInfo( )を含む for— loopの レー プ回数を示す。 number— of— audiosの 8 ビヅトフィールドは、 audio_stream_PIDと AudioCodingInfo( )を含む for-loopのループ回数を示す 6 video— stream_PIDの 1 6 ビヅトフィールドは、 その prograin_sequenceに有効なビデオストリームを含むト · ランスポートパケットの P I Dを示す。 このフィールドに続く VideoCodinglnfo ( )は、 その video— stream— PIDで参照されるビデオストリームの内容を説明しなけ ればならない。
audio—stream一 PIDの 1 6 ビヅ トフィー レド ίま、 その program一 sequence【こ有効な オーディオストリームを含むトランスポートパケヅ 卜の P I Dを示す。 このフィ ールドに続く AudioCodingInfo( )は、 その audio_stream_PIDで参照されるビデオス トリームの内容を説明しなければならない。
なお、 シンタクスの for- loopの中で video_stream_PIDの値の現れる順番は、 そ の program_sequenceに有効な PMTの中でビデオストリームの P I Dが符号化されて いる順番に等しくなければならない。 また、 シンタクスの for- loopの中で audio_ streai_P IDの値の現れる順番は、 その program_sequenceに有効な PMTの中でォーデ ィォストリームの P I Dが符号化されている順番に等しくなければならない。
図 5 5は、 図 5 4に示した Programinfoのシンタクス内の VideoCodinglnfoのシ ン夕クスを示す図である。 図 5 5に示した VideoCodinglnfoのシンタクスを説明す るに、 video_formatの 8ビヅトフィールドは、 図 5 6に示すように、 Programlnf o( )の中の video_stream_PIDに対応するビデオフォーマヅトを示す。
frame_rateの 8ビットフィールドは、 図 5 7に示すように、 ProgramInfo( )の中 の video_stream_PIDに対応するビデオのフレ一ムレ一トを示す。 display_aspect —ratioの 8ビヅトフィールドは、 図 5 8に示すように、 ProgramlnfoOの中の vid eo_stream_PIDに対応するビデオの表示ァスぺクト比を示す。
図 5 9は、 図 5 4に示した Programinfoのシンタクス内の AudioCodinglnfoのシ ン夕クスを示す図である。 図 5 9に示した AudioCodinglnfoのシンタクスを説明す るに、 audio_codingの 8ビヅトフィールドは、 図 60に示すように、 Programlnf o()の中の audio_stream_PIDに対応するオーディオの符号化方法を示す。
audio— component— typeの 8ビヅトフィールドは、 図 6 1に示すように、 Progra mInfo()の中の audio_stream_PIDに対応するオーディオのコンポーネント夕ィプを 示す。 sampling— frequencyの 8ビヅトフィールドは、 図 62に示すように、 Prog ramInfo()の中の audio_stream_PIDに対応するオーディオのサンプリング周波数を 示す。
次に、 図 45に示した zzzzz. clipのシンタクス内の CP I (Characteristic P oint Information)について説明する。 C P Iは、 A Vストリームの中の時間情報 とそのファイルの中のァドレスとを関連付けるためにある。 CP Iには 2つの夕 イブがあり、 それらは EPjaapと Τϋ— mapである。 図 63に示すように、 CPI()の中の 0?し1^ 6が£?_]11^ typeの場合、 その CPI()は EP_mapを含む。 図 64に示すように、 CPI()の中の CPI_typeが TU_map typeの場合、 その CPI( )は TU_mapを含む。 1つの A Vストリームは、 1つの EP_map又は 1つの TU_mapを持つ。 A Vストリームが SE S Fトランスポートストリームの場合、 それに対応する Clipは EPjnapを持たなけ ればならない。
図 65は、 CP Iのシンタクスを示す図である。 図 65に示した CP Iのシン 夕クスを説明するに、 versioiummberは、 この CPI()のバージョンナンパ一を示す 4個のキャラクタ一文字である。 version_numberは、 I SO 646に従って、 " 0045"と符号化されなければならない。 lengthは、 この lengthフィールドの直後か ら CPI()の最後までの CPI()のバイ ト数を示す 32ビヅ トの符号なし整数である。 CPI— typeは、 図 66に示すように、 1ビヅ トのフラグであり、 Clipの C P Iの夕 ィプを表す。
次に、 図 65に示した C P Iのシンタクス内の EPjnapについて説明する。 EP_m apには、 2つの夕イブがあり、 それはビデオストリーム用の EP_mapとオーディオ ストリーム用の EPjnapである。 EPjnapの中の EPjnap— typeが、 EPjnapのタイプを区 別する。 Clipが 1つ以上のビデオストリームを含む場合、 ビデオストリーム用の EPjnapが使用されなければならない。 Clipがビデオストリームを含まず、 1っ以 上のオーディオストリームを含む場合、 オーディオストリーム用の EPjnapが使用 されなければならない。
ビデオストリーム用の EPjnapについて図 6 7を参照して説明する。 ビデオスト リーム用の EP_mapは、 stream_PID、 PTS_EP_start、 及び、 RSPN_EP_startというデ 一夕を持つ。 stream_PIDは、 ビデオストリームを伝送するトランスポートパケヅ トの P I Dを示す。 PTS_EP一 startは、 ビデオストリームのシーケンスヘッダから 始めるアクセスユニットの P T Sを示す。 RSPN_EP_startは、 A Vストリームの中 で PTS_EP_startにより参照されるアクセスュニッ トの第 1バイ ト目を含むソース ポケットのァドレスを示す。
EP_niap_for_one一 stream_PID( )と呼ばれるサブテーブルは、 同じ P I Dを持つト ランスポートパケヅ卜によって伝送されるビデオストリーム毎に作られる。 Cl ip の中に複数のビデオストリームが存在する場合、 EP— mapは複数の EP_niap_for— one —stream— PID( )を含んでもよい。
オーディオストリーム用の EP— mapは、 stream_PID、 PTS_EP_start、 及び RSPN— E P— startというデータを持つ。 stream_PIDは、 オーディオストリームを伝送するト ランスポートパケヅトの P I Dを示す。 PTS_EP_startは、 ォ一ディォストリーム のアクセスュニヅ トの P T Sを示す。 RSPN一 EP_startは、 A Vストリームの中で P TS_EP— startで参照されるアクセスュニヅトの第 1バイ ト目を含むソースポケヅト のァドレスを示す。
EP_map_for_one_stream_PID( )と呼ばれるサブテーブルは、 同じ P I Dを持つト ランスポートパケットによって伝送されるオーディオストリーム毎に作られる。 Cl ipの中に複数のオーディオストリームが存在する場合、 EP_mapは複数の EP— map 一 for_one— stream_PID( )を含んでもよい。
EP_mapと STC一 Infoの関係を説明するに、 1つの EPjnap— for— one_stream一 PID( )は、 S T Cの不連続点に関係なく 1つのテーブルに作られる。 RSPN一 EP一 startの値と S TC_Info( )において定義される RSPN_STC_startの値を比較することにより、 それそ れの STC_sequenceに属する EP_mapのデータの境界が分かる （図 6 8を参照） 。 EP —mapは、 同じ P I Dで伝送される連続したストリームの範囲に対して、 1つの EP _inap_for_one— stream_PIDを持たねばならない。 図 6 9に示したような場合、 pro gram#lと program#3は、 同じビデオ P I Dを持つが、 データ範囲が連続していない. ので、 それそれのプログラム毎に EP _map_f or_one— stream_P IDを持たねばならない ( 図 7 0は、 EP一 mapのシンタクスを示す図である。 図 7 0に示した EPjnapのシン 夕クスを説明するに、 EP_typeは、 4ビヅ トのフィールドであり、 図 7 1に示すよ うに、 EP_mapのエントリポイントタイプを示す。 EP_typeは、 このフィールドに続 くデ一夕フィールドのセマンティクスを示す。 Cl ipが 1つ以上のビデオストリー ムを含む場合、 EP_typeは 0(' video' )にセヅ トされなければならない。 又は、 Cl i Pがビデオストリームを含まず、 1つ以上のオーディオストリームを含む場合、 EP _typeは l (' audio' )にセヅトされなければならない。
number一 of一 stream一 P IDsの 1 6 ビヅ トのフィ一レド Ίま、 EP_map ( ) © Φ © number, of— stream_PIDsを変数に持つ for-loopのループ回数を示す。 stream_P ID(k)の 1 6 ビヅ トのフィー レド ίま、 EP_map— for一 one— stream— P ID(num一 EP— entries(k) )【こよつ て参照される k番目のエレメン夕リストリーム （ビデオ又はオーディオストリー ム） を伝送するトランスポートパケヅトの P I Dを示す。 EP— typeが 0 (' video' ) に等しい場合、 そのエレメン夕リストリームはビデオストリ一ムでなければなら ない。 また、 EP_typeが l (，audio，）に等しい場合、 そのエレメン夕リストリームは オーディオストリームでなければならない。
num—EP— entries(k)の 1 6 ビヅ トのフィ一レド ίま、 EP_map_for_one_stream_PID ( num_EP_entri es ( k ) )によって参照される num_EP_entr i e s ( k )を示す。 EP_map_for _one_s treai_P ID_Star t_address ( k )： この 3 2 ビヅ トのフィーノレド fま、 EP_map( ) の中で EP_map_for_one— stream_P ID (numj:P— entries(k) )が始まる相対バイ ト位置 を示す。 この値は、 EP_iiiap( )の第 1バイ ト目からの大きさで示される。
padding_wordは、 EP_map( )のシン夕クスに従って挿入されなければならない。 Xと Yは、 0又は任意の正の整数でなければならない。 それそれのパディングヮ一 ドは、 任意の値をとつてもよい。
図 7 2は、 EP_map_for_one_stream_PIDのシンタクスを示す図である。 図 7 2に 示した EPjnap— for_one_stream_P IDのシン夕クスを説明するに、 PTS_EP— startの 3 2ビットのフィールドのセマンティクスは、 EP_map( )において定義される EP_typ eにより異なる。 EP_typeが 0 (， video' )に等しい場合、 このフィールドは、 ビデオ ストリームのシーケンスヘッダで始まるアクセスュニヅトの 3 3 ビヅト精度の P T Sの上位 3 2 ビヅ トを持つ。 EP_typeが 1 (， audio' )に等しい場合、 このフィー ルドは、 オーディオストリームのアクセスュニヅトの 3 3ビヅト精度の P T Sの 上位 3 2ビットを持つ。
RSPN— EP_startの 3 2ビットのフィールドのセマンティクスは、 EP_niap( )におい て定義される EP_typeにより異なる。 EP_typeが 0 (' video' )に等しい場合、 このフ ィ一ルドは、 A Vストリームの中で PTS_EP_startにより参照されるアクセスュニ ヅトのシーケンスへヅダの第 1バイ ト目を含むソースポケットの相対ァドレスを 示す。 又は、 EP_typeが 1 (' audio' )に等しい場合、 このフィールドは、 A スト リームの中で PTS_EP_startにより参照されるアクセスュニヅトのオーディオフレ ームの第一バイ ト目を含むソースポケヅ卜の相対ァドレスを示す。
RSPN— EP一 startは、 ソースパケヅト番号を単位とする大きさであり、 A Vストリ ームファイルの最初のソースパケヅトから01 1 11^0( )にぉぃて定義される0 861；
_SPNの値を初期値としてカウントされる。 その A Vストリームファイルの中での 絶対ァドレスは、
SPN_xxx = RSPN_xxx - offset_SPN
により算出される。 シンタクスの for- loopの中で RSPN一 EP— startの値は、 昇順に現 れなければならない。
次に、 TU_mapについて、 図 7 3を参照して説明する。 TU_mapは、 ソースパケヅ トのァライバルタイムクロヅク （到着時刻ベースの時計） に基づいて、 1つの時 間軸を作る。 その時間軸は、 TU_map_time_axisと呼ばれる。 TUjnap_time_axisの 原点は、 TU__map( )の中の offset_timeによって示される。 TU—map— time— axisは、 o ffset_timeから一定の単位に分割される。 その単位を、 time— unitと称する。
A Vストリームの中の各々の time— unitの中で、 最初の完全な形のソースパケヅ トの A Vストリームフアイル上のァドレスが、 TU_mapにストアされる。 これらの アドレスを、 RSPN_time_miit— startと称する。 TU— map_time_axis上において、 k (k>=0)番目の time_unitが始まる時刻は、 TU_start— time(k)と呼ばれる。 この値は 次式に基づいて算出される。
TU— start—time ( = offset— time + k*time一 unit— size
Τϋ .start time(k)は、 4 5 k H zの精度を持つ。 図 7 5は、 TUjnapのシンタクスを示す図である。 図 7 5に示した TU_mapのシン 夕クスを説明するに、 0 361:_ ^ 1116の3 2 1311:長のフィールドは、 TU_inap_time_ax isに対するオフセッ トタイムを与える。 この値は、 Cl ipの中の最初の time_unitに 対するオフセット時刻を示す。 off set—timeは、 2 7 M H z精度のァライバルタイ ムクロックから導き出される 4 5 k H zクロックを単位とする大きさである。 A Vストリームが新しい Cl ipとして記録される場合、 offset一 timeは 0にセヅ 卜され なければならない。
time_uni t— sizeの 3 2ビヅトフィールドは、 time_unitの大きさを与えるもので あり、 それは 2 7 MHz精度のァライバルタイムクロックから導き出される 45 k H z クロックを単位とする大きさである。 time_unit_sizeは、 1秒以下 （time_unit_ sizeく =45000) にすることがよい。 number— of— time— unit— entriesの 3 2ビヅ トフ ィールドは、 TU_map( )の中にストァされている time_unitのェントリ数を示す。
RSPN—time— unit_startの 3 2 ビヅ トフィールドは、 A Vストリームの中でそれ それの time_unitが鬨始する場所の相対ァドレスを示す。 RSPN— time_unit— startは、 ソースパケヅト番号を単位とする大きさであり、 AV streamファイルの最初のソー スパケットから Cl ipInfo( )において定義される offset_SPNの値を初期値として力 ゥントされる。 その AV streamファイルの中での絶対ァドレスは、
SPN_xxx = RSPN— XXX - offset_SPN
により算出される。 シン夕クスの for-loopの中で RSPN_time_unit_startの値は、 昇順に現れなければならない。 （k+1 )番目の time_unitの中にソースパケヅトが何 もない場合、 （ k+1 )番目の RSPN— time— unit— startは、 k番目の RSPN_time— unit— sta rtと等しくなければならない。
図 4 5に示した zzzzz. cl ipのシン夕クス内の Cl ipMarkについて説明する。 Cl ip Markは、 クリヅプについてのマーク情報であり、 Cl ipMarkの中にストアされる。 このマークは、 記録器 （記録再生装置 1 ) によってセヅトされるものであり、 ュ 一ザによってセットされるものではない。
図 7 5は、 Cl ipMarkのシンタクスを示す図である。 図 7 5に示した CI ipMarkの シンタクスを説明するに、 version_nu]iiberは、 この Cl ipMark( )のバージョンナン バ一を示す 4個のキャラクタ一文字である。 version numberは、 I S O 6 4 6に 従って、 "0045"と符号化されなければならない。
lengthは、 この lengthフィールドの直後から Cl ipMarkOの最後までの Cl ipMark ( )のバイ ト数を示す 3 2 ビヅトの符号なし整数である。 number_of_Cl ip_marksは、 Cl ipMarkの中にストァされているマークの個数を示す 1 6ビヅトの符号なし整数, number— of一 Cl ip— marks は、 0であってもよい。 mark— typeは、 マークのタイプを 示す 8ビヅ トのフィールドであり、 図 7 6に示すテーブルに従って符号化される。 mark_tiiiie_stampは、 3 2 ビヅトフィールドであり、 マークが指定されたポイン トを示すタイムスタンプをストアする。 mark_time一 stampのセマンティクスは、 図 7 7に示すように、 PlayList( )の中の CPし typeにより異なる。
STC_sequence_idは、 CPI ( )の中の CPし typeが EPjnap typeを示す場合、 この 8ビ ヅ トのフィールドは、 マークが置かれているところの S T C連続区間の STC_sequ ence_idを示す。 CPI ( )の中の CPI_typeが TU— map typeを示す場合、 この 8ビヅ トの フィールドは何も意味を持たず、 0にセットされる。 character— setの 8ビッ トの フィールドは、 mark_nameフィ一ルドに符号化されているキャラクタ一文字の符号 化方法を示す。 その符号化方法は、 図 1 9に示される値に対応する。
name— 1 engthの 8ビヅ トフィールドは、 Mark_imiiieフィールドの中に示されるマ ーク名のバイ ト長を示す。 mark_nameのフィールドは、 マークの名称、を示す。 この フィールドの中の左から name— length数のバイ ト数が、 有効なキャラクタ一文字で あり、 それはマークの名称を示す。 mark_nameフィールドの中で、 それら有効なキ ャラク夕一文字の後の値は、 どんな値が入っていてもよい。
re: _thumbnaiし indexのフィ一ルドは、 マークに付加されるサムネイル画像の情 報を示す。 ref_thumbnai l_indexフィールドが、 OxFFFFでない値の場合、 そのマー クにはサムネイル画像が付加されており、 そのサムネイル画像は、 mark.thmbファ ィルの中にストアされている。 その画像は、 mark. thmbファイルの中で ref_thumb naiし indexの値を用いて参照される。 i>ef_thumbnai l— indexフィールドが、 OxFFF F である場合、 そのマークにはサムネイル画像が付加されていない。
MakersPrivateDataについては、 図 2 2を参照して既に説明したので、 その説明 は省略する。
次に、 サムネイルインフォメーション （Thumbnai l Information) について説明 する。 サムネイル画像は、 menu. thmbファイル又は mark. thmbファイルにストアさ れる。 これらのファイルは同じシンタクス構造であり、 ただ 1つの Thumbnai l ( )を 持つ。 menu. thmbファイルは、 メニューサムネイル画像， すなわち Volumeを代表す る画像、 及び、 それそれの PlayListを代表する画像をストアする。 全てのメニュ 一サムネイルは、 ただ 1つの menu. thmbファイルにストァされる。
mark.thmbファイルは、 マークサムネイル画像， すなわちマーク点を表すビクチ ャをストァする。 全ての PlayList及び Cl ipに対する全てのマークサムネイルは、 ただ 1つの mark. thmbファイルにストアされる。 サムネイルは頻繁に追加、 削除さ れるので、 追加操作と部分削除の操作は容易に高速に実行できなければならない。 この理由のため、 Thumbnai U )はブロック構造を有する。 画像のデータはいくつか の部分に分割され、 各部分は 1つの tn_blockに格納される。 1つの画像デ一夕は 連続した tnjalockに格納される。 tn_blockの列には、 使用されていない tn_block が存在してもよい。 1つのサムネイル画像のバイ ト長は可変である。
図 7 8は、 menu. thmbと mark. thmbのシンタクスを示す図であり、 図 7 9は、 図 7 8に示した] nenu . thm と mark . thmbのシンタクス内の Thumbnai 1のシンタクスを示 す図である。 図 7 9に示した Thumbnai lのシンタクスについて説明するに、 versi on_numberは、 この Thumbnai 1 ( )のノ、'一ジョンナンバーを示す 4個のキャラクター 文字である。 version_numberは、 I S O 6 4 6に従って、 " 0045"と符号化されな ければならない。
lengthは、 この lengthフィールドの直後から Thumbnai 1 ( )の最後までの MakersP rivateData( )のバイ ト数を示す 3 2 ビヅトの符号なし整数である。 tn_blocks— st art_addressは、 Thumbnai 1 ( )の先頭のバイ トからの相対バイ ト数を単位として、 最初の tnjalockの先頭バイ トァドレスを示す 3 2ビットの符号なし整数である。 相対バイ ト数は 0からカウントされる。 number_of_thuinbnai lsは、 Thumbnai )の 中に含まれているサムネイル画像のェントリ数を与える 1 6ビットの符号なし整 数である。
tn_block_si zeは、 1024バイ トを単位として、 1つの tn_blockの大きさを与える 16ビットの符号なし整数である。 例えば、 tn_block一 size= 1ならば、 それは 1つ の tn— blockの大きさが 1024バイ トであることを示す。 number of tn blocksは、 こ の Thumbnai l O中の tn_blockのェントリ数を表す 1 1 6 ビヅトの符号なし整数であ る。 thumbnai l— indexiま、 この thumbnai l— indexフィーノレド；^ら 台まる for レーフ。 1 回分のサムネイル情報で表されるサムネイル画像のィンデクス番号を表す 1 6ビ ヅ トの符号なし整数である。 thumbnaiし index として、 OxFFFFという値を使用し てはならない。 thumbnaiし index は UIAppInfoVolume( )、 UIAppInfoPlayList( )、 PlayListMarkO, 及び Cl ipMark( )の中の re:f_tlmiiibnaiし indexによって参照される, thumbnai l— pi cture_formatは、 サムネイル画像のピクチャフォーマヅトを表す 8 ビグトの符号なし整数で、 図 8 0に示すような値をとる。 表中の DCFと PNGは" menu.thmb" 内でのみ許される。 マークサムネイルは、 値" 0x00" ( M P E G - 2 V i d e o I- pi cture )をとらなければならない。
picture_data_sizeは、 サムネイル画像のバイ ト長をバイ ト単位で示す 3 2 ビヅ トの符号なし整数である。 start_tn_block_mimberは、 サムネイル画像のデ一夕が 始まる tnjDlockの tn_block番号を表す 1 6ビットの符号なし整数である。 サムネ ィル画像データの先頭は、 tb_blockの先頭と一致していなければならない。 tn— b lock番号は、 0から始まり、 tnjalockの for-ループ中の変数 kの値に関係する。 x_picture_lengthは、 サムネイル画像のフレーム画枠の水平方向のピクセル数 を表す 1 6ビヅトの符号なし整数である。 y_picture_lengthは、 サムネイル画像 のフレーム画枠の垂直方向のピクセル数を表す 1 6 ビヅ トの符号なし整数である。 tn_b lockは、 サムネイル画像がストアされる領域である。 Thumbnai 1 ( )の中の全 ての tn— blockは、 同じサイズ （固定長） であり、 その大きさは tn_block_si zeによ つて定義される。
図 8 1 A及び図 8 1 Bは、 サムネイル画像デ一夕がどのように tn— blockに格納 されるかを模式的に表した図である。 図 8 1 A及ぴ図 8 1 Bのように、 各サムネ ィル画像デ一夕は tn_blockの先頭から始まり、 1 tn_blockを超える大きさの場合 は、 連続する次の tnjD l ockを使用してストアされる。 このようにすることにより、 可変長であるピクチャデ一夕が、 固定長のデ一夕として管理することが可能とな り、 削除といった編集に対して簡便な処理により対応することができるようにな る。
次に、 A Vストリームファイルについて説明する。 A Vストリームファイルは、 "M2TS"ディ レク ト リ （図 14) にス トアされる。 AVス トリームファイルには、 2つのタイプがぁり、 それらは、 Clip AVス トリームと Bridge-Clip AVスト リ ームファイルである。 両方の AVス トリーム共に、 これ以降で定義される DVR MPEG— 2 トランスポートス ト リームファイルの構造でなければならない。 先ず、 DVR MPEG— 2 トランスポートス ト リームについて説明する。 D VR MP E G— 2 トランスポートスト リームの構造は、 図 82に示すようになつ ている。 AVス ト リームファイルは、 DVR MPEG 2 トランスポートス ト リー ムの構造を持つ。 DVR MPEG 2 トランスポートス ト リームは、 整数個の Ali gned unitから構成される。 Alignedunitの大きさは、 6 144 バイ ト （204 8 * 3 バイ ト） である。 Aligned unitは、 ソースパケッ トの第 1バイ ト目から始 まる。 ソースパケッ トは、 192バイ ト長である。 1つのソースパケヅ トは、 TP _extra_headerと トランスポートノ ゲ、ソ ト； ^らなる。 TP_extra_headery：、 4ノ ィ ト長であり、 またトランスポートパケッ トは、 1 88バイ ト長である。
1つの Aligned unitは、 32個のソースパケヅ トからなる。 DVR MPEG 2 トランスポートス ト リームの中の最後の Aligned unitも、 また 32個のソースパ ケヅ トからなる。 よって、 DVR MP E G 2 トランスポートスト リ一ムは、 Ali gned unitの境界で終端する。 ディスクに記録される入力トランスポートス ト リー ムのトランスポートパケッ トの数が 32の倍数でないとき、 ヌルパケヅ ト （PID= OxlFFFのトランスポートパケッ ト） を持ったソースパケヅ トを最後の Aligned un itに使用しなければならない。 ファイルシステムは、 DVR MPEG 2 トランス ポートス ト リームに余分な情報を付加してはならない。
図 83に、 DVR MPEG— 2 トランスポートスト リームのレコーダモデルを 示す。 図 83に示したレコーダは、 レコーディングプロセスを規定するための概 念上のモデルである。 DVR MPEG— 2 トランスポートス トリームは、 このモ デルに従う。
MPEG— 2 トランスポートス トリームの入力夕ィ ミングについて説明する。 入力 MPE G2 トランスポ一トス トリームは、 フルトランスポートスト リーム又 はパーシャルトランスポートストリームである。 入力される MPEG2 トランス ポ一トスト リームは、 I SO/I E C 1 38 1 8— 1又は I SO/I E C 1 38 1 8 -9に従っていなければならない。 MPEG 2 トランスポートス ト リームの i番目のバイ トは、 T— S TD(I SO/I E C 1 38 1 8 _ lで規定される Tran sport stream system target decoder)とソ一スノ ケヅ夕ィザへ、 時刻 t(i)に同時 に入力される。 Rpkは、 トランスポートパケッ トの入力レートの瞬時的な最大値で ある。
27MHz PLL52は、 27 M H zクロヅクの周波数を発生する。 27MH zクロ ヅクの周波数は、 MP EG— 2 トランスポートス ト リームの P CR (Program C1 ock Reference)の値にロックされる。 arrival time clock counter 53は、 27 MHzの周波数のパルスをカウントするバイナリーカウンタ一である。 Arrivaし tim e_clock(i)は、 時刻 t(i)における Arrival time clock counterのカウント値であ る。
source packetizer 54 ίま'、 全てのトランスポートノ ケヅ ト【こ TP_extra— header を付加し、 ソースパケッ トを作る。 Arrival_time— stampは、 トランスポートパケ ヅ トの第 1バイ ト目が T— S TDとソースパケヅ夕ィザの両方へ到着する時刻を 表す。 Arrivaし time— stamp(k)は、 次式で示されるように Arrivaし time_clock(k) のサンプル値であり、 ここで、 kはトランスポートパケヅ トの第 1バイ ト目を示す ( arrival— time_stamp(k) = arrival— time— clock(k)% 230
2つの連続して入力される トランスポートパケヅ トの時間間隔が、 230/270000 00秒 （約 40秒） 以上になる場合、 その 2つのトランスポ一トパケッ トの arrival_ time_stampの差分は、 230/27000000秒になるようにセヅ トされるべきである。 レ コーダは、 そのようになる場合に備えてある。
smoothing buffer 55は、 入力トランスポートス ト リームのビヅ トレードをス ムージングする。 スムージングバッファは、 オーバーフロウしてはならない。 Rm axは、 スムージングパヅファが空でないときのスム一ジングバヅファからのソー スパケヅ トの出力ビヅ トレートである。 スムージングバッファが空であるとき、 スムージングバヅファからの出力ビヅ トレートは 0である。
次に、 DVR MP E G— 2 トランスポートス ト リームのレコーダモデルのパラ メータについて説明する。 Rmaxという値は、 AVス ト リームファイルに対応する ClipInfo()において定義される TS recording rateによって与えられる。 この値は、 次式により算出される。
Rmax = TS— recording— rate * 192/188
TS_recording_rateの値は、 bytes/secondを単位とする大きさである。
入力トランスボートス ト リームが SE S Fトランスポートス トリームの場合、 Rpkは、 AVス ト リームファイルに対応する ClipInfo()において定義される TS_re cording_rateに等しくなければならない。 入力トランスポ一トスト リームが SE S Fトランスポートス ト リームでない場合、 この値は MPEG- 2 transport streamの デスクリプ夕ー， 例えは maximum—bitrate一 descriptorや partial— t醒 sport_stre am_descriptor等において定義される値を参照してもよい。
smoothing buffer sizeは、 入力トランスポートスト リームが SE S Fトランス ポートスト リームの場合、 スムージングバッファの大きさは 0である。 入力トラ ンスポートス トリームが SE S Fトランスポートスト リームでない場合、 スムー ジングバッファの大きさは MPEG-2 transport streamのデスクリブタ一、 例えば s moothing— buffer— descriptor short一 smoothing— buff er_descriptor、 partial_t ransport— stream—descriptorなど【こおレ、て定義される値を参照してもよレ、。
記録機 （レコーダ） 及び再生機 （プレーヤ） は、 十分なサイズのバヅファを用 意しなければならない。 デフォルトのバヅファサイズは、 1536 bytes である。 次に、 DVR MPEG— 2 トランスポートス トリームのプレーヤモデルについ て説明する。 図 84は、 DVR MP E G- 2 トランスポートスト リ一ムのプレ一 ャモデルを示す図である。 これは、 再生プロセスを規定するための概念上のモデ ルである。 DVR MPEG— 2 トランスポートス トリームは、 このモデルに従う <
27MHz X-tal 6 1は、 27 M H zの周波数を発生する。 27 MH z周波数の誤差 範囲は、 +/-30 ppm (27000000 +/- 810 Hz)でなければならない。 arrival time clock counter 62は、 27 MH zの周波数のパルスをカウントするバイナリ一力 ゥン夕一である。 Arrival— time— clock(i)は、 時刻 t( i )における Arrival time cl ock counterのカウント値である。
smoothing buffer 64において、 Rmaxは、 スムージングバッファがフルでない ときのスムージングバッファへのソースパケヅ トの入力ビヅ トレートである。 ス ムージングバヅファがフルであるとき、 スム一ジングバヅファへの入力ビッ トレ ートは 0である。
MPEG— 2 トランスポートス ト リームの出力夕イミングを説明するに、 現在 のソースパケヅ 卜の arrival— tinie_stampが arrival— time— ciock(i)の L SB 30 ビッ トの値と等しいとき、 そのソースパケッ トのトランスポートパケッ トは、 ス ムージングバヅファから引き抜かれる。 Rpkは、 トランスポートパケッ トレートの 瞬時的な最大値である。 スムージングバッファは、 アンダーフロウしてはならな い。
DVR MPEG— 2 トランスポートス ト リームのプレーヤモデルのパラメ一夕 については、 上述した D VR MPEG— 2 トランスポートス トリームのレコーダ モデルのパラメ一夕と同一である。
図 85は、 Source packetのシンタクスを示す図である。 transport_packet( )は、 I S0/I E C 1 38 18 - 1で規定される MP E G— 2 トランスポートパケヅ トである。 図 85に示した Source packetのシンタクス内の TP_Extra_headerのシ ン夕クスを図 86に示す。 図 86に示した TP_Extra_headerのシン夕クスについて 説明するに、 copy_peruiission_indicatorは、 トランスポートパケヅ トのペイ口一 ドのコピー制限を表す整数である。 コピー制限は、 copy free, no more copy、 c opy onceヽ 又は copy prohibitedとすることができる。 図 87はヽ copy_permissi on_indicatorの値と、 それらによって指定されるモ一ドの関係を示す。
copy_per)nission_iiidicatorは、 全てのトランスポートパケッ トに付加される。 I E E E 1394ディジタルィン夕フエ一スを使用して入力トランスポートス ト リームを記録する場合、 copy— permission— indicatorの値は、 IEEE1394 isochron ouspacket headerの中の E M I (Encryption Mode Indicator)の値に関連付けて もよい。 I E E E 1 394ディジタルインタフエースを使用しないで入力トラン スポートスト リームを記録する場合、 copy_permission— indicatorの値は、 トラン スポ一トパケッ トの中に埋め込まれた CCIの値に関連付けてもよい。 アナログ信号 入力をセルフエンコードする場合、 copy_permission_indicatorの値は、 アナログ 信号の CGMS— Aの値に関連付けてもよい。
arrival— time— stam は、 次式
arrival time_stamp(k) = arrival time clock(K % 230 において、 arrivaし tiiie_stampによって指定される値を持つ整数値である。
Clip AVストリームの定義をするに、 Clip AVストリームは、 上述したよう な定義がされる DVR MPEG— 2トランスポートストリームの構造を持たねば ならない。 arrivaし time_clock(i)は、 Clip A Vストリームの中で連続して増加 しなければならない。 Clip AVストリームの中にシステムタイムベース （S T C ベース） の不連続点が存在したとしても、 その Clip A Vストリームの airivaし t ime一 clock(i)は、 連続して増加しなければならない。
Clip AVストリームの中の開始と終了の間の arrival_time一 clock(i)の差分の 最大値は、 26時間でなければならない。 この制限は、 MPEG2 トランスポー トストリームの中にシステムタイムベース （S T Cベース） の不連続点が存在し ない場合に、 Clip A Vス ト リームの中で同じ値の P T S (Presentation Time St amp)が決して現れないことを保証する。 MP E G 2システムズ規格は、 PT Sの ラヅブアラウンド周期を 233/90000秒（約 26.5時間）.と規定している。
Bridge-Clip A Vストリームの定義をするに、 Bridge- Clip AVストリームは、 上述したような定義がされる DVR MPEG— 2 トランスポートストリームの構 造を持たねばならない。 Bridge- Clip AVストリームは、 1つのァライバル夕ィ ムベースの不連続点を含まなければならない。 ァライバルタイムペースの不連続 点の前後のトランスポートストリームは、 後述する符号化の制限に従わなければ ならず、 且つ後述する D VR— S TDに従わなければならない。
本例においては、 編集における Playltem間のビデオとオーディオのシームレス 接続をサポートする。 Playltem間をシームレス接続にすることは、 プレーヤ/レ コーダに"デ一夕の連続供給"と"シームレスな復号処理"を保証する。 "データの連 続供給"とは、 ファイルシステムが、 デコーダにバッファのアンダーフロウを起こ させることのないように必要なビットレートでデ一夕を供給することを保証でき ることである。 デ一夕のリアルタイム性を保証して、 デ一夕をディスクから読み 出すことができるように、 データが十分な大きさの連続したプロヅク単位でスト ァされるようにする。
"シームレスな復号処理"とは、 プレーヤが、 デコーダの再生出力にポーズゃギ ヤップを起こさせることなく、 ディスクに記録されたオーディオビデオデ一夕を 表示できることである。
シームレス接続されている Playltemが参照する A Vストリームについて説明す る。 先行する Playltemと現在の Playltemの接続が、 シームレス表示できるように 保証されているかどうかは、 現在の Playltemにおいて定義されている connection _conditionフィールドから判断することができる。 Playltem間のシームレス接続 は、 Bridge- Cl ipを使用する方法と使用しない方法がある。
図 8 8は、 Bridge-Cl ipを使用する場合の先行する Playltemと現在の Playltemの 関係を示している。 図 8 8においては、 プレーヤが読み出すストリームデータが、 影を付けて示されている。 図 8 8に示した T S 1は、 Cl ipl (Cl ip A Vストリー ム） の影を付けられたストリームデータと Bridge- Cl ipの RSPN_arrival_time_dis continuityより前の影を付けちれたストリ一ムデ一夕かちなる。
T S 1の Cl iplの影を付けられたストリームデータは、 先行する Playltemの IN— time (図 8 8において IN_timelで図示されている） に対応するプレゼンテーショ ンュニヅトを復号するために必要なストリームのァドレスから、 RSPN_exit— from _previous— Cl ipで参照されるソースパケヅトまでのストリ一ムデ一夕である。 T S 1に含まれる Bridge - Cl ipの RSPN— arrival— time_discontinuityより前の影を付 けられたストリームデ一夕は、 Bridge- Cl ipの最初のソースパケヅトから、 RSPN— arrivaし time—discontinuityで参照されるソースパケッ トの直前のソースパケヅ トまでのストリームデータである。
また、 図 8 8における T S 2は、 Cl ip2 (Cl ip A Vストリーム） の影を付けら れたストリームデ一夕と Bridge-Cl ipの RSPN_arrivaし time_discontinuity以後の 影を付けられたストリームデ一夕からなる。 T S 2に含まれる Bridge-Cl ipの RSP N_arrival_time— di scontinuity以後の影を付けられたストリームデ一夕は、 RSPN —arrival— time— discontinuityで参照されるソースパケヅ トから、 Bridge - Cl ipの 最後のソースパケヅ トまでのストリームデータである。 T S 2の Cl ip2の影を付け られたストリームデ一夕は、 RSPN— enter_to_current_Cl ipで参照されるソースパ ケヅトから、 現在の Play Itemの OUT— time (図 8 8において 0IIT_tinie2で図示されて いる） に対応するプレゼンテーションュニヅトを復号するために必要なストリ一 ムのアドレスまでのストリームデ一夕である。 図 89は、 Bridge-Clipを使用しない場合の先行する Playltemと現在の Playlte inの関係を示している。 この場合、 プレーヤが読み出すストリームデータは、 影を 付けて示されている。 図 89における T S 1は、 Clipl (Clip A Vストリーム）の 影を付けられたストリームデータからなる。 T S 1の Cliplの影を付けられたスト リームデ一夕は、 先行する Playltemの IN_time (図 89において IN_timelで図示さ れている） に対応するプレゼンテーションュニヅトを復号するために必要なスト リームのアドレスから始まり、 Cliplの最後のソースパケヅトまでのデータである, また、 図 89における S 2は、 Clip2 (Clip AVストリーム）の影を付けられた ストリームデ一夕からなる。
T S 2の Clip2の影を付けられたストリームデータは、 Clip2の 初のソースパ ケヅトから始まり、 現在の Playltemの 0UT_time (図 89において 0UT_time2で図示 されている） に対応するプレゼンテーションュニヅトを復号するために必要なス トリームのアドレスまでのストリ一ムデ一夕である。
図 88と図 89において、 丁 31と 32は、 ソースパケヅ トの連続したスト リームである。 次に、 T S 1と T S 2のストリーム規定と、 それらの間の接続条 件について考える。 先ず、 シームレス接続のための符号化制限について考える。 トランスポートストリームの符号化構造の制限として、 先ず、 丁 31と丁 32の 中に含まれるプログラムの数は、 1でなければならない。 31と 32の中に 含まれるビデオストリームの数は、 1でなければならない。 31と丁 32の中 に含まれるオーディオス トリームの数は、 2以下でなければならない。 T S 1と T S 2の中に含まれるオーディオストリームの数は、 等しくなければならない。 T S 1及び Z又は T S 2の中に、 上記以外のエレメン夕リストリーム又はプライ ベートストリームが含まれていてもよい。
ビデオビヅ トス トリームの制限について説明する。 図 90は、 ピクチャの表示 順序で示すシームレス接続の例を示す図である。 接続点においてビデオストリー ムをシームレスに表示できるためには、 0UT_timel (Cliplの 0UT_tiine) の後と IN _time2 (CI ip2の IN_time) の前に表示される不必要なピクチャは、 接続点付近の Clipの部分的なストリームを再ェンコ一ドするプロセスにより、 除去されなけれ ばならない。 図 9 0に示したような場合において、 BridgeSequenceを使用してシームレス接 続を実現する例を、 図 9 1に示す。 RSPN_arrival— time一 discontinuityより前の B ridge-Cl ipのビデオストリームは、 図 9 0の Cl iplの OUT— timelに対応するピクチ ャまでの符号化ビデオストリームからなる。 そして、 そのビデオストリームは先 行する Cl iplのビデオストリームに接続され、 1つの連続で M P E G 2規格に従つ たエレメン夕リストリームとなるように再ェンコ一ドされている。
同様にして、 RSPN_arrival— time— discontinuity以後の Bridge-Cl ipのビデオス トリ一ムは、 図 9 0の Cl ip2の IN—time2に対応するピクチャ以後の符号化ビデオス トリームからなる。 そして、 そのビデオストリームは、 正しくデコード開始する ことができて、 これに続く Cl ip2のビデオストリームに接続され、 1つの連続で M P E G 2規格に従ったエレメン夕リストリームとなるように再エンコードされて いる。 Bridge-Cl ipを作るためには、 一般に、 数枚のピクチャは再エンコードしな ければならず、 それ以外のピクチャはォリジナルの Cl ipからコピ一することがで きる。
図 9 0に示した例の場合に BridgeSequenceを使用しないでシームレス接続を実 現する例を図 9 2に示す。 Cl iplのビデオストリームは、 図 9 0の 0UT_timelに対 応するピクチャまでの符号化ビデオストリームからなり、 それは、 1つの連続で M P E G 2規格に従つたエレメン夕リストリームとなるように再エンコードされ ている。 同様にして、 Cl ip2のビデオストリームは、 図 9 0の Cl ip2の IN_time2に 対応するピクチャ以後の符号化ビデオストリームからなり、 それは、 1つの連続 で M P E G 2規格に従ったエレメン夕リストリームとなるように再ェンコ一ドさ れている。
ビデオストリームの符号化制限について説明するに、 先ず、 丁 3 1と丁 3 2の ビデオストリームのフレームレートは、 等しくなければならない。 T S 1のビデ ォストリームは、 sequence_end_codeで終端しなければならない。 T S 2のビデオ ストリームは、 Sequence Header、 GOP Header^ そして Iピクチャで開始しなけれ ばならない。 T S 2のビデオストリームは、 クローズド G O Pで開始しなければ ならない。
ビヅトストリームの中で定義されるビデオプレゼンテーションュニヅト （フレ ーム又はフィールド） は、 接続点を挟んで連続でなければならない。 接続点にお いて、 フレーム又はフィールドのギャップがあってはならない。 接続点において、 トヅブーボトムのフィールドシ一ケンスは連続でなければならない。 3— 2プル ダウンを使用するエンコードの場合は、 "top_field—first" 及び "repeat_first —field"フラグを書き換える必要があるかもしれない， 又はフィールドギヤップの 発生を防ぐために局所的に再ェンコ一ドするようにしてもよい。
オーディオビヅトストリームの符号化制限について説明するに、 T S 1と T S 2のオーディオのサンプリング周波数は、 同じでなければならない。 T S 1と T S 2のオーディオの符号化方法 （例. MPEG 1レイヤ 2，AC— 3,SE S F L P CM, A AC) は、 同じでなければならない。
次に、 MPE G— 2 トランスポートストリームの符号化制限について説明する に、 T S 1のオーディオストリ一ムの最後のオーディオフレームは、 T S 1の最 後の表示ピクチャの表示終了時に等しい表示時刻を持つオーディオサンプルを含 んでいなければならない。 T S 2のオーディオストリームの最初のォ一ディオフ レームは、 T S 2の最初の表示ピクチャの表示鬨始時に等しい表示時刻を持つォ —ディオサンプルを含んでいなければならない。
接続点において、 オーディオプレゼンテ一ションュニヅトのシーケンスにギヤ ヅプがあってはならない。 図 93に示すように、 2オーディオフレーム区間未満 のオーディオプレゼンテーションュニヅ 卜の長さで定義されるオーバーラヅプが あってもよい。 T S 2のエレメンタリストリームを伝送する最初のパケヅトは、 ビデオパケヅトでなければならない。 接続点におけるトランスポートストリーム は、 後述する DVR— S TDに従わなくてはならない。
Clip及び Bridge- Clipの制限について説明するに、 T S 1と T S 2は、 それぞれ の中にァライバルタイムベースの不連続点を含んではならない。
以下の制限は、 Bridge- Clipを使用する場合にのみ適用される。 T S 1の最後の ソースパケヅトと T S 2の最初のソースパケヅトの接続点においてのみ、 Bridge -Clip AVストリームは、 ただ 1つのァライバル夕ィムベースの不連続点を持つ。 ClipInfo()において定義される RSPN— arrivaし time_discontinuityが、 その不連続 点のァドレスを示し、 それは T S 2の最初のソースパケヅトを参照するァドレス を示さなければならない。
Bridge Sequence I nfo( )において定義される RSPN— exit— from一 previous— CI ipによ つて参照されるソースパケットは、 Cl iplの中のどのソースパケットでもよい。 そ れは、 Al igned unitの境界である必要はない。 BridgeSequenceInfo( )において定 義される RSPN_ente to_currentJU ipによって参照されるソースパケヅ トは、 C1 ip2の中のどのソースパケットでもよい。 それは、 Al igned unitの境界である必要 はない。
Playltemの制限について説明するに、 先行する Playltemの ΟϋΤ—time (図 8 8、 図 8 9において示される OUT_tiniel) は、 T S 1の最後のビデオプレゼンテ一ショ ンュニットの表示終了時刻を示さなければならない。 現在の Playltemの IN_time (図 8 8、 図 8 9において示される IN_time2) は、 T S 2の最初のビデオプレゼ ンテーシヨンュニットの表示開始時刻を示さなければならない。
Bridge-Cl ipを使用する場合のデ一夕アロケーションの制限について、 図 9 4を 参照して説明するに、 シームレス接続は、 ファイルシステムによってデ一夕の連 続供給が保証されるように作られなければならない。 これは、 Cl ipl (Cl ip A V ストリームファイル） と Cl ip2 (Cl ip A Vストリームファイル） に接続される Br idge-Cl ip A Vストリームを、 データアロケーション規定を満たすように配置す ることによって行われなければならない。
RSPN— exit— from_previous_C l ip以前の Cl ipl (Cl ip A Vス ト リームファイル） のストリ一ム部分が、 ハーフフラグメント以上の連続領域に配置されているよう に、 RSPN_exit_from— previous一 Cl ipが選択されなければならない。 Bridge-Cl ip A Vストリームのデ一夕長は、 ハーフフラグメント以上の連続領域に配置される ように、 選択されなければならない。 RSPN— enter— to_current_Clip以後の Cl ip2 (Cl ip A Vストリームファイル） のストリーム部分が、 ハーフフラグメント以上 の連続領域に配置されているように、 RSPN_enter_to一 current_Clipが選択されな ければならない。
Bridge-Cl ipを使用しないでシームレス接続する場合のデータアロケーションの 制限について、 図 9 5を参照して説明するに、 シームレス接続は、 ファイルシス テムによってデータの連続供給が保証されるように作られなければならない。 こ れは、 Clipl (Clip AVス トリームファイル） の最後の部分と Clip2 (Clip AV ス ト リームファイル） の最初の部分を、 デ一夕アロケーション規定を満たすよう に配置することによって行われなければならない。
Clipl (Clip AVス トリームファイル） の最後のス ト リーム部分が、 ハーフフ ラグメント以上の連続領域に配置されていなければならない。 Clip2 (Clip AV ス ト リームファイル） の最初のス ト リーム部分が、 ハーフフラグメント以上の連 続領域に配置されていなければならない。
次に、 D VR— S TDについて説明する。 DVR— S TDは、 DVR MPE G 2 トランスポートス ト リームの生成及ぴ検証の際におけるデコード処理をモデル 化するための概念モデルである。 また、 DVR— S TDは、 上述したシームレス 接続された 2つの Playltemによって参照される AVス ト リームの生成及び検証の 際におけるデコ一ド処理をモデル化するための概念モデルでもある。
D VR— S T Dモデルを図 96に示す。 図 9 6に示したモデルにほ、 DVR M PEG— 2 トランスポートストリームプレーヤモデルが構成要素として含まれて いる 0 η, ΤΒη,ΜΒη, EBn, TBsys, Bsys, Rxn, Rbxn, Rxsys, Dn, Dsys, On及び Pn (k)の表記方法は、 I SO/I E C 138 1 8— 1の T— S T Dに定義されている ものと同じである。 すなわち、 次の通りである。 nは、 エレメン夕 リス ト リームの ィンデクス番号である。 TBnは、 エレメン夕リス ト リーム nのトランスポートバッ ファである。
MBnは、 エレメン夕リス ト リーム nの多重バッファである。 ビデオス ト リームに ついてのみ存在する。 EBnは、 エレメン夕リス ト リーム nのエレメン夕リストリー ムバヅファである。 ビデオストリームについてのみ存在する。 TBsysは、 復号中の プログラムのシステム情報のための入カバヅファである。 Bsysは、 復号中のプロ グラムのシステム情報のためのシステム夕ーゲヅ トデコーダ内のメインバッファ である。 Rxnは、 データが TBnから取り除かれる伝送レートである。 Rbxnは、 PE Sパケヅ トペイロードが MBnから取り除かれる伝送レートである。 ビデオス ト リー ムについてのみ存在する。
Rxsysは、 データが TBsysから取り除かれる伝送レートである。 Dnは、 エレメン 夕リスト リーム nのデコーダである。 Dsysは、 復号中のプログラムのシステム情報 に関するデコーダである。 Onは、 ビデオス トリーム nの re- ordering bufferである < Pn(k)は、 エレメン夕リス ト リーム nの k番目のプレゼンテーションュニヅ トである,
DVR— S TDのデコーディングプロセスについて説明する。 単一の DVR M PEG— 2 トランスポートスト リームを再生している間は、 トランスポートパケ ヅ トを TB1， TBn又は TBsysのバッファへ入力するタイ ミングは、 ソースパケヅ トの arrival_time— stampにより決定される。 TBI, MBl, EBl, TBn, Bn, Bsys及び TBsy sのバッファリング動作の規定は、 I S OZI E C 1 38 1 8— 1に規定されて いる T— S TDと同じである。 復号動作と表示動作の規定もまた、 I S 0/1 E C 138 1 8— 1に規定されている T一 S T Dと同じである。
シ一ムレス接続された Playltemを再生している間のデコーディングプロセスに ついて説明する。 ここでは、 シームレス接続された Playltemによって参照される 2つの A Vス トリームの再生について説明をすることにし、 以後の説明では、 上 述した （例えば、 図 88に示した） TS 1と T S 2の再生について説明する。 T S 1は、 先行するスト リ一ムであり、 T S 2は、 現在のス トリームである。
図 97は、 ある AVス ト リーム （T S 1 ) からそれにシームレスに接続された 次の AVス ト リーム （T S 2) へと移るときのトランスポートパケヅ の入力, 復号， 表示のタイ ミングチャートを示す。 所定の A Vス ト リーム （T S 1 ) から それにシームレスに接続された次の AVス トリーム （T S 2) へと移る間には、 T S 2のァライバルタイムベースの時間軸 （図 97において A T C 2で示され る） は、 T S 1のァライバルタイムベースの時間軸 （図 97において AT C 1で 示される） と同じでない。
また、 T S 2のシステムタイムベースの時間軸 （図 97において S T C 2で示 される） は、 T S 1のシステムタイムベースの時間軸 （図 97において S T C 1 で示される） と同じでない。 ビデオの表示は、 シームレスに連続していることが 要求される。 オーディオのプレゼンテーシヨンュニッ トの表示時間にはオーバー ラヅプがあってもよい。
D VR - S T D への入力タイ ミングについて説明する。 時刻 T1までの時間、 すなわち、 T S 1の最後のビデオパケヅ トが DVR— S TDの TB 1に入力終了 するまでは、 D VR— S TDの TB1、 TBn又は TBsysのバッファへの入力夕ィ ミン グは、 T S 1のソースパケヅトの arrival_tiine_stampによって決定される。
T S 1の残りのパケヅ トは、 TS_recording— rate(T S 1 )のビッ トレートで D V R _ S T Dの TBn又は TBsysのバッファへ入力されなければならない。 ここで、 TS _recording_rate(T S 1 )は、 Cliplに対応する ClipInfo()において定義される TS _recording— rateの値である。 T S 1の最後のバイ トがバッファへ入力する時刻は、 時刻 T2である。 したがって、 時刻 T1から T2までの区間では、 ソースパケットの arrival一 time— stampは無視される。
N 1を T S 1の最後のビデオパケヅトに続く T S 1のトランスポートパケヅト のバイ ト数とすると、 時刻 T1乃至 T2までの時間 DT1は、 N 1バイ トが TS_record ing_rate(T S 1 )のビヅトレートで入力終了するために必要な時間であり、 次式 により算出される。
ΔΤ1= T2- T1 = N1 I TS— recording—rate (T S 1 )
時刻 Tl乃至 T2までの間は、 RXnと RXsysの値は共に、 TS_recording_rate( T S 1 )の値に変化する。 このルール以外のパヅファリング動作は、 T— STDと同じ である。
T2の時刻において、 arrival time clock counterは、 T S 2の最初のソースパ ケヅ トの arrival— time_stafflpの値にリセヅ トされる。 DVR— STDの TB1， TBn 又は TBsysのバヅファへの入力夕ィミングは、 T S 2のソースパケヅトの arriva l_time_stampによって決定される。 nと RXsysは共に、 T— S TDにおいて定義 されている値に変化する。
付加的なオーディオパヅファリング及びシステムデ一夕バヅファリングについ て説明するに、 オーディオデコーダとシステムデコーダは、 時刻 T1から T2までの 区間の入力デ一夕を処理することができるように、 T_ S TDで定義されるバヅ ファ量に加えて付加的なバッファ量 （約 1秒分のデータ量） が必要である。
ビデオのプレゼンテーションタイミングについて説明するに、 ビデオプレゼン テーシヨンュニヅ トの表示は、 接続点を通して、 ギャップなしに連続でなければ ならない。 ここで、 S T C 1は、 T S 1のシステムタイムベースの時間軸 （図 9 7では S T C 1と図示されている） とし、 STC 2は、 T S 2のシステムタイム ベースの時間軸 （図 97では S T C 2と図示されている。 正確には、 S T C 2は、 T S 2の最初の P CRが T一 STDに入力した時刻から鬨始する。 ） とする。
S T C 1と S T C 2の間のオフセヅトは、 次のように決定される。 PTSlendは、 T S 1の最後のビデオプレゼンテーションュニヅ トに対応する S T C 1上の P T Sであり、 PTS2startは、 T S 2の最初のビデオプレゼンテーションユニットに対 応する S T C 2上の P T Sであり、 Tppは、 T S 1の最後のビデオプレゼンテーシ ョンユニットの表示期間とすると、 2つのシステムタイムペースの間のオフセヅ ト STC_deltaは、 次式により算出される。
STC— delta = PTSlend + Tpp - PTS2start
オーディオのプレゼンテーションのタイミングについて説明するに、 接続点に おいて、 オーディオプレゼンテ一ションュニヅトの表示夕ィミングのオーバーラ ヅプがあっても良く、 それは 0乃至 2オーディオフレーム未満である （図 97に 図示されている" audio overlap"を参照） 。 どちらのオーディオサンプルを選択す るかということと、 ォ一ディオプレゼンテ一ションュニヅ トの表示を接続点の後 の補正されたタイムベースに再同期することは、 プレーヤ側により設定されるこ とである。
D VR- S T Dのシステムタイムクロックについて説明するに、 時刻 T 5におい て、 T S 1の最後のオーディオプレゼンテーションユニットが表示される。 シス テムタイムクロックは、 時刻 T 2から T 5の間にオーバーラヅプしていてもよい。 この区間では、 DVR— S TDは、 システムタイムクロヅクを古いタイムべ一ス の値 （STC 1 ) と新しいタイムべ一スの値 （ST C 2) の間で切り替える。 S T C 2の値は、 次式により算出される。
STC2 = STCl-STC_delta
バヅファリングの連続性について説明する。 STCllvideo_endは、 T S 1の最後 のビデオパケットの最後のバイ トが DVR— S TDの TB 1へ到着するときのシ ステムタイムべ一ス S T C 1上の S T Cの値である。 STC22video_startは、 T S 2の最初のビデオパケヅ卜の最初のバイ トが DVR— S TDの TB 1へ到着する ときのシステムタイムベース S TC 2上の ST Cの値である。 STC21video_endは、 STCllvideo_end の値をシステムタイムベース S T C 2上の値に換算した値である ( STC21video endは、 次式により算出される。 STC21video一 end = STCllvideo— end ― STC— delta
D VR— S TDに従うために、 次の 2つの条件を満たすことが要求される。 先 ず、 T S 2の最初のビデオパケットの TB 1への到着タイミングは、 次に示す不 等式を満たさなければならない。 そして、 次に示す不等式を満たさなければなら ない。
STC22video_start > STC21video_end + ΔΤ1
この不等式が満たされるように、 Clip 1及び、 又は、 Clip2の部分的なストリー ムを再エンコード及び、 又は、 再多重化する必要がある場合は、 その必要に応じ て行われる。
次に、 S T C 1と S T C 2を同じ時間軸上に換算したシステムタイムベースの 時間軸上において、 T S 1からのビデオパケヅトの入力とそれに続く T S 2から のビデオパケットの入力は、 ビデオバヅファをオーバーフロー及びアンダーフロ 一させてはならない。
このようなシンタクス、 データ構造、 規則に基づくことにより、 記録媒体に記 録されているデータの内容、 再生情報などを適切に管理することができ、 もって、 ユーザが再生時に適切に記録媒体に記録されているデータの内容を確認したり、 所望のデ一夕を簡便に再生できるようにすることができる。
次に、 図 46で示した Cliplnfoのシンタクスの中にある time— controlled_flag を 1にセヅトする場合の A Vストリームファイルの記録について、 詳細な内容を説 明する。 time_controlled_flagを 1にセヅ トする場合、 A Vス トリームの時間経 過と A Vストリームのデ一夕バイ ト量が、 次の関係にあることを示す。 すなわち、 AVストリームの時間経過と A Vストリームのデータバイ ト量との関係が、 所定 の誤差の範囲内で比例する、 ことを保証する。
TS一 average一 rate*192/188 * (t -a )<= AV— file一 size(t)
<= TS_average_rate*192/188 * (t +a)
…式 （ 1 ) 上記の式は、 図 46の Cliplnfoの time_controlled_flagの説明の中で示した式 とは、 すこし形式が違うが本質的には同じである。
ここで、 TS_average rateは、 AVストリームファイル （D VRトランスポ一ト ストリームファイル） の平均ビヅ トレ一トを bytes/second の単位で表したもので あり、 Cl iplnfoの中の同名のフィールドにより示される。 また、 tは、 A Vスト リームファイルの最初のソースパケヅトからのァライバルライムペースの経過時 刻を秒単位で示す。 AV— f i le_size(t)は、 時刻七における A Vスト リームフアイ ルのサイズをバイ ト単位で表したものである。 αは、 所定の一定値であり、 例え ば、 300秒である。
TS_average_rateは、 記録器のアプリケーションによって所定に値に決める。 例 えば、 長時間録画モード （L Pモード） ，標準録画モード （S Pモード）、 高画 質録画モード （H Qモード） といった記録モードに応じて、 それそれのモード用 の TS一 average_rate値を決める。
式（1 )を満たすように、 A Vストリームファイルが記録されている場合、 そのス トリームのある時間分だけ部分的にストリームを消去すると、 消去した時間分だ け前記スト リームの TS_average_rateで示されるビヅ トレートで記録可能な空き領 域をディスク上に作れることを保証できる。 例えば、 S Pモードの A Vストリー ムファイルのある時間分だけ部分的にストリームを消去すると、 消去した時間分 だけ、 同じ S Pモードで記録可能な空き領域をディスク上に作ることができる。 図 9 8は、 A Vストリームの時間経過と A Vストリームのデ一夕バイ ト量との 関係が、 所定の誤差の範囲内で比例するように、 可変ビッ トレートを制御する場 合の、 図 1の記録再生装置 1の A Vエンコーダ 15の動作を説明するブ口ック図で ある。 図 9 8と図 1で、 同じ番号が付けられているプロックは同一のものである。 先ず、 ユーザインタフェース 2 4を通して、 ユーザから L P， S Pモードなど の記録モードが制御部 2 3に入力される。 制御部 2 3は記録モードに応じて、 記 録する A Vストリーム （D V Rトランスポートストリーム） の多重化ビヅトレー ト、 及びビデオ符号化の平均ビヅトレートを設定する （図 9 9のフローチャート のステヅプ S 2 0参照） 。
制御部 2 3は、 time一 control led—flagを 1にセヅトし、 多重化ストリームの平 均ビヅトレ一トを TS_average__rateとし、 また多重化ビヅトレートを TS_recordin g_rateとする。 制御部 2 3は、 time— control led_f lag，TS_recording_rateと TS_a verage_rateを Cl iplnfoに設定した Cl ip Informationファイルのデータベースを出 力する。 Cl ip Informationファイルは、 図 1で説明したように E C C符号化部 2 0の処理を通して、 記録媒体に記録される。
アナログのビデオ入力をエンコードする場合は、 端子 1 1からビデオが入力さ れる。 又は、 ディジタル放送入力のビデオをトランスコードする場合は、 A Vデ コーダ 2 7からのビデオが入力される。 入力ビデオは、 ビデオエンコーダ 1 5 1 へ入力される。 制御部 2 3は、 所定時間あたりのビデオに対する割り当て符号化 ビヅ ト量を計算して、 それをビデオエンコーダに指定する。 ビデオエンコーダ 1 1 5は、 所定時間あたりのビデオをエンコードして、 実際に発生した符号化ビヅ ト量を制御部 2 3へ入力する。 例えば、 所定時間の大きさは、 ビデオの G O Pで あり、 0 . 5秒である。 制御部 2 3は、 エンコーダから入力される実際に発生した 符号化ビヅ ト量のエンコード開始後の累計値に基づいて、 A Vスト リームの時間 経過と A Vストリームのデ一夕バイ ト量との関係が、 所定の誤差の範囲内で比例 するように、 ビデオ符号化の可変ビッ トレートの制御をして、 次の所定時間あた りのビデオに対する割り当て符号化ビッ ト量を計算する。 また、 このときに、 制 御部 2 3が、 エンコーダからビデオの符号化難易度 （動きベクトル予測の予測残 差の大きさ、 D C T係数の量子化スケールの大きさ等） を供給されることができ れば、 更に高画質な可変ビットレートを実現できる。 すなわち、 ビデオの符号化 難易度が高いほど、 所定時間あたりのビデオに対する割り当て符号化ビット量を 大きくするように制御する。
ビデオエンコーダ 1 1 5は、 ビデオストリ一ムをマルチプレクサ 1 6へ入力す る。 マルチプレクサ 1 6へはまた、 オーディオストリームと A V同期等のシステ ム情報 （S ) が入力される。 また、 オーディオ入力のエンコード処理の流れ、 及 び、 A V同期等のシステム情報 （S ) については、 図 1の説明と同じである。 マルチプレクサ 1 6は、 ビデオ及びオーディオストリームを、 所定の多重化ビ ヅ トレートのトランスポートストリームに多重化する。 このとき、 ビデオとォー ディォのパケヅ ト化は、 M P E G 2 トランスポートストリームのシステム夕ーゲ ヅ トデコーダ （T一 S T D ) を破綻させないように制御しなければならない。 T 一 S T Dの制限によって、 ビデオのアクセスュニヅ ト （符号化された I， P , B のピクチャ） 及びオーディオのアクセスュニヅト （オーディオフレーム） をパケ ヅト化することができない場合、 マルチプレクサ 1 6は、 ヌルパケッ ト （パケヅ ト I Dが、 OxlFFFであるパケット） を発生しないように多重化する。 この多重化 制御により、 連続するトランスポートパケットの時間間隔は不規則になり、 パケ ットは間欠的に発生する。
マルチプレクサ 1 6から出力されるトランスポートパケットは、 ソースパケッ 夕ィザ 1 9へ入力される。 ソースパケヅタイザ 1 9は、 各トランスポートパケヅ トにァライバルタイムスタンプを付加して、 ソースパケット化する。 そして、 ソ ースパケヅ ト列を前詰して、 A Vストリームファイルを生成する。 A Vストリー ムファイルは、 図 1で説明したように E C C符号化部 2 0の処理を通して、 記録 媒体に記録される。
図 9 9は、 A Vストリームの時間経過と A Vストリームのデーダバイ ト量との 関係が、 所定の誤差の範囲内で比例することを保証する符号化モード （time_con trol led_flag=l) において、 ビデオを可変ビヅ トレート符号化して、 A Vストリ ームを記録する動作を説明するフローチャートである。
ステップ S 2 0で、 制御部 2 3は、 トランスボートス ト リームの多重化ビヅ ト レート TS_recording— rate及びビデオ符号化の平均ビットレートを設定する。
ビデオ符号化の平均ビヅ トレートは、 TS_average_rateから、 オーディオ符号化 の一定のビヅ トレートと多重化のオーバへヅ ドのビヅ トレートを差し引いた値と する。 ここで、 TS_average— rateは、 記録器のアプリケーション （L P， S Pモー ドなど） によって所定に値に決められる。
TS_recording_rateは、 ビデオの可変ビヅトレート符号化の最大ビヅトレ一トに、 オーディオ符号化の一定のビヅトレ一トと多重化のオーバへヅ ドのビットレ一ト を加えた値よりも大きい値である。
ステヅプ S 2 1で、 制御部 2 3は、 ビデオストリームを、 予め設定した所定の 時間区間毎に所定の平均ビットレートが保証される様に、 可変ビットレートでェ ンコードするようにビデオエンコーダ 1 5 1を制御する。
ステヅプ S 2 2で、 制御部 2 3は、 トランスポートパケヅト化するエレメンタ リストリームがない場合にヌルパケットを発生しないようにマルチプレクサ 1 6 を制御する。 この多重化制御により、 連続する 2個のトランスポートパケットの時 間間隔は不規則になり、 パケットは間欠的に発生する。
ステップ S 23で、 制御部 23は、 各トランスポートパケヅトにァライバルタ ィムスタンプを付加して、 ソースパケヅト化するように、 ソースパケヅ夕ィザ 1 9を制御し、 そして、 ソースパケヅト列を前詰して、 AVストリームファイルと して記録するように制御する。
次に、 ビデオの可変ビヅ トレート符号化をする場合の MPEGの VBV (Vide 0 Buffering Verifier) の制御方法について説明する。 VBVは、 MPEGが規 定する理論的なデコーダモデルである （図 100を参照） 。 MP EGビデオェン コーダは、 VBVを正しく動作させるようにビデオストリームをエンコードしな ければならない。 これにより、 エンコード方法を制限する （主に量子化制御及び ピクチャのビッ ト量の制限） 。 VB Vの持つパヅファを VBVバッファと呼ぶ。 これは現実のデコーダに理論上、 最低必要なバヅファサイズである。 MPEG 2 メインプロファイルメインレベルの場合、 VBVバッファサイズは、 1. 75 M b i t sである。
可変ビヅ トレート時の MP E Gの VB Vは、 一般に、 図 10 1で示す方法が広 く知られている。 すなわち、 図 10 1は、 VB Vバッファに空きがあるときは、 バヅファへの入力ビヅ トレートが VB R( Variable Bit - Rate、 可変ビヅ トレー ト）の最大ビヅ ト レ一トであり、 VBVバッファのビヅ ト占有量がフルの場合は、 バヅファへの入力ビヅトレートが 0になる.場合の VB V制御を説明する図である。 図 1 0 1において、 右上がりの線の傾きは、 VBRの最大ビヅトレートを示し、 VBVバヅファに空きがあるときは、 VBRの最大ビヅ トレートでバヅファ占有 量が増える。 また、 VBVバヅファのビッ ト占有量がフルの場合は、 バッファへ の入力ビヅ トレートが 0となり、 バッファ占有量は変わらない。 横軸は時間軸で あり、 T1は 1つのデコード時刻を示し、 時刻 T1において図示する T1の時刻のピ クチャが瞬時にデコードされて、 バッファ占有量が減少する。 以後、 所定の時間 間隔で同様にして、 ピクチャがデコードされて、 バッファ占有量が減少する。 こ の図 1 0 1で示す方法では、 ビデオエンコーダがビデオストリ一ム中にス夕ヅフ ィングバイ トを発生することはない。
これに対して、 本発明では、 VB Vを図 102に示すように制御する。 すなわ ち、 所定の時間 （例えば、 G O P ) 毎にビットレートを変更する可変ビットレー トにおいて、 所定の時間内では C B R (Constant Bit-Rate、 固定ビヅ トレート）の V B V制御を行う。 図 1 0 2は、 G O P (例えば、 0 . 5秒のビデオシ一ケン ス） 内で C B Rの場合の V B V制御を示す。 すなわち、 V B Vバッファへの入力 ビヅトレートが、 現在の G 0 Pの符号化ビットレートであり、 V B Vバッファが オーバ一フローしないようにス夕ヅフィングバイ トを揷入する場合の V B V制御 を説明する図である。
ス夕ヅフィングバイ トの揷入するかどうかの判断と、 挿入する場合のス夕ヅフ イングバイ トの量の計算は、 次の手順で行う。 以下の説明において、
VBV— BUFFER_SIZE = 1.75*1024*1024 bit
gop_bit_rate : G O P毎のビヅ 卜レー卜 [bit/second]
とする。
( 1 ) 現在、 符号化するピクチャの最低ビット量の計算。
図 1 0 2の時刻 d 1のピクチャを例として説明する。 先ず、 時刻 d 1 のピクチャ を V B Vがデコードする直前の V B Vバッファのビヅ ト占有量 vbvj)を得る。 次に、 ビヅ ト占有量 vbv— bに、 時刻 d 1からその次のピクチャのデコ一ド時刻 d 2までの 間 （tau) にビットレート gop_bit— rateで入力されるビッ ト量を加えた値 t m pを 計算する。 現在、 符号化するピクチャの最低ビット量 min_picture_bitは、 tmp と VBV_BUFFER_SIZEから次のように計算できる。
tmp = vbv_b + gop_bit_rate*tau
min— picture— bit = tmp - VBV_BUFFER_SIZE
( 2 ) pi ctureの符号化後に、 byte stuffingが必要かのチェック。 現在のピク チヤの実際の符号化ビヅト gen_picture_bitが、 min— picture— bitより小さい場合 は、 次に示す計算式で示す大きさのスタッフイングバイ ト発生する。 現在符号化 した P i c tureの後に num_s tuff i ng_byte©数の s tuff ing by tesをビデオエンコーダ が符号化する。 1つのスタッフイングバイ トは、 8ビッ トの" 0000 0000"の符号で ある。
if (gen一 picture一 bit < min_picture一 bit)
nui_stuff ing_byte=(min_picture bit-gen picture_bit+4)/8 この図 1 0 2で示す方法では、 ビデオエンコーダが所定時間のビデオに割り当 てられたビヅト量を使うように制御することを目的として、 V B Vバッファへの 入力ビヅ トレートが現在の G O Pの符号化ビヅ トレ一トであり、 V B Vパヅファ がオーバーフローしないようにビデオエンコーダがス夕ヅフィングバイ トを発生 する。
図 1 0 2に示す V B V制御は、 本発明のコンセプトである、 A Vス ト リームの 時間経過と A Vストリームのデータバイ ト量との関係が図 1 0 3に示すように、 所定の誤差範囲内で比例することを保証するために、 有効である。 図 1 0 1に示 す V B V制御を使うと、 入力ビデオの中に長い時間の静止画像があると、 図 1 0 3の関係を保証できなくなる。 すなわち、 静止画像は情報量が比較的小さいため、 その情報量よりも符号化の割り当てビット量を大きくしても、 実際に符号化して 発生するビット量はある比較的小さな値に飽和してしまう。 したがって、 この場 合、 A ストリームの時間経過と A Vストリームのデータパイ ト量の関係が図 1 0 4に示すように、 比例しない。 このような場合でも、 図 1 0 2に示す V B V制 御を使えば、 ビデオエンコーダが所定時間のビデオに割り当てられたビット量を 使うように制御することを目的として、 V B Vバヅファへの入力ビヅ トレートが 現在の G O Pの符号化ビヅトレードであり、 V B Vバッファがオーバーフローし ないようにビデオエンコーダがス夕ヅフィングバイ トを発生するので、 A Vスト リームの時間経過と A Vストリームのデータバイ ト量との関係が図 1 0 3に示す ように、 所定の誤差範囲内でほぼ比例することを保証できる。
図 1 0 4の場合、 静止画像部分の時間部分の A Vストリームを消去しても、 そ の部分の占めるデータバイ ト量は、 平均ビットレートに消去時間をかけたデ一夕 サイズよりも小さいため、 消去した時間分だけ前記ストリームの TS_average_rat eで示されるビットレートで記録可能な空き領域をディスク上に作れることができ ない。 一方、 図 1 0 3の場合、 A Vストリームのある時間分だけ部分的にストリ ームを消去すると、 消去した時間分だけ前記ストリームの TS_average_rateで示さ れるビットレートで記録可能な空き領域をディスク上に作れることができる。 図 1 0 5は、 上述の図 9 9のステヅブ S 2 1の処理における、 ビデオの可変ビ ットレ一ト制御の処理の詳細を説明するフローチャートである。 01/82605 一
PCT/JP01/03412
74 ステップ S 200で、 VB Rの余裕量 sv_nowに初期値 SV1をセットする。 本発明 の可変ビヅ トレート制御は、 AVストリームの時間経過と A Vストリームのデー 夕バイ ト量との関係が所定の誤差範囲内で比例することを保証するために、 VB Rの余裕量 sv_nowが、 0から最大値 SVMAXになるように制御を行う。
例えば、 上記の式 （ 1) において、 ひ =300秒の場合、 SV1, SVMAXは次の値 である。 ここで、 ビデオの平均符号化ビッ トレートは、 図 99のステップ S 20 で決定された値である （図 107を参照） 。
SV1 = (ビデオの平均符号化ビヅ トレ一ト） * 300
SVMAX = SV1 * 2
ステップ S 20 1で、 現 GO Pの符号化の割り当てビヅ b_allocの計算する c ステヅプ S 202で、 以下の不等式が成り立つかを調べる。 このステップ Si; ϊ V B Rの余裕量がマイナスにならないかどうかチェックである。
sv一 now + b_av - b_al loc >= 0
ここで、 b— avは、 ビデオの平均符号化ビットレートから計算される、 GOP; i たりの符号化の割り当てビット量の平均値である。 GOPの時間長を、 0. 5: I とすると b_avは次の値である。
b_av = (ビデオの平均ビヅトレート） * 0.5
ステップ S 202で Ye sの場合は、 ステップ S 203へ進む。 ステップ S 02で Noの場合は、 ステヅプ S 204へ進み、 b_allocを b_avとし、 ステヅ ' ： 205へ進む。
ステップ S 203では、 以下の不等式が成り立つかを調べる。 このステツ：： 1 は、 VB Rの余裕量が最大値 SVMAXを超えないかどうかチェヅクである。
sv一 now + b_av - b— alloc く = SVMAX
ステヅプ S 203で Ye sの場合は、 ステヅプ S 205へ進む。 ステヅプ ί 03で Noの場合は、 ステヅプ S 204へ進み、 b_allocを b_avとし、 ステ、 ， 205へ進む。
ステップ S 205で、 現在の G OPのエンコードする。 そして、 現在の G を割り当てビット量 b一 allocでエンコードし、 そのときの VB V制御は、 V： E ヅファへの入力ビヅトレ一トを現在の GOPの符号化ビッ トレ一トとし、 V r バヅファがオーバ一フローしないようにスタッフィングバイ トを揷入するように 制御する。 この処理の詳細については、 図 106で説明する。
ステップ S 206で、 VBRの余裕量 sv_nowを次式のように更新する。 ここで、 b_genは、 ステップ S 205で、 現在の G 0 Pのエンコードした結果、 得られた現 G〇 Pの符号化ビッ ト量である。
sv_no += ¾_av - b_gen
ステヅプ S 207で、 現 GO Pが最後の GO Pであるか調べる。 ステヅプ S 2 07で、 Ye sの場合は、 処理を終了する。 ステップ S 207で、 Noの場合は、 ステップ S 20 1へ戻る。
図 1 06は、 上述の図 1 05のステヅプ S 205の処理における、 VB V制御 の処理の詳細を説明するフローチャートである。
ステヅプ S 300で、 次式のように現 GO Pに割り当てられた符号化ビッ ト量 を符号化ビヅトレート gopjDit— rateに変換する。
gop— bit— rate = b— alloc / (15/ 29.97)
ステップ S 30 1で、 現 GOPの中で、 現在符号化するピクチャの最低ビヅト 量 min_picture一 bitを次式により計算する。
tmp = vbv_b + gop_bit_rate*tau
iin_picture_bit = tip - VBV_BUFFER_SIZE
ここで、 vbvj)は、 VBVが、 現在符号化するピクチャをデコードする直前の V BVバヅファのビヅト占有量である （図 102参照） 。
tauは、 現在 符号化するピクチャのデコード時刻と その次のピクチャのデコー ド時刻の差である （図 102参照） 。
VBV— BUFFER— SIZEは、 V B Vバッファサイズであり、 MPEG 2 MP@MLの 場合、 1.75 Mbitである。
ステップ S 302で、 現在のピクチャのェンコ一ドし、 その発生ビヅ ト量 gen_ picture— bitを得る。
ステップ S 303で、 次の不等式を調べる。
gen_picture_bit く min— picture— Mt
ステップ S 303で Ye sの場合は、 ステヅプ S 304へ進む。 ステップ S 3 0 3で N oの場合は、 ステヅプ S 3 0 5へ進む。
ステップ S 3 0 4で、 現在符号化した pictureの後に num— stuffing— byteの数の ス夕ヅフィングバイ トをビデオエンコーダが現在符号化し、 それらを符号化ピク チヤの後ろに付加する （図 1 0 2参照） 。
num_stufnng_byte=(min_picture_t)it-gen_picture_bit+4)/8
ステップ S 3 0 5で、 G O Pの最後のピクチャかどうか調べる。 ステップ S 3 0 5で、 Y e sの場合は、 処理を終了する。 ステヅブ S 3 0 5で、 N oの場合は、 ステップ S 3 0 1へ戻る。
以上のようにして、 ビデオストリームの可変ビッ トレート符号化を制御し、 A Vストリームファイルを生成することにより、 A Vストリームの時間経過と A V ストリームのデータバイ ト量との関係が、 所定の誤差の範囲内で比例することを 保証することできる。 これにより、 そのストリームのある時間分だけ部分的にス トリームを消去すると、 消去した時間分だけ前記ストリームの TS_average_rateで 示されるビッ トレートで記録可能な空き領域をディスク上に作れることを保証で きる。
次に、 比較のため、 A Vストリームの時間経過と A Vストリームのデータバイ ト量との関係が比例することを保証しない符号化モード （time_control led— f lag =0) における A Vストリームの記録方法の例を 2つ示す。
1つ目の time_control led一 f lag=0の場合の例は、 ディジタル放送の A Vストリ ーム （プログラム） のトランスポートストリームをトランスペアレント記録する 場合である。 ディジタル放送が統計多重を用いている場合、 一般に、 その中の A Vストリームは可変ビヅトレートである。 一般に、 この場合の A Vストリームの 時間経過と A Vストリームのデータバイ ト量との関係が比例することは保証され ないので、 この A Vストリームをトランスペアレント記録して Cl ipを作成した場 合、 その Cl ipの time_control led— f lagを 0にセヅトする。
2つ目の tiiie_control led_f lag=0の場合の例は、 ビデオを可変ビヅ トレート符 号化する場合に、 ビデオス ト リームを、 予め設定した所定の時間区間毎に所定の 平均ビヅ トレート以下になる様に、 可変ビヅ トレートでエンコードする場合であ る。 これは、 図 1 0 1で説明したように、 ビデオ符号化の V B V制御が、 V B V バヅファに空きがあるときは、 ノ ヅファへの入力ビヅトレ一トを Variable Bit-R ateの最大ビッ トレートにし、 VB Vバヅファのビヅ ト占有量がフルの場合は、 Λ ヅファへの入力ビヅ トレートを 0にする場合である。 図 1 08と図 1 09を用い て、 この場合の AVストリームの記録方法を説明する。
図 1 08は、 A Vス トリームの時間経過と A Vストリームのデータバイ ト量と の関係が、 比例することを保証しない符号化モード （tiiae_controlled_;flag=0) において、 ビデオを可変ビットレート符号化して、 A Vストリームを記録する動 作を説明するフローチャートを示す。
ステップ S 400以外は、 図 99と同じである。
ステップ S 400で、 ビデオストリームを、 予め設定した所定の時間区間毎に 所定の平均ビヅ トレート以下になる様に、 可変ビヅトレートでェンコードするよ うにビデオエンコーダ 1 5 1を制御する。
図 1 09は、 上述の図 1 08のステップ S 400の処理における、 ビデオの可 変ビッ トレート制御の処理の詳細を説明するフローチャートである。
ステップ S 500で、 VBRの余裕量 sv_nowに初期値 SV1をセットする。 この場 合の可変ビヅ トレート制御は、 VB Rの余裕量 sv_nowが、 負の値にならないよう に制御を行う。
ステップ S 50 1で、 現 GOPの符号化の割り当てビヅ b_allocの計算する。 ステヅプ S 502で、 以下の不等式が成り立つかを調べる。 このステップ Sは、 VB Rの余裕量がマイナスにならないかどうかチェックである。
sv— now + b_av - b— alloc >= 0
ここで、 ID— avは、 ビデオの平均符号化ビットレートから計算される、 GOPあ たりの符号化の割り当てビット量の平均値である。 GOPの時間長を、 0. 5秒 とすると b_avは次の値である。
b_av = (ビデオの平均ビッ トレート） * 0.5
ステップ S 502で Ye sの場合は、 ステヅプ S 504へ進む。 ステップ S 5 02で Noの場合は、 ステップ S 504へ進み、 b— allocを b_avとし、 ステップ S 504へ進む。
ステヅプ S 504で、 現在の GO Pのェンコ一ドする。 そして、 現在の GO P を割り当てビット量 b_allocでエンコードし、 そのときの VBV制御は、 そのとき の VBV制御は、 VB Vバヅファに空きがあるときは、 バッファへの入力ビッ ト レートを VB R (Variable Bit- Rate)の最大ビッ トレートにし、 VBVバッファの ビヅ ト占有量がフルの場合は、 バッファへの入力ビヅ トレ一トを 0にする場合の VBV制御とする （図 1 0 1参照） 。 このステヅプ Sでは、 ビデオストリームに ス夕ヅフィングバイ トを符号化しない。
ステヅプ S 505で、 VBRの余裕量 sv_nowを次式のように更新する。 ここで、 b_genは、 ステップ S 504で、 現在の G 0 Pのエンコードした結果、 得られた現 GOPの符号化ビット量である。
sv一 now += b_av - b_gen
ステヅプ S 506で、 現 GO Pが最後の G〇Pであるか調べる。 ステヅプ S 5 06で、 Ye sの場合は、 処理を終了する。 ステヅプ S 506で、 N oの場合は、 ステップ S 50 1へ戻る。
上記の図 108及び図 1 09の記録方法の場合、 前述したように AVストリー ムの時間経過と AVストリームのデータバイ ト量との関係が所定の誤差範囲内で 比例することを保証しない。 例えば、 入力ビデオの中に長い時間の静止画像があ ると、 ス トリ一ムの時間経過と A Vストリームのデータバイ ト量との関係が 図 1 04に示したようになる。 すなわち、 静止画像は情報量が比較的小さいため、 その情報量よりも符号化の割り当てビット量を大きくしても、 実際に符号化して 発生するビット量はある比較的小さな値に飽和してしまう。 したがって、 この場 合、 AVストリームの時間経過と AVスト リームのデータバイ ト量の関係が、 比 例しない。
一方、 ビデオエンコーダが所定時間のビデオに割り当てられたビット量を使う ように制御することを目的として、 VBVバヅファへの入力ビヅトレートが現在 の GO Pの符号化ビヅトレートであり、 VBVバッファがオーバーフローしない ようにビデオエンコーダがスタッフィングバイ トを発生するように制御すれば、 AVストリームの時間経過と A Vストリームのデ一夕バイ ト量との関係が、 所定 の誤差範囲内でほぼ比例することを保証できる。
また、 AVストリームの時間経過と A Vストリームのデータバイ ト量との関係 が、 比例することを保証する符号化モード （time— conti>oI
Figure imgf000081_0001
を簡単に 実現する方法として、 トランスポートス ト リームを多重化するときにヌルパケッ トを揷入して、 一定ビヅ トレ一トのトランスポートス ト リームを記録することも 考えられる。 これは、 主にテープ記録媒体 （D— V H S等） で用いられている符 号化方法である。 ここで、 ヌルパケッ トは、 そのパケッ ト I D ( P I D ) が、 Ox 1FFFにセヅ トされている、 情報としては何も意味を持たないトランスポートパケ ヅ トである。
図 9 9の方法と比較する参考のために、 図 1 1 0に、 所定の一定ビヅ トレート のトランスポートス ト リームを符号化することによって、 A Vスト リームの時間 経過と A Vスト リームのデ一タバイ ト量との関係が、 比例することを保証する符 号化モードのフローチャートを示す。
ステヅプ S 6 0 0で、 トランスポートス トリームの多重化ビヅ トレート及びビ デォ符号化のビヅ トレートを設定する ステヅプ S 6 0 1で、 ビデオス ト リーム を、 所定の一定のビヅ トレート、 又は、 そのビッ トレート以下で、 エンコードす る。
ステップ S 6 0 2で、 トランスポートパケヅ ト化するエレメン夕リス ト リーム がない場合にヌルパケヅ ト （情報としては意味を持たないトランスポートパケヅ ト） を発生して多重化し、 所定の一定の多重化ビヅ トレートのトランスポートス ト リームを符号化する。
ステップ S 6 0 3で、 各トランスポートパケヅ トにァライバルタイムスタンプ を付加して、 ソースパケヅ ト化する。 ソースパケッ トを記録媒体に記録する。 上記の記録方法で A Vストリームを Cl ipとして記録した場合、 その Cl ipの time —control led_f lagは 1にセヅ トされる。 しかしながら、 この方法は、 ヌルパケヅ トを使用するため、 ビデオ符号化に効率良く符号ビッ トを使用していないので、 図 9 9の符号化方法よりもビデオの画質が劣る問題がある （このことについては、 例えば特願平 1 1— 2 2 0 7 2 7の従来の技術の欄に詳しく述べている） 。 その ため、 本発明では上記の図 1 1 0の記録方法を推奨しない。
次に、 A Vス トリームファイルのある時間分だけ部分的にス トリームを消去す る方法について説明する。 図 1 1 1は、 オリジナルの A Vストリームファイルと、 そのストリームの部分 的な再生範囲のストリームを消去する編集を行った後の A Vストリームファイル の例を示す。 編集前に、 Virtual PlayListは、 オリジナル A Vストリーム上の IN — timeと 0UT_timeを指しているとする。 このとき、 Virtual PlayListが使用してい ないストリーム部分を消去する編集 （ミニマイズ編集） をした場合、 それはオリ ジナル A Vストリ一ムを図 1 1 1に示す編集後のストリームへ変える。 オリジナ ル A Vストリームの先頭から X点までのデータと、 Y点から最後までのデータが 消去される。 以下の説明では、 この X点と Y点を決める方法の例を説明する。 図 1 1 2は、 A Vストリームの内容を解析することをしないで、 I N点の前の 不要なデータを消去する方法を説明する図である。 PlayListはオリジナル A Vス トリーム上の IN点を指す。 また、 その A Vストリームの EPjnapを図示する。 I N 点が指すピクチャをデコードするためには、 ァドレス ISA2から開始する Iピクチ ャが必要である。
また、 X点の後で、 PAT，PMT及び P C Rパケッ トが必要である。 RSPN_EP_start = ISA1の P T Sは ptslであり、 RSPN_EP— start=ISA2の P T Sは pts2である。 ptslと pts2のシステム夕ィムペースの時間差が 100 msec以上ならば、 ァドレス ISA1と IS A2の間には PAT， PMT及び P C Rパケヅ トが存在する （少なくとも、 S E S F , D V B， A T S C， I S D Bの場合はそうである） 。
したがって、 X点はアドレス ISA1の前に決められる。 そして、 X点はァライン ドュニヅトの境界でなければならない。 記録装置は、 A Vストリームの内容を解 析することをしないで、 X点を EP_mapを使用して次のステヅプで決めることができ る。
( S 1 ) システムタイムベース上で IN timeの P T Sに最も近く、 且つそれよりも 過去の表示時刻の P T Sの値を持つ SPN_EP_startを見つける。
( S 2 ) ステヅプ S 1で見つけた SPN—EP—startの P T Sの値よりも少なくとも 100 msec過去の表示時刻の P T Sの値を持つ SPfLEP_startを見つける。
( S 3 ) X点は、 ステップ S 2で見つけた SPN_EP_startよりも前に決められる。 そして、 X点はァラインドュニヅ トの境界でなければならない。
この方法は、 X点を決めるために A Vストリームのデータを読み出し、 その内 容を解析することを必要としないので、 簡単である。 しかし、 編集後の A Vスト リームは、 その PlayListの再生には不要なデータを残してしまう場合がある。 も し、 X点を決めるために A Vストリームのデ一夕を読み出し、 その内容を解析す るならば、 その PlayListの再生には不要なデータをより効率良く消去できる。
図 1 1 3は、 A Vストリームの内容を解析することをしないで、 O U T点の後 ろの不要なデータを消去する方法を説明する図である。 PlayListはオリジナル A Vストリーム上の O U T点を指す。 また、 その A Vストリームの EPjnapを図示す る。
SPN_EP_start=ISA4から開始するビデオシーケンスは次に示すものであることを 前提とする。
12 BO Bl P5…
ここで、 I , P， Bはそれそれ Iピクチャ， Pピクチャそして Bピクチャを表す。 数字は表示順序を表す。 この処理において、 記録装置が A Vス トリームの内容を 解析しない場合、 記録装置は 0UT_timeの P T Sが参照するところのピクチャの情 報 （ピクチャコーディングタイプ， テンポラル ·レファレンスなど） が分かい。 0 UT_tiineの P T Sはピクチャ B0又は B1を参照しているかもしれない （記録装置が A Vストリームの内容を-解析しない場合、 このことは分かい） 、 この場合、. ピクチ ャ B 0 , B 1をデコードするためには I 2が必要である。 1 2の P T Sは OUT ti meの P T Sよりも大きい （0UT_time < pts4, ここで pts4は I 2の： P T Sである） （ I 2の P T Sは OUT— timeの P T Sよりも大きいが、 B 0， B lのために 1 2が必 要である。
したがって、 Y点は図に示すアドレス ISA5の後ろに決められる。 ISA5は、 EP_m apの中で ISA4の直後にある SPN_EP— startの値である。 Y点はまたァラインドュニヅ トの境界でなければならない。
記録装置は、 A Vストリームの内容を解析することをしないで、 Y点を EPjaapを 使用して次のステヅブで決めることができる。
( S 1 ) システムタイムベース上で OUT timeの P T Sに最も近く、 且つそれより も未来の表示時刻の P T Sの値を持つ SPNJ1P— startを見つける。
( S 2 ) ステップ S 1で見つけた SPN EP_startの直後にある SPN_EP start を見つ ける。
( S 3 ) Y点は、 ステヅプ S 2で見つけた SPN_EP_startよりも後ろに決められる。 そして、 Y点はァラインドュニッ トの境界でなければならない。
この方法は、 Y点を決めるために A Vストリームのデ一夕を読み出し、 その内 容を解析することを必要としないので、 簡単である。 しかし、 編集後の A Vス ト リームは、 その PlayListの再生には不要なデータを残してしまう場合がある。 も し、 Y点を決めるために A Vス ト リームのデータを読み出し、 その内容を解析す るならば、 その PlayListの再生には不要なデ一夕をより効率良く消去できる。 次に、 EP_mapの作成の動作例を図 1 1 4のフローチャートを用いて説明する。 この処理は図 1の記録再生装置の多重化ストリーム解析部 1 8で行われる。
ステップ S 11でス ト リーム解析部 1 8は、 記録する A Vプログラムのビデオの P I Dをセヅ トする。 トランスポートス トリームの中に複数のビデオが含まれて いる場合は、 それそれのビデオ P I Dをセッ トする。
ステヅプ S 12でス ト リーム解析部 1 8は、 ビデオのトランスポートパケヅ トを 受信する。
ステヅプ S 1 3でス ト リーム解析部は、 トランスポートパケヅ トのペイロード (パケヅ トヘッダに続くデ一夕部） が P E Sパケッ トの第 1バイ ト目から開始し ているかを調べる （P E Sパケッ トは、 M P E G 2で規定されているパケッ トで あり、 エレメン夕リス ト リームをパケッ ト化するものである） 。 これは、 トラン スポートパケヅ トへヅダにある" payload_unit_start— indicator"の値を調べるご とにより分かり、 この値が 1である場合、 トランスポートパケッ トのペイロード が P E Sパケヅ トの第 1バイ ト目から鬨始する。 ステヅプ S 1 3で N oの場合は、 ステップ S 1 2へ戻り、 Y e sの場合は、 ステヅプ S 1 4へ進む。
ステップ S 1 4でス ト リーム解析部は、 P E Sパケッ トのペイロードが、 M P E Gビデオの sequence_header_code( 3 2 ビヅ ト長で" 0χ00Ο0Ο1Β3"の符号）の第 1 バイ ト目から鬨始しているかを調べる。 ステップ S 1 4で N oの場合は、 ステツ ブ S 1 2へ戻り、 Y e sの場合は、 ステップ S 1 5へ進む。
ステヅプ S 15へ進んだ場合、 現在のトランスポートパケッ トをエント リポイン トとする。 ステヅプ S 1 6でスト リーム解析部は、 上記パケヅ トのパケヅ ト番号 と上記 sequencejieade code から開始する Iピクチャの P T Sとそのエントリポ ィン卜が属するビデオの P I Dを取得し、 制御部 2 3へ入力する。 制御部 2 3は EPjnapを作成する。
ステヅプ S 1 7で、 現在のパケヅ卜が最後に入力されるトランスポートパケヅ トであるかどうかを判定する。 最後のパケヅトでない場合、 ステップ S 1 2へ戻 る。 最後のパケットである場合、 処理を終了する。
上述した一連の処理は、 ハードゥヱァにより実行させることもできるが、 ソフ トウエアにより実行させることもできる。 一連の処理をソフトウエアにより実行 させる場合には、 そのソフトウエアを構成するプログラムが専用のハードウエア に組み込まれているコンピュータ、 又は、 各種のプログラムをインストールする ことで、 各種の機能を実行することが可能な、 例えば汎用のパーソナルコンビュ 一夕などに、 記録媒体からインスト一ルされる。
この記録媒体は、 図 1 1 5に示すように、 コンピュータとは別に、 ユーザにプ ログラムを提供するために配布される、 プログラムが記 されている磁気ディス ク 2 2 1 (フロヅ ピディスクを含む） 、 光ディスク 2 2 2 ( C D - R O M (Comp act Disk-Read Only Memory) , D V D (Digital Versati le Disk) を含む） 、 光 磁気ディスク 2 2 3 (M D (Mini-Disk) を含む） 、 若しくは半導体メモリ 2 2 4 等よりなるパヅケージメディアにより構成されるだけでなく、 コンピュータに予 め組み込まれた状態でユーザに提供される、 プログラムが記憶されている R O M 2 0 2や記憶部 2 0 8が含まれるハードディスクなどで構成される。
なお、 本明細書において、 媒体により提供されるプログラムを記述するステツ プ Sは、 記載された順序に従って、 時系列的に行われる処理は勿論、 必ずしも時 系列的に処理されなくとも、 並列的あるいは個別に実行される処理をも含むもの である。
また、 本明細書において、 システムとは、 複数の装置により構成される装置全 体を表すものである。 産業上の利用可能性 以上の如く、 A Vストリームを符号化して記録するときに、 その A Vストリー ムの属性情報として、 time_control led_flag, TS_average_rateを記録する。 tim e_control led一 flagを 1にセットする場合、 A Vストリームの時間経過と A Vスト リームのデータバイ ト量との関係が、 所定の誤差の範囲内で比例することを保証 する。 また、 TS_average_rateは、 A Vストリームファイル （トランスポートスト リーム） の平均ビヅトレ一トを bytes/second の単位で表したものである。 TS_av erage_rateは、 記録器のアプリケーションによって所定に値に決める。 例えば、 長時間録画モード （L Pモード） ， 標準録画モード （ S Pモード） 、 高画質録画 モード （H Qモード） といった記録モードに応じて、 それそれのモードの TS—ave rage— rateの値を決める。
A Vストリームファイルの time_contro l ied—f lagが 1にセヅ 卜されている場合、 そのストリームのある時間分だけ部分的にストリームを消去すると、 消去した時 間分だけ前記ストリームの TS_average_rateで示されるビッ トレートで記録可能な 空き領域をディスク上に作れることを保証できる。 例えば、 S Pモードの A Vス トリームファイルのある時閭分だけ部分的にストリームを消去すると、 消去した 時間分だけ、 同じ S Pモードで記録可能な空き領域をディスク上に作ることがで きる。
time—control led—flagを 1にセットする場合、 次のようにして A Vストリーム を符号化する。
( 1 ) トランスポートストリームの多重化ビヅトレート及びビデオ符号化の平均 ビットレートを設定する。
( 2 ) ビデオストリームを、 予め設定した所定の時間区間毎に所定の平均ビヅ ト レートが保証される様に、 可変ビヅ トレートでエンコードする。 ここで、 M P E Gビデオ符号化の V B V (Video Buffering Verifier)制御は、 ビデオエンコーダ が所定時間のビデオに割り当てられたビット量を使うように制御することを目的 として、 V B Vバッファへの入力ビヅトレートが現在の符号化ビヅ トレートであ り、 V B Vバヅファがオーバーフロ一しないようにビデオエンコーダがス夕ヅフ イングバイ トを発生するようにする。
( 3 ) トランスポートパケヅト化するエレメン夕リストリームがない場合にヌル パケットを発生しないように多重化の制御をする。
( 4 ) 各トランスポートパケヅトにァライバルタイムスタンプを付加して、 ソー スパケヅト化し、 そして、 ソースパケヅト列を前詰して、 A Vストリームフアイ ルとして記録する。
このようにして、 A Vストリームを符号化して記録することにより、 そのスト リームのある時間分だけ部分的にストリームを消去すると、 消去した時間分だけ 前記ストリームの TS_average_rateで示されるビットレートで記録可能な空き領域 をディスク上に作れることを保証できる。

Claims

請求の範囲
1 . 映像データを符号化する符号化装置において、
前記映像データを可変レートにより符号化する符号化器と、
時間経過に対して映像符号化デ一夕量がほぼ比例するように制御する制御部と を有する符号化装置。
2 . 前記制御部は、 単位時間あたりの映像符号化デ一夕発生量が所定量に満 たないときにはスタッフイングバイ トを符号化するよう制御する請求の範囲第 1 項に記載の符号化装置。
3 . 前記制御部は、 各々のピクチャの符号化の際に発生するデータ量に応じ てスタッフィングバイ トを符号化するか否かを判定する請求の範囲第 2項に記載 の符号化装置。
4 . 前記制御部は、 V B Vバヅファがオーバーフローしないようにス夕ヅフ ィングバイ トを符号化するよう制御する請求の範囲第 2項に記載の符号化装置。
5 . 前記制御部は、 時間経過に対して符号化データ量がほぼ比例するように 符号化する符号化モードと通常の符号化モードのどちらか一方で符号化するよう に制御する請求の範囲第 1項に記載の符号化装置。
6 . 前記制御部は、 前記符号化モードが、 時間経過に対して符号化データ量 がほぽ比例するように符号化するモードか否かを示す付加情報を生成する請求の 範囲第 5項に記載の符号化装置。
7 . 映像データを符号化する符号化装置の符号化方法において、
前記映像データを可変レートにより符号化する符号化ステップと、
時間経過に対して映像符号化デ一夕量がほぼ比例するように制御する制御ステ ツプとを含む符号化方法。
8 . 映像データを符号化する符号化装置を制御するプログラムにおいて、 前記映像デ一夕を可変レートにより符号化する符号化ステツプと、
時間経過に対して映像符号化デ一夕量がほぼ比例するように制御する制御ステ ップとを含むコンビユー夕が読み取り可能なプログラムが記録されている記録媒 体。
9 . 映像デ一夕を符号化する符号化装置を制御するコンピュータに、 前記映像データを可変レートにより符号化する符号化ステップと、
時間経過に対して映像符号化データ量がほぼ比例するように制御する制御ステ ヅプとを実行させるプログラム。
1 0 . 映像データが記録されている記録媒体において、
前記映像データと、 前記映像デ一夕に対応するオーディオデータを含む A Vス トリ一ムファイルと、
前記 A Vストリームファイルの記録モ一ドを示すフラグとが記録されている記 録媒体。
1 1 . 前記フラグは、 time一 control led_f lagである請求の範囲第 1 0項に記 載の記録媒体。
1 2 . 前記フラグは、 記録してからの時間経過に対してファイルサイズが比 例するようにして記録されるモードであることを示す請求の範囲第 1 1項に記載 の記録媒体。
[ 2 0 0 1年 8月 2曰 （0 2 . 0 8 . 0 1 ) 国際事務局受理：出願当初の請求の範囲 1 , 2 , 5 , 7 , 8 , 9 , 1 0及び 1 1は補正された；出願当初の請求の範 π 2け
取り下げられた；他の請求の範囲は変更なし。 （2頁） ]
1 . (補正後） 映像データを符号化する符号化装置において、
前記映像デ一夕を可変レートにより符号化する符号化器と、
少なくとも時間経過に対して符号化映像データ量がほぽ比例する符号化モード、 及び時間経過に対して符号化映像デ一夕量が比例することを保証しない符号化モ ―ドを有し、 当該符号化モードに応じて前記符号化器における符号化映像デ一夕 の発生量を制御する制御部とを有する符号化装置。
2 . (補正後） 前記制御部は、 単位時間あたりの符号化映像デ一夕発生量が所 定量に満たないときにはスタッフィングパイ トを符号化するよう制御する請求の 範囲第 1項に記載の符号化装置。
3 . 前記制御部は、 各々のピクチャの符号化の際に発生するデータ量に応じ てス夕ッフィングバイ トを符号化するか否かを判定する請求の範囲第 2項に記載 の符号化装置。
4 . 前記制御部は、 V B Vバヅファがォ一バーフローしないようにスタッフ イングバイ トを符号化するよう制御する請求の範囲第 2項に記載の符号化装置。
5 . (補正後） 前記制御部は、 発生する符号化映像データ量が所定の誤差の範 囲内で時間経過に比例するように前記符号化器を制御する請求の範囲第 1項に記 載の符号化装置。
6 . 前記制御部は、 前記符号化モードが、 時間経過に対して符号化デ一夕量 がほぼ比例するように符号化するモードか否かを示す付加情報を生成する請求の 範囲第 5項に記載の符号化装置。
7 . (補正後） 映像データを符号化する符号化装置の符号化方法において、 前記映像デー夕を可変レートにより符号化する符号化ステップと、
少なくとも時間経過に対して符号化映像データ量がほぼ比例する符号化モード、 及び時間経過に対して符号化映像データ量が比例することを保証しない符号化モ ―ドを有し、 当該符号化モードに応じて前記符号化器における符号化映像データ の発生量を制御する制御ステツプとを含む符号化方法。 補正された屈紙 (条約第 19
8 . (補正後） 映像データを符号化する符号化装置を制御するプログラムにお いて、
前記映像データを可変レートにより符号化する符号化ステツプと、
少なくとも時間経過に対して符号化映像デ一夕量がほぼ比例する符号化モード、 及び時間経過に対して符号化映像デ一夕量が比例することを保証しない符号化モ 一ドを有し、 当該符号化モードに応じて前記符号化器における符号化映像データ の発生量を制御する制御ステップとを含むコンピュータが読み取り可能なプログ ラムが記録されている記録媒体。
9 . (補正後） 映像デ一夕を符号化する符号化装置を制御するコンピュータに、 前記映像データを可変レートにより符号化する符号化ステップと、
少なくとも時間経過に対して符号化映像デ一夕量がほぼ比例する符号化モ一ド、 及び時間経過に対して符号化映像デ一夕量が比例することを保証しない符号化モ 一ドを有し、 当該符号化モードに応じて前記符号化器における符号化映像デ一夕 の発生量を制御する制御ステツブとを実行させるプログラム。
1 0 . (補正後） 映像デ一夕が記録されている記録媒体において、
前記映像データと、 前記映像デ一夕に対応するオーディオデ一タを含む A Vス トリームファイルと、
前記 A Vストリームファイルのファイルサイズが、 時間経過に対してほぼ比例 する符号化モードで符号化されたか否かを示すフラグとが記録されている記録媒 体。
1 1 . (補正後） 前記フラグは、 time_control led_flagである請求の範囲第 1 0項に記載の記録媒体。
1 2 . (削除）
補正された屈紙 (条約第 19
PCT/JP2001/003412 2000-04-21 2001-04-20 Encoding device and method, recorded medium, and program WO2001082605A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US10/018,836 US7236687B2 (en) 2000-04-21 2001-04-20 Information processing apparatus and method, program, and recording medium
EP01921962A EP1198132A4 (en) 2000-04-21 2001-04-20 CODING DEVICE AND METHOD, RECORDING MEDIUM AND PROGRAM
MXPA01013110A MXPA01013110A (es) 2000-04-21 2001-04-20 Dispositivo codificador y metodo, medio de registro y programa.

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2000183770 2000-04-21
JP2000-183770 2000-04-21
JP2000-268042 2000-09-05
JP2000268042 2000-09-05

Publications (1)

Publication Number Publication Date
WO2001082605A1 true WO2001082605A1 (en) 2001-11-01

Family

ID=26594225

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/JP2001/003413 WO2001082604A1 (en) 2000-04-21 2001-04-20 Information processing apparatus and method, program, and recorded medium
PCT/JP2001/003412 WO2001082605A1 (en) 2000-04-21 2001-04-20 Encoding device and method, recorded medium, and program

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/JP2001/003413 WO2001082604A1 (en) 2000-04-21 2001-04-20 Information processing apparatus and method, program, and recorded medium

Country Status (7)

Country Link
US (2) US7646967B2 (ja)
EP (2) EP1198132A4 (ja)
JP (4) JP5008161B2 (ja)
KR (2) KR100806432B1 (ja)
CN (3) CN101867835B (ja)
MX (1) MXPA01013110A (ja)
WO (2) WO2001082604A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1316959A2 (en) * 2001-11-30 2003-06-04 Victor Company of Japan, Ltd. After-recording apparatus
US7496279B2 (en) 2001-12-22 2009-02-24 Lg Electronics Inc. Method of recording dubbing audio data onto a rewritable recording medium
US7502543B2 (en) 2001-06-22 2009-03-10 Sony Corporation Data transmission apparatus and data transmission method
US7545407B2 (en) 2001-12-24 2009-06-09 Lg Electronics Inc. Method of recording still pictures onto a recording medium
US7907186B2 (en) 2002-01-28 2011-03-15 Lg Electronics Inc. Method of recording still pictures on a recording medium
CN101404166B (zh) * 2007-10-04 2011-11-30 瑞萨电子株式会社 光盘再现设备及其操作方法

Families Citing this family (119)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8429699B2 (en) * 1999-12-14 2013-04-23 Arturo A. Rodriguez Systems and methods for resource-adaptive processing of scaled video and graphics
CN101430909B (zh) * 2001-06-15 2012-11-14 夏普株式会社 数据记录方法和数据解码方法
KR20020097454A (ko) 2001-06-21 2002-12-31 엘지전자 주식회사 멀티채널 스트림 기록장치 및 방법과, 그에 따른 기록매체
KR100598285B1 (ko) 2001-06-21 2006-07-07 엘지전자 주식회사 멀티채널 스트림 기록장치 및 방법과, 그에 따른 기록매체
JP2003032602A (ja) * 2001-07-11 2003-01-31 Pioneer Electronic Corp 画像編集装置及び方法、画像記録再生装置並びにコンピュータプログラム
JP3716920B2 (ja) * 2001-10-16 2005-11-16 ソニー株式会社 記録媒体再生装置および方法、記録媒体、並びにプログラム
CN101661785A (zh) 2001-11-29 2010-03-03 夏普株式会社 数据记录装置、数据再生装置、数据记录方法和数据显示方法以及记录装置
US7274857B2 (en) * 2001-12-31 2007-09-25 Scientific-Atlanta, Inc. Trick modes for compressed video streams
KR100563685B1 (ko) * 2002-02-25 2006-03-28 엘지전자 주식회사 재기록 가능 기록매체의 재생리스트 관리방법
KR100880627B1 (ko) * 2002-04-25 2009-01-30 엘지전자 주식회사 멀티 더빙 오디오 스트림의 기록 및 재생 관리방법
KR20030087193A (ko) 2002-05-07 2003-11-14 엘지전자 주식회사 멀티 채널 방송 스트림의 기록 관리방법
JP3833571B2 (ja) * 2002-05-28 2006-10-11 富士通株式会社 データ復号器およびデータ復号化方法
US7657152B2 (en) * 2002-05-28 2010-02-02 Panasonic Corporation Broadcast playback and/or recording apparatus
KR100930354B1 (ko) * 2002-06-18 2009-12-08 엘지전자 주식회사 대화형 광디스크 장치에서의 콘텐츠 정보 재생방법과,콘텐츠 제공서버에서의 콘텐츠 정보 제공방법
CA2462070C (en) 2002-06-21 2012-03-20 Lg Electronics Inc. Recording medium having data structure for managing reproduction of video data recorded thereon
CA2465105C (en) 2002-06-21 2012-08-28 Lg Electronics Inc. Recording medium having data structure for managing reproduction of video data recorded thereon
KR100550697B1 (ko) 2002-06-24 2006-02-08 엘지전자 주식회사 다중 타이틀 비디오 데이터의 재생을 관리하기 위한데이터 구조를 갖는 기록 매체와 그에 따른 기록 및 재생방법 및 장치
KR20040000290A (ko) 2002-06-24 2004-01-03 엘지전자 주식회사 고밀도 광디스크의 멀티 경로 데이터 스트림 관리방법
CN101350215B (zh) 2002-06-24 2012-08-29 Lg电子株式会社 记录和再现用于视频数据的再现的数据结构的方法及装置
US7889968B2 (en) 2002-06-24 2011-02-15 Lg Electronics Inc. Recording medium having data structure for managing reproduction of multiple reproduction path video data for at least a segment of a title recorded thereon and recording and reproducing methods and apparatuses
WO2004003907A1 (en) * 2002-06-28 2004-01-08 Lg Electronics Inc. Recording medium having data structure for managing reproduction of multiple playback path video data recorded thereon and recording and reproducing methods and apparatuses
CA2459086C (en) 2002-06-28 2013-08-13 Lg Electronics Inc. Recording medium having data structure for managing recording and reproduction of multiple path data recorded thereon and recording and reproducing methods and apparatus
KR100607949B1 (ko) * 2002-09-11 2006-08-03 삼성전자주식회사 계층화된 정보 구조를 이용한 멀티미디어 데이터 기록장치, 재생 장치 및 그 정보저장매체
JP3858151B2 (ja) * 2002-10-01 2006-12-13 パイオニア株式会社 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造
JP4431043B2 (ja) 2002-10-14 2010-03-10 エルジー エレクトロニクス インコーポレイティド 記録された複数のオーディオストリームの再生を管理するためのデータ構造を有する光ディスク、それによる記録及び再生方法及び装置
RU2334287C2 (ru) 2002-10-15 2008-09-20 Эл Джи Электроникс Инк. Носитель записи со структурой данных для управления воспроизведением записанных на нем нескольких графических потоков и способы и устройства записи и воспроизведения
KR100620332B1 (ko) 2002-11-08 2006-09-13 엘지전자 주식회사 멀티 컴포넌트 스트림의 기록 방법 및 장치와, 그에 따라기록된 멀티 컴포넌트 스트림을 갖는 고밀도 광디스크그리고 이의 재생 방법과 장치
US7720356B2 (en) 2002-11-12 2010-05-18 Lg Electronics Inc Recording medium having data structure for managing reproduction of multiple reproduction path video data recorded thereon and recording and reproducing methods and apparatuses
US7783160B2 (en) 2002-11-20 2010-08-24 Lg Electronics Inc. Recording medium having data structure for managing reproduction of interleaved multiple reproduction path video data recorded thereon and recording and reproducing methods and apparatuses
US7664372B2 (en) 2002-11-20 2010-02-16 Lg Electronics Inc. Recording medium having data structure for managing reproduction of multiple component data recorded thereon and recording and reproducing methods and apparatuses
US20050055375A1 (en) * 2002-12-13 2005-03-10 Yasuyuki Torii Recording and reproducing system, recording apparatus, reproducing apparatus, record medium, recording and reproducing method, recording method, reproducing method, program and record medium
US20050111831A1 (en) * 2002-12-13 2005-05-26 Chiyoko Matsumi Recording and reproducing system, recording and reproducing method, program and record medium
US7366733B2 (en) 2002-12-13 2008-04-29 Matsushita Electric Industrial Co., Ltd. Method and apparatus for reproducing play lists in record media
KR100520115B1 (ko) * 2002-12-27 2005-10-10 삼성전자주식회사 플레이리스트 관리 장치 및 방법
EP1843352B1 (en) * 2003-02-19 2010-10-20 Panasonic Corporation Recording medium, playback apparatus, recording method, program, and playback method
US7693394B2 (en) 2003-02-26 2010-04-06 Lg Electronics Inc. Recording medium having data structure for managing reproduction of data streams recorded thereon and recording and reproducing methods and apparatuses
US7809775B2 (en) * 2003-02-27 2010-10-05 Lg Electronics, Inc. Recording medium having data structure for managing playback control recorded thereon and recording and reproducing methods and apparatuses
CN100397882C (zh) 2003-02-28 2008-06-25 Lg电子株式会社 具有用于管理记录其上的视频数据的随机/洗牌重现的数据结构的记录媒体以及记录和重现的方法和装置
KR20090107560A (ko) * 2003-03-14 2009-10-13 인터디지탈 테크날러지 코포레이션 무선 통신에서 사용하기 위한 이득 제어 루프를 갖는 무선 송수신 유닛(ｗｔｒｕ)
US7224664B2 (en) 2003-03-25 2007-05-29 Lg Electronics Inc. Recording medium having data structure for managing reproduction of data streams recorded thereon and recording and reproducing methods and apparatuses
US7620301B2 (en) 2003-04-04 2009-11-17 Lg Electronics Inc. System and method for resuming playback
US7660511B2 (en) 2003-04-23 2010-02-09 Panasonic Corporation Recording medium, playback device, recording method, playback program, and playback method designating cue-up position using playlist mark information
JP4228767B2 (ja) * 2003-04-25 2009-02-25 ソニー株式会社 再生装置、再生方法、再生プログラムおよび記録媒体
KR100954999B1 (ko) * 2003-06-02 2010-04-27 엘지전자 주식회사 고밀도 광디스크의 부가 콘텐츠 데이터 관리 및 재생방법
US20040252966A1 (en) * 2003-06-10 2004-12-16 Holloway Marty M. Video storage and playback system and method
JP3931843B2 (ja) 2003-06-13 2007-06-20 株式会社日立製作所 記録媒体および再生方法
WO2005010882A1 (en) 2003-07-24 2005-02-03 Lg Electronics Inc. Recording medium having a data structure for managing reproduction of text subtitle data recorded thereon and recording and reproducing methods and apparatuses
KR20050012328A (ko) 2003-07-25 2005-02-02 엘지전자 주식회사 고밀도 광디스크의 프레젠테이션 그래픽 데이터 관리 및재생방법과 그에 따른 고밀도 광디스크
JP2005057657A (ja) * 2003-08-07 2005-03-03 Canon Inc 画像処理装置
US7966642B2 (en) * 2003-09-15 2011-06-21 Nair Ajith N Resource-adaptive management of video storage
EP2200030A3 (en) * 2003-10-03 2010-10-20 Sharp Kabushiki Kaisha Recording and reproducing apapratus
US7945141B2 (en) * 2003-10-06 2011-05-17 Samsung Electronics Co., Ltd. Information storage medium including event occurrence information, and apparatus and method for reproducing the information storage medium
JP4464101B2 (ja) * 2003-10-10 2010-05-19 キヤノン株式会社 トランスポートストリーム編集方法及び装置
EP2204805B1 (en) * 2003-10-10 2012-06-06 Sharp Kabushiki Kaisha A content reproducing apparatus, a content recording medium, a control program and a computer-readable recording medium
TW200518070A (en) 2003-10-10 2005-06-01 Matsushita Electric Ind Co Ltd Recording medium, reproduction device, program, and reproduction method
KR20050035678A (ko) 2003-10-14 2005-04-19 엘지전자 주식회사 광디스크 장치의 부가 데이터 재생방법 및 장치와, 이를위한 광디스크
KR20050036277A (ko) * 2003-10-15 2005-04-20 엘지전자 주식회사 고밀도 광디스크의 네비게이션 정보 관리방법
KR20050048848A (ko) 2003-11-20 2005-05-25 엘지전자 주식회사 고밀도 광디스크의 플레이리스트 생성방법, 관리방법 및재생방법과 기록재생장치
KR20050052790A (ko) * 2003-12-01 2005-06-07 엘지전자 주식회사 고밀도 광디스크 및 고밀도 광디스크의 파일 관리방법 및재생방법과 기록재생장치
EP1721319A2 (en) * 2004-01-06 2006-11-15 LG Electronics Inc. Recording medium and method and apparatus for reproducing and recording text subtitle streams
KR20050072255A (ko) * 2004-01-06 2005-07-11 엘지전자 주식회사 고밀도 광디스크의 서브타이틀 구성방법 및 재생방법과기록재생장치
EP1713276B1 (en) * 2004-02-06 2012-10-24 Sony Corporation Information processing device, information processing method, program, and data structure
WO2005076278A1 (en) * 2004-02-10 2005-08-18 Lg Electronic Inc. Recording medium having a data structure for managing data streams associated with different languages and recording and reproducing methods and apparatuses
US7587405B2 (en) * 2004-02-10 2009-09-08 Lg Electronics Inc. Recording medium and method and apparatus for decoding text subtitle streams
US20050196146A1 (en) * 2004-02-10 2005-09-08 Yoo Jea Y. Method for reproducing text subtitle and text subtitle decoding system
EP1716566A1 (en) * 2004-02-10 2006-11-02 LG Electronic Inc. Recording medium having a data structure for managing font information for text subtitles and recording and reproducing methods and apparatuses
WO2005074394A2 (en) * 2004-02-10 2005-08-18 Lg Electronics Inc. Recording medium having a data structure for managing various data and recording and reproducing methods and apparatuses
EP1730947A2 (en) * 2004-02-10 2006-12-13 LG Electronics Inc. Recording medium having a data structure for managing various data streams and recording and reproducing methods and apparatuses
WO2005076601A1 (en) 2004-02-10 2005-08-18 Lg Electronic Inc. Text subtitle decoder and method for decoding text subtitle streams
EP1714281A2 (en) * 2004-02-10 2006-10-25 LG Electronic Inc. Recording medium and method and apparatus for decoding text subtitle streams
RU2377669C2 (ru) * 2004-02-10 2009-12-27 ЭлДжи ЭЛЕКТРОНИКС ИНК. Носитель записи, имеющий структуру данных для управления различными данными, и способ и устройство записи и воспроизведения
KR20050089353A (ko) * 2004-03-04 2005-09-08 엘지전자 주식회사 고밀도 광디스크와 그에 따른 데이터 파일 구성 방법 및재생 방법과 장치
KR20060129067A (ko) * 2004-02-26 2006-12-14 엘지전자 주식회사 기록매체 및 텍스트 서브타이틀 스트림 기록 재생 방법과장치
KR100662902B1 (ko) * 2004-03-09 2007-01-02 삼성전자주식회사 Ｄｖｉ 규격의 디지털 신호를 출력할 수 있는 광재생장치및 그 재생방법
WO2005088634A1 (en) 2004-03-17 2005-09-22 Lg Electronics Inc. Recording medium, method, and apparatus for reproducing text subtitle streams
KR101102398B1 (ko) 2004-03-18 2012-01-05 엘지전자 주식회사 기록매체 및 기록매체상에 기록된 텍스트 서브타이틀스트림 재생 방법과 장치
US7617242B2 (en) 2004-03-30 2009-11-10 Panasonic Corporation Method and apparatus for reproducing play lists in record media
US20050232601A1 (en) * 2004-04-02 2005-10-20 Hiroshi Kase Data recording and reproducing apparatus, data recording and reproducing method and recording medium
US20050220442A1 (en) * 2004-04-02 2005-10-06 Hiroshi Kase Data recording and reproducing apparatus, data recording and reproducing method and recording medium
US20050219980A1 (en) * 2004-04-02 2005-10-06 Hiroshi Kase Data recording and reproducing apparatus, data recording and reproducing method and recording medium
CN1943237A (zh) * 2004-04-15 2007-04-04 皇家飞利浦电子股份有限公司 无需重新编码为多媒体段的无缝连接创建桥接剪辑
JP4249224B2 (ja) * 2004-04-16 2009-04-02 パナソニック株式会社 再生装置、及び記録方法
EP1746825B1 (en) * 2004-04-16 2011-06-08 Panasonic Corporation Recording medium, reproduction device, program
KR20060047266A (ko) * 2004-04-26 2006-05-18 엘지전자 주식회사 기록매체, 기록매체의 재생방법과 재생장치
EP1596396A1 (en) * 2004-05-15 2005-11-16 Deutsche Thomson-Brandt Gmbh Method for splitting a data stream
JP4608953B2 (ja) * 2004-06-07 2011-01-12 ソニー株式会社 データ記録装置、方法およびプログラム、データ再生装置、方法およびプログラム、ならびに、記録媒体
US20050276548A1 (en) * 2004-06-10 2005-12-15 Jiang Fu Transcoding closed captioning data from broadcast DTV onto DVD
US8600217B2 (en) * 2004-07-14 2013-12-03 Arturo A. Rodriguez System and method for improving quality of displayed picture during trick modes
CN100395842C (zh) * 2004-12-10 2008-06-18 上海乐金广电电子有限公司 Dvd设备的编码装置及其方法
KR101151303B1 (ko) * 2004-12-29 2012-06-08 엘지전자 주식회사 데이터 패킷의 도착시각을 결정하는 방법 및 장치
TWI323456B (en) * 2005-01-07 2010-04-11 Samsung Electronics Co Ltd Storage medium storing metadata for providing enhanced search function
KR100782810B1 (ko) * 2005-01-07 2007-12-06 삼성전자주식회사 확장 검색 기능을 제공하기 위한 메타데이터가 기록된 저장매체를 재생하는 방법 및 장치
US8249416B2 (en) * 2005-01-28 2012-08-21 Panasonic Corporation Recording medium, program, and reproduction method
JP2006302346A (ja) * 2005-04-15 2006-11-02 Toshiba Corp 情報記録媒体、情報記録方法、情報再生方法、情報記録装置、情報再生装置
EP1873780B1 (en) * 2005-04-22 2018-10-03 Sony Corporation Recording device, recording method, reproducing device, reproducing method, program, and recording medium
US7912219B1 (en) 2005-08-12 2011-03-22 The Directv Group, Inc. Just in time delivery of entitlement control message (ECMs) and other essential data elements for television programming
JP2007074549A (ja) * 2005-09-08 2007-03-22 Toshiba Corp 情報記録媒体、情報記録方法、情報再生方法、情報記録装置、情報再生装置
US8989084B2 (en) 2005-10-14 2015-03-24 Qualcomm Incorporated Methods and apparatus for broadcasting loading information corresponding to neighboring base stations
JP4784371B2 (ja) * 2006-04-06 2011-10-05 ソニー株式会社 記録装置、記録方法および記録プログラム
JP4591405B2 (ja) * 2006-05-10 2010-12-01 ソニー株式会社 情報処理装置及び情報処理方法、並びにコンピュータ・プログラム
JP4229144B2 (ja) * 2006-06-23 2009-02-25 ソニー株式会社 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
JP4755257B2 (ja) 2006-11-16 2011-08-24 富士通セミコンダクター株式会社 Ｇｏｐ間管理装置
JP5239170B2 (ja) * 2007-02-28 2013-07-17 富士ゼロックス株式会社 画像処理システム及びプログラム
US20090033791A1 (en) * 2007-07-31 2009-02-05 Scientific-Atlanta, Inc. Video processing systems and methods
US8223151B2 (en) * 2008-01-25 2012-07-17 Tektronix, Inc. Mark extension for analysis of long record length data
US8300696B2 (en) * 2008-07-25 2012-10-30 Cisco Technology, Inc. Transcoding for systems operating under plural video coding specifications
JP2011151784A (ja) * 2009-12-25 2011-08-04 Panasonic Corp 動画像多重化装置、映像音声記録装置及び動画像多重化方法
JP2012249019A (ja) * 2011-05-26 2012-12-13 Sony Corp 記録装置、記録方法、再生装置、再生方法、プログラム、および記録再生装置
JP5999405B2 (ja) * 2011-11-28 2016-09-28 ソニー株式会社 情報処理装置、情報処理方法、並びにプログラム
JP2013115552A (ja) * 2011-11-28 2013-06-10 Sony Corp 情報処理装置、情報処理方法、並びにプログラム
US10372758B2 (en) * 2011-12-22 2019-08-06 Tivo Solutions Inc. User interface for viewing targeted segments of multimedia content based on time-based metadata search criteria
TWI540886B (zh) * 2012-05-23 2016-07-01 晨星半導體股份有限公司 音訊解碼方法及音訊解碼裝置
TWI447718B (zh) * 2012-09-03 2014-08-01 Mstar Semiconductor Inc 產生略縮圖之方法與裝置
US9888115B2 (en) 2013-02-28 2018-02-06 Lennard A. Gumaer Media device and method of using a media device
US9998750B2 (en) 2013-03-15 2018-06-12 Cisco Technology, Inc. Systems and methods for guided conversion of video from a first to a second compression format
JP6461638B2 (ja) * 2014-02-21 2019-01-30 日本放送協会 受信機
US10679581B2 (en) * 2016-04-28 2020-06-09 Sony Corporation Information processing terminal apparatus
DE102017127428B4 (de) * 2016-11-22 2023-11-09 Hyundai Motor Company Verfahren und Vorrichtung zum Wiedergeben von Inhalten basierend auf einer Präsentationszeit im Fahrzeugnetzwerk
CN112115072B (zh) * 2020-09-03 2022-06-17 清华大学 时序图的处理方法及装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0846907A (ja) * 1994-07-27 1996-02-16 Hitachi Ltd ディスク記録装置
JPH0946691A (ja) * 1995-07-31 1997-02-14 Victor Co Of Japan Ltd 情報蓄積出力方法及び情報蓄積出力装置
US5612900A (en) 1995-05-08 1997-03-18 Kabushiki Kaisha Toshiba Video encoding method and system which encodes using a rate-quantizer model
JPH09135412A (ja) * 1995-11-08 1997-05-20 Canon Inc 記録再生装置
US5872598A (en) 1995-12-26 1999-02-16 C-Cube Microsystems Scene change detection using quantization scale factor rate control
JPH11205740A (ja) * 1998-01-09 1999-07-30 Toshiba Corp 圧縮記録装置及び方法
EP1091588A1 (en) 1999-04-23 2001-04-11 Sony Corporation Image encoder and its method

Family Cites Families (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3344607B2 (ja) 1993-10-04 2002-11-11 松下電器産業株式会社 光ディスク、再生装置および再生方法
JP2873781B2 (ja) 1994-08-17 1999-03-24 株式会社グラフィックス・コミュニケーション・ラボラトリーズ 動画像符号量制御方法と装置
JP3119116B2 (ja) 1995-06-07 2000-12-18 株式会社日立製作所 ディジタル映像信号の出力回路、記録装置及び再生装置
US6002834A (en) * 1995-02-24 1999-12-14 Hitachi, Ltd. Optical disk having table relating sector address and time and optical disk reproducing apparatus
JP3329979B2 (ja) * 1995-02-24 2002-09-30 株式会社日立製作所 光ディスク及び光ディスク再生装置
JPH08280012A (ja) 1995-04-08 1996-10-22 Sony Corp データ記録方法及び装置、データ再生方法及び装置、記録媒体、データ伝送方法及び装置
TW436777B (en) * 1995-09-29 2001-05-28 Matsushita Electric Ind Co Ltd A method and an apparatus for reproducing bitstream having non-sequential system clock data seamlessly therebetween
JPH09139937A (ja) 1995-11-14 1997-05-27 Fujitsu Ltd 動画ストリーム変換装置
JP3536493B2 (ja) 1995-12-13 2004-06-07 ソニー株式会社 オーサリングシステム，このシステムで使用される符号化装置及び多重化装置並びに多重ビットストリームを生成する方法
JPH09233374A (ja) 1996-02-20 1997-09-05 Sony Tektronix Corp 放送用録画再生システム
JP4112644B2 (ja) 1996-02-28 2008-07-02 パイオニア株式会社 情報記録媒体、情報記録装置及び情報記録方法並びに情報再生装置及び情報再生方法
JP3719758B2 (ja) 1996-03-19 2005-11-24 パイオニア株式会社 情報記録装置及び方法並びに情報再生装置及び方法
JPH09312656A (ja) 1996-03-21 1997-12-02 Sony Corp 伝送装置およびその方法
JPH1023069A (ja) 1996-07-02 1998-01-23 Sony Corp 伝送装置及び伝送方法
JP3216531B2 (ja) 1996-07-24 2001-10-09 三菱電機株式会社 再多重化装置および再多重化方法
KR19980017222A (ko) * 1996-08-30 1998-06-05 배순훈 디브이디 시스템의 화상 스캔 방법
US5838876A (en) * 1996-09-24 1998-11-17 Sony Corporation Frame-accurate edit and playback in digital stream recording
JP3151173B2 (ja) 1996-09-25 2001-04-03 松下電器産業株式会社 画像圧縮符号化装置及び方法
US6393196B1 (en) 1996-09-27 2002-05-21 Matsushita Electric Industrial Co., Ltd. Multimedia stream generating method enabling alternative reproduction of video data, and a multimedia optical disk authoring system
US5917830A (en) * 1996-10-18 1999-06-29 General Instrument Corporation Splicing compressed packetized digital video streams
JPH10133700A (ja) 1996-10-31 1998-05-22 Sanyo Electric Co Ltd 圧縮符号化データの記録方法
JPH10145735A (ja) 1996-11-05 1998-05-29 Toshiba Corp 復号装置および画像／音声再生方法
US6324335B1 (en) * 1996-11-29 2001-11-27 Sony Corporation Editing system and editing method
JP4363671B2 (ja) 1997-03-20 2009-11-11 ソニー株式会社 データ再生装置及びデータ再生方法
JP3791114B2 (ja) 1997-04-30 2006-06-28 ソニー株式会社 信号再生装置及び方法
JP3356004B2 (ja) * 1997-05-30 2002-12-09 日本ビクター株式会社 可変レート符号化装置及び方法
EP1193708B1 (en) * 1997-09-17 2006-03-29 Matsushita Electric Industrial Co., Ltd. Optical disc, recording apparatus, and computer-readable recording medium
CA2247637A1 (en) * 1997-09-17 1999-03-17 Matsushita Electric Industrial Co., Ltd. Video data editing apparatus, optical disc for use as a recording medium of a video data editing apparatus, and computer-readable recording medium storing an editing program
US6181870B1 (en) * 1997-09-17 2001-01-30 Matushita Electric Industrial Co., Ltd. Optical disc having an area storing original and user chain information specifying at least part of a video object stored on the disc, and a computer program and recording apparatus for recording and editing the chain information
JPH1196730A (ja) 1997-09-17 1999-04-09 Matsushita Electric Ind Co Ltd 光ディスク及びその編集装置、再生装置
JPH11103441A (ja) 1997-09-26 1999-04-13 Matsushita Electric Ind Co Ltd クリップ表示方法とその表示装置
DE69838869T2 (de) 1997-10-03 2008-12-04 Sony Corp. Vorrichtung und Verfahren zum Spleißen von codierten Datenströmen sowie Vorrichtung und Verfahren zur Erzeugung von codierten Datenströmen
JPH11122623A (ja) 1997-10-15 1999-04-30 Mega Chips Corp 画像符号化装置
EP0910087B1 (en) 1997-10-17 2011-11-30 Sony Corporation Recording apparatus and method, reproducing apparatus and method, recording/reproducing apparatus and method, recording medium and distribution medium
EP0917149A3 (en) 1997-10-21 2001-03-21 Sony Corporation Information processing apparatus, information processing method, presentation medium and recording medium
JP3276596B2 (ja) 1997-11-04 2002-04-22 松下電器産業株式会社 動画像編集装置
JPH11149717A (ja) 1997-11-19 1999-06-02 Toshiba Corp デコード処理方法及び装置
TW385436B (en) 1997-12-12 2000-03-21 Toshiba Corp Digital recording system using variable recording rate
JPH11259992A (ja) 1998-03-10 1999-09-24 Toshiba Corp 情報記録媒体と情報記録装置と情報編集装置とディジタル放送記録装置
JP4615637B2 (ja) 1998-03-20 2011-01-19 パイオニア株式会社 情報記録再生装置
EP0953977B1 (en) * 1998-05-01 2003-03-26 Samsung Electronics Co., Ltd. Recording medium for storing real time recording/reproduction information
JP4207304B2 (ja) 1998-05-19 2009-01-14 ソニー株式会社 情報入力装置および方法、情報出力装置および方法、並びに記録媒体
JPH11355772A (ja) 1998-06-10 1999-12-24 Victor Co Of Japan Ltd 映像信号符号化装置
JP3383587B2 (ja) 1998-07-07 2003-03-04 株式会社東芝 静止画像連続情報記録方法と光ディスクと光ディスクの情報再生装置と情報再生方法
JP3356691B2 (ja) * 1998-07-07 2002-12-16 株式会社東芝 情報記録媒体とその記録方法及び再生方法
JP2000059326A (ja) 1998-08-11 2000-02-25 Sony Corp 送出ログファイル作成方法およびデータ送出装置
EP0991072A1 (en) 1998-09-07 2000-04-05 Deutsche Thomson-Brandt Gmbh Method for addressing a bit stream recording
EP0986062A1 (en) 1998-09-07 2000-03-15 Deutsche Thomson-Brandt Gmbh Method for addressing a bit stream recording
TW463165B (en) * 1998-09-07 2001-11-11 Thomson Brandt Gmbh Method for addressing a bitstream to be recorded or being recorded on a storage medium
JP4207099B2 (ja) * 1998-09-29 2009-01-14 ソニー株式会社 画像編集装置及びその方法
JP2000149502A (ja) * 1998-11-10 2000-05-30 Sony Corp 編集データ作成装置
CA2289958C (en) * 1998-11-19 2003-01-21 Tomoyuki Okada Information recording medium, apparatus and method for recording or reproducing data thereof
EP1021048A3 (en) * 1999-01-14 2002-10-02 Kabushiki Kaisha Toshiba Digital video recording system and its recording medium
WO2000046803A1 (fr) 1999-02-05 2000-08-10 Kabushiki Kaisha Toshiba Procede permettant de creer des trains de donnees et procede permettant d'effectuer des suppressions partielles
US6470140B1 (en) * 1999-03-10 2002-10-22 Matsushita Electric Industrial Co., Ltd. Optical disc optical disc recording and reproducing apparatus, and optical disc recording and reproducing method
WO2000055854A1 (fr) * 1999-03-17 2000-09-21 Kabushiki Kaisha Toshiba Procede d'enregistrement de donnees en fluxet de leur structure
US6493005B1 (en) * 1999-03-30 2002-12-10 Sony Corporation On screen display
JP4389365B2 (ja) * 1999-09-29 2009-12-24 ソニー株式会社 トランスポートストリーム記録装置および方法、トランスポートストリーム再生装置および方法、並びにプログラム記録媒体
JP4328989B2 (ja) * 1999-11-24 2009-09-09 ソニー株式会社 再生装置、再生方法、並びに記録媒体
JP3942792B2 (ja) 2000-03-28 2007-07-11 パイオニア株式会社 映像編集方法及び装置、並びにそのための記憶媒体
GB0007870D0 (en) * 2000-03-31 2000-05-17 Koninkl Philips Electronics Nv Methods and apparatus for making and replauing digital video recordings, and recordings made by such methods
JP4168569B2 (ja) 2000-03-31 2008-10-22 松下電器産業株式会社 映像編集装置
JP4517266B2 (ja) * 2000-04-21 2010-08-04 ソニー株式会社 情報処理装置および方法、記録媒体、並びにプログラム
US7477833B2 (en) * 2000-04-21 2009-01-13 Sony Corporation Information processing apparatus and method, program, and recorded medium specifying particular picture characteristics

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0846907A (ja) * 1994-07-27 1996-02-16 Hitachi Ltd ディスク記録装置
US5612900A (en) 1995-05-08 1997-03-18 Kabushiki Kaisha Toshiba Video encoding method and system which encodes using a rate-quantizer model
JPH0946691A (ja) * 1995-07-31 1997-02-14 Victor Co Of Japan Ltd 情報蓄積出力方法及び情報蓄積出力装置
JPH09135412A (ja) * 1995-11-08 1997-05-20 Canon Inc 記録再生装置
US5872598A (en) 1995-12-26 1999-02-16 C-Cube Microsystems Scene change detection using quantization scale factor rate control
JPH11205740A (ja) * 1998-01-09 1999-07-30 Toshiba Corp 圧縮記録装置及び方法
EP1091588A1 (en) 1999-04-23 2001-04-11 Sony Corporation Image encoder and its method

Non-Patent Citations (1)

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

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7502543B2 (en) 2001-06-22 2009-03-10 Sony Corporation Data transmission apparatus and data transmission method
EP1316959A2 (en) * 2001-11-30 2003-06-04 Victor Company of Japan, Ltd. After-recording apparatus
EP1316959A3 (en) * 2001-11-30 2005-08-10 Victor Company of Japan, Ltd. After-recording apparatus
US7289718B2 (en) 2001-11-30 2007-10-30 Victor Company Of Japan, Ltd. After-recording apparatus
US8224161B2 (en) 2001-11-30 2012-07-17 Victor Company Of Japan, Ltd. After-recording apparatus
US8233776B2 (en) 2001-11-30 2012-07-31 Victor Company Of Japan, Ltd. After-recording apparatus
US8244108B2 (en) 2001-11-30 2012-08-14 Victor Company Of Japan, Ltd. After-recording apparatus
US7496279B2 (en) 2001-12-22 2009-02-24 Lg Electronics Inc. Method of recording dubbing audio data onto a rewritable recording medium
US8295686B2 (en) 2001-12-22 2012-10-23 Lg Electronics Inc. Method of recording dubbing audio data onto a rewritable recording medium
US7545407B2 (en) 2001-12-24 2009-06-09 Lg Electronics Inc. Method of recording still pictures onto a recording medium
US7907186B2 (en) 2002-01-28 2011-03-15 Lg Electronics Inc. Method of recording still pictures on a recording medium
CN101404166B (zh) * 2007-10-04 2011-11-30 瑞萨电子株式会社 光盘再现设备及其操作方法

Also Published As

Publication number Publication date
CN1199446C (zh) 2005-04-27
US7646967B2 (en) 2010-01-12
JP2012191658A (ja) 2012-10-04
KR20020026195A (ko) 2002-04-06
US8634700B2 (en) 2014-01-21
EP2546833A3 (en) 2014-08-20
MXPA01013110A (es) 2002-06-04
EP1198132A1 (en) 2002-04-17
CN101867835B (zh) 2013-09-11
JP5047371B2 (ja) 2012-10-10
CN1383677A (zh) 2002-12-04
EP2546833A2 (en) 2013-01-16
KR20020022135A (ko) 2002-03-25
JP5500398B2 (ja) 2014-05-21
KR100821019B1 (ko) 2008-04-08
WO2001082604A1 (en) 2001-11-01
JP2011135589A (ja) 2011-07-07
JP2011050082A (ja) 2011-03-10
US20030103604A1 (en) 2003-06-05
JP5008160B2 (ja) 2012-08-22
CN101867835A (zh) 2010-10-20
EP1198132A4 (en) 2010-07-28
US20100080534A1 (en) 2010-04-01
CN1383678A (zh) 2002-12-04
JP2011050081A (ja) 2011-03-10
JP5008161B2 (ja) 2012-08-22
KR100806432B1 (ko) 2008-02-21

Similar Documents

Publication Publication Date Title
JP5500398B2 (ja) 情報処理装置および方法、記録媒体、並びにプログラム
KR100746821B1 (ko) 정보 처리 장치와 방법, 기록매체
JP4919130B2 (ja) 情報処理装置、情報処理方法、記録媒体、およびプログラム、並びにデータ構造
JP4517267B2 (ja) 記録装置および方法、再生装置および方法、プログラム、並びに記録媒体
JP4682434B2 (ja) 情報処理装置および方法、記録媒体、並びにプログラム
WO2001082608A1 (fr) Appareil et procede de traitement des informations, programme et support enregistre
WO2001082611A1 (fr) Procede et appareil de traitement d&#39;informations, support enregistre, et programme
JP4355988B2 (ja) 情報処理装置、情報処理方法、プログラム記録媒体、プログラム、および情報記録媒体
JP2002158965A (ja) 情報処理装置および方法、記録媒体、プログラム、並びに記録媒体
JP2002159004A (ja) 符号化装置および方法、記録媒体、並びにプログラム

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN KR MX US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

WWE Wipo information: entry into national phase

Ref document number: PA/a/2001/013110

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 2001921962

Country of ref document: EP

Ref document number: 1020017016424

Country of ref document: KR

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

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 1020017016424

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2001921962

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10018836

Country of ref document: US