MX2007012939A - A device for and a method of processing an encrypted data stream for trick play - Google Patents

Abstract

A device (3000) for processing an encrypted data stream (3001), wherein decryption messages are provided for decrypting each segment (1403) of the encrypted data stream (3001), wherein each decryption message comprises a number of decryption elements, wherein the device (3000) comprises a detection unit (3002) for detecting the number of decryption elements per decryption message, and a determining unit (3003) for determining a position for providing the decryption messages in relation to the sequence of the segments (1403), based on the detected number.

Description

AND METHOD FOR PROCESSING A FLOW OF ENCRYPTIONED DATA FIELD OF THE INVENTION The invention relates to a device for processing: "a stream of encrypted data." Further, the invention relates to a method of processing a stream of encrypted data. Additionally, the invention relates to a computer-readable medium BACKGROUND OF THE INVENTION [0002] The three electronic entertainment devices have been increasingly important, and in particular, an increasing number of users purchase audio / video players. Other HDD-based entertainment equipment Because 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 reasons security in an encrypted way MPEG2 is a standard for the generic encoding of motion and audio images associated and creates a video output stream of raster data that can be arranged in a specific order called the GOP structure ("Group of images"). An MPEG2 video bit stream is constituted by joins. series of data frames that encode images. The No. Ref. : 186099 three (forms of coding of an image are intracoal (I image), predictive of advance (P image) and bidirectional predictor (B image) An intra-coded frame (I-frame) is related to a particular image and contains the corresponding data. An advance predictive frame (P-frame) needs information from an I-frame or previous P-frame.A bidirectional predictive frame (B-frame) is independent of the information of an I-frame or Previous or subsequent P-frame, It is an interesting function in a media playback device to switch from a normal playback mode, in which the media content is reproduced in a normal velicity, to a trick-play playback mode, in the which media content is reproduced in a modified manner, for example with an increased speed ("fast forward") or vice versa. WO 03/107666 Al discloses a trick-play in an encrypted data stream, wherein the Control Word information units required to decrypt successive segments of the stream are supplied. Different media content providers can use different formats for encrypted video content and to decrypt data needed to decrypt the encrypted video content. Thus, it can be very difficult to coordinate providing segments of encrypted video content and provide and decrypt encrypted decryption data, particularly in a transition between normal playback and trick-play. SUMMARY OF THE INVENTION It is an object of the invention to appropriately adjust the provision of an encrypted data stream and the corresponding decryption data. For the purpose of obtaining the object defined above, a device is provided for processing an encrypted data stream, a method for processing an encrypted data stream, a program element and a computer readable medium in accordance with the independent re-occurrences. In accordance with an exemplary embodiment of the invention, a device for processing an encrypted data stream is provided, wherein decryption messages are provided to decrypt each segment of the encrypted data stream, wherein each decryption message comprises a number of encrypted data. decryption elements, wherein the device comprises a detection unit for detecting the number of decryption elements per decryption message, and a determining unit for determining a position for providing the decryption memes in relation to the sequence of the decryption elements. , based on the detected number.

In accordance with another exemplary embodiment of the invention, there is provided a method for processing a stream of encrypted data, wherein the decryption messages are provided to decrypt each segment of the encrypted data stream, wherein each decryption message comprises a number of decryption elements, wherein the method comprises the steps of detecting the number of decryption elements per decryption message, and determining a position to provide decryption messages in relation to the sequence of the segments, based on the number detected. In accordance with yet another exemplary embodiment of the invention, a device for processing an encrypted data stream is provided, wherein the decryption messages are provided to decrypt each segment of the encrypted data stream, wherein the device comprises a detection unit. for detecting a switch from a trick-play reproduction mode to a normal playback reproduction mode, and a determining unit for determining a way to handle the decryption messages to avoid an excessive interruption of playback during a switching from the mode from trick-play playback to a normal playback playback mode. Moreover, in accordance with yet another exemplary embodiment of the invention, there is provided a method for processing a physical, | or in a hybrid form, ie by means of software components and physical equipment components, the characterization characteristics in accordance with the invention particularly have the advantage that the encrypted content and the corresponding decryption data (optionally decrypted) ) necessary to decrypt the encrypted content, can be synchronized appropriately due to the sophisticated control of the supply and the handling of the decryption messages, in particular the Rights Control Messages (ECM, for its acronym in English). By selecting an appropriate position or time to insert or provide a particular decryption message in a data stream it can be ensured that sufficient and correct information is provided to decrypt the decryption messages and / or the encrypted data stream within of a time limit, Particularly the number of decryption elements (eg Control Words) included in a decryption message (eg, an ECM) may contain valuable information to improve synchronization. By taking this measure, the decryption data can be supplied soon enough to ensure that a reproduction of the data stream in any reproduction mode (eg normal playback or trick-play) is continuous without interruption by large disturbances of reproduction.

Particularly in a transition from a trick-play reproduction to a normal reproduction, it may be convenient to extract, select and / or appropriately process decryption information supplied with a data stream to allow accurate and timely decryption to avoid or minimize an interruption in a transition area. In accordance with one aspect of the invention, a number of decryption elements (e.g.

Controll) included in a single decryption message (for example, an ECM) can be used as a criterion to control the timing of delivery of decryption messages. Then, this detected number can be taken as a basis to decide in which position a description message should be inserted in a sequence of segments that form the data flow. The dependence of the number of decryption elements per desander message, for example one or two, may be appropriate to provide the corresponding decryption messages in a particular time in advance or not, for example a segment in advance or zero segments in advance. By appropriate selection of this position, it is possible to improve or optimize the synchronization of the provision of the content data and decryption data. Thus, in accordance with an exemplary embodiment of the invention, a method is provided for handling Messages from ControlJ Rights, particularly in a fast-forward mode example for a trick-play playback mode).

In a fast-track trick-play mode, the ECMs and Control Words (C), respectively, can be delivered in a particular period in advance (particularly in the current period or in a period in advance), depending on the number of CWs in the periods (for example one or two). It may also be possible to store (temporarily) and / or archive and / or store (permanently) the ECMS. To create a trick-play flow, it might be appropriate for the data banks to be supplied to a decipherer. Such a decryptor needs Control Words used in the encryption process to decrypt the data blocks. These Control Words can also be encrypted and stored in a Rights Control Message (ECM). There may be an implicit upper trick-play speed limit, which originates from the limited speed of the processing capacity of the decryption message decrypter (for example a smart card). In a normal reproduction, the life of the Control Word can be 10 seconds and can be compressed with the trick-play speed factor in the trick-play mode. In accordance with one embodiment of the invention, there is provided a method for generating a trick-play flow of a flow of encrypted video data. At least one Word of Con rol may be required to decrypt successive segments of the video data stream, the Control Words are supplied in a Rights Control Message (ECM), the Rights Control Message (ECM) is supplied in advance of the successive segment of the video data stream to be de-encrypted. The method may comprise the steps of detecting whether a single Control Word or more Control Words are supplied (by ECM). Subsequently, for decryption, an ongoing Rights Control Message (ECM) may be provided in the event that a Rights Control Message carries two Control Words (CWs), plus an advance period of Control Messages from Rights (ECM) if it carries only one Control Word (CW). Optionally, the Rights Control Messages originally supplied can be extracted from the encrypted video data stream. As a result, a trick-play playback mode executed correctly, improved, in particular a fast-forward trick-play reproduction mode can be achieved. For the ECMs that must be available for a trick-play at a correct time, the ECMs can be stored in a separate file. In this file, it may be possible to indicate to which period an ECM belongs.

Exemplary fields of application of the system according to the invention are digital video recording devices (such as combinations of hard disks, DVD + RW, etc.), network enabled devices using trick-play, or conditioned access systems. system in accordance with an exemplary embodiment of the invention is directed to special ECM precautions It has been found that these precautions may be convincing in many cases in a fast-forward trick-play. Improved vision in this matter has shown that a refinement in such precautions may be appropriate to correctly execute a trick-play, particularly a trick-play. fast forward According to another aspect of the invention, an appropriate synchronization of the decryption messages and content to be reproduced in a transition from trick-play to normal reproduction can be achieved by detecting a switch between these two reproduction modes. When such switching occurs, a determining unit can ensure that a playback interruption is avoided or at least significantly reduced around switching by properly analyzing the decryption messages, controlling their provision and / or selecting appropriate decryption messages. Particularly, a last decryption message sent before the start of the mode trick-play reproduction and a first message of decryption sent after the end of the trick-play reproduction mode can be analyzed or compared in this context. In particular, it may be decided whether or not it is necessary to extract or process the first decryption message in the normal playback mode initiated. Thus, the quality of a trick-play / normal playback transition can be improved and the undesirable switching effects can be eliminated. Thus, it can be ensured that, when a switch from a raw trick-play stream to a normal encrypted playback stream, a correct decryption start occurs as soon as possible. In other words, the required and correct ECMs can be provided as quickly as possible after switching. With reference to the dependent claims, the additional exemplary embodiments of the invention will be described. Subsequently, the exemplary embodiments of the device for processing an encrypted data stream that detects the number of decryption elements per decryption message will be described. These modalities can also be applied for the method of processing an encrypted data stream, for the computer readable medium and for the program element.

Lq > s decryption messages can be messages from Control (ECMs), and the decryption elements can be Control Words (CW). Accordingly, the device can per realized as an MPEG2 video data processing device. In accordance with another exemplary embodiment of the invention, a decryption message corresponding to a particular segment can be provided in advance of the particular segment. By providing the decryption message in a good time before the start of a particular segment, it can be ensured that the same decryption message can be decrypted before the corresponding segment of the data content has to be reproduced, Such a reproduction may require completing the decryption of the corresponding segment (part of) with the use of the decrypted decryption message. The unit for determining the device can be adapted to, in case the detected number of decryption elements per decryption message is two, proport < fcionar the segments of zero messages of decryption in advance. In other words, the decryption message can be delivered essentially directly prior to the corresponding segmentation. Thus, when two CWs are provided in an ECM for a corresponding period of the data flow, the ECM should not be sent with a distance.

