Thread safety of VP9 motion search

[hcb]

Is there any particular order that VP9 blocks must be motion-searched? I suspect they must be evaluated one at a time in raster order but I'm not sure. If there is no order, does that mean that a multicore encoder could work on a few blocks at a time, or would priority problems arise when the evaluated block shifts overlap?

[Pieter Kapsenberg]

The way an encoder works is not defined by the specification. As long as the bitstream that you end up creating is legal, you can do whatever you want.

In  general, multithreading is a good way to parallelize motion search. But once you start to write the bitstream, you may find that for some blocks a (slightly) different vector may actually result in better overall compression than the "ideal" one found by motion search.

On Thu, Feb 23, 2017 at 11:23 AM, hcb <designingo...@gmail.com> wrote:

Is there any particular order that VP9 blocks must be motion-searched? I suspect they must be evaluated one at a time in raster order but I'm not sure. If there is no order, does that mean that a multicore encoder could work on a few blocks at a time, or would priority problems arise when the evaluated block shifts overlap?

--
You received this message because you are subscribed to the Google Groups "Codec Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codec-devel+unsubscribe@webmproject.org.
To post to this group, send email to codec...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/codec-devel/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[hcb]

Yes, I know encoder design isn't specified. I just wondered if there would be problems if blocks overlapped after being motion-shifted. Wouldn't a block that came before (raster-wise) another be processed by the decoder first, in which case the encoder would need to take that into account? Maybe it doesn't matter, I'm just wondering. I also wonder if a full 1/4 pel motion search, like within x pixels in all directions, would be "good" enough, at least a lot better than diamond, to the point where the "ideal" one found is indeed the best. 

On Thursday, February 23, 2017 at 2:30:15 PM UTC-5, Pieter Kapsenberg wrote:

The way an encoder works is not defined by the specification. As long as the bitstream that you end up creating is legal, you can do whatever you want.

In  general, multithreading is a good way to parallelize motion search. But once you start to write the bitstream, you may find that for some blocks a (slightly) different vector may actually result in better overall compression than the "ideal" one found by motion search.

On Thu, Feb 23, 2017 at 11:23 AM, hcb <designingo...@gmail.com> wrote:

Is there any particular order that VP9 blocks must be motion-searched? I suspect they must be evaluated one at a time in raster order but I'm not sure. If there is no order, does that mean that a multicore encoder could work on a few blocks at a time, or would priority problems arise when the evaluated block shifts overlap?

--
You received this message because you are subscribed to the Google Groups "Codec Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to codec-devel...@webmproject.org.

[Pieter Kapsenberg]

Motion vectors point to images that have always been previously decoded, not pixels in the current image so there is no causality problem there.

[hcb]

So you're saying motion searching is not about comparing chunks of the current inter frame to a reference intra/inter frame, but rather moving chunks of one or more reference frames to approximate the current frame as closely as possible?

[Pieter Kapsenberg]

No. When you are encoding an inter frame, for any given block you search which same-shaped block in one of the available previous pictures best matches it. Those are pictures that have previously been encoded, and then reconstructed (re-decoded).