Information storage medium for stream data, recording method thereof, playback method, recording device, and playback device

The present invention relates to an information storage medium for recording video data transmitted by digital broadcasting or the like or stream data transmitted with a packet structure, a data structure of management information regarding stream data recorded on this medium, and recording of the management information. Regarding the method and playback method.

In recent years, TV broadcasting has entered the era of digital broadcasting. Along with this, there has been a demand for a device that stores digital data of digital TV broadcasting as it is, regardless of its contents, a so-called streamer.

The digital TV broadcasts currently being broadcast use the MPEG transport stream. It is thought that MPEG transport streams will continue to be used as standard in the field of digital broadcasting using moving images.

In this digital broadcast, the broadcast content (mainly video information) is time-divided into data groups of predetermined size (for example, 188 bytes) called transport packets, and the broadcast data is transmitted for each transport packet. To.

As a streamer for recording this digital broadcast data, there is a home-use digital VCR such as D-VHS (digital VHS) currently on the market. In the streamer using this D-VHS, the broadcast bit stream is recorded as it is on the tape. Therefore, a plurality of programs are multiplexed and recorded on the video tape.

At the time of playback, all the data is sent from the VCR to the set-top box (digital TV receiver: hereinafter abbreviated as STB) as it is, whether it is played from the beginning or in the middle. In this STB, a desired program is selected from the sent data by a user operation or the like. The selected program information is transferred from the STB to a digital TV receiver or the like and played back (playback of video + audio or the like).

In this D-VHS streamer, since a tape is used as a recording medium, quick random access cannot be realized, and it becomes difficult to quickly jump to a desired position of a desired program and play it back.

A streamer using a large-capacity disk medium such as DVD-RAM can be considered as a promising candidate that can solve such a drawback of the tape (difficulty of random access). In that case, considering random access and special playback, it is inevitably necessary to record management data together with broadcast data.

Here, between STB, which is a digital TV receiver, and a streamer that uses a large-capacity disk media such as DVD-RAM, or between a streamer that uses this large-capacity disk media and another streamer that uses D-VHS or the like. A digital interface compliant with IEEE1394 or the like can be used for data transfer to and from.

In this digital interface, video data / stream data is transferred for each transport packet received by digital broadcasting.

For example, in a digital interface using IEEE1394, in order to guarantee real-time transfer of received data of digital broadcasting, time stamp data indicating the reception time is added to each transport packet and the transfer is performed. There is.

In addition, in order to guarantee the continuous reproduction of the received data of the above digital broadcast recorded on the information storage medium such as DVD-RAM in the STB in real time, the transport packet data is displayed on the information storage medium together with each transport packet data. The time stamp data is also recorded at the same time.

<p> In the above case, time stamp data is added to each transport packet and recorded as stream data to be recorded on an information storage medium using a large-capacity disk medium such as DVD-RAM. Therefore, time management is performed using this time stamp data.</p><p> In digital TV, video data is broadcast in an information-compressed form using a digital compression method called MPEG2. According to this MPEG2 method, the P picture information has only the difference information for the I picture, and the B picture information has only the difference information for the I picture and the P picture. Therefore, the B picture or the P picture cannot be reproduced independently, and the reproduction from the I picture is required to reproduce these.</p><p> Here, the video playback time seen by the user indicated by the display time of each of the pictures I, B, and P is different from the time stamp time. Therefore, when the time management for the stream data recorded on the information storage medium is performed only by the time stamp data, there arises a problem that the display time (video reproduction time) for the user cannot be accurately controlled.</p><p> The present invention has been made in view of the above circumstances, and an object of the present invention is to improve the processing of stream information recording.</p>

<p> In order to achieve the above object, in the embodiment of the present invention, a data area (STREAM.VRO) configured to record stream data and management information (STRI) related to this stream data are recorded. An information medium (201) with a managed area (STREAM.IFO) is used. Here, the management information (STRI in FIG. 13 / SFIT in FIG. 15) is configured to include time information (PTSL in FIG. 15) corresponding to a specific part (AU in FIGS. 16 to 17) of the stream data. Will be done.</p><p> The stream data can be configured by a data unit of a certain size (for example, 64 kB SOBU).</p>

<p> Improvements can be made regarding the processing of stream information recording.</p>

Hereinafter, with reference to the drawings, a stream data storage medium according to an embodiment of the present invention, a data structure of management information regarding stream data recorded on this medium, a recording method and a reproduction method of the management information, and the like will be described. To do.

FIG. 1 is a diagram illustrating a data structure of stream data according to an embodiment of the present invention. The data structure of the stream data recorded on the information storage medium will be described with reference to FIG.

The stream data (STREAM.VRO) 106 (Fig. 1 (a)) recorded on an information storage medium (Fig. 3, other 201) such as a DVD-RAM disk is a stream object for each content of the video information in the stream data. (Hereinafter, it is abbreviated as SOB as appropriate). That is, each SOB is formed by stream data obtained by one real-time continuous recording.

As shown in Fig. 1 (b), the stream data recorded on the information storage medium is grouped as stream objects (SOB) # A 298 and # B 299 for each content of the video information in the stream data. It has been recorded.

FIGS. 1 (b) to 1 (k) show in detail the contents of one SOB # A · 298 among a plurality of stream objects (SOB # A, # B, ...).

When stream data (STREAM.VRO) 106 is recorded on a DVD-RAM disc, each is recorded with a sector of 2048 bytes as the minimum unit. Furthermore, 16 sectors are combined into one ECC block, and interleaving (sorting of data arrangement order) and correction code for error correction are added in the same ECC block.

In this embodiment, a stream block (or stream object unit SOBU) is configured in units of one or more (typically two) ECC blocks, and stream information is generated in this stream block unit (or SOBU unit). Recording, partial erasing, editing, etc. are performed.

In this embodiment, how many ECC blocks make up a stream block can be determined according to the transfer rate of the stream data (STREAM.VRO) 106 to be transferred.

For example, in the example of FIGS. 1 (c) and 1 (d), stream block # 1 is composed of two ECC blocks # α and # β, and stream block # 2 is composed of three ECC blocks # γ, # δ and # ε. It is configured. In a DVD streamer, two ECC blocks (32 sectors) make up one stream block (or SOBU).

Each ECC block is composed of 16 sectors as shown in FIG. 1 (e). Therefore, as can be seen from FIGS. 1 (c) to 1 (e), the stream block (or SOBU) # 1 composed of 2 ECC blocks corresponds to 32 sectors (sector No. 0 to sector No. 31).

That is, if 1 sector = 2 kbytes, the present invention can be implemented with the stream block (SOBU) having a fixed size of 64 kbytes (32 sectors).

The stream data (STREAM.VRO) 106 is recorded in the information storage medium as a set of a time stamp and a transport packet as shown in FIG. 1 (g).

At that time, as shown in FIG. 1 (f), pack headers 11 and 12 and PES headers 13 and 14 in which system clock information (system clock reference SCR) and the like are recorded are arranged at the head of each sector. The sector data header 17 is recorded immediately after the PES header 14, but only the first sector of each stream block (or SOBU) is recorded with the stream block header 16 instead of the sector data header.

The stream block header 16 or the sector data header 17 can have contents corresponding to the application header described later (see FIG. 9 or FIG. 10).

The sector data header 17 in FIG. 1 (f) shows the data arrangement information in the data areas 22 and 23.

Data areas 21, 22 (or 23) in Figure 1 (f) include time stamps (corresponding to the ATS shown in Figure 20, Figure 29, etc.) and transport packets (Figure 1), as shown in Figure 1 (g). 22 or the packet in Figure 23, or the application packet AP in Figure 29) is packed sequentially.

In the example of FIG. 1 (g), a case where one transport packet d is recorded across a plurality of sectors (No. 0 and No. 1) is illustrated. Such a transport packet d corresponds to the partial packet of FIG. 22 or FIG.

By the way, in digital broadcasting, a multi-program compatible multiplexing / separation method called a transport stream is adopted, and the size of one transport packet is often 188 bytes (or 183 bytes).

On the other hand, as described above, the one sector size is 2048 bytes, and even if various header sizes are subtracted, the transport for digital broadcasting is within one data area 21, 22, 23 (Fig. 1 (f)). About 10 packets can be recorded.

In the transport packet, as shown in FIG. 1 (h), the transport packet headers 61 to 64 (corresponding to 511 in FIG. 23 (b) described later) and the payloads 71 to 75 in which the data is recorded (described later). It corresponds to 512 in Fig. 23 (b)).

As shown in FIG. 1 (i), MPEG-encoded I-picture information 31, B-picture information 33, 34, and P-picture information 32 are recorded in the payloads 71 to 75.

In the first transport packet in which the I picture information 31 is recorded, the random access indicator 503 (see FIG. 23 (a)) is flagged as "1", and the first transformers of the B and P picture information 32 to 34 are set. The port packet is flagged as "1" on the payload unit start indicator 501 (see Figure 23 (a)).

As shown in FIG. 1 (j), each of the picture information 31 to 34 divided and recorded in the payloads 71 to 75 has the picture header information 41 at the beginning and the picture compression which is the actual picture information. Information 42 (I picture compression information 42 for I picture information 31) is recorded.

Further, in each picture header information 41, as shown in FIG. 1 (k), header identification information 51, picture identification information 52 that enables identification of each I, B, and P picture, and decoder output display. PTS (presentation time stamp) information 53 indicating the timing and DTS (decoding time stamp) information 54 indicating the timing for the decoder to start decoding are recorded. These picture header information 41 are included in advance in the received information of digital broadcasting.

In the stream data recorded on the information storage medium, a specific picture position can be identified by using the picture identification information 52 shown in FIG. 1 (k).

Alternatively, since the PTS information 53 is recorded in the picture header information 41 as shown in FIGS. 1 (j) and 1 (k), the decoder can start displaying using this value.

FIG. 2 is a diagram illustrating a directory structure of a data file according to an embodiment of the present invention. The content (file structure) of the information recorded on the information storage medium according to the embodiment of the present invention will be described with reference to FIG.

Information recorded on an information storage medium such as a DVD-RAM disk has a hierarchical file structure for each piece of information. The video information and stream data information described in this embodiment are contained in a subdirectory 101 named DVD_RTR directory (or DVD_RTAV) 102.

In the DVD_RTR (DVD_RTAV) directory 102, the data file 103 having the following contents is stored.

That is, RTR.IFO (or VR_MANGR.IFO) 104, STREAM.IFO (SR_MANGR.IFO / SR_MANGR.BUP) 105, and SR_PRIVT.DAT / SR_PRIVT.BUP105a are stored as a group of management information (navigation data). To.

Also, as the data body (content information), STREAM.VRO (or SR_TRANS.SRO) 106, RTR_MOV.VRO (VR_MOVIE.VRO) 107, RTR_STO.VRO (or VR_STILL.VRO) 108, and RTR_STA.VRO (or) VR_AUDIO.VRO) 109 is stored.

A subdirectory 110 for storing other information can be provided in the root directory 100 in the upper hierarchy of the subdirectory 101 including the data file 103.

The contents of this subdirectory include a video title set VIDEO_TS111 containing a video program, an audio title set AUDIO_TS112 containing an audio program, and a subdirectory 113 for storing computer data.

Data recorded in an information storage medium while maintaining the packet structure with respect to the data transmitted in the form of a packet structure on a wired or wireless data communication path is called "stream data".

The stream data itself is recorded together with the file name STREAM.VRO (or SR_TRANS.SRO) 106. The file in which the management information for the stream data is recorded is STREAM.IFO (or SR_MANGR.IFO and its backup file SR_MANGR.BUP) 105.

In addition, the file recorded by digitally compressing analog video information handled by VCR (VTR) or conventional TV based on the MPEG2 standard is RTR_MOV.VRO (or VR_MOVIE.VRO) 107, which is after-recorded audio or background. The file that collects still image information including audio is RTR_STO.VRO (or VR_STILL.VRO) 108, and the dubbing audio information file is RTR_STA.VRO (or VR_AUDIO.VRO) 109.

FIG. 3 is a diagram illustrating a recorded data structure (particularly a structure of management information) on an information medium (DVD recording / replay disc) according to an embodiment of the present invention.

As shown in FIG. 3B, the lead-in area 204 and the lead-in area 204 are located in the area sandwiched between the end of the information storage medium 201 of FIG. 3A 201 in the inner peripheral direction 202 and the end of the information storage medium 201 in the outer peripheral direction 203. There is a volume &amp; file structure information 206 in which file system information is recorded, a data area 207, and a readout area 205. The lead-in area 204 is composed of embossed and rewritable data zones, and the lead-out area 205 is composed of rewritable data zones. Data area 207 is also composed of rewritable data zones.

As shown in Fig. 3 (c), computer data and audio &amp; video data can be mixed and recorded in the data area 207. In this example, the audio &amp; video data area 210 is sandwiched between the computer data area 208 and the computer data area 209.

In the audio &amp; video data area 210, as shown in FIG. 3D, mixed recording of the real-time video recording area 221 and the stream recording area 222 is possible. (It is also possible to use only one of the real-time video recording area 221 or the stream recording area 222.) As shown in FIG. 3 (e), the real-time video recording area 221 has the RTR shown in FIG. Navigation data RTR.IFO (VR_MANGR.IFO) 104, movie real-time video object RTR_MOV.VRO (VR_MOVIE.VRO) 107, still picture real-time video object RTR_STO.VRO (VR_STILL.VRO) 108, and audio for after-recording, etc. The object RTR_STA.VRO (VR_AUDIO.VRO) 109 is recorded.

Similarly, as shown in FIG. 3 (e), the stream recording area 222 contains the streamer navigation data STREAM.IFO (SR_MANGR.IFO / SR_MANGR.BUP) 105 and the transport bitstream data STREAM shown in FIG. .VRO (SR_TRANS.VRO) 106 is recorded.

Although not shown in FIGS. 3 (d) and 3 (e), the application-specific navigation data SR_PRIVT and DAT / SR_PRIVT.BUP105a shown in FIG. 2 can also be recorded in the stream recording area 222.

This SR_PRIVT, DAT105a is navigation data unique to each application connected (supplied) to the streamer, and is data that does not need to be recognized by the streamer.

STREAM.IFO (or SR_MANGR.IFO) 105, which is management information related to stream data, has a data structure as shown in FIGS. 3 (f) to 3 (i).

That is, as shown in Fig. 3 (f), STREAM.IFO (or SR_MANGR.IFO) 105 has a video manager (VMGI or STR_VMGI) 231, a stream file information table (SFIT) 232, and original PGC information (ORG_PGCI). 233, user-defined PGC information table (UD_PGCIT) 234, text data manager (TXTDT_MG) 235, and application private data manager (APDT_MG) 236 that manages the manufacturer information table (MNFIT) or application-specific navigation data SR_PRIVT.DAT105a. It is composed of and.

As shown in Fig. 3 (g), the stream file information table (SFIT) 232 in Fig. 3 (f) has stream file information table information (SFITI) 241 and one or more stream object information (SOBI) # A · 242. , # B 243, ........., original PGC information general information 271, and one or more original cell information # 1,272, # 2,273 ......... Can be included.

