Why upward rounding in H.264?

Hi,

I found almost all of the average rounding in H.264 is upward rounding.

For example,

a=round((c+d)/2)=(c+d+1)>>1;

Why always upward rounding? Can we use downward rounding instead?

Best regards,
Davy

Davy wrote:
> Hi,
>
> I found almost all of the average rounding in H.264 is upward rounding.
>
> For example,
>
> a=round((c+d)/2)=(c+d+1)>>1;
>
> Why always upward rounding? Can we use downward rounding instead?
>

For two simple reasons:-

1.Standard rounding is defined as [0, 0.5) -> 0 (means excluding 0.5)
and [0.5, 1] -> 1.

2. That is how the standard is defined. If you go different from
standard and lo, you will have output which may not be bit exact to
standard defined output. No one would be interested in your codec.

-N

Nishu wrote:
> Davy wrote:
>> Hi,
>>
>> I found almost all of the average rounding in H.264 is upward rounding.
>>
>> For example,
>>
>> a=round((c+d)/2)=(c+d+1)>>1;
>>
>> Why always upward rounding? Can we use downward rounding instead?
>>
> 
> For two simple reasons:-
> 
> 1.Standard rounding is defined as [0, 0.5) -> 0 (means excluding 0.5)
> and [0.5, 1] -> 1.
> 
> 2. That is how the standard is defined. If you go different from
> standard and lo, you will have output which may not be bit exact to
> standard defined output. No one would be interested in your codec.

The standard specifies that procedure for good reason: it rounds to 
nearest. If an explanation of how it works is needed, ask again, but I 
think it's pretty obvious once you know what to look for.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:
> Nishu wrote:
> > Davy wrote:
> >> Hi,
> >>
> >> I found almost all of the average rounding in H.264 is upward rounding.
> >>
> >> For example,
> >>
> >> a=round((c+d)/2)=(c+d+1)>>1;
> >>
> >> Why always upward rounding? Can we use downward rounding instead?
> >>
> >
> > For two simple reasons:-
> >
> > 1.Standard rounding is defined as [0, 0.5) -> 0 (means excluding 0.5)
> > and [0.5, 1] -> 1.
> >
> > 2. That is how the standard is defined. If you go different from
> > standard and lo, you will have output which may not be bit exact to
> > standard defined output. No one would be interested in your codec.
>
> The standard specifies that procedure for good reason: it rounds to
> nearest. If an explanation of how it works is needed, ask again, but I
> think it's pretty obvious once you know what to look for.

0.5 is nearer to 1 than to 0?

Andor wrote:

> Jerry Avins wrote:
> > Nishu wrote:
> > > Davy wrote:
> > >> Hi,
> > >>
> > >> I found almost all of the average rounding in H.264 is upward rounding.
> > >>
> > >> For example,
> > >>
> > >> a=round((c+d)/2)=(c+d+1)>>1;
> > >>
> > >> Why always upward rounding? Can we use downward rounding instead?
> > >>
> > >
> > > For two simple reasons:-
> > >
> > > 1.Standard rounding is defined as [0, 0.5) -> 0 (means excluding 0.5)
> > > and [0.5, 1] -> 1.
> > >
> > > 2. That is how the standard is defined. If you go different from
> > > standard and lo, you will have output which may not be bit exact to
> > > standard defined output. No one would be interested in your codec.
> >
> > The standard specifies that procedure for good reason: it rounds to
> > nearest. If an explanation of how it works is needed, ask again, but I
> > think it's pretty obvious once you know what to look for.
>
> 0.5 is nearer to 1 than to 0?

http://en.wikipedia.org/wiki/Rounding

http://www.aaamath.com/est27a-rounding.html

random google picks.

Nishu wrote:
> Andor wrote:
>
> > Jerry Avins wrote:
> > > Nishu wrote:
> > > > Davy wrote:
> > > >> Hi,
> > > >>
> > > >> I found almost all of the average rounding in H.264 is upward rounding.
> > > >>
> > > >> For example,
> > > >>
> > > >> a=round((c+d)/2)=(c+d+1)>>1;
> > > >>
> > > >> Why always upward rounding? Can we use downward rounding instead?
> > > >>
> > > >
> > > > For two simple reasons:-
> > > >
> > > > 1.Standard rounding is defined as [0, 0.5) -> 0 (means excluding 0.5)
> > > > and [0.5, 1] -> 1.
> > > >
> > > > 2. That is how the standard is defined. If you go different from
> > > > standard and lo, you will have output which may not be bit exact to
> > > > standard defined output. No one would be interested in your codec.
> > >
> > > The standard specifies that procedure for good reason: it rounds to
> > > nearest. If an explanation of how it works is needed, ask again, but I
> > > think it's pretty obvious once you know what to look for.
> >
> > 0.5 is nearer to 1 than to 0?
>
> http://en.wikipedia.org/wiki/Rounding

Nishu,

the OP's question was "why does the standard specify that we round up,
ie.round( 0.5 ) = 1? why can't we round down, ie.round( 0.5 ) = 0?".

Obviously, your original answer was the correct one: it's just the
convention of this standard. I questioned Jerry's assertion that there
was a good reason for this convention: "it rounds to nearest". I don't
see 0.5 nearer to 1 than to 0.