In advance. For example, for a particular segment or period, it may be possible to provide the decryption elements for this period and for a subsequent period in a common decryption message. In the following period, the decryption element for this period can again be provided, and in addition to this the corresponding decryption element for the following period. This scheme can allow to provide all the elements of decryption (Control Words) in a time limit so that a long interruption during the reproduction of data related to different periods can be avoided. However, in the event that the detected number of decryption elements per decryption message is one, the device determining unit may be adapted to provide the decryption message one segment in advance. This can ensure proper synchronization of content and decryption data. The device may additionally comprise a storage unit which can be adapted to store the decryption messages in a separate file. This file can be indicative of the assignment of the decryption messages to the corresponding segments. When you store decryption messages assigned to segments In a separate file, the de-cracking data can be archived and can be easily retrieved, when required, individually, two registers can be provided to store the two descriptive elements of a single message; of description, where only one of the two registries has the ability to overwrite data stored in it at the same time. In other words, the decryptor can contain two records, one for the description elements called "odd" and one for the called "pair", so that two types of decryption elements can be defined. "Odd" and "even" are terms to distinguish between two elements of subsequent decryption in a luxury. One of the two registers stores the peer decryption elements, the other stores the odd decryption elements. After the decryption, the decryption elements can be written for the corresponding registers in the decryptor, possibly on writing previously stored values. However-, only an inactive record in progress can be about esc < rite with a new value. The device may comprise a control unit adapted to extract the decryption messages originally provided from the encrypted data stream, particularly in order to avoid a possible overload.

Write of decryption elements in the records that are still necessary. The device can be adapted to process an encrypted data stream of video data or audio data. However, such media content is not the only type of data that can be processed with the scheme according to the invention. The trick-play generation and application of similar ions can be a problem for both video processing and audio processing (pure). The device may also be adapted to process a stream of encrypted data of digital data, Additionally, the device may comprise a reproduction unit for reproducing the flow of decrypted data. Such a reproduction unit may comprise a speaker or headphones and / or an optical display device so that both audio and visual data may be reproduced so that they are perceived by a human. Furthermore, the device may comprise a unit of generates < pion to process the decrypted data stream for a re > production in a trick-play playback mode. Such a trick-play generation unit adapted to generate a flow of damage for reproduction in a trick-play reproduction mode can be adjusted by a user by selecting corresponding options in a user interface, for example buttons of a device , a keyboard or a remote control. The trick-play playback mode selected by a user can be one of the group consisting of a fast-forward playback mode, a fast-reverse mode, a slow-motion playback mode, a frozen-frame playback mode, a instant replay playback mode, and a reverse playback mode. However, other trick-play flows are possible. For a trick-play, only a portion of subsequent data should be used for an output (for example for a visual display and / or for an acoustic output). Since not all data (P-frames, B-frames in a data stream can be used independently of other data (I-frames) to generate expandable signals, the recognition of independently usable data may be of interest (I The device according to the invention can be adapted to process an MPEG2 encrypted data stream MPEG2 is a designation for a group of audio and video coding standards according to the MPEG2 (acronym in English). LngQ of the Motion Picture Experts Group), and published as the International Standard ISO / IEC 13818. For example, MPEG2 is used to encode audio and video for broadcast signals including digital and cable satellite TV, but it can also be used for DVD.The device according to the invention can be realized as one of the group consisting of a device digital video recording, a network enabled device, a conditioned access system, a portable audio player 1, a portable video player, a mobile phone, a DVD player, a CD player, a media player | based on hard drive, an internet radio device, a public entertainment device, and an MP3 player. However, these applications are only exemplary. Next, exemplary embodiments of the device for processing an encrypted data stream based on a detection of a switch from a trick-play reproduction mode to a normal reproduction mode will be described. These modalities can be applied to the method of processing an encrypted data stream, for the computer-readable medium and for the program element, the device, the unit of determination can be adapted to determine, based on a last message from decryption before the trick-play playback mode and a first decryption message in the normal playback mode, if the first decryption message in the normal playback reproduction mode should be modified. combination of the last decryption message before the trick-play and the first decryption message after the trick-play reproduction mode may contain information required to decide sure how these decryption messages should be used to ensure proper processing without a long disruption interruption. Particularly, this analysis can be directed towards questioning whether the first decryption message in the normal reproduction mode should be modified to ensure that the decryption element (s) included in it are used for the purpose of reducing an interval between a trick-play and a reprodi; normal ction. More particularly, the determining unit may be adapted to determine, based on a comparison of a last decryption message before the trick-play reproduction mode and a first decryption message in the normal reproduction reproduction mode, if it should be modified the first decryption message in the normal playback playback mode. Such a comparison, particularly of the type of decryption messages, can improve the quality of the transition from a trick-play to a normal reproduction. By comparing the last decryption message before the trick-play reproduction mode and the first decryption message in the normal reproduction reproduction mode it may be possible to estimate the length of the interruption when a switching of reproduction modes occurs. It may be possible to reduce the length of this interruption by taking appropriate countermeasures. The The need to process (particularly decrypt and use) the first decryption message in the normal reproduction mode can be used to reduce or eliminate such interruption. The determination unit can be adapted to determine that the system can be carried within the an operation state in which the first deseeding message found from the normal reproduction mode will be sent to a decryption message processor, if no decryption messages are present in the stream for more than one time threshold interval of, for example several seconds. In other words, particularly to avoid an excessive switching time from trick-play to normal playback, it is possible to introduce an idle time functionality for ECMs. Additionally or alternatively, the determination unit may be adapted to determine that the first decryption message in the normal reproduction reproduction mode must be modified when the comparison produces the result that the types of messages desiring the last message of decryption before of the trick-play playback mode and the first decoding message in the normal playback playback mode (which is after the trick-play playback mode) are identical. In accordance with this modality, the system can be forced to use the first ECM of the normal reproduction flow. When a switchover to normal playback has occurred, the type of the last ECM before switching to a trick-play, which has been remembered, can be compared to the type of the first ECM in the normal playback stream. If they are identical, the type of the first ECM in the normal reproduction mode is corrected in a way that ensures that this ECM is processed by the smart card. Additionally or alternatively, the determination unit may be adapted to add a last decryption message, which is a copy of the first decryption message in the normal reproduction reproduction mode but with a type of decryption message opposite to that remembered, for an end of the data stream in the trick-play reproduction mode when a switchover from a trick-play reproduction mode to a normal playback reproduction mode is detected. In accordance with this mode, an ECM can be added at the end of the trick-play flow at the time the commutation command is received. From the ECM file, it is possible to know what the first ECM of the normal reproduction flow will be. This ECM can then be inserted at the end of the flow: rick-play, particularly with a type opposite to the remembered one. Additionally or alternatively, the unit of determination can be adapted to add at least one message of decryption within the data stream in the trick-play reproduction mode. Particularly, the unit for determining compliance with this mode can be adapted to copy the decryption messages from the intra-coded frames originally encrypted within the data stream in the trick-play reproduction mode. Thus, ECMs can be inserted into the trick-play flow for one generation, trick-play. Even when it is not necessary to process the tj: rick-play data without formatting by a receiver, taking this measure does not disturb any part of the processing. On the other hand, could I prevent the interruption of the EC by maintaining the current ECM flow? Still with reference to the described embodiment, the determining unit can be adapted to copy messages of de-icing of the intra-coded frames originally encrypted within the data stream in the trick-play reproduction mode. Additionally or alternatively, the aggregation unit can be adapted to insert decryption messages, used to generate the data flow in the trick-play reproduction modcj), within the data stream in the? Μ ??? of reproduction trick-play. In other words, the first option is related to incorporating ECMs present in lab I-frames originally encrypted that can simply be copied into the trick-play flow. The second option is to insert the ECMs that are used for the trick-play generation. The aspects defined above and additional aspects of the invention are apparent from the examples of the embodiment which will be described below and are explained with reference to these examples of modalities. BRIEF DESCRIPTION OF THE FIGURES Le. The invention will be described in greater detail hereinafter with reference to the examples of the embodiment but which is not a limitation of the invention. Read Figure 1 is a transport flow package with marked time. Read Figure 2 shows an MPEG2 group of image structure with intra-coded frames and forward predictive frames, Figure 3 illustrates an MPEG2 group of imaging structure with intra-coded frames, predictive frames of advance and bidirectional predictive frames. Figure 4 illustrates a structure of a characteristic point information file and stored flow content. Figure 5 illustrates a system for a trick-play in an unformatted stream. Figure 6 illustrates time compression in trick-play.

The | Figure 7 illustrates a trick-play with a fractional distance. Figure 8 illustrates a low speed trick-play. The! Figure 9 illustrates a structure of general access-condition system. Figure 10 illustrates an encrypted transport stream packet of digital video transmission. Figure 1 1 illustrates a transport flow packet header of the digital video transmission encrypted transport flow packet of Figure! 1 0. Figure 12 illustrates a system that allows to execute a trick-play in a completely encrypted stream. LOL Figure 13 illustrates a complete transport flow and a partial transport flow. Figure 14 illustrates Right Control Messages for a type I flow and for a type II flow. Figure 15 illustrates writing Control Words to a decryptor. Figure 16 illustrates the handling of a Law Control Message in a fast-forward mode. Figure 17 illustrates the detection of one or two Control Words. Figure 18 illustrates a jump through two coding control bit switches.

You. Figure 19 illustrates a handling of Rights Control Messages in fast-forward trick-play mode. Read Figure 2 0 illustrates a handling of Rights Control Messages in a forward playback mode! fast moderate. Figure 21 illustrates a trick-play generator and receiver in accordance with an exemplary embodiment of the invention. Figure 22 illustrates an interruption of Rights Control Messages during a trick-play. Figure 2 3 illustrates the change of the ur table ID. First Normal Reproduction Rights Control Message. Figure 24 illustrates an additional Rights Control Message at the end of the trick-play. Figure 2 5 illustrates a switch from a forward trick-play to a normal reproduction. Figure 2 6 illustrates a switch from a reverse trick-play to a normal reproduction. Figure 27 illustrates a forward switch to a normal reproduction. Figure 28 illustrates an optimized switching from a trick-play to a normal reproduction. Figure 29 illustrates a common decryptor for a trick-play generator and receiver.

Figure 30 illustrates a device for processing a flow < encrypted data in accordance with an exemplary embodiment 4r of the invention. Figure 31 illustrates another device for processing an encrypted data stream in accordance with another exemplary embodiment of the invention. Figure 32 shows an example of an ECM file. DETAILED DESCRIPTION OF THE INVENTION The illustrations in the Figures are schematic. In the different Figures, identical or similar elements are provided with the same reference signs, then, with reference to Figures 1 to 13, different aspects of implementation of trick-play are described for transportation flows in accordance with modalities, eg, of the invention. In particular, several possibilities will be described for reading a trick-play in an MPEG2 encoded stream, which can be partially or fully encrypted, or not be encrypted. The following description will focus on specific methods for the MPEG2 transport stream format. However, the invention is not restricted to this format. The experiments were actually carried out with an extension, the so-called marked-time transport flow. This compiles transport flow packets, the total of which are prependientes with a header of 4 bytes f? which is the arrival time of the transport flow packet. This time can be derived from the value of the program base reference time (PCR) at the moment in which the first byte of the pagúetee is received in the recording device. This is an appropriate method for storing the synchronization information with the flow, so that the reproduction of the flow becomes a relatively easy process. A problem during playback is to ensure that the MPEG2 decoder buffer will not be exceeded or overflowed if the input stream was in accordance with the decoder buffer model, the restoration of relative synchronization ensures that the outflow is also agreed upon. Some of the trick-play methods described here are independent of the timestamp and are performed well in the same way in transport flows with or without time stamps. Figure 1 illustrates a marked time transport flow packet 100 having a total length 104 of 188 bytes comprising a timestamp 101 having a length 105 of 4 bytes, a packet header 102, and a payload of package 103 that has a length of 184 bytes.

