RU2273109C2 - Method and device for processing information, program and data carrier - Google Patents

Abstract

FIELD: method and device for processing AV information, engineering of data carrier for recording a file including information provided for clarification purposes in graphic user interface, information of main and auxiliary reproduction routes, information about connection between appropriate reproduction domains along main route.

SUBSTANCE: type CPI_type is described in PlayList. CPI_type contains type EP_type and type EP_map_type. If position of I-image can be determined, type EP_map_type is utilized, if it can not be determined, type EP_map_type is utilized. Therefore, recorded AV stream data are subject to analysis of I-image and AV data of stream recorded without designation of I-image position may be controlled jointly.

EFFECT: possible joint controlling of AV stream, for which high speed reproduction is possible, and AV stream, for which such a possibility is not available, and also repeated recording is possible.

17 cl, 123 dwg

Description

Technical field

The present invention relates to a method and apparatus for processing information, a program and a recording medium. In particular, it relates to a method and apparatus for processing information, a program and a recording medium for recording a file including information presented for explanation in a GUI (graphical user interface), information of the main playback path, information of the secondary playback path, connection information between the respective playback domains constituting the main playback path, or information about bookmarks or resume points used by the user to set the desired scene.

BACKGROUND OF THE INVENTION

Recently, various types of optical discs that can be removed from a recording device have been proposed as a recording medium. Recordable optical discs have been proposed as a recording medium with a large capacity of several gigabytes, which are designed to record AV (audio-video) signals. Sources (sources of supply) of digital AV signals for recordable optical discs include, for example, digital satellite broadcasting CS (via a communications satellite) and satellite digital broadcasting BS (via a broadcast satellite). For future use, a digital television broadcasting system using terrestrial radio waves has also been proposed.

It should be noted that digital video signals supplied from these sources are usually transmitted in compressed form in accordance with the MPEG-2 standard. For recording devices, the recording speed corresponding to this device is set. If digital video signals obtained from a digital broadcasting system are recorded in accordance with an analog recording system using a conventional video recording medium for home use, the digital video signals are first decoded and then band limited. Alternatively, when using a digital recording system, in particular, an MPEG1 video recording system, an MPEG2 video recording system, or a DV (digital video) system, the digital video signals are first decoded and then re-encoded in accordance with the re-encoding rate and the encoding system corresponding to the recording device.

However, such a recording method, in which the transmitted binary signal stream is first decoded and then bandwidth limited or re-encoded before recording, necessarily leads to a deterioration in image quality. If, when recording compressed digital signals, the transmission speed of the input digital signals does not exceed the recording speed of the recording and / or reproducing device, the method in which the transmitted binary signal stream is directly recorded without decoding or re-encoding leads to a lower degree of image quality deterioration. However, if the transmission speed of the compressed digital signals exceeds the speed of writing to the disc used as the recording medium, it is first necessary to decode the digital signals in the recording and / or reproducing device and re-encode the digital signals for recording so that the transmission speed is not higher than the upper disk write speed limit.

If the signals are transmitted using a variable speed system in which the bit rate of the input binary digital signals increases or decreases over time, the capacity of the recording medium can be used less wastefully when using a disc recording system in which data is first buffered and then recorded in the form of a package, compared with a recording system in which a rotating head has a fixed rotation speed and, therefore, a fixed recording speed.

In the near future, digital broadcasting will become widespread, and it can be assumed that there will be a certain demand for such recording and / or reproducing devices in which the transmitted signals can be recorded as digital signals without decoding or re-encoding, as in the case of a data storage device on magnetic tape and a drive in which a disk is used as a recording medium.

Meanwhile, when recording the AV data stream to the recording medium using the above recording device, an analysis of the AV data stream can be performed to enable fast playback, to determine the position of the I-image and to record with access to the I-image. Alternatively, the AV stream can be recorded directly, without analysis.

In this case, appropriately dedicated application programs are usually used, with which the AV stream was recorded on the recording medium in the form of AV streams of various formats. This led to the need to develop costly application programs, which required considerable time. When recording AV streams using such application programs, a different format is used for different AV streams, which leads to the fact that the corresponding AV streams cannot be played on the same devices due to lack of compatibility.

In addition, a disadvantage of a conventional recording device is that, for example, it is difficult to perform subsequent recording of audio data.

Description of the invention

In this regard, the present invention is directed to a device in which together can be processed AV stream that allows you to record at high speed, and an AV stream that does not allow to record at high speed.

In addition, the present invention is directed to a device in which it is possible to perform subsequent recording.

An information processing device for recording AV stream data on a recording medium includes a controller for generating a first table describing the relationship of the relationship between the presentation timestamp and the address in the AV data of the stream of the corresponding access device, or a second table describing the relationship of the relationship between the time stamp arrival received from the time point of arrival of the transport packet, and the address in the AV data of the stream of the corresponding transport packet, and the device during selected for recording according to the recording method of one of the first table and the second table on the recording medium together with the AV stream data.

The first table may be EP_map, and the second table may be TU_map.

In the case of recording without analysis, the selector may select a second table.

The controller can select the first table in the case of recording with its own encoding.

The controller can select the first table in the case of an analysis record.

The controller may generate identification information indicating which of the first and second tables has been recorded, and the recording device may remember the specified identification information.

The controller controls in such a way that if the first table is recorded together with the AV data of the stream, information specifying the playback domain expresses time information for the playback domain of the AV data of the stream based on the presentation time; and so that if the second table is recorded together with the AV data of the stream, information specifying the playback domain expresses time information for the playback domain of the AV data of the stream based on the arrival time.

The present invention also relates to a method of processing information for recording AV stream data on a recording medium, including a generating step for generating a first table describing the relationship of the relationship between the presentation timestamp and the address in the AV data of the stream of the corresponding access unit, or a second table describing the relationship the relationship between the timestamp received at the time point of arrival of the transport packet, and the address in the AV data stream corresponding trans ortnogo packet recording step for recording selected depending on the method of recording one of the first table and the second table on the recording medium together with the AV stream data.

The present invention also relates to a recording medium on which a computer-readable program is written for an information processing device that records AV data of a stream on a recording medium, in which the program includes a generating step for generating a first table describing a relationship of a relationship between a time stamp presentation and the address in the AV data of the flow of the corresponding access unit, or the second table describing the relationship of the relationship between mended arrival time obtained by the time point of arrival of a transport packet and an address in the AV data stream corresponding transport packet, a recording step for recording the selected depending on the method of recording one of the first table and the second table on the recording medium together with the AV stream data.

The present invention is also directed to a program for having a computer controlling an information processing apparatus recording AV stream data on a recording medium perform a generation step for generating a first table describing a relationship of a relationship between a presentation timestamp and an address in AV data the flow of the corresponding access unit, or a second table describing the relationship of the relationship between the time stamp obtained at the time of arrival t ansportnogo packet and location AV data stream corresponding to the transport packet and including a recording step for recording the selected depending on the method of recording one of the first table and the second table on the recording medium together with the AV stream data.

The present invention also relates to an information processing device for reproducing AV data of a stream from a recording medium, including reproducing means for reproducing one of the first table describing the relationship of the relationship between the presentation time stamp and the address in the AV data of the stream of the corresponding access unit, and the second tables, depending on the relationship of the relationship between the timestamp received at the time point of arrival of the transport packet, and the address in the AV data of the stream of the corresponding transport packet from the recording medium onto which the first table or the second table is recorded, depending on the recording method, and a control unit for controlling the outputted AV data of the stream based on the reproduced table.

The present invention also relates to an information processing method for reproducing AV data of a stream from a recording medium, including a reproducing step for reproducing one of a first table describing a relationship of a relationship between a presentation time stamp and an address in an AV data of a stream of a corresponding access unit, and a second table describing the relationship of the relationship between the timestamp received from the time point of arrival of the transport packet, and the address in AV data stream corresponding to the transport packet from the recording medium onto which the first table or the second table is recorded, depending on the recording method, and a control step for controlling the output of the AV data of the stream based on the reproduced table.

The present invention also relates to a recording medium on which a computer-readable program is recorded for an information processing apparatus recording AV data of a stream on a recording medium, in which the program includes a reproducing step for reproducing one of a first table describing a relationship of a relationship between a time stamp presentation and address of the AV data of the flow of the corresponding access unit, and a second table describing the relationship of the relationship between the mark the arrival time obtained from the arrival time point of the transport packet and the AV data address of the stream of the corresponding transport packet from the recording medium onto which the first table or the second table is recorded, depending on the recording method, and a control step for controlling the outputted AV data of the stream based on reproducible table.

The present invention also relates to a program by which a computer controlling an information processing apparatus that records AV data of a stream on a recording medium performs a reproducing step for reproducing one of a first table describing a relationship of a relationship between a presentation time stamp and an address in AV data stream of the corresponding access unit, and a second table describing the relationship of the relationship between the arrival time stamp obtained at the time point the arrival of the transport packet and the address in the AV data of the stream of the corresponding transport packet from the recording medium onto which the first table or the second table is recorded, depending on the recording method, and a control step for controlling the outputted AV data of the stream based on the reproduced table.

The present invention is also directed to a recording medium onto which a first table describing the relationship of the relationship between the presentation time stamp and the address in the AV data of the flow of the corresponding access unit is recorded, and a second table describing the relationship of the relationship between the arrival time stamp received from the transport packet arrival time point and the addresses in the AV data of the stream of the corresponding transport packet, depending on the recording method.

The present invention is also directed to an information processing apparatus for recording AV stream data on a recording medium, including means for generating reproduction determining information composed of first information defining a main reproduction path and second information defining an auxiliary reproduction path, and a recording means for for recording AV stream data and playback determining information on a recording medium.

The main playback path may be a path for subsequent recording of audio data.

The first information may be the main mainpath, and the second information may be a Sub-path.

The second information may include type information indicative of the type of auxiliary playback information, the name of the AV data file of the stream referenced by the auxiliary playback path, the input and output points of the AV data of the data stream of the auxiliary playback path, and the time on the main path at which the input point of the playback path synchronously starts on the time axis of the main path.

The present invention is also directed to an information processing method for an information processing apparatus recording AV stream data onto a recording medium, including a generation step for generating reproduction determining information consisting of first information indicating the main reproduction path and second information defining an auxiliary playback path reproduced in synchronization with the main playback path, and a recording step for recording AV data eye and information determining the reproduction on the recording medium.

The present invention is also directed to a recording medium on which a computer-readable program is written for an information processing apparatus recording AV data of a stream on a recording medium, in which the program includes a generation step for generating reproduction determining information consisting of first information, indicating the main playback path, and the second information defining the auxiliary playback path, reproduced synchronously with the main m by reproduction, and a recording step for recording AV stream data and information specifying reproduction on the recording medium.

The present invention is also directed to a program by which a computer controlling an information processing apparatus recording AV stream data onto a recording medium performs a generation step for generating reproduction determining information consisting of first information indicating a main reproduction path and a second information defining an auxiliary reproduction path synchronously reproduced with the main reproduction path and a recording step for recording A V stream data and reproduction determining information to the recording medium.

The present invention is also directed to an information processing apparatus for reproducing AV data of a stream from a recording medium including a reproducing means for reproducing from the recording medium information specifying reproduction, consisting of first information indicating a main reproduction path and second information defining an auxiliary playback path that is reproduced in synchronization with the primary playback path, and control means for terminal board AV data stream reproduced on the basis of information specifying the playback.

The present invention also includes a method for processing information for reproducing AV data of a stream from a recording medium, including a reproducing step for reproducing from a recording medium information specifying reproduction, consisting of first information indicating a main reproduction path and second information defining an auxiliary path playback, reproduced synchronously with the main playback path, and a control step for controlling output A V data stream based on reproducible information defining reproduction.

The present invention is also directed to a recording medium on which a computer-readable program is recorded for an information processing apparatus recording AV data of a stream on a recording medium, in which the program includes a reproducing step for reproducing, from the recording medium, information specifying reproduction consisting of the first information indicating the main playback path, and second information defining an auxiliary playback path, reproduced synchronously with the main by reproduction, and a control step for controlling the output of the AV data of the stream based on reproducible information defining reproduction.

The present invention is also directed to a program by which a computer controlling an information processing apparatus recording AV data of a stream on a recording medium performs a reproducing step for reproducing from the recording medium information specifying reproduction consisting of first information indicating the main reproduction path , and second information defining an auxiliary reproduction path reproduced synchronously with the main reproduction path, and a control step, p ednaznachenny for controlling AV output data stream based on playing information defining playing.

A recording medium in accordance with the present invention on which information specifying reproduction is recorded, consisting of first information indicating a main reproduction path and second information defining an auxiliary reproduction path synchronously reproduced with the main reproduction path.

In the apparatus and method for recording and / or reproducing information, the program for the recording medium, the program and the recording medium in accordance with the present invention, depending on the recording method, one of the first table describing the relationship of the relationship between the presentation time stamp and the address is recorded in the AV data of the flow of the corresponding access unit, and the second table describing the relationship between the relationship between the timestamp received from the time point of arrival of the transport packet and the address in the AV data s of the flow of the corresponding transport packet.

In the method and device for processing information, the program for the recording medium and the program in accordance with the present invention are one of the first table describing the relationship of the relationship between the presentation timestamp and the AV address of the data stream of the corresponding access unit, and the second table describing the relationship of the relationship between the time stamp arrival received at the time point of arrival of the transport packet and the address in the AV data of the stream of the corresponding transport packet is reproduced from the recording medium, n and which recorded the first table or second table, depending on the recording method, and the output is controlled accordingly.

In the apparatus and method for processing information, the program for the recording medium program and the second recording medium, in accordance with the present invention, information is recorded defining reproduction, consisting of the first information indicating the main playback path, and the second information indicating the auxiliary playback path reproduced synchronously with the main playback path.

In an apparatus and method for processing information, a program for a recording medium, and a program in accordance with the present invention, information for determining reproduction consisting of first information indicating a primary playback path and second information indicating an auxiliary playback path reproduced is reproduced for corresponding output control synchronously with the main playback path.

Other objectives, features and advantages of the present invention will be more apparent upon consideration of the embodiments of the present invention that are presented in the drawings.

Brief Description of the Drawings

Figure 1 depicts a configuration of one embodiment of a recording and / or reproducing apparatus in accordance with the present invention.

Figure 2 - format of data recorded on a recording medium using the device 1 recording and / or playback.

Figure 3 - Real PlayList and Virtual PlayList.

Figa, 4B and 4C - the creation of Real PlayList.

Figa, 5B and 5C - erasing Real PlayList.

Figa and 6B - editing layout.

7 is a sub-path provision in Virtual PlayList.

Fig - change the playback sequence in the PlayList.

Fig. 9 is a label on a PlayList and a label on a Clip.

Figure 10 - menu minimized to an icon.

11 is a tag added to the PlayList.

12 is a tag added to a Clip.

13 is a relationship between a PlayList, Clip, and an image file minimized to an icon.

Fig - directory structure.

Fig - syntax infr.dvr.

Fig - syntax DVRVolume.

Fig - syntax Resume Volume.

Fig. 18 is a UlAppInfo Volume syntax.

Fig. 19 is a table of values of a character set.

20 is a TableOfPlayList syntax.

Fig. 21 is another TableOfPlayList syntax.

Fig - syntax MakersPrivateData.

Fig. 23 shows the syntax of xxxx.rpls and yyyy.vpls.

Figa - 24C - PlayList.

25 is a PlayList syntax.

Fig - table PlayList_type.

Fig depicts the syntax of UlAppInfoPlayList.

Figa - 28C - flags in the syntax UlAppInfoPlayList depicted in Fig.27.

Fig.29 - Playltem.

Fig.30 - Playltem,

Fig - Playltem.

Fig - syntax Playltem.

Fig - IN-time.

Fig. 34 - OUT-time.

Fig - table Connection_Condition.

Figa - 36D - Connection_Condition.

Fig. 37 shows BridgeSequenceInfo.

Fig. 38 shows the syntax of BridgeSequenceInfo.

Fig. 39 - SubPlayItem.

Fig - syntax SubPlayItem.

Fig - table Mark_type.

Fig - syntax PlayListMark.

Fig - table Mark_type.

Fig.44 - Mark_time_stamp.

Fig - syntax zzzzz.clip.

Fig - syntax ClipInfo.

Fig - table Clip_stream_type.

Fig.48 - offset_SPN.

Fig. 49 - offset_SPN.

Figa, 50B - domain STC.

Fig.51 -STC_tnfo.

Fig - syntax STC_Info.

Fig - Programlnfo.

Fig - syntax Programlnfo.

Fig - syntax VideoCodingInfo.

Fig - table Video_format.

Fig. 57 is a frame_rate table.

Fig. 58 is a display_aspect_ratio table.

Fig. 59 is the syntax of AudioCodingInfo.

Fig. 60 is an audio_coding table.

Fig - table audio_component_type.

Fig - table sampling_frequency.

Fig - CPI.

Fig.64 - CPI.

Fig - CPI syntax.

Fig.66 is a table CPl_type.

Fig - video EP_map.

Fig - EP_map.

Fig - EP_map.

Fig - syntax EP_map.

Fig - table EP_typevalues.

Fig - syntax EP_map_for_one_stream_PID.

Fig - table TU_map.

Fig. 74 is a TU_map syntax.

Fig - syntax ClipMark.

Fig - table Mark_type.

Fig.77 - table Mark_type_stamp.

Fig. 78 is the syntax of menu.thmb and mark.thmb.

Fig. 79 is a view showing a syntax of a thumbnail thumbnail.

Fig. 80 is a thumbnail_picture_format table.

Fig. 81 A and 81B - tn_block.

Fig - the structure of the transport stream of the DVR MPEG2.

Fig - model of the recorder transport stream DVR MPEG2.

84 is a model of an MPEG2 DVR transport stream playback device.

Fig - syntax of the source package.

Fig - syntax TP_extra_header.

Fig - table indicator permission to copy.

Fig - seamless connection.

Fig - seamless connection.

Fig - seamless connection.

Fig - seamless connection.

Fig - seamless connection.

Fig. 93 is an audio overlay.

Fig - seamless connection, which uses BridgeSequence.

95 is a seamless connection that does not use BridgeSequence.

Fig - model DVR STD.

Fig - graph synchronization for decoding and display.

Fig - syntax of the file PlayList.

Fig - syntax UlAppInfoPlayList in the file PlayList in Fig.

Fig - syntax PlayList () in the file PlayList in Fig.

Fig - syntax SubPlayItem.

Fig. 102 is a flowchart for illustrating a method for generating a RealPlayList.

103 is a flowchart for illustrating a method for generating a VirtualPlayList.

Fig. 104 is a flowchart for illustrating a method of reproducing a PlayList.

Fig. 105 is a flowchart for illustrating a method for reproducing a sub-path of a PlayList.

Fig. 106 is a flowchart for illustrating a method for generating a PlayListMark.

107 is a flowchart for illustrating a method for determining a playback location in which PlayListMark is used.

Fig.108 - the media.

BEST MODE FOR CARRYING OUT THE INVENTION

This embodiment of the present invention will be described in detail with reference to the drawings. Figure 1 depicts a typical internal structure of a recording and / or reproducing apparatus 1 in which the present invention is used. First, the structure of the recording unit 2 configured to record signals arriving from the outside will be described. The recording and / or reproducing apparatus 1 is configured in such a way that analog or digital data is supplied and recorded thereto.

