[FFmpeg-devel] [PATCH] lavfi/vf_scale_cuda: Reset frame size after acquiring from hwframe.

Timo Rothenpieler timo at rothenpieler.org
Fri May 24 20:25:00 EEST 2019


On 24.05.2019 18:39, Josh Allmann wrote:
> The first frame is scaled correctly, and subsequent frames are
> over-scaled / cropped since the frame data is reset with the
> hwframe after each invocation of the scaler.
> 
> The hwframe-allocated frame has a width/height that is 32-bit
> aligned. The scaler uses this aligned width / height as its target,
> leading to "over-scaling" and then cropping of the result.
> 
> To generate a broken test sample:
> 
>    ffmpeg -hwaccel cuvid -c:v h264_cuvid -i <input> -an \
>      -lavfi scale_cuda=w=426:h=240 -c:v h264_nvenc <output>
> ---
> 
> Tested with NV12 and 420P inputs.
> 
> Noting that YUV444P seems generally broken - both before/after this patch.
> 
> 
>   libavfilter/vf_scale_cuda.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
> index 6b1ef2bb6f..13eb3ad24c 100644
> --- a/libavfilter/vf_scale_cuda.c
> +++ b/libavfilter/vf_scale_cuda.c
> @@ -489,6 +489,8 @@ static int cudascale_scale(AVFilterContext *ctx, AVFrame *out, AVFrame *in)
>   
>       av_frame_move_ref(out, s->frame);
>       av_frame_move_ref(s->frame, s->tmp_frame);
> +    s->frame->width = s->planes_out[0].width;
> +    s->frame->height= s->planes_out[0].height;
>   
>       ret = av_frame_copy_props(out, in);
>       if (ret < 0)

This is certainly correct. The original author of this must have wrongly 
assumed that av_frame_copy_props takes care of it.
Wonder how this was never noticed before.

Applied, thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4538 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190524/572c29c5/attachment.bin>


More information about the ffmpeg-devel mailing list