[theora-dev] Multi-Thread Theora Encoder
Felipe Portavales Goldstein
portavales at gmail.com
Fri Oct 12 11:39:30 PDT 2007
On 10/12/07, Maik Merten <maikmerten at gmx.net> wrote:
> Felipe Portavales Goldstein schrieb:
> > The first fragment of the second half of the screen could use the last
> > motion vector from the previous fragment on the first half of the
> > screen. This LAST_MV mode is used to save the bits of a new Motion
> > Vector added to the stream.
> > But, when using the threads, if we want to run the motion vector
> > search in parallel, we must avoid data dependencies between threads
> > and therefore we loose a little compression.
> Actually I wonder if it isn't feasible to do a "postprocessing" step
> after motion search to search for missed LAST_MV opportunities, thus
> restoring compression efficiency. The set of possibly affected fragments
> (the ones on the thread "boundaries") is known or pretty small and I
> guess it may be possible to do this rather fast.
> Chances are I may be missing some obvious problems, though.
Yes, you are right.
I can do a simple post search quite fast, (linear time of number of MVs found)
If I find two identical MVs, I change the fragmet MV type to LAST_MV
and drop the duplicate MV.
But this algorithm will not be identical of the original non threaded.
Because the original can drop even potential different MVs if the cost
of adding a new MV is higher than the gain in using the new MV
compared to using the LAST_MV.
I mean, you could have a lower error finding a new MV, but this
improvement minus the cost of adding a new MV could not be better than
just use the LAST_MV.
do what you sugested can improve the coding efficiency, and is worth
Thanks for the tip :-)
> theora-dev mailing list
> theora-dev at xiph.org
Felipe Portavales Goldstein <portavales at gmail>
Undergraduate Student - IC-UNICAMP
Computer Systems Laboratory
More information about the theora-dev