WO2006114761A1 - A device for and a method of detecting positions of intra-coded frames in a data stream - Google Patents

A device for and a method of detecting positions of intra-coded frames in a data stream Download PDF

Info

Publication number
WO2006114761A1
WO2006114761A1 PCT/IB2006/051279 IB2006051279W WO2006114761A1 WO 2006114761 A1 WO2006114761 A1 WO 2006114761A1 IB 2006051279 W IB2006051279 W IB 2006051279W WO 2006114761 A1 WO2006114761 A1 WO 2006114761A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
frames
unit
frame
device
intra
Prior art date
Application number
PCT/IB2006/051279
Other languages
French (fr)
Inventor
Albert Rijckaert
Eric Moors
Roland Manders
Original Assignee
Koninklijke Philips Electronics N.V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/78Television signal recording using magnetic recording
    • H04N5/782Television signal recording using magnetic recording on tape
    • H04N5/783Adaptations for reproducing at a rate different from the recording rate
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/005Reproducing at a different information rate from the information rate of recording
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television, VOD [Video On Demand]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television, VOD [Video On Demand]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/414Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/4147Personal Video Recorder [PVR]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television, VOD [Video On Demand]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network, synchronizing decoder's clock; Client middleware
    • H04N21/432Content retrieval operation from a local storage medium, e.g. hard-disk
    • H04N21/4325Content retrieval operation from a local storage medium, e.g. hard-disk by playing back content from the storage medium
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television, VOD [Video On Demand]
    • H04N21/60Selective content distribution, e.g. interactive television, VOD [Video On Demand] using Network structure or processes specifically adapted for video distribution between server and client or between remote clients; Control signaling specific to video distribution between clients, server and network components, e.g. to video encoder or decoder; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6587Control parameters, e.g. trick play commands, viewpoint selection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television, VOD [Video On Demand]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00Record carriers by type
    • G11B2220/20Disc-shaped record carriers
    • G11B2220/25Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537Optical discs
    • G11B2220/2541Blu-ray discs; Blue laser DVR discs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction

Abstract

A device (1700) for detecting positions of intra-coded frames (201) in a data stream comprising a plurality of segments, each segment comprising a header unit (1002) and a payload unit (1005), wherein the device (1700) comprises a determining unit (1702) adapted to determine payload unit start indicators (1012) in the header units (1002), and a detection unit (1704) adapted to detect positions of intra-coded frames (201) in the payload units (1005) based on the determined payload unit start indicators (1012).

Description

A device for and a method of detecting positions of intra-coded frames in a data stream

FIELD OF THE INVENTION

The invention relates to a device for detecting positions of intra-coded frames in a data stream.

Beyond this, the invention relates to a method of detecting positions of intra- coded frames in a data stream. Moreover, the invention relates to a program element.

Furthermore, the invention relates to a computer-readable medium.

BACKGROUND OF THE INVENTION

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

US 2003/0081939 discloses a method for recording a digital broadcast program and time-based playback of a recorded broadcast program.

Since the reduction of storage space is an important issue in the field of audio/video players, audio and video data are often stored in a compressed manner, and for security reasons in an encrypted manner.

MPEG2 is a standard for the generic coding of moving pictures and associated audio and creates a video stream out of frame data that can be arranged in a specified order called the GOP ("Group Of Pictures") structure. An MPEG2 video bitstream is made up of a series of data frames encoding pictures. The three ways of encoding a picture are intra-coded (I picture), forward predictive (P picture) and bidirectional predictive (B picture). An intra- coded frame (I-frame) is related to a particular picture and contains the corresponding data. A forward predictive frame (P-frame) needs information of a preceding I-frame or P-frame. A bidirectional predictive frame (B-frame) is dependent on information of a preceding or subsequent I-frame or P-frame.

It is an interesting function in a media playback device to switch from a normal reproduction mode, in which media content is played back in a normal speed, to a trick-play reproduction mode, in which media content is played back in a modified manner, for instance with an increased speed ("fast forward"). For calculating a trick-play stream, a system may need to know the position of I-frames in a data stream to be processed.

OBJECT AND SUMMARY OF THE INVENTION It is an object of the invention to detect intra-coded frames in a data stream in an efficient manner.

In order to achieve the object defined above, a device for detecting positions of intra-coded frames in a data stream, a method of detecting positions of intra-coded frames in a data stream, a program element and a computer-readable medium according to the independent claims are provided.

According to an exemplary embodiment of the invention, a device for detecting positions of intra-coded frames in a data stream comprising a plurality of segments, each segment comprising a header unit and a payload unit, is provided. The device may comprise a determining unit adapted to determine payload unit start indicators in the header units, and a detection unit adapted to detect positions of intra-coded frames in the payload units based on the determined payload unit start indicators.

According to another exemplary embodiment of the invention, a method of detecting positions of intra-coded frames in a data stream comprising a plurality of segments, each segment comprising a header unit and a payload unit, is provided. The method may comprise the steps of determining payload unit start indicators in the header units, and detecting positions of intra-coded frames in the payload units based on the determined payload unit start indicators.

Beyond this, according to another exemplary embodiment of the invention, a computer-readable medium is provided, in which a computer program of detecting positions of intra-coded frames in a data stream comprising a plurality of segments, each segment comprising a header unit and a payload unit, is stored, which computer program, when being executed by a processor, is adapted to control or carry out the above-mentioned method steps.

Moreover, according to still another exemplary embodiment of the invention, a program element of detecting positions of intra-coded frames in a data stream comprising a plurality of segments, each segment comprising a header unit and a payload unit, is provided, which program element, when being executed by a processor, is adapted to control or carry out the above-mentioned method steps. The detection of positions of intra-coded frames in a data stream according to the invention can be realized by a computer program, that is to say by software, or by using one or more special electronic optimization circuits, that is to say in hardware, or in hybrid form, that is to say by means of software components and hardware components. The characterizing features according to the invention particularly have the advantage that a system for localizing I-frames in a data stream is provided in which information is derived from usually non-encrypted payload unit start indicators (PLUSIs) and used to evaluate the localization of intra-coded frames. The knowledge of I-frame positions in a data stream may be desired, since they can be advantageously used to provide certain functionalities, for instance in the frame of trick-play.

According to an aspect of the invention, PLUSIs are used as a source of information of a position of I-frames in a payload unit. In other words, a usually non- decrypted header unit of a data stream may be analyzed with respect to the occurrence of PLUSIs, which allows to determine in many cases the position and/or the length of intra- coded frames in a payload unit succeeding a header unit. Regardless whether the payload unit is encrypted or not, I-frame position information may be obtained from the analysis of a usually plaintext header, thus allowing to derive the desired information without a requirement to decrypt an entire payload unit. Thus, the computational burden is low, and a fast detection of I-frames is made possible. This, in turn, accelerates the generation of trick-play data. Normally, there is lack of information in an encrypted stream about where an I- frame starts, as this can decrease the demands on a storage device and the required computing resources. Since the I-frames may be localized relatively easily by the invention, it may be sufficient to read an amount of data holding an I-frame (maximum 1700 packets), instead of a lull group of pictures (GOP) plus an I-frame. Finding the start of an I-frame is thus made possible by the invention, particularly for the case of an encrypted stream.

According to one aspect of the invention, a method of detecting I-frames of an encrypted video transport stream is provided, which transport stream may comprise a succession of video frames. The method may comprise identifying, in a time span, an amount of payload unit start indicators (PLUSIs) present in packet headers of the transport stream, and determining an occurrence factor of said identified PLUSIs in relation to frames appeared within the time span. Further, position information representing the position of said identified PLUSIs may be stored within the transport stream, and the I-frames may be determined based on the occurrence factor and the position information. - A -

Thus, an exemplary embodiment of the invention allows the detection of I-frames, which I-frames may or may not be encrypted, using the payload unit start indicator flag present in the transport stream packet header. For instance, the I-frames found may be used to generate trick-play streams or to perform key frame extraction. One aspect according to the invention is to provide a simple way of finding I- frames, even in an encrypted stream, wherein the I-frames may be needed for generating trick- play streams. Thus, less storage is needed as only a reduced amount of data that holds an I- frame, instead of a full group of pictures plus an I-frame has to be processed.

