Re: VP8 Maximum Motion Vector Size
Yaowu Xu
magnitude of VP8 motion vectors
1. The limit on transmitted motion vectors, where each motion vector
component magnitude is limited to [-1023, 1023] at 1/4 pixel
resolution, i.e. effectively, [-255, 255] of full pixels.
2. Due to the addition of motion vectors, effective motion vectors in
use within vp8 encoder and decoder can have magnitudes higher than the
limits in 1. But as the reference decoder/encoder clamp all motion
vectors to effectively within the actual image + UMV border, the
motion vector size is therefore limited by the image size with UMV
border at full pixel resolution. It should be noted here that motion
vectors are stored mostly at 1/8 pixel resolution within reference
encoder/decoder.
3. The data type used in reference encoder/decoder to store motion
vector components is 16 bit "short" integer, this limits the size of
motion vector component to [-32768, 32767] in 1/8 pixel resolution,
i.e. [-4096, 4095] in full pixel values.
All above work fine for all video with resolution lower than Quad-HD,
but we realize that there is a problem when input video resolution
goes beyond 4096x4096, i.e. a 16 bit "short" integer is not long
enough to store a motion vector component with value higher than 4096
full pixels.
At this point, it is necessary to amend the VP8 specification to
clarify the motion vector value behavior for image size larger than
4096x4096, there are a couple of options here:
a. specify the maximum motion vector size range to [-4096, 4095] full
pixels regardless the image size (VP8 define 14 raw bits for width and
height, 16383x16383 is the maximum possible image size), this requires
additional enforcement of the size limit in encoder/decoders for
bit-stream compliant.
b. do not specify a maximum motion vector size, but change the
decoder/encoder source code to replace the 16 bit short integer data
type with a 32 bit integer data type to accommodate even larger motion
vector size.
We would like to hear from the community on this issue, comments are welcome.
Thanks,
Yaowu
On Sat, Oct 9, 2010 at 4:34 AM, Habeeb Quazi <hab...@gmail.com> wrote:
> But the sum will be clamped before interpolation?
>
>
> On Oct 9, 2:06 am, John Koleszar <jkoles...@google.com> wrote:
>> On Fri, Oct 8, 2010 at 12:14 PM, Habeeb Quazi <habe...@gmail.com> wrote:
>> > Hi,
>> > I have a question regarding what the maximum motion vector size can
>> > be.
>> > It states in the bitstream guide that an MV coded in the bitstream can
>> > take a value of +/- 1023 in 1/4 pixel units. This would need (1+10)
>> > bits to store.
>> > However, the decoded MV is added to the best_mv and thus would need 12
>> > bits to store.
>> > My question is, how does VP8 handle this addition of MVs, since on
>> > each macroblock if we keep on adding a large best_mv to a large
>> > decoded new_mv, the value of the motion vector will keep increasing
>> > until it is clamped by the picture size. So, is it intentional to
>> > allow the MV to stack up and eventually be clamped or is it supposed
>> > to be clamped to a specific range i.e. +/- 1023 (1/4 pixel units).
>> > Hope someone can reply soon.
>> > Thanks!
>> > Habeeb
>>
>> Yes, the behavior you describe is intentional. Note that it's the
>> best_mv that is clamped, not the sum.
>>
>> John
>
> --
> You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
> To post to this group, send email to webm-d...@webmproject.org.
> To unsubscribe from this group, send email to webm-discuss...@webmproject.org.
> For more options, visit this group at http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.
>
>