Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On Thu, Jul 15, 2021 at 5:49 AM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > James Almer > > Sent: Thursday, 15 July 2021 05:21 > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > d3d11va support, added mfxhdlpair > > > > On 7/15/2021 12:10 AM, Soft Works wrote: > > > > > > > > >> -Original Message- > > >> From: ffmpeg-devel On Behalf Of > > >> Xiang, Haihao > > >> Sent: Thursday, 15 July 2021 04:35 > > >> To: ffmpeg-devel@ffmpeg.org > > >> Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > >> d3d11va support, added mfxhdlpair > > >> > > >> On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: > > >>> On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: > > >>>> On Tue, Nov 3, 2020 at 7:47 PM Artem Galin > > >> wrote: > > >>>> > > >>>>> Adding DX11 relevant device type checks and adjusting callbacks > > >>>>> with proper MediaSDK pair type support. > > >>>>> > > >>>>> Extending structure for proper MediaSDK pair type support. > > >>>>> > > >>>>> Signed-off-by: Artem Galin . > > >>>> > > >>>> > > >>>> Patchset obviously closes the gap of DirectX 11 support and already > > >>>> checked with several apps that use FFMPEG. > > >>>> > > >>>> Any particular review comments should be yet expected? > > >>>> > > >>>> Changes seem to be straight forward and incorporate prev. comments. > > >>>> > > >>>> thank in advance > > >>>> > > >>>> regards > > >>>> Max > > >>> > > >>> There are some issues pointed out by Soft Works related to switching > > >>> the default to DX11 breaking existing command lines with DX9, plus > > >>> an OpenCL<->QSV interop regression this would introduce that > > >>> according to him should be easy to fix. > > >>> > > >>> If those are addressed, the set should be good. > > >> > > >> If we may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021- > > >> June/281778.html > > >> (qsvdec: add support for HW_DEVICE_CTX method) first, we should be > > >> able to use the common device stuff to initialize d3d11va device for > > >> QSV and needn't use child_device_type to specify child device. > > > > > > There's no doubt that the new method will be better, but the point is > not > > to break existing command lines. From my experience, ffmpeg usually > avoids > > to break established command line patterns, which is a good thing imo. > > > > > > Anything more official than my perception? Please feel free to chime > > > in... ;-) > > > > That patch appears to attempt to maintain support for existing command > > lines for a deprecation period, something we've done before with other > > hwaccels like cuvid, so if it's really better, it's fine and acceptable. > ^ > > Hi James, > > "That patch" that preserves compatibility doesn't exist yet. We need to > make sure that command lines using the '--child_device' parameter will > continue to work, while Haihao's patch will be the "future way": > > > -init_hw_device d3d11va=d3d11va:xxx -init_hw_device qsv@d3d11va > > The new behaviour that is introduced by this patch is that an initialized > hw device can now be applied to qsv decoders (currently only to filter > graphs and qsv encoders). > > Additionally, the default should remain to be D3D9 (if none of the above > is specified) as laid out earlier - again for maintaining compatibility but > also for better robustness and performance. > > Upon introduction of DX11/D3D11VA support, it makes sense to make it default as well, this would help for upcoming implementations and general usages in the long run, including new usages, as headless platforms support, which is an obvious D3D9 gap, as an example. Compatibility is still preserved and available with D3D9 path, there is no functional change. If D3D9 is critical for further usage - it has to be requested explicitly. regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On Tue, Nov 3, 2020 at 7:47 PM Artem Galin wrote: > Adding DX11 relevant device type checks and adjusting callbacks with > proper MediaSDK pair type support. > > Extending structure for proper MediaSDK pair type support. > > Signed-off-by: Artem Galin > . Patchset obviously closes the gap of DirectX 11 support and already checked with several apps that use FFMPEG. Any particular review comments should be yet expected? Changes seem to be straight forward and incorporate prev. comments. thank in advance regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: let the SDK to choose the encoding mode by default
it would be good to describe the change a bit more clearly,
something like: Allows MediaSDK *runtime *to choose LowPower/non-LowPower
modes, if not explicitly set.
regards
Max
On Mon, Sep 28, 2020 at 9:32 AM Haihao Xiang wrote:
> The SDK may support LowPower and non-LowPower modes, some features are
> available only under one of the two modes. It is hard for user to know
> whether a feature is supported under the given mode, so let the SDK to
> choose a mode for encoding by default.
> ---
> libavcodec/qsvenc.c | 6 --
> libavcodec/qsvenc.h | 2 +-
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 1ed8f5d973..cff96e59c9 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -510,7 +510,7 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
> }
> }
>
> -if (q->low_power) {
> +if (q->low_power == 1) {
> #if QSV_HAVE_VDENC
> q->param.mfx.LowPower = MFX_CODINGOPTION_ON;
> #else
> @@ -519,7 +519,9 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
> q->low_power = 0;
> q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
> #endif
> -} else
> +} else if (q->low_power == -1)
> +q->param.mfx.LowPower = MFX_CODINGOPTION_UNKNOWN;
> +else
> q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
>
> q->param.mfx.CodecProfile = q->profile;
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index 4f579d1db1..55cc1a 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -96,7 +96,7 @@
> { "adaptive_b", "Adaptive B-frame placement",
> OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> 1, VE }, \
> { "b_strategy", "Strategy to choose between I/P/B-frames",
> OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1,
> VE }, \
> { "forced_idr", "Forcing I frames as IDR frames",
> OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 = 0 }, 0,
> 1, VE }, \
> -{ "low_power", "enable low power mode(experimental: many limitations by
> mfx version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, {
> .i64 = 0}, 0, 1, VE},\
> +{ "low_power", "enable low power mode(experimental: many limitations by
> mfx version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, {
> .i64 = -1}, -1, 1, VE},\
>
> extern const AVCodecHWConfigInternal *ff_qsv_enc_hw_configs[];
>
> --
> 2.25.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user plugin since libmfx 1.28
On Fri, Aug 21, 2020 at 9:29 AM Xiang, Haihao
wrote:
> On Fri, 2020-08-21 at 05:48 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Haihao Xiang
> > > Sent: Friday, August 21, 2020 7:23 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Haihao Xiang
> > > Subject: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user plugin
> since
> > > libmfx 1.28
> > >
> > > MFXVideoUSER_Load call is redundant since libmfx 1.28
> > > ---
> > > Fixed merge conflict when applying this patch by 'git am'
> > >
> > > libavcodec/qsv.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index
> > > 17720070f1..56a30ad642 100644
> > > --- a/libavcodec/qsv.c
> > > +++ b/libavcodec/qsv.c
> > > @@ -19,7 +19,6 @@
> > > */
> > >
> > > #include
> > > -#include
> > > #include
> > >
> > > #include
> > > @@ -36,6 +35,10 @@
> > > #include "avcodec.h"
> > > #include "qsv_internal.h"
> > >
> > > +#if !QSV_VERSION_ATLEAST(1, 28)
> > > +#include
> > > +#endif
> > > +
> > > #if QSV_VERSION_ATLEAST(1, 12)
> > > #include "mfx/mfxvp8.h"
> > > #endif
> > > @@ -295,6 +298,9 @@ enum AVPictureType ff_qsv_map_pictype(int
> > > mfx_pic_type) static int qsv_load_plugins(mfxSession session, const
> char
> > > *load_plugins,
> > > void *logctx) {
> > > +#if QSV_VERSION_ATLEAST(1, 28)
> > > +return 0;
> > > +#else
> > > if (!load_plugins || !*load_plugins)
> > > return 0;
> > >
> > > @@ -340,6 +346,7 @@ load_plugin_fail:
> > > }
> > >
> > > return 0;
> > > +#endif
> > >
> > > }
> >
> >
> > Hi,
> >
> > Are you sure this check is right? You are checking the libmfx version
> > against which ffmpeg is compiled.
> >
> > What happens, when a graphics driver supports only API level 1.21?
> >
>
> I understand your concern, however lots of features in FFmpeg are
> disabled/enabled against api version at compile-time.
>
>
have you checked if runtime checks with QSV_RUNTIME_VERSION_ATLEAST can be
avoided?
regards
Max
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fix memory leak in qsvenc.c
make sense. regards Max On Thu, Aug 13, 2020 at 4:15 AM Alex Pokotilo wrote: > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi/vf_vpp_qsv: fix the infinite loop while framerate lower than input
On Sun, Jul 5, 2020 at 5:56 PM Zhong Li wrote: > > > I can't see the benefit to use MSDK framerate conversion function. Is > > > it a good idea to drop it and use ffmpeg native fps filter instead? > > > > Reconsidering this, leaving the filter buggy doesn't seem to be > comfortable to me, > > hence IMHO it'll be better to have this bug fixed. > My suggestion would be just delete MSDK framerate conversion instead > of patch it. > Will send a patch if nobody against. > should be ok when comes with proper description, as comes with price of performance regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/qsvvpp: Work around a bug in MSDK where VPP processing hangs under certain conditions
On Sat, Jun 6, 2020 at 7:29 AM Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Max Dmitrichenko
> > Sent: Friday, June 5, 2020 3:09 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter/qsvvpp: Work around a bug
> > in MSDK where VPP processing hangs under certain conditions
> >
> > On Mon, May 25, 2020 at 12:40 AM Soft Works
> > wrote:
> >
> > > These are:
> > > - Dimensions are already aligned (e.g. 1920x800)
> > > - No scaling is done
> > > - Color format conversion (e.g. 10bit to 8bit)
> > >
> > > Example command:
> > > ffmpeg -c:v hevc_qsv -hwaccel qsv -i hevc_10bit_1920_800.mkv
> > > -filter_complex "scale_qsv=format=nv12" -c:v h264_qsv out.mkv
> > >
> > > Fix:
> > > - Increase the frame height to the next alignment value
> > >
> > > V2:
> > > - removed empty line
> > > - removed duplicated line
> > > ---
> > > libavfilter/qsvvpp.c | 7 ++-
> > > libavfilter/vf_scale_qsv.c | 9 -
> > > 2 files changed, 14 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c index
> > > 1bbb7a7e68..98d2353d1c 100644
> > > --- a/libavfilter/qsvvpp.c
> > > +++ b/libavfilter/qsvvpp.c
> > > @@ -420,6 +420,7 @@ static int init_vpp_session(AVFilterContext
> > > *avctx, QSVVPPContext *s)
> > > mfxHandleType handle_type;
> > > mfxVersion ver;
> > > mfxIMPL impl;
> > > +int height_align_adjust = 0;
> > > int ret, i;
> > >
> > > if (inlink->hw_frames_ctx) {
> > > @@ -463,9 +464,13 @@ static int init_vpp_session(AVFilterContext
> > > *avctx, QSVVPPContext *s)
> > > out_frames_ctx = (AVHWFramesContext *)out_frames_ref->data;
> > > out_frames_hwctx = out_frames_ctx->hwctx;
> > >
> > > +/* work around a bug in MSDK where VPP processing hangs under
> > > certain conditions */
> > > +if (inlink->h == outlink->h)
> > > +height_align_adjust = 1;
> > > +
> > > out_frames_ctx->format= AV_PIX_FMT_QSV;
> > > out_frames_ctx->width = FFALIGN(outlink->w, 32);
> > > -out_frames_ctx->height= FFALIGN(outlink->h, 32);
> > > +out_frames_ctx->height= FFALIGN(outlink->h +
> > > height_align_adjust, 32);
> > > out_frames_ctx->sw_format = s->out_sw_format;
> > > out_frames_ctx->initial_pool_size = 64;
> > > if (avctx->extra_hw_frames > 0) diff --git
> > > a/libavfilter/vf_scale_qsv.c b/libavfilter/vf_scale_qsv.c index
> > > 5259104a4f..303d2101a9 100644
> > > --- a/libavfilter/vf_scale_qsv.c
> > > +++ b/libavfilter/vf_scale_qsv.c
> > > @@ -181,8 +181,10 @@ static int init_out_pool(AVFilterContext *ctx,
> > > AVQSVFramesContext *out_frames_hwctx;
> > > enum AVPixelFormat in_format;
> > > enum AVPixelFormat out_format;
> > > +int height_align_adjust = 0;
> > > int i, ret;
> > >
> > > /* check that we have a hw context */
> > > if (!ctx->inputs[0]->hw_frames_ctx) {
> > > av_log(ctx, AV_LOG_ERROR, "No hw context provided on
> > > input\n"); @@ -191,6 +193,7 @@ static int init_out_pool(AVFilterContext
> > *ctx,
> > > in_frames_ctx =
> > > (AVHWFramesContext*)ctx->inputs[0]->hw_frames_ctx->data;
> > > in_frames_hwctx = in_frames_ctx->hwctx;
> > >
> > > in_format = in_frames_ctx->sw_format;
> > > out_format= (s->format == AV_PIX_FMT_NONE) ? in_format :
> > > s->format;
> > >
> > > @@ -200,9 +203,13 @@ static int init_out_pool(AVFilterContext *ctx,
> > > out_frames_ctx = (AVHWFramesContext*)outlink->hw_frames_ctx-
> > >data;
> > > out_frames_hwctx = out_frames_ctx->hwctx;
> > >
> > > +/* work around a bug in MSDK where VPP processing hangs under
> > > + certain
> > > conditions */
> > > +if (in_frames_ctx->height == out_height)
> > > +height_align_adjust = 1;
> > > +
> > > out_frames_ctx->format= AV_PIX_FMT_QS
Re: [FFmpeg-devel] [PATCH v2] avfilter/qsvvpp: Work around a bug in MSDK where VPP processing hangs under certain conditions
On Mon, May 25, 2020 at 12:40 AM Soft Works wrote:
> These are:
> - Dimensions are already aligned (e.g. 1920x800)
> - No scaling is done
> - Color format conversion (e.g. 10bit to 8bit)
>
> Example command:
> ffmpeg -c:v hevc_qsv -hwaccel qsv -i hevc_10bit_1920_800.mkv
> -filter_complex "scale_qsv=format=nv12" -c:v h264_qsv out.mkv
>
> Fix:
> - Increase the frame height to the next alignment value
>
> V2:
> - removed empty line
> - removed duplicated line
> ---
> libavfilter/qsvvpp.c | 7 ++-
> libavfilter/vf_scale_qsv.c | 9 -
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index 1bbb7a7e68..98d2353d1c 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -420,6 +420,7 @@ static int init_vpp_session(AVFilterContext *avctx,
> QSVVPPContext *s)
> mfxHandleType handle_type;
> mfxVersion ver;
> mfxIMPL impl;
> +int height_align_adjust = 0;
> int ret, i;
>
> if (inlink->hw_frames_ctx) {
> @@ -463,9 +464,13 @@ static int init_vpp_session(AVFilterContext *avctx,
> QSVVPPContext *s)
> out_frames_ctx = (AVHWFramesContext *)out_frames_ref->data;
> out_frames_hwctx = out_frames_ctx->hwctx;
>
> +/* work around a bug in MSDK where VPP processing hangs under
> certain conditions */
> +if (inlink->h == outlink->h)
> +height_align_adjust = 1;
> +
> out_frames_ctx->format= AV_PIX_FMT_QSV;
> out_frames_ctx->width = FFALIGN(outlink->w, 32);
> -out_frames_ctx->height= FFALIGN(outlink->h, 32);
> +out_frames_ctx->height= FFALIGN(outlink->h +
> height_align_adjust, 32);
> out_frames_ctx->sw_format = s->out_sw_format;
> out_frames_ctx->initial_pool_size = 64;
> if (avctx->extra_hw_frames > 0)
> diff --git a/libavfilter/vf_scale_qsv.c b/libavfilter/vf_scale_qsv.c
> index 5259104a4f..303d2101a9 100644
> --- a/libavfilter/vf_scale_qsv.c
> +++ b/libavfilter/vf_scale_qsv.c
> @@ -181,8 +181,10 @@ static int init_out_pool(AVFilterContext *ctx,
> AVQSVFramesContext *out_frames_hwctx;
> enum AVPixelFormat in_format;
> enum AVPixelFormat out_format;
> +int height_align_adjust = 0;
> int i, ret;
>
> /* check that we have a hw context */
> if (!ctx->inputs[0]->hw_frames_ctx) {
> av_log(ctx, AV_LOG_ERROR, "No hw context provided on input\n");
> @@ -191,6 +193,7 @@ static int init_out_pool(AVFilterContext *ctx,
> in_frames_ctx =
> (AVHWFramesContext*)ctx->inputs[0]->hw_frames_ctx->data;
> in_frames_hwctx = in_frames_ctx->hwctx;
>
> in_format = in_frames_ctx->sw_format;
> out_format= (s->format == AV_PIX_FMT_NONE) ? in_format :
> s->format;
>
> @@ -200,9 +203,13 @@ static int init_out_pool(AVFilterContext *ctx,
> out_frames_ctx = (AVHWFramesContext*)outlink->hw_frames_ctx->data;
> out_frames_hwctx = out_frames_ctx->hwctx;
>
> +/* work around a bug in MSDK where VPP processing hangs under certain
> conditions */
> +if (in_frames_ctx->height == out_height)
> +height_align_adjust = 1;
> +
> out_frames_ctx->format= AV_PIX_FMT_QSV;
> out_frames_ctx->width = FFALIGN(out_width, 16);
> -out_frames_ctx->height= FFALIGN(out_height, 16);
> +out_frames_ctx->height= FFALIGN(out_height +
> height_align_adjust, 16);
> out_frames_ctx->sw_format = out_format;
> out_frames_ctx->initial_pool_size = 4;
>
> --
> 2.26.2.windows.1
>
>
patch seems to be manually edited and cannot be applied automatically.
During my tests, I couldn't see any change of behavior with and without
patch,
more details needed for patch justification.
regards
Max
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 2/9] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On Tue, May 19, 2020 at 10:11 AM Zhong Li wrote:
> 于2020年5月19日周二 上午4:31写道：
> >
> > From: Artem Galin
> >
> > Adding DX11 relevant device type checks and adjusting callbacks with
> > proper MediaSDK pair type support.
> >
> > Extending structure for proper MediaSDK pair type support.
> >
> > Signed-off-by: Artem Galin
> > ---
> > libavcodec/qsv.c | 53 ++-
> > libavcodec/qsv_internal.h | 2 +-
> > 2 files changed, 37 insertions(+), 18 deletions(-)
> >
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> > index 17720070f1..ef57b92a9f 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -36,6 +36,8 @@
> > #include "avcodec.h"
> > #include "qsv_internal.h"
> >
> > +#define MFX_IMPL_VIA_MASK(impl) (0x0f00 & (impl))
> > +
> > #if QSV_VERSION_ATLEAST(1, 12)
> > #include "mfx/mfxvp8.h"
> > #endif
> > @@ -239,7 +241,9 @@ int ff_qsv_find_surface_idx(QSVFramesContext *ctx,
> QSVFrame *frame)
> > int i;
> > for (i = 0; i < ctx->nb_mids; i++) {
> > QSVMid *mid = >mids[i];
> > -if (mid->handle == frame->surface.Data.MemId)
> > +mfxHDLPair *pair = (mfxHDLPair*)frame->surface.Data.MemId;
> > +if ((mid->handle_pair.first == pair->first) &&
> > +(mid->handle_pair.second == pair->second))
> > return i;
> > }
> > return AVERROR_BUG;
> > @@ -380,7 +384,11 @@ static int ff_qsv_set_display_handle(AVCodecContext
> *avctx, QSVSession *qs)
> > int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
> > const char *load_plugins, int gpu_copy)
> > {
> > +#if CONFIG_D3D11VA
> > +mfxIMPL impl = MFX_IMPL_AUTO_ANY | MFX_IMPL_VIA_D3D11;
> > +#else
> > mfxIMPL impl = MFX_IMPL_AUTO_ANY;
> > +#endif
> > mfxVersionver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR }
> };
> > mfxInitParam init_par = { MFX_IMPL_AUTO_ANY };
> >
> > @@ -469,7 +477,7 @@ static AVBufferRef *qsv_create_mids(AVBufferRef
> *hw_frames_ref)
> >
> > for (i = 0; i < nb_surfaces; i++) {
> > QSVMid *mid = [i];
> > -mid->handle= frames_hwctx->surfaces[i].Data.MemId;
> > +mid->handle_pair =
> *((mfxHDLPair*)frames_hwctx->surfaces[i].Data.MemId);
> > mid->hw_frames_ref = hw_frames_ref1;
> > }
> >
> > @@ -646,7 +654,7 @@ static mfxStatus qsv_frame_lock(mfxHDL pthis,
> mfxMemId mid, mfxFrameData *ptr)
> > goto fail;
> >
> > qsv_mid->surf.Info = hw_frames_hwctx->surfaces[0].Info;
> > -qsv_mid->surf.Data.MemId = qsv_mid->handle;
> > +qsv_mid->surf.Data.MemId = _mid->handle_pair;
> >
> > /* map the data to the system memory */
> > ret = av_hwframe_map(qsv_mid->locked_frame, qsv_mid->hw_frame,
> > @@ -679,7 +687,13 @@ static mfxStatus qsv_frame_unlock(mfxHDL pthis,
> mfxMemId mid, mfxFrameData *ptr)
> > static mfxStatus qsv_frame_get_hdl(mfxHDL pthis, mfxMemId mid, mfxHDL
> *hdl)
> > {
> > QSVMid *qsv_mid = (QSVMid*)mid;
> > -*hdl = qsv_mid->handle;
> > +mfxHDLPair *pair_dst = (mfxHDLPair*)hdl;
> > +mfxHDLPair *pair_src = (mfxHDLPair*)_mid->handle_pair;
> > +
> > +pair_dst->first = pair_src->first;
> > +
> > +if (pair_src->second != (mfxMemId)MFX_INFINITE)
> > +pair_dst->second = pair_src->second;
> > return MFX_ERR_NONE;
> > }
> >
> > @@ -687,24 +701,19 @@ int ff_qsv_init_session_device(AVCodecContext
> *avctx, mfxSession *psession,
> > AVBufferRef *device_ref, const char
> *load_plugins,
> > int gpu_copy)
> > {
> > -static const mfxHandleType handle_types[] = {
> > -MFX_HANDLE_VA_DISPLAY,
> > -MFX_HANDLE_D3D9_DEVICE_MANAGER,
> > -MFX_HANDLE_D3D11_DEVICE,
> > -};
> > AVHWDeviceContext*device_ctx =
> (AVHWDeviceContext*)device_ref->data;
> > AVQSVDeviceContext *device_hwctx = device_ctx->hwctx;
> > mfxSessionparent_session = device_hwctx->session;
> > mfxInitParaminit_par = { MFX_IMPL_AUTO_ANY };
> > mfxHDLhandle = NULL;
> > +int hw_handle_supported = 0;
> >
> > mfxSessionsession;
> > mfxVersionver;
> > mfxIMPL impl;
> > mfxHandleType handle_type;
> > mfxStatus err;
> > -
> > -int i, ret;
> > +int ret;
> >
> > err = MFXQueryIMPL(parent_session, );
> > if (err == MFX_ERR_NONE)
> > @@ -713,13 +722,23 @@ int ff_qsv_init_session_device(AVCodecContext
> *avctx, mfxSession *psession,
> > return ff_qsv_print_error(avctx, err,
> >"Error querying the session
> attributes");
> >
> > -for (i = 0; i < FF_ARRAY_ELEMS(handle_types); i++) {
> > -err = MFXVideoCORE_GetHandle(parent_session, handle_types[i],
> );
> > -if (err == MFX_ERR_NONE) {
> > -handle_type = handle_types[i];
> > -break;
> > +if
Re: [FFmpeg-devel] [PATCH] avfilter/qsvvpp: Work around a bug in MSDK where VPP processing hangs under certain conditions
On Sun, May 24, 2020 at 2:13 PM Soft Works wrote:
> These conditions are:
> - Dimensions are aligned to 16/32 byte (e.g. 1920x800)
> - No scaling is done
> - Color format conversion (e.g. 10bit to 8bit)
>
> Example command:
> ffmpeg -c:v hevc_qsv -hwaccel qsv -i hevc_10bit_1920_800.mkv
> -filter_complex "scale_qsv=format=nv12" -c:v h264_qsv out.mkv
>
> Fix:
> - Increase the frame height to the next alignment value
>
there is a strong feeling that adjustments are enforced in more cases than
actually needed,
only height is checked for decision.
> ---
> libavfilter/qsvvpp.c | 7 ++-
> libavfilter/vf_scale_qsv.c | 9 -
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index 1bbb7a7e68..98d2353d1c 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -420,6 +420,7 @@ static int init_vpp_session(AVFilterContext *avctx,
> QSVVPPContext *s)
> mfxHandleType handle_type;
> mfxVersion ver;
> mfxIMPL impl;
> +int height_align_adjust = 0;
> int ret, i;
>
> if (inlink->hw_frames_ctx) {
> @@ -463,9 +464,13 @@ static int init_vpp_session(AVFilterContext *avctx,
> QSVVPPContext *s)
> out_frames_ctx = (AVHWFramesContext *)out_frames_ref->data;
> out_frames_hwctx = out_frames_ctx->hwctx;
>
> +/* work around a bug in MSDK where VPP processing hangs under
> certain conditions */
>
is this confirmed to be a bug from
https://github.com/Intel-Media-SDK/MediaSDK/issues ?
> +if (inlink->h == outlink->h)
> +height_align_adjust = 1;
> +
> out_frames_ctx->format= AV_PIX_FMT_QSV;
> out_frames_ctx->width = FFALIGN(outlink->w, 32);
> -out_frames_ctx->height= FFALIGN(outlink->h, 32);
> +out_frames_ctx->height= FFALIGN(outlink->h +
> height_align_adjust, 32);
> out_frames_ctx->sw_format = s->out_sw_format;
> out_frames_ctx->initial_pool_size = 64;
> if (avctx->extra_hw_frames > 0)
> diff --git a/libavfilter/vf_scale_qsv.c b/libavfilter/vf_scale_qsv.c
> index 5259104a4f..303d2101a9 100644
> --- a/libavfilter/vf_scale_qsv.c
> +++ b/libavfilter/vf_scale_qsv.c
> @@ -181,8 +181,10 @@ static int init_out_pool(AVFilterContext *ctx,
> AVQSVFramesContext *out_frames_hwctx;
> enum AVPixelFormat in_format;
> enum AVPixelFormat out_format;
> +int height_align_adjust = 0;
> int i, ret;
>
> +
> /* check that we have a hw context */
> if (!ctx->inputs[0]->hw_frames_ctx) {
> av_log(ctx, AV_LOG_ERROR, "No hw context provided on input\n");
> @@ -191,6 +193,7 @@ static int init_out_pool(AVFilterContext *ctx,
> in_frames_ctx =
> (AVHWFramesContext*)ctx->inputs[0]->hw_frames_ctx->data;
> in_frames_hwctx = in_frames_ctx->hwctx;
>
> +in_format = in_frames_ctx->sw_format;
> in_format = in_frames_ctx->sw_format;
> out_format= (s->format == AV_PIX_FMT_NONE) ? in_format :
> s->format;
>
> @@ -200,9 +203,13 @@ static int init_out_pool(AVFilterContext *ctx,
> out_frames_ctx = (AVHWFramesContext*)outlink->hw_frames_ctx->data;
> out_frames_hwctx = out_frames_ctx->hwctx;
>
> +/* work around a bug in MSDK where VPP processing hangs under certain
> conditions */
> +if (in_frames_ctx->height == out_height)
> +height_align_adjust = 1;
> +
> out_frames_ctx->format= AV_PIX_FMT_QSV;
> out_frames_ctx->width = FFALIGN(out_width, 16);
> -out_frames_ctx->height= FFALIGN(out_height, 16);
> +out_frames_ctx->height= FFALIGN(out_height +
> height_align_adjust, 16);
> out_frames_ctx->sw_format = out_format;
> out_frames_ctx->initial_pool_size = 4;
>
> --
> 2.26.2.windows.1
>
>
>
without sample input video - patch has no meaning.
regards
Max
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode support for HEVC 4:2:2 8-bit and 10-bit
On Fri, May 15, 2020 at 9:06 AM Fu, Linjie wrote: > > From: ffmpeg-devel On Behalf Of > > Artem Galin > > Sent: Tuesday, April 28, 2020 00:26 > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Cc: Zhong Li > > Subject: Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode > > support for HEVC 4:2:2 8-bit and 10-bit > > > > On Wed, 15 Apr 2020 at 05:02, Fu, Linjie wrote: > > > > > > From: Zhong Li > > > > Sent: Wednesday, April 15, 2020 09:58 > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> > > > > Cc: Fu, Linjie > > > > Subject: Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode > > > > support for HEVC 4:2:2 8-bit and 10-bit > > > > > > > > Linjie Fu 于2020年2月26日周三 下午4:43写道： > > > > > > > > > > Enables HEVC Range Extension decoding support (Linux) for 4:2:2 > 8/10 > > > bit > > > > > on ICL+ (gen11 +) platform. > > > > > > > > > > Signed-off-by: Linjie Fu > > > > > --- > > > > > [v2]: restrict to support on Linux. > > > > > > > > > > libavcodec/qsv.c | 16 > > > > > libavutil/hwcontext_qsv.c | 24 > > > > > 2 files changed, 40 insertions(+) > > > > > > > > > > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c > > > > > index db98c75..171a8d6 100644 > > > > > --- a/libavcodec/qsv.c > > > > > +++ b/libavcodec/qsv.c > > > > > @@ -195,6 +195,12 @@ enum AVPixelFormat > > ff_qsv_map_fourcc(uint32_t > > > > fourcc) > > > > > case MFX_FOURCC_NV12: return AV_PIX_FMT_NV12; > > > > > case MFX_FOURCC_P010: return AV_PIX_FMT_P010; > > > > > case MFX_FOURCC_P8: return AV_PIX_FMT_PAL8; > > > > > +#if CONFIG_VAAPI > > > > > LGTM. CONFIG_VAAPI is not needed here because crash does not related to > > these changes. > > Full support MFX_FOURCC_YUY2 is WIP for Windows. > > > > > > > +case MFX_FOURCC_YUY2: return AV_PIX_FMT_YUYV422; > > > > > > > > There is no VAAPI structures here, so should not use CONFIG_VAAPI to > > > > disable them. > > > > > > > > > > This is pointed out in [1] that D3D code doesn't support YUYV format, > and > > > indeed > > > It leads to unexpected crash in windows.(instead of working or > reporting > > > unsupported > > > On ICL- platform) > > > > > > Hence this patch restricted to add support on linux only. > > > > > > And I admit the best solution should be get this fully supported on > both > > > linux and windows. > > > (I believe Max and Artem is helping on windows side) > > > > > > Thanks for the review, > > > Linjie > > > > > > [1] > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/1582596080-1035-1- > > git-send-email-linjie...@intel.com/ > > Synced with Zhong, will keep the restriction for now and apply this set > soon. (if no objections) > > it make sense, as patch is clearly Linux focused > - Linjie > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 5:09 PM Mark Thompson wrote:
> On 08/05/2020 21:26, Hendrik Leppkes wrote:
> > On Fri, May 8, 2020 at 5:51 PM wrote:
> >>
> >> From: Artem Galin
> >>
> >> Added AVD3D11FrameDescriptors array to store array of single textures
> in case if there is no way
> >> to allocate array texture with BindFlags = D3D11_BIND_RENDER_TARGET.
> >>
> >> Signed-off-by: Artem Galin
> >> ---
> >> libavutil/hwcontext_d3d11va.c | 26 --
> >> libavutil/hwcontext_d3d11va.h | 9 +
> >> 2 files changed, 29 insertions(+), 6 deletions(-)
> >>
> >> ...
> >> diff --git a/libavutil/hwcontext_d3d11va.h
> b/libavutil/hwcontext_d3d11va.h
> >> index 9f91e9b1b6..295bdcd90d 100644
> >> --- a/libavutil/hwcontext_d3d11va.h
> >> +++ b/libavutil/hwcontext_d3d11va.h
> >> @@ -164,6 +164,15 @@ typedef struct AVD3D11VAFramesContext {
> >> * This field is ignored/invalid if a user-allocated texture is
> provided.
> >> */
> >> UINT MiscFlags;
> >> +
> >> +/**
> >> + * In case if texture structure member above is not NULL contains
> the same texture
> >> + * pointer for all elements and different indexes into the array
> texture.
> >> + * In case if texture structure member above is NULL, all elements
> contains
> >> + * pointers to separate non-array textures and 0 indexes.
> >> + * This field is ignored/invalid if a user-allocated texture is
> provided.
> >> + */
> >> +AVD3D11FrameDescriptor *texture_infos;
> >> } AVD3D11VAFramesContext;
> >>
> >
> >
> > I'm not really a fan of this. Only supporting array textures was an
> > intentional design decision back when D3D11VA was defined, because it
> > greatly simplified the entire design - and as far as I know the
> > d3d11va decoder, for example, doesnt even support decoding into
> > anything else.
>
> For an decoder, yes, because the set of things to render to can easily be
> constrained.
>
> For an encoder, you want to support more cases then just textures
> generated by a decoder, and ideally that would allow arbitrary textures
> with the right properties so that the encoder is not weirdly gimped
> (compare NVENC, which does accept any texture). The barrier to making that
> work is this horrible texture preregistration requirement where we need to
> be able to find all of the textures which might be used up front, not the
> single/array texture difference. While changing the API here is not fun,
> following the method used for the same problem with D3D9 surfaces seems
> like the simplest way to make it all work nicely.
>
> Possibly I am not understanding something here, though - I don't see what
> this has to do with the setting of D3D11_BIND_RENDER_TARGET (and in
> particular why the code discards the array index if this flag is set).
>
>
D3D11_BIND_RENDER_TARGET are not required for decode/encode but
later filters/VPP:
https://github.com/Intel-Media-SDK/MediaSDK/blob/9890dff6064a7f8fe738899fc0c39b33a2d181b5/samples/sample_common/src/d3d11_allocator.cpp#L461
I am re-checking if this is really a MUST condition by any of the
requirements
regards
Max
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 10:32 PM Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Max Dmitrichenko > > Sent: Saturday, May 9, 2020 10:16 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > > adding more texture information to the D3D11 hwcontext API > > > > On Sat, May 9, 2020 at 8:13 PM Soft Works wrote: > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Hendrik Leppkes > > > > > > > > > > > > > > > > Of course there is a choice. Only support the new stuff. Afterall > > > > > we havent supported it at all for years now, so only supporting it > > > > > on newer drivers isn't the end of the world. > > > > > > > > > > > > > To give an example for consistency: > > > > > > > > d3d11va decoding will only ever decode into array-textures. So when > > > > I use d3d11va decoding, and then try to encode with qsvenc, it still > > > > fails on > > > such > > > > systems, right? > > > > And not only that, it'll fail in mysterious ways. > > > > > > > > When I'm decoding with qsvdec and it produces a list of textures, > > > > and > > > the API > > > > user does not handle them, since its a new feature and a API change, > > > it'll > > > > break mysteriously again. > > > > > > Nothing will break when ffmpeg supports non-array textures, neither > > > expected nor mysteriously. > > > > > > > > it is not matter of this patches list, > > can it be discussed in other patch review thread? > > It is very relevant to this patch set, because supporting non-array > textures > or not has a big impact on the number of cases that your patch will break. > > this patch is not offering "non-array textures" support for DX11 and decode/encode. would it be only reasonable to discuss such topic with "non-array textures" patch ? > Making DX11 the default AND not making sure that command lines will > keep working widely (with driver versions as are deployed in the real world > and not just the very latest ones), that are two things that do not > go together very well, IMHO. > > Regards, > softworkz > > > regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 10:26 PM Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Max Dmitrichenko > > Sent: Saturday, May 9, 2020 10:13 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > > adding more texture information to the D3D11 hwcontext API > > > > On Sat, May 9, 2020 at 8:31 PM Soft Works wrote: > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Hendrik Leppkes > > > > Sent: Saturday, May 9, 2020 7:54 PM > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] > > libavutil/hwcontext_d3d11va: > > > > adding more texture information to the D3D11 hwcontext API > > > > > > > > On Sat, May 9, 2020 at 7:41 PM Soft Works > > wrote: > > > > > > > > > > > -Original Message- > > > > > > From: ffmpeg-devel On > > Behalf > > > > > > Of Hendrik Leppkes > > > > > > Sent: Saturday, May 9, 2020 9:08 AM > > > > > > To: FFmpeg development discussions and patches > > > > > de...@ffmpeg.org> > > > > > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] > > > > libavutil/hwcontext_d3d11va: > > > > > > adding more texture information to the D3D11 hwcontext API > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not really a fan of this. Only supporting array textures > > > > > > > > was an intentional design decision back when D3D11VA was > > > > > > > > defined, because it greatly simplified the entire design - > > > > > > > > and as far as I know the d3d11va decoder, for example, > > > > > > > > doesnt even support decoding into > > > > > > anything else. > > > > > > > > > > > > > > > > - Hendrik > > > > > > > > > > > > > > It's not like there would be a choice. The Intel MSDK uses an > > > > > > > allocator mechanism and when it asks for a non-array DX11 > > > > > > > texture it has to > > > > > > be given one. > > > > > > > > > > > > > > > > > > > Of course there is a choice. Only support the new stuff. > > > > > > Afterall we havent supported it at all for years now, so only > > > > > > supporting it on newer drivers isn't the end of the world. > > > > > > > > > > It _IS_ the end of the world when at the same time, the default > > > > > will be switched to DX11 because this will automatically create > > > > > many cases where things will fail which have been working > previously. > > > > > > > > > > An automatic fallback is not a good alternative either because > > > > > that would break specific adapter selection by adapter number > > > > > because the numbering is different between D3D9 and DX11. > > > > > > > > > > Assuming that everybody would have the latest driver is not > > > > > matching the situation in the real world. See here for an example: > > > > > https://github.com/softworkz/ffmpeg_dx11/issues/1 > > > > > > > > > > > > > According to your own documentation, even the proposed DX11 version > > > > will still fail on various systems (only bullet point 3 is solved > > > > from the > > > list in issue > > > > 2, leaving 1 and 2) So either you have a fallback, or DX11 should > > > probably just > > > > not be the default at all then. > > > > > > From a perspective of a normal ffmpeg command line user, my position > > > is that DX11 should not be made the default because it will break > > > command lines that have been working before. (in a significant amount > > > of cases) > > > > > > > > This switch is documented and explained with reasons. > > a normal ffmpeg command line user has no association like with headless > HW > > setup and DX11. > > You can document that wherever you want, but for existing users, > command lines that have always been working before
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 8:13 PM Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Hendrik Leppkes > > > > > > > > > > Of course there is a choice. Only support the new stuff. Afterall we > > > havent supported it at all for years now, so only supporting it on > > > newer drivers isn't the end of the world. > > > > > > > To give an example for consistency: > > > > d3d11va decoding will only ever decode into array-textures. So when I use > > d3d11va decoding, and then try to encode with qsvenc, it still fails on > such > > systems, right? > > And not only that, it'll fail in mysterious ways. > > > > When I'm decoding with qsvdec and it produces a list of textures, and > the API > > user does not handle them, since its a new feature and a API change, > it'll > > break mysteriously again. > > Nothing will break when ffmpeg supports non-array textures, neither > expected > nor mysteriously. > > it is not matter of this patches list, can it be discussed in other patch review thread? > > Adding a confusing alternate way to store textures in the context seems > less > > then ideal, even more so since its not necessary for up-to-date drivers. > Let > > It's not a confusing alternate way; non-array textures are just an > alternate way > that hasn't been implemented in the ffmpeg code so far, that's all. > > If you don't like the way how it's done, here's an alternate way that is > probably > a bit cleaner but also more verbose: > https://github.com/softworkz/ffmpeg_dx11/commit/c09cc37ce7f513717493e060df740aa0e7374257 > > (if you wonder about the disabled locking: it's not required at all - > neither for Intel, > Nvidia or AMD D3D11VA decoders, we could discuss that separately if you > wish) > > Best regards, > softworkz > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 8:31 PM Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Hendrik Leppkes
> > Sent: Saturday, May 9, 2020 7:54 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> > adding more texture information to the D3D11 hwcontext API
> >
> > On Sat, May 9, 2020 at 7:41 PM Soft Works wrote:
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel On Behalf Of
> > > > Hendrik Leppkes
> > > > Sent: Saturday, May 9, 2020 9:08 AM
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11]
> > libavutil/hwcontext_d3d11va:
> > > > adding more texture information to the D3D11 hwcontext API
> > > >
> > >
> > > > > >
> > > > > > I'm not really a fan of this. Only supporting array textures was
> > > > > > an intentional design decision back when D3D11VA was defined,
> > > > > > because it greatly simplified the entire design - and as far as
> > > > > > I know the d3d11va decoder, for example, doesnt even support
> > > > > > decoding into
> > > > anything else.
> > > > > >
> > > > > > - Hendrik
> > > > >
> > > > > It's not like there would be a choice. The Intel MSDK uses an
> > > > > allocator mechanism and when it asks for a non-array DX11 texture
> > > > > it has to
> > > > be given one.
> > > > >
> > > >
> > > > Of course there is a choice. Only support the new stuff. Afterall we
> > > > havent supported it at all for years now, so only supporting it on
> > > > newer drivers isn't the end of the world.
> > >
> > > It _IS_ the end of the world when at the same time, the default will
> > > be switched to DX11 because this will automatically create many cases
> > > where things will fail which have been working previously.
> > >
> > > An automatic fallback is not a good alternative either because that
> > > would break specific adapter selection by adapter number because the
> > > numbering is different between D3D9 and DX11.
> > >
> > > Assuming that everybody would have the latest driver is not matching
> > > the situation in the real world. See here for an example:
> > > https://github.com/softworkz/ffmpeg_dx11/issues/1
> > >
> >
> > According to your own documentation, even the proposed DX11 version will
> > still fail on various systems (only bullet point 3 is solved from the
> list in issue
> > 2, leaving 1 and 2) So either you have a fallback, or DX11 should
> probably just
> > not be the default at all then.
>
> From a perspective of a normal ffmpeg command line user, my position is
> that DX11 should not be made the default because it will break command
> lines that have been working before. (in a significant amount of cases)
>
>
This switch is documented and explained with reasons.
a normal ffmpeg command line user has no association like with headless HW
setup and DX11.
Even, as stated below, discrete graphics adapters setup will benefit from
default'ing to DX11.
it has to be reasonable decision but not purely focusing on support of
somehow aged HW,
before 6th Gen Intel(R) Core(TM) processor family (Codename Skylake).
> Even more important, though: The behavior should be deterministic, which
> means that ffmpeg should not make an automatic decision (consider the
> device selection by adapter number).
>
>
behavior stays deterministic with option for explicit selection of DX
version.
also, no drop of DX9 is considered.
> Intel discrete graphic adapters are coming this year, so device selection
> will become even more important than before as you will be able to have
> even multiple Intel graphics adapters.
>
> Regarding your question above ("only the 3rd bullet point is addressed"):
> We implemented a comprehensive device detection which gives us detailed
> Information about all hardware devices, their drivers, supported codecs and
> capabilities.
> This allows us to detect Intel adapters having drivers below MSDK version
> 1.21,
> and for those we're using D3D9 only.
>
> But for all other versions (MSDK 1.21 to 1.31), we _want_ to be able to use
> DX11 because it allows using without a connected display and without an
> active user session (e.g. Windows service).
>
>
are there prepared patch to consider?
> So, the impact is two-fold:
> - We would be in the position to choose D3D9, but we "want" to have it
> working on all the other driver versions
> - For a regular user, who cannot easily determine the MSDK version (or
> should
> not be needed to bother doing so), the resulting ffmpeg behavior would
> be failure in a lot of cases
>
> softworkz
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
regards
Max
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 7:48 PM Hendrik Leppkes wrote: > On Sat, May 9, 2020 at 7:18 PM Max Dmitrichenko > wrote: > > > > On Sat, May 9, 2020 at 3:18 PM Hendrik Leppkes > wrote: > > > > > On Sat, May 9, 2020 at 2:11 PM Max Dmitrichenko > > > wrote: > > > > > > > > Question about array-textures: are there any confirmation that with > any > > > > BindFlags combination it is should be possible to create such > texture? > > > > Most importantly D3D11_BIND_RENDER_TARGET. > > > > > > > > > > More interestingly, is there any evidence that this is in fact not > > > possible? > > > I see no mention of any limitations like that in the D3D11 > documentation. > > > > > > Where does this condition then come from? > > > > > > > > MSFT documentation is not share much details, > > Try following https://pastebin.com/iCPrwUem > > see #if condition for easy check > > > > Did you ever try reducing the number of bind flags? > Flagging it both for decoder and renderer usage at the same time seems > slightly overkill to me, afterall only one of those processes is going > to fill the texture, and you could (and maybe should) use a different > pool if you want renderer target textures, for eg. filtering? > > both flags: D3D11_BIND_DECODER ( output from the decoder API ) and D3D11_BIND_VIDEO_ENCODER (input from the video encoder API) work fine for ArraySize > 1 / array-textures where more complex cases , like with D3D11_BIND_RENDER_TARGET seems to be gap with one texture in AVHWFramesContext, unless we have several AVHWFramesContext, is this a case? regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 3:18 PM Hendrik Leppkes wrote: > On Sat, May 9, 2020 at 2:11 PM Max Dmitrichenko > wrote: > > > > Question about array-textures: are there any confirmation that with any > > BindFlags combination it is should be possible to create such texture? > > Most importantly D3D11_BIND_RENDER_TARGET. > > > > More interestingly, is there any evidence that this is in fact not > possible? > I see no mention of any limitations like that in the D3D11 documentation. > > Where does this condition then come from? > > MSFT documentation is not share much details, Try following https://pastebin.com/iCPrwUem see #if condition for easy check regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 9:18 AM Hendrik Leppkes wrote:
> On Sat, May 9, 2020 at 9:07 AM Hendrik Leppkes
> wrote:
> >
> > On Sat, May 9, 2020 at 2:12 AM Soft Works wrote:
> > >
> > > > From: ffmpeg-devel On Behalf Of
> > > > Hendrik Leppkes
> > > > Sent: Friday, May 8, 2020 10:27 PM
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11]
> libavutil/hwcontext_d3d11va:
> > > > adding more texture information to the D3D11 hwcontext API
> > > >
> > > > On Fri, May 8, 2020 at 5:51 PM wrote:
> > > > >
> > > > > From: Artem Galin
> > > > >
> > > > > Added AVD3D11FrameDescriptors array to store array of single
> textures
> > > > > in case if there is no way to allocate array texture with
> BindFlags =
> > > > D3D11_BIND_RENDER_TARGET.
> > > > >
> > > > > Signed-off-by: Artem Galin
> > > > > ---
> > > > > libavutil/hwcontext_d3d11va.c | 26 --
> > > > > libavutil/hwcontext_d3d11va.h | 9 +
> > > > > 2 files changed, 29 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/libavutil/hwcontext_d3d11va.c
> > > > > b/libavutil/hwcontext_d3d11va.c index c8ae58f908..cd80931dd3 100644
> > > > > --- a/libavutil/hwcontext_d3d11va.c
> > > > > +++ b/libavutil/hwcontext_d3d11va.c
> > > > > @@ -72,8 +72,8 @@ static av_cold void load_functions(void) }
> > > > >
> > > > > typedef struct D3D11VAFramesContext {
> > > > > -int nb_surfaces_used;
> > > > > -
> > > > > +size_t nb_surfaces;
> > > > > +size_t nb_surfaces_used;
> > > > > DXGI_FORMAT format;
> > > > >
> > > > > ID3D11Texture2D *staging_texture; @@ -112,6 +112,8 @@ static
> void
> > > > > d3d11va_frames_uninit(AVHWFramesContext *ctx)
> > > > > if (s->staging_texture)
> > > > > ID3D11Texture2D_Release(s->staging_texture);
> > > > > s->staging_texture = NULL;
> > > > > +
> > > > > +av_freep(_hwctx->texture_infos);
> > > > > }
> > > > >
> > > > > static int d3d11va_frames_get_constraints(AVHWDeviceContext *ctx,
> @@
> > > > > -152,8 +154,10 @@ static void free_texture(void *opaque, uint8_t
> *data)
> > > > > av_free(data);
> > > > > }
> > > > >
> > > > > -static AVBufferRef *wrap_texture_buf(ID3D11Texture2D *tex, int
> index)
> > > > > +static AVBufferRef *wrap_texture_buf(AVHWFramesContext *ctx,
> > > > > +ID3D11Texture2D *tex, int index)
> > > > > {
> > > > > +D3D11VAFramesContext *s = ctx->internal->priv;
> > > > > +AVD3D11VAFramesContext *frames_hwctx = ctx->hwctx;
> > > > > AVBufferRef *buf;
> > > > > AVD3D11FrameDescriptor *desc = av_mallocz(sizeof(*desc));
> > > > > if (!desc) {
> > > > > @@ -161,6 +165,10 @@ static AVBufferRef
> > > > *wrap_texture_buf(ID3D11Texture2D *tex, int index)
> > > > > return NULL;
> > > > > }
> > > > >
> > > > > +frames_hwctx->texture_infos[s->nb_surfaces_used].texture =
> tex;
> > > > > +frames_hwctx->texture_infos[s->nb_surfaces_used].index =
> index;
> > > > > +s->nb_surfaces_used++;
> > > > > +
> > > > > desc->texture = tex;
> > > > > desc->index = index;
> > > > >
> > > > > @@ -199,7 +207,7 @@ static AVBufferRef
> > > > *d3d11va_alloc_single(AVHWFramesContext *ctx)
> > > > > return NULL;
> > > > > }
> > > > >
> > > > > -return wrap_texture_buf(tex, 0);
> > > > > +return wrap_texture_buf(ctx, tex, 0);
> > > > > }
> > > > >
> > > > > static AVBufferRef *d3d11va_pool_alloc(void *opaque, int size) @@
> > > > > -220,7 +228,7 @@ static AVBufferRef *d3d11va_pool_alloc(void
> *opaque,
> > > > int size)
> > > > > }
> > > > >
> > > > > ID3D11Texture2D_AddRef(hwctx->texture);
> > > > > -return wrap_texture_buf(hwctx->texture,
> s->nb_surfaces_used++);
> > > > > +return wrap_texture_buf(ctx, hwctx->texture,
> > > > > + s->nb_surfaces_used);
> > > > > }
> > > > >
> > > > > static int d3d11va_frames_init(AVHWFramesContext *ctx) @@ -267,7
> > > > > +275,7 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
> > > > > av_log(ctx, AV_LOG_ERROR, "User-provided texture has
> > > > mismatching parameters\n");
> > > > > return AVERROR(EINVAL);
> > > > > }
> > > > > -} else if (texDesc.ArraySize > 0) {
> > > > > +} else if (!(texDesc.BindFlags & D3D11_BIND_RENDER_TARGET) &&
> > > > > + texDesc.ArraySize > 0) {
> > > > > hr = ID3D11Device_CreateTexture2D(device_hwctx->device,
> > > > , NULL, >texture);
> > > > > if (FAILED(hr)) {
> > > > > av_log(ctx, AV_LOG_ERROR, "Could not create the
> texture
> > > > > (%lx)\n", (long)hr); @@ -275,6 +283,12 @@ static int
> > > > d3d11va_frames_init(AVHWFramesContext *ctx)
> > > > > }
> > > > > }
> > > > >
> > > > > +hwctx->texture_infos =
> av_mallocz_array(ctx->initial_pool_size,
> > > > sizeof(*hwctx->texture_infos));
> > > > > +if (!hwctx->texture_infos)
> > > > > +return AVERROR(ENOMEM);
> > > > > +
> > > > > +
Re: [FFmpeg-devel] [PATCH v3 4/4] libavutil/qsv: enabling d3d11va support
On Sun, Apr 26, 2020 at 10:00 PM Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Mark Thompson > > Sent: Sunday, April 26, 2020 8:54 PM > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v3 4/4] libavutil/qsv: enabling > d3d11va > > support > > > > On 24/04/2020 15:52, artem.ga...@gmail.com wrote: > > > From: Artem Galin > > > > > > Makes selection of d3d11va device type by default and over DirectX 9, > > > which is still supported but requires explicit selection. > > > > ... which might break users with older drivers/systems. Some comment on > > exactly which setups are broken would be helpful here. > > I have done some investigation on this question: > https://github.com/softworkz/ffmpeg_dx11/issues/1 > > A short summary: > > - D3D11 will fail for Gen 3 Intel CPUs > DX9 is still possible to use, this patch is not about DX9 removing > > - D3D11 will fail for Gen 4 and Gen 5 Intel CPUs as long as DX11 array > textures are used > (to get these working, the D3D11 hw context needs to be extended to > support non-array textures) > > Feel free to share a patch with support of non-array textures > - For all newer CPUs: For all drivers that are older than 14-16 months, > D3D11 may fail > (except when implementing support for non-array DX11 textures) > > Windows DCH Drivers allow to install latest drivers, even on OEM devices > Note: by "working" or "fail" I'm considering the full set of hw features > including VPP filters. > Simple decoding or encoding might still work in cases where I wrote "fail". > > Feel free to share a patch with support > > An additional objection I have is about the non-deterministic selection > between D3D9 and DX11. > The -qsv_device parameter allows to specify the device numer/Index of a > graphics adapter to use. > > On Windows, the numbering graphic adapters is very different between D3D9 > and DX11 (=> DXGI). > You could roughly say that D3D9 is counting by connected displays while > DXGI is counting by > Physical device. > > As long as there is no way to specify whether to enforce D3D9 or DX11, it > is impossible to know > which adapter ID should be specified when the implementation makes an > internal decision whether > to select D3D9 or DX11. In that context, defaulting to DX11 will break > applications that are > specifying D3D9 adapter IDs. > > There needs to be a deterministic and reliable behavior which can be > controlled from the > command line. The proposed method for selecting D3D9 is not sufficient > from my point of view > because the QSV codecs are standalone codecs and intended to work without > dealing with explicit > hw context creation. For the other half, there should also be a way to > explicitly select "DX11-or-fail". > > IMO there should be a global command line option to explicitly choose > between D3D9 or DX11. > (global, because there's no way to mix the two). > > Usage examples describe explicit selection. DX11 has certain advantages, already described, over DX9 and should be used by default, this also helps to end-customers which are not (dont want to be?) very familiar with DX details and limitations. it is not possible to avoid such fact of switching. > softworkz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 3/4] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On Sun, Apr 26, 2020 at 8:31 PM Mark Thompson wrote:
> On 24/04/2020 15:52, artem.ga...@gmail.com wrote:
> > From: Artem Galin
> >
> > Adding DX11 relevant device type checks and adjusting callbacks with
> > proper MediaSDK pair type support.
> >
> > Extending structure for proper MediaSDK pair type support.
> >
> > Signed-off-by: Artem Galin
> > ---
> > libavcodec/qsv.c | 66 +++
> > libavcodec/qsv_internal.h | 1 +
> > 2 files changed, 54 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> > index db98c75073..35e62417f6 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -36,6 +36,8 @@
> > #include "avcodec.h"
> > #include "qsv_internal.h"
> >
> > +#define MFX_IMPL_VIA_MASK(impl) (0x0f00 & (impl))
> > +
> > #if QSV_VERSION_ATLEAST(1, 12)
> > #include "mfx/mfxvp8.h"
> > #endif
> > @@ -221,8 +223,15 @@ int ff_qsv_find_surface_idx(QSVFramesContext *ctx,
> QSVFrame *frame)
> > int i;
> > for (i = 0; i < ctx->nb_mids; i++) {
> > QSVMid *mid = >mids[i];
> > +#if CONFIG_VAAPI
> > if (mid->handle == frame->surface.Data.MemId)
> > return i;
> > +#else
> > +mfxHDLPair *pair = (mfxHDLPair*)frame->surface.Data.MemId;
> > +if ((mid->handle_pair.first == pair->first) &&
> > +(mid->handle_pair.second == pair->second))
> > +return i;
> > +#endif
>
> Is there any reason not to pass around an mfxHDLPair on Linux as well?
> All the #ifdefs you're adding here are not fun.
>
>
Linux doesnt rely on .second field the same as DX11
> > }
> > return AVERROR_BUG;
> > }
> > @@ -362,7 +371,11 @@ static int ff_qsv_set_display_handle(AVCodecContext
> *avctx, QSVSession *qs)
> > int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
> > const char *load_plugins, int gpu_copy)
> > {
> > +#if CONFIG_D3D11VA
> > +mfxIMPL impl = MFX_IMPL_AUTO_ANY | MFX_IMPL_VIA_D3D11;
>
> Does that still do the right thing on systems where only D3D9 works?
>
>
yes, it is only a hint for D11 when possible.
> > ...
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
and thanks for reviews, Mark
regards
Max
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support
On Wed, Mar 11, 2020 at 10:58 PM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Max Dmitrichenko > > Sent: Wednesday, March 11, 2020 12:49 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support > > > > On Tue, Mar 10, 2020 at 10:36 PM Soft Works > > wrote: > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Artem Galin > > > > Sent: Tuesday, March 10, 2020 5:10 PM > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support > > > > > > > > Any comments on updated patch by link below: > > > > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200306130954.893 > > > > 8- > > > > 1-artem.ga...@gmail.com/ > > > > > > I don't see any comments there. > > > > > > > > I can help commenting below: > > > Allow selection of a specific DXGI adapter > > QSV can make use only one Intel's adapter for currently available HW, if > > changed in the future - this comment should be addressed. > > 1. It wil change this year because Intel is about to release discrete gpu > boards > we have plans to address it when appropriate > 2. Users can have other GPU boars installed so Intel's GPU is not always > the first > DXGI/D3D11 adapter > > see d3d11va_device_find_adapter_by_vendor_id() related changes > > > Change filters to support mfxHandlePair > > Filters should come in next patches, > > This is initial implementation which will establish base for later > filters > > change(s). > > I don't think it is a good idea to submit a path that will break filtering > functionality. > > it is not possible to break DX11 filtering functionality when DX11 support doesnt exist at the first place. > The submitted patch is far away from being complete. I know it > because I've already done a full implementation of D3D11 > support for QuickSync (but not yet submitted). > > DX11 support has certain and strong benefits. we have this patch for DX11 support already no clear understanding if and when any other implementation(s) to expect. softworkz > regards Max (max.dmitriche...@intel.com) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support
On Tue, Mar 10, 2020 at 10:36 PM Soft Works wrote: > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Artem Galin > > Sent: Tuesday, March 10, 2020 5:10 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support > > > > Any comments on updated patch by link below: > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200306130954.8938- > > 1-artem.ga...@gmail.com/ > > I don't see any comments there. > > I can help commenting below: > Allow selection of a specific DXGI adapter QSV can make use only one Intel's adapter for currently available HW, if changed in the future - this comment should be addressed. > Change filters to support mfxHandlePair Filters should come in next patches, This is initial implementation which will establish base for later filters change(s). > Allow deriving from D3D11VA hw context please explain more to this comment. > [...] > > > > >> > > > > Could you help me to reproduce this unusual behavior where texture > > > > need > > > not > > > > be the same for all frames in a frames context? > > > > > > It's the default behaviour of a D3D11 frames context; it only makes a > > > single array texture when you set a fixed size at the start > > > (specifically for the decode use-case which requires a single array > > > texture). So for example d3d11 + hwupload filter will do this. > > The D3D11 hardware context needs to be extended to support non-array > texture-pools. Otherwise a significant range of graphics devices would fail > to work (practically all that don’t have drivers supporting the most > recent SDK > versions. > > preferences of ffmpeg is to keep using array-texture and therefore goal of patch to add such implementation, Current QSV HW and drivers already support array-texture, no issue here. > softworkz > regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_hevc: add qmax/qmin support for HEVC encoding
On Wed, Mar 11, 2020 at 11:44 AM Linjie Fu wrote:
> Add qmax/qmin support for HEVC software bitrate control(SWBRC).
>
> Limitations:
> - RateControlMethod != MFX_RATECONTROL_CQP
> - with EXTBRC ON
>
> Signed-off-by: Dmitry Rogozhkin
> Signed-off-by: Linjie Fu
> ---
>
> Relative code in MSDK for the limitation:
>
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/encode_hw/hevc/agnostic/g9/hevcehw_g9_legacy.cpp#L4267
>
> libavcodec/qsvenc.c | 11 +--
> libavcodec/qsvenc_hevc.c | 2 ++
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 52b4e43..2c22eb7 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -732,6 +732,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
> if (q->adaptive_b >= 0)
> q->extco2.AdaptiveB = q->adaptive_b ? MFX_CODINGOPTION_ON
> : MFX_CODINGOPTION_OFF;
> #endif
> +}
> +
> +if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
> AV_CODEC_ID_HEVC) {
> +if (q->extbrc >= 0)
> +q->extco2.ExtBRC = q->extbrc ? MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;
>
> #if QSV_VERSION_ATLEAST(1, 9)
> if (avctx->qmin >= 0 && avctx->qmax >= 0 && avctx->qmin >
> avctx->qmax) {
> @@ -747,12 +752,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
> q->extco2.MaxQPP = q->extco2.MaxQPB = q->extco2.MaxQPI;
> }
> #endif
> -}
> -
> -if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
> AV_CODEC_ID_HEVC) {
> -if (q->extbrc >= 0)
> -q->extco2.ExtBRC = q->extbrc ? MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;
> -
> q->extco2.Header.BufferId = MFX_EXTBUFF_CODING_OPTION2;
> q->extco2.Header.BufferSz = sizeof(q->extco2);
>
> diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> index 27e2232..3bdca7d 100644
> --- a/libavcodec/qsvenc_hevc.c
> +++ b/libavcodec/qsvenc_hevc.c
> @@ -262,6 +262,8 @@ static const AVCodecDefault qsv_enc_defaults[] = {
> // same as the x264 default
> { "g", "248" },
> { "bf","8" },
> +{ "qmin", "-1"},
> +{ "qmax", "-1"},
> { "trellis", "-1"},
> { "flags", "+cgop" },
> #if FF_API_PRIVATE_OPT
> --
> 2.7.4
>
>
>
looks reasonable
regards
Max
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/qsv: adding DX11 support
On Thu, Jan 9, 2020 at 1:04 AM Hendrik Leppkes wrote: > On Thu, Jan 9, 2020 at 12:32 AM Max Dmitrichenko > wrote: > > > Historically, QSV failed at accepting the array-textures that are used > > > by a D3D11 decoder, which is why this was not included. > > > > > > > > > > right but not anymore, > > therefore this patch. > > > > Cool. Whats the requirement on that? New MFX library? Certain driver > versions? > > MFX library can be used as it is, as it used to be mostly driver issue (which was extended in support and publicly released with several releases already) As such driver fix cannot be considered as major improvement - there is not dedicated flag to check, assumption with 2019/latest drivers should be: array-textures is working and any deviation is regression to fix asap. hope this explains > - Hendrik > thank you for the comments, my feedback to Artem: LGTM regards Max > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/qsv: adding DX11 support
On Mon, Dec 23, 2019 at 8:24 PM Hendrik Leppkes wrote: > On Mon, Dec 23, 2019 at 7:40 PM Artem Galin wrote: > > > > This enables DX11 support for QSV with higher priority than DX9. > > In case of multiple GPUs configuration, DX9 API does not allow to get > > access to QSV device in some cases - headless. > > Implementation based on DX11 resolves that restriction by enumerating > list of available GPUs and finding device with QSV support. > > > > Signed-off-by: Artem Galin > > Did you test this in combination of D3D11VA decoding and QSV encoding? > yes, it has been tested > Historically, QSV failed at accepting the array-textures that are used > by a D3D11 decoder, which is why this was not included. > > right but not anymore, therefore this patch. > - Hendrik > regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers
On Sun, Sep 29, 2019 at 3:19 AM Fu, Linjie wrote:
> > -Original Message-
> > From: Li, Zhong
> > Sent: Friday, September 13, 2019 00:05
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Cc: Fu, Linjie
> > Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> > vaMapBuffer returns multiple buffers
> >
> > > From: ffmpeg-devel On Behalf Of
> > Linjie Fu
> > > Sent: Friday, May 31, 2019 8:35 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Fu, Linjie
> > > Subject: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> > > vaMapBuffer returns multiple buffers
> > >
> > > It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to
> > map
> > > buffer for each slice.
> > >
> > > Currently, assigning new buffer for pkt when multiple buffer returns
> from
> > > vaMapBuffer will cover the previous encoded pkt data and lead to encode
> > issues.
> > >
> > > Iterate through the buf_list first to find out the total buffer size
> needed for
> > the
> > > pkt, allocate the whole pkt to avoid repeated reallocation and memcpy,
> > then copy
> > > data from each buf to pkt.
> > >
> > > Signed-off-by: Linjie Fu
> > > ---
> > > [v2]: allocate the whole pkt to avoid repeated reallocation and memcpy
> > >
> > > libavcodec/vaapi_encode.c | 18 +-
> > > 1 file changed, 13 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index
> > > 2dda451..9c9e5dd 100644
> > > --- a/libavcodec/vaapi_encode.c
> > > +++ b/libavcodec/vaapi_encode.c
> > > @@ -489,6 +489,8 @@ static int vaapi_encode_output(AVCodecContext
> > *avctx,
> > > VAAPIEncodeContext *ctx = avctx->priv_data;
> > > VACodedBufferSegment *buf_list, *buf;
> > > VAStatus vas;
> > > +int total_size = 0;
> > > +uint8_t *ptr;
> > > int err;
> > >
> > > err = vaapi_encode_wait(avctx, pic); @@ -505,15 +507,21 @@ static
> int
> > > vaapi_encode_output(AVCodecContext *avctx,
> > > goto fail;
> > > }
> > >
> > > +for (buf = buf_list; buf; buf = buf->next)
> > > +total_size += buf->size;
> > > +
> > > +err = av_new_packet(pkt, total_size);
> > > +ptr = pkt->data;
> > > +
> > > +if (err < 0)
> > > +goto fail_mapped;
> > > +
> > > for (buf = buf_list; buf; buf = buf->next) {
> > > av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
> > > "(status %08x).\n", buf->size, buf->status);
> > >
> > > -err = av_new_packet(pkt, buf->size);
> > > -if (err < 0)
> > > -goto fail_mapped;
> > > -
> > > -memcpy(pkt->data, buf->buf, buf->size);
> > > +memcpy(ptr, buf->buf, buf->size);
> > > +ptr += buf->size;
> > > }
> > >
> > > if (pic->type == PICTURE_TYPE_IDR)
> > > --
> > > 2.7.4
> >
> > LGTM
>
> Thanks for review.
> A kindly ping.
>
> - linjie
>
LGTM
regards
Max
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context
On Fri, Sep 20, 2019 at 5:12 AM Fu, Linjie wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Fu, Linjie
> > Sent: Wednesday, September 11, 2019 00:02
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> > hw_frames_ctx for vp9 without destroy va_context
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > > Of Mark Thompson
> > > Sent: Tuesday, September 10, 2019 08:02
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> > > hw_frames_ctx for vp9 without destroy va_context
> > >
> > > On 09/09/2019 16:40, Fu, Linjie wrote:
> > > >> -Original Message-
> > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf
> > > >> Of Fu, Linjie
> > > >> Sent: Friday, August 30, 2019 16:05
> > > >> To: FFmpeg development discussions and patches > > >> de...@ffmpeg.org>
> > > >> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> > recreate
> > > >> hw_frames_ctx for vp9 without destroy va_context
> > > >>
> > > >>> -Original Message-
> > > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > >> Behalf
> > > >>> Of Fu, Linjie
> > > >>> Sent: Friday, August 9, 2019 19:47
> > > >>> To: FFmpeg development discussions and patches > > >>> de...@ffmpeg.org>
> > > >>> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> > > recreate
> > > >>> hw_frames_ctx for vp9 without destroy va_context
> > > >>>
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > >>> Behalf
> > > Of Hendrik Leppkes
> > > Sent: Friday, August 9, 2019 17:40
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> > > >> recreate
> > > hw_frames_ctx for vp9 without destroy va_context
> > >
> > > On Tue, Aug 6, 2019 at 10:55 AM Fu, Linjie
> > wrote:
> > > >
> > > >> -Original Message-
> > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org]
> > > On
> > > Behalf
> > > >> Of Hendrik Leppkes
> > > >> Sent: Tuesday, August 6, 2019 16:27
> > > >> To: FFmpeg development discussions and patches > > >> de...@ffmpeg.org>
> > > >> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> > > recreate
> > > >> hw_frames_ctx for vp9 without destroy va_context
> > > >>
> > > >> On Thu, Jul 11, 2019 at 10:20 AM Linjie Fu >
> > > wrote:
> > > >>>
> > > >>> VP9 allows resolution changes per frame. Currently in VAAPI,
> > > >>> resolution
> > > >>> changes leads to va context destroy and reinit. This will cause
> > > >>> reference frame surface lost and produce garbage.
> > > >>>
> > > >>> Though refs surface id could be passed to media driver and
> found
> > > in
> > > >>> RTtbl, vp9RefList[] in hal layer has already been destroyed.
> Thus
> > > the
> > > >>> new created VaContext could only got an empty RefList.
> > > >>>
> > > >>> As libva allows re-create surface separately without changing
> the
> > > >>> context, this issue could be handled by only recreating
> > > >>> hw_frames_ctx.
> > > >>>
> > > >>> Set hwaccel_priv_data_keeping flag for vp9 to only recreating
> > > >>> hw_frame_ctx when dynamic resolution changing happens.
> > > >>>
> > > >>> Could be verified by:
> > > >>> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> > > >>> ./resolutions.ivf -pix_fmt p010le -f rawvideo -vframes 20 -y
> > > >> vaapi.yuv
> > > >>>
> > > >>> Signed-off-by: Linjie Fu
> > > >>> ---
> > > >>> libavcodec/decode.c| 10 +-
> > > >>> libavcodec/internal.h | 1 +
> > > >>> libavcodec/pthread_frame.c | 2 ++
> > > >>> libavcodec/vaapi_decode.c | 40 ++
> > --
> > > -
> > > >> --
> > > >>> --
> > > -
> > > >> --
> > > >>> libavcodec/vaapi_vp9.c | 4
> > > >>> 5 files changed, 34 insertions(+), 23 deletions(-)
> > > >>>
> > > >>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > > >>> index 0863b82..7b15fa5 100644
> > > >>> --- a/libavcodec/decode.c
> > > >>> +++ b/libavcodec/decode.c
> > > >>> @@ -1254,7 +1254,6 @@ int
> > > >> ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> > > >>>
> > > >>> frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx-
> > > data;
> > > >>>
> > > >>> -
> > > >>> if (frames_ctx->initial_pool_size) {
> > > >>> // We guarantee 4 base work surfaces. The function
> above
> > > guarantees
> > > >> 1
> > > >>> // (the absolute minimum), so add the
Re: [FFmpeg-devel] [PATCH] lavc/qsv: improve the default GPU memory usage
On Fri, Nov 1, 2019 at 11:20 AM Zhong Li wrote:
> > A large initial_pool_size leads to redundant GPU memory allocations
> > compared with MSDK.
> >
> > For some special cases which needs larger GPU memory like look_ahead,
> > add -extra_hw_frames to allocate more.
> >
> > CMD:
> > ffmpeg -hwaccel qsv -extra_hw_frames 50 -c:v hevc_qsv -i hevc.h265 -c:v
> h264_qsv
> > -look_ahead 1 -look_ahead_depth 50 -y output.h264
> >
> > Fix #7943.
> >
> > Reported-by: Eero T
> > Signed-off-by: Linjie Fu
> > ---
> > fftools/ffmpeg_qsv.c | 2 +-
> > libavcodec/qsvdec.c | 5 -
> > libavcodec/qsvenc_h264.c | 4 ++--
> > 3 files changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/fftools/ffmpeg_qsv.c b/fftools/ffmpeg_qsv.c
> > index 9c4285b..5039a5a 100644
> > --- a/fftools/ffmpeg_qsv.c
> > +++ b/fftools/ffmpeg_qsv.c
> > @@ -93,7 +93,7 @@ int qsv_init(AVCodecContext *s)
> > frames_ctx->height= FFALIGN(s->coded_height, 32);
> > frames_ctx->format= AV_PIX_FMT_QSV;
> > frames_ctx->sw_format = s->sw_pix_fmt;
> > -frames_ctx->initial_pool_size = 64 + s->extra_hw_frames;
> > +frames_ctx->initial_pool_size = 24 + s->extra_hw_frames;
>
> Should be better add pool size when look_ahead is enabled.
>
>
yes, please follow this.
> E:g
> initial_pool_size = 24 + look_head_depth + s->extra_hw_frames;
>
> you can set a default look_ahead_depth when look_ahead is enabled bu
> no depth specified.
>
> > frames_hwctx->frame_type =
> MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET;
> >
> > ret = av_hwframe_ctx_init(ist->hw_frames_ctx);
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> > index 0d34021..407e6de 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -300,8 +300,11 @@ static int alloc_frame(AVCodecContext *avctx,
> QSVContext *q, QSVFrame *frame)
> > else
> > ret = ff_get_buffer(avctx, frame->frame,
> AV_GET_BUFFER_FLAG_REF);
> >
> > -if (ret < 0)
> > +if (ret < 0) {
> > +av_log(avctx, AV_LOG_ERROR, "More memory in need, "
> > +"try -extra_hw_frames to allocate more.\n");
> > return ret;
> > +}
> >
> > if (frame->frame->format == AV_PIX_FMT_QSV) {
> > frame->surface = *(mfxFrameSurface1*)frame->frame->data[3];
> > diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
> > index 27f36b9..4e8035b 100644
> > --- a/libavcodec/qsvenc_h264.c
> > +++ b/libavcodec/qsvenc_h264.c
> > @@ -112,8 +112,8 @@ static const AVOption options[] = {
> > { "max_dec_frame_buffering", "Maximum number of frames buffered in
> the DPB", OFFSET(qsv.max_dec_frame_buffering), AV_OPT_TYPE_INT, { .i64 = 0
> }, 0, UINT16_MAX, VE },
> >
> > #if QSV_HAVE_LA
> > -{ "look_ahead", "Use VBR algorithm with look ahead",
> OFFSET(qsv.look_ahead), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
> > -{ "look_ahead_depth", "Depth of look ahead in number frames",
> OFFSET(qsv.look_ahead_depth), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 100, VE },
> > +{ "look_ahead", "Use VBR algorithm with look ahead,
> extra_hw_frames is needed",OFFSET(qsv.look_ahead),
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
> > +{ "look_ahead_depth", "Depth of look ahead in number frames,
> extra_hw_frames is needed", OFFSET(qsv.look_ahead_depth), AV_OPT_TYPE_INT,
> { .i64 = 0 }, 0, 100, VE },
>
> No need to update the message if follow comments above.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] ffmpeg-qsv: Is opaque memory allocation path used in ffmpeg-qsv?
usage as format= AV_PIX_FMT_QSV; frame_type = MFX_MEMTYPE_OPAQUE_FRAME; enforces usage of opaque memory from any 3rd_party application. you can offer patch to remove opaque implementation where it will be not reasonable to apply it unless deprecated and dropped from MediaSDK definition https://github.com/Intel-Media-SDK/MediaSDK/blob/518334ea3cd34764ff2c941d32591c8eb1cadee5/api/include/mfxstructures.h#L383 > it might not be actually functional help in validation and fixes are welcome regards Max On Sat, Oct 26, 2019 at 12:13 AM Rogozhkin, Dmitry V < dmitry.v.rogozh...@intel.com> wrote: > On Fri, 2019-10-25 at 02:17 +, Fu, Linjie wrote: > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Rogozhkin, Dmitry V > > > Sent: Friday, October 25, 2019 05:17 > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] ffmpeg-qsv: Is opaque memory allocation > > > path > > > used in ffmpeg-qsv? > > > > > > On Thu, 2019-10-24 at 17:12 +0200, Max Dmitrichenko wrote: > > > > Hi, > > > > > > > > Just have a look at any usage as: ffmpeg -hwaccel qsv ... > > > > > > I looked into these 3 command lines on Linux: > > > > > > ffmpeg -hwaccel qsv -c:v h264_qsv -i AUD_MW_E.264 \ > > >-vf hwdownload,format=nv12 -pix_fmt yuv420p \ > > >AUD_MW.yuv > > > > > > ffmpeg -hwaccel qsv -c:v h264_qsv -i AUD_MW_E.264 \ > > >-c:v hevc_qsv -b:v 5M AUD_MW_E.hevc > > > > > > ffmpeg -init_hw_device qsv=hw \ > > >-filter_hw_device hw -f rawvideo -pix_fmt \ > > >yuv420p -s:v 176x144 -i AUD_MW.yuv -vf \ > > >hwupload=extra_hw_frames=64,format=qsv \ > > >-c:v h264_qsv -b:v 5M -frames:v 10 \ > > >-y ./AUD_MW_E.h264 > > > > > > For what I see, none of the them is using QSV opaque memory. For > > > the > > > first 2 command lines ffmpeg explicitly prints (w/ -loglevel > > > debug): > > > > > > [h264_qsv @ 0x34f6980] Decoder: output is video memory surface > > > > > > Besides, I checked w/ manual printfs from the code - opaque is not > > > used. > > > > > > Hence, this question: is actually qsv opaque memory path used > > > anywhere > > > in ffmpeg.exe sample or in other libavcodec/libavfilter based > > > applications? Is there Linux/Windows difference which I don't > > > notice in > > > code review? > > > > > > > I didn't see MFX_MEMTYPE_OPAQUE_FRAME set for frames_hwctx- > > >frame_type > > in mainline ffmpeg application. > > Right. I also don't see it. I think that none of upstream ffmpeg > applications actually exercise this path. This raises a concern why we > have this in sources and complicate them if we don't use them? I guess > most testing is done via mainline ffmpeg.exe and opaque path test > coverage is likely missing meaning it might not be actually functional. > > If we will look from the end-user perspective, there is also > opportunity to write their own applications using libavcodec/etc. > libraries. In this case he will work with these 2 header files exposing > QSV capabilities: > > ./libavcodec/qsv.h > ./libavutil/hwcontext_qsv.h > > On this path he will be able to use the following: > AVQSVFramesContext::frame_type > AVQSVContext::opaque_alloc > to configure QSV. > > Questions: > 1. Is opaque memory usage limited to internal ffmpeg component > connections? or it is possible to have external non-ffmpeg component > connected to ffmpeg one via qsv opaque memory? > 2. Does anyone actually uses the above to configure qsv opaque memory? > 3. Regardless of the above: is that possible to deprecate and drop QSV > opaque memory support in ffmpeg-qsv path? > > > > > BTW, in the frame_allocator used for > > MFXVideoCORE_SetFrameAllocator(), > > > https://github.com/FFmpeg/FFmpeg/blob/6f2a3958cfac135c60b509a61a4fd39432d8f9a9/libavcodec/qsv.c#L562 > > > > only MFX_MEMTYPE_INTERNAL_FRAME and MFX_MEMTYPE_EXTERNAL_FRAME is > > supported as an allocation request since commit: > > 4ab61cd983b539749bd621ea271624ddb5196a8e > > > > (For VPP, MFX_MEMTYPE_FROM_VPPIN is supported) > > - linjie > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] ffmpeg-qsv: Is opaque memory allocation path used in ffmpeg-qsv?
Hi, Just have a look at any usage as: ffmpeg -hwaccel qsv ... any 3rd_party implementation can use it by requesting AV_PIX_FMT_QSV regards Max On Thu, Oct 24, 2019 at 12:47 AM Rogozhkin, Dmitry V < dmitry.v.rogozh...@intel.com> wrote: > Hi, > > I was looking into the ffmpeg qsv (mediasdk hw acceleration) path > implementation and wonder whether opaque memory allocation path is > actually used and exercised? > > I failed to come across any code in ffmpeg sources which use it. Do I > miss something? > > Are there any other usages possible? For example, can it be used in > self-written applications somehow? > > Thank you, > Dmitry. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v4 1/2] lavf/qsvvpp:allocate continuous memory
On Tue, Jun 18, 2019 at 9:52 AM Linjie Fu wrote:
> Mediasdk calls CMRT to copy from video to system memory and requires
> memory to be continuously allocated across Y and UV.
>
> Add a new path to allocate continuous memory when using system out.
> Use get_continuous_buffer to arrange data according to pixfmt.
>
>
it would be good to keep such continuous allocations consistent with
encoder's implementation,
see
https://github.com/FFmpeg/FFmpeg/blob/8f6e65183354d1d402ae80c71cba2759fe152018/libavcodec/qsvenc.c#L1218
if needed, needs to be checked before re-allocation.
> Signed-off-by: Linjie Fu
> ---
> libavfilter/qsvvpp.c | 67
> 1 file changed, 62 insertions(+), 5 deletions(-)
>
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index 8d5ff2eb65..07fe53573d 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -27,6 +27,7 @@
> #include "libavutil/hwcontext_qsv.h"
> #include "libavutil/time.h"
> #include "libavutil/pixdesc.h"
> +#include "libavutil/imgutils.h"
>
> #include "internal.h"
> #include "qsvvpp.h"
> @@ -346,6 +347,57 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
> AVFilterLink *inlink, AVFrame *p
> return qsv_frame;
> }
>
> +static int get_continuous_buffer(AVFrame *frame, int align)
> +{
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
> +int ret, i, padded_height;
> +
> +if (!desc)
> +return AVERROR(EINVAL);
> +
> +if ((ret = av_image_check_size(frame->width, frame->height, 0, NULL))
> < 0)
> +return ret;
> +
> +if (!frame->linesize[0]) {
> +if (align <= 0)
> +align = 32; /* STRIDE_ALIGN. Should be av_cpu_max_align() */
> +
> +for (i=1; i<=align; i+=i) {
> +ret = av_image_fill_linesizes(frame->linesize, frame->format,
> + FFALIGN(frame->width, i));
> +if (ret < 0)
> +return ret;
> +if (!(frame->linesize[0] & (align-1)))
> +break;
> +}
> +
> +for (i = 0; i < 4 && frame->linesize[i]; i++)
> +frame->linesize[i] = FFALIGN(frame->linesize[i], align);
> +}
> +
> +padded_height = FFALIGN(frame->height, 64);
> +if ((ret = av_image_fill_pointers(frame->data, frame->format,
> padded_height,
> + NULL, frame->linesize)) < 0)
> +return ret;
> +
> +frame->buf[0] = av_buffer_alloc(ret);
> +if (!frame->buf[0]) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
> +
> +if ((ret = av_image_fill_pointers(frame->data, frame->format,
> padded_height,
> + frame->buf[0]->data,
> frame->linesize)) < 0)
> +goto fail;
> +
> +frame->extended_data = frame->data;
> +
> +return 0;
> +fail:
> +av_frame_unref(frame);
> +return ret;
> +}
> +
> /* get the output surface */
> static QSVFrame *query_frame(QSVVPPContext *s, AVFilterLink *outlink)
> {
> @@ -375,15 +427,20 @@ static QSVFrame *query_frame(QSVVPPContext *s,
> AVFilterLink *outlink)
> out_frame->surface = (mfxFrameSurface1
> *)out_frame->frame->data[3];
> } else {
> /* Get a frame with aligned dimensions.
> - * Libmfx need system memory being 128x64 aligned */
> -out_frame->frame = ff_get_video_buffer(outlink,
> - FFALIGN(outlink->w, 128),
> - FFALIGN(outlink->h, 64));
> -if (!out_frame->frame)
> + * Libmfx need system memory being 128x64 aligned
> + * and continuously allocated across Y and UV */
> +out_frame->frame = av_frame_alloc();
> +if (!out_frame->frame) {
> return NULL;
> +}
>
> out_frame->frame->width = outlink->w;
> out_frame->frame->height = outlink->h;
> +out_frame->frame->format = outlink->format;
> +
> +ret = get_continuous_buffer(out_frame->frame, 128);
> +if (ret < 0)
> +return NULL;
>
> ret = map_frame_to_surface(out_frame->frame,
>_frame->surface_internal);
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
regards
Max
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
