[FFmpeg-devel] GSoC Weekly report (libswscale)

[Pedro Arthur]

Hi,
Since the last patch I was trying to improve the performance regression.
First I tried to process horizontal lines in batches, processing
(horizontal_filter_size + n)
lines at a time. I also tried to remove branch code from the processing
function, for example:
int process(...) {
    if (c->hcscale_fast) {
        do_x()
    } else {
         do_y()
     }
}
changed to:
int process_fast(...) {do_x()}
int process_(...) {do_y()}

But these changes more or less didn't improve the performance at all.
As the most significant difference between the old and new code is that
the color conversion is separated from the horizontal scaling I merged
back the color conversion with the horizontal scaling and the performance
seemed to be on par with the original code again.

One point I would like to comment is the performance measurement method. I
used 3 methods
1 - using the scaling code, scale each line n times and measure the total
scaling time
this method was the most reliable as the measured time deviation between
different runs
was > 0.1%.
2 - Call the scaling function n times, this method was not much reliable
with total time
deviation of 0.1% to 20%.
3 - Run the program n times,  measured time as not reliable deviation of
10%-30%.
For all the 3 methods the time measurement as done for only the horizontal
scaling code.

I think method 2 and 3 would be more close to real world usage but its
deviation is to high
to get any conclusion from its results.


Using method 1 with merge color conversion + horizontal scaling performance
seems to be
on par with the original code.

Some numbers. Performance penalty %. (< 0 means gain)

A - New code
B - New code with merged color conversion and horizontal scaling
C - B + line batches

Method   |     A    |     B    |     C    |
-------------------------------------------
1        |    ~3%   |   ~0%    |  0% ~ 2% |
2        | -2% ~ 9% | -6% ~ 8% | -7% ~ 7% |
3        | -4% ~ 11%| -5% ~ 6% | -7% ~ 3% |
-------------------------------------------


In short, A is at least 3% slower in all methods,  B has no penalties in
method 1 but in 2 and 3
is bad in some cases while good in others. C seems average in 1 and 2 while
good in 3.
Yet I can not guarantee these claims as the deviation in 2 and 3 is pretty
high.

It would be good if some one could check the code performance in real world
cases. Or if there
is some better method of measuring the performance let me know.

I'm also attaching the patches for each code. swscale.patch is for A,
swscale_merge.patch is for B
and swscale_merge_batch.patch is for C.
I think that with some validation of these numbers the patch can be applied.

Thanks,
Pedro.





2015-08-11 16:29 GMT-03:00 Michael Niedermayer <michael at niedermayer.cc>:

> On Tue, Aug 11, 2015 at 03:17:55PM -0300, Pedro Arthur wrote:
> > Hi,
> >
> > The past week I worked on refactoring the vertical scaler code.
> > The vertical scaler was not split in scaling pass and color conversion
> pass
> > (as the horizontal scaler)
> > because the output functions currently merge these passes and it would
> > require rewriting all these
> > functions.
> > This week I should clean up the code, check the new code performance and
> > get the patch ready
> > for push.
>
> ./ffmpeg -i lena.pnm -s 4096x2048 test.mp4
> segfaults
>
> ./ffmpeg -i fate-suite/cine/bayer_gbrg8.cine  -vf scale=300:300 -vframes 1
> img.jpg
> all green image
>
> ./ffplay -i ~/videos/lena.pnm -vf format=yuv410p
> mostly green
>
> also please submit patches more often than once a week(as theres
> little time left) and if you
> easily can then please split the patch into one for horizontal and
> one for vertical. But if this is alot of work then leave it rather
> in one patch.
> For example if you could get the horizontal code bug free without
> speed regression then that could be pushed and the amount of
> code to work on would be half ...
>
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is what and why we do it that matters, not just one of them.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: swscale.patch
Type: text/x-patch
Size: 34128 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150815/4e76e30a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: swscale_merge.patch
Type: text/x-patch
Size: 39281 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150815/4e76e30a/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: swscale_merge_batch.patch
Type: text/x-patch
Size: 40688 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150815/4e76e30a/attachment-0002.bin>