KR100449200B1 - Computer implementation method, trick play stream generation system - Google Patents

Abstract

A system and method for generating trick playback video streams such as fast forward and fast reverse video streams from MPEG compressed normal playback bitstreams. The system filters the bitstream by receiving a compressed normal playback bitstream and extracting and storing only a portion of the bitstream. The system extracts I frames and sequence headers, including all weighting matrices, from the read back MPEG bitstream and stores this information in a new file. The system then assembles or combines the filtered data in the proper order to produce a single assembled bitstream. The system also ensures that the weighting matrix corresponds to each I frame properly. This creates a bitstream consisting of a plurality of sequence headers and I frames. The assembled bitstream is then MPEG-2 decoded to produce a new video sequence that includes only one of every X pictures of the original uncompressed normal playback bitstream. The picture stream thus output is then re-encoded with the respective MPEG parameters required for the trick playback stream to generate a trick playback stream that is a valid MPEG encoded stream but contains only one of every X frames. Thus, the present invention creates a compressed trick-play video stream requiring reduced storage and reduced data transmission bandwidth.

Description

Computer implementation method, trick play stream generation system

Reference

The following references are incorporated herein by reference.

The ISO / IEC MPEG specification, referred to as ISO / IEC l38l8, is incorporated herein by reference.

Field of invention

FIELD OF THE INVENTION The present invention relates generally to video-on-demand systems and video compression, in particular fast forward compressed from a normal play compressed video bitstream and A system and method for generating fast reverse video bitstreams.

The video-on-demand system allows a plurality of users or viewers to selectively view movies or other audio / video sequences stored on one or more video servers or media servers. Video servers are connected to a plurality of users or subscribers via a data transmission channel such as a broadcast network. For example, video servers may be connected to a plurality of users or subscribers via a broadcast cable system or a satellite broadcast system. Video servers store a plurality of movies or other audio / video sequences, and each user can select one or more movies from the video servers for viewing. Each user includes a television or other viewing device as well as associated decoding logic for selecting and watching desired movies. When the user selects a movie, the selected movie is sent to each user's television through one of the data transmission channels.

Full-motion digital video requires large amounts of storage and data transmission bandwidth. Accordingly, video-on-demand systems use various forms of video compression algorithms to reduce the amount of storage required and the data transfer bandwidth. In general, other video compression methods exist for still graphic images and full-motion video. Video compression methods for still graphic images or single video frames are referred to as intra frame compression methods, and compression methods for athletic video are referred to as interframe compression methods.

Examples of video data compression for still graphic images are run-length-encoding (RLE) and Joint Photographic Expert Group (JPEG) compression. The RLE compression method works by testing a duplicated pixel within a single line of the bitmap and storing the number of consecutive duplicate pixels rather than data for that pixel itself. JPEG compression is a group of related standards that provide a lossless (no deterioration of the image) or lossy (unrecognizably severe degradation) compression form. Although JPEG compression was designed for the compression of still images rather than the original video, JPEG compression is used in some athletic video applications.

In contrast to compression algorithms for still images, most video compression algorithms are designed to compress full motion video. Compression algorithms for athletic video use the concept referred to as interframe compression, which includes storing only the differences between successive frames in the data file. Interframe compression generally stores the entire image of a key frame or reference frame in an appropriately compressed format. Consecutive frames are compared with key frames, and only the differences between the key frame and the consecutive frames are stored. Periodically, new key frames are stored, such as when new scenes are displayed, and successive comparisons start from these new reference points. Note that the interframe compression rate remains constant while the video quality changes. Alternatively, interframe compression rates can be content-dependent, i.e. compression is less efficient if the video clip being compressed includes many abrupt transitions from one image to another. do. Examples of video compression using interframe compression techniques are MPEG, DVI and Indeo, among others.

MPEG background

The compression standard, referred to as Moving Pictures Experts Group (MPEG) compression, is a set of methods for the compression and decompression of full motion video images using the interframe compression technology described above. MPEG compression uses both motion compensation and discrete cosine transform (DCT) processes and can produce compression ratios of 200: 1 or more.

The MPEG standard requires that sound be recorded simultaneously with the video data, and the video and audio data are interleaved in a single file to attempt to keep the video and audio synchronized during playback. Audio data is also commonly compressed, and the MPEG standard describes audio compression methods such as MPEG Layer II, also known as Philips trade name 'MUSICAM'.

In most video sequences, the background is relatively stable while motion occurs in the foreground. The background may move, but most consecutive frames in the video sequence are redundant. In generating the MPEG stream, the MPEG encoder generates not only B frames but also I or intra frames and P or predicted frames. I frames contain video data for the entire frame of video and are typically located every 10 to 15 frames. P frames only include changes to previous I or P frames. Both I and P frames are used as references for subsequent frames. In general, for frame (s) following an I or P frame, ie frames following a reference frame, only a small portion of these frames differs from the corresponding portions of each reference frame. Therefore, for these frames only the differences are captured, compressed and stored.