Exemplary application fields of the system according to the invention are digital video recording devices (such as hard disk combinations, DVD +RW, etc.) or network enabled devices that may use trick-play.

According to an exemplary embodiment of the invention, PLUSIs are detected in a stream, which PLUSIs can be used to detect the I-frames in the stream. An exemplary method according to the invention uses certain characteristics of the subsequent PLUSIs in a stream to see if they can be used for localizing I-frames. These characteristics may include the amount of PLUSIs in a certain time span, and a number of PLUSIs derived from frames in a window. By using the amount of PLUSIs in a certain time span, an algorithm may decide whether there is a relation between the amount of frames in the stream and the amount of PLUSIs in the stream. If the result of this decision is that there is a one-to-one relation (each frame has its own PLUSI), then the algorithm may use the other criteria to decide which of those frames are the I-frames.

One aspect of the invention is directed to verifying the usability of the payload unit start indicators in a plaintext MPEG2 transport stream packet header for detecting I-frame start positions in the data. Further, a method according to the invention may be also capable of detecting the location of the I-frame, if a PLUSI per frame is used.

According to the invention, it may be intended to find the I-frames via the streams solely by detecting the payload unit start indicators (PLUSI) and optionally the distance (in time) between successive PLUSIs. It may be determined whether a packetized elementary stream (PES) per frame or a PES per GOP is used. There is also the possibility that no relation between a PES and video exists.

If a PES per GOP is used, it is possible to create an index file that stores the position of each packet that has the PLUSI set to "1" and mark this as the start of an I-frame. If a PES per frame is used, it is possible to use a sliding window for certain size, in the range of for instance 16 to 23 successive PLUSIs to determine the I-frames in the set. The selected range has an impact to the accuracy of the method, as it should be matched to the size of expected GOP sizes. This sliding window allows the detection of I-frames even if the GOP size is not a constant value. Again, an index file may be created that stores the position of each packet that has PLUSIs set to "1" and is marked as an I-frame by the algorithm described.

As the method according to the invention can not be trusted 100% (some P- frames and/or B-frames may incorrectly be marked as an I-frame), it is a further aspect according to the invention that a detection/clean-up circuit may be provided for insuring that I-frames passed to a trick-play generator are truly I-frames. This may imply that the frames used for trick-play generation are (at least partially) decrypted, analyzed, and sent to the trick- play generator. If a frame is detected that is not an I-frame, the previous I-frame will be resent by the trick-play generator. For trick-play generation (at least fast play) it is not absolutely essential that all I-frames are used. Referring to the dependent claims, further exemplary embodiments of the invention will be described.

Next, exemplary embodiments of the device for detecting positions of intra-coded frames in a data stream will be described. These embodiments may also be applied for the method of detecting positions of intra-coded frames in a data stream, for the computer- readable medium and for the program element.

In the device according to the invention, the detection unit may be adapted to detect, in case that the determining unit has determined a single payload unit start indicator in a segment, a starting position of a corresponding intra-coded frame in the payload unit from the determined payload unit start indicator, and a length of the corresponding intra-coded frame by decrypting the payload unit from the starting position onwards. According to this embodiment, the determining unit has determined that only one payload unit start indicator is present in a segment (particularly a PES). Then, it is unambiguously possible to determine a starting position of an I-frame based on the information contained in this PLUSI. For determining the length of the I-frame, a corresponding part of the (possibly encrypted) data starting at the starting position of the I-frame may be decoded. However, the data amount to be decoded is relatively small due to the knowledge of the starting position, so that the bandwidth of the system may be used efficiently. Alternatively, in case that the determining unit has determined one respective payload unit start indicator for each frame of a segment (that is to say a plurality of PLUSIs in a segment, wherein in this case a segment may be a Group of Pictures, GOP, and a frame may be a Packetized Elementary Stream packet, a PES packet), intra-coded frames in the payload unit may be detected by analyzing the size of the frames, and by classifying a frame as an intra- coded frame based on the size of the frame. According to this embodiment, the sequence of frames in the payload unit is analyzed. In many cases, I-frames have a larger size than B- frames and P-frames so that the size is an appropriate criteria to decide a probability whether a particular frame is an I-frame or not. For instance, frames exceeding a threshold in size may be classified to be I-frames. Frames with smaller sizes may be classified as other frames (particularly B-frames or P-frames).

Still referring to the above embodiment, a size of each of the windows may be selected depending on an expected size of a segment. In other words, in the frame of the described sliding window technique, the sliding windows may be dimensioned in accordance with an expected size (that is an expected number of frames) of a Group of Pictures (GOP) as the segment. For instance, the sliding window size may be at minimum equal to the GOP size and at maximum smaller than twice the GOP size.

Particularly, the detection unit may be adapted, for analyzing the size of the frames, to group the frames into overlapping or non-overlapping windows, and to classify a frame as an intra-coded frame based on the size of the frames compared to the size of other frames in a respective window. In other words, a window may be defined within the sequence of frames contained in the payload unit. Within such windows, an analysis can be carried out which of the frames included therein has the largest size and might therefore be an I-frame. Then, this window may be shifted, for instance by one frame, so that overlapping windows are created in which I-frames may be detected.

However, also non-overlapping windows are possible, that is to say the payload unit may be divided into a plurality of portions that do not overlap, and the analysis of the frames included in these windows can be carried out independently from other windows. Then, the window size should be matched to the GOP size. Preferably, the window size is an integer amount (N, for instance N=2) of the GOP, and the N largest frames in a window may then be chosen as I-frames.

The determining unit may be adapted to determine a number of payload unit start indicators in the header unit in a predetermined time span. Then, the determining unit may determine an occurrence factor of the number of pay load unit start indicators in the header units in relation to frames appeared within the predetermined time span. Furthermore, the determining unit may be adapted to determine position information concerning a position of the payload unit start indicators in the data stream. Beyond this, the detection unit may be adapted to detect positions of the intra-coded frames in the data stream based on the occurrence factor and the position information. Such an algorithm is able to determine I- frames with proper accuracy.

The device may be adapted to process a data stream having a plaintext header unit. In other words, for analyzing the PLUSIs, it is not necessary to decrypt the header, since the header is usually provided in plaintext, that is to say in a non-encrypted manner. This accelerates the I-frame detection algorithm, because a time-consuming decryption is dispensible.

The device may be adapted to process a data stream having a plaintext payload unit or an encrypted payload unit and/or may be adapted to process a data stream comprising at least one plaintext payload unit interspersed with at least one encrypted payload unit. Thus, the device may be adapted in such a manner as to process a data stream having a plaintext payload unit or an encrypted payload unit or a mixture of plaintext and encrypted payload units. The concept of the invention is applicable to both encrypted and non-encrypted data streams. Particularly in the case of encrypted payload units, the method according to the invention is particularly advantageous, since the computational burden for decrypting an entire data stream just for I-frame detection is large and can be significantly reduced with the schemes according to the invention. Further, data streams including a mixture of encrypted and non-encrypted portions may be processed with the system according to the invention. Only few bandwidth is needed for processing in this case. The described aspect can be implemented as well in the context of PES level decryption.

The device according to the invention may be adapted to process a data stream of video data or audio data. However, such media content is not the only type of data that may be processed advantageously according to the invention. Trick-play generation and other applications are an issue for both, video processing and (pure) audio processing. The device according to the invention may be adapted to process a data stream of digital data.

Further, the device may comprise an extraction unit adapted to extract a key frame in the data stream based on the detected positions of intra-coded frames. Thus, the information concerning I-frames may be used for key frame detection. A key frame in this context may be particularly a single still image in an animated sequence that occurs at an important or characteristic point in that sequence or scene.

Additionally or alternatively, the device according to the invention may comprise a generation unit adapted to generate a data stream for reproduction in a trick-play reproduction mode based on the detected positions of intra-coded frames. A user may adjust such a trick- play mode by selecting corresponding options in a user interface, for instance buttons of a device, a keypad, or a remote control. The trick-play reproduction mode selected by a user and requiring the information concerning the position of I-frames may be one of the group consisting of a fast forward reproduction mode, a fast reverse reproduction mode, a slow motion reproduction mode, a freeze frame reproduction mode, an instant replay reproduction mode, and a reverse reproduction mode. Other trick-play schemes are however possible. For trick-play, only a portion of subsequent data shall be used for output (e.g. for visual display and/or for acoustical output). Since not all data (P-frames, B-frames) in a data stream can be used independently from other data (I-frames) for generating displayable signals, the knowledge of the independently usable data (I-frames) is desired.

