[x264-devel] External motion vectors in x264

[Jason Garrett-Glaser]

On Tue, Nov 9, 2010 at 1:21 PM, Marco Munderloh
<munderl at tnt.uni-hannover.de> wrote:
> On 09.11.2010 21:15, Jason Garrett-Glaser wrote:
>> On Tue, Nov 9, 2010 at 12:01 PM, Marco Munderloh
>> <munderl at tnt.uni-hannover.de> wrote:
>>>> Can you explain your particular use-case in more detail?
>>>> Additionally, how are you going to signal partition types and
>>>> macroblock modes?
>>>
>>> At the moment I just want to reuse some already calculated motion
>>> vectors from a preprocessor to reduce computing time. For the decision
>>> on what macroblock mode and partition to use I still want to use the RD
>>> optimizer of x264. To get motion vectors for every partition I'm
>>> thinking of smart interpolating them from the known motion vectors which
>>> are on a sub macroblock level.
>>
>> What about reference frame indices?  Perhaps more importantly, what
>> about frame types?  You don't know before running x264 which frames
>> will be P and which will be B, so you can't possibly have computed the
>> motion vectors for the appropriate frametype combinations unless you
>> just computed all possible motion vector pairings.
>
> For now, I want to use P frames with one reference frame only. Maybe
> later, the motion vectors can be extrapolated assisted by the known
> motion to support more than one reference frame. B frames might also be
> supported later by inverting and realigning the motion vector for p+1.
> Just to make sure: this is not about coding efficiency.

Is this about performance?  An extremely fast x264 motion search is
generally better than any motion vectors provided by some other
source, and in "superfast", less than 1/4 of total time is spent on
motion search (less than half of which is spent in the fullpel
search).

If you're looking to give x264 potentially "good" vectors that it
should check against (but not drop the entire motion search), I could
add an API for adding arbitrary predictors.

Dark Shikari