Andor wrote:
> Jerry Avins wrote:
>> Nishu wrote:
>>> Davy wrote:
>>>> Hi,
>>>>
>>>> I found almost all of the average rounding in H.264 is upward rounding.
>>>>
>>>> For example,
>>>>
>>>> a=round((c+d)/2)=(c+d+1)>>1;
>>>>
>>>> Why always upward rounding? Can we use downward rounding instead?
>>>>
>>> For two simple reasons:-
>>>
>>> 1.Standard rounding is defined as [0, 0.5) -> 0 (means excluding 0.5)
>>> and [0.5, 1] -> 1.
>>>
>>> 2. That is how the standard is defined. If you go different from
>>> standard and lo, you will have output which may not be bit exact to
>>> standard defined output. No one would be interested in your codec.
>> The standard specifies that procedure for good reason: it rounds to
>> nearest. If an explanation of how it works is needed, ask again, but I
>> think it's pretty obvious once you know what to look for.
> 
> 0.5 is nearer to 1 than to 0?

If that one instance is what you mean by rounding up, then yes: the 
algorithm is biased to round up. The bias is small. .4999 rounds down.

One way to avoid (most of) the bias is setting .5 aside as a special 
case, and rounding that to the nearest even number. (Odd works also, but 
not as splitting-hairs well.)

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Andor wrote:
> Nishu wrote:
>> Andor wrote:
>>
>>> Jerry Avins wrote:
>>>> Nishu wrote:
>>>>> Davy wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I found almost all of the average rounding in H.264 is upward rounding.
>>>>>>
>>>>>> For example,
>>>>>>
>>>>>> a=round((c+d)/2)=(c+d+1)>>1;
>>>>>>
>>>>>> Why always upward rounding? Can we use downward rounding instead?
>>>>>>
>>>>> For two simple reasons:-
>>>>>
>>>>> 1.Standard rounding is defined as [0, 0.5) -> 0 (means excluding 0.5)
>>>>> and [0.5, 1] -> 1.
>>>>>
>>>>> 2. That is how the standard is defined. If you go different from
>>>>> standard and lo, you will have output which may not be bit exact to
>>>>> standard defined output. No one would be interested in your codec.
>>>> The standard specifies that procedure for good reason: it rounds to
>>>> nearest. If an explanation of how it works is needed, ask again, but I
>>>> think it's pretty obvious once you know what to look for.
>>> 0.5 is nearer to 1 than to 0?
>> http://en.wikipedia.org/wiki/Rounding
> 
> Nishu,
> 
> the OP's question was "why does the standard specify that we round up,
> ie.round( 0.5 ) = 1? why can't we round down, ie.round( 0.5 ) = 0?".
> 
> Obviously, your original answer was the correct one: it's just the
> convention of this standard. I questioned Jerry's assertion that there
> was a good reason for this convention: "it rounds to nearest". I don't
> see 0.5 nearer to 1 than to 0.

I interpreted the OP's question more broadly. .5 --> 1 was an example, 
ans might as well have have been .2 --> 1. To me, "round up" is the 
opposite of "truncate" = "round down".

Davy,

When you wrote "round up", what did you mean?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:
> Andor wrote:
> > Jerry Avins wrote:
> >> Nishu wrote:
> >>> Davy wrote:
> >>>> Hi,
> >>>>
> >>>> I found almost all of the average rounding in H.264 is upward rounding.
> >>>>
> >>>> For example,
> >>>>
> >>>> a=round((c+d)/2)=(c+d+1)>>1;
> >>>>
> >>>> Why always upward rounding? Can we use downward rounding instead?
> >>>>
> >>> For two simple reasons:-
> >>>
> >>> 1.Standard rounding is defined as [0, 0.5) -> 0 (means excluding 0.5)
> >>> and [0.5, 1] -> 1.
> >>>
> >>> 2. That is how the standard is defined. If you go different from
> >>> standard and lo, you will have output which may not be bit exact to
> >>> standard defined output. No one would be interested in your codec.
> >> The standard specifies that procedure for good reason: it rounds to
> >> nearest. If an explanation of how it works is needed, ask again, but I
> >> think it's pretty obvious once you know what to look for.
> >
> > 0.5 is nearer to 1 than to 0?
>
> If that one instance is what you mean by rounding up, then yes: the
> algorithm is biased to round up. The bias is small. .4999 rounds down.

I thought you were going to pull out some metric where 0.5 is closer to
1 than to 0 :-).

>
> One way to avoid (most of) the bias is setting .5 aside as a special
> case, and rounding that to the nearest even number. (Odd works also, but
> not as splitting-hairs well.)

Alternatively, using random rounding, one can avoid special cases: p in
[0,1] is rounded towards 1 with probability p and to 0 with probability
1 - p.

Regards,
Andor

Andor wrote:
> Alternatively, using random rounding, one can avoid special cases: p in
> [0,1] is rounded towards 1 with probability p and to 0 with probability
> 1 - p.

Random rounding? Like, randomly round down or round up? Wouldn't that 
double rounding error? (Error would be <1.0 for this scheme, <=0.5 for 
0..0.5 rounds down, otherwise round up)

Cheers,
Nicholas Sherlock

-- 
http://www.sherlocksoftware.org