VP8 Maximum Motion Vector Size
Habeeb Quazi
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
John Koleszar
Yes, the behavior you describe is intentional. Note that it's the
best_mv that is clamped, not the sum.
John
Habeeb Quazi
On Oct 9, 2:06 am, John Koleszar <jkoles...@google.com> wrote:
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
> --
> 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.
>
>
Krzysztof Bartczak
Since you have a differential no more that 255 pixels it is very
unlikely the vectors would stack up to reach more than 4095 pixels.
Think about it from the encoder side, this is what would have to
happen to see the stacking up:
1st picture - object moving 255 pixels relative to the begining
2nd picture - object accellerates and moving 510 pixels relative to
picture 1
3rd picture - object accelerates more and moving 765 pixels relative
to picture 2
etc.
Not so many phisical objects are accelerating (a rocket, a car or
train sometimes) and I belive it is not worth special encoding
feature.
Note that for software encoders/decoders this does not make to much
difference, but for hardware every additional bit of precision is
precious. Every additional bit requires more silicon to process that
bit, therefore is more expensive and adds a litte to final power
consumption.
In my opinion
- option a) is way much better
- if you really want the vectors to stack up to 16383, please clearly
state (and limit that in encoder) that the vectors have to be encoded
using no more that 18 bits.
- if I convinced you that the vector stack-up is not worth the
efford, please put a limitation on existing encoder and state in the
spec that encoders must not generate vectors bigger than 12, 13, 14 or
15 bits (you choose). Have you ever seen the stacking up in existing
streams?
Less bits == less hardware == cheaper hardware == less power
consumption
Regards,
Krzysztof
> > To unsubscribe from this group, send email to webm-discuss+unsubscr...@webmproject.org.
Jim
than the picture size.
On Oct 11, 9:33 am, Krzysztof Bartczak <krzysztof.bartc...@gmail.com>
wrote:
>
> - Show quoted text -
John Koleszar
The MV is allowed to point outside the frame. VP8 calls this
"unrestricted motion vectors" or UMVs in the bitstream guide. The data
outside the frame is synthesized by extending the last visible pixel
outward "infinitely". How you handle this is implementation specific.
What the libvpx decoder does at the moment is keep a small border
(~20px) of these synthesized pixels, then clamp any MVs that point
farther into the border than are actually available. The important
thing is that this secondary clamping not affect the MVs used in the
MV decoding process. So let's say:
MVe = clamp1(best_mv) + new_mv
MVp = clamp2(MVe)
It's important that the MVe value be preserved as it's part of the
motion vector decoding context model. ie, This MVe could be a future
MV's best_mv, but MVp can not be. MVe is defined by the bitstream. but
MVp is completely implementation independent.
John
Krzysztof Bartczak
Vectors are allowed to point outside the frame. Same standards aslo
limits the size of the motion vectors. It is ofter specified in
profiles or levels.
See the Yaowu's post. In current encoder/decoder MVe is stored on 16
bits.
When you use only the equation:
equal than 4096x4096.
I assume you do not want rely on overflows, so to avoid it, suggest to
ammend the specification and restrict the the maximum motion vector
size range to [-4096, 4095].
Note that, using stack up, it is unlikely to get a stream with vectors
close to that limit. If you want VP8 to be hardware friendly please
consider limiting MVe to even smaller number, like 15 or 14 bits.
Krzysztof
On Oct 11, 2:32 pm, John Koleszar <jkoles...@google.com> wrote:
Paul Wilkins
[-4096, 4095].
Even though it will be hard to reach this in steps of 255 I think it
is important that the limiting behavior is specified clearly.
Actually if people start regularly coding >= quad HD the limit of 255
pixels on the maximum step may become a problem and this is something
we need to consider in regard to future plans.