Hi, The specification points out a problem in the dc prediction : "This procedure describes the complete process of undoing the DC prediction to recover the original DC values. Because it is possible to add a value as large as 580 to the predicted DC coefficient value at every block, which will then be used to increase the predictor for the next block, the reconstructed DC value could overflow a 16-bit integer." And explains the solution : "This is handled by truncating the result to a 16-bit signed representation, simply throwing away any higher bits in the two?s complement representation of the number." which is done in the algorithm: * Truncate DC to a 16-bit representation by dropping any higher-order bits. But why dropping higher-order bits ? With a simple exemple with an unsigned integer 100001 If I truncate this number to a 4-bit representation by dropping any higher-order bits I get 0001 which is far from the initial value. I think the value could be rounded to 1111 which is better ? To round DC, which is signed with a 17-bit representation, to a 16 bit signed value, this gives : if (DC<? (2^15)) DC = -2^15 else if (DC>2^(15)-1) DC = -2^(15)-1 Am I wrong ? Regards J.F.
On 03/25/2011 07:38 AM, Jonathan Fabrizio wrote:> * Truncate DC to a 16-bit representation by dropping any higher-order bits. > > But why dropping higher-order bits ?1. In practice, this overflow does not occur. A non-buggy encoder is very unlikely to produce streams that overflow because this would result in bad quality. 2. Checking for overflow (which occurs not at all or very rarely) would waste CPU time, because most processors do not have fast saturating arithmetic. 3. Theora is designed to be backwards-compatible with On2 VP3, so the core decoding algorithms could not be changed. --Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20110325/590d3344/attachment.pgp
Le 25/03/2011 13:52, Benjamin M. Schwartz a ?crit :> On 03/25/2011 07:38 AM, Jonathan Fabrizio wrote: >> * Truncate DC to a 16-bit representation by dropping any higher-order bits. >> >> But why dropping higher-order bits ? > 1. In practice, this overflow does not occur. A non-buggy encoder is very > unlikely to produce streams that overflow because this would result in bad > quality. > > 2. Checking for overflow (which occurs not at all or very rarely) would > waste CPU time, because most processors do not have fast saturating > arithmetic. > > 3. Theora is designed to be backwards-compatible with On2 VP3, so the core > decoding algorithms could not be changed. > > --Ben >thank you for your response J.F.