| Message ID | 1558715987-3692-1-git-send-email-joshua.allmann@gmail.com |
|---|---|
| State | New |
| Headers | show |
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.
Actually, I've submitted the fix a while ago and got ignored. I then wrote to Timo directly to his email and got ignored again. https://github.com/Svechnikov/ffmpeg-scale-cuda-problem Le ven. 24 mai 2019 19:25, Timo Rothenpieler <timo@rothenpieler.org> a écrit : > 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. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On 24.05.2019 21:32, Сергей Свечников wrote: > Actually, I've submitted the fix a while ago and got ignored. I then wrote > to Timo directly to his email and got ignored again. > https://github.com/Svechnikov/ffmpeg-scale-cuda-problem I simply missed the original mail to the list, sorry about that. The mail you sent to me directly got caught by Spamassassin due to "Excess base64 in From: field", which it also tagged this mail with, but it coming via this list saved it.
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)
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(+)