The device according to the invention may be adapted to process an MPEG2 data stream. MPEG2 is the designation for a group of audio and video coding standards agreed upon by MPEG (moving pictures experts group), and published as the ISO/IEC13818 international standard. MPEG2 may be used to encode audio and video for broadcast signals, including digital satellite and cable TV, but may also be used for DVD.

The device according to the invention may be realized at least one of the group consisting of a digital video recording device, a network-enabled device, a conditional access system, a portable audio player, a portable video player, a mobile phone, a DVD player, a CD player, a harddisk-based media player, an internet radio device, a public entertainment device, and an MP3 player. However, these applications are only exemplary.

The aspects defined above and further aspects of the invention are apparent from the examples of embodiment to be described hereinafter and are explained with reference to these examples of embodiment.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in more detail hereinafter with reference to examples of embodiment but to which the invention is not limited. Fig. 1 illustrates a time-stamped transport stream packet.

Fig. 2 shows an MPEG2 group of picture structure with intra-coded frames and forward predictive frames.

Fig. 3 illustrates an MPEG2 group of picture structure with intra-coded frames, forward predictive frames and bidirectional predictive frames.

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

Fig. 5 illustrates a system for trick-play on a plaintext stream.

Fig. 6 illustrates time compression in trick-play. Fig. 7 illustrates trick-play with fractional distance.

Fig. 8 illustrates low speed trick-play.

Fig. 9 illustrates a general conditional access system structure.

Fig. 10 illustrates a digital video broadcasting encrypted transport stream packet.

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

Fig. 12 illustrates a system allowing to perform trick-play on a fully encrypted stream.

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

Fig. 14 illustrates a transport stream packet with a pay load unit start indicator set. Fig. 15 illustrates frame-size distribution of a data stream comprising I-frames and

P-frames.

Fig. 16 illustrates the accuracy of I-frame detection from payload unit start indicators according to the invention.

Fig. 17 illustrates a device for detecting positions of intra-coded frames in a data stream according to an exemplary embodiment of the invention.

Fig. 18 illustrates frame-size distribution of a data stream comprising I-frames, P- frames and B-frames.

DESCRIPTION OF EMBODIMENTS The illustration in the drawing is schematically. In different drawings, similar or identical elements are provided with the same reference signs.

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

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

Experiments were actually done with an extension, the so-called time-stamped transport stream. This comprises transport stream packets, all of which are pre-pended with a 4 bytes header in which the transport stream packet arrival time is placed. This time may be derived from the value of the program clock reference (PCR) time-base at the time the first byte of the packet is received at the recording device. This is a proper method to store the timing information with the stream, so that playback of the stream becomes a relatively easy process.

One problem during playback is to ensure that the MPEG2 decoder buffer will not overrun nor underflow. If the input stream was compliant to the decoder buffer model, restoring the relative timing ensures that the output stream is also compliant. Some of the trick-play methods described herein are independent of the time stamp and perform equally well on transport streams with and without time stamps.

Fig. 1 illustrates a time stamped transport stream packet 100 having a total length 104 of 188 Bytes and comprising a time stamp 101 having a length 105 of 4 Bytes, a packet header 102, and a packet payload 103 having a length of 184 Bytes.

This following description will give an overview of the possibilities to create an MPEG/DVB (digital video broadcasting) compliant trick-play stream from a recorded transport stream and intends to cover the full spectrum of recorded streams from those that are completely plaintext, so every bit of data can be manipulated, to streams that are completely encrypted (for instance according to the DVB scheme), so that only headers and some tables may be accessible for manipulation. The invention also addresses a solution in between these extremes, where only the data that needs to be manipulated to generate the trick-play stream is in plaintext.

When creating trick-play for an MPEG/DVB transport stream, problems may arise when the content is at least partially encrypted. It may not be possible to descend to the elementary stream level, which is the usual approach, or even access any packetized elementary stream (PES) headers before decryption. This also means that finding picture frames is not possible. Known trick-play engines need to be able to access and process this information.

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

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

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

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

Even if an MPEG2 stream is not encrypted (that is to say plaintext), trick-play is not trivial. An easy solution is just to output the data faster to a decoder to get a fast-forward mode, but as MPEG has timing related information encoded in its headers, this cannot just be done with the expectation to get a proper fast-forward. Besides that, it may be difficult to decide what frames to drop, as this method to perform fast-forward, may give a frame rate higher than the display rate.

Moreover, such a stream is not an MPEG2 compliant transport stream. This can be acceptable if the decoder is in the storage device but may be problematic if the signal is transferred by a standard digital interface. Furthermore, the bit rate may increase dramatically in the whole chain. If the normal play stream is a time stamped transport stream of a single program originating from satellite broadcast, the bit rate to the decoder in normal play may be around 40 Mbps and packets may be in irregular positions with gaps in between (partial transport stream). If the stream is compressed with the trick-play factor, the bit rate may be around 120 Mbps for a 3x trick-play speed. The necessary sustained bandwidth of a harddisk drive may also be increased with the trick-play factor. So it would be appropriate to keep sending the correct amount of frames, but here a problem may occur when using a video coding technique like MPEG that exploits the temporal redundancy of video to achieve high compression ratios. Frames can no longer be decoded independently. A structure of a plurality of groups of pictures (GOPs) is shown in Fig. 2.

Particularly, Fig. 2 shows a stream 200 comprising several MPEG2 GOP structures with a sequence of I-frames 201 and P-frames 202. The GOP size is denoted with reference numeral 203. The GOP size 203 is set to 12 frames, and only I-frames 201 and P- frames 202 are shown here. In MPEG, a GOP structure may be used in which only the first frame is coded independently of other frames. This is the so-called intra-coded or I-frame 201. The predictive frames or P-frames 202 are coded with a unidirectional prediction, meaning that they only rely on the previous I-frame 201 or P-frame 202 as indicated by arrows 204 in Figure 2.

Such a GOP structure has typically a size of 12 or 16 frames 201, 202. It is assumed that a trick-play speed of 2x forward is desired. So, for instance, every second frame should be skipped. This is not possible in the compressed domain due to the dependence on the reconstructed previous frame during decoding. So just dropping some compressed frames and fixing the timing information is no option.

The alternative is to decode the entire stream first, then skip every second frame and finally encode the remaining frames again. This may lead to an unacceptable complexity of the trick-play circuitry or software. So in the best case, some frames can be skipped from the GOP, on which no other frames rely. For the example of a trick-play speed of 2x with a GOP size of 12 frames, only the last 6 P-frames can be skipped. In this case, the displayed images tend to be of a "jumpy" nature, where a short normal speed period is obtained, followed by a sudden jump in time. Especially at higher trick-play speeds this may be unpleasant and does not give the viewer the look and feel of usual trick-play.

Another structure 300 of a plurality of groups of pictures (GOP) is shown in Fig. 3.

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

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

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

Whatever structure the stream has, the solutions described until now, may give an acceptable form of trick-play for a fast-forward mode. For reverse, the frames would have to be reordered in time, but due to the fact that MPEG uses the temporal correlation between successive frames to achieve a high compression ratio, the order in which the frames have to be decoded is fixed. Therefore, a GOP first has to be decoded in forward direction. The order of the GOPs sent to the decoder can be reversed, and GOPs can be skipped for higher reverse trick-play speeds. Reducing the GOPs by skipping P-frames or B-frames as described above is also possible in this case. Anyway, it may result in a displayed sequence of forward play and backward jumps. Therefore, the trick-play frames have to be selected from the decoded GOP and reversed in order, after which the frames are re-encoded. Then the previous GOP is fetched and processed and so on. Although possible, the complexity of such procedure may be high.

