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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
