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.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to