Motion video signal processing for recording or reproducing – Local trick play processing – With randomly accessible medium
Reexamination Certificate
2002-01-18
2004-09-28
Boccio, Vincent (Department: 2615)
Motion video signal processing for recording or reproducing
Local trick play processing
With randomly accessible medium
C386S349000
Reexamination Certificate
active
06798973
ABSTRACT:
BACKGROUND OF THE INVENTION
This invention relates generally to the reading of a multiplexed data packet stream, and more particularly to the reading of MPEG and DVD streams.
In its earliest years, video was transmitted and recorded as analog signals. However, it has long been recognized that video can also be transmitted in digital form. The advantage of digital video includes the ability to compress the digital information, error correction, and reduced signal degradation.
One technique for transmitting digital video is to break the digital information into discreet “chunks” or “packets” of data. These packets can be multiplexed with other packets, e.g. other video data, audio data, and other multi-media type data. Therefore, multiple signals, digitally stored in packets, can be interlaced and interwoven to provide multiple channel or multimedia content.
In
FIG. 1
, two signal streams are represented. A first string
10
is a video signal stream, and a second stream
12
is an audio signal stream. In its representation, the video signal stream is represented as a number of video “frames”
14
a
,
14
b
,
14
c
,
14
d
,
14
e
,
14
f
,
14
g
, and
14
h
. When being viewed, the frames
14
a
-
14
f
are displayed or projected in rapid sequence, providing the illusion of motion.
In frame
14
a
, a horse
16
is galloping towards an object
18
. In frames
14
b, c
, and
d
the horse
16
continues to gallop and passes the object
18
. In frame
14
e
, the horse
16
is shot with a gun
20
, and in frames
14
f
-
14
h
, the horse falls to the ground, dead.
It is quite possible to store and transmit pixel information for each of the frames of
14
a
-
14
h
of the video stream
10
. However, this represents a tremendous amount of data, in that each frame can include millions of bites of information. For this reason, compression techniques such as MPEG, use a variety of techniques to minimize the amount of data that needs to be sent in order to reconstruct the frames
14
a
-
14
h
. For example, MPEG uses a technique to reduces the amount of information sent for a new frame based upon the data that has already been sent in previous frames.
The audio stream
12
is shown here in analog form. However, if it is to be sent along with the video stream
10
, it is also preferably packetized so that both the video stream
10
and the audio stream
12
can be sent along the same transmission channel. However, since the video stream
10
and the audio stream
12
must be synchronized such that, for example, when the gun
20
in frame
14
e
shoots the horse
16
the “bang”
22
of the gun is synchronized with the display of the frame
14
e
. This is referred to as temporal synchronization.
FIG. 1
therefore represents “unpacketized” video and audio streams. In
FIG. 2
, the audio and video streams have been converted into a multiplex data packet stream. More particularly, the data packet stream of
FIG. 2
is referred to as a “system stream” of data packets
26
a
,
26
b
,
26
c
and
26
d
. In this example, packets
26
a
,
26
b
, and
26
d
are video data packets, and packet
26
c
is an audio data packet. Each of the data packets includes a header portion
28
, and a payload section
30
.
Generically, system streams as illustrated in
FIG. 2
are used to embed digitized video streams and audio streams
12
of FIG.
1
. Generally, the packets
26
a
-
26
d
are of fixed size but they can also be made to have variable size.
The headers
28
store meta data, which includes such information as packet size, a time stamp, etc. The header areas
28
can also store other data or programs.
Video and audio packets are often designed so that they are large enough to accommodate more than one frame of video or audio data. Therefore, if the payload section
30
is large enough, a full frame and part of another frame can be stored within a single packet. For example, with video packet
26
a
all of frame
14
a
and a portion of frame
14
b
are stored in the payload section
30
. In the video packet
26
b
, the rest of frame
14
b
and all of frame
14
c
are stored within the payload
30
of the video packet. Likewise, a marker
32
in audio packet
26
c
indicates that all of an audio frame
34
, and a portion of the next audio frame
36
are stored within the payload section
30
.
It should be noted that it is totally arbitrary how big the payload section
30
of a particular packet should be. For example, a payload section can be anywhere from one byte to one gigabyte in length. These payload sections are generally fixed, but are sometimes made variable depending on the desires of the programmer.
It should be noted that the packet size and the frame size are totally unrelated. The packet size is based upon the expectation of the data packet stream readers. For example, data packet stream readers include buffers of a given size, which expect the packets to be of a proper size to keep them full. Therefore, the encoder which creates the packets
26
a
-
26
d
models the needs of the decoder or readers, and will change packet size for a given decoder type. However, since decoders or readers are standardized, the size of the packets created by the encoders also tend to be standardized.
In
FIG. 3
, the system stream of
FIG. 2
has been transformed into a transport stream for actual transmission. The transmission stream includes a number of very small packets
38
a
,
38
b
,
38
c
,
38
d
,
38
e
, and
38
f
. Collectively, these packets
38
a
-
38
f
form the video packet
26
a
of FIG.
2
. These packets
38
a
-
38
f
include their own headers
40
and payloads
42
. It would be noted that the payload
42
of packet
38
a
includes the header
28
of the video packet
26
a
plus a small portion of the frame
14
a
of the video packet
26
a
. Therefore, the system stream shown in
FIG. 2
is a higher level stream than the transport stream of FIG.
3
. In this example, the transport level is the lowest level stream, and is the stream that is actually transmitted.
In this example, the data packet
38
a
-
38
f
are rather small, e.g. 188 bytes in length. Since a frame can comprise many thousands of bytes of data, it takes a great many packets
38
a
-
38
f
to carry the information for a single frame of data. For the purpose of error correction, some of the data packets
38
a
-
38
f
are repeated once or twice. For example, packet
38
d
is a repeat of
38
c
, and packet
38
f
is a repeat of packet
38
e.
The above descriptions are somewhat conceptual in that they illustrate actual image frames being sent. However, as is well known to those skilled in the art, compression technology such as MPEG do not send pictures, per se, but send motion vectors which indicate changes from previous frames. However, periodically, the whole frame is sent in what is known as a I frame. Other frames may have part of a picture, but with pointers to an I frame or another frame.
The sequential transmission of a large number of the data packets
38
a
-
38
f
of
FIG. 3
comprise the transport stream
44
. Once the transport stream has been received, it must be decoded or “read” in order to recover the original data.
In
FIG. 4
, a conceptual representation of a reader takes the transport stream
44
and puts it through an input/output (I/O) process
46
to fill a “pipeline” or buffer
48
. The portion
50
of the buffer indicates the filled region, and the portion
52
of the buffer indicates that portion of the buffer that can be filled with new data from the transport stream
44
. The I/O process
46
can determine the boundary line or pointer
54
between the filled and the unfilled regions of the buffer
48
, and can determine when the buffer
48
is sufficiently low enough that additional data from the transport stream
44
should be entered into the buffer. The data within the buffer
48
moves toward the base
56
of the buffer as indicated by arrow
58
where a parcer process
60
reads a segment
62
of the buffer and reconstitutes, for example, the frame
64
.
It should be noted that the conventional reading process
Boccio Vincent
Neostar, Inc.
LandOfFree
Method and apparatus including reverse play of a multiplexed... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus including reverse play of a multiplexed..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus including reverse play of a multiplexed... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3186970