Analog video signals and analog audio signals are fed to pins 11, 12, respectively. The video signals arriving at terminal 11 are supplied to the analysis unit 14 and to the AV encoding device 15. The audio signals arriving at terminal 12 are supplied to an analysis unit 14 and an AV encoding device 15. The analysis unit 14 highlights characteristic points, such as scene changes in the input video and audio signals.

The AV encoding device 15 encodes the input video and audio signals so that it outputs to the multiplexer 16 system information (S), such as an encoded video stream (V), an encoded audio stream (A), and an AV synchronization signal.

The encoded video stream is a video stream encoded, for example, using the MPEG2 system, while the encoded audio stream is an audio stream encoded in accordance with the MPEG1 system, wherein the encoded audio stream is, for example, an audio stream encoded, for example, in accordance with the system MPEG1, or audio stream encoded in accordance with the Dolby AC3 system. The multiplexer 16 commutes the input video and audio streams based on the input system information so that it outputs the multiplex stream through the switch 17 to the multiplex stream analysis unit 18 and the source packetizer 19.

A multiplex stream is, for example, an MPEG-2 transport information stream or an MPEG2 program stream. The source packetizer 19 encodes the input multiplex stream into an AV stream consisting of source packets in accordance with the application format of the recording medium 100 onto which this stream is to be recorded. The AV stream is processed in the ECC block 20 (error correction and coding) and modulation blocks 21 with the application of ECC codes and with modulation before it is output to the recording unit 22, which then records the file of the AV stream based on the control signals output by the controller 23.

A transport stream, such as broadcast digital television, input via a digital interface or from a digital television tuner, is fed to terminal 13. There are two recording systems of the transport stream supplied to terminal 13, one of which is a “transparent” recording system, and the other is a system in which recording is preceded by re-coding, designed to reduce, for example, the recording speed of bits. The command information of the recording system is supplied from the output 24 in the form of a user interface to the controller 23.

In a "transparent" recording of the input transport stream, the transport stream supplied to terminal 13 is output through the switch 17 to the multiplex stream analysis unit 18 and to the source packetizer 19. The next processing step when recording the AV stream to the recording medium will be the same as the encoding and recording step of the analog input audio and video signals described above, and therefore it is not explained here to simplify the presentation.

If re-encoding the input transport stream and its subsequent recording, the transport stream supplied to terminal 13 is supplied to a demultiplexer 26, which demultiplexes the input transport stream to isolate the video stream (V), audio stream (A), and system information (S).

From the stream (information) allocated by the demultiplexer 26, the video stream is output to the audio decoder 27, while the audio stream and system information are supplied to the multiplexer 16. The audio decoder 27 decodes the input transport stream to output the encoded video stream (V) to the multiplexer 16.

The audio stream and system information output by the demultiplexer 26 and supplied to the multiplexer 16, and the video stream output by the AV encoding device 15 are multiplexed based on the input system information and output to the multiplex stream analysis unit 18 and to the source packetizer 19 through the switch 17 as a multiplex stream. Further processing of recording the AV stream to the recording medium is performed in the same manner as with respect to the encoding and recording of the analog input audio and video signals described above, and therefore is not explained here to simplify the presentation.

The recording and / or reproducing device 1, in accordance with the present embodiment, records the AV stream file on the recording medium 100, and also records the database information of the application in which the file is recorded. The information supplied to the controller 23 is information about the features of the moving image supplied from the analysis unit 14, information about the features of the AV stream from the multiplexed stream analysis unit 18, and user command information supplied to the output 24.

Information about the features of the moving image coming from the analysis unit 14 is generated by the analysis unit 14 when the AV encoder 15 encodes the video signals. The analysis unit 14 analyzes the content of the video and audio signals supplied to the input to generate information related to the image characteristic of the input signals of the moving image (clip mark). This information is information indicating an image of characteristic clip mark points, such as program start points, scene change points, start and end points of commercial transmission, name or telop (voice mail) in the input video signals, and also includes an image minimized to an icon, and information related to stereo / monaural switching points and muted parts of the audio signals.

The above information indicating the image is supplied through the controller 23 to the multiplexer 16. When multiplexing the encoded image defined as a clip mark using the controller 23, the multiplexer 16 returns information for determining the encoded image in the AV stream to the controller 23. In particular, this information represents PTS (timestamp of presentation) information of the image or address in the AV stream of the encoded version of the image. The controller 23 records the type of image features and information to determine the encoded image in the AV stream in conjunction with each other.

The information about the features of the AV stream from the multiplexed stream analysis unit 18 is information related to the encoding information of the AV stream to be recorded and recorded using the analysis unit 18. For example, the feature information includes time stamp and I-picture address information in the AV stream, break point information of system clocks, encoding parameters of the AV stream, and information of the change point of the encoding parameters in the AV stream. In the "transparent" recording of the transport stream supplied to the input 13, the multiplexed stream analysis unit 18 detects an image of the aforementioned clip mark from the input transport stream and generates information for determining the image indicated by the clip mark and its type.

The information designated by the user coming from input 24 is information identifying the reproduction domain specified by the user, symbols for explaining the contents of the reproduction domain, or information such as bookmarks or continuation points set by the user for his or her preferred scene.

Based on the above input information, the controller 23 creates a base of AV data for the stream (clip), a database of the group (PlayList) of the playback domain (Playltem) of the AV stream, control information of the recorded contents of the recording medium 100 (info.dvr), and information related to the minimized image into the pictogram. Similar to the AV stream, application database information built on the basis of the above information is processed in ECC unit 20 and modulation unit 21 and input to the recording unit 22, which then writes the database file to the recording medium 100.

Next, the above application database information will be described in detail.

When the AV stream file recorded on the recording medium 100 (image data and sound data files) and the application database information recorded thus on the recording medium 100 are reproduced by the reproducing unit 3, the controller 23 first sends a command to the reading unit 28 for reading application database information from the recording medium 100. The reading unit 28 reads the application database information from the recording medium 100 and then reads the application database information from the recording medium 100 in order to send the application database information through demodulation and error correction processing performed by the demodulation unit 29 and ECC decoder 30, to the controller 23.

Based on the application database information, the controller 23 outputs the PlayList playlist recorded on the recording medium 100 to the user interface of the terminal 24. The user selects the PlayList required for playback from the various PlayList lists. Information related to the PlayList, which is indicated as being playable, is provided to the controller 23. The controller 23 issues a command to the read unit 28 to read the file of the AV stream needed to play the PlayList. In accordance with this command, the reading unit 28 reads the corresponding AV stream from the recording medium 100 to output the readable AV stream to the demodulating unit 29. In this case, the demodulated stream supplied to the demodulating unit 29 is demodulated by the preset processing and output through the processing by the ECC decoder 30 to the source depacketizer 31.

The source depacketting device 31 converts the AV stream of the application format, read from the recording medium 100 and processed in a predetermined manner, into the stream processed by the demultiplexer 26. The demultiplexer 26 outputs system information (S), such as a video stream (V), an audio stream (A) or AV synchronization, forming a domain (Playltem) of the reproduction of the AV stream determined by the controller 23 into an audio decoder 27, the AV decoder 27 decodes the video stream and the audio stream to output the reproduced video signal and the reproduced audio signal n connected to it leads 32, 33, respectively.

If information 24 is received from the output 24 through the user interface, which is an instruction for random access playback or special playback, the controller 23 determines the read position of the AV stream from the recording medium 100 based on the contents of the database (clip) of the AV stream for generating a command to the read unit 28 reading the AV stream. If the PlayList selected by the user is to be played back from a predetermined point in time, the controller 23 issues a command to the reading unit 28 to read data from the I-image, the timestamp of which is closest to the specified point in time.

When the user selects a specific clip label from index points or scene change points for a program recorded in ClipMark in ClipInformation, the same as when the user selects a specific image from a list of images collapsed into an icon that are presented in the user interface, index points or points changing the scene recorded in ClipMark, the controller 23 determines the position of the AV read on the recording medium 100 to issue a command to the read unit 28 to read the AV stream. That is, the controller 23 issues a command to the read unit 28 for reading data starting from the I-image, whose address is very close to the address of the AV stream in which the image selected by the user is recorded. The reading unit 28 reads data starting at the specified address. The read data is processed by the demodulating unit 29, the ECC decoder 30, and the source packetizer 19 so that they are supplied to the demultiplexer 26 and decoded by the audio decoder 27 to reproduce the AV data indicated by the label point image address.

If the user gave a fast forward command, the controller 23 issues a command to the read unit 28 to sequentially read the I-image data in the AV stream, sequentially based on the database (clip) of the AV stream.

The reading unit 28 reads the data of the AV stream, starting from the specified random access point. Thus, the read data is reproduced through processing by various components on the side located downstream of the processing.

Next, a case will be described when the user is editing the AV stream recorded on the recording medium 100. If it is necessary to determine the playback domain for the AV stream recorded on the recording medium 100, for example, if you want to create a playback route consisting of playing part of a song performed by singer A from program A of the song, and sequentially playing part of the song of the same singer A from another program B songs, information related to the starting point (IN-point) and end point (OUT-point) of the playback domain, is entered into the controller 23 through the output of the user interface. The controller 23 creates a database of the group (PlayList) of the playback domains (Playltem) of the AV streams.

When the user wants to erase part of the AV stream recorded on the recording medium 100, information related to the input and output points of the IN-point and OUT-point of the erasure domain is input to the controller 23, which then modifies the PlayList database so that only the required ones are accessed AV streams. The controller 23 also generates instructions for the recording unit 22 to erase unnecessary parts of the AV stream.

Next, a case will be described when the user is required to specify the playback domains of the AV stream recorded on the recording medium to create a new playback route and for seamless interconnection of the respective playback domains. In this case, the controller 23 creates a database of the group (PlayList) of the domains (Playltem) of the reproduction of the AV stream and performs partial re-encoding and re-multiplexing of the video stream close to the connection points of the playback domains.

Image information at the input and output points of the IN-point and OUT-point of the playback domain is received from output 24 to the controller 23. The controller 23 issues a command to the read unit 28 to read the data necessary for reproducing the image at the IN-points and OUT-points. The read unit 28 reads data from the recording medium 100. The data read in this way is output through the demodulating unit 29, the ECC decoder 30, and the source packetizer 19 to the demultiplexer 26.

The controller 23 analyzes the data supplied to the demultiplexer 26 to determine the method of re-encoding for the video stream (changing or encoding the picture picture_coding_type and assigning the number of encoding bits for re-encoding) and the re-multiplexing system to send this system to the AV encoding device 15 and to the multiplexer 16.

Demultiplexer 26 then splits the input stream into a video stream (V), an audio stream (A), and system information (S). The video stream can be classified into data input to the audio decoder 27 and data input to the multiplexer 16. The first is the data necessary for re-encoding, and decoded using the audio decoder 27, the decoded image is then re-encoded by the AV encoding device 15 and, thus, it becomes a video stream. The latest data is data copied from the original stream without re-encoding. The audio stream and system information directly go to the multiplexer 16.

The multiplexer 16 multiplexes the input stream based on information transmitted from the controller 23 for outputting the multiplexed stream, which is processed by the ECC unit 20 and the modulation unit 21 so that it is supplied to the recording unit 22. The recording unit 22 records the AV stream of the recording medium 100 based on control signals supplied from the controller 23.

Next, application database information and operations based on this information, such as playback and editing, will be described. Figure 2 shows the structure of the application format having two layers, that is, PlayList and Clip, designed to control the AV stream. Volume Information manages all Clips and Playlists on the disc. Here, one AV stream and its supporting information, composed together, is considered as an object, which is called a clip. The file of the AV stream is called a clip file of the AV stream, while the supporting information is called a clip file of information.

In one clip-file of the AV stream, data corresponding to the MPEG-2 transport information stream is recorded, which is arranged in the form of a structure prescribed by the application format. Being large, this file is treated as a string of bytes. The contents of the AV stream clip file are rotated on a time axis, with clip entry points (I-image), which are mainly selected based on time. When the time stamp of the access point for presetting the clip is set, an information clip file is used to search for address information from which data is read in the clip file of the AV stream.

Next, a playlist (PlayList) will be described with reference to FIG. 3, which is provided to the user to select the desired play domain to be viewed from the Clip, and to directly edit the play domain. One of the PlayList is a set of Clip playback domains. One play domain in a predefined Clip is called a Playltem (play point) and is represented by a pair of IN-points and OUT-points on the time axis. Thus, a PlayList is formed using a set of many Playltem (play points).

A PlayList playlist can be of two types, one of which is a valid Real PlayList playlist and the second is a Virtual PlayList. Real PlayList collectively contains parts of the Clip stream to which it refers. That is, Real PlayList selects on the disk the amount of data corresponding to the part of the Clip stream to which it refers, and when the Real PlayList is erased, the data of the part of the Clip stream to which it refers is also erased.

Virtual PlayList does not contain Clip data. Therefore, if the Virtual PlayList is modified or erased, the contents of the Clip are not changed in any way.

The following explains editing the Real PlayList. FIG. 4A shows the creation of a Real PlayList, and if the AV stream is recorded as a new Clip, a new Real PlayList is also created in which reference is made to the entire Clip.

FIG. 4B shows a division of a Real PlayList, which is an operation of dividing a Real PlayList at a desired point into two Real PlayLists. Such a separation operation is performed when two programs control a single clip controlled by a single PlayList, and when the user needs to re-register or re-record as separate programs. This operation does not change the content of the Clip, that is, to split the Clip itself.

On figs depicts the operation of combining real playlists Real PlayList, which is the operation of combining two Real PlayList into one new Real PlayList. This combination operation is performed when the user needs to re-register two programs as a single program. This operation does not change the content of the Clip, that is, to combine the clips themselves into one clip.

5A depicts the erasure of the entire Real PlayList. If an operation is performed to erase everything previously set by Real PlayList, the associated portion of the Clip stream to which the Real PlayList is erased is also erased.

5B shows a partial erasure of a Real PlayList. If the desired part of the Real PlayList is erased, the interconnected Play Item playback items are changed so that they only reference the necessary part of the Clip stream. The corresponding portion of the Clip stream is erased.

On figs shows the minimization of the real playlist Real PlayList. It is an operation that causes the Playltem playlist associated with the Real PlayList to make reference only to the portion of the Clip stream needed for the Virtual PlayList. The corresponding portion of the Clip stream that is not needed for Virtual PlayList is deleted.

If the real PlayList is changed using the above operation so that the portion of the Clip stream referenced by Real PlayList is erased, there is a possibility that there will be a Virtual PlayList that uses the remote Clip, so Virtual PlayList may occur problems due to the fact that this clip has been deleted.

To prevent this from happening, in response to the user’s delete command, the following message is displayed to the user: "If there is a Virtual PlayList linking to part of the Clip stream referenced by the Real PlayList and the Real PlayList is erased, the Virtual PlayList itself is erased - is this correct ? ", which requires confirmation or is displayed as a warning, after which the erase processing is performed or canceled depending on the user's commands. Alternatively, instead of deleting the virtual playlist Virtual PlayList, the operation of minimizing the real playlist Real PlayList is performed.

Next, operation for the virtual playlist Virtual PlayList will be described. If work is being performed for the Virtual PlayList, the contents of the Clip are not changed. 6A and 6B depict assembly and editing (IN-OUT editing). This is the operation of creating a Playltem play domain that the user wants to browse to create a virtual playlist Virtual PlayList. Seamless connection between Playltems play points is supported by the application format described below.

There are two real lists of PlayList 1, 2 and clips 1, 2 associated with the corresponding Real PlayList, and the user defines the predefined domain in Real PlayList 1 (domain from IN1 to OUT1: Playltem 1) as a playback domain, and also describes it as a domain to be played, the next predefined domain in Real PlayList 2 (domain from IN2 to OUT2: Playltem 2) as a play domain, as shown in FIG. 6A, thereby creating a single Virtual PlayList, which consists of Playltem play points 1 and Playltem2 as shows but on figv.

Re-editing the Virtual PlayList will now be described. Re-editing can be determined by changing the input or output points of the IN-points and OUT-points of the Virtual PlayList, adding or adding new Playltems to the Virtual PlayList, and deleting the Playltems to Virtual PlayList. The Virtual PlayList itself can also be deleted.

Figure 7 presents the audio editing (subsequent recording) of the virtual playlist Virtual PlayList. This operation is the registration of subsequent audio recordings in the PlayList virtual playlist as a sub-path. This subsequent audio recording is supported by the application software. An additional audio stream is added as a sub-path to the AV stream of the main path of the virtual playlist Virtual PlayList.

The operation of changing (moving) a playlist of a PlayList shown in FIG. 8 is common to a real playlist Real PlayList and a virtual playlist Virtual PlayList. This operation is a change in the playlist of a PlayList on a disk (volume) and is supported by a table of a playlist TableOfPlayList, as defined in the application format, as will be described later with reference, for example, to FIG. This operation does not change the contents of the Clip.

Next, the mark will be described. The label is intended to indicate the allocation or characteristic time in the clip and in the playlist PlayList, as shown in Fig.9. The label added to the Clip is called the ClipMark (CM) label. A ClipMark tag is, for example, a program index point or a scene change point to indicate a characteristic scene attributed to the contents of an AV stream. The ClipMark tag is generated, for example, by the analysis unit 14 of FIG. 1. When playing a PlayList, the clip label referenced by the PlayList can be referenced and used.

The label attached to the PlayList is called PlayListMark (playlist label). A PlayListMark tag is, for example, a bookmark position or continuation point set by the user. Labeling for the Clip and for the PlayList is done by adding a timestamp indicating the point of the timestamp in the tag list. Removing a tag, on the other hand, is deleting a timestamp of a tag from the tag list. Therefore, when you set or remove the AV mark, the stream does not change in any way.

As another format for the ClipMark clip, the image referenced by the ClipMark can be determined based on the address in the AV stream. Setting the Clip label is done by adding information to the label list based on the address indicating the image of the label point. A tag deletion, on the other hand, is a deletion of information based on an address pointing to an image of a tag point from a tag list. Therefore, when you set or remove the AV mark, the stream does not change in any way.

Next, an image collapsed into an icon will be described. The thumbnail image is a still image added to that Volume, PlayList, and Clip. There are two types of thumbnails in the form of an icon, one of which is a thumbnail representing the content. It is used mainly in the main image so that the user can select what he or she wants to view using a cursor that is not shown. Another type of thumbnail image is an image pointing to the scene indicated by the mark.

The Volume volume and associated PlayList playlists must have images representing them. Representative images of the Volume are supposed to be used for the initial demonstration of a still image representing the contents of the disc when the disc is in the appropriate position in the recording and / or reproducing apparatus 1. It should be noted that a disc means a recording medium 100, which is assumed to have a disc-shaped shape. The representative image of the PlayList is supposed to be used as a still image to represent the contents of the PlayList.

As the image representing the PlayList playlist, the original PlayList image in the form of a thumbnail image (representing the image) can be considered. However, the initial image for playback time 0 is not necessarily the best image representing the content. Thus, the user can set the additional image as a thumbnail image for the PlayList playlist. Two kinds of thumbnail images, i.e. thumbnail thumbnails representing images representing the Volume volume, and thumbnail images representing the PlayList playlist, are called thumbnail images. Since menu thumbnail images are often displayed, these thumbnail thumbnails must be read from disk at an increased speed. Thus, it is effective to record the entire set of menu images collapsed in the form of an icon in the form of a single file. It is not necessary that the thumbnail images of the menus are images extracted from moving images of a volume, but they can be images input from a personal computer or a digital still camera, as shown in FIG. 10.

