Picture buffering for prediction references and display
Abstract
The invention relates to an encoder for forming an encoded picture stream. The pictures are defined as reference pictures or non-reference pictures, and information relating to decoding order and output order of a picture is defined for pictures of the picture stream. The encoder is arranged to form to the bitstream an indication of such a number of pictures arranged to be buffered in decoding order that is sufficient to recover the output order of pictures. The invention also relates to a signal, hypothetical encoder, decoder, hypothetical decoder, electronic device, system, software program and a storage medium.
Term
Term ended
Expired 6 November 2023, 2.9 years ago.
- Priority
- Filed
- Granted
- Expired
- Today
34 claims: 15 independent, 19 dependent
- 1A hypothetical decoder (5) for hypothetically decoding an encoded picture stream, and the hypothetical decoder (5) comprises a picture buffer (5.2) for buffering reference pictures and pictures to be reordered, characterized in that the hypothetical decoder (5) is configured to receive from an encoder (1) an attribute defining a number of pictures arranged to be buffered that is sufficient to recover the output order of pictures in the picture buffer (5.2) when pictures are input to buffering in decoding order, and that the hypothetical decoder (5) comprises the following:a processing block for performing the following before inserting a newly decoded picture to the buffer (5.2), - examining if the newly decoded picture can be inserted in the buffer (5.2) without removing another picture from the buffer (5.2), - on the basis of said examination, if the newly decoded picture cannot be inserted in the buffer (5.2) without removing another picture from the buffer (5.2), selecting a picture to be removed from the buffer (5.2), - removing the selected picture from the buffer (5.2).
- 3A signal containing an encoded picture stream, and the signal contains at least a first reference picture and a second reference picture, the signal contains at least one signal element to enable the first reference picture precedes the second reference picture in decoding order and the second reference picture precedes the first reference picture in output order, characterized in that the signal contains an indication of such a number of pictures arranged to be buffered that is sufficient to recover the output order of pictures when pictures are input to buffering in decoding order.
- 5An encoder (1) for forming an encoded picture stream, and the encoder (1) is arranged to include to the picture stream at least a first reference picture and a second reference picture, and at least one signal element to enable the first reference picture to precede the second reference picture in decoding order and the second reference picture to precede the first reference picture in output order, characterized in that the encoder is arranged to form to the picture stream an indication of such a number of pictures arranged to be buffered in a decoder that is sufficient to recover the output order of pictures when pictures are input to buffering in decoding order.
- 12An encoder (1) comprising a hypothetical decoder (5) for hypothetically decoding an encoded picture stream, and the encoder (1) comprises a picture buffer (5.2) for buffering reference pictures and pictures to be reordered, characterized in that the hypothetical decoder (5) is configured to receive from an encoder (1) an attribute defining a number of pictures arranged to be buffered that is sufficient to recover the output order of pictures in the picture buffer (5.2) when pictures are input to the picture buffer (5.2) in decoding order, and that the hypothetical decoder (5) comprises the following:a processing block for performing the following before inserting a newly decoded picture to the buffer (5.2), - examining if the newly decoded picture can be inserted in the buffer (5.2) without removing another picture from the buffer (5.2). - on the basis of said examination, if the newly decoded picture cannot be inserted in the buffer (5.2) without removing another picture from the buffer (5.2), selecting a picture to be removed from the buffer (5.2), - removing the selected picture from the buffer (5.2).
- 14A method for forming an encoded picture stream comprising including the signal with at least a first reference picture and a second reference picture, and at least one signal element to enable the first reference picture to precede the second reference picture in decoding order and the second reference picture to precede the first reference picture in output order, characterized in that the method comprises the step of:- defining an indication of a number of pictures arranged to be buffered in a decoder that is sufficient to recover the output order of pictures to the picture stream when pictures are input to buffering in decoding order.
- 16A method for buffering decoded pictures, the size of the buffer (5.2) is defined, the maximum number of reference pictures in the buffer (5.2) is defined, and a picture buffer (5.2) is used for buffering both prediction references and decoded pictures for arranging them in output order, characterized in that a number of pictures to be buffered in decoding order that is sufficient to recover the output order of pictures is received from an encoder and the size of the picture buffer is defined on the basis of the received number.
- 18A decoder (2) including means (2.3) for buffering decoded pictures, the pictures being defined as reference pictures or non-reference pictures, the size of the buffer is defined, and the number of reference pictures in the buffer is defined, an input for inputting a signal which contains at least a first reference picture and a second reference picture, and at least one signal element to enable the first reference picture to precede the second reference picture in decoding order and the second reference picture to precede the first reference picture in output order, and the signal further contains at least an indication of such a number of pictures arranged to be buffered that is sufficient to recover the output order of pictures when pictures are input to buffering in decoding order, and that the means (2.3) for buffering includes a picture buffer (2.1) for buffering both prediction references and decoded pictures for arranging them in output order, characterized in that the decoder (2) comprises a definer for defining the size of the picture buffer on the basis of said indication.
- 27A software program comprising machine executable steps for forming an encoded picture stream, and machine executable steps for inserting in said picture stream of at least a first reference picture and a second reference picture and at least one signal element to enable the first reference picture to precede the second reference picture in decoding order and the second reference picture to precede the first reference picture in output order, characterized in that the software program comprises machine executable steps for inserting in said picture stream an indication of a number of pictures arranged to be buffered that is sufficient to recover the output order of the decoded pictures when said decoded pictures are input to buffering in decoding order.
- 28A software program comprising machine executable steps for hypothetically decoding an encoded picture stream, and the software program comprises machine executable steps for buffering reference pictures and pictures to be reordered in a picture buffer (5.2; 2.1), characterized in that the software program further comprises the following:machine executable steps for performing the following before inserting a newly decoded picture to the buffer (5.2;2.1), - receiving from an encoder (1) an attribute defining a number of pictures arranged to be buffered that is sufficient to recover the output order of pictures in the picture buffer (5.2) when pictures are input to the picture buffer (5.2) in decoding order, - examining if the newly decoded picture can be inserted in the buffer (5.2;2.1) without removing another picture from the buffer (5.2;2.1), based on the received attribute, - on the basis of said examination, if the newly decoded picture cannot be inserted in the buffer (5.2;2.1) without removing another picture from the buffer (5.2;2.1), selecting a picture to be removed from the buffer (5.2;2.1), - removing the selected picture from the buffer (5.2;2.1).
- 29A software program comprising machine executable steps for buffering decoded pictures, the size of the buffer is defined, and the maximum number of reference pictures in the buffer is defined, and machine executable steps for processing a signal which contains at least a first reference picture and a second reference picture, and at least one signal element to enable the first reference picture to precede the second reference picture in decoding order and the second reference picture to precede the first reference picture in output order, characterized in that the signal further contains at least an indication of such a number of pictures arranged to be buffered that is sufficient to recover the output order of decoded pictures when said decoded pictures are input to buffering in decoding order, wherein the software program comprises machine executable steps for buffering both prediction references and decoded pictures for arranging them in displaying order in a picture buffer (5.2;2.1), and machine executable steps for defining the size of the buffer (5.2;2.1) on the basis of said indication.
- 30A storage medium for storing a software program comprising machine executable steps for forming an encoded picture stream, and including the signal with at least a first reference picture and a second reference picture and at least one signal element to enable the first reference picture to precede the second reference picture in decoding order and the second reference picture to precede the first reference picture in output order, characterized in that the software program comprises machine executable steps for forming to the bitstream an indication of such a number of pictures arranged to be buffered in a decoder that is sufficient to recover the output order of pictures when pictures are input to buffering in decoding order.
- 31An electronic device comprising an encoder (1) for forming an encoded picture stream, the encoder (1) is arranged to insert in said picture stream at least a first reference picture and a second reference picture, and at least one signal element to enable the first reference picture to precede the second reference picture in decoding order and the second reference picture to precede the first reference picture in output order, characterized in that the encoder is arranged to picture stream an indication of such a number of pictures arranged to be buffered in a decoder that is sufficient to recover the output order of pictures when pictures are input to buffering in decoding order.
- 32An electronic device (8) comprising a decoder (2) including means (2.3) for buffering decoded pictures, the maximum number of reference pictures in the buffer is defined, and the electronic device (8) comprises an input for inputting a signal which contains at least a first reference picture and a second reference picture, and at least one signal element to enable the first reference picture to precede the second reference picture in decoding order and the second reference picture to precede the first reference picture in output order, characterized in that the signal further contains at least an indication of such a number of pictures arranged to be buffered that is sufficient to recover the output order of pictures when pictures are input to buffering in decoding order, and that the means (2.3) for buffering includes a picture buffer (2.1) for buffering both prediction references and decoded pictures for arranging them in output order, wherein the decoder (2) comprises a definer (2.2;2.4) for defining the size of the picture buffer (2.1) on the basis of said indication.
- 33A system comprising an encoder (1) for forming a signal containing an encoded picture stream, a transmission channel (4) for transmitting the signal to a decoder (2), the decoder (2) including means (2.3) for buffering decoded pictures, and the system is arranged to include to the picture stream at least a first reference picture and a second reference picture, and at least one signal element to enable the first reference picture to precede the second reference picture in decoding order and the second reference picture to precede the first reference picture in output order, characterized in that the encoder is arranged to form to the picture stream an indication of such a number of pictures arranged to be buffered in said decoder that is sufficient to recover the output order of pictures when pictures are input to buffering in decoding order.
- 34A device (1) comprising an input for inputting information of at least a first reference picture and a second reference picture and at least one signal element to enable the first reference picture to precede the second reference picture in decoding order and the second reference picture to precede the first reference picture in output order, characterized in that the device is arranged to form an indication of a number of pictures arranged to be buffered in decoding order that is sufficient to recover the output order of pictures when pictures are input to buffering in decoding order.
Independent claims15
103 paragraphs, as filed
Field of the Invention
The present invention relates to a picture buffering for prediction references and display, the method consisting of an encoding step for forming encoded pictures in an encoder, an optional hypothetical decoding step for decoding said encoded pictures in the encoder, a transmission step for transmitting said encoded pictures to a decoder, a decoding step for decoding the encoded pictures for forming decoded pictures, and rearranging step for arranging the decoded pictures in displaying order.
Background of the Invention
Published video coding standards include ITU-T H.261, ITU-T H.263, ISO/IEC MPEG-1, ISO/IEC MPEG-2, and ISO/IEC MPEG-4 Part 2. These standards are herein referred to as conventional video coding standards.
There is a standardization effort going on in a Joint Video Team (JVT) of ITU-T and ISO/IEC. The work of JVT is based on an earlier standardization project in ITU-T called H.26L. The goal of the JVT standardization is to release the same standard text as ITU-T Recommendation H.264 and ISO/IEC International Standard 14496-10 (MPEG-4 Part 10). The draft standard is referred to as the JVT coding standard in this paper, and the codec according to the draft standard is referred to as the JVT codec.
The optional reference picture selection mode of H.263 and the NEWPRED coding tool of MPEG-4 Part 2 enable selection of the reference frame for motion compensation per each picture segment, e.g., per each slice in H.263. Furthermore, the optional Enhanced Reference Picture Selection mode of H.263 and the JVT coding standard enable selection of the reference frame for each macroblock separately.
Reference picture selection enables many types of temporal scalability schemes. Figure 1 shows an example of a temporal scalability scheme, which is herein referred to as recursive temporal scalability. The example scheme can be decoded with three constant frame rates. Figure 2 depicts a scheme referred to as Video Redundancy Coding, where a sequence of pictures is divided into two or more independently coded threads in an interleaved manner. The arrows in these and all the subsequent figures indicate the direction of motion compensation and the values under the frames correspond to the relative capturing and displaying times of the frames.
In conventional video coding standards, the decoding order of pictures is the same as the display order except for B pictures. A block in a conventional B picture can be bi-directionally temporally predicted from two reference pictures, where one reference picture is temporally preceding and the other reference picture is temporally succeeding in display order. Only the latest reference picture in decoding order can succeed the B picture in display order (exception: interlaced coding in H.263 where both field pictures of a temporally subsequent reference frame can precede a B picture in decoding order). A conventional B picture cannot be used as a reference picture for temporal prediction, and therefore a conventional B picture can be disposed without affecting the decoding of any other pictures.
The JVT coding standard includes the following novel technical features compared to earlier standards: <ul id="ul0001" list-style="dash" compact="compact"><li>The decoding order of pictures is decoupled from the display order. The picture number indicates decoding order and the picture order count indicates the display order.</li><li>Reference pictures for a block in a B picture can either be before or after the B picture in display order. Consequently, a B picture stands for a bi-predictive picture instead of a bi-directional picture.</li><li>Pictures that are not used as reference pictures are marked explicitly. A picture of any type (intra, inter, B, etc.) can either be a reference picture or a non-reference picture. (Thus, a B picture can be used as a reference picture for temporal prediction of other pictures.)</li><li>A picture can contain slices that are coded with a different coding type. In other words, a coded picture may consist of an intra-coded slice and a B-coded slice, for example.</li></ul>
Decoupling of display order from decoding order can be beneficial from compression efficiency and error resiliency point of view.
An example of a prediction structure potentially improving compression efficiency is presented in Figure 3. Boxes indicate pictures, capital letters within boxes indicate coding types, numbers within boxes are picture numbers according to the JVT coding standard, and arrows indicate prediction dependencies. Note that picture B17 is a reference picture for pictures B18. Compression efficiency is potentially improved compared to conventional coding, because the reference pictures for pictures B18 are temporally closer compared to conventional coding with PBBP or PBBBP coded picture patterns. Compression efficiency is potentially improved compared to conventional PBP coded picture pattern, because part of reference pictures are bi-directionally predicted.
Figure 4 presents an example of the intra picture postponement method that can be used to improve error resiliency. Conventionally, an intra picture is coded immediately after a scene cut or as a response to an expired intra picture refresh period, for example. In the intra picture postponement method, an intra picture is not coded immediately after a need to code an intra picture arises, but rather a temporally subsequent picture is selected as an intra picture. Each picture between the coded intra picture and the conventional location of an intra picture is predicted from the next temporally subsequent picture. As Figure 4 shows, the intra picture postponement method generates two independent inter picture prediction chains, whereas conventional coding algorithms produce a single inter picture chain. It is intuitively clear that the two-chain approach is more robust against erasure errors than the one-chain conventional approach. If one chain suffers from a packet loss, the other chain may still be correctly received. In conventional coding, a packet loss always causes error propagation to the rest of the inter picture prediction chain.
In the JVT coding standard, decoded pictures have to be buffered for two reasons: First, decoded pictures are used as reference pictures for predicting subsequent coded pictures. Second, due to decoupling of the decoding order from the display order, decoded pictures have to be reordered in display order.
The following example is used to explain the problem of separate buffering the present invention overcomes.
Consider the following sequence of pictures, where P is a predicted picture, BS a reference bi-predictive picture, and BN a non- reference bi-predictive picture, and the number relates to display order: <tables id="tabl0001" num="0001"><table frame="none"><tgroup cols="8" colsep="0"><colspec colnum="1" colname="col1" colwidth="28mm" /><colspec colnum="2" colname="col2" colwidth="10mm" /><colspec colnum="3" colname="col3" colwidth="12mm" /><colspec colnum="4" colname="col4" colwidth="12mm" /><colspec colnum="5" colname="col5" colwidth="12mm" /><colspec colnum="6" colname="col6" colwidth="12mm" /><colspec colnum="7" colname="col7" colwidth="12mm" /><colspec colnum="8" colname="col8" colwidth="12mm" /><tbody><row><entry rowsep="0">Display order</entry><entry rowsep="0" align="center">P1</entry><entry rowsep="0" align="center">BN2</entry><entry rowsep="0" align="center">BN3</entry><entry rowsep="0" align="center">BS4</entry><entry rowsep="0" align="center">BN5</entry><entry rowsep="0" align="center">BN6</entry><entry rowsep="0" align="center">P7...</entry></row><row rowsep="0"><entry>Decoding order</entry><entry align="center">P1</entry><entry align="center">P7</entry><entry align="center">BS4</entry><entry align="center">BN2</entry><entry align="center">BN3</entry><entry align="center">BN5</entry><entry align="center">BN6</entry></row></tbody></tgroup></table></tables>
This can be decoded with three picture memories in the reference picture buffer, but when BN5 is decoded, it is not yet time to display it: <tables id="tabl0002" num="0002"><table frame="none"><tgroup cols="11" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="25mm" /><colspec colnum="2" colname="col2" colwidth="10mm" /><colspec colnum="3" colname="col3" colwidth="10mm" /><colspec colnum="4" colname="col4" colwidth="11mm" /><colspec colnum="5" colname="col5" colwidth="12mm" /><colspec colnum="6" colname="col6" colwidth="12mm" /><colspec colnum="7" colname="col7" colwidth="12mm" /><colspec colnum="8" colname="col8" colwidth="12mm" /><colspec colnum="9" colname="col9" colwidth="12mm" /><colspec colnum="10" colname="col10" colwidth="12mm" /><colspec colnum="11" colname="col11" colwidth="13mm" /><tbody><row><entry>Decoded time</entry><entry align="center">P1</entry><entry align="center">P7</entry><entry align="center">BS4</entry><entry>BN2</entry><entry align="center">BN3</entry><entry align="center">BN5</entry><entry align="center">BN6</entry><entry align="center" /><entry align="center" /><entry align="center" /></row><row><entry>Display time</entry><entry align="center" /><entry align="center" /><entry align="center" /><entry>P1</entry><entry align="center">BN2</entry><entry align="center">BN3</entry><entry align="center">BS4</entry><entry align="center">BN5</entry><entry align="center">BN6</entry><entry align="center">P7 ...</entry></row></tbody></tgroup></table></tables>
Therefore BN5 has to be stored to reorder pictures in display order.
The problem does not exist in conventional video coding standards, because the display order for all reference pictures is the same as their decoding order and because only the latest decoded reference picture has to be buffered to reorder pictures in display order if B pictures are in use. The conventional video coding standard supporting reference picture selection have a reference picture buffer but they do not have a picture buffer for display reordering.
The following straightforward proposal was proposed for the JVT coding standard: Have a picture buffer for reference pictures that is separate from a picture buffer for display reordering. Specify the maximum-number of pictures separately for both buffers.
Let us reconsider the above described example again. A reference picture enters the reference picture buffer as soon as it is decoded. A non-reference picture does not enter the reference picture buffer. A decoded picture is removed from the reference picture buffer as soon as it is no longer needed for reference. For example, picture P1 can be removed after decoding of picture BN3. A picture enters the display reordering buffer as soon as it is decoded. A decoded picture is removed from the display reordering buffer when it can be displayed. The figure below shows the contents of the buffers just after decoding each picture. <tables id="tabl0003" num="0003"><table frame="none"><tgroup cols="11" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="25mm" /><colspec colnum="2" colname="col2" colwidth="10mm" align="center" /><colspec colnum="3" colname="col3" colwidth="10mm" align="center" /><colspec colnum="4" colname="col4" colwidth="11mm" align="center" /><colspec colnum="5" colname="col5" colwidth="12mm" align="center" /><colspec colnum="6" colname="col6" colwidth="12mm" align="center" /><colspec colnum="7" colname="col7" colwidth="12mm" align="center" /><colspec colnum="8" colname="col8" colwidth="12mm" align="center" /><colspec colnum="9" colname="col9" colwidth="12mm" align="center" /><colspec colnum="10" colname="col10" colwidth="12mm" align="center" /><colspec colnum="11" colname="col11" colwidth="10mm" align="center" /><tbody><row><entry>Decoded time</entry><entry>P1</entry><entry>P7</entry><entry>BS4</entry><entry>BN2</entry><entry>BN3</entry><entry>BN5</entry><entry>BN6</entry><entry /><entry /><entry /></row><row><entry>Display time</entry><entry /><entry /><entry /><entry>P1</entry><entry>BN2</entry><entry>BN3</entry><entry>BS4</entry><entry>BN5</entry><entry>BN6</entry><entry>P7</entry></row><row><entry>Reference buf</entry><entry>P1</entry><entry>P1</entry><entry>P1</entry><entry>P1</entry><entry>BS4</entry><entry>BS4</entry><entry>P7</entry><entry /><entry /><entry /></row><row><entry /><entry /><entry /><entry /><entry>P7</entry><entry>BS4</entry><entry>BS4</entry><entry>P7</entry><entry>P7</entry><entry /><entry /></row><row><entry /><entry /><entry /><entry /><entry /><entry /><entry>P7</entry><entry>P7</entry><entry /><entry /><entry /></row><row><entry>Display buf</entry><entry /><entry>P1</entry><entry>P1</entry><entry>BS4</entry><entry>BS4</entry><entry>BS4</entry><entry>BN5</entry><entry>BN6</entry><entry>P7</entry><entry /></row><row><entry /><entry /><entry /><entry /><entry>P7</entry><entry>P7</entry><entry>P7</entry><entry>P7</entry><entry>P7</entry><entry>P7</entry><entry /></row></tbody></tgroup></table></tables>
It can be seen that the required sizes of the reference picture buffer and the display reordering buffer are 3 pictures and 2 pictures respectively.
The working document JVT-B050 produced for the 2nd meeting of the Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG (ISO/IEC JTC1/SC29/WG11 and ITU-T SG16 Q.6) in Geneva, CH, Jan.29 - Feb.1, 2002 proposes a new video complexity verifier. This verifier, when used as a part of the Hypothetical Reference Decoder (HRD), characterizes the amount of delay and buffer-size that is needed to decode and present a given bit stream at a certain level of computational capacity at the decoder.
Summary of the Invention
In the present invention the reference picture buffer and the display picture buffer are combined, wherein both the reference pictures and the pictures to be reordered are stored in the same buffer to avoid the need to store the same picture in two different places.
The present invention provides a hypothetical decoder, signal, encoder, decoder, method, device, system and computer program in accordance with the appended claims for use in any kind of network device and terminal device, wherein the same buffer can be used to store at the decoder both the reference pictures and the pictures waiting to be displayed. Furthermore, the pictures are not stored twice in the memory.
The invention solves the decoded picture buffering problem in the JVT coding standard that did not exist in conventional video coding standards. The invention saves memory compared to the other solution proposed for the JVT coding standard. The advantage that the memory needed for buffering the pictures can be minimized is a significant advantage in small devices like mobile terminals.
Description of the Drawings
<dl id="dl0001"><dt>Fig. 1</dt><dd>shows an example of a recursive temporal scalability scheme,</dd><dt>Fig. 2</dt><dd>depicts a scheme referred to as Video Redundancy Coding, where a sequence of pictures is divided into two or more independently coded threads in an interleaved manner,</dd><dt>Fig. 3</dt><dd>presents an example of a prediction structure potentially improving compression efficiency,</dd><dt>Fig. 4</dt><dd>presents an example of the intra picture postponement method that can be used to improve error resiliency,</dd><dt>Fig. 5</dt><dd>depicts an advantageous embodiment of the system according to the present invention,</dd><dt>Fig. 6</dt><dd>depicts an advantageous embodiment of the encoder according to the present invention,</dd><dt>Fig. 7</dt><dd>depicts an advantageous embodiment of the decoder according to the present invention,</dd></dl>
Detailed Description of the Invention
In the unified buffer solution all decoded pictures stay in the unified buffer until they are no longer used as reference pictures and until their display order comes. The unified buffer saves memory compared to separate picture buffers for reference pictures and for reordering in display order.
Let us reconsider the previous example again when a unified buffer is in use. <tables id="tabl0004" num="0004"><table frame="none"><tgroup cols="10" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="25mm" /><colspec colnum="2" colname="col2" colwidth="10mm" /><colspec colnum="3" colname="col3" colwidth="10mm" /><colspec colnum="4" colname="col4" colwidth="11mm" /><colspec colnum="5" colname="col5" colwidth="12mm" /><colspec colnum="6" colname="col6" colwidth="12mm" /><colspec colnum="7" colname="col7" colwidth="12mm" /><colspec colnum="8" colname="col8" colwidth="12mm" /><colspec colnum="9" colname="col9" colwidth="12mm" /><colspec colnum="10" colname="col10" colwidth="10mm" /><tbody><row><entry>Decoded time</entry><entry>P1</entry><entry>P7</entry><entry>BS4</entry><entry>BN2</entry><entry>BN3</entry><entry>BN5</entry><entry>BN6</entry><entry /><entry /></row><row><entry>Display time</entry><entry /><entry /><entry>P1</entry><entry>BN2</entry><entry>BN3</entry><entry>BS4</entry><entry>BN5</entry><entry>BN6</entry><entry>P7</entry></row><row><entry>Unified buffer</entry><entry>P1</entry><entry>P1</entry><entry>P1</entry><entry>P1</entry><entry>BS4</entry><entry>BS4</entry><entry>BN6</entry><entry>P7</entry><entry /></row><row><entry /><entry /><entry /><entry>P7</entry><entry>BS4</entry><entry>BS4</entry><entry>P7</entry><entry>BN5</entry><entry>P7</entry><entry /></row><row><entry /><entry /><entry /><entry /><entry>P7</entry><entry>P7</entry><entry /><entry>P7</entry><entry /><entry /></row></tbody></tgroup></table></tables>
However, there are some matters which should be taken into account in the unified buffer solution. The size of the buffer should be set big enough to store all the pictures which are still needed, <i>i.e.</i> all reference pictures and pictures to be reordered. The memory capacity is often limited so the size of the buffer is some kind of compromise. The encoder has to check that the decoder is able to store enough pictures to decode and output all pictures without errors. This check can be performed by an optional Hypothetical Reference Decoder (HRD) in the encoding device. The HRD comprises a coded picture buffer for storing coded data stream and a decoded picture buffer for storing decoded reference pictures and for reordering decoded pictures in display order. The HRD moves data between the buffers similarly to the decoder of an decoding device does. However, the HRD need not decode the coded pictures entirely nor output the decoded pictures, but the HRD only checks that the decoding of the picture stream can be performed under the constraints given in the coding standard. When the HRD is operating, it receives a coded data stream and stores it to the coded picture buffer. In addition, the HRD removes coded pictures from the coded picture buffer and stores at least some of the corresponding hypothetically decoded pictures into the decoded picture buffer. The HRD is aware of the input rate according to which the coded data flows into the coded picture buffer, the removal rate of the pictures from the coded picture buffer, and the output rate of the pictures from the decoded picture buffer. The HRD checks for coded or decoded picture buffer overflows, and it indicates if the decoding is not possible with the current settings. Then the HRD informs the encoder about the buffering violation wherein the encoder can change the encoding parameters by, for example, reducing the number of reference frames, to avoid buffering violation. Alternatively or additionally, the encoder starts to encode the pictures with the new parameters and sends the encoded pictures to the HRD which again performs the decoding of the pictures and the necessary checks. As a yet another alternative, the encoder may discard the latest encoded frame and encode later frames so that no buffering violation happens.
Slice-based Operation
The minimum recommended unit to encapsulate in a transmission packet is a slice or a data partition. The minimum relatively independently decodable unit is a slice. Consequently, the unified buffering model assumes that a whole slice or a whole data partition is transmitted at a time. The model also assumes that packet-based networks and transmission protocols are used, and therefore a whole slice or a whole data partition is received at a time.
It is assumed that one slice is being decoded at a time. Thus, data is removed from the hypothetical input buffer slice by slice. The proposed complexity model is used to determine the time needed to virtually decode a slice. When that time is expired, the next slice can be virtually decoded.
Overview of the Buffering Model of the present invention
The reference decoder is based on a buffer model presented in this section. The model is based on three buffers: the pre-decoder buffer, the decoding buffer, and the post decoder buffer. The pre-decoder buffer buffers compressed data. The operation of the decoding buffer represents the operation of a real decoder and sets the processing complexity constraints. The post-decoder buffer contains reconstructed pictures that are used for reference picture for motion compensation and/or wait for a correct moment to be virtually displayed.
The default buffer sizes are given in the profile and level definitions. The buffer sizes can also be negotiated. The size of the decoding buffer gives the maximum size of a slice. The size of the post-decoder buffer can be given in bytes or in units of 16x16 pixels, for example.
The operation of the pre- and post-decoder buffer can be controlled by two parameters. The initial pre-decoder buffering period and the initial post-decoder buffering period define how long the buffers are filled in before any data is removed from them. The periods are signalled for each bit-stream separately.
Three time-stamps can be associated for a data unit (a data partition, a slice, or a picture). Each slice and data partition is associated with a transmission time. In case of file access, the transmission time is indicated in the file. Otherwise, the real transmission time is used. Each slice can be associated with a decoding time. The decoding time can be used to delay decoding of a slice in order to avoid overflows of the post-decoder buffer. Each picture is associated with a display time.
Time-related parameters are given in a common time-scale, Such as clock ticks of a 90 kHz or a 27 MHz clock.
The model can be applied to any continuous and independently decidable part of a coded bit-stream. In case of discontinuities, such as accessing a bit-stream from a random position, the model is reset.
Operation of the Buffering Model
The model is defined as follows: <ol id="ol0001" ol-style=""><li>1. The buffers are initially empty.</li><li>2. A slice or a data partition, excluding its real header, is added to the pre-decoder buffer at its transmission time. A certain amount of memory, for example eight bytes, of additional memory is reserved for each slice to store its header. (Actual slice headers may be closely linked with some payload header specific data, such as the parameter set indicator in the draft RTP payload format (VCEG-N72R1). It is impractical to remove this kind of data from header portion of the slice for HRD purposes only. Thus, a constant size of the slice header is assumed.)</li><li>3. No data is removed from the pre-decoder buffer during a period called the initial pre-decoder buffering period. The period starts when the first slice or data partition is added to the buffer.</li><li>4. When the initial pre-decoder buffering period has expired and if decoding time-stamps are in use, the decoding timer is started from the decoding time of the earliest picture in the picture buffer. Otherwise, no decoding timer is needed.</li><li>5. Pictures are removed from the pre-decoder buffer slice by slice in ascending order of picture identifiers (using modulo arithmetic). Slices of a particular picture are removed in their transmission order. A slice, including its data partitions, is moved from the pre-decoder buffer to the decoding buffer at one time when the decoding buffer becomes empty. However, a slice is not removed from the pre-decodor buffer before the decoding timer reaches the decoding time of the slice.</li><li>6. A slice remains in the decoding buffer as long as its calculated decoding duration. The duration is the larger one of the two candidates: candidate 1 = number of macroblocks in a slice / maxMacroblockPerSec and candidate 2 = number of bits in a slice / maxBitsPerSec.</li><li>7. An uncompressed picture enters the post-decoder buffer when the last slice (in the decoding order) of the corresponding coded picture is removed from the decoding buffer.</li><li>8. Data is not removed from the post-decoder buffer during a period called the initial post-decoder buffering period. The period starts when the first picture has been placed into the post-decoder buffer.</li><li>9. When the initial post-decoder buffering period has expired, the playback timer is started from the earliest display time of the pictures residing in the post-decoder buffer at that time.</li><li>10. A picture is virtually displayed when the playback timer reaches the scheduled display time of the picture.</li><li>11. A picture is removed from the post-decoder buffer when it is virtually displayed and when it is no longer needed as a reference picture.</li></ol>
Requirements for a Compliant Bit-Stream
Any transmitted or stored bit-stream shall comply with the following requirements: <ul id="ul0002" list-style="dash" compact="compact"><li>The occupancy of the pre-decoder buffer shall not exceed the default or signalled buffer size.</li><li>Any slice shall not be larger than the size of the decoding buffer.</li><li>The occupancy of the post-decoder buffer shall not exceed the default or signalled buffer size.</li><li>Each picture shall be inserted into the post-decoder buffer before or on its display time.</li></ul>
When the default buffer sizes according to a certain profile and level are used, a bit-stream is compliant with this profile and level.
Requirements for a Compliant Decoder
A decoder shall be capable of receiving and decoding all the pictures in a compliant bit-stream when the same buffer sizes are assumed both in the decoder and in the bit-stream. Furthermore, the decoder shall pass each picture to a display process at the same time when the hypothetical reference decoder would display the picture virtually.
In the following the invention will be described in more detail with reference to the system of Fig. 5, the encoder 1 and hypothetical reference decoder (HRD) 5 of Fig 6 and decoder 2 of Fig. 7. The pictures to be encoded can be, for example, pictures of a video stream from a video source 3, <i>e.g</i>. a camera, a video recorder, etc. The pictures (frames) of the video stream can be divided into smaller portions such as slices. The slices can further be divided into blocks. In the encoder 1 the video stream is encoded to reduce the information to be transmitted via a transmission channel 4, or to a storage media (not shown). Pictures of the video stream are input to the encoder 1. The encoder has an encoding buffer 1.1 (Fig. 6) for temporarily storing some of the pictures to be encoded. The encoder 1 also includes a memory 1.3 and a processor 1.2 in which the encoding tasks according to the invention can be applied. The memory 1.3 and the processor 1.2 can be common with the transmitting device 6 or the transmitting device 6 can have another processor and/or memory (not shown) for other functions of the transmitting device 6. The encoder 1 performs motion estimation and/or some other tasks to compress the video stream. In motion estimation similarities between the picture to be encoded (the current picture) and a previous and/or latter picture are searched. If similarities are found the compared picture or part of it can be used as a reference picture for the picture to be encoded. In JVT the display order and the decoding order of the pictures are not necessarily the same, wherein the reference picture has to be stored in a buffer (e.g. in the encoding buffer 1.1) as long as it is used as a reference picture. The encoder 1 also inserts information on display order of the pictures into the transmission stream.
From the encoding process the encoded pictures are moved to an optional encoded picture buffer 1.5, if necessary. The encoded pictures are transmitted from the encoder 1 to the decoder 2 via the transmission channel 4. In the decoder 2 the encoded pictures are decoded to form uncompressed pictures corresponding as much as possible to the encoded pictures. Each decoded picture is buffered in the DPB 2.1 of the decoder 2 unless it is displayed substantially immediately after the decoding and is not used as a reference picture. In the system according to the present invention both the reference picture buffering and the display picture buffering are combined and they use the same decoded picture buffer 2.1. This eliminates the need for storing the same pictures in two different places thus reducing the memory requirements of the decoder 2.
The decoder 1 also includes a memory 2.3 and a processor 2.2 in which the decoding tasks according to the invention can be applied. The memory 2.3 and the processor 2.2 can be common with the receiving device 8 or the receiving device 8 can have another processor and/or memory (not shown) for other functions of the receiving device 8.
Let us now consider the encoding-decoding process in more detail. Pictures from the video source 3 are entered to the encoder 1 and advantageously stored in the encoding buffer 1.1. The encoding process is not necessarily started immediately after the first picture is entered to the encoder, but after a certain amount of pictures are available in the encoding buffer 1.1. Then the encoder 1 tries to find suitable candidates from the pictures to be used as the reference frames. The encoder 1 then performs the encoding to form encoded pictures. The encoded pictures can, for example, be predicted pictures (P), bi-predictive pictures (B), or intra-coded pictures (I). The intra-coded pictures can be decoded without using any other pictures, but other type of pictures need at least one reference picture before they can be decoded. Pictures of any of the above mentioned picture types can be used as a reference picture.
The encoder attaches two time stamps to the pictures: a decoding time stamp (DTS) and output time stamp (OTS). The decoder can use the time stamps to determine the correct decoding time and time to output (display) the pictures. However, those time stamps are not necessarily transmitted to the decoder or it does not use them.
If the encoder has the HRD 5, the encoder defines the size of the DPB 5.2 (DPB size). The initial size may depend on some parameters relating to the video stream (e.g. resolution, colour/BW, etc.). There can also be a maximum size defined for the DPB 5.2 (DPBcapacity). The initial size may not necessarily be the same as the maximum size but it can also be smaller than the maximum size. Also the maximum number of reference frames stored in the DPB is defined. This value is referred as num_ref_frames in this description.
In the decoder the DPB 2.1 has a limited size (DPB size) which in some applications may be varied during the decoding process, if necessary. The initial size of the DPB 2.1 may depend on some parameters relating to the video stream (e.g. resolution, colour/BW, etc.). There can also be a maximum size defined for the DPB 2.1 (DPBcapacity). The initial size may not necessarily be the same as the maximum size but it can also be smaller than the maximum size. Also the maximum number of reference frames stored in the DPB is defined. This value is referred as num_ref_frames in this description.
The transmission and/or storing of the encoded pictures (and the optional virtual decoding) can be started immediately after the first encoded picture is ready. This picture is not necessarily the first one in decoder output order because the decoding order and the output order may not be the same. However, because the size of the DPB 2.1 of the decoder 2 is limited it is necessary to define how long the delay between decoding time of a picture and the display time of the picture can be at maximum, <i>i.e.</i> the maximum number of the pictures to be reordered for displaying. This value is referred as num_reorder_frames in this description. num_reorder_frames is the number of consecutive frames in decoding order that is required to recover the output order of pictures at any time. The sum of the maximum number of reference frames stored in the DPB and the maximum number of the pictures to be reordered for displaying, excluding those pictures which already are stored as reference pictures, must not be greater than the current capacity of the DPB. DPB size illustrates how many pictures can be stored in the DPB 2.1. It can be calculated by dividing the size of the DPB (in bytes) by the size of a picture (in bytes).
When the first picture of the video stream is encoded the transmission can be started. The encoded pictures are optionally stored to the encoded picture buffer 1.5. The transmission can also start at a later stage, for example, after a certain part of the video stream is encoded.
The decoder 2, 5 should output the decoded pictures in correct order, for example by using the ordering of the picture order counts, and hence the reordering process need be defined clearly and normatively.
Next, the operation of the decoder 2 according to an embodiment of the present invention will be described. The DPB 2.1 contains memory places for storing a number of pictures. Those places are also called as frame stores in this description. An attribute FrameStoreUsage is used here as the indicator of the reservation status of a frame store (in use/not in use). The value of FrameStoreUsage reflects the usage of current frame store. A first value (e.g. 0) means the frame store is empty and it can be overwritten safely. A second value (e.g. 1) means this is a frame store used for reference (but not for reordering), a third value (<i>e.g</i>. 2) means this is a frame store used for reordering (but not for reference). A fourth value (<i>e.g</i>. 3) means this is a frame store used for both reference and reordering. The initial value of FrameStoreUsage shall be the first value. It is also possible to use a separate, second attribute to define whether a picture is (virtually) displayed or not. It can have values "unused for output" or "used for output". A picture marked as "used for output" means the picture still stays in the DPB and waits for its turn to output: It shall be marked as "unused for output" as a result of outputting the picture. If the second attribute is used, only the first and second values would be used with the FrameStoreUsage, wherein the combination of the first and the second attribute gives the same information as the FrameStoreUsage with the four different value alternatives. It is also possible to define an attribute for the validity of a picture (valid/invalid). A picture is marked as "Invalid" if it is intentionally inserted in order to fill the detected gaps between neighbouring frame_num. Otherwise, the picture is marked as "Valid", which may be correctly decoded or reconstructed by means of error concealments. The frame stores can also be uniquely indexed which implies the decoding order of the buffered pictures.
In the beginning of the decoding procedure the status of all the frame stores is set to empty, or free. This is done by setting the FrameStoreUsage to the first value for all frame stores. The decoder 2 can also set the following variables to an initial value (e.g. 0): num_frames_in_use, which contains the number of frame stores used for either reference or output; num_frames_use_ref, which contains the number of frame stores used for reference; and num_frames_use_output, which contains the number of frame stores used for output.
An additional frame store is used to save the newly decoded picture. The DPB plus the additional frame store is called the Extended DPB (EDPB).
Step 1: Decoding
The decoder 2 starts to decode the encoded pictures beginning from the picture having smallest decoding time stamp. When the picture is decoded it will be stored to the additional frame store. The picture to be decoded can either be a frame or a field. If it is a reference picture, the FrameStoreUsage is set to the fourth value, otherwise to the third value. It is labelled as "used for reordering" at first, because it cannot be determined whether the newly decoded picture needs reordering or not at this step without the information about the DPB.
Step 2: Reordering
Before the following steps, the decoder 2 needs to know if there is at least one more picture to be decoded and some information from the slice header of the next picture to be decoded.
Step 2.1 If there is at least one more picture to be decoded and the number of frames to be reordered in DPB is less than num_reorder_frames, the decoder 2 does not output a picture. If the newly decoded picture is used for reference, then Step 3 will be executed, otherwise Step 4 will be executed.
Step 2.2 If there is at least one more picture to be decoded and the number of frames to be reordered in DPB is equal to num_reorder_frames, the following conditions will be checked: <ul id="ul0003" list-style="dash" compact="compact"><li>The newly decoded picture is a frame.</li><li>The additional frame store contains two fields.</li><li>if a single field resides in the additional frame store, the next picture to be decoded is not its opposite parity of the same frame.</li></ul>
If none of the above conditions is true, go to Step 1 to decode the opposite parity field of the same frame.
Then, if at least one of the above conditions is true, the frame stores in DPB and the additional frame store will be looked through to find which picture needs to be output. The picture, which is the first picture in the output order among the pictures to be reordered in DPB and the additional frame store, shall be output. How to determine the first picture in the output order is described later. If the outputted picture is a field and the opposite parity field of the same frame is present, both fields are output. The output pictures should be marked as "unused for reordering".
If the newly decoded picture is output and is not used for reference, then go to Step 1 to decode the next picture. If the newly decoded picture is used for reference (but not used for reordering), FrameStoreUsage is set to the second value (1) and the Step 3 follows. If the newly decoded picture is used for reordering (but not used for reference), FrameStoreUsage is set to a third value (2) and then go to Step 4 to store the picture for reordering. If the newly decoded picture is used both for reference and reordering, set FrameStoreUsage to the fourth value (3) and then go to Step 3.
Step 2.3 If there are no more pictures to be decoded, all the pictures that are still marked as "used for reordering" shall be output in output order. Then the decoder stops working until there are more pictures to decode.
Step 3: Marking picture as "unused for reference"
If the newly decoded picture is a reference picture, "Sliding Window" or "Adaptive Memory Control" mechanism is applied to the frame store set consisting of pictures marked as "used for reference".
Step 4: Storing
If the newly decoded picture is a frame, the step 4.1 will be performed, otherwise the step 4.2.
Step 4.1 There should be at least one empty frame store in the DPB 2.1 before storing the newly decoded frame. FrameStoreUsage is set to be equal to FrameStoreUsage of the additional frame store. Go to Step 1 to decode the next picture.
Step 4.2 For a newly decoded field, the destination frame store will be an empty frame store if its opposite parity field of the same frame is not in the DPB 2.1. In this case the FrameStoreUsage is set to be equal to FrameStoreUsage of the additional frame store. Otherwise, the newly decoded picture should be stored into the same frame store as its opposite parity field and FrameStoreUsage is unchanged. Go to Step 4.3 to decode the next picture.
Step 4.3 After storing the newly decoded picture into the DPB, it is assumed that the latest decoded picture is stored in a frame store whose FrameStoreIndex is 0, the second latest decoded picture is stored in a frame store whose FrameStoreIndex is 1, and so on. Last, Step 1 is performed to decode the next picture.
It shall be noticed that marking a picture as "unused for reference" and marking a picture as "unused for reordering" are decoupled.
To help understand the operations in the steps presented above, two examples are shown for the reordering process. The italic numbers after (or below) the picture labels indicate the frame_num. Reference pictures are indicated by underlining the letter of the picture label. 'x' means no picture is reordered before decoding the next picture.
Example 1. num reorder frames = 1; 10 frames are coded. <tables id="tabl0005" num="0005"><table frame="all"><tgroup cols="11"><colspec colnum="1" colname="col1" colwidth="46mm" /><colspec colnum="2" colname="col2" colwidth="10mm" /><colspec colnum="3" colname="col3" colwidth="12mm" /><colspec colnum="4" colname="col4" colwidth="12mm" /><colspec colnum="5" colname="col5" colwidth="12mm" /><colspec colnum="6" colname="col6" colwidth="12mm" /><colspec colnum="7" colname="col7" colwidth="12mm" /><colspec colnum="8" colname="col8" colwidth="12mm" /><colspec colnum="9" colname="col9" colwidth="12mm" /><colspec colnum="10" colname="col10" colwidth="12mm" /><colspec colnum="11" colname="col11" colwidth="14mm" /><thead><row><entry valign="top">Coded pictures in output order</entry><entry valign="top">I0</entry><entry valign="top">B1</entry><entry valign="top">B2</entry><entry valign="top">P3</entry><entry valign="top">B4</entry><entry valign="top">B5</entry><entry valign="top">P6</entry><entry valign="top">B7</entry><entry valign="top">B8</entry><entry valign="top">P9</entry></row></thead><tbody><row><entry>Decoding order:</entry><entry><u style="single">I</u>0 <i>0</i></entry><entry><u style="single">P</u>3 <i>1</i></entry><entry>B1 <i>2</i></entry><entry>B2 <i>2</i></entry><entry><u style="single">P</u>6 <i>2</i></entry><entry>B4 <i>3</i></entry><entry>B5 <i>3</i></entry><entry><u style="single">P</u>9 <i>3</i></entry><entry>B7 <i>4</i></entry><entry>B8 <i>4</i></entry></row><row><entry>After reordering</entry><entry>x</entry><entry>I0</entry><entry>B1</entry><entry>B2</entry><entry>P3</entry><entry>B4</entry><entry>85</entry><entry>P6</entry><entry>B7</entry><entry>B8, P9</entry></row></tbody></tgroup></table></tables>
Example 2. num reorder frames = 2: 13 frames are coded. <tables id="tabl0006" num="0006"><table frame="all"><tgroup cols="14"><colspec colnum="1" colname="col1" colwidth="20mm" /><colspec colnum="2" colname="col2" colwidth="10mm" /><colspec colnum="3" colname="col3" colwidth="11mm" /><colspec colnum="4" colname="col4" colwidth="12mm" /><colspec colnum="5" colname="col5" colwidth="12mm" /><colspec colnum="6" colname="col6" colwidth="12mm" /><colspec colnum="7" colname="col7" colwidth="12mm" /><colspec colnum="8" colname="col8" colwidth="12mm" /><colspec colnum="9" colname="col9" colwidth="12mm" /><colspec colnum="10" colname="col10" colwidth="12mm" /><colspec colnum="11" colname="col11" colwidth="11mm" /><colspec colnum="12" colname="col12" colwidth="11mm" /><colspec colnum="13" colname="col13" colwidth="11mm" /><colspec colnum="14" colname="col14" colwidth="12mm" /><thead><row><entry valign="top">Coded pictures in output order</entry><entry valign="top">I0</entry><entry valign="top">B1</entry><entry valign="top">B2</entry><entry valign="top">B3</entry><entry valign="top">P4</entry><entry valign="top">B5</entry><entry valign="top">B6</entry><entry valign="top">B7</entry><entry valign="top">P8</entry><entry valign="top">B9</entry><entry valign="top">B10</entry><entry valign="top">B11</entry><entry valign="top">P12</entry></row></thead><tbody><row><entry>Decoding order</entry><entry><u style="single">I</u>0 <i>0</i></entry><entry><u style="single">P</u>4 <i>1</i></entry><entry><u style="single">B</u>2 <i>2</i></entry><entry>B1 <i>3</i></entry><entry>B3 <i>3</i></entry><entry><u style="single">P</u>8 <i>3</i></entry><entry><u style="single">B</u>6 <i>4</i></entry><entry>B5 <i>5</i></entry><entry>B7 <i>5</i></entry><entry><u style="single">P</u>12 <i>5</i></entry><entry>B10 <i>6</i></entry><entry>B9 <i>7</i></entry><entry>B11 <i>7</i></entry></row><row><entry>After reordering</entry><entry>x</entry><entry>x</entry><entry>I0</entry><entry>B1</entry><entry>B2</entry><entry>B3</entry><entry>P4</entry><entry>B5</entry><entry>B6</entry><entry>B7</entry><entry>P8</entry><entry>B9</entry><entry>B10, B11, P12</entry></row></tbody></tgroup></table></tables>
If the decoder 2 notices that the encoded pictures can not be decoded, the size of the DPB 2.1 may be too small. In some applications the decoder 2 can inform the encoder to change the encoding parameters, for example, to use less reference pictures, or to use larger DPB size. In the error situation the decoder 2 may still output those decoded pictures which if managed to decode and/or to output some default pictures (e.g. empty frames).
Sliding window operation for reordering
The num_reorder_frames is used to define the sliding window operation for reordering purpose. The pictures to be reordered are -arranged in output order to find out the picture which should jump out of the scope of the window first. Once the number of pictures to be reordered reaches the num reorder frames, the first picture in output order is sure to fall out of the window as the result of one sliding window operation. This subsection specifies how to find the earliest picture in output order among the pictures that are marked as "used for reordering".
Step 1. Initialization. Set the oldest picture in decoding order in DPB1 be the candidate picture.
Step 2. Loop from the second oldest picture to the latest picture (in decoding order) and use i as the loop counter. The loop body is composed by Step 2.1 and Step 2.2.
Step 2.1 If picture i is an IDR picture, the candidate picture is the picture to find, break the loop.
Step 2.2 If the POC of picture i is less than the POC of the candidate picture, set picture i as the candidate picture.
Step 3. End. The candidate picture is the oldest picture in output order.
The num_ref_frames and num_reorder_frames are signalled to the decoder 2 by some way, for example by a sequence parameter set. Every time when a different sequence parameter set becomes effective, num_ref_frames or num_reorder_frames may change and thus special care on the DPB should be taken.
1.5.1 Changing of num_ref_frames
No special actions need to be done when <i>num_ref_frames</i> increases.
When <i>num_ref_frames</i> decreases, a simple operation upon the DPB is proposed: Let diff_ref_frames equal to the new num_ref_frames minus old num_ref_frames. All the diff_ref_frames reference frames from the oldest in decoding order shall be marked as "unused for reference".
1.5.2 Changing of num_reorder_frames
When num_reorder_frames increases, 0 picture per one decoded picture is output in (new num_reorder_frames) - (old num_reorder_frames) pictures after (old num_reorder_frames) picture since the decoded picture using the new sequence parameter set. For example, the <i>num_reorder_frames</i> of two parts of the bitstream are 1 and 2 respectively. When P3 is decoded, no picture is output. <tables id="tabl0007" num="0007"><table frame="all"><tgroup cols="13"><colspec colnum="1" colname="col1" colwidth="27mm" /><colspec colnum="2" colname="col2" colwidth="10mm" /><colspec colnum="3" colname="col3" colwidth="10mm" /><colspec colnum="4" colname="col4" colwidth="10mm" /><colspec colnum="5" colname="col5" colwidth="10mm" /><colspec colnum="6" colname="col6" colwidth="10mm" /><colspec colnum="7" colname="col7" colwidth="10mm" /><colspec colnum="8" colname="col8" colwidth="10mm" /><colspec colnum="9" colname="col9" colwidth="10mm" /><colspec colnum="10" colname="col10" colwidth="10mm" /><colspec colnum="11" colname="col11" colwidth="10mm" /><colspec colnum="12" colname="col12" colwidth="10mm" /><colspec colnum="13" colname="col13" colwidth="19mm" /><thead><row><entry valign="top">Decoding order</entry><entry valign="top">I0</entry><entry valign="top">P2</entry><entry valign="top">B1</entry><entry valign="top">P4</entry><entry valign="top">B3</entry><entry valign="top">I0</entry><entry valign="top">P3</entry><entry valign="top">B2</entry><entry valign="top">B1</entry><entry valign="top">P6</entry><entry valign="top">B5</entry><entry valign="top">B4</entry></row></thead><tbody><row><entry>After reordering</entry><entry>x</entry><entry>10</entry><entry>B1</entry><entry>P2</entry><entry>B3</entry><entry>P4</entry><entry>x</entry><entry>10</entry><entry>B1</entry><entry>B2</entry><entry>P3</entry><entry>B4, B5, B6</entry></row></tbody></tgroup></table></tables>
When <i>num_reorder_frames</i> decreases, more than one picture is output at the decoded picture using the new sequence parameter set. For example, the <i>num_reorder_frames</i> of two parts of the bitstream are 2 and 1 respectively. When I0 is decoded, two pictures <b>B5</b> and <b>P6</b> are output at the same time. <tables id="tabl0008" num="0008"><table frame="all"><tgroup cols="13"><colspec colnum="1" colname="col1" colwidth="27mm" /><colspec colnum="2" colname="col2" colwidth="10mm" /><colspec colnum="3" colname="col3" colwidth="10mm" /><colspec colnum="4" colname="col4" colwidth="10mm" /><colspec colnum="5" colname="col5" colwidth="10mm" /><colspec colnum="6" colname="col6" colwidth="10mm" /><colspec colnum="7" colname="col7" colwidth="10mm" /><colspec colnum="8" colname="col8" colwidth="10mm" /><colspec colnum="9" colname="col9" colwidth="16mm" /><colspec colnum="10" colname="col10" colwidth="10mm" /><colspec colnum="11" colname="col11" colwidth="10mm" /><colspec colnum="12" colname="col12" colwidth="10mm" /><colspec colnum="13" colname="col13" colwidth="14mm" /><thead><row><entry valign="top">Decoding order</entry><entry valign="top">I0</entry><entry valign="top">P3</entry><entry valign="top">B2</entry><entry valign="top">B1</entry><entry valign="top">P6</entry><entry valign="top">B5</entry><entry valign="top">B4</entry><entry valign="top">I0</entry><entry valign="top">P2</entry><entry valign="top">B1</entry><entry valign="top">P4</entry><entry valign="top">B3</entry></row></thead><tbody><row><entry>After reordering</entry><entry>x</entry><entry>x</entry><entry>I0</entry><entry>B1</entry><entry>B2</entry><entry>P3</entry><entry>B4</entry><entry><b>B5, P6</b></entry><entry>I0</entry><entry>B1</entry><entry>P2</entry><entry>B3, P4</entry></row></tbody></tgroup></table></tables>
A picture that is stored for prediction, referred to as a reference picture, is marked as "used for reference", and is labelled as a short-term reference picture, in which case it is identified by its frame_number and parity. A short-term picture may be assigned a long-term reference frame index, in which case it is identified by its long-term index. A picture that is not stored for prediction is labelled as "unused for prediction". Reference picture buffer is a picture set that are composed by pictures marked as "used for reference" in DPB. Removing a picture from reference picture buffer means marking the picture as "unused for reference". To reset the reference picture buffer means to mark all the pictures in reference picture buffer as "unused for reference". Short-term reference pictures can remain marked for reference for a finite duration, given by MaxFrameNum. Long term reference pictures can remain marked "used for reference" until the next IDR picture. Memory_management_control_operation commands can be used to modify the contents of the reference picture buffer.
In another embodiment of the present invention the HRD 5 is used with the encoder 1 to virtually perform the decoding of the encoded pictures similarly than the decoder 2 does. The encoded picture buffer 1.5 ca be used as a pre-decoding buffer for a HRD 5. One aim of the virtual decoding in the HRD 5 is to eliminate a risk for decoding errors due to unbalanced encoding/decoding tasks. The HRD 5 includes a decoded picture buffer 5.2 (DPB) for temporarily storing pictures decoded by the HRD 5. Also in the HRD 5 both the reference picture buffering and the display picture buffering are combined and they use the same decoded picture buffer 5.2 thus reducing the memory requirements of the encoder 1. All decoded pictures stay in the unified buffer until they are no longer used as reference pictures and until their (virtual) display time is reached. The term virtual refers to the fact that in the HRD 5 of the encoder 1, in which the decoding is performed in this advantageous embodiment, the decoded pictures are not displayed but the HRD 5 only checks if there could be errors in the decoding process of the decoder 2 due to, for example, too small buffer size. If errors exist the HRD 5 can inform the encoder to change some encoding parameters, or the size of the DPB 2.1 of the decoder 1 can be increased, for example, by sending a SEI (Supplemental Enhancement Information) message to the decoder 1 in some implementations (unless the maximum size of the DPB is already in use).
The decoding can be simultaneous operation with encoding, or the encoder first creates the bitstream, and when the bitstream is ready, it will be input to HRD 5 for checking that the bitstream fulfils the HRD 5 and processing level requirements. The HRD may also create and modify some HRD parameters, such as the initial buffering delay in coded picture buffer, according to the characteristics of the coded stream.
To fulfil the purpose above, the reordering process shall not depend upon any HRD-related timing information, because such information may be absent in the decoder. At the same time, it should be allowed that the decoder doesn't obey HRD DTS and OTS accurately. For example, an application like streaming recorder would like to receive bit streams, decode them and store the decoded sequence as fast as possible or operates slower due to the transmission channel capacity. In this case, the HRD DTS and OTS can not be obeyed.
The present invention can be applied in many kind of systems and devices. The transmitting device 6 including the encoder 1 and optionally the HRD 5 advantageously include also a transmitter 7 to transmit the encoded pictures to the transmission channel 4. The receiving device 8 include the decoder 2, a receiver 9 to receive the encoded pictures, and a display 10 on which the decoded pictures can be displayed. The transmission channel can be, for example, a landline communication channel and/or a wireless communication channel. The transmitting device and the receiving device include also one or more processors 1.2, 2.2 which can perform the necessary steps for controlling the encoding/decoding process of video stream according to the invention. Therefore, the method according to the present invention can mainly be implemented as machine executable steps of the processors. The buffering of the pictures can be implemented in the memory 1.3, 2.3 of the devices. The program code 1.4 of the encoder can be stored into the memory 1.3. Respectively, the program code 2.4 of the decoder can be stored into the memory 2.3.
6 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6
Every citation, both waysCites: the store holds 4 of 5
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US5835149A | Cites | United States of America | – |
| US5909224A | Cites | United States of America | – |
| US5926227A | Cites | United States of America | – |
| US6289129B1 | Cites | United States of America | – |
| RIBAS-CORBERA J. ET AL.: 'A flexible decoder buffer model for JVT video coding' INTERNATIONAL CONFERENCE ON IMAGE PROCESSING (ICIP'02) vol. 2, 22 September 2002 - 25 September 2002, ROCHESTER, NY, UNITED STATES, pages II/493 - II/496, XP010608016 | Non-patent | – | – |
| REGUNATHAN ET AL: "Video Complexity Verifier (VCV) for HRD" JVT, 2ND MEETING, [Online] 29 January 2002 (2002-01-29), pages 1-18, Geneva, CH Retrieved from the Internet: URL:ftp3.int.ch/av-arch/video-site/0201_Ge n/JVT-B050.doc> [retrieved on 2005-07-08] | Non-patent | – | – |
| REGUNATHAN ET AL: "Video Complexity Verifier (VCV) for HRD", JVT, 2ND MEETING, 29 January 2002 (2002-01-29), Geneva, CH, pages 1 - 18, Retrieved from the Internet <URL:ftp3.int.ch/av-arch/video-site/0201_Gen/JVT-B050.doc> [retrieved on 20050708] | Non-patent | – | Examiner |
22 members in 13 offices
Priority claims19
| Document | Office | Kind | Date |
|---|---|---|---|
| 424409P | United States of America | – | |
| 42440902 | United States of America | P | |
| 42440902 | United States of America | P | |
| 429953P | United States of America | – | |
| 42995302 | United States of America | P | |
| 42995302 | United States of America | P | |
| 430712P | United States of America | – | |
| 43071202 | United States of America | P | |
| 43071202 | United States of America | P | |
| 0300832 | Finland | W | |
| 0300832 | Finland | W | |
| 424409P | – | – | – |
| 429953P | – | – | – |
| 430712P | – | – | – |
| FI2003000832 | – | – | – |
| US20020424409P | – | – | – |
| US20020429953P | – | – | – |
| US20020430712P | – | – | – |
| WO2003FI00832 | – | – | – |
Members22
| Document | Office | Kind | |
|---|---|---|---|
| WO2004043071A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2003276300A1 | Australia | A1 | |
| US2004179619A1 | United States of America | A1 | |
| TW200421878A | Taiwan Province of China | A | |
| MXPA05004627A | Mexico | A | |
| EP1559274A1 | European Patent Office (EPO) | A1 | |
| KR20050084678A | Republic of Korea | A | |
| RU2005117360A | Russian Federation | A | |
| TWI249356B | Taiwan Province of China | B | |
| JP2006506027A | Japan | A | |
| JP2006094544A | Japan | A | |
| EP1559274B1This record | European Patent Office (EPO) | B1 | |
| AT359673T | Austria | T | |
| ATE359673T1 | Austria | T1 | |
| DE60313205D1 | Germany | D1 | |
| KR100769234B1 | Republic of Korea | B1 | |
| DE60313205T2 | Germany | T2 | |
| RU2310290C2 | Russian Federation | C2 | |
| ES2285264T3 | Spain | T3 | |
| MY134659A | Malaysia | A | |
| JP4516016B2 | Japan | B2 | |
| US8107744B2 | United States of America | B2 |
79 legal events, as 12 offices reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | Office | |
|---|---|---|---|
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Ep patent has lapsedLapsedEUG | EUG | SE | |
| ExpiryMK07 | MK07 | AT | |
| Patent expired after termination of 20 yearsExpiredPE20 | PE20 | GB | |
| Announcement of lapse in spainLapsedFD2A | FD2A | ES | |
| Patent ceasedCeasedPL | PL | CH | |
| Patent expired because of reaching the maximum lifetime of a patentExpiredMK | MK | NL | |
| Expiry of rightR071 | R071 | DE | |
| Opt-out of the competence of the unified patent court (upc) registeredP01 | P01 | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Change of name, addressHC9C | HC9C | HU | |
| Change of name, addressHC9C | HC9C | HU | |
| Appointment of representativeFH1C | FH1C | HU | |
| Succession in titleGB9C | GB9C | HU | |
| Fee paymentPLFP | PLFP | FR | |
| Fee paymentPLFP | PLFP | FR | |
| Transmission of propertyTP | TP | FR | |
| Fee paymentPLFP | PLFP | FR | |
| Change of ownershipPD | PD | NL | |
| Change of the ownerPC | PC | AT | |
| AssignmentPUE | PUE | CH | |
| Transfer of patentPC2A | PC2A | ES | |
| Change of applicant/patenteeR081 | R081 | DE | |
| Change of representativeR082 | R082 | DE | |
| Fee paymentPLFP | PLFP | FR | |
| Amendments to the register in respect of changes of name or changes affecting rights (sect. 32/1977)REGISTERED BETWEEN 20150910 AND 20150916732E | 732E | GB | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| No opposition filedOpposition26N | 26N | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| No opposition filed within time limitOppositionORIGINAL CODE: 0009261PLBE | PLBE | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: NO OPPOSITION FILED WITHIN TIME LIMITSTAA | STAA | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Definitive protectionFG2A | FG2A | ES | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Fr: translation filedET | ET | EP | |
| Filing of the translation of the text of european patentsAG4A | AG4A | HU | |
| Translation of granted ep patentGrantedTRGR | TRGR | SE | |
| Ep patent valid in romaniaEPE | EPE | RO | |
| Corresponds to:REF | REF | EP | |
| European patents granted designating irelandGrantedFG4D | FG4D | IE | |
| New agentNV | NV | CH | |
| European patent takes effect as a national patent in ch/liEP | EP | CH | |
| Designated contracting statesAK | AK | EP | |
| European patent grantedGrantedFG4D | FG4D | GB | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| (expected) grantORIGINAL CODE: 0009210GRAA | GRAA | EP | |
| Grant fee paidORIGINAL CODE: EPIDOSNIGR3GRAS | GRAS | EP | |
| Information on inventor provided before grant (corrected)RIN1 | RIN1 | EP | |
| Information on inventor provided before grant (corrected)RIN1 | RIN1 | EP | |
| Information on inventor provided before grant (corrected)RIN1 | RIN1 | EP | |
| Despatch of communication of intention to grant a patentORIGINAL CODE: EPIDOSNIGR1GRAP | GRAP | EP | |
| Request for extension of the european patent (deleted)DAX | DAX | EP | |
| Request for examination filed17P | 17P | EP | |
| Designated contracting statesAK | AK | EP | |
| Request for extension of the european patentAX | AX | EP | |
| Public reference made under article 153(3) epc to a published international application that has entered the european phaseORIGINAL CODE: 0009012PUAI | PUAI | EP |
Numbers
- Publication
- 1559274
- Publication, DOCDB
- 1559274
- Publication, EPODOC
- EP1559274
- Application
- 3810480
- Application, DOCDB
- 03810480
- Application, EPODOC
- EP20030810480
Titles3
- German
- BILDPUFFERUNG FÜR PRÄDIKTIONSREFERENZEN UND ANZEIGE
- English
- PICTURE BUFFERING FOR PREDICTION REFERENCES AND DISPLAY
- French
- MISE EN MEMOIRE TAMPON D'IMAGES POUR REFERENCES ET AFFICHAGE PREDICTIFS
Classification
- CPC, 9
- H04N21/23406
- H04N19/51
- H04N21/44004
- H04N19/44
- H04N19/89
- H04N19/31
- H04N19/423
- H04N19/573
- H04N19/577
- IPC, 5
- H04N7 24
- H04N7 12
- H04N7 26
- H04N7 36
- H04N19 89
Designated states1
- Contracting states, 1
- Türkiye