[FFmpeg-devel] [PATCH] avcodec: use looking up crop table method when do clip

[Ronald S. Bultje]

Hi,

On Mon, Aug 10, 2015 at 10:12 PM, 周晓勇 <zhouxiaoyong at loongson.cn> wrote:

>
>
>
> > -----原始邮件-----
> > 发件人: "Michael Niedermayer" <michael at niedermayer.cc>
> > 发送时间: 2015年8月11日 星期二
> > 收件人: "FFmpeg development discussions and patches" <
> ffmpeg-devel at ffmpeg.org>
> > 抄送:
> > 主题: Re: [FFmpeg-devel] [PATCH] avcodec: use looking up crop table method
> when do clip
> >
> > On Fri, Aug 07, 2015 at 05:30:01PM +0800, 周晓勇 wrote:
> > > based on last h264qpel optimization patch i have pushed
> > > do i need separate this patch to double? cause one file to change
> loongson arch
> > > use looking up crop table method may boost up decode on loongson, and
> with this patch x86 pass fate too
> >
> > > but i have not tested on other arch
> >
> > as this also changes x86, benchmarks on x86 are required
>
> test on Ubuntu 15.04 and cpu:
> time ./ffmepg -i 1280x720.mp4 -f rawvideo -an -vframes 4096 -y /dev/null
>
> Architecture:          x86_64
> CPU 运行模式：    32-bit, 64-bit
> Byte Order:            Little Endian
> CPU(s):                4
> On-line CPU(s) list:   0-3
> 每个核的线程数：2
> 每个座的核数：  2
> Socket(s):             1
> NUMA 节点：         1
> 厂商 ID：           GenuineIntel
> CPU 系列：          6
> 型号：              58
> Model name:            Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz
> 步进：              9
> CPU MHz：             1285.804
> CPU max MHz:           1800.0000
> CPU min MHz:           800.0000
> BogoMIPS:              3591.56
> 虚拟化：           VT-x
> L1d 缓存：          32K
> L1i 缓存：          32K
> L2 缓存：           256K
> L3 缓存：           3072K
> NUMA node0 CPU(s):     0-3
>
> no patch:
> real    0m14.362s
> user    0m48.380s
> sys     0m0.416s
>
> with patch:
> real    0m13.536s
> user    0m48.484s
> sys     0m0.476s
>
> test 3 times, almost same
>
> have out-of-array read error been fixed up?
> how to recurrence?
> could i try to fix the out-of-array read error, or redefine CLIP() in
> loongson branch?


The problem is that in various places where we use this macro, the value
can quite literally be 100s or even 1000s below 0 or over 255. We don't
quite know what the upper limit is to be honest. So we removed that
optimization. If you can figure out the theoretical upper/lower limit in
all users of these macros, or limit their usage only to these codecs where
we know the limits, maybe it's OK.

Ronald