On the other hand, a clip and a PlayList playlist must be tagged with a plurality of tags, whereby the image of the tag points must be directly viewed so that the position of the content of the tags can be found. An image denoting such cue points is called a cue image collapsed into an icon. Therefore, the image, which is the original for the label image collapsed into an icon, is basically a highlighted image of the label point, and not an image input from the outside.

Fig. 11 shows the relationship between the tag added to the PlayList and the tag image collapsed into the icon, while Fig. 12 shows the relationship between the tag added to the Clip and the tag image collapsed in the icon. Unlike the thumbnail menu image, the thumbnail thumbnail image is used, for example, in the sub-menu to present the details of the PlayList when it is not necessary to read with a short access time. Thus, whenever a thumbnail image is required, the recording and / or reproducing device 1 opens a file and reads part of this file when some time necessary to open and read part of the file by the recording device 1 and / or playback does not present any problem.

To reduce the number of files presented in the volume, it is preferable that the entire set of tag images collapsed in the form of an icon be recorded in one file. Although a PlayList playlist can contain one thumbnail menu image and many thumbnail thumbnail images, the user does not need to select Clip directly (usually a Clip is selected through the PlayList playlist) and therefore there is no need to create menu images minimized as a pictogram.

13 shows the relationship between thumbnail thumbnails, thumbnail thumbnails, PlayList playlists, and clips. In the thumbnail thumbnail menu image file, thumbnail thumbnails of the menu images provided by various PlayList playlists are recorded. The thumbnail of the menu image file contains an image of the Volume volume, collapsed as an icon, representing the contents of the data recorded on the disc. In the thumbnail menu image file, thumbnail thumbnails created by various PlayList playlists and various clips are recorded.

Next, CPI (Feature Point Information) will be described. CPI is the data contained in the Clip information information file, which is mainly used to find the data address in the file of the AV stream of the clip, from which it is necessary to start reading data when the time stamp of the access point is presented in the clip. In this embodiment, two types of CPI are used, one of which is EP_map and the other is TU_map.

EP_map is a list of entry points (EPs) of data extracted from the elementary stream and the transport information stream. It contains address information used to search for a place or entry point into the AV stream from which decoding is to be started. The EP entry point data alone consists of presentation time stamps (PTS) and data addresses in the AV stream of the access unit associated with the PTS, the data addresses being mapped to a PTS.

The EP_map list is used mainly for two purposes. Firstly, it is used to search for the data address in the AV stream in the access unit represented by the PTS in the PlayList playlist. Secondly, EP_map is used for fast forward or fast reverse. If when recording the input AV stream using the recording and / or reproducing device 1, the syntax of the stream can be analyzed, an EP_map list is created and written to disk.

TU_map contains a list of time unit data (TU), which is obtained based on the time points of arrival of the transport packet arriving through the digital interface. This allows you to create a relationship between time based on the arrival time and the data address in the AV stream. When the recording and / or reproducing apparatus 1 records the input AV stream and the syntax of the stream cannot be analyzed, a TU_map is created and written to the disc.

STCInfo records information about break points in the file of the AV stream, in which the MPEG-2 transport stream is recorded.

When an AV stream contains STC break points, the same PTS values may appear in the AV stream file. Thus, if the time point in the AV stream is determined based on the PTS, the PTS of the access point is insufficient to determine the point. In addition, indexing of the contiguous STC domain containing the PTS is required. In this format, the contiguous STC domain and its index are called the STC-sequence and the STC-sequence-ID, respectively. The STC-sequence information is determined by the STCInfo of the Clip Information file of the clip information.

The STC-sequence-ID is used in the AV stream file and is optional in the AV stream file containing TU_map.

Each of the programs is a set of elementary streams and together contains a single basis of system time for synchronized playback of these streams.

For the playback device (recording and / or reproducing device 1 of FIG. 1), it is important to determine the content of the AV stream before decoding it. This content includes, for example, the PID values of the transport packet of the audio or video stream or the type of video or audio components, such as HDTV (high definition television) video or MPEG-2 AAC audio stream. This information is used to create a menu screen file representing the contents of a PlayList that refers to an AV stream to a user. It is also useful for setting the initial state of the AV decoder and demultiplexer of the corresponding device.

For this reason, the Clip Information file contains information about the Programlnfo program to illustrate the contents of the program.

It may happen that the contents of the program will be changed in the file of the AV stream, in which the MPEG-2 transport stream is recorded. For example, the PID of a transport packet transmitting an elementary video stream may change, or the type of component of the video stream may change from SDTV (standard television) to HDTV (high-definition television).

Program Information Programlnfo records information about the points of change in the program content in the AV stream file. The domain of the AV stream file in which the program content remains constant is called a program sequence.

This program sequence is used in the AV stream file containing EP_map and is optional in the AV stream file in which TU_map is used.

The present embodiment defines a self-coding stream format (SESF). SESF is used to encode analog input signals and to decode digital input signals for subsequent encoding of the decoded signal into the MPEG-2 transport stream.

SESF defines the elementary stream related to the MPEG-2 transport stream and AV stream. When the recording and / or reproducing apparatus 1 encodes and records the input signals in the SESF, an EP_map list is created and written to the disc.

The digital broadcast stream uses one of the following recording systems on the recording medium 100: first, the digital broadcast stream is transcoded to the SESF stream. In this case, the recorded stream must comply with SESF and EP_map must be prepared and written to disk.

Alternatively, the elementary stream forming the digital broadcast stream is transcoded into a new elementary stream and re-multiplexed into a new transport stream according to the stream format prescribed by the organization to standardize the digital broadcast stream. In this case, EP_map must be created and written to disk.

For example, it is assumed that the input stream is an MPEG-2 transport stream corresponding to ISDB (the standard designation for digital satellite broadcasting in Japan), with a transport stream containing an HDTV video stream and an AAC audio stream (with automatic amplitude control). The HDTV video stream is transcoded into an SDTV video stream, wherein the SDTV video stream and the original AAC audio stream are re-multiplexed into a TS (transport stream). Both the SDTV stream and the transport stream must conform to the ISDB format.

Another system for recording a digital broadcast stream to a recording medium 100 is a “transparent” recording of the input transport stream when the input transport stream is recorded unchanged, in which case the EP_map list is generated and written to disk.

Alternatively, a transparent recording of the input transport information stream is performed, that is, the input transport information stream is recorded without changes, a TU_map list is created and written to disk.

Next, the directory and file are explained. The recording and / or reproducing device 1 is described below as a DVR device (digital video recorder). On Fig shows a typical directory structure on the disk. The directories of the DVR may include a root directory including the DVR directory and a DVR directory including the PLAYLIST directory, the CLIPINF directory, the M2TS directory and the DATA directory, as shown in FIG. . Although other directories may be created below the root directory than those indicated above, they are not described in the format of this embodiment.

Below the "DATA" directory are all the files and directories prescribed by the DVR application format. Directory "DVR" includes four directories. Below the PLAYLIST directory are the Real PlayList and Virtual PlayList database files. The last directory may not contain a PlayList file.

Below "CLIPINF" is the Clip database. This directory may also not contain AV stream files. The "DATA" directory contains broadcast information files, such as broadcast digital television.

The following files are recorded in the "DVR" directory. The file "info.dvr", which is created in the DVR directory to record complete information about the application layer. There should be one info.dvr file in the DVR directory. This file name is assumed to be fixed to info.dvr. The file "menu.thmb", which contains information related to the menu images collapsed into an icon. Below the DVR directory there should be 0 or 1 image of the label collapsed in the icon. The file name "menu.thmb" is assumed to be fixed for this file. If there is no image of a menu minimized to an icon, then this file cannot exist.

The file "mark.thmb" contains information related to the tag image collapsed into an icon. Below the DVR directory, there should be 0 or 1 image of the label collapsed into the icon. It is assumed that the file name should be fixed in "menu.thmb". If there is no image of the menu minimized to an icon, this file cannot exist.

The PLAYLIST directory contains two kinds of PlayList files that represent Real PlayList and Virtual PlayList. The file "xxxxx.rpls" contains information related to one Real PlayList. One file is created for each Real PlayList. The file name is "xxxxx.rpls", where "xxxxx" indicates five digits from 0 to 9. The file extension must be "rpls".

The file "yyyyy.vpls" contains information related to one Virtual PlayList. For each Virtual PlayList, one file is created with the name "yyyyy.vpls", where "uuuuu" stands for five digits from 0 to 9. The file extension must be "vpls".

The "CLIPINF" directory contains files, each of which is associated with each file of the AV stream. The file "zzzzz.clpi" is a clip information file of the Clip Information corresponding to one file of the AV stream (the clip file of the AV stream or the file of the Bridge-Clip stream). In the name "zzzzz.clpi" of the file, "zzzzz" means five digits from 0 to 9. The file extension must be "clpi".

The "M2TS" directory contains an AV stream file. The file "zzzzz.m2ts" is an AV stream file processed by the DRV system. It is an AV stream clip file or a Bridgy-Clip AV stream file. The file name is "zzzzz.rn2ts", where "zzzzz" stands for five digits from 0 to 9. The file extension should be "m2ts".

The "DATA" directory contains data transmitted via the data broadcasting system. This data may be, for example, XML or MPEG files.

Next, the syntax and semantics of each directory (file) will be described. On Fig depicted the syntax of the file "info.dvr". The "info.dvr" file consists of three objects, that is, DVRVolume (), TableOfPlayLists () and MakersPrivateData ().

We describe the syntax of the info.dvr file shown in FIG. TableOfPlayLists_Start_address indicates the starting address of the table of the playlist TableOfPlayLists () as the relative number of bytes from the starting byte of the file "info.dvr". The relative number of bytes is counted starting at 0.

MakersPrivateData_Start_address indicates the starting address of the manufacturer’s private data MakersPrivateData () as the relative number of bytes from the starting byte of the info.dvr file. The relative number of bytes is counted from 0. The padding_word is inserted in conjunction with the syntax "info.dvr". N1 and N2 are positive integers used if necessary. Each padding word (padding_word) can take any value.

The DVRVolume () contains information indicating the contents of the volume (disk). On Fig depicts the syntax of the DVRVolume. Next, the syntax of the DVR Volume () depicted in FIG. 16 will be described. Version number Version_number is four characters indicating the version number of DVRVolume (). The version number version_number is encoded as "0045" in accordance with the ISO646 standard.

The length is indicated by a 32-bit unsigned integer indicating the number of bytes immediately after the length field to the end of DVRVolume ().

ResumeVolume () contains the names of the Real PlayList or Virtual PlayList file that were last played in the Volume volume. However, the playback position when the user interrupted the playback of Real PlayList or Virtual PlayList is recorded in the resume mark defined in PlayListMark () (see FIGS. 42 and 43).

17 shows the syntax of ResumeVolume (). We describe the syntax of ResumeVolume () shown in FIG. The Valid_flag flag indicates that the resume_PlayList_name field is valid or invalid when this one-bit flag is set to 1 or 0, respectively.

The 10-byte resume_PlayList_name field indicates the name of the Real PlayList or Virtual PlayList file to be renewed.

In UlAppInfoVolume, in the syntax of DVRVolume () shown in Fig. 16, the user interface application parameters related to that Volume are recorded. On Fig depicts the syntax of UlAppInfoVolume, the semantics of which will now be lower. The 8-bit character_set field specifies how to encode characters encoded in the Volume_name volume name field. The encoding method corresponds to the values shown in Fig.19.

The 8-bit name_length field indicates the length in bytes of the name of the Volume, which is represented in the Volume_name field. The Volume_name field indicates the designation of the Volume. The number of bytes, indicated by the number contained in the name_length field, counted to the left of this field, is the number of valid characters and indicates the volume designation. Values immediately following these valid characters may be arbitrary values.

The Volume_protect_flag volume protection flag is a flag indicating whether the contents of the Volume volume can be provided to the user without restriction. If this flag is set to 1, the contents of Volume are allowed to be provided to the user only if the user entered the PIN code (password) correctly. If this flag is set to 0, the contents of Volume are allowed to be provided to the user even if the user has not entered a PIN code.

If the user installed the disc on the playback device, and this flag was set to 0, or the flag was set to 1, but the user entered the PIN code correctly, the recording and / or playback device 1 shows the PlayList for this disk. At the same time, restrictions on the playback of the corresponding PlayList are independent of the value of Volume_protect_flag and are represented by the playback control flag playback_control_flag, which is defined in the UlAppInfo of the Volume volume.

The PIN code consists of four digits from 0 to 9, each of which is encoded in accordance with ISO / IEC 646. The ref_thumbnail_index field indicates information about the image collapsed into an icon added to that. If the ref_thumbnail_index field is a value other than OxFFFF, the thumbnail is added to the Volume. The thumbnail image is written to the menu.thumb file. This image is referenced using the value of ref_thumbnail_index in the menu.thumb file. If 0xFFFF is written in the ref_thumbnail_index field, this indicates that the thumbnail image has been added to the Volume volume.

Next, the table of the playlist TableOfPlayList () in the syntax info.dvr shown in Fig. 15 will be described. The name of the PlayList file (Real PlayList and Virtual PlayList) is recorded in TableOfPlayList (). All PlayList playlist files recorded in the Volume volume are contained in TableOfPlayList (), with TableOfPlayList () indicating the playback sequence of the default PlayList value for this in Volume.

20 depicts the syntax of TableOfPlayList (), which will be described later. The Version_number version number of the TableOfPlayList () table contains four characters indicating the version number of the TableOfPlayList. The version number version_number shall be encoded as "0045" in accordance with ISO 646.

The length is a 32-bit unsigned integer indicating the number of bytes of TableOfPlayList () immediately after the left margin to the end of TableOfPlayList (). The 16-bit number_of_PlayList field indicates the number of loops including the name of the playlist file PlayList_file_name. This number must be equal to the number of PlayList recorded in the Volume. The 10-byte number PlayList_file_name indicates the name of the PlayList file.

21 shows another syntax configuration for TableOfPlayList (). The syntax depicted in FIG. 21 contains the syntax shown in FIG. 20, which contains a UlAppInfoPlayList. Thanks to this structure, including the UlAppInfoPlayList, it becomes possible to create a menu image simply by reading TableOflPlayLists. In the following description, the syntax depicted in FIG. 20 is assumed to be used.

Next, the MakersPrivateData contained in the info.dvr file shown in FIG. 15 will be described. MakersPrivateData (manufacturer’s private data) is provided so that the manufacturer of the recording and / or reproducing apparatus 1 has the ability to enter the manufacturer’s private data into MakersPrivateData () for special applications of various companies. Each manufacturer’s private data has a standardized manufacturer identifier, maker_ID, to identify the manufacturer who identified them. MakersPrivateData () may contain one or more maker_IDs.

If MakersPrivateData () already contains the private data of any manufacturer, and for the pre-installed manufacturer you need to enter private data, these new private data is added to MakersPrivateData (), without erasing the previously existing private data. Thus, in this embodiment, in one MakersPrivateData (), private data from multiple manufacturers may be contained.

22 shows the syntax of MakersPrivateData. Next, the syntax of the MakersPrivateData depicted in FIG. 22 will be described. The version number version_number of the table of the playlist TableOfPlayList () contains four characters indicating the version number of TableOfPlayLists. The version number version_number must be encoded as "0045" in accordance with ISO 646. The Length is an unsigned 32-bit integer indicating the number of bits of TableOfPlayList () immediately after the length field to the end of MakersPrivateData ().

Mpd_blocks_start_address indicates the start address of the first mpd_block () as the relative number of bytes from the starting byte of MakersPrivateData (). Number_of_maker_entries is a 16-bit unencoded integer representing the number of entries in the manufacturer’s private data included in MakersPrivateData (). MakersPrivateData () should not contain two or more private data producers that have the same maker_ID manufacturer identifier value.

Mpd_blocks_size is a 16-bit unsigned integer representing the size of one block of private data from the mpd_block manufacturer in the form of 1024 byte blocks. For example, if mpd_block_size is 1, this indicates that the size of one mpd_block is 1024 bytes. Number_of_mpd_blocks is an unsigned 16-bit integer that represents the number of mpd_block blocks contained in MakersPrivateData (). Manufacturer's identifier Maker_ID is a 16-bit unsigned integer that indicates the model number code of the DVR system by which the manufacturer’s private data was generated. The value encoded in the maker_ID is indicated by the licensee.

Manufacturer Model Code maker_model_code is a 16-bit unsigned integer indicating the model number code of the DVR system that was created by the manufacturer’s private data. The value encoded in maker_model_code is set by the manufacturer who accepted the format license. Start_mpd_block_number (the start number of the manufacturer’s private information block) is an unsigned 16-bit integer indicating the mpd_block number from which the manufacturer’s private data begins. The start of the manufacturer’s private data should be combined with the start of mpd_block. Start_mpd_block_number corresponds to the j variable in mpd_block with loops.

Mpd_length (manufacturer private data length) is an unsigned 32-bit integer indicating the size of the manufacturer’s private data. Mpd_block is an area in which the manufacturer’s private data is recorded. All mpd_blocks in MakersPrivateData () must be the same size.

Explained below is the Real PlayList file and the Virtual PlayList file, in other words, xxxxx.rpls and yyyyy.vpls. 23 shows the syntax xxxxx.rpls (Real PlayList) and yyyyy.vpls (Virtual PlayList), which have the same structure. Each of the files xxxxx.rpls and yyyyy.vpls consists of three objects, that is, from PlayList (), PlayListMark () and MakersPrivateData ().

PlayListMark_Start_address indicates the starting address of PlayListMark () as the relative number of bytes from the beginning of the PlayList file. The relative number of bytes is counted from zero.

MakersPrivateData_Start_address indicates the starting address of MakersPrivateData (), as the relative number of bytes from the leading end of the PlayList file. The relative number of bytes is counted from zero.

The padding_word (fill word) is entered according to the syntax of the PlayList file so that N1 and N2 are arbitrary positive integers. Each filling word can take on any meaning.

A PlayList will be described below, although it has been briefly described above. All PlayList playlists on the disc must reference the play domain in all Clip videos, with the exception of Bridge-Clip. In addition, two or more Real PlayLists should not result in overlapping play domains that are represented by their Playltems play points on the same clip.

Consider FIG. 24A, 24V and 24C. For all Clip, there are corresponding Real PlayLists, as shown in FIG. 24A. This rule is respected even after the editing operation is completed, as shown in FIG. 24B. Therefore, all clips should be viewed with reference to one of the real playlists of Real PlayLists.

As shown in FIG. 24C, a virtual playlist virtual domain playlist Virtual PlayList must be contained in the play domain and the play domain Bridge-Clip. There should be no Bridge-Clip on the disk that is not referenced by any of the Virtual PlayList virtual playlists.

A Real PlayList containing a list of Playltem playlists should not contain SubPlayItem sub-playlists. The PlayList virtual playlist contains a list of Playltem playlists and, if the CPI_type type contained in PlayList () is EP_map and PlayList_type is 0 (PlayList playlist containing video and audio information). Virtual PlayList can contain one sub-play item SubPlayItem. In PlayList (), in accordance with this embodiment, SubPlayItem is used only for subsequent recording of audio information. The number of SubPlayItems owned by one Virtual PlayList must be 0 or 1.

