[FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: clean padding when upload qsv frames

[Eoff, Ullysses A]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Wenbin Chen
> Sent: Wednesday, December 01, 2021 11:41 PM
> To: ffmpeg-devel at ffmpeg.org
> Cc: Chen, Wenbin <wenbin.chen at intel.com>
> Subject: [FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: clean padding when upload qsv frames
> 
> When we upload a frame that is not padded as MSDK requires, we create a
> new AVFrame to copy data. The frame's padding data is uninitialized so
> it brings run to run problem. For example, If we run the following
> command serveral times we will get different outputs.
> 
> ffmpeg -init_hw_device qsv=qsv:hw -qsv_device /dev/dri/renderD128
> -filter_hw_device qsv -f rawvideo -s 192x200 -pix_fmt p010
> -i 192x200_P010.yuv -vf "format=nv12,hwupload=extra_hw_frames=16"
> -c:v hevc_qsv output.265
> 
> According to https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#encoding-procedures
> "Note: It is the application's responsibility to fill pixels outside
> of crop window when it is smaller than frame to be encoded. Especially
> in cases when crops are not aligned to minimum coding block size (16
> for AVC, 8 for HEVC and VP9)"
> 
> I add a function to fill padding area with border pixel to fix this
> run2run problem, and also move the new AVFrame to global structure
> to reduce redundant allocation operation to increase preformance.
> 
> Signed-off-by: Wenbin Chen <wenbin.chen at intel.com>

[UAE] *bump*... Reviews encouraged!  This run-to-run issue has been
around for way too long and causes a lot of intermittent noise/failures
in some automated regression testing.  Let's get it fixed, please!
Gstreamer has not had this issue and/or fixed it a long time ago!