A conclusion from the foregoing considerations is that using only the I-frames in the trick-play generation may be a proper solution, because these frames can be decoded independently. As a result, the trick-play generation may be easier especially for reverse. Additionally, the use of only I-frames already allows for trick-play speeds down to 3x or 4x. For really low trick-play speeds, the more complex techniques mentioned above may be implemented. In the following, some aspects related to a CPI ("characteristic point information") file will be described.

Finding I-frames in a stream usually requires parsing the stream, to find the frame headers. Locating the positions where the I-frame starts can be done while the recording is being made, or off-line after the recording is completed, or semi on-line, in fact being off-line but with a small delay with respect to the moment of recording. The I-frame end can be found by detecting the start of the next P-frame or B-frame. The meta-data derived this way can be stored in a separate but coupled file, which file may be denoted as characteristic point information file or CPI file. This file may contain pointers to the start and eventually end of each I-frame in the transport stream file. Each individual recording may have its own CPI file. The structure of a characteristic point information file 400 is visualized in Fig. 4. Apart from the CPI file 400, stored information 401 is shown. The CPI file 400 may also contain some other data that are not discussed here. With the data from the CPI file 400 it is possible to jump to the start of any I- frame 201 in the stream. If the CPI file 400 also contains the end of the I-frames 201, the amount of data to read from the transport stream file is exactly known to get a complete I- frame 201. If for some reason the I-frame end is not known, the entire GOP or at least a large part of the GOP data is to be read to be sure that the entire I-frame 201 is read. The end of the GOP is given by the start of the next I-frame 201. It is known from measurements that the amount of I-frame data can be 40% or more of the total GOP data.

With the retrieved 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 stream are re-multiplexed correctly, in such a manner that no buffer problems for the MPEG decoder will occur. Although this seems to be a straightforward solution, it is not a trivial solution as will become clear in the following.

Next, some aspects related to as to how to construct a trick-play stream will be described.

With the help of the CPI file, describing at what packet position an I-frame 201 starts, as well as where the I-frame 201 ends, access is provided to all I-frames 201 from the original stream. But just concatenating adequately chosen I-frames 201 into one big stream of only I-frames 201 does not result in a valid MPEG stream, as will become clear from the following.

The first point to investigate is the bit rate of the trick-play stream. For example, the original stream has an average video bit rate of 4 Mbps and a GOP size 203 of 12 frames. The bit rate may be extracted from a measurement on a real broadcast stream. It is assumed that the trick-play stream consists of I-frames 201 only that are each displayed one frame time, leading to a refresh rate of the trick-play stream equal to normal play. It is recalled that the amount of I-frame 201 data could be 40% of the GOP data. This number originates from a measurement, where the average has been around 25%. So on average 25% of the data have to be compressed into 1/12 of the time, leading to a 3 times higher bit rate. Thus the average trick-play bit rate would be 12 Mbps with peaks up to around 20 Mbps. This simple example is intended to provide some feeling for the bit rate effect and its origin.

In fact, the sizes of the I-frames 201 are known or are derivable from the measurement. Therefore, the bit rate for an I-frame 201 only trick-play stream as a function of time can easily be calculated accurately. The trick-play bit rate may be 2 to 3 times higher than the normal play bit rate and sometimes it may be higher than allowed by the MPEG2 standard. Taking into account that this is an example with a moderate bit rate stream and that streams with higher bit rates will surely be encountered, it is clear that some form of bit rate reduction has to be applied. For instance, the trick-play bit rate may be comparable to the normal play bit rate. This is especially important if the streams are sent to a decoder via a digital interface. Additional demand on bandwidth from the interface due to trick-play should be avoided. A first option is to reduce the size of the I-frames 201. However, this may add complexity and limitations in relation to trick-play for encrypted streams.

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

In the following, some aspects related to timing issues and stream construction will be described.

A trick-play system 500 is schematically depicted in Fig. 5. The trick-play system 500 comprises a recording unit 501, an I-frame selection unit 502, a trick-play generation block 503 and an MPEG2 decoder 504. The trick-play generation block 503 includes a parsing unit 505, an adding unit 506, a packetizer unit 507, a table memory unit 508 and a multiplexer 509. The recording unit 501 provides the I-frame selection unit 502 with plaintext MPEG2 data 510. The multiplexer 509 provides the MPEG2 decoder 504 with an MPEG2 DVB compliant transport stream 511.

The I-frame selector 502 reads specific I-frames 201 from the storage device 501. Which I-frames 201 are chosen depends on the trick-play speed as will be described below. The retrieved I-frames 201 are used to construct an MPEG-2/DVB compliant trick-play stream that is then sent to the MPEG-2 decoder 504 for decoding and rendering.

The position of the I-frame packets in the trick-play stream cannot be coupled to the relative timing of the original transport stream. In trick-play, the time axis may be compressed with the speed factor and additionally inversed for reverse trick-play. Therefore, the time stamps of the original time stamped transport stream may not be suitable for trick- play generation.

Moreover, the original PCR time base may be disturbing for trick-play. First of all it is not guaranteed that a PCR will be available within the selected I-frame 201. But even more important is that the frequency of the PCR time base would be changed. According to the MPEG2 specification, this frequency should be within 30 ppm from 27 MHz. The original PCR time base fulfils this requirement, but if used for trick-play it would be multiplied by the trick-play speed factor. For reverse trick-play this even leads to a time base running in the wrong direction. Therefore, the old PCR time base has to be removed and a new one added to the trick-play stream.

Finally, I-frames 201 normally contain two time stamps that tell the decoder 504 when to start decoding the frame (decoding time stamp, DTS) and when to start presenting, for instance displaying, it (presentation time stamp, PTS). Decoding and presentation may be started when DTS respectively PTS are equal to the PCR time base, which is reconstructed in the decoder 504 by means of the PCRs in the stream. The distance between, e.g., the PTS values of 2 I-frames 201 corresponds to their nominal distance in display time. In trick-play this time distance is compressed with the speed factor. Since a new PCR time base is used in trick-play, and because the distance for DTS and PTS is no longer correct, the original DTS and PTS of the I-frame 201 have to be replaced. To solve above-mentioned complications, the I-frame 201 may first be parsed into an elementary stream in the parsing unit 505. Then the empty P-frames 202 are added on elementary stream level. The obtained trick-play GOP is mapped into one PES packet and packetized to transport stream packets. Then corrected tables like PAT, PMT, etc. are added. At this stage, a new PCR time base together with DTS and PTS are included. The transport stream packets are pre-pended with a 4 bytes time stamp that is coupled to the PCR time base such that the trick-play stream can be handled by the same output circuitry as used for normal play. In the following, some aspects related to trick-play speeds will be described.

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

Nb=G/T (1)

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

N=D*G/T (2)

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

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

Secondly, arbitrary trick-play speeds will be discussed.

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

D=N*T/G (3)

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

As visualized in Fig. 7 illustrating trick-play with fractional distances, there are particularly three possibilities to choose the I-frame 201 : A. The I-frame closest to the ideal point; / = round(7p)

B. The last I-frame before the ideal point; / = int(7p)

C. The first I-frame after the ideal point; /= int(7p)+l As can clearly be seen, the actual distance is varying between int(Z>) and int(Z>)+l, the ratio between the occurrences of the two being dependent on the fraction of D, such that the average distance is equal to D. This means that the average trick-play speed is equal to N, but that the actually used frame has a small jitter with respect to the ideal frame. Several experiments have been performed with this, and although the trick-play speed may vary locally, this is not visually disturbing. Usually, it is not even noticeable especially at somewhat higher trick-play speeds. It is also clear from Fig.7 that it makes no essential difference whether to choose method A, B or C.

With this method, trick-play speed N does not need to be an integer but can be any number above the basic speed Nb. Also speeds below this minimum can be chosen, but then the picture refresh rate may be lowered locally because the effective trick-play GOP size T is doubled or at still lower speeds even tripled or more. This is due to a repetition of the trick- play GOPs, as the algorithm will choose the same I-frame 201 more than once.

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

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

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

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

Rt=RZT (4) With a trick-play GOP structure of IPP (T=3) or IPPP (T=4), the refresh rate Rt is 8 1/3 Hz respectively 6 1/4 Hz for Europe and 10 Hz respectively 7 1/2 Hz for the USA. Although the judgement of trick-play picture quality is a somewhat subjective matter, there are clear hints from experiments that these refresh rates are acceptable for low speeds and even advantageous at higher speeds.

