Note: Descriptions are shown in the official language in which they were submitted.
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
1
METHOD AND APPARATUS FOR ENABLING RANDOM ACCESS TO
INDIVIDUAL PICTURES IN AN ENCRYPTED VIDEO STREAM
BACKGROUND OF THE INVENTION
The present invention relates to an encrypted
paclcetized data processing system. The invention is
particularly suited for use in a video-on-demand (VOD)
system wherein motion control ("trick modes"), such as
fast forward and fast reverse modes, are required.
Video-on-demand (VOD) is an interactive video
service typically provided over a point-to-multipoint
distribution system, such as a cable television system.
With VOD, a subscriber can order video (such as a movie,
sport event or the lilce) or other types of content at
any time, without adhering to a pre-defined showing
schedule. A full-function VOD system provides the
subscriber with Video Cassette Recorder (VCR)-like
motion control functions, such as pause (freeze frame),
fast forward, fast reverse, and slow reverse. These
functions, variously known as tricl~ play, trick mode, or
motion control, enhance the subscriber's viewing
experience and mimic (or exceed) the level of control
subscribers expect from conventional video tapes, such
as those which can be commonly purchased or rented.
In a VOD system, content is stored in video
servers, which are specialized high-capacity file
servers. The content is played from stored files upon
purchase by a subscriber. To facilitate remultiplexing
and error correction, digital video content is typically
packetized into fixed-size units. Such is that case in
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
2
the popular MPEG-2 standard (ITU-T Rec. H.222.0
ISO/IEC 13818) used in digital television.
To perform motion control, a video server
controller responds to motion control commands from set-
s top boxes and Changes the way content is played back.
In fast forward and fast reverse, the video server will
skip selected pictures to create a sped-up version of
the video. Depending on the method employed, it may be
necessary to have fast, random access to the individual
pictures in a video file. To reduce storage
requirements and to allow flexible control of the speed-
up factor, pictures in fast forward and fast reverse
sequences are often extracted in real time from the
normal video file, which contains all pictures in the
movie or other program.
There are two ways to search for pictures to be
displayed in a scan forward/backward sequence. The
first is to scan the main video file sequentially
looking for starts of pictures. The other method is to
build an auxiliary index file to the start points of
pictures in the main video file.
However, another concern is controlling access to
the VOD programming, e.g., to maintain the financial
viability of the system. Specifically, a conditional
access scheme is implemented to deny access to services
or content by unauthorized parties. Conditional access
requires a trustworthy mechanism for classifying users
into different groups, and an enforcement mechanism for
denying access to groups of unauthorized users.
Encryption is often used to control access to the
content carried by carrier signals. The conventional
approach to encrypting content for VOD distribution is
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
3
to have real-time encrypting devices on the delivery
path between the video server and the subscribers. This
approach works well when the number of subscribers is
relatively small. However, as the number of subscribers
increases, the number of encrypting devices and their
physical space requirements become burdensome. This
space problem does not exist with traditional broadcast
type services because the same content stream is shared
by all subscribers and the number of encrypting devices
does not increase with the number of subscribers.
An alternative to real-time encryption of VOD
content is off-line, pre-encryption. In this approach,
video content is processed and encrypted before it is
loaded into video servers. The advantage of pre-
encryption is that it removes the need for encrypting
devices on the video delivery path, thus making VOD
service substantially less expensive and more~scalable.
The pre-encryption can be done centrally at a content
preparation site, which is separate from the locations
(headends) at which the VOD service is deployed. Once
video is pre-encrypted at the central site, the same
encrypted copies can be distributed to multiple headends
where VOD is deployed.
However, pre-encrypting VOD content creates a
problem: it interferes with the detection of the
location of the starting point of individual pictures in
a video file. In general, video servers do not have the
capability or authorization to decrypt pre-encrypted
video content. As a result, they cannot locate
individual pictures in an encrypted video file just by
scanning the file. A similar problem is confronted when
the encrypted content is stored at a decoder prior to
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
4
display, where it is time consuming and computationally
intensive to have to decrypt all of the pictures to
locate specific pictures.
Accordingly, it would be desirable to provide a
system that addresses the above problems.
The system should enable random access to
individual pictures in an encrypted video file for use
in modes such as fast forward, fast reverse, pause,
resume, slow motion (forward or reverse), frame-by-frame
or other incremental frame advance or scan (e. g.,
advancing N frames at a time, where N>1), and the like.
The system should allow a secure video-on-demand
system to be deployed at a reduced cost.
The system should be compatible with packeti~ed
data communication schemes, such as MPG-2.
The invention should be compatible with a user
device that stores an encrypted video file, such as a
personal video recorder (PVR), personal computer hard
disk or the like.
The present invention provides a system having the
above and other advantages.
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
SUNl~2ARY OF THE INVENTION
The present invention relates to an encrypted
packetized data processing system.
In accordance with one aspect of the invention, a
5 particular method for providing at least partially
encrypted packetized data includes the step of receiving
input digital data from a data source, such as a video
server. The input digital data includes a plurality of
encoded data segments with respective data headers, such
as found in an MPEG-compatible Packetized Elementary
Stream (PES) packet. The input digital data is
subdivided for transport in successive transport packets
such that at least two types of transport packets are
provided, including a first type that includes at least
a portion of an associated data header, and a second
type that includes at least a portion of an associated
encoded data segment but does not include any portion of
the data headers.
The second type of transport packets are encrypted,
while leaving the first type of transport packets
unencrypted. Identifiers are provided for the
respective transport packets to indicate whether the
respective transport paclcet is encrypted or unencrypted.
This allows the transport packets with the header
data to be randomly accessed from a memory, which is
particularly advantageous for performing "trick modes",
such as fast forward and fast reverse, e.g., in a video-
on-demand service. If a packet includes header data, it
is suitable for use in a trick mode since it provides
data from the start of a video, audio or other data
packet.
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
6
In a further aspect of the invention, a method for
decoding at least partially encrypted paclcetized data
includes the step of receiving successive transport
packets from a transport stream. The transport packets
are formed by subdividing digital data that includes a
plurality of encoded data segments with respective data
headers into a first, encrypted type that includes at
least a portion of an associated data header, and a
second, unencrypted type that includes at least a
portion of an associated encoded data segment but does
not include any portion of the data headers.
Identifiers are provided for the respective transport
packets to indicate whether the respective transport
packet is encrypted or unencrypted.
The transport packets are stored in a-storage
device, and the identifiers are used to randomly access
the first type of transport pacltets from the storage
device without performing decryption. For example, a
personal video recorder or other user device that stores
the partially encrypted transport packets may be used.
The packets are subsequently decrypted when the user
desires to view the data.
Corresponding apparatuses are also presented.
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
7
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates the formation of transport
packets in accordance with~the present invention.
FIG. 2 illustrates an encoder in accordance with
the present invention.
FIG. 3 illustrates a user device/decoder in
accordance with the present invention.
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
8
DETATLED DESCRTPTTON OF THE INVENTION
The present invention relates to an encrypted
packetized data processing system.
FIG. 1 illustrates the formation of transport
packets in accordance with the present invention.
To facilitate discussion, an implementation of the
invention in a typical packetized digital video format,
such as MPEG-2, is discussed. However, the present
invention is applicable to other digital formats sharing
similar features.
In the MPEG-2 format, video information is
digitized and compressed before being encoded. The
compression can be considered part of the encoding.
Compressed video from a program 100 is divided into
variable-length units called Packetized Elementary
Stream (PES) packets, such as PES packets 105 and 110,
each of which contains a variable number of encoded
pictures. For example, the PES packet 105 includes
encoded pictures 119, 121, . . . , 124.
The example PES packet 105 has a header 116 and a
payload portion 117. Moreover, each picture in the PES
packet 105 is prefixed by a header containing
information about the picture. For example, the picture
119 has a header 118, the picture 121 has a header 120,
and the picture 124 has a header 123.
For transmission and storage purposes, PES packets
are further broken down into fixed-length units called
transport packets, such as transport packets 130, 140
and 150. With the MPEG-2 standard, each transport
packets comprises 188 bytes. Generally, the PES packet
length is much larger than the size of a transport
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
9
stream packet. Each transport paclcet has a header and a
payload portion. The header of a transport packet
contains, among other information, two transport
scrambling control bits, which indicates the encryption
( scrambling) status of the paclcet .
In the MPEG-2 standard, the scrambling control bits
are designated by the field
"transport-scrambling-control". A scrambling control
value of "00" indicate the transport packet is not
scrambled, while the values "01", "10", and "11" can be
user-defined. The value "11" is used herein as an
example to designate a scrambled or encrypted transport
packet. Any type of analogous scheme may be used to
indicate the encryption status of a transport packet.
The transport packet 130 includes a header 131,
scrambling control bits 132 (which indicate an
unencrypted transport packet), and a payload 133. The
transport packet 140 includes a header 141, scrambling
control bits 142 (which indicate an encrypted transport
packet), and a payload 143. The transport packet 150
includes a header 151, scrambling control bits 152
(which indicate an unencrypted transport packet), and a
payload 153.
Each transport packet is formed by subdividing the
contents of successive portions of a PES packet. For
example, the payload 133 of the transport packet 130
comprises the PES header 116, picture header 118, and a
portion of the picture data 119 of the PES payload 117.
The payload 143 of the transport packet 140 comprises a
successive portion of the picture data 119 of the PES
payload 117. The payload 153 of the transport packet
150 comprises the picture header 120, and a portion of
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
the picture data 121 of the PES payload 117, and so on.
Note that FIG. 1 is shown in simplified form since,
in practice, the data from one picture is usually
carried in the payloads of several transport packets.
5 Moreover, the amount of picture data (e. g., fields 119,
121, 124) is often much larger than the amount of the
corresponding picture header data (e. g., fields 118,
120, 123, respectively). As a result, the majority of
the transport packets will carry only picture data but
10 no picture header data, thereby resulting in most
transport packets being encrypted, with relatively few
transport packets being unencrypted. Thus, an
unauthorized user who tunes to the mostly-encrypted
program will not be able to watch the program with
appreciable understanding.
The transport packets are assembled into a
transport stream and transmitted to a user terminal
(e.g., set-top box) typically via a satellite, cable or
hybrid fiber/cable network, although communication via
essentially any network, such as a computer network is
also possible. If prepared at a central content
preparation site, the transport stream may be provided
to one or more headends before being provided to the
user terminal.
Generally, the data can be prepared at a central
preparation site, such as by a national supplier, at a
headend, or each content vendor can arrange for its own
content preparation, e.g., according to any special
needs of its equipment.
As is known, a transport stream is a multiplex
formed by interleaving transport packets belonging to
one or more programs. Transport packets belonging to
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
11
different programs in a transport stream are
differentiated by a Packet Identifier (PID) in their
headers. A single Program Transport Stream includes of
transport packets of one program only.
FIG. 2 illustrates an encoder in accordance with
the present invention. The encoder 200 comprises
equipment for performing selective packet encryption.
The depicted equipment may be located at a central
content preparation site or at a headend, for example.
The present invention overcomes the problem of
locating picture start points caused by the use of pre-
encryption. This is achieved, as discussed, by leaving
selected (transport stream) packets unencrypted in a
video file. The equipment set-up 200 to achieve this
includes one or more digital video sources 210, a pre-
processing workstation 215 for generating auxiliary data
files and for labeling selected packets for encryption,
an encryption device 220, an encryption device
controller 205, an optional post-processing workstation
225 for processing encrypted video (e. g., to adjust
timing information that may be perturbed by the
encryption process), and a storage device 230 for
storing the processed data prior to providing it to a
headend or end user.
In the encoder set-up 200, the digital video source
210 supplies the digital video stream to be encrypted.
The video source may be a digital video encoder, or a
file server playing back pre-encoded video files. The
digital video stream is fed into the pre-processing
workstation 215, whose main function is to identify and
label transport packets for encryption. A packet is
selected for encryption if it contains no picture header
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
12
or portion thereof, and therefore need not be examined
by the video server during motion control (trick modes).
Transport packets selected for encryption are labeled by
having the transport scrambling control bits set to some
special value (e.g., "11").
Packets to be left unencrypted are similarly
labeled, using a different special value (e.g. "00").
The pre-processing step may optionally generate
auxiliary data files used in the delivery of VOD
services.
Encryption of the pre-processed video stream is
performed by the encryption device 220 under the control
of the device controller 205, which is, in turn,
responsive to encryption control parameters. Any
suitable encryption scheme may be used. The encryption
control parameters may include, e.g., information
related to the program being encrypted, or the
particular encryption session, or both. When encryption
is performed, the encryption device 220 examines the
transport scrambling control bits of each transport
packet. Packets with those two bits set to, e.g., "00"
are left unencrypted, while packets with the bits set
to, e.g., "11" are encrypted.
The output of the encryption device 220, which
comprises a selectively-encrypted video stream, is
optionally put through a post-processing stage (e. g.,
workstation 225) before being stored in the storage
device 230. Post-processing may or may not be needed
depending on the design and implementation of the VOD
service equipment.
To search for the starting point of pictures in a
pre-encrypted video file during trick mode play, a video
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
13
server scans the transport paclcets in a video file
sequentially. The transport scrambling control bits in
each transport packet headers indicate whether the
packet is encrypted. If a packet is encrypted, it can
be inferred that it contains no picture header. If a
packet is unencrypted, the payload can be examined to
locate the picture header.
A video server can still read other kinds of
information embedded in a pre-encrypted video file, such
as private data in an adaptation field of a transport
packet header.
FIG. 3 illustrates a user device/decoder in
accordance with the present invention.
Optionally, the program content can be temporarily
stored at a user device/decoder prior to playing. The
device may be a personal video recorder or other
terminal or appliance in a user's home, or even a
portable unit carried by the user or used in an
automobile.
For example, rather than playing at a specified
time under the control of a headend, a storage device
containing the programming may be purchased or rented
for subsequent re-play by the user. Under a purchase,
scenario, the user may enjoy unlimited replays, while
under a rental scenario, a fixed number of replays or an
expiration date may be enforced.
Or, the user may be given the option of storing the
transport stream prior to playing.
Thus, the user device/decoder 300 can be provided
with the capability for providing motion control (e. g.,
trick modes).
The decoder 300 may include a demultiplexer (demux)
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
14
302 that receives a transport stream with the encrypted
and unencrypted transport packets, such as those
previously stored at the storage device 230 in FIG. 2,
and optionally other programming services. Other
necessary components, e.g., for demodulation, error
correction, synchronization and the like are not shown,
but should be apparent to those skilled in the art.
The demux 302 extracts the encrypted and
unencrypted packets that belong to a particular program.
The extracted stream of packets either is stored in the
memory 310, or is provided to a second demux 305, which
separates the encrypted transport packets from the
unencrypted transport packets. For example, an entire
movie or the like may be stored in the memory 310 for
subsequent retrieval and motion control. The memory 310
is analogous to the storage device 230 of FIG. 2.
The demux 305 includes a scrambling control bit
identifier/detector 306 that identifies the scrambling
control bits of each transport packet to determine if
the packet is encrypted or unencrypted.
A control 335, such as a central processing unit
(CPU), provide oversight of the various functions in the
decoder 300.
A user interface 340 receives commands from a user,
e.g., via a hand-held remote control, to view the
content in a regular play mode or in a trick mode. In
response to this request, the interface 340 provides a
corresponding signal to the control 335, which commands
the memory 310 to output the packets to the demux 305.
A video/audio/data processing function 320 receives
unencrypted packets from the decryptor 315 and demux
305.
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
The data from the function 320 is provided to an
output device 325, such as a television, personal
computer, speakers, and so forth. The output device 325
may provide a graphical user interface (GUI) or other
5 mechanism to assist the user in playing the programming
content in a normal or trick mode. The user may also
place an order for the content via such an interface.
An optional upstream transmitter 330 transmits a
user request, such ~as an order for VOD programming, to a
10 headend or other networlc control facility. The user
request may travel over the same or different channel
from which the transport stream was received.
It should now be appreciated that the present
invention provides a system for providing conditional
15 access to packetized picture, audio or other data. The
system selectively encrypts packetized data such that
transport packets that include header data are
unencrypted, while all other transport packets that do
not include header data are encrypted. This allows the
transport packets with the header data to be randomly
accessed from a memory, which is particularly
advantageous for performing triclt modes, such as fast
forward and fast reverse, e.g., in a video on demand
service.
In particular, after the transport packets are
selectively encrypted and stored, transport scrambling
and control bits for each packet can be accessed to
determine whether the packet is encrypted, and
consequently, whether the packet includes header data.
If a packet includes header data, it is suitable for use
in a trick mode since it provides data from the start of
a video, audio or other data packet.
CA 02408232 2002-11-O1
WO 02/15579 PCT/US00/11891
16
Although the invention has been described in
connection with various specific embodiments, those
skilled in the art will appreciate that numerous
adaptations and modifications may be made thereto
without departing from the spirit and scope of the
invention as set forth in the claims.
For example, the selectively encrypted transport
packets need not be transmitted to a subscriber
terminal, but may be provided in a storage device for
subsequent retrieval by a user, such as in a personal
video recorder (PVR).
