WO2007072242A1

WO2007072242A1 - A device for and a method of processing an encrypted data stream

Info

Publication number: WO2007072242A1
Application number: PCT/IB2006/054410
Authority: WO
Inventors: Albert M. A. Rijckaert; Jozef P. Van Gassel; Eric W. J. Moors; Roland P. J. M. Manders
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-12-23
Filing date: 2006-11-23
Publication date: 2007-06-28

Abstract

A device (3100) and method is disclosed for processing an encrypted data stream (3107). Further, a program element and a computer-readable medium are disclosed enabling the disclosed method. The device comprises a detection unit (3101) for detecting decryption messages in the encrypted data stream, a selection unit (3102) is provided for selectively identifying decryption messages that correspond to portions of the encrypted data stream that have been repeated subsequent to the creation of the encrypted data stream and a deletion unit (3103) is provided for deleting one or more of the decryption messages identified as corresponding to repeated portions of the encrypted data stream. The embodiments process an encrypted data stream comprising repeated portions into a processed encrypted data stream with a rate of change of decrypting messages substantially equivalent to that of the encrypted data stream in its original from.

Description

A device for and a method of processing an encrypted data stream

FIELD OF THE INVENTION

The invention relates to a device for processing an encrypted data stream. The invention further relates to a method of processing an encrypted data stream. The invention further relates to a program element.

The invention further relates to a computer-readable medium.

BACKGROUND OF THE INVENTION

Electronic entertainment devices become more and more important. Particularly, an increasing number of users buy hard disk based audio/video players and other entertainment equipment.

Since the reduction of storage space is an important issue in the field of audio/video players, audio and video data are often stored in a compressed manner, and for security reasons in an encrypted manner. MPEG2 is a standard for the generic coding of moving pictures and associated audio and creates a video stream out of frame data that can be arranged in a specified order called the GOP ("Group Of Pictures") structure. An MPEG2 video bit stream is made up of a series of data frames encoding pictures. The three ways of encoding a picture are intra-coded (I picture), forward predictive (P picture) and bi-directional predictive (B picture). An intra- coded frame (I-frame) is related to a particular picture and contains the corresponding data. A forward predictive frame (P-frame) needs information of a preceding I-frame or P-frame. A bi-directional predictive frame (B-frame) is dependent on information of a preceding or subsequent I-frame or P-frame.

It is an interesting function in a media playback device to switch from a normal reproduction mode, in which media content is played back in a normal speed, to a trick-play reproduction mode, in which media content is played back in a modified manner, for instance with a reduced speed ("slow forward"), a still picture, or vice versa.

US 2003/0053540 Al discloses slow motion trick-play with a slowdown factor of n on an MPEG data stream, wherein for each original I frame or P frame n-1 backward predicted freeze frames are inserted and for each original B frame n-1 copies of the original B frames are added.

Furthermore different media content providers may use different formats for encrypted video content and for decryption data needed for decrypting the encrypted video content. Thus, the coordination of providing segments of encrypted video content and providing and decrypting encrypted decryption data may be difficult, particularly in a trick- play mode such as slow- forward. For example, when the MPEG data stream is in an encrypted form the repetition of copies of the original B frames, as taught by US 2003/0053540 Al, also requires the repetition of the information required to decrypt successive segments of the stream since the formats used by different media content providers are proprietary and secret in nature. The repetition of this information can then interfere with the correct operation of the decryption of the encrypted video content. This is because although decryption messages are repeated in an encrypted data stream in its original form for data redundancy purposes, the rate at which different decryption messages are repeated is limited to reduce the processing load on the decryption system and in particular on the smart card typically used in such a system. Therefore there is a need to process an encrypted data stream such that the effects of the repeated information introduced for certain trick-play modes are corrected for.

BRIEF SUMMARY OF THE INVENTION

It is an object of the invention to properly adjust the provision of an encrypted data stream to correct for the effects of repeated information introduced in the encrypted data stream.

In order to achieve the object defined above, with a device according to the invention, characteristic features are provided so that a device according to the invention can be characterized in the way defined below, that is:

A device for processing an encrypted data stream, wherein decryption messages are provided for decrypting at least one segment of the encrypted data stream, wherein the device comprises: a detection unit for detecting the decryption messages in the encrypted data stream; a selection unit for selectively identifying for deletion at least one of the decryption messages detected by the detection unit; and a deletion unit for deleting the at least one of the decryption messages selectively identified by the selection unit, wherein the selection unit is arranged to select the at least one of the decryption messages to be deleted based upon an identification that the at least one of the decryption messages has been subsequently repeated in the encrypted data stream after creation of the encrypted data stream in its original form.

A method according to the invention can be characterized in the way defined below, that is:

A method of processing an encrypted data stream, wherein decryption messages are provided for decrypting at least one segment of the encrypted data stream, the method comprising the method steps of: detecting the decryption messages in the encrypted data stream; selectively identifying for deletion at least one of the decryption messages detected during the method step of detecting the decryption messages; and deleting the at least one of the decryption messages selectively identified during the method step of selectively identifying, wherein the method step of selectively identifying selects the at least one of the decryption messages to be deleted based upon an identification that the at least one of the decryption messages has been subsequently repeated in the encrypted data stream after creation of the encrypted data stream in its original form. A program element according to the invention can be characterized in the way defined below, that is:

A program element directly loadable into the memory of a programmable device, comprising software code portions for performing, when said program element is run on the device, the method steps of: detecting the decryption messages in the encrypted data stream; selectively identifying for deletion at least one of the decryption messages detected during the method step of detecting the decryption messages; and deleting the at least one of the decryption messages selectively identified during the method step of selectively identifying, wherein the method step of selectively identifying selects the at least one of the decryption messages to be deleted based upon an identification that the at least one of the decryption messages has been subsequently repeated in the encrypted data stream after creation of the encrypted data stream in its original form. A computer-readable medium according to the invention can be characterized in the way defined below, that is:

A computer-readable medium directly loadable into the memory of a programmable device, comprising software code portions for performing, when said program element is run on the device, the method steps of: detecting the decryption messages in the encrypted data stream; selectively identifying for deletion at least one of the decryption messages detected during the method step of detecting the decryption messages; and deleting the at least one of the decryption messages selectively identified during the method step of selectively identifying, wherein the method step of selectively identifying selects the at least one of the decryption messages to be deleted based upon an identification that the at least one of the decryption messages has been subsequently repeated in the encrypted data stream after creation of the encrypted data stream in its original form. The measures according to the invention provide the advantage that an encrypted data stream that has been subsequently processed from its original form to include repeated portions can be further processed to remove only the repeated portions of the decryption information necessary to produce an encrypted data stream that does not conflict with the correct decryption of the processed encrypted data stream as a whole. Particularly, by detecting decryption messages comprised within the encrypted data stream and further deleting selectively one or more decryption messages that have been identified as being repeated in the encrypted data stream subsequent to the original creation of the encrypted data stream then an encrypted data stream can be provided which will operate in an equivalent manner to the original encrypted data stream even withstanding the occurrence of repeated parts within the encrypted data stream.

The measures as claimed in claim 2 and claim 16 provide an encrypted data stream that contains only a single decryption message comprised within a repeated section of data within the encrypted data stream. Therefore the encrypted data stream output by the device contains almost the same number of decryption messages as the encrypted data stream in its original form and reduces the processing load on a decryption message decrypter that must process the encrypted data stream since the number of decryption messages to be processed is reduced to the same level as that of the encrypted data stream in its original form. The measures as claimed in claim 3 provide an encrypted data stream that allows faster channel changing since as many original ECMs are included in the encrypted data stream as possible.

Furthermore, the measures defined in claim 4 and claim 17 enable the selective identification of repeated decrypted messages to be performed in a simple manner.

Preferably, the measures of claim 5 enable the device according to the invention to operate in co-operation with a further device for processing an encrypted data stream wherein the further device generates the repeated portions in the encrypted data stream and communicates the repeated portions to the device according to the invention. This allows the device according to the invention to be implemented in a simple manner.

Advantageously, the measures of claim 6 enable the device according to the invention to identify repeated portions in the encrypted data stream independently from any other device without reliance on any external information other than the encrypted data stream itself. Favorably, the measures of claim 7 enable the device according to the invention to identify repeated portions in the encrypted data stream using the statistics of the decryption messages in the encrypted data stream. The analysis of the characteristics of the decryption messages enable a simple identification of repeated portions of the encrypted data stream by noting anomalies in the analyzed characteristics. Preferably, the measures of claim 8 enable the analysis of anomalies to be based on the timing characteristics of the decryption messages providing a simple manner to detect and identify repeated portions in the encrypted data stream since the rate at which decryption messages appear in the encrypted data stream will not in general be higher than that of in an encrypted data stream in its original form. Favorably, the measures of claim 9 enable the device according to the invention to identify in a simple manner repeated portions in the encrypted data stream.

Beneficially, the measures of claim 10 allow an encrypted data stream to be produced in accordance with an object of the invention in a situation where the location of the decryption message in the encrypted data stream and the location of the encrypted video data requiring the decryption message are both contained within a single portion of the encrypted data stream that is repeated. Such a situation can occur in a conditional access system making use of decryption messages comprising a single control word.

Preferably, the measures of claim 11 allow an encrypted data stream to be produced in accordance with an object of the invention for conditional access systems making use of decryption messages comprising one or more control words and provide an embodiment that is therefore widely applicable.

Favorably, the measures of claim 12 allow an encrypted data stream to be processed that is a video, an audio or a data stream. Allowing each of these streams to comprise repeated portions and yet still contain a set of decryption messages allowing correct decryption of each stream.

Preferably, the measures of claim 13 allow an encrypted data stream to be processed that is an MPEG2 data stream. MPEG2 is a designation for a group of audio and video coding standards agreed upon by MPEG (Moving Pictures Experts Group), and published as the ISO/IEC 13818 International Standard. For example, MPEG2 is used to encode audio and video for broadcast signals including digital satellite and cable TV, but may also be used for DVD. This therefore enables consumers to enjoy high quality entertainment.

Advantageously, the measures according to claim 14 provide a device according to the invention that may be realized as one of the group consisting of a digital video recording device, a network-enabled device, a conditional access system, a portable audio player, a portable video player, a mobile phone, a DVD player, a CD player, a hard disk based media player, an Internet radio device, a computer, a television, a public entertainment device and an MP3 player. However, these applications are only exemplary. The aspects defined above and further aspects of the invention are apparent from the examples of embodiment to be described hereinafter and are explained with reference to these examples of embodiment.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will be described in more detail hereinafter with reference to examples of embodiment but to which the invention is not limited.

Fig. 1 illustrates a time-stamped transport stream packet.

Fig. 2 shows an MPEG2 group of picture structure with intra-coded frames and forward predictive frames. Fig. 3 illustrates an MPE G2 group of picture structure with intra-coded frames, forward predictive frames and bi-directional predictive frames.

Fig. 4 illustrates a structure of a characteristic point information file and stored stream content.

Fig. 5 illustrates a system for trick-play on a plaintext stream. Fig. 6 illustrates time compression in trick-play.

Fig. 7 illustrates trick-play with fractional distance.

Fig. 8 illustrates low speed trick-play.

Fig. 9 illustrates a general conditional access system structure. Fig. 10 illustrates a digital video broadcasting encrypted transport stream packet.

Fig. 11 illustrates a transport stream packet header of the digital video broadcasting encrypted transport stream packet of Fig. 10.