After the I frames are generated, the MPEG encoder divides each I frame into a grid of l6 × l6 pixel squares called macro blocks. Each one frame is divided into macro blocks to perform motion compensation. Subsequent pictures after the I frame are also divided into the same macro blocks. The encoder then searches for an exact or near exact match between the reference picture macro block and the macro block in subsequent pictures. If a match is found, the encoder sends a vector motion code or motion vector. The vector motion code or motion vector only contains information about the difference between the I frame and each next picture. Blocks in the following pictures that do not change anything with respect to the reference picture or the block in the I frame are ignored. Therefore, the amount of data actually stored for these frames is significantly reduced.

After the motion vectors are generated, the encoder then tracks the changes using spatial redundancy. Therefore, after finding changes in the location of the macro blocks, the MPEG algorithm further reduces the data by describing the difference between the corresponding macro blocks. This is done through a mathematical process referred to as discrete cosine transformation or DCT. This process divides the macro block into four sub-blocks that look for changes in color and brightness. Human perception is more sensitive to brightness changes than color changes. Therefore, the MPEG algorithm puts more effort into reducing color space than brightness.

The MPEG stream includes three picture types referred to as intra (I) frames, predictive (P) frames and bi-directional interpolated (B) frames. Intra frames provide entry points to a file for random access and are generally only compressed appropriately. The predictive frames are encoded relative to the previous frame, ie the previous intra frame or the predictive frame. In general, prediction frames receive a fairly large amount of compression and are used as criteria for future prediction frames. Bidirectional pictures contain the largest amount of compression and require both past and future criteria to be encoded. Bidirectional frames are never used for references to other frames.

Each picture or frame also includes a picture header that identifies the frame and includes information about that frame. The MPEG standard also includes sequence headers that identify the beginning of a video sequence. Sequence headers are only required once before the start of the video sequence. However, the MPEG-2 standard allows a sequence header to be delivered before any I frame or P frame. The sequence header contains information about the video sequence, including frame rate and picture size, among other information.

MPEG bitstreams used in digital television applications generally include a sequence header before every I frame and P frame. This is necessary to facilitate channel surfing between different video channels, which is an important user requirement. In general, when a user switches to a new channel, the video for that new channel can only be displayed until the next sequence header appears in the bitstream. This is because the sequence header contains important information about the video sequence required by the decoder before the sequence can be displayed. If the sequence header was not included before each I frame and / or P frame, when the user switches to a new channel, the video for that new channel will probably not be immediately displayed, i.e. the video will be It may not be displayed until the header.

The MPEG encoding stream also includes weighting matrices used to decode I frames in the MPEG bitstream. Each weighting matrix contains a matrix of coefficients applied to other parameters of the discrete cosine transform (DCT) used to encode the frame. New weight matrix values are included at the beginning of the old video sequence, and these values are used for each frame until a subsequent new weight matrix appears in the MPEG stream. Weighting matrices are typically included in sequence headers or picture headers. However, weight matrices can be inserted in P or B frames.

Trick play streams

In an interactive video-on-demand system, it is highly desirable to allow the user to selectively fast forward and / or fast reverse through the movie being watched. Therefore, some video-on-demand systems include fast forward and fast reverse streams, referred to as trick play streams for each movie. If the user wants to fast forward or reverse through the movie, the user selects the fast forward or fast reverse option. Each fast forward or fast reverse trickplay stream is then delivered to the user at the appropriate point being watched by the user, thus simulating the fast forward or fast reverse of the movie being watched.

Interactive video-on-demand systems that include trick play streams require methods for generating trick play streams from a regular play bitstream. One current method for generating fast forward and fast reverse bitstreams from a normal playback bitstream includes using a look-up table with multiple streams. The lookup table contains a plurality of indices that refer to respective I frames, and the video server attempts to jump from the indices to the indices and plays only I-frames in each jump. . In other words, the video server indexes the lookup table to play only I-frames for fast forward and fast reverse trick play streams. One problem with this approach is that while fast forward or fast reverse is required, a significant considerable burden is imposed on the video server when performing table lookups and jumping from indicator to indicator in progress. This method also has the problem of associated bit rate expansion.

Another known method for generating trick-play fast forward and fast reverse bitstreams does not include the AC coefficients of the DCT, but generates a video stream that includes only the DC coefficients. This creates a blocky trick-play stream, so it is less desirable than other trick-play stream generation methods.

