On 15/04/16 09:50, Anton Khirnov wrote:
> The reasoning is the same as for the previous commit.
> ---
> libavfilter/vf_hwdownload.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_hwdownload.c b/libavfilter/vf_hwdownload.c
> index 0ba1d98..0c0d630 100644
> --- a/libavfilter/vf_hwdownload.c
> +++ b/libavfilter/vf_hwdownload.c
> @@ -141,7 +141,8 @@ static int hwdownload_filter_frame(AVFilterLink *link,
> AVFrame *input)
> goto fail;
> }
>
> - output = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> + output = ff_get_video_buffer(outlink, ctx->hwframes->width,
> + ctx->hwframes->height);
> if (!output) {
> err = AVERROR(ENOMEM);
> goto fail;
> @@ -153,6 +154,9 @@ static int hwdownload_filter_frame(AVFilterLink *link,
> AVFrame *input)
> goto fail;
> }
>
> + output->width = outlink->w;
> + output->height = outlink->h;
> +
> err = av_frame_copy_props(output, input);
> if (err < 0)
> goto fail;
>
This kills hwdownload from vaapi for cropped frames because that uses
av_frame_copy() in av_hwframe_transfer_data() which ensures that the sizes
match.
For example:
./avconv -vaapi_device /dev/dri/card0 -hwaccel vaapi -hwaccel_output_format
vaapi -i test1080p.mp4 -an -vf 'format=vaapi|nv12,hwupload,hwdownload' out.mp4
Patch 2/3 will also do this, but I don't see an easy example.
Probably easier to fix on the vaapi side by messing with the sizes somehow
before the copy?
- Mark
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