The following description will provide an overview of the possibilities to create a trick-play flow according to MFjEG / DVB (digital video transmission) from a registered transport flow and plans to cover the total spectrum of recorded flows from those that are completely unformatted, so that each bit of data can be manipulated, up to flows that are completely encrypted (for example in accordance with the DVB scheme). ), so that only headings and some tables can be accessible for manipulation. The invention also provides a solution between these extremes, wherein only the data that needs to be manipulated to generate the trick-play flow is unformatted. During the creation of a 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 in the usual approach, or even access any of the packed elementary stream headings (PES) before decryption. This also means that it is not possible to find the image frames. Known trick-play engines are necessary to have the ability to access and process this information. Er. In the frame of this description, the term "ECM" means a Rights Control Message. This message may particularly comprise a secret provider owner information and may, among other things, synchronization report encoded in their headers, this can not be done only with the expectation of obtaining an appropriate fast forward. Besides that, it can be difficult to decide which frames to descend, as this method to execute a fast forward, can provide a frame index higher than the speed of deployment. Moreover, such a flow is not a transport stream according to MPEG2. This may be acceptable if the decoder is in the storage device but can be problematic if the signal is transferred by a standard digital interfcLce. Additionally, the bit rate can increase dramatically in the global chain. If the normal reproduction flow is a marked-time-of-program flow of a single program that originates from a satellite transmission, the bit-to-decoder bit rate in normal playback may be around 40 Mbps and the packets may be find themselves in irregular positions with intermediate spaces (partial transport flow). If the flow is compressed with the trick-play factor, the bit rate can be around 120 Mbps for a 3x trick-play speed. The necessary sustained broadband of a hard disk controller can also be increased with the trick-play factor.

Thus it would be appropriate to maintain the sending of the correct number of frames, but here a problem can occur when a video coding technique such as MPEG is used that takes advantage of the temporary video redundancy to achieve high compression ratios. The frames can no longer be decoded independently. A structure of a plurality of groups of images (GOPs) is shown in Figure 2. Particularly, Figure 2 shows a stream 200 comprising several GOP MPEG2 structures with a sequence of I-frames 201 and P-frames 202. The GOP size is designated with the reference number 203 The size of GOP 203 is set to 12 frames, and here only I-frames 201 and P-frames 202 are shown. In MPEG, a GOP structure can be used in which only the first frame is encoded independently of the others This is the so-called intra-coded or I-frame 201. The predictive frames or P-frames 202 are coded with a unidirectional prediction, which means that they only depend on the previous I-frame 201 or P-frame 202 according to indicated by the arrows 204 in Figure 2. The GOP structure typically has a size of 12 or 16 frames 201, 202. It is assumed that a trick-forward speed is desired, so, for example, every second frame the frames would have to be reordered in time, but due to the fact that the MPEG uses the temporal correlation between successive frames to obtain a high compression ratio, the order in which the frames must be decoded is fixed. Therefore, a GOP must first be deodified in a forward direction. The order of the GOPs sent to the decoder can be reversed, and the GOPs can be omitted for higher back-up trick-play speeds. The reduction of GOPs by the omission of P-frames or B-frames as described above is also possible in this case. Either way, it may result in a displayed sequence of playback or recession instability. Therefore, the trick-play frames must be selected from the coded GOP and inverted in order, after which the frames are recoded. Then the previous GOP is recovered and processed and so on. Even when possible, the complexity of such a procedure may be high. A conclusion of the above considerations is that the use of only the I-frames in the trick-play generation can be an appropriate solution, because these frames can be decoded independently. As a result, the trick-play generation may be easier especially for a kickback. Additionally, the use of only I-frames already allows trickle speeds play down to 3x or 4x. For really low trick-play speeds, the more complex techniques mentioned above can be implemented. Next, some aspects related to a CPI file ("characteristic point information") will be described. Finding I-frames in a flow usually requires analyzing the flow syntactically, to find the frame headers. The location of the positions where the I-frame starts can be done while the registration is taking place, or off-line after the registration is completed, or in semiline, in fact it is offline but with a small delay with respect to the moment of registration The end of I-frame can be found by detecting the start of the next P-frame or B-frame.Metadata derived in this way can be stored in a separate but coupled file which can be desigando As a characteristic point information file or a CPI file, this file may contain pointers for the start and eventually the end of each I-frame in the transport flow file.Each individual record may have its own CPI file.

The structure of a characteristic point information file 400 is observed in Figure 4. In addition to the CPI 400 file, stored information 401 is displayed. The CPI 400 file may also contain some other data that is not discussed here.

With the data of the CPI 400 file it is possible to jump to the beginning of any I-frame 201 in the flow. If the CPI file 400 also contains the end of the I-frames 201, the amount of data to be read from the transport flow file is exactly known to obtain a complete I-frame 201. If for some reason the end of I- The plot is not known, the complete GOP or at least a large part of the GOP data must be read in order 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 the measurements that the amount of data and frame can be 40% more than the total GOP data. With the recovered I-frames 201, a new trick-play stream that complies with the MPEG-2 transport stream format can be constructed. All that is needed is that the frames for the trick-play flow are remultiplexed correctly, so that no storage problems will occur for the MPEG decoder. Even though this seems to be a simple solution, this is not a trivial solution as it will become clearer from the following. Subsequently, some aspects related to how to build a trick-play flow will be described. With the help of the CPI file, which describes in which packet position an I-frame 201 starts, as well as where the I-frame 201 ends, an access is provided for all I-frames 201 of the original stream. But with just concatenating suitably I-selected frames 201 in a large stream of only I-frames 201 does not result in a valid MPEG stream, as it will become clearer from the following. The first point to investigate is the bit rate of the trick-play flow. For example, the original stream has an average video bitrate of 4Mbps and a GOP 203 of twelve frames. The bit rate can be obtained from a measurement in a real transmission stream. This assumes that the trick-play flow consists of I-frames 201 only that each frame is deployed one at a time, leading to an updated transfer rate of the trick-play flow equal to normal reproduction. It is recalled that the I-frame data amount 201 could be 40% of the GOP data. This number originates from a measurement, where the average has been around 25%. So in an average of 25% of the data should be compressed in one twelfth of the time, leading to three times a higher bit rate. Thus, the trick-play bit transfer rate would be 12 Mbps with peaks of up to around 20 Mbps. This simple example has the purpose of providing some information to realize the effect of the bit rate and its origin. In fact, the sizes of the I-frames 201 are known or can be derived from the measurements. Therefore, the bit rate for an I-frame 201 only trick-play flow as a function of time can be easily calculated accurately. The trick-play bit transfer rate can be two to three times higher than the normal playback bit rate and can sometimes be higher than that allowed by the MPEG2 standard. Taking into account that this is an axis with a moderate bit rate flow and that the flows with the highest bit rate will surely be found, it is clear that some form of bit rate reduction has been applied . For example, the trick-play bit transfer rate may be comparable with the normal playback bit rate. This is; especially important if the flows are sent to a decoder through a digital interface. An additional demand on the bandwidth of the interface due to trick-play should be avoided. A first option is to reduce the size of the I-frames 201. However, this could add complexity and limitations in relation to trick-play for lexical flows. option, which may be appropriate for particular applications, is to reduce the updated transfer speed of the trick-play image by deploying each I-frame 201 several times. The bit rate it will be reduced accordingly. This can be achieved by adding the empty P-frame calls 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 inner frame. This has a limited bit cost, which in many cases can be ignored compared to an I-frame 201. From experiments it is known that trick-play GOP structures such as IPP or IPPP may be acceptable for image quality trick-play and even convenient at high trick-play speeds. The resulting trick-play bit transfer rate is of the same order as the normal playback bit rate. It is also mentioned that these structures can reduce the required sustained bandwidth of the storage device. Below, some aspects related to issues of synchronization and flow construction will be described. A trick-play system 500 is shown schematically in Figure 5. The trick-play system 500 comprises a recording unit 501, an I-frame selection unit 502, a trick-play generation block 503 and a MPEG2 504 decoder. The trick-play generation block 503 includes a syntactic analysis unit 505, an aggregation unit 506, a the frequency of the PCR time base would be changed. In accordance with the MPEG2 specification, this frequency must be within 30 ppm of 27 MHz. The original PCR time base meets this requirement, but used for trick-play should be multiplied by the trick-play speed factor. For kickback trick-play this still leads to a time base that runs in the wrong direction. Therefore, the old PCR timebase has to be eliminated and a new one must be added to the trick-play flow. Finally, the I-frames 201 usually contain two timestamps that tell the decoder 504 when to start the decoding of the frame (decoding time stamp, DTS) and when to start the presentation, for example to display it (stamp) of decoding time, PTS for its acronym in English). The decoding and presentation can be initiated when a respective DTS of a 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, for example, the PTS values of the 2 I-frames 201 corresponds to their nominal distances at the deployment time. In trick-play this time distance is compressed by the speed factor.

