On Tue, 19 Apr 2016 13:33:05 +0200 Anton Khirnov <[email protected]> wrote:
> 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. So the dst AVFrame passed to the API must be allocated "uncropped", but its width/height fields must have the cropped size? That's very complex and awkward, IMHO. As long as the API explicitly checks for these, it might be fine though. (Not sure how it's going to check the uncropped size, maybe play buffer tricks?) Here I think an explicit cropping rect on AVFrames would remove issues like these. By the way, what's also lacking is a way to transfer to a non-refcounted AVFrame. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
