Patent Application
20080008455
The invention will now be described, by way of example, with reference to the accompanying drawings, wherein:
Instead of just using CPI information for stored video streams on disk, the invention uses the CPI information in each stream buffer that implements a communication channel between two A/V processing components. In C-HEAP, as proposed in patent application with internal reference PHNL021390, a communication channel consists of one or more buffers that can be used to store A/V data written by a producer and read by a consumer. In the C-HEAP communication protocol, a buffer must first be claimed (reserved) before it can be written. When it has been written, the producer must release it, before a consumer can read it. While writing A/V data to a channel buffer, CPI data can be generated as well, where the CPI data identifies the locations of the I-frames in the buffer being written. The CPI data may be transported in a separate channel or may be a reserved part of the channel buffer being written.
An exemplary playback system 100 is illustrated in
During playback, the player 106 reads the stored video data out of the disc 102 and puts the data in the buffer 107. For a typical MPEG A/V stream of sufficient quality, a bitrate of approximately 4 Mbit/sec is required. With 25 frames per second, on the average approximately 20 kBytes are required to store a frame. A typical GOP size of 12 means that a complete GOP can be stored in 240 kB of memory. A 1-MB stream buffer then typically contains 4 I-frames. In addition, the meta data (CPI data) for the stored data is also read into the buffer 107. Data processed by “player” 106 is put into buffer 107, which can be directly read by the next processing element “decryptor” 108. There is no need for a buffer to be completely “full” before data is read from it. Furthermore, all buffers are typically part of a single memory, such that no copying is required between buffer memory spaces. More precisely, data written by a player 106 to a buffer space 107 can directly be read by a next processing element (decryptor 108). Once there is sufficient data in the buffer 107, the oldest data is transferred to the buffer 109. The decryption device 108 then begins decrypting the video data in the buffer 109. The decrypted data is then stored in the buffer 109 until it the next processing element (demux 110) starts reading from its input buffer. The demultiplexer 110 then demultiplexes the decrypted data. When the demultiplexed data is read out of the buffer 111 (and possibly transferred to the buffer 113), the decoder 112 decodes the demultiplexed data. When the decoded data is read out of the buffer 113 by a display device 115, the decoded data can be displayed.
A method for performing trickplay operations on a multimedia playback device will now be described with reference to
When going from normal playback to a fast forward mode of operation, it is no longer necessary to flush all channel buffers between the disc 102 and the decoder 112 and read only I-frames from the disc 102 and put these in the output channel of the player components. Instead, the decoder can select the I-frames directly from its input stream buffer 113, as can all of the processing elements in the processing chain. In the mean time, the player 106 can switch to reading of I-frames only. Once all I-frames have been read from an input stream buffer, according to the C-HEAP communication protocol, the buffer is released and becomes usable again by a producer. The producer will now overwrite all the data in the stream buffer, but in the fast forward mode, will now only write I-frames.
When a slow forward mode of operation is selected, the last processing element in the chain (the decoder 112 in
When a fast reverse mode of operation is requested, the last processing element in the playback device 104, e.g., the decoder 112 in the illustrative playback system illustrated in
Slow reverse is similar to fast reverse, but there is no need to select I-frames. The last processing element in the processing chain can begin to read frames in reverse order from its input buffer, until all channels are flushed and the player 106 has started reading earlier frames from the disc 102. For a smoother display, slow reverse is performed by reading out the output buffer 113 by display device 115 in reverse frame order. Because the decoded frames require more buffer space than compressed A/V data, only one previous output frame will be buffered there. Note that simply reading compressed frames in reverse order (for decoding) does not work, because of the structure of MPEG streams (B and P frames). This way of working does not require more processing power or bandwidth, even if reverse play is at normal speed. The whole processing chain can be working in “forward” mode, thereby optimizing disk access and decoder performance. Only the final readout of buffer 113 must be reversed. Too minimize buffer capacity, only one previous decoded frame in this embodiment of the invention is buffered there.
A problem that still remains is that when channel buffers are read or flushed, the player 106 must know which frame to read next from the disc 102 to enable the trickplay operation to go on smoothly after the last processing element in the processing chain has processed the data in its input buffers. This is typically not simply the next frame which the player has read before switching to trickplay mode because there is some pipeline delay between the player 106 and the decoder 112. As a result, the player 106 needs to find out which frame will be the last frame processed by the last processing element in the chain before it runs out of data. This can be done by checking the CPI data in the input buffer for the last frame to be processed. By getting this information for the last I-frame to be processed by the last processing element in the chain, for a specific trickplay mode, the player 106 knows which frame to retrieve next from the disc 102. For example, the processor 114 can retrieve the CPI information from the decoder 112 and buffer 113 and then route this information to the player 106 but the invention is not limited thereto.
To assure that the processing chain controller has enough time to flush all streaming buffers except for the input buffer of the last processing element in the chain, and the last processing element in the chain can finish processing the current GOP, a buffer of 240 kB is already sufficient. For fast forward/backward trickplay, probably two GOPs including 3 I-frames are sufficient. For fast reverse, with 2 GOP's of data in the input buffer in which the decoder can access the I-frames in any order, the decoder can decode and display at least one previous I-frame and at most 2 I-frames. Display of an I-frame takes 1/25th of a second (40 ms) for a typical 50 Hz interlace TV screen, or 1/30th of a second for a typical 60 Hz interlace TV screen. This is the time in which all the relevant buffers must be flushed and the player 106 start reading from the hard disk 102, as well as to have the data arrive at the input channel of the decoder. A number of frames will be read in forward order from the disk, to obtain good disk access speed, and the subsequent processing elements can read out the buffer of the disk reader in reverse order. If this deadline is not met, then the decoder will run out of input data after jumping backwards 1 or 2 I-frames and the output will not be smooth. Should this time not be sufficient, then the size of the buffer of the decoder can be increased or the number of reserved buffers by the decode can be increased to overcome this problem. For example, if the decoder reserves 3 buffers of 1 GOP each at the same time, then the decoder can minimally display 2 previous frames and maximally 3 frames, allowing 2 or 3 time periods to accomplish the flushing and disc accessing.
It will be understood that the different embodiments of the invention are not limited to the exact order of the above-described steps as the timing of some steps can be interchanged without affecting the overall operation of the invention. Furthermore, the term “comprising” does not exclude other elements or steps, the terms “a” and “an” do not exclude a plurality and a single processor or other unit may fulfill the functions of several of the units or circuits recited in the claims.
A method and apparatus for performing trickplay operations on a multimedia playback device is disclosed. When a trickplay request is received during regular multimedia playback, the appropriate frame for processing at a last processing means is determined in response to the trickplay request. The appropriate frame from a buffer is retrieved using meta data stored in the buffer which identifies the frame and the retrieved frame is processed. Meanwhile, a second appropriate frame in the stored multimedia content is selected for processing by a first processing means in response to the trickplay request. The second appropriate frame and subsequently selected frames are then processed so that the second appropriate frame is available to the last processing means when the last processing means has completed processing of the retrieved frame.
| Number | Date | Country | Kind |
|---|---|---|---|
| 03100724.8 | Mar 2003 | EP | regional |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/IB04/50273 | 3/17/2004 | WO | 00 | 5/8/2006 |