Fig. 12 illustrates a system allowing the performance of trick-play on a fully encrypted stream.

Fig. 13 illustrates a full transport stream and a partial transport stream.

Fig. 14 illustrates Entitlement Control Messages for a stream type I and for a stream type II.

Fig. 15 illustrates writing Control Words to a decrypter. Fig. 16 illustrates Entitlement Control Message handling in a fast forward mode.

Fig. 17 illustrates detection of one or two Control Words.

Fig. 18 illustrates the splitting of a transport stream packet at a frame boundary. Fig. 19 illustrates a system allowing the performance of slow- forward trick- play on a fully encrypted stream.

Fig. 20 illustrates a hybrid stream with plaintext packets on each frame boundary.

Fig. 21 illustrates a system allowing the performance of slow- forward trick- play on a stored hybrid encrypted stream.

Fig. 22 illustrates an incomplete picture start code at the concatenation point of repeated B-frame data.

Fig. 23 illustrates the effect of MPEG frame re-ordering from transmission order to display order. Fig. 24 illustrates the effect of MPEG frame re-ordering during slow- forward from transmission order through the intermediate display frame order to the actual displayed frames.

Fig. 25 illustrates the effect of MPEG frame re-ordering during slow- forward making use of empty P-frames before the anchor frames. Fig. 26 illustrates the effect of MPEG frame re-ordering during slow- forward making use of backward predictive empty B-frames.

Fig. 27 illustrates the effect of MPEG frame re-ordering during slow- forward making use of forward predictive empty B-frames. Fig. 28 illustrates the high table ID toggle rate due to repetition of B-frame data.

Fig. 29 illustrates the loss of a necessary Control Word for a type I system due to B-frame data repetition.

Fig. 30a illustrates the handling of ECMs for the slow- forward stream. Fig. 30b illustrates the handling of ECMs for the slow- forward stream suitable for fast channel changing.

Fig. 31 illustrates a system for removing ECMs corresponding to the repeated B-frame data according to an exemplary embodiment of the invention.

Fig. 32 illustrates a system for removing ECMs corresponding to the repeated B-frame data making use of a repetition detection unit according to an exemplary embodiment of the invention.

Fig. 33 illustrates a system for removing ECMs corresponding to the repeated B-frame data making use of an analyzer unit according to an exemplary embodiment of the invention. Fig. 34 illustrates the loss of a necessary Control Word for a type II system due to B-frame data repetition and the removal of ECMs corresponding to all but the last repetition of the repeated B-frame data.

Fig. 35 illustrates the handling of ECMs for the slow- forward stream to prevent the loss of a necessary Control Word for a type II system due to B-frame data repetition.

Fig. 36 illustrates the results of a measurement of B-frame data length over time for a typical broadcast reception.

Fig. 37 illustrates the overlap of repeated B-frame data when the length of the B-frame data in time exceeds a single frame display time. Fig. 38 illustrates a trick-play generator and a receiver according to an exemplary embodiment of the invention.

Fig. 39 illustrates a common decrypter for trick-play generator and receiver.

Fig. 40 illustrates a device for processing an encrypted data stream according to an exemplary embodiment of the invention. Fig. 41 illustrates another device for processing an encrypted data stream according to another exemplary embodiment of the invention. Fig. 42 shows an example of an ECM file.

The Figures are schematically drawn and not true to scale, and the identical reference numerals in different Figures refer to corresponding elements. It will be clear for those skilled in the art, that alternative but equivalent embodiments of the invention are possible without deviating from the true inventive concept, and that the scope of the invention will be limited by the claims only.

DETAILED DESCRIPTION OF THE INVENTION

In the following, referring to Fig. 1 to Fig. 13, different aspects of trick-play implementation for transport streams according to exemplary embodiments of the invention will be described.

Particularly, several possibilities to perform trick-play on an MPEG2 encoded stream will be described, which may be partly or totally encrypted, or non-encrypted. The following description will target methods specific to the MPEG2 transport stream format. However, the invention is not restricted to this format.

Experiments were actually done with an extension, the so-called time-stamped transport stream. This comprises transport stream packets, all of which are pre-pended with a 4 bytes header in which the transport stream packet arrival time is placed. This time may be derived from the value of the program clock reference (PCR) time-base at the time the first byte of the packet is received at the recording device. This is a proper method to store the timing information with the stream, so that playback of the stream becomes a relatively easy process. One problem during playback is to ensure that the MPEG2 decoder buffer will not overrun nor underflow. If the input stream was compliant to the decoder buffer model, restoring the relative timing ensures that the output stream is also compliant. Some of the trick-play methods described herein are independent of the time stamp and perform equally well on transport streams with and without time stamps. Fig. 1 illustrates a time stamped transport stream packet 100 having a total length 104 of 188 Bytes and comprising a time stamp 101 having a length 105 of 4 Bytes, a packet header 102, and a packet payload 103 having a length of 184 Bytes.

This following description will give an overview of the possibilities to create an MPEG/DVB (digital video broadcasting) compliant trick-play stream from a recorded transport stream and intends to cover the full spectrum of recorded streams from those that are completely plaintext, so every bit of data can be manipulated, to streams that are completely encrypted (for instance according to the DVB scheme), so that only headers and some tables may be accessible for manipulation. When creating trick-play for an MPEG/DVB transport stream, problems may arise when the content is at least partially encrypted. It may not be possible to descend to the elementary stream level, which is the usual approach, or even access any packetized elementary stream (PES) headers before decryption. This also means that finding picture frames is not possible. Known trick-play engines need to be able to access and process this information.

In the frame of this description, the term "ECM" denotes an Entitlement Control Message. This message may particularly comprise secret provider proprietary information and may, among others, contain encrypted Control Words (CW) needed to decrypt the MPEG stream. Typically, Control Words expire in 10-20 seconds. The ECMs are embedded in packets in the transport stream.

In the frame of this description, the term "keys" particularly denotes data that may be stored in a smart card and may be transferred to the smart card using EMMs, that is so-called "Entitlement Management Messages" that may be embedded in the transport stream. These keys may be used by the smart card to decrypt the Control Words present in the ECM. An exemplary validity period of such a key is one month.

In the frame of this description, the term "Control Words" (CW) particularly denotes decryption information needed to decrypt actual content. Control words may be decrypted by the smart card and then stored in a memory of the decryption core.

Some aspects related to trick-play on plaintext streams will now be described. It is preferable that any MPEG2 streams created are MPEG2 compliant transport streams. This is because the decoder may not only be integrated within a device, but may also be connected via a standard digital interface, such as a IEEE 1394 interface, for example.

Account should also be taken of any problems that may occur when using a video coding technique like MPEG2 that exploits the temporal redundancy of video to achieve high compression ratios. Frames can no longer be decoded independently.

A structure of a plurality of groups of pictures (GOPs) is shown in Fig. 2. Particularly, Fig. 2 shows a stream 200 comprising several MPEG2 GOP structures with a sequence of I-frames 201 and P-frames 202. The GOP size is denoted with reference numeral 203. The GOP size 203 is set to 12 frames, and only I-frames 201 and P-frames 202 are shown here.

In MPEG, a GOP structure may be used in which only the first frame is coded independently of other frames. This is the so-called intra-coded or I-frame 201. The predictive frames or P-frames 202 are coded with a unidirectional prediction, meaning that they only rely on the previous I-frame 201 or P-frame 202 as indicated by arrows 204 in Figure 2. Such a GOP structure has typically a size of 12 or 16 frames 201, 202.

Another structure 300 of a plurality of GOPs is shown in Fig. 3. Particularly, Fig. 3 shows the MPEG2 GOP structure with a sequence of I-frames 201, P-frames 202 and B-frames 301. The GOP size is again denoted with reference numeral 203.

It is possible to use a GOP structure containing also bi-directionally predictive frames or B-frames 301 as shown in Fig. 3. A GOP size 203 of 12 frames is chosen for the example. The B-frames 301 are coded with a bi-directional prediction, meaning that they rely on a previous and a next I- or P-frame 201, 202 as indicated for some B-frames 301 by curved arrows 204. The transmission order of the compressed frames may be not the same as the order in which they are displayed.

To decode a B-frame 301, both reference frames before and after the B-frame 301 (in display order) are needed. To minimize the buffer demand in a decoder, the compressed frames may be reordered. So in transmission, the reference frames may come first. The reordered stream, as it is transmitted, is also shown in Fig. 3, lower part. The reordering is indicated by straight arrows 302. A stream containing B-frames 301 can give a nice looking trick-play picture if all the B-frames 301 are skipped. For the present example, this leads to a trick-play speed of 3x forward.

Even if an MPEG2 stream is not encrypted (that is to say plaintext), trick-play is not trivial. The possibility of a slow-reverse based on I-frames only is briefly mentioned. An efficient frame based slow-reverse is practically impossible though, due to the necessary inversion of the MPEG2 GOP. Slow- forward which is also known as slow motion forward is a mode in which the display picture runs at a lower than normal speed. A rudimentary form of slow- forward is already possible with the technique making use of a fast-forward algorithm that generates trick-play GOPs. Setting the fast-forward speed to a value between zero and one results in a slow- forward stream based on a repetition of fast-forward trick-play GOPs. For a plaintext stream this is no problem but for an encrypted stream it can lead to the erroneous decryption of part of the I-frame in certain specific conditions. There are several options to solve this problem but the most suitable way is not to repeat the fast-forward trick- play GOP but to extend the size of the trick-play GOP by the addition of empty P-frames. This technique in fact also enables slow-reverse, because it is based on the trick-play GOPs used for fast-forward/reverse and therefore on the independently decodable I-frames. However, it is not preferred to make use of this kind of I-frame based slow- forward or slow- reverse for the following reason. The distance between I-frames in normal play is around half a second and for slow-forward/reverse it is multiplied with the slow motion factor. So this type of slow- forward or slow-reverse is not really the slow motion consumers are used to but in fact it is more like a slide show with a large temporal distance between the successive pictures. In another trick-play mode called still picture mode the display picture is halted. This can be achieved by adding empty P-frames to the I-frame for the duration of the still picture mode. This means that the picture resulting from the last I-frame is halted. When switching to still picture from normal play, this can also be the nearest I-frame according to the data in the CPI file. This technique is an extension of the fast-forward/reverse modes and results in nice still pictures especially if interlace kill is used. However the positional accuracy is often not sufficient when switching from normal play or slow- forward/reverse to still picture.

The still picture mode can be extended to implement a step mode. The step command advances the stream to some next or previous I-frame. The step size is at minimum one GOP but can also be set to a higher value equal to an integer number of GOPs. Step forward and step backward are both possible in this case because only I-frames are used. The slow- forward can also be based on a repetition of every frame, which results in a much smoother slow motion. The best form of slow- forward would in fact be a repetition of fields instead of frames because the temporal resolution is doubled and there are no interlace artifacts. This is however practically impossible for the intrinsically frame based MPEG2 streams and even more so if they are largely encrypted. The interlace artifacts can be significantly reduced for the I- and P-frames by using special empty frames to force the repetition. Such an interlace reduction technique is not available for the B-frames though. Whether the use of interlace kill for the I- and P-frames is still advantageous in this case or in fact leads to a more annoying picture for the viewer can only be verified by experiments.

