[XviD-devel] Changes to get_pmv2

[Tom Jacobs]

thank you guel. i will try this.

 if understand right, to give it a wrong prediction for the left macroblock
i can, in get_pmv2, return zeroMV when it looks for the left block. this
would make the prediction ignore the block, cos it hasnt got a vector.
doing this will not stop the calculated prediction from being stored in the
bitstream and from being used when the next row is being calculated.

or have i confused myself?

or would you need to call get_pmv2 again block my block (in serial) after
the searches have been (in parallel)

Tom


Quoting Christoph Lampert <chl at math.uni-bonn.de>:

> On Mon, 20 Sep 2004, Tom Jacobs wrote:
>
> > hi
> >
> > i am still threading mostion estimation and am looking at ways of
> gettin
> > around the problem of each blocks predictions being based on its
> > neighbours.
> > ideally we would make the prediction from the pixel above, below, left
> and
> > right. because of the scan method used in ME we have changed it to left
> top
> > and top right.
> > you there be a great quality decrease if it was changed to top left,
> top,
> > top right? for my work this would make it possible for a whole row to
> be
> > processed in parallel.
>
> Hi,
>
> the decrease in quality (or rather the raise in bitrate) wouldn't be big,
> but, if you write the resulting MVs to the bitstream like that, it would
> violate the MPEG-4 standard, the resulting bitstream wouldn't be playable
> by MPEG-4 codecs anymore.
> What you can do is do ME with the "wrong" predictors, but then afterwards
> use the right predictors to write the bitsream. This will slow the
> process down a little, and cause another raise in bitrate, but unless you
> target very low bitrates, I guess it would still be acceptable.
>
> However, more important, the gain in speed isn't that big by doing only
> ME
> in parallel. I tried a while ago (when machine were much slower),
> splitting the image vertically in two halfs. But the overhead of creating
> the threads, doing ME and rejoining the results was bigger than expected.
> The speedup was less than 10% for 2 CPUs.
>
> gruel
>
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>