[x264-devel] External motion vectors in x264

[Marco Munderloh]

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.

> 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.

This might be a great thing to have (not only for my current problem)
but also for additional research of me and other people!

Tanks a lot,
 Marco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5799 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20101110/87a52a0d/attachment.bin>