Slow-reverse on the basis of individual frames is in fact very complicated for MPEG signals due to the temporal predictions. A complete GOP has to be buffered and reversed. There is no simple method that we know of to recode the frames in a GOP to the reverse order. So an almost complete decoding and encoding might be necessary with an inversion of the frame order between these two. This asks for the buffering of a complete decoded GOP as well as a full MPEG decoder and encoder.

Still picture mode can be defined as an extension of the frame-based slow- forward mode. It is based on a repeated display of the current frame for the duration of the still picture mode whatever the type of this frame is. This is in fact a slow- forward with an infinite slow motion factor if this indicates the factor with which the normal play stream is slowed down. No interlace kill is possible if the picture is halted on a B-frame. In that sense this still picture mode is worse than the trick-play GOP based still picture mode. This can be corrected by only halting the picture at an I- or P- frame at the cost of a somewhat less accurate still picture position. Discontinuities in the temporal reference and the PTS can also be avoided in this case. Moreover, the bit rate is significantly reduced because the repetition of an I- or P-frame is forced by the insertion of empty frames instead of a repetition of the frame data itself as is necessary for the B-frames. So, technically speaking, the halting of a picture at an I- or P-frame is the best choice. The still picture mode can also be extended with a step mode. The step command advances the stream in principle to the next frame. Larger step sizes are possible by stepping to the next P-frame or some next I-frame. A step backward on frame basis is not possible. The only option is to step backward to one of the previous I-frames.

Two types of still picture mode have been mentioned, namely trick-play GOP based and frame based. The first one is most logically connected to fast-forward/reverse whereas the second one is related to slow-forward. When switching from some mode to still picture, it is preferable to choose the related still picture mode to minimise the switching delay. The streams resulting from both methods look very alike because they are both based on the insertion of empty frames to force the repetition of an anchor frame. But on detailed stream construction level there are some differences.

In the following, some aspects related to a CPI ("characteristic point information") file will be described.

Finding I-frames in a stream usually requires parsing the stream, to find the frame headers. Locating the positions where the I-frame starts can be done while the recording is being made, or off-line after the recording is completed, or semi on-line, in fact being off-line but with a small delay with respect to the moment of recording. The I-frame end can be found by detecting the start of the next P-frame or B-frame. The meta-data derived this way can be stored in a separate but coupled file that may be denoted as characteristic point information file or CPI file. This file may contain pointers to the start and eventually end of each I-frame in the transport stream file. Each individual recording may have its own CPI file.

The structure of a characteristic point information file 400 is visualized in Fig. 4. Apart from the CPI file 400, stored information 401 is shown. The CPI file

400 may also contain some other data that are not discussed here.

With the data from the CPI file 400 it is possible to jump to the start of any I- frame 201 in the stream. If the CPI file 400 also contains the end of the I-frames 201, the amount of data to read from the transport stream file is exactly known to get a complete I- frame 201. If for some reason the I-frame end is not known, the entire GOP or at least a large part of the GOP data is to be read to be sure that the entire I-frame 201 is read. The end of the GOP is given by the start of the next I-frame 201. It is known from measurements that the amount of I-frame data can be 40% or more of the total GOP data.

It is known that reducing the trick-play picture refresh rate can be achieved by displaying each I-frame 201 several times. The bit rate will be reduced accordingly. This may be achieved by adding so-called empty P-frames 202 between the I-frames 201. Such an empty P-frame 202 is not really empty but may contain data instructing the decoder to repeat the previous frame. This has a limited bit cost, which can in many cases be neglected compared to an I-frame 201. From experiments it is known that trick-play GOP structures like IPP or IPPP may be acceptable for the trick-play picture quality and even advantageous at high trick-play speeds. The resulting trick-play bit rate is of the same order as the normal play bit rate. It is also mentioned that these structures may reduce the required sustained bandwidth from the storage device.

Here some aspects related to timing issues and stream construction will be described.

A trick-play system 500 is schematically depicted in Fig. 5.

The trick-play system 500 comprises a recording unit 501, an I-frame selection unit 502, a trick-play generation block 503 and an MPEG2 decoder 504. The trick-play generation block 503 includes a parsing unit 505, an adding unit 506, a packetizer unit 507, a table memory unit 508 and a multiplexer 509.

The recording unit 501 provides the I-frame selection unit 502 with plaintext MPEG2 data 510. The multiplexer 509 provides the MPEG2 decoder 504 with an MPEG2 DVB compliant transport stream 511. The I-frame selector 502 reads specific I-frames 201 from the storage device 501. Which I-frames 201 are chosen depends on the trick-play speed as will be described below. The retrieved I-frames 201 are used to construct an MPEG-2/DVB compliant trick- play stream that is then sent to the MPEG-2 decoder 504 for decoding and rendering. The position of the I-frame packets in the trick-play stream cannot be coupled to the relative timing of the original transport stream. In trick-play, the time axis may be compressed or expanded with the speed factor and additionally inversed for reverse trick- play. Therefore, the time stamps of the original time stamped transport stream may not be suitable for trick-play generation. Moreover, the original PCR time base may be disturbing for trick-play. First of all it is not guaranteed that a PCR will be available within the selected I-frame 201. But even more important is that the frequency of the PCR time base would be changed. According to the MPE G2 specification, this frequency should be within 30 ppm from 27 MHz. The original PCR time base fulfils this requirement, but if used for trick-play it would be multiplied by the trick-play speed factor. For reverse trick-play this even leads to a time base running in the wrong direction. Therefore, the old PCR time base has to be removed and a new one added to the trick-play stream.

Finally, I-frames 201 normally contain two time stamps that tell the decoder 504 when to start decoding the frame (decoding time stamp, DTS) and when to start presenting, for instance displaying, it (presentation time stamp, PTS). Decoding and presentation may be started when DTS respectively PTS are equal to the PCR time base, which is reconstructed in the decoder 504 by means of the PCRs in the stream. The distance between, e.g., the PTS values of 2 I-frames 201 corresponds to their nominal distance in display time. In trick-play this time distance is compressed or expanded with the speed factor. Since a new PCR time base is used in trick-play, and because the distance for DTS and PTS is no longer correct, the original DTS and PTS of the I-frame 201 have to be replaced.

To solve above-mentioned complications, the I-frame 201 may first be parsed into an elementary stream in the parsing unit 505. Then the empty P-frames 202 are added on elementary stream level. The obtained trick-play, GOP is mapped into one PES packet and packetized to transport stream packets. Then corrected tables like PAT, PMT, etc. are added. At this stage, a new PCR time base together with DTS and PTS are included. The transport stream packets are pre-pended with a 4 bytes time stamp that is coupled to the PCR time base such that the trick-play stream can be handled by the same output circuitry as used for normal play. In the following, some aspects related to trick-play speeds will be described. In this context, firstly, fixed trick-play speeds will be discussed.

As mentioned before, a trick-play GOP structure like IPP may be used in which the I-frame 201 is followed by two empty P-frames 202. It is assumed that the original GOP has a GOP size 203 of 12 frames and that all the original I-frames 201 are used for trick-play. This means that the I-frames 201 in the normal play stream have a distance of 12 frames and the same I-frames 201 in the trick-play stream a distance of 3 frames. This leads to a trick-play speed of 12/3 = 4x. If the original GOP size 203 in frames is denoted by G, the trick-play GOP size in frames by T and the trick-play speed factor by Nb, the trick-play speed in general is given by:

N_b=G/T (1)

Nb will also be denoted as the basic speed. Higher speeds can be realized by skipping I-frames 201 from the original stream. If every second I-frame 201 is taken, the trick-play speed is doubled, if every third I-frame 201 is taken, the trick-play speed is tripled and so on. In other words, the distance between the used I-frames 201 of the original stream is 2, 3 and so on. This distance may be always an integer number. If the distance between the I-frames 201 used for trick-play generation is denoted by D (D=I meaning that every I-frame 201 is used), then the general trick-play speed factor N is given by:

N=D*GZT (2)

This means that all integer multiples of the basic speed can be realized, leading to an acceptable set of speeds. It should be noticed that D is negative for reverse trick-play and that D=O results in a still picture. Data can only be read in a forward direction. Therefore, in reverse trick-play, data is read forward and jumps are made backwards to retrieve the preceding I-frame 201 given by D. It should also be noticed that a larger trick- play GOP size T results in a lower basic speed. For instance, IPPP leads to a finer grained set of speeds than IPP.

Referring to Fig. 6, time compression in trick-play will be explained.

Fig. 6 shows the situation for 7=3 (IPP) and G= 12. For D=2, an original display time of 24 frames is compressed into a trick-play display time of 3 frames resulting in N=S. In the given example, the basic speed is an integer but this is not necessarily the case. For G= 16 and 7=3, the basic speed is 16/3 = 5 1/3 which does not result in a set of integer trick-play speeds. Therefore, the IPPP structure (7=4) is better suited for a GOP size of 16 resulting in a basic speed of 4x. If a single trick-play structure is desired that fits to the most common GOP sizes of 12 and 16, IPPP may be chosen. Secondly, arbitrary trick-play speeds will be discussed.

In some cases, the set of trick-play speeds resulting from the method described above is satisfying, in some cases not. In the case of G= 16 and 7=3 one probably still would prefer integer trick-play speed factors. Even in the case of G= 12 and 7=4 it might be preferred to have a speed not available in the set like for instance 7x. Now, the trick-play speed formula will be inverted and the distance D will be calculated which is given by:

D=N*T/G (3)

Using the above example with G=12, 7=4 and N=I results in D=2 1/3. Instead of skipping a fixed number of I-frames 201, an adaptive skipping algorithm might be used that chooses the next I-frame 201 based on the fact what I-frame 201 best matches the required speed. To choose the best matching I-frame 201, the next ideal point Ip with the distance D may be calculated and one of the I-frames 201 may be chosen closest to this ideal point to construct a trick-play GOP. In the following step, again the next ideal point may be calculated by increasing the last ideal point by D.

As visualized in Fig. 7 illustrating trick-play with fractional distances, there are particularly three possibilities to choose the I-frame 201 :