Next, a PlayList playlist will be described. On Fig depicts the syntax of the PlayList, which is explained below. The version number version_number contains four characters indicating the version number of the PlayList () playlist. Version_number is encoded as "0045" in accordance with ISO 646. The length length is an unsigned 32-bit integer indicating the total number of bytes of the PlayList () playlist, directly from the length field to the end of PlayList (). The type of the playlist PlayList_type, one example of which is shown in FIG. 26, is an 8-bit field indicating the type of the playlist PlayList.

CPl_type is a one-bit flag indicating the value of the CPI_type of the clip referenced from PlayItem () and SubPlayItem (). Nbgs CPI_types defined in the CPI of all clips referenced from the same PlayList playlist must have the same values. Number of play points number_of_Playltems, is a 16-bit field indicating the number of Playltem play points presented in the PlayList.

The identifier of the playitem Playltem_id corresponding to a predetermined PlayItem () is determined by the sequence in which PlayItem () appears in the PlayItem () containing the loop. Playltem_id starts at 0. The number of playback sub-items number_of_SubPlayItems is a 16-bit field indicating the number of SubPlayItem in the PlayList playlist. This value is 0 or 1. The optional audio stream path is a sub-path view.

Next will be described UlAppInfoPlayList syntax of the playlist PlayList depicted in Fig.25. UlAppInfoPlayList contains UI application parameters related to the PlayList playlist. On Fig depicts the syntax of UlAppInfoPlayList, which will be described later. The character_set field is an 8-bit field that indicates how characters are encoded in the PlayList_name playlist name field. The encoding method corresponds to the values presented in the table shown in Fig.19.

The length of the name name_length is an 8-bit field indicating the length in bytes of the name of the PlayList playlist, which is listed in the PlayList_name field. The PlayList_name field represents the designation of the PlayList playlist. The number of bytes of a number indicating the length of the name name_length, counted to the left of this field, is the number of valid characters and indicates the name of the PlayList. The values following these valid characters may be any value.

Record time and date record_time_and_date is a 56-bit field that records the date and time of the recording of the PlayList. This field is 14 digits for the year / month / day / hour / minute / second encoded as binary decimal numbers (BCD). For example, 2001/12/23: 01: 02: 03 is encoded as "0x20011223010203".

The duration is a 24-bit field indicating the total playing time of the PlayList in a clock / minute / second format as a single unit. This field is six digits encoded as binary decimal numbers (BCD). For example, 01:45:30 is encoded as "0 × 014530".

The valid period valid_period is a 32-bit field indicating the valid time periods of the PlayList. This field contains 8 digits encoded as 4-bit binary decimal digits (BCD). The valid valid_period period is used in the recording and / or reproducing apparatus 1, for example, when a PlayList for which a valid period has expired should be automatically deleted. For example, 2001/05/07 is encoded as "0 × 20010507".

The manufacturer indicator maker_ID is an unsigned 16-bit integer indicating the manufacturer of the DVR playback device (recording and / or reproducing device 1) on which the PlayList playlist was last updated. The value encoded as the maker_ID is assigned to the license holder in DVR format. The maker_code is a 16-bit unsigned integer indicating the model number of the DVR playback device on which the PlayList was last updated. The value encoded in the maker_code manufacturer code is determined by the manufacturer who accepted the license in DVR format. If the playback control flag playback_control_flag is set to 1, its playlist PlayList is played back only when the user successfully enters the PIN code. If this flag is set to 0, the user can view the PlayList playlist without having to enter a PIN code.

If the write_protect_flag write protection flag is set to 1, deleting or changing the contents of the PlayList is prohibited, except write_protect_flag. If this flag is set to 0, the user can freely erase or modify the playlist PlayList. If this flag is set to 1, the recording and / or reproducing apparatus 1 displays a message requesting re-confirmation by the user before the user is allowed to erase, edit or overwrite the PlayList.

There may be a real Real PlayList in which the write_protect_flag write protection flag is set to 0, there may be a Virtual PlayList virtual playlist that refers to Clip in the Real PlayList, and the write_protect_flag Virtual PlayList write protection flag can be set to 1. If the user wants to erase the Real PlayList, the recording and / or reproducing device 1 generates a warning to the user due to the presence of the above Virtual PlayList or “minimizes” the Real PlayList before the Real PlayList is erased.

If the is_played_flag flag is set to 1, as shown in FIG. 28B, this indicates that the PlayList has been played at least once since it was recorded, and when it is set to 0, it indicates that PlayList playlist has never been played since it was recorded.

The archive field is a two-bit field indicating whether the PlayList is an original or a copy, as shown in FIG. 28C. The ref_thumbnail_index field indicates image information collapsed to an icon representing a PlayList. If the ref_thumbnail_index field has a value other than 0xFFFF, the thumbnail image representing the playlist PlayList is added to the PlayList, and this PlayList is recorded in the menu.thmb file. The image is referenced using the value of ref_thumbnail_index in the menu.thmb file. If the ref_thumbnail_index field contains 0xFFFF, this means that a thumbnail image representing the PlayList has been added to the PlayList playlist.

The Playltem play point is explained below. One PlayItem () basically contains the following data: Clip_Information_file_name, intended to indicate the name of the clip file, entry time and exit time IN-time and OUT-time, connected together to indicate the playback domain of the Clip, the sequence identifier stc_sequence_id referenced entry time and exit time IN-time and OUT-time if CPI_type defined in PlayList () is an EP_map type, and the connection condition Connection_Condition indicates the connection status of the previous Playltem and the current Playltem.

If a PlayList consists of two or more Playltem playlists, these Playltems are arranged in a series, without time intervals or overlapping, on the global time axis of the PlayList. If the CPI_type type defined in the PlayList playlist is EP_map and the current PlayList does not contain BridgeSequence (), the IN-time and OUT-time pair of entry and exit times should indicate the same time on the continuous STC domain, which defined by the sequence identifier STC_sequence_id. Such a case is shown in FIG.

FIG. 30 shows a case in which the CPI_type type defined by the PlayList () and when the current Playltem contains BridgeSequence (), for which the rules described below apply. The entry point time of the playhead before the current playltem, shown as IN_time1, indicates the Bridge-Clip time defined in BridgeSequenceInfo () of the current playltem. In this case, the output time OUT_time must comply with the encoding restrictions, which will be described later.

The IN_time entry time of the current Playltem playhead, represented as IN_time2, indicates the time in Bridge-Clip defined in BridgeSequenceInfo () of the current Playltem. This IN_time must also comply with the encoding restrictions described below. The exit time OUT_time of the Playltem of the current Playltem, depicted as OUT_time2, indicates the time of the continuous STC domain defined by the sequence identifier STC_sequence_id of the current Playltem.

If the CPI_type PlayList () is of type TU_map, the input and output times IN_time and OUT-time of the Playltem playhead paired together indicate the time of the same clip AV stream, as shown in FIG.

The syntax of the Playltem playback point is depicted in FIG. Regarding the syntax of the Playltem depicted in FIG. 32, the Clip_information_file_name field indicates the name of the clip information file. The type of clip stream Clip_stream_type defined by ClipInfo () of this clip information file of the Clip Information should indicate the AV stream of the clip.

The STC_sequence_id sequence identifier is an 8-bit field and indicates the STC_sequence_id of the continuous STC domain referenced by the Playltem play point. If the CPI_type type defined in PlayList () is TU_map, this 8-bit field has no value and is set to 0. Input time IN_time is a 32-bit field and is used to record the start time of the playback of the Playltem. The semantics of the IN_time entry time are different from the CPI_type type defined in the PlayList () playlist, as shown in FIG.

The exit time OUT_time is a 32-bit field and is used for the end time of a Playltem play item. The semantics of the OUT_time output time is different from the CPI_type type defined in PlayList (), as shown in FIG. 34.

The connection condition connection_condition is a 2-bit field indicating the connection condition between the previous Playltem and the current Playltem, as shown in FIG. 35. FIG. 36A through 36D depict various Connection_condition states depicted in FIG. 35.

BridgeSequenceInfo is explained with reference to Fig.37. BridgeSequenceInfo is supporting information for the current Playltem play point and includes the following information. That is, BridgeSequenceInfo includes the file name Bridge_Clip_Information_fiIe_name, which is used to determine the AV file Bridge_Clip, and Bridge_Clip_Information_file_name, which define the corresponding clip information file Clip Information (Fig. 45).

The previous Playltem playback point also refers to the packet address of the source of the AV stream of the clip. Behind this source packet, the first packet source of the Bridge-Clip AV stream is included. This address is called RSPN_exit_from_previous_Clip (RSPN output from the previous clip). It also represents the address of the source package of the AV stream of the clip, which is referenced by the current Playltem playback point. Before this source package, the last source package of the Bridge_ AV stream of the Bridge_clip file is connected. This address is called RSPN_enter_to_current_Clip (RSPN entry in the current clip).

On Fig RSPN_arrival_time_discontinuity (time gap arrival RSPN) indicates the address of the source packet in the AV stream Bridge_Clip, which contains the break point in the basis of time of arrival. This address is defined in ClipInfo () (Fig. 46).

On Fig depicts the syntax of BridgeSequenceInfo. As can be seen from the syntax of BridgeSequenceInfo shown in Fig. 38, the Bridge_Clip_Information_file_name field indicates the name of the Clip Information clip information file corresponding to the Bridge_Clip_Information_file file. The stream type Clip_stream_type defined in ClipInfo () of this clip information file should indicate "Bridge_Clip AV stream".

The 32-bit RSPN field of the output from the previous clip RSPN_exit_from_previous_Clip is the relative address of the source packet of the AV stream of the clip, which is referenced by the previous Playltem. Behind this source package, the first source package of the Bridge_Clip AV stream file is connected. RSPN_exit_from_previous_Clip has a size based on the source package number as a block, and is calculated with the offset_SPN offset value defined in ClipInfo () from the first source package of the AV stream file of the clip that is referenced by the previous Playltem playback point.

The 32-bit RSPN_enter_to_curent_Clip field (RSPN input into the current clip) represents the relative address of the source packet of the AV stream of the clip, which is referenced by the current Playltem playback point. Before this source package, the last source package of the Bridge_Clip AV stream file is attached. RSPN_enter_to_curent_Clip has a size that is based on the source packet number in the form of a block. RSPN_enter_to_curent_Clip is calculated with the offset_SPN offset value specified in ClipInfo () from the first packet of the file source of the AV stream of the clip referenced by the current Playltem playback point as the initial value.

The subplay item SubPlayItem is explained with reference to Fig. 39. The use of SubPlayItem () is permitted only if the CPI_type type of the playlist PlayList () is an EP_map type. In the present embodiment, SubPlayItem is used only for subsequent recording of audio data. SubPlayItem () includes the following data. First, it includes Clip_Information_file_name (the name of the clip information file), which is used to identify the clip that is referenced using the sub-path in the PlayList playlist.

It also contains the subPath_IN_time sub-path entry time and the SubPath_OUT_time sub-path exit time, which are used to determine the playback domain of the sub-path in the clip. In addition, it contains the identifier sync_PlayItem_id and start_PTS_of_PlayItem, designed to indicate the start time of the playback sub-path on the time axis of the main path. The AV stream of the clip referenced via the sub-path should not contain STC break points (break points of the base system time). The clip audio sample synchronization signals used in the sub-path are synchronized with the main sample audio sample synchronization signals.

On Fig depicts the syntax of the sub-path SubPlayItem. When considering the syntax of the SubPlayItem shown in FIG. 40, it can be seen that the Clip_Information_file_name field (name of the clip information file) indicates the name of the clip information file and is used for the sub-path in the PlayList. The type of clip stream Clip_ stream_type defined in this ClipInfo () should point to the AV stream of the clip.

The 8-bit sync_PlayItem_id identifier field indicates the type of path to the subpath. Here, only '0x00' is set, as shown in FIG. 41, while other values are reserved for future use.

The 8-bit sync_PlayItem_id identifier field indicates the identifier of the Playltem_id playitem for Playltem containing the start of the sub-path playing time on the time axis of the main path. The value of the identifier of the playitem Playltem_id corresponding to the predetermined playitem Playltem is defined in the playlist PlayList () (Fig.25).

The 32-bit sync_start_PTS_of_PlayItem field indicates the start time of the subpath playback on the time axis of the main path and the upper 32 bits of the PTS (presentation time stamp) of the Playltem playback point referenced by sync_PlayItem_id. The field of the upper 32-bit input time of the sub-path SubPath_IN_time contains the start time of the sub-path playback. SubPath_IN_time sub-path entry time defines the top 32 PTS bits of 33 bits corresponding to the first sub-path submission block.

The field of the upper 32 bits of the subPath_OUT_time sub-path exit time contains the sub-path playback end time. SubPath_OUT_time indicates the upper 32 bits of the end value of the Presentation_end_TS view, which are calculated using the following equation:

Presentation_end_TS = PTS_OUT + AU_duration,

where PTS_out is a 33-bit PTS corresponding to the last subPath subpath path presentation unit, and AU_duration duration is a 90 kHz display period of the last subPath sub path submission path block.

Next, the label of the playlist PlayListMark () in the syntax xxxxx.rpls and yyyyy.vpls, which are shown in Fig.23. Label information related to the PlayList playlist is recorded in that label of the PlayListMark playlist. On Fig depicts the syntax of the PlayListMark. As can be seen from the syntax of the PlayListMark depicted in FIG. 42, the version number version_number is four characters indicating the version number of this label of the playlist PlayListMark (). The version number version_number must be encoded so that its value is "0045" in accordance with ISO 646.

The length is a 32-bit unsigned integer indicating the number of bytes of the label of the playlist PlayListMark () immediately after the length field to the end of the label of the playlist PlayListMark (). Number of playlist marks number_of_PlayListMark is a 16-bit unsigned integer indicating the number of marks recorded in PlayListMark. Number_of_PlayListMark may be zero. The mark type mark_type is an 8-bit field indicating the type of mark, and is encoded in the table shown in FIG. 43.

In the 32-bit field of the mark_time_stamp timestamp, a timestamp is written indicating the point defined by the timestamp. The semantics of mark_time_stamp is different from the CPI_type defined in PlayList (), as shown in FIG. The Playltem_id item ID is an 8-bit field that identifies the Playltem play item in which the label is entered. The values of the Playltem_id identifier corresponding to the predefined Playltem play item are defined in the PlayList () play list (see FIG. 25).

The 8-bit character set field character_set represents a way to encode characters encoded in the mark_name field (label name). The encoding method corresponds to the values shown in Fig.19. The 8-bit name length field name_length indicates the length in bytes of the label name represented in the label name field mark_name. The mark_name field indicates the label name specified in the mark_name field. The number of bytes corresponding to the number name_length to the left of this field are valid characters and indicate the name of the label. In the mark_name field, the value following these valid characters may be arbitrary.

The index link field of the thumbnail image, ref_thumbnail_index, indicates information of the thumbnail thumbnail that is added to the label. If the ref_thumbnail_index field does not contain 0xFFFF, the image minimized to the icon is added to its label, and the image minimized to the icon is written to the mark.thmb file. This image is referenced in the mark.thmb file using the value of ref_thumbnail_index, as described below. If the ref_thumbnail_index field contains 0xFFFF, this indicates that no thumbnail image has been added to the label.

The following describes the clip information file Clip Information, zzzzz.clpi (file Clip Information) consists of six objects, as shown in Fig.45. They are ClipInfo (), STCInfo (), Program (), CPI (), ClipMark () and MakersPrivateData (). For the AV stream (clip of the AV stream of the clip or the AV stream of Bridg-Clip) and the corresponding Clip Information file, the same sequence of digits "zzzzz" is used.

Consider the syntax of the zzzzz.clpi file (Clip Information file), which is shown in FIG. The start address of ClipInfo_Start_address indicates the start address of ClipInfo () with the relative number of bytes from the beginning of the byte of the zzzzz.clpi file, which is used as a block. The relative number of bytes is counted from zero.

STC_Info_Start_address indicates the start address of STC_Info with the relative number of bytes from the start byte of the zzzzz.clpi file as a block. ProgramInfo_Start_address indicates the start address of ProgramInfo () with the relative number of bytes from the start byte of the zzzzz.clpi file as a block. The relative number of bytes is counted from 0, CPI_Start_address indicates the start address of CPI () with the relative number of bytes from the starting byte of the zzzzz.clpi file as a block. The relative number of bytes is counted from zero.

The start address of ClipMark_Start_address indicates the start address of ClipMark () with the relative number of bytes from the start byte of the zzzzz.clpi file as a block. The relative number of bytes is counted from zero. The start address of the manufacturer's private data The_MakersPrivateData Start_address indicates the start address of the manufacturer's private data MakersPrivateData () with a relative number of bytes from the start byte of the leading end of the zzzzz.clpi file as a block. The relative number of bytes is counted from zero. The padding_word filling word is inserted according to the syntax of the zzzzz.clpi file. N1, N2, N3, N4 and N5 must be equal to zero or, possibly, can be positive integers. Corresponding fill words can also take arbitrary meanings.

Next, ClipInfo will be described. On Fig depicted the syntax of ClipInfo. ClipInfo () records the attribute information of the corresponding AV stream files (clip AV stream file and Bridge-Clip AV stream file).

As shown in FIG. 46, which depicts ClipInfo syntax, the version_number version number is four characters indicating the version number of this ClipInfo (). Version_number must be encoded as “0045” in accordance with ISO 646. The length length is an unsigned 32-bit integer indicating the number of bytes of ClipInfo () directly from the end of the length field to the end of ClipInfo (). The 8-bit clip stream type field Clip_stream_type indicates the type of AV stream corresponding to the Information Clip file, as shown in FIG. The types of respective AV streams will be described below.

The 32-bit offset_SPN offset field sets the source packet number offset value for the first source packet number of the first source packet of the AV stream (AV stream clip or AV stream Bridge-Clip). When the AV stream file is the first file written to disk, the offset_SPN value should be zero.

As shown in FIG. 48, when the initial part of the AV stream file is deleted during editing, offset_SPN may take a value other than 0. In this embodiment, the relative source packet number (relative address) that refers to offset_SPN is often described in the form RSPNxxx, where xxx is modified so that RSPN_xxx is RAPN_EP_start. The relative source packet number is made commensurate with the source packet number as a block and is counted from the first source packet number of the AV stream file with an initial offset value of offset_SPN.

The number of source packets from the first source packet of the AV stream file to the source packet referenced by the relative source packet number (SPN_xxx) is calculated by the following equation:

SPN_xxx = RSPN_xxx - offset_SPN.

On Fig depicted the case when the offset offset_SPN is equal to 4.

Timestamp Write Speed TS_recording_rate is an unsigned 24-bit integer that represents the bit rate of the input / output bits required for an AV stream for a DRV drive (write unit 22) or a DRV drive (read unit 28). Record time and date record_time_and_date is a 56-bit field designed to record the recording date and time of the AV stream corresponding to Clip, and is an encoded representation of the year / month / day / hour / minute in the form of 4-bit binary decimal numbers (BCD ), which represent 14 digits. For example, 2001/2/23: 01: 02: 03 is encoded as "0x20011223010203".

Duration is a 24-bit field indicating the total playing time of the clip using hours / minutes / seconds based on the arrival time clock. This field contains six digits encoded as 4-bit binary decimal numbers (BCD). For example, 01:45:30 is encoded as "0 × 014530".