Therefore, an improved system and method are needed to efficiently generate trick-play video streams, i.e., fast forward and fast reverse video streams, from a compressed normal playback bitstream.

1 illustrates a computer system for generating video trick playback streams in accordance with the present invention.

1A is a block diagram illustrating the computer system of FIG. 1.

2 is a flow chart illustrating the operation of the present invention.

3 is a flow chart showing the operation of the filter of FIG.

4 is a flow chart showing operation of the verifier / stator of FIG.

5 is a flowchart illustrating operation of the embodiment according to the present invention.

6A-6C are flowcharts of a preferred embodiment for generating a reverse trick play stream in accordance with the present invention.

Summary of the Invention

The present invention includes a system and method for generating trick-play video streams, ie fast forward and fast reverse video streams, from a compressed normal playback bitstream. The present invention efficiently creates a compressed trick-play video stream that requires reduced storage and reduced data transmission bandwidth requirements. The invention also does not require real time processing of video data, such as index look-ups.

The system first receives a compressed normal playback bitstream stored in local media or received from a remote location. The system then filters the bitstream only by extracting and saving portions of the bitstream. The system preferably extracts I-frames and sequence headers containing all weighting matrices from the MPEG bitstream and stores this information in one or more new files. Therefore, the filtering removes or deletes portions of the MPEG data stream including prediction (P) frames and bi-directional (B) frames.

The system then aggregates, ie assembles, or combines the filtered data in forward or reverse order to produce a single assembled bitstream. The system also ensures that the weighting matrices correspond appropriately to the respective I-frames. For fast forward trick-play streams, the assembled bitstream contains sequence headers, I frames and respective weighting matrices in the proper time or sequence as shown in the original MPEG stream. For fast reverse trick play bitstream streams, the system reverses in order of header / I frame groupings or tuples to produce a reverse play stream. This creates an assembled bitstream comprising a plurality of I-frames and sequence headers with associated weight matrices.

The assembled bitstream is then MPEG-2 decoded to produce a new video stream. The new video sequence contains only one of all X pictures or frames of the original uncompressed normal playback bitstream, where 1 / X is the frequency of the I frames in the original compressed normal frame stream. This output picture stream is then re-encoded with the desired MPEG parameters for the trick play stream, thus producing a trick play stream that is a valid MPEG encoded stream. When this new MPEG encoded trickplay stream is decoded, the result is a fast forward or fast reverse video sequence containing only one of all X frames of the original uncompressed regular play bitstream.

Therefore, the present invention produces trick play streams more efficiently from the compressed normal play bitstream. The resulting trick play stream is a valid MPEG encoded stream and therefore has reduced storage and data transfer data bandwidth requirements, and this trick play stream can be decoded with known operation on any MPEG decoder.

When the following detailed description of the preferred embodiment is considered in connection with the following drawings, a better understanding of the present invention can be obtained.

Detailed description of embodiments

Referring to FIG. 1, a system for generating trick playback video streams from a compressed normal playback bitstream is shown. The system preferably generates trick playback streams for use in video-on-demand systems. However, the present system may be used to generate trick play streams for use in any of several types of applications, as desired.

As shown, in one embodiment the trick play generation system includes a general purpose computer system 60. Computer system 60 receives the compressed normal play bitstream and generates one or more trick play streams. In the present invention, the term "trick play streams" refers to fast forward and / or fast reverse video streams, preferably compressed streams, which are generated from a normal play bitstream and are compressed normal play bitstreams. Is generated from

The computer system 60 preferably includes several standard components, including one or more processors, one or more buses, a hard drive, and memory. 1A, a block diagram illustrating the apparatus included in the computer system of FIG. 1 is shown. 1A is for illustrative purposes, and note that other computer architectures may be used as needed. As shown, the computer system includes at least one processor 80 connected to the system memory 84 through chipset logic 82. The chipset 82 preferably includes a Peripheral Component Interconnect bridge (PCI) bridge to the PCI bus 86. The MPEG decoder 74 and the MPEG encoder 76 are shown connected to the PCI bus 86. In another embodiment, MPEG decoding and encoding is performed in software. Various other components may be included in the computer system, such as video 88 and hard drive 90.

Referring again to FIG. 1, in a preferred embodiment the computer system 60 includes or is connected to one or more digital storage devices or media storage devices. For example, in the embodiment of FIG. 1, computer system 60 is coupled to media storage unit 62 via cable 64. The media storage unit 62 includes one or more CD-ROM drives and / or one or more digital video disc (DVD) storage units for storing digital video. The computer system may include one or more internal CD-ROM drives and may be connected to one or more separate digital video disc (DVD) storage units. The computer system 60 may also be connected to other forms of digital or analog storage devices when needed.

