JPWO2000046803A1 - Method for generating stream data and method for partially erasing data - Google Patents

Abstract

(57) [Summary] Stream data has a recording data structure consisting of stream blocks (or stream object units, SOBUs) divided into predetermined data sizes. Data is recorded (or encoded) and partially erased (or temporarily erased) in units of these stream blocks (SOBUs).

Description

Detailed Description of the Invention

FIELD OF THE INVENTION This invention relates to bitstream information or packet structure of digital broadcasting, etc.
Generates (encodes) stream data to be transmitted using
The stream data is recorded on an information medium, and the encoded stream data is
Partially erase (temporary erase/full erase) the decoded or recorded stream data.
BACKGROUND ART (Description of the Related Art) In recent years, TV broadcasting has entered the era of digital broadcasting.
To store digital data of TV broadcasts as digital data regardless of its content.
Currently, digital TV broadcasting uses MPEG transport streams.
In the field of digital broadcasting using video, MP3 players are expected to continue to be used.
The EG transport stream is considered to be the standard. Currently available streamers for recording this digital broadcast data are
Examples include home digital VCRs such as D-VHS (digital VHS).
This streamer using D-VHS can receive the broadcasted bitstream.
Therefore, multiple programs are multiplexed onto a video tape.
When playing back, whether you are playing from the beginning or from the middle,
All data is transmitted from the VCR to the set-top box (digital TV reception)
The STB receives the user's operation.
The desired program is selected from the sent data by the operation etc.
The set information is transferred from the STB to a digital TV receiver, etc., and played back (video + audio).
Since the D-VHS streamer uses tape as the recording medium, it can play back quickly.
Random access is not possible, and you cannot quickly jump to the desired position in the desired program.
This is a promising candidate to overcome the drawback of tape (difficulty in random access).
As a supplement, a streamer using large capacity disk media such as DVD-RAM is also available.
In that case, it is necessary to consider random access and special playback.
Naturally, it becomes necessary to record management data together with broadcast data. (Problem) Generally, when a DVD-RAM disk is used as an information storage medium, a 16-cell disk is required.
An ECC block is constructed for each sector, and data is interleaved within the ECC block.
The data is then reordered and an error correction code is added.
To erase or rewrite only specific sectors within a block and then add to them
This requires the following complex process: First, all data in the ECC block is read, and then the buffer is
After re-sorting (de-interleaving) in memory, the data for a specific sector is
Delete or rewrite the data, add (modify) it, and then reconnect the interface.
The "read mode" records data by adding a reordering code and an error correction code.
This process takes a very long time, and it is difficult to record or erase the stream data.
The object of the present invention is to solve the above problem by providing a method for easily and
Recording (encoding) and partial erasure (temporary/full erasure) of stream data in a short time
Disclosure of the Invention In order to achieve the above object, the present invention provides a method for converting stream data into predetermined data.
Stream blocks (or stream object units) divided by data size
The recording data structure is made up of stream blocks (SOBUs).
It is possible to record (or encode) and partially erase data in units of SOBU.
Specifically, in the case of partial erasure (full erasure), the first data unit (transport
packet/application packet; e.g., 188 bytes) and one or more
A second data unit (sector/stream) having the first data unit (packet)
pack; for example, 2048 bytes or 2 kbytes) and one or more of the second data
A third data unit (stream block/SO) having a data unit (sector/pack)
BU; for example, 64 kbytes = 32 sectors = 2 ECC blocks)
Bitstream information (DVD Bitstream) consisting of System Objects (SOB)
In a method for handling a stream object (SOB), one of the bitstream information included in the SOB is
15, 16, 22 or 24)
The third data unit (stream block/SOBU) is erased as a unit (see FIG. 1
7, step S22). More specifically, in the case of partial erasure (full erasure), the first data unit (transfer
port packet/application packet), and one or more of the first data units
a second data unit (sector/stream pack) having a second data unit (packet), and one or more
a third data unit (stream) having the second data unit (sector/pack) of
It is composed of a stream object (SOB) containing
Bitstream information (DVD bitstream), and said stream information
Streamer information (STRE in Figs. 2 and 3) that manages (DVD bitstream)
27 (STRI in FIG. 27), the bitstream information (DVD bitstream) is composed of one or more cells
Information about the program to be created and the sequence (replay) of said program or a part thereof
Program chain (PGC) information (FIG. 3(f) or FIG. 27) indicating the order of
ORG_PGCI/UD_PGCIT in FIG. 27), and
T; PGCI#i in FIG. 28) is the streamer information (STREAM.IFO/S
TRI), and the program chain information (PGCI#i/SCI/SC_GI in FIG. 28
) is the first data unit (application packet) containing the contents of the cell
start time information (751 in FIGS. 15 and 22; SC_S_APA in FIGS. 21 and 28)
T) and the first data unit (application packet) containing the contents of the cell.
) end time information (757 in FIGS. 15 and 22; SC_E_AP in FIGS. 21 and 28)
AT), and the start time information (SC_S_APAT) and the end time information (SC_E
_APAT) to determine the bits included in the stream object (SOB).
Deletion of part of the stream information (deletion area 741/742 in FIG. 22 or FIG. 24)
In the case of partial temporary erasure, the first data unit (transport packet/address) is specified (step S21 in FIG. 17).
application packet) and one or more of the first data units (packets).
a second data unit (sector/stream pack) and one or more of said second data units
The third data unit (stream block/SOBU) has a sector/pack number.
) and bitstream information consisting of a stream object (SOB) including
In a method for handling information (DVD bitstream), one of the bitstream information included in the stream object (SOB) is
23 or 25) to the third data unit (stream
The data is set to the temporary erase state in units of a single SOBU (each step in FIG. 17).
In this section, "partial erase" or "erase" is replaced with "temporary erase." More specifically, in the case of partial temporary erase, the first data unit (transport
packet/application packet), and one or more of the first data units (packets
a second data unit (sector/stream pack) having one or more preceding data units (packets)
A third data unit (stream block) having the second data unit (sector/pack)
Bitstream Object (SOB) containing a bitstream object (SOB) and a bitstream object (SOBU).
bitstream information (DVD bitstream), and the stream information (D
Streamer information (STREAM in Figs. 2 and 3) that manages the VD bitstream
27 ) (STRI in FIG. 27 ), the bitstream information (DVD bitstream) is composed of one or more cells
Information about the program to be created and the sequence (replay) of said program or a part thereof
Program chain (PGC) information (FIG. 3(f) or FIG. 27) indicating the order of
ORG_PGCI/UD_PGCIT in FIG. 27), and
T; PGCI#i in FIG. 28) is the streamer information (STREAM.IFO/S
TRI), and the program chain information (PGCI#i/SCI/SC_GI in FIG. 28
) is the first data unit (application packet) containing the contents of the cell
temporary erasure start time information (ERA_S_APAT in FIGS. 21, 23, and 28);
Provisional deletion of the first data unit (application packet) containing the contents of the cell
21, 23, and 28), and the temporary erasure start time information (ERA_S_APAT) and the temporary erasure end time information (ERA_E_APAT) are included.
The stream object (SOB)
) included in the bit stream information (the temporary erasure area 7 in FIG. 23 or FIG. 25)
47) is designated (at step S21 in FIG. 17,
"Partial erasure range" is read as "provisional erasure range"). In the above-mentioned temporary erasure, the management information (streamer information STREAM) is erased in the following manner.
.IFO/STRI) is rewritten. That is, the program chain information (PGCI#i/SCI/SC_G
I) is the first data unit (application packet I) containing the contents of the cell
) start time information (SC_S_APAT) and the first data including the contents of the cell
temporary erasure start time information (ERA_S_A) of data unit (application packet)
PAT) and the first data unit (application packet) containing the contents of the cell.
the temporary erasure start time information (ERA_S_APAT) and the temporary erasure end time information (ERA_E_APAT) of ...
The stream object (SOB)
) included in the bit stream information (the temporary erasure area 747 in FIG. 23 and FIG. 25)
) is specified (in step S21 of FIG. 17,
"Deletion range" is read as "provisional deletion range"), and the start time information (SC_S_APAT) is the third data unit (stream
The first data unit (application packet) starting within the block/SOBU
When the start time information (SC_S_APAT) is matched with the beginning of the
The third data unit includes the first data unit (application packet).
The first data unit (
Application packet) start time information (SC_S_A
The temporary erasure start time information (ERA_S_APAT) is adjusted to the temporary erasure start time information (ERA_S_APAT)
(In step S26 of FIG. 17, "partial erasure" is replaced with "temporary erasure"
), and rewrite the streamer information (STREAM.IFO/STRI) (see Figure 1).
17, step S27). In the case of encoding to generate bitstream information, the first data unit (
transport packets/application packets) and one or more of the first data
a second data unit (sector/stream pack) having a data unit (packet);
a third data unit (sector/pack) having one or more of the second data units (sectors/packs);
It consists of a Stream Object (SOB) containing a Stream Block (SOBU).
A method for handling bitstream information (DVD bitstream) generated by
and a time stamp is assigned to each of one or more packet data constituted by the first data unit.
Attach a timestamp (ATS) (step S01 in FIG. 13); Attach an array of one or more pieces of time-stamped packet data to the third data unit (
(Step S02) by dividing the third data unit (stream block/SOBU);
The information about the packet data is stored in data units (sectors/packs) (see FIG. 11(d)).
11 or the stream block header including the number of packets 631, etc.
In the recording method of the present invention, the bit stream generated by the encoding method is inserted into the bit stream (or application header) (step S08).
The bit stream information is recorded on a predetermined medium (such as an optical disk). Alternatively, in the case of encoding to generate bit stream information, the first data unit
a transport packet/application packet and one or more of the above
A second data unit (sector/stream pack) having one data unit (packet)
) and a third data unit having one or more of the second data units (sectors/packs).
Stream Object (SOB) containing (Stream Block/SOBU)
In the method for handling bitstream information (DVD bitstream) consisting of
and a time stamp is assigned to each of one or more packet data constituted by the first data unit.
Attach a timestamp (ATS) (step S01 in FIG. 13); Attach an array of one or more pieces of time-stamped packet data to the third data unit (
Stream Block/SOBU) (Step S02);
16(k)) and padding area (Fig.
26(k); stuffing packet (732 in FIG. 26(i)) is added (
Step S03) Furthermore, the third data unit (stream block/SOBU) is divided into
The inside of the data string is divided into the second data units (sectors/packs) (step
Step S04): Add the padding to the end of the third data unit (stream block/SOBU).
If there is a padding area (732 in FIG. 16(k)),
The size of the data is larger than the size of the second data unit (sector/pack) (step
If the step S06 is "Yes", all the information is essentially meaningless (zero in FIG. 26(i)).
The first data unit (the trailing stuffing in FIG. 26(i)) is filled with
packet) as the padding area (step S07);
The information about the packet data (Fig. 11(d)) is stored in data units (sectors/packs).
11 or the stream block header including the number of packets 631, etc.
In the recording method of the present invention, the bit stream generated by the encoding method may be inserted into the bit stream (step S08).
The stream information is recorded on a predetermined medium (optical disk, etc.). BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, with reference to the drawings, a stream data generation method according to an embodiment of the present invention will be described.
Method for creating, recording, and method for partially erasing recorded stream data
FIG. 1 illustrates the data structure of stream data according to an embodiment of the present invention.
The stream data recorded on an information storage medium such as a DVD-RAM disk is
A stream object (hereinafter referred to as a stream object) is created for each content of video information in the stream data.
Each SOB is a single real
The SOB#A is formed from stream data obtained by real-time continuous recording.
This stream data is stored on a DVD-RAM disc.
When recording, the minimum unit is a sector of 2048 kbytes.
Furthermore, 16 sectors are grouped together to form one ECC block, and the same EC
Interleaving (rearranging the data order) and error correction within the C block
In this embodiment, the stream is divided into units of one or more ECC blocks.
Stream information is recorded in units of stream blocks.
This is the feature of the present invention. In this embodiment, the number of ECC blocks that make up a stream block is
The amount of data transfer can be determined based on the transfer rate of the stream data.
For example, in the example of FIG. 1(e), stream block #1 has two ECC blocks.
Stream block #2 consists of three ECC blocks #
It is composed of γ, #δ, and #ε. In the DVD streamer, two ECC blocks are
One stream block (stream object unit) is made up of 32 sectors.
Each ECC block consists of 16 sectors, as shown in Figure 1(d).
Therefore, as can be seen from FIGS. 1(d) and 1(e), the data is composed of two ECC blocks.
Stream block (or SOBU) #1 has 32 sectors (sector No. 0
In other words, if 1 sector = 2k bytes, the stream block (SOBU) is
The present invention can be implemented with a fixed size of 64 kbytes (32 sectors).
The contents of each sector correspond to a stream pack (details will be explained later with reference to Figure 9, etc.).
For example, the stream corresponding to sector No. 0 (FIG. 1(d))
As shown in FIG. 1(c), a pack consists of a pack header 1, a PES header 6, and a slot.
A stream block header (described later with reference to FIG. 11) 11, a data area 21, and
Also, the stream pack corresponding to sector No. 1 (Fig. (d))
As shown in FIG. 1(c), the data consists of a pack header 2, a PES header 7, and a sector data.
12, which will be described later with reference to FIG. 12, and a data area 22.
An example of the internal structure of the PES headers 6 and 7 in FIG. 1(c) will be explained later with reference to FIG.
The data area 21 in FIG. 1(c) contains the time stamp as shown in FIG.
and transport packet pairs (timestamp a, transport
Packet a, timestamp b, transport packet d)
Similarly, the data area 22 contains a time stamp and a transport packet.
On the other hand, the rear data area 23 contains another array of pairs of
As shown, a transport packet f, an end code 31, and padding
The multiple pairs of timestamps and transport packets in FIG. 1(b) are shown in FIG.
The bit stream will be arranged as shown in (a) of FIG. 1. The stream block #1 (shown in (a) of FIG. 1) before SOB #A 298 (shown in (f) of FIG. 1)
The data structure of SOB#A 298 is as shown in Fig. 1(d) to (b).
The data structure of the following stream block #2 (Fig. 1(g)) is as follows:
That is, the sector N after the last ECC block #ε of stream block #2
o. 78 (FIG. 1(h)) is a pack header 3 and a PE
It includes an S header 8, a sector data header 13, and a data area 24.
The last sector No. 79 of ECC block #ε (FIG. 1(h)) is the same as that of FIG.
1(j), the data area 24 of sector No. 78 includes a pack header 4 and a padding packet 40.
Port packet z, end code 32, and padding area 37.
The padding packet 40 of the last sector No. 79 is shown in FIG.
As shown in FIG. 2, the data file includes a PES header 9 and a padding area 38. The contents of the padding area 38 will be described later with reference to FIG. 26. FIG. 2 shows the directory structure of a data file according to an embodiment of the present invention.
The information recorded on an information storage medium such as a DVD-RAM disk is divided into hierarchical layers for each piece of information.
The image information and the screen image data described in this embodiment have a layered file structure.
The stream data information is stored in the DVD_RTR directory (or DVD_RTAV
The DVD_RTR (DVD_RTAV) directory 102 contains the following contents:
That is, as a group of management information (navigation data), RTR.I is stored in the data file 103.
VR_MANGR.IFO (or VR_MANGR.IFO) 104 and STREAM.IFO (S
R_MANGR. IFO/SR_MANGR. BUP) 105 and SR_PRI
VT.DAT/SR_PRIVT.BUP 105a are stored. Also, as the data body (content information), STREAM.VRO (or
SR_TRANS. SRO) 106 and RTR_MOV. VRO (VR_MOV
IE.VRO) 107 and RTR_STO.VRO (or VR_STILL.
VRO) 108 and RTR_STA.VRO (or VR_AUDIO.VRO)
) 109 are stored in the directory 101 above the subdirectory 101 containing the data file 103.
The main directory 100 contains a subdirectory 110 that stores other information.
This subdirectory contains a video title containing video programs.
Torset VIDEO_TS111, an audio recording containing audio programs
Title set AUDIO_TS112, subdivision for computer data storage
The data transmitted in the form of a packet structure on a wired or wireless data communication path is
On the other hand, data recorded on an information storage medium while maintaining the packet structure is called "storage."
The stream data itself is called STREAM.VRO (or SR_TRA
The stream is recorded under the file name NS.SRO)106.
The file in which management information for the data is recorded is STREAM.IFO (
Or SR_MANGR.IFO and its backup file SR_MANGR
. BUP) 105. Also, analog video information handled by VCR (VTR) or conventional TV etc.
Files recorded digitally compressed based on the MPEG2 standard are RTR_MO
V.VRO (or VR_MOVIE.VRO) 107, and after-recording
A file that collects still image information including audio or background sound.
The rule is RTR_STO.VRO (or VR_STILL.VRO) 108
, the dubbing audio information file is RTR_STA.VRO (or VR_AU
3 shows an information medium according to an embodiment of the present invention, for example, a DVD-RAM disc.
3A is a diagram illustrating the structure of recorded data on a recordable/reproducible optical disk 201 such as a disk.
The area between the two ends includes a lead-in area 204 as shown in FIG.
and volume and file structure information 20 in which file system information is recorded.
6, a data area 207, and a lead-out area 205.
The data area 204 is made up of embossed and rewritable data zones, and the read-out
The data area 205 is made up of a rewritable data zone.
The data area 207 is also composed of a rewritable data zone. As shown in FIG. 3(c), the data area 207 contains computer data and online data.
In this example, audio and video data can be recorded together.
Between the data area 208 and the computer data area 209,
The audio and video data area 210 is sandwiched between the two. As shown in FIG. 3(d), the audio and video data area 210 has a rear
Mixed recording of real-time video recording area 221 and stream recording area 222
(Real-time video recording area 221 or streaming)
As shown in FIG. 3(e), the real-time video recording area 221 contains the video data shown in FIG. 2.
The navigation data of the RTR shown in RTR.IFO(VR_MANGR.
IFO) 104 and a movie real-time video object RTR_MOV.
VRO (VR_MOVIE.VRO) 107 and still picture real-time video
Video object RTR_STO.VRO (VR_STILL.VRO) 108
and audio object RTR_STA.VR for after-recording, etc.
3(e), the stream recording area 222 contains the audio data shown in FIG.
The streamer navigation data STREAM.IFO (SR_MA
NGR.IFO/SR_MANGR.BUP) 105 and transport bits
Stream data STREAM.VRO (SR_TRANS.VRO) 106 and
Although not shown in FIGS. 3(d) and 3(e), the stream recording area 222 has
, the application-specific navigation data SR_PRIVT shown in FIG.
, DAT/SR_PRIVT. BUP 105a can also be recorded. This SR_PRIVT, DAT 105a is connected (supplied) to the streamer.
Navigation data specific to each application and stored by the streamer.
Stream.IFO (or SR) is management information for stream data.
_MANGR.IFO) 105 has the data structure shown in Figures 3(f) to 3(i).
That is, as shown in FIG. 3(f), STREAM.IFO (or SR_M
ANGR.IFO) 105 is a video manager (VMGI or STR_VM
GI) 231, Stream File Information Table (SFIT) 232, and
Original PGC information (ORG_PGCI) 233 and user-defined PGC information table
UD_PGCIT 234 and the text data manager (TXTDT_M
G) 235 and Manufacturer Information Table (MNFIT) or Application Specific
An application that manages the navigation data SR_PRIVT.DAT 105a
Application Private Data Manager (APDT_MG) 236
The stream file information table (SFIT) 232 in FIG.
As shown in g), the stream file information table information (SFITI) 241
and one or more stream object information (SOBI) #A·242, #B·2
43, ..., original PGC information general information 271, and one or more original
It is now possible to include cell information #1, 272, #2, 273, etc.
Each stream object information (e.g., SOBI#A.242) in FIG.
) is a stream object general information (SOBI_
GI) 251, time map information 252, etc. Also, each original cell information (for example, #1 272;
corresponds to the SCI shown in FIG. 28), as shown in FIG. 3(h),
81 (which will be described later and corresponds to C_TY shown in FIG. 28), cell ID 282, and the
The start time of this cell (see FIG. 15(l) to be described later), SC_S_
APAT) 283, the end time of the corresponding cell (see FIG. 15(l) to be described later),
3(g) and the time map information 252 in FIG. 3(h) included in SOBI#A in FIG. 3(g) can include the time map information 252 in FIG. 3(h ...).
, as shown in FIG. 3(i), stream block number 261, first stream block
Block size 262, first stream block time difference 263, second stream block
Including the block size 264, the second stream block time difference 265, ...
The time difference of each stream block constituting the time map information 252 can be
The contents will be described later with reference to Fig. 5. Fig. 4 shows the stream object (SOB), cell, program, and so on of the present invention.
4 is a diagram illustrating the relationship between the RAM chain (PGC) and the like.
The relationship between SOB and PGC in this invention will be explained using the following: Stream data (STREAM.VRO or SR_TRANS.SRO)
The stream data recorded in 106 is a collection of one or more ECC blocks.
The stream block is composed of the following parts, and the part is recorded in units of the stream block.
This stream data is divided into sections for each content of the information to be recorded (for example,
For example, each program in a digital broadcast is recorded as a stream object.
Management information for each stream object (SOB#A, SOB#B) (original
The navigation system includes the PGC information 233, the user-defined PGC information table 234, etc.
Stream data stream.ifo (SR_MANGR.ifo) 105 (see FIG. 4)
3(e) and (f)). The management information (
STREAM.IFO 105) is a stream, as shown in Figure 3(f) and (g).
Stream object information (S) in the file information table (SFIT) 232
Stream object information (SOBI) #A·242, (SOBI) #B·243 are recorded.
The internal structure of each H.243 mainly consists of the data size and time for each stream block.
When the stream data is played back, a program consisting of a sequence of one or more cells is played back.
The information of the program control chain (PGC) (corresponding to PGCI#i in FIG. 28 to be described later) is used.
The stream data is played back according to the setting order of the cells that make up this PGC.
The PGC can generate a stream.VRO (SR_TRANS.SRO) 106.
Original PGC that can play all recorded stream data continuously
290 (ORG_PGCI 233 in FIG. 3(f)) and the
User-defined PGC#a・293, #b・, which can be set in any desired location and order.
296 (corresponding to the contents of UD_PGCIT 234 in FIG. 3(f)).
Original cells #1 and #2 that make up the original PGC 290 exist.
2 is basically one-to-one with stream object #A 298 and #B 299.
On the other hand, user-defined cell #11 294 that constitutes a user-defined PGC exists.
#12・295 and #31・297 are one stream object #A・29
Any position can be set within the range of #B·8 or #B·299. The sector size of each stream block can be set in various ways, but it is preferable to set it to
In a preferred embodiment, two ECC blocks are used, as in stream block #1 in FIG.
A stream object of a fixed size (64k bytes) with a lock (32 sectors)
It is preferable to use a unit (SOBU) as a stream block. In this way, the stream block is set to a fixed size (for example, 2 ECC blocks = 3
If the SOBU size is fixed at 2 sectors (64 kbytes), the following advantages can be obtained: (01) Even if stream data is erased or rewritten in SOBU units,
The ECC block of the SOBU is the ECC block of the SOBU other than the one to be erased or rewritten.
It does not affect the block. Therefore, the erase or rewrite operation
ECC de-interleaving/interleaving (for SOBUs not subject to
(02) The access position for the recording information in any SOBU is set to the number of sectors (
Or other parameters corresponding to the number of sectors; for example, the stream
The packet can be identified by the information contained in the packet and the application packets within it.
For example, when accessing the intermediate position of a certain SOBU#k,
1 and the 16th sector from the boundary between SOBU #k (or the 16th sector)
The stream block size and stream block position in the time map information can be specified.
5 is a diagram illustrating the contents of the lock time difference.
The contents of each data in H.252 will be explained. As shown in (f), (g), and (h) of FIG. 5, the stream object (SOB)
In the examples of (f) and (h) in FIG. 5, the stream blocks constituting SOB #A 298 are:
The data size of block #1 is 2 ECC blocks (#α, #β), and is 32 sections.
The time map information has a size of 1000 bytes (Fig. 5(e)(i)).
5(a)(k))
Stream block #1 (Fig. 5(j)) at the beginning of SOB #A 298 (Fig. 5(g)) is 32 sectors (64 kbytes).
5(f)) has sector No. 0 (FIG. 5(e)) at the beginning, and sector No. 0
The time stamp a is recorded at the beginning of the data area 21 (FIG. 5(d)) included in
In addition, the stream block #2 (Fig. 5(g)) following SOB #A·298 (Fig.
5(f)) has sector No. 32 (FIG. 5(e)) at its beginning, and sector No.
The data area 311 (FIG. 5(d)) included in 32 has a time stamp p
As shown in FIG. 5(c), the first stream data of stream block #1 is recorded as follows:
The timestamp value of the next stream block #2 is timestamp a.
The timestamp value of the first stream data is timestamp p.
The value of the stream block time difference 263 is the difference between the timestamp p and the timestamp
The time map information 252 in FIG. 5A is given as a difference value between time stamp p and time stamp a ([time stamp p] - [time stamp a]).
The access data unit AUD in the stream object information SOBI is also included.
The information contained in this AUD (Access Unit
You can specify the SOBU containing the information you want to access by using the SOBU start map (e.g., AUSM).
Figure 6 shows how to specify a cell range in an original cell and a user-defined cell.
The range of each cell can be specified by specifying the start and end times.
Specifically, before the partial erasure described later with reference to FIG. 15 and subsequent figures (stream data),
The start time 283 of the corresponding cell in the original cell (immediately after the recording of the data) and the
The end time 284 of the cell (FIG. 6(b)) is the time of the corresponding stream object.
The value of the first timestamp a in project #A 298 (FIG. 6(f)) and the value of the latest timestamp a
The value of the later timestamp z (FIG. 6(c)) is used. In contrast, the time range specified in user-defined cell #12 295 (FIG. 6(k)) is used.
For example, the time can be specified as shown in Fig. 6(i) and (j).
The values of the timestamps d and n corresponding to the transport packets d and n are
It can be set as the start time 331 of the cell and the end time 332 of the cell.
In Figure 6(f), Stream Object (SOB) #A·298 is composed of two streams.
In the examples of (e) and (g) of FIG. 6, stream block #1 is composed of 32 sectors (sector N
Stream block #2 is composed of 48 sectors (sectors
The first sector No. 0 of stream block #1 is composed of sectors No. 32 to No. 79, as shown in Figure 6(e) and (d).
As shown, there are a pack header 1, a PES header 6, a stream block header 11, and a data
The rear sector No. 78 of stream block #2 is composed of data area 21, etc.
As shown in FIG. 1, there are 3 pack headers, 8 PES headers, 13 sector data headers, and
6(h) shows the data area 24. In addition, the sector No. 1 in FIG. 6(g) contains the pack header as shown in FIG.
2, sector data header 12, data area 22, etc. are recorded.
) sector No. 33 includes a sector data header 321, as shown in FIG.
The data area 312 and other areas are recorded. In the data area 21 of FIG. 6(d) and (h), as shown in FIG. 6(c) and (i),
A pair of timestamp a and transport packet a or timestamp d
In addition, a pair of transport packet d and transport packet d is recorded in the data area 24 of FIG.
and transport packet pair and the last timestamp z+transport
The pair of packets z is followed by an end code 32 and a padding area 37 (see FIG. 1).
6(j)) is recorded in the data area 22 of FIG. 6(h).
Transport packet containing the subsequent contents of transport packet d in area 21
In other words, in this example, the contents of transport packet d are
, are recorded separately in data area 21 and data area 22. The first half of transport packet d in FIG. 6(i) (on the data area 21 side) is
, which corresponds to the tail side partial packet of FIG. 8(f) to be described later, and
The latter half of the packet d (on the data area 22 side) is the same as the first part of FIG. 8(g) described later.
6(i) corresponds to the head side partial packet. Furthermore, the data area 312 of FIG. 6(h) contains the tag
timestamp n and transport packet n pair and other similar pairs
Here, the start time 3 of the cell corresponding to the point where the user etc. has specified the playback start time is recorded.
31 (FIG. 6(j)) shows two transactions divided into data areas 21 and 22.
The time stamp d (FIG. 6(i)) for the entire transport packet d is specified.
The transport packets are replaced with application packets.
When the packet arrival time is APAT, the cell start time 331 is
The cell start time APAT can be expressed as the cell start time 33 of the cell corresponding to the point where the user or the like specifies the playback end time.
2 (FIG. 6(j)) for transport packet n in data area 312
This cell end time 332 is specified by timestamp n (FIG. 6(i)).
The cell start time (cell start APAT) 331 and the cell end time (cell end APAT) can be expressed as
As shown in FIG. 6(k), the user-defined cell information #12.
This user-defined cell information #12 295 is recorded inside the cell information #12 295 shown in FIG. 3(f) or the lower part of FIG.
The above can be recorded in the user-defined PGC information table 234. The above is the cell start/end information for the user-defined cell information (information of the user-defined PGC).
Regarding the completion time information, the original cell information (original cell information)
The cell start/end time information relating to the above can be exemplified as follows: That is, the leading timestamp a in FIG. 6(c) corresponds to the corresponding cell in FIG. 6(b).
The end timestamp z indicates the start time 283 of the cell.
The start time 283 of the cell in question in FIG. 6B can indicate the cell start APAT (the start time of the
Start of erase APAT (SC_S_APAT) or start of erase APAT (ER
Also, the end time 284 of the cell in question in FIG. 6B can be made to correspond to the cell end APAT (which will be described later).
Stream Cell End APAT (SC_E_APAT) or Erasure End APAT
The cell start time (cell start APAT) 283 and the cell end time (cell end APAT) can be made to correspond to the above.
As shown in FIG. 6(a), the original cell information #1 and #2 are
This original cell information #1·272 is recorded inside the original cell information #1·272 shown in FIG. 3(f) or the bottom of FIG.
It can be recorded in the original PGC information 233. The cell start APAT and cell end APAT will be described later with reference to FIG.
Specific examples will be shown in the explanations of Figures 18 to 21 and Figures 30 to 33. Figure 7 shows a stream data recording and reproducing apparatus (stream data recording and reproducing apparatus) according to an embodiment of the present invention.
7 is a diagram illustrating the configuration of a stream data as a preferred embodiment of the present invention.
The internal structure of the recording and reproducing device (streamer) will now be described. The stream data recording and reproducing device in this embodiment includes an encoder unit 40
1, decoder unit 402, STB unit 403, main MPU unit 404, V (video) mixer
a signaling unit 405, a frame memory unit 406, a key input unit 407, a display unit 408,
A disc for recording or reproducing information on a DVD-RAM disc 201.
disk drive unit 409, data processor (D-PRO) unit 410, temporary storage unit 4
11, an A/V (audio/video) input unit 412, and a TV tuner unit 413.
This stream data recording and playback device further includes a satellite receiver connected to the STB unit 403.
Star antenna 421, system time counter (STC) section 424, V mixing
A digital video signal is sent from the unit 405 to a personal computer (PC) 435.
an interface (I/F) 434 for analog TV 437; a D/A converter 43
Here, the V-mixing unit 405 receives the V-PRO unit 438 of the decoding unit 402.
and a digital video signal 423 from the STB unit 403.
This mixing function allows you to
For example, a broadcast image from the STB unit 403 is displayed on the left side of the display screen of the TV 437.
The image reproduced from the disk 201 can be displayed on the right side of the display screen of the 437.
Alternatively, the broadcast image from the STB unit 403 and the reproduced image from the disc 201 can be
On the PC435 monitor screen, overlap the overlapping window.
In the above configuration, the encoder unit 401 contains the video and audio
A/D conversion unit 414, a digital video signal or ST
The digital video signal 423 from B03 is selected and sent to the video encoding unit 416.
a selector 415 that sends the video signal from the selector 415 to a video
The audio encoding unit 416 encodes the audio signal from the A/D conversion unit 414.
an audio encoder 417 for receiving a closed-loop signal from the TV tuner 413;
Encoding a caption (CC) signal or a teletext signal into a sub-picture (SP)
an SP encoding unit 418, a formatter unit 419, and a buffer memory unit 420
On the other hand, the decoding unit 402 includes a separation unit 425 with a built-in memory 426, a reduced image
A video decoder 428 incorporating a thumbnail picture generator 439,
P decoding unit 429, audio decoding unit 430, TS packet transfer unit 427
, a video processor (V-PRO) unit 438, an audio D/A conversion unit 432
The digital audio signal decoded by the decoding unit 430 is input to the interface.
The digital signal can be output to the outside via the device (I/F) 431.
An analog audio signal converted by the D/A converter 432
This drives the speaker 433 via an external audio amplifier (not shown).
The D/A converter 432 converts the digital audio from the audio decoder 430.
In addition to the audio signal, the digital audio signal 422 from the STB unit 403
When the reproduced data from the disc 201 is transferred to the STB unit 403, the following D/A conversion is possible:
The TS packet transfer unit 427 transfers the reproduced data (bitstream) from the separation unit 425.
stream) to transport packets (TS packets), and
The transfer time is adjusted to the time information from the TS packet and the TS packet is sent to the STB unit 403.
The main MPU 404 in FIG. 7 includes a work RAM 404a as a working memory,
A control program named stream data creation control unit 404b and a stream
A control program named data playback control section 404c and a stream data section
The file management area (the navigation RT shown in FIG. 2 or FIG. 3(e)) includes a control program called the partial deletion/temporary deletion control unit 404d.
R.IFO 104, STREAM.IFO 105) to read and write
The main MPU unit 404 connects the D-PRO unit 410 to a dedicated microcomputer bus.
The control during recording in the stream data recording and reproducing device is performed by the control program
This is performed by the main MPU 404 using a sequential control program. First, the flow of video signals during recording in the device shown in FIG. 7 will be explained.
During image capture, a stream data creation control unit 404b in the main MPU 404
That is, a series of processes are performed according to the sequential program of the STB unit 403 via a transmission path conforming to the IEEE 1394 standard.
The stream data sent from the encoder 401 is first sent to the formatter 402.
The IEEE 1394 receiving side of the formatter unit 419 receives the time counter of the STC 424.
Based on the counter value, the time from the start of the stream data transfer is read.
The time information is sent to the main MPU 404 as management information, and the work RAM 4
The main MPU 404 stores the stream data in the stream buffer 404a based on the time information.
per VOBU for real-time RTR recorders, per VOBU for streamers
Create division information to separate the data into OBUs and then correspond to this division information.
The division information of the cell and the program, as well as the division information of the PGC
The division information is created and sequentially recorded in the work RAM 404a in the main MPU 404.
The formatter unit 419 controls the stream data creation control unit 4 of the main MPU unit 404.
In accordance with the instruction from 04b, the data is sent from the STB unit 403 in the form of FIG.
The received stream data is converted into the form shown in Fig. 1(c)(i) (the stream data shown in Fig. 8(h) to be described later).
The converted stream pack sequence is then sent to the D-PRO unit 410.
The input stream pack is a constant 2048 bytes, the same as the sector.
The D-PRO unit 410 divides the input stream pack into
Every six sectors are grouped together to form an ECC block, which is then sent to the disk drive unit 409.
Here, the disk drive unit 409 stores a RAM disk (information storage medium)
If the recording preparation to the D-PRO unit 201 is not yet completed, the D-PRO unit 410
The data is transferred to the temporary storage unit 411 and temporarily stored therein, and then the data is read out from the disk drive unit 409.
When the disk drive unit 409 is ready to record, the D-PRO unit 4
10 transfers the data stored in the temporary storage unit 411 to the disk drive unit 409
This starts recording onto the disk 201.
Once the saved data has been recorded, the subsequent data is sent from the formatter unit 419.
The temporary storage unit 411 is designed to be fast accessible and to store recording data for several minutes or more.
Next, we will explain how data is processed during playback.
The control during playback in the stream data playback control section 404c is
A series of processes are performed by the main MPU 404 according to the sequential program.
First, the disk drive unit 409 reads the RAM disk (information storage medium) 2
The stream data is reproduced from D-01.
The stream data is transferred to the decoder unit 402 via the PRO unit 409. Inside the decoder unit 402, the transport
The packets are received by the demultiplexer 425. The demultiplexer 425 receives the stream ID 603 and the sub-stream ID 604, which will be described later with reference to FIG.
According to the stream ID, the video packet data (MPEG video data) is
The audio packet data is transferred to the audio decoder 428.
The sub-picture packet data is transferred to the SP decoder 429.
The video data decoded by the video decoding unit 428 is sent to the V mixing unit 4
05 and converted into an analog TV signal via the D/A converter 436, and
At the same time, the audio signal decoded by the audio decoding unit 430 is transferred to the D/A converter 7 for image display.
The converted digital audio data is sent to the A converter 432 and converted into digital audio data.
The digital audio data is input to an external audio device (not shown) via an I/F 431.
Alternatively, the converted digital audio data is transferred to the D/A converter.
The signal is converted into an analog audio signal by the converter 432 and passed through an audio amplifier (not shown).
The stream data recording and reproducing apparatus (stream data recording and reproducing device) according to the embodiment of the present invention has been described above.
As described above, the signal flow in the DVD-RAM disc (information storage medium) 201 is recorded.
The stream data is formatted in the formatter unit 419 into the structure shown in FIG.
The stream data recording procedure, which is centered around this conversion process, is shown in Figure 1.
The procedure for playing back stream data will be described later with reference to the flowchart in FIG. 3. Also, the procedure for playing back stream data will be described with reference to the flowchart in FIG.
FIG. 8 shows the contents of digital broadcasting and the video data transfer in IEEE1394.
FIG. 1 is a diagram illustrating the correspondence between a transmission format and a stream pack in a streamer.
In digital broadcasting, video information compressed according to the MPEG2 standard is transmitted
The transport packet contains the following information:
As shown in (b), a transport packet header 511 and data of recording information are included.
As shown in FIG. 8(a), the transport packet header 511 is composed of a payload 512 in which the data itself is recorded.
A code unit start indicator 501, a packet ID (PID) 502, a random
It consists of an access indicator 503, a program clock reference 504, etc.
The MPEG compressed video information is divided into I picture information, B picture information, and P
I-picture information (571 in FIG. 9, which will be described later) is recorded.
The first transport packet in the packet contains the random access event shown in FIG.
The indicator 503 is set to a flag of "1".
The first transport packet of each of 573, 574, and 572 in FIG.
8(a) payload unit start indicator 501 is flagged as "1"
These random access indicators 503 and payload unit start
The information of the indicator 501 is used to create an I-picture mapping table (described later).
11) and B, P-picture start position mapping table (later
For example, the payload unit start indicator 501 shown in FIG.
For transport packets with a flag of "1", B and P-pictures are opened.
The corresponding bit in the start position mapping table (642 in FIG. 11) is set to "1."
In digital broadcasting, video and audio information are transmitted via separate transports.
The information is transferred in a port packet.
) is identified by a packet ID (PID) 502.
In this case, a video packet mapping table (643 in FIG. 11 to be described later) and an audio
As shown in FIG. 8(c), in digital broadcasting, multiple packets are stored in one transponder.
The programs (in this example, programs 1 to 3) are packetized and transferred in time division.
For example, the transport packet header 511 and payload in FIG.
The information in the recording information 512 is the transport of program 2 shown in FIG.
The packets are transferred as packets b 522 and e 525. For example, if a digital broadcast receiver (such as a user of the STB in FIG. 7) operates
8(c) is recorded on the information storage medium 201 shown in FIG. 3 or FIG.
In this case, in the STB unit 403 of FIG.
Only transport packets b and e of program 2 in c) are extracted. At this time, the STB unit 403 extracts each transport packet as shown in FIG.
The time information when packets b 522 and e 525 are received is a time stamp 531.
7 by the IEEE1394 transfer method.
When data is transferred to the data matter unit 419, as shown in FIG.
The set of the timestamp 531 and the transport packet 522 is divided into small pieces.
The formatter unit 419 in FIG. 7 transfers the data from the STB unit 403 using IEEE 1394.
The transmitted stream data is in the form of FIG. 8(d) (or the form of FIG. 1(a) or
8(f), (g), and (h).
is a bit stream in the format of Fig. 8(f), (g), and (h) (stream in Fig. 8(h)
A pack sequence) is recorded on the information storage medium 201. Specifically, in one embodiment of the present invention, each sector (FIG. 1(d)(h)
At the beginning of the data are pack headers 1, 2, and 3, which contain system clock information, etc.
3, 4 and PES headers 6, 7, 8, 9 are placed (Fig. 1(c)(i), Fig. 6(
Immediately after that, sector data headers 12 and 13 (see FIG. 1(c)(i)) are provided.
, FIG. 6(d)) is recorded, but only the first sector of each stream block is recorded.
Instead of a data header, a stream block header 11 is recorded (see FIG. 1(
(c), (d) of FIG. 6). Data areas 21, 22, 23, and 24 (FIG. 1(c)(i)) contain a plurality of time
Stamps and transport packets (Fig. 1(a)) are packed sequentially,
One transport packet (packet d in FIG. 1(b); packet d in FIG. 8(e))
8(f)) are stored in multiple sectors (No. 0 and No. 1 in Fig. 1(d);
In g), the data is recorded across the partial packet. Here, one of the features of the present invention is
By using a data structure that takes advantage of this feature, the sector size (for example, 2
It is possible to record packets with a size greater than 0.48 bytes.
In digital broadcasting, the data is transmitted in what is called a transport stream, as shown in Figure 8(c).
It uses a multiplexing and demultiplexing method that supports multiple programs,
If the size of packet b-522 is 188 bytes (or 183 bytes),
As mentioned above, one sector size is 2048 bytes, and various header sizes are
Even if subtracted, there is only one data area 21, 22, 23, 24 (FIG. 1(c)(i))
In contrast, in digital communication networks such as ISDN, the packet size is 409.
There are cases where a large long packet of 6 bytes is transferred. For example, in digital broadcasting, one data area 21, 22, 23, 24 (see FIG. 1) is used.
(c) In addition to recording multiple transport packets in (i),
It is now possible to record large packets such as
The data structure that makes use of the above characteristics (data of one packet is spread across multiple packets)
By using the feature that allows recording in multiple data areas, one packet can be recorded in multiple data areas.
This allows for recording across 21, 22, 23, and 24.
For example, all packets are streamed regardless of packet size.
In addition, although a normal packet has a timestamp, the timestamp shown in FIG.
In this way, the timestamp can be omitted in the partial packet. In this way, the split at the boundary of two adjacent stream packs (FIG. 8(h)) is prevented.
The partial packet (assuming each packet is 188 bytes)
The size is 1 to 187 bytes; the average is just under 100 bytes) and can be used effectively for information recording.
In addition, the timestamps omitted for partial packets (timestamps) can be
(e.g., 4 bytes per timestamp) to increase the storage capacity of the medium 201.
The position of the timestamp immediately following the first packet in FIG.
First access point 625 in FIG. 12(b) or
If a remainder occurs in a stream block, it is specified by the padding data.
For example,
As shown in FIG. 1(b), the last transport packet in stream block #1
An end code 31 is placed after f, and the remaining part is a padding area 36
The padding areas 37 and 38 in FIG. 1(j) are also padding data.
For the specific internal data structure of the padding area, see Figure 26.
FIG. 9 shows the relationship between the video information compression method and the transport packet in MPEG.
and transport packets in MPEG and applications in streamers.
As mentioned above, in digital broadcasting, video information is compressed according to the MPEG2 standard.
As shown in FIG. 9, the compressed information 561 of the I-picture 551 is the I-picture information 57.
1 is recorded in transport packets a, b, ....
The difference information 563 and 564 is stored in the transport packet as B picture information 573.
d, .... The difference information 565 and 566 of the B picture 554 is recorded in the B picture.
The structure information 573, 574 is recorded in transport packets d, f, .
Then, the difference information 562 of the P picture 552 is stored as P picture information 572.
In this way, the I, B, and P picture information is recorded in different transport packets.
When such transport packets are recorded on the streamer,
The content of the transport packet is a time stamp 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.
The stream PES packet with a pack header attached is shown in FIG.
A stream PES packet consists of a PES header, a substream ID, and an application
Application header and application header extension (optional)
) and stuffing byte (optional) and the above ATS-equipped application
The PES header (stream PES packet header) is composed of the following:
This will be described later with reference to Figure 10.
11 and 12)
This will be described later with reference to Figure 12. Figure 10 explains the internal structure of the PES header shown in Figures 1, 8, 9, etc.
The PES header 601 in FIG. 10(a) is a packet header as shown in FIG.
Start code prefix 602, stream ID 603, playback timestamp
This PES header 601 includes the PES headers 604, 605, 606, 607, 608, 609, 609, 610, 611, 612, 613, 614, 615, 616, 617, 618, 619, 620, 621, 622, 623, 624, 62
PES headers 6 to 9, PES headers 6 to 7 in FIG. 8(h), PES header 6 in FIG. 9
The stream PES header in FIG. 10(d) corresponds to a packet start code prefix.
Stream ID (private stream 2), PES packet length,
This stream PES header contains the substream ID etc.
This is the same as the stream PES header and corresponds to the PES header 601 in FIG.
The PES header 9 in FIG. 1(j) has the contents shown in FIG. 10(a).
When the PES header has a stream ID of 6, the MPEG standard specifies that
03 (Fig. 10(b)) is "10111110",
On the other hand, the stream ID 603 (substream ID in FIG. 10(c)) is "00
If the value is "000010", the packet with that PES packet is
In the stream block #1 in FIG. 1(e), the last transport packet f
(Fig. 1(a)) is located in the last sector No. 31 (Fig. 1(d)).
However, in stream block #2 (FIG. 1(e)(g)), the user may interrupt the stream.
Since the recording was completed at the time of the last transport packet z (Fig. 1(j)),
Located in sector No. 78 (FIG. 1(h)) and sector No. 79 (FIG. 1(h))
The area inside is an empty space where no stream data is recorded.
Data No. 79 is recorded as padding packet 40 (FIG. 1(i)).
Figure 11 illustrates the internal structure of the stream block header shown in Figure 1(c).
As shown in FIG. 11(a), the stream block header 11 is
Supports upstream ID, application header, stuffing bytes, etc.
The stream block header 11 has the following contents:
packet information 611, stream block information 612, sector data header information
The transport packet information 611 in FIG. 11(b) includes the transport packet information 613 in FIG.
This is the same as the port packet information 611. The stream block in FIG. 11(b) in which information about the entire stream block is recorded
The program block information 612 is the recording time 622 (information storage medium 20) in FIG.
date and time information recorded in transport packet attribute 623 (transport packet attribute 624)
attribute information about the stream packet), stream block size 624 (if applicable
The data size of the stream block to be used (for example, the number of ECC blocks)
1B), which corresponds to the stream block time difference 625. Here, taking FIG. 1B as an example, the time range information in the corresponding stream block
is [stream block time difference] = [the first one in stream block #2]
The timestamp value is calculated as [timestamp a value] - [timestamp a value].
11(c) is the stream block time difference 625. Also, the sector data header information 613 in FIG. 11(b) is the stream block time difference 625 in FIG.
First Access Point 626 and Transport Packet Connection Flag 627
This sector data header information 613 corresponds to the sector data shown in FIG.
The transport packet information 611 in FIG. 11(c) contains information similar to that in the data header 12.
As shown in the figure, the number of transport packets (the number of application packets) is 631.
It includes a transport packet mapping table 632 etc. (see FIG. 11(d)
The number of application packets corresponds to AP_Ns in FIG. 12(c) to be described later.
The number of transport packets (application packets) in FIG. 11(d) is 6.
As shown in FIG. 11(e), the I-picture mapping table 641, B
, P picture mapping table 642, etc. Also, the transport packet mapping table 632 in FIG.
A video packet mapping table 643, an audio packet mapping table
644, program specific information mapping table 645, etc.
Each mapping table in the transport packet mapping table 632
(Fig. 11(e)) is configured in a bitmap format. For example, n transport packets (addresses) are stored in one stream block.
If a packet containing a packet application is recorded, the transform shown in FIG.
The value of the port packet number (application packet number) 631 is "n." Furthermore, each of the mapping tables 643 to 645 consists of "n-bit data."
, individual transport packets (addresses) arranged from the beginning in the stream block.
One bit is assigned to each of the following packets:
FIG. 12 is a diagram illustrating the internal structure of the sector data header shown in FIG.
The sector data headers 12 and 13 in FIG. 1(c) and (i) are data areas 21 and 22.
12, the data arrangement information in the first address is shown.
The internal data includes an access point 651 and a transport packet connection flag 652.
As shown in Figure 12(d) (and the bottom of Figure 9), the same as one sector,
A stream pack with a size of 2048 bytes consists of a pack header and
This stream PES packet is composed of a stream PES header.
In the data block, the sector data header 12 of FIG. 12(a) or the stream data of FIG. 11(a) is
Application packet header corresponding to part of stream block header 11
This application packet header contains the following, as shown in FIG.
* Application packet header format version description; * Application packets (transport packets) that start within the stream pack
* The number of application packets (AP_Ns) that start in the stream pack;
The stamp position is described as a relative value from the first byte of the stream pack.
, First application packet timestamp position FIRST_AP_OF
FSET; *Are header extension and/or stuffing bytes present?
Extension header information EXTENSION_HEADER_I indicating whether
FO; *SERVICE_ID, the identifier of the service that generated the stream. FIRST_AP_
OFFSET is the first bit included in the sector data header 12 in FIG.
As shown in FIG. 1B, transport packet d is transmitted across two sectors.
Here, the last timestamp in the sector or the
If a transport packet crosses over to the next sector, a transport packet connection flag is generated.
In the example of FIG. 1B, the block 652 is set to "1".
Data area 2 at the beginning of the timestamp following transport packet d
The address in 2 is recorded in the first access point 651 (in bits).
The file of sector No. 1 (or its corresponding stream pack) shown in Figure 1(d)
The first access point value is set in the data area 22 of sector No. 1 (FIG. 1(c)).
This can be set to a value larger than the size of the section.
The timestamp corresponding to the packet that follows the packet recorded in Data No. 1
In this embodiment of the present invention, the value of the first access point 651 is
A value larger than the size of the data areas 21, 22, 23, and 24 can be specified.
So, the sector size (or stream pack size = 2048 bytes)
The timestamp start position is specified even for packets with a size larger than
For example, in the data structure of FIG.
It is assumed that the data is recorded across sectors 0 to 2. Furthermore, the packet
The time stamp for sector No. 0 is located at the first position in the data area 21.
At the same time, the timestamp for the next packet is recorded in sector number.
In this case, the value of the first access point of sector No. 0 is "0", and the value of the first access point of sector No. 1 is "0".
The value of the first access point of data area No. 1 is "Data area No. 1".
The value of the first access point of sector No. 2 is "T
FIG. 13 shows the encoding procedure for stream data according to an embodiment of the present invention.
7 is a flowchart illustrating a recording procedure. First, in the encoding unit 401 in FIG. 7, packetized data is
1(b), 8(f), etc., or the AT
S) in the buffer memory unit 420 (step S01). In other words, in step S01,
Therefore, playback data stored in sectors of consecutive stream blocks (SOBU)
The data area is a transport packet with time stamp (ATS) (application
The timestamp added here is
7 is used. Next, the time stamp and packet data temporarily stored in the buffer memory unit 420 are
The bit string containing the data is divided into stream blocks (or SOBUs).
In this embodiment, the same transport packet is used as shown in FIG.
(d) is prohibited from being recorded across different stream blocks (#1, #2).
In this case, the time stamp temporarily recorded in the buffer memory unit 420 in FIG.
Step S02: Separating the stamp and packet data into stream blocks
In this case, a set of a timestamp and a transport packet is a complete stream.
The data must be divided so that it fits within the block.
The code (Fig. 1(j)) and padding areas are added as needed (step
In this way, the buffer memory unit 420 is switched for each stream block (SOBU).
The separated timestamp and packet data bit string are further separated into
It is divided into each block (or each stream pack of 2048 bytes) (step
In this embodiment, the same transport packet (d) is transmitted to different sectors.
It is also possible to record across the areas (No. 0 and No. 1 in FIG. 1(d)).
In this case, in step S04, the data areas 21, 22,
The data is randomly divided according to the predetermined size assigned to sectors 23 and 24. After that, the first position of each sector (stream pack) in the buffer memory unit 420 is
In the position, a pack header and a PES header as shown in FIG. 1(c), FIG. 9, etc.
The information of the pack header and PES header inserted in step S05 is
The information is stored in the device that generated the transport packet (application packet).
The sequence header information is output arbitrarily by the device (application device).
Next, the padding area size at the end of the stream block (SOBU)
Is the size larger than the sector recording size (stream pack size 2048 bytes)?
For example, if the last stream of stream object #A 298 in FIG. 1(f) is
In the recording block #2, the user can end the recording at any point.
Therefore, the size of the recordable area in stream block #2 is
In this case, the result of the determination in step S06 is that the total padding area is
The sector size is larger than the sector recording size. (Examples of (f) to (j) in Figure 1)
In this example, the stream data is recorded up to the middle of sector No. 78, and then sector No.
In this case, the pad 79 in FIG.
The total size of the recording areas 37 and 38 is larger than the size of sector No. 79.
In this case (YES in step S06), the stream ID 60 in FIG.
The value of sector 3 is set to "10111110" as described above, and sector No. 79 (
All sectors filled with padding area) are converted to padding packets 40
If it is determined in step S06 that the padding area size is equal to or smaller than the sector recording size, the data is written to the padding area (step S07).
If it is determined that the pad is
Once the conversion process into the ping packet is completed, the data recorded in the buffer memory unit 420 is
The packet data sequence in the stream block (SOBU) is analyzed.
From the results, the related information of the transport packet information (Fig. 11(b) to (e) and Fig.
12(b) to (d)) are created. Then, the first cell in the stream block is created.
The stream block 11 in FIG. 11(a) is inserted immediately after the PES header of the
(Step S08). Alternatively, the first sector (first stream
After the PES header of the frame pack, the application shown in Figure 9, Figure 11, etc.
A header is inserted (step S08). Furthermore, all the data except the first sector and padding packets in the stream block are
For each sector, the PES header is immediately followed by the sector data shown in FIG. 12(a).
Alternatively, the first sector (the first stream) in the stream block (SOBU) is inserted (step S09).
for all sectors (stream pack) excluding the padding area
Then, after the PES header, the application header shown in Figures 9, 12, etc.
The header insertion in steps S08 and S09 is performed by the buffer memory.
The bit stream encoded by the above steps (steps S01 to S09) is
stream (a stream having a data structure created on the buffer memory unit 420)
The information is stored in an information storage medium such as a DVD-RAM disk by the device shown in FIG.
3 or 201 in FIG. 7. In step S08, all the transforms in the stream block (SOBU) are recorded.
The port packet header 511 (FIG. 8(b)) is searched for and the payload of FIG.
Unit start indicator 501, PID 502, random access indicator
The transport packet mapping table in FIG. 11(e) is created using the value of the data 503.
Each data in the table 632 can be created. Also, the first timestamp in the next stream block (SOBU) can be created.
value and the value of the first timestamp in the current stream block (SOBU)
Calculate the difference between the time difference and the time difference 625 in FIG. 8(c)
14 shows a procedure for decoding stream data according to an embodiment of the present invention.
8(c), (i) or (h) of FIG. 8.
The stream information recorded on the RAM disk 201 is demultiplexed by the demultiplexer 42 shown in FIG.
Stream data is extracted from the transport packets in the
The playback procedure for the data will be explained below. The range to be played back is specified by the user using time information.
is the stream block (or S) to be played back that corresponds to the specified time information.
First, a process for searching for the RAM disk (see FIG. 3) on which information has been recorded using the method illustrated in FIG.
7) is loaded into the disk drive unit 409 of FIG.
After that, for example, the device user can specify the desired playback range as the "playback start time".
After this specification is made, the key input section in Figure 7
407 (or a remote controller, not shown)
) is pressed, the main MPU 404 in FIG.
3(f) in accordance with the control unit 404c.
T) 232 and reads the contents of the time map information 252 in FIG.
From the read information, the main MPU 404 determines the specified "start playback"
Stream Block (SOBU) containing the "time" position (playback start time position)
The number and the start address of the stream block (SOBU) are calculated (
Step S11). In the embodiment shown in FIG. 3(i), the time map information 252 contains
In this case, only the differential time information for each stream block is recorded.
The stream data playback control unit (playback control program) in 404 controls each stream.
Time machine information (SOBI) 242, 243 (FIG. 3(g))
the time difference between the stream blocks in the data block information 252 (see FIG. 5(b)) 263;
The value of 265 is added sequentially and compared to see if it reaches the time specified by the user.
Based on the comparison results, the time specified by the user is determined to be which Stream Object (SOB)
The timestamp value contained in the stream block (SOBU)
This determines whether the stream block you are trying to access matches the
Alternatively, a stream object having a data structure as shown in FIG. 29 can be obtained.
When SOBI information is used, the information contained in this SOBI (type)
map information MAPL, the number of entries in MAPL MAPL_ENT_Ns, etc.
The start address of the stream block (SOBU) to be accessed
The head position address determined in step S11 can be used to determine the head position of the disk drive unit 40.
The disk drive unit 4 thus receives the address information of the access destination.
09 is the address of a specific stream block (SOBU) corresponding to this address information.
The beginning position of this stream block (SOBU) is accessed.
Starting from this, the disc drive unit 409 reads from the loaded disc 201,
Reads recorded stream data in units of stream blocks (SOBU).
By the process of step S12, the packet arrival time (or application packet arrival time) is calculated.
individual transport packets (or APs) with their associated packet arrival times (APATs)
The packet is retrieved (recorded contents are
The stream data thus read is then transferred via the D-PRO unit 410 to the digital
The data is transferred from the disk drive unit 409 to the separation unit 425 in the decoding unit 402 .
The transferred stream data is temporarily stored in the internal memory 426 of the separation unit 425.
When the amount of stream data stored in the internal memory 426 of the separation unit 425 exceeds a certain amount, the data is transferred to the internal memory 426 (step S13).
Then, the packets in the padding area (37, 38, etc. in Figure 1(j))
It is automatically detected whether it is a padding packet or not.
If a padding packet is found in the internal memory 426 of the separator 425, the padding packet is
The padding area including the fetching packet is stored in the internal memory 42 of the separator 425.
The padding packets are then removed from the stream data by the separation unit 425 (step S14).
On the internal memory 426, various headers (pack header, PES header, stream header,
block headers, sector data headers, etc.) are erased.
The stream data on the internal memory 426 of the remote unit 425 is time stamped (AT
S) and converted into a stream of packet data only (bit stream)
Step S15. Next, the converted bit stream data is transmitted to a communication line (IEEE1394 system).
It is necessary to transfer the data to an external device (such as the STB unit 403 in FIG. 7) using a real bus or the like.
It is checked whether or not there is one (step S16). The check in step S16 can be performed, for example, in the following manner.
That is, when the user of the device in FIG. 7 initially sets up the device, the user can select "playback bitstream" and
"Transfer game to external device? ...Yes/No" setting screen (not shown)
If you select Yes in the
The stream data reproduced from the information storage medium 201 is sent to the STB unit 403 in FIG.
If it is necessary to send it (YES in step S16),
The stream is played back in synchronization with the timestamps attached to the
The data is sequentially transferred to the STB unit 403 (step S17).
If IEEE1394 is used as the transfer method to 3, the played stream
The system data is converted into the data structure shown in Fig. 8(e) and transferred. If the IEEE1394 transfer is not required (No in step S16), or
After the IEEE1394 transfer is completed, the data is stored in the internal memory 426 of the separation unit 425.
, time stamp (ATS) from the converted bitstream in step S15
The data is then converted into a data string of only packet data (step S18). The packet data in the converted data string contains the following information according to the contents at the time of recording:
, video packets, secondary video (SP) packets, audio packets, etc.
The data packs containing these packets have a pack header.
The stream ID (not shown) in the header determines the type of data (video or sub-picture)
By referring to the contents of this stream ID, the video packet can be distinguished from the video packet shown in FIG.
The sub-picture packets are transferred to the decoder 428, and the sub-picture packets are transferred to the SP decoder 429.
The audio packets are then transferred to the audio decoding unit 430.
In each decoding unit (428 to 430), the corresponding recorded content is individually
The various information recorded in this manner (video, sub-picture, audio, etc.) is decoded separately (step S19).
When the code is started individually, the STC (System Time Counter) 424 in FIG.
Based on the playback timestamp set in
and/or audio information is reproduced at a predetermined timing (on a monitor TV).
The playback time stamp in step S20 is displayed on the screen or played back as audio from a speaker (step S20).
The PES header (604 in FIG. 10B) is used.
Alternatively, the playback timestamp in step S20 can be set as shown in FIG.
The SCR (System Clock Reference) base (
15 and 16 show a part of the stream data according to an embodiment of the present invention.
15 is a diagram for explaining the partial erasure method. FIG. 15 shows the details of the apparent first half remaining area 743 after partial erasure.
FIG. 16 shows the details of the apparent second half remaining area 744 after partial erasure.
22 and 24 show stream data according to another embodiment of the present invention.
This explains how to erase a part of the data, and each stream block is a fixed size (32
It is composed of Stream Object Units (SOBU) of 64k bytes per sector.
FIG. 22 shows the details of the apparent first half remaining area 743 after partial erasure.
FIG. 24 shows the details of the apparent latter remaining area 744 after partial erasure.
23 and 25 show a stream data according to another embodiment of the present invention.
This explains the temporary erasure method of data, where each stream block is a fixed size (32
It is composed of Stream Object Units (SOBU) of 64k bytes per sector.
FIG. 23 shows the case where the erasure areas (741, 742) in FIG. 22(g) and (h) are temporary erasure areas (
25 shows an example of a data structure in the case where
The erased areas (741, 742) of 24(g)(h) are temporary erased areas (747, 748
) is shown as an example of the data structure in the case where the stream already recorded on the information storage medium 201 in FIG.
Regarding partial (or temporary) erasure of part of the system data
In a stream data recording/playback device (streamer), partial erasure processing (temporary erasure) is performed.
The process is executed by the control program "Stream Data Partial Deletion" of the main MPU unit 404 in FIG.
In one embodiment of the present invention, data erasure (or temporary erasure) is always performed by the stream.
This is done in units of music blocks (or SOBUs).
Time information specifying the cell range (cell start APAT (SC_S_APAT/ERA_
S_APAT); Cell End APAT (SC_E_APAT/ERA_E_APAT)
T)) allows the user to specify a detailed area to be erased (or a temporary area to be erased)
This is also a feature of the present invention. In one embodiment of the present invention, as shown in FIG. 1(b)(j),
The end of the block (or SOBU) is padding area 36, 38, and the same block
Transport packets can be recorded across different stream blocks (SOBU).
This structure ensures that the boundaries of transport packets and stream blocks are always aligned.
Since the breaks between the stream blocks (SOBU) match,
17 shows a procedure for partially erasing stream data according to an embodiment of the present invention.
This is a flowchart explaining the procedure for completely erasing part of the recorded information.
Use the flowchart to learn the temporary erasure procedure (part of the recorded information is erased as if it were erased)
The management information is changed as described above, but the information itself is not deleted but remains.
Although not shown in FIG. 17, the main MPU 404 in FIG. 7 executes "stream
A control program called "Partial Data Erase/Temporary Erase Control Unit" 404d starts.
First, the information storage medium 201 loaded in the disk drive unit 409 in FIG.
Stream.IFO, which contains management information about stream data.
The information in 105 (see FIG. 2, FIG. 3(e), etc.) is read.
The information is temporarily stored in the work RAM 404a in the main MPU 404. The information storage medium 201 loaded in the disk drive 409 in FIG.
As the state before (or before temporary erasure), Stream Object (SOB) #B
・299 is recorded. This SOB#B is a stream block (or S
OBU) #3 to #5, and all transport packets recorded therein
If the packet (or application packet) is in a state where it can be played back,
In this case, the erasure process is performed using the original cell information corresponding to SOB#B.299.
#2 273 (FIG. 3(g); this original cell information is stored in the work RAM 404
a) is included as part of the management information STREAM.IFO 105 temporarily stored in
The following are specified as the specified range: (1a) The start time 751 of the relevant cell (FIG. 15(l) or FIG. 22(l))
The time corresponds to transport packet r (FIG. 15(k) or FIG. 22(k)).
The time stamp r (which represents the arrival time of transport packet r) is specified.
(2a) At the end time 756 of the relevant cell (FIG. 16(l) or FIG. 24(l))
The time is set to the time corresponding to the transport packet w (FIG. 16(k) or FIG. 24(k)).
Specify the time of timestamp w (indicating the arrival time of transport packet w)
On the other hand, in the case of temporary erasure processing, the original cell corresponding to SOB#B·299 is
Specification range of information #2 273 (Fig. 3(g); part of STREAM.IFO105)
The following are specified within the range: (1b) The start time 752 (FIG. 23(l)) of the relevant cell is set as the transport time.
The time (transmission time) of the timestamp rr corresponding to the packet rr (FIG. 23(k))
(2b) the end time 758 (FIG. 25(l)) of the corresponding cell is set to the transport
The time of time stamp j corresponding to packet j (FIG. 25(k)) (transport
In the following explanation of the partial erasure procedure (or temporary erasure procedure),
Before and after erasure, STREAM.IFO105 and STREAM.VRO1 in FIG.
15, 16 and 22 to 25 show how the contents of .06 change.
The explanation will be given with reference to the appropriate cases. First, the case of partial erasure will be explained, and then the case of temporary erasure will be explained. [In the case of partial erasure] Now, let us consider the case shown in FIG. 15(f), FIG. 16(f), FIG. 22(f) or FIG. 24(f).
Partially erases the center of Stream Object (SOB) #B.299
15(g), 16(g), 22(g) or 24(g)
Assuming that the apparent erasure area 741 is set as shown in FIG.
First, the user can specify the range of partial deletion by entering time information (start time of partial deletion and part of the data).
By this specification, the scope of the "apparent erased area 741" shown in FIG. 15(g) etc. is specified.
After this erasure range designation operation, the SOB#B·2 in FIG. 15(f) etc.
99, the apparent first half remaining area 743 and the apparent second half remaining area 744
(See Fig. 15(g), Fig. 16(g), Fig. 22(g) or Fig. 24(g))
The range of the "apparent erased area 741" is specified in step S21.
and the master MP that executes the stream data partial deletion/temporary deletion control unit 404d in FIG.
The U unit 404 generates time map information (252 in FIG. 3(h) or
Based on the contents of the read time map information,
The stream blocks that are completely included in the range of partial erasure specified by the user (
One or more SOBUs or an SOB containing one or more SOBUs; typically
The stream block (SOBU) is searched for.
Transport packets included in the corresponding SOB
All application packets before the end of erasure are erased.
The stream block (or SOBU) thus deleted is then stored in the management area shown in FIG.
Information (STREAM.IFO/SR_MANGR.IFO) 105
It is treated as if it is not in the file STREAM.VRO106 (i.e., the file
The system will ignore the deleted Stream Block/SOBU.) Note that the information on the deleted Stream Block/SOBU
The physical address location on the storage medium 201 is the DVD_RTR directory shown in FIG.
102 (where the management information 105 cannot be involved, for example,
Another file that exists under the computer data storage subdirectory 113 of
In this case, the file exists under the subdirectory 113.
The physical recording location on the information storage medium 201 where the separate file is recorded is
In the system, it is removed from the file STREAM.VRO 106. Next, the first half remaining area 743 and the second half remaining area 744 for the partial deletion range shown in FIG.
The stream object (SOB) is divided into two parts, one for each of the remaining areas 744 and one for each of the remaining areas 744.
The new stream object (SOB# in FIG. 15(h) etc.) generated by the division of
SOB information (SOBI) for SOB #B*745, SOB #C*746 is created.
The created SOBI is stored in the work RAM 404a in the main MPU 404 shown in FIG.
At that time, the time machine recorded for SOB#B before division is
The relevant part of the SOB information 252 is transcribed to create new SOB#B*745 and
Time map information for SOB#C.746 is also created (step S23).
The specific targets for the above time map information content changes (transcription/creation) are, for example:
Various information (261 to 265) shown in FIG. 3(i) or the stream shown in FIG.
Contents of the system object information (SOBI) (MAPL, MAPL_ENT_Ns, etc.)
) Note that when the time map information (MAPL) is shortened due to partial erasure,
"One or more subsequent" following the SOBI containing the lost time map information (MAPL)
"Continued SOBI and all subsequent information tables" refers to the modified (shortened) SO
This prevents gaps from occurring between adjacent SOBIs.
In this case, SOBI_SRP# in FIG. 29, part of SFIT, FIG. 3(f) or
STR_VMGI in FIG. 27 (all start addresses of information tables after SFIT)
The main MPU 404 in FIG. 7 controls the stream data partial erase/temporary erase control unit 404.
Executes processing according to a sequential program for d, and
The data read instruction is sent to the information storage medium 20.
Stream data is recorded in the file STREAM.VRO (also
is from within SR_TRANS.SRO) 106 (FIG. 2), stream block #5
The data ((i) to (l) in FIG. 16 or FIG. 24) is reproduced, and the data is the main
The data is temporarily stored in the work RAM 404a in the MPU 404. Next, the main MPU 404 searches the temporarily stored data and
) or the area closest to the start time of the apparent second half remaining area 744 shown in FIG.
The search results are in sector No. 112 as shown in (i) to (k) of FIG.
The time stamp k (or sector number as shown in FIG. 24(i) to (k))
If the timestamp k) in 144 matches or is close to the value
The value of this timestamp k is the value of the corresponding cell in the original cell information #3·762.
The start time (SC_S_ATAP, etc.) 752 of the cell thus set is set to the value of
The stream data temporarily stored in the work RAM 404a in the main MPU 404 is
Data management information STREAM.IFO (or SR_MANGR.IFO) 10
Similarly, the end time (SC_E_
ATAP, etc.) 756 is the original cell information #2.27 before partial erasure.
In the embodiment shown in FIG. 15, FIG. 16, FIG. 22 or FIG. 24, the value of the end time 756 of the corresponding cell of the stream
Since the block #4 is completely included within the range of the partial erase, that part is effectively erased.
At this time, stream block #3 and stream block #5 are not substantially erased.
15, 16, 22 or 24.
As shown in (g) to (g), the end of stream block #3 and
A part of the beginning of the block #5 is an apparent erasure area 7 designated by the user, etc.
In one embodiment of the present invention, the first half remaining area for the range 741 of partial erasure is included in
743 and the latter remaining area 744, a stream object (SOB
#B) is split and separated, and the original cell range is also split accordingly.
Corresponding to this division and separation, the embodiment of FIG. 15, FIG. 16, FIG. 22 or FIG. 24
In this example, the position of stream block #5 is newly added to stream object #C.
On the other hand, the stream object (SOB) #B 299 before erasure is defined as .746.
The stream object information (SOBI) #B 243 (FIG. 3(g))
The time map information (the contents of which are the same as those in FIG. 3(i) and the SOBI in FIG. 29)
Stream block #5
The block size and the stream block time difference value do not change before and after partial erasure. Therefore, as shown in step S23 of FIG. 17, this time map information is
The newly created stream object is stored in STREAM.IFO 105.
Stream corresponding to object #C 746 (Fig. 16(h), Fig. 24(h), etc.)
The partial deletion corresponding to this newly defined stream object #C 746 is transcribed as time map information in stream object #C.
The original cell information #3·762 after deletion (FIG. 16(m) or FIG. 24(m)) is
The display range to be specified is the range of the apparent second half remaining area 744 specified by the user.
When the time map information is created by the process of step S23, the newly defined
Original cell information for the SOB (SOB # #B*, SOB #C) is created.
In creating this original cell information, the corresponding original cell #3 762 (
The specified range (FIG. 16(m) and FIG. 24(m)) is set. This setting is performed so that the start time of the corresponding cell is set to the end time of the partial erasure specified by the user, etc.
By adjusting the clock (or by the user, etc.), the partial deletion start time
Specifically, taking the illustration in the lower part of FIG. 31 (described later) as an example, after complete erasure (partial erasure
After the complete erasure is completed, the new SOB cell #k+1 (before the complete erasure, the cell #k
+2) start time (SC_S_APATk+1) is set by the user, etc.
The erase end time (SC_E_APATk+1 of cell #k+1 before complete erasure)
Or, at the end of cell #k of the SOB after complete erasure (cell #k before complete erasure)
The time (SC_E_APATk) is the erasure start time (complete erasure start time) specified by the user, etc.
In the example illustrated in the lower part of FIG. 31, the SC_S_APAT of cell #k+1 before and after the complete erasure is
Regarding this, the start time (SC_S_APATk) and end time (SC_E_
APATk) remains unchanged. The above-mentioned "SOBI align" is performed by the process of step S24.
(This prevents gaps from occurring between adjacent SOBIs.) Next, the original (before erasure) stream object information (SOBI) #B·24
3 (FIG. 3(g)) information (time map information, etc.) is rewritten (step
Specifically, the substantially erased area 742 (FIG. 16(h), FIG. 24(h))
and the newly defined SOB area 746 (FIG. 16(h), FIG. 24(h)).
The time map information is rewritten with the minutes removed from the original time map information.
The reason for this is that after partial erasure, SOB#B*745 (see (h) of FIG. 15 and (c) of FIG. 22)
Since the stream block constituting (h) is only #3,
The stream that was essentially deleted from the time map information in SOBI#B・243
Part of Stream Block #4 and another Stream Object (SOB #C)
This is because it is necessary to delete the information of stream block #5 that has become the attribute. This information deletion is the information rewriting process of step S25. This deletion process is the same as that shown in FIG.
The management information (S
In step S25, the information (time map information, etc.) is rewritten.
The "SOBI align" described above is performed (this creates a gap between adjacent SOBIs).
(This prevents gaps from occurring.) Next, the information content of the original cell information #2 273 before erasure is changed.
Here, original cell information #3·76 in step S24 is
First, the same process as in the creation of the original cell corresponding to the SOB whose time map information has been rewritten is performed.
The time range is changed (step S26). This change is made so that the end time of the cell in question is set to the partial erasure start time designated by the user or the like.
By adjusting the clock (or by the time specified by the user, etc.),
Specifically, taking the illustration in the lower part of FIG. 31 (to be described later) as an example, cell #k (before complete erasure)
The end time (SC_E_APATk) of the cell (cell #k) is specified by the user, etc.
The erase start time (SC_S_APATk+1 of cell #k+1 before complete erasure)
Or, at the start of cell #k+1 after full erasure (cell #k+2 before full erasure)
The time (SC_S_APATk+1) is set to the erasure end time (
Next, the main MPU 404 in FIG. 7 controls the stream data partial erase/provisional erase control unit.
404d, and executes the process according to the sequential program.
A data read instruction is issued to the live unit 409.
A file STREAM.VRO in which stream data is recorded on the body 201
(or SR_TRANS.SRO) 106 (FIG. 2) from within the stream block
The data of block #3 ((i) to (l) in FIG. 15 or FIG. 22) is reproduced, and the data
The data is temporarily stored in the work RAM 404a in the main MPU 404. The main MPU 404 searches through the temporarily stored data and
is more likely to occur at the end time of the apparent first half remaining area 743 shown in FIG. 22(g).
The search results are shown in (i) to (k) of FIG. 15 or FIG. 22, and the sector number is
If it matches or is close to the value of the timestamp v in .90,
The value of this timestamp v is the original cell information #2·761 (
The end time 757 (FIG. 15(l)) of the corresponding cell in FIG. 15(m) and FIG. 22(m),
The value thus set is stored in the work RAM 404a of the main MPU 404.
Temporarily stored management information (STREAM.IFO/SR_MANGR.IFO)
The start time of the corresponding cell in the original cell information #2 761 after partial erasure is 7
The value of 51 (SC_S_APAT) is the original cell information #2.2 before partial erasure.
Since the value of the start time 751 of the corresponding cell of 73 is the same as the value (SC_S_APAT),
The value remains unchanged and is used as management information (STREAM.IFO/SR_MANGR
When the above series of processes are completed, the changed data is stored in the work RAM 404a in FIG.
Stream data management information (STREAM.IFO/SR_MANGR.IF
O) Based on the information in 105, the main MPU unit 404 issues a command to the disk drive unit 409.
This causes the STREAM.IFO/SR_MANG on the information storage medium 201 to
The information in the R.IFO 105 is rewritten (step S27). As a result of this information rewriting, the deleted stream block (SOBU) is
It will be ignored by the file system (DVD_RTAV file system)
Finally, in S28, the volume and file structure recorded on the information storage medium 201 is
The information in the creation information 206 (FIG. 3B) is rewritten, and the file system information is
The data size and time information (time difference) for each stream block are recorded (step S28).
This specified range is used for the range specified by the Stream Object Information (SOBI).
The specified range of the original cell information that indicates the playback range corresponding to the range is set to be equal to or
can be narrowed ((f) to (f) in Fig. 15, Fig. 16, Fig. 22 or Fig. 24).
In this way, the user can see that the stream blocks
It is possible to erase a portion of recorded SOB information in any arbitrary range, even in a small area.
The location where the memory block is recorded (= address information) can be calculated.
After the partial erasure process is performed as described above, the data is reproduced from the information storage medium 201.
As shown in FIG. 4, one original PGC 290 has original cell #2
In other words, the user or the like can play back the original cell #1 and original cell #2 from the information storage medium 201 on which the partial erasure process has been executed.
When the original cell is reproduced, the original cell information #2·761 (FIG. 15(m), etc.)
The playback starts from the start time 751 of the cell and ends at the end time 757 of the cell.
Immediately after that, the corresponding cell in the original cell information #3·762 (FIG. 16(m), etc.)
The playback will start continuously (usually seamlessly) from the start time 752. [Temporary Erasure] DVD Streamers allow two types of erasure. The first is the temporary erasure described above.
The first is to completely erase part of the stream, and the second is to
Partially erased (temporary erase; abbreviated as TE)
Regarding the temporary erasure: (11) The temporary erasure portion of the stream can be completely reconstructed; (12) The start and end positions of the temporary erasure portion are determined by the application packet.
Time information can be marked with the accuracy of the arrival time (APAT) (streamer user
The user cannot recognize internal information such as SOB, SOBU, SOBI/MAPL, etc.
Therefore, the range of temporary erasure, i.e., the start position of the temporary erasure part, can be recognized.
(13) During recording, the streamer format does not consider the contents of the stream and allows the user to mark the beginning and end positions on a time basis.
The erased part can be completely erased (this allows the temporarily erased part to be erased in real time).
(11) to (13) above are the same as those shown in Fig. 3(f), Fig. 4, Fig. 27 or Fig. 32.
Stream cell information SCI (see Figure 1) in the original PGC (not a user-defined PGC)
This can be realized by using the protect flag TE (FIG. 28) included in the
The TE flag in indicates a temporarily erased cell. Next, the stream object (S
OB) The central part of #B 299 is temporarily erased, and the same as in FIG. 23(g) or FIG.
5(g), it is assumed that an apparent temporary erasure area 747 is set.
17. In the temporary erasure process, the "partial erasure range" in steps S21 to S23 in FIG.
If you read "Delete Range" as "Temporary Delete Range," the processing procedure will be the same.
Also, steps S27 to S28 in FIG. 17 are also partially
The procedure is the same whether it is an erase or temporary erase. In the following, steps S24 to S26 in FIG. 17 are explained as follows:
23 and 25. When the time map information is created by the process of step S23, the newly defined
Original cell information for the SOB (SOB # #B*, SOB #C) is created.
In creating this original cell information, the designated range of the corresponding original cell is set.
Specifically, taking the illustration in FIG. 30(b) described later as an example, the temporary erase flag TE is set to
The start time of cell #k+1 set to "10b" is specified by the user, etc.
This is the temporary erasure start time (ERA_S_APAT; temporary erasure start mark).
The end time of cell #k+1, whose temporary erase flag TE is set to "10b", is
The temporary erasure end time (ERA_E_APAT; temporary erasure end time) specified by the
Alternatively, taking the illustration in the upper part of FIG. 31 (to be described later) as an example, when the temporary erasure flag TE is "1",
The start time of cell #k+1 set to 0b" is SC_S_APATk+1.
The end time of this cell #k+1 is SC_E_APATk+1. Next, regarding the original (before temporary erasure) stream object information (SOBI),
Information (such as time map information) is rewritten in the same way as the partial deletion described above.
In this temporary erasure, the data to be temporarily erased is not erased itself, but the data to be temporarily erased is erased.
The management information of the data is simply rewritten to the "temporarily erased" state.
The data to be erased (in the example of FIG. 30(b) or the upper part of FIG. 31, the data of cell #k+1)
When the data is completely erased, the following process is performed: First, the original cell corresponding to the SOB whose time map information has been rewritten is erased.
The time range is changed (step S26). Specifically, taking the illustration of FIG. 30 (described later) as an example, the temporarily erased cell in FIG.
The start time (ERA_S_APAT) of #k+1 is the time after complete erasure in FIG. 30(c).
The temporary erasure time is set to the end time (SC_E_APAT) of the file #k.
The end time (ERA_E_APAT) of cell #k+1 is after the complete erasure in FIG. 30(c).
The start time (SC_S_APAT) of cell #k+1 (cell #k+2 before complete erasure)
The main points of the temporary erasure process described above can be summarized as follows: (a) The temporary erasure start time (ERA_S_APAT) and the temporary erasure end time (
ERA_E_APAT) is included in the Stream Object (SOB).
for a part of the bitstream information (temporarily erased area 747 in FIG. 23 or FIG. 25)
A temporary erasure range is designated (at step S21, the "partial erasure range" is designated).
(This should be read as "provisional erasure range"). The start time (SC_S_APAT) starts within the stream block (SOBU).
If it matches the beginning of the transport packet (application packet)
When the application starts, a transport packet (
Starts within a stream block (SOBU) containing a
The first transport packet (application packet)
The start time of temporary erasure (ERA_S_APAT) is
T) (in step S26, "partial erase" is read as "temporary erase"
Then, rewrite the streamer information (STREAM.IFO/STRI).
(b) Alternatively, the start time of temporary erasure (ERA_S_APAT) and the end time of temporary erasure are set (step S27).
The stream object (SOB) is
) included in the bit stream information (the temporary erasure area 7 in FIG. 23 or FIG. 25)
47) is designated (in step S21, "partial erasure" is
The cells (TE cells) corresponding to the specified temporary erasure range are
When it contains the beginning of a SOB, it is accompanied by a start time (SC_S_APAT).
Stream containing transport packets (application packets)
Transport packets (applications) starting within a SOBU
The temporary erasure is performed at the start time (SC_S_APAT) of the first of the temporary erasure packets.
The start time of the erasure (ERA_S_APAT) is adjusted (at step S26,
"Partial deletion" should be read as "temporary deletion"). And, streamer information (STRE
(c) Alternatively, the temporary erasure start time (ERA_S_APAT) and the temporary erasure start time (ERA_S_APAT) are rewritten (step S27).
The stream object (SOB) is
) included in the bit stream information (the temporary erasure area 7 in FIG. 23 or FIG. 25)
47) is designated (in step S21, "partial erasure" is
(The "Application Data Range" is replaced with "Temporary Data Range").
Stream blocks (SOBU in FIG. 30(b)) containing
#3) in another stream block (SOBU #2 in FIG. 30(b)) immediately following it.
The first transport packet (application packet) that starts with
The start time of the temporary erasure (ERA_S_APAT) is
APAT) (in step S26, "partial erase" is changed to "provisional erase"
Then, the streamer information (STREAM.IFO/STRI)
(d) Alternatively, the temporary erasure start time (ERA_S_APAT) and the temporary erasure start time (ERA_S_APAT) are rewritten (step S27).
The stream object (SOB) is
) included in the bit stream information (the temporary erasure area 7 in FIG. 23 or FIG. 25)
47) is designated (in step S21, "partial erasure" is
(The "erasing range" is replaced with the "temporary erasure range"). The trace immediately following the cell (TE cell) corresponding to the part where the temporary erasure range is specified
Stream packets containing transport packets (application packets)
Transposon starts within the block (SOBU#1 of cell #k+1 in Figure 30(c)).
The start time of the first application packet (S
Set the temporary erasure end time (ERA_E_APAT) to the temporary erasure end time (ERA_E_APAT).
(In step S26, "partial erasure" is replaced with "temporary erasure").
, rewrite the streamer information (STREAM.IFO/STRI) (step
S27). FIG. 18 shows MPEG encoded video data (before partial erasure or temporary erasure)
FIG. 19 is a diagram for explaining a method for setting time management information for the original cell information (partial erasure) corresponding to the video data of FIG.
Explain the relationship between time information and field information in the
In the above-described embodiment, a specific data size (for example, 32 sectors/64k) is used.
Substantial partial erasure is performed for each stream block (SOBU) divided into
The detailed apparent partial erasure range can be defined in the original cell range.
However, the present invention is not limited to this.
Divide and manage into units or blocks, and manage each unit or block
In addition to erasing, you can specify the range of playback information (cells, etc.) to perform "user-defined" playback.
This invention can be applied to any method that allows you to specify a detailed playback range.
For example, a management information file for managing video information recorded in MPEG2 can be created.
In the RTR.IFO 104 (FIG. 2), the MPEG2 motion picture is
The I-picture to the point just before the next I-picture is taken as a unit, which is specific to image compression.
This unit is called a Video Object Unit (VOBU).
This VOBU corresponds to a Stream Object Unit (SOBU).
The NTSC TV standard displays approximately 30 images (frames) per second.
Each image is called a picture, and in the interlaced format, one picture (frame) is
The image is displayed using two field scans (odd field scan and even field scan).
The streamer records the time when the stream data arrives at the receiver.
The timestamp information is used as time (hour) information.
In one embodiment of the present invention, the first I shown in FIG.
It is also possible to express time information by counting the number of fields from picture a.
In this embodiment, the time map information is
For example, the stream block size in FIG.
For H.262, the data size of one VOBU (or SOBU) corresponds to
In addition, the time information corresponding to the stream block time difference 263 is
The number of fields contained in the corresponding VOBU (or SOBU) is
At this time, the information of original cell #1 (SCI in FIG. 28) 763 (FIG. 19) is
The start time of the corresponding cell (SC_S_APAT or ERA_S_APAT
) 753 and the end time of the corresponding cell (SC_E_APAT or ERA_E
APAT) 758 information is the number of fields counted from the first I-picture a in FIG.
For example, the time information of the nth picture in FIG. 18 can be expressed as the 2nth field.
FIG. 20 shows the MPEG encoded video data (after partial erasure or temporary erasure)
FIG. 21 is a diagram illustrating a method for setting time management information for the original cell information (partial erasure) corresponding to the video data of FIG.
Explain the relationship between time information and field information in the
When the video information in FIG. 18 is subjected to partial erasure processing, the result is as shown in FIG.
In other words, only VOBU#2 (SOBU#2) is effectively partially erased.
The range of small part erasure specified by is the same as that of the stream described with reference to FIG. 15 and other figures.
As in the case of partial erasure of system data, this can be specified by setting the range of cells. That is, in FIG. 20, if the user or the like selects a part from B picture f to B picture s,
If partial erasure is specified, VOBU#2 (SO
BU#2) is completely erased. At this time, only a part of it is included in the specified range of partial erasure.
VOBU#1 (SOBU#1) and VOBU#3 (SOBU#3) are
As with stream data, VOBs (or SOBUs) remain before and after the partially erased portion.
SOB) is divided into VOB#1 (SOB#1) and VOB#2 (SOB#2)
Correspondingly, the cells before partial erasure are the original cell #1 and the original
At this time, as shown in FIG. 21, the information (SCI) 764 of the original cell #1 is
End time of the corresponding cell (SC_E_APAT or ERA_E_APAT) 7
59, the 2fth field corresponding to the B picture f is specified, and the original
The start time (SC_S_APAT) of the cell #2 information (SCI) 765
or ERA_S_APAT) 754, which corresponds to B picture s, and 2(s-q
For example, the time information of the fth picture in FIG. 20 is the 2fth field.
In the embodiment shown in Fig. 20 and Fig. 21, the number of fields is always the same for each VOB (SOB).
The number of fields is counted from the first picture of the VOB.
In the information (SCI), the corresponding VOB (SOB) can be specified by the number of fields.
This is the feature of this embodiment. Figure 26 shows the internal structure (address) of the sectors that make up a stream block (SOBU).
Stream packs and stuffing packets, including application packets
26(d) is a diagram illustrating an example of a stream pack including a stream object (SOB) #A 298 shown in FIG.
c) As shown in (e), it is composed of multiple stream blocks #1, #2, ...
Each stream block #1, #2, ... is 2ECC block size (=3
2 sectors = 64k bytes)
In this way, for example, if stream block (SOBU) #2 is deleted,
However, the ECC block of Stream Block (SOBU) #1 is not affected by this deletion.
The first stream block (SOBU) #1 of SOB#A.298 is shown in Figure 26 (
As shown in b), sectors 0 to 31 (32 sectors/64k bytes)
Each sector of Stream Block (SOBU) #1 has a similar data structure.
For example, for sector No. 0, as shown in FIG.
In other words, sector No. 0 is a stream packet of 2048 bytes (2k bytes).
This stream pack consists of a 14-byte pack header and
The stream PES packet consists of a 6-byte PES header and a 1-byte sub-packet.
The stream data area consists of a 9-byte application header and a 2027-byte stream data area.
Header extension (optional) and stuffing bytes (optional)
The application packet area consists of an application timestamp and an application packet area.
For example, a 188-byte transport packet is an application packet.
When stored in the application packet area as packets, about 10 packets are
In stream recording, the application that generates the recording content stores the application packets in the application packet area.
Do your own stuffing so you don't have to adjust the length separately.
Therefore, in stream recording, the stream pack is always the required length (for example,
The stuffing bytes in Figure 26(a) allow the stream back to be treated as having a predetermined length (for example, 2048 bytes).
When recording a stream, the application
The first byte of the stream timestamp ATS is the
Application packet area in the first stream packet at the beginning
On the other hand, for subsequent stream packets in the SOB, the start of the adjacent stream packet must be aligned.
At packet boundaries, application packets may be split.
The partial packets shown in the lower part of FIG. 9 are the packets generated by this splitting.
This indicates an application packet. The first application timestamp starts within the stream packet.
The byte offset and the application name to start within that stream packet.
The number of application packets is written in the application header. This allows the first application packet in a stream packet to be
Before the application timestamp and after the last application packet
Stuffing is done automatically. This automatic stuffing
The pack header in FIG. 26(a) contains information about the pack start code, S
CR base information, SCR extension information, program maximum rate information
It contains information such as the SCR base, marker bit, and pack stuffing length. The SCR base consists of 32 bits, with the 32nd bit being set to zero.
The maximum program rate is 10.08 Mbps. The PES header and substream ID in FIG. 26(a) are the same as those shown in FIG. 10(c).
The application header in Fig. 26(a) has the following contents:
Application information, number of application packets AP_Ns, first application
Packet timestamp position FIRST_AP_OFFSET, extension
Header information EXTENSION_HEADER_IFO, service ID, etc.
where version is the version of the application header format.
The AP_Ns of the application header starts within the corresponding stream pack.
This describes the number of application packets in the corresponding stream pack.
If the first byte of the ATS is stored in the
FIRST_AP_OFFSET can be considered to be the start of the application packet.
The timestamp position of the first application packet in this stream packet
The value is written in bytes relative to the first byte of the packet.
If there is no application packet starting within the stream packet, the FIR
ST_AP_OFFSET is set to "0". EXTENSION_HEADER_INFO contains the stream packet
Application header extension and/or stuffing bag in
If the content of EXTENSION_HEADER_INFO is 00b, the application
The application header extension is also included after the application header.
If the contents of EXTENSION_HEADER_INFO is 10b, the application
There is an application header extension after the application header,
It indicates that no stuffing bytes are present. If the contents of EXTENSION_HEADER_INFO are 11b, the application
There is an application header extension after the application header,
And there are stuffing bytes after the application header extension.
The contents of EXTENSION_HEADER_INFO must not be 01b.
Stuffing bytes before the application packet area (optional)
is activated by "EXTENSION_HEADER_INFO=11b".
This allows the bidirectional
The number of application packets that can be stored in the application packet area.
Prevents the "packing paradox" that occurs when there is a discrepancy between the number of bits and the
SERVICE_ID describes the ID of the service that generates the stream.
If this service is unknown, SERVICE_ID is set to 0x0000.
The application packet area in FIG. 26(a) is the same as that shown in the lower part of FIG.
(The packet in FIG. 9 can be read as an application packet in FIG. 26.)
In other words, a partial application packet is added to the beginning of the application packet area.
The packet is then recorded, followed by the application timestamp ATS and the application
Multiple pairs of application packets are recorded sequentially, with a part at the end.
In other words, the start of the application packet area is
Application packets can exist. End of application packet area
At the end of the packet, a partial application packet or a reserved number of bytes is
There can be an application timestamp placed before each application packet.
The ATS consists of 32 bits (4 bytes).
The basic part is a 90 kHz unit.
The extension part is the lesser value measured at 27 MHz.
In FIG. 26(a), the application header extension indicates the application
Stores information that may differ between application packets and
Such information may not be applicable to all applications.
Therefore, the data field of the application header is not required for the stream data.
The presence of an optional application header extension within the area
and (in the EXTENSION_HEADER_INFO mentioned above)
When recording a stream, the application
The first byte of the stream timestamp ATS is the
Application packet area in the first stream packet at the beginning
On the other hand, for subsequent stream packets in the SOB, the start of the adjacent stream packet must be aligned.
At packet boundaries, application packets may be split.
The partial application packets shown in FIG. 8(f)(g) or FIG. 9 are
This shows the application packets resulting from the split. The first application timestamp starts within the stream packet.
The byte offset and the application name to start within that stream packet.
The number of application packets is written in the application header. This allows the first application packet in a stream packet to be
Before the application timestamp and after the last application packet
The stuffing is done automatically. That is, the above automation mechanism allows the application to "stack itself."
This automatic stuffing allows
The application header extension (optional) is a list of entries.
This contains the stream packet for each application that starts within the stream packet.
There is one entry for the packet, one byte long. The bytes in this entry are:
It can be used to store information that can vary from application packet to application packet. Note that the 1-byte application header extension (optional)
is a 1-bit AU_START, a 1-bit AU_END, and a 2-bit C
When AU_START is set to "1", the associated application packet
However, if there is a random access entry point (random access unit) in the stream,
When AU_END is set to "1", it indicates that the associated application packet contains a
This indicates that this is the last packet of a random access unit. COPYRIGHT indicates the copyright status of the associated application packet.
The packet structure in Figure 26(a) is applied to sectors other than the last sector of SOB#A·298.
For example, if the end of SOB#A·298 is sector No. 63 in Figure 26(f),
This sector is then filled with padding packets 40 (see FIG. 1(i)) as shown in FIG. 26(g).
)), the padding area 38 (see FIG. 26(h))
26(i), the content will be different from that of FIG. 26(a).
A fetching packet consists of a 14-byte pack header and a 6-byte PES header.
a 1-byte substream ID, a 9-byte application header,
The pack containing the head of the stuffing packet contains this application packet area.
The bit area is a 4-byte application timestamp ATS and 201
It consists of four bytes of zero byte data (data that has no actual recorded content).
On the other hand, in the pack containing the subsequent stuffing packet,
The application packet area is 2018 bytes of zero byte data (no ATS).
When recording is performed at an extremely low bit rate, the time map information (Fig. 3(h)
252 in the SOBI; or MAPL in the SOBI in FIG. 29
Stuffing is required to achieve this.
is defined as a conceptual unit for this purpose.
The purpose of the event is to ensure that each SOBU, including the Staffing Area, has at least one A
This is achieved by including a TS value in the stuffing packet. The stuffing packets are subject to the following conditions: One or more stuffing packets are always included in the actual application.
From the application packet area of the pack after the pack containing the packet data
* One or more stuffing packets start with one 4-byte ATS and the corresponding
Required to fill the application data area of the remaining SOBU packs
It consists of only zero byte data (following the ATS).
When the number of sectors per SOBU is SOBU_SIZE, 0≦n≦SOBU_S
If we set it to IZ-1, the total length of the stuffing packet is "4 + 2014 + n x 2
The ATS of the stuffing packets is set as follows: * At least one pack contains actual application packet data.
In the SOBU, the ATS of the stuffing packet is
* In SOBUs that do not contain actual application packet data, the stack is set to the ATS of the application packet that precedes the stack;
The ATS of a stuffing packet is determined according to the contents of the time map information, etc. All stuffing packets or all packets containing parts of stuffing packets are
A pack is structured as follows: * The SCR of the pack header is the SCR of the preceding pack, multiplied by 2048 x 8 bits ÷ 1
*PES packet headers and substream IDs are the same as all other PES packets.
* In the application header (see Figure 12 (c) (d)), AP_N
s=0, FIRST_AP_OFFSET=0, EXTENSION_HEAD
ER_IFO = 00b, SERVICE_ID = 0 (in the application header
27 shows the management information of the streamer (STREAM.IFO or SR_
2 or 3(e) is a diagram for explaining the internal data structure of the management information (navigation data) S
TREAM.IFO (SR_MANGR.IFO) 105 is as shown in FIG.
This streamer information STR1 is stored in the streamer information STR1 as shown in FIG. 3(f) or FIG. 27.
Streamer video manager information STR_VMGI and stream file information TE
Table SFIT and original PGC information ORG_PGCI (more generally expressed
PGC information PGCI#i) and user-defined PGC information table UD_PG
CIT, text data manager TXTDT_MG, and application program
The streamer video manager information STR_VMGI is composed of the following:
Video manager in which management information related to STR1 and STR_VMGI is written
Information management information VTSI_MAT and a search function for playlists in a stream
A playlist search pointer table (PL_
SRPT). Here, a playlist is a list of parts of a program.
The list allows the user to define any playback sequence (for the program content).
The stream file information table SFIT is directly related to the streamer operation.
Contains all navigation data. Stream File Information Table
The details of the rule SFIT will be described later with reference to FIG. 29. The original PGC information ORG_PGCI is
C) is the part that describes the information about the program set.
ORG_PGC indicates the sequence of programs (
chain), and the ".SRO" file (SR_
TRANS.SRO 106). Here, the program set refers to the entire recorded content of the information storage medium 201 (all
In the playback of a program set, any program
If the program has been edited and its playback order has been changed relative to the original recording
The playback order is the same as the recording order of the program, except for
This program set is called the original PGC (ORG_PGC).
The program corresponds to a data structure and is user-recognized or user-defined.
A program in a program set is a logical unit of recorded content.
The program is composed of the above original cells.
Furthermore, a cell is a data structure that represents a part of a program. Original PG
The cells in C are called "original cells," and are cells in user-defined PGCs, which will be described later.
are called "user-defined cells." Each program in the program set must have at least one original cell.
Each part of the program in each playlist is composed of
On the other hand, in a streamer, only stream cells (SCs) are defined.
A music cell refers to a portion of the recorded bitstream.
In the present embodiment, unless otherwise specified, when "cell" is mentioned, it means "stream"
The term "program chain" (PGC) refers to a higher conceptual unit.
In the null PGC, the PGC is a sequence of programs (chains) corresponding to the program set.
In addition, in the case of a user-defined PGC, the PGC corresponds to a playlist.
A user-defined PGC, which refers to a chain of program parts, is also called a navigation chain.
And part of each program belongs to the original PGC.
The user-defined PGC information table UD_PGCIT in FIG.
C information table information UD_PGCITI and one or more user-defined PGC search points
Inter UD_PGC_SRP#n and one or more user-defined PGC information UD_PG
The user-defined PGC information table information UD_PGCITI can include user-defined PGC information CI#n.
UD_PGC_SRP_Ns indicates the number of search pointers UD_PGC_SRP;
, UD_ indicating the end address of the user-defined PGC information table UD_PGCIT
The number of UD_PGC_SRPs indicated by UD_PGC_SRP_Ns is user-defined.
The number of PGC information (UD_PGCI) is the same as the number of user-defined PGCs (UD_PGCI).
The number is the same as the number of UD_PGCITs. This number is allowed up to 99. UD_PGCIT_EA specifies the end address of the UD_PGCIT.
Described as the relative byte count (F_RBN) from the first byte of D_PGCIT
Here, F_RBN is the beginning of the defined field in the file.
It indicates the relative byte number from the original PGC information ORG_PGCI or user-defined PGC information table.
The user-defined PGC information UD_PGCI in the UD_PGCIT is generally expressed as
The text data manager TXTDT_MG in FIG. 27 stores supplementary text information.
This TXTDT_MG is the primary text information PRM_
TXTI can be stored in the playlist and program.
Although not shown, 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 the data to be transmitted to the streamer.
The connected application device can receive any non-real-time information (including real-time
A conceptual area that can store the stream data plus any additional desired information.
FIG. 28 shows the PGC information (ORG_PGCI/UD_PGCIT in FIG. 3 or
28 is a diagram illustrating the internal data structure of original PGC information ORG_27.
PGCI or user-defined PGC information in the user-defined PGC information table UD_PGCIT
As shown in FIG. 28, PGC information PGCI#i is a general representation of PGC general information PGC_G
I, one or more program information PGI#m, and one or more stream cell information servers
The SCI_SRP#n is a pointer to one or more stream cell information SCI#n.
The PGC general information PGC_GI includes the number of programs PG_Ns and the number of streams.
and the number of SCI_SRPs SCI_SRP_Ns.
Each program information PGI (for example, PGI#1) has a program type PG_
TY, the number of cells in the program C_Ns, and the primary
Text information PRM_TXTI and item text search pointer number IT
Here, the program type PG_TY contains information indicating the status of the program.
In particular, whether the program is protected from accidental deletion, etc.
If this protect flag is "0b", the program is not protected.
When it is "1b", it is in a protected state. The number of cells C_Ns indicates the number of cells in the corresponding program.
Throughout the program and all cells, the cells are sorted according to their ascending order (implicitly
For example, in a PGC, program #1 has C_Ns=1, and program #2
If a PGC has C_Ns=2, the first stream cell information SCI of that PGC
The second and third SCIs are associated with Program #2.
The primary text information PRM_TXTI is attached to the information storage medium (DVD-RAM
In order to make the DVD 201 available worldwide, one common character set is used.
Text with (ISO/IEC646:1983 (ASCII code))
The item text search pointer number IT_TXT_SRPN is the item text search pointer number.
Text (text data corresponding to the program)
The program that executes the item text is
If not, IT_TXT_SRPN is set to "0000h". Each stream cell information search pointer SCI_SRP (for example, SCI_SR
P#1) is SCI_SA indicating the start address of the corresponding stream cell information SCI
This SCI_SA contains the relative byte number from the first byte of PGCI.
Each stream cell information SCI (for example, SCI#1) is written as a stream cell general information.
information SC_GI and one or more stream cell entry point information SC_EPI
The stream cell general information SC_GI is composed of temporary erase (TE)
A cell type C_TY including a flag TE indicating the state and an entry for a stream cell
The number of point information SC_EPI_Ns and the stream object number SOB_
N, a stream cell start APAT (SC_S_APAT shown in FIG. 6 and elsewhere),
Stream cell end APAT (SC_E_APAT shown in FIG. 6 and other figures) and the cell
Indicates the start APAT of the temporary erased cell when it is in the temporary erased state (TE=01b).
The erase start APAT (ERA_S_APAT shown in FIG. 6 and other figures) and the cell in the temporary erase state
When the erase end signal is in the erase end state (TE=10b), the erase end signal indicates the end APAT of the temporary erased cell.
The cell type C_TY contains the format of the stream cell and its temporary erase state.
That is, the cell format C_TY1="010b" is the format of all stream cells.
(This C_TY1="010b" allows the stream cell and the
On the other hand, if the flag TE is "00b", it indicates that the cell is in a normal state.
If the flag TE is "01b" or "10b", the cell is temporarily erased.
The flag TE="01b" indicates that the cell in question (the cell in the temporary erased state) is in the SOBU.
Starts after the first application packet that starts in the same SOBU.
The flag TE="10b" indicates that the cell (cell in the temporary erase state) is terminated before the final application packet.
At least one SOBU boundary (first application packet or last application packet)
This shows the case where the application packet starts within the SOBU. The protect flag of the program and the TE flag of the cell in the program are
Therefore, (a) any cell in a program that is in the protected state cannot be set to the temporarily erased state.
(b) A program containing one or more cells in the temporary erased state is set to the protected state.
The number of entry point information SC_EPI_Ns in a stream cell is
The number of stream cell entry point information included in the stream cell information SCI is
Each stream cell entry point information SC_EPI (for example, SC
There are two types of SC_EPI (Type A and Type B). Type A SC_EPI has an entry point type EP_TY and an entry point
and the application packet arrival time EP_APAT.
The SC_EPI of type B is indicated by the entry point type EP_TY1="00b". In addition to the EP_TY and EP_APAT of type A, the SC_EPI of type B is indicated by the entry point type EP_TY1="00b".
Type B contains primary text information PRM_TXTI.
In any stream cell, the following is used to skip a part of the recorded content:
All entry points are available in the application.
This APAT can be used to identify the destination packet arrival time.
, it is possible to specify where the data output starts. The stream object number SOB_N is the number of the SOB that the corresponding cell refers to.
Stream cell start APAT (SC_S_APAT) describes the start AP of the corresponding cell.
Stream Cell End AP AT (SC_E_APAT) describes the end AP of the corresponding cell.
The erase start APAT (ERA_S_APAT) is a description of the erase start APAT. ...
In the temporarily erased cell including the boundary (the TE field of its C_TY is "10b"),
The first application that starts in the first SOBU whose beginning is included in this temporary erase cell
The erasure end APAT (ERA_E_APAT) describes the arrival time (APAT) of an erasure packet.
In the temporarily erased cell including the boundary (the TE field of its C_TY is "10b"),
Starting in the SOBU containing the application packet immediately following the temporary erased cell
It describes the arrival time of the first application packet (APAT)
FIG. 29 shows the stream file information table (SF in FIG. 3(f) or FIG. 27).
As shown in FIG. 29, the stream file information table SFIT is a diagram illustrating the internal data structure of the stream file information table SFIT.
Stream file information table information SFITI and one or more stream object streams
It is composed of stream information SOB_STI#n and stream file information SFI.
The stream file information table information SFITI is stored in the information storage medium (DVD-
The number of stream file information SFI_Ns on the RAM disk 201 and SF
Number of stream object stream information following ITI SOB_STI_Ns
SFIT end address SFIT_EA, and SFI start address SFI_
SFIT_EA is the relative byte count (F_RBN) from the first byte of SFIT.
The SFI_SA describes the end address of the SFIT. The SFI_SA is the relative number of bytes from the first byte of the SFIT (F_RB
The stream object stream information SOB_STI contains three types of parameters:
Each parameter has a unique value for each bitstream recording.
However, this is usually not the case in most bitstream recordings.
These parameter sets can be equal. Therefore, SOB_STI is
It is stored in a table separate from the Stream Object Information (SOBI) table.
Several Stream Objects (SOBs) share the same SOB_STI.
It is allowed for multiple SOBs to point to the same SOB_STI.
Therefore, the number of SOB_STIs is usually less than the number of SOBs.
SOB_STI#1) specifies the application packet size AP_SIZE and
The number of service IDs SERV_ID_Ns and the service IDs (SERV_IDs)
, Application Packet Device Unique ID (AP_DEV_UID), and
AP_SIZE contains the number of bits transferred from the application device to the streamer.
The application packet size is the byte length of the packets in the packet stream.
In the DVD streamer, the application packet size is
In stream recording, the time is kept constant so that during each uninterrupted recording
If the application packet size changes during
The stream object (current SOB) is then terminated and a new stream object is created.
A new project (new SOB) is started with a new AP_SIZE.
Both the SOB and the new SOB are in the original PGC information (ORG_PGCI).
The SERV_ID_Ns parameter specifies the number of service IDs included in the subsequent parameters.
SERV_IDs is a list of service IDs written in any order.
AP_DEV_UID is the ID of the application that supplied the recorded bitstream.
The stream file information SFI describes a unique device ID specific to the stream device.
General information SF_GI and one or more stream object information (SOB information) sub-items
A link pointer (SOBI_SRP) #n and one or more SOB information (SOBI) #
The stream file general information SF_GI is composed of the number of SOBIs SOBI_Ns and
The number of sectors per SOBU (SOBU_SIZE) and a type of time map information.
Here, SOBU_SIZE describes the size of the SOBU in number of sectors.
The size is fixed at 32 (32 sectors = 64 kbytes).
In each time map information (MAPL), the first entry is SOB
pertaining to the application packet contained within the first 32 sectors of
Similarly, the second entry means the application contained in the next 32 sectors.
This applies to the third and subsequent entries.
Each SOB information search pointer (for example, SOBI_SRP#1) is
This SOBI_SA contains the start address SOBI_SA of the stream.
The relative byte count (F_RBN) from the first byte of the file information SFI
Each SOB information (for example, SOBI#1) is a stream object general information.
SOB_GI, time map information MAPL, and access unit data AUD
Stream object general information SOB_GI is the information of a stream object.
Type SOB_TY and Stream Object Recording Time SOB_REC_TM
the stream information number SOB_STI_N of the stream object, and
The access unit data flags AUD_FLAGS and the opening of the stream object
First application packet arrival time SOB_S_APAT and stream of
The end application packet arrival time SOB_E_APAT of the project and the
First stream object unit SOB_S_ of this stream object
SOBU and the number of entries MAPL_ENT_Ns of the time map information
The type of stream object SOB_TY indicates the temporary erased state (TE state).
In the part where you can write the bits indicating the copy generation management system and/or the bits of the copy generation management system.
The Stream Object Recording Time SOB_REC_TM is the time
The stream information number SOB_STI_N of the stream object describes the recording time of the corresponding stream object.
The index of the SOB_STI valid for the stream object is described.
The access unit data flag AUD_FLAGS is used to indicate the access unit data of the corresponding stream object.
Whether Access Unit Data (AUD) exists for the object, and if so,
If access unit data (AUD) exists, AUD_FLAGS describes what kind of access unit data it is.
The Access Unit Data (AUD) itself is a set of Access Unit Data as shown in Figure 29.
Unit general information AU_GI, access unit end map AUEM, and playback
The access unit general information AU_GI is composed of the access unit general information described for the corresponding SOB.
AU_Ns indicates the number of access units, and which SOBUs belonging to the corresponding SOB are access units.
The access unit start map AUSM indicates whether the access unit
The access unit end map AUEM is the same as the AUSM (if present).
It is a bit array of the same length as the bit array of the access unit of the corresponding SOB.
The playback timestamp list PTSL indicates which SOBU contains the end of the data stream segment.
This is a list of playback timestamps for the unit.
The SL element contains the playback timestamp (PTS) of the corresponding access unit.
An access unit (AU) is a part of a recorded bitstream.
Any single continuous portion adapted for individual playback.
For example, in an audio/video bitstream, an access unit is typically
Usually, this is the part corresponding to the I-picture of MPEG. Now, let's go back to the explanation of the contents of SOB_GI. AUD_FLAGS consists of the flag RTAU_FLG and the flag AUD_FLG.
, flag AUEM_FLG and flag PTSL_FLG. When the flag RTAU_FLG is 0b, the real-time data of the corresponding SOB
When the flag RTAU_FLG is 1b, the access unit flag is not set.
AU flags (AU_START, AU_E) described in the header extension
ND) can be present in the real-time data of the corresponding SOB.
The above state is also permitted when the flag AUD_FLG below is 0b. When the flag AUD_FLG is 0b, the access unit
When the flag AUD_FLG is 1b, it indicates that there is no access unit data (AUD) for the corresponding SOB.
When the flag AUEM_FLG is 0b, the corresponding SOB does not contain AUEM.
When the flag AUEM_FLG is 1b, it indicates that an AUEM exists in the corresponding SOB.
When the flag PTSL_FLG is 0b, the corresponding SOB does not have a PTSL.
When the flag PTSL_FLG is 1b, it indicates that a PTSL exists in the corresponding SOB.
SOB_S_APAT indicates the start application parameter of the stream object.
In other words, SOB_S_APAT describes the packet arrival time.
The arrival time of the first application packet belonging to the SOB is indicated. This Packet Arrival Time (PAT) consists of two parts: a base part and an extension part.
The basic part is called the 90kHz unit value, and the extended part is called the 90kHz unit value.
The part is a detailed value measured at 27 MHz (less significant value)
SOB_E_APAT indicates the end application parameter of the stream object.
In other words, SOB_E_APAT describes the packet arrival time.
The arrival time of the last application packet belonging to the SOB is indicated. SOB_S_SOBU indicates the first stream object of the stream object.
In other words, SOB_S_SOBU describes the object unit.
, S containing the beginning of the first application packet of the stream object
OBU is shown. MAPL_ENT_Ns is the time map information (M
The time map information MAPL corresponds to the time map information 252 in FIG.
FIG. 30 shows a case where a part of a certain program #j is partially erased (temporarily erased and permanently erased).
In this case, the cell and corresponding time information (SC_S_APAT/SC_E_A
PAT; ERA_S_APAT/ERA_E_APAT) Relationship Example (Part 1)
The streamer according to the embodiment of the present invention is a diagram for explaining the above.
There are two types of deletion: partial deletion, which completely deletes a part of the stream, and temporary deletion, which temporarily deletes a part of the stream.
As shown in FIG. 30(a), the original program (corresponding to SOB#n)
Program #j is composed of cell #k, and this cell #k is SOBU #1 to SOB
In this case, the start time of cell #k is SC_S_A
In such a program #j, the streamer user writes the following as shown in FIG.
As shown, the area (SC_S_AP) that completely includes SOBU#3 to SOBU#4
AT and ending with SC_E_APAT) as temporary erase cell #k+1
At this time, the temporary erase flag TE of cell #k+1 becomes "10b." In this case, SOBU#1 to SOBU#2 of cell #k before temporary erasure (FIG. 30(a))
The part corresponding to 2 remains unchanged as cell #k even after temporary erasure (FIG. 30(b)).
Also, SOBU #3 to SOBU #4 included in temporary erase cell (TE cell) #k+1
The part corresponding to SOBU #5 to SOBU #6 after temporary erasure (FIG. 30(b))
As shown in FIG. 30(b), temporary erase cell (TE cell) #k+1 is SOBU#
In this case, the SOBU boundary between SOBU #3 and SOBU #4 is included.
Application packet of the first application packet starting in U#3
The arrival time is indicated by ERA_S_APAT of TE cell #k+1.
In SOBU #5 containing the application packet immediately following cell #k+1
The application packet arrival time of the first application packet that starts
, ERA_E_APAT of TE cell #k+1. From program #j in FIG. 30(b), TE cell #k+1 is truly erased (completely erased).
), the original program (Fig. 30(a)) belongs to SOB#n.
The program #j is divided into SOB #n and SOB #n+1 as shown in FIG.
In this case, the SC_E_APAT of the cell #k after the complete erasure is divided into the TE cell #k+1
In addition, the ERA_S_APAT of cell #k after complete erasure can be adjusted.
+1 SC_S_APAT is matched with ERA_E_APAT of TE cell #k+1.
In this way, not only SC_S_APAT and SC_E_APAT but also ERA_
The reason for using S_APAT and ERA_E_APAT is as follows: TE cell uses two kinds of special APAT, namely SC_S_APAT/SC_
E_APAT and ERA_S_APAT/ERA_E_APAT
This is because the SOBUs in the TE cell (SOBU#3 to SOBU#4 in Figure 30(b))
In other words, if the medium (DVD-RAM disk) 201 becomes full during recording,
When this happens, the streamer erases the TE cell completely to create a new unrecorded
The SOBUs in this state (SOBU#3 to SOBU#4 in FIG. 30(b)) are acquired.
To achieve this goal of "obtaining a new unrecorded SOBU," the TE Cell
SC_S_APAT and SC_E_APAT alone are not sufficient.
In the search through the time map information (MAPL), the assigned S
This is because there are two possible search locations in the OBU.
Using S_APAT and ERA_E_APAT, it is possible to
FIG. 31 shows how a part of a program #j is partially erased (temporarily erased and permanently erased).
In this case, the cell and corresponding time information (SC_S_APAT/SC_E_A
31 is a diagram illustrating a relationship example (part 2) between the original recording program #j and the TE flag "00b
" cell #k (start time is SC_S_APAT; end time is SC_E_APAT
Here, when the temporary erased cells do not include the SOBU boundary (ERA_S_APAT
/ERA_E_APAT) is assumed. A part of this program #j (range from APAT=A to APAT=B)
), the cell #k of the original recording is temporarily erased.
E flag is "00b"; start time is SC_S_APATk; end time is SC_E
_APATk) and cell #k+1 (TE flag is "10b"; start time is SC_
S_APATk+1; end time SC_E_APATk+1) and cell #k+2
(TE flag is "00b"; start time is SC_S_APATk+2; end time is
After temporary erasure (TE), the original cells are reorganized as shown in the middle of FIG.
Thus, program #j starts again from cell #k whose TE flag is "00b" (start time
The temporary erase (TE) operation does not affect the contents of the original PGC information, but
The contents of the stream file information SFI are left unchanged, while the user-defined PGC information is not changed, or the user-defined cells are
The main operation of temporary erasure is performed in program #j.
Cell #j is divided into the normal stream part (the part that has not been erased) and the temporary erased part.
If the contents of the user-defined PGC information are left unchanged, the TE operation
Even after the reconfiguration of the navigation data, the navigation data remains exactly the same as it was before the temporary erasure.
The cell #k+1 is completely erased. Then, as shown in the lower part of FIG.
The cell #k at the time of temporary erasure remains unchanged even after complete erasure and becomes cell #k.
+2 becomes cell #k+1 after complete erasure. Figure 32 shows the cells specified by the original PGC or user-defined PGC,
How the SOBUs corresponding to these cells are related by time map information
A user-defined PGC does not contain its own SOB, but the SOBs in the original PGC are
Therefore, a user-defined PGC can be described only by using the PGC information.
This means that any playback sequence can be played without modifying the SOB data.
A user-defined PGC also does not contain a program, but is a program in the original PGC.
An example of such a user-defined PGC is shown in Figure 32.
User-defined PGC so that cells in the GC refer to SOBs in the original PGC
In Fig. 32, PGC#n has four cells #1 to #4.
Two refer to SOB#1, and the remaining two refer to SOB#2. From a cell in a user-defined PGC to the original PGC (SOBI time map)
The solid arrows in the user-defined P
The playback order of cells in a GC may be completely different from the playback order in the original PGC.
The playback of any SOB and its SOBUs begins with the start APAT (S_AP
The S_APAT of an SOB or SOBU is specified by the S_APAT of the Stream Pack of the corresponding SOB.
It is defined relative to the timestamp recorded in the payload (see Figure 8(b)).
During SOB recording, each incoming application packet contains
It is time-stamped by a local clock reference.
The APAT of the first application packet of an SOB is SOB_S_APAT.
The 4 least significant bytes of all APATs are stored as
important bytes) are the corresponding application in the ~.SRO file.
The reference number inside the streamer is fixed in advance for playback of SOB or SOBU data.
The lens clock is set to the SCR value, after which the clock starts counting automatically.
This SCR value is stored in the first stream pack where playback begins (pack header
Based on this clock, the SOB or SOBU
The playback and output of all subsequent application packets of the SOB_1 to the SOB pointed to by any Stream Cell (SC) is executed.
Stream cell opening with any value between S_APAT and SOB_E_APAT
If the start APAT (SC_S_APAT) is specified, the desired APAT is included.
An address is required to find the SOBU containing the application packet.
The number of stream packs per SOBU is fixed, but each SOBU
The interval between captured arrival times is flexible. Therefore, each SOB
Time map information (MAPL) describing the arrival time interval of the SOBU of the corresponding SOB
) In other words, the address method realized by the time map information (MAPL)
The formula converts any APAT into a relative logical block address within the file.
Point to the SOBU where the desired application packet can be found.
Figure 33 shows the contents of the SOBU that make up each stream object (SOB).
, how to store the data in the data area 207 in FIG. 3 (data areas 21 to 23 in FIG. 1)
1 is a diagram illustrating an example of how an SOB is recorded.
This section explains how to allocate the free space of the information storage medium (DVD-RAM disk) 201.
Therefore, as shown in FIG. 33, data areas are distributed over the entire medium (disk).
When such an SOB is read from the medium (disc), it is allocated in a certain data area.
While jumping from one data area to the next, data is supplied from the medium (disk).
In order to guarantee continuous supply of SOB data even in such a case,
The allocation of OB data is performed under the following conditions: SOB is a chain of continuous data areas (hereinafter abbreviated as CDA).
The CDA is basically allocated to a continuous physical sector within the medium (disk).
The minimum length of the DCA and the data allocation in the CDA are such that each SOB can be played back continuously.
The CDA is limited by the model of the player that can generate the data. The CDA is a contiguous physical sector within the medium (disc).
The CDA consists of multiple ECC blocks.
Except for cases where logical sectors are skipped during recording, SOB data is accessed continuously.
The restrictions on recording SOB data in the CDA are as follows: (21) SOB data and other data must not be recorded in the same ECC block.
(22) Even if a defective sector is encountered during recording of SOB data, replacement processing is performed.
(Linear Replacement) is not used. Here, if a cell start AP is included in a SOBU that includes multiple application packets,
A cell has a cell start APAT or cell end APAT that does not coincide with the SOBU boundary.
Now, two consecutive SOBUs, SOBU#k-1 and SOBU#k, can have T.
Let us consider a case where there is a cell start APAT in the middle of SOBU#k.
A series of packets from the application packet specified by the cell start APAT.
To start playing application packets, first select the desired application.
It is necessary to access SOBU#k containing the application packet (corresponding to the desired APAT).
It is necessary to not immediately access the target application packet.
The addressing method based on the time map information (MAPL) is only the start address of the SOBU.
This is because it is assumed that the desired APAT is not given.
Scan the session packet from the beginning (boundary between SOBU#k-1 and SOBU#k).
If the desired APAT is found by this scan,
The playback output of application packets from the point where they were received is
As described above, the effects of the embodiment of the present invention can be summarized as follows:
1. The stream data to be recorded on the information storage medium is divided into stream blocks of a predetermined size.
It is configured in lock units (or SOBU units), and in stream block units
To record and erase data, it is very difficult to determine the address of the beginning of the stream block.
This makes it easier to control access during playback (as shown in S12 of FIG. 14).
2. The stream data to be recorded on the information storage medium is divided into a predetermined size (for example, 32
It is composed of stream blocks of 64k bytes per sector, and the same stream block
Within the packet, timestamps and data packets (transport packets) are different.
Since recording can be performed across sectors, the sector size can be larger than the sector size (2048k bytes).
3. When a DVD-RAM disk is used as the information storage medium, a data packet (transport packet) of 16
Each sector is configured as an ECC block, and data is stored in the ECC block.
A terleave (rearrangement) and an error correction code are added.
Only specific sectors in the CC block can be erased, rewritten, or added.
To do this, all data in the ECC block is read once and the buffer is
After re-arrangement (de-interleaving) in the memory, the data for a specific sector is
Erase or rewrite the data, add (modify), and then re-interleave
(rearrangement) and error correction code are added and recorded (read-modify
This process takes a lot of time and requires a stream
The problem is that data recording and partial erasure cannot be performed in real time. To address this, the stream block size is set to an integer multiple of the ECC block size (for example,
For example, SOBU = 2ECC block size) and stream block unit (
For this reason, the read-modify-write
This eliminates the need for write processing and enables direct overwriting on the information storage medium in ECC block units.
As a result, the recording or partial deletion of stream data can be performed at high speed.
4. Each stream block has its own header information (stream block header)
By including a header (or application header), stream data playback
In some cases, it is possible to start playback from the beginning of a stream block.
Therefore, the stream data recording and playback device (streamer) needs to start streaming at an early stage.
By reading the block header, it is possible to easily process the regenerated stream data.
5. As mentioned above, playback basically starts from the beginning of the stream block.
However, in rare cases, the first ECC block after the second one in the stream block
In FIG. 1, the same transport packet d may start playback from two sectors (sector No.
As shown in the example where the data is recorded across sectors 0 and 1, the second and subsequent E
When playback starts from the beginning of the CC block, where is the next timestamp?
It is necessary to know what information is recorded in each sector. Each sector has its own header information (sector data header or application header) at the beginning of the sector.
application header) and a first access point 651 (
Alternatively, by recording FIRST_AP_OFFSET in FIG. 12(c),
Playback starts from the beginning of the second or subsequent ECC block in the stream block.
6. As shown in FIG. 1(j), the stream to be recorded in stream block #2 can be easily
An end code 32 is added to the end of the data.
When playing back data from the ECC block, an error in the error correction or stream data
If the end code 32 cannot be read due to a data transfer error within the data recording/playback device,
In this case, it may be mistakenly interpreted that stream data is also recorded in the padding area 38.
There is a risk that the PES header 601 (or the stream PES packet header) in FIG.
Stream ID 603 (or substream ID) is "10111110"
If sector No. 79 is set as padding packet 40,
It is mistakenly interpreted that stream data is also recorded in area 38, and data transfer
Even if the encoding unit (video encoding unit 416, audio encoding unit 417)
The padding packet 40 is recognized by the SP encoding section 417 and the SP encoding section 418.
As described above, the padding packet 40 (or the stuffing packet in FIG. 26(i))
By setting the tag packet, the end code 32 cannot be read and the padding area
This significantly reduces the risk of displaying an incorrect image even if 38 is misrecognized.
7. The area range specified by the original cell can be specified by the stream object.
The remaining area after partial erasure is equal to or smaller than the area to be erased.
By specifying a playback range within the stream object, the user can
Furthermore, any range can be set as the range for partial erasure with high precision.

[Brief explanation of the drawings]

FIG. 1 is a diagram illustrating the data structure of stream data according to an embodiment of the present invention. FIG. 2 is a diagram illustrating the directory structure of a data file according to an embodiment of the present invention. FIG. 3 is a diagram illustrating the structure of recorded data on an information medium (DVD recording/playback disc) according to an embodiment of the present invention. FIG. 4 is a diagram illustrating the relationship between stream objects (SOBs), cells, program chains (PGCs), etc. according to the present invention. FIG. 5 is a diagram illustrating the contents of stream block sizes and stream block time differences in time map information. FIG. 6 is a diagram illustrating a method for specifying cell ranges in original cells and user-defined cells. FIG. 7 is a diagram illustrating the configuration of a stream data recording/playback device (streamer) according to an embodiment of the present invention. FIG. 8 is a diagram illustrating the correspondence between digital broadcast content, IEEE 1394 video data transfer formats, and stream packs in a streamer. FIG. 9 is a diagram illustrating the relationship between MPEG video information compression methods and transport packets, and the relationship between MPEG transport packets and application packets in a streamer. FIG. 10 is a diagram illustrating the internal structure of the PES header shown in FIGS. 1, 8, 9, etc. FIG. 11 is a diagram illustrating the internal structure of the stream block header shown in FIG. 1. FIG. 12 is a diagram illustrating the internal structure of the sector data header shown in FIG. 1. FIG. 13 is a flowchart illustrating a stream data encoding procedure and a recording procedure according to an embodiment of the present invention. FIG. 14 is a flowchart illustrating a stream data decoding procedure and a playback procedure according to an embodiment of the present invention. FIG. 15 is a diagram (Example 1) illustrating a method for partially erasing stream data according to an embodiment of the present invention. FIG. 16 is a diagram (Example 2) illustrating a method for partially erasing stream data according to another embodiment of the present invention. FIG. 17 is a flowchart illustrating a procedure for partially erasing stream data according to an embodiment of the present invention. FIG. 18 is a diagram illustrating a method for setting time management information for MPEG-encoded video data (before partial erasure or temporary erasure). FIG. 19 is a diagram illustrating the relationship between time information and field information in original cell information (before partial erasure or temporary erasure) corresponding to the video data of FIG. 18. FIG. 20 is a diagram illustrating a method for setting time management information for MPEG-encoded video data (after partial erasure or temporary erasure). Fig. 21 is a diagram for explaining the relationship between time information and field information in the original cell information (after partial erasure or temporary erasure) corresponding to the video data of Fig. 20. Fig. 22 is a modified example of Fig. 15, in which all stream blocks are of a fixed size (3
23 is a diagram illustrating an example of a method for partially erasing stream data when the stream data is configured by SOBUs of 2 sectors (2 ECC blocks).
24 is a diagram illustrating an example of a method for temporarily erasing stream data when the stream data is configured by SOBUs of 2 sectors (2 ECC blocks).
25 is a diagram illustrating another example of a method for partially erasing stream data when the stream data is configured by SOBUs of 2 sectors (2 ECC blocks).
2 is a diagram illustrating another example of a method for temporarily erasing stream data when the stream data is configured in an SOBU of 2 sectors (2 ECC blocks). FIG. 26 is a diagram illustrating an example of the internal structure of a sector that configures a stream block (SOBU) (stream packs including application packets and stream packs including stuffing packets). FIG. 27 is a diagram illustrating an example of the streamer management information (STREAM.IFO or SR_
28 is a diagram for explaining the internal data structure of PGC information (ORG_PGCI/UDPGCIT in FIG. 3 or MANGR.IFO in FIG. 2).
29 is a diagram illustrating the internal data structure of the stream file information table (SFIT in FIG. 3 or FIG. 27).
FIG. 30 is a diagram illustrating the internal data structure of a program #j when a part of the program #j is partially erased (temporarily erased and permanently erased).
In this case, the cell and corresponding time information (SC_S_APAT/SC_E_A
PAT; ERA_S_APAT/ERA_E_APAT) Relationship Example (Part 1)
FIG. 31 shows a diagram illustrating a case where a part of a certain program #j is partially erased (temporarily erased and permanently erased).
In this case, the cell and corresponding time information (SC_S_APAT/SC_E_A
FIG. 32 is a diagram illustrating an example (part 2) of the relationship between a cell specified by an original PGC or a user-defined PGC and
33 is a diagram showing an example of how the contents of the SOBUs that make up each Stream Object (SOB) are recorded in data area 207 in FIG. 3 (data areas 21 to 23 in FIG. 1).

───────────────────────────────────────────────────── Continued from the front page (72) Inventor: Yuji Ito 5-22-1-302 Chuo, Ota-ku, Tokyo, Japan (72) Inventor: Shinichi Kikuchi 4-23 Yokodai, Isogo-ku, Yokohama, Kanagawa, Japan -1 Shock Villa Yoko V-202 (Note) This publication is based on the publication published internationally by the International Bureau of Patents (WIPO). The effect of the international publication of the Japanese patent application (Japanese utility model registration application) related to this publication arises pursuant to Article 184-10, Paragraph 1 of the Patent Act (Article 48-13, Paragraph 2 of the Utility Model Act) and is unrelated to this publication.

Claims (25)

[Claims] [Claim 1] A method for handling bitstream information consisting of a stream object including a first data unit, a second data unit having one or more of the first data units, and a third data unit having one or more of the second data units, comprising: an information erasure method for erasing a portion of the bitstream information included in the stream object in units of the third data units. [Claim 2] A method for handling bitstream information consisting of a stream object including a first data unit, a second data unit having one or more of the first data units, and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the bitstream information includes information of a program consisting of one or more cells and information of a program chain indicating a sequence of the program or a part of it, the program chain information is included in the streamer information, and the program chain information includes start time information of the first data unit including the content of the cell and end time information of the first data unit including the content of the cell, and an erasure range specification method in which an erasure range of a part of the bitstream information included in the stream object is specified by the start time information and the end time information. [Claim 3] A method for handling bitstream information consisting of a stream object including a first data unit, a second data unit having one or more of the first data units, and a third data unit having one or more of the second data units, comprising: a temporary erasure state setting method for setting a portion of the bitstream information included in the stream object to a temporary erasure state using the third data unit as a unit. [Claim 4] A method for handling bit stream information consisting of a stream object including a first data unit, a second data unit having one or more of the first data units, and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the bit stream information includes information of a program consisting of one or more cells and information of a program chain indicating a sequence of the program or a part of it, the program chain information is included in the streamer information, and the program chain information includes temporary erasure start time information of the first data unit including the content of the cell and temporary erasure end time information of the first data unit including the content of the cell, and a temporary erasure range specification method in which a temporary erasure range for a part of the bit stream information included in the stream object is specified by the temporary erasure start time information and the temporary erasure end time information. [Claim 5] An information management method for handling bit stream information composed of stream objects each including a first data unit, a second data unit having one or more of the first data units, and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the bit stream information includes information of a program composed of one or more cells and information of a program chain indicating a sequence of the program or a part of it, the program chain information is included in the streamer information, and the program chain information includes start time information of the first data unit including the content of the cell, temporary erasure start time information of the first data unit including the content of the cell, and temporary erasure end time information of the first data unit including the content of the cell, and a temporary erasure range for a part of the bit stream information included in the stream object is specified by the temporary erasure start time information and the temporary erasure end time information, and when the start time information coincides with the start of the first data unit starting within the third data unit, the streamer information is rewritten by adjusting the temporary erasure start time information to the start time information of a first of the first data units starting within the third data unit, which includes the first data unit with the start time information. [Claim 6] An information management method for handling bit stream information composed of stream objects each including a first data unit, a second data unit having one or more of the first data units, and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the bit stream information includes information of a program composed of one or more cells and information of a program chain indicating a sequence of the program or a part of it, the program chain information is included in the streamer information, and the program chain information includes start time information of the first data unit including the content of the cell, temporary erasure start time information of the first data unit including the content of the cell, and temporary erasure end time information of the first data unit including the content of the cell, a temporary erasure start time information and temporary erasure end time information specify a temporary erasure range for a part of the bit stream information included in the stream object, and when the cell corresponding to the part where the temporary erasure range is specified includes the beginning of the stream object, the streamer information is rewritten by matching the temporary erasure start time information to the start time information of a first of the first data units starting in the third data unit including the first data unit with the start time information. [Claim 7] An information management method for handling bit stream information composed of stream objects each including a first data unit, a second data unit having one or more of the first data units, and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the bit stream information includes information of a program composed of one or more cells, and information of a program chain indicating a sequence of the program or a part thereof, the program chain information is included in the streamer information, and the program chain information includes start time information of the first data unit including the content of the cell, temporary erasure start time information of the first data unit including the content of the cell, and temporary erasure end time information of the first data unit including the content of the cell, and a temporary erasure range for a part of the bit stream information included in the stream object is specified by the temporary erasure start time information and the temporary erasure end time information, and the streamer information is rewritten by matching the temporary erasure start time information to the start time information of a first of the first data units starting within another third data unit immediately following the third data unit including the first data unit with the start time information. 8. A method for handling bitstream information configured by a stream object including a first data unit, a second data unit having one or more of the first data units, and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the bitstream information includes information of a program configured by one or more cells and information of a program chain indicating a sequence of the program or a part thereof, the program chain information is included in the streamer information, the program chain information includes start time information of the first data unit including the content of the cell, temporary erasure start time information of the first data unit including the content of the cell, and temporary erasure end time information of the first data unit including the content of the cell, a temporary erasure start time information and temporary erasure end time information for the first data unit including the content of the cell, a temporary erasure range for a part of the bitstream information included in the stream object is specified by the temporary erasure start time information and the temporary erasure end time information,
an information management method for rewriting the streamer information by matching the temporary erasure end time information with the start time information of the first of the first data units that starts within the third data unit that includes the data unit. 9. A method for handling bitstream information configured by a stream object including a first data unit, a second data unit having one or more of the first data units, and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the streamer information includes management information of the stream object, and when a leading portion of the stream object is deleted, the third data unit located at the leading end of the stream object after the deletion is left as it is,
An information management method in which only the content of the management information relating to the deleted portion is changed in response to the deletion. 10. A first data unit and a second data unit having one or more of said first data units.
a playback sequence setting method for setting a playback sequence of a program chain including a first data unit and a third data unit having one or more of the second data units, the method comprising: setting a playback sequence of a program chain including a first data unit and a third data unit having one or more of the second data units; and setting a playback sequence of a program chain including a first data unit and a third data unit having one or more of the second data units; 11. A first data unit and a second data unit having one or more of said first data units.
A method for handling bitstream information consisting of a stream object including a data unit and a third data unit having one or more of the second data units, the method comprising: assigning a timestamp to each of one or more packet data consisting of the first data unit; dividing an array of one or more of the timestamped packet data into third data units; and inserting a header containing information about the packet data into the first second data unit within the third data unit. 12. A method for recording bitstream information encoded by the method of claim 11 onto a predetermined information medium. 13. A first data unit and a second data unit having one or more of said first data units.
A method for handling bitstream information consisting of a stream object including a data unit and a third data unit having one or more of the second data units, the method comprising: attaching a timestamp to each of one or more packet data consisting of the first data unit; dividing an array of one or more of the timestamp-attached packet data into third data units; and adding an end code and, if necessary, a padding area to the end of the data in the third data unit. 14. The method according to claim 13, further comprising: dividing the inside of the data string divided into the third data units into the second data units; and if the padding area is present at the end of the third data unit and the size of this padding area is larger than the size of the second data unit,
A method for encoding bitstream information, comprising: setting the first data unit, which is entirely filled with information having no substantial content, as the padding area; and inserting a header containing information about the packet data into the first second data unit within the third data unit. 15. A method for recording the bitstream information encoded by the method of claim 13 or 14 on a predetermined information medium. 16. A first data unit and a second data unit having one or more of said first data units.
A method for handling bitstream information configured by a stream object including a data unit and a third data unit having one or more of the second data units, the method comprising: attaching a timestamp to each of one or more packet data configured by the first data unit; and arranging an array of one or more of the time-stamped packet data into the third data unit.
a data string divided into the third data units by the second data units; a data string divided into the third data units by the second data units; a data string having the padding area at the end of the third data unit and a data string having the padding area at the end of the third data unit, the data string having the padding area at the end of the third data unit, and a data string having the padding area at the end of the third data unit and a data string having the padding area at the end of the third data unit and a data string having the padding area at the end of the third data unit and a data string having the padding area at the end of the third data unit and a data string having the padding area at the end of the third data unit and a data string having the padding area at the end of the third data unit and a data string having the padding area at the end of the third data unit and a data string having the packet data ... 17. A method for extracting a data string decoded by the method of claim 16 from an information medium on which the bit stream information encoded by the method of claim 16 is recorded, and reproducing the information content contained in this data string. 18. An information medium on which the bitstream information encoded by the method according to claim 13 or 14 is recorded. 19. A first data unit and a second data unit having one or more of said first data units.
1. A medium for recording bit stream information composed of a stream object including a data unit and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the bit stream information includes information of a program composed of one or more cells and information of a program chain indicating a sequence of the program or a part thereof, the program chain information is included in the streamer information, and the program chain information includes start time information of the first data unit including the content of the cell and end time information of the first data unit including the content of the cell, and an erasure range of a part of the bit stream information included in the stream object is specified by the start time information and the end time information. 20. A first data unit and a second data unit having one or more of said first data units.
an information medium for recording bit stream information consisting of a stream object including a data unit and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the bit stream information includes information of a program consisting of one or more cells and information of a program chain indicating a sequence of the program or a part thereof, the program chain information is included in the streamer information, and the program chain information includes temporary erasure start time information of the first data unit including the content of the cell and temporary erasure end time information of the first data unit including the content of the cell, and a temporary erasure range for a part of the bit stream information included in the stream object is specified by the temporary erasure start time information and the temporary erasure end time information. 21. A first data unit and a second data unit having one or more of said first data units.
an information medium for recording bit stream information composed of a stream object including a data unit and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the bit stream information includes information of a program composed of one or more cells, and information of a program chain indicating a sequence of the program or a part thereof, the program chain information being included in the streamer information, and the program chain information including: start time information of the first data unit including the content of the cell; temporary erasure start time information of the first data unit including the content of the cell; and temporary erasure end time information of the first data unit including the content of the cell, wherein a temporary erasure range for a part of the bit stream information included in the stream object is specified by the temporary erasure start time information and the temporary erasure end time information, and wherein, when the start time information coincides with a beginning of the first data unit starting within the third data unit, the streamer information is rewritten by aligning the temporary erasure start time information with the start time information of a first of the first data units starting within the third data unit, which includes the first data unit with the start time information. 22. A first data unit and a second data unit having one or more of said first data units.
an information medium for recording bit stream information composed of a stream object including a data unit and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the bit stream information includes information of a program composed of one or more cells, and information of a program chain indicating a sequence of the program or a part thereof, the program chain information is included in the streamer information, and the program chain information includes: start time information of the first data unit including the content of the cell, temporary erasure start time information of the first data unit including the content of the cell, and temporary erasure end time information of the first data unit including the content of the cell, a temporary erasure start time information and a temporary erasure end time information of the first data unit including the content of the cell, and a temporary erasure range for a part of the bit stream information included in the stream object is specified by the temporary erasure start time information and the temporary erasure end time information, and when the cell corresponding to the part where the temporary erasure range is specified includes the beginning of the stream object, the streamer information is rewritten by adjusting the temporary erasure start time information to the start time information of a first of the first data units starting in the third data unit including the first data unit with the start time information. 23. A first data unit and a second data unit having one or more of said first data units.
an information medium for recording bit stream information composed of a stream object including a data unit and a third data unit having one or more of the second data units, and streamer information for managing the stream information, wherein the bit stream information includes information of a program composed of one or more cells and information of a program chain indicating a sequence of the program or a part thereof, the program chain information is included in the streamer information, and the program chain information includes: start time information of the first data unit including the content of the cell, temporary erasure start time information of the first data unit including the content of the cell, and temporary erasure end time information of the first data unit including the content of the cell, and a temporary erasure range for a part of the bit stream information included in the stream object is specified by the temporary erasure start time information and the temporary erasure end time information, and the streamer information is rewritten by adjusting the temporary erasure start time information to the start time information of a first of the first data units starting within another third data unit immediately following the third data unit including the first data unit with the start time information. 24. A first data unit and a second data unit having one or more of said first data units.
a third data unit having one or more of the second data units and a third data unit having one or more of the second data units; and streamer information for managing the stream information, wherein the bitstream information includes information of a program including one or more cells and information of a program chain indicating a sequence of the program or a part thereof, the program chain information is included in the streamer information, and the program chain information includes start time information of the first data unit including the content of the cell, temporary erasure start time information of the first data unit including the content of the cell, and temporary erasure end time information of the first data unit including the content of the cell, and a temporary erasure range for a part of the bitstream information included in the stream object is specified by the temporary erasure start time information and the temporary erasure end time information, and
An information medium configured to rewrite the streamer information by matching the temporary erasure end time information with the start time information of the first of the first data units that starts within the third data unit that includes the data unit. 25. A first data unit and a second data unit having one or more of said first data units.
In a medium for recording bitstream information configured by a stream object including a data unit and a third data unit having one or more of the second data units, and streamer information for managing the stream information, the streamer information includes management information of the stream object, and when a leading portion of the stream object is deleted, the third data unit located at the leading end of the stream object after the deletion is left as it is,
An information medium configured so that only the content of the management information relating to the deleted portion is changed in response to the deletion.