The time_controlled_flag flag indicates the recording mode of the AV stream file. If this flag time_controlled_flag is 1, this indicates that a recording mode is selected in which the file size is proportional to the time elapsed since the recording started, so this state is represented by the following equation:

Ts_average_rate * 192/188 * (t-start_time) - α <= size_clip (t)

<= TS_average_rate * 192/188 * (t - startJime) + α,

where TS_average_rate is the average bit rate of the transport stream of the AV stream file, expressed in bytes / second.

In the above equation, t represents the time in seconds, while the start_time is the time point when the first packet of the source file of the AV stream was recorded. Size_clip (t) is 10 * 192 bytes, and α is a constant depending on TS_average_rate.

If the time_controlled_flag flag is set to 0, this indicates that the recording mode is not controlled so that the recording time is proportional to the file size of the AV stream. For example, the input transport stream is recorded in a "transparent" way.

If the time_controlled_flag flag is set to 1, the 24-bit TS_average_rate average timestamp field indicates the TS_average_rate value used in the above equation. If time_controlled_flag is set to 0, this field has no value and should be set to 0. For example, a transport stream with a variable bit rate is encoded using the following sequence: first, the transport stream is set to the recording speed TS_recording_rate timestamp. The video stream is encoded at a variable bit rate. A transport packet is periodically encoded without the use of null packets.

The 32-bit RSPN_amval_time_discontinuity field is the relative address of the place at which gaps are made based on the arrival time of the Bridge-Clip AV stream file. RSPN_arrival_time_discontinuity is commensurate with the source packet number of the block as a block and is calculated with the offset_SPN value defined in ClipInfo (), as from the first packet source of the Bridge-Clip AV stream file. The absolute address in the AV Clip file of the Bridge-Clip stream is calculated based on the above equation:

SPN_xxx = RSPN_xxx - offset_SPN.

The 144-bit reserver_for_system_use field is reserved for the system. If the is_format_identifier_valid flag (format match identifier flag) is 1, this indicates that the format_identifier field is valid. If the is_format_identifier_valid flag is set to 1, this indicates that the format_ identifier format identifier field is valid. If the original network identifier validity flag is_original_network_ID_valid is 1, this indicates that the transport stream identifier validity field is_transport_stream_id - valid is valid. If the is_transport_stream_id - valid flag is 1, this indicates that the transport_stream_ID field is valid. If the is_servece_ID_valid flag is 1, this indicates that the servece_ID field is valid.

If the is_country_code_valid country code validity flag is 1, this indicates that the country_code country code is valid. The 32-bit format_identifier identifier field indicates the value of the format_identifier format identifier belonging to the registration descriptor (defined in ISO / IEC 13818-1) in the transport stream. The 16-bit field of the original network identifier original_network_ID indicates the value of original_network_ID defined in the transport stream.

The 16-bit field in servece_ID denotes the servece_ID value defined in the transport stream. The 24-bit country code field country_code represents the country code defined in accordance with ISO3166. Each character is encoded in accordance with ISO8859-1. For example, Japan is represented as "JPN" and encoded as "Ox4AOx50 0x4E." The name of the stream format stream_format_name is a 15-character code in accordance with ISO-646, which represents the name of the format organization that provides the definition of the transport stream. Unauthorized byte in this field has the value '0xFF',

The format identifier format_identifier, network originality identifier original_network_ID, transport stream identifier transport_stream_ID, servece_ID identifier, country code country_code, and stream format name stream_format_name indicate the transport stream service provider. This allows you to recognize restrictions on the encoding of audio or video streams and the definition of a stream as private data streams from other audio and video streams or SI (service information). This information can be used to verify whether the decoder can decode the stream. If such decoding is possible, the information can be used to turn on the decoder system before decoding begins.

Next, STC_Info will be described. A temporary domain in an MPEG-2 transport stream that does not contain STC break points (break points based on system time) is called the STC_sequence sequence. In the clip, the sequence STC_sequence is determined by the value of the identifier STC_sequence_id. On figa and 50B shows a continuous STC domain. The same STC values never appear in the same STC_sequence sequence, although the maximum clip length is limited, as described below. Therefore, the same PTS values also never appear in the same STC_sequence sequence. If the AV stream contains N STC break points, where N> 0, the base of the system time of the clip is divided into (N + 1) STC_sequences sequences.

In STC_Info, the address of the place where the STC break occurs (break of the base of the system time) is recorded. As explained with reference to FIG. 51, the RSPN_STC_start indicates the address and the start point of the arrival time of the source packet referenced by (k + 1) st RSPN_STC_ start, and the arrival time of the last source burst.

On Fig depicts the syntax STC_Info. As can be seen from the STC_Info syntax shown in FIG. 52, the version number version_number is four characters indicating the version number of STC_Info (). Version_number can be encoded as "0045" in accordance with ISO 646.

The length is a 32-bit unsigned integer indicating the number of bytes of STC_Info () immediately after this length field until the end of STCInfo. If the CPI_type from CPI () indicates the type TU_map, this duration field may be set to 0. If the CPI_ type from CPI () indicates the type EP_map, num_of_STC_sequence must be at least 1.

The unsigned 8-bit integer num_of_STC_sequence indicates the number of sequences in the clip. This value indicates the number of loops immediately after this field. The STC_sequence_id identifier corresponding to the predefined STC_ sequence is determined in the order in which RSPN_STC_start appears, corresponding to the STC_ sequence in the loop containing RSPN_STC_start. STC_sequence_ID begins with 0.

The 32-bit RSPN_STC_start field indicates the address at which the STC_sequence sequence of the AV stream file begins. RSPN_STC_start denotes the address where the system time base break in the AV stream file occurs. RSPN_ STC_start may also be a relative source packet address that contains the first PCR of the new system time base in the AV stream. The size of RSPN_STC_start is based on the source packet number and is counted from the first source packet of the AV stream file with the offset_SPN value defined in ClipInfo () as the initial value. In this AV stream file, the absolute address is calculated using the above equation, which is:

SPN_xxx = RSPN_xxx - offset_SPN.

Next, Programlnfo will be described in the zzzz.clip syntax depicted in FIG. 45 with reference to FIG. A time domain having the following properties in a clip is called a program_sequence program sequence. These properties are that the PCR_PID value does not change, the number of elementary audio streams also does not change, the PID values in the corresponding video streams do not change, the encoding information that is determined by its VideoCodingInfo does not change, the number of elementary audio streams also does not change, the PID values of the corresponding audio streams do not change, and the fact that the encoding information, which is determined by its AudioCodingInfo, does not change.

The program_sequence program sequence has only one system time base, at the same time point. Program_sequence has a single PMT at the same time point. ProgramInfo () records the address of the place where program_sequence begins. RSPN_program_sequence_start indicates the address.

On Fig depicts the syntax of Programlnfo. With respect to the Programlnfo shown in FIG. 54, the version_number version number contains four characters indicating the version number of ProgramInfo (). Version_number must be encoded in "0045" in accordance with ISO 646.

The length is a 32-bit unsigned integer indicating the number of bytes of ProgramInfo () directly from the end of this duration field to the end of ProgramInfo (). If CPI_type from CPI () indicates the type TU_map, this duration field can be set to 0. If CPI_type from CPI () indicates the type EP_map, the number of programs number_of_programs must be no less than 1.

The 8-bit unsigned integer of the program number sequence sequence number_of_program_sequences indicates the number of program_sequences program sequences in the clip. This value indicates the number of loops following this field. If program_sequence in the clip does not change, the number of program_sequences program sequences must be set to 1. The 32-bit RSPN_program_sequence_start field is the relative address where the program sequence in the AV stream begins.

RSPN_program_sequence_start is commensurate with the source packet number, which is taken as a block and counts with the offset_SPN offset value, defined in ClipInfo () as the first source packet of the AV stream file. The absolute address in the AV stream file is calculated using the equation:

SPN_xxx = RSPN_xxx - offset_SPN.

The RSPN_program_sequence_start values in the loop syntax should appear in ascending order.

The 16-bit PCR_PID field denotes the PID of the transport packet containing the PCR field valid for the program_sequence program sequence. The 8-bit field for the number of audio programs number_of_audios indicates the number of loops containing audio_strem_PID and AudioCodingInfo (). The 16-bit video_stream_PID field indicates the PID of the transport packet containing the video stream acting on its sequence of program_sequence programs. VideoCodingInfo () following this field should explain the contents of the video stream referenced by its video_stream_PID.

The 16-bit field audio_stream_PID indicates the PID of the transport packet containing the audio stream that is valid for its program_sequence. AudioCodingInfo () following this field should explain the contents of the video stream referenced by its audio stream audio_stream_PID.

The order in which the video_stream_PID values for the syntax loop should be equal to the PID encoding sequence of the video stream in the PMT is valid for the program_sequence program sequence. In addition, the order in which audio_stream_PID values appear in the syntax loop must be equal to the PID encoding sequence of the audio stream in PMT valid for program_sequence.

Fig represents the syntax of VideoCodingInfo in the syntax Programlnfo depicted in Fig. 54. Regarding the syntax of VideoCodingInfo shown in FIG. 55, the 8-bit video format field video_format indicates the video format corresponding to video_stream_PID in ProgramInfo (), as shown in FIG. 56.

In Fig. 57, an 8-bit frame_rate frame rate field indicates a video frame rate corresponding to video_stream_PID in ProgramInfo (). The 8-bit display_aspect_ratio field indicates the speed of the video aspect corresponding to video_stream_PID in Programlnfo ().

Fig. 59 depicts the syntax of AudioCodingInfo in the Programlnfo syntax depicted in Fig. 54. With respect to the AudioCodingInfo syntax shown in FIG. 59, the 8-bit audio_format field indicates an audio coding method corresponding to the audio_stream_PID in ProgramInfo (), as shown in FIG. 60.

The 8-bit field audio_component_type indicates the type of audio component corresponding to audio_stream_PID in Programlnfo (), as shown in FIG. 61, while the 8-bit field sampling_frequency indicates the sampling frequency of audio information corresponding to audio_stream_PID in ProgramInfo (), as shown in FIG. 62.

The CPI (information at characteristic points) syntax of the zzzzz.clip file shown in FIG. 45 will be described below. CPI is used to correlate the time in the AV stream with the address in its file. CPI can be of two types, namely EP_map and TU_map. In Fig. 63, if CPI_type in CPI () is EP_map, its CPI () contains EP_map. On Fig, if the CP_type in CPI () is a TU_map, its CPI () contains TU_map. One AV stream contains one EP_map or one TU_map. If the AV stream is an SESF transport stream, the corresponding Clip should contain EP_map.

Fig depicts the syntax of the CPI. With respect to the CPI syntax depicted in FIG. 65, the version_number version number contains four characters indicating the version number of this CPI (). Version_number must be encoded to “0045” in accordance with ISO 646. The length is a 32-bit unsigned integer indicating the number of bytes directly from this duration field to the end of CPI (). CPI_type is a 1-bit flag and indicates the type of CPI clip, as shown in FIG.

Next, the EP_map list in the CPI syntax shown in FIG. 65 will be described. There are two types of EP_map, that is, EP_map for the video stream and EP_map for the audio stream. EP_map_type in EP_map is different between these EP_map types. If the Clip contains one or more video streams, EP_map should be used for the video stream. If the Clip does not contain a video stream but contains one or more audio streams, EP_map should be used for the audio stream.

EP_map for the video stream is explained with reference to Fig. The EP_map for the video stream contains stream_PID, PTS_EP_start, and RSPN_EP_start data. Stream_PID represents the PID of the transport packet transmitting the video stream. PTS_EP_start indicates the PTS of the access unit starting with the procurement of the sequence of the video stream. RSPN_RP_start indicates the address of the source packet including the first byte of the access block referenced from PTS_EP_ start in the AV stream.

A subtable called EP_map_for_one_stream_PID () is created from one video stream transmitted by a transport packet containing the same PID to another. If there are multiple video streams in the clip, EP_map may contain multiple EP_map_for_one_stream_PID ().

The EP_map for the audio stream contains a stream of data stream_PID, PTS_EP_start and RSPN_EP_start. Stream stream_PID represents the PID of the transport packet transmitting the audio stream. PTS_EP_start represents the PTS of the access unit in the audio stream. RSPN_EP_start indicates the source packet address containing the first byte of the access unit, which is indicated by the PTS_EP_start of the AV stream.

A subtable called EP_map_for_one_stream_PID () is created from one audio stream transmitted by a transport packet having the same PID to another. If several audio streams exist in the Clip, EP_map may contain multiple EP_map-_for_one_stream_PID ().

In the relationship between EP_map and STC_Info, one EP_map_for_one_stream_PID () is created in the same table, regardless of the break points in the STC. A comparison of the RSPN_EP_start value with the RSPN_STC_start value defined in STC_Info () reveals the boundaries of the EP_map data belonging to the corresponding STC_sequences sequences (see FIG. 68). The EP_map table must have one EP_map_for_one_stream_PID for the continuous stream range transmitted by the same PID. In the case of FIG. 69, programs program # 1 and program # 3 contain the same video PID, however, the data range is not continuous, so an EP_map_for_one_stream_PID must be provided for each program.

On Fig depicts the syntax EP_map. To explain the syntax of EP_map shown in FIG. 70, the EP_type type is a 4-bit field and shows the type of entry point EP_map, as shown in FIG. The type EP_type represents the semantics of the data field following this field. If Clip includes one or more video streams, the EP_type type must be set to 0 ("video"). Alternatively, if the Clip does not contain a video stream but contains one or more audio streams, then EP_type should be set to 1 ("audio").

The 16-bit number_of_stream_PID field indicates the number of loops in the loop containing number_of_stream_PID in EP_map as a variable. The 16-bit field stream_PID (k) indicates the PID of the transport packet transmitting the number k (video or audio stream) to the elementary stream, which is referenced by EP_map_for_one_stream_PID (num_EP_entries (k)). If EP_type is 0 ("video"), its elementary stream must be a video stream. If EP_type is 1 ("audio"), its elementary stream must be an audio stream.

The 16-bit field num_EP_entries (k) indicates the num_EP_entries (k) referenced by EP_map_entries (k). EP_map_for_one_stream_PID_Start_address (k): this 32-bit field indicates the position of the relative address at which EP_map_for_one_stream_PID (num_EP_entries (k)) begins in EP_map (). This value is indicated by the size from the first byte of EP_map ().

Padding_word must be entered in accordance with the syntax EP_map (). X and Y are arbitrary positive integers. The corresponding filling words can take any arbitrary meaning.

On Fig depicts the syntax EP_map_for_one_stream_PID. To clarify the syntax of EP_map_for_one_stream_PID depicted in FIG. 72, the semantics of the 32-bit PTS_EP_start field are of the EP_type type defined by EP_map (). If EP_type is 0 ("video"), this field contains the upper 32 bits of the PTS of the 3-bit precision access unit starting with the header of the video stream sequence.

If EP_type is 1 (“audio”), this field contains the upper 32 bits of the PTS of the 33-bit precision audio access block.

The semantics of the 32-bit RSPN_EP_start field are different in the EP_type type defined in EP_map (). If EP_type is 0 ("video"), this field indicates the relative address of the source packet including the first byte of the access block sequence header, which is referenced from PTS_EP_ start in the AV stream. Alternatively, if EP_type is 1 (“audio”), this field indicates the relative address of the source packet containing the first byte in the audio stream of the access unit referenced from PTS_EP_start in the AV stream.

RSPN_EP_start has a size that is based on the source packet number of the block as a block and is calculated from the first packet packet of the AV stream file, with the offset_SPN value defined in ClipInfo () as the original value. The absolute address in the file of the AV stream is calculated by the equation:

SPN_xxx - RSPN_xxx - offset_SPN.

It should be noted that the value of RSPN_EP_start in the syntax should appear in ascending order.

Next, TU_map will be explained with reference to FIG. 73. TU_map generates a time axis based on the clock time of the arrival of the source packet (portion of the time base of the arrival time). This time axis is called TU_map_time_axis. The start point of the time axis TU_map_time_axis is indicated by the offset_time offset time in TU_map (). The time axis TU_map_time_axis is divided into a predetermined block from the offset_time offset time, this block being called time_unit.

In each time_unit time block in the AV stream, the file addresses of the AV stream of the source packet are recorded in TU_map in the first full form. These addresses are called RSPN_time_unit_start. At the point in time at which the kth (k> 0) time_unit block starts at TU_map_time_axis, it is called TU_star_time (k). This value is calculated based on the following equation:

TU_start_time (k) = offset_time + k * time_unit_size.

It should be noted that the accuracy of TU_start_time (k) is determined by the frequency of 45 kHz.

On Fig depicts the syntax of the table TU_map. To clarify the syntax of TU_map shown in FIG. 74, the 32-bit offset_time field determines the offset time with respect to TU_map_time_axis. This value indicates the offset time with respect to the first time_unit block of the clip. The offset time size oifset_time is based on a clock frequency of 45 kHz obtained from a clock frequency of the arrival time of 27 MHz, which is used as a block. If the AV stream should be recorded as a new Clip, the offset_time should be set to 0.

The 32-bit time_unit_size field represents the size of the time_unit block of time and is based on a clock frequency of 45 kHz obtained from a clock frequency of the arrival time with an accuracy of 27 MHz, which is used as a block. Preferably, time_unit_size does not exceed one second (time_unit_size ≤ 45000). The 32-bit number_of_time_unit_entries field indicates the number of inputs written to TU_map ().

The 32-bit RSN__time_unit_start field indicates the relative address of the location in the AV stream at which each time_unit block starts. RSN_time_unit_start has a size based on the number of the source packet used as the unit, and is calculated with the offset_SPN offset value determined by ClipInfo () relative to the first source packet of the AV stream file, which is used as the original value. The absolute file address of the AV stream is calculated using the equation:

SPN_xxx = RSPN_xxx - offset_SPN.

It should be noted that the value of RSN_time_unit_start in the loop from the syntax should appear in ascending order. If there is no source packet in the number (k + 1) time_unit, the number (k + 1) RSN_time_unit_start should be equal to the number k RSPN_time_unit_start.

To explain ClipMark in the zzzzz.clip syntax shown in FIG. 45, ClipMark is label information related to a clip and recorded in ClipMark. This label is not set by the user, but is set by the recording device (device 1 recording and / or playback).

On Fig depicts the syntax of ClipMark. To clarify the syntax of ClipMark shown in FIG. 75, the version number version_number contains four characters indicating the version number of this ClipMark. Version_number must be encoded as "0045" in accordance with ISO 646.

The length is a 32-bit unsigned integer indicating the number of bytes of ClipMark () immediately after the duration field to the end of ClipMark (). Number_of_Clip_marks is a 16-bit unsigned integer indicating the number of labels recorded in ClipMark, and may be 0. Mark_type is an 8-bit field indicating the type of label and encoded in accordance with the table shown in Fig. 76.

Timestamp mark_time_stamp is a 32-bit field and writes a timestamp indicating a pointer that has a specific timestamp. The semantics of mark_time_stamp differs in CPI_type in PlayList (), as shown in FIG.

If CPI_tipe in CPI () indicates the EP_map type, this 8-bit field indicates the STC_sequence_id of the contiguous STC domain where marke_time_stamp is placed. If CPI_type in CPI () indicates the type TU_map, this 8-bit field has no meaning and is set to 0. The 8-bit Character_set field indicates how characters encoded in the mark_name field are indicated. The encoding method corresponds to the value depicted in Fig.19.