The compressed normal playback bitstream will be included in storage media such as a CD-ROM or a digital video disc (DVD). In such an embodiment, storage media comprising a compressed normal playback bitstream is inserted into each storage device included or coupled to computer system 60, and the computer system 60 is compressed from the storage media. Read the playback bitstream. For example, a compressed normal playback bitstream can be included on a CD-ROM, which is inserted into the media storage unit 62 or the CD-ROM drive of the computer system 60, so that the computer system 60 ) Accesses the compressed normal playback bitstream. In addition, the compressed normal playback bitstream may be included in the DVD, which is read from the DVD by the computer system 60.

Alternatively, the compressed normal playback bitstream may be received from an external source such as a remote storage device or a remote computer system. In this embodiment, the computer system is preferably an input device such as an Asynchronous Transfer Mode (ATM) adapter card or an Integrated Services Digital Network (ISDN) terminal adapter, or other digital data receiver, for receiving compressed normal playback bitstreams. It includes. The compressed normal playback bitstream is stored or received in analog format and converted into digital data, either external to computer system 60 or internal to computer system 60.

As mentioned above, computer system 60 generates a trick-play video stream from the compressed normal playback bitstream. As will be discussed below, computer system 60 performs MPEG-2 decoding and encoding functions, as well as filtering and verifier / fixer functions. In a preferred embodiment, the filtering and verifier / stator functions are performed in software in computer system 60, where the software is represented by floppy disk 72. In another embodiment, computer system 60 includes dedicated hardware to perform one or both of the filtering and verifier / stator functions.

In the embodiment of FIG. 1, computer system 60 preferably includes a hardware MPEG (MPEG-2) decoder card 74 and a hardware MPEG (MPEG-2) encoder card 76. The MPEG decoder 74 and the MPEG encoder 76 include adapters connected to the bus of the computer system, but are shown as being outside the computer system 60 in FIG. 1 for convenience of description. Alternatively, one or both of the MPEG decoder and MPEG encoder are external to computer system 60. In another embodiment, computer system 60 performs one or both of MPEG decompression and MPEG compression in software, where the software is shown as floppy disk 72. In this embodiment, computer system 60 does not include a hardware MPEG decoder or MPEG encoder.

Note that a system for generating trick-play video streams may include two or more interconnected computers when needed. The system for generating a trick-play video stream may include dedicated hardware used independently or in conjunction with a general purpose programmable computer. Note that any of several types of systems may be used to generate the trick-play video stream according to the present invention.

Flowchart

2, a diagram illustrating the operation of the present invention is shown. As shown, the present invention includes a filter operation 102, a verifier / stator operation 104, an MPEG-2 decode operation, and an MPEG-encoding operation. As detailed above, each of these operations will be performed in hardware or software when needed.

As shown, the system of the present invention receives a normal playback bitstream. A normal play bitstream is a bitstream of video data used to represent a video sequence, such as a television segment or a movie, on a screen such as a television or computer system. More precisely, filter 102 extracts all weighting matrices, as well as I-frames and sequence headers, from the MPEG bitstream and stores this new information in a new file. Thus, filter 102 removes all the rest of the MPEG bitstream except for I-frames, sequence headers, and weight matrices. Thus, filter 102 deletes the portion of the MPEG data stream that includes the prediction (P) frame and the bidirectional (B) frame.

As described above, the MPEG encoded bitstream includes a plurality of I-frames that are intracoded pictures. Each I frame contains video data for the entire frame of video and is periodically located within the sequence. P and B frames contain change information for previous or subsequent frames. Each picture or frame also includes a picture header that identifies the frame and includes information about the frame. The MPEG encoded bitstream further includes one or more sequence headers which, among other information, contain some constant information about the video sequence, including frame rate and picture size.

The MPEG encoded stream also includes weighting matrices used to reconstruct pixel values from the DCT coefficients of the MPEG bitstream. Each weighting matrix comprises a matrix of coefficients applied to different parameters of the discrete cosine transform (DCT) used to encode the frame. The decoder's matrices are reinitialized at the beginning of every video sequence, and these values are used for each frame until a subsequent new weighting matrix appears in the MPEG stream. Note that MPEG encoded streams contain both interframe and intraframe matrices. The trick play generation system and method utilizes only intraframe matrices to generate a trick play stream.

Weighting matrices are typically included in a picture header for each I frame, or in a sequence header before each I frame. In some cases, however, the weighting matrix for each I frame may not be included in the I frame picture header or sequence header, but may be included in a previous P or B frame. In other words, in some cases, new values of the weighting matrix for each I frame may be included in a previous P or B frame. This occurs when a P or B frame contains one or more macroblocks encoded with I frame syntax. The filter 102 thus examines the P and B frames for the weighted matrix and stores these matrices for use by the verifier / stator block 104.