Since a new new PCR time base is used in trick-play, and because the distance for DTS and PTS is no longer is correct, the original DTS and PTS of the I-frame 201 must be replaced. To solve the aforementioned complications, the I-frame 201 can first be analyzed syntactically within an elementary stream in the syntactic analysis unit 505. Then the empty P-frames 202 are added at the elementary stream level. The GOP, tick-play obtained is related in a PES package and is packaged to transport transport flow packets. Then correlated tables like PAT, P T, etc. They are added. In this e: apa, a new PCR time base together with a DTS and PTS are included. The transport flow packets are prependent with a timestamp of 4 bytes that is coupled to the PCR time base so that the i: rick-play flow can be handled by the same output circuit as the one used for normal reproduction. Next, some aspects related to trick-play speeds will be described. In this context, first, fixed trick-play speeds will be discussed. According to the foregoing, a GOP tr: .ck-play structure such as IPP can 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 203 size of 12 frames and that the total of the original I-frames 201 are used for a negative for the backward trick-play and that D = 0 results in a frozen image. The data can only be read in a forward dijrection. Therefore, in a backward trick-play, the data can be read forward and the jumps are made backwards to retrieve the previous I-frame Qr 201 given by D. It should also be noted that a GOP size trick-play larger T results in a lower basic speed. For example, the IPPP, leads to a set of speeds more refined than those of IPP. Next, with reference to Figure 6, the time compression in trick-play will be explained. LCL Figure 6 shows the situation for T = 3 (IPP) and G = 12. For D = 2, an original deployment time of 24 frames is compressed in a trick-play deployment time of 3 i frames resulting in N = 8. In the given example, the basic velocity is an integer but this is not necessarily the case. For G = 16 and T = 3, le. basic speed is 16/3 = 5 1/3 which does not result in a set of whole trick-play speeds. Therefore, the IPPP structure (T = 4) is better for a GOP size of 16 which results in a basic speed of 4x. If a single trick-play construction is desired to be assembled to most common GOP sizes of 12 and 16, an IPPP can be selected.

Er. Second, arbitrary trick-play speeds will be discussed.

At the I-frame closest to the ideal point; J = rounding (Jp) BJ The last I-frame before the ideal point; J = int (Jp) The first I-frame after the ideal point; J = int (Jp) +1 As can be clearly seen, the real distance is variable between int () and int (D) + l, the proportion between the occurrences of the is dependent on the fraction of D so that the distance average is equal to D. This means that the average trick-play speed is equal to N, but that the plot actually used has a small fluctuation with respect to the ideal plot. Several experiments have been done with this and even though the trick-play speed can vary locally, this is not visually a disturbance. Usualmehte, this is not even persive especially at slightly higher trick-play speeds. It is also clear from Figure 7 that the difference in whether to select method A, B or C does not become essential. With this method, the trick-play velocity N need not be an integer but can be any number above the basic speed Nb. Also speeds below this minimum can be selected, but then the refresh rate of images can be decreased locally because the effective GOP trick-play size T is duplicated or at still lower speeds even tripled or more. This is due to a repetition of the trick-play GOPs, according to the algorithm the same I-frame 201 will be selected more than once. Figure 8 shows an example for D = 2/3 which is equivalent to N = 2/3 Nb. Here, the rounding function is used to select the i-frames 201 and according to what can be preserved the frames 2 and 4 are selected twice. In any case, the described method will allow a variable trick-play speed continuously. For backward trick-play a negative value is selected for N. For the example of Figure 7 this simply means that arrows 700 are pointing in the other direction. The described method will also include the fixed trick-pLay velocity groups mentioned at the beginning and will have the same quality, especially if the yielding function is used. Therefore, it might be appropriate that the flexible method described in this section should always be implemented whatever the selection of speeds. Below we will discuss some aspects related to the update speed of the trick-play image. The term "refresh rate" particularly means the frequency with which new images are In the conditioned access system 900, the 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. A control word 906 may be provided to the content encryption unit 902 and to an ECM generating 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 which is decryption information that is necessary and provided for the content encryption unit 904 to decrypt the encrypted content 903. Additionally, an authorization key 910 is provided to the ECM generation unit 907 and to a KMM generation unit 911, where the latter generates a KMM and provides the same to a KMM decoding unit 912 of the smart card 905. The decoding unit KMM 912 provides an output signal to the ECM decoding unit 908. Furthermore, a group code 914 can be provided to the generation unit KMM 911 and to a generation unit GKM 915 which can also be upgraded with a user code 918. The generation unit GKM 915 generates | a GKM of GKM signal and provides the same to a GKM decoding unit 916 of the smart card 905, where the decoding unit GKM 916 obtains as an additional input a user key 917. MLS beyond this, the rights 919 can be provided towards a generating unit ??? 920 which generates an EMM signal and provides same to an EMM decryption unit 921. The EMM decoding unit 921 located in the smart card 905 is coupled with a rights list unit 913 which supplies the ECM 908 decoding unit with corresponding control information. ECVI stands for Rights Control Messages, KMM stands for Key Management Messages, GKM Group Key Messages, and EMM Rights Management Messages. 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 transmitted content 901 is encrypted under the control of the system (CA) 900. At the receiver, the content is decrypted before decoding and interpreting whether access is granted by the CA 900 system.

The CA 900 system uses a hierarchy by layers (see Figure 9). The CA 900 system transfers the content clearing key (Control Word C 906, 909) from the server to the client in the form of an encrypted message, called ECM (Rights Control Message). The ECMs are encrypted using an authorization key (AK) 910. For security reasons, the CA 900 server can renew the authorization key 910 when issuing a KMM (Message Management of Keys). A KMM is in fact a special type of EMM (Rights Management Message), but for a greater claridc.d the term KMM can be used. The KMMs are also encrypted using a key that for example can be a group clcive (GK) 914, which is renewed by sending a GKM (Group Key Message) which is again a special type of EMM. The GKMs are then encrypted with the user key (UK) 917, 918, which is a fixed single key incorporated in the smart card 905 and known only by the provider's CA 900 system. The authorization keys and group keys are stored in the smart card 905 of the receiver. Rights 919 (for example observation rights) are sent to customers in the form of an EMM (Rights Management Messages) and stored locally on a secure device (smart card 905). Rights 919 are coupled to a specific program. A list of Rights 913 provides access to a group of programs that depend on the type of subscription. The ECMs are only processed in keys (Control Words) by the smart card 905 if a right 919 is available for the specific program. EMMs of rights are subject to an identical layered structure as to KMMs (they are not repressed in the Figure). In an MPEG2 system, the encrypted content, ECMs and EMMs (which include the KMM and GKM types) are all multiplexed in a single MPEG2 transport stream. previous description is a generalized view of the system In a digital video transmission, only the encryption algorithm, the pair / inpar control word structure, the global structure of ECMs and EMMs and their references are defined. The detailed structure of the system CA 900 and the manner of the payloads of ECMs and EMMs in which they are encoded and used are from specific suppliers.

Also the smart card is from a specific provider, However, from experience it is known that many providers essentially follow the structure of the generalized view of Figure 9. Next, the topics of DVB encryption / decryption will be discussed. The encryption and decryption algorithm applied is defined by the DVB standardization organization. In At the beginning, two possibilities of encryption are defined, that is, encryption of the PES level and encryption of the TS level. However, in real life the TS level encryption method is mainly used. The encryption and decryption of transport flow packets is done based on packets. This means that the encryption and decryption algorithm is restarted each time a new transport flow packet is received. Therefore, the packets can be encrypted and decrypted individually. In the flow (transport, encrypted and unformatted packets are mixed because some parts of the flow are encrypted (for example, audio / video) and others are not (for example, tables), even within a part of the flow. (for example: video) encrypted and unformatted packets can be typed in. Next, with reference to Figure 10, an encrypted transport stream packet DVB 1000 will be described.The 1000 stream packet has a length 1001 of 188 Bytes and comprises three portions. A packet header 1 0 02 has a size of 1 0 03 of 4 bytes. Subsequent packet header 10 0 2, an adaptation field 1 004 can be included in the flow packet 1 0 0 0 After that, an encrypted packet payload DVB 1005 can be sent, Figure 11 illustrates a detailed structure of the transport stream packet header 1002 of Figure 10. The transport stream packet header 1002 comprises a synchronization unit (SY C) 1010, a transport error indicator (TEI). , for its acronym in English) 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 transport priority, a packet identifier (PID) 1013 used to determine the packet allocation, a transport selection control (SCB) 1014 is used to select the CW that it is necessary to decrypt the transport flow package, an adaptation field control (AFLD) 1015, and a continuity counter (CC) 1016. Thus, Figure 10 and Figure 11 show the MPEG2 1000 transport stream packet that has been encrypted and which comprises different parts: Package header 1002 is unformatted. It works to obtain important information such as a packet identifier number (PID), the presence of an adaptation field, selection control bits, etc.

Adaptation field 1004 is also found without format. It may contain important information of incronization such as PCR. The encrypted packet payload DVB 1005 contains the actual program content that may have been encrypted using the DVB algorithm. In order to select the correct CW that is necessary to decrypt the transmitted program, it is necessary to parse the transport flow packet header. A schematic analysis of this header is provided in Figure 11. An important field for the decryption of the transmitted program is the selection control bit field (SCB) 1014. This SCB field 1014 indicates which CW the decryptor must use to decrypt the transmitted program. It even indicates whether the payload of the packet is encrypted or unformatted. For each new transport flow package, this SCB 1014 should be parsed as it changes over time and can change from packet to packet. Next, some aspects related to trick-play on completely encrypted flows will be described. The first reason why this is an interesting aspect is that the trick-play in fully encrypted and unencrypted streams are the two extremes of a range of possibilities. Another reason is that there are applications in which it may be necessary to register completely encrypted flows. In that way, it would be useful to have a technique at hand to develop a trick-play on a completely encrypted flow. A basic principle is to read a sufficiently large data block from the storage device, decrypt it, select an I-frame in the block and build a trick-play flow with it. Tcil system 1200 is represented in Figure 12. You. Figure 12 shows the basic principle of a trik-play on a completely encrypted stream. For this purpose, data stored on a hard disk 1201 is provided as ur .. transport stream 1202 to a decryptor 1203. In addition, 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 decryptor 1203. With the use of the Control Words, the decryptor 1203 decrypts the encrypted transport stream 1202 and sends the decrypted data to an I-frame 1205 detector and filter. From there, the data is provided to v.a insert unit of empty frame P 1206 which transports the data to a top box of configuration 1207. From there the data is supplied to a television 1208.

