[FFmpeg-devel] [RFC] performance tuning, memcpy

[FFmpeg-devel] [RFC] performance tuning, memcpy

[Thilo Schunck via ffmpeg-devel]

Hi Team!

Apologies for maybe breaking submit rules but as of now I don't know better :-)

I figured out on arm "hwdownload" is quite slow.
I turns out this is caused by imgutils.c image_copy_plane which does a memcpy loop

     for (;height > 0; height--) {

        memcpy(dst, src, bytewidth);

        dst += dst_linesize;
        src += src_linesize;
    }

As a POC, quick'n dirty I create 4 threads and split the copy. In my case this improved fps from about ~26 to 51

./ffmpeg -hide_banner -hwaccel v4l2request -hwaccel_output_format drm_prime \
 -threads 4 \
 -i ../Big_Buck_Bunny_720_10s_10MB.mp4 \
 -filter_complex "[0:v]hwdownload,format=nv12[myOut]" -map "[myOut]"  \
 -f null -

Maybe someone is interested in this improvement with cleaned code. 
My PoC uses hard coded 4 threads which is for sure bad ...

Btw. This may apply to other locations as well.


Also, but specific for arm there is a tuned memcpy replacement:
https://github.com/simonjhall/copies-and-fills/
which also speeds up ffmpeg (and of course everything else).


 Best from Germany
     Thilo

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] performance tuning, memcpy

[Niklas Haas via ffmpeg-devel]

On Monday, November 10th, 2025 at 3:09 PM, Thilo Schunck via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:

> 
> 
> Hi Team!
> 
> Apologies for maybe breaking submit rules but as of now I don't know better :-)
> 
> I figured out on arm "hwdownload" is quite slow.
> I turns out this is caused by imgutils.c image_copy_plane which does a memcpy loop
> 
> for (;height > 0; height--) {
> 
> 
> memcpy(dst, src, bytewidth);
> 
> dst += dst_linesize;
> src += src_linesize;
> }
> 
> As a POC, quick'n dirty I create 4 threads and split the copy. In my case this improved fps from about ~26 to 51
> 
> ./ffmpeg -hide_banner -hwaccel v4l2request -hwaccel_output_format drm_prime \
> -threads 4 \
> -i ../Big_Buck_Bunny_720_10s_10MB.mp4 \
> -filter_complex "[0:v]hwdownload,format=nv12[myOut]" -map "[myOut]" \
> -f null -
> 
> Maybe someone is interested in this improvement with cleaned code.
> My PoC uses hard coded 4 threads which is for sure bad ...

I could see `hwcontext_drm` specifically using an internal `AVSliceThread` for `RAM<->VRAM` transfers. We have to be careful about thread safety, though, as `av_hwframe_transfer_data` may be called from multiple threads. So in the worst case, we need to create and tear down the `AVSliceThread` per frame being transferred..

As a possible alternative, `vf_hwdownload` could become frame-threaded, though that would only improve throughput, not latency.

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org