As shown, filter 102 provides a stored output that includes a portion of an MPEG stream to verifier / stator 104. Verifier / corrector 104 assembles or combines the data generated by filter 102 into a single bitstream. Verifier / corrector 104 assembles or connects the stored data in the proper order to produce the assembled bitstream. Verifier / corrector 104 uses the information provided by filter 102 to ensure that the sequence header corresponds to the appropriate I frame.

Verifier / corrector 104 also allows weighting matrices found in the stream, such as in P or B frames, to be included in the associated stream and correspond appropriately to each I frame. In other words, the verifier / corrector 104 also ensures that the weighted matrix or quantization matrix changes are properly integrated into the newly assembled bitstream. In the preferred embodiment, the verifier / corrector 104 generates new sequence headers for the weighted matrices found in the P and B frames and associates these new headers with the correct I frames.

For fast forward trick-play streams, the assembled bitstream includes sequence headers, I frames and respective weighting matrices in the appropriate time or sequence order when they are represented in the original MPEG stream. For the fast reverse trick play bitstream sequence, the verifier / corrector 104 generates an inverse play sequence by reversing the sequence header / I frame grouping or header / I frame aggregation order. Thus, the verifier / corrector 104 also rearranges the sequence header / I frame set in the reverse order to ensure that the matrix corresponds to each I frame.

Thus, the output of verifier / corrector 104 is an assembled bitstream that includes a plurality of sequence headers and I-frames. As such, the verifier / corrector 104 generates a bitstream that is a valid MPEG encoded frame.

The output assembly bitstream is provided to a decoder block 106, which is preferably an MPEG-2 decoder block 106. The MPEG-2 decoder block 106 decodes the assembled bitstream, i.e. each I frame, to produce a new video sequence. The new video sequence is an uncompressed sequence and contains only one in every X picture of the original uncompressed normal playback stream. Thus, if the original normal play bitstream included in an I frame is included at one frequency every X frames, the new video sequence contains only one of every X picture or frame of the original uncompressed normal play stream. . For example, if the original MPEG-2 compressed bitstream received at the input of the filter contains I frames every 7 frames, MPEG-2 decoder block 106 contains uncompressed video data and Create a bitstream that contains only one of every seven frames of the uncompressed bitstream of.

The picture stream thus output is then provided to encoder block 108, where the stream is re-encoded with each MPEG parameter required for the trick play stream. These MPEG parameters include bit rate, picture size and others. In the preferred embodiment, the encoder block 108 encodes the stream with a smaller picture size and lower data rate than the normal playback stream for reduced data storage and transmission bandwidth.

MPEG-2 encoding 108 produces a trick-play stream that is a valid MPEG encoded stream, but contains only one X frame of the original stream. Therefore, the trick play stream output from the encoder 108 includes I frames, P frames, and B frames. When this new MPEG encoded trick playback system is then sent to the user and decoded by the MPEG decoder, the resulting bitstream includes a stream that contains only one X frame of the original uncompressed normal playback bitstream. do.

Figure 3-Filter Flowchart

Referring to FIG. 3, a flow chart showing the operation of filter 102 according to one embodiment is shown. In step 202, filter 102 examines a block of MPEG data. It is assumed here that the block of MPEG data is a sequence header or a picture header. If the MPEG data being examined is a sequence header, return to step 212 and start checking for the next block of MPEG data.

If the frame or data being examined in step 202 is a picture header or picture, then in step 214 the filter 102 examines the picture header and subsequent frames corresponding to the picture header. If the frame or data being examined is an I frame, then in step 222 the filter 102 stores the picture header and the I frame. The filter 102 also stores, at step 224, corresponding data (correspondence data) representing the picture header or each sequence header corresponding to the stored I frame. After storing the I frame and corresponding data, the filter 102 returns to step 202 to examine the next block of MPEG data.

If the frame being examined is a P or B frame, then at step 232 the filter 102 checks whether the P or B frame, respectively, contains a weighting matrix. If not, no P or B frame data is stored, and the filter 102 returns to step 202 to examine the next block of MPEG data. If the P or B frame being examined includes a weight matrix, then at step 234 the filter 102 stores the weight matrix. In step 236 the filter 102 associates the weighting matrix with each I frame, i. In step 236 the filter 102 preferably also stores corresponding data representing each I frame corresponding to the weighted matrix. After filter 102 has stored the weighting matrix and corresponding data, filter 102 returns to step 202 to examine the next block of MPEG data.

Thus, filter 102 examines all headers and frames of the MPEG stream. This is necessary because weighting matrices can occur in any header or frame of the MPEG stream. Filter 102 includes only a sequence header and a weighting matrix that can be located anywhere in the MPEG stream, such as I frames and P or B frames. The filter 102 does not include P frame or B frame data. Filter 102 also associates a sequence header and weighting matrix with each corresponding I frame.