The 8-bit name_length field indicates the duration in bytes of the label name represented in the mark_name field. This mark_name field defines the name of the label. The number of bytes corresponding to the name_length number to the left of this field is essentially the number of characters and denotes the name of the label. In the mark_name field, the values following these valid characters may be arbitrary.

The ref_thumbnail_index field indicates image information collapsed into an icon attached to the label. If the ref_thumbnail_index field has a value other than 0xFFFF, the thumbnail image is added to its label, and this thumbnail image is recorded in the mark.thumb file. This image is referenced using the value of ref_thumbnail_index in the mark.thumb file. If the ref_thumbnail_index field has a value of 0 × FFFF, the thumbnail image is not attached to its label.

The private data of the manufacturer MakerPrivateData has already been explained with reference to Fig.22 and, therefore, their explanation is not given here.

Next, thumbnail_information is explained. The thumbnail image is written to the menu.thmb file or to the mark.thmb file. These files have the same syntax structure and contain a single Thumbnail (). The menu.thmb file contains an image representing the corresponding PlayLists. The total number of menu images collapsed into an icon is recorded in a single menu.thmb file.

The mark.thmb file contains an image of a label collapsed into an icon, that is, an image representing a label point. The total number of tag images collapsed into an icon corresponding to the total number of PlayList playlists and Clips clips are recorded in a single mark.thmb file. Since thumbnails are often added or erased, the add and partial erase operation must be performed directly and quickly. For this reason, Thumbnail () has a block structure. Image data is divided into many parts, each of which is recorded in one tn_block. Some image data is recorded in sequential tn_blocks. An unused tn_block may exist on the tn_blocks line. The length in bytes of a single thumbnail image is variable.

FIG. 78 shows the syntax of menu.thmb and mark.thmb, and FIG. 79 shows the syntax of the Thumbnail in the syntax of menu.thmb and mark.thmb shown in FIG. To clarify the syntax of the Thumbnail depicted in FIG. 79, the version number version_number contains four characters indicating the version number of this Thumbnail (). Version_number must be encoded as "0045" in accordance with ISO 646.

The length is a 32-bit unsigned integer indicating the number of bytes of MakerPrivateData ()’s private data directly from the duration field to the end of Thumbnail (). Tu_block_start_address is an unsigned 32-bit integer indicating the address of the start byte of the first tn_block, as the relative number of bytes from the start byte of Thumbnail () as a block. The number of relative bytes is calculated from 0. Number_of_thumbnails is an unsigned 16-bit integer that represents the number of inputs of the image collapsed into an icon contained in Thumbnail ().

Tu_block_size is a 16-bit unsigned integer that represents the size of one tn_block, in the form of a block of 1024 bytes. If, for example, tn_block_size is 1, this indicates that the size of one tn_block is 1024 bytes. Number_of_tn_blocks is a 116-bit unsigned integer indicating the number of entries in tn_block in this Thumbnail (). Thumbnail_index is an unsigned 16-bit integer indicating the index number of the thumbnail image represented by thumbnail thumbnail information for a single loop starting from the thumbnail_index field. The value 0 × FFFF should not be used as Thumbnail_index. This Thumbnail_index is referenced from ref_thumbnai_index in UlAppInfoVolume (). UIAppInfoPlayList (), PlayListMark () and ClipMark ().

Thumbnail_picture_format is an 8-bit unsigned integer that defines the format of the image collapsed into an icon and takes the value shown in Fig. 80. In the table, DCF and PNG are only allowed in menu.thumb. The thumbnail image can be set to “0 × 00” (MPEG-2 Video 1-image).

Image data size Picture_data_size is a 32-bit unsigned integer indicating the length in bytes of the image, collapsed into an icon in bytes, as a block. Start_tn_block_number is a 16-bit unsigned integer indicating the tn_block number of that tn_block where the image data collapsed into the icon starts. The beginning of image data collapsed into an icon should coincide with the beginning of tn_block. The tn_block number starts at 0 and refers to the value of the variable k in the tn_block loop.

X_picture_length is a 16-bit unsigned integer indicating the number of image elements (pixels) in the horizontal direction of the image frame collapsed into an icon. Y_picture_length is a 16-bit unsigned integer indicating the number of image elements (pixels) in the vertical direction of the image frame collapsed into an icon. Tn_block is an area in which an image minimized to an icon is recorded. All tn_blocks in Thumbnail () are the same size (fixed length) and their size is determined by tn_block_size.

On Fig A and 81B schematically shows how the image data, rolled up into an icon, are recorded in tn_block. If, as shown in FIGS. 81 A and 81B, the thumbnail image starts at the beginning of tn_block and has a size exceeding 1 tn_block, it is recorded using the next tn_block. In this case, data with a variable length can be controlled as data of a fixed length, so that editing during erasing can be performed with simpler processing.

The following describes the AV stream file. The file of the AV stream recorded in the directory "M2TS" (Fig). There are two types of AV stream files, namely the Clip AV stream file and the Bridge-Clip AV stream file. Both AV streams must have the structure of a DVR MPEG-2 transport stream file, as defined below.

First, the transport stream of the DVR MPEG-2 is explained. The structure of the transport stream of the DVR MPEG-2 shown in Fig. The AV stream file has a DVR MPEG-2 transport stream structure. The MPEG-2 DVR transport stream consists of an integer number of mapped blocks. The size of the mapped blocks is 6144 bytes (2048 * 3 bytes). Mapped blocks begin with the first byte of the source packet.

The source packet is 192 bytes long. One source packet consists of an optional TP_extra_header header and a transport packet. TP_extra_header is 4 bytes long, with the transport packet being 188 bytes in length.

One mapped block consists of 32 source packets. The last mapped block in the MPEG-2 DVR transport stream also consists of 32 source packets. Therefore, the MPEG-2 DVR transport stream ends at the boundary of the associated block. If the number of transport packets of the input transport information stream written to the disk is not a multiple of 32, the source packet having a zero packet (transport packet PID = 0x1FFFF) should be used as the last mapped block. The file system should not use redundant information in the transport stream of the MPEG-2 DVR.

On Fig shows a model of the recording device of the transport packet MPEG-2 transport stream of information. The recording device shown in FIG. 83 is a conceptual model for describing a recording process. The MPEG-2 DVR transport stream conforms to this model.

The following explains the input timing of the MPEG-2 transport stream. The MPEG-2 input transport stream is a full transport stream or a partial transport stream. MPEG-2 transport input stream must comply with ISO / IEC 13818-1 or ISO / IEC 13818-9. The number of the ith byte of the MPEG-2 transport stream is entered simultaneously at time t (i) into the T-STD (target decoder of the transport stream system in accordance with ISO / IEC 13818-1) and into the source packetizer. Rpk is the instantaneous maximum value of the input speed of the transport packet.

The 27 MHz PLL 52 oscillator generates 27 MHz clock pulses. The 27 MHz clock is locked to the program clock reference (PCR) value of the MPEG-2 transport stream. The counter 53 of the time of arrival of clock pulses reads pulses with a frequency of 27 MHz. Arrival_time_clock (i) represents the count value of the counter arrival of the pulse of the clock frequency at time t (i).

The source packetizer 54 attaches an additional TP_extra_header to the total number of transport packets to create a source packet. Arrival_time_stamp indicates the time when the first byte of the transport packet reaches both the T-STD and the packet source device. Arrival_time_stamp (k) is the value of the Arrival_time__clock (k) sample, which is represented by the following equation:

arrival_time_stamp (k) = arrival_time_clock (k)% 230,

where k denotes the first byte of the transport packet.

If the time separation between two adjacent transport packets is 230/2 7000000 seconds (approximately 40 seconds) or more, the difference arrival_time_stamp of these two transport packets should be set to 230/2 7000000 seconds. A recording device is designed for this.

Smoothing buffer 55 smooths the bit rate of the input transport stream. The smoothing buffer should not overflow. Rmax is the output bit rate of the source packet from the smoothing buffer when the content of the smoothing buffer is non-zero. If the content of the smoothing buffer is zero, the output bit rate of the smoothing buffer is 0.

The following explains the model parameters of the DVR MPEG-2 transport stream recorder. The Rmax value is given by TS_recording_rate, as defined in ClipInfo (), associated with the file of the AV stream. This value can be calculated using the following equation:

Rmax = TS_recording_rate * 192/188,

where the TS_recording_rate value is in bytes / second.

If the input transport stream is an SESF transport stream, Rpk must be equal to TS_recording_rate, as defined in ClipInfo (), associated with the file of the AV stream. If the input transport stream is not an SESF transport stream, reference may be made to values defined, for example, in the MPEG-2 transport stream descriptor, such as maximum_bitrate_descriptor or partial_stream_descriptor for this value.

If the input transport stream is a SESF transport stream, the size of the smoothing buffer is 0. If the input transport stream is not a SESF transport stream, reference may be made to values defined in the MPEG-2 transport stream descriptor, such as, for example, values defined in the smoothing buffer descriptor smoothing_buffer_descriptor, in the short smoothing buffer descriptor short_smoothing_buffer_descriptor, or in the partial transport stream descriptor partial_transport_stream_descriptor.

For the recording device and playback device (playback device), a buffer of sufficient size must be installed. The buffer size specified by definition is 1536 bytes.

The following explains the model of the playback device transport stream DVR MPEG-2. On Fig shows a model of a device for reproducing a transport stream DVR MPEG-2. Here is a conceptual model for describing the reproduction process. The MPEG-2 DVR transport stream conforms to this model.

The 27 MHz oscillator X-tal 61 generates a frequency of 27 MHz. The error range of 27 MHz should be ± 30 ppm (27000000 ± 810 Hz). The counter 62 of the time of arrival of clock pulses is a binary counter for counting pulses with a frequency of 27 MHz. Arrival_time_clock (i) represents the count value of the clock pulse counter at time t (i).

In the smoothing buffer 64, Rmax is the input bit rate of the source packet to the smoothing buffer when the smoothing buffer is not full. If the smoothing buffer is full, the input bit rate in the smoothing buffer is 0.

To explain the output synchronization of the MPEG-2 transport stream, if arrival_time_stamp of the current source packet is 30 bits on the lower significant side of arrival_time_clock (i), the transport packet stream of the source packet is removed from the smoothing buffer. Rpk is the instantaneous maximum value of the speed of the transport packet. Smoothing buffer overflow is not allowed.

The model parameters of the MPEG-2 DVR transport stream playback device are the same as those for the MPEG-2 DVR transport stream recording device described above.

On Fig presents the syntax of the source package. Transport_packet () is an MPEG-2 transport stream in accordance with ISO / IEC 13818-1. The syntax of TP_Extra-header in the syntax of the source packet shown in FIG. 85 is shown in FIG. To clarify the syntax of the TP_Extra-header shown in FIG. 86, copy_permission_indicator is an integer representing a restriction on copying the contents of the transport packet. Restriction on copying can be: free copying, additional copies are forbidden, copying is allowed only once or copying is forbidden. On Fig depicts the relationship between the value of copy_permission_indicator and the modes that it denotes.

The copy_permission_indicator copy permission indicator is attached to all transport packets. If the input transport stream is recorded using the IEEE 13 94 digital interface, the value of copy_permission_indicator can be correlated with the value of EMI (coding mode indicator). If the input transport stream is recorded without using the IEEE1394 digital interface, the copy_permission_indicator copy permission indicator value may be correlated with the CCI value that is embedded in the transport packet. If the input analog signal is independently encoded, the value of copy_permission_indicator may be correlated with the value of the CGMS-A analog signal.

Arrival_time_stamp is the integer that has the value specified in arrival_time_stamp, determined using the following equation:

Arrival_time_stamp (k) = arrival_time_clock (k)% 230.

To determine the AV stream of a clip, the AV stream of the clip must have an MPEG-2 DVR transport stream structure defined as described above. The value of Arrival_time_clock (i) should increase sequentially in the AV stream of the clip. If there are break points at the base of the system time (STC base), in the AV stream of the Clip, arrival_time_clock (i) in the AV stream of the clip should increase sequentially.

The maximum value of the various values of arrival_time_clock (i) between the beginning and end of the AV stream of the clip should be 26 hours. This limitation ensures that if there is no break point (STC base) in the base system time, the MPEG-2 PTS (presentation timestamp) with the same value never appears in the AV Clip stream in the MPEG-2 transport stream. The MPEG-2 system standard defines that the PTS contains a cyclic return period of 233/90000 seconds (approximately 26.5 hours).

To determine the Bridge-Clip AV stream, note that the Bridge-Clip AV stream must have an MPEG-2 DVR transport stream structure defined as described above. The Bridge-Clip AV stream should include a break point on one base of the arrival time. The transport stream back and forth from the break point of the base of the arrival time must comply with the encoding and DVR-STD restrictions, as explained below.

This embodiment supports seamless connectivity between Playltems editable video audio playheads. A seamless connection between Playltems ensures “continuous data feed” to the playback / decoding device and “seamless decoding processing”. "Continuous data feed" represents the possibility of guaranteed data feed to the decoder at the bit rate necessary to prevent buffer overflows. In order for data to be read from disk in real time, the data must be written in the form of continuous blocks with a sufficiently large block size.

“Seamless decoding processing” means the ability of a playback device to display audio-video data recorded on a disc without pausing or interrupting the reproduced output of the decoder.

Next, an AV stream is explained with a link from the seamlessly connected Playltems play points. Whether or not the seamless display of the previous Playltem and the current Playltem is guaranteed, you can check the connection_condition for the connection condition field defined in the current Playltem play point. There are two methods for seamlessly connecting Playltems, which are a method using Bridge-Clip and a method not using Bridge-Clip.

On Fig shows the relationship between the previous Playltem and the current Playltem in the case of using Bridge-Clip. On Fig, the stream data read by the playback device is represented by hatched. On Fig TS1 consists of the hatched data stream Clip1 (AV stream clip) and hatched data stream, which follow before RSPN_arrival_time_discontinuity.

The hatched stream data of Clip1 TS1 is the stream data from the stream address necessary to decode the presentation block corresponding to the IN_item of the previous Playltem playback point (which is shown as IN-time1 in FIG. 88) to the source packet referred to by RSPN_exit_from_previous_Clip. The shaded stream data before the RSPN_arrival_time_discontinuity Bridge-Clip contained in TS1 is the stream data from the first Bridge-Clip source packet to the source packet immediately preceding the source packet referenced by RSPN_arrival_time_ discontinuity.

On Fig, TS2 is represented as hatched data stream Clip 2 (AV stream clip) and hatched data stream following RSPN_arrival_time_discontinuity Bridge-Clip. The hatched stream data from the RSPN_arrival_time_discontinuity Bridge-Clip is contained in the TS2 stream data from the source packet referenced by RSPN_arrival_time_discontinuity, to the last Bridge-Clip source packet. The hatched stream data of Clip2 TS2 is the stream data from the source packet referenced by RSPN_enter_to_current_Clip to the stream address required to decode the presentation block corresponding to the OUT_time output time of the current Playltem playhead (depicted as OUT_time2 in FIG. 88).

On Fig shows the relationship between the previous Playltem and the current Playltem when not using Bridge-Clip. In this case, the stream data read by the playback device is represented by hatched. On Fig TS1 consists of the hatched data stream Clip1 (AV stream Clip). The shaded stream data of Clip1 TS1 is the data starting at the stream address required when decoding the presentation block corresponding to the input time IN_time of the previous Playltem, depicted at time IN_time1 in Fig. 89 as the last packet of the source Clip1.

On Fig TS2 is represented by hatched data stream Clip2 (AV stream clip).

The hatched stream data of Clip2 TS2 is the stream data starting in the first packet of the Clip2 source, as the stream address needed to decode the presentation block corresponding to the OUT_time output time of the current Playltem playhead (shown as OUT_time2 in FIG. 89).

In FIGS. 88 and 89, TS1 and TS2 are continuous source packet streams. Next, we will consider the features of the flows TS1 and TS2 and the connection conditions between them. First, encoding restrictions for a seamless connection will be described. To limit the encoding structure of the transport stream, the number of programs contained in TS1 and TS2 should be 1. The number of video streams contained in TS1 and TS2 should be 1. The number of audio streams contained in TS1 and TS2 should be 2 or less. The number of audio streams contained in TS1 and TS2 must be equal to each other. It is also possible for TS1 and / or TS2 to contain elementary streams or private streams other than those described above.

The limitations of the video bitstream are explained below. On Fig shows a typical seamless connection, represented by a sequence of image displays. In order for the video stream to be presented seamlessly near the connection point, it is necessary to remove unnecessary images displayed behind OUT_timel (output time OUT_time Clip1) and ahead of IN_time2 (input time IN_time Clip2) using the process of re-encoding a partial clip stream close to the connection point.

On Fig shows an embodiment of a seamless connection using BridgeSequence. The Bridge-Clip video stream previous to RSPN_arrival_time_discontinuity consists of an encoded video stream up to an image corresponding to the output time OUT_ time1 Clip1 of FIG. 90. This video stream is connected to the video stream of the previous Clip1 and re-encoded to form an elementary stream conforming to the MPEG2 standard.

The Bridge-Clip video stream following RSPN_arrival_time_discontinuity consists of an encoded video stream following the image corresponding to the IN_time2 Clip2 input time of FIG. 90. The decoding of this video stream may begin correctly to connect the video stream to the next Clip2 video stream. Re-encoding is performed in such a way that a single continuous elementary stream conforming to the MPEG-2 standard is generated. To create a Bridge-Clip, in general, you need to re-encode multiple images, while other images can be copied from the original clip.

On Fig shows an embodiment of a seamless connection without using BridgeSequence in the embodiment depicted in Fig.90. The video stream Clip1 consists of an encoded video stream, as well as the image corresponding to the output time OUT_timel of Fig. 90 and is re-encoded to obtain an elementary stream conforming to the MPEG2 standard. Similarly, the Clip2 video stream consists of encoded bitstreams following the image associated with the input time IN_time2 Clip2 of FIG. 90. These encoded bitstreams are already re-encoded to obtain a single continuous elementary stream conforming to the MPEG2 standard.

To explain the limitations of the coding of the video stream, the frame rates of the video streams TS1 and TS2 should be equal to each other. The TS1 video stream must end with the sequence end code sequence_end_code. The TS2 video stream should begin with a Sequence header, GOP Header, and I-picture. TS2 video stream should start when the GOP is closed.

Video presentation blocks defined in a bit stream (frame or field) must be continuous with the connection point between them. No gap at the connection points in the form of fields or frames is allowed. In the case of encoding using 3-2 drop-down menus, it may be necessary to overwrite the flags "top_field_first" "repeat_first_field". Alternatively, re-coding can be performed to eliminate the formation of spaces in the fields.

To clarify the limitations of coding the audio bitstream, the sampling frequencies of the audio stream TS1 and TS2 should be equal to each other. The encoding method of the audio streams TS1 and TS2 (for example, MPEG1 layer 2, AC-3, SESF, LPCM and AAC) must be equal to each other.

To explain the encoding limitations of the MPEG-2 transport stream, the last audio frame of the TS1 audio stream should contain audio samples having display synchronization equal to the final display time of the last displayed image TS1. The first audio frame of the TS2 audio stream should comprise an audio sample having a display synchronization equal to the start synchronization of the display of the first displayed image TS2.