In the following, some aspects related to encrypted stream environments will be described.

In the following, some information about encrypted transport streams is presented as a basis for the description of trick-play on encrypted streams. It is focussed on the Conditional Access System used for broadcast.

Fig. 9 illustrates a conditional access system 900 which will be described in the following.

In the conditional access system 900, content 901 may be provided to a content encryption unit 902. After having encrypted the content 901, the content encryption unit 902 supplies a content decryption unit 904 with encrypted content 903.

A control word 906 may be supplied to the content encryption unit 902 and to a ECM generation unit 907. The ECM generation unit 907 generates an ECM and provides the same to an ECM decoding unit 908 of a smartcard 905. The ECM decoding unit 908 generates from the ECM a control word which is decryption information that is needed and provided to the content encryption unit 904 to decrypt the encrypted content 903.

Furthermore, an authorization key 910 is provided to the ECM generation unit 907 and to a KMM generation unit 911, wherein the latter generates a KMM and provides the same to a KMM decoding unit 912 of the smartcard 905. The KMM decoding unit 912 provides an output signal to the ECM decoding unit 908. Moreover, a group key 914 may be provided to the KMM generation unit 911 and to a GKM generation unit 915 which may further be provided with a user key 918. The GKM generation unit 915 generates a GKM signal GKM and provides the same to a GKM decoding unit 916 of the smartcard 905, wherein the GKM decoding unit 916 gets as a further input a user key 917. Beyond this, entitlements 919 may be provided to an EMM generation unit 920 which generates an EMM signal and provides the same to an EMM decoding unit 921. The EMM decoding unit 921 located in the smartcard 905 is coupled with an entitlement list unit 913 which provides the ECM decoding unit 908 with corresponding control information. ECM denotes Entitlement Control Messages, KMM denotes Key Management Messages, GKM denotes Group Key Messages, and EMM denotes Entitlement 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 broadcasted content 901 is encrypted under the control of the CA system 900. In the receiver, content is decrypted before decoding and rendering if access is granted by the CA system 900.

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

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

In an MPEG2 system, encrypted content, ECMs and EMMs (including the KMM and GKM types) are all multiplexed into a single MPEG2 transport stream. The description above is a generalized view of the CA system 900. In digital video broadcasting, only the encryption algorithm, the odd/even control word structure, the global structure of ECMs and EMMs and their referencing are defined. The detailed structure of the CA system 900 and the way the payloads of ECMs and EMMs are encoded and used are provider specific. Also the smartcard is provider specific. However, from experience it is known that many providers follow essentially the structure of the generalized view of Fig. 9.

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

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

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

Fig. 11 illustrates a detailed structure of the transport stream packet header 1002 of Fig. 10.

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

Thus, Fig. 10 and Fig. 11 show the MPEG2 transport stream packet 1000 that has been encrypted and which comprises different parts:

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

- DVB Encrypted Packet Payload 1005 contains the actual program content that may have been encrypted using the DVB algorithm. In order to select the correct CW that is needed to decrypt the broadcasted program it is necessary to parse the transport stream packet header. A schematic overview of this header is given in Fig.l 1. An important field for the decryption of the broadcasted program is the scrambling control bits (SCB) field 1014. This SCB field 1014 indicates which CW the decrypter must use to decrypt the broadcasted program. Moreover, it indicates whether the payload of the packet is encrypted or in plaintext. For every new transport stream packet, this SCB 1014 must be parsed since it changes over time and can change from packet to packet.

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

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

Using the control words, the decrypter 1203 decrypts the encrypted transport stream 1202 and sends the decrypted data to an I-frame detector and filter 1205. From there, the data are provided to an insert empty P frame unit 1206 which conveys the data to a set top box 1207. From there, data are provided to a television 1208.

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

If the recording made does not consist of all packets from the full multiplex, the recording becomes a so-called partial transport stream 1300 (see Fig. 13). Further, Fig. 13 illustrates a full transport stream 1301. The DVB standard requires that if a partial transport stream 1300 is played, all normal DVB mandatory tables like NIT (network information table), BAT (bouquet association table) etc. are removed. Instead of these tables, the partial stream should have SIT (selection information table) and DIT (discontinuity information table) tables inserted.

In the following, referring to Fig. 14 to Fig. 18, systems will be described which are capable of detecting positions of intra-coded frames 201 in a data stream using information of payload unit start indicators (PLUSI) according to exemplary embodiments of the invention.

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

An important information lacking about an encrypted stream is where an I-frame 201 starts, as this can really decrease the demands on the storage device. Knowing the I-frame 201 locations, it is only necessary to read an amount of data that holds an I-frame 201 (max. 1700 packets), instead of a full GOP plus an I-frame 201. Finding the start of an I-frame is not trivial though, especially on an encrypted stream. What is easier to find, even on an encrypted stream, is the location where a PES packet starts, as the payload unit start indicator (PLUSI) 1012 is set when PES header data is present. This PLUSI 1012 is present in the transport stream packet header 1401, so it is not encrypted. Fig. 14 depicts a transport stream packet 1400 that has the PLUSI bit 1012 set.

The transport stream packet 1400 has a PES header 1401 and an elementary payload 1402 including a GOP start 1403, a frame start 1404 and video data 1405.

According to the standard, PES packets need not really be related to frames though, but a lot of channels package exactly one entire GOP in one PES packet. This means that in this case, the presence of a PLUSI 1012 also indicates the start of a GOP. As GOPs start with an I-frame 201 this means that the I-frame 201 will also start at that location, and that this can be a possible starting point for reading a block of data in trick-play.

However, packaging one GOP per PES packet is not mandatory, or even a de facto standard. Other channels may start a new PES packet per frame, so that only every N-th PLUSI 1012 indicates an I-frame 201, where N is the GOP size 203 in frames.

In a worst-case, the PES packet sizes may be totally unrelated to the actual frames, although such a situation is unfamiliar in actual broadcast streams.

However, one cannot always just rely on the PLUSI 1012 to find an I-frame 201. But if it is coupled, which is in many practical scenarios the case, it may increase performance considerably. So it is promising to try to verify if the PLUSI 1012 is related to the frames in the video. To do this, several possibilities exist.

Without decoding, it is possible to simply count the PLUSIs 1012 in the video stream. This can e.g. be done during the recording of a program. Dividing the total playing time by the amount of PLUSIs 1012 is a good indication of a relation between PLUSI 1012 and frames.

If it is near enough equal to one frame period, each frame is packaged in its own PES, and each PLUSI 1012 indicates the start of a new frame.

If it is within an adequate predetermined limit equal to an integer multiple of the frame period (probably 12 or 16), it is very likely that each PES packet holds a full GOP. The integer found is a good approximation of the GOP size 203 in frames.

Any other value probably means there is no relation between frames and PES packets. Using the PLUSI 1012 to find frames is not possible in this case.

Having a GOP per PES is the easiest situation, because then it is possible to safely assume that each I-frame 201 starts at the position of a PLUSI 1012. To effectively make use of this, the PLUSI positions may be stored in some kind of CPI (characteristic point information) file. This file is comparable to the CPI file used for plaintext streams (see Fig. 4 and corresponding description) in the sense that it may contain the starting points of all the I- frames 201, however it does not contain the ending points.

If each PES holds a single frame, a bit more processing is necessary to use the

PLUSI 1012. First of all, the GOP size may be detected, and secondly, it may be analyzed where the GOP starts. This can be detected by looking at the amount of data between two successive PLUSIs 1012, which is equal to the size of the intermediate frame. Most likely the

I-frames 201 are the biggest frames.

Fig. 15 shows a graphical representation 1500 of the expected frame size distribution for a sequence of I-frames 201 and P-frames 202. For instance, the TV station "TWl" uses one PES for each frame so this station was used for performing measurements as a basis for further investigation. The frame sizes were determined by detecting the PLUSIs 1012 and the frame type was taken from the picture header. Although the frame type will not be available for an encrypted stream, it is used here as a reference for the quality of a possible I-frame detection. From these data the inventors noticed the following:

- The GOP structure is IBPBPB....

- The GOP size 203 is mainly 12 frames.

