[x264-devel] x264 multithread predictors

[Nadir Raimondo]

Hi Jason, thanks for your help.

I've tried with sliced-threads parameters and it seems to resolve my 
problem (obviously with fps decrease). I have read that with slice-based 
every frame is split into slices, each slice encoded by one thread.
I suppose that in x264, without extra parameters, each frames correspond 
to a single slice so each thread encode frames sequentially and can 
handle long MV.
Is it correct?

Thanks.
Nadir


On 01/08/2013 07:21 PM, Jason Garrett-Glaser wrote:
> On Tue, Jan 8, 2013 at 9:09 AM, Nadir Raimondo <raimondo at ismb.it> wrote:
>> Dear all,
>>
>> I'm trying to integrate into the x264 library a custom motion estimation
>> algorithm for special sequences of images with low overlap.
>>
>> I calculate new predictors using ancillary data provided by some sensors to
>> increase encoding accuracy. Given the low initial overlap, motion vectors
>> (and predictor) are very long (about 260 pixels, 1040 in qpel).
>>
>> All works fine for P frames, with frames sequence IPPPPPPP the gain is about
>> 1 dB. Now I'm trying to extend the algorithm for B frames (GOP IBPBPBPBP)
>> but I have a problem in multithread scenario (with single thread all work
>> correctly).
>> It seems that inside x264_me_search_ref function in me.c the MV predictors
>> between B and P frames are limited by a mv_y_max_qpel value. As a
>> consequence the output MV is not correct and macroblock is encoded as intra.
>>
>> I thought x264 multithread encoding was performed on minigop so first thread
>> 1 encode I, thread 2 encode P and than B, thread 3 encode next P and B and
>> so on. Does this predictor limitation occur when the B frame encoding has
>> already started while P frame encoding is still pending? or am I doing
>> something wrong?
> http://akuvian.org/src/x264/sliceless_threads.txt
>
> Jason
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>