Below, some aspects will be mentioned with respect to the question of what a record contains. ?? perform a record of a single channel, the record must contain all the data required to play the recording of the channel in a final stage. One can resort to recording almost everything on a certain transponder, but in this way one would record much more than what is needed to reproduce the program intended to record. This means that both broadband and storage space would be wasted. So instead of this, only the packages really needed should be recorded. For each program this means that one must record the total of MPEG2 mandatory packages such as PAT (program association table), CAT (conditional access table), and obviously for each program the video and audio packages as well as the PMT (ta program correspondence) that describes which packages belong to a program. Additionally, the CAT / PMT can describe CA packages (ECMs) necessary for the flow desencrpción. Unless the recording is made without formatting after the description, the ECM packages have to be recorded as well. If the recording made does not consist of all the packages of the complete multiplex, the recording becomes a so-called partial transport flow 1300 (see Figure Additionally, Figure 13 illustrates a transport flow complete 1301. The DVB standard requires that if a partial transponte stream 1300 is played, all the usual DVB mandatory tables such as NIT (network information table), BAT (bouquet association table) etc. They are the -iminated. Instead of these tables, the partial flow should have SIT (selection information table) and DIT (discontinuity information table) inserts, Next, with reference to Figure 14 through Figure 32, systems will be described which have the ability to process a stream of encrypted data in accordance with exemplary embodiments of the invention. It is emphasized that the systems described below can be implemented in the frame of, and in combination with any of the systems described with reference to Figure 1 through Figure 13. Next, some aspects related to the treatment with ECMs will be described. (Rights Control Messages). Bringing up the next block during trick-play can mean jumping backwards in the flow. Then, it will be explained that this may not only be the case for a trick-play rollback but also for a trick-play advance at moderate speeds. The situation for forward trick-play u coni with forward jumps and for trick-play with backward jumps inherently will be explained later. Specific problems can occur caused by the fact that the data must be decrypted. A conditioned access system can be designed for a transmission. In a normal reproduction, the transmitted flow can be reconstructed with original times. But trick-play can have severe implications for the handling of cryptographic metadata due to changed times. The data can be compressed in time due to a trick-play, but the latency of the smart card can remain constant.

To create a trick-play flow, the selected data blocks can run through a decryptor. This decryptor needs the Control Words used in the encryption process to decrypt the data blocks. These Control Words can also be encrypted and stored in the ECMs. In a box of higher normal configuration (STB), these ECMs can be part of the program to be tuned. A conditional access module can extract the ECMs, send them to an intelligent card, and, if the card has rights, or an authorization to decrypt these ECMs, it can receive the decrypted Control Word from it. Control words usually have a relatively short lifetime, for example, approximately 10 seconds. East The period of life can be indicated by the Selection Control Bit (SCB) in the transport flow packet headers. If this changes, the next Control Word has to be used. This change or switching SCB is indicated in Figure 14 by a vertical line and with a reference number 1402. With reference in Figure 14, particularly two scenarios or two types of flow can be distinguished: According to a type I flow shown in a lower arrow 1401 in Figure 14, two Control Words (CWs) are provided by Rights Control Message (ECM). According to a type II flow shown in a top arrow 1400 in Figure 14, only one Control Word (CW) is provided by Rights Control Message (ECM). Figure 14 illustrates the two data streams 1400, 1401 comprising periods or segments arranged subsequently A, B, C designated with the reference number 1403. In the scenario illustrated in the upper arrow 1400 of Figure 14, essentially a Word of Control by corresponding ECM is provided. In contrast to this, in the lower arrow 1401, each ECM comprises two Control Words, ie the control word that is related to the current period or ECM, and additionally the Control Word of the subsequent period or ECM. Of that Thus, there is some redundancy concerning the supply of the Control Words. In the short period of life, the elements of the decryption information may be transmitted several times, so tuning an average channel during the average life of such a Control Word does not mean that it will be waiting for the next Control Word. The conditioned access module can only send the first unique ECM it finds to the smart card to reduce or minimize the traffic to the card, since it can have a rather slow processor. This shows that there may be a trick-play limitation on encrypted flows. There may be an implicit upper speed limit, which comes from the limited speed of the processing capacity of the intertrend card. In trick-play, the control word's life period of 10 seconds can be compressed with the trick-play speed factor. It is also possible to say that the frequency of sending ECMs to the smart card is multiplied with the speed factor. Sending an ECM to a smart card and receiving decrypted Control Words can take approximately half a second. With a period of life for each Control Word of 10 seconds, the maximum trick-play speed can be limited up to 20 times. To reach these 20 times, you can be sure that the NDEs are sent or supplied at the moment! Right. In reverse, they must be sent in some reverse order. This means that it may not be possible to just depend on their positions in the original flow. The way in which Control Words are packaged in an ECM can be from a specific provider and is particularly different for type I flow and type II flow, as depicted in Figure 14 CW A designates the CW that was used for encrypt period A, CW B designates the CW that was used to encrypt period B, and so on. The transmission time axis is plotted horizontally. The ECM A can be defined so that it is the ECM that is present during the greatest art of period A. It can be seen that, in that case, the ECM A carries the CW for the current period A and for the flow type I additionally for the next period B. In general, an ECM can carry at least the CW for the current period and could carry the CW for the next period. Due to the zapping, this can probably be true for all or many suppliers. In continuation, some aspects related to the advance trick-play will be discussed. Subsequently, it will be described how omitting some of the I-frames can generate a very high speed of advance (fast.In trick-play, the data and therefore the SCB period can be compressed by an amount equal to the speed factor. It can be assumed that nothing special is done and the STB is left to use the original ECMs incorporated in the flow. For a type I flow, this may not be a problem as long as the compressed SCB period is larger than the latency of the smart card because, for example, the ECM B also supports the CW for a period C (see Figure 14). ). Therefore, the total of period B may be available for the decryption of CW C that must be available at the beginning of a period C for the decryption of the video data. This can result in a maximum trick-play speed equal to the ratio of the SCB period and the latency of the smart card, by employing 20x. However, a CW C may not be present in ECM B bara a type II flow, and as a result this method may fail for a type II flow. Before continuing, you should provide more information about a decryptor and how you can handle CWs. The decryptor can contain two registers, one for CW "even" and one for "odd". "Par" e "odd" does not have to mean that the values of the CWs by themselves are even or odd. The terms are particularly used to distinguish between two subsequent CWs in the flow. Which CW should be used for the decryption of a package is indicated by the SCB in the package header. Thus the CWs used to encrypt the flow are alternately between odd and even. In the Figure 14 this means that, for example, CW A and CW C are odd, while CW B and CW D are even. After the decryption by the smart card, CWs can be written for the corresponding registers in the decrypter that overwrites the previous values, in accordance! as indicated in Figure 15. Figure 15 illustrates the two registers 1501, 1502 that contain CWs pairs (register 1501) and that contain odd CWs (register 1502). Additionally, the smart card latency 1500, which is a time required by the smart card to retrieve or decrypt a CW from an ECM, is illustrated in Figure 15. In! In the case of type I flow, each ECM carries two CWs and as a result both registers 1501, 1502 can be overwritten after the ECM decryption. One of registers 1501, 1502 is active and the other is inactive. What is active depends on the SCB. In the example, the SCB will indicate during period B that the even register 1501 is the active one. The active record can only be overwritten with an identical one that already carries because it is still required for the decryption of the rest of that particular period. Therefore, only the inactive record can be overwritten with a new value.

Performing a detailed review in period B in trick-play. Assuming that an ECM is sent to the smart card at the start of this period so that the SCB 1402 switch is crossed. The question is, which ECM could then be sent to the smart card? This ECM should carry the CW C to ensure a description within time by the smart card for use at the start of period C. It could also carry a CW B without disturbing the correct availability of the CWs in the decryptor. Looking again at Figure 14, it can be seen that for the Type I flow this means sending the ECM B and for the type II flow the ECM C at the start of a period B. In general, the current ECM can be sent in case you carry two CWs, and a period in advance if you carry only one CW. Sending an ECM a period in advance can be contradictory to the incorporated ECMs, so the latter has to be removed from the flow in that case. For a more generalized approach it may be preferred that the original ECMs are always removed from the flow by the trick-play generation circuit or software. An exemplary way to read data blocks, jump forward in the flow and send ECMs is indicated in Fig. 16. Figure 16 shows an ECM handling in a fast forward mode. ?? a plurality of subsequent periods 1403 separated by SCB switches 1402, a plurality of data blocks 1600 are reproduced, wherein a switch 1601 occurs between different blocks of data. For type I flow, an ECM B is sent on a boundary between periods A and B. For type II flow, an ECM C is sent at a boundary between a period A and a period B. Additionally, according to the flow Type I an ECM C is sent at a boundary between a period B and a period C. For a type II flow, an ECM D is sent at a boundary between a period B and a period C. For ECMs it must be available for a trick-play at the correct time, the ECMs can be stored in a separate file. In this file it can also be indicated to which period an ECM belongs (which part of the recorded flow). Packages in the MPEG stream file can be numbered. The number of the first packet of a period (switching SCB 1402) can be stored together with the ECM for this same period 1403. The ECM file can be generated during the recording of the flow. An example of an ECM file is shown in Figure 32. The ECM file is a file that can be created during recording. In the flow, the ECM packets may be located which may contain the Control Words required to decrypt the video data. Each NDE it can be used for a certain period, for example 10 seconds, and can be transmitted (repeated) several times during this period (for example 100 times). The ECM file can contain every first new ECM of each period. The ECM data can be written within this file, and can be accompanied with some metadata. First of all, a serial number (a count of up to 1) can be given. As a second field, the ECM file can contain the position of the SCB switch. This can designate the first packet that this ECM can use to decrypt its content correctly. Then the time position of this SCB commutation can follow as the third field. These three fields can be followed by the same ECM packet data of which only the first bytes are represented in Figure 32. The differences between the ECMs are further lowered in the payload and are not visible here. With the use of the SCB switches stored in the ECM file, it can be easy to detect if the switching is crossed even if it were during a jump. To send the correct ECM, it may be required to know if the ECMs contain one or two CWs. In principle, this is not known because it's from a specific and secret provider. However, this can easily be determined experimentally by sending the ECMs at various times and observing the results in the deployment. An alternative method that is particularly appropriate to be implemented in the storage device itself is as follows. Send a single ECM to the smart card at the time of a SCB switch, decrypt the flow and check for the PES headers when two periods come. With a PES header by GOP, they exist! around 20 PES headings in each period. The positioning of a PES header can be easily detected because a PLUSI bit in the raw header of the packet can indicate its presence. If the correct PES headers are only found during the first period (after the latency of the smart card), the ECM contains a C. If they are also found during the second period, it contains two CWs. Such a situation is represented in Figure 17. Figure 17 illustrates a situation for a CW detection for two CW detections. According to what can be observed ::, different periods 1403 of encrypted content 1700 are provided. With an intelligent card latency 1500, an ECM A can be decrypted to generate corresponding CWs. By decrypting the encrypted content 1700, the decrypted content 1701 can be generated. Additionally, the headers PES 1702 are shown in Figure 17, that is, a PES A header in a period A (left) and a PES B header in a period B (right).

The] area 1703 of a period B for a CW in Figure 17 indicates | that the data is decrypted with the wrong keys and therefore they are encoded. This verification could be done during the recording, in which case it will be taken for example 20 to 30 seconds. It could also be remapped offline and, due to two packages indicated by PLUSls (one in each period) would have to be verified, it could be quickly. In the likely case that adequate PES headers are not available, the image headers could be used instead. In fact, any known information can be useful for detection. In any case, one / two CW indications can be stored in the ECM file. Up to now it has been assumed that a jump in the flow would cross a maximum SCB commutation. If it were crossed more than once, the described method would have to be modified. A new scheme to send ECMs would be necessary in such a case. Figure 18 represents this situation. Figure 18 illustrates hops through two SCB switches 1402. According to the scheme of Figure 18, an ECM A is sent at the beginning of a period A in the type I flow frame. In the type II flow frame, at the start of period A, the ECM B is sent. Additionally, according to type I flow, the ECM C is sent at the beginning of the period B, and in the flow frame type II, the ECM D is sent at the beginning of period B. First of all, it is requested to look ahead to know if the next jump will be on one or two switches SCB 1402. This it is necessary to select the ECM containing the CW to decrypt the data that follows the next hop according to the ECM to be sent to the smart card. But the data after a jump of two SCBs are encripates with the same type of CW (even or odd) according to the data before the jump. Sending a: _1CM containing the necessary CW after the overflow jump will automatically enter the active record in the decryptor with a different value, thus leading to the loss of data in the current period. Thus the method fails and a jump on two SCB switches is not possible. This can also be a limiting factor for maximum trick-play speed. Assuming for a moment that the hop size is at its maximum of a SCB period, then the original time distance of for example 10 seconds can be compressed for the deployment time of a trick-play GOP. With IPPP, this can be equal to 160 ms in Europe. This is a trick-play speed factor of around 60x. Due e. that one is not a hopping time but a fixed number of packages, the maximum hop size could be translated to for example 5 seconds. Still the latency or in other words the performance of the smart card can be the dominant factor that limits the speed of trick-play. Next, some aspects related to backward trick-play will be described. In | a backward trick-play, a backward jump in the flow file is performed. Data belonging to a frame is read in a forward mode, but as backward playback is created, the next image read will be a previous image in the stream. The way in which data blocks can be read and in which jumps can be made is shown in Figure 19.