- GOP sizes 203 of 2, 4, 6, 8 and 10 frames are present occasionally.

- P-frames 202 and even B-frames 301 are sometimes (but relatively seldom) larger than surrounding I-frames 201.

Still assuming in generally proper approximation that the I-frames 201 should have the largest size, the following detection method ("sliding window method") can be performed.

A limited set of consecutive frame sizes is taken and is let slide along the total set of frames.

At each position of the sliding set, the largest frame in the set is determined and assumed to be an I-frame 201. Of course the same I-frame 201 will be found at several consecutive positions of the sliding set. At the end, all or at least most of the probable I-frames 201 in the measurement are found.

Because the type (I, P or B) of all frames is available as a reference, the quality of the detection method can be checked. First of all, it can be checked which I-frames 201 are not detected as such. Secondly, it is checked which P-frames 202 or B-frames 301 are erroneously detected as being an I-frame 201. Thereby, it can be evaluated what size should be chosen for the limited set of consecutive frames. The detection method may be repeated for several set sizes to investigate this. The number of correctly detected I-frames 201 as well as the P-frames 202 and B- frames 301 erroneously detected to be I-frames 201 are tabulated in Fig. 16.

In a first row of the table shown in Fig. 16, the set size is plotted, that is to say a width of the sliding window in frames. In a row "I", the number of detected I-frames 201 is shown. In a row "Missed I", the number of non-detected I-frames 201 is shown. In a row "P", the number of P-frames 202 which have been erroneously detected as I-frames 201 are shown. In a row "B", the number of B-frames 301 which have been erroneously detected as I-frames 201 are shown.

Thus, the set size is indicated in the top row. For clarity, the number of missed I- frames 201 is also included. In reality there are 402 I-frames 201 in the used measurement set of 4725 frames.

The table indicates that there are two very specific boundaries namely between a set size of 11 and 12 frames and between 23 and 24 frames. At a set size smaller than 12, the number of P-frames 202 and B-frames 301 erroneously detected as I-frames 201 increases dramatically. At a set size of 24 frames and larger a huge amount of I-frames 201 is missed. Between these two boundaries, the quality of the detection only varies slightly with an optimum at a set size of 13.

The most commonly used and also maximum GOP size 203 in the measurement data is 12 frames. So the set size may preferably be at minimum equal to the GOP size 203 and at maximum smaller than twice the GOP size 203. This can be understood from the following reasoning. The set should contain at least one I-frame 201 at all times to avoid a P- frame 202 or B-frame 301 being forcedly marked as an I-frame 201. On the other hand, a specific I-frame 201 should be the only one in the sliding set at a certain moment in order not to be missed if both surrounding I-frames 201 are larger. Within the given range, a proper detection quality is obtained. Although a fallback option of repeating I-frames 201 will have to be used occasionally, the gain in reducing the block size by the use of this method is enormous.

Assuming that the GOP sizes 203 encountered in real life will be mainly 12 and 16, a set size in the range of 16 to 23 should be chosen. The start and end points of the found I-frames 201 may be stored in a CPI file that is fully comparable to the CPI file for plaintext streams.

A method has been described how CPI data can possibly be generated for an encrypted stream by using PLUSIs 1012. In the following, referring to Fig. 17, a device 1700 for generating trick-play according to an exemplary embodiment of the invention will be described.

A data stream 1701 comprises a plurality of subsequently transmitted transport stream packets, wherein each transport stream packet comprises a header unit 1002 and a payload unit 1005.

The data stream is supplied to a determining unit 1702 that determines payload unit start indicators (PLUSIs) 1012 in the header units 1002. As a result of this determination, PLUSI information 1703 is obtained and is provided to a detection unit 1704.

The detection unit 1704 detects positions of I-frames 201 in the payload units 1005 based on the determined PLUSIs 1012, that is to say based on the PLUSI information 1703. As a result of this detection, the detection unit 1704 provides at its output, which is coupled to an input of a trick-play generating unit 1705, 1-frame information 1706 which may be derived according to the schemes particularly described above referring to the Fig. 14 to Fig. 16. This I-frame (position and/or length) information 1706 is used by the trick-play generating unit 1705 to generate, based on the I-frame information 1706 and the data stream 1701, a trick-play stream 1707, for instance a fast forward trick-play stream.

In Fig. 18, a data stream 1800 comprising I-frames 201, P-frames 204 and B- frames 301 is shown. Similarly as in Fig. 15, it may be taken from Fig. 18 that in many cases, I-frames

201 have a larger size (indicated by the height of the bars) than P-frames 204 and B-frames 301. This statistical fact is used according to an exemplary embodiment of the invention to determine I-frames 201 in an encrypted data stream without the necessity to completely decrypt the entire data stream for I-frame analysis. It should be noted that the term "comprising" does not exclude other elements or steps and the "a" or "an" does not exclude a plurality. Also elements described in association with different embodiments may be combined.

It should also be noted that reference signs in the claims shall not be construed as limiting the scope of the claims.

Claims

Claims:
1. A device (1700) for detecting positions of intra-coded frames (201) in a data stream comprising a plurality of segments, each segment comprising a header unit (1002) and a payload unit (1005), wherein the device (1700) comprises a determining unit (1702) adapted to determine payload unit start indicators (1012) in the header units (1002); a detection unit (1704) adapted to detect positions of intra-coded frames (201) in the payload units (1005) based on the determined payload unit start indicators (1012).
2. The device (1700) according to claim 1, wherein the detection unit (1704) is adapted to detect, in case that the determining unit (1702) has determined a single payload unit start indicator (1012) in a segment, a starting position of a corresponding intra-coded frame (201) in the payload unit (1005) from the determined payload unit start indicator (1012), and a length of the corresponding intra-coded frame (201) by decrypting the payload units (1005) from the starting position onwards.
3. The device (1700) according to claim 1, wherein the detection unit (1704) is adapted to detect, in case that the determining unit (1702) has determined one respective payload unit start indicator (1012) for each frame of a segment, intra-coded frames (201) in the payload unit (1005) by analyzing the size of the frames, and by using the size of a frame as a criteria for classifying the frame as an intra-coded frame (201) or not.
4. The device (1700) according to claim 3, wherein the detection unit (1704) is adapted, for analyzing the size of the frames, to group the frames into overlapping or non-overlapping windows, and to classify a frame as an intra-coded frame (201) or not using the size of the frame compared to the size of other frames in a respective window as a criteria.
5. The device (1700) according to claim 4, wherein a size of each of the windows is selected depending on an expected size of a segment.
6. The device (1700) according to claim 1, wherein the determining unit (1702) is adapted to determine a number of payload unit start indicators (1012) in the header units (1002) in a predetermined time span.
7. The device (1700) according to claim 6, wherein the determining unit (1702) is adapted to determine an occurrence factor of the number of payload unit start indicators (1012) in the header units (1002) in relation to frames appeared within the predetermined time span.
8. The device (1700) according to claim 7, wherein the determining unit (1702) is adapted to determine a position information concerning a position of the payload unit start indicators (1012) in the data stream.
9. The device (1700) according to claim 8, wherein the detection unit (1704) is adapted to detect positions of the intra-coded frames (201) in the data stream based on the occurrence factor and the position information.
10. The device (1700) according to claim 1, adapted to process a data stream having a plaintext header unit (1002).
11. The device (1700) according to claim 1 , adapted to process a data stream having a plaintext payload unit (1005; 1402) or an encrypted payload unit (1005; 1402) and/or adapted to process a data stream comprising at least one plaintext payload unit (1005; 1402) interspersed with at least one encrypted payload unit (1005; 1402).
12. The device (1700) according to claim 1, adapted to process a data stream of video data or audio data.
13. The device (1700) according to claim 1, adapted to process a data stream of digital data.
14. The device (1700) according to claim 1, comprising an extraction unit adapted to extract a key frame in the data stream based on the detected positions of intra-coded frames (201).
15. The device (1700) according to claim 1, comprising a trick-play generation unit (1705) adapted to generate a data stream for reproduction in a trick-play reproduction mode based on the detected positions of intra-coded frames (201).
16. The device (1700) according to claim 15, wherein the trick-play reproduction mode is one of the group consisting of a fast forward reproduction mode, a fast reverse reproduction mode, a slow motion reproduction mode, a freeze frame reproduction mode, an instant replay reproduction mode, and a reverse reproduction mode.
17. The device (1700) according to claim 1, adapted to operate according to the MPEG2 standard.
18. The device (1700) according to claim 1, realized as at least one of the group consisting of a digital video recording device and a network-enabled device and a conditional access system and a portable audio player and a portable video player and a mobile phone and a DVD player and a CD player a harddisk-based media player and an internet radio device and a public entertainment device and an MP3 player.
19. A method of detecting positions of intra-coded frames (201 ) in a data stream comprising a plurality of segments, each segment comprising a header unit (1002) and a payload unit (1005), wherein the method comprises the steps of determining payload unit start indicators (1012) in the header units (1002); detecting positions of intra-coded frames (201) in the pay load units (1005) based on the determined payload unit start indicators (1012).
20. A computer-readable medium, in which a computer program of detecting positions of intra-coded frames (201) in a data stream comprising a plurality of segments, each segment comprising a header unit (1002) and a payload unit (1005), is stored, which computer program, when being executed by a processor, is adapted to control or carry out the following method steps: determining payload unit start indicators (1012) in the header units (1002); detecting positions of intra-coded frames (201) in the payload units (1005) based on the determined payload unit start indicators (1012).
21. A program element of detecting positions of intra-coded frames (201 ) in a data stream comprising a plurality of segments, each segment comprising a header unit (1002) and a payload unit (1005), which program element, when being executed by a processor, is adapted to control or carry out the method steps of: determining payload unit start indicators (1012) in the header units (1002); detecting positions of intra-coded frames (201) in the payload units (1005) based on the determined payload unit start indicators (1012).
PCT/IB2006/051279 2005-04-26 2006-04-25 A device for and a method of detecting positions of intra-coded frames in a data stream WO2006114761A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05103396.7 2005-04-26
EP05103396 2005-04-26

