Hi, 2014-08-31 21:24 GMT+02:00 Luca Barbato <[email protected]>: > Nothing is using it right now. > --- > libavcodec/avcodec.h | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > index 14440fe..c5fd990 100644 > --- a/libavcodec/avcodec.h > +++ b/libavcodec/avcodec.h > @@ -2920,8 +2920,7 @@ typedef struct AVHWAccel { > enum AVPixelFormat pix_fmt; > > /** > - * Hardware accelerated codec capabilities. > - * see FF_HWACCEL_CODEC_CAP_* > + * Hardware accelerated codec capabilities. (currently unused) > */ > int capabilities; > > -- > 1.8.5.1
Well, the initial use-case I had in mind, in view to supporting some hwaccel2 interfaces, was a capability bit to indicate it is possible to implicitly output to raw YUV buffers, possibly user-allocated, instead of dealing with VASurfaceID, VdpSurface id, or other excessive download/upload/sync mechanisms, etc. Another use-case is that for some hwaccels, it could be interesting to enable frame-level decoding, while also still allowing slice-level decoding in specific use cases. e.g. in dxva2/vaapi, that could be a way to enable "short" mode decoding in H.264 AVC, but keep "long" mode decoding for H.264 MVC. Having said that, I believe a simple comment update is fine as it is. An explicit deprecation attribute would not. Regards, -- Gwenole Beauchesne Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France Registration Number (RCS): Nanterre B 302 456 199 _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