Figure 19 shows a time point 1900 in which an ECM A is sent, and shows a time point 1901 in which an ECM B is sent. The specific ECM problems have already been discussed previously for an advance trick-play. Next, we will discuss what will happen for a setback. Observing in Figure 19, the following can be detected: The CW to decrypt the data from a certain period must already (still) be present in the sencr iptador when this period is entered.

A previous normal playback period (following trick-play period) is always introduced during a backward jump. - - The ECM carrying CW B must be sent when the period C is used to allow the latency of the smart card at the highest possible trick-play speed. - This ECM can then also carry a CW C without any disturbance of the subsequent decryption process of a C period (CW C in the decryptor is overwritten by a CW C). And so in general, when a period enters the reverse direction, an ECM can be sent that carries the CW of the previous normal reproduction period and that can carry the CW of the period that has just been introduced. Observing in Figure 14, it can be seen that when a period is entered in the reverse direction, an ECM B has to be sent to the smart card for type I flow as well as for type II flow. In general, the ECM must be sent from the previous period to the one entered. Observed in Figure 19 again, it can be seen that a SCB 1402 confutation can be crossed more than once and that it is possible to enter a period twice in the reverse direction. To determine on which of these occasions the ECM can be sent, it must be evaluate what happens when the period C is introduced in the flow file to which it will jump and the position of the SCB 14 02 confutation as it is stored in the archive]) ECMs are known. If the distance from the jump I destination to the switching SCB 1 4 0 2 is smaller than the block size, the period can be entered a second time. As:, in general, an ECM could be sent at the start of the last jump within a period. This is the ECM of the period before the one just entered. This is indicated in the Figure 19 It is also possible to say that this ECM can be sent in a jump if the boundary of the two periods is located between the ends of the blocks before and after the jump. This could omit the need to detect if the period will be entered twice and you can omit the insertion of ECM j | > for jumping within a period. Next, some aspects related to a moderate speed advancement trick-play will be discussed. Figure 16 shows an ideal solution for a forward reproduction, where subsequent data blocks do not overlap. But if the trick-play speed is moderate, it is decilr I-frames are not omitted, some overlaps may occur, if the normal playback stream is encrypted and the location of the I-frames is unknown. Figure 20 shows this effect.

Particularly, Figure 20 shows a point of time 2000 in which an ECM C is sent for a type I flow and a NDE ECM sent for a type II flow, and shows a time point 2001 in which an ECM B is sent for a type I flow and an ECM C is sent for a type II flow. It has been mentioned above that ECMs can be sent at the junction of a SCB 1402 switch. Now in an inverted sense it is possible for a specific switch 1402 to be crosswise twice in the trick-play direction. For identical reasons, the ECM should be sent the last time switch 1402 is crossed. Also here, this is easily detectable. Again the block size and the distance between the destination jumps are known from which it can be derived! if the back flips are made. If so, and if the position of the known SCB switching 1402 is crossed during the backward jump, this switching SCB 1402 will be crossed again. For a general advance trick-play, the ECM should be sent the last time a 1403 period is entered. In other words, an ECM can be sent when a new period is entered unless SCB 1402 is placed after the next destination hop. Subsequently, some aspects related to sending the ECMs will be discussed. In the previous previous discussion about the management of NDEs, it was mentioned that NDEs should be sent to the Smart card. Here, we describe how a trick-play stream sjLn format is constructed from a normal playback stream completely encrypted. Since it will be unformatted, no ECMs are needed in the trick-play flow that meets MEPG by itself but may be necessary to build it. The trick-play generation, which a decryptor, can be part of a storage device. If a smart card is also present on this device, sending the ECMs could only be the ones mentioned, the ECM is sent to the smart card at the correct time after the transformation in the smart card interface format. But in theory this format may be unknown because | The commands to the card can be from a specific and secret provider. Thus the ECM must be sent to the security device to which the smart card is connected. If the smart card is not present in the same storage device, some secure communication with an external smart card, for example in the STB, must be established. However, for reasons of a more general approach, another option could be preferred in which the necessary ECMs are incorporated into the transport flow blocks that are sent to the conditional access module (which includes the decryptor) for a I-frame extraction without format. The original incorporated ECMs can be removed from this flow. Sending a NDE at a certain moment means that it has to be inserted at that point in the flow to the decryptor. These ECMs could also be repeated regularly as in a normal transmission signal but this is not really necessary and therefore could complicate the trick-play generation. Next, some aspects related to switching between normal playback and trick-play playback will be described. Switching between normal playback and trick-play may result in some special effects. A real behavior may depend on the availability of the Words; Control (C s) and therefore the management and processing of ECMs (Rights Control Message). Cor. Referring to Figure 21, a 2100 trick-play system will be unwritten. The trick-play system 2100 includes a storage device 2103, a trick-play generator 2101 and a receiver 2102. The storage device 2103 stores data to be reproduced which are supplied as a stream of | transport 2105 to a decrypting unit 2106 and to a switching unit 2108 of the trick-play generator 2101. The switching unit 2108 can switch between a normal play mode (NP) and a trick-play (TP) mode.

By means of a control unit 2109, the speed of a desired trick-play can be selectively inputted as well as the fact whether normal reproduction or trick-play is desired. This information is supplied from the control unit 2109 to the storage device 2103. The control unit 2109 can be, for example, controlled by a user by means of a user interface. Additionally, control unit 2109 provides data or commands input to a trick-play flow construction unit 2107 and to an ECM memory unit 2112. The storage device 2103 transmits the feed flow not only to the decrypting unit 2106 and to the switching unit 2108, but also provides ECM data stored in an ECM file 2104 to an ECM memory unit 2112. The ECM memory unit 2112, which also receives the parameters from the control unit 2109, provides the flow construction unit trick-pi.a and 2107 and an intelligent card interface unit 2111 with ECM data. Additionally, the intelligent card interfcLse unit 2 1 1 1 is adapted to communicate with a smart card 2 1 1 0. The smart card 2 1 1 0 generates Control Words (CW) and I provides the Control Words by means of the smart card interface unit 2111 to the decrypting unit 2106.

In a normal reuction mode, the switching position of the switching unit 2108 is the same as that shown in Figure 21. In this mode of operation, the transport flow 2105 is directly ided to the receiving unit 2112. However , when a trick-play mode is selected, the switching will go to the other position, so that the transport stream 2105 will be essed by the trick-play flow construction unit 2107 which will ide trick-play data to the receiver 2102 , more particularly to a decrypting unit 2113 of the receiver 2102 and to an ECM extractor unit 2116 of the receiver 2102. Uria ECM extractor unit 2116 will supply ECMs to a smart card interface 2117 that is communicatedly coupled to a smart card 2118. In response to the ECMs, the smart card interface 2117 ides the decrypting unit 2113 with the Words of Control as decryption information. After the decrypting unit 2113 has passed, the data is transmitted to a decoder / translator unit 2114 where the data 2115 can be transmitted to a display unit (not shown). As shown in Figure 21, there are two particular aspects that have to be considered. The first is the effect on the 2102 receiver that can decrypt, decode and translate a signal that is switched between normal playback and trick-play. The second is the effect of switching in relation to the trick-play generator 2101. Next, the receiving unit 2102 will be described further. The trick-play flow generated in accordance with the techniques described here can be a raw stream! . In this case, a decryption of the ttrick-play flow in the receiver 2102 is not necessary and the MPEG decoding can start immediately after switching to trick-play. Next, the trick-play generator 2101 will be described further. The trick-play generator 2101 can decryptify the flow for the purpose of selecting the I-frames in format and constructing a trick-play flow therefrom. This ess should start as soon as possible after switching to trick-play. Among others, the number of CWs per ECM influences this. This information is considered in a way that is known (for example from the CPI file, see Figure 4 and corresponding description), because it is also necessary for the continuous trick-play generation. Next, a particular switching scenario from trick-play to normal playback will be described. E: special effects, which may occur during a switch from trick-play to normal playback, they are described here. Again, a distinction must be made between the trick-play generator 2101 and the receiver 2102. During a switch to normal reuction, the trick-play generator 2101 can simply stop its operation. Thus, special measures may be necessary in relation to this trick-play generator. But as will be explained below, the trick-play generator 2101 can ime the switching effect on the receiver 2102 by taking some special actions particularly at this point. During switching to the normal encrypted playback stream, some special effects may occur in receiver 2102. It may be apriate to distinguish between two situations, i.e. the use of individual decryptors or a common decryptor by receiver 2102 and the trick-pLay generator 2101. Next, a scenario with individual decryptors will be described. This situation can occur if the receiver 2102 and a generator 2101 are in separate boxes or boxes connected by means of a digital bus, but this configuration can also be used when both are in the same box (see Figure 21). The switching lem and some solutions are explained below. During switching from an unformatted trick-play to the normal encrypted playback stream, you must Start a correct decryption as soon as possible. Due to the fact that the ECM flow is interrupted during the unformatted trick-play, it could take a while before the user has the ability to observe the normal playback video again. This situation is represented in Figure 22 for a trick-play speed of 4x advance. Figure 22 shows a sequence of periods A and B, where A is related to a period with ECMs with a table ID of 0: c80, and B is related to a period with ECMs with table ID 0x81. An upper arrow 2200 shows a sequence of blocks A and B. A lower arrow 2201 shows a sequence of blocks A and B with two normal reproduction portions 2202 flanking a trick-play portion 2203. The first ECM after switching to a Normal playback 2202 might not be extracted from the stream and then retransmitted to the smart card for processing. The same ECM can be transmitted repeatedly, and a switch in the table ID from 0x80 to 0x81 or vice versa can indicate the change to a new ECM. To limit the traffic to the smart card, only the first ECM of a new series according to the detected of the table ID can be transmitted on the smart card. In the event that the last ECM extracted before switching to a 2203 trick-play and the first ECM in | the flow after switching back to a normal play 2202 are of the same type (both 0x80 or 0x81), this first ECM can be not extracted and processed. In Figure 22, the last ECM before, and the first ECM after a trick-play are both of type B that are ECMs with a table ID of 0x81. Without additional measures it could be required to wait until the next ECM of a different type (A in the example) is found which may take a while, for example 10 seconds. During this period, there may be a non-correct description and therefore a non-MPEG decoding and the display of the normal reproduction stream 2202. Next, four possible solutions for the described problem will be explained. Solution 1 Some measures can be taken to avoid an excessive switching time from a 2203 trick-play to a 2202 normal reproduction. A first option is to introduce a time-out function for ECMs in the receiving STB In a normal situation , the ECMs are never separated more than for example 800 ms. If ECMs are present in the flow for several seconds, the STB can be brought into a state where the first found ECM will be sent to the smart card. This ensures that the first ECM after the raw format trick-play will be processed.