Thus, if the matrix is included in one of the intervening P or B frames, the filter 102 stores this matrix in a file for use when the trick playmaster sequence is reconstructed. As will be discussed in more detail below, during construction of the trick play stream, the present invention creates a dummy sequence header or otherwise inserts a new matrix into the assembled bitstream.

After the sequence header or frame is checked, filter 102 checks the next block of MPEG data, and this operation is repeated. In addition, filter 102 examines all headers and frames for MPEG sequences, storing sequence headers, I frames, and weighting matrices, but not P and B frames. Thus, filter 102 stores a portion of an MPEG data stream that includes only a sequence header, picture header, I frames, and weighted matrices.

In one embodiment, the results of filter 102 are combined to generate the trick play bitstream. As such, it should be noted that if the results of filter 102 are simply combined, the bitstream cannot be a valid MPEG bitstream. In a preferred embodiment, the present invention is because an MPEG compressed bitstream must be able to be delivered through a standard MPEG decoder.

Figure 4-Verifier / Stator Flowchart

Referring to FIG. 4, a flow diagram illustrating the operation of the verifier / stator 104 assembling the trick play stream is shown. In step 302 the verifier / stator 104 examines a block of stored MPEG data, i.e., a block of MPEG data stored by the filter 102. It should be noted that a block of MPEG data is one of a sequence header, a picture header, an I frame, or a weighted matrix. If the MPEG data being examined by the validator / corrector 104 in step 302 is a sequence header, picture header, or I frame, then in step 304 the validator / corrector 104 is passed to the filter 102. Corresponding data generated by the module is examined to associate the picture header or sequence header with the appropriate I frame. In step 306 the verifier / stator 104 groups or connects I frames and their respective picture headers and / or sequence headers, where these groupings are referred to as header / I frame sets. In step 308 the verifier / corrector 104 connects the new header / I frame set to the assembled bitstream to assemble the new bitstream. After step 308 is performed, verifier / corrector 104 returns to step 302 to examine the next stored block of MPEG data, and the operation is repeated.

If the system generates a fast forward stream, then at step 308 the verifier / stator 104 identifies a group of I frames and their respective picture headers and / or sequence headers, referred to as a header / I frame set. Connect in forward time order, that is, in the order in which they appear in the original stream. If the system generates a fast reverse stream, then at step 308 the verifier / stator 104 connects the header / I frame set in reverse chronological order. Thus, for a fast reverse sequence, the picture header and the sequence header corresponding to each I frame are continuously connected at a time prior to their respective I frames. However, header / I frame grouping or aggregation is connected in reverse chronological order.

If the MPEG data being examined by the verifier / stator 104 in step 302 is a weighted matrix, then the verifier / stator 104 in step 312 preferably generates a new sequence header comprising the weighted matrix. do. Validator / corrector 104 then proceeds to step 304 where validator / corrector 104 generates corresponding data generated by filter 102 and generates a new sequence header in step 306 for each. Group with I frames. In step 306 the verifier / stator 104 positions the newly generated sequence header before the corresponding I frame. In step 308 the verifier / corrector 104 connects the new sequence header / I frame set to the bit stream that is assembled to assemble the new bitstream.

If the I frame does not include a weight matrix, the verifier / stator 104 uses a weight matrix or a default value from the previous I frame. In the preferred embodiment, the default matrix used is implicitly determined by the fact that the stream does not explicitly contain a matrix, and this operation is part of the MPEG standard.

Other embodiments

In a first alternative embodiment of the invention, for a fast forward trick play stream, the trick play generation system includes P frames and I frames in the fast forward trick play stream. This embodiment is preferably used for a 2x, 3x or 4x fast forward trick-play stream, preferably for 3x fast forward streams. In this embodiment, the system examines the MPEG stream against the interframe matrix of B frames and moves to the P frames following these interframe matrices. Note that this embodiment is only possible for fast trick-play streams because the P frames of the original MPEG stream contain only changes to the previous P frames.

5, a block diagram illustrating the operation of the present invention in accordance with another embodiment is shown. As shown, this embodiment of the present invention includes an MPEG-2 decode operation 502, an extraction operation 504, and an MPEG-2 encoding operation 506. Each of these operations will be performed in hardware or software as needed.

