| < draft-bankoski-vp8-bitstream-05.txt | draft-bankoski-vp8-bitstream-06.txt > | |||
|---|---|---|---|---|
| Network Working Group J. Bankoski | Network Working Group J. Bankoski | |||
| Internet-Draft J. Koleszar | Internet-Draft J. Koleszar | |||
| Intended status: Informational L. Quillio | Intended status: Informational L. Quillio | |||
| Expires: February 3, 2012 J. Salonen | Expires: February 12, 2012 J. Salonen | |||
| P. Wilkins | P. Wilkins | |||
| Y. Xu | Y. Xu | |||
| Google Inc. | Google Inc. | |||
| August 2, 2011 | August 11, 2011 | |||
| VP8 Data Format and Decoding Guide | VP8 Data Format and Decoding Guide | |||
| draft-bankoski-vp8-bitstream-05 | draft-bankoski-vp8-bitstream-06 | |||
| Abstract | Abstract | |||
| This document describes the VP8 compressed video data format, | This document describes the VP8 compressed video data format, | |||
| together with a discussion of the decoding procedure for the format. | together with a discussion of the decoding procedure for the format. | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on February 3, 2012. | This Internet-Draft will expire on February 12, 2012. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 3, line 7 ¶ | skipping to change at page 3, line 7 ¶ | |||
| 13.3. Token Probabilities . . . . . . . . . . . . . . . . . . 69 | 13.3. Token Probabilities . . . . . . . . . . . . . . . . . . 69 | |||
| 13.4. Token Probability Updates . . . . . . . . . . . . . . . 73 | 13.4. Token Probability Updates . . . . . . . . . . . . . . . 73 | |||
| 13.5. Default Token Probability Table . . . . . . . . . . . . 78 | 13.5. Default Token Probability Table . . . . . . . . . . . . 78 | |||
| 14. DCT and WHT Inversion and Macroblock Reconstruction . . . . . 83 | 14. DCT and WHT Inversion and Macroblock Reconstruction . . . . . 83 | |||
| 14.1. Dequantization . . . . . . . . . . . . . . . . . . . . . 83 | 14.1. Dequantization . . . . . . . . . . . . . . . . . . . . . 83 | |||
| 14.2. Inverse Transforms . . . . . . . . . . . . . . . . . . . 84 | 14.2. Inverse Transforms . . . . . . . . . . . . . . . . . . . 84 | |||
| 14.3. Implementation of the WHT Inversion . . . . . . . . . . 85 | 14.3. Implementation of the WHT Inversion . . . . . . . . . . 85 | |||
| 14.4. Implementation of the DCT Inversion . . . . . . . . . . 87 | 14.4. Implementation of the DCT Inversion . . . . . . . . . . 87 | |||
| 14.5. Summation of Predictor and Residue . . . . . . . . . . . 90 | 14.5. Summation of Predictor and Residue . . . . . . . . . . . 90 | |||
| 15. Loop Filter . . . . . . . . . . . . . . . . . . . . . . . . . 91 | 15. Loop Filter . . . . . . . . . . . . . . . . . . . . . . . . . 91 | |||
| 15.1. Filter Geometry and Overall Procedure . . . . . . . . . 92 | 15.1. Filter Geometry and Overall Procedure . . . . . . . . . 91 | |||
| 15.2. Simple Filter . . . . . . . . . . . . . . . . . . . . . 94 | 15.2. Simple Filter . . . . . . . . . . . . . . . . . . . . . 94 | |||
| 15.3. Normal Filter . . . . . . . . . . . . . . . . . . . . . 98 | 15.3. Normal Filter . . . . . . . . . . . . . . . . . . . . . 98 | |||
| 15.4. Calculation of Control Parameters . . . . . . . . . . . 103 | 15.4. Calculation of Control Parameters . . . . . . . . . . . 103 | |||
| 16. Interframe Macroblock Prediction Records . . . . . . . . . . 105 | 16. Interframe Macroblock Prediction Records . . . . . . . . . . 105 | |||
| 16.1. Intra-Predicted Macroblocks . . . . . . . . . . . . . . 105 | 16.1. Intra-Predicted Macroblocks . . . . . . . . . . . . . . 105 | |||
| 16.2. Inter-Predicted Macroblocks . . . . . . . . . . . . . . 106 | 16.2. Inter-Predicted Macroblocks . . . . . . . . . . . . . . 106 | |||
| 16.3. Mode and Motion Vector Contexts . . . . . . . . . . . . 107 | 16.3. Mode and Motion Vector Contexts . . . . . . . . . . . . 107 | |||
| 16.4. Split Prediction . . . . . . . . . . . . . . . . . . . . 113 | 16.4. Split Prediction . . . . . . . . . . . . . . . . . . . . 113 | |||
| 17. Motion Vector Decoding . . . . . . . . . . . . . . . . . . . 117 | 17. Motion Vector Decoding . . . . . . . . . . . . . . . . . . . 117 | |||
| 17.1. Coding of Each Component . . . . . . . . . . . . . . . . 117 | 17.1. Coding of Each Component . . . . . . . . . . . . . . . . 117 | |||
| skipping to change at page 91, line 44 ¶ | skipping to change at page 91, line 44 ¶ | |||
| Loop filtering is one of the more computationally-intensive aspects | Loop filtering is one of the more computationally-intensive aspects | |||
| of VP8 decoding. This is the reason for the existence of the | of VP8 decoding. This is the reason for the existence of the | |||
| optional, less-demanding simple filter type. | optional, less-demanding simple filter type. | |||
| Note carefully that loop filtering must be skipped entirely if | Note carefully that loop filtering must be skipped entirely if | |||
| loop_filter_level at either the frame header level or macroblock | loop_filter_level at either the frame header level or macroblock | |||
| override level is 0. In no case should the loop filter be run with a | override level is 0. In no case should the loop filter be run with a | |||
| value of 0; it should instead be skipped. | value of 0; it should instead be skipped. | |||
| To facilitate efficient implementation, the VP8 decoding algorithms | ||||
| generally, and the loop filter especially, were designed with SIMD | ||||
| ("Single Instruction Multiple Datum" or "integer vector") processors | ||||
| in mind. The reference decoder implementation of loop filtering | ||||
| (found in loopfilter.c) is, in effect, a portable SIMD specification | ||||
| of the loop filtering algorithms intended to simplify a realization | ||||
| on an actual SIMD processor. | ||||
| Unfortunately, the approach taken there does not lead to maximal | ||||
| efficency (restricted to the C language, that is) and, as far as a | ||||
| pure algorithm specification is concerned, is in places obscure. For | ||||
| example, various aspects of filtering are conditioned on absolute | ||||
| differences lying below certain thresholds. An ordinary C | ||||
| implementation would simply discriminate amongst these behaviors | ||||
| using if statements. The reference decoder instead effects this by | ||||
| "masking arithmetic", that is, using "and" operations to | ||||
| (conditionally) zero-out values to be added or subtracted to pixels. | ||||
| Furthermore, the structure holding the various threshold values is | ||||
| artificially parallelized. While this mimics closely the approach | ||||
| taken in vector-processor machine language, it is not how one usually | ||||
| programs in C. | ||||
| In this document, we take a different approach and present the | ||||
| algorithms in a more straightforward, idiomatic, and terse C style. | ||||
| Together with the reference version, we hope to provide the "best of | ||||
| both worlds", that is, a pure algorithm specification here and a | ||||
| strong suggestion as to an optimal actual implementation in | ||||
| loopfilter.c. | ||||
| We begin by discussing the aspects of loop filtering that are | We begin by discussing the aspects of loop filtering that are | |||
| independent of the controlling parameters and type of filter chosen. | independent of the controlling parameters and type of filter chosen. | |||
| 15.1. Filter Geometry and Overall Procedure | 15.1. Filter Geometry and Overall Procedure | |||
| The Y, U, and V planes are processed independently and, except for | The Y, U, and V planes are processed independently and identically. | |||
| the values of certain control parameters (derived from the | ||||
| loop_filter_level and sharpness_level), identically. | ||||
| The loop filter acts on the edges between adjacent macroblocks and on | The loop filter acts on the edges between adjacent macroblocks and on | |||
| the edges between adjacent subblocks of a macroblock. All such edges | the edges between adjacent subblocks of a macroblock. All such edges | |||
| are horizontal or vertical. For each pixel position on an edge, a | are horizontal or vertical. For each pixel position on an edge, a | |||
| small number (two or three) of pixels adjacent to either side of the | small number (two or three) of pixels adjacent to either side of the | |||
| position are examined and possibly modified. The displacements of | position are examined and possibly modified. The displacements of | |||
| these pixels are at a right angle to the edge orientation, that is, | these pixels are at a right angle to the edge orientation, that is, | |||
| for a horizontal edge, we treat the pixels immediately above and | for a horizontal edge, we treat the pixels immediately above and | |||
| below the edge position, for a vertical edge, we treat the pixels | below the edge position, for a vertical edge, we treat the pixels | |||
| immediately to the left and right of the edge. | immediately to the left and right of the edge. | |||
| skipping to change at page 94, line 9 ¶ | skipping to change at page 93, line 28 ¶ | |||
| 1. Macroblock coding mode is neither B_PRED nor SPLTMV; and | 1. Macroblock coding mode is neither B_PRED nor SPLTMV; and | |||
| 2. There is no DCT coefficient coded for the whole macroblock. | 2. There is no DCT coefficient coded for the whole macroblock. | |||
| For these macroblocks, loop filtering for edges between subblocks | For these macroblocks, loop filtering for edges between subblocks | |||
| internal to a macroblock is effectively skipped. This skip strategy | internal to a macroblock is effectively skipped. This skip strategy | |||
| significantly reduces VP8 loop-filtering complexity. | significantly reduces VP8 loop-filtering complexity. | |||
| Edges between macroblocks and those between subblocks are treated | Edges between macroblocks and those between subblocks are treated | |||
| with different control parameters (and, in the case of the normal | with different control parameters (and, in the case of the normal | |||
| filter, with different algorithms); luma and chroma edges are also | filter, with different algorithms). Except for pixel addressing, | |||
| treated with different control parameters. Except for pixel | there is no distinction between the treatment of vertical and | |||
| addressing, there is no distinction between the treatment of vertical | horizontal edges. Luma edges are always 16 pixels long, chroma edges | |||
| and horizontal edges. Luma edges are always 16 pixels long, chroma | are always 8 pixels long, and the segments straddling an edge are | |||
| edges are always 8 pixels long, and the segments straddling an edge | treated identically; this of course facilitates vector processing. | |||
| are treated identically; this of course facilitates vector | ||||
| processing. | ||||
| Because many pixels belong to segments straddling two or more edges, | Because many pixels belong to segments straddling two or more edges, | |||
| and so will be filtered more than once, the order in which edges are | and so will be filtered more than once, the order in which edges are | |||
| processed given above must be respected by any implementation. | processed given above must be respected by any implementation. | |||
| Within a single edge, however, the segments straddling that edge are | Within a single edge, however, the segments straddling that edge are | |||
| disjoint and the order in which these segments are processed is | disjoint and the order in which these segments are processed is | |||
| immaterial. | immaterial. | |||
| Before taking up the filtering algorithms themselves, we should | Before taking up the filtering algorithms themselves, we should | |||
| emphasize a point already made: Even though the pixel segments | emphasize a point already made: Even though the pixel segments | |||
| End of changes. 8 change blocks. | ||||
| 44 lines changed or deleted | 11 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||