For type II flow, sometimes an additional delay can be introduced when the smart card is busy. In such a scenario, it could happen that the smart card is occupied for some time which may obstruct]: timely processing of the next ECM. Solution 2 The storage device containing the trick-play generator can also force the use of the first ECM of the normal reproduction stream 2202. It is': a situation is shown in Figure 23. The type of the last ECM (0x80 or 0x81) before switching to trick-play (for example, fast forward) is remembered. During a switchover to a normal play 2202 again, it could be compared to the first ECM type in the normal play stream 2202. If identical, the ID c.e table of the first ECM (s) in the normal playback stream 2202 is changed to the other value, ensuring that it will be sent to the smart card by the receiver. An arrow | 2300 indicates inverting a table ID. The additional switching delay can be equal to the solution 1 described above. Solution 3 In this case, the trick-play generator adds an ECM at the end of the trick-play flow (for example, fast forward) at the moment the commutation command is received. From ECM file, the trick-play generator knows what the first ECM of the normal reproduction stream 2202. This then inserts this ECM at the end of the trick-play flow 2203 but with a table ID opposite to the remembered one. In Figure 24, the ECM for the first part of the normal reprinting flow 2202 is type B and the remembered type of the last ECM before trick-play is also B. Thus the ECM required to decrypt the normal reproduction flow 2202 directly following trick-play 2203 is taken from the ECM file and inserted at the end of the trick-play flow 2 2 03 but with a table ID changed to A. This ensures that this ECM is sent to the smart card just before the moment switching. The trick-play generator could insert a frozen image 2 4 0 0 after this ECM by saying 0. 5 to 1 0 seconds before the actual switching to a normal 2202 playback for the purpose of compensating the latency of the smart card. Even though the example described is related to fast forward, this could also have been in a fast reverse. Solution 4 A fourth option is to have ECMs inserted in the trick-play flow by the trick-play generator. Although it is not necessary for the processing of the trick-play data by the receiver, this processing is not disturbed in any way. trick-play This depends on one / two CW situations. It is irrelevant whether this ECM is processed by the smart card or not because in any case the content of the decryptor records will not be changed. So where the switching point is located in the current period, the decrypter in the receiver will always carry the CW of the current period, and the CW for the next period will certainly be available before crossing within this period . Therefore, the correct decryption of the normal playback stream in the receiver can start immediately after switching to normal playback and will not be interrupted. Subsequently, a transition from a backward to a normal playback will be discussed. Ta} , the situation is depicted in Figure 26. Figure 26 shows a transition 2503 from a backward trick-play mode (jumps between subsequent data blocks 2500 are illustrated by arrows 2502) to a normal playback mode 2501. Particularly, the Figure 26 shows a time point 2600 in which an ECM B is sent and shows a time point 2601 in which an ECM C is sent. Details for a type I flow and for a type II flow can be taken from the table shown in Figure 26. In this case, the CW of the next normal reproduction period will never be available at the time of commutation. The decryptor in the receiver will carry the CWs for the current and next trick-play period, but these are the current and previous normal playback periods. It is assumed that transition 2503 occurs anywhere at a midpoint of the current period C. The last ECM received by STB before the transition time is ECM B of the previous normal production period. The first ECM received after the transition will be an ECM C of the current period. This will be within approximately 100 ms. As this ECM C has a different table ID than the previous ECM B, it will be transmitted on or to the smart card and processed. Thus a correct decryption can start immediately. But this decryption can be interrupted if the switching point is near the end of a period. The type I flow can have a space in the ECMs of approximately one second at the end of the period. Switching during this interval means that an ECM C will not be found and that ECM D is the first normal reprodup ECM after the last trick-play ECM which is an ECM B. Because ECMs B and D have the same ID of table, the ECM D will not be processed and the normal reproduction flow will be interrupted for a full period. Thus the normal reproduction point at which it can be jumped must at least be found before the space in the ECMs at the end of the period. If the switching point is in the Last (second of a period, it may be appropriate to jump back a little in the normal reproduction flow.) The effect for type II flow may be more or less identical, In this case, ECM D may be sent, for example, already during the last 600 ms of a period, so a commutation in this interval also means that an ECM C is ignored with the same effect as described above, so here it is appropriate to jump to a normal starting point of reproduction more than 600 ms before the end of the period In fact, the same technique can be applied in both cases Even if another effect to be considered, according to the above mentioned, the normal reproduction time remaining in the current period should allow the access of an ECM of this period, but additionally this should ensure that this ECM is processed, however, especially at high trick-play speeds, the smart card could still be busy with ECM processing B. During this busy time, the incoming ECMs can not be sent to the smart card and could easily be discarded. There is no guarantee that they will be stored for further processing. The time that the smart card will still be occupied may depend on the trick-play speed and the position of the switching point in the period. But in any case it will not be greater than the latency of the smart card. So this latency could be added one second interval discussed above In gene: al, it is possible to say that the normal starting point of reproduction should be located minimally about two seconds before the end of the current period during switching from a backward to normal playback. Next, some aspects related to delays? of switching will be discussed. An additional I switching delay can be introduced by the decryption at the start of the normal playback stream. For previous solutions 1 and 2, this delay can be equal to the time until the first ECM is found in the normal reproduction flow plus the delay of the smart card. It will stop solution 3, it is only equal to the delay of the smart card, which is compensated by the unfolding of a frozen image. Solution 4 does not introduce any switching delay if it is implemented correctly, but there may be some change in the starting position of normal playback when coming from a backspace. Next, additional optimizations of the switching in relation to the MPEG will be explained. In order to have an image on the screen as fast as possible, there are also effects that are related to MPEG decoding. Assuming that the If the normal playback size can be started immediately, it may be appropriate to skip to the beginning of a GOP for the fastest MPEG decoder response. In the case of a flow consisting of only I- and P-frames, the decoder 3 can initiate with the I-frame that is the first in the GOP and can then continue with the P-frames that are referencing this I-frame. In the case that also the B-frames are present in the flow there is a decoding problem due to the rearrangement of the frames in the transmitted flow 3 (see Figure 3). The first B-frames found in the flow do not belong to the deployment GOP that started with the first I-frame that was built. In fact, they belong to a previous GOP and are not only referencing this I-frame but also a previously transmitted P-frame. This P-frame is not available when playback is started at the start of a transmitted GOP. This leads to an incorrect decoding of these B-frames and that corrupts the images at the start of the normal playback stream. In fact, it is not ideal to introduce a point for a transmitted MPEG stream that contains B-frames. The best available points are still the beginning of the plot. In the case of a blank format, it is possible to clean the start of the normal playback mode when removing! the first B-frames located between the I-frame and the next P-frame. However, this may not be possible in the case of an encrypted file where the locations of the B-frames may not be known.

In order to make the transmission at the flujp level as continuous as possible, the reading of a trick-play data block and the related generation and transmission of a trick-play GOP must be completed before a jump to a normal reproduction flow. AS] L it may be preferred to end the trick-play GOP and then jump to the start of a normal playback GOP. It could be unknown where this GOP starts, especially with encrypted flows. But in any case the trick-play generator can determine your jumping objectives in an optimal way. If the start of the GOPs is not known, optimization with respect to the MPEG is possible in any way. If on the other hand the start of the GOP is known from the CPI file, these will be used as possible jumping targets. The logical points to start a normal playback are the last trick-play objective jump before the commutation command or the first target is received after this command. In the case of the above solutions 1 and 2, a correct deseneripción of the normal reproduction flow can not start immediately at the entry point. First, an NDE 'of the normal reproduction flow itself has to be exurated and processed. This means that trick-play jump destinations can not be used. Therefore, these solutions are usually not preferred.

