[x264-devel] External motion vectors in x264

[Jason Garrett-Glaser]

On Tue, Nov 9, 2010 at 3:18 PM, Marco Munderloh
<munderl at tnt.uni-hannover.de> wrote:
> On 09.11.2010 23:32, Jason Garrett-Glaser wrote:
>> 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).
>
> The external motion vectors are there without costs and in high quality,
> and yes, performance is an issue. So what I want to know is how much
> time (complexity) can be saved by using this external motion vectors and
> what quality can be achieved compared to the x264 motion search
> (superfast to slower). In the end this thing should go into some
> hardware. Therefore this experiment if it's worth the afford.

An API for this sort of thing is complicated; it'll likely be easier
to decide on something sane if you drop by IRC (#x264dev on Freenode).

Dark Shikari