|Publication number||US7840119 B2|
|Application number||US 10/256,044|
|Publication date||Nov 23, 2010|
|Filing date||Sep 25, 2002|
|Priority date||Sep 25, 2002|
|Also published as||US20040056884, WO2004030355A1|
|Publication number||10256044, 256044, US 7840119 B2, US 7840119B2, US-B2-7840119, US7840119 B2, US7840119B2|
|Inventors||Robert O. Eifrig, Walter Anderes, Bridget Diane Kimball, Paul Douglas Baker|
|Original Assignee||General Instrument Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (18), Referenced by (10), Classifications (9), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates to MPEG digital video encoding and decoding (e.g., for digital television). In particular, the present invention relates to methods and apparatus for processing progressive I-slice refreshed Moving Pictures Expert Group (MPEG) data streams to facilitate “trick play” modes on a display device. Trick play modes include pause, fast forward, rewind, jump, still frame display, and the like.
In order to understand the concept of progressive I-slice refreshed MPEG data streams, it is necessary to understand some basics about the typical I-frame based MPEG data stream. MPEG gets much of its compression capability by sending only the changes between different video frames. A first type of frame, known as a prediction or “P” frame, contains an abridged set of data used by the decoder to predict a full frame from a previous “P” frame or from a previous complete frame (an intra-coded “I” frame) in the video stream. The stream merely carries “fine tuning” information to correct errors from an approximate prediction. An I-frame is compressed without motion prediction. Thus, a full video frame can be reconstructed from an I-frame without reference to any other frame. In this manner, errors in the prior frame predictions will be eliminated once an I-frame arrives and is decoded. Bi-directional “B” frames are like P-frames, except that the prediction is made not only from the previous I-frame or P-frame, but also from the next one. MPEG data streams encoded in this manner are referred to herein as “I-frame based MPEG data streams.” An I-frame based MPEG data stream may start with an optional Group-of-Pictures (GOP) header followed by an I-frame. The video frame can be reconstructed from the GOP without reference to other frame information.
In progressively refreshed streams, such as taught in commonly owned U.S. Pat. No. 5,057,916 to Krause et al. entitled “Method and Apparatus for Refreshing Motion Compensated Sequential Video Images,” sequential video images are refreshed one region at a time. A different region in each of the plurality of video images is communicated without compression during a refresh cycle. In this manner, an image area defined by the region is progressively refreshed by the non-compressed regions during the refresh cycle. Compression of video images may be controlled to prevent data contained in regions not yet refreshed during a current refresh cycle from corrupting data contained in regions that have been refreshed during the current refresh cycle.
When an MPEG encoder is used in the progressive refresh mode, the I-frames are broken into slices and distributed across the transmitted P-frames as I-slices. MPEG data streams encoded in this manner are referred to herein as “progressive I-slice refreshed MPEG data streams.” The spreading of I-slices over multiple P-frames equalizes the bit rate and does not present a problem when the stream is played back sequentially. However, when trying to implement trick play modes in a progressive I-slice refreshed MPEG data stream, the lack of I-frames requires either extremely large buffers for several pictures worth of data or the stream must be fully decoded and then re-encoded as an I-frame based stream resulting in a loss of quality. This additional decoding and re-encoding also requires extra hardware, thereby incurring extra cost in the display device (e.g., set-top terminal, digital video recorder, personal versatile recorder, and the like).
It would be advantageous to provide a method and apparatus for enabling trick play modes on progressive I-slice refreshed MPEG data streams and other types of progressively refreshed data streams. It would be further advantageous to provide such a scheme where the processing required for enabling trick play modes is minimized to allow for real time performance. It would be advantageous to provide for improved visual characteristics of video during trick play modes such as fast forward and rewind. It would be advantageous to provide such improvements regardless of whether the data stream is an I-frame based stream or a progressively I-sliced refreshed stream.
The methods and apparatus of the present invention provide the foregoing and other advantages.
The present invention provides methods and apparatus for processing progressive I-slice refreshed Moving Pictures Expert Group (MPEG) data streams to facilitate “trick play” modes on a display device. A display device with personal versatile recorder capabilities is provided which is enabled to process progressive I-slice refreshed MPEG data streams to enable trick play mode features. The display device comprises a receiver for receiving a progressive I-slice refreshed MPEG data stream having I-slices distributed over multiple P-frames. The display device further comprises a syntax parser for parsing the data stream to locate the I-slices which make up an I-frame. A storage device is provided for storing the data stream. The display device also comprises an interface for receiving a command for a trick play mode feature. A processor associated with the syntax parser is provided for recovering the located I-slices from the storage device and assembling the recovered I-slices into one or more constructed I-frames. A decoder is provided for decoding the constructed I-frames to enable the trick play mode features.
The present invention will hereinafter be described in conjunction with the appended drawing figures, wherein like numerals denote like elements, and:
The ensuing detailed description provides preferred exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the invention. Rather, the ensuing detailed description of the preferred exemplary embodiments will provide those skilled in the art with an enabling description for implementing a preferred embodiment of the invention. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the appended claims.
The present invention uniquely solves the problems of high-speed rewind and fast-forward trick play modes for a display device, such as a digital video recorder (DVR) or personal versatile recorder (PVR) application manipulating MPEG compressed video streams.
Two problems of high speed trick play modes are (1) the very fast decoder and transport data rates required (2) a “slide show” effect when the incoming video stream data rate exceeds the decoder's maximum input rate and pictures must be skipped (not decoded and thus not displayed).
The invention addresses two modes of MPEG compression, I-frame and progressive I-slice refreshed compression. Rather than skipping entire pictures, pieces of individual pictures (referred to herein as “slices”), are assembled to form pictures. The resulting visual effect provides more continuity of motion during a high-speed forward or rewind trick play modes.
For I-slice compression, the invention particularly reduces the amount of data that is needed from the hard disk drive during a mode of high-speed trick play (fast forward or rewind). This is because I-slice compression relies on several pictures to build the current picture to be displayed. The set of pictures required to build a complete picture is referred to as a refresh cycle. A complete set of pictures in a refresh cycle must be read from the storage media and decoded by the video decoder in order to display one picture. Fast rewind speed exceeds the video decoder data throughput, so the decoder cannot keep up to this data rate and display frames must be repeated while a new refresh cycle is decoded. To solve this problem, a constructed I-frame picture is built from an existing MPEG stream, by “cutting and pasting” of the intra-coded slices that are concatenated to form one full picture per refresh cycle. Only the constructed I-frame picture must be transported from the storage media to the video decoder. This greatly reduces the required bandwidth by the transport system and the video decoder.
The progressive I-slice based refresh mode does not have a GOP header, nor does it have any I-frames. The entire stream is built as a “PBBPBBPBBPBBP . . . ” sequence where “P” represents P-frames and “B” represents B-frames.
Of the four P-frames, each one has slices that are intra coded, while the rest of the P-frame has motion estimation based on the previous picture, so that reconstructing a P-frame requires the previous frame. With a progressive I-slice refreshed approach, no prediction can be made as to how many frames are required to build a picture. However, the ‘refresh rate’ parameter can be set from, e.g., two to thirty-two frames in the encoder. The refresh rate is number of total frames in a refresh cycle. This means that, on average, the ‘refresh rate’ number of frames are required to collect a complete set of I-slices and build a complete video picture. It should be appreciated, however, that this refresh rate parameter can vary in other encoder designs.
In the example shown in
The general concept of the present invention is to build a constructed I-frame 60 from just the intra-coded slices (20, 25, 30, and 35) from each of the P-frames in a refresh cycle. The constructed I-frame algorithm relies on the fact that concatenating the intra-coded slices of the P-frames in a refresh cycle builds a complete picture without gaps between slices. In other words, each P-frame each holds a piece of the puzzle (an I-slice) that forms the constructed I-frame 60.
A consequence of a constructed I-frame 60 built from several different pictures on slice boundaries is that motion between slices in a single constructed I-frame may not be contiguous. This is because there is motion between the several P-pictures within a refresh cycle. During a high-speed trick mode such as rewind or fast forward, this artifact of seams at the slice points is a small distraction compared to the improved visual effect of the overall motion in the scene.
In an example embodiment of the invention as shown in
The constructed I-frame of the present invention reduces the complexity of trick play modes. In a preferred exemplary embodiment, the decoder 175 may only decode constructed I-frames for use during the trick play mode features. Each macroblock which forms the constructed I-frame is an intra-coded macroblock. Therefore, the constructed I-frames are easily decoded by the decoder 175, since there is no motion compensation for these frames. As the inventive algorithm is symmetrical, forward and rewind trick play modes work in essentially the same way.
The display device 100 may comprise one of a personal versatile recorder (PVR), a digital video recorder, a set-top terminal, a digital television, a cellular telephone, a personal digital assistant, a personal computer, or the like.
The I-slices which make up the constructed I-frame may be distributed over N P-frames. The N P-frames may be provided in the data stream each refresh cycle.
In a further example embodiment, the syntax parser 125 may provide indexing data comprising a location of each I-slice within the data stream. The indexing data 125 may be stored on the storage device 130 and accessed by the processor 150 (e.g., navigation data subsystem 160 of processor 150) to locate and recover the I-slices. The indexing data may further comprise a location of each I-slice positioned at a top portion of a P-frame. I-slice 20 of
The processor 150 may be adapted to access the indexing data independently from accessing of the data stream. The processor 150 may also be adapted to accesses the indexing data either sequentially or at random temporal locations.
The command 140 may comprise a fast forward command establishing a fast forward interval. In such an example embodiment, the indexing data may be used to locate a nearest I-slice positioned at the top portion of a P-frame in the data stream. The nearest I-slice and I-slices subsequent in time thereto are recovered and assembled to form a constructed I-frame. For the duration of the fast forward interval, the indexing data is used to locate subsequent additional I-slices positioned at the top portions of P-frames in the data stream. Each subsequent additional I-slice and I-slices subsequent in time thereto are recovered and assembled to provide additional constructed I-frames. The result is a video sequence composed of constructed I-frames, which can be passed directly to the decoder 175 for decoding prior to display on display 180.
The nearest I-slice may comprise one of an I-slice located forward of a current data stream position or prior to a current data stream position. This can be accomplished since the indexing data can be efficiently traversed either forward or backward in the order it was recorded.
The command 140 may comprise a rewind command establishing a rewind interval. For implementing a rewind mode, the indexing data is used to locate a nearest I-slice positioned at the top portion of a P-frame in the data stream. The nearest I-slice and I-slices subsequent in time thereto are recovered and assembled to form a constructed I-frame. For the duration of the rewind interval, the indexing data is used to locate previous additional I-slices positioned at the top portions of P-frames in the data stream. Each previous additional I-slice and I-slices subsequent in time thereto are recovered and assembled to provide additional constructed I-frames.
As can be seen from the forgoing description, the algorithm employed for a rewind command is slightly modified from the algorithm used for a fast forward command. For rewind, successive I-slices positioned at the top portion of the P-frames are located in reverse order, but the constructed I-frame is assembled by obtaining the I-slices reading forward from each top of frame I-slice Oust as when implementing the fast forward mode).
Those skilled in the art will appreciate that the construction of the I-frame for the first I-frame to be displayed in response to a trick play mode command 140 need not begin at the top portion of a P-frame. For example, the assembly of the first constructed I-frame may begin with a first located I-slice, regardless of its position within the P-frame. In an example embodiment, the fist located I-slice may be positioned below a top portion of a P-frame. In such an embodiment, the constructed I-frame may contain a blank portion above the position of the first located I-slice. Subsequent constructed I-frames will be complete I-frames without a blank portion. I-slice 20 of
Alternatively, the trick play mode speed may correspond to a multiple of a refresh rate of the MPEG data stream 115. To achieve such an effect, constructed I-frames must be skipped over during fast forward and rewind modes which require speeds faster than the refresh rate. For example, if the refresh rate is 30 frames per second and 60 seconds worth of transport stream were used, 60 constructed I-frames would be produced. However, as only 30 of the constructed I-frames could be presented in one second, the decoder may drop every other constructed I-frame, thereby providing a fast forward or rewind display rate of 60 times the normal play rate.
Similarly, a fast forward or rewind rate less than the refresh rate may be provided, by using each constructed I-frame more than once during the trick play mode display. For example, a fast forward or rewind rate which is half that of the refresh rate can be provided by using 15 seconds of the transport stream. In such an instance, 15 constructed I-frames will be assembled, and each one must be displayed twice to accommodate the 30 frames per second display rate, thereby providing a fast forward or rewind rate of 15 times the normal play rate. Those skilled in the art will appreciate that the rewind or fast forward rate may be any multiple of the refresh rate. However, when providing a fast forward or rewind rate less than the refresh rate, it is preferable to maintain an even repeat rate of each constructed I-frame. Therefore, the refresh rate should be evenly divisible by the number of seconds of transport stream used.
The constructed I-frame algorithm may also be modified to work with an I-frame based data stream. The resulting picture is similar to I-slice compression in that the picture displayed in trick play mode is built from several pictures. With an I-frame based data stream, complete I-frames are already present in the data stream. These complete I-frames do not rely on other frames to be decoded as they contain all intra-coded macroblocks. To produce a high speed forward or rewind without the ‘slide show’ effect which would occur if only the complete I-frames were decoded for display during these trick play modes, pieces (i.e. slices) of several complete I-frames may be concatenated to form a constructed I-frame. For example, the receiver 120 may receive an I-frame based MPEG data stream instead of the progressive I-slice refreshed MPEG data stream. In such an embodiment, the processor 150 may concatenate slices of multiple I-frames of the I-frame based MPEG data stream to form the constructed I-frame upon receipt of the trick play mode command. Applying the constructed I-frame algorithm to an I-frame based data stream provides for improved visual appearance during trick play modes and does not result in a drastic reduction of data throughput.
Those skilled in the art will appreciate that the configuration of the components shown in
The flowchart of
The steps are repeated after the slice count is incremented until a Start and End are identified. After a Start and End have been identified the chain may be appended to the previously found chain. When a complete constructed I-frame is formed the “chains” are sent to the video decoder for processing and display. The process is repeated for the duration of the fast forward or rewind command.
As shown in
(1) Overwriting the payload sections that are not part of the intra-coded slice. Part of the start and ending packet of the “chain” must be zeroed out. This removes the spurious data such as start codes that are not associated with the intra-coded slice. For example, in
(2) Removal of collisions of the continuity count of two appended packets by sandwiching in a ‘dummy’ packet. Two packets with duplicate continuity counts cannot be appended together since the decoder will drop one of them. If a collision does occurs, an empty packet may be appended first to increment the continuity count. The result is a discontinuity in the count but this does not cause the appended packet of the next “chain” of packets to be dropped.
It should now be appreciated that the present invention provides advantageous methods and apparatus for processing progressive I-slice refreshed MPEG data streams or the like enable trick play mode playback, without the need to transcode the entire date stream into an I-frame based data stream. The invention can be implemented for use with a personal versatile recorder and a cable television set top box. The invention lowers the cost and improves the quality of providing PVR service in any video distribution system that uses the progressive I-slice refreshed MPEG encoding mode, as well as other types of progressively refreshed data streams.
Although the invention has been described in connection with various illustrated embodiments, numerous modifications and adaptations may be made thereto without departing from the spirit and scope of the invention as set forth in the claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5057916||Nov 16, 1990||Oct 15, 1991||General Instrument Corporation||Method and apparatus for refreshing motion compensated sequential video images|
|US5477397||Jun 8, 1993||Dec 19, 1995||Matsushita Electric Corporation Of America||Digital high definition television receiver with features that facilitate trick-play modes on a digital VCR|
|US5568200||Jun 7, 1995||Oct 22, 1996||Hitachi America, Ltd.||Method and apparatus for improved video display of progressively refreshed coded video|
|US5579183 *||Apr 8, 1994||Nov 26, 1996||U.S. Philips Corporation||Recording and reproducing an MPEG information signal on/from a record carrier|
|US5717816||Aug 30, 1994||Feb 10, 1998||Hitachi America Ltd.||Method and apparatus for the selection of data for use in VTR trick playback operation in a system using intra-coded video frames|
|US5778143||Aug 30, 1994||Jul 7, 1998||Hitachi America, Ltd.||Method and apparatus for the selection of data for use in VTR trick playback operation in a system using progressive picture refresh|
|US6137834 *||May 28, 1997||Oct 24, 2000||Sarnoff Corporation||Method and apparatus for splicing compressed information streams|
|US6373905 *||Feb 11, 1999||Apr 16, 2002||Matsushita Electric Industrial Co., Ltd.||Decoding apparatus and decoding method|
|US6380991 *||Nov 19, 1998||Apr 30, 2002||Tektronix, Inc.||Method for splicing MPEG-2 transport streams|
|US6434195||Nov 20, 1998||Aug 13, 2002||General Instrument Corporaiton||Splicing of video data in progressively refreshed video streams|
|US6920178 *||Oct 12, 1999||Jul 19, 2005||France Telecom Sa||Method switching the video component(s) of a first digital, audio-visual program onto the video components of a second audio-visual digital, video-audio program to compensate their phase-shift|
|US7177522 *||Oct 9, 2001||Feb 13, 2007||Broadcom Corporation||System and method for personal video recording|
|US20010043792||Mar 6, 2000||Nov 22, 2001||Hidetoshi Mishima||Digital video signal record and playback device and method for recording and playing back the same|
|US20020061183||Oct 9, 2001||May 23, 2002||Macinnis Alexander G.||System and method for personal video recording|
|US20030016939 *||Feb 28, 2002||Jan 23, 2003||Samsung Electronics Co., Ltd.||Apparatus and method for searching for broadcast signal using a storage medium in a TV|
|US20080040740 *||Aug 1, 2007||Feb 14, 2008||Prime Research Alliance E, Inc.||Alternative Advertising in Prerecorded Media|
|EP0485798A2||Oct 29, 1991||May 20, 1992||General Instrument Corporation||Method and apparatus for refreshing motion compensated sequential video images|
|EP1009166A2||Oct 19, 1999||Jun 14, 2000||General Instrument Corporation||Splicing of video data in progressively refreshed video streams|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8291277 *||Oct 16, 2012||Cleversafe, Inc.||Data distribution utilizing unique write parameters in a dispersed storage system|
|US8352831 *||Oct 13, 2010||Jan 8, 2013||Cleversafe, Inc.||Digital content distribution utilizing dispersed storage|
|US8385408 *||Nov 30, 2009||Feb 26, 2013||Lg Electronics Inc.||Image display apparatus, image transmitting apparatus, image transmitting method and recording medium|
|US8612827 *||Jan 8, 2013||Dec 17, 2013||Cleversafe, Inc.||Digital content distribution utilizing dispersed storage|
|US8792777 *||Jan 10, 2007||Jul 29, 2014||Broadcom Corporation||Accurate fast forward rate when performing trick play with variable distance between frames|
|US20080166100 *||Jan 10, 2007||Jul 10, 2008||Tim Ross||Accurate fast forward rate when performing trick play with variable distance between frames|
|US20100135382 *||Nov 30, 2009||Jun 3, 2010||Duk-Sung Kim||Image display apparatus, image transmitting apparatus, image transmitting method and recording medium|
|US20110107181 *||May 5, 2011||Cleversafe, Inc.||Data distribution utilizing unique write parameters in a dispersed storage system|
|US20110161781 *||Jun 30, 2011||Cleversafe, Inc.||Digital content distribution utilizing dispersed storage|
|US20130125190 *||Jan 8, 2013||May 16, 2013||Cleversafe, Inc.||Digital content distribution utilizing dispersed storage|
|International Classification||H04N9/804, H04N5/783, H04N5/91, H04N5/93, H04N7/26|
|Cooperative Classification||H04N9/8042, H04N5/783|
|Sep 25, 2002||AS||Assignment|
Owner name: GENERAL INSTRUMENT CORPORATION, PENNSYLVANIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:EIFRIG, ROBERT;ANDERES, WALTER;KIMBALL, BRIDGET DIANE;AND OTHERS;REEL/FRAME:013339/0124;SIGNING DATES FROM 20020830 TO 20020917
|Jul 9, 2013||AS||Assignment|
Owner name: GENERAL INSTRUMENT HOLDINGS, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GENERAL INSTRUMENT CORPORATION;REEL/FRAME:030764/0575
Effective date: 20130415
Owner name: MOTOROLA MOBILITY LLC, ILLINOIS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GENERAL INSTRUMENT HOLDINGS, INC.;REEL/FRAME:030866/0113
Effective date: 20130528
|Apr 24, 2014||FPAY||Fee payment|
Year of fee payment: 4
|Nov 26, 2014||AS||Assignment|
Owner name: GOOGLE TECHNOLOGY HOLDINGS LLC, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MOTOROLA MOBILITY LLC;REEL/FRAME:034472/0001
Effective date: 20141028