As shown, the system of the present invention receives a normal bitstream, preferably an MPEG compressed normal playback bitstream. This compressed normal playback bitstream is provided to a decoder block 502, preferably an MPEG-2 decoder block 502. The MPEG-2 decoder block 502 decodes each frame to produce the original uncompressed video sequence. The original uncompressed video sequence is then provided to extraction block 504 which extracts one of every X frames of the video sequence. The extraction block 504 also connects these extracted frames in forward time order or in reverse time order. These connected frames include a bitstream that contains only one of every X pictures of the original uncompressed normal playback stream. Thus, if an I frame is included at one frequency for every X frames of the original normal play bit stream, the new video sequence contains only one of every X picture or frame of the original uncompressed normal play bit stream.

The picture stream thus output is then provided to an encoder block 506, where it is re-encoded with the respective MPEG parameters required for the trick play stream. These MPEG parameters include bit rate, picture size and others. The MPEG-2 encoder 506 generates a trick play stream that is a valid MPEG encoded stream but contains only one of every X frames. When this new MPEG-encoded trickplay stream is sent to the user and decoded by the MPEG decoder, the resulting bit stream contains a stream that contains only one of every X frames of the original uncompressed normal play bitstream. .

Reverse trick play generation-another embodiment

Referring to Fig. 6, another preferred embodiment for generating a reverse trick play stream according to the present invention is shown. FIG. 6 is shown in three parts of FIGS. 6A, 6B, and 6C for convenience. In the embodiment of Figure 6, the reverse trick play stream is created by scanning the video stream for the first time at the end. This embodiment also uses memory stacks that temporarily store groupings or sets of MPEG data so that they are stored in reverse playback trick streams in the proper order.

As shown in FIG. 6, an initialization state is performed in step 602 where the stack is cleared. In step 604 a search is performed for the first picture start code of the video sequence. In step 604 the search is performed beginning at the end of the video stream. If the start code of the first picture is found in the search from the end to the end, then at step 606 a marker is pushed onto the stack. As will be discussed below, this marker is used to identify different blocks or portions of the video stream. After step 606, the search state begins.

In step 612, the method retrieves a start code from the video stream. In step 614, the method determines if the end of the file condition is found during the search for start code in step 612. If found, in step 616 the output stream is closed, the program exits and the operation ends. If the end of the file condition is not found in step 614, the method in step 620 presumably finds the start code of the video stream.

It will be appreciated that the found start code includes the beginning of a user data block, the beginning of an extension block, the beginning of a B or P frame picture header block, or the beginning of an I frame picture header. As shown in FIG. 6, different operations are performed in step 620 depending on what type of start code is found. Note that the circular block in FIG. 6 includes headings and is not a functional step.

If the start code found in step 620 is the beginning of the user data block, the method in step 622 adjusts the contents of the user data block if necessary. The content of the user data block is adjusted to comply with the possible new parameters required for preparing the track playback stream described above. After the content has been adjusted in step 622, the method in step 624 pushes the coordinates of the user data block onto the stack. The operation then returns to step 612 where a search for a new start code is performed as described above.

If the start code found in step 620 is the beginning of an extension block, then in step 632 the present invention pushes the extension block onto the stack. The method then returns to step 612 to retrieve the next start code.

If the start code found in step 620 is the beginning of a B or P frame picture header block, the method in step 642 pops all the coordinates on the stack until an indication is detected. In other words, if the start of a B or P frame picture header block is detected, the mode coordinates of the stack above the marker are removed or popped from the stack in step 642. The marker is then pushed back to the stack or back to step 644. The operation then returns to step 612 where a search for a new start code is performed as described above.

If the start code found in step 620 is an I frame picture header, the method in step 652 adjusts the I frame picture header information if necessary. The I frame picture header information is adjusted to follow the possible new parameters used to prepare the track playback stream, as described above. After adjusting the I frame picture header, the method in step 654 pushes the coordinates of the I frame picture header block onto the stack. In step 656, the method pops or removes the coordinates pushed onto the stack until the marker is detected. In step 658, the method writes the data of the corresponding video stream to the output reverse trick play stream as each set of coordinates is popped. Here, when the coordinates are popped from the stack in step 656, the steps 656 and 658 are performed sequentially or simultaneously, and when the coordinates are popped from the stack, data from the corresponding video stream is written to the outputted reverse playback stream. Please note.

In step 656, all the coordinates are popped from the stack, and in step 658, recorded as an output trick trick stream, the method in step 660 pushes the marker back onto the stack. In step 662, the method retrieves a first sequence header start code. If this first sequence header start code is found, the method returns to step 612 to retrieve the next start code, which operation is repeated as described above.

Accordingly, the present invention includes a system and method for generating a trick play video stream from a compressed normal play video stream. The present invention examines each header or frame of the MPEG sequence and stores the sequence header, I frame and associated weight matrix. The system then intelligently assembles a new fast forward or fast reverse bitstream containing these stored contents. The newly assembled bit stream is then decoded to produce a plurality of uncompressed frames. These uncompressed frames are then re-encoded according to the MPEG standard to produce a new MPEG stream which is a trick-play fast forward or fast reverse stream.

