On 22/03/17 10:15, wm4 wrote: > On Wed, 22 Mar 2017 11:07:08 +0100 > Steve Lhomme <[email protected]> wrote: > >> On Wed, Mar 22, 2017 at 11:02 AM, wm4 <[email protected]> wrote: >>> On Wed, 22 Mar 2017 10:41:13 +0100 >>> Steve Lhomme <[email protected]> wrote: >>> >>>> --- >>>> libavcodec/hevcdec.c | 10 ++++++++++ >>>> 1 file changed, 10 insertions(+) >>>> >>>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c >>>> index e24ce1e3c..3b8fadff3 100644 >>>> --- a/libavcodec/hevcdec.c >>>> +++ b/libavcodec/hevcdec.c >>>> @@ -381,6 +381,14 @@ static void export_stream_params(AVCodecContext >>>> *avctx, const HEVCParamSets *ps, >>>> num, den, 1 << 30); >>>> } >>>> >>>> +#if CONFIG_HEVC_DXVA2_HWACCEL || CONFIG_HEVC_D3D11VA_HWACCEL >>>> ++static void add_dxva_constraints(AVCodecContext *avctx) >>>> +{ >>>> + avctx->coded_width = FFALIGN(avctx->coded_width, 128); >>>> + avctx->coded_height = FFALIGN(avctx->coded_height, 128); >>>> +} >>>> +#endif >>>> + >>>> static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps) >>>> { >>>> #define HWACCEL_MAX (CONFIG_HEVC_DXVA2_HWACCEL + >>>> CONFIG_HEVC_D3D11VA_HWACCEL + \ >>>> @@ -391,9 +399,11 @@ static enum AVPixelFormat get_format(HEVCContext *s, >>>> const HEVCSPS *sps) >>>> sps->pix_fmt == AV_PIX_FMT_YUV420P10) { >>>> #if CONFIG_HEVC_D3D11VA_HWACCEL >>>> *fmt++ = AV_PIX_FMT_D3D11VA_VLD; >>>> + add_dxva_constraints(s->avctx); >>>> #endif >>>> #if CONFIG_HEVC_DXVA2_HWACCEL >>>> *fmt++ = AV_PIX_FMT_DXVA2_VLD; >>>> + add_dxva_constraints(s->avctx); >>>> #endif >>>> #if CONFIG_HEVC_VAAPI_HWACCEL >>>> *fmt++ = AV_PIX_FMT_VAAPI; >>> >>> Seems a bit fragile to do it this way. Might be better to wait for >>> glorious future hwaccel improvements. >>> >>> We'll probably have an API that returns required surface format, >>> minimum surface number, and surface dimensions in a specific case. Then >>> decoder and hwaccel code would be cleanly separated. >> >> If that replaces reading coded_width/coded_height directly that might >> help. Otherwise in my case the information of which source codec is >> used with the hardware acceleration is lost by the time I get to >> allocate the surfaces and it should not depend on any libavcodec/util >> stuff. >> >> IMO coded_width/height should always have the proper value to allocate >> the surfaces. But if it makes more sense via an external API, fine >> with me. > > IMO it should contain whatever value the codec has natively, not > necessarily what hwaccel surfaces need to be allocated with. But I > agree that API users shouldn't be forced to duplicate determining the > surface size, which is where the new API comes into it.
Yep. I'll try to send a first run of this soon. - Mark _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
