[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