On Wed, 7 Jun 2017 16:34:46 +0200 Steve Lhomme <[email protected]> wrote:
> On Wed, Jun 7, 2017 at 12:13 PM, Hendrik Leppkes <[email protected]> wrote: > > On Wed, Jun 7, 2017 at 9:10 AM, Steve Lhomme <[email protected]> wrote: > >> On Tue, Jun 6, 2017 at 6:51 PM, wm4 <[email protected]> wrote: > >>> This also adds support to avconv (which is trivial due to the new > >>> hwaccel API being generic enough). For now, this keeps avconv_dxva2.c as > >>> "dxva2-old", although it doesn't work as avconv.c can't handle multiple > >>> hwaccels with the same pixfmt. It will be removed in a later commit. > >>> > >>> The new decoder setup code in dxva2.c is significantly based on work by > >>> Steve Lhomme <[email protected]>, but with heavy changes/rewrites. > >>> --- > >>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c > >>> index 69d5908551..7a9182af9b 100644 > >>> --- a/libavcodec/hevcdec.c > >>> +++ b/libavcodec/hevcdec.c > >>> @@ -383,7 +383,7 @@ static void export_stream_params(AVCodecContext > >>> *avctx, const HEVCParamSets *ps, > >>> > >>> static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps) > >>> { > >>> - #define HWACCEL_MAX (CONFIG_HEVC_DXVA2_HWACCEL + > >>> CONFIG_HEVC_D3D11VA_HWACCEL + \ > >>> + #define HWACCEL_MAX (CONFIG_HEVC_DXVA2_HWACCEL + > >>> CONFIG_HEVC_D3D11VA_HWACCEL * 2 + \ > >>> CONFIG_HEVC_VAAPI_HWACCEL + > >>> CONFIG_HEVC_VDPAU_HWACCEL) > >>> enum AVPixelFormat pix_fmts[HWACCEL_MAX + 2], *fmt = pix_fmts; > >>> > >>> @@ -391,6 +391,7 @@ 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; > >>> + *fmt++ = AV_PIX_FMT_D3D11; > >> > >> Can this be configured when building ? Since I will not support the > >> new format anytime soon I'd rather not try this for every file we > >> decode for nothing. > >> > > > > The old version is first in the format list, so your app gets called > > with that first. Additional ifdefs everywhere and a configure option > > would get seriously messy, just to avoid one if check in the app that > > you should be having anyway (and possibly even do already?). Please > > don't :) > > Yes but in VLC if you select no HW acceleration we still try all > output formats until we find a matching configuration. I mean, it would be simple to just check whether the AV_PIX_FMT maps to something potentially useful in VLC, in the get_format callback? Even if it's just a "if (fmt != AV_PIX_FMT_D3D11)". > Also if the new format is better, shouldn't it come before the old one > ? (I wouldn't mind having D3D11 above DXVA2 as well) Hm, maybe. I feel like it shouldn't depend on the order, but at least there's nothing that would speed against it. So: AV_PIX_FMT_D3D11 AV_PIX_FMT_D3D11VA_VLD AV_PIX_FMT_DXVA2_VLD _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
