Re: [FFmpeg-devel] [PATCH] lavf/qsv_scale: add scaling mode option
On Wed, Jan 16, 2019 at 9:55 AM Zhong Li wrote:
> Signed-off-by: Zhong Li
> ---
> libavfilter/vf_scale_qsv.c | 36 +++-
> 1 file changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/libavfilter/vf_scale_qsv.c b/libavfilter/vf_scale_qsv.c
> index 7d593b2..f9f708e 100644
> --- a/libavfilter/vf_scale_qsv.c
> +++ b/libavfilter/vf_scale_qsv.c
> @@ -69,6 +69,8 @@ enum var_name {
> VARS_NB
> };
>
> +#define QSV_HAVE_SCALING_CONFIG QSV_VERSION_ATLEAST(1, 19)
> +
> typedef struct QSVScaleContext {
> const AVClass *class;
>
> @@ -88,7 +90,14 @@ typedef struct QSVScaleContext {
> int nb_surface_ptrs_out;
>
> mfxExtOpaqueSurfaceAlloc opaque_alloc;
> -mfxExtBuffer*ext_buffers[1];
> +
> +#if QSV_HAVE_SCALING_CONFIG
> +mfxExtVPPScaling scale_conf;
> +#endif
> +int mode;
> +
> +mfxExtBuffer *ext_buffers[1 + QSV_HAVE_SCALING_CONFIG];
> +int num_ext_buf;
>
> int shift_width, shift_height;
>
> @@ -285,6 +294,8 @@ static int init_out_session(AVFilterContext *ctx)
> mfxStatus err;
> int i;
>
> +s->num_ext_buf = 0;
> +
> /* extract the properties of the "master" session given to us */
> err = MFXQueryIMPL(device_hwctx->session, );
> if (err == MFX_ERR_NONE)
> @@ -357,10 +368,7 @@ static int init_out_session(AVFilterContext *ctx)
> s->opaque_alloc.Header.BufferId =
> MFX_EXTBUFF_OPAQUE_SURFACE_ALLOCATION;
> s->opaque_alloc.Header.BufferSz = sizeof(s->opaque_alloc);
>
> -s->ext_buffers[0] = (mfxExtBuffer*)>opaque_alloc;
> -
> -par.ExtParam= s->ext_buffers;
> -par.NumExtParam = FF_ARRAY_ELEMS(s->ext_buffers);
> +s->ext_buffers[s->num_ext_buf++] =
> (mfxExtBuffer*)>opaque_alloc;
>
> par.IOPattern = MFX_IOPATTERN_IN_OPAQUE_MEMORY |
> MFX_IOPATTERN_OUT_OPAQUE_MEMORY;
> } else {
> @@ -396,6 +404,18 @@ static int init_out_session(AVFilterContext *ctx)
> par.IOPattern = MFX_IOPATTERN_IN_VIDEO_MEMORY |
> MFX_IOPATTERN_OUT_VIDEO_MEMORY;
> }
>
> +#if QSV_HAVE_SCALING_CONFIG
> +memset(>scale_conf, 0, sizeof(mfxExtVPPScaling));
> +s->scale_conf.Header.BufferId = MFX_EXTBUFF_VPP_SCALING;
> +s->scale_conf.Header.BufferSz = sizeof(mfxExtVPPScaling);
> +s->scale_conf.ScalingMode = s->mode;
> +s->ext_buffers[s->num_ext_buf++] = (mfxExtBuffer*)>scale_conf;
> +av_log(ctx, AV_LOG_VERBOSE, "Scaling mode: %"PRIu16"\n", s->mode);
> +#endif
> +
> +par.ExtParam= s->ext_buffers;
> +par.NumExtParam = s->num_ext_buf;
> +
> par.AsyncDepth = 1;// TODO async
>
> par.vpp.In = in_frames_hwctx->surfaces[0].Info;
> @@ -595,6 +615,12 @@ static const AVOption options[] = {
> { "h", "Output video height", OFFSET(h_expr),
> AV_OPT_TYPE_STRING, { .str = "ih" }, .flags = FLAGS },
> { "format", "Output pixel format", OFFSET(format_str),
> AV_OPT_TYPE_STRING, { .str = "same" }, .flags = FLAGS },
>
> +#if QSV_HAVE_SCALING_CONFIG
> +{ "mode", "set scaling mode",OFFSET(mode),
> AV_OPT_TYPE_INT,{ .i64 = MFX_SCALING_MODE_DEFAULT},
> MFX_SCALING_MODE_DEFAULT, MFX_SCALING_MODE_QUALITY, FLAGS, "mode"},
> +{ "low_power", "low power mode",0,
> AV_OPT_TYPE_CONST, { .i64 = MFX_SCALING_MODE_LOWPOWER}, INT_MIN, INT_MAX,
> FLAGS, "mode"},
> +{ "hq","high quality mode", 0,
> AV_OPT_TYPE_CONST, { .i64 = MFX_SCALING_MODE_QUALITY}, INT_MIN, INT_MAX,
> FLAGS, "mode"},
> +#endif
> +
> { NULL },
> };
>
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
seems to be quiet straight forward and simple.
regards
Max Dm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/qsvvpp: cope with MFX_ERR_MORE_DATA condition in VPP pipeline
On Mon, Jan 14, 2019 at 5:53 PM Rostislav Pehlivanov
wrote:
> On Mon, 14 Jan 2019 at 12:40, Linjie Fu wrote:
>
> > Returning AVERROR(EAGAIN) when libmfx needs more data will cause the
> > failure
> > of requesting the next frame and lead to an infinite loop.
> >
> > Sleep for a while to release the resources before calling
> > MFXVideoCORE_SyncOperation
> > in hwupload to avoid the crash (in MCTF for example).
> >
> > Signed-off-by: Linjie Fu
> > ---
> > libavfilter/qsvvpp.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> > index 06efdf5089..1a10d16788 100644
> > --- a/libavfilter/qsvvpp.c
> > +++ b/libavfilter/qsvvpp.c
> > @@ -714,8 +714,10 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s,
> > AVFilterLink *inlink, AVFrame *picr
> >
> > if (ret < 0 && ret != MFX_ERR_MORE_SURFACE) {
> > /* Ignore more_data error */
> > -if (ret == MFX_ERR_MORE_DATA)
> > -ret = AVERROR(EAGAIN);
> > +if (ret == MFX_ERR_MORE_DATA) {
> > +ret = MFX_ERR_NONE;
> > +av_usleep(10);
> > +}
> > break;
> > }
> >
> > --
> > 2.17.1
> >
>
> This seems like its an ugly hack.
>
>
totally agree here, it should not be time dependent
> >
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
regards
Maxym Dm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows
On Sat, Oct 13, 2018 at 6:43 PM Mark Thompson wrote: > On 06/10/18 07:21, Landgraph wrote: > > 1. Old logic meaned: everywhere, except Windows, ffmpeg has to use HW > acceleration, but on Windows ffmpeg has to use (unavailable) software > encode by default > > 2. Software encode is available only if you provide corresponding > software MediaSDK library, which isn't provided with ffmpeg. More > information could be found in > https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/samples/readme-encode_linux.pdf > > 3. HW encode is available on Windows in the driver by default > > This has been proposed before - I can't find the original discussion > (maybe it was on IRC), but I did find < > https://lists.libav.org/pipermail/libav-devel/2016-November/080419.html>. > The reason for not doing it is that a subset of the Intel drivers segfault > immediately when the hardware plugin is loaded on some platforms. That's a > pain for anyone wanting to support diverse systems, so the decision was to > continue to load the sw plugin by default so it doesn't crash (even if the > software plugin isn't present), and leave the non-default case as the > crashing one so the user has to do something to trigger it. > > If you can characterise either the set of platforms it crashes on or a set > of platforms it definitely works on then maybe we could conditionally > change the default behaviour? > > - Mark > > it was 2 years old discussion and with early drivers (we even had this development a bit ahead of general driver availability) now it should be working on most of the platforms - I would suggest to make a positive side. > > > --- > > libavcodec/qsvenc_hevc.c | 4 > > 1 file changed, 4 deletions(-) > > > > diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c > > index 4339b316a3..e7ca27d49f 100644 > > --- a/libavcodec/qsvenc_hevc.c > > +++ b/libavcodec/qsvenc_hevc.c > > @@ -217,11 +217,7 @@ static av_cold int qsv_enc_close(AVCodecContext > *avctx) > > return ff_qsv_enc_close(avctx, >qsv); > > } > > > > -#if defined(_WIN32) > > -#define LOAD_PLUGIN_DEFAULT LOAD_PLUGIN_HEVC_SW > > -#else > > #define LOAD_PLUGIN_DEFAULT LOAD_PLUGIN_HEVC_HW > > -#endif > > > > #define OFFSET(x) offsetof(QSVHEVCEncContext, x) > > #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows
On Tue, Oct 9, 2018 at 3:50 AM Landgraph wrote: > 1. Old logic meaned: everywhere, except Windows, ffmpeg has to use HW > acceleration, but on Windows ffmpeg has to use (unavailable) software > encode by default > 2. Software encode is available only if you provide corresponding > software MediaSDK library, which isn't provided with ffmpeg. More > information could be found in > > https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/samples/readme-encode_linux.pdf > 3. HW encode is available on Windows in the driver by default > --- > libavcodec/qsvenc_hevc.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c > index 4339b316a3..e7ca27d49f 100644 > --- a/libavcodec/qsvenc_hevc.c > +++ b/libavcodec/qsvenc_hevc.c > @@ -217,11 +217,7 @@ static av_cold int qsv_enc_close(AVCodecContext > *avctx) > return ff_qsv_enc_close(avctx, >qsv); > } > > -#if defined(_WIN32) > -#define LOAD_PLUGIN_DEFAULT LOAD_PLUGIN_HEVC_SW > -#else > #define LOAD_PLUGIN_DEFAULT LOAD_PLUGIN_HEVC_HW > -#endif > > #define OFFSET(x) offsetof(QSVHEVCEncContext, x) > #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM > -- > 2.14.1.windows.1 > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel it is good switch for HW configuration per default, agree. LGTM regards Maxym ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavu/qsv: make a copy as libmfx alignment requirement for uploading
On Sun, Sep 30, 2018 at 11:14 AM Zhong Li wrote:
> Libmfx requires 16 bytes aligned input/output for uploading.
> Currently only output is 16 byte aligned and assigning same width/height to
> input with smaller buffer size actually, thus definitely will cause
> segment fault.
>
> Can reproduce with any 1080p nv12 rawvideo input:
> ffmpeg -init_hw_device qsv=qsv:hw -hwaccel qsv -filter_hw_device qsv -f
> rawvideo -pix_fmt nv12 -s:v 1920x1080
> -i 1080p_nv12.yuv -vf
> 'format=nv12,hwupload=extra_hw_frames=16,hwdownload,format=nv12' -an -y
> out_nv12.yuv
>
> It can fix #7418
>
> Signed-off-by: Zhong Li
> ---
> libavutil/hwcontext_qsv.c | 31 +--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index 33e121b..3039cfa 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -862,6 +862,10 @@ static int qsv_transfer_data_to(AVHWFramesContext
> *ctx, AVFrame *dst,
> mfxSyncPoint sync = NULL;
> mfxStatus err;
> int ret = 0;
> +/* make a copy if the input is not padded as libmfx requires */
> +AVFrame tmp_frame, *src_frame;
> +int realigned = 0;
> +
>
> while (!s->session_upload_init && !s->session_upload && !ret) {
> #if HAVE_PTHREADS
> @@ -887,16 +891,36 @@ static int qsv_transfer_data_to(AVHWFramesContext
> *ctx, AVFrame *dst,
> if (ret < 0)
> return ret;
>
> +
> +if (src->height & 16 || src->linesize[0] & 16) {
> +realigned = 1;
> +memset(_frame, 0, sizeof(tmp_frame));
> +tmp_frame.format = src->format;
> +tmp_frame.width = FFALIGN(src->width, 16);
> +tmp_frame.height = FFALIGN(src->height, 16);
> +ret = av_frame_get_buffer(_frame, 32);
> +if (ret < 0)
> +return ret;
> +
> +ret = av_frame_copy(_frame, src);
> +if (ret < 0) {
> +av_frame_unref(_frame);
> +return ret;
> +}
> +}
> +
> +src_frame = realigned ? _frame : src;
> +
> if (!s->session_upload) {
> if (s->child_frames_ref)
> -return qsv_transfer_data_child(ctx, dst, src);
> +return qsv_transfer_data_child(ctx, dst, src_frame);
>
> av_log(ctx, AV_LOG_ERROR, "Surface upload not possible\n");
> return AVERROR(ENOSYS);
> }
>
> in.Info = out->Info;
> -map_frame_to_surface(src, );
> +map_frame_to_surface(src_frame, );
>
> do {
> err = MFXVideoVPP_RunFrameVPPAsync(s->session_upload, , out,
> NULL, );
> @@ -917,6 +941,9 @@ static int qsv_transfer_data_to(AVHWFramesContext
> *ctx, AVFrame *dst,
> return AVERROR_UNKNOWN;
> }
>
> +if (realigned)
> +av_frame_unref(_frame);
> +
> return 0;
> }
>
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
LGTM
regards
Max
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavu/qsv: fix a random hwupload failure regression
On Sun, Sep 30, 2018 at 11:14 AM Zhong Li wrote:
> Variable 'ret' hasn't been initialized，thus introducing a random
> hwupload failure regression due to qsv session uninitialized.
>
> Signed-off-by: Zhong Li
> ---
> libavutil/hwcontext_qsv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index cb3e184..33e121b 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -861,7 +861,7 @@ static int qsv_transfer_data_to(AVHWFramesContext
> *ctx, AVFrame *dst,
>
> mfxSyncPoint sync = NULL;
> mfxStatus err;
> -int ret;
> +int ret = 0;
>
> while (!s->session_upload_init && !s->session_upload && !ret) {
> #if HAVE_PTHREADS
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
LGTM
regards
Max
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] frame: Simplify the video allocation
On Tue, Sep 11, 2018 at 6:43 PM James Almer wrote: > On 9/3/2018 6:03 AM, Maxym Dmytrychenko wrote: > > On Mon, Sep 3, 2018 at 10:17 AM Michael Niedermayer > > > wrote: > > > >> On Sun, Sep 02, 2018 at 09:34:23PM -0300, James Almer wrote: > >>> From: Luca Barbato > >>> > >>> Merged-by: James Almer > >>> --- > >>> This is the next merge in the queue. It's a critical part of the > AVFrame > >> API, > >>> so even if FATE passes I'd rather have others look at it and test in > case > >>> something breaks. > >>> > >>> The only difference compared to the libav commit is the "32 - 1" > padding > >> per > >>> plane when allocating the buffer, which was only in our tree. > >> > >> why is the STRIDE_ALIGN (which is a thing in units of bytes along the > >> horizontal axis) added to padded_height which is vertical axis ? > >> This is not done prior to the change > >> > >> Also if this changes how buffers are structured or sized it requires a > more > >> detailed commit message than "frame: Simplify the video allocation" > >> > >> > > If can help: > > Use of av_image_fill_pointers() helps to allocate planes continuously > > instead of separate allocation for each plane, > > which can end up in very different start locations of the allocated > memory. > > > > Continuous allocation can be better for performance and/or functional > sides > > of the operations, > > example of Intel's HW - QSV, > > which is assuming Y/UV planes to be continuously allocated. > > I just merged this commit and the next, "qsv: enforcing continuous > memory layout" of your authoring, where one line checks the distance > between frame->data[1] and frame->data[0] to ensure the buffer is > continuous. This check, with the padding in our av_frame_get_buffer() > implementation, will probably always fail, but i can't test it. > > Can you look into it, if that's indeed the case? > just finished my test cases and it seems to be just fine, fixes the original, non-deterministic problem. distance between frame->data[1] and frame->data[0] is not always non-continuous(and causes the problem) where now av_frame_get_buffer() fixes such corner case. thanks, James regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] frame: Simplify the video allocation
On Mon, Sep 3, 2018 at 10:17 AM Michael Niedermayer wrote: > On Sun, Sep 02, 2018 at 09:34:23PM -0300, James Almer wrote: > > From: Luca Barbato > > > > Merged-by: James Almer > > --- > > This is the next merge in the queue. It's a critical part of the AVFrame > API, > > so even if FATE passes I'd rather have others look at it and test in case > > something breaks. > > > > The only difference compared to the libav commit is the "32 - 1" padding > per > > plane when allocating the buffer, which was only in our tree. > > why is the STRIDE_ALIGN (which is a thing in units of bytes along the > horizontal axis) added to padded_height which is vertical axis ? > This is not done prior to the change > > Also if this changes how buffers are structured or sized it requires a more > detailed commit message than "frame: Simplify the video allocation" > > If can help: Use of av_image_fill_pointers() helps to allocate planes continuously instead of separate allocation for each plane, which can end up in very different start locations of the allocated memory. Continuous allocation can be better for performance and/or functional sides of the operations, example of Intel's HW - QSV, which is assuming Y/UV planes to be continuously allocated. > thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I have often repented speaking, but never of holding my tongue. > -- Xenocrates > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel thank you - James, Michael. regards Maxym ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_qsv: fix log level for session initialization error
do you really want to have warning log with the error statement inside? (root case of such MFXVideoVPP_Init behaviour is different topic and actually should be re-checked) just looking at the initial issue on Windows: >I thought I had the entire pipeline (decode/scale-resize/encode) being performed by Quicksync it is not yet clear if exactly so and logs have to be checked, like CPU utilization can be high due to decode, as an example. Command line can be easier, if input codec format is supported by qsv, something like: ffmpeg.exe -hwaccel qsv -c:v h264_qsv -i "testvid.mp4" -vf "scale_qsv=640:360" -b:v 800k -c:v h264_qsv -c:a copy -y "testoutput.mp4" regards Maxym On Thu, Jul 5, 2018 at 3:20 PM Moritz Barsnick wrote: > On Thu, Jul 05, 2018 at 10:17:35 +, Li, Zhong wrote: > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Moritz Barsnick > [...] > > > Ideally, the returned mfxStatus would be evaluated and printed, but no > such > > > function is available (yet). %d perhaps? > > > > ff_qsv_print_error() can be used to print detailed error type. Is it > helpful? > > Basically yes, even in other places, but that function's in libavcodec, > and we're in libavutil. We would need to move the code around IIUC, but > I don't have any way of testing new code with this failing scenario > right now (I have this effect on a Windows machine, but can't actually > build on Windows), so that would be a blind modification from my side. > Better if the QSV maintainers (i.e. you ;-)) did this. > > This is the issue it would help to understand: > http://ffmpeg.org/pipermail/ffmpeg-user/2018-July/040438.html > > Thanks, > Moritz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
