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

[Niklas Haas via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

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