Quoting Mark Thompson (2016-04-17 20:39:40) > On 15/04/16 12:29, wm4 wrote: > > On Fri, 15 Apr 2016 10:58:51 +0100 > > Mark Thompson <[email protected]> wrote: > > > >> The hw frame used as reference has an attached size but it need not > >> match the actual size of the surface, so enforcing that the sw frame > >> used in copying matches its size exactly is not useful. > >> --- > >> libavutil/hwcontext_vaapi.c | 12 ++++++++++++ > >> 1 file changed, 12 insertions(+) > >> > >> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c > >> index 1a385ba..fd7f7b7 100644 > >> --- a/libavutil/hwcontext_vaapi.c > >> +++ b/libavutil/hwcontext_vaapi.c > >> @@ -779,6 +779,9 @@ static int vaapi_transfer_data_from(AVHWFramesContext > >> *hwfc, > >> AVFrame *map; > >> int err; > >> > >> + if (dst->width > hwfc->width || dst->height > hwfc->height) > >> + return AVERROR(EINVAL); > >> + > > > > Would it be simpler for everyone not to fail and to use the minimum size > > in each dimension? > > In general I think that it should error out if the size doesn't match > exactly, because it's just a recipe for either silent unexpected cropping or > use of uninitialised data. > > This specific change allows the bottom/right cropping case to work as a user > might expect after Anton's change to the hwdownload semantics to fix vdpau, > which given the cropping situation I think is unfortunate but necessary. I > don't think the exception should be extended further without a good reason. > > > Alternatively, we could document the constraints on which sizes can be > > passed to the API. > > Yes. This should probably be documented on av_hwframe_transfer_data() > regardless of what we decide here.
After some thinking, I'd say the way it should behave in the following way: - the sw frames passed to transfer_data SHOULD be allocated to the pool width, otherwise the API is allowed to fail if the allocated size is too small - both frames passed to transfer data MUST have the same display size set, and if possible only that size will be transferred If everyone agrees, I'll send a new set that would make it behave like this. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