The I solution 3 will always send the ECM connected to the start of the normal playback stream and then wait for the latency of the smart card. This means that any destination hop can be selected as the starting point of the normal playback stream. The correct decryption of the normal reproduction flow starts immediately at this point. Solution 4 has the smallest switching delay from the point of view of the decryption. In this case, normal playback will not be started on the last trick-play jump target before the commutation command because it can lead to problems in certain situations. It can be assumed that at the moment that the commutation command is received, the end of the data block located in the boundary of period B and C is reached, as shown in Figure 27. The. Figure 27 shows a transition 2503 from a forward trick-play mode (jumps between subsequent data blocks 2500 are illustrated by arrows 2502) to a normal playback mode 2501. Particularly, the Figure 27 shows a time point 2700 in which an ECM D (CW D) is sent in the case of type II flow, or in which an ECM (CC and CW D) is sent in the case of a type I flow Somewhere in the beginning of period C, the ECM that will overwrite the CW B has already been sent to the card Then start a normal playback in the next jump destination trick-play. As a result of the optimization of the switching in relation to the MPEG, discontinuities in the MPEG stream can be significantly reduced at the time of switching. A first discontinuity is found in the PCRs and in the DTS / PTS. These discontinuities can be avoided during normal-to-trick-play switching but due to the time axis compressed in trick-play they can not be avoided during switching back to normal playback. Another discontinuity can be found in the continuity counter. Practical decoders can react to all these discontinuities. In any case it may be appropriate for them to be signaled to the decoder as much as possible. If the trick-play generator and the decoder are in a box this can be quite easy but otherwise the possibilities offered by the MPEG standard can be used. During a switchover between a trick-play reproduction and a normal :: production, there may also be a problem related to the Service Information tables (SI) that are found in the flow. It is relatively likely that at least some tables will be divided over multiple packages. This also means that one can switch when a table is only partially received / processed. Mandatory tables PAT (Program Association Table), CAT (Conditional Access Table) and PMT (Program Map Table) are created by the trick-play engine and incorporated into the trick-play flow. Other tables are not transmitted during trick-play. During a switch to trick-play, discontinuities can be avoided by some synchronization between the trick-play engine and normal playback. During a switch back to normal playback, the trick-play motor can not ensure the absence of discontinuities. The PAT / CAT PMT tables are complete within a trick-play GOP. Because the trick-play GOP is complete before switching to normal playback, incomplete tables are not found at the end of the trick-play flow. But this is not known where to jump into the normal reproduction flow in relation to the tables. Thus the first packets of tables found after switching could only contain the last part of a table. It is not known how an STB reacts to this but in fact one can expect such a packet to be discarded because a table header is needed for the parsing of the table. Thus, when acting according to what has been described, it could not be a real problem. Actually, all tables except the PAT / CAT / PMT should be removed from the recorded partial transport flow and an SIT (Selection Information Table) and DIT (Discontinuity Association Table) must be inserted, the SIT containing all the relevant SI data. The DIT indicates a discontinuity and could (should) be inserted at the switching point. A box that accepts a partial TS must understand the meaning of a DIT when it is present. In the DVB standard, it is claimed that: "whenever a partial bit flow discontinuity occurs, two transport flow packets belonging to an OxOOlE PID (DIT) should be inserted directly at the transition point, with no more packets The former must have 184 bytes of adaptation field that fill with a discontinuity flag, setting it to "1" (in order to ensure that it is in accordance with the MPEG-2 continuity count restrictions for transitions succession introduced in independent transmission / storage stages.) The second of these transport packages shall contain the "DIT" and shall not have such flag set to "1." Subsequently, a modality that has a common decryptor shall be described. common decoder by a receiver and a trick-play generator can be the case when the receiver and the trick-play generator are combined in a box. sharing violation because this decryptor At the same time, it will be described with reference to Figure 30, a | device 3000 for processing an encrypted data stream 3001 in accordance with an exemplary embodiment of the invention. The decryption messages, ie ECMs, are provided to decrypt each period 1403 of the encrypted data stream 3001, wherein each ECM comprises a number of Control Words (CW) as description elements. The device 3000 comprises a detection unit 3002 for detecting the number of Control Words per Rights Control Message (ECM). This number is two for the type I flow and is one for the type II flow. The encrypted data stream 3001 can be supplied to the detection unit 3002. The device 3000 further comprises a determination unit 3003 for determining a position to supply the ECMs in the sequence of the periods 1403, based on the detected number. For this purpose, the output of the detection unit 3002 which can encode a number of Control Words by ECM, can be supplied to the determination unit 3003. Additionally, the determination unit 3003 can be supplied with the flow of encrypted data 3001 and can modify the data flow incripts 3001 accordingly, to properly position or insert the ECMs.

The encrypted data stream (original or modified) can be supplied to a generating unit 3004 which can decrypt the encrypted data stream 3001 to condition the latter for a normal reproduction mode and reproduce it by means of a reproduction unit. 3005, or may alternatively generate a trick-play stream from the encrypted data stream 3001, for the purpose of executing a trick-play in the reproduction unit 3005. When the detection unit 3002 detects an ECM corresponding to a particular period 1403 includes two ECM Control Words (type I flow), then the determination unit 3003 can provide the zero ECM segments in advance. Alternatively, when the detection unit 3002 detects that the number of Control Words of an ECM is one, then the determination unit 3003 can provide the ECM with a period 1403 in advance (type II flow). Next, a device 3100 for processing an encrypted data stream 3101 in accordance with another exemplary embodiment of the invention will be described with reference to Figure 31. Again, the ECMs as decryption messages can be conditioned to decrypt each period 1403 of the flu; or encrypted data 3101. The device 3100 comprises a detection unit 3102 for detecting a switching from a mode of trick-play playback (for example a fast-forward mode) to a normal playback mode. A user can initiate such switching by operating a user interface 3103, for example by pressing a corresponding button. In such a case, the detection unit 3102 transmits this information to a determination unit 3104 and to a generation unit 3105. The determination unit 3104 is adapted to ensure, based on a comparison of a last ECM before the reproduction mode. trick-play and a first ECM in normal playback mode, that the first ECM in the normal playback play mode is sent to a smart card. The determination unit 3104 can modify the encrypted data stream 3101 accordingly. Ad;.tionally, the generation unit 3105 has the ability to selectively generate a trick-p-.ay reproduction stream or a normal reproduction reproduction stream that must < 5 is reproduced by a reproduction unit 3106. For this purpose, the generation unit 3105 is conditioned with the encrypted data stream 3101, and can receive control information from the detection unit. 3102 and / or from the determination unit 3104. The determination unit 3104 may be adapted to determine whether the first ECM in the normal reproduction mode should be processed to avoid excessive interruption of the a playback during a switchover from a trick-play generation mode to the normal playback mode. It should be noted that the term "comprising" does not exclude other elements or steps and that the article "a" or "an": or excludes a plurality. Also the elements described in association with different modalities can be combined. It should be noted that the reference signs in the claims should not be construed as limiting the scope of the claims. It is noted that in relation to this date, the best method known to the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.

Claims (1)

1. CLAIMS Having described the invention as above, the content of the following claims is claimed as property: A device for processing an encrypted data stream, wherein the decryption messages are provided to decrypt each segment of the encrypted data stream, wherein each decryption message comprises a number of decryption elements, wherein the device comprises a determination unit for determining a position for providing the decryption messages in relation to the sequence of the segments, characterized in that the device further comprises a detection unit to detect the number of decryption elements per decryption message, the number of decryption messages that is indicative of the position to be determined; wherein the determination unit further determines the position to provide the decryption messages in relation. to the sequence of the segments, based on the detected number of decryption elements per decryption message. The device according to claim 1, characterized in that the decryption messages are Messages, Rights Control and the elements of Disconnection are Control Words. The device according to claim 1, characterized in that a decryption message corresponding to a particular segment is provided in advance of the particular segment. 4. | The device according to claim 1, characterized in that the encrypted data stream is of a first type of encrypted data stream or the encrypted data stream is of a second type of encrypted data stream; the first type of encrypted data stream comprises a first number of decryption elements per decryption message which is equal to the number of decryption messages; and the second type of encrypted data stream comprises a second number of decryption elements per decryption message which is not equal to the number of decryption messages; the detection unit is further arranged to detect the first number of decryption elements per decryption message for the first type of encrypted data stream or to detect the second number of decryption elements per decryption message for the second type of encrypted data flow; and the determination unit is also arranged to determine the position to provide the decryption messages in relation to the sequence of the segments, based on the first number of decryption elements per message] | of decryption for the first type of encrypted data stream or based on the second number of decryption elements per decryption message for the second type of | encrypted data flow. 5.1 The device according to claim 1, characterized in that the determination unit is adapted, in case the detected number of decryption elements per decryption message is two, to provide the decryption message directly preceding the corresponding segment. 6. The device according to claim 1, characterized in that the determination unit is adapted, in case the detected number of decryption elements per decryption message is one, to provide in advance the decryption message a segment. The device according to claim 1, characterized in that it comprises a storage unit adapted to store the decryption messages in a file | separated . 8. The device according to claim 7, characterized in that the file is indicative of the assignment of each of the decryption messages to the segments correspbndlentes. The device according to claim 5, characterized in that it comprises two registers for storing the two decryption elements assigned to a decryption message, wherein, at the same time, only one of the two registers has the ability to overwrite data stored in the same. 10 The device in accordance with the claim 6, characterized in that it comprises two registers for storing decryption elements, wherein, at the same time, only one of the two registers has the capacity to overwrite data stored therein. 11 The device in accordance with the claim 1, because it comprises a control unit adapted to eliminate decryption messages originally provided from the encrypted data stream. 12 The device in accordance with the claim 1, because it is adapted to process a stream of e-encrypted data of video data or audio data. The device according to claim 1, characterized in that it is adapted to process a flow of encrypted data | s of digital data. 14 The device in accordance with the claim 1, characterized in that it comprises a reproduction unit for re-producing the decrypted data stream. 15 The device in accordance with the claim 1, characterized in that it comprises a generating unit for processing the data stream for reproduction in a trick-play reproduction mode. 16 The device according to claim 15, characterized in that the trick-play reproduction mode is one of], group consisting of a fast-forward playback mode, a fast-reverse playback mode, a slow-motion playback mode. , a frozen frame playback mode, an instant repeat playback mode, and a reverse playback mode. 17, The device according to claim 1, characterized in that it is adapted to process an encrypted MPEG2 data stream. 18 The device in accordance with the claim 1, characterized in that it is made with at least one of the group consisting of a digital video recording device and a network-enabled device and a conditioned access system and a portable audio player and a portable video player and a telephone mobile and a DVD player and a CD player and a media player based on hard disk and an Internet radio device, and a public entertainment device and an MP3 player. 19 A method to process a data flow the following method steps: determining a position to provide decryption messages in relation to the sequence of the segments characterized in that the method further comprises detecting the number of decryption elements per decryption message, the number of decryption messages that is indicative of the position to be determined; and wherein the step of determining further determines the position to provide the decryption messages in relation to the sequence of the segments, based on the detected number of decryption elements per decryption message. 21. A program element for processing an encrypted data stream, wherein the decryption messages are provided to decrypt each segment of the encrypted data stream, wherein each decryption message comprises a number of decryption elements, the program element , when executed by a processor, is adapted to control or carry out the method steps of: determining a position to provide the decryption messages in relation to the sequence of the segments characterized in that the method further comprises detjectar the number of elements of decryption by message | of decryption, the number of decryption messages that is indicative of the position to be determined; and wherein the step of determining further determines the position to provide the decryption messages in relation to the sequence of the segments, based on the detected number of decryption elements per decryption message.