[x264-devel] The size of search area in reference frames
john sisi
sisi.john1 at gmail.com
Mon Jun 14 09:12:36 CEST 2010
I think you are right but what is the exact difference between
--merange and --mvrange? The default value of merange is set to 16
while the default value of mvrange is -1 (Auto).
Ideally, full or exhaustive search must achieve the best PSNR
performance but I got a weird result: I encoded foreman (CIF) at
256kbps with default settings and I got an average PSNR-Y of 34.26 dB
for a specific frame. Then I used --me "esa" to enable the exhaustive
search. This time I got 34.04 dB on the same frame! I expected to get
a higher PSNR but the result is not consistent with my expectation. I
use only one reference frame. But what is the problem? Thanks again,
John
On Sun, Jun 13, 2010 at 11:58 PM, Radek Czyz <radoslaw at syskin.cjb.net> wrote:
> On 14/06/2010 3:48 PM, john sisi wrote:
>>
>> Thanks for the reply. Since moving objects can move further over a
>> larger interval of time, so a larger search area must be used for
>> motion estimation. The larger the search area, the higher the
>> computational complexity.
>
> Yes, but only in case of full search.
> Any sane motion search algorithm doesn't have a concept of "search area" at
> all. It can only have a maximum vector size allowed but increasing this
> value has no effect on complexity (for values large enough).
>
>> But as you mentioned, x264 always uses a fixed window size (or maximum
>> search range or vector size) on all reference frames which I think is
>> not an efficient strategy. But am I right?
>
> Full search could be the definition of inefficiency :) so of course. But
> nobody uses it so it doesn't matter.
>
> Regards
>
>
> In other words, assuming that the size of
>>
>> the search window (for either fullpel or quarterpel motion estimation)
>> in the first reference frame is 32x32, this size in the second
>> reference frame must be about 64x64 (assuming that objects has a
>> linear speed) and so on.
>>
>> But as you mentioned, x264 always uses a fixed window size (or maximum
>> search range or vector size) on all reference frames which I think is
>> not an efficient strategy. But am I right?
>>
>> John
>>
>> On Sun, Jun 13, 2010 at 11:15 PM, Jason Garrett-Glaser
>> <darkshikari at gmail.com> wrote:
>>>
>>> On Sun, Jun 13, 2010 at 10:54 PM, Radek Czyz<radoslaw at syskin.cjb.net>
>>> wrote:
>>>>
>>>> On 14/06/2010 2:45 PM, john sisi wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> As you may know better, due to the movement of objects, the search
>>>>> area for motion estimation in reference frames must be increased in
>>>>> order to achieve better PSNR performance. But it seems that x264
>>>>> doesn't increase the size of the search area in the reference frames
>>>>> and it always uses the same size. But am I right? If not, please
>>>>> correct me by showing where this issue is handled. Thanks,
>>>>>
>>>>> John
>>>>
>>>> Hi,
>>>>
>>>> Since you're asking for details of x264, can you describe your question
>>>> more
>>>> in terms of x264's workings?
>>>>
>>>> Particularly, what is this "search area" (do you mean during fullsearch
>>>> only?) and from what it should be increased (that is, why was "it"
>>>> decreased
>>>> in the first place).
>>>>
>>>> x264 has maximum vector size as part of its configuration but, as its
>>>> name
>>>> suggests, it's already a maximum allowed, and it's up to the user to
>>>> increase it if he wants to allow more.
>>>
>>> x264 by default uses the maximum allowed by the spec (for maximum
>>> vector size). The user can't ask for more.
>>>
>>> Dark Shikari
>>> _______________________________________________
>>> x264-devel mailing list
>>> x264-devel at videolan.org
>>> http://mailman.videolan.org/listinfo/x264-devel
>>>
>> _______________________________________________
>> x264-devel mailing list
>> x264-devel at videolan.org
>> http://mailman.videolan.org/listinfo/x264-devel
>>
>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
More information about the x264-devel
mailing list