[FFmpeg-devel] [PATCH] libavcodec/nvenc.c: copy incoming hwaccel frames instead of ref count increase
Hello,
This patch makes nvenc copy incoming hwaccel frames instead of ref count
increase.
It fixes the bug which may happen when on-GPU transcoding is done and encoder
is set to use B frames.
How to reproduce the bug:
./ffmpeg \
-hwaccel cuda -hwaccel_output_format cuda \
-i input.mkv \
-c:v h264_nvenc -preset p4 -tune hq -bf 3 \
-y output.mkv
Expected output:
[h264 @ 0x55b14da4b4c0] No decoder surfaces left
[h264 @ 0x55b14da682c0] No decoder surfaces left
[h264 @ 0x55b14da850c0] No decoder surfaces left
[h264 @ 0x55b14daa1ec0] No decoder surfaces left
Error while decoding stream #0:0: Invalid data found when processing input
[h264 @ 0x55b14da2e6c0] No decoder surfaces left
Error while decoding stream #0:0: Invalid data found when processing input
Last message repeated 1 times
Although fix adds extra CUDA DtoD memcopy, our internal testing results didn't
show any noticeable difference in transcoding performance.
From c95adcf7d5f5dd787eaa80fa4643e7868f85848e Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Tue, 14 Sep 2021 14:03:24 +0300
Subject: [PATCH] nvenc: copy incoming HW frame instead of referencing
---
libavcodec/nvenc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 815b9429b3..9b4c968179 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1849,7 +1849,7 @@ static int nvenc_upload_frame(AVCodecContext *avctx, const AVFrame *frame,
return reg_idx;
}
-res = av_frame_ref(nvenc_frame->in_ref, frame);
+res = av_hwframe_transfer_data(nvenc_frame->in_ref, frame, 0);
if (res < 0)
return res;
@@ -1858,7 +1858,6 @@ static int nvenc_upload_frame(AVCodecContext *avctx, const AVFrame *frame,
ctx->registered_frames[reg_idx].in_map.registeredResource = ctx->registered_frames[reg_idx].regptr;
nv_status = p_nvenc->nvEncMapInputResource(ctx->nvencoder, &ctx->registered_frames[reg_idx].in_map);
if (nv_status != NV_ENC_SUCCESS) {
-av_frame_unref(nvenc_frame->in_ref);
return nvenc_print_error(avctx, nv_status, "Error mapping an input resource");
}
}
@@ -2029,8 +2028,6 @@ static int process_output_surface(AVCodecContext *avctx, AVPacket *pkt, NvencSur
goto error;
}
-av_frame_unref(tmpoutsurf->in_ref);
-
tmpoutsurf->input_surface = NULL;
}
--
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".
Re: [FFmpeg-devel] [PATCH] libavcodec/nvenc.c: copy incoming hwaccel frames instead of ref count increase
This is a good point, let me check and come back later. От: Timo Rothenpieler Отправлено: 28 сентября 2021 г. 21:28 Кому: FFmpeg development discussions and patches ; Roman Arzumanyan Копия: Yogender Gupta ; Ricardo Monteiro Тема: Re: [FFmpeg-devel] [PATCH] libavcodec/nvenc.c: copy incoming hwaccel frames instead of ref count increase External email: Use caution opening links or attachments ___ 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] libavcodec/nvenc.c: copy incoming hwaccel frames instead of ref count increase
Thanks for the quick update, Timo. Honestly I just might have missed this moment with input frame registering as I was tracking CUdeviceptr's in map / unmap and memcpy calls. Strangely enough the patch has passed extensive QA validation round on different codecs and HW setups. I think your approach is obviously safer and illustrates better API usage. От: Timo Rothenpieler Отправлено: Вторник, 28 сентября, 2021 22:11 Кому: FFmpeg development discussions and patches; Roman Arzumanyan Копия: Yogender Gupta; Ricardo Monteiro Тема: Re: [FFmpeg-devel] [PATCH] libavcodec/nvenc.c: copy incoming hwaccel frames instead of ref count increase On 28.09.2021 19:58, Timo Rothenpieler wrote: > Hmm, so far my approach to deal with this was to inject a > scale_cuda=passthrough=0 into the filter chain, which pretty much does > exactly this, but only controllable by the user. > > But I do agree that this is a bit of a clutch and not all that user > friendly. > > My main concern with this approach is that it will inevitably increase > VRAM usage, depending on bframe count and resolution even quite > significantly. > And it's surprisingly common that users show up that are highly pressed > for memory. When bframes were switched on by default, several people > showed up who where suddenly running out of VRAM. > > I do like this approach though, since it will for the average user make > using a full hw chain a lot less bothersome. > > So what I'd propose is: > > - Add an option to retain the old behaviour of just holding a reference > to the input frame no matter what. > - Instead of explicitly copying the frame like you do right now, call > av_frame_make_writable() on the frame, right after where you right now > are replacing av_frame_ref with av_hwframe_transfer_data. > That is for one very easy to disable conditionally, and does not require > you to guard all the unref calls. > Plus, it will only actually copy the frame if needed (i.e. it won't do > anything if it comes out of a filterchain and has nothing else holding a > ref) > > > Timo See attached patch for that approach. I just encoded a 5 minute sample using it, and I do see a marginal decrease in performance (it drops by literally x0.01 speed, so pretty much within margin of error, but it did show that consistently) and increase in VRAM usage as expected. However, given that your patch does seem to work just fine, somehow, it would be interesting to know if re-using a frame/CUDA buffer after registering it with nvenc is safe? Given that the logic right now never unregisters buffers unless it runs out of free slots, it would seem weird to me if that was the case. What if a buffer actually does get re-used, as is common with non-nvdec-frames allocated from a hwframes ctx? ___ 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] avfilter: add sharpen_npp video filter
Thanks for review, Timo.
Please find revised patch attached.
(de)interlacing is now removed, doc entry was added as well.
От: Timo Rothenpieler
Отправлено: 28 сентября 2021 г. 22:58
Кому: FFmpeg development discussions and patches ;
Roman Arzumanyan
Копия: Yogender Gupta ; Ricardo Monteiro
Тема: Re: [FFmpeg-devel] [PATCH] avfilter: add sharpen_npp video filter
External email: Use caution opening links or attachments
From 422be4d348a07e1abbdae0208a20cd1f3ce70e28 Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Mon, 6 Sep 2021 14:26:27 +0300
Subject: [PATCH] avcodec/sharpen_npp: adding sharpening video filter with
borders control
---
configure| 5 +-
doc/filters.texi | 17 +++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h| 2 +-
libavfilter/vf_sharpen_npp.c | 284 +++
6 files changed, 307 insertions(+), 3 deletions(-)
create mode 100644 libavfilter/vf_sharpen_npp.c
diff --git a/configure b/configure
index 231d0398a8..5e630e6e5d 100755
--- a/configure
+++ b/configure
@@ -3094,6 +3094,7 @@ thumbnail_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
transpose_npp_filter_deps="ffnvcodec libnpp"
overlay_cuda_filter_deps="ffnvcodec"
overlay_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
+sharpen_npp_filter_deps="ffnvcodec libnpp"
amf_deps_any="libdl LoadLibrary"
nvenc_deps="ffnvcodec"
@@ -6444,8 +6445,8 @@ enabled libmodplug&& require_pkg_config libmodplug libmodplug libmodplug
enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h lame_set_VBR_quality -lmp3lame $libm_extralibs
enabled libmysofa && { check_pkg_config libmysofa libmysofa mysofa.h mysofa_neighborhood_init_withstepdefine ||
require libmysofa mysofa.h mysofa_neighborhood_init_withstepdefine -lmysofa $zlib_extralibs; }
-enabled libnpp&& { check_lib libnpp npp.h nppGetLibVersion -lnppig -lnppicc -lnppc -lnppidei ||
- check_lib libnpp npp.h nppGetLibVersion -lnppi -lnppc -lnppidei ||
+enabled libnpp&& { check_lib libnpp npp.h nppGetLibVersion -lnppig -lnppicc -lnppc -lnppidei -lnppif ||
+ check_lib libnpp npp.h nppGetLibVersion -lnppi -lnppif -lnppc -lnppidei ||
die "ERROR: libnpp not found"; }
enabled libopencore_amrnb && require libopencore_amrnb opencore-amrnb/interf_dec.h Decoder_Interface_init -lopencore-amrnb
enabled libopencore_amrwb && require libopencore_amrwb opencore-amrwb/dec_if.h D_IF_init -lopencore-amrwb
diff --git a/doc/filters.texi b/doc/filters.texi
index 568c2995bc..c9bd4ac87d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1,6 +1,23 @@ Keep the same colorspace property (default).
@end table
@end table
+@section sharpen_npp
+Use the NVIDIA Performance Primitives (libnpp) to perform image sharpening with
+border control.
+
+The following additional options are accepted:
+@table @option
+
+@item border_type
+Type of sampling to be used ad frame borders. One of the following:
+@table @option
+
+@item replicate
+Replicate pixel values.
+
+@end table
+@end table
+
@section shear
Apply shear transform to input video.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fa2d18e45f..ab5e0ce075 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -426,6 +426,7 @@ OBJS-$(CONFIG_SETRANGE_FILTER) += vf_setparams.o
OBJS-$(CONFIG_SETSAR_FILTER) += vf_aspect.o
OBJS-$(CONFIG_SETTB_FILTER) += settb.o
OBJS-$(CONFIG_SHARPNESS_VAAPI_FILTER)+= vf_misc_vaapi.o vaapi_vpp.o
+OBJS-$(CONFIG_SHARPEN_NPP_FILTER)+= vf_sharpen_npp.o
OBJS-$(CONFIG_SHEAR_FILTER) += vf_shear.o
OBJS-$(CONFIG_SHOWINFO_FILTER) += vf_showinfo.o
OBJS-$(CONFIG_SHOWPALETTE_FILTER)+= vf_showpalette.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 338561a446..002626cef7 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -407,6 +407,7 @@ extern const AVFilter ff_vf_setrange;
extern const AVFilter ff_vf_setsar;
extern const AVFilter ff_vf_settb;
extern const AVFilter ff_vf_sharpness_vaapi;
+extern const AVFilter ff_vf_sharpen_npp;
extern const AVFilter ff_vf_shear;
extern const AVFilter ff_vf_showinfo;
extern const AVFilter ff_vf_showpalette;
diff --git a/libavfilter/version.h b/libavfilter/version.h
index ab5eb14634..dfbc1bd7c2 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -30,7 +30,7 @@
#include "libavutil/version.h"
#define LIBAVFILTER_VERSION_MAJOR 8
-#define LIBAVFILTER_VERSION_MINOR 10
+#define LIBAVFILTER_VERSION_MINOR 11
#define LIBAVF
Re: [FFmpeg-devel] [PATCH] avfilter: add scale2ref_npp video filter
Thanks for the review, Timo.
Please find revised patch attached.
Docstring was added, trailing spaces removed, commit message brushed up.
Avfilter minor version bump added.
От: Timo Rothenpieler
Отправлено: 28 сентября 2021 г. 22:37
Кому: FFmpeg development discussions and patches ;
Roman Arzumanyan
Копия: Yogender Gupta ; Ricardo Monteiro
Тема: Re: [FFmpeg-devel] [PATCH] avfilter: add scale2ref_npp video filter
External email: Use caution opening links or attachments
From c8a7fa9c564049ca48a95b0fb315dc904e84a4b0 Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Mon, 6 Sep 2021 15:25:51 +0300
Subject: [PATCH] libavfilter/scale_npp: scale2ref_npp filter added
---
doc/filters.texi | 76 ++
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vf_scale_npp.c | 512 +++--
4 files changed, 565 insertions(+), 26 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index c9bd4ac87d..846aba0fda 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -18493,6 +18493,82 @@ Set value which will be added to filtered result.
This filter supports the all above options as @ref{commands}.
+@section scale2ref_npp
+
+Use the NVIDIA Performance Primitives (libnpp) to scale (resize) the input
+video, based on a reference video.
+
+See the scale_npp filter for available options, scale2ref_npp supports the same
+but uses the reference video instead of the main input as basis. scale2ref_npp
+also supports the following additional constants for the @option{w} and
+@option{h} options:
+
+@table @var
+@item main_w
+@item main_h
+The main input video's width and height
+
+@item main_a
+The same as @var{main_w} / @var{main_h}
+
+@item main_sar
+The main input video's sample aspect ratio
+
+@item main_dar, mdar
+The main input video's display aspect ratio. Calculated from
+@code{(main_w / main_h) * main_sar}.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Scale a subtitle stream (b) to match the main video (a) in size before overlaying
+@example
+'scale2ref_npp[b][a];[a][b]overlay_cuda'
+@end example
+
+@item
+Scale a logo to 1/10th the height of a video, while preserving its display aspect ratio.
+@example
+[logo-in][video-in]scale2ref_npp=w=oh*mdar:h=ih/10[logo-out][video-out]
+@end example
+@end itemize
+
+@subsection Commands
+
+This filter supports the following commands:
+@table @option
+@item width, w
+@item height, h
+Set the output video dimension expression.
+The command accepts the same syntax of the corresponding option.
+
+If the specified expression is not valid, it is kept at its current
+value.
+@end table
+
+@section scharr
+Apply scharr operator to input video stream.
+
+The filter accepts the following option:
+
+@table @option
+@item planes
+Set which planes will be processed, unprocessed planes will be copied.
+By default value 0xf, all planes will be processed.
+
+@item scale
+Set value which will be multiplied with filtered result.
+
+@item delta
+Set value which will be added to filtered result.
+@end table
+
+@subsection Commands
+
+This filter supports the all above options as @ref{commands}.
+
@section scroll
Scroll input video horizontally and/or vertically by constant speed.
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 002626cef7..63415d2f8d 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -391,6 +391,7 @@ extern const AVFilter ff_vf_scale_qsv;
extern const AVFilter ff_vf_scale_vaapi;
extern const AVFilter ff_vf_scale_vulkan;
extern const AVFilter ff_vf_scale2ref;
+extern const AVFilter ff_vf_scale2ref_npp;
extern const AVFilter ff_vf_scdet;
extern const AVFilter ff_vf_scharr;
extern const AVFilter ff_vf_scroll;
diff --git a/libavfilter/version.h b/libavfilter/version.h
index dfbc1bd7c2..e4c25b9225 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -30,7 +30,7 @@
#include "libavutil/version.h"
#define LIBAVFILTER_VERSION_MAJOR 8
-#define LIBAVFILTER_VERSION_MINOR 11
+#define LIBAVFILTER_VERSION_MINOR 12
#define LIBAVFILTER_VERSION_MICRO 100
diff --git a/libavfilter/vf_scale_npp.c b/libavfilter/vf_scale_npp.c
index 3e25c2c95f..09f35a3143 100644
--- a/libavfilter/vf_scale_npp.c
+++ b/libavfilter/vf_scale_npp.c
@@ -25,13 +25,13 @@
#include
#include
-#include "libavutil/avstring.h"
-#include "libavutil/common.h"
#include "libavutil/hwcontext.h"
#include "libavutil/hwcontext_cuda_internal.h"
#include "libavutil/cuda_check.h"
#include "libavutil/internal.h"
#include "libavutil/opt.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/eval.h"
#include "libavutil/pixdesc.h"
#include "avfilter.h"
@@ -44,12 +44,13 @@
static const enum AVPixelFormat supported_formats[] = {
AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUVA
Re: [FFmpeg-devel] [PATCH] avfilter: add scale2ref_npp video filter
Thanks for the review Andreas, that's indeed helpful.
Allow me some time, I'll come back bit later with revised patch.
От: ffmpeg-devel от имени Andreas Rheinhardt
Отправлено: 4 октября 2021 г. 11:59
Кому: ffmpeg-devel@ffmpeg.org
Тема: Re: [FFmpeg-devel] [PATCH] avfilter: add scale2ref_npp video filter
External email: Use caution opening links or attachments
Roman Arzumanyan:
> Thanks for the review, Timo.
>
> Please find revised patch attached.
> Docstring was added, trailing spaces removed, commit message brushed up.
> Avfilter minor version bump added.
This has lots of duplication with the ordinary scale filter: var_names,
enum var_name and enum eval_mode are identical; check_exprs and
scale_pars_expr are basically the same. You are even copying bugs from
the original scale filter: Its handling of the AVDictionary is buggy,
because it is supposed to return an AVDictionary with all the
unrecognized/unsupported options instead of just taking all the options.
Given that your filter simply ignores the options your handling of it is
worse, but also more easily fixable: Use the init-callback instead of
the init_dict and remove the unused options completely.
>
> @@ -366,8 +715,8 @@ static int nppscale_config_props(AVFilterLink *outlink)
> inlink->w, inlink->h, outlink->w, outlink->h);
>
> if (inlink->sample_aspect_ratio.num)
> -outlink->sample_aspect_ratio =
> av_mul_q((AVRational){outlink->h*inlink->w,
> -
> outlink->w*inlink->h},
> +outlink->sample_aspect_ratio = av_mul_q((AVRational){outlink->h *
> inlink->w,
> + outlink->w *
> inlink->h},
> inlink->sample_aspect_ratio);
> else
> outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
Cosmetic change; should not be in a functional commit.
>
> @@ -148,7 +483,9 @@ static int nppscale_query_formats(AVFilterContext *ctx)
> static const enum AVPixelFormat pixel_formats[] = {
> AV_PIX_FMT_CUDA, AV_PIX_FMT_NONE,
> };
> -return ff_set_common_formats_from_list(ctx, pixel_formats);
> +AVFilterFormats *pix_fmts = ff_make_format_list(pixel_formats);
> +
> +return ff_set_common_formats(ctx, pix_fmts);
> }
ff_set_common_formats_from_list(ctx, pixel_formats) is a shortcut for
ff_set_common_formats(ctx, ff_make_format_list(pixel_formats)), so this
is not a functional change; it just adds more code duplication.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel&data=04%7C01%7Crarzumanyan%40nvidia.com%7C2d27e43ba73646720eb408d9871549ad%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637689348213495919%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lcu8tWfQOz0ROcat8ipL9kYqp%2FJc5iw8EldqrG6EjdA%3D&reserved=0
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] avfilter: add scale2ref_npp video filter
Please find revised patch attached.
>Use the init-callback instead of the init_dict and remove the unused options
>completely.
Did that.
>This has lots of duplication with the ordinary scale filter
There are some leftovers copy-pasted from scale2ref filter to make
scale2ref_npp parameters syntax similar. Their amount was trimmed to possible
minimum.
От: ffmpeg-devel от имени Andreas Rheinhardt
Отправлено: 4 октября 2021 г. 11:59
Кому: ffmpeg-devel@ffmpeg.org
Тема: Re: [FFmpeg-devel] [PATCH] avfilter: add scale2ref_npp video filter
External email: Use caution opening links or attachments
Roman Arzumanyan:
> Thanks for the review, Timo.
>
> Please find revised patch attached.
> Docstring was added, trailing spaces removed, commit message brushed up.
> Avfilter minor version bump added.
This has lots of duplication with the ordinary scale filter: var_names,
enum var_name and enum eval_mode are identical; check_exprs and
scale_pars_expr are basically the same. You are even copying bugs from
the original scale filter: Its handling of the AVDictionary is buggy,
because it is supposed to return an AVDictionary with all the
unrecognized/unsupported options instead of just taking all the options.
Given that your filter simply ignores the options your handling of it is
worse, but also more easily fixable: Use the init-callback instead of
the init_dict and remove the unused options completely.
>
> @@ -366,8 +715,8 @@ static int nppscale_config_props(AVFilterLink *outlink)
> inlink->w, inlink->h, outlink->w, outlink->h);
>
> if (inlink->sample_aspect_ratio.num)
> -outlink->sample_aspect_ratio =
> av_mul_q((AVRational){outlink->h*inlink->w,
> -
> outlink->w*inlink->h},
> +outlink->sample_aspect_ratio = av_mul_q((AVRational){outlink->h *
> inlink->w,
> + outlink->w *
> inlink->h},
> inlink->sample_aspect_ratio);
> else
> outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
Cosmetic change; should not be in a functional commit.
>
> @@ -148,7 +483,9 @@ static int nppscale_query_formats(AVFilterContext *ctx)
> static const enum AVPixelFormat pixel_formats[] = {
> AV_PIX_FMT_CUDA, AV_PIX_FMT_NONE,
> };
> -return ff_set_common_formats_from_list(ctx, pixel_formats);
> +AVFilterFormats *pix_fmts = ff_make_format_list(pixel_formats);
> +
> +return ff_set_common_formats(ctx, pix_fmts);
> }
ff_set_common_formats_from_list(ctx, pixel_formats) is a shortcut for
ff_set_common_formats(ctx, ff_make_format_list(pixel_formats)), so this
is not a functional change; it just adds more code duplication.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel&data=04%7C01%7Crarzumanyan%40nvidia.com%7C2d27e43ba73646720eb408d9871549ad%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637689348213495919%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lcu8tWfQOz0ROcat8ipL9kYqp%2FJc5iw8EldqrG6EjdA%3D&reserved=0
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
From 633df1b03f53853dbbd399caacc13722b1c4c279 Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Mon, 6 Sep 2021 15:25:51 +0300
Subject: [PATCH] libavfilter/scale_npp: scale2ref_npp filter added
---
doc/filters.texi | 76 +++
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vf_scale_npp.c | 450 +++--
4 files changed, 506 insertions(+), 23 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index c9bd4ac87d..846aba0fda 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -18493,6 +18493,82 @@ Set value which will be added to filtered result.
This filter supports the all above options as @ref{commands}.
+@section scale2ref_npp
+
+Use the NVIDIA Performance Primitives (libnpp) to scale (resize) the input
+video, based on a reference video.
+
+See the scale_npp filter for available options, scale2ref_npp supports the same
+but uses the reference video instead of the main input as basis. scale2ref_npp
+also supports the following additional constants for the @option{w} and
+@option{h} options:
+
+@table @var
+@item main_w
+@item main_h
+The main input video's width and height
+
+@item main_a
+The same as @var{main_w} / @var{main_h}
+
+@item main_sar
+The main input video's sample aspect ratio
+
+@item main_dar, mdar
+The main inp
Re: [FFmpeg-devel] next release
LTS releases would be a superb option for corporate FFMpeg users. От: ffmpeg-devel от имени Michael Niedermayer Отправлено: 6 октября 2021 г. 12:57 Кому: FFmpeg development discussions and patches Тема: [FFmpeg-devel] next release External email: Use caution opening links or attachments Hi Should the next release be called "LTS"? Should the next release be 4.5 or 5.0 ? Should it be made in december 2021 ? (as was suggested in jbs release mail) thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri ___ 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] [PATCH] avfilter/vf_transpose adding NPP transpose filter
Hello, This patch adds NPP transpose filter. Cmd example: ffmpeg.exe -hwaccel cuvid -c:v h264_cuvid -i input.mp4 -vf transpose_npp="t=3" -c:v h264_nvenc -y output_transpose_npp.mp4 Supported values: t=0 no transpose t=1 90 deg clockwise t=2 180 deg clockwise t=3 270 deg clockwise -- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-Adding-NPP-transpose-filter.patch Description: 0001-Adding-NPP-transpose-filter.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_transpose adding NPP transpose filter
Hi Timo, Refactored the patch according to your review: 1. It actually does the rotation, so renamed the filter. 2. Replaced "t" with the "a" & "angle" cli options like in vf_rotate filter. Though supporting rotation angle multiple of 90 degrees. 3. Added the config dependency (not sure if I've done it the right way). Cmd to check: ffmpeg.exe ^ -hwaccel cuvid ^ -codec:v h264_cuvid ^ -i input_240.mp4 ^ -vcodec h264_nvenc ^ -vf rotate_npp="a=180" ^ -y rotate_npp_180.mp4 -Original Message- From: ffmpeg-devel On Behalf Of Timo Rothenpieler Sent: Monday, September 3, 2018 1:43 PM To: FFmpeg development discussions and patches ; Roman Arzumanyan Cc: Yogender Gupta Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_transpose adding NPP transpose filter Minus the missing configure dependency, documentation entry and minor bump, the filter looks fine to me code wise. Two issues though: From my understanding, it's not a transpose filter, but a rotation one, fixed to 90 degree angles. Unless I'm missing something in the code, it's not doing any actual flipping, like vf_transpose does. It should also be calling nppiTranspose_8u_C1R somewhere after/before the call to nppiRotate_8u_C1R. Or use a transformation matrix to do the transposition in one step, assuming libnpp has a function for that. It's possible that I missed it doing the transpose somewhere, so please correct me if I'm wrong. I'd also strongly prefer this filter to be compatible with the arguments of normal vf_transpose, and behave the same for the same arguments. Additional parameters with more functions are fine. Timo --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-Adding-NPP-rotate-filter.patch Description: 0001-Adding-NPP-rotate-filter.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_transpose_npp: adding NV12 support to transpose_npp filter
Hello, This patch adds NV12 support to vf_transpose_npp filter. Now filter can be used in nvdec -> nvenc transcoding scenarios like this: ffmpeg -hwaccel cuvid -c:v h264_cuvid -i input.h264 -c:v h264_nvenc -vf transpose_npp="dir=clock" -y output.h264 -- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-Adding-NV12-support-to-transpose_npp-filter.patch Description: 0001-Adding-NV12-support-to-transpose_npp-filter.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/nvenc: set average and max bitrate values to zero when in CQ rate control mode
Hello, The patch fixes bug with CQ RC mode: max and average bitrate values were not set to zero. How to reproduce: #CQ 30 file ffmpeg \ -i big_buck_bunny_1080p_h264.mov -c:v h264_nvenc -preset medium \ -cq 30 -y output_cq30.mp4 #CQ 10 file ffmpeg \ -i big_buck_bunny_1080p_h264.mov -c:v h264_nvenc -preset medium \ -cq 10 -y output_cq10.mp4 Before the patch, both output_cq30.mp4 and output_cq10.mp4 were of same size. After the patch, output_cq10.mp4 file has higher quality and bigger size. -- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-fixing-CQ-mode-avg-max-bitrate-settings.patch Description: 0001-fixing-CQ-mode-avg-max-bitrate-settings.patch ___ 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] [PATCH] avcodec/nvenc: maxBitrate is honored in CQ mode if set by user
This fixes bug in my previous patch which was discarding maxBitrate. CQ mode shall honor maxBitrate value if it's set by user via CLI. How to check: ./ffmpeg.exe \ -i big_buck_bunny_1080p_h264.mov \ -c:v h264_nvenc \ -cq 10 \ -maxrate 10M \ -y output_cq10_10M.mp4 -- BR, Roman Arzumanyan 0001-Fixing-bug-in-CQ-RC-mode.-Max-bitrate-is-honored-if-.patch Description: 0001-Fixing-bug-in-CQ-RC-mode.-Max-bitrate-is-honored-if-.patch ___ 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] [PATCH] avcodec/nvenc: multiple reference frames support
Hello, This patch adds multiple reference frames support (part of Video Codec SDK 9.1). It adds "nb_ref_frames" CLI option to set number of reference frames. Possible values: * auto - let encoder decide (default value). * [0;7] - set value by hand. 0 is equal to auto. Usage example: ffmpeg -i big_buck_bunny_1080p_h264.mov -c:v hevc_nvenc -frames:v 128 -nb_ref_frames auto -bf 2 -y big_buck_bunny_1080p_nb_auto.h265 ffmpeg -i big_buck_bunny_1080p_h264.mov -c:v h264_nvenc -frames:v 128 -nb_ref_frames 1 -y big_buck_bunny_1080p_nb_1.h264 Actual number of reference frames will be determined by encoder, but it will not exceed value of "nb_ref_frames" option. -- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-avcodec-nvenc-adding-multiple-reference-frames.patch Description: 0001-avcodec-nvenc-adding-multiple-reference-frames.patch ___ 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] avcodec/nvenc: multiple reference frames support
> First, this needs SDK Version Guards Thanks, I've missed that. Added to patch. > Second, in what way is this different from the existing global > option(avctx->refs), which nvenc.c already uses to set It's slightly different from existing global option (gives more fine-grain control): "nb_ref_frames" effectively specifies maximum allowed number of reference frames in L0 and L1 reference lists for every P & B frame; "avctx->refs" effectively specifies DPB size; -Original Message- From: ffmpeg-devel On Behalf Of Timo Rothenpieler Sent: Friday, September 27, 2019 12:56 PM To: FFmpeg development discussions and patches ; Roman Arzumanyan Cc: Yogender Gupta Subject: Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: multiple reference frames support On 27/09/2019 11:04, Roman Arzumanyan wrote: > Hello, > > This patch adds multiple reference frames support (part of Video Codec SDK > 9.1). > It adds "nb_ref_frames" CLI option to set number of reference frames. > Possible values: > >* auto - let encoder decide (default value). >* [0;7] - set value by hand. 0 is equal to auto. > > Usage example: > ffmpeg -i big_buck_bunny_1080p_h264.mov -c:v hevc_nvenc -frames:v 128 > -nb_ref_frames auto -bf 2 -y big_buck_bunny_1080p_nb_auto.h265 > ffmpeg -i big_buck_bunny_1080p_h264.mov -c:v h264_nvenc -frames:v 128 > -nb_ref_frames 1 -y big_buck_bunny_1080p_nb_1.h264 > > Actual number of reference frames will be determined by encoder, but it will > not exceed value of "nb_ref_frames" option. Thanks! Two things: First, this needs SDK Version Guards, since we want to keep supporting building against older SDKs and thus Driver-Versions. There are a few examples in nvenc.h already, like NVENC_HAVE_HEVC_BFRAME_REF_MODE. It should be done in the same fashion for this feature. Second, in what way is this different from the existing global option(avctx->refs), which nvenc.c already uses to set h264->maxNumRefFrames and hevc->maxNumRefFramesInDPB? The refs option is documented as "number of reference frames", which seems fitting for this. Can that option just be re-used to also set this new parameter, if it's available, or are they doing different things? ___ 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". --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-avcodec-nvenc-adding-multiple-reference-frames.patch Description: 0001-avcodec-nvenc-adding-multiple-reference-frames.patch ___ 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] [PATCH] nv-codec-headers: Video Codec SDK 9 support
Hello, Please find attached patch for nv-codec-headers. It adds Video Codec SDK 9 support. -- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-Updating-headers-for-Video-Codec-SDK-9-release.patch Description: 0001-Updating-headers-for-Video-Codec-SDK-9-release.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] libavcodec/nvenc_hevc: adding B frame support
Hello, Please find attached patch, it adds HEVC B-frames support to nvenc_hevc. This feature requires Video Codec SDK 9 + Turing card. -- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-Adding-b_as_ref-support-for-HEVC.patch Description: 0001-Adding-b_as_ref-support-for-HEVC.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] libavcodec/cuviddec: adding HEVC YUV444P decoding support
Hello, Please find attached patch, it adds HEVC YUV444P decoding support. Supported formats are AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUV444P12LE. This feature requires Video Codec SDK 9. -- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-Adding-HEVC-YUV444P-decoding-support.patch Description: 0001-Adding-HEVC-YUV444P-decoding-support.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
Hello world, > [your idea here] Fully async API which provides a means to receive a notification when a frame is decoded / processed by filter etc. Be it a callback, conditional variable etc. чт, 18 апр. 2024 г. в 12:22, : > > > On 18 Apr 2024, at 10:46, Stefano Sabatini wrote: > > > On date Wednesday 2024-04-17 15:58:32 +0200, Michael Niedermayer wrote: > >> Hi all > >> > >> The pace of inovation in FFmpeg has been slowing down. > >> Most work is concentarted nowadays on code refactoring, and adding > >> support for new codecs and formats. > >> > >> Should we > >> * make a list of longer term goals > >> * vote on them > >> * and then together work towards implementing them > >> ? > >> > >> (The idea here is to increase the success of larger efforts > >> than adding codecs and refactoring code) > >> It would then also not be possible for individuals to object > >> to a previously agreed goal. > >> And it would add ideas for which we can try to get funding/grants for > >> > >> (larger scale changes need consensus first that we as a whole want > >> them before we would be able to ask for funding/grants for them) > >> > >> Some ideas and why they would help FFmpeg: > >> > > [...] > >> * client side / in browser support > >> (expand towards webapps, webpages using ffmpeg client side in the > browser) > >> bring in more users and developers, and it will be costly for us > >> if we let others take this area as its important and significant > > > > There are already several projects on github, the most prominent one: > > https://github.com/ffmpegwasm/ffmpeg.wasm/ > > > > In general it would be useful to provide libav* bindings to other > > languages, for example: > > https://github.com/PyAV-Org/PyAV > > https://github.com/zmwangx/rust-ffmpeg > > > > Not sure these should be really moved to FFmpeg though. > > > > One option I'm currenly exploring is having a python filter enabling > > to specify a custom filter implemented in python (needed for custom > > ad-hoc logic you don't really want to implement in C since it's not > > generic enough) and to enable using python modules when effiency is > > not an issue. > > Lua would probably be a better choice for this from ease of integration > and also speed PoV last I checked. IIRC Python had some rather complex > threading implications when used in a library. > > But I agree having something like this in general seems nice for some > prototyping and debugging with filters as well. > > > ___ > > 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] [PATCH] avcodec/nvenc: High bit depth encoding for HEVC
Hi Diego,
Asking for my own education.
As far as you've explained, the 8 > 10 bit conversion happens within the
driver, that's understandable.
But how does it influence the output? Does it perform some sort of
proprietary SDR > HDR conversion under the hood that maps the ranges?
What's gonna be the user observable difference between these 2 scenarios?
1) 8 bit input > HEVC 8 bit profile > 8 bit HEVC output
2) 8 bit input > 10 bit up conversion > HEVC 10 bit profile > 10 bit HEVC
output
Better visual quality? Smaller compressed file size?
In other words, what's the purpose of this feature except enabling new
Video Codec SDK capability?
чт, 18 апр. 2024 г. в 13:44, Diego Felix de Souza via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org>:
> Hi Timo,
>
> Thank you for your review. Please check my answers below.
>
> Best regards,
>
> Diego
>
> On 17.04.24, 16:27, "Timo Rothenpieler" wrote:
>
> External email: Use caution opening links or attachments
>
>
> On 15/04/2024 16:39, Diego Felix de Souza via ffmpeg-devel wrote:
> > From: Diego Felix de Souza
> >
> > Adding 10-bit encoding support for HEVC if the input is 8-bit. In
> > case of 8-bit input content, NVENC performs an internal CUDA 8 to
> > 10-bit conversion of the input prior to encoding. Currently, only
> > AV1 supports encoding 8-bit content as 10-bit.
>
> I'm not sure about this one.
> Since it's just "SW", or rather CUDA based, conversion, this job could
> also be done by scale_cuda, outside of some niche formats it doesn't
> support yet.
> Which would also allow for more consistent command lines across versions.
>
>
> Although it is a software-based solution, the conversion is integrated
> with other kernels
> inside the driver. In this way, it will demand fewer memory accesses and
> better Streaming
> Multiprocessor (SM) utilization, leading to a improved performance and a
> lower latency
> compared to the scale_cuda approach. Moreover, the proposed approach
> overall consumes
> less memory since it only requires an 8-bit per channel frame as input and
> no extra 10-bit frames.
>
>
> > Signed-off-by: Diego Felix de Souza
> > ---
> > libavcodec/nvenc.c | 8
> > libavcodec/nvenc_hevc.c | 1 +
> > 2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> > index 794174a53f..c302cc7dc4 100644
> > --- a/libavcodec/nvenc.c
> > +++ b/libavcodec/nvenc.c
> > @@ -514,7 +514,7 @@ static int nvenc_check_capabilities(AVCodecContext
> *avctx)
> > }
> >
> > ret = nvenc_check_cap(avctx, NV_ENC_CAPS_SUPPORT_10BIT_ENCODE);
> > -if (IS_10BIT(ctx->data_pix_fmt) && ret <= 0) {
> > +if ((IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) && ret <= 0)
> {
> > av_log(avctx, AV_LOG_WARNING, "10 bit encode not supported\n");
> > return AVERROR(ENOSYS);
> > }
> > @@ -1421,7 +1421,7 @@ static av_cold int
> nvenc_setup_hevc_config(AVCodecContext *avctx)
> > }
> >
> > // force setting profile as main10 if input is 10 bit
> > -if (IS_10BIT(ctx->data_pix_fmt)) {
> > +if (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) {
>
> Won't this need guarded behind the NVENC_HAVE_NEW_BIT_DEPTH_API as well?
> Or would this also work fine with older headers, by just setting this?
>
> For older SDK versions, the HEVC main 10 profile would be selected, but
> the encoded bitstream
> would be still 8-bits. For the sake of consistence and clarity, I will put
> it behind the
> NVENC_HAVE_NEW_BIT_DEPTH_API as you suggested.
>
> > cc->profileGUID = NV_ENC_HEVC_PROFILE_MAIN10_GUID;
> > avctx->profile = AV_PROFILE_HEVC_MAIN_10;
> > }
> > @@ -1435,8 +1435,8 @@ static av_cold int
> nvenc_setup_hevc_config(AVCodecContext *avctx)
> > hevc->chromaFormatIDC = IS_YUV444(ctx->data_pix_fmt) ? 3 : 1;
> >
> > #ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
> > -hevc->inputBitDepth = hevc->outputBitDepth =
> > -IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 :
> NV_ENC_BIT_DEPTH_8;
> > +hevc->inputBitDepth = IS_10BIT(ctx->data_pix_fmt) ?
> NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
> > +hevc->outputBitDepth = (IS_10BIT(ctx->data_pix_fmt) ||
> ctx->highbitdepth) ? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
> > #else
> > hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
> > #endif
> > diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
> > index b949cb1bd7..02e9c9c8eb 100644
> > --- a/libavcodec/nvenc_hevc.c
> > +++ b/libavcodec/nvenc_hevc.c
> > @@ -183,6 +183,7 @@ static const AVOption options[] = {
> > { "fullres", "Two Pass encoding is enabled where first Pass
> is full resolution",
> > 0,
> AV_OPT_TYPE_CONST, { .i64 = NV_ENC_TWO_PASS_FULL_RESOLUTION },
> 0, 0, VE, .unit =
> "multipass" },
> > #endif
> > +{ "highbitdepth", "Enable 10 bit encode for 8 bit
>
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: High bit depth encoding for HEVC
Thanks for the explanation, Timo! I was hoping that 8>10 bit up-conversion which happens in the driver may bring some goodness like SDR > HDR conversion, recently presented by NV. Or some other algo which is easier to keep proprietary. Otherwise, although it is convenient in some use cases, it doesn't look more tempting than, say, a similar 8>10 bit NPP up-conversion which shall yield the same (presumably SoL) performance. чт, 18 апр. 2024 г. в 16:32, Timo Rothenpieler : > On 18/04/2024 14:29, Roman Arzumanyan wrote: > > Hi Diego, > > Asking for my own education. > > > > As far as you've explained, the 8 > 10 bit conversion happens within the > > driver, that's understandable. > > But how does it influence the output? Does it perform some sort of > > proprietary SDR > HDR conversion under the hood that maps the ranges? > > What's gonna be the user observable difference between these 2 scenarios? > > 1) 8 bit input > HEVC 8 bit profile > 8 bit HEVC output > > 2) 8 bit input > 10 bit up conversion > HEVC 10 bit profile > 10 bit > > HEVC output > > > > Better visual quality? Smaller compressed file size? > > In other words, what's the purpose of this feature except enabling new > > Video Codec SDK capability? > > Video Codecs tend to be more efficient with 10 bit, even if it's just 8 > bit content that's been up-converted to 10 bit. > I.e. yes, it'll (Or can, at least. Not sure if it's a given.) produce > smaller/higher quality content for the same input. > > As for the exact reason, I can't explain, but it's a well known concept. > ___ 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] [PATCH] libavcodec/cuviddec A53CC closed captions support added to cuviddec & nvenc
-- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-A53CC-support-added-to-nvcuvid-nvenc.patch Description: 0001-A53CC-support-added-to-nvcuvid-nvenc.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavfilter : cuda linkage changed for vf_scale_cuda & vf_thumbnail_cuda
Please find attached the patch that introduces structure to store CUDA function pointers to be used within scale & thumbnail filters. -- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-CUDA-linkage-changed-to-dynamic-loading-for-filters.patch Description: 0001-CUDA-linkage-changed-to-dynamic-loading-for-filters.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] nvcodec-headers: add cuCtxGetCurrent function
Hello, This patch adds cuCtxGetCurrent function to nvcodec-headers repo. Second patch of the group which adds FFmpeg option to use current CUDA context depends on this. 0001-Add-cuCtxGetCurrent-function.patch Description: Binary data ___ 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] [PATCH 2/2] libavutil/hwcontect_cuda: add option to use current CUDA context
Hello, This is the second patch of the group which adds the option to use CUDA context current to calling thread. It simplifies the usage of ffmpeg libraries in applications which rely on CUDA runtime API. Example: AVDictionary *opts = NULL; AVBufferRef *hwDeviceCtx; av_dict_set(&opts, "current_ctx", "1", 0); av_hwdevice_ctx_create(&hwDeviceCtx, type, NULL, opts, 0); 0001-libavutil-hwcontext_cuda-option-added-to-use-context.patch Description: Binary data ___ 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 2/2] libavutil/hwcontect_cuda: add option to use current CUDA context
Thanks for the swift reply Timo, you're right about versioning. However, I didn't find any existing CUDA API versioning macro unlike that for Video Codec SDK API. So I basically did the same thing as that in previous commit to nvcodec-headers which barely adds new function pointer... Anyway, I took the liberty and added same versioning to CUDA API as that for Video Codec SDK API. I picked CUDA API v. 11.4 for no particular reason, simply because nvcodec-headers doesn't use latest features and minimal required driver (530+) supports that CUDA version. Please LMK if there's another approach to CUDA API versioning I must follow. чт, 14 сент. 2023 г. в 13:00, Timo Rothenpieler : > This will either need updates to the ffnvcodec version checks in > configure, to ensure the new symbol always exists, or some kind of more > selective check to only build those parts of the code if the new > function is present. > > As it is now, this would fail all current builds. > ___ > 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". > -- -- С уважением, Роман Арзуманян. Главный разработчик по направлению видео аналитики. 0001-libavutil-hwcontext_cuda-option-added-to-use-context.patch Description: Binary data 0001-Add-cuCtxGetCurrent-function.patch Description: Binary data ___ 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 2/2] libavutil/hwcontect_cuda: add option to use current CUDA context
Got it, thanks. Please find the patches in attachment. Just for my own understanding - could you please explain how this magic works in the configure script? I mean this section: if ! disabled ffnvcodec; then ffnv_hdr_list="ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" check_pkg_config ffnvcodec "ffnvcodec >= 12.1.14.0" "$ffnv_hdr_list" "" || \ check_pkg_config ffnvcodec "ffnvcodec >= 12.0.16.0 ffnvcodec < 12.1" "$ffnv_hdr_list" "" || \ check_pkg_config ffnvcodec "ffnvcodec >= 11.1.5.2 ffnvcodec < 12.0" "$ffnv_hdr_list" "" || \ check_pkg_config ffnvcodec "ffnvcodec >= 11.0.10.2 ffnvcodec < 11.1" "$ffnv_hdr_list" "" || \ check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.14 ffnvcodec < 8.2" "$ffnv_hdr_list" "" fi To me it looks like any ffnvcodec package of version in range between 8.1.24.14 and 12.1.14.0 will pass this check. чт, 14 сент. 2023 г. в 18:04, Timo Rothenpieler : > On 14/09/2023 17:02, Roman Arzumanyan wrote: > > Hi Timo, > > > > > The usual approach is to rely on the ffnvcodec version. > > > Whenever you need a function from a specific version, bump the > > versions in configure to the current version from git master and all the > > respective old branches, since that will be the version of the next > release. > > > > Sorry, but I don't understand what to do. Could you please give me a > hand? > > There's ffnvcodec.pc.in <http://ffnvcodec.pc.in> file where I can bump > > the version from 12.1.14.0 to 12.1.14.1 > > Don't bump it. It gets bumped after every release. > Just set the versions in configure to the current version from the > various branches. > > > Then I see this check in ffmpeg/configure: > > > > if ! disabled ffnvcodec; then > > > > ffnv_hdr_list="ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h > > ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" > > > > check_pkg_config ffnvcodec "ffnvcodec >= 12.0.16.0" "$ffnv_hdr_list" "" > || \ > > > > check_pkg_config ffnvcodec "ffnvcodec >= 11.1.5.2 ffnvcodec < 12.0" > > "$ffnv_hdr_list" "" || \ > > > > check_pkg_config ffnvcodec "ffnvcodec >= 11.0.10.2 ffnvcodec < 11.1" > > "$ffnv_hdr_list" "" || \ > > > > check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.14 ffnvcodec < 8.2" > > "$ffnv_hdr_list" "" > > > > fi > > > > > > Under the hood it adds cflags detected by pkg-config via > > check_pkg_config function. But in the ffnvcodec.pc we don't export any > > extra cflags. > > > > Do I have to add extra flags to ffnvcodec.pc.in > > <http://ffnvcodec.pc.in>to define symbols containing the full > > ffnvcodecpackage version? > > > > Like NVENC_API_MAJOR_VERSIONand NVENC_API_MINORversion but for the whole > > ffnvcodec package? > > If configure depends on the latest versions, there is no need for > further checks. > -- -- С уважением, Роман Арзуманян. Главный разработчик по направлению видео аналитики. 0001-Add-cuCtxGetCurrent-function.patch Description: Binary data 0001-Option-added-to-use-current-CUDA-ctx.patch Description: Binary data ___ 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 2/2] libavutil/hwcontect_cuda: add option to use current CUDA context
Hello, Any updates on this patch? чт, 14 сент. 2023 г. в 19:52, Roman Arzumanyan : > Got it, thanks. > Please find the patches in attachment. > > Just for my own understanding - could you please explain how this magic > works in the configure script? I mean this section: > > if ! disabled ffnvcodec; then > > ffnv_hdr_list="ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h > ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" > > check_pkg_config ffnvcodec "ffnvcodec >= 12.1.14.0" "$ffnv_hdr_list" > "" || \ > > check_pkg_config ffnvcodec "ffnvcodec >= 12.0.16.0 ffnvcodec < > 12.1" "$ffnv_hdr_list" "" || \ > > check_pkg_config ffnvcodec "ffnvcodec >= 11.1.5.2 ffnvcodec < 12.0" > "$ffnv_hdr_list" "" || \ > > check_pkg_config ffnvcodec "ffnvcodec >= 11.0.10.2 ffnvcodec < > 11.1" "$ffnv_hdr_list" "" || \ > > check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.14 ffnvcodec < 8.2" > "$ffnv_hdr_list" "" > > fi > > > To me it looks like any ffnvcodec package of version in range between > 8.1.24.14 and 12.1.14.0 will pass this check. > > чт, 14 сент. 2023 г. в 18:04, Timo Rothenpieler : > >> On 14/09/2023 17:02, Roman Arzumanyan wrote: >> > Hi Timo, >> > >> > > The usual approach is to rely on the ffnvcodec version. >> > > Whenever you need a function from a specific version, bump the >> > versions in configure to the current version from git master and all >> the >> > respective old branches, since that will be the version of the next >> release. >> > >> > Sorry, but I don't understand what to do. Could you please give me a >> hand? >> > There's ffnvcodec.pc.in <http://ffnvcodec.pc.in> file where I can bump >> > the version from 12.1.14.0 to 12.1.14.1 >> >> Don't bump it. It gets bumped after every release. >> Just set the versions in configure to the current version from the >> various branches. >> >> > Then I see this check in ffmpeg/configure: >> > >> > if ! disabled ffnvcodec; then >> > >> > ffnv_hdr_list="ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h >> > ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" >> > >> > check_pkg_config ffnvcodec "ffnvcodec >= 12.0.16.0" "$ffnv_hdr_list" "" >> || \ >> > >> > check_pkg_config ffnvcodec "ffnvcodec >= 11.1.5.2 ffnvcodec < 12.0" >> > "$ffnv_hdr_list" "" || \ >> > >> > check_pkg_config ffnvcodec "ffnvcodec >= 11.0.10.2 ffnvcodec < 11.1" >> > "$ffnv_hdr_list" "" || \ >> > >> > check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.14 ffnvcodec < 8.2" >> > "$ffnv_hdr_list" "" >> > >> > fi >> > >> > >> > Under the hood it adds cflags detected by pkg-config via >> > check_pkg_config function. But in the ffnvcodec.pc we don't export any >> > extra cflags. >> > >> > Do I have to add extra flags to ffnvcodec.pc.in >> > <http://ffnvcodec.pc.in>to define symbols containing the full >> > ffnvcodecpackage version? >> > >> > Like NVENC_API_MAJOR_VERSIONand NVENC_API_MINORversion but for the >> whole >> > ffnvcodec package? >> >> If configure depends on the latest versions, there is no need for >> further checks. >> > > > -- > -- > С уважением, Роман Арзуманян. > Главный разработчик по направлению видео аналитики. > ___ 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] [PATCH] libavutil/hwcontext_cuda: fix bug in cuda_device_uninit
Hello, In my previous patch which introduced the AV_CUDA_USE_CURRENT_CONTEXT feature I unintentionally made a mistake of not checking this flag when uninitializing the CUDA. It was causing cuda_device_uninit() function to destroy the CUDA context it didn't create. So far it only reproduces under cuda compute sanitizer: = COMPUTE-SANITIZER = Program hit invalid device context (error 201) on CUDA API call to cuCtxDestroy_v2. But nonetheless shall be fixed. Please find a fix in attached file, now cuCtxDestroy is called under condition. 0001-libavutil-hwcontext_cuda-fix-cuda_device_uninit-when.patch Description: Binary data ___ 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] [PATCH] libavcodec/cuviddec AV1 decoding support for Ampere cards
Hello, This patch adds AV1 decoding support for av1_cuvid stand-alone decoder. It requires Ampere GPU. -- BR, Roman Arzumanyan 0001-AV1-nvcuvid-support.patch Description: 0001-AV1-nvcuvid-support.patch ___ 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] [PATCH] libavfilter/vf_colorrange_cuda: CUDA-accelerated video filter for MPEG and JPEG color range conversions
Hello,
This patch adds video filter which does color range conversion similar to
swscale scaling filter.
How to use it:
./ffmpeg \
-hwaccel cuda -hwaccel_output_format cuda \
-i /path/to/intput/file.mp4 \
-vf colorrange_cuda=range=mpeg \
-c:v h264_nvenc \
-y /path/to/output/file.mp4
From 2b15d8a609a12d97b1ba7500c7f8771b336e2fdf Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Sat, 10 Sep 2022 11:05:56 +0300
Subject: [PATCH] libavfilter/vf_colorrange_cuda CUDA-accelerated color range
conversion filter
---
configure | 2 +
libavfilter/Makefile | 3 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_colorrange_cuda.c | 432 ++
libavfilter/vf_colorrange_cuda.cu | 93 +++
5 files changed, 531 insertions(+)
create mode 100644 libavfilter/vf_colorrange_cuda.c
create mode 100644 libavfilter/vf_colorrange_cuda.cu
diff --git a/configure b/configure
index 9d6457d81b..e5f9738ad1 100755
--- a/configure
+++ b/configure
@@ -3155,6 +3155,8 @@ transpose_npp_filter_deps="ffnvcodec libnpp"
overlay_cuda_filter_deps="ffnvcodec"
overlay_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
sharpen_npp_filter_deps="ffnvcodec libnpp"
+colorrange_cuda_filter_deps="ffnvcodec"
+colorrange_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
amf_deps_any="libdl LoadLibrary"
nvenc_deps="ffnvcodec"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 30cc329fb6..784e154d81 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -230,6 +230,9 @@ OBJS-$(CONFIG_COLORMAP_FILTER) += vf_colormap.o
OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o colorspacedsp.o
OBJS-$(CONFIG_COLORTEMPERATURE_FILTER) += vf_colortemperature.o
+OBJS-$(CONFIG_COLORRANGE_CUDA_FILTER)+= vf_colorrange_cuda.o \
+vf_colorrange_cuda.ptx.o \
+cuda/load_helper.o
OBJS-$(CONFIG_CONVOLUTION_FILTER)+= vf_convolution.o
OBJS-$(CONFIG_CONVOLUTION_OPENCL_FILTER) += vf_convolution_opencl.o opencl.o \
opencl/convolution.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 5ebacfde27..5e9cbe57ec 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -213,6 +213,7 @@ extern const AVFilter ff_vf_colormap;
extern const AVFilter ff_vf_colormatrix;
extern const AVFilter ff_vf_colorspace;
extern const AVFilter ff_vf_colortemperature;
+extern const AVFilter ff_vf_colorrange_cuda;
extern const AVFilter ff_vf_convolution;
extern const AVFilter ff_vf_convolution_opencl;
extern const AVFilter ff_vf_convolve;
diff --git a/libavfilter/vf_colorrange_cuda.c b/libavfilter/vf_colorrange_cuda.c
new file mode 100644
index 00..949e7d3bbf
--- /dev/null
+++ b/libavfilter/vf_colorrange_cuda.c
@@ -0,0 +1,432 @@
+/*
+ * Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/cuda_check.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "scale_eval.h"
+#include "video.h"
+
+#include "cuda/load_helper.h"
+
+static const enum AVPixelFormat supported_formats[] = {
+AV_PIX_FMT_NV12,
+AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV444P,
+};
+
+#define DIV_UP
Re: [FFmpeg-devel] [PATCH] libavfilter/vf_colorrange_cuda: CUDA-accelerated video filter for MPEG and JPEG color range conversions
Thanks for the detailed review, Timo. Please find fixed patch in attachement. От: ffmpeg-devel от имени Timo Rothenpieler Отправлено: 10 сентября 2022 г. 16:16 Кому: FFmpeg development discussions and patches ; Roman Arzumanyan Копия: Yogender Gupta ; Sven Middelberg ; Hermann Held Тема: Re: [FFmpeg-devel] [PATCH] libavfilter/vf_colorrange_cuda: CUDA-accelerated video filter for MPEG and JPEG color range conversions External email: Use caution opening links or attachments On 10.09.2022 10:16, Roman Arzumanyan wrote: > From 2b15d8a609a12d97b1ba7500c7f8771b336e2fdf Mon Sep 17 00:00:00 2001 > From: Roman Arzumanyan > Date: Sat, 10 Sep 2022 11:05:56 +0300 > Subject: [PATCH] libavfilter/vf_colorrange_cuda CUDA-accelerated color range > conversion filter We could also call this colorspace_cuda, since it does overlap with what the colorspace software filter does, just not nearly to the same degree of feature-completeness. That's fine in my book though, and if someone cares enough, the other features of the colorspace filter can be added over time. > --- > configure | 2 + > libavfilter/Makefile | 3 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_colorrange_cuda.c | 432 ++ > libavfilter/vf_colorrange_cuda.cu | 93 +++ > 5 files changed, 531 insertions(+) > create mode 100644 libavfilter/vf_colorrange_cuda.c > create mode 100644 libavfilter/vf_colorrange_cuda.cu > > diff --git a/configure b/configure > index 9d6457d81b..e5f9738ad1 100755 > --- a/configure > +++ b/configure > @@ -3155,6 +3155,8 @@ transpose_npp_filter_deps="ffnvcodec libnpp" > overlay_cuda_filter_deps="ffnvcodec" > overlay_cuda_filter_deps_any="cuda_nvcc cuda_llvm" > sharpen_npp_filter_deps="ffnvcodec libnpp" > +colorrange_cuda_filter_deps="ffnvcodec" > +colorrange_cuda_filter_deps_any="cuda_nvcc cuda_llvm" Typically should be sorted in by alphapetical ordering. > amf_deps_any="libdl LoadLibrary" > nvenc_deps="ffnvcodec" > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index 30cc329fb6..784e154d81 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -230,6 +230,9 @@ OBJS-$(CONFIG_COLORMAP_FILTER) += > vf_colormap.o > OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o > OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o > colorspacedsp.o > OBJS-$(CONFIG_COLORTEMPERATURE_FILTER) += vf_colortemperature.o > +OBJS-$(CONFIG_COLORRANGE_CUDA_FILTER)+= vf_colorrange_cuda.o \ > +vf_colorrange_cuda.ptx.o \ > +cuda/load_helper.o Same here on alphabetical ordering, should be between colormatrix and colorspace. > OBJS-$(CONFIG_CONVOLUTION_FILTER)+= vf_convolution.o > OBJS-$(CONFIG_CONVOLUTION_OPENCL_FILTER) += vf_convolution_opencl.o > opencl.o \ > opencl/convolution.o > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c > index 5ebacfde27..5e9cbe57ec 100644 > --- a/libavfilter/allfilters.c > +++ b/libavfilter/allfilters.c > @@ -213,6 +213,7 @@ extern const AVFilter ff_vf_colormap; > extern const AVFilter ff_vf_colormatrix; > extern const AVFilter ff_vf_colorspace; > extern const AVFilter ff_vf_colortemperature; > +extern const AVFilter ff_vf_colorrange_cuda; > extern const AVFilter ff_vf_convolution; > extern const AVFilter ff_vf_convolution_opencl; > extern const AVFilter ff_vf_convolve; > diff --git a/libavfilter/vf_colorrange_cuda.c > b/libavfilter/vf_colorrange_cuda.c > new file mode 100644 > index 00..949e7d3bbf > --- /dev/null > +++ b/libavfilter/vf_colorrange_cuda.c > @@ -0,0 +1,432 @@ > +/* > + * Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved. > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED T
[FFmpeg-devel] [PATCH] avcodec/cuvidddec: Guess pixel format based on probed bit depth
Hello world,
This patch adds a pixel format guess based on probed bit depth.
With current FFMpeg ToT, when the cuvid codec is opened, input sw_pix_fmt
is AV_PIX_FMT_NV12 until the first frame is decoded. Even if input has 10
or 12 bit depth, the format will be NV12 for some time.
What's the need for this patch ?
Applications that rely on libavcodec will have a chance to calculate the
proper amount of vRAM required to store a reconstructed video frame before
decoding begins.
From ae80b12d10a4de4aa96a4670b72accbfc5a87631 Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Thu, 1 Aug 2024 16:35:22 +0300
Subject: [PATCH] Guess pixel format based on bit depth
---
libavcodec/cuviddec.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index f88ad75e88..2205b1536a 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -834,7 +834,7 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
int ret = 0;
enum AVPixelFormat pix_fmts[3] = { AV_PIX_FMT_CUDA,
- AV_PIX_FMT_NV12,
+ AV_PIX_FMT_NONE,
AV_PIX_FMT_NONE };
int probed_width = avctx->coded_width ? avctx->coded_width : 1280;
@@ -845,11 +845,26 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
if (probe_desc && probe_desc->nb_components)
probed_bit_depth = probe_desc->comp[0].depth;
+// Arbitrarily pick pixel format based on bit depth.
+switch (probed_bit_depth) {
+case 8:
+pix_fmts[1] = AV_PIX_FMT_NV12;
+break;
+case 10:
+pix_fmts[1] = AV_PIX_FMT_P010;
+break;
+case 12:
+pix_fmts[1] = AV_PIX_FMT_P012;
+break;
+default:
+break;
+}
+
ctx->pkt = avctx->internal->in_pkt;
// Accelerated transcoding scenarios with 'ffmpeg' require that the
// pix_fmt be set to AV_PIX_FMT_CUDA early. The sw_pix_fmt, and the
// pix_fmt for non-accelerated transcoding, do not need to be correct
-// but need to be set to something. We arbitrarily pick NV12.
+// but need to be set to something.
ret = ff_get_format(avctx, pix_fmts);
if (ret < 0) {
av_log(avctx, AV_LOG_ERROR, "ff_get_format failed: %d\n", ret);
--
2.34.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".
Re: [FFmpeg-devel] [PATCH] avcodec/cuvidddec: Guess pixel format based on probed bit depth
Hi Timo, > Why can't the application simply also look at the probed format? It's certainly possible, but in my opinion it makes sense to improve the codec behavior. All required information is already there, why not return the correct value ? > The 12 bit format should be AV_PIX_FMT_P016. > Also, might as well take probe_desc->log2_chroma_w/log2_chroma_h into account. > If they're 0, it's 444, and the formats change to AV_PIX_FMT_YUV444P(16). > Akin to the switch() on format->bit_depth_luma_minus8 in the probe function. Thanks, I'll fix and submit v.2 of the patch. чт, 1 авг. 2024 г. в 21:14, Timo Rothenpieler : > On 01.08.2024 15:54, Roman Arzumanyan wrote: > > Hello world, > > > > This patch adds a pixel format guess based on probed bit depth. > > With current FFMpeg ToT, when the cuvid codec is opened, input sw_pix_fmt > > is AV_PIX_FMT_NV12 until the first frame is decoded. Even if input has 10 > > or 12 bit depth, the format will be NV12 for some time. > > > > What's the need for this patch ? > > Applications that rely on libavcodec will have a chance to calculate the > > proper amount of vRAM required to store a reconstructed video frame > before > > decoding begins. > > The 12 bit format should be AV_PIX_FMT_P016. > Also, might as well take probe_desc->log2_chroma_w/log2_chroma_h into > account. > If they're 0, it's 444, and the formats change to AV_PIX_FMT_YUV444P(16). > Akin to the switch() on format->bit_depth_luma_minus8 in the probe > function. > > Patch looks fine on first glance, though relying on a rather arbitrary > second field there does not seem like a good idea to me. > Why can't the application simply also look at the probed format? > ___ > 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] [PATCH v2] avcodec/cuvidddec: Guess pixel format based on probed bit depth and chroma sampling
Hello world,
Please find v2 of the previous patch attached.
Both bit depth and chroma sampling (420 and 444 as supported by Nvdec) are
now taken into account when selecting sw_pix_fmt.
From a0c0c8497e75987ae771a466c9f0fce5c3ef106c Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Thu, 1 Aug 2024 16:35:22 +0300
Subject: [PATCH] Guess pixel format based on bit depth and chroma sampling:
---
libavcodec/cuviddec.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index f88ad75e88..a7185fecbf 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -834,22 +834,41 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
int ret = 0;
enum AVPixelFormat pix_fmts[3] = { AV_PIX_FMT_CUDA,
- AV_PIX_FMT_NV12,
+ AV_PIX_FMT_NONE,
AV_PIX_FMT_NONE };
int probed_width = avctx->coded_width ? avctx->coded_width : 1280;
int probed_height = avctx->coded_height ? avctx->coded_height : 720;
-int probed_bit_depth = 8;
+int probed_bit_depth = 8, is_yuv444 = 0;
const AVPixFmtDescriptor *probe_desc = av_pix_fmt_desc_get(avctx->pix_fmt);
if (probe_desc && probe_desc->nb_components)
probed_bit_depth = probe_desc->comp[0].depth;
+if (probe_desc && !probe_desc->log2_chroma_w && !probe_desc->log2_chroma_h)
+is_yuv444 = 1;
+
+// Pick pixel format based on bit depth and chroma sampling.
+// Only 420 and 444 sampling are supported by HW so far, no need to check for 422.
+switch (probed_bit_depth) {
+case 8:
+pix_fmts[1] = is_yuv444 ? AV_PIX_FMT_YUV444P : AV_PIX_FMT_NV12;
+break;
+case 10:
+pix_fmts[1] = is_yuv444 ? AV_PIX_FMT_YUV444P10 : AV_PIX_FMT_P010;
+break;
+case 12:
+pix_fmts[1] = is_yuv444 ? AV_PIX_FMT_YUV444P16 : AV_PIX_FMT_P016;
+break;
+default:
+break;
+}
+
ctx->pkt = avctx->internal->in_pkt;
// Accelerated transcoding scenarios with 'ffmpeg' require that the
// pix_fmt be set to AV_PIX_FMT_CUDA early. The sw_pix_fmt, and the
// pix_fmt for non-accelerated transcoding, do not need to be correct
-// but need to be set to something. We arbitrarily pick NV12.
+// but need to be set to something.
ret = ff_get_format(avctx, pix_fmts);
if (ret < 0) {
av_log(avctx, AV_LOG_ERROR, "ff_get_format failed: %d\n", ret);
--
2.34.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".
Re: [FFmpeg-devel] [PATCH v2] avcodec/cuvidddec: Guess pixel format based on probed bit depth and chroma sampling
Thanks a lot Timo ! Just for my own education: in my application I follow the usual sequence of API calls to init hw device context and open the codec. What's the right place to probe the input? I was under the impression that it's done within avformat_find_stream_info(). пт, 2 авг. 2024 г. в 16:57, Timo Rothenpieler : > On 02/08/2024 15:31, Roman Arzumanyan wrote: > > Hello world, > > > > Please find v2 of the previous patch attached. > > Both bit depth and chroma sampling (420 and 444 as supported by Nvdec) > are > > now taken into account when selecting sw_pix_fmt. > > It's actually AV_PIX_FMT_YUV444P16 for both 10 and 12 bit, due to how > the bits are aligned opposite to what ffmpeg expects in > AV_PIX_FMT_YUV444P10. > > No need to resend for that, will ammend locally. > ___ > 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] [PATCH] avcodec/nvenc: Video Codec SDK 10 features support
Hello, This patch adds Video Codec SDK 10 features support: * Presets and tuning info * Multipass encode modes * Low Delay Key Frame Scale 0001-Adding-SDK10-features-support.patch Description: 0001-Adding-SDK10-features-support.patch ___ 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] avcodec/nvenc: Video Codec SDK 10 features support
Hello, nice to meet you. >Wouldn't it make sense to transition from compile time version checks to >runtime checking? Video Codec SDK headers are not included into ffmpeg 'as is' but using the nvcodec-headers project instead. This is community-driven project which aims to work around the licensing policies. So we can't influence ffmpeg development too much and only supports it's development with patches. Changing compile-time checks with runtime checks is a big thing to do and in order to convince community to accept such changes we need to have very solid background. От: Soft Works Отправлено: 30 июня 2020 г. 17:35 Кому: FFmpeg development discussions and patches ; Roman Arzumanyan Копия: Yogender Gupta Тема: RE: [FFmpeg-devel] [PATCH] avcodec/nvenc: Video Codec SDK 10 features support External email: Use caution opening links or attachments > -Original Message- > From: ffmpeg-devel On Behalf Of > Roman Arzumanyan > Sent: Tuesday, June 30, 2020 4:08 PM > To: ffmpeg-devel@ffmpeg.org; timo > Cc: Yogender Gupta > Subject: [FFmpeg-devel] [PATCH] avcodec/nvenc: Video Codec SDK 10 > features support > > Hello, > > This patch adds Video Codec SDK 10 features support: > > * Presets and tuning info > * Multipass encode modes > * Low Delay Key Frame Scale Hi Roman, Yogender, great to see somebody from Nvidia here. I think it's been a while.. :-) I have a rather general question: Wouldn't it make sense to transition from compile time version checks to runtime checking? (like Intel does..) We're currently stuck at SDK 8.1 because otherwise it would break functionality for customers having devices for which no newer drivers are available. 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".
[FFmpeg-devel] [PATCH] avfilter: add sharpen_npp video filter
This patch adds simple sharpening filter which is accelerated by NPP. CLI
sample:
./ffmpeg \
-hwaccel cuda -hwaccel_output_format cuda \
-i ./input.mp4 \
-vf sharpen_npp \
-c:v hevc_nvenc \
-y ./output_sharp.mp4
From 0df6297bd3664beb05c813c5fc62852e61616fa9 Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Mon, 6 Sep 2021 14:26:27 +0300
Subject: [PATCH] sharpen_npp video filter added
---
configure| 5 +-
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_sharpen_npp.c | 530 +++
4 files changed, 535 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/vf_sharpen_npp.c
diff --git a/configure b/configure
index af410a9d11..e092cc8c67 100755
--- a/configure
+++ b/configure
@@ -3094,6 +3094,7 @@ thumbnail_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
transpose_npp_filter_deps="ffnvcodec libnpp"
overlay_cuda_filter_deps="ffnvcodec"
overlay_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
+sharpen_npp_filter_deps="ffnvcodec libnpp"
amf_deps_any="libdl LoadLibrary"
nvenc_deps="ffnvcodec"
@@ -6443,8 +6444,8 @@ enabled libmodplug&& require_pkg_config libmodplug libmodplug libmodplug
enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h lame_set_VBR_quality -lmp3lame $libm_extralibs
enabled libmysofa && { check_pkg_config libmysofa libmysofa mysofa.h mysofa_neighborhood_init_withstepdefine ||
require libmysofa mysofa.h mysofa_neighborhood_init_withstepdefine -lmysofa $zlib_extralibs; }
-enabled libnpp&& { check_lib libnpp npp.h nppGetLibVersion -lnppig -lnppicc -lnppc -lnppidei ||
- check_lib libnpp npp.h nppGetLibVersion -lnppi -lnppc -lnppidei ||
+enabled libnpp&& { check_lib libnpp npp.h nppGetLibVersion -lnppig -lnppicc -lnppc -lnppidei -lnppif ||
+ check_lib libnpp npp.h nppGetLibVersion -lnppi -lnppif -lnppc -lnppidei ||
die "ERROR: libnpp not found"; }
enabled libopencore_amrnb && require libopencore_amrnb opencore-amrnb/interf_dec.h Decoder_Interface_init -lopencore-amrnb
enabled libopencore_amrwb && require libopencore_amrwb opencore-amrwb/dec_if.h D_IF_init -lopencore-amrwb
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index af957a5ac0..330ddfe5d5 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -423,6 +423,7 @@ OBJS-$(CONFIG_SETRANGE_FILTER) += vf_setparams.o
OBJS-$(CONFIG_SETSAR_FILTER) += vf_aspect.o
OBJS-$(CONFIG_SETTB_FILTER) += settb.o
OBJS-$(CONFIG_SHARPNESS_VAAPI_FILTER)+= vf_misc_vaapi.o vaapi_vpp.o
+OBJS-$(CONFIG_SHARPEN_NPP_FILTER)+= vf_sharpen_npp.o
OBJS-$(CONFIG_SHEAR_FILTER) += vf_shear.o
OBJS-$(CONFIG_SHOWINFO_FILTER) += vf_showinfo.o
OBJS-$(CONFIG_SHOWPALETTE_FILTER)+= vf_showpalette.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 0c6b2347c8..e50e5f3b6a 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -404,6 +404,7 @@ extern const AVFilter ff_vf_setrange;
extern const AVFilter ff_vf_setsar;
extern const AVFilter ff_vf_settb;
extern const AVFilter ff_vf_sharpness_vaapi;
+extern const AVFilter ff_vf_sharpen_npp;
extern const AVFilter ff_vf_shear;
extern const AVFilter ff_vf_showinfo;
extern const AVFilter ff_vf_showpalette;
diff --git a/libavfilter/vf_sharpen_npp.c b/libavfilter/vf_sharpen_npp.c
new file mode 100644
index 00..85549c36d0
--- /dev/null
+++ b/libavfilter/vf_sharpen_npp.c
@@ -0,0 +1,530 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * NPP sharpen video filter
+ */
+
+#include
+#include
+#include
+#include
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/cuda_check.h"
+#include "libavutil/internal.h"
+#inc
[FFmpeg-devel] [PATCH] avfilter: add scale2ref_npp video filter
This patch adds scale2ref_npp video filter which is similar to scale2ref, but
accelerated by NPP. CLI sample:
./ffmpeg \
-hwaccel cuda -hwaccel_output_format cuda \
-i ./bbb_sunflower_1080p_30fps_normal.mp4 \
-i ./920px-Wilber-huge-alpha.png \
-filter_complex
"[0:v]scale_npp=format=yuv420p[v0];[1:v]hwupload_cuda[v1];[v1][v0]scale2ref_npp=w=oh*mdar:h=ih/4[foreg][backg];[backg][foreg]overlay_cuda=x=(main_w-overlay_w),scale_npp=w=1280:720[out]"
\
-map "[out]" -c:v h264_nvenc -y ./output_overlay.mp4
From 1aba9987ec2c5a78e593f836205ef56b806534a8 Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Mon, 6 Sep 2021 15:25:51 +0300
Subject: [PATCH] scale2ref_npp filter added
---
libavfilter/allfilters.c | 1 +
libavfilter/vf_scale_npp.c | 531 +++--
2 files changed, 509 insertions(+), 23 deletions(-)
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 0c6b2347c8..6a8ae5a99e 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -389,6 +389,7 @@ extern const AVFilter ff_vf_scale_qsv;
extern const AVFilter ff_vf_scale_vaapi;
extern const AVFilter ff_vf_scale_vulkan;
extern const AVFilter ff_vf_scale2ref;
+extern const AVFilter ff_vf_scale2ref_npp;
extern const AVFilter ff_vf_scdet;
extern const AVFilter ff_vf_scroll;
extern const AVFilter ff_vf_segment;
diff --git a/libavfilter/vf_scale_npp.c b/libavfilter/vf_scale_npp.c
index 3e25c2c95f..9fa04b40e6 100644
--- a/libavfilter/vf_scale_npp.c
+++ b/libavfilter/vf_scale_npp.c
@@ -32,7 +32,10 @@
#include "libavutil/cuda_check.h"
#include "libavutil/internal.h"
#include "libavutil/opt.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/eval.h"
#include "libavutil/pixdesc.h"
+#include "libswscale/swscale.h"
#include "avfilter.h"
#include "formats.h"
@@ -44,12 +47,13 @@
static const enum AVPixelFormat supported_formats[] = {
AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUVA420P,
AV_PIX_FMT_NV12,
AV_PIX_FMT_YUV444P,
};
-static const enum AVPixelFormat deinterleaved_formats[][2] = {
-{ AV_PIX_FMT_NV12, AV_PIX_FMT_YUV420P },
+static const enum AVPixelFormat deinterleaved_formats[][3] = {
+{ AV_PIX_FMT_NV12, AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUVA420P },
};
enum ScaleStage {
@@ -67,12 +71,74 @@ typedef struct NPPScaleStageContext {
struct {
int width;
int height;
-} planes_in[3], planes_out[3];
+} planes_in[4], planes_out[4];
AVBufferRef *frames_ctx;
AVFrame *frame;
} NPPScaleStageContext;
+static const char *const var_names[] = {
+"in_w", "iw",
+"in_h", "ih",
+"out_w", "ow",
+"out_h", "oh",
+"a",
+"sar",
+"dar",
+"hsub",
+"vsub",
+"ohsub",
+"ovsub",
+"n",
+"t",
+"pos",
+"main_w",
+"main_h",
+"main_a",
+"main_sar",
+"main_dar", "mdar",
+"main_hsub",
+"main_vsub",
+"main_n",
+"main_t",
+"main_pos",
+NULL
+};
+
+enum var_name {
+VAR_IN_W, VAR_IW,
+VAR_IN_H, VAR_IH,
+VAR_OUT_W, VAR_OW,
+VAR_OUT_H, VAR_OH,
+VAR_A,
+VAR_SAR,
+VAR_DAR,
+VAR_HSUB,
+VAR_VSUB,
+VAR_OHSUB,
+VAR_OVSUB,
+VAR_N,
+VAR_T,
+VAR_POS,
+VAR_S2R_MAIN_W,
+VAR_S2R_MAIN_H,
+VAR_S2R_MAIN_A,
+VAR_S2R_MAIN_SAR,
+VAR_S2R_MAIN_DAR, VAR_S2R_MDAR,
+VAR_S2R_MAIN_HSUB,
+VAR_S2R_MAIN_VSUB,
+VAR_S2R_MAIN_N,
+VAR_S2R_MAIN_T,
+VAR_S2R_MAIN_POS,
+VARS_NB
+};
+
+enum EvalMode {
+EVAL_MODE_INIT,
+EVAL_MODE_FRAME,
+EVAL_MODE_NB
+};
+
typedef struct NPPScaleContext {
const AVClass *class;
@@ -102,8 +168,33 @@ typedef struct NPPScaleContext {
int force_divisible_by;
int interp_algo;
+struct SwsContext *sws;
+struct SwsContext *isws[2];
+AVDictionary *opts;
+
+char *size_str;
+char *flags_str;
+
+int interlaced;
+
+int in_range;
+int out_range;
+
+AVExpr *w_pexpr;
+AVExpr *h_pexpr;
+
+double var_values[VARS_NB];
+double param[2];
+
+int eval_mode;
+
+unsigned int flags;
} NPPScaleContext;
+const AVFilter ff_vf_scale2ref_npp;
+
+static int config_props(AVFilterLink *outlink);
+
static int nppscale_init(AVFilterContext *ctx)
{
NPPScaleContext *s = ctx->priv;
@@ -131,6 +222,256 @@ static int nppscale_init(AVFilterContext *ctx)
return 0;
}
+static int check_exprs(AVFilterContext *ctx)
+{
+NPPScaleContext *scale = ctx->priv;
+unsigned vars_w[VARS_NB] = { 0 }, vars_h[VARS_NB] = { 0 };
+
+if (!scale->w_pexpr &&a
[FFmpeg-devel] [PATCH] avcodec/cuviddec: update amount of decoder surfaces from within sequence decode callback
Hello,
This patch reduces vRAM usage by cuvid decoder implementation.
The number of surfaces used for decoding is updated within the parser
sequence decode callback.
Also the "surfaces" AVDictionary option specific to cuvid was removed in
favor of "extra_hw_surfaces".
vRAM consumption was tested on various videos and savings are between 1%
for 360p resolution up to 21% for some 1080p H.264 videos.
Decoding performance was tested on various H.264 and H.265 videos in
different resolutions from 360p and higher, no performance penalty was
found.
From 32a1b016e88fa40b983318d4583750ef250a78d9 Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Thu, 1 Jun 2023 11:17:39 +0300
Subject: [PATCH] libavcodec/cuviddec: determine DPB size from within cuvid
parser
---
libavcodec/cuviddec.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 3d43bbd466..759ed49870 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -115,6 +115,12 @@ typedef struct CuvidParsedFrame
#define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, ctx->cudl, x)
+// NV recommends [2;4] range
+#define CUVID_MAX_DISPLAY_DELAY (4)
+
+// Actual DPB size will be determined by parser.
+#define CUVID_DEFAULT_NUM_SURFACES (CUVID_MAX_DISPLAY_DELAY + 1)
+
static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* format)
{
AVCodecContext *avctx = opaque;
@@ -309,6 +315,25 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form
return 0;
}
+if (ctx->nb_surfaces < format->min_num_decode_surfaces + 3)
+ctx->nb_surfaces = format->min_num_decode_surfaces + 3;
+
+if (avctx->extra_hw_frames > 0)
+ctx->nb_surfaces += avctx->extra_hw_frames;
+
+if (0 > av_fifo_realloc2(ctx->frame_queue, ctx->nb_surfaces * sizeof(CuvidParsedFrame))) {
+av_log(avctx, AV_LOG_ERROR, "Failed to recreate frame queue on video sequence callback\n");
+ctx->internal_error = AVERROR(EINVAL);
+return 0;
+}
+
+ctx->key_frame = av_realloc_array(ctx->key_frame, ctx->nb_surfaces, sizeof(int));
+if (!ctx->key_frame) {
+av_log(avctx, AV_LOG_ERROR, "Failed to recreate key frame queue on video sequence callback\n");
+ctx->internal_error = AVERROR(EINVAL);
+return 0;
+}
+
cuinfo.ulNumDecodeSurfaces = ctx->nb_surfaces;
cuinfo.ulNumOutputSurfaces = 1;
cuinfo.ulCreationFlags = cudaVideoCreate_PreferCUVID;
@@ -846,6 +871,7 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
goto error;
}
+ctx->nb_surfaces = CUVID_DEFAULT_NUM_SURFACES;
ctx->frame_queue = av_fifo_alloc2(ctx->nb_surfaces, sizeof(CuvidParsedFrame), 0);
if (!ctx->frame_queue) {
ret = AVERROR(ENOMEM);
@@ -993,7 +1019,7 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
}
ctx->cuparseinfo.ulMaxNumDecodeSurfaces = ctx->nb_surfaces;
-ctx->cuparseinfo.ulMaxDisplayDelay = (avctx->flags & AV_CODEC_FLAG_LOW_DELAY) ? 0 : 4;
+ctx->cuparseinfo.ulMaxDisplayDelay = (avctx->flags & AV_CODEC_FLAG_LOW_DELAY) ? 0 : CUVID_MAX_DISPLAY_DELAY;
ctx->cuparseinfo.pUserData = avctx;
ctx->cuparseinfo.pfnSequenceCallback = cuvid_handle_video_sequence;
ctx->cuparseinfo.pfnDecodePicture = cuvid_handle_picture_decode;
@@ -1097,7 +1123,6 @@ static const AVOption options[] = {
{ "bob", "Bob deinterlacing", 0, AV_OPT_TYPE_CONST, { .i64 = cudaVideoDeinterlaceMode_Bob }, 0, 0, VD, "deint" },
{ "adaptive", "Adaptive deinterlacing", 0, AV_OPT_TYPE_CONST, { .i64 = cudaVideoDeinterlaceMode_Adaptive }, 0, 0, VD, "deint" },
{ "gpu", "GPU to be used for decoding", OFFSET(cu_gpu), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD },
-{ "surfaces", "Maximum surfaces to be used for decoding", OFFSET(nb_surfaces), AV_OPT_TYPE_INT, { .i64 = 25 }, 0, INT_MAX, VD },
{ "drop_second_field", "Drop second field when deinterlacing", OFFSET(drop_second_field), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
{ "crop", "Crop (top)x(bottom)x(left)x(right)", OFFSET(crop_expr), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD },
{ "resize", "Resize (width)x(height)", OFFSET(resize_expr), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD },
--
2.34.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".
Re: [FFmpeg-devel] [PATCH] avcodec/cuviddec: update amount of decoder surfaces from within sequence decode callback
Thanks for the review, Anton. Please find the updated patch attached.
BTW - what do you mean by "you should also forward the actual error code"?
Within the cuvid_handle_video_sequence() function in case of error,
function still returns 0 and sets internal context error, so I kept
behavior intact. Do I miss something?
пн, 5 июн. 2023 г. в 13:19, Anton Khirnov :
> Quoting Roman Arzumanyan (2023-06-05 09:30:07)
> > Hello,
> >
> > This patch reduces vRAM usage by cuvid decoder implementation.
> > The number of surfaces used for decoding is updated within the parser
> > sequence decode callback.
> > Also the "surfaces" AVDictionary option specific to cuvid was removed in
> > favor of "extra_hw_surfaces".
>
> This can break existing workflows, you should deprecated the option
> instead and only remove it after some time has passed.
>
> >
> > vRAM consumption was tested on various videos and savings are between 1%
> > for 360p resolution up to 21% for some 1080p H.264 videos.
> > Decoding performance was tested on various H.264 and H.265 videos in
> > different resolutions from 360p and higher, no performance penalty was
> > found.
> >
> > From 32a1b016e88fa40b983318d4583750ef250a78d9 Mon Sep 17 00:00:00 2001
> > From: Roman Arzumanyan
> > Date: Thu, 1 Jun 2023 11:17:39 +0300
> > Subject: [PATCH] libavcodec/cuviddec: determine DPB size from within
> cuvid
> > parser
> >
> > ---
> > libavcodec/cuviddec.c | 29 +++--
> > 1 file changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
> > index 3d43bbd466..759ed49870 100644
> > --- a/libavcodec/cuviddec.c
> > +++ b/libavcodec/cuviddec.c
> > @@ -115,6 +115,12 @@ typedef struct CuvidParsedFrame
> >
> > #define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, ctx->cudl, x)
> >
> > +// NV recommends [2;4] range
> > +#define CUVID_MAX_DISPLAY_DELAY (4)
> > +
> > +// Actual DPB size will be determined by parser.
> > +#define CUVID_DEFAULT_NUM_SURFACES (CUVID_MAX_DISPLAY_DELAY + 1)
> > +
> > static int CUDAAPI cuvid_handle_video_sequence(void *opaque,
> CUVIDEOFORMAT* format)
> > {
> > AVCodecContext *avctx = opaque;
> > @@ -309,6 +315,25 @@ static int CUDAAPI cuvid_handle_video_sequence(void
> *opaque, CUVIDEOFORMAT* form
> > return 0;
> > }
> >
> > +if (ctx->nb_surfaces < format->min_num_decode_surfaces + 3)
> > +ctx->nb_surfaces = format->min_num_decode_surfaces + 3;
>
> FFMAX()
>
> > +
> > +if (avctx->extra_hw_frames > 0)
> > +ctx->nb_surfaces += avctx->extra_hw_frames;
> > +
> > +if (0 > av_fifo_realloc2(ctx->frame_queue, ctx->nb_surfaces *
> sizeof(CuvidParsedFrame))) {
>
> this is the old deprecated AVFifoBuffer API, you cannot use it with
> AVFifo objects
>
> you should also forward the actual error code
>
> > +av_log(avctx, AV_LOG_ERROR, "Failed to recreate frame queue on
> video sequence callback\n");
> > +ctx->internal_error = AVERROR(EINVAL);
> > +return 0;
> > +}
> > +
> > +ctx->key_frame = av_realloc_array(ctx->key_frame, ctx->nb_surfaces,
> sizeof(int));
> > +if (!ctx->key_frame) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to recreate key frame queue
> on video sequence callback\n");
> > +ctx->internal_error = AVERROR(EINVAL);
>
> Leaks key_frame on failure and should be ENOMEM.
>
> --
> Anton Khirnov
> ___
> 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".
>
From 4aeff36c9d79c046e726bcc18a311754ace5c47e Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Thu, 1 Jun 2023 11:17:39 +0300
Subject: [PATCH] libavcodec/cuviddec: determine amount of decoded surfaces
from within cuvid parser
---
libavcodec/cuviddec.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 3d43bbd466..ef25c1d470 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -115,6 +115,12 @@ typedef struct CuvidParsedFrame
#define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, ctx->cudl, x)
+// NV recommends [2;4] range
+#define CUVID_MAX_DISPLAY_DELAY (4)
+
+// Actual pool size will be determined by parser.
+