A. The I-frame closest to the ideal point; / = round(//?)

B. The last I-frame before the ideal point; / = mt{Ip) C. The first I-frame after the ideal point; / = int(//?)+l

As can clearly be seen, the actual distance is varying between int(D) and int(D)+l, the ratio between the occurrences of the two being dependent on the fraction of D, such that the average distance is equal to D. This means that the average trick-play speed is equal to N, but that the actually used frame has a small jitter with respect to the ideal frame. Several experiments have been performed with this, and although the trick-play speed may vary locally, this is not visually disturbing. Usually, it is not even noticeable especially at somewhat higher trick-play speeds. It is also clear from Fig.7 that it makes no essential difference whether to choose method A, B or C. With this method, trick-play speed N does not need to be an integer but can be any number above the basic speed Nb. Also speeds below this minimum can be chosen, but then the picture refresh rate may be lowered locally because the effective trick-play GOP size T is doubled or at still lower speeds even tripled or more. This is due to a repetition of the trick-play GOPs, as the algorithm will choose the same I-frame 201 more than once.

Fig. 8 shows an example for D=2/3 which is equivalent to N=2/3 Nb. Here, the round function is used to select the I-frames 201 and as can be seen frames 2 and 4 are selected twice.

Anyway, the described method will allow for a continuously variable trick- play speed. For reverse trick-play a negative value is chosen for N. For the example of Fig. 7 this simply means that the arrows 700 are pointing in the other direction. The method described will also include the sets of fixed trick-play speeds mentioned earlier and they will have the same quality, especially if the round function is used. Therefore, it might be appropriate that the flexible method described in this section should always be implemented whatever the choice of the speeds will be.

Now some aspects related to the refresh rate of the trick-play picture will be discussed.

The term "refresh rate" particularly denotes the frequency with which new pictures are displayed. Although not speed dependent, it will be briefly discussed here because it can influence the choice of T. If the refresh rate of the original picture is denoted by R (25Hz or 30Hz), the refresh rate of the trick-play picture [R₁) is given by:

R_t=RfT (4)

With a trick-play GOP structure of IPP (T=3) or IPPP [T=A), the refresh rate R_t is 8 1/3 Hz respectively 6 1/4 Hz for Europe and 10 Hz respectively 7 1/2 Hz for the USA.

Although the judgement of trick-play picture quality is a somewhat subjective matter, there are clear hints from experiments that these refresh rates are acceptable for low speeds and even advantageous at higher speeds. In the following, some aspects related to encrypted stream environments will be described.

Here some information about encrypted transport streams is presented as a basis for the description of trick-play on encrypted streams. It is focussed on the Conditional

Access System used for broadcast. Fig. 9 illustrates a conditional access system 900 which will now be described.

In the conditional access system 900, content 901 may be provided to a content encryption unit 902. After having encrypted the content 901, the content encryption unit 902 supplies a content decryption unit 904 with encrypted content 903. In this specification it has been stated that ECM denotes Entitlement Control

Messages. Furthermore, it is meant that KMM denotes Key Management Messages, GKM denotes Group Key Messages and EMM denotes Entitlement Management Messages. A Control Word 906 may be supplied to the content encryption unit 902 and to an ECM generation unit 907. The ECM generation unit 907 generates an ECM and provides the same to an ECM decoding unit 908 of a smart card 905. The ECM decoding unit 908 generates from the ECM a Control Word that is decryption information that is needed and provided to the content encryption unit 904 to decrypt the encrypted content 903.

Furthermore, an authorization key 910 is provided to the ECM generation unit 907 and to a KMM generation unit 911, wherein the latter generates a KMM and provides the same to a KMM decoding unit 912 of the smart card 905. The KMM decoding unit 912 provides an output signal to the ECM decoding unit 908.

Moreover, a group key 914 may be provided to the KMM generation unit 911 and to a GKM generation unit 915 which may further be provided with a user key 918. The GKM generation unit 915 generates a GKM signal GKM and provides the same to a GKM decoding unit 916 of the smart card 905, wherein the GKM decoding unit 916 gets as a further input a user key 917.

Beyond this, entitlements 919 may be provided to an EMM generation unit 920 that generates an EMM signal and provides the same to an EMM decoding unit 921. The EMM decoding unit 921 located in the smart card 905 is coupled with an entitlement list unit 913 which provides the ECM decoding unit 908 with corresponding control information.

In many cases, content providers and service providers want to control access to certain content items through a conditional access (CA) system.

To achieve this, the broadcasted content 901 is encrypted under the control of the CA system 900. In the receiver, content is decrypted before decoding and rendering if access is granted by the CA system 900.

The CA system 900 uses a layered hierarchy (see Fig. 9). The CA system 900 transfers the content decryption key (Control Word CW 906, 909) from server to client in the form of an encrypted message, called an ECM. ECMs are encrypted using an authorization key (AK) 910. For security reasons, the CA server 900 may renew the authorization key 910 by issuing a KMM. A KMM is in fact a special type of EMM, but for clarity the term KMM may be used. KMMs are also encrypted using a key that for instance can be a group key (GK) 914, which is renewed by sending a GKM that is again a special type of EMM. GKMs are then encrypted with the user key (UK) 917, 918, which is a fixed unique key embedded in the smart card 905 and known by the CA system 900 of the provider only. Authorization keys and group keys are stored in the smart card 905 of the receiver.

Entitlements 919 (for instance viewing rights) are sent to individual customers in the form of an EMM and stored locally in a secure device (smart card 905). Entitlements 919 are coupled to a specific program. An entitlements list 913 gives access to a group of programs depending on the type of subscription. ECMs are only processed into keys (Control Words) by the smart card 905 if an entitlement 919 is available for the specific program. Entitlement EMMs are subject to an identical layered structure as the KMMs (not depicted in Fig. 9).

In an MPEG2 system, encrypted content, ECMs and EMMs (including the KMM and GKM types) are all multiplexed into a single MPEG2 transport stream.

The description above is a generalized view of the CA system 900. In digital video broadcasting, only the encryption algorithm, the odd/even Control Word structure, the global structure of ECMs and EMMs and their referencing are defined. The detailed structure of the CA system 900 and the way the payloads of ECMs and EMMs are encoded and used are provider specific. Also the smart card is provider specific. However, from experience it is known that many providers follow essentially the structure of the generalized view of Fig. 9.

In the following, DVB Encryption/Decryption topics will be discussed.

The applied encryption and decryption algorithm is defined by the DVB standardisation organisation. In principle two encryption possibilities are defined namely PES level encryption and TS level encryption. However, in real life mainly the TS level encryption method is used. Encryption and decryption of the transport stream packets is done packet based. This means that the encryption and decryption algorithm is restarted every time a new transport stream packet is received. Therefore, packets can be encrypted or decrypted individually. In the transport stream, encrypted and plaintext packets are mixed because some stream parts are encrypted (e.g. audio/video) and others are not (e.g. tables). Even within one stream part (e.g. video) encrypted and plaintext packets may be mixed.

Referring to Fig. 10, a DVB encrypted transport stream packet 1000 will be described. The stream packet 1000 has a length 1001 of 188 Bytes and comprises three portions. A packet header 1002 has a size 1003 of 4 Bytes. Subsequent to the packet header 1002, an adaptation field 1004 may be included in the stream packet 1000. After that, a DVB encrypted packet payload 1005 may be sent. Fig. 11 illustrates a detailed structure of the transport stream packet header

1002 of Fig. 10.

The transport stream packet header 1002 comprises a synchronization unit (SYNC) 1010, a transport error indicator (TEI) 1011 which may indicate transport errors in a packet, a payload unit start indicator (PLUSI) 1012 which may particularly indicate a possible start of a PES packet in the subsequent payload 1005, a transport priority unit (TPI) 1017 indicating priority of the transport, a packet identifier (PID) 1013 used for determining the assignment of the package, a transport scrambling control (SCB) 1014 is used to select the CW that is needed for decrypting the transport stream packet, an adaptation field control (AFLD) 1015, and a continuity counter (CC) lOlβ.Thus, Fig. 10 and Fig. 11 show the MPEG2 transport stream packet 1000 that has been encrypted and which comprises different parts:

- Packet header 1002 is in plaintext. It serves to obtain important information such as a packet identifier (PID) number, presence of an adaptation field, scrambling control bits, etc.

- Adaptation field 1004 is also in plaintext. It can contain important timing information such as the PCR.

- DVB Encrypted Packet Payload 1005 contains the actual program content that may have been encrypted using the DVB algorithm.

In order to select the correct CW that is needed to decrypt the broadcasted program it is necessary to parse the transport stream packet header. A schematic overview of this header is given in Fig.11. An important field for the decryption of the broadcasted program is the scrambling control bits (SCB) field 1014. This SCB field 1014 indicates which CW the decrypter must use to decrypt the broadcasted program. Moreover, it indicates whether the payload of the packet is encrypted or in plaintext. For every new transport stream packet, this SCB 1014 must be parsed since it changes over time and can change from packet to packet.

In the following, some aspects related to trick-play on fully encrypted streams will be described.

The first reason why this is an interesting topic is that trick-play on plaintext and fully encrypted streams are the two extremes of a range of possibilities. Another reason is that there exist applications in which it may be necessary to record fully encrypted streams. Thus, it would be useful to have a technique at hand to perform trick-play on a fully encrypted stream. A basic principle is to read a large enough block of data from the storage device, decrypt it, select an I-frame in the block and construct a trick-play stream with it. Such a system 1200 is depicted in Fig. 12

Fig. 12 shows the basic principle of trick-play on a fully encrypted stream. For this purpose, data stored in a hard disk 1201 are provided as a transport stream 1202 to a decrypter 1203. Further, the hard disk 1201 provides a smart card 1204 with an ECM, wherein the smart card 1204 generates Control Words from this ECM and sends the same to the decrypter 1203.

Using the Control Words, the decrypter 1203 decrypts the encrypted transport stream 1202 and sends the decrypted data to an 1-frame detector and filter 1205. From there, the data are provided to an insert empty P frame unit 1206 which conveys the data to a set top box 1207. From there, data are provided to a television 1208. Some aspects will be mentioned with respect to the question of what a recording contains.

Making a recording of a single channel, the recording must contain all the data required to playback the recording of the channel at a later stage. One can resort to just record everything on a certain transponder, but this way one would record far more than one needs to playback the program intended to record. This means that both bandwidth and storage space would be wasted. So instead of this, only the packets really needed should be recorded. For each program this means one must record all the MPEG2 mandatory packets like PAT (program association table), CAT (conditional access table), and obviously for each program the video and audio packets as well as the PMT (program map table) that describes which packets belong to a program. Furthermore, the CAT/PMT may describe CA packets (ECMs) needed for decryption of the stream. Unless the recording is made in plaintext after decryption, those ECM packets have to be recorded as well.

If the recording made does not consist of all packets from the full multiplex, the recording becomes a so-called partial transport stream 1300 (see Fig. 13). Further, Fig. 13 illustrates a full transport stream 1301. The DVB standard requires that if a partial transport stream 1300 is played, all normal DVB mandatory tables like NIT (network information table), BAT (bouquet association table) etc. are removed. Instead of these tables, the partial stream should have SIT (selection information table) and DIT (discontinuity information table) tables inserted. In the following, referring to Fig. 14 to Fig. 42, systems will be described which are capable of processing an encrypted data stream according to exemplary embodiments of the invention.

It is emphasized that the systems described in the specification can be implemented in the frame of and in combination with any of the systems described referring to Fig. 1 to Fig. 13.

In the following, some aspects related to dealing with ECMs will be described.

Jumping to the next block during trick-play can mean jumping back in the stream. It will be explained that this may not be only the case for trick-play reverse but also for trick-play forward at moderate speeds. The situation for forward trick-play with forward jumps and for reverse trick-play with inherently backward jumps will be explained afterwards.

Specific problems may occur caused by the fact that data has to be decrypted. A conditional access system may be designed for transmission. In normal play, the transmitted stream may be reconstructed with original timings. But trick-play may have severe implications for the handling of cryptographic metadata due to changed timings. The data may be compressed or expanded in time due to trick-play, but the latency of the smart card may remain constant.

To create a trick-play stream, the mentioned data blocks may go through a decrypter. This decrypter needs the Control Words used in the encryption process to decrypt the data blocks. These Control Words may also be encrypted and stored in ECMs. In a normal set-top-box (STB), these ECMs may be part of the program tuned to. A conditional access module may extract the ECMs, send them to a smart card, and, if the card has rights or an authorization to decrypt these ECMs, may receive the decrypted Control Words from it. Control Words usually have a relatively short lifetime of, for instance, approximately 10 seconds. This lifetime may be indicated by the Scrambling Control Bit, SCB 1014, in the transport stream packet headers. If it changes, the next Control Word has to be used. This SCB change or toggle is indicated in Fig. 14 by a vertical line and with a reference numeral 1402. Referring to Fig. 14, particularly two different scenarios or stream types may be distinguished:

According to a stream type I shown in a lower row 1401 in Fig. 14, two Control Words (CWs) are provided per ECM. According to a stream type II shown in an upper row 1400 in Fig. 14, only one Control Word (CW) is provided per ECM.

Fig. 14 illustrates the two data streams 1400, 1401 comprising subsequently arranged periods or segments A, B, C denoted with reference numeral 1403. In the scenario illustrated in the upper row 1400 of Fig. 14, essentially one Control Word per corresponding ECM is provided. In contrast to this, in the lower row 1401, each ECM comprises two Control Words, namely the Control Word relating to the current period or ECM, and additionally the Control Word of the subsequent period or ECM. Thus, there is some redundancy concerning the provision of the Control Words. During the short lifespan, items of the decryption information may be transmitted several times, so that tuning to such a channel halfway through the lifespan of such a Control Word does not mean waiting for the next Control Word. The conditional access module may only send the first unique ECM it finds to the smart card to reduce or minimize the traffic to the card, as it may have a fairly slow processor. This shows that there may be a limitation of trick-play on encrypted streams.

There may be an implicit upper speed limit, coming from the limited speed of the processing capability of the smart card. In trick-play, the Control Word lifetime of 10 seconds may be compressed or expanded with the trick-play speed factor. Sending an ECM to a smart card and receiving the decrypted Control Words may take approximately half a second. The way Control Words are packed into an ECM may be provider-specific and particularly different for stream type I and stream type II, as depicted in Fig. 14.

CW A denotes the CW that was used to encrypt period A, CW B denotes the CW that was used to encrypt period B, and so on. Horizontally, the transmission time axis is plotted. ECM A may be defined as being the ECM that is present during the major part of period A. It can be seen that, in that case, ECM A holds the CW for the current period A and for stream type I additionally for the next period B. In general, an ECM may hold at least the CW for the current period and might hold the CW for the next period. Due to zapping, this may probably be true for all or many providers.

Before going on, more information will be provided about a decrypter and how it may handle the CWs. The decrypter may contain two registers, one for the "odd" and one for the "even" CW. "Odd" and "even" does not have to mean that the values of the CWs themselves are odd or even. The terms are particularly used to distinguish between two subsequent CWs in the stream. Which CW has to be used for the decryption of a packet is indicated by the SCB 1014 in the packet header. So the CWs used to encrypt the stream are alternating between odd and even. In Fig. 14 this means that, for instance, CW A and CW C are odd, whereas CW B and CW D are even. After the decryption by the smart card, CWs may be written to the corresponding registers in the decrypter overwriting previous values, as indicated in Fig. 15. Fig. 15 illustrates the two registers 1501, 1502 containing even CWs (register

1501) and containing odd CWs (register 1502). Further, smart card latency 1500, that is a time needed by the smart card to retrieve or decrypt a CW from an ECM, is illustrated in Fig. 15.

In the case of stream type I, each ECM holds two CWs and as a result both registers 1501, 1502 may be overwritten after the decryption of the ECM. One of the registers 1501, 1502 is active and the other is inactive. Which one is active depends on the SCB 1014. In the example, the SCB 1014 will indicate during period B that the even register 1501 is the active one. The active register may only be overwritten with a CW identical to the one it already holds because it is still needed for decryption of the remainder of that particular period. Therefore, only the inactive register may be overwritten with a new value.

Taking a closer look at period B in trick-play. Assuming that an ECM is sent to the smart card at the start of this period so at the moment the SCB toggle 1402 is crossed. The question is what ECM could then be sent to the smart card?

This ECM should hold CW C to ensure a timely decryption by the smart card for usage at the start of period C.

It may also hold CW B without disturbing the correct availability of CWs in the decrypter.

Looking again at Fig. 14, it can be seen that for stream type I this means sending ECM B and for stream type II ECM C at the start of period B. In general, the current ECM can be sent in case it holds two CWs, and one period in advance if it holds only one CW. Sending an ECM one period in advance may be contradictory though to the embedded ECMs, so the latter have to be removed from the stream in that case. For a more generalized approach it may be preferred that the original ECMs are always removed from the stream by the trick-play generation circuitry or software. However, this cannot always be true. Fig. 16 shows ECM handling in a fast forward mode.

In a plurality of subsequent periods 1403 separated by SCB toggles 1402, a plurality of data blocks 1600 are reproduced, wherein a switching 1601 occurs between different data blocks. For stream type I, an ECM B is sent at a border between periods A and B. For stream type II, an ECM C is sent at a border between period A and period B. Furthermore, according to stream type I, an ECM C is sent at a border between period B and period C. For a stream type II, an ECM D is sent at a border between period B and period C. For ECMs to be available for trick-play at the correct moment, the ECMs may be stored in a separate file. In this file it may also be indicated to which period an ECM belongs (which part of the recorded stream). The packets in the MPEG stream file may be numbered. The number of the first packet of a period (SCB toggle 1402) may be stored alongside with the ECM for this same period 1403. The ECM file may be generated during recording of the stream.

An example of an ECM file is shown in Fig. 42.

The ECM file is a file that may be created during the recording. In the stream, ECM packets may be located which may contain the Control Words needed to decrypt the video data. Every ECM may be used for a certain period, for instance 10 seconds, and may be transmitted (repeated) several times during this period (for instance 100 times). The ECM file may contain every first new ECM of such a period. The ECM data may be written into this file, and may be accompanied by some metadata. First of all, a serial number (counting up from 1) may be given. As a second field, the ECM file may contain the position of the SCB toggle. This may denote the first packet that can use this ECM to correctly decrypt its content. Then the position in time of this SCB toggle may follow as the third field. These three fields may be followed by the ECM packet data itself of which only the first bytes are depicted in Fig. 42. The differences between the ECMs are further down the payload and not visible here.

Using the SCB toggles stored in the ECM file, it may be easy to detect if such toggle is crossed even if this would be during a jump. To send the correct ECM, it may be required to know whether the ECMs contain one or two CWs. In principle, this is not known because it is provider-specific and secret. However, this can easily be determined experimentally by sending ECMs at various moments and observing the results on the display. An alternative method that is particularly suitable for implementation in the storage device itself is as follows. Send one single ECM to the smart card at the moment of an SCB toggle, decrypt the stream and check for PES headers in the coming two periods. With one PES header per GOP, there are around twenty PES headers in each period. The position of a PES header may be easily detected because a PLUSI bit in the plaintext header of the packet may indicate its presence. If correct PES headers are only found during the first period (after the latency of the smartcard), the ECM contains one CW. If they are also found during the second period, it contains two CWs.

Such a situation is depicted in Fig. 17.

Fig. 17 illustrates a situation for one CW detection and for two CW detection. As can be seen, different periods 1403 of encrypted content 1700 are provided. With a smartcard latency 1500, an ECM A may be decrypted to generate corresponding CWs. By decrypting the encrypted content 1700, decrypted content 1701 may be generated. Further shown in Fig. 17 are PES headers 1702, namely a PES header A in period A (left) and a PES header B in period B (right). The area 1703 of period B for one CW in Fig. 17 indicates that the data is decrypted with the wrong key and therefore scrambled. This checking could be done while recording, in which case it will take for instance 20 to 30 seconds. It could also be done offline and, because only two packets indicated by the PLUSIs (one in each period) would have to be checked, it could be very quick. In the unlikely event that adequate PES headers are not available, the picture headers could be used instead. In fact, any known information may be useable for detection. Anyway, a one/two CW indication may be stored in the ECM file.

In the following, some aspects related to dealing with slow-forward streams in particular will be described.

For the construction of a slow- forward stream many considerations apply. For example, the construction of a slow- forward stream on elementary stream level can only be performed on fully plaintext data. As a consequence, the slow-forward stream will be fully plaintext. This is also the case for a normal play stream that has been encrypted. Such a situation is unacceptable to a copyright holder. Furthermore, this is worse than in the case of fast-forward/reverse stream because all information, i.e. each and every frame, is present in plaintext in the slow- forward stream and not just a subset of the frames as is the case for true fast-forward/reverse streams. Therefore a plaintext normal play stream can easily be reconstructed from a plaintext slow-forward stream. So the slow-forward stream should be encrypted if the normal play stream is encrypted. Since a DVB encryptor is not permissible in a consumer device this can only be realized if the slow- forward stream is constructed on transport stream level using the encrypted data packets from the originally transmitted encrypted data stream.

To be able to construct a slow-forward stream on transport stream level it is first of all necessary that each individual frame is available as a series of transport stream packets. In the case of one PES packet per frame this comes naturally. A PES packet is always contained in a series of transport stream packets because PES and transport stream packets are aligned. In the case of one PES packet per GOP this is only the case for the start of the I-frame. All other frame boundaries are mostly located somewhere inside a packet. This is shown in Fig. 18. Such a packet 1800 therefore contains information from two frames 1801 and 1802. So first it is necessary for this packet 1800 to be split up into two packets 1803 1804, the first one 1803 containing the data from the first frame 1801 in the original packet 1800 and the second one 1804 containing the data from the next frame 1802. Each of the two packets 1803 1804 resulting from the splitting has to be stuffed, for instance, with an adaptation field AF 1805 and 1806. The splitting of packets is clearly no problem for a plaintext stream. A first option would be to fully decrypt the normal play data as is depicted in Fig. 19. The decryption in slow- forward mode of a stored fully encrypted stream or a stored hybrid stream is no problem because no stream data is skipped or duplicated in the stream to the decrypter. The complete stored stream is simply fed at a lower than normal rate through the decrypter, which also means that there would be no problems with the embedded ECMs. The plaintext stream coming from the decrypter can then be used to split the packets or in fact to perform any necessary stream manipulation. But the resulting slow- forward stream is, of course, always a plaintext stream in this case.

The construction of an encrypted slow- forward stream from an encrypted normal play stream has to be performed on transport stream level because the use of a DVB encrypter in consumer devices may not be allowed. For this a hybrid stream, as shown in Fig. 20, with only a few plaintext packets 2001 on all frame boundaries is preferable. The other plaintext packets 2000 and encrypted packets 2002 are left unmodified. Such a stream could be generated on the playback side of the storage device if the stored stream is fully encrypted. In this case the decrypter in Fig. 19 is a selective type that only decrypts the necessary packets. But preferably the stream is already stored on for example a hard disk drive 2100 as a hybrid stream as is indicated in Fig. 21.

The plaintext packets in the hybrid stream should now also allow for the splitting of packets containing data from two frames. However, even with a hybrid stream some part of the sequence header code or picture start code can still be located in an encrypted packet. In this case an ideal splitting is not possible. In fact the split is made between the encrypted and plaintext packet. For a frame based slow- forward also other types of concatenation have to be considered than the concatenation of empty P frames to I frames, for example, the concatenation of B-frames to B-frames. This asks for a gluing algorithm at these frame boundaries as is clarified in Fig. 22. In the example there is only one byte of the picture start code at the start of the B-frame 2200 and one byte of the picture start code end of the B-frame 2201. As a result two bytes are missing at the concatenation point. These two bytes have to be inserted in the gluing area 2202. For this gluing it has to be known how the 4-byte MPEG picture start code is split.

In slow- forward mode the decoder has somehow to be forced to repeat the display of a picture in accordance with the slow motion factor. Empty P-frames can be used to force the repetition of a picture resulting from an I-frame. The same technique can also be applied for pictures resulting from P-frames. This technique cannot be applied for B-frames though because empty P-frames always point to an anchor frame being an I- or P-frame. This is in fact the case for any type of empty frame. So the repetition of a picture resulting from a B-frame has to be realized in another way. The only guaranteed method is to repeat the B- frame data itself. Since the repeated B-frames point to the same anchor frames as the original B-frame the resulting pictures will be identical. The amount of data for a B-frame is much more than for an empty P-frame but in general it is still significantly less than for an I-frame. Anyway, the transmission time is also multiplied with the slow motion factor so at least on average there need not be an increase in bit rate.

The empty frames used to force the repetition of pictures resulting from I- or P-frames can be of the interlace kill type thus reducing interlace artefacts for these pictures. But such a reduction is not possible for pictures resulting from the B-frames because the repetition is not forced by an empty frame but by a repetition of the B-frame data itself. So the B-frames will always have the original interlace effects. If interlace kill would be used for the I- and P-frames this might look inconsistent because pictures with and without interlace effects are sequentially present in the stream of displayed pictures. Alternatively, it is better to only use empty frames without interlace kill to construct the slow- forward stream. One might expect that the repetition of the I- and P- frames should be enforced by the insertion in the transmission stream of empty P-frames after the original I- or P-frame. This method may be used for fast-forward/reverse streams consisting of I-frames followed by empty P-frames. However this method is not correct for a stream that also includes B-frames, as is the case for a slow-forward stream constructed from a stored transmission stream with B-frames. Due to the reordering from transmission stream to display stream the I- and P-frames will be repeated in the wrong position thus disturbing the normal display order of the frames. This will be clarified by means of Fig. 23 and Fig. 24. Fig. 23 depicts the effect of reordering in normal play. The top line 2300 shows a normal play transmission stream with a GOP size of 12 frames consisting of I- 2302, P- 2304 and B-frames 2303. The first four frames of the next transmission GOP are also shown here for clarity. The bottom line 2301 shows the stream after reordering to the display order. The index indicates the display frame order. According to pages 24 and 25 of the MPEG-2 standard, ISO/IEC 13818-1 : 1995(E), the reordering is performed as follows:

• B-frames keep their original position;

• Anchor frames are shifted to the position of the next anchor frame.

Upon closer inspection looking at how the slow-forward stream is constructed from this normal play stream. The top line 2400 in Fig. 24 shows the transmission order of the first part of the slow-motion stream for this case, assuming a slow motion factor of 3. Empty P-frames 2404 are inserted after the I-frames 2403 and P-frames 2405, and the B- frames 2406 are repeated. The middle line 2401 shows the effect of the reordering. The bottom line 2402 shows how the I-frames 2403 are repeated 2407 and 2408 by the empty P- frames 2404 in this case. The same repetition occurs for the P-frames 2405. An empty P- frame 2404 results in a displayed picture that is a copy of the picture resulting from the previous anchor frame, which itself could also be an empty P-frame. It is clearly visible that the normal display order indicated by the index is disturbed because the display of frame 14 is split up into two parts. Only the last time frame 14 2408 is displayed it is in the correct position. This also means that all the B-frames are decoded erroneously. Therefore this is not the correct way to generate a slow- forward trick-play stream. In fact there are several possibilities to solve this problem. A first one is shown in Fig. 25. Here the empty P-frames 2404 are inserted before the anchor frames 2403 and 2405 in the transmitted stream extracted from the storage device as is shown in the top line 2500. In the reordered stream, shown in the middle line 2501, the empty P-frames 2404 are now after the anchor frames 2403 and 2405. This is where they should be for a correct repetition of the anchor frames as is clear from the bottom line 2502.

There are however some disadvantages in the use of empty P-frames. The first one is related to the propagation of errors within a GOP. P-frames depend on the previous anchor frame and B-frames depend on the surrounding anchor frames. A data error during the transfer to the STB results in decoding errors and therefore disturbances in the picture. If this error is in an anchor frame it propagates until the end of the GOP because subsequent P- frames depend on this anchor frame. Also the B-frames are affected because they use the pictures from the disturbed surrounding anchor frames for their decoding. So the picture disturbances gradually increase towards the end of the GOP. This is especially important for slow- forward where the GOP size can be very large and therefore very long in time. On the other hand a data error in a B-frame has only a very limited effect because no other frames depend on it. So the picture disturbances are restrained to this B-frame and its repetitions. One could argue that data errors should not occur on a digital interface but there is a second disadvantage in the use of empty P-frames. If these are of the interlace kill type they change the decoded picture by nature resulting in decoding errors for the subsequent frames. So interlace kill is not possible.

It is also indicated that several types of empty B-frames can be constructed. They have the advantage that no additional error propagation is introduced and that interlace kill can be used. The most important types of empty B-frames for our discussion are the forward and backward predictive empty B-frames. We will call them respectively Bf- and Bb-frames. The terms forward and backward predictive might be confusing to the reader. First of all a B-frame is normally bi-directionally predictive, but unidirectional predictive B- frames can also exist. In the latter case they can be forward or backward predictive. Forward predictive means that an anchor frame is used to predict the following B-frames during encoding. So the picture resulting from a forward predictive B-frame is reconstructed during decoding from the previous anchor frame. This means that the Bf- frame forces the repetition of the previous anchor frame. Therefore it has the same effect as an empty P or Pe-frame. It will be clear that the Bb-frame has the opposite effect. It forces the display of the anchor frame following it. For both types of empty B-frames an interlace kill version also exists. Empty B-frames can be used for the construction of a slow- forward stream. The first possibility on the basis of Bb-frames is depicted in Fig. 26. The Bb-frames 2603 are inserted before the anchor frames 2403 2405 in the transmitted stream, as shown in the top line 2600 and keep their position during the reordering as shown in the middle line 2601. The anchor frames 2403 2405 are shifted to the position of the next anchor frame as is also shown in the middle line 2601. The Bb-frame 2603 forces the display of the anchor frame following it in the reordered stream as shown in the bottom line 2602.

However, the preferred option is the use of Bf- frames as depicted in Fig. 27. They are inserted after the anchor frames 2403 2405 in the transmission stream as shown in the top line 2700. The reordered stream is shown in the middle line 2701. The repeated display, as shown in the bottom line 2702, of the anchor frames 2403 2405 in the reordered stream is forced by the Bf- frames 2703 that follow them. It is clear that the use of Bf- frames 2703 is very similar to the use of empty P-frames 2404 for the construction of fast-forward and fast-reverse streams. In fact the use of Bf- frames 2703 is also possible in that case thus using common measures for trick-play generation which is a further benefit. However, when Bf- frames 2703 are used for fast-forward and fast-reverse we have to consider the effect of reordering. This means that some parameters in the fast-forward/reverse stream like the PTS/DTS and the temporal references have to be chosen differently.

A further complication arises with the handling of ECMs in combination with the creation of a slow- forward stream that is not trivial. Extra attention has to be paid to the conditions applied to encrypted data streams.

Initially starting with the assumption that a slow- forward stream is a normal play stream that is transferred to the decoder at a lower than normal speed. In this case, the latency of the smart card relative to the data is lowered by a factor equal to the slow motion factor L. Current conditional access systems will operate properly even with a smart card latency of zero. This means that the original embedded ECMs can be used in their original positions. So no special ECM handling is needed in this case. However, the actual slow- forward stream deviates on some points from the above assumption. The first point is that measures are taken to enforce the repetition of the frames. This means that the slow- forward stream is not just a stretched normal play stream, but that additional data is added. The repetition of the anchor frames is realised by the insertion of empty frames. These do not contain any ECMs and therefore the normal processing order is not disturbed. So the original ECMs can still be used in this case. On the other hand, the repetition of the B-frames is enforced by the repetition of the B-frame data. These may contain ECMs and the normal ECM order is disturbed if a toggle of the table ID 2802 and 2803 is present within the B-frame as is depicted in Fig. 28 at point 2800. A repetition of such a B-frame leads to a high rate of ECMs being to the smart card. This is because in the known decryption systems decryption messages with the same toggle ID are filtered to reduce the rate at which decryption messages are sent to the smart card. In the known decryption systems a toggle in the table ID is used to filter decryption messages. IN the present example, a table ID toggle is found at the start 2801 of the repeated B-frames and at the original toggle location 2800 somewhere along these frames. The high rate of ECMs can cause the decryption system to become overloaded and fail since the rate of different ECMs being sent to the decrypter is higher than in the encrypted data stream in its original form.

Therefore, to create a smooth slow-forward trick-play stream not only are the are there repeated ECMs that were present in the original encrypted data stream to improve channel changing response there are also subsequently repeated ECMs that have been inserted into the encrypted data stream during subsequent processing of the trick-play stream. Another effect has to do with the presence of Control Words in the decrypter, thus influencing the decryption of the stream. Starting with a stream of type I where there are two Control Words per ECM. The Control Words resulting from the ECM with a toggled table ID will destroy the Control Word needed to decrypt the first part of the B-frame. This is depicted in Fig. 29. If we assume that ECMs are discarded as long as the smart card is busy this does not have any effect if the repetition of the B-frames 2900 is shorter than the latency of the smart card 2901. But with a small latency 2901 and a high slow motion factor it can lead to the loss of data from the first part of a repeated B-frame 2900, since a portion of the repeated B-frame data 2902 can no longer be decrypted. This is because a required control word has been overwritten in the registers of the decrypter.

Both of these problems, being the high ECM rate and the loss of data, are preferably solved by discarding the ECMs 3003 from a series of repeated frames 3000 and 3001 except from the last frame 3002 as is shown in Fig. 30a. So only the last 3002 of a series of identical B-frames 3000, 3001 and 3002 will contain the original ECMs 3003. In this case there is only one table ID toggle 2800 in the series of identical B-frames 3000, 3001 and 3002 at a moment that the Control Word for the decryption of the start of the B-frame is no longer needed. The ECMs 3003 do not take part in the repetition process, thus leading to a normal order of the ECMs with a correct timing.

In Fig. 30b the output of a further advantageous embodiment is illustrated. In the repeated B frames 3000, 3001 and 3002 the original ECMs 3003 are only repeated in the repeated B frames 3000 and 3001 up to the table ID toggle 2800, i.e. pre-toggle original ECMs 3004 are kept and the post-toggle ECMs after the table ID toggle 2800 are removed 3005 in a filtering process. For the final repeated B frame 3002 all original ECMs are inserted, including the post-toggle ECMs 3006 after the table ID toggle 2008. This is advantageous to increase the speed of response of the system after channel changing, or zapping. The inverse process can be applied for situations when the first B-frame of a repeated sequence comprises all ECMs, however then the following repeated B-frames would then have the pre-toggle ECMs 3004 removed and only comprise the post-toggle ECMs 3006.

Fig. 31 shows an embodiment 3100 capable of performing the required processing on the encrypted data stream 3107 to solve the problems mentioned above. A detection unit 3101 detects the ECMs contained within the encrypted data stream that has been modified from its original form 3106 by a trick-play generator 3105, generating for example a slow- forward trick-play stream by repeating B-frame data and the ECMs corresponding to the positions in time of the repeated B-frame data. The detected ECMs are communicated to a selection unit 3102 which identifies at least one of the ECMs as have being repeated subsequent to the creation of the original encrypted data stream 3106 transmitted by the original content provider, i.e. the only entity that actually knows how the conditional access system is truly constructed and the requirements upon ECMs to guarantee correct operation of the conditional access system. The selection unit 3102 may comprise an input 3104 for identifying sections of the encrypted data stream that have been repeated. This input is preferably connected directly to a trick-play generator 3105 that inserts the repeated sections into the encrypted data stream. The selection unit 3102 then selects encryption messages or ECMs to be deleted. A deletion unit 3103 deletes the selected encryption messages from the encrypted data stream.

In a further embodiment of the invention as shown in Fig. 32 the device 3100 may also contain repetition detection unit 3200. The repetition detection unit 3200 is capable of analysing the incoming encrypted data stream and identifying sections of the stream that have been repeated at a time later than the creation of the original encrypted data stream. The repetition detection unit 3200 may comprise a decrypter as known to the skilled person to completely decrypt the incoming data stream and analyse it for repeated frames and a comparator also known from the prior art to perform such an analysis on the decrypted data stream. Alternatively, the repetition detection unit 3200 may comprise a simple table ID toggle detector that monitors the table ID in the incoming data stream and generates a toggle signal when the table ID changes.

In a further embodiment of the invention as shown in Fig. 33 the device 3100 may also contain an analyser unit 3300. The analyser unit 3300 may be connected to the detection unit 3101 and be capable of receiving information 3301 about the characteristics of the encryption messages, or ECMs, contained within the encrypted data stream. Exemplary forms for such characteristics are the toggles of the table IDs comprised within the encrypted data stream. It has been found preferable to use the timing characteristics of the ECMs as a suitable characteristic to analyse. The analyser unit 3300 can then use timing characteristics resulting from the detected ECMs to identify portions of the encrypted data stream that have been repeated since the creation of the encrypted data stream in its original form. Such an embodiment, like that of Fig. 32, does not require explicit information to be given to the selection unit and therefore the embodiments of Fig. 32 and Fig. 33 can operate independently of the trick-play unit 3105. The information on repeated sections contained within the encrypted data stream is then passed on to the selection unit 3102 via the input 3104 for receiving information on repeated sections of the encrypted data stream.

This method will also solve the high ECM rate problem for a stream with only one Control Word per ECM. The Control Word problem is a little bit different though. There is no risk that the Control Word needed to decrypt the first part of a repeated B-frame will be destroyed. But a special effect occurs if the table ID toggle and SCB toggle are in one and the same B-frame. In practice this is not to be expected to occur frequently because the distance between these two is often larger than the GOP size due to the latency of the smart card. So the method given earlier for two Control Words per ECM will generally also work for systems with one Control Word per ECM. But the case that the toggles of table ID and SCB are in one and the same B-frame will be considered anyway for the less frequent occurrences.

Fig. 34 depicts this infrequent situation. The single Control Word 3400 resulting from the ECM with a toggled table ID 3403 is necessary to decrypt the part of the B-frame 3402 after the SCB toggle 3401. So if only the last frame 3404 of a series of identical B-frames contains ECMs 3003, the last part of the earlier B-frames 3405 of the series cannot be decrypted correctly.

Maintaining the original ECMs 3003 in the first frame 3500 of a series of identical B-frames and discarding them from the remaining frames 3405 can easily correct this. This situation is depicted in Fig. 35. However, ECMs only in the first frame 3500 is less preferable for systems with two Control Words per ECM, for example, if one of the Control Words would be required to be used immediately. Fortunately, such two Control Words per ECM systems generally send the necessary Control Word one complete cryptographic period in advance. So for one Control Word per ECM systems, only the first B-frame of a series of identical B-frames should contain the ECMs if one wants to consider this less frequent situation.

Another point that deviates from a simply stretched normal play stream is the data rate. Although the average data rate of the slow- forward stream is certainly lower than for the normal play stream, this is not the case for the data rate of compressed frames. Compressed frames can result from the repetition of the B-frame data. One might expect that the duration of B-frames will normally be less than one frame time. On average this is true but occasionally the transmission time of a B-frame can be larger than one frame time. In a measurement on the television channel ZDF lasting roughly 30 seconds a B- frame was detected of 1.4 frame times. This measurement is depicted in Fig. 36. The average B-frame data length equals 0.6 frames, but regularly the duration of the B-frame data is larger than one frame time.

The positioning of the packets of B-frames by means of a correction of their time stamp with the time stamp offset will lead to a correct result as long as the duration of the B-frame is smaller than one frame time. But if a B-frame in the slow- forward stream is larger than one frame, the end of it will overlap with the subsequent frame because the start of the frames is placed with a distance of one frame. The situation for a B-frame larger than one frame time is clarified in Fig. 37. This is true for all of the repeated B-frames 3700 except the last B-frame 3701 of the repeated section because the last repeated B-frame 3701 would never overlap with the subsequent frame 3702, since it did not originally overlap with the subsequent frame 3702 in the encrypted data stream in its original form. The type of the previous and next frame has no influence on this effect. So there can be an anchor frame, a B- frame or even an empty frame.

This means that all the B-frames of a series of identical B-frames 3700 except the last one 3701 have to be compressed in time, these are shown as compressed B-frames 3703 in Fig. 37. This compression can increase the local bit rate even to a level above the maximum bit rate of the total normal play stream. To limit this increase as much as possible, the packets of the B-frame are evenly distributed over the available frame time. The time stamp of the first packet of a B-frame can be calculated with offset rules to evenly distribute the frames over time.

One could imagine that the method of equal packet distribution for the B- frames should be used in all cases and not only if compression is needed. But in most cases this means that the B-frame is expanded. The application of a time stamp offset to the first packet of a B-frame means that the distance of this packet to the DTS is equal to the normal play stream. The expansion would then result in a smaller time distance than original between the end of the B-frame data and the corresponding DTS. But it can easily be understood that the DTS of a frame can never be earlier than one frame time after the start of the frame data. The reasoning is as follows. The DTS of a frame in the original stream is by definition always one frame time later than the DTS of the previous frame. The DTS of this previous frame can never be earlier than the end of the data of this frame and therefore never before the start of the data of the current frame. This means that the DTS of an arbitrary frame is at least one frame time later than the start of the data for this frame. This also means that the DTS is always after the end of the frame data, even if this data is evenly distributed in one frame time. So the described equal packet distribution should be applied to all B- frames except the last repeated one. For simplicity, a compressed as well as expanded frame will both be named a compressed frame in the remainder of this specification.

Gluing is only necessary between the B-frames of an identical series of B- frames. So a possible additional gluing packet will only be added to the end of a compressed B-frame and never anywhere else. An additional PCR packet is added to the end of the B- frames except to the end of the last repeated B-frame because there is no room at this point.

This again means that the additional PCRs are only added at the end of compressed B-frames.

So no special placement algorithm is necessary for these packets because they are all included in the compression algorithm. A consequence from the compression of B-frames is that the earlier described correction of the value of a PCR within the frame data is no longer correct for such a B- frame.

The compression of B-frames as described above leads to a smaller time gap between the table ID toggle and the SCB toggle, which is especially critical for one Control Word per ECM systems where the time distance between these two is matched to the latency of the smart card. Therefore, the solution given for the less frequent case does not work properly in all situations. Therefore it is nevertheless preferable that in most circumstances the ECMs should only be present in the last frame of a series of identical B-frames. Next, an embodiment having a common decrypter will be described. The use of one common decrypter by receiver and trick-play generator can be the case when receiver and trick-play generator are combined in one box. There is no sharing violation because this decrypter is only used by the trick-play generator during trick-play and by the receiver in normal play.

Referring to Fig. 38, a trick-play system 3800 will be described. The trick-play system 3800 includes a storage device 3803, a trick-play generator 3801 and a receiver 3802.

The storage device 3803 stores data to be reproduced which are provided as a transport stream 3805 to a decrypter unit 3806 and to a switch unit 3808 of the trick-play generator

3801. The switch unit 3808 may switch between a normal play mode (NP) and a trick-play mode (TP). Via a control unit 3809, the speed of a desired trick-play may be selectively input as well as the fact whether a normal play or a trick-play is desired. This information is provided from the control unit 3809 to the storage device 3803. The control unit 3809 can be, for instance, controlled by a user via a user interface.

Further, the control unit 3809 provides the entered data or commands to a trick-play stream construction unit 3807 and to an ECM memory unit 3812. The storage device 3803 transmits the transport stream not only to the decrypter unit 3806 and to the switch unit 3808, but also provides ECM data stored in an ECM file 3804 to an ECM memory unit 3812. The ECM memory unit 3812, which also receives the parameters from the control unit 3809, provides the trick-play stream construction unit 3807 and a smart card interface unit 3811 with ECM data. Further, the smart card interface unit 3811 is adapted to communicate with a smart card 3810. The smart card 3810 generates Control Words (CW) and provides the Control Words via the smart card interface unit 3811 to the decrypter unit 3806.

In a normal play mode, the position of the switch of the switch unit 3808 is as shown in Fig. 38. In this operation mode, the transport stream 3805 is directly provided to the receiver unit 3812. However, when a trick-play mode is selected, the switch will go to the other position, so that the transport stream 3805 will be processed by the trick-play stream construction unit 3807 which will provide trick-play data to the receiver 3802, more particularly to a decrypter unit 3813 of the receiver 3802 and to an ECM extractor unit 3816 of the receiver 3802.

An ECM extractor unit 3816 will supply ECMs to a smart card interface 3817 that is communicatively coupled to smart card 3818. In response to the ECMs, the smart card interface 3817 provides the decrypter unit 3813 with Control Words as decryption information. After having passed the decrypter unit 3813, the data are passed to a decoder/renderer unit 3814 from where the data 3815 may be transmitted to a display unit (not shown).

As depicted in Fig. 38, there are particularly two aspects that have to be considered. The first one is the effect on the receiver 3802 that may decrypt, decode and render a signal that is switched between normal play and trick-play. The second one is the effect of the switching in relation to the trick-play generator 3801.

The receiver unit 3802 will now be further described. The trick-play stream generated according to the techniques described herein may be a plaintext stream. In this case, no decryption of the trick-play stream is necessary in the receiver 3802 and the MPEG decoding can start immediately after the switching to trick-play. Here the trick-play generator 3801 will be further described. The trick-play generator 3801 may decrypt the stream in order to select the plaintext I-frames and construct a trick-play stream from it. This process should start as soon as possible after switching to trick-play. Among others, the number of CWs per ECM influences this. This information is regarded as being known (for instance from the CPI file, see Fig. 4 and corresponding description), because it is also necessary for the continuous trick-play generation.

In the following, a particular scenario of switching from trick-play to normal play will be discussed. Special effects, which may occur when switching from trick-play to normal play, are described here. Again, it will be distinguished between the trick-play generator 3801 and the receiver 3802.

When switching to normal play, the trick-play generator 3801 can simply stop its operation. So no special measures may be necessary in relation to this trick-play generator. But as will be explained hereafter, the trick-play generator 3801 can improve the switching effects in the receiver 3802 by taking some special actions particularly at this point.

When switching to the encrypted normal play stream, some special effects may occur in the receiver 3802. It might be appropriate to distinguish between two situations, namely the use of individual decrypters or one common decrypter by the receiver 3802 and trick-p lay generator 3801.

Next, a scenario with individual decrypters will be described. This situation may occur if receiver 3802 and trick-play generator 3801 are in separate boxes connected via a digital bus, but this configuration can also be used when both are in the same box (see Fig. 38). Fig. 39 shows a system 3900 with a common decrypter 3806. An additional switch 3901 is provided in the system 3900 with the common decrypter 3806.

From a switching point of view, the situation for one common decrypter 3806 is identical to the situation for two synchronized individual decrypters. This is in fact the case for solution 4 described previously for two individual decrypters. Solutions 2 and 3 might also be used, but for one common decrypter 3806, the ECM traffic is not interrupted during trick-play. So the memorized table ID should not be the one of the last normal play ECM but from the last ECM sent to the decrypter before the special switching ECM. This is the table ID of the last normal ECM of the trick-play stream. Problems with a busy smart card can be avoided by the choice of the switching moment. So most of what is described for two individual decrypters is also applicable here.

Referring to Fig. 40, a device 4000 for processing an encrypted data stream 4001 according to an exemplary embodiment of the invention will be described. Decryption messages, namely ECMs, are provided for decrypting each period 1403 of the encrypted data stream 4001, wherein each ECM comprises a number of Control Words (CW) as decryption elements.

The device 4000 comprises a detection unit 4002 for detecting the number of Control Words per Entitlement Control Message (ECM). This number is two for stream type I, and is one for stream type II. The encrypted data stream 4001 may be supplied to the detection unit 4002.

The device 4000 further comprises a determining unit 4003 for determining a position for providing the ECMs in the sequence of the periods 1403, based on the detected number. For this purpose, the output of the detection unit 4002 which may encode a number of Control Words per ECM, may be supplied to the determining unit 4003. Further, the determining unit 4003 may be supplied with the encrypted data stream 4001 and may modify the encrypted data stream 4001 accordingly, to properly position or insert the ECMs.

The (original or modified) encrypted data stream may be provided to a generation unit 4004 which may decrypt the encrypted data stream 4001 to provide the latter for a normal play mode and reproduce it via a reproduction unit 4005, or may alternatively generate a trick-play stream from the encrypted data stream 4001, in order to perform trick- play on the reproduction unit 4005.

When the detection unit 4002 detects that an ECM corresponding to a particular period 1403 includes two Control Words per ECM (stream type I) the determining unit 4003 may provide the ECM zero segments in advance. Alternatively, when the detecting unit 4002 detects that the number of Control Words of an ECM is one, then the determining unit 4003 may provide the ECM one period 1403 in advance (stream type II).

In the following, referring to Fig. 41, a device 4100 for processing an encrypted data stream 4101 according to another exemplary embodiment of the invention will be described.

Again, ECMs as decryption messages may be provided for decrypting each period 1403 of the encrypted data stream 4101.

The device 4100 comprises a detection unit 4102 for detecting a switch from a trick-play reproduction mode (for instance a fast forward mode) to a normal play reproduction mode. A user may initiate such a switch by operating a user interface 4103, for instance by pressing a corresponding button.

In such an event, the detection unit 4102 transmits this information to a determining unit 4104 and to a generation unit 4105. The determining unit 4104 is adapted to ensure, based on a comparison of a last ECM before the trick-play reproduction mode and a first ECM in the normal play reproduction mode, that the first ECM in the normal play reproduction mode is sent to a smart card. The determining unit 4104 may modify the encrypted data stream 4101 accordingly.

Further, the generation unit 4105 is capable of generating, selectively, a trick- play reproduction stream or normal play reproduction stream to be reproduced by a reproduction unit 4106. For this purpose, the generation unit 4105 is provided with the encrypted data stream 4101, and may receive controlling information from the detection unit 4102 and/or from the determining unit 4104. The determining unit 4104 may be adapted to determine whether the first ECM in the normal play reproduction mode is to be processed to avoid an excessive interruption of a reproduction when switching from the trick-play generation mode to the normal play mode.

A list of abbreviations used in the specification is provided in Table 1.

AFLD Adaptation Field Control

BAT Bouquet Association Table

CA Conditional Access

CAT Conditional Access Table

CC Continuity Counter

CW Control Word

CPI Characteristic Point Information

DIT Discontinuity Information Table

DTS Decoding Time Stamp

DVB Digital Video Broadcast

ECM Entitlement Control Messages

EMM Entitlement Management Messages

GK Group Key

GKM Group Key Message

GOP Group Of Pictures

HDD Hard Disk Drive

KMM Key Management Message

MPEG Motion Pictures Experts Group

NIT Network Information Table

PAT Program Association Table PCR Program Clock Reference

PES Packetized Elementary Stream

PID Packet Identifier

PLUSI Payload Unit Start Indicator

PMT Program Map Table

PTS Presentation Time Stamp

SIT Selection Information Table

SCB Scrambling Control Bits

STB Set-top-box

SYNC Synchronization Unit

TEI Transport Error Indicator

TPI Transport Priority Unit

TS Transport Stream

UK User Key

Table 1 Abbreviations used in the specification

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. The embodiments provide in general a concept of processing an encrypted data stream comprising repeated portions into a processed encrypted data stream with a rate of change of decrypting messages substantially equivalent to that of the encrypted data stream in its original from. Furthermore, any of the embodiments described comprise implicit features, such as, an internal current supply, for example, a battery or an accumulator. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word "comprising" and "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. The singular reference of an element does not exclude the plural reference of such elements and vice- versa. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The terms "data" and "content" have been used interchangeably through the text, but are to be understood as equivalents.

Claims

CLAIMS:

1. A device (3100) for processing an encrypted data stream (3107), wherein decryption messages (3003) are provided for decrypting at least one segment (1403) of the encrypted data stream, wherein the device comprises: a detection unit (3101) for detecting the decryption messages in the encrypted data stream; a selection unit (3102) for selectively identifying for deletion at least one of the decryption messages detected by the detection unit; and a deletion unit (3103) for deleting the at least one of the decryption messages selectively identified by the selection unit, wherein the selection unit (3102) is arranged to select the at least one of the decryption messages to be deleted based upon an identification that the at least one of the decryption messages has been subsequently repeated in the encrypted data stream (3107) after creation of the encrypted data stream in its original form (3106).

2. The device (3100) of claim 1 wherein the selection unit (3102) is further arranged to select for deletion all but one of the at least one of the decryption messages (3003) identified as being subsequently repeated.

3. The device (3100) of claim 1 wherein: the detection unit (3101) further comprises a means to detect a first set of encrypted messages (3004) and a second set of encrypted messages (3006) in the encrypted data stream; and wherein the selection unit is adapted to selectively identify for deletion at least one of the decryption messages detected by the detection unit corresponding to either the first set of encrypted messages (3004) or the second set of encrypted messages (3006).

4. The device (3100) of claim 1 or 2 wherein: the selection unit (3102) further comprises an input (3104) arranged for receiving information indicating repeated portions of the encrypted data stream comprised within the encrypted data stream; and wherein the selection unit is adapted to selectively identify for deletion at least one of the decryption messages detected by the detection unit corresponding to the repeated portions indicated by the information received from the input of the selection unit.

5. The device (3100) of claim 4 wherein the information indicating the repeated portions of the encrypted data stream is provided by a further device (3105) for processing an encrypted data stream.

6. The device (3100) of claim 4 further comprising: a repetition detection unit (3200) for detecting repeated portions of the encrypted data stream by detecting portions that have been subsequently repeated in the encrypted data stream (3107) after creation of the encrypted data stream in its original form (3106); the repetition detection unit comprising an output for outputting information indicating the repeated portions of the encrypted data stream; wherein the output of the repetition detection unit is connected to the input (3104) of the selection unit (3102) arranged for receiving information indicating repeated portions.

7. The device (3100) of claim 4 wherein the detection unit (3101) has an analysis output (3301) for outputting characteristics of the decryption messages (3003) in the encrypted data stream; and wherein the device (3100) further comprises an analyzer unit (3300) connected to the analysis output (3301) of the detection unit; the analyzer unit being arranged to detect repeated portions of the encrypted data stream subsequently repeated in the encrypted data stream (3107) after creation of the encrypted data stream in its original form (3106) by analyzing the characteristics of the decryption messages (3003) in the encrypted data stream received from the analysis output (3301) of the detection unit; the analyzer unit further comprising an output for outputting information indicating the repeated portions of the encrypted data stream; wherein the output of the analyzer unit is connected to the input (3104) of the selection unit (3102) arranged for receiving information indicating repeated portions.

8. The device (3100) of claim 7 wherein the characteristics of the decryption messages arranged to be analyzed are timing characteristics.

9. The device (3100) of claim 8 wherein the timing characteristics of the decryption messages arranged to be analyzed are toggles 2800 in a table ID parameter.

10. The device (3100) of claim 2 wherein the selection unit is further arranged to select for deletion all but the first of the at least one of the decryption messages identified as being subsequently repeated.

11. The device (3100) of claim 2 wherein the selection unit is further arranged to select for deletion all but the last of the at least one of the decryption messages identified as being subsequently repeated.

12. The device (3100) of claim 1 adapted to process an encrypted data stream comprising one or more from a selection of: video data; audio data; and digital data.

13. The device (3100) of claim 1 adapted to process an encrypted MPEG2 data stream.

14. The device (3100) of claim 1 realized as at least one of the group consisting of: a digital video recording device; a network-enabled device; a conditional access system; a portable audio player; a portable video player; a mobile phone; a DVD player; a CD player; a hard disk based media player; an Internet radio device; a computer; a television; a public entertainment device; and an MP3 player.

15. A method of processing an encrypted data stream (3107), wherein decryption messages (3003) are provided for decrypting at least one segment (1403) of the encrypted data stream, the method comprising the method steps of: detecting the decryption messages in the encrypted data stream; selectively identifying for deletion at least one of the decryption messages detected during the method step of detecting the decryption messages; and deleting the at least one of the decryption messages selectively identified during the method step of selectively identifying, wherein the method step of selectively identifying selects the at least one of the decryption messages to be deleted based upon an identification that the at least one of the decryption messages has been subsequently repeated in the encrypted data stream after creation of the encrypted data stream in its original form.

16. The method of claim 15 wherein the method step of selectively identifying further selects for deletion all but one of the at least one of the decryption messages identified as being subsequently repeated.

17. The method of claim 15 or 16 wherein the method step of selectively identifying further comprises the method steps of: receiving information indicating repeated portions of the encrypted data stream comprised within the encrypted data stream; and selectively identifying for deletion at least one of the decryption messages detected during the method step of detecting the decryption messages corresponding to the repeated portions indicated by the information received indicating repeated portions of the encrypted data stream comprised within the encrypted data stream.

18. A program element directly loadable into the memory of a programmable device, comprising software code portions for performing, when said program element is run on the device, the method steps of: detecting decryption messages in an encrypted data stream; selectively identifying for deletion at least one of the decryption messages detected during the method step of detecting the decryption messages; and deleting the at least one of the decryption messages selectively identified during the method step of selectively identifying, wherein the method step of selectively identifying selects the at least one of the decryption messages to be deleted based upon an identification that the at least one of the decryption messages has been subsequently repeated in the encrypted data stream after creation of the encrypted data stream in its original form.

19. A computer-readable medium directly loadable into the memory of a programmable device, comprising software code portions for performing, when said program element is run on the device, the method steps of: detecting decryption messages in an encrypted data stream; selectively identifying for deletion at least one of the decryption messages detected during the method step of detecting the decryption messages; and deleting the at least one of the decryption messages selectively identified during the method step of selectively identifying, wherein the method step of selectively identifying selects the at least one of the decryption messages to be deleted based upon an identification that the at least one of the decryption messages has been subsequently repeated in the encrypted data stream after creation of the encrypted data stream in its original form.