Publications (1)

Publication Number Publication Date
WO2006114761A1 true true WO2006114761A1 (en) 2006-11-02

Family

ID=36758242

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2006/051279 WO2006114761A1 (en) 2005-04-26 2006-04-25 A device for and a method of detecting positions of intra-coded frames in a data stream

Country Status (1)

Country Link
WO (1) WO2006114761A1 (en)

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1936974A1 (en) * 2006-12-18 2008-06-25 Hitachi, Ltd. Apparatus for video recording and reproducing, and method for trick play of video
WO2008063881A3 (en) * 2006-11-13 2008-07-10 Scientific Atlanta System and method for signaling characteristics of pictures' interdependencies
EP2077672A1 (en) * 2007-08-22 2009-07-08 Nippon Telegraph and Telephone Corporation Video quality estimation device, video quality estimation method, frame type judgment method, and recording medium
EP2122934A2 (en) * 2007-02-22 2009-11-25 Symmetricom, Inc. Spatial and temporal loss determination in packet based video broadcast system in an encrypted environment
EP2213000A1 (en) * 2007-07-16 2010-08-04 Telchemy, Incorporated Method and system for content estimation of packet video streams
EP2315428A1 (en) * 2009-10-23 2011-04-27 Samsung Electronics Co., Ltd. Digital content processing apparatus and method of digital video receiver
EP2413535A1 (en) * 2010-07-30 2012-02-01 Deutsche Telekom AG Method for estimating the type of the group of picture structure of a plurality of video frames in a video stream
US8155207B2 (en) 2008-01-09 2012-04-10 Cisco Technology, Inc. Processing and managing pictures at the concatenation of two video streams
US8259817B2 (en) 2008-11-12 2012-09-04 Cisco Technology, Inc. Facilitating fast channel changes through promotion of pictures
US8279926B2 (en) 2009-06-18 2012-10-02 Cisco Technology, Inc. Dynamic streaming with latticed representations of video
US8326131B2 (en) 2009-02-20 2012-12-04 Cisco Technology, Inc. Signalling of decodable sub-sequences
US8416858B2 (en) 2008-02-29 2013-04-09 Cisco Technology, Inc. Signalling picture encoding schemes and associated picture properties
US8416859B2 (en) 2006-11-13 2013-04-09 Cisco Technology, Inc. Signalling and extraction in compressed video of pictures belonging to interdependency tiers
US8699578B2 (en) 2008-06-17 2014-04-15 Cisco Technology, Inc. Methods and systems for processing multi-latticed video streams
US8705631B2 (en) 2008-06-17 2014-04-22 Cisco Technology, Inc. Time-shifted transport of multi-latticed video for resiliency from burst-error effects
US8718388B2 (en) 2007-12-11 2014-05-06 Cisco Technology, Inc. Video processing with tiered interdependencies of pictures
US8782261B1 (en) 2009-04-03 2014-07-15 Cisco Technology, Inc. System and method for authorization of segment boundary notifications
US8804845B2 (en) 2007-07-31 2014-08-12 Cisco Technology, Inc. Non-enhancing media redundancy coding for mitigating transmission impairments
US8875199B2 (en) 2006-11-13 2014-10-28 Cisco Technology, Inc. Indicating picture usefulness for playback optimization
US8886022B2 (en) 2008-06-12 2014-11-11 Cisco Technology, Inc. Picture interdependencies signals in context of MMCO to assist stream manipulation
US8949883B2 (en) 2009-05-12 2015-02-03 Cisco Technology, Inc. Signalling buffer characteristics for splicing operations of video streams
US8958486B2 (en) 2007-07-31 2015-02-17 Cisco Technology, Inc. Simultaneous processing of media and redundancy streams for mitigating impairments
US8971402B2 (en) 2008-06-17 2015-03-03 Cisco Technology, Inc. Processing of impaired and incomplete multi-latticed video streams
WO2018039179A1 (en) * 2016-08-22 2018-03-01 Intel IP Corporation Enhanced key frame protection on cellular networks

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1033875A2 (en) * 1999-02-23 2000-09-06 Canon Kabushiki Kaisha Recording and reproducing apparatus
EP1292138A2 (en) * 2001-08-31 2003-03-12 STMicroelectronics, Inc. Apparatus and method for indexing MPEG video data to perform special mode playback in a digital video recorder and indexed signal associated therewith
EP1324614A2 (en) * 1999-11-10 2003-07-02 NDS Limited System for data stream processing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1033875A2 (en) * 1999-02-23 2000-09-06 Canon Kabushiki Kaisha Recording and reproducing apparatus
EP1324614A2 (en) * 1999-11-10 2003-07-02 NDS Limited System for data stream processing
EP1292138A2 (en) * 2001-08-31 2003-03-12 STMicroelectronics, Inc. Apparatus and method for indexing MPEG video data to perform special mode playback in a digital video recorder and indexed signal associated therewith