No gaps in the sequence of audio presentation blocks are allowed at the junction point. As shown in FIG. 93, there may be an overlay determined by the duration of the audio presentation block, which should be less than two domains of the audio frame. The first packet transmitting the TS2 elementary stream must be a video packet. The transport stream at the junction should correspond to the DVR-STD, which is explained below.

To explain the limitations of Clip and Bridge-Clip in TS1 and TS2, no gaps in the base of the arrival time are allowed.

The following restrictions apply only to the use of Bridge-Clip. The Bridge-Clip AV stream has a single break point based on the arrival time only at the junction of the last TS1 source packet and the first TS2 source packet. The arrival time gap SPN_arrival_time_discontinuity defined in ClipInfo () represents the address at the breaking point, which should represent the address that refers to the first packet of the TS2 source.

The source package referenced by RSPN_exit_from_previous_Clip defined in BridgeSequenceInfo () can be any source package in Clip1. This source packet should not border on the associated block. The source package referenced by RSPN_enter_to_current_Clip defined in BridgeSequenceInfo () can be any source package in Clip2. This source packet should not border on the associated block.

To explain the limitations of Playltem, the output time OUT_time of the previous Playltem (OUT_time1, as shown in FIG. 89) should represent the final display time of the last block of the video presentation TS1. The input time IN_time of the current Play Time (IN_time2 shown in FIGS. 88 and 89) should represent the start time of the display of the first presentation block TS2.

To explain the limitations of data placement in the case of using Bridge-Clip, as shown in FIG. 94, a seamless connection should be made to ensure continuous file system data feed. This should be implemented using the AV stream of the clip, connecting with Clip1 (file of the AV stream of the clip) and Clip2 (file of the AV stream of the clip), so that the requirements for data placement are met.

RSPN_exit_from_previous_Clip should be selected so that the portion of the Clip1 stream (file of the AV stream of the clip) preceding RSPN_exit_from_previous_Clip is arranged in a continuous region of at least half of the fragment. The length of the AV data of the Bridge-Clip stream should be selected so that the data is arranged in a continuous area of at least half of the fragment. RSPN_enter_to_current_Clip should be selected so that the part of the Stream2 stream (file of the AV stream of the clip) following RSPN_enter_to_current_Clip is arranged in a continuous region of at least half of the fragment.

To clarify the limitations of data placement in the case of seamless connection, without using Bridge-Clip, as shown in Fig. 95, seamless connection should be performed in such a way as to guarantee a continuous flow of data by the file system. This should be implemented by arranging the last part of Clip1 (file of the AV stream of the clip) and the first part of Clip2 (file of the AV stream of the clip) so that the data placement conditions are met.

The last part of the Clip1 stream (file of the AV stream of the clip) should be located in a continuous region of at least one half of the fragment. The first part of the Clip2 stream (file of the AV stream of the clip) should be located in a continuous region of at least one half of the fragment.

The following explains the DVR-STD. This DVR-STD is a conceptual model designed to model decoding processing when generating and validating an MPEG-2 DVR transport stream. The DVR-STD is also a conceptual model for modeling the decoding process when generating and validating an AV stream, referenced by two Playltems, seamlessly interconnected as described above.

On Fig depicted model DVR-STD. The model shown in Fig. 96 includes, as an integral element, a model of a transport stream playback device DVR MPEG-2. The designations n, Tbn, Mbn, Ebn, Tbsys, Bsys, Rxn, Rbxn, Rxsys, Dn, Dsys, On and P9 (k) are the same as defined in the T-STD in accordance with ISO / IEC 13818-1, where n is the index number of the elementary stream and Tbn is the transport buffer of the elementary stream n.

MBn is a multiplexing buffer for elementary stream n and exists only for the video stream. EBn is a buffer of elementary stream n and is present only in the video stream. TBsys is the main buffer in the system target decoder for system information for the decoded program. Rxn is the transmission rate at which data is output from TBn. Rbxn is the transmission rate at which the contents of the PES packet are removed from MBn and is present only for the video stream.

Rxsys is the baud rate at which data is output from TBsys. Dn is a decoder of elementary stream n. Dsys is a decoder corresponding to the system information of the decoded program. On is a buffer for changing the order of video stream n. Pn (k) is a representation block number k of the elementary stream.

The following explains the decoding process for the DVR-STD. During the time when the transport stream of one MPEG-2 DVR is played back, the synchronization of the transport packet input in TB1, TBn, or TBsys is determined by the arrival_time_stamp of the source packet arrival time stamp. The requirements for the operation of the TB1, MB1, EB1, TBn Bn, TBsys and Bsys buffers are the same as for the T-STD in accordance with ISO / IEC 13818-1, while the requirements for the decision and operation operations are the same. as for the T-STD, and comply with ISO / IEC 13818-1.

The following will describe the decoding process during playback of seamlessly linked PlayLists. The following explains the playback of two AV streams referenced by seamlessly connected Playltems playback points. Next, the reproduction of TS1 and TS2 shown, for example, in FIG.

TS1 and TS2 are the previous stream and the current stream, respectively.

On Fig shows a timing diagram of the input, decoding and display of transport packets during transmission from a given AV stream (TS1) to the next AV stream, seamlessly connected to it (TS2). During transmission from a given AV stream (TS1) to the next AV stream seamlessly connected to it (TS2), the time axis of the arrival time base TS2 does not coincide with the time axis of the arrival time basis TS1 (as shown by ATC1 in FIG. 97).

In addition, the time axis of the base system time TS2 (indicated by ATC1 in FIG. 97) does not coincide with the time axis of the base system time TS1 (indicated by STC1 in FIG. 97). It is required that the video display is continuous and seamless, however, overlapping display time of presentation blocks may occur.

The following explains the input timing for the DVR-STD. During the time until T1, that is, until the last video packet TV1 DVR-STD is input, the input clock for the TB1, TBn or TBsys DVR-STD buffers is determined by the arrival_time_stamp arrival timestamp of the TS1 arrival time basis.

The remaining packets TS1 must be entered in the buffers TBn or TBsys DVR-STD with the bit rate TS_recording_rate (TS1). TS_recording_rate (TS1) is the value of the recording speed Ts_recording_rate defined in ClipInfo () corresponding to Clip1. The time of the last byte TS1 is entered into the buffer at time T2. Thus, during the time between the moment T1 and the moment T2, the arrival_time_stamp of the source packet is not taken into account.

If N1 is the number of bytes in the transport packet TS1 following the last video packet TS1, the time DT1 from time T1 to time T2 is the time required to fully enter N1 bytes with a bit rate TS_recording_rate (TS1), and is calculated in accordance with the following equation:

DT1 = T2-T1 = N1 / TS_recording_rate.

During the time from time T1 to time T2 (TS1), both Rxn and Rxsys are changed to TS_recording_rate (TS1). With the exception of this rule, the operation of the buffer is the same as with the T-STD.

At time T2, the input time clock counter is set to the arrival_time_stamp value of the first TS2 source packet. The input clock in the TB1, TBn, or TBsys DVR-STD buffer is determined by the arrival_time_stamp arrival time stamp of the TB2 source packet. Both Rxn and Rxsys change to the values defined in the T-STD.

To clarify the operation of additional audio buffers and system data buffers, the audio decoder and system decoder must have additional buffer capacity (equivalent to one second in data volume) in addition to the buffer size defined in T-STD so that they can accommodate input data for a domain from time T1 to time T2.

To explain synchronization, the video presentation should be continuous, that is, it should not have gaps, points of transition through the connection. It should be noted that STC1 is the time axis of the system time base TS1 (designated as STC1 in FIG. 9), while STC2 is the time axis of the system time base TS2 (represented as STC2 in FIG. 97; if STC2 is operating correctly starts at the point in time when the first PCR TS2 was introduced into the T-STD).

The offset between STC1 and STC2 is defined as follows: PTS1end is the PTS for STC1 corresponding to the last TS2 video presentation block. PTS2start is the PTS for STC2 corresponding to the first TS2 video presentation block, and Tpr is the display time period of the last video presentation block TS1, wherein the offset STC_delta between the two system time bases is calculated according to the following equation:

STC_delta = PTS1end + Trp - PTS2start.

To clarify the synchronization of the audio presentation, there may be an overlay of the display time of the audio presentation block, and this overlay must be less than 0-2 audio frames (see "audio overlay" shown in Fig. 97). An indication as to which of the audio samples should be selected and re-synchronized when the audio presentation block is displayed in the corrected time axis behind the connection point is installed in the playback device.

To explain the synchronization of the DVR-STD system time, the last TS1 audio presentation unit is displayed as T5 time. System time synchronization may overlap between time T2 and time T5. During this time domain, the DVR-STD switches the system time synchronization between the value of the old time base (STC1) and the value of the new time base (STC2). The value of STC2 can be calculated in accordance with the following equation:

STC2 = STC1 - STC_delta.

Next, the continuity of the buffers is explained. STC11video_end represents the STC value of the STC2 system time base when the first byte of the first video packet reaches TV1 from the DVR-STD. STC22video_start is an STC value based on the STC2 system time when the first byte of the first video packet reaches TV1 from the DVR-STD. STC21video_end is the STC11video_end value calculated as the STC2 value of the STC2 system time base. STC21 video_end is calculated according to the following equation:

STC21video_end = STC11video_end - STC_delta.

In order to meet the conditions of the DVR-STD, it is necessary that the following two conditions are met: firstly, the synchronization of the arrival of the first TS2 video packet in TV1 must satisfy the following inequality:

STC22video_start> STC21video_end + ΔТ1.

If it is necessary to re-encode and / or multiplex a partial stream of Clip1 and / or Clip2 so that the above inequality is satisfied, this re-encoding or multiplexing is performed accordingly.

Secondly, the input of the video packet from TS1, which follows after the input of the video packet from TS2 on the time axis of the base of the system time displayed from STC1 and STC2 on the same time axis, should not lead to overflow or empty of the video buffer.

In the above syntax, the data structure and rules are used as the basis, the content of the data recorded on the recording medium, or reproducible information can be properly controlled so that the user can confirm the content of the data recorded on the recording medium during playback, or reproduce the required data in a completely accessible way .

In the above embodiment, the MPEG-2 transport stream is adopted as an example of a multiplexed stream. However, this is just an example, since the MPEG-2 DCC program stream or the transport stream used by the DirecTV Service of the USA (trademark) can also be used as a multiplexed stream.

On Fig presents a modification of the file playlist PlayList. The marked difference between the syntax of FIG. 98 and FIG. 99 is the place where UlAppInfoPlayList () is recorded. In the embodiment of FIG. 98, in which the UlAppInfoPlayList () is outside the PlayList (), a further extension of the UlAppInfoPlayList () information can be achieved quite simply.

The version number version_number is four characters indicating the version number of the workpiece as an image collapsed into an information file icon.

PlayList_start_address indicates the leading address of the PlayList () as a number of relative bytes from the leading end of the PlayList file as a block. The number of relative bytes is calculated from 0.

PlayListMark_start_address indicates the leading address of the PlayListMark () as the number of relative bytes from the leading byte of the PlayList file as a block. The number of relative bytes is calculated from 0.

MakersPrivateData_start_address denotes the leading address of the manufacturer's private data MakersPrivateData as the number of relative bytes from the leading byte of the PlayList file as a block. The number of relative bytes is calculated from 0.

On Fig presents the syntax of UlAppInfoPlayList in the PlayList file on Fig. PlayList_service_type indicates the type of the PlayList file, an example of which is shown in FIG. PlayList_service_type may have the same meaning as the type of service provided by digital broadcast television. For example, in a broadcast satellite system in Japan, there are three types of service, namely a TV service, an audio service, and a broadcast service. A value representing the type of program service contained in the Clip AV stream used by the PlayList playlist is set to PlayList_service_type.

PlayList_character_set denotes a method for encoding characters encoded in the fields channel_name, PlayList_name and PlayList_detail, while designating a method for encoding characters encoded in the mark_name field in PlayListMark.

Channel number channel_number denotes the broadcast channel number or service number of the user’s choice when recording a PlayList. If several PlayLists are combined into a single PlayList, the channel_number indicates the representative value of the PlayList. If this field is set to 0xFFFF, this field has no meaning.

Channel name length channel_name_length indicates the length in bytes of the channel name given in the channel_name field. This field has a value of no more than 20.

Channel_name denotes the name of the service or broadcast channel of the user's choice when recording a PlayList. The number of bytes in the number indicated by channel_name_length to the left of this field represents valid characters and indicates the above name. The remaining bytes following these valid characters can be set to any arbitrary value. If multiple PlayList playlists are combined into one PlayList, this field indicates the name of the corresponding PlayList.

PlayList_name_length indicates the length in bytes of the name of the PlayList specified in the PlayList_name field.

Play_List_name represents the name of the PlayList playlist. The number of bytes by the number specified in PlayList_name_length to the left of this field represents valid characters and indicates the above name. The remaining bytes in this field following these valid characters may be set to any arbitrary value.

PlayList_detail_length indicates the length in bytes of the detailed PlayList information specified in the PlayList_detail field. This field has a value of no more than 1200.

PlayList_detail denotes text intended to illustrate the details of a PlayList playlist. The number of bytes by the number given in the PlayList_detail_length field to the left of this field is valid characters. The remaining bytes in this field following these valid characters may be set to an arbitrary value.

The value of this syntax field is otherwise the same as for the field with the same name, which is shown in Fig.27.

FIG. 100 shows the syntax of a PlayList () of a playlist file of a PlayList of FIG. This syntax is basically the same as in the embodiment depicted in FIG. 25, except that this syntax is not present in UlAppInfoPlayList ().

101 depicts a modification of the syntax of SubPlayItem. This syntax differs markedly from the embodiment depicted in FIG. 40 in that an STC_sequence_id identifier has been added.

The STC_sequence_id identifier indicates the STC_sequence_id for the STC referenced by SubPath_IN_time and SubPath_OUT_time, which are used to identify the playback domain of the AV stream file corresponding to the name of the information file Clip_Information_file_name. SubPath_IN_time and SubPath_OUT_time denote the time of the same contiguous STC domain defined by STC_sequence_id.

When adding the STC_sequence_id identifier to SubPlayItem, it is allowed for the AV stream file referenced by SubPlayItem to have an STC break point.

The syntax field otherwise has the same meanings as the field with the same name shown in FIG.

102 is a flowchart illustrating a method for generating a real playlist Real PlayList. In this case, reference is made to the block diagram of the recording and / or reproducing device shown in FIG. In step S11, the controller 43 records the Clip AV stream.

In step S12, the controller 23 checks whether the EP_map of the AV stream can be prepared or not. If the result of the check in step S12 is YES, the controller 23 proceeds to step S13. Otherwise, the controller 23 proceeds to step S14 to generate the TU_map.

In step S15, the controller 23 sets the CLI_type for the PlayList. In step S16, the controller 23 generates a PlayList () consisting of a Playltem, which fully covers the entire possible range of clip playback. If CPI_type is an EP_map type, time information is set based on the PTS. If the clip has an STC breakpoint and the PlayList () consists of two or more Playltem play points, the connection_condition condition between the Playltem play points is also determined. If CPI_type is a TU_map type, time information is set based on the arrival time.

In step S17, the controller 23 generates a UlAppInfoPlayList ().

At step S18, the controller 23 generates a PlayListMark.

At step S19, the controller 23 generates a MakerPrivateData.

In step S20, the controller 23 generates a RealPIayList file.

Thus, one Real PlayList file is always generated when a new recording of the AV stream of a clip occurs.

103 is a flowchart illustrating a method for generating a virtual playlist Virtual PlayList.

At step S31, one real playlist Real PlayList recorded on the disc is determined through the user interface. From the playback range of Real PlayList, the playback range is determined by the input and output points IN and OUT using the user interface. If the CPI_type type is an EP_map type, the playback domain is set based on the PTS. If the CPI_type type is the TU_type type, the playback domain is set based on the arrival time.

In step S32, the controller 23 checks whether all work has been completed by indicating the playback range by the user. If the user selects a domain to play next to the specified playback domain, the controller 23 returns to step S31. If all the work of specifying the playback range by the user has been completed, the controller 23 proceeds to step S33.

At step S33, the state of the connection (Connection_condition between two sequentially playable playback domains) is determined by the user through the interface or controller 23.

If in step S34, the CPI_type is an EP_map type, the user indicates subpath information (audio information after recording). This step is skipped if the subpath is not configured by the user.

In step S35, the controller 23 generates a PlayList () based on the playback range information specified by the user, and based on the connection condition connection_condition.

In step S36, the controller 23 generates a UlAppInfoPlayList ().

At step S37, the controller 23 generates a PlayListMark.

At step S38, the controller 23 generates a MakerPrivateData.

In step S39, the controller 23 generates a VirtualPlayList file.

Thus, one virtual PlayList file is generated for each group of play domains that were selected from the Real PlayList play range recorded on the disk and which the user needs to view.

104 is a flowchart for explaining a method of a PlayList.

In step S51, the controller 23 obtains information regarding info.dvr, the Clip Information file, the PlayList file and the thumbnail image file, and generates a GUI image showing a list of PlayLists recorded on the disc to display the GUI image thus formed, in the GUI through the user interface.

In step S52, the controller 23 provides information explaining the PlayList in the GUI image based on the UlAppInfoPlayList in the respective PlayLists.

In step S53, the user instructs to play one PlayList from the GUI image through the user interface.

If the CPI_type is an EP_map type, the controller 23 in step S54 obtains from the sequence identifier STC_sequence_id and the ON_time PTS on time, the source packet number that has the entry point temporarily located in front of and closest to the entry time at IN_time. If the CPI_type type is a TU_map type, the controller 23 receives from the IN_time entry time of the current Playltem playhead, the source packet number where the time block begins, temporarily preceding and closest to the IN_time entry time.

In step S55, the controller 23 reads the data of the AV stream from the packet number of the source received in the previous step for routing the read data to the AV decoder 27.

If at step S56 there is a Playltem play point that is temporarily preceding the current Playltem, the controller 23 performs display connection processing between the previous Playltem and the current Playltem in accordance with the connection_condition of the connection condition.

If in step S57 the CPI_type is an EP_map type, the AV decoder 27 issues a command to start the image from the image for the IN_time PTS entry time. If CPI_type is a TU_map type, the AV decoder 27 issues a command to start displaying a stream image following the IN_time entry time.

In step S58, the controller 23 issues an instruction to the AV decoder 27 to continue decoding the AV stream.

If the CPI_type is an EP_map type, the controller 23 in step S59 checks whether the image currently being displayed is the OUT_time PTS output time image. In addition, if CPI_type is a TU_map type, the controller 23 checks whether or not the currently decoded stream is a stream coming after the OUT_time output time.

If the result of the check in step S59 is NO, the controller 23 proceeds to step S60. In step S60, the controller 23 displays the current image with respect to that which was when returning to step S58. If the result of the check in step S59 is YES, the controller 23 proceeds to step S61.

In step S61, the controller 23 checks whether or not the current Playltem play point is the last Playltem in the PlayList, if the test result is NO, the controller 23 returns to step S54 and, otherwise, the playlist PlayList ends.