Although the systems and methods of the present invention have been described in connection with the above-described embodiments, they are not intended to be limited to the specific forms set forth herein, but may be rationally included within the spirit and scope of the invention as defined by the appended claims. Intended to encompass modifications, variations, and the like.

Claims (16)

A computer implemented method for generating trick playback streams from a compressed normal play bitstream, Receiving a compressed normal play bitstream, wherein the compressed normal play bitstream comprises a plurality of intracoded frames and a plurality of intercoded frames; , Extracting the intracoded frames from the compressed normal playback bitstream, wherein the extracting comprises storing the intracoded frames in a storage memory; Assembling the intracoded frames to form an assembled bitstream after the extracting step; Decoding the assembled bitstream to produce a plurality of uncompressed frames, and Encoding the plurality of uncompressed frames after the decoding step to produce a compressed trick play bitstream, wherein the compressed trick play bitstream includes only a subset of the frames of the regular play bitstream; Computer implementation method. The method of claim 1, The compressed normal playback bitstream includes the plurality of intracoded frames at a specific frequency, And said extracting comprises extracting data bits corresponding to said intracoded frame at said particular frequency. The method of claim 1, The compressed normal playback bitstream includes a plurality of sequence headers including information about at least a plurality of the intracoded frames, The extracting step extracts the sequence headers from the compressed normal playback bitstream, wherein the extracting step includes storing the sequence headers in the storage memory, And said assembling includes assembling said sequence headers and said intracoded frames to form said assembled bitstream. The method of claim 1, The method generates a trick play fast forward bitstream, And said assembling comprises assembling said intracoded frames in a forward time order. The method of claim 1, The method generates a trick play fast reverse bitstream, And said assembling comprises assembling said intracoded frames in reverse time order. The method of claim 1, The compressed normal playback bitstream includes a plurality of matrices corresponding to the intracoded frames, The method, Positioning the matrices in the compressed normal play bitstream; Assembling the intracoded frames to form the assembled bitstream comprises including the matrices in the assembled bitstream. The method of claim 1, Each of the plurality of matrices corresponds to one of the intracoded frames, And said assembling comprises assembling each of said matrices with corresponding ones of said intracoded frames. The method of claim 1, The compressed normal playback bitstream is an MPEG compressed bitstream, Decoding the assembled bitstream comprises MPEG decoding the assembled bitstream to produce the plurality of uncompressed frames, And encoding the plurality of uncompressed frames comprises MPEG encoding the plurality of uncompressed frames to produce an MPEG compressed trickplay bitstream. A system for generating trick playback streams from a compressed normal playback bitstream, A storage medium for storing a compressed normal playback bitstream, the compressed normal playback bitstream including a plurality of intracoded frames and a plurality of intercoded frames; A filter for extracting the intracoded frames from the compressed normal playback bitstream; A storage memory for storing the extracted intracoded frames; A verifier / fixer for assembling the stored intracoded frames to form an assembled bitstream, A decoder for decoding the assembled bitstream to produce a plurality of uncompressed frames, and An encoder that encodes the plurality of uncompressed frames to produce a compressed trickplay bitstream, the compressed trickplay bitstream comprising only a subset of the frames of the normal playback bitstream. , Trick play stream generation system. The method of claim 9, The compressed normal playback bitstream includes the plurality of intracoded frames at a specific frequency, And the filter extracts data bits corresponding to the intracoded frames at the specific frequency. The method of claim 9, The compressed normal playback bitstream includes a plurality of sequence headers including information about at least a plurality of the intracoded frames, The filter extracts the sequence headers from the compressed normal playback bitstream, stores the sequence headers in the storage memory, The verifier / stator assembles the sequence headers and the intracoded frames to form the assembled bitstream. The method of claim 9, The system generates a trick play fast forward bitstream, And the verifier / stator assembles the intracoded frames in forward time order. The method of claim 9, The system generates a trick-play fast reverse bitstream, And the verifier / stator assembles the intracoded frames in reverse time order. The method of claim 9, The compressed normal playback bitstream includes a plurality of matrices corresponding to the intracoded frames, The filter places the matrices in the compressed normal playback bitstream and stores the matrices in the storage memory, And the verifier / stator assembles the intracoded frames and the matrices to form the assembled bitstream. The method of claim 9, Each of the plurality of matrices corresponds to one of the intracoded frames, The verifier / stator assembles each of the matrices with corresponding ones of the intracoded frames. The method of claim 1, The compressed normal playback bitstream is an MPEG compressed bitstream, The decoder is an MPEG decoder, And the encoder is an MPEG encoder.