Cited By (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008063881A3 (en) * 2006-11-13 2008-07-10 Scientific Atlanta System and method for signaling characteristics of pictures' interdependencies
US8416859B2 (en) 2006-11-13 2013-04-09 Cisco Technology, Inc. Signalling and extraction in compressed video of pictures belonging to interdependency tiers
US8875199B2 (en) 2006-11-13 2014-10-28 Cisco Technology, Inc. Indicating picture usefulness for playback optimization
US9716883B2 (en) 2006-11-13 2017-07-25 Cisco Technology, Inc. Tracking and determining pictures in successive interdependency levels
US9521420B2 (en) 2006-11-13 2016-12-13 Tech 5 Managing splice points for non-seamless concatenated bitstreams
US8571392B2 (en) 2006-12-18 2013-10-29 Hitachi Consumer Electronics Co., Ltd. Apparatus for video recording and reproducing, and method for trick play of video
CN101207776B (en) 2006-12-18 2012-05-02 株式会社日立制作所 Apparatus for video recording and reproducing, and method for trick play of video
EP1936974A1 (en) * 2006-12-18 2008-06-25 Hitachi, Ltd. Apparatus for video recording and reproducing, and method for trick play of video
EP2122934A2 (en) * 2007-02-22 2009-11-25 Symmetricom, Inc. Spatial and temporal loss determination in packet based video broadcast system in an encrypted environment
EP2122934A4 (en) * 2007-02-22 2013-09-25 Symmetricom Inc Spatial and temporal loss determination in packet based video broadcast system in an encrypted environment
EP2213000A1 (en) * 2007-07-16 2010-08-04 Telchemy, Incorporated Method and system for content estimation of packet video streams
EP2213000A4 (en) * 2007-07-16 2012-04-25 Telchemy Inc Method and system for content estimation of packet video streams
US8804845B2 (en) 2007-07-31 2014-08-12 Cisco Technology, Inc. Non-enhancing media redundancy coding for mitigating transmission impairments
US8958486B2 (en) 2007-07-31 2015-02-17 Cisco Technology, Inc. Simultaneous processing of media and redundancy streams for mitigating impairments
US8320747B2 (en) 2007-08-22 2012-11-27 Nippon Telegraph And Telephone Corporation Video quality estimation apparatus, video quality estimation method, frame type determination method, and recording medium
EP2077672A1 (en) * 2007-08-22 2009-07-08 Nippon Telegraph and Telephone Corporation Video quality estimation device, video quality estimation method, frame type judgment method, and recording medium
EP2077672A4 (en) * 2007-08-22 2010-01-06 Nippon Telegraph & Telephone Video quality estimation device, video quality estimation method, frame type judgment method, and recording medium
US8718388B2 (en) 2007-12-11 2014-05-06 Cisco Technology, Inc. Video processing with tiered interdependencies of pictures
US8873932B2 (en) 2007-12-11 2014-10-28 Cisco Technology, Inc. Inferential processing to ascertain plural levels of picture interdependencies
US8155207B2 (en) 2008-01-09 2012-04-10 Cisco Technology, Inc. Processing and managing pictures at the concatenation of two video streams
US8804843B2 (en) 2008-01-09 2014-08-12 Cisco Technology, Inc. Processing and managing splice points for the concatenation of two video streams
US8416858B2 (en) 2008-02-29 2013-04-09 Cisco Technology, Inc. Signalling picture encoding schemes and associated picture properties
US9819899B2 (en) 2008-06-12 2017-11-14 Cisco Technology, Inc. Signaling tier information to assist MMCO stream manipulation
US8886022B2 (en) 2008-06-12 2014-11-11 Cisco Technology, Inc. Picture interdependencies signals in context of MMCO to assist stream manipulation
US9350999B2 (en) 2008-06-17 2016-05-24 Tech 5 Methods and systems for processing latticed time-skewed video streams
US8705631B2 (en) 2008-06-17 2014-04-22 Cisco Technology, Inc. Time-shifted transport of multi-latticed video for resiliency from burst-error effects
US9723333B2 (en) 2008-06-17 2017-08-01 Cisco Technology, Inc. Output of a video signal from decoded and derived picture information
US8699578B2 (en) 2008-06-17 2014-04-15 Cisco Technology, Inc. Methods and systems for processing multi-latticed video streams
US9407935B2 (en) 2008-06-17 2016-08-02 Cisco Technology, Inc. Reconstructing a multi-latticed video signal
US8971402B2 (en) 2008-06-17 2015-03-03 Cisco Technology, Inc. Processing of impaired and incomplete multi-latticed video streams
US8259817B2 (en) 2008-11-12 2012-09-04 Cisco Technology, Inc. Facilitating fast channel changes through promotion of pictures
US8259814B2 (en) 2008-11-12 2012-09-04 Cisco Technology, Inc. Processing of a video program having plural processed representations of a single video signal for reconstruction and output
US8320465B2 (en) 2008-11-12 2012-11-27 Cisco Technology, Inc. Error concealment of plural processed representations of a single video signal received in a video program
US8681876B2 (en) 2008-11-12 2014-03-25 Cisco Technology, Inc. Targeted bit appropriations based on picture importance
US8761266B2 (en) 2008-11-12 2014-06-24 Cisco Technology, Inc. Processing latticed and non-latticed pictures of a video program
US8326131B2 (en) 2009-02-20 2012-12-04 Cisco Technology, Inc. Signalling of decodable sub-sequences
US8782261B1 (en) 2009-04-03 2014-07-15 Cisco Technology, Inc. System and method for authorization of segment boundary notifications
US9609039B2 (en) 2009-05-12 2017-03-28 Cisco Technology, Inc. Splice signalling buffer characteristics
US8949883B2 (en) 2009-05-12 2015-02-03 Cisco Technology, Inc. Signalling buffer characteristics for splicing operations of video streams
US8279926B2 (en) 2009-06-18 2012-10-02 Cisco Technology, Inc. Dynamic streaming with latticed representations of video
US9467696B2 (en) 2009-06-18 2016-10-11 Tech 5 Dynamic streaming plural lattice video coding representations of video
EP2315428A1 (en) * 2009-10-23 2011-04-27 Samsung Electronics Co., Ltd. Digital content processing apparatus and method of digital video receiver
US8549568B2 (en) 2009-10-23 2013-10-01 Samsung Electronics Co., Ltd Digital content processing apparatus and method of digital video receiver
EP2413535A1 (en) * 2010-07-30 2012-02-01 Deutsche Telekom AG Method for estimating the type of the group of picture structure of a plurality of video frames in a video stream
WO2012013655A1 (en) * 2010-07-30 2012-02-02 Deutsche Telekom Ag Method for estimating the type of the group of picture structure of a plurality of video frames in a video stream
US9241156B2 (en) 2010-07-30 2016-01-19 Deutsche Telekom Ag Method for estimating the type of the group of picture structure of a plurality of video frames in a video stream
KR101857829B1 (en) 2010-07-30 2018-05-14 도이체 텔레콤 악티엔 게젤샤프트 Method for estimating the type of the group of picture structure of a plurality of video frames in a video stream
WO2018039179A1 (en) * 2016-08-22 2018-03-01 Intel IP Corporation Enhanced key frame protection on cellular networks

Similar Documents

Publication Publication Date Title
US6771657B1 (en) Non real-time delivery of MPEG-2 programs via an MPEG-2 transport stream
US20070234395A1 (en) Speeding up channel change
US6925180B2 (en) PC card recorder
US20090323822A1 (en) Support for blocking trick mode operations
US20090169181A1 (en) Application enhancement tracks
US6952521B2 (en) Methods and apparatus for editing digital video recordings, and recordings made by such methods
US20100215338A1 (en) Signalling of decodable sub-sequences
US20050097614A1 (en) Bi-directional indices for trick mode video-on-demand
US20030208771A1 (en) System and method for providing multi-perspective instant replay
US7218635B2 (en) Apparatus and method for indexing MPEG video data to perform special mode playback in a digital video recorder and indexed signal associated therewith
US20030058948A1 (en) Method of setting a system time clock at the start of an mpeg sequence
US20030169815A1 (en) Performing personal video recording (PVR) functions on digital video streams
US20090310934A1 (en) Picture interdependencies signals in context of mmco to assist stream manipulation
US20090257508A1 (en) Method and system for enabling video trick modes
US20040062398A1 (en) Method and system for key insertion for stored encrypted content
US20050157714A1 (en) Scrambled packet stream processing
US7106749B1 (en) System for data stream processing
EP1388862A1 (en) Method and apparatus to facilitate the implementation of trick modes in a personal video recording system
US20030095790A1 (en) Methods and apparatus for generating navigation information on the fly
US20080115175A1 (en) System and method for signaling characteristics of pictures' interdependencies
US7177522B2 (en) System and method for personal video recording
US20060277581A1 (en) Local entity and a method for providing media streams
US20030081939A1 (en) Method for recording a digital broadcast program and time-based playback of a recorded broadcast program and apparatus therefor
WO2002015579A1 (en) Method and apparatus for enabling random access to individual pictures in an encrypted video stream
US20070258586A1 (en) Personal video recorder having dynamic security functions and method thereof

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWW Wipo information: withdrawn in national office

Country of ref document: DE

NENP Non-entry into the national phase in:

Ref country code: DE

NENP Non-entry into the national phase in:

Ref country code: RU

WWW Wipo information: withdrawn in national office

Country of ref document: RU

122 Ep: pct app. not ent. europ. phase

Ref document number: 06728033

Country of ref document: EP

Kind code of ref document: A1