105 is a flowchart illustrating a method for reproducing a SubPath of a PlayList. The SubPath playback method of FIG. 105 is used only if the CPI_type PlayList is an EP_map. Processing in accordance with the algorithm is performed simultaneously with the processing following step S54 when reproducing the playlist PlayList of FIG. 104. In addition, it is assumed that the AV decoder 27 allows you to decode two audio streams at the same time.

In step S71, the controller 23 receives the SubPlayItem information.

In step S72, the controller 23 obtains a source packet number containing an entry point temporarily previous and closest to SubPath_IN_time.

In step S73, the controller 23 reads the data of the AV subpath from the source packet number having the above entry point for routing the data thus read to the AV decoder 27.

In step S74, the controller 23 issues a command to the AV decoder 27 to start displaying the audio information of the subpath when the main path playback reaches the image indicated by sync_PlayItem_id and sync_start_PTS_of_PlayItem.

In step S75, the AV decoder 27 continues to decode the subpath's AV stream.

In step S76, the controller 23 checks whether or not the PTS subpath currently displayed is SubPath_OUT_time. If the result of the check is NO, the controller 23 proceeds to step S77, where the controller 23 continues to display the subpath. The controller 23 then returns to step S75.

If, in step S76, the PTS of the currently displayed subpath is SubPath_OUT_time, the subpath mapping is terminated.

The main path and subpath of one PlayList file, to which the user has given a command, is reproduced, as shown in FIGS. 104 and 105.

106 is a flowchart for illustrating a method for generating a PlayListMark. In this case, reference is made to the block diagram of the recording and / or reproducing device of FIG.

In step S91, the controller 23 obtains information on info.dvr, the Clip Information file, the PlayList file and the thumbnail image file, and generates a GUI image showing the PlayLists recorded on the disc to display the GUI image thus formed in GUI through the user interface.

At step S92, the user instructs the controller 23 to play one PlayList through the user interface.

In step S93, the controller 23 starts playing the specified PlayList in accordance with the command (see FIG. 104).

In step S94, the user instructs the controller 23 to set the label on the preferred scene through the user interface.

If the CPI_type type is EP_map in step S95, the controller 23 receives the PTS label and the Playltem_id identifier for the Playltem to which it belongs. In addition, the controller 23 receives the arrival time of the cue point if the CPI_type type is TU_map.

In step S95, the controller 23 writes label information to the PlayListMark ().

In step S97, the controller 23 writes the PlayList file to the recording medium 100.

107 is a flowchart for illustrating a method for determining a playback location using PlayListMark. In this case, reference is made to the block diagram of the recording and / or reproducing device 1 of FIG. 1.

In step S111, the controller 23 obtains information on info.dvr, the Clip Information file, the PlayList file and the thumbnail image file, and generates a GUI image showing a list of PlayLists recorded on the disc (recording medium 100) for displaying the GUI image formed in this way in the GUI through the user interface.

In step S112, the user instructs the controller 23 to play one PlayList through the user interface.

In step S113, the controller 23 displays a list of images collapsed into an icon generated from the image referenced by the PlayListMark, which is displayed in the GUI through the user interface.

In step S114, the user indicates the cue point of the playback start point through the user interface.

If the CPI_type type is EP_map, the controller 23 receives the PTS label and the Playltem_id to which it belongs. If the CPI_type type represents TU_map, the controller 23 receives the ATS (arrival time stamp) for this label.

If the CPI_type type is EP_map, the controller 23, in step SI16, obtains the STC-sequence_id identifier of the AV stream referenced from the Playltem indicated by the Playltem_id identifier.

In step S 117, if the CPI_type type is EP_map, the controller 23 inputs the AV stream to the decoder based on the PTS tag and based on the STC-sequence_id identifier. In particular, the controller 23 performs similar processing to that performed in step S55 using the PTS tag and the STC-sequence_id identifier. If the CPI_type is TU_type, the controller 23 inputs the AV stream to the decoder based on the ATS label. In particular, the controller performs processing similar to the processing in step S54 and step S55 of FIG. 104 using the ATS.

If in step S118, the CPI_type type is EP_tar, the controller 23 starts displaying the label point from the PTS image. If the CPI_type type is TU_map, the controller 23 starts displaying the image back from the ATS label point.

Thus, the user selects, for example, the starting point of the preferred scene from the PlayList playlist. The starting point thus selected is controlled by the recording device (controller 23 of the recording and / or reproducing device 1) in PlayListMark. In addition, the user selects the start point of the playback from the list of cue points recorded in the PlayListMark so that the playback device starts playback at the start point, as shown in Fig. 107.

If the above syntax uses the data structure and rules as the basis, the content data recorded on the recording medium or the playback information can be properly managed, allowing the user to confirm the content of the data recorded on the recording medium during playback, or it is extremely accessible to reproduce the necessary data.

If the position of the I-image can be analyzed, the AV stream of various formats can be recorded, played back and controlled using a common application program (software) provided that TU_map is used.

If the AV stream is recorded on the recording medium as its contents (I-image position), analyzed (recording with analysis), EP_MAP is used, while the AV stream was directly recorded on the recording medium without analyzing its contents (I-image position) (record without analysis), TU_map is used. In this way, AV data can be recorded, played back and controlled using a common application program.

Thus, if the scrambled AV data is decrypted with analysis to record it on the recording medium, EP_MAP is used, while if the scrambled AV data is directly recorded on the recording medium without decryption (without analysis), TU_map is used. In this case, AV data can be recorded, played back and controlled using conventional application programs.

In addition, the type EP_map and type TU_map can be described in PlayList () as CPI_type, while TU_map can be used if the position of the I-image can be analyzed, while if the position of the I-image cannot be analyzed, it can used by TU_map. In this case, the recorded data of the AV stream with the analysis of the position of the I-image and the data of the AV stream recorded without analysis of the position of the I-image can be controlled in a unified manner using a common program simply by setting the corresponding flag.

In addition, the PlayList file and the Clip Information file are recorded separately, so that if the contents of this PlayList or Clip change during, for example, editing, there is no need to change the file regardless of the file being modified. The result of this is that the contents of the file can be changed directly to reduce the time required for such a change or recording.

In addition, if at the beginning only info.dvr is read into the user interface to represent the contents of the disc record for reading from the disc only the PlayList file, the command to play which was received from the user and the corresponding Clip Information file, the waiting time of the user can be reduced.

If you collect the total number of PlayList files or Clip Information files in one file for recording, the file size becomes voluminous. So the time required to change the contents of the file for recording will be significantly longer than when the corresponding files are recorded separately. The present invention addresses this drawback.

The above sequence of operations can be performed not only by hardware, but also by software. If the sequence of operations is to be performed using software, they are installed from the recording medium to a computer installed in the appropriate hardware in which the program forming the software is installed, or to a general purpose personal computer according to FIG. 38, which allows performing various functions on basis of the many programs installed in it.

The recording medium consists not only of the means of the package distributed for delivering the program to the user on a computer, such as a magnetic disk 221 on which the program is recorded, including a floppy disk, optical disk 222, CD-ROM (Read-Only Memory on CD) or A DVD (Universal Digital Disc), a magneto-optical disc 223, a mini-disk or a semiconductor storage device 224, but also includes a hard disk, including a read-only memory 202 on which the program is recorded, and a storage device 208 that ond delivered to the user for installation on the computer, as shown in fig.108.

In the present description, the steps of a program delivered on a medium include not only chronological processing in accordance with the indicated sequence, but also processing not performed chronologically, but in parallel or separately.

In addition, in this specification, a system means an entire device consisting of a plurality of component devices.

Industrial applicability

In the method and apparatus for processing information in accordance with the present invention, the program for the recording medium, the program and the recording medium in accordance with the present invention, one of the first table establishing the relationship of the relationship between the timestamp of the presentation and the address of the AV data of the stream in the corresponding access unit, and a second table establishing the relationship of the relationship between the timestamp received from the time point of arrival of the transport packet and the address of the AV data of the stream in accordance vuyuschem overpack is recorded depending on the recording method.

In the method and device for processing information, the program for the recording medium and the program in accordance with the present invention, one of the first table establishing the relationship of the relationship between the timestamp of the presentation and the address in the AV data of the stream in the corresponding access unit, and the second table establishing the relationship of the relationship between the arrival time stamp obtained from the arrival time point of the transport packet and the address of the AV data of the stream in the corresponding transport packet, which are recorded on the nose The recording medium, depending on the recording method, is played back from the recording medium to control the output.

In the method and device for processing information, the program for the recording medium, the program and the second recording medium, in accordance with the present invention, information is recorded defining reproduction, consisting of the first information defining the main playback path, and the second information defining the auxiliary playback path reproduced synchronously with the main playback path.

In the method and apparatus for processing information, a program for a recording medium and a program in accordance with the present invention, information specifying reproduction consisting of first information defining a main reproduction path and second information defining an auxiliary reproduction path is reproduced from the recording medium for corresponding control conclusion.

Thus, in any case, an AV stream for which high-speed playback is possible, and an AV stream for which high-speed playback is not possible, can be controlled together, while re-recording is also possible.

Claims (39)

1. An information processing device for recording the AV data of a stream on a recording medium, comprising a controller for generating a first table describing the relationship of the relationship between the presentation time stamp and the address in the specified AV data of the stream of the corresponding access unit, or a second table describing the relationship of the relationship between the timestamp received from the time point of arrival of the transport packet and the address in the specified AV data of the flow of the corresponding transport about the package, and a recording device for recording one of the first and second tables, which are selected depending on the recording method on the specified recording medium along with the specified AV stream data. 2. The information processing device according to claim 1, characterized in that said first table is EP_map, and said second table is TU_map. 3. The information processing device according to claim 1, characterized in that said controller selects said second table in the case of recording without analysis. 4. The information processing device according to claim 1, characterized in that said controller selects said first table in the case of recording with self-coding. 5. The information processing device according to claim 1, characterized in that said controller selects said first table in the case of recording with analysis. 6. The information processing device according to claim 1, characterized in that said controller generates identification information indicating which of the first and second tables has been recorded. 7. The information processing device according to claim 6, characterized in that said controller performs control so that if said first table is recorded together with said AV stream data, the reproduction domain time of said AV stream data is controlled based on the presentation time, and wherein if said second table is recorded together with said AV stream data, the reproduction domain time of said AV stream data is controlled based on the arrival time. 8. A method of processing information for recording AV stream data on a recording medium, comprising the step of generating a first table describing the relationship of the relationship between the presentation time stamp and the address in the specified AV data of the stream of the corresponding access unit, or a second table describing the relationship of the relationship between the arrival time stamp, received at the time point of arrival of the transport packet, and the address in the specified AV data of the stream of the corresponding transport packet, and the recording step of one of the first and second a blitz, optionally, depending on the recording method, to said recording medium together with said AV stream data. 9. A recording medium on which a computer-readable program is written for an information processing device for recording AV stream data onto a recording medium, said program including the step of generating a first table describing the relationship of the relationship between the presentation timestamp and the address in the specified AV data the flow of the corresponding access unit, or a second table describing the relationship of the relationship between the arrival time stamp obtained from the arrival time point and the transport packet, and the address in the specified AV data of the stream of the corresponding transport packet, and a recording step for recording one of the first and second tables, optionally, depending on the recording method, on the specified recording medium along with the specified AV data of the stream. 10. An information processing device for reproducing AV data of a stream from a recording medium, comprising a playback unit for reproducing one of the first table describing the relationship of the relationship between the presentation time stamp and the address in the specified AV data of the stream of the corresponding access unit, and the second table, describing the relationship between the arrival timestamp obtained from the arrival time point of the transport packet and the address in the indicated AV data of the stream with tvetstvuyuschego transport packet, from said recording medium on which is recorded said first table or said second table depending on a recording method, and a control unit for controlling output of said AV stream data based on the reproduced table. 11. A method of processing information for reproducing AV data of a recording medium stream, comprising the step of reproducing one of the first table describing the relationship of the relationship between the presentation timestamp and the address in the specified AV data of the stream of the corresponding access unit, and the second table describing the relationship of the relationship between the arrival time stamp obtained from the time point of arrival of the transport packet, and the address in the specified AV data of the stream of the corresponding transport packet from the specified carrier pisi on which is recorded said first table or said second table depending on a recording method, and an output control step of said AV stream data based on the reproduced table. 12. A recording medium on which a computer-readable program is written for an information processing device for recording AV stream data on a recording medium, said program including the step of reproducing one of the first table describing the relationship of the relationship between the presentation timestamp and the address in said AV data stream of the corresponding access unit, and a second table describing the relationship between the relationship between the timestamp of arrival, received at the time point neither the arrival of the transport packet, and the address in the indicated AV data of the stream of the corresponding transport packet from the specified recording medium onto which the indicated first table or the indicated second table is recorded, depending on the recording method, and the step of controlling the output of the indicated AV data of the stream based on the reproduced table . 13. A recording medium on which one of the first table describing the relationship of the relationship between the presentation time stamp and the address in the specified AV data of the flow of the corresponding access unit is recorded, and the second table describing the relationship of the relationship between the arrival time stamp obtained from the time point of arrival of the transport packet and the address in the indicated AV data of the stream of the corresponding transport packet, depending on the recording method. 14. An information processing device for processing sound and / or image information, comprising an input for inputting sound and / or image information; a controller for generating characteristic point information consisting of (i) an input point map describing the relationship between the entry timestamp of the input point and the address of the corresponding input point, or (ii) a time module map describing the relationship between the time module arrival time stamp and address the corresponding time module, in accordance with the type of the specified input information of sound and / or image, and an output intended for outputting an input point card or a time mode card la. 15. The device of claim 14, further comprising a recording device for recording said sound and / or image information and characteristic point information on the recording medium. 16. The device according to clause 15, in which said controller generates input point cards when the input sound and / or image information is converted into a stream format with self-coding. 17. An information processing device for processing sound and / or image information, comprising an input for inputting sound and / or image information; a controller for generating (i) an input point map describing the relationship between the time stamp of the input point presentation and the address of the corresponding input point, or (ii) a time module card describing the relationship between the time stamp of the arrival time of the time module and the address of the corresponding time module, and the device recording, designed to record information of sound and / or image and card input point or card of the temporary module on the recording medium. 18. The device according to 17, in which the specified controller generates cards of the temporary module when the map of the input point cannot be prepared. 19. An information processing device for recording audio and / or image input information, comprising a controller for generating playlist information and map information corresponding to clip information, said clip information consisting of sound and / or image information, said information the playlist includes at least one playitem indicated by an input point and an output point of clip information, said information as you include (i) an entry point map describing the relationship between the entry timestamp for the entry point and the address of the corresponding entry point, or (ii) a time module map describing the relationship between the arrival time stamp of the time entry and the address of the corresponding time module, and a recording device designed for storing playlist information, map information and clip information on the recording medium. 20. The device according to claim 19, wherein said controller generates map information for each clip information. 21. The device according to claim 20, wherein said controller generates card information of the same type as for all clip information associated with one playlist. 22. A method of processing information of sound and / or image, comprising the following steps: inputting information of sound and / or image; generating characteristic point information consisting of (i) an input point map describing the relationship between the timestamp of the input point representation and the address of the corresponding input point, or (ii) a time module map describing the relationship between the time stamp of the arrival time of the time module and the address of the corresponding time module in according to the type of specified input information of sound and / or image, and an output intended for outputting a card of an input point or a card of a temporary module. 23. The method according to item 22, further comprising the step of recording the specified sound and / or image information and characteristic point information on the recording medium. 24. The method of claim 23, wherein the input point map is generated when the input sound information and / or image is converted to a self-encoding stream format. 25. A method for processing sound information and / or image information, comprising the following steps: inputting sound information and / or image; generating (i) an entry point map describing the relationship between the timestamp of the entry point representation and the address of the corresponding entry point, or (ii) a time module map describing the relationship between the arrival time stamp of the time module and the address of the corresponding time module in which one of the input map points and maps of the temporary module are selected adaptively, and recording information of sound and / or image and maps of the input point or maps of the temporary module on the recording medium. 26. The method according A.25, in which the map of the temporary module is generated when the map of the input point cannot be prepared. 27. A method of recording input sound and / or image information, comprising the steps of: generating playlist information and map information corresponding to clip information, said clip information consisting of sound and / or image information, said playlist information including at least at least one playback point indicated by an input point and an output point of clip information, said card information including (i) an input point map describing the relationship between the time stamp of the presentation of the input point and the address of the corresponding input point, or (ii) a time module card describing the relationship between the time stamp of the time module and the address of the corresponding time module, and storing the information of the playlist, map information and clip information on the recording medium. 28. The method of claim 27, wherein map information is generated for each clip information. 29. The method of claim 28, wherein card information of the same type is generated for all clip information associated with one playlist. 30. A device for reproducing sound and / or image information, comprising a reproducing device for reproducing sound and / or image information from a recording medium and (i) an input point map describing the relationship between the timestamp of the presentation of the input point of the specified information and the address of the corresponding input point , or (ii) a time module card describing the relationship between the time stamp of the time module arrival of the specified information and the address of the corresponding time module, respectively etstvii with the type of said input audio data and / or images; a card recovery unit for reconstructing an input point or a card of a temporary module from said recording medium, and a reproduction unit for sound and / or image information for reproducing sound and / or image information associated with the reconstructed card. 31. The device according to clause 30, in which the input point map is stored on the specified recording medium when the sound and / or image information has a self-encoding stream format. 32. A device for reproducing sound and / or image information containing a reproducing device for reproducing from a recording medium onto which play list information and map information corresponding to clip information, specified clip information including said sound and / or playback information is recorded, wherein said playlist information includes at least one playitem indicated by an input point and an output point of clip information, wherein The indicated card information includes (i) an input point map describing the relationship between the timestamp of the presentation of the clip information input point and the address of the corresponding input point, or (ii) a time module map describing the relationship between the time stamp of the clip information information and the address of the corresponding time module ; a playlist recovery unit for recovering playlist information; a card recovery unit for recovering map information and a reproducing unit for reproducing clip information associated with the restored map information. 33. The device according to p, in which the corresponding card information is stored for each information of the clip. 34. The device according to p, in which the card information of the same type is stored for all the clip information associated with a single playlist. 35. A method of reproducing sound and / or image information, comprising the steps of: reproducing sound and / or image information from a recording medium and (i) an entry point card describing the relationship between the timestamp of the presentation of the input point of the specified information and the address of the corresponding input point, or (ii) a temporary module card describing the relationship between the time stamp of the arrival time of the specified module information and the address of the corresponding temporary module, in accordance with the type of input sound and / or image formations; recovering an input point card or a temporary module card from said recording medium, and reproducing sound information and / or image information associated with the reconstructed card. 36. The method according to clause 35, in which the input point map is stored on the specified recording medium when the sound and / or image information has a self-encoding stream format. 37. A method of reproducing sound and / or image information, comprising reproducing from a recording medium onto which playlist information and map information corresponding to clip information, said clip information including said sound and / or image information is recorded, said playlist including, at least one play point indicated by an entry point and an exit point of clip information, said map information including (i) an entry point map describing the relationship interconnection between presentation time stamp of the entry point of the clip and location information corresponding to the entry point, or (ii) the temporary card module, describing the relationship between arrival time stamp module temporary location information of the clip and the corresponding time unit; restoring playlist information; recovering map information, and reproducing clip information associated with the restored map information. 38. The method according to clause 37, in which the corresponding card information is stored for each information of the clip. 39. The method of claim 38, wherein the card information of the same type is stored for all clip information associated with a single playlist.

Images