Each stream object information (eg SOBI # A · 242) in FIG. 3 (g) can include stream object general information (SOBI_GI) 251, time map information 252, and more, as shown in FIG. 3 (h). ..

In addition, each original cell information in FIG. 3 (g) (for example, # 1 and 272; which will be described later but corresponds to the SCI shown in FIG. 14) has cell type 281 (which will be described later) as shown in FIG. 3 (h). Corresponding to C_TY shown in FIG. 14, cell ID 282, corresponding cell start time (corresponding to FIG. 6 (b) described later, SC_S_APAT shown in FIG. 14 and others) 283, and corresponding cell end time (corresponding to FIG. 6 described later). (B), corresponding to SC_E_APAT shown in Figure 14 and others) 284, PTS offset 9 and time relationship table 2 can be included.

Here, the PTS offset 9 is the difference between the PTS (presentation time stamp) value of the display start picture of the original cell (details of the original cell will be described later) and the PTS value of the I picture immediately before it (details are described). See below in Figure 20).

The time map information 252 in FIG. 3 (h) included in SOBI # A in FIG. 3 (g) has a stream block number 261, a first stream block size 262, and a first stream block as shown in FIG. 3 (i). The time difference 263, the second stream block size 264, the second stream block time difference 265, ......... can be included. The contents of each stream block time difference constituting the time map information 252 will be described later with reference to FIG.

FIG. 4 is a diagram illustrating a relationship between a stream object (SOB), a cell, a program chain (PGC), and the like in one embodiment of the present invention. Hereinafter, the relationship between SOB and PGC will be described using the example shown in FIG.

The stream data recorded in the stream data (STREAM.VRO or SR_TRANS.SRO) 106 constitutes a stream block as a collection of one or more ECC blocks, and recording, partial erasure processing, etc. are performed in this stream block unit. .. This stream data forms a group called a stream object for each content of information to be recorded (for example, for each program in digital broadcasting).

The management information (original PGC information 233, user-defined PGC information table 234, etc.) for each stream object (SOB # A, SOB # B) recorded in STREAM.VRO (SR_TRANS.SRO) 106 is the navigation data STREAM.IFO. (SR_MANGR.IFO) 105 (see bottom of Figure 4 and Figures 3 (e) (f)).

The management information (STREAM.IFO105) for each stream object # A 298 and # B 299 in Fig. 4 is the stream in the stream file information table (SFIT) 232 as shown in Fig. 3 (f) (g). It is recorded as object information (SOBI) # A 242, # B 243.

The inside of each of the stream object information (SOBI) # A · 242 and (SOBI) # B · 243 mainly includes the time map information 252 in which the data size and time information for each stream block are described.

When playing back stream data, information on a program chain (PGC) composed of a series of one or more cells (corresponding to PGCI # i in FIG. 14 described later) is used. Therefore, the stream data can be played back in the order of setting the cells constituting this PGC.

The PGC includes the original PGC290 (ORG_PGCI 233 in Fig. 3 (f)) that can continuously play all the stream data recorded in STREAM.VRO (SR_TRANS.SRO) 106, and the user wants to play it. There are two types of user-defined PGC # a 293 and # b 296 (corresponding to the contents of UD_PGCIT 234 in Fig. 3 (f)) where the location and order can be set arbitrarily.

The original cells # 1, 291 and # 2, 292 that make up the original PGC290 basically exist in a one-to-one correspondence with the stream objects # A, 298, and # B, 299.

On the other hand, the user-defined cells # 11/294, # 12/295, and # 31/297 that make up the user-defined PGC are in arbitrary positions within the range of one stream object # A / 298 or # B / 299. Can be set.

The sector size of each stream block can be set in various ways, but as a preferred embodiment, a stream having a constant size (64 kbytes) in 2 ECC blocks (32 sectors) as shown in stream block # 1 in FIG. An object unit (SOBU) may be used as a stream block.

Fixing a stream block to a SOBU of a certain size (for example, 2 ECC blocks = 32 sectors = 64 kbytes) in this way has the following advantages: (01) Even if the stream data is erased or rewritten in SOBU units: , The ECC block of the SOBU does not affect the ECC block of the SOBU other than the one to be erased or rewritten. Therefore, ECC deinterleave / interleave (for SOBUs that are not subject to erasure or rewrite) does not occur due to erasure or rewrite; (02) Access position for recorded information inside any SOBU is determined by the number of sectors (for SOBUs that are not subject to erasure or rewrite). Alternatively, it can be specified by other parameters corresponding to the number of sectors; for example, information on the stream pack in FIG. 10 and the application packet group inside it, which will be described later. For example, when accessing the intermediate position of a certain SOBU # k, the 16th sector (or the position of the application packet corresponding to the 16th sector) from the boundary between SOBU # k-1 and SOBU # k may be specified.

FIG. 5 is a diagram for explaining the contents of the stream block size and the stream block time difference in the time map information. Hereinafter, the contents of each data in the time map information 252 will be described with reference to FIG.

As illustrated in FIGS. 5 (f) (g) (h), the stream object (SOB) # A · 298 is composed of two stream blocks # 1 and # 2.

In the example of Fig. 5 (f) (h), the data size of stream block # 1 that composes SOB # A 298 is composed of 2 ECC blocks (# α, # β), which is equivalent to 32 sectors (Fig. 5 (e)). It has the size of (i)). That is, the first stream block size 262 (Fig. 5 (j)) in the time map information 252 (Fig. 5 (a) (k)) is 32 sectors (64 kbytes).

Stream block # 1 (Fig. 5 (f)) at the beginning of SOB # A 298 (Fig. 5 (g)) has sector No. 0 (Fig. 5 (e)) at the beginning, and is in sector No. 0. A time stamp a (FIG. 5 (c)) is recorded at the beginning of the included data area 21 (FIG. 5 (d)).

In addition, the subsequent stream block # 2 (Fig. 5 (f)) of SOB # A 298 (Fig. 5 (g)) has sector No. 32 (Fig. 5 (e)) at the beginning, and is in sector No. 32. A time stamp p (Fig. 5 (c)) is recorded at the beginning of the included data area 311 (Fig. 5 (d)).

As shown in Fig. 5 (c), the time stamp value of the first stream data of stream block # 1 is the time stamp a, and the time stamp value of the first stream data of the next stream block # 2 is the time stamp p. It has become.

The value of the first stream block time difference 263 in FIG. 5 (b) (corresponding to the stream block time difference 263 in FIG. 3 (i)) is the difference value between the above time stamp p and the time stamp a ([time stamp p]-[ Given by time stamp a]).

Note that the time map information 252 in FIG. 5A can be handled as including the access data unit AUD in the stream object information SOBI, which will be described later with reference to FIG. From the information contained in this AUD (access unit start map AUSM, etc.), the SOBU containing the information you want to access can be specified.

FIG. 6 is a diagram illustrating a method of specifying a cell range in the original cell and the user-defined cell. The range of each cell can be specified by specifying the start time and the end time.

Specifically, as the time of the start time 283 of the corresponding cell and the end time 284 (Fig. 6 (b)) of the corresponding cell in the original cell immediately after recording the stream data, the corresponding stream object # A 298 (Fig. 6 (Fig. 6 (b)) The value of the first time stamp a and the value of the last time stamp z (Fig. 6 (c)) in f)) are used.

On the other hand, the time range can be specified in user-defined cells # 12 and 295 (Fig. 6 (k)). For example, the values of the time stamps d and n corresponding to the transport packets d and n specified as shown in FIGS. 6 (i) and 6 (j) are the values of the start time 331 of the corresponding cell and the end time 332 of the corresponding cell. Can be set as.

Figure 6 (f) illustrates the case where stream object (SOB) # A · 298 is composed of two stream blocks # 1 and # 2.

In the example of FIGS. 6 (e) and 6 (g), the stream block # 1 is composed of 32 sectors (sectors No. 0 to No. 31), and the stream block # 2 is composed of 48 sectors (sectors No. 32 to No. 79). It is composed of.

As shown in FIGS. 6 (e) and 6 (d), the first sector No. 0 of the stream block # 1 is composed of a pack header 1, a PES header 6, a stream block header 11, a data area 21, and the like.

Further, as shown in FIGS. 6 (e) and 6 (d), the rear sector No. 78 of the stream block # 2 is composed of a pack header 3, a PES header 8, a sector data header 13, a data area 24, and the like.

Further, as shown in FIG. 6 (h), the pack header 2, the sector data header 12, the data area 22 and others are recorded in the sector No. 1 in FIG. 6 (g), and the sector No. 33 in FIG. 6 (g) is recorded. As shown in FIG. 6 (h), the sector data header 321 and the data area 312 and others are recorded in.

In the data area 21 of FIGS. 6 (d) and 6 (h), as shown in FIGS. 6 (c) and 6 (i), a pair of the time stamp a and the transport packet a or the time stamp d and the transport packet d are provided. The pair is recorded.

In the area of data area 24 in FIG. 6 (d), a plurality of time stamp and transport packet pairs, an end code 32 following the last time stamp z + transport packet z pair, and a padding area 37 Is recorded.

Further, as shown in FIG. 6 (i), the data area 22 of FIG. 6 (h) includes a transport packet d including the following contents of the transport packet d of the data area 21. That is, in this example, the content of the transport packet d is divided into the data area 21 and the data area 22 and recorded.

The first half (data area 21 side) of the transport packet d in FIG. 6 (i) corresponds to the last part packet in FIG. 23 (f) described later, and the second half of the transport packet d in FIG. 6 (i). (Data area 22 side) corresponds to the head side partial packet of FIG. 23 (g) described later.

Further, in the data area 312 of FIG. 6 (h), as shown in FIG. 6 (i), a pair of the time stamp n and the transport packet n and other similar pairs are recorded.

Here, the cell start time 331 (FIG. 6 (j)) corresponding to the location where the user or the like specifies the playback start time is the time stamp d for the entire two transport packets d divided into the data areas 21 and 22. (Specified by (Fig. 6 (i)).

When the transport packet is read as an application packet (AP) and the application packet arrival time is APAT, the cell start time 331 can be expressed as a cell start APAT.

Further, the end time 332 (Fig. 6 (j)) of the cell corresponding to the place where the user or the like has specified the playback end time is specified by the time stamp n (Fig. 6 (i)) for the transport packet n in the data area 312. Will be done. This cell end time 332 can be expressed as a cell end APAT.

The above cell start time (cell start APAT) 331 and cell end time (cell end APAT) 332 can be recorded inside the user-defined cell information # 12 and 295 as shown in FIG. 6 (k).

This user-defined cell information # 12 and 295 can be recorded in the user-defined PGC information table 234 shown in FIG. 3 (f) or the lower part of FIG.

The above is about cell start / end time information related to user-defined cell information (user-defined PGC information), but the following examples are given for cell start / end time information related to original cell information (original cell information). it can.

That is, the start time 283 of the corresponding cell in FIG. 6 (b) can be indicated by the start time stamp a in FIG. 6 (c), and the end time 284 of the corresponding cell can be indicated by the end time stamp z in FIG. 6 (b).

The start time 283 of the corresponding cell in FIG. 6 (b) can correspond to the cell start APAT (including the stream cell start APAT (SC_S_APAT) or the erase start APAT (ERA_S_APAT)).

Further, the end time 284 of the corresponding cell in FIG. 6B can correspond to the cell end APAT (including the stream cell end APAT (SC_E_APAT) or the erase end APAT (ERA_E_APAT)).

The above cell start time (cell start APAT) 283 and cell end time (cell end APAT) 284 are recorded inside the original cell information # 1.272 as shown in FIG. 6 (a).

The original cell information # 1 and 272 can be recorded in the original PGC information 233 shown in FIG. 3 (f) or the lower part of FIG.

FIG. 7 describes a recording data structure (particularly, a structure of playback end position information / resume information, VMGI management information / recording time information, etc.) on an information medium (DVD recording / replay disk) according to another embodiment of the present invention. It is a figure to do.

Since the data structure of FIGS. 7 (a) to 7 (f) is the same as that of FIGS. 3 (a) to 3 (f), the description thereof will be omitted.

As shown in FIG. 7 (g), the video manager (STR_VMGI) 231 of FIG. 7 (f) includes playback end position information (resume information) 6110, video manager management information (VMGI_MAT) 6111 and others.

As shown in FIG. 7 (h), the reproduction end position information (resume information) 6110 includes the original PGC number 6210, the original cell number 6220, the reproduction end position time (resume time) information 6230, and the like.

Also, the video manager management information (VMGI_MAT) 6111 includes the time zone (TM_ZONE) 6240.

When the playback of the recorded stream block (or original cell) is completed, the playback end position information 6110 is used as resume information in the video manager information 231 in the management information recording area (STREAM.IFO) in Fig. 7 (e). Can be recorded.

The time information 6230 included in the playback end position information 6110 is recorded as a time stamp (ATS) value, but the PTS value (or the total number of fields from the cell playback start position) is recorded as the time information 6230. You can also do it.

The time zone (TM_ZONE) 6240 contains information on the recording time (REC_TM), as shown in FIG. 7 (i).

The recording time (REC_TM) information is the time zone type (TZ_TY) that identifies whether REC_TM is due to Universal Time Coordinated (UTC) or a specific local time, and the time offset of REC_TM from UTC. Includes a time zone offset (TZ_OFFSET) that describes the date and time in minutes.

The recording time (REC_TM) may be described in the format of the cell start time (SC_S_APAT) shown in FIG. 6B or the like or the format of the playback time (presentation time PTM) of the cell.

There are two types of this recording time (REC_TM). The first is the stream object recording time (SOB_REC_TM), and the second is the playlist creation time (PL_CREATE_TM).

Here, SOB_REC_TM indicates the time when the stream object (SOB) corresponding to the original cell was recorded.

A playlist is a list of a part of a program. This playlist allows the user to define any playback sequence (for the contents of the program). PL_CREATE_TM indicates the time when such a playlist was created.

FIG. 8 is a diagram illustrating the internal structure of the PES header shown in FIG. 1 and others.

As shown in FIG. 8 (b), the PES header 601 of FIG. 8 (a) includes a packet start code prefix 602, a stream ID 603, a playback time stamp 604, and the like. This PES header 601 corresponds to the PES headers shown in FIGS. 1 (f), 5 (d), 6 (d), and the like.

Further, as shown in FIG. 8 (c), the stream PES header of FIG. 8 (d) includes a packet start code prefix, a stream ID (private stream 2), a PES packet length, a sub stream ID, and the like. This stream PES header is the same as the stream PES header of FIG. 22 described later, and has the contents corresponding to the PES header 601 of FIG. 8 (a).

When the PES header in Fig. 1 (f) has the internal structure of PES header 601 shown in Fig. 8 (a), according to the MPEG standard, the stream ID 603 (Fig. 8 (b)) of this PES header is "10111110". Occasionally, a packet with this PES header is defined as a padding packet (see Figure 12 (g) below).

On the other hand, when the stream ID 603 (substream ID in FIG. 8C) is "00000010", the packet with the PES packet includes the stream recorded data.

In stream block # 1 of FIG. 1 (c), the last transport packet g (FIG. 1 (g)) exists in sectors No. 0 to No. 31 (FIG. 1 (e)). However, in stream block # 2 (Fig. 1 (e) (g)), when recording is terminated in the middle by a user or the like, the last transport packet (not shown) is placed in a sector before the last sector. The last sector (not shown) may be a free area where stream data is not recorded. In this case, the padding packet (the padding packet 40 of FIG. 12 (g) described later) is recorded in the last sector.

FIG. 9 is a diagram illustrating the internal structure of the stream block header shown in FIG.

As shown in FIG. 9A, the stream block header 11 has contents corresponding to a substream ID, an application header, an application header extension, a stuffing byte, and the like.

In the 1-byte application header extension (optional), 1-bit AU_START, 1-bit AU_END, and 2-bit COPYRIGHT are described.

When AU_START is set to "1", it indicates that the associated application packet (eg AP in Figure 29) contains a random access entry point (starting a random access unit) in the stream.

When AU_END is set to "1", it indicates that the associated application packet is the last packet of the random access unit.

The copyright status of related application packets is described in COPYRIGHT.

As shown in FIG. 9B, the stream block header 11 includes transport packet information 611, stream block information 612, sector data header information 613, and the like.

The transport packet information 611 in FIG. 9 (b) refers to the same as the transport packet information 611 in FIG. 9 (c).

The stream block information 612 in FIG. 9 (b), in which information about the entire stream block is recorded, has a recording time 622 (date and time information recorded in the information storage medium 201) and a transport packet in FIG. 9 (c). It corresponds to attribute 623 (attribute information about transport packets), stream block size 624 (data size of the corresponding stream block (for example, it can be described by the number of ECC blocks)), stream block time difference 625, and so on.

Here, taking Fig. 5 (b) as an example, the time range information in the corresponding stream block is [stream block time difference] = [first time stamp value in stream block # 2]-[time stamp a Value] is calculated. This [stream block time difference] becomes the stream block time difference 625.

Further, the sector data header information 613 of FIG. 9B corresponds to the first access point 626 and the transport packet connection flag 627 of FIG. 9C. This sector data header information 613 includes the same information as the sector data header 12 of FIG. 10 which will be described later.

As shown in FIG. 9 (d), the transport packet information 611 of FIG. 9 (c) includes the number of transport packets (number of application packets) 631, the transport packet mapping table 632, and the like.

The number of application packets in FIG. 9 (d) corresponds to the number of packets AP_Ns in FIG. 10 (c) or FIG. 11 described later.

As shown in FIG. 9 (e), the number 631 of transport packets (application packets) in FIG. 9 (d) can include the I picture mapping table 641, the B, P picture mapping table 642, and the like.

Further, the transport packet mapping table 632 of FIG. 9D can include a video packet mapping table 643, an audio packet mapping table 644, a program-specific information mapping table 645, and the like.

Each mapping table (Fig. 9 (e)) in the transport packet mapping table 632 is configured in bitmap format.

For example, when n transport packets (application packets) are recorded in one stream block, the value of the number of transport packets (number of application packets) 631 in Fig. 9 (d) is "n". It becomes.

Furthermore, each mapping table 643 to 645 consists of "n-bit data", and one bit is assigned to each transport packet (application packet) arranged from the front in the stream block.

FIG. 10 is a diagram illustrating the internal structure of the sector data header shown in FIG.

For example, the sector data header 17 in FIG. 1 (f) shows the data arrangement information in the data areas 22 and 23, and the sector data header in FIG. 10 (a) (corresponding to the application header in FIG. 10 (d)) 12 Corresponds to.

The sector data header 12 has an internal structure including a first access point 651 and a transport packet connection flag 652, as shown in FIG. 10 (b).

By the way, as shown in FIG. 10D, one stream pack having a size of 2048 bytes, which is the same as one sector, is composed of a pack header and a stream PES header. Then, the stream PES packet includes an application packet header corresponding to a part of the sector data header 12 of FIG. 10A or the stream block header 11 of FIG. 9A.

This application packet header contains the following, as shown in Figure 10 (c): * Version of the application packet header format; * Number of application packets (transport packets) starting in the relevant stream pack AP_Ns; * First application packet time stamp position FIRST_AP_OFFSET; * Header extension and / or stuffing that describes the position of the time stamp of the first application packet starting in the relevant stream pack as a relative value from the first byte of the stream pack. Extension header information indicating whether or not a byte exists EXTENSION_HEADER_IFO; * The identifier of the service that generated the corresponding stream SERVICE_ID.

FIRST_AP_OFFSET included in the application packet of FIG. 10 (d) corresponds to the first access point 651 included in the sector data header 12 of FIG. 10 (a).

As shown in FIG. 1 (g), the transport packet d is recorded across two sectors. Here, when the last time stamp in the sector or the transport packet spans the next sector, the transport packet connection flag 652 is set to "1".

In the example of Fig. 1 (g), the address in the data area 22 at the beginning of the time stamp that comes after the transport packet d that spans the next sector is recorded in the first access point 651 (in bit units). Has been done.

Set the first access point value of sector No. 1 (or its corresponding stream pack) shown in Fig. 1 (e) to a value larger than the size of data area 22 (Fig. 1 (f)) of sector No. 1. Can be done. By doing so, it is shown that the position of the time stamp corresponding to the packet following the packet recorded in the sector No. 1 exists in the next and subsequent sectors.

In one embodiment of the invention, the value of the first access point 651 can be larger than the size of the data areas 21, 22, and 23, so that it is larger than the sector size (or stream pack size = 2048 bytes). The time stamp start position can be specified even for a packet having a large size.

For example, in the data structure of FIG. 1, one packet is recorded across sector No. 0 to sector No. 2. Further, the time stamp for the packet is recorded in the first position in the data area 21 of sector No. 0, and the time stamp for the next packet is placed in the T bit in the data area of sector No. 2. Consider the case.

In this case, the value of the first access point of sector No. 0 is "0", the value of the first access point of sector No. 1 is "data area 22 size of sector No. 1 + T", and the first access of sector No. 2 The value of the point is "T".

FIG. 11 is a diagram illustrating another example of the time map information 252 according to the embodiment of the present invention.

This time map information 252 is a different example from the time map information 252 in FIGS. 3 (h) and 3 (i), and for each stream block (first stream block, second stream block, ...), Table information that describes the stream block size, stream block time difference, and number of packets (AP_Ns).

It is assumed that the total number of transport packets (or the total number of application packets AP_Ns) is specified (from the STB side) in order to access a predetermined screen (picture) using the time map information 252 in FIG. Then, (on the disk device side), the number of transport packets (AP_Ns) is sequentially added from the first stream block in FIG. 11, and the stream block is accessed when the specified value is reached.

FIG. 12 is a diagram illustrating an example of the internal configuration (stream pack including application packets and stream pack including stuffing packets) of the sectors constituting the stream block (SOBU).

As shown in FIGS. 12 (c) and 12 (e), the stream objects (SOB) # A and 298 of FIG. 12 (d) are composed of a plurality of stream blocks # 1, # 2, ....

Each stream block # 1, # 2, ... is composed of a stream object unit (SOBU) with a 2ECC block size (= 32 sectors = 64 kbytes).

In this way, for example, even if stream block (SOBU) # 2 is deleted, the ECC block of stream block (SOBU) # 1 is not affected by this deletion.

As shown in FIG. 12 (b), the first stream block (SOBU) # 1 of SOB # A / 298 is composed of sector No. 0 to sector No. 31 (32 sectors / 64 kbytes).

Each sector of stream block (SOBU) # 1 has a similar data structure. For example, sector No. 0 is as shown in FIG. 12 (a).

That is, sector No. 0 is composed of a stream pack of 2048 bytes (2 kbytes). This stream pack consists of a 14-byte pack header and a 2034-byte stream PES packet.

A stream PES packet consists of a 6-byte PES header, a 1-byte substream ID, and a 2027-byte stream data area.

The stream data area consists of a 9-byte application header, an application header extension (optional), a stuffing byte (optional), and an application packet area.

The application packet area is composed of a group of application packets each having an application time stamp (ATS) at the beginning.

For example, when a 188-byte size transport packet is stored as an application packet in the application packet area, about 10 application packets can be stored in the application packet area.

In stream recording, the application that generates the recorded content performs stuffing by itself so that it is not necessary to adjust the pack length separately. Therefore, in stream recording, the stream pack can always be treated as having the required length (for example, 2048 bytes).

The stuffing bytes in Figure 12 (a) can be used to keep the stream pack at a given length (2048 bytes) at all times.

Although not shown, the pack header of FIG. 12 (a) contains pack start code information, SCR-based information, SCR extension information, program maximum rate information, marker bits, pack stuffing length information, and the like.

The SCR base consists of 32 bits, and the 32nd bit is zero. In addition, 10.08 Mbps is adopted as the maximum program rate.

The PES header and substream ID in FIG. 12 (a) have the contents as shown in FIG. 8 (c).

As shown in FIG. 10 (c), the application header of FIG. 12 (a) includes version information, the number of application packets AP_Ns, the time stamp position FIRST_AP_OFFSET of the first application packet, the extension header information EXTENSION_HEADER_IFO, the service ID, and the like. ..

Here, the version number of the application header format is described in the version.

AP_Ns in the application header describes the number of application packets that start in the relevant stream pack. When the first byte of ATS is stored in the corresponding stream pack, it can be considered that the application packet starts in this stream pack.

In FIRST_AP_OFFSET, the time stamp position of the first application packet started in the corresponding stream packet is described in byte units as a relative value from the first byte of this stream packet. If there is no application packet to start in the stream packet, "0" is described in FIRST_AP_OFFSET.

EXTENSION_HEADER_INFO describes whether the application header extension and / or stuffing byte exists in the corresponding stream packet.

If the content of EXTENSION_HEADER_INFO is 00b, it indicates that there are no application header extensions or stuffing bytes after the application header.

If the content of EXTENSION_HEADER_INFO is 10b, it indicates that there is an application header extension after the application header, but there is no stuffing byte.

If the content of EXTENSION_HEADER_INFO is 11b, it indicates that the application header extension exists after the application header and that the stuffing byte also exists after the application header extension.

It is prohibited that the content of EXTENSION_HEADER_INFO is 01b.

The stuffing byte (optional) before the application packet area is activated by "EXTENSION_HEADER_INFO = 11b". By doing so, it is possible to prevent the "packing paradox" from occurring when there is a contradiction between the number of bytes in the application header extension and the number of application packets that can be stored in the application packet area.

In SERVICE_ID, the ID of the service that creates the stream is described. If this service is unknown, 0x0000 is described in SERVICE_ID.

The application packet area of FIG. 12 (a) can be configured in the same manner as shown in the lower part of FIG. 22 described later (the packet of FIG. 22 is read as an application packet in FIG. 12).

That is, the partial application packet is recorded at the beginning of the application packet area, then a plurality of pairs of the application time stamp ATS and the application packet are sequentially recorded, and the partial application packet is recorded at the end.

In other words, a partial application packet can exist at the start position of the application packet area. At the end position of the application packet area, there can be a partial application packet or a stuffing area with a reserved number of bytes.

The application time stamp (ATS) placed before each application packet consists of 32 bits (4 bytes). This ATS is divided into two parts: the basic part and the extended part. The basic part is the part called the 90kHz unit value, and the extended part shows the small value (less significant value) measured at 27MHz.

In FIG. 12 (a), the application header extension can be used to store information that may differ between application packets. Such information is not always required for all applications.

Therefore, the application header data fields are defined so that it can be stated (in EXTENSION_HEADER_INFO above) that an optional application header extension exists within the stream data area.

At the time of recording the stream, the first byte of the application time stamp ATS of the first application packet must be aligned with the start position of the application packet area in the first stream packet at the beginning of the stream object SOB.

On the other hand, for subsequent stream packets in the SOB, the application packet may be split at the adjacent stream packet boundary.

The partial application packet shown in FIG. 22 or FIG. 23 (f) (g), which will be described later, shows the application packet generated by this split.

The byte offset of the first application timestamp initiated within the stream packet and the number of application packets initiated within the stream packet are described in the application header.

By doing so, stuffing within a stream packet is automatically performed before the first application time stamp and after the last application packet.

That is, the above automation mechanism realizes that "the application stuffs itself". This automatic stuffing ensures that stream packets always have the required length.

The application header extension (optional) consists of a list of entries. There is one 1-byte long entry for each application packet that starts within the stream packet. The bytes of these entries can be used to store information that may vary from application packet to application packet.

In the 1-byte application header extension (optional), 1-bit AU_START, 1-bit AU_END, and 2-bit COPYRIGHT are described.

When AU_START is set to "1", it indicates that the associated application packet contains a random access entry point (start of a random access unit) in the stream.

When AU_END is set to "1", it indicates that the associated application packet is the last packet of the random access unit.

The copyright status of related application packets is described in COPYRIGHT.

The packet structure of FIG. 12 (a) can be applied to other than the last sector of SOB # A · 298, but it is not necessarily applied to the last sector.

For example, if SOB # A · 298 ends in sector No. 63 in FIG. 12 (f) and this sector is composed of padding packets 40 as shown in FIG. 12 (g), the padding area 38 ( The contents of FIG. 12 (h)) are different from those of FIG. 12 (a).

That is, as shown in FIG. 12 (i), the stuffing packet as the padding packet 40 includes a 14-byte pack header, a 6-byte PES header, a 1-byte substream ID, and a 9-byte application header. It consists of a 2018 byte application packet area.

In a pack containing the beginning of a stuffing packet, this application packet area consists of a 4-byte application timestamp ATS and 2014 bytes of zero-byte data (data with no substantial record).

On the other hand, in a pack containing its subsequent stuffing packets, this application packet area consists of 2018 bytes of zero-byte data (without ATS).

By the way, when a record with an extremely low bit rate is made, stuffing is required to ensure the recovery (reproduction) of the time map information (252 in Fig. 3 (h); or MAPL in SOBI in Fig. 15 described later). become. The stuffing packet in Figure 12 (i) is defined as a conceptual unit for that purpose.

The purpose of this stuffing packet is achieved by ensuring that each SOBU, including the stuffing area, contains at least one ATS value.

Stuffing packets are subject to the following conditions: * 1 or more stuffing packets always start in the application packet area of the pack after the pack containing the actual application packet data; * 1 or more stuffing packets It consists of one 4-byte ATS and as much zero-byte data (following the ATS) as needed to fill the application data area of the remaining pack of the SOBU. Now, when the number of sectors per SOBU is SOBU_SIZ and 0 n SOBU_SIZ-1, the total length of the stuffing packet is "4 + 2014 + n x 2018" bytes.

The ATS of a stuffing packet is set as follows: * Within a SOBU where at least one pack contains the actual application packet data, the ATS of the stuffing packet becomes the ATS of the application packet that precedes the stuffing packet. Set; * In SOBU that does not include the actual application packet data, the ATS of the stuffing packet is determined according to the contents such as time map information.

All packs containing stuffing packets or parts of stuffing packets are configured as follows: * The SCR in the pack header shall be the SCR of the preceding pack plus "2048 x 8 bits ÷ 10.08 Mbps". * PES packet header and substream ID should be the same for all other PES packets; * In the application header (see Figure 10 (c) (d)), AP_Ns = 0, FIRST_AP_OFFSET = 0, EXTENSION_HEADER_IFO = 00b, SERVICE_ID = 0 (other parameters in the application header are also 0).

FIG. 13 is a diagram illustrating an internal data structure of streamer management information (corresponding to STREAM.IFO or SR_MANGR.IFO in FIG. 2).

STREAM.IFO (SR_MANGR.IFO) 105, which is the management information (navigation data) shown in FIG. 2 or FIG. 3 (e), includes streamer information STRI as shown in FIG.

As shown in Fig. 3 (f) or Fig. 13, this streamer information STRI includes streamer video manager information STR_VMGI, stream file information table SFIT, and original PGC information ORG_PGCI (more generally, PGC information PGCI # i). ), The user-defined PGC information table UD_PGCIT, the text data manager TXTDT_MG, and the application private data manager APDT_MG.

As shown in FIG. 13, the streamer video manager information STR_VMGI is a play in which the video manager information management information VTSI_MAT in which management information related to STRI and STR_VMGI is described and a search pointer for searching a playlist in the stream are described. Contains a list search pointer table (PL_SRPT).

Here, a playlist is a list of a part of a program. This playlist allows the user to define any playback sequence (for the contents of the program).

The stream file information table SFIT contains all navigation data directly related to the streamer operation. The details of the stream file information table SFIT will be described later with reference to FIG.

Original PGC information ORG_PGCI is a part that describes information about the original PGC (ORG_PGC). ORG_PGC indicates navigation data that describes the program set. ORG_PGC is a chain of programs and contains stream data recorded in the ".SRO" file (SR_TRANS.SRO106 in FIG. 2) of FIG. 2 or FIG. 18 described later.

Here, the program set indicates the entire recorded contents (all programs) of the information storage medium 201. In the reproduction of the program set, the same reproduction order as the recording order of the program is used as the reproduction order unless an arbitrary program is edited and the reproduction order is changed with respect to the original recording. This program set supports a data structure called the original PGC (ORG_PGC).

A program is a logical unit of recorded content that is recognized by the user or defined by the user. The program in the program set consists of one or more original cells. The program is defined only within the original PGC.

In addition, cells are data structures that represent parts of a program. The cells in the original PGC are called "original cells", and the cells in the user-defined PGC described later are called "user-defined cells".

Each program in the program set consists of at least one original cell. Also, each part of the program in each playlist is composed of at least one user-defined cell.

On the other hand, in the streamer, only the stream cell (SC) is defined. Each stream cell refers to a portion of the recorded bitstream. In the embodiment of the present invention, when the term "cell" is used without particular notice, it means a "stream cell".

The program chain (PGC) is a superordinate conceptual unit. In the original PGC, PGC refers to a chain of programs corresponding to a program set. Also, in user-defined PGCs, PGCs refer to a chain of programs that correspond to playlists.

Also, a user-defined PGC that points to a chain of parts of a program contains only navigation data. Then, a part of each program refers to the stream data belonging to the original PGC.

The user-defined PGC information table UD_PGCIT in FIG. 13 can include user-defined PGC information table information UD_PGCITI, one or more user-defined PGC search pointers UD_PGC_SRP # n, and one or more user-defined PGC information UD_PGCI # n.

Although not shown, the user-defined PGC information table information UD_PGCITI includes UD_PGC_SRP_Ns indicating the number of user-defined PGC search pointers UD_PGC_SRP and UD_PGCIT_EA indicating the end address of the user-defined PGC information table UD_PGCIT.

The number of UD_PGC_SRP indicated by UD_PGC_SRP_Ns is the same as the number of user-defined PGC information (UD_PGCI) and the same as the number of user-defined PGC (UD_PGC). This number is allowed up to "99".

UD_PGCIT_EA describes the end address of the corresponding UD_PGCIT as the number of bytes (F_RBN) relative to the first byte of the UD_PGCIT.

Here, F_RBN indicates the number of bytes relative to the first byte of the defined field in the file, starting from zero.

The PGCI # i, which generally represents the user-defined PGC information UD_PGCI in the original PGC information ORG_PGCI or the user-defined PGC information table UD_PGCIT, will be described later with reference to FIG.

The text data manager TXTDT_MG in FIG. 13 is supplementary text information. This TXTDT_MG can be stored in playlists and programs along with the primary text information PRM_TXTI in Figure 14.

Although not shown, the application private data manager APDT_M in FIG. 13 can include application private data manager general information APDT_GI, one or more APDT search pointers APDT_SRP # n, and one or more APDT area APADTA # n.

Here, the application private data APDT is a conceptual area in which an application device connected to the streamer can store arbitrary non-real-time information (more desired information in addition to real-time stream data).

FIG. 14 is a diagram illustrating an internal data structure of PGC information (ORG_PGCI / UD_PGCIT in FIG. 3 or PGCI # i in FIG. 13).

The PGC information PGCI # i in FIG. 14 is a general representation of the original PGC information ORG_PGCI in FIG. 13 or the user-defined PGC information UD_PGCI in the user-defined PGC information table UD_PGCIT.

As shown in FIG. 14, PGC information PGCI # i includes PGC general information PGC_GI, one or more program information PGI # m, one or more stream cell information search pointer SCI_SRP # n, and one or more stream cell information SCI. It is composed of #n.

The PGC general information PGC_GI includes the number of programs PG_Ns and the number of stream cell information search pointers SCI_SRP SCI_SRP_Ns.

Each program information PGI (eg PGI # 1) contains the program type PG_TY, the number of cells in the program C_Ns, the program's primary text information PRM_TXTI, and the item text search pointer number IT_TXT_SRPN.

Here, the program type PG_TY includes information indicating the state of the corresponding program. In particular, it includes a flag indicating whether or not the program is protected from accidental erasure, that is, a protect flag.

When this protect flag is "0b", the corresponding program is not protected, and when it is "1b", it is in a protected state.

Number of cells C_Ns indicates the number of cells in the program. Throughout all PGC programs and all cells, cells are (implicitly) attached to the program in ascending order.

For example, if program # 1 has C_Ns = 1 and program # 2 has C_Ns = 2 in PGC, then the first stream cell information SCI of that PGC will be attached to program # 1, and the second, The third SCI will accompany program # 2.

Primary text information PRM_TXTI describes text information with one common character set (ISO / IEC 646: 1983 (ASCII code)) in order to make the information storage medium (DVD-RAM disk) 201 available worldwide. It was done.

The search pointer number IT_TXT_SRPN of the item text describes the search pointer number for the item text (text data corresponding to the corresponding program) IT_TXT. If the program does not have an item text, IT_TXT_SRPN is set to "0000h".

Each stream cell information search pointer SCI_SRP (eg SCI_SRP # 1) contains SCI_SA indicating the start address of the corresponding stream cell information SCI. This SCI_SA is described by the number of bytes relative to the first byte of PGCI (F_RBN).

Each stream cell information SCI (for example, SCI # 1) is composed of stream cell general information SC_GI and one or more stream cell entry point information SC_EPI # n.

The stream cell general information SC_GI includes the cell type C_TY including the flag TE indicating the temporary erase (TE) state, the number SC_EPI_Ns of the stream cell entry point information, the stream object number SOB_N, and the stream cell start APAT (Figure). 6 SC_S_APAT shown elsewhere, stream cell end APAT (SC_E_APAT shown in Figure 6 others), and erase start APAT indicating the start APAT of the temporary erase cell when the cell is in the temporary erase state (TE = 10b). Includes (ERA_S_APAT shown in Fig. 6 et al.) And Erase end APAT (ERA_E_APAT shown in Fig. 6 et al.), Which indicates the end APAT of the temporarily erased cell when the cell is in the temporary erase state (TE = 10b). There is.

The cell type C_TY describes the format of the relevant stream cell and its temporary deletion status.

That is, the cell format C_TY1 = "010b" is described in the format of all stream cells (this C_TY1 = "010b" can distinguish between stream cells and other cells).

On the other hand, if the flag TE is "00b", it indicates that the cell is in the normal state, and if the flag TE is "01b" or "10b", it indicates that the cell is in the temporary erase state. ..

Flag TE = "01b" indicates that the cell (cell in temporary erase state) starts after the first application packet that starts in SOBU and ends before the last application packet in the same SOBU. ..

Further, the flag TE = "10b" indicates a case where the corresponding cell (cell in the temporarily erased state) includes at least one SOBU boundary (the first application packet or the last application packet starts in the SOBU).

The protect flag of the program and the TE flag of the cell in the program cannot be set at the same time. Therefore, (a) none of the cells in the program in the protected state can be set to the temporarily erased state; (b) the program containing one or more cells in the temporarily erased state cannot be set to the protected state.

The number of stream cell entry point information SC_EPI_Ns describes the number of stream cell entry point information included in the corresponding stream cell information SCI.

There are two types (type A and type B) of each stream cell entry point information SC_EPI (for example, SC_EPI # 1) in FIG.

The type A SC_EPI contains the entry point type EP_TY and the entry point application packet arrival time EP_APAT. Type A is indicated by the entry point type EP_TY1 = "00b".

Type B SC_EPI contains primary text information PRM_TXTI in addition to Type A EP_TY and EP_APAT. Type B is indicated by entry point type EP_TY1 = "01b".

In any stream cell, the entry point can be used as a tool to skip a part of the recorded contents. All entry points can be identified by the application packet arrival time (APAT). With this APAT, it is possible to identify where the data output starts.

The stream object number SOB_N describes the SOB number referenced by the corresponding cell.

The stream cell start APAT (SC_S_APAT) describes the start APAT of the corresponding cell.

Stream cell end APAT (SC_E_APAT) describes the end APAT of the corresponding cell.

The erase start APAT (ERA_S_APAT) is the first temporary erase cell that contains at least one SOBU boundary (the TE field of its C_TY is "10b") to start within the first SOBU that contains the beginning of this temporary erase cell. It describes the arrival time (APAT) of the application packet.

End of Erase APAT (ERA_E_APAT) is the first start in a temporary erase cell containing at least one SOBU boundary (the TE field of its C_TY is "10b") in the SOBU containing the application packet immediately following the temporary erase cell. It describes the arrival time (APAT) of the application packet.

FIG. 15 is a diagram illustrating the internal data structure of the stream file information table (SFIT).

As shown in FIG. 15, the stream file information table SFIT is composed of the stream file information table information SFITI, one or more stream object stream information SOB_STI # n, and the stream file information SFI.

Stream file information table information SFITI is the number of stream file information SFI_Ns on the information storage medium (DVD-RAM disk) 201, the number of stream object stream information following SFITI SOB_STI_Ns, the end address of SFIT SFIT_EA, and the start of SFI. Consists of address SFI_SA.

SFIT_EA describes the end address of SFIT by the number of bytes (F_RBN) relative to the first byte of SFIT.

In addition, SFI_SA describes the start address of SFI by the number of bytes (F_RBN) relative to the first byte of SFIT.

Each stream object stream information SOB_STI contains three types of parameters. Each parameter can have a unique value for each bitstream recording. However, in many bitstream recordings these parameter sets can usually be equal. Therefore, SOB_STI is stored in a separate table from the Stream Object Information (SOBI) table, allowing several stream objects (SOBs) to share the same SOB_STI (ie point to the same SOB_STI). There is. Therefore, the number of SOB_STIs is usually smaller than the number of SOBs.

Each stream object stream information SOB_STI (eg SOB_STI # 1) in Figure 15 contains the application packet size AP_SIZ, the number of service IDs SERV_ID_Ns, the service IDs (SERV_IDs), and the application packet device unique ID (AP_DEV_UID). ..

AP_SIZ is the byte length of the packet in the bitstream transferred from the application device to the streamer and describes the application packet size.

In the DVD streamer, the application packet size is constant in each bitstream recording. Therefore, if the application packet size changes during each uninterrupted recording, the current stream object (current SOB) will be terminated there and a new stream object (new SOB) will be replaced by a new AP_SIZ. Is started with. At that time, both the current SOB and the new SOB belong to the same program in the original PGC information (ORG_PGCI).

SERV_ID_Ns describes the number of service IDs included in the subsequent parameters.

SERV_IDs is a list of service IDs in any order.

AP_DEV_UID describes a unique device ID unique to the application device that supplied the recorded bitstream.

As shown in FIG. 15, the stream file information SFI includes stream file general information SF_GI, one or more stream object information (SOB information) search pointer (SOBI_SRP) # n, and one or more SOB information (SOBI) # n. It is composed of.

Stream file general information SF_GI includes the number of SOBIs SOBI_Ns, the number of sectors per SOBU SOBU_SIZ, and MTU_SHFT which is a kind of time map information.

Here, SOBU_SIZ describes the size of SOBU in terms of the number of sectors, and this size is constant at 32 (32 sectors = 64 kbytes). This means that within each timemap information (MAPL), the first entry pertains to an application packet contained within the first 32 sectors of the SOB. Similarly, the second entry pertains to application packets contained in the next 32 sectors. The same applies to the third and subsequent entries.

Each SOB information search pointer (eg SOBI_SRP # 1) contains the SOBI start address SOBI_SA. This SOBI_SA describes the start address of the related SOBI by the number of bytes (F_RBN) relative to the first byte of the stream file information SFI.

Each SOB information (for example, SOBI # 1) is composed of stream object general information SOB_GI, time map information MAPL, and access unit data AUD (optional).

Stream object general information SOB_GI includes stream object type SOB_TY, stream object recording time SOB_REC_TM, stream object stream information number SOB_STI_N, access unit data flag AUD_FLAGS, stream object start application packet arrival time SOB_S_APAT, and stream object. Includes the end application packet arrival time SOB_E_APAT, the first stream object unit SOB_S_SOBU of the corresponding stream object, and the number of time map information entries MAPL_ENT_Ns.

The stream object type SOB_TY is the part that can describe the bit indicating the temporary erase state (TE state) and / or the bit of the copy generation management system.

Stream object recording time SOB_REC_TM describes the recording time of the related stream object (SOB).

The stream information number SOB_STI_N of the stream object describes the valid SOB_STI index for the stream object.

The access unit data flag AUD_FLAGS describes whether or not access unit data (AUD) exists for the relevant stream object, and if so, what kind of access unit data it is.

If access unit data (AUD) is present, AUD_FLAGS describes some characteristics of the AUD.

As shown in FIG. 15, the access unit data (AUD) itself is composed of the access unit general information AU_GI, the access unit end map AUEM, and the playback time stamp list PTSL.

The access unit general information AU_GI includes AU_Ns indicating the number of access units described for the corresponding SOB and an access unit start map AUSM indicating which SOBU belonging to the corresponding SOB includes the access unit.

The access unit end map AUEM is a bit array of the same length as the AUSM (if present) and indicates which SOBU contains the end of the bitstream segment associated with the access unit of the SOB.

Playback time stamp list PTSL is a list of playback time stamps of all access units belonging to the corresponding SOB. One PTSL element in this list contains the Play Timestamp (PTS) value for the corresponding access unit.

The access unit (AU) refers to any single continuous portion of the recorded bitstream and is configured to be suitable for individual playback. For example, in an audio / video bitstream, the access unit is usually the part that corresponds to the MPEG I-picture.

Here, I will return to the explanation of SOB_GI again.

AUD_FLAGS includes the flag RTAU_FLG, the flag AUD_FLG, the flag AUEM_FLG, and the flag PTSL_FLG.

When the flag RTAU_FLG is 0b, it is indicated that there is no access unit flag in the real-time data of the corresponding SOB.

When the flag RTAU_FLG is 1b, it is shown that the AU flags (AU_START, AU_END) described in the application header extension of Fig. 9 (a) or Fig. 12 (a) can exist in the real-time data of the corresponding SOB. Is done. This state is also allowed when the following AUD_FLG is 0b.

When the flag AUD_FLG is 0b, it indicates that there is no access unit data (AUD) for the corresponding SOB.

When the flag AUD_FLG is 1b, it indicates that access unit data (AUD) may exist for the corresponding SOB.

When the flag AUEM_FLG is 0b, it indicates that AUEM does not exist in the corresponding SOB.

When the flag AUEM_FLG is 1b, it indicates that AUEM exists in the corresponding SOB.

When the flag PTSL_FLG is 0b, it indicates that PTSL does not exist in the corresponding SOB.

When the flag PTSL_FLG is 1b, it indicates that PTSL exists in the corresponding SOB.

SOB_S_APAT describes the start application packet arrival time of the stream object. That is, SOB_S_APAT indicates the arrival time of the first application packet belonging to the SOB.

This packet arrival time (PAT) is divided into two parts: the basic part and the extended part. The basic part is the part called the 90kHz unit value, and the extended part shows the small value (less significant value) measured at 27MHz.

SOB_E_APAT describes the end application packet arrival time of the stream object. That is, SOB_E_APAT indicates the arrival time of the last application packet belonging to the SOB.

SOB_S_SOBU describes the first stream object unit of the corresponding stream object. That is, SOB_S_SOBU indicates the SOBU that contains the start of the first application packet of the stream object.

MAPL_ENT_Ns describes the number of time map information (MAPL) entries that follow SOBI_GI.

The time map information MAPL has contents corresponding to the time map information 252 in FIG. 3 (h).

One of the relevance of the contents in Figures 13 and 15 can be summarized as follows: The streamer information STRI contained in management information 105 manages the stream object SOB that forms part of the contents of the stream data. Includes stream file information table SFIT. This SFIT contains the stream object information SOBI that manages the SOB. This SOBI includes access unit general information AU_GI including management information (access unit start map AUSM) and management information (PTSL).

Here, the management information (ATS or AUSM) includes the information used when transferring the stream data, and the management information (PTS or SC_S_APAT) includes the information used when displaying the stream data.

FIG. 16 is a diagram illustrating the correspondence between the access unit start map (AUSM; see FIG. 15) and the stream object unit (SOBU; see FIGS. 1, 4 to 6, and 12).

As shown, the bit "1" part of AUSM indicates that the corresponding SOBU contains an access unit (AU).

Now, let's assume that the i-th (1 i AU_Ns) bit position in which the bit is set in AUSM is AUSM_pos (i). Then, the location of the access unit AU is as follows.

(1) If SOBU # i indicated by AUSM_pos (i) contains one or more starting AUs (which are described by the AU_START and AU_END marks (if any) in the stream), then AUSM_pos (i) , Assigned to the first AU starting in SOBU # i. Here, SOBU # i is placed in SOBUs described by AUSM_pos (i) and AUEM_pos (i) (if AUEM exists).

(2) The AU ends with the AU_END mark that appears first after the start of this AU, and the AU ends with the last SOBU indicated by the assigned AUEM element (if AUEM exists).

In any access unit data, it is not possible to describe two or more accessible access units for each SOBU of SOB.

Figure 17 illustrates the correspondence between the access unit start map (AUSM; see Figure 15) and the access unit end map (AUEM; see Figure 15) and the stream object unit (SOBU; see Figure 2, Figure 4, and Figure 11). It is a figure to do.

AUEM is a bit array of the same length as AUSM (if any). The AUEM bit indicates which SOBU contains the end of the bitstream segment attached to the access unit of the corresponding SOB.

The number of bits set in AUEM matches the number of bits set in AUSM. That is, each setting bit in AUSM has a bit set correspondingly in AUEM.

Now, let AUSM_pos (i) be the i-th (1 i AU_Ns) bit position where the bit is set in AUSM, and set the i-th (1 i AU_Ns) bit position where the bit is set in AUEM. Try it as AUEM_pos (i). In this case, there is the following relationship.

(1) 1 AUSM_pos (i) AUEM_pos (i) MAPL_ENT_Ns; (2) AUSM_pos (i + 1)&gt; AUEM_pos (i); (3) If i == AU_Ns or AUSM_pos (i + 1)&gt; 1+ If AUEM_pos (i), AU # i ends with SOBU # [AUEM_pos (i)] (1 i AU_Ns); (4) If AUSM_pos (i + 1) == 1 + AUEM_pos (i), then AU # i ends with SOBU # [AUEM_pos (i)]. Alternatively, it ends at SOBU # [1 + AUEM_pos (i)] == SOBU # [AuSM_pos (i + 1)]. That is, AU # i ends when AU # i + 1 starts in SOBU (1 i AU_Ns).

FIG. 18 is a diagram illustrating how the cells specified by the original PGC or the user-defined PGC and the SOBUs corresponding to these cells are related by the time map information.

The user-defined PGC does not include its own SOB, but refers to the SOB in the original PGC. Therefore, a user-defined PGC can be described only by using PGC information. This means that an arbitrary playback sequence can be realized without tampering with the SOB data.

The user-defined PGC also does not include a program and is composed of a chain of cells corresponding to a part of the program in the original PGC.

An example of such a user-defined PGC is shown in FIG. This example shows the case where the user-defined PGC # n is created so that the cells in the PGC refer to the SOB in the original PGC.

In FIG. 18, PGC # n has four cells # 1 to # 4. Two of them refer to SOB # 1 and the other two refer to SOB # 2.

The solid arrow from the cell in the user-defined PGC to the original PGC (to SOBI timemap information) indicates the playback period for that cell. The cell reproduction order in the user-defined PGC may be completely different from the reproduction order in the original PGC.

Regeneration of any SOB and its SOBU is identified by the start APAT (S_APAT) and end APAT (E_APAT) in FIG.

The SOB or SOBU S_APAT is defined in relation to the time stamp recorded in the payload of the corresponding SOB stream pack (see Figure 1 (h), Figure 22, Figure 23).

During SOB recording, each incoming application packet is time stamped by the local clock reference in the streamer. This is the application packet arrival time (APAT).

The APAT of the first application packet of SOB is stored as SOB_S_APAT. The 4 least significant bytes of all APATs are pre-fixed for the corresponding application packets in the "~ .SRO" file.

In order to reproduce SOB or SOBU data, the reference clock inside the streamer is set to the SCR value, and then the clock is automatically counted. This SCR value is described in the first stream pack (in the pack header) where playback begins. Based on this clock, playback / output of all subsequent application packets from SOB or SOBU is executed.

If any stream cell (SC) specifies a stream cell start APAT (SC_S_APAT) with an arbitrary value between SOB_S_APAT and SOB_E_APAT of the SOB pointed to by that SC, the application packet with the desired APAT. You will need an address to find the SOBU that contains.

The number of stream packs per SOBU is constant, but the arrival time intervals captured by each SOBU are flexible. Therefore, each SOB has a time map information (MAPL) that describes the arrival time interval of the SOBU of the corresponding SOB. That is, the addressing scheme realized by timemap information (MAPL) points to a SOBU that can translate any APAT into a relative logical block address in the file to find the desired application packet.

FIG. 19 is a diagram illustrating a configuration of a stream data recording / playback system (optical disk device / streamer, STB device) according to an embodiment of the present invention. In this embodiment, a recordable / playable optical disc such as a DVD-RAM disc is assumed as the information storage medium 201.

Hereinafter, the internal structure of the stream data recording / playback device according to the embodiment of the present invention will be described with reference to FIG.

This stream data recording / playback device is composed of an optical disk device 415, an STB device 416, and peripheral devices thereof.

Peripheral devices include a video mixing unit 405, a frame memory unit 406, an external speaker 433, a personal computer (PC) 435, a monitor TV 437, a D / A converter 432, 436, and an I / F unit 431, 434.

The optical disk device 415 is a recording / playback unit 409 including a disk drive, and a data processor unit (hereinafter abbreviated as D-PRO unit) that processes stream data to the recording / playback unit 409 (or stream data from the recording / playback unit 409). It includes a 410, a temporary storage unit 411 that temporarily stores stream data overflowing from the D-PRO unit 410, and an optical disk device control unit 412 that controls the operations of the recording / playback unit 409 and the D-PRO unit 410.

The optical disk device 415 further receives a stream data sent from the STB device 416 via IEEE1394 or the like (or sends stream data to the STB device 416 via IEEE1394 or the like), and a data transfer interface unit 414 and a data transfer interface unit. With the formatter / deformer unit 413 that converts the stream data received by 414 into a signal format for recording on the information storage medium (RAM disk) 201 (or converts the stream data reproduced from the medium 201 into a signal format such as IEEE1394). It has.

Specifically, the IEEE1394 receiving side of the data transfer interface unit 414 reads the time from the start of stream data transfer based on the time count value of the reference clock generator (system time counter STC) 440.

Based on the above time information, the partition information that divides the stream data into stream blocks (or SOBU) is created, and the cell separation information and program separation information corresponding to this division information, as well as the PGC separation, are created. Create information.

The formatter / deformer unit 413 converts the stream data sent from the STB device 416 into a stream pack column (see FIGS. 12 (a), 23 (h), etc.), and converts the converted stream pack column into a stream pack column. Input to D-PRO section 410. The input stream pack has a fixed size of 2048 bytes, which is the same as the sector. The D-PRO unit 410 collects the input stream packs into ECC blocks for each 16 sectors and sends them to the recording / playback unit 409.

Here, when the recording / playback unit 409 is not ready for recording on the medium 201, the D-PRO unit 410 transfers the recorded data to the temporary storage unit 411 for temporary storage, and the recording / playback unit 409 performs the data. Wait until you are ready to record.

When the recording / playback unit 409 is ready for recording, the D-PRO unit 410 transfers the data stored in the temporary storage unit 411 to the recording / playback unit 409. As a result, recording on the medium 201 is started. After recording the data stored in the temporary storage unit 411, the subsequent data is seamlessly transferred from the formatter / deformer unit 413 to the D-PRO unit 410.

Here, the temporary storage unit 411 assumes a large-capacity memory so that it can be accessed at high speed and can hold recorded data for several minutes or more.

The time stamp information attached to the recording bit stream via the formatter / deformer unit 413 can be obtained from the reference clock generator (STC) 440.

Further, the time stamp information (SCR) extracted from the playback bit stream via the formatter / deformer unit 413 can be set in the STC440.

A reference clock (system clock reference SCR) is recorded in the pack header in the stream data recorded in the information storage medium 201. When reproducing the stream data (SOB or SOBU) recorded on the medium 201, the reference clock generator (STC) 440 is adapted to the reference clock (SCR) reproduced from the medium 201 (the value of SCR is Set to STC440).

That is, in order to reproduce SOB or SOBU data, the reference clock (STC440) in the streamer (optical disk device 415) is set to the system clock reference SCR described in the first stream pack in which reproduction is started. After that, the STC440 counts up automatically.

The STB section 416 demodulates the contents of the digital broadcast radio wave received by the satellite antenna 421, and demodulates with a demodulator 422 that provides demodulated data (stream data) in which one or more programs are multiplexed, and a demodulator 422. It is provided with a reception information selector unit 423 that selects information on a specific program (desired by the user) from data (transport packet of program 2 in the case of FIG. 23 described later as an example).

When recording the information (transport packet) of the specific program selected by the reception information selector unit 423 on the information storage medium 201, the selector unit 423 records only the transport packet of the specific program according to the instruction of the STB control unit 404. The included stream data is sent to the data transfer interface unit 414 of the optical disk device 415 by IEEE1394 transfer via the data transfer interface unit 20.

If you just want to watch the information (transport packet) of the specific program selected by the reception information selector unit 423 without recording it, the selector unit 423 follows the instruction of the STB control unit 404 and the selector unit 423 transport packet of the specific program. The stream data containing only the data is sent to the multiplexing information separation unit 425 of the decoder unit 402.

On the other hand, when playing back a program recorded on the information storage medium 201, the stream data sent from the optical disk device 415 to the STB device 416 via the IEEE1394 serial bus is sent to the decoder section 402 via the selector section 423. It is sent to the multiplexing information separation unit 425.

The multiplexing information separation unit 425 classifies various packets (video packets, audio packets, sub-picture packets) included in the stream data sent from the selector unit 423 on the internal memory unit 426 according to the ID of each packet. .. Then, the divided packets are distributed to the corresponding decoding units (video decoding unit 428, sub-picture decoding unit 429, and audio decoding unit 430, respectively.

The video decoding unit 428 decodes the (MPEG-encoded) video packet sent from the multiplexing information separation unit 425 to generate video data. At that time, the video decoding unit 428 has a built-in representative image (thumbnail) generation unit 439 in order to have a function of generating a reduced image (thumbnail picture) representing the recorded content from the I picture in the MPEG video data. There is.

Video decoded by video decoding unit 428 (and / or representative image generated by generation unit 439), sub-pictures decoded by sub-picture decoding unit 429 (information such as subtitles and menus), and audio decoding unit 430. The audio decoded by is transmitted to the video mixing unit 405 via the video processor unit 438.

The video mixing unit 405 uses the frame memory unit 406 to create a digital image in which subtitles and the like are superimposed on the moving image. This digital image is converted into an analog image via the D / A converter 436 and sent to the monitor TV 437.

Further, the digital image from the video mixing unit 405 is appropriately captured in the personal computer 435 via the signal lines such as the I / F unit 434 and the IEEE 194.

On the other hand, the digital audio information decoded by the audio decoding unit 430 is sent to the external speaker 433 via the D / A converter 432 and an audio amplifier (not shown). Further, the decoded audio information is digitally output to the outside via the I / F section 431.

The operation timing in the STB device 416 is determined by the clock from the system time counter (STC) unit 424.

The above-mentioned instructions and the like by the STB control unit 404 (operation control of each internal configuration of the STB device 416) are executed by the control program stored in the program memory unit 404a. At that time, the work memory unit 407 is appropriately used in the control process by the STB control unit 404.

The timing of the internal operation of the STB device 416 including the STB control unit 404 and the decoder unit 402 can be regulated by the clock from the STC unit 424. Further, by synchronizing the STC440 of the optical disk device 415 and the STC unit 424 of the STB device 416, the operation timing of the entire streamer system including the optical disk device 415 and the STB device 416 can be regulated.

As a method of synchronizing the STC440 and the STC unit 424, the STC440 and the STC unit 424 are set by the reference clock (SCR) in the stream data passed between the data transfer interface unit 414 and the data transfer interface unit 420. There is.

Looking at the device configuration in FIG. 19 by function, the STB device 416 contains a "reception time management unit", a "stream data content analysis unit", a "stream data transfer unit", and a "time-related information generation unit". Can be divided / classified into.

Here, the "reception time management unit" is composed of a demodulator (demodulation unit) 422, a reception information selector unit 423, a multiplexing information separation unit 425, an STB control unit 404, and the like. This "reception time management unit" receives the digital TV broadcast by the satellite antenna 421 and records the reception time for each transport packet in the received broadcast information.

The "stream data content analysis unit" is composed of a multiplexing information separation unit 425, an STB control unit 404, and the like. This "stream data content analysis unit" analyzes the contents of the received stream data and extracts each picture position and / or PTS value of I, B, and P.

The "stream data transfer unit" is composed of a multiplexing information separation unit 425, a reception information selector unit 423, an STB control unit 404, a data transfer interface unit 420, and the like. This "stream data transfer unit" transfers the stream data to the optical disk device 415 while maintaining the difference reception time interval for each transport packet.

The "time-related information generation unit" is composed of a multiplexing information separation unit 425, an STB control unit 404, a data transfer interface unit 420, and the like. This "time-related information generation unit" includes the reception time (time stamp) information recorded by the "reception time management unit" and the display time information (PTS value and / or the number of fields) extracted by the "stream data content analysis unit". Create relationship information between.

FIG. 20 is a diagram illustrating a time relationship table showing a relationship between a display time and a data transfer time in one embodiment of the present invention. The basic features of the present invention will be described with reference to FIG.

In the NTSC system, which is one of the TV display methods, 30 screens / pictures (frames) are displayed as video signals on the TV monitor screen per second. Since a normal TV uses an interlaced method, the screen is first scanned and displayed every other scanning line on one screen, and then the shifted images are scanned every other scanning line. This fills the space between the previous screens and displays one screen (picture). The image displayed every other image is called a field.

The NTSC system displays 30 frames / 60 fields per second. This NTSC system is a display system mainly used in Japan and the United States. On the other hand, the PAL method, which is mainly used in Europe, displays 25 frames / 50 fields per second.

FIG. 20A is a diagram in which screens / pictures (frames) that change 30 images per second are arranged according to a display time (presentation time; or playback time) 1.

Information representing the display time (playback time) 1 of the screen / picture includes (a) the method of expressing by "the number of difference fields from a specific screen (picture)"; (b) "PTS (presentation time stamp; or" There is a method of expressing with "playback time stamp)".

PTS can be used in a way that uses a 27MHz and / or 90kHz reference clock and represents the display time with a counter value that is constantly incrementing (counter value increments by 1). For example, the value of the counter when indicating each screen / picture (frame) with a counter that increments with a reference clock of 27 MHz (or 90 kHz) is used as the value of PTS.

The PTS value for each picture is included in the picture header information 41 (see FIG. 1 (j)) in the received signal information on the digital TV.

In FIG. 20 (a), the display time of the I picture a is represented by PTS No. 1, and the display times of the I pictures i and q are represented by PTS No. 2 and PTS No.3.

Now, for example, suppose that a user is instructed to display a screen (picture) hours, minutes, and seconds after the display of I picture a. Then, the above-mentioned designated time interval (after hours, minutes, and seconds) is converted into a count value of 27 MHz and / or 90 kHz. Then, the addition result of this converted value and the PTS value (PTS No. 1) displayed in I picture a can be calculated to search for the "screen (picture) to be displayed" instructed by the user.

Since the stream data recorded on the information storage medium 201 is recorded with a time stamp added to each transport packet as shown in FIG. 1 (g) and others, this time stamp information is used. Time management is performed for stream data.

However, since this time stamp information cannot be recognized by the user, the user uses the display time (playback time) 1 to specify the screen (picture) to be viewed.

In this case, information indicating the relationship between the time stamp information for managing the time of the stream data and the display time (playback time) 1 information that can be specified by the user is required. The information showing this relationship is the time relationship table 2 (or the reproduction time stamp list PTSL of FIG. 15) shown in FIG. 20 (b).

As illustrated in FIG. 20 (b), in the time relationship table 2, the corresponding data transfer time information (I picture) is displayed for each PTS value (PTSNo.1, PTSNo.2, PTSNo.3, ...). The transfer start time 4), data transfer time information (I picture transfer end time 5), and the total number of packets 10 from the beginning of the cell to the target I picture are described.

For example, looking at I picture a of PTS No. 1, the time stamp (ATS) # 1 of the line of data transfer time information (I picture transfer start time 4) is the first packet of I picture a information 7 in Fig. 2 (c). (AP) Corresponds to the time stamp (ATS) # 1 of # 1, and the time stamp (ATS) # 2 of the line of the data transfer time information (I picture transfer end time 5) is the I picture a information in Fig. 2 (c). It corresponds to the time stamp (ATS) # 2 of the trailing packet (AP) # 2 of 7. Since I picture a is the first picture here, the total number of packets 10 for I picture a of PTS No. 1 is 1 as shown in FIG. 20 (b).

Similarly, looking at the I picture i of PTS No. 2, the time stamp (ATS) # 3 of the line of the data transfer time information (I picture transfer start time 4) is the head side of the I picture i information 8 in Fig. 2 (c). Corresponding to the time stamp (ATS) # 3 of the packet (AP) # 3, the time stamp (ATS) # 4 of the line of the data transfer time information (I picture transfer end time 5) is the I picture i of Fig. 2 (c). Corresponds to the time stamp (ATS) # 4 of the trailing packet (AP) # 4 of information 8. Here, since I picture i is 85100 sheets after the first I picture a, the total number of packets 10 for I picture i of PTS No. 2 is "85101" as shown in FIG. 20 (b). The same applies to PTS No. 3 and later.

Area where management information (SFIT in Fig. 15) related to stream data (Fig. 1 (a), Fig. 20 (c) and other STREAM.VRO106) is recorded in the time relation table 2 as shown in Fig. 20 (b). A major feature of the present invention lies in the fact that the user can specify the screen position in picture units by recording in the data and using this time-related table.

Here, the correspondence between the time relationship table 2 and the reproduction time stamp list PTSL shown in FIG. 15 will be described.

When the time stamp shown in Fig. 1 (g) and others is ATS, the value of PTS included in the playback time stamp list PTSL in Fig. 15 and ATS have the following relationship: (1) Cell (1) A stream cell) refers to a portion of a recorded bitstream; (2) an AU (usually an I picture) is a contiguous portion of a recorded bitstream (AU corresponds to a portion of a cell). (3) Which SOBU contains the AU (I picture corresponding to a part of the cell) is indicated by the access unit start map AUSM in Fig. 15 (see Fig. 16); (4) PTS value. Is the playback time (display time; or presentation time PTM) of the corresponding AU (the value of the PTS corresponding to the AU corresponds to a part of the cell with respect to the playback time); (5) The cell start APAT (SC_S_APAT) is The arrival time of the transport packet or application packet AP of the corresponding cell (SC_S_APAT corresponds to the value of PTS with respect to the playback time); (6) The transport packet or application packet AP is prefixed with a time stamp ATS (see Fig. 22, Fig. 29 (g), etc.); (7) The PTS value is included in the PTSL (see Fig. 15). (8) From (3) to (7) above, the value of PTS included in PTSL corresponds to ATS through AUSM, SC_S_APAT, etc.

Therefore, the playback time stamp list PTSL provides information (PTS value) indicating the relationship (relationship regarding playback time) between the start time (SC_S_APAT) of the AU (I picture) and the time stamp ATS of the packet included in the bit stream. It can be said that it is a "time-related table (Fig. 20 (b))" that includes it.

Alternatively, it can be said that the PTSL (time relationship table) is information indicating the correspondence between the PTS value and the ATS.

By the way, in order to display the B picture or the P picture, it is necessary to always start from the display (decoding) of the I picture. Therefore, the time relation table 2 shown in FIG. 20B shows the time stamp at the I picture position and the corresponding display time information as a list.

Here, as the display time information, "PTS information (PTS value)", "number of difference fields from the specific reference screen (picture)", "year / month / day time information", and the like can be used.

It is also possible to use the difference information between each I picture (for example, the number of fields inserted between each I picture) instead of displaying the absolute value as the display time information as shown in FIG. 20 (b). Is. (The time-related table using the number of fields will be described later with reference to FIG. 28.) Further, although "PTS information" is used as the display time information in FIG. 20 (b), the present invention is variously possible. In the embodiment of the above, the method is not limited to this method, and instead, "the number of difference fields from the specific reference screen (picture)" or "year / month / day / time information" or the like can be used.

In the time relation table 2 shown in FIG. 20 (b), not only the value of the transfer start time 4 for each I picture is recorded in the list as time stamps (ATS) # 1, # 3, and # 5. The value of the transfer end time 5 of the I picture is also recorded as the time stamps (ATS) # 2, # 4, and # 6.

For this reason, fast forward playback (first forward FF) or fast reverse playback (when performing special playback such as first reverse FR, "time stamp (ATS) # 1 to # 2", "time stamp (ATS) # 3" By specifying the transport packet position (or application packet position) of the I picture to be played back, such as "from # 4" and "timestamp (ATS) # 5 to # 6", from the information storage medium 201, Only I picture information (or access unit AU information) can be played back, decoded, and displayed.

In the embodiment of FIG. 20A, the display start picture position (position of B picture f) of the original cell (see FIG. 4) is used as a reference. The difference between the PTS value (PTS No. 5) of the display start picture of this original cell and the PTS value (PTS No. 1) of the I picture a immediately before it is the PTS offset 9. This PTS offset value 9 is recorded in the original cell information 272 as shown in FIG. 3 (h).

Specifically, as shown in FIG. 20A, the display start picture of the original cell is set to B picture f, and the PTS value at that time is set to PTS No. 5. Assuming that the display time of I picture a immediately before that is PTSNo.1, the value of PTS offset 9 can be obtained by "PTSNo.5-PTSNo.1".

When the user specifies a specific screen (specific picture frame), it is often specified by the difference display time from the display start position of the original cell. After converting this difference display time to the number of counters of 27 MHz and / or 90 kHz, the PTS value of the screen (picture frame) specified by the user can be calculated by adding the value of PTS offset 9.

As shown in FIG. 20 (b), a list of PTS values for each I picture is recorded in the time relation table 2. Refer to this table to find the PTS value at the I-picture position that is smaller than the calculated PTS value and is closest to the calculated PTS value, and specify the corresponding time stamp (ATS) value of the I-picture transfer start time 4. Then, the access to the information storage medium 201 is started.

As shown in FIG. 20 (b), the total number of transport packets 10 (access position information) from the start position of the original cell to the corresponding I picture is also recorded in the time relation table 2 in parallel with the time stamp. There is.

Therefore, according to the embodiment of FIG. 20, the desired stream data position is accessed by specifying the number of transport packets (or the number of application packets AP_Ns) from the start position of the original cell instead of the time stamp (ATS). It is also possible.

When the stream data (STREAM.VRO) 106 of FIG. 20 (c) is recorded on the information storage medium 201 shown in FIG. 3 or the like, the content (SOB or SOBU) of the stream data 106 is a predetermined data recording unit (transport). A packet or application packet) is recorded in the data area (STREAM.VRO / SR_TRANS.SRO) of medium 201. At that time, the management information (STRI) regarding the stream data 106 is also recorded in the management area (STREAM.IFO / SR_MANGR.IFO) of the medium 201.

This management information (STRI) is combined with the first management information (ATS; or AUSM corresponding to the I-picture transfer start time) used for accessing the stream data 106 (access to I-picture information or access unit AU); It is different from the first management information (AUSM) and shows the relationship between this first management information and the second management information (PTS; or SC_S_APAT) used to access the stream data. A third management information (time relationship table; or PTSL) is recorded.

Here, the stream data 106 is a bit stream compressed based on the MPEG standard, and the second management information corresponds to the playback time (PTS) of the stream data.

FIG. 21 is a diagram illustrating a relationship between a display time and a data transfer time in one embodiment of the present invention.

Regarding the data structure in the stream data (Fig. 1, Fig. 2 and other STREAM.VRO106) recorded on the information storage medium 201, the recording position and stream block (SOBU) of each picture information 6010 to 6030 are used with reference to FIG. The arrangement relationship between and is explained.

In this embodiment, stream data is recorded in stream block (SOBU) units, and time stamp information is used to specify access to a predetermined image (picture).

When a time stamp value is specified as the playback start position from the STB device 416 in FIG. 19, the information for calculating the stream block (SOBU) corresponding to the specified time stamp value is the time in FIG. 3 (h). Map information 252 (or time map information MAPL in FIG. 15 or time map information in FIG. 18).

In the example of FIG. 3 (h), the time map information 252 is recorded as a part of the stream object information (SOBI) 242 in STREAM.IFO 105, which is a management information recording area for the stream data. In the example of FIG. 15, the time map information MAPL is also recorded as part of SOBI.

In the time map information 252 shown in FIG. 3 (i), only the time stamp difference time information for each stream block is recorded. In this case, the values of the time difference 263 and 265 of each stream block in the time map information 252 are sequentially added for each stream object information (SOBI) 242 and 243. Then, it is necessary to compare whether or not this sequential addition value has reached the time stamp time specified by the STB device 416 side. Based on the comparison result, it is determined whether the time specified by the STB device 416 matches the time stamp value contained in which stream block (SOBU) in which stream object (SOB).

As shown in FIG. 21 (c), the boundary position of each picture information 6010 to 6030 and the boundary position of the stream block (SOBU) do not always match.

In this case, for example, as shown in FIG. 21 (a), if playback is to be started from the position of P picture o in which the PTS value is PTS No. 6, the following processing is required.

That is, the value of PTS No. 2 of the I picture i immediately before it is calculated from the time relation table 2 (the internal configuration is the same as that of FIG. 20 (b)) in FIG. 21 (b), and the I picture i information 6010 is recorded. Playback must start from the beginning of stream block (SOBU) #A, which contains the first transport packet # 2.

However, until the playback proceeds from the start position of stream block (SOBU) #A to the desired position of P picture o, the image information (from picture i to picture n in Fig. 21 (a)) during that time is sent to the external monitor (TV). Not output.

FIG. 22 is a diagram illustrating the relationship between the video information compression method in MPEG and the transport packet, and the relationship between the transport packet in MPEG and the application packet in the streamer.

As shown in FIG. 22, a signal compression method called MPEG2 is adopted for broadcast signal information on a digital TV. In the signal compression method by MPEG, each screen (picture) for TV display is classified into I picture 551 which does not include time difference information and B picture 553, 554 and P picture 552 which includes time difference information.

The I picture exists as a single unit without being affected by the previous and next screen (picture) information, and after DCT conversion for one screen (picture), the quantized information becomes the I picture compression information 561 and the I picture information. Recorded as 31. In the P picture 552, only the difference information 562 for the I picture 551 is recorded as the P picture information 32, and in the B picture 553 and 554, the difference information for the I picture 551 and the P picture 552 is recorded as the B picture information 33 and 34.

Therefore, at the time of video reproduction, the screen cannot be generated by the P picture 552, the B picture 553, and the 554 alone, and each picture screen can be generated only after the I picture 551 screen is generated. Each picture information 31 to 34 is separately recorded in the payload in one or more transport packets. At this time, the boundary positions of the picture information 31 to 34 and the boundary positions between the transport packets are recorded so as to always match.

When the transport packet of FIG. 22 is recorded on the streamer (optical disk device 415 of FIG. 19), the contents of the transport packet are transferred to a time-stamped packet (application packet) called an application time stamp (ATS).

Then, a group of application packets with ATS (usually around 10 packets) is stored in the application packet area in the stream PES packet.

This stream PES packet with a pack header is one stream pack.

A stream PES packet is composed of a PES header, a substream ID, an application header, an application header extension (optional), a stuffing byte (optional), and an application packet area for storing the above-mentioned application packet group with ATS. To.

FIG. 23 is a diagram for explaining the correspondence between the contents of digital broadcasting, the video data transfer form in IEEE1394, and the stream pack in the streamer.

In digital broadcasting, video information compressed according to the MPEG2 standard is transferred on a transport packet. As shown in FIG. 23 (b), the transport packet is composed of a transport packet header 511 and a payload 512 in which the data body of the recorded information is recorded.

As shown in FIG. 23A, the transport packet header 511 is composed of a payload unit start indicator 501, a packet ID (PID) 502, a random access indicator 503, a program clock reference 504, and the like.

The MPEG compressed video information includes I picture information, B picture information, and P picture information. The first transport packet in which the I picture information is recorded is flagged as "1" on the random access indicator 503 in FIG. 23 (a). Further, in the first transport packet of each B and P picture information, the flag of "1" is set in the payload unit start indicator 501 of FIG. 23 (a).

Utilizing the information of these random access indicator 503 and payload unit start indicator 501, I picture mapping table (641 in FIG. 9 (e)) and B, P picture start position mapping table (642 in FIG. 9 (e)). Information is created.

For example, for a transport packet flagged as "1" on the payload unit start indicator 501 shown in FIG. 23 (a), in the B, P picture start position mapping table (642 in FIG. 9 (e)). The bit at the relevant location becomes "1".

In digital broadcasting, video information and audio information are transferred in different transport packets. Then, the distinction of each information is identified by the packet ID (PID) 502 in FIG. 23 (a). Using the information of PID 502, a video packet mapping table (643 in FIG. 9 (e)) and an audio packet mapping table (644 in FIG. 9 (e)) are created.

As shown in FIG. 23 (c), in digital broadcasting, a plurality of programs (programs 1 to 3 in this example) are time-divisioned and transferred to one transponder in a packet form.

For example, the information of the transport packet header 511 and the payload (recorded information) 512 of FIG. 23 (b) is transferred by the transport packets b 522 and e 525 of program 2 shown in FIG. 23 (c).

For example, when the user intends to record the second program of FIG. 23 (c) on the information storage medium 201, the transport packet b of the program 2 is set in the reception information selector unit 423 in the STB device 416 shown in FIG. , E only are extracted.

At that time, as shown in FIG. 23 (d), the STB device 416 adds the time information in which the transport packets b522 and e525 are received in the form of time stamps 531 and 532.

After that, when data is transferred to the formatter / deformer unit 413 of FIG. 19 using the IEEE1394 transfer method, the set of the time stamp and the transport packet is finely divided as shown in FIG. 23 (e). It will be transferred.

In the formatter / deformer section 413 of FIG. 19, the stream data transferred from the STB device 416 by IEEE1394 is temporarily returned to the form of FIG. 23 (d) (corresponding to the form of FIG. 1 (g)). Then, a bit stream in the format of FIG. 23 (d) (stream pack sequence of FIG. 23 (h)) is recorded in the information storage medium 201.

Specifically, in one embodiment of the present invention, a pack header and a PES header in which system clock information and the like are recorded are arranged at the head of each sector (see FIG. 23 (h) and the like).

Data areas 21, 22, and 23 (Fig. 1 (f)) are sequentially packed with multiple time stamps and transport packets (Fig. 1 (g)), but one transport packet (Fig. 1 (g)). Packet d; Packet b of Program 2 in Fig. 23 (d) is recorded across multiple sectors (No. 0 and No. 1 in Fig. 1 (e); Partial packet in Fig. 23 (f) (g)). Will be done. Here is one of the features of this invention.

By using a data structure that takes advantage of this feature, it is possible to record packets with a size larger than the sector size (for example, 2048 bytes). This point will be further described.

As shown in Fig. 23 (c), digital broadcasting employs a multi-program compatible multiplexing / separation method called a transport stream, and the size of one transport packet b / 522 is 188 bytes (or 183 bytes). In many cases.

As mentioned above, the size of one sector is 2048 bytes, and even if various header sizes are subtracted, there are 10 transport packets for digital broadcasting in one data area 21, 22, 23 (Fig. 1 (f)). You can record before and after.

On the other hand, in digital communication networks such as ISDN, large long packets with a packet size of 4096 bytes may be transferred.

In addition to recording multiple transport packets in one data area 21, 22, 23 (Fig. 1 (f)) such as digital broadcasting, in the case of packets with a large packet size such as long packets However, by using a data structure that makes the best use of the above features (a feature that allows one packet of data to be recorded across multiple packets), one packet can be continuously recorded in multiple data areas 21, 22, and 23. Record to straddle.

Then, for the transport packet for digital broadcasting and the long packet for digital communication, all the packets can be recorded in the stream block without any fraction regardless of the packet size.

Further, although a normal packet has a time stamp, as shown in FIG. 23 (g), the time stamp can be omitted in the partial packet.

In this way, the partial packet separated by the boundary between the two adjacent stream packs (Fig. 23 (h)) (the size of the partial packet is 1 to 187 bytes if 188 bytes per packet; 100 bytes on average). Weak) can be effectively used for information recording. Not only that, the storage capacity for the medium 201 can be increased by the amount of the time stamp omitted for the partial packet (for example, 4 bytes per time stamp).

The position of the time stamp immediately after the first partial packet in FIG. 23 (g) can be specified by the first access point 625 in FIG. 10 (b) or FIRST_AP_OFFSET in FIG. 10 (c).

In the optical disk device 415 (streamer) of FIG. 19, the set of the time stamp and the transport packet (FIGS. 23 (f) and (g)) is recorded on the information storage medium 201 as it is.

FIG. 24 is a flowchart illustrating a procedure for recording stream data according to an embodiment of the present invention. The processing at the time of recording stream data will be described with reference to FIG. 24. This process can be executed by the process program stored in the program memory unit 404a of the STB control unit 404 shown in FIG.

As shown in FIG. 23 (c), a plurality of program information is time-division-multiplexed in one transponder.

In the reception information selector unit 423 of FIG. 19, a transport packet of only a specific program is extracted from the packet string of the time-division-multiplexed multiple program information (step S01).

In the "reception time management unit (demodulation unit 422 in FIG. 19, reception information selector unit 423, multiplexing information separation unit 425, STB control unit 404, etc.)", the necessary program information is stored in the memory unit of the multiplexing information separation unit 425. It is temporarily stored in 426 (step S02).

At the same time, the reception time for each transport packet is measured, and the measured value is added to each transport packet (or application packet) as a time stamp (ATS) as shown in FIG. 23 (d). .. The time stamp information added in this way is recorded in the memory unit 426 (step S03).

Next, the "stream data content analysis unit (multiplexed information separation unit 425, STB control unit 404, etc. in FIG. 19)" analyzes the information in the transport packet (application packet) recorded in the memory unit 426. To.

Specifically, each picture boundary position is cut out from the transport packet (application packet) column, and PTS information (well, information on the number of corresponding fields) is extracted from the picture header information 41 for each packet (well, information on the number of corresponding fields). Step S04).

Here, there are two methods for cutting out the boundary position of each picture, and which method is selected depends on the content of the stream data.

The first picture boundary position extraction method detects the flag of the random access indicator 503 (Fig. 23 (a)) in the transport packet header 511 (Fig. 23 (b)), detects the I picture position, and detects the payload. This is a method of detecting the B or P picture position from the flag detection of the unit start indicator 501 (FIG. 23 (a)).

The second picture boundary position cutting method extracts the picture identification information 52 (Fig. 1 (k)) and the PTS information 53 (Fig. 1 (k)) in the picture header information 41 (Fig. 1 (j)). The method.

After the above processing (steps S01 to S04), in the "time-related information generation unit (multiplexed information separation unit 425, STB control unit 404, data transfer interface unit 420, etc. in FIG. 19)", the time stamp (ATS) is used. As a list showing the relationship between the PTS value and the PTS value, create the time relationship table 2 (or the playback time stamp list PTSL in FIG. 15) as shown in FIG. 20 (b), and create the work memory in the STB control unit 404. Record in section 407 (step S05).

After that, while maintaining the reception time interval in the STB device 416 and the optical disk device 415 (that is, keeping the relationship between the count value change of STC440 and the count value change of STC424 in FIG. 19 constant), the multiplexing information separator The packet data (stream data) temporarily stored in the memory unit 426 of the 425 is transferred to the optical disk device 415 (step S06).

In this way, the optical disk device 415 records the stream data temporarily stored in the memory unit 426 on the information storage medium 201 (step S07).

The processes of steps S06 to S07 are repeated until the stream data transfer to the optical disk device 415 is completed (step S08 no).

When the stream data has been transferred to the optical disk device 415 and the recording process is completed (step S08 yes), the time-related table 2 (or playback time stamp list PTSL) temporarily recorded in the work memory unit 407 of the STB control unit 404). Information is transferred to the optical disk device 415 (step S10).

Then, the information in the time-related table 2 (or the reproduction time stamp list PTSL) is recorded in the management information recording area (STREAM.IFO) 105 of the information storage medium 201 (step S11).

During the processing of step S11, the recording time of the stream object (SOB_REC_TM in FIG. 7 (i)), which is the content of the recorded stream data, is set to the time zone (TM_ZONE) in the management information recording area (STREAM.IFO) 105. ) 6240 (Can be recorded in Figure 7 (h).

By the way, when recording stream data, encrypted stream data may be recorded for the purpose of protecting the copyright of the content provider. When encrypted in this way, all transport packets are encrypted and the time stamp transfer process between the STB device 416 and the optical disk device 415 is prohibited. In this case, when recording the (encrypted) stream data on the information storage medium 201, it is necessary for the optical disk device 415 to independently add a time stamp.

On the STB device 416 side in FIG. 19, reception time is managed for each transport packet (application packet). In this case, countermeasures against deviation of the reference clock frequency (specifically, synchronization of the reference clock) between the STB device 416 side and the optical disk device 415 side become an important issue. Therefore, the recording process for the encrypted stream data will be described below.

FIG. 25 is a flowchart illustrating a procedure for recording encrypted stream data according to an embodiment of the present invention. This processing procedure can be executed by the processing program stored in the program memory unit 404a of the STB control unit 404 shown in FIG.

First, it is checked whether the time-related table 2 (FIG. 20 (b)) or the playback time stamp list PTSL (FIG. 15) exists in the work memory 407 of the STB control unit 404 of FIG. 19 (step S50).

If there is no time-related table (or PTSL) (step S50 no), the time-related table (or PTSL) is created by the same process as steps S04 to S05 in FIG. 24 (step S52).

After the time-related table (or PTSL) is created in this way, or when the time-related table (or PTSL) is already in the work memory 407 of the STB control unit 404 (step S50 yes), the STB device 416 to the optical disk device 415 The (encrypted) stream data is transferred to, and this stream data is recorded in the information storage medium 201 (step S51).

The process of step S51 is continued until the recording of this (encrypted) stream data is completed (step S53 no). The stream data recording step S51 has the same processing contents as steps S01 to S03 and S06 in FIG. 24.

The process of step S52 may be executed in parallel with the process of step S51.

When the recording of the (encrypted) stream data is completed in this way (step S53 yes), the reference clock synchronization process is executed between the STB device 416 and the optical disk device 415 (step S54).

This reference clock synchronization process can be performed, for example, as follows.

That is, at the time of stream data transfer, every time a specific number (for example, 10,000 or 100,000) of transport packets (application packets) is transmitted / received, the transmission / reception time is set by the STB device 416 and the optical disk device 415, respectively. Record in unit 407 and temporary storage unit 411.

After that, a transmission time list is sent every time a specific number of transport packets (application packets) are transmitted from the STB device 416 side to the optical disk device 415 side. Then, the optical disk device 415 side compares the sent list with the list created in advance on the optical disk device 415 side to calculate the reference clock synchronization deviation amount between the two.

After that, the time relation table 2 (or PTSL) is transferred from the STB device 416 to the optical disk device 415 (step S55).

The time-related table 2 (or PTSL) transferred from the STB device 416 to the optical disk device 415 in this way is corrected based on the information of the reference clock synchronization deviation amount calculated in the reference clock synchronization process of step S54 (step). S56).

The time relation table 2 (or PTSL) corrected by the reference clock synchronization deviation amount is recorded in the management information area (STREAM.IFO105 in FIG. 3 (e) or SFIT in FIG. 15) of the information storage medium 201. (Step S57).

By doing the above, it is possible to record / reproduce the stream data (in the encrypted state).

Instead of the above-mentioned "correction for deviation of reference clock synchronization for encrypted stream data" method, the following method may be used as another method.

That is, as shown in FIG. 20 (b), the number of transport packets transferred between each I picture is recorded in the time relationship table 2. Then, instead of specifying the time stamp value of the playback start screen (as a picture specification method), the total number of transport packets (or application packets) from the beginning of the cell is specified.

In this case, as the information in the time map information 252, instead of the data structure shown in FIG. 3 (i), as shown in FIG. 11, the number of transport packets (or the number of application packets) included in each stream block. AP_Ns) Have 633.

When the total number of transport packets (total number of application packets) is specified from the STB device 416 side to access a predetermined screen (picture), the optical disk device 415 side sequentially transforms from the first stream block shown in FIG. The number of port packets (application packets) 633 is added, and the stream block (or SOBU) is accessed when the addition result reaches the specified value.

FIG. 26 is a flowchart illustrating a procedure for reproducing stream data according to an embodiment of the present invention. This processing procedure can be executed by the processing program stored in the program memory unit 404a of the STB control unit 404 shown in FIG. Hereinafter, the stream data reproduction step will be described with reference to FIG. 26.

The user can specify the desired playback start time and / or playback end time in the form of "difference time (hours, minutes, seconds) based on the display start time of the specified original cell". The STB control unit 404 in the STB device 416 receives, for example, a specific playback start time and playback end time specified in this way (step S21).

In the STB control unit 404, the time information of the received playback start time and playback end time is converted into a clock count value of 27 MHz and / or 90 kHz, and the difference PTS value from the display start time of the original cell is calculated. ..

The STB control unit 404 controls the optical disk device 415, reads the time-related table 2 (or PTSL) recorded in the stream data management information recording area (STREAM.IFO105), and temporarily records it in the work memory unit 407 ( Step S22).

Further, the STB control unit 404 controls the optical disk device 415 to read the information of the time map information 252 (or MAPL) recorded in the stream data management information recording area (STREAM.IFO105), and enters the work memory unit 407. Temporarily record (step S23).

Next, the value of PTS offset 9 shown in FIGS. 3 (h) and 20 (a) is read, and the display start time of the corresponding original cell (corresponding to B picture f in FIG. 20 (a)) and immediately before that are displayed. Check the difference from the display time of I picture a (PTS No. 5-PTS No. 1 in Fig. 20 (a)) (step S24).

Furthermore, the value of PTS offset 9 shown in Fig. 3 (h) and Fig. 20 (a) is read, and (a) the value (PTS offset 9) and (b) the I picture immediately before the display start time of the original cell are read. The PTS value at the -a position (PTS No. 1) (when the display start picture f of the original cell is immediately after the I picture a as shown in Fig. 20 (a)) and (c) the difference PTS examined in step S24. Add the value (PTSNo.5-PTSNo.1) to calculate the PTS value of the playback start time and playback end time specified by the user (step S25).

Next, the PTS value of the I picture i immediately before the playback start location specified by the user and the value of the time stamp # 2 are checked using the time relation table 2 (step S26), and the optical disk device 415 is notified.

The optical disk device is a stream block (SOBU) including the start position of the I picture i information 6010 (FIG. 21 (c)) from the data (FIG. 3 (i)) of the time map information 252 shown in FIG. 3 (h). ) Check the value of the first time stamp (ATS) # 1 of #A and determine the location (address) of the first sector # α to be accessed (step S27).

Based on the address thus determined, the optical disk device 415 reproduces the information from the transport packet (AP) # 1 of FIG. 21 (c) from the information storage medium 201 (step S28).

Next, the STB control unit 404 in FIG. 19 notifies the decoder unit 402 of the PTS value (PTS No. 6 in FIG. 21 (a)) indicating the display start time of the information that started playback in step S28 (step S29). ).

Along with this notification, the optical disk device 415 transfers the information that started playback in step S28 to the STB device 416 side (step S30).

Subsequently, the STB control unit 404 reads the picture identification information 52 (FIG. 1 (k)) from the memory 426 in the decoder unit 402, and inputs the I picture (a part of the information transferred from the optical disk device 415). Discard (or ignore) the previous data (step S31).

Next, the video decoding unit 428 of FIG. 19 starts decoding from the beginning position of the I picture (I picture i in FIG. 21 (a)) input in step S31, and the PTS value specified by the notification in step S29. The display (video output) is started from (PTS No. 6 in FIG. 21 (a)) (step S32).

Hereinafter, the same processing as in steps S24 to S28 is repeated, the address on the information storage medium 201 corresponding to the reproduction end time is checked, and the reproduction is continued until the end address corresponding to the reproduction end time (step S33).

When the above series of playback is completed, the playback end position information 6110 shown in FIG. 7 (g) is used as resume information, and the video manager information in the management information recording area (STREAM.IFO105 shown in FIG. 7 (e)). It can be recorded in 231 (Fig. 7 (F)).

As the data contents of the reproduction end position information 6110, the corresponding PGC number 6210, the cell number 6220 in the PGC number 6210, and the reproduction end position time information 6230 are recorded as shown in FIG. 7 (h).

This time information 6230 is recorded as a time stamp value, but the PTS value (or the total number of fields from the cell reproduction start position) can also be recorded as the time information 6230.

When the reproduction end position information is to be reproduced again from the position of the (resume) information 6110, the reproduction start position can be obtained by the process of FIG. 27 described later.

During standard playback as described above with reference to FIG. 26, the count value of the STC unit 424, which is the reference clock creation unit in the STB device 416, is the value of the DTS (decode time stamp) information 54 shown in FIG. 1 (k). Decoding in the decoder unit 402 is started from the time when matches with.

FIG. 27 is a flowchart illustrating a procedure for special reproduction of stream data according to an embodiment of the present invention. This processing procedure can be executed by the processing program stored in the program memory unit 404a of the STB control unit 404 shown in FIG.

When performing special playback such as fast forward playback (fast forward FF) or fast reverse playback (fast reverse FR), only the I picture information recorded on the information storage medium 201 is extracted and played back, and decoded and displayed.

In this case, set the "special playback mode" for the decoder unit 402 so that the STC unit 424 (Fig. 19) and the DTS information 54 (Fig. 1 (k)) are out of synchronization and decoded in free mode. Do (step S41).

Even during special playback, the information of the time relationship table 2 and the time map information 252 is read from the management information recording area (STRAM.IFO) 105 of the information storage medium 201 and recorded in the work memory unit 407 of the STB control unit 404 (step). S42).

Next, the time map information 252 of the stream object information (SOBI) 242 corresponding to the corresponding playback start location is read and temporarily recorded in the work memory unit 407 in the STB control unit 404 (step S43).

Next, the time stamp values of the start time / end time at each I picture position (the position of each AU # in the example of FIG. 16) are extracted from the time relation table 2 (step S44).

Next, from the time map information 252, the stream block (SOBU) containing the time stamp value of the corresponding I picture is checked, and the address of the first sector thereof is checked (step S45).

For example, during special playback, only the I picture information 6010 to 6050 shown in FIG. 28 (b), which will be described later, is decoded and displayed. The positions of the I picture information 6010 to 6050 can be obtained by using the information in the time relation table 2 and the time map information 252.

Next, the optical disk device 415 reproduces the information in the Zen stream block (SOBU) including each I picture on the information storage medium 201, and transfers the reproduced information to the memory unit 426 in the multiplexing information separation unit 425. (Step S46).

Next, in the decoder unit 402 of FIG. 19, the picture identification information 52 (FIG. 1 (k)) in the data transferred to the memory unit 426 of the multiplexing information separation unit 425 is read, and based on this information 52, I Discard the non-picture data (step S47).

That is, in step S47, only the I-picture information extracted by the picture identification information 52 is extracted from the played / transferred stream data, and only the I-picture information extracted by the video decoding unit 428 is decoded.

Next, the I picture data selected (that is, not discarded) inside the memory unit 426 of the multiplexing information separation unit 425 in the decoder unit 402 is transferred to the frame memory unit 406 (step S48).

The I-picture data transferred to the frame memory unit 406 in this way is sequentially displayed on the display screen of the TV (or video monitor) 437 (step S49).

FIG. 28 is a diagram illustrating a time relationship table showing the relationship between the display time and the data transfer time in another embodiment of the present invention.

In the embodiment of FIG. 20, the absolute value is displayed as the display time information as shown in FIG. 20 (b), but instead, the difference information between each I picture (for example, it is inserted between each I picture). It is also possible to use field number information).

Further, in FIG. 20 (b), "PTS information" is used as the display time information, but in various possible embodiments of the present invention, the method is not limited to this method, and instead, a "specific reference screen (picture) is used. The number of difference fields from) "or" date / time information "etc. can be used. An example in this case is the time relationship table 6 in FIG.

As shown in FIG. 28 (b), each group of pictures (GOP) shows a group of pictures starting from a certain I picture position and from that I picture to immediately before the next I picture. In the data structure of the time relation table 6 shown in FIG. 28 (c), the number of display fields for each GOP is recorded as the display time information.

In addition, the number of stream blocks (SOBUs) occupied by each GOP is also described in the time relation table 6. By doing so, without using the time map information 252 shown in FIG. 3 (h), the given display time information is directly transferred to the stream block (SOBU) in which the start position of the I picture information is recorded. Access is possible.

At the boundary position between GOP # 2 and GOP # 3 in the example of FIG. 28 (b), the switching position of the GOP and the switching position of the stream block (SOBU) are the same. When the boundary of the adjacent GOP and the boundary of the adjacent SOBU match in this way, the GOP termination matching flag in the time relation table 6 shown in FIG. 28 (c) is set to "1". By doing so, the identification accuracy of the stream block position (SOBU position) including the head position of the I picture information is improved.

In addition, since the rear end position of the I picture information is used during special playback such as FF or FR described above, the time relationship table 6 in FIG. 28 (c) is also provided with the I picture size information in each GOP. There is.

FIG. 29 is a diagram illustrating how a packet (AP) in stream data (SOBU) is reproduced in one embodiment of the present invention.

FIG. 29 illustrates a case where the stream blocks ## 1, # 2, ... of FIG. 1 (c) are all composed of SOBU # 1, # 2, ... of a constant size (2 ECC block size). ing.

Fig. 29 (f) shows the data structure of the first sector No. 0 of SOBU # 1 (Fig. 29 (e)) and the last sector No. 63 of SOBU # 2 adjacent to SOBU # 1 (Fig. 29 (e)). The data structure of is shown. Although not shown, sector No. 0 to sector No. 62 have a similar concept.

As shown in Fig. 29 (f), the system clock reference SCR is recorded in the pack header of the stream pack corresponding to sector No. 0, and the system clock reference SCR is also recorded in the pack header of the stream pack corresponding to sector No. 63. Is recorded.

Now, suppose that the picture to be played back (the picture specified by the user in the playback time) exists in the middle of SOBU # 2 (in FIG. 16, for example, the position indicated by AU # 1). The picture specified by the user in the playback time corresponds to the cell start application packet arrival time SC_S_APAT.

In this case, the disk drive (not shown) included in the recording / playback unit 409 of FIG. 19 cannot directly access the middle of SOBU # 2, but accesses the boundary position between SOBU # 1 and SOBU # 2. Then, the reproduction of the stream data (STREAM.VRO) 106 of FIG. 29 (a) starts from the boundary position between SOBU # 1 and SOBU # 2.

The interval from the boundary position between SOBU # 1 and SOBU # 2 to the playback start position (position corresponding to SC_S_APAT) corresponds to the PTS offset 9 described in FIG. 20 (a).

The application packet existing between the boundary position between SOBU # 1 and SOBU # 2 and the playback start position (the position corresponding to SC_S_APAT) is decoded, but the playback output is not output (the screen is not displayed). This corresponds to the process of step S31 in FIG.

FIG. 29 (g) illustrates that the PTS information (PTS value or PTS offset) and the application packet AP to be reproduced are related by the time relationship table 2 in FIG. 20 (a). is there.

Here, the relationship between the above time relationship table and the playback time stamp list PTSL shown in FIG. 15 will be reorganized.

When the time stamp shown in Fig. 1 (g) and others is ATS, the value of PTS included in the playback time stamp list PTSL in Fig. 15 and ATS have the following relationship: (1) Stream cell Refers to a part of the recorded bitstream; (2) AU (usually an I picture) is a contiguous part of the recorded bitstream (AU corresponds to a part of the cell); (3) Which SOBU contains the AU (I picture corresponding to a part of the cell) is indicated by AUSM (see Fig. 16); (4) The value of PTS is the playback time (display time; Alternatively, it is a presentation time PTM) (the value of PTS corresponding to AU corresponds to a part of the cell with respect to the playback time); (5) Cell start APAT (SC_S_APAT) is the arrival time of the application packet AP of the corresponding cell. Yes (SC_S_APAT corresponds to the PTS value with respect to playback time); (6) The application packet AP is prefixed with a time stamp ATS (see Figure 29 (g) etc.); (7) The PTS value is , Included in PTSL (see Figure 15); (8) From the above, the value of PTS included in PTSL corresponds to ATS through AUSM, SC_S_APAT, etc.

Therefore, the playback time stamp list PTSL provides information (PTS value) indicating the relationship (relationship regarding playback time) between the start time (SC_S_APAT) of the AU (I picture) and the time stamp ATS of the packet included in the bit stream. It is a "time relation table (Fig. 20 (b))" including.

Alternatively, it can be said that the PTSL (time relationship table) is information indicating the correspondence between the PTS value and the ATS.

Finally, the meanings of some terms used in the description of each embodiment are summarized: * Stream object (SOB) indicates data in a recorded bitstream. Up to 999 SOBs can be recorded in the SR_TRANS.SRO file.

* A stream object unit (SOBU) is a basic unit organized within a SOB. That is, each SOB consists of a chain of SOBUs. Note that the SOBU at the beginning and / or end of the SOB may contain data that does not belong to the effective part of the SOB, especially after editing.

SOBU is not characterized by playback time or playback order, but by a fixed size (32 sector size or 2 ECC block size).

* Access unit (AU) refers to any single contiguous portion of a recorded bitstream suitable for individual playback. This AU usually corresponds to an I-picture in an MPEG-encoded bitstream.

* The access unit start map (AUSM) shows which SOBU of the corresponding SOB contains the AU.

* Application packets (APs) are part of the bitstream coming from the application device during recording. Alternatively, the AP is part of a bitstream that goes to the application device during playback. These APs are included in the multiplexing transport and have a constant size (up to 64574 bytes) during recording.

* The Application Timestamp (ATS) is placed before each AP and consists of 32 bits (4 bytes). The ATS consists of a 90kHz basic part and a 27MHz extended part.

* A cell (or stream cell SC) is a data structure that represents a part of a program. The cells in the original PGC are called the original cells, and the cells in the user-defined PGC are called user-defined cells. Each program in the program set consists of at least one original cell. Each part of the program in each playlist consists of at least one user-defined cell. In the streamer, when we simply refer to a cell, we mean a stream cell (SC). Each SC refers to a portion of the recorded bitstream.

* Cell number (CN) is the number (1 to 999) assigned to the cell in PGC.

* Stream cell entry point information (SC_EPI) is used as a tool for skipping a part of the recording and can exist in any stream cell (SC).

* The start application packet arrival time (SOB_S_APAT) of the stream object refers to the arrival time of the first AP belonging to the corresponding SOB. This arrival time consists of a 90kHz basic part and a 27MHz extended part.

* The end application packet arrival time (SOB_E_APAT) of the stream object refers to the arrival time of the last AP belonging to the corresponding SOB.

* Stream cell start application packet arrival time (SC_S_APAT) refers to the arrival time of the first AP belonging to the SC.

* Stream cell end application packet arrival time (SC_E_APAT) refers to the arrival time of the last AP belonging to the SC.

* Navigation data is data used to control recording, playback, and editing of a bitstream (SOB).

* A playlist (PL) is a list of program parts where the user can arbitrarily define a playback sequence. PL is described as a user-defined PGC.

* A program (PG) is a logical unit of recorded content that is recognized or defined by the user. A program in a program set consists of one or more original cells. The program is defined only within the original PGC.

* Program chain (PGC) is a superordinate conceptual unit. In the case of the original PGC, the PGC represents a chain of programs corresponding to the program set. On the other hand, in the case of a user-defined PGC, the PGC corresponds to a playlist and indicates a chain of a part of the program.

* Program chain information (PGCI) is a data structure that indicates the overall playback of PGC. PGCI is used in both the original PGC and the user-defined PGC. The user-defined PGC consists only of PGCI, and the cell refers to the SOB in the original PGC.

* The program chain number (PGCN) is a serial number (1 to 99) assigned to the user-defined PGC.

* The program number (PGN) is a serial number (1 to 99) assigned to the program in the original PGC.

* Program set refers to the entire recorded content of a disc (recording medium) consisting of all programs. If no program has been edited to change the playback order of the original recording, the same playback order as the program recording order is used when playing back the program set.

* Real-time recording means that when the buffer memory size is limited, the buffer memory overflows as long as any stream data encoded at the limited transfer rate is transferred at the limited transfer rate. It means a recording that can record the stream data on a disk (recording medium).

The effects of each embodiment of the present invention can be summarized as follows: 1. Between the time stamp data (ATS) recorded in the stream data and the display time information (PTS or field information) for the user. By having the information indicating the relationship (time relationship table or PTSL) as a part of the management information (SFIT), it is possible to start the playback / screen display from the display time specified by the user with high accuracy. ..

2. At the time of editing, the user specifies the specified range of partial erasure or sorting of the recorded stream data by the display time on the monitor TV.

As in "1." above, the stream data has a time relationship table (or PTSL) showing the relationship between the time stamp data and the display time information as a part of the management information (SFIT). This makes it possible to accurately set the edit point position (partial erase range or rearrangement specified range) using this time relationship table (or PTSL). As a result, time management for stream data can be performed using time stamp data (ATS), and accurate editing processing in response to a user request can be guaranteed.

3. As shown in "1." above, since the stream data has a time-related table (or PTSL), either the time stamp data (ATS) or the display time information (PTS) can be reproduced. The playback start position (resume playback start position) when the streamer is restarted can be set accurately just by describing it as the end position information (resume information).

4. When accessing a specific position on the information storage medium by recording the playback end position information (resume information) with time stamp data (ATS), the time map information 252 is used to quickly know the address to be accessed. be able to.

5. MPEG compressed data must start playback from I picture. By recording information (time relationship table) indicating the relationship between the time stamp data (ATS) and the display time information (PTS or field information) at the start position of each I picture (or the start position of the access unit AU). , Access control to the desired I picture (desired AU) can be performed at high speed by using the time map information 252.

6. By recording information (time relationship table) showing the relationship between the time stamp data (ATS) at each I picture start position (start position of each AU) and the display time information (PTS or field information). , In combination with the time map information 252, the address of the stream block (or SOBU) position including the I picture (AU) can be known. Therefore, special playback processing such as fast forward FF or fast reverse FR that plays / displays only the I picture becomes possible.

The present invention is not limited to each of the above embodiments, and various modifications and changes can be made at the stage of implementation without departing from the gist thereof. In addition, each embodiment may be implemented in combination as appropriate as possible, in which case the effect of the combination can be obtained.

Further, the above-described embodiment includes inventions at various stages, and various inventions can be extracted by an appropriate combination of the plurality of constituent elements disclosed in this application. For example, if one or more of the constituents are removed from all the constituents shown in the embodiment, but at least one of the effects of the present invention or the effects associated with the implementation of the present invention is obtained, the constituents are present. The deleted configuration can be extracted as an invention.

<figref num="1">The figure explaining the data structure of the stream data which concerns on one Embodiment of this invention.</figref><figref num="2">The figure explaining the directory structure of the data file which concerns on one Embodiment of this invention.</figref><figref num="3">The figure explaining the recording data structure (particularly the structure of management information) on the information medium (DVD recording / re-disc) which concerns on one Embodiment of this invention.</figref><figref num="4">The figure explaining the relationship between a stream object (SOB), a cell, a program chain (PGC), etc. in this invention.</figref><figref num="5">The figure explaining the stream block size, the contents of the stream block time difference, etc. in the time map information.</figref><figref num="6">The figure explaining the cell range specification method in an original cell and a user-defined cell.</figref><figref num="7">The figure explaining the recording data structure (particularly, the structure of the reproduction end position information / resume information, VMGI management information / recording time information, etc.) on the information medium (DVD recording / re-disc) which concerns on another Embodiment of this invention.</figref><figref num="8">Figure 1 A diagram illustrating the internal structure of the PES header shown elsewhere.</figref><figref num="9">The figure explaining the internal structure of the stream block header shown in FIG.</figref><figref num="10">The figure explaining the internal structure of the sector data header shown in FIG.</figref><figref num="11">The figure explaining another example of the time map information in one Embodiment of this invention.</figref><figref num="12">The figure explaining an example of the internal structure (stream pack containing an application packet and stream pack containing a stuffing packet) of the sector which constitutes a stream block (SOBU).</figref><figref num="13">A diagram illustrating the internal data structure of streamer management information (corresponding to STREAM.IFO or SR_MANGR.IFO in Figure 2).</figref><figref num="14">A diagram illustrating the internal data structure of PGC information (ORG_PGCI / UD_PGCIT in Figure 3 or PGCI # i in Figure 13).</figref><figref num="15">A diagram illustrating the internal data structure of a stream file information table (SFIT).</figref><figref num="16">The figure which exemplifies the correspondence between the access unit start map (AUSM) and the stream object unit (SOBU).</figref><figref num="17">The figure which exemplifies the correspondence between the access unit start map (AUSM) and access unit end map (AUEM), and stream object unit (SOBU).</figref><figref num="18">The figure which illustrates how the cell specified by the original PGC or the user-defined PGC and the SOBU corresponding to these cells are related by the time map information.</figref><figref num="19">The figure explaining the structure of the stream data recording / reproduction system (optical disk apparatus / streamer, STB apparatus) which concerns on one Embodiment of this invention.</figref><figref num="20">The figure explaining the time relation table which shows the relationship between the display time and the data transfer time in one Embodiment of this invention.</figref><figref num="21">The figure explaining the relationship between the display time and the data transfer time in one Embodiment of this invention.</figref><figref num="22">The figure explaining the relationship between the video information compression method in MPEG and a transport packet, and the relationship between a transport packet in MPEG and an application packet in a streamer.</figref><figref num="23">The figure explaining the correspondence relationship between the content of digital broadcasting, the video data transfer form in IEEE1394, and the stream pack in streamer.</figref><figref num="24">The flowchart which explains the recording procedure of stream data which concerns on one Embodiment of this invention.</figref><figref num="25">The flowchart which explains the recording procedure of the encrypted stream data which concerns on one Embodiment of this invention.</figref><figref num="26">A flowchart illustrating a procedure for reproducing stream data according to an embodiment of the present invention.</figref><figref num="27">The flowchart which explains the procedure of special reproduction of stream data which concerns on one Embodiment of this invention.</figref><figref num="28">The figure explaining the time relation table which shows the relationship between the display time and the data transfer time in another embodiment of this invention.</figref><figref num="29">The figure explaining how the packet (AP) in stream data (SOBU) is reproduced in one Embodiment of this invention.</figref>

Code description

201 ... Information media, 415 ... Optical disc devices, 416 ... STB devices.