[FFmpeg-devel] [PATCH] fix add_bytes_mmx and add_bytes_l2_mmx for w <= 15
Mon Jun 23 19:05:23 CEST 2008
On Mon, 23 Jun 2008, Reimar D?ffinger wrote:
> On Mon, Jun 23, 2008 at 01:08:32AM +0200, Michael Niedermayer wrote:
>> On Sun, Jun 22, 2008 at 09:34:08AM +0200, Reimar D?ffinger wrote:
>>> Like in attached patch? Unfortunately the benchmark number seem
>>> completely unrealistic to me, going by them there would be 4x speedup in
>>> some cases...
>>> Though I tested with png images, maybe they are a horrible testcase.
>>> Example numbers:
>>> previous code:
>>> 39350 dezicycles in blub, 1 runs, 0 skips
>>> 24925 dezicycles in blub, 2 runs, 0 skips
>>> 16242 dezicycles in blub, 4 runs, 0 skips
>>> 11603 dezicycles in blub, 8 runs, 0 skips
>>> 9407 dezicycles in blub, 16 runs, 0 skips
>> 16 runs? Dont you have a file that uses that code more than 16 times?
> Well, the pngs created with e.g. mplayer -vo png do not use it at all,
> but I used some other png files.
-vo png is uncompressed.
-vo png:z=9 uses whatever prediction mode libpng thinks is best, which
may or may not include add_bytes depending on the image content.
> Well, in that respect it works, but with a "proper" benchmark it seems
> to be slower - I strongly suspect that the png code hardly ever uses
> counts larger than 15.
Prediction mode is selected per line. Thus, when add_bytes is used, the
only possible size is the width of your image.
More information about the ffmpeg-devel