Re: [FFmpeg-devel] [PATCH] lavc/vp9: set update_map to 0 when segmentation.enabled is 0
On Wed, 22 May 2024 11:10:31 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Wed, May 22, 2024 at 10:36 AM Hendrik Leppkes
> wrote:
>
> > On Thu, Feb 29, 2024 at 7:19 AM llyyr wrote:
> > >
> > > segmentation.update_map is never reset to 0 on a new frame, and
> > > retains the value from the previous frame. This bugs out a bunch
> > > of hwaccel drivers when segmentation.enabled is 0 but update_map
> > > isn't because they don't ignore values behind switches. We also
> > > do this for vp8* so this commit is just mirroring the vp8 logic.
> > >
> > > This fixes an issue with certain samples** that causes blocky
> > > artifacts with vaapi and d3d11va (as far as known hwaccel drivers
> > > go). Mesa worked around*** this by ignoring this field if
> > > segmentation.enabled is 0, but d3d11va still doesn't work.
> > >
> > > *
> > https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/vp8.c#l811
> >
> > > ** https://github.com/mpv-player/mpv/issues/13533
> > > ***
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816
> > >
> > > Signed-off-by: llyyr
> > > ---
> > > libavcodec/vp9.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > > index 855936cdc1c7..4a628625131e 100644
> > > --- a/libavcodec/vp9.c
> > > +++ b/libavcodec/vp9.c
> > > @@ -717,6 +717,8 @@ static int decode_frame_header(AVCodecContext
> > > *avctx, s->s.h.segmentation.feat[i].skip_enabled =
> > get_bits1(&s->gb);
> > > }
> > > }
> > > +} else {
> > > +s->s.h.segmentation.update_map = 0;
> > > }
> > >
> > > // set qmul[] based on Y/UV, AC/DC and segmentation Q idx
> > > deltas
> > >
> > > base-commit: d263fce2b209e86a5a1e8f1b6aa33430ecc2c187
> > > --
> >
> > Change LGTM.
> > I was debugging the same issue today, and found the same problem
> > with some hwaccels not properly ignoring update_map when
> > segmentation is disabled.
> >
> > Will apply soon if there are no further comments.
> >
>
> Is fine, please apply.
>
Another LGTM. We've been seeing this reported on the mpv side as well.
--phil
___
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] avformat/mov: avoid seeking back to 0 on HEVC open GOP files
On Tue, 14 May 2024 19:07:59 -0700
Philip Langdale via ffmpeg-devel wrote:
> On Wed, 15 May 2024 01:36:43 +0530
> llyyr.pub...@gmail.com wrote:
>
> > From: llyyr
> >
> > ab77b878f1 attempted to fix the issue of broken packets being sent
> > to the decoder by implementing logic that kept attempting to
> > PTS-step backwards until it reached a valid point, however applying
> > this heuristic meant that in files that had no valid points (such
> > as HEVC videos shot on iPhones), we'd seek back to sample 0 on
> > every seek attempt. This meant that files that were previously
> > seekable, albeit with some skipped frames, were not seekable at all
> > now.
> >
> > Relax this heuristic a bit by giving up on seeking to a valid point
> > if we've tried a different sample and we still don't have a valid
> > point to seek to. This may some frames to be skipped on seeking but
> > it's better than not being able to seek at all in such files.
> >
> > Fixes: ab77b878f1 ("avformat/mov: fix seeking with HEVC open GOP
> > files") Fixes: #10585
>
> LGTM.
>
> I know it's been a _long time_ since you first sent this; I'll push
> next week if there aren't any other comments.
>
Pushed. Thanks!
--phil
___
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] avformat/mov: avoid seeking back to 0 on HEVC open GOP files
On Wed, 15 May 2024 01:36:43 +0530
llyyr.pub...@gmail.com wrote:
> From: llyyr
>
> ab77b878f1 attempted to fix the issue of broken packets being sent to
> the decoder by implementing logic that kept attempting to PTS-step
> backwards until it reached a valid point, however applying this
> heuristic meant that in files that had no valid points (such as HEVC
> videos shot on iPhones), we'd seek back to sample 0 on every seek
> attempt. This meant that files that were previously seekable, albeit
> with some skipped frames, were not seekable at all now.
>
> Relax this heuristic a bit by giving up on seeking to a valid point if
> we've tried a different sample and we still don't have a valid point
> to seek to. This may some frames to be skipped on seeking but it's
> better than not being able to seek at all in such files.
>
> Fixes: ab77b878f1 ("avformat/mov: fix seeking with HEVC open GOP
> files") Fixes: #10585
> ---
> libavformat/mov.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index b3fa748f27e8..6174a04c3169 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -10133,7 +10133,7 @@ static int mov_seek_stream(AVFormatContext
> *s, AVStream *st, int64_t timestamp, {
> MOVStreamContext *sc = st->priv_data;
> FFStream *const sti = ffstream(st);
> -int sample, time_sample, ret;
> +int sample, time_sample, ret, next_ts, requested_sample;
> unsigned int i;
>
> // Here we consider timestamp to be PTS, hence try to offset it
> so that we @@ -10154,7 +10154,17 @@ static int
> mov_seek_stream(AVFormatContext *s, AVStream *st, int64_t timestamp,
> if (!sample || can_seek_to_key_sample(st, sample, timestamp))
> break;
> -timestamp -= FFMAX(sc->min_sample_duration, 1);
> +
> +next_ts = timestamp - FFMAX(sc->min_sample_duration, 1);
> +requested_sample = av_index_search_timestamp(st, next_ts,
> flags); +
> +// If we've reached a different sample trying to find a good
> pts to
> +// seek to, give up searching because we'll end up seeking
> back to
> +// sample 0 on every seek.
> +if (!can_seek_to_key_sample(st, requested_sample, next_ts)
> && sample != requested_sample)
> +break;
> +
> +timestamp = next_ts;
> }
>
> mov_current_sample_set(sc, sample);
LGTM.
I know it's been a _long time_ since you first sent this; I'll push next
week if there aren't any other comments.
--phil
___
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] configure: fix compilation with glslang 14
On Wed, 31 Jan 2024 17:34:08 +0100 (CET) Lynne wrote: > The configure check already had fallback for the previous version > of glslang, which had different requirements for flags. > This commit simply moves the flags needed for glslang 13 to the > fallback, while first trying to use new flags for glslang 14. > > This drops support for ~3 year old glslang versions, which > I'm not sure had the complete C API we're using anyway. > > Patch attached. > LGTM. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions
On Sat, 2 Dec 2023 23:02:36 +0100 Thomas Mundt wrote: > > LGTM, thanks. > I am going to squash the three commits and push. There's no real need to put each filter in a separate diff when the logical change is identical in all three. Thanks, --phil ___ 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] bwdif_vulkan: fix artifacts on vulkan decode images
On Sun, 29 Oct 2023 07:22:46 +0100 (CET) Lynne wrote: > Due to making the decode frames context use the coded size, the > filter started to display those artifacts as it reused the input > frame's size. > > Change it to instead output the real image size for images, not the > input. > > Patch attached. > LGTM. Thanks. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
On Fri, 27 Oct 2023 12:00:10 +0200
David Rosca wrote:
> This allows some optimizations in driver, such as not having to read
> back the data if write-only mapping is requested.
> ---
> v3: Fix another warning
>
> libavutil/hwcontext_vaapi.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 558fed94c6..86b0852c12 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext
> *hwfc, VAStatus vas;
> void *address = NULL;
> int err, i;
> +#if VA_CHECK_VERSION(1, 21, 0)
> +uint32_t vaflags = 0;
> +#endif
>
> surface_id = (VASurfaceID)(uintptr_t)src->data[3];
> av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
> @@ -882,7 +885,15 @@ static int vaapi_map_frame(AVHWFramesContext
> *hwfc, }
> }
>
> +#if VA_CHECK_VERSION(1, 21, 0)
> +if (flags & AV_HWFRAME_MAP_READ || !(flags &
> AV_HWFRAME_MAP_OVERWRITE))
> +vaflags |= VA_MAPBUFFER_FLAG_READ;
> +if (flags & AV_HWFRAME_MAP_WRITE)
> +vaflags |= VA_MAPBUFFER_FLAG_WRITE;
> +vas = vaMapBuffer2(hwctx->display, map->image.buf, &address,
> vaflags); +#else
> vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
> +#endif
> if (vas != VA_STATUS_SUCCESS) {
> av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface
> " "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
LGTM. Thanks.
--phil
___
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] avutil/hwcontext_vaapi: return ENOSYS for unsupported operation
On Fri, 27 Oct 2023 23:37:01 +0800
Zhao Zhili wrote:
> From: Zhao Zhili
>
> av_hwframe_transfer_data try with src_ctx first. If the operation
> failed with AVERROR(ENOSYS), it will try again with dst_ctx. Return
> AVERROR(EINVAL) makes the second step being skipped.
> ---
> libavutil/hwcontext_vaapi.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 558fed94c6..bb28bcf588 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -217,7 +217,7 @@ static int
> vaapi_get_image_format(AVHWDeviceContext *hwdev, return 0;
> }
> }
> -return AVERROR(EINVAL);
> +return AVERROR(ENOSYS);
> }
>
> static int vaapi_frames_get_constraints(AVHWDeviceContext *hwdev,
> @@ -805,19 +805,19 @@ static int vaapi_map_frame(AVHWFramesContext
> *hwfc,
> if (!ctx->derive_works && (flags & AV_HWFRAME_MAP_DIRECT)) {
> // Requested direct mapping but it is not possible.
> -return AVERROR(EINVAL);
> +return AVERROR(ENOSYS);
> }
> if (dst->format == AV_PIX_FMT_NONE)
> dst->format = hwfc->sw_format;
> if (dst->format != hwfc->sw_format && (flags &
> AV_HWFRAME_MAP_DIRECT)) { // Requested direct mapping but the formats
> do not match.
> -return AVERROR(EINVAL);
> +return AVERROR(ENOSYS);
> }
>
> err = vaapi_get_image_format(hwfc->device_ctx, dst->format,
> &image_format); if (err < 0) {
> // Requested format is not a valid output format.
> -return AVERROR(EINVAL);
> +return err;
> }
>
> map = av_malloc(sizeof(*map));
> @@ -992,7 +992,7 @@ static int vaapi_map_to_memory(AVHWFramesContext
> *hwfc, AVFrame *dst, if (dst->format != AV_PIX_FMT_NONE) {
> err = vaapi_get_image_format(hwfc->device_ctx, dst->format,
> NULL); if (err < 0)
> -return AVERROR(ENOSYS);
> +return err;
> }
>
> err = vaapi_map_frame(hwfc, dst, src, flags);
LGTM.
--phil
___
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 1/2] avutil/hwcontext_vulkan: cuda doesn't belong to valid_sw_formats
On Fri, 27 Oct 2023 23:37:00 +0800
Zhao Zhili wrote:
> From: Zhao Zhili
>
> Move it to transfer_get_formats.
> ---
> libavutil/hwcontext_vulkan.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/libavutil/hwcontext_vulkan.c
> b/libavutil/hwcontext_vulkan.c index 8dd40cb66f..8481427b42 100644
> --- a/libavutil/hwcontext_vulkan.c
> +++ b/libavutil/hwcontext_vulkan.c
> @@ -1664,11 +1664,6 @@ static int
> vulkan_frames_get_constraints(AVHWDeviceContext *ctx, NULL, NULL,
> NULL, NULL, 0, 0) >= 0; }
>
> -#if CONFIG_CUDA
> -if (p->dev_is_nvidia)
> -count++;
> -#endif
> -
> constraints->valid_sw_formats = av_malloc_array(count + 1,
> sizeof(enum
> AVPixelFormat)); if (!constraints->valid_sw_formats)
> @@ -1684,10 +1679,6 @@ static int
> vulkan_frames_get_constraints(AVHWDeviceContext *ctx, }
> }
>
> -#if CONFIG_CUDA
> -if (p->dev_is_nvidia)
> -constraints->valid_sw_formats[count++] = AV_PIX_FMT_CUDA;
> -#endif
> constraints->valid_sw_formats[count++] = AV_PIX_FMT_NONE;
>
> constraints->min_width = 1;
> @@ -2416,12 +2407,22 @@ static int
> vulkan_transfer_get_formats(AVHWFramesContext *hwfc, enum
> AVHWFrameTransferDirection dir, enum AVPixelFormat **formats)
> {
> -enum AVPixelFormat *fmts = av_malloc_array(2, sizeof(*fmts));
> +enum AVPixelFormat *fmts;
> +int n = 2;
> +
> +#if CONFIG_CUDA
> +n++;
> +#endif
> +fmts = av_malloc_array(n, sizeof(*fmts));
> if (!fmts)
> return AVERROR(ENOMEM);
>
> -fmts[0] = hwfc->sw_format;
> -fmts[1] = AV_PIX_FMT_NONE;
> +n = 0;
> +fmts[n++] = hwfc->sw_format;
> +#if CONFIG_CUDA
> +fmts[n++] = AV_PIX_FMT_CUDA;
> +#endif
> +fmts[n++] = AV_PIX_FMT_NONE;
>
> *formats = fmts;
> return 0;
LGTM. Thanks!
--phil
___
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] hwcontext_vulkan: add the VK_IMAGE_USAGE_SAMPLED_BIT bit to new images
On Thu, 5 Oct 2023 23:26:38 +0200 (CEST) Lynne wrote: > This fixes filtering on Nvidia. > > Patch attached. > Tested locally. Filtering works and vulkan validation passes. Ship it! --phil ___ 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] avfilter/scale_cuda: add support for rgb32/bgr32 conversions
As we are introducing two new formats and supporting conversions
between them, and also with the existing 0rgb32/0bgr32 formats, we get
a combinatorial explosion of kernels. I introduced a few new macros to
keep the things mostly managable.
The conversions are all simple, following existing patterns, with four
specific exceptions. When converting from 0rgb32/0bgr32 to rgb32/bgr32,
we need to ensure the alpha value is set to 1. In all other cases, it
can just be passed through, either to be used or ignored.
---
libavfilter/vf_scale_cuda.c | 2 +
libavfilter/vf_scale_cuda.cu | 151 ---
2 files changed, 122 insertions(+), 31 deletions(-)
diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index 1c99befec8..370cb1d9cd 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -51,6 +51,8 @@ static const enum AVPixelFormat supported_formats[] = {
AV_PIX_FMT_YUV444P16,
AV_PIX_FMT_0RGB32,
AV_PIX_FMT_0BGR32,
+AV_PIX_FMT_RGB32,
+AV_PIX_FMT_BGR32,
};
#define DIV_UP(a, b) ( ((a) + (b) - 1) / (b) )
diff --git a/libavfilter/vf_scale_cuda.cu b/libavfilter/vf_scale_cuda.cu
index c9c6cafdb6..de06ba9433 100644
--- a/libavfilter/vf_scale_cuda.cu
+++ b/libavfilter/vf_scale_cuda.cu
@@ -853,9 +853,67 @@ struct Convert_yuv444p16le_yuv444p16le
}
};
-// bgr0->X
-
-struct Convert_bgr0_bgr0
+#define DEF_CONVERT_IDENTITY(fmt1, fmt2)\
+\
+struct Convert_##fmt1##_##fmt2 \
+{ \
+static const int in_bit_depth = 8; \
+typedef uchar4 in_T;\
+typedef uchar in_T_uv; \
+typedef uchar4 out_T; \
+typedef uchar out_T_uv; \
+\
+DEF_F(Convert, out_T) \
+{ \
+DEFAULT_DST(0) = SUB_F(y, 0); \
+} \
+\
+DEF_F(Convert_uv, out_T_uv) \
+{ \
+} \
+}; \
+
+#define DEF_CONVERT_REORDER(fmt1, fmt2) \
+\
+struct Convert_##fmt1##_##fmt2 \
+{ \
+static const int in_bit_depth = 8; \
+typedef uchar4 in_T;\
+typedef uchar in_T_uv; \
+typedef uchar4 out_T; \
+typedef uchar out_T_uv; \
+\
+DEF_F(Convert, out_T) \
+{ \
+uchar4 res = SUB_F(y, 0); \
+DEFAULT_DST(0) = make_uchar4( \
+res.z, \
+res.y, \
+res.x, \
+res.w \
+); \
+} \
+\
+DEF_F(Convert_uv, out_T_uv) \
+{ \
+} \
+}; \
+
+#define DEF_CONVERT_RGB(fmt1, fmt2) \
+\
+DEF_CONVERT_IDENTITY(fmt1, fmt1)\
+DEF_CONVERT_REORDER (fmt1, fmt2)\
+DEF_CONVERT_REORDER (fmt2, fmt1)\
+DEF_CONVERT_IDENTITY(fmt2, fmt2)
+
+DEF_CONVERT_RGB(rgb0, bgr0)
+DEF_CONVERT_RGB(rgba, bgra)
+DEF_CONVERT_IDENTITY(rgba, rgb0)
+DEF_CONVERT_IDENTITY(bgra, bgr0)
+DEF_CONVERT_REORDER(rgba, bgr0)
+DEF_CONVERT_REORDER(bgra, rgb0)
+
+struct Convert_bgr0_bgra
{
static const int in_bit_depth = 8;
typedef uchar4 in_T;
@@ -865,7 +923,13 @@ struct Convert_bgr0_bgr0
DEF_F(Convert, out_T)
{
-DEFAULT_DST(0) = SUB_F(y, 0);
+uchar4 res = SUB_F(y, 0);
+DEFAULT_DST(0) = make_uchar4(
+res.x,
+res.y,
+res.z,
+1
+);
}
DEF_F(Convert_uv, out_T_uv)
@@ -873,7 +937,7 @@ struct Convert_bgr0_bgr0
}
};
-struct Convert_bgr0_rgb0
+struct Convert_bgr0_rgba
{
static const int in_bit_depth = 8;
typedef uchar4 in_T;
@@ -888,7 +952,7 @@ struct Convert_bgr0_rgb0
res.z,
res.y,
res.x,
-res.w
+1
);
}
@@ -897,9 +961,7 @@ struct Convert_bgr0_rgb0
}
};
-// rgb0->X
-
-struct Convert_rgb0_bgr0
+struct Convert_rgb0_bgra
{
static const int in_bit_depth = 8;
typedef uchar4 in_T;
@@ -914,7 +976,7 @@ struct Convert_rgb0_bgr0
res.z,
res.y,
res.x,
-res.w
+1
);
}
@@ -923,7 +985,7 @@ struct Convert_rgb0_bgr0
}
};
-struct Convert_rgb0_rgb0
+struct Convert_rgb0_rgba
{
static const int in_bit_depth =
[FFmpeg-devel] [PATCH] avfilter/scale_cuda: add support for rgb32/bgr32 conversions
As we are introducing two new formats and supporting conversions
between them, and also with the existing 0rgb32/0bgr32 formats, we get
a combinatorial explosion of kernels. I introduced a few new macros to
keep the things mostly managable.
The conversions are all simple, following existing patterns, with four
specific exceptions. When converting from 0rgb32/0bgr32 to rgb32/bgr32,
we need to ensure the alpha value is set to 1. In all other cases, it
can just be passed through, either to be used or ignored.
---
libavfilter/vf_scale_cuda.c | 2 +
libavfilter/vf_scale_cuda.cu | 175 ---
2 files changed, 146 insertions(+), 31 deletions(-)
diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index 1c99befec8..370cb1d9cd 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -51,6 +51,8 @@ static const enum AVPixelFormat supported_formats[] = {
AV_PIX_FMT_YUV444P16,
AV_PIX_FMT_0RGB32,
AV_PIX_FMT_0BGR32,
+AV_PIX_FMT_RGB32,
+AV_PIX_FMT_BGR32,
};
#define DIV_UP(a, b) ( ((a) + (b) - 1) / (b) )
diff --git a/libavfilter/vf_scale_cuda.cu b/libavfilter/vf_scale_cuda.cu
index c9c6cafdb6..c82649e84f 100644
--- a/libavfilter/vf_scale_cuda.cu
+++ b/libavfilter/vf_scale_cuda.cu
@@ -853,9 +853,67 @@ struct Convert_yuv444p16le_yuv444p16le
}
};
-// bgr0->X
-
-struct Convert_bgr0_bgr0
+#define DEF_CONVERT_IDENTITY(fmt1, fmt2)\
+\
+struct Convert_##fmt1##_##fmt2 \
+{ \
+static const int in_bit_depth = 8; \
+typedef uchar4 in_T;\
+typedef uchar in_T_uv; \
+typedef uchar4 out_T; \
+typedef uchar out_T_uv; \
+\
+DEF_F(Convert, out_T) \
+{ \
+DEFAULT_DST(0) = SUB_F(y, 0); \
+} \
+\
+DEF_F(Convert_uv, out_T_uv) \
+{ \
+} \
+}; \
+
+#define DEF_CONVERT_REORDER(fmt1, fmt2) \
+\
+struct Convert_##fmt1##_##fmt2 \
+{ \
+static const int in_bit_depth = 8; \
+typedef uchar4 in_T;\
+typedef uchar in_T_uv; \
+typedef uchar4 out_T; \
+typedef uchar out_T_uv; \
+\
+DEF_F(Convert, out_T) \
+{ \
+uchar4 res = SUB_F(y, 0); \
+DEFAULT_DST(0) = make_uchar4( \
+res.z, \
+res.y, \
+res.x, \
+res.w \
+); \
+} \
+\
+DEF_F(Convert_uv, out_T_uv) \
+{ \
+} \
+}; \
+
+#define DEF_CONVERT_RGB(fmt1, fmt2) \
+\
+DEF_CONVERT_IDENTITY(fmt1, fmt1)\
+DEF_CONVERT_REORDER (fmt1, fmt2)\
+DEF_CONVERT_REORDER (fmt2, fmt1)\
+DEF_CONVERT_IDENTITY(fmt2, fmt2)
+
+DEF_CONVERT_RGB(rgb0, bgr0)
+DEF_CONVERT_RGB(rgba, bgra)
+DEF_CONVERT_IDENTITY(rgba, rgb0)
+DEF_CONVERT_IDENTITY(bgra, bgr0)
+DEF_CONVERT_REORDER(rgba, bgr0)
+DEF_CONVERT_REORDER(bgra, rgb0)
+
+struct Convert_bgr0_bgra
{
static const int in_bit_depth = 8;
typedef uchar4 in_T;
@@ -865,7 +923,13 @@ struct Convert_bgr0_bgr0
DEF_F(Convert, out_T)
{
-DEFAULT_DST(0) = SUB_F(y, 0);
+uchar4 res = SUB_F(y, 0);
+DEFAULT_DST(0) = make_uchar4(
+res.x,
+res.y,
+res.z,
+1
+);
}
DEF_F(Convert_uv, out_T_uv)
@@ -873,7 +937,7 @@ struct Convert_bgr0_bgr0
}
};
-struct Convert_bgr0_rgb0
+struct Convert_bgr0_rgba
{
static const int in_bit_depth = 8;
typedef uchar4 in_T;
@@ -888,7 +952,7 @@ struct Convert_bgr0_rgb0
res.z,
res.y,
res.x,
-res.w
+1
);
}
@@ -897,9 +961,7 @@ struct Convert_bgr0_rgb0
}
};
-// rgb0->X
-
-struct Convert_rgb0_bgr0
+struct Convert_rgb0_bgra
{
static const int in_bit_depth = 8;
typedef uchar4 in_T;
@@ -914,7 +976,7 @@ struct Convert_rgb0_bgr0
res.z,
res.y,
res.x,
-res.w
+1
);
}
@@ -923,7 +985,7 @@ struct Convert_rgb0_bgr0
}
};
-struct Convert_rgb0_rgb0
+struct Convert_rgb0_rgba
{
static const int in_bit_depth =
Re: [FFmpeg-devel] [PATCH] lavu/hwcontext_cuda: declare support for argb/abgr/rgba/bgra
On Sat, 10 Jun 2023 19:59:35 -0700
Philip Langdale wrote:
> These are physically compatible formats and are potentially useful.
>
> Signed-off-by: Philip Langdale
> ---
> libavutil/hwcontext_cuda.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> index 5ae7711c94..22eb9f5513 100644
> --- a/libavutil/hwcontext_cuda.c
> +++ b/libavutil/hwcontext_cuda.c
> @@ -45,6 +45,10 @@ static const enum AVPixelFormat
> supported_formats[] = { AV_PIX_FMT_YUV444P16,
> AV_PIX_FMT_0RGB32,
> AV_PIX_FMT_0BGR32,
> +AV_PIX_FMT_ARGB,
> +AV_PIX_FMT_ABGR,
> +AV_PIX_FMT_RGBA,
> +AV_PIX_FMT_BGRA,
> #if CONFIG_VULKAN
> AV_PIX_FMT_VULKAN,
> #endif
After discussion with Timo, pushed as:
> @@ -45,6 +45,8 @@ static const enum AVPixelFormat supported_formats[]
> = { AV_PIX_FMT_YUV444P16,
> AV_PIX_FMT_0RGB32,
> AV_PIX_FMT_0BGR32,
> +AV_PIX_FMT_RGB32,
> +AV_PIX_FMT_BGR32,
> #if CONFIG_VULKAN
> AV_PIX_FMT_VULKAN,
> #endif
to fix that nvenc accepts RGB32 and BGR32 but the hwcontext does not.
RGB32 and BGR32 map to RGBA and BGRA on little-endian, so it achieves
the main result I was originally looking for as well.
--phil
___
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/vf_yadif_cuda: remove unnecessary private struct fields
On Wed, 14 Jun 2023 20:04:35 -0700 Philip Langdale wrote: > I'm not sure why I originally did this, but there's no good reason to > put pointers to the cuda context and stream in the priv struct. They > are directly available in the device context that is already being > stored there. > > Signed-off-by: Philip Langdale pushed. --phil ___ 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 v3] avfilter/vf_bwdif_cuda: CUDA accelerated bwdif deinterlacer
I've been sitting on this for 3 1/2 years now(!), and I finally got
around to fixing the loose ends and convincing myself that it was
correct. It follows the same basic structure as yadif_cuda, including
leaving out the edge handling, to avoid expensive branching.
Signed-off-by: Philip Langdale
---
configure| 2 +
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_bwdif_cuda.c | 375 +++
libavfilter/vf_bwdif_cuda.cu | 309 +
5 files changed, 689 insertions(+)
create mode 100644 libavfilter/vf_bwdif_cuda.c
create mode 100644 libavfilter/vf_bwdif_cuda.cu
diff --git a/configure b/configure
index 4ac7cc6c0b..db36177c7d 100755
--- a/configure
+++ b/configure
@@ -3695,6 +3695,8 @@ blend_vulkan_filter_deps="vulkan spirv_compiler"
boxblur_filter_deps="gpl"
boxblur_opencl_filter_deps="opencl gpl"
bs2b_filter_deps="libbs2b"
+bwdif_cuda_filter_deps="ffnvcodec"
+bwdif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
bwdif_vulkan_filter_deps="vulkan spirv_compiler"
chromaber_vulkan_filter_deps="vulkan spirv_compiler"
color_vulkan_filter_deps="vulkan spirv_compiler"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index ff149a3733..9b7813575a 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -213,6 +213,8 @@ OBJS-$(CONFIG_BOXBLUR_FILTER)+=
vf_boxblur.o boxblur.o
OBJS-$(CONFIG_BOXBLUR_OPENCL_FILTER) += vf_avgblur_opencl.o opencl.o \
opencl/avgblur.o boxblur.o
OBJS-$(CONFIG_BWDIF_FILTER) += vf_bwdif.o yadif_common.o
+OBJS-$(CONFIG_BWDIF_CUDA_FILTER) += vf_bwdif_cuda.o
vf_bwdif_cuda.ptx.o \
+yadif_common.o
OBJS-$(CONFIG_BWDIF_VULKAN_FILTER) += vf_bwdif_vulkan.o
yadif_common.o vulkan.o vulkan_filter.o
OBJS-$(CONFIG_CAS_FILTER)+= vf_cas.o
OBJS-$(CONFIG_CCREPACK_FILTER) += vf_ccrepack.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 6593e4eb83..9a7fadc58d 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -197,6 +197,7 @@ extern const AVFilter ff_vf_bm3d;
extern const AVFilter ff_vf_boxblur;
extern const AVFilter ff_vf_boxblur_opencl;
extern const AVFilter ff_vf_bwdif;
+extern const AVFilter ff_vf_bwdif_cuda;
extern const AVFilter ff_vf_bwdif_vulkan;
extern const AVFilter ff_vf_cas;
extern const AVFilter ff_vf_ccrepack;
diff --git a/libavfilter/vf_bwdif_cuda.c b/libavfilter/vf_bwdif_cuda.c
new file mode 100644
index 00..a5ecfbadb6
--- /dev/null
+++ b/libavfilter/vf_bwdif_cuda.c
@@ -0,0 +1,375 @@
+/*
+ * Copyright (C) 2019 Philip Langdale
+ *
+ * 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
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/cuda_check.h"
+#include "internal.h"
+#include "yadif.h"
+
+#include "cuda/load_helper.h"
+
+extern const unsigned char ff_vf_bwdif_cuda_ptx_data[];
+extern const unsigned int ff_vf_bwdif_cuda_ptx_len;
+
+typedef struct DeintCUDAContext {
+YADIFContext yadif;
+
+AVCUDADeviceContext *hwctx;
+AVBufferRef *device_ref;
+AVBufferRef *input_frames_ref;
+AVHWFramesContext *input_frames;
+
+CUmodulecu_module;
+CUfunction cu_func_uchar;
+CUfunction cu_func_uchar2;
+CUfunction cu_func_ushort;
+CUfunction cu_func_ushort2;
+} DeintCUDAContext;
+
+#define DIV_UP(a, b) ( ((a) + (b) - 1) / (b) )
+#define ALIGN_UP(a, b) (((a) + (b) - 1) & ~((b) - 1))
+#define BLOCKX 32
+#define BLOCKY 16
+
+#define CHECK_CU(x) FF_CUDA_CHECK_DL(ctx, s->hwctx->internal->cuda_dl, x)
+
+static CUresult call_kernel(AVFilterContext *ctx, CUfunction func,
+CUdeviceptr prev, CUdeviceptr cur, CUdeviceptr
next,
+CUarray_format format, int channels,
+int src_width, // Width is pixels per channel
+
[FFmpeg-devel] [PATCH] avfilter/vf_yadif_cuda: remove unnecessary private struct fields
I'm not sure why I originally did this, but there's no good reason to
put pointers to the cuda context and stream in the priv struct. They
are directly available in the device context that is already being
stored there.
Signed-off-by: Philip Langdale
---
libavfilter/vf_yadif_cuda.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/libavfilter/vf_yadif_cuda.c b/libavfilter/vf_yadif_cuda.c
index b5ff84e11a..d57e65 100644
--- a/libavfilter/vf_yadif_cuda.c
+++ b/libavfilter/vf_yadif_cuda.c
@@ -38,8 +38,6 @@ typedef struct DeintCUDAContext {
AVBufferRef *input_frames_ref;
AVHWFramesContext *input_frames;
-CUcontext cu_ctx;
-CUstreamstream;
CUmodulecu_module;
CUfunction cu_func_uchar;
CUfunction cu_func_uchar2;
@@ -109,7 +107,7 @@ static CUresult call_kernel(AVFilterContext *ctx,
CUfunction func,
ret = CHECK_CU(cu->cuLaunchKernel(func,
DIV_UP(dst_width, BLOCKX),
DIV_UP(dst_height, BLOCKY), 1,
BLOCKX, BLOCKY, 1,
- 0, s->stream, args, NULL));
+ 0, s->hwctx->stream, args, NULL));
exit:
if (tex_prev)
@@ -131,7 +129,7 @@ static void filter(AVFilterContext *ctx, AVFrame *dst,
CUcontext dummy;
int i, ret;
-ret = CHECK_CU(cu->cuCtxPushCurrent(s->cu_ctx));
+ret = CHECK_CU(cu->cuCtxPushCurrent(s->hwctx->cuda_ctx));
if (ret < 0)
return;
@@ -197,7 +195,7 @@ static av_cold void deint_cuda_uninit(AVFilterContext *ctx)
if (s->hwctx && s->cu_module) {
CudaFunctions *cu = s->hwctx->internal->cuda_dl;
-CHECK_CU(cu->cuCtxPushCurrent(s->cu_ctx));
+CHECK_CU(cu->cuCtxPushCurrent(s->hwctx->cuda_ctx));
CHECK_CU(cu->cuModuleUnload(s->cu_module));
CHECK_CU(cu->cuCtxPopCurrent(&dummy));
}
@@ -253,8 +251,6 @@ static int config_output(AVFilterLink *link)
return AVERROR(ENOMEM);
}
s->hwctx = ((AVHWDeviceContext*)s->device_ref->data)->hwctx;
-s->cu_ctx = s->hwctx->cuda_ctx;
-s->stream = s->hwctx->stream;
cu = s->hwctx->internal->cuda_dl;
link->hw_frames_ctx = av_hwframe_ctx_alloc(s->device_ref);
@@ -310,7 +306,7 @@ static int config_output(AVFilterLink *link)
y->csp = av_pix_fmt_desc_get(output_frames->sw_format);
y->filter = filter;
-ret = CHECK_CU(cu->cuCtxPushCurrent(s->cu_ctx));
+ret = CHECK_CU(cu->cuCtxPushCurrent(s->hwctx->cuda_ctx));
if (ret < 0)
goto exit;
--
2.39.2
___
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] lavu/hwcontext_cuda: declare support for argb/abgr/rgba/bgra
These are physically compatible formats and are potentially useful.
Signed-off-by: Philip Langdale
---
libavutil/hwcontext_cuda.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 5ae7711c94..22eb9f5513 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -45,6 +45,10 @@ static const enum AVPixelFormat supported_formats[] = {
AV_PIX_FMT_YUV444P16,
AV_PIX_FMT_0RGB32,
AV_PIX_FMT_0BGR32,
+AV_PIX_FMT_ARGB,
+AV_PIX_FMT_ABGR,
+AV_PIX_FMT_RGBA,
+AV_PIX_FMT_BGRA,
#if CONFIG_VULKAN
AV_PIX_FMT_VULKAN,
#endif
--
2.39.2
___
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] avfilter/vf_bwdif_cuda: CUDA accelerated bwdif deinterlacer
I've been sitting on this for 3 1/2 years now(!), and I finally got
around to fixing the loose ends and convincing myself that it was
correct. It follows the same basic structure as yadif_cuda, including
leaving out the edge handling, to avoid expensive branching.
Signed-off-by: Philip Langdale
---
configure| 2 +
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_bwdif_cuda.c | 379 +++
libavfilter/vf_bwdif_cuda.cu | 309
5 files changed, 693 insertions(+)
create mode 100644 libavfilter/vf_bwdif_cuda.c
create mode 100644 libavfilter/vf_bwdif_cuda.cu
diff --git a/configure b/configure
index 2fbe03921a..e6f766dbcf 100755
--- a/configure
+++ b/configure
@@ -3694,6 +3694,8 @@ blend_vulkan_filter_deps="vulkan spirv_compiler"
boxblur_filter_deps="gpl"
boxblur_opencl_filter_deps="opencl gpl"
bs2b_filter_deps="libbs2b"
+bwdif_cuda_filter_deps="ffnvcodec"
+bwdif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
bwdif_vulkan_filter_deps="vulkan spirv_compiler"
chromaber_vulkan_filter_deps="vulkan spirv_compiler"
color_vulkan_filter_deps="vulkan spirv_compiler"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index ff149a3733..9b7813575a 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -213,6 +213,8 @@ OBJS-$(CONFIG_BOXBLUR_FILTER)+=
vf_boxblur.o boxblur.o
OBJS-$(CONFIG_BOXBLUR_OPENCL_FILTER) += vf_avgblur_opencl.o opencl.o \
opencl/avgblur.o boxblur.o
OBJS-$(CONFIG_BWDIF_FILTER) += vf_bwdif.o yadif_common.o
+OBJS-$(CONFIG_BWDIF_CUDA_FILTER) += vf_bwdif_cuda.o
vf_bwdif_cuda.ptx.o \
+yadif_common.o
OBJS-$(CONFIG_BWDIF_VULKAN_FILTER) += vf_bwdif_vulkan.o
yadif_common.o vulkan.o vulkan_filter.o
OBJS-$(CONFIG_CAS_FILTER)+= vf_cas.o
OBJS-$(CONFIG_CCREPACK_FILTER) += vf_ccrepack.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 6593e4eb83..9a7fadc58d 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -197,6 +197,7 @@ extern const AVFilter ff_vf_bm3d;
extern const AVFilter ff_vf_boxblur;
extern const AVFilter ff_vf_boxblur_opencl;
extern const AVFilter ff_vf_bwdif;
+extern const AVFilter ff_vf_bwdif_cuda;
extern const AVFilter ff_vf_bwdif_vulkan;
extern const AVFilter ff_vf_cas;
extern const AVFilter ff_vf_ccrepack;
diff --git a/libavfilter/vf_bwdif_cuda.c b/libavfilter/vf_bwdif_cuda.c
new file mode 100644
index 00..4f5daf9a89
--- /dev/null
+++ b/libavfilter/vf_bwdif_cuda.c
@@ -0,0 +1,379 @@
+/*
+ * Copyright (C) 2019 Philip Langdale
+ *
+ * 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
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/cuda_check.h"
+#include "internal.h"
+#include "yadif.h"
+
+#include "cuda/load_helper.h"
+
+extern const unsigned char ff_vf_bwdif_cuda_ptx_data[];
+extern const unsigned int ff_vf_bwdif_cuda_ptx_len;
+
+typedef struct DeintCUDAContext {
+YADIFContext yadif;
+
+AVCUDADeviceContext *hwctx;
+AVBufferRef *device_ref;
+AVBufferRef *input_frames_ref;
+AVHWFramesContext *input_frames;
+
+CUcontext cu_ctx;
+CUstreamstream;
+CUmodulecu_module;
+CUfunction cu_func_uchar;
+CUfunction cu_func_uchar2;
+CUfunction cu_func_ushort;
+CUfunction cu_func_ushort2;
+} DeintCUDAContext;
+
+#define DIV_UP(a, b) ( ((a) + (b) - 1) / (b) )
+#define ALIGN_UP(a, b) (((a) + (b) - 1) & ~((b) - 1))
+#define BLOCKX 32
+#define BLOCKY 16
+
+#define CHECK_CU(x) FF_CUDA_CHECK_DL(ctx, s->hwctx->internal->cuda_dl, x)
+
+static CUresult call_kernel(AVFilterContext *ctx, CUfunction func,
+CUdeviceptr prev, CUdeviceptr cur, CUdeviceptr
next,
+CUarray_format format, int channels,
+int src_
Re: [FFmpeg-devel] [PATCH] avfilter/vf_bwdif: Remove undesireable spatial preference logic
On Sat, 25 Mar 2023 00:02:03 +0100
Thomas Mundt wrote:
> Hi Philip,
>
> Philip Langdale schrieb am Fr., 24. März 2023,
> 23:21:
>
> > bwdif inherited this check from yadif, which was originally
> > supposed to prefer the spatial predictor if the temporal predictor
> > was too far off.
> >
> > However, the core bwdif algorithm already accounts for the spatial
> > predictor, so this additional check actually ends up preferring a
> > worse value, reducing the overall quality.
> >
> > This was found by cyanreg while writing bwdif_vulkan, and the visual
> > improvement is pretty dramatic in some samples. If we agree that
> > this change is desirable, we should update all implementations.
> >
> > Signed-off-by: Philip Langdale
> > ---
> > libavfilter/vf_bwdif.c | 5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> > index 65c617ebb3..441bb11e7b 100644
> > --- a/libavfilter/vf_bwdif.c
> > +++ b/libavfilter/vf_bwdif.c
> > @@ -106,11 +106,6 @@ typedef struct ThreadData {
> > interpol = (c + e) >> 1;
> >
> > #define FILTER2() \
> > -if (interpol > d + diff) \
> > -interpol = d + diff; \
> > -else if (interpol < d - diff) \
> > -interpol = d - diff; \
> > - \
> >
>
> Removing this will make lower thirds and other graphic jump up and
> down each frame. It is the main improvement over w3fdif that I have
> ported from yadif.
> Can you provide samples including still graphics that are improved
> with this patch?
Hi Thomas,
Sorry for this thread going unanswered for so long. With the Vulkan
hwaccel stuff sorted out, I wanted to come back to this. I discussed
more with Lynne and we're no longer convinced this change is obviously
desirable. You are right about the jumping behaviour - and although
there are samples (eg: the burosch ones on samples.ffmpeg.org) which
look better with the change, I don't think that's something to over
index on.
Thanks,
--phil
___
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] vulkan: discard dependencies when explicitly waiting for execution
On Wed, 7 Jun 2023 01:23:24 +0200 (CEST)
Lynne wrote:
> From eb74297de8662c9fa66cd719c6315567966afe56 Mon Sep 17 00:00:00 2001
> From: Lynne
> Date: Wed, 7 Jun 2023 01:16:29 +0200
> Subject: [PATCH 2/2] vulkan: discard dependencies when explicitly
> waiting for execution
>
> This reduces memory needed dramatically, as unneeded resources
> can be immediately returned to the pool.
> Although waitforfences is threadsafe, we add a mutex wait around
> it, as the mutex fence in combination with waitforfences assures
> us that no other thread will reset the fence in the meanwhile
> whilst the mutex is locked. This allows is to call
> ff_vk_exec_discard_deps.
> ---
> libavutil/vulkan.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
> index 4b96c0c200..0cfe334db0 100644
> --- a/libavutil/vulkan.c
> +++ b/libavutil/vulkan.c
> @@ -480,7 +480,10 @@ FFVkExecContext *ff_vk_exec_get(FFVkExecPool
> *pool) void ff_vk_exec_wait(FFVulkanContext *s, FFVkExecContext *e)
> {
> FFVulkanFunctions *vk = &s->vkfn;
> +pthread_mutex_lock(&e->lock);
> vk->WaitForFences(s->hwctx->act_dev, 1, &e->fence, VK_TRUE,
> UINT64_MAX);
> +ff_vk_exec_discard_deps(s, e);
> +pthread_mutex_unlock(&e->lock);
> }
>
> int ff_vk_exec_start(FFVulkanContext *s, FFVkExecContext *e)
LGTM.
--phil
___
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 1/2] vulkan: synchronize access to execution pool fences
On Wed, 7 Jun 2023 01:59:55 +0200 (CEST) Lynne wrote: > Jun 7, 2023, 01:45 by d...@lynne.ee: > > > Jun 7, 2023, 01:22 by d...@lynne.ee: > > > >> vkResetFences is specified as being user-synchronized > >> (yet vkWaitFences, is not). > >> > >> Patch attached. > >> > > > > Stray change in vulkan_decode.c removed locally. > > > > Also removed the vkWaitForFences call during > the _start function from the mutex lock, as > it's safe to do so, and added a comment. > Ah, you updated the diff. This one is LGTM. --phil ___ 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 1/2] vulkan: synchronize access to execution pool fences
On Wed, 7 Jun 2023 01:22:25 +0200 (CEST)
Lynne wrote:
> From c79aa3ed01033f515cbb21251e83cb5bafdf83d7 Mon Sep 17 00:00:00 2001
> From: Lynne
> Date: Wed, 7 Jun 2023 00:24:43 +0200
> Subject: [PATCH 1/2] vulkan: synchronize access to execution pool
> fences
>
> vkResetFences is specified as being user-synchronized
> (yet vkWaitFences, is not).
> ---
> libavcodec/vulkan_decode.c | 2 +-
> libavutil/vulkan.c | 12 ++--
> libavutil/vulkan.h | 2 ++
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/vulkan_decode.c b/libavcodec/vulkan_decode.c
> index 889c67a15f..9e3ebf6770 100644
> --- a/libavcodec/vulkan_decode.c
> +++ b/libavcodec/vulkan_decode.c
> @@ -1106,7 +1106,7 @@ int ff_vk_decode_init(AVCodecContext *avctx)
>
> /* Create decode exec context.
> * 4 async contexts per thread seems like a good number. */
> -err = ff_vk_exec_pool_init(s, &qf_dec, &ctx->exec_pool,
> 4*avctx->thread_count,
> +err = ff_vk_exec_pool_init(s, &qf_dec, &ctx->exec_pool, 1,
> nb_q,
Comment is now out of date?
> VK_QUERY_TYPE_RESULT_STATUS_ONLY_KHR, 0,
> session_create.pVideoProfile); if (err < 0)
> diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
> index bc4466e6c9..4b96c0c200 100644
> --- a/libavutil/vulkan.c
> +++ b/libavutil/vulkan.c
> @@ -241,6 +241,7 @@ void ff_vk_exec_pool_free(FFVulkanContext *s,
> FFVkExecPool *pool) vk->WaitForFences(s->hwctx->act_dev, 1,
> &e->fence, VK_TRUE, UINT64_MAX); vk->DestroyFence(s->hwctx->act_dev,
> e->fence, s->hwctx->alloc); }
> +pthread_mutex_destroy(&e->lock);
>
> ff_vk_exec_discard_deps(s, e);
>
> @@ -379,12 +380,17 @@ int ff_vk_exec_pool_init(FFVulkanContext *s,
> FFVkQueueFamilyCtx *qf, /* Init contexts */
> for (int i = 0; i < pool->pool_size; i++) {
> FFVkExecContext *e = &pool->contexts[i];
> -
> -/* Fence */
> VkFenceCreateInfo fence_create = {
> .sType = VK_STRUCTURE_TYPE_FENCE_CREATE_INFO,
> .flags = VK_FENCE_CREATE_SIGNALED_BIT,
> };
> +
> +/* Mutex */
> +err = pthread_mutex_init(&e->lock, NULL);
> +if (err != 0)
> +return AVERROR(err);
> +
> +/* Fence */
> ret = vk->CreateFence(s->hwctx->act_dev, &fence_create,
> s->hwctx->alloc, &e->fence);
> if (ret != VK_SUCCESS) {
> @@ -489,8 +495,10 @@ int ff_vk_exec_start(FFVulkanContext *s,
> FFVkExecContext *e) };
>
> /* Create the fence and don't wait for it initially */
> +pthread_mutex_lock(&e->lock);
> vk->WaitForFences(s->hwctx->act_dev, 1, &e->fence, VK_TRUE,
> UINT64_MAX); vk->ResetFences(s->hwctx->act_dev, 1, &e->fence);
> +pthread_mutex_unlock(&e->lock);
If WaitForFences doesn't require synchronisation, would it be desirable
to call it outside the mutex locking?
Otherwise, LGTM.
--phil
___
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] hevcdec: remove redundant bits_used_for_short_term_rps field
On Tue, 6 Jun 2023 13:03:43 +0200 (CEST) Lynne wrote: > It was introduced for Vulkan, but it is equivalent to > short_term_ref_pic_set_size when !short_term_ref_pic_set_sps_flag, > and when !!short_term_ref_pic_set_sps_flag, Vulkan hardcodes a zero > anyway. > > 3-line patch attached. > LGTM --phil ___ 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: avutil/hwcontext_vulkan: disable multiplane when deriving from cuda
Today, cuda is not able to import multiplane images, and cuda requires
images to be imported whether you trying to import to cuda or export
from cuda (in the later case, the image is imported and then copied
into on the cuda side). So any interop between cuda and vulkan requires
that multiplane be disabled.
The existing option for this is not sufficient, because when deriving
devices it is not possible to specify any options.
And, it is necessary to derive the Vulkan device, because any pipeline
that involves uploading from cuda to vulkan and then back to cuda must
use the same cuda context on both sides, and the only way to propagate
the cuda context all the way through is to derive the device at each
stage.
ie:
-vf hwupload=derive_device=vulkan,,hwupload=derive_device=cuda
Signed-off-by: Philip Langdale
---
libavutil/hwcontext_vulkan.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index e8241638d9..ec084d94d7 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -1180,6 +1180,7 @@ static void vulkan_device_free(AVHWDeviceContext *ctx)
static int vulkan_device_create_internal(AVHWDeviceContext *ctx,
VulkanDeviceSelection *dev_select,
+ int disable_multiplane,
AVDictionary *opts, int flags)
{
int err = 0;
@@ -1335,9 +1336,15 @@ static int
vulkan_device_create_internal(AVHWDeviceContext *ctx,
if (opt_d)
p->use_linear_images = strtol(opt_d->value, NULL, 10);
-opt_d = av_dict_get(opts, "disable_multiplane", NULL, 0);
-if (opt_d)
-p->disable_multiplane = strtol(opt_d->value, NULL, 10);
+/*
+ * The disable_multiplane argument takes precedent over the option.
+ */
+p->disable_multiplane = disable_multiplane;
+if (!p->disable_multiplane) {
+opt_d = av_dict_get(opts, "disable_multiplane", NULL, 0);
+if (opt_d)
+p->disable_multiplane = strtol(opt_d->value, NULL, 10);
+}
hwctx->enabled_dev_extensions = dev_info.ppEnabledExtensionNames;
hwctx->nb_enabled_dev_extensions = dev_info.enabledExtensionCount;
@@ -1511,7 +1518,7 @@ static int vulkan_device_create(AVHWDeviceContext *ctx,
const char *device,
}
}
-return vulkan_device_create_internal(ctx, &dev_select, opts, flags);
+return vulkan_device_create_internal(ctx, &dev_select, 0, opts, flags);
}
static int vulkan_device_derive(AVHWDeviceContext *ctx,
@@ -1537,7 +1544,7 @@ static int vulkan_device_derive(AVHWDeviceContext *ctx,
if (strstr(vendor, "AMD"))
dev_select.vendor_id = 0x1002;
-return vulkan_device_create_internal(ctx, &dev_select, opts, flags);
+return vulkan_device_create_internal(ctx, &dev_select, 0, opts, flags);
}
#endif
#if CONFIG_LIBDRM
@@ -1570,7 +1577,7 @@ static int vulkan_device_derive(AVHWDeviceContext *ctx,
drmFreeDevice(&drm_dev_info);
-return vulkan_device_create_internal(ctx, &dev_select, opts, flags);
+return vulkan_device_create_internal(ctx, &dev_select, 0, opts, flags);
}
#endif
#if CONFIG_CUDA
@@ -1589,7 +1596,11 @@ static int vulkan_device_derive(AVHWDeviceContext *ctx,
dev_select.has_uuid = 1;
-return vulkan_device_create_internal(ctx, &dev_select, opts, flags);
+/*
+ * CUDA is not able to import multiplane images, so always derive a
+ * Vulkan device with multiplane disabled.
+ */
+return vulkan_device_create_internal(ctx, &dev_select, 1, opts, flags);
}
#endif
default:
--
2.39.2
___
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] avutil/hwcontext_vulkan: disable multiplane when deriving from cuda
Today, cuda is not able to import multiplane images, and cuda requires images to be imported whether you trying to import to cuda or export from cuda (in the later case, the image is imported and then copied into on the cuda side). So any interop between cuda and vulkan requires that multiplane be disabled. The existing option for this is not sufficient, because when deriving devices it is not possible to specify any options. And, it is necessary to derive the Vulkan device, because any pipeline that involves uploading from cuda to vulkan and then back to cuda must use the same cuda context on both sides, and the only way to propagate the cuda context all the way through is to derive the device at each stage. ie: -vf hwupload=derive_device=vulkan,,hwupload=derive_device=cuda Signed-off-by: Philip Langdale --- libavutil/hwcontext_vulkan.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c index e8241638d9..2c594317f9 100644 --- a/libavutil/hwcontext_vulkan.c +++ b/libavutil/hwcontext_vulkan.c @@ -1589,6 +1589,11 @@ static int vulkan_device_derive(AVHWDeviceContext *ctx, dev_select.has_uuid = 1; +/* + * CUDA is not able to import multiplane images, so always derive a + * Vulkan device with multiplane disabled. + */ +av_dict_set(&opts, "disable_multiplane", "1", 0); return vulkan_device_create_internal(ctx, &dev_select, opts, flags); } #endif -- 2.39.2 ___ 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] Web/Index: add post for new Vulkan decoding support
On Wed, 31 May 2023 19:55:19 +0200 (CEST) Lynne wrote: > + May 31st, 2023, Vulkan decoding > + > + Recently, Vulkan-powered decoding hardware acceleration code was > merged into the codebase. > + This is the first vendor-generic and platform-generic decode > acceleration API, enabling the > + same code to be used on multiple platforms, with very minimal > overhead. > + This is also the first multi-threaded hardware decoding API, and > our code makes full use of this, > + saturating all available decode engines the hardware exposes. > + > + > + Those wishing to test the code can consult our > + href="https://trac.ffmpeg.org/wiki/HWAccelIntro#Vulkan";>documentation > page. > + For those who would like to integrate FFmpeg's Vulkan code to > demux, parse, decode, and receive > + a VkImage to present or manipulate, documentation and examples > are available in our source tree. > + > + > + As this is also the first practical implementation of the > specifications, bugs may be present, > + particularly in drivers, and, although passing verification, the > implementation itself. > + > > Patch attached. > LGTM --phil ___ 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] vulkan_decode: do not align the image dimensions
On Mon, 29 May 2023 04:08:17 +0200 (CEST) Lynne wrote: > According to Dave Airlie: > > > but I think ignoring it should be fine, I can't see any > > other way to get the imaeg extents correct for other usage > > what width/height should be used for the images? > > the final presentable dimensions, or the coded dimensions? > > if you don't want noise I think the presentable dims > > the driver should round up the allocations internally, > > but if you are going to sample from the images then w/h have to be > > the bounds of the image you want > > since otherwise there's no way to stop the sampler from > > going outside the edges > Works fine on nvidia here. I agree with the logic - it doesn't seem reasonable to handle it the other way. --phil ___ 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] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg
On Wed, 08 Feb 2023 19:38:07 +0200 Rémi Denis-Courmont wrote: > Le keskiviikkona 8. helmikuuta 2023, 16.27.52 EET Devin Heitmueller a > écrit : > > On Wed, Feb 8, 2023 at 8:08 AM Jean-Baptiste Kempf > > wrote: > > > Do we really need those PIX_FMT in FFmpeg public API? > > > > Tiled formats are annoying, but not uncommon in popular embedded > > platforms (e.g. NXP iMX, TI Davinci). > > Uh, not to deny that, but tiled formats are in no way an embedded > thing, as you imply. They are also used by desktop GPUs. And that is > not really relevant, I would argue, to the discussion, either way. > > > Of course ffmpeg could choose > > to ignore them, but it would effectively prevent it from being used > > on those platforms (and it's pretty essential to use the hardware > > blocks to do any real video processing). > > Insofar as the format is *only* used by a single module, I don't see > the need to assign it a pixel format in libavutil. You could just as > well define a generic V4L format that would be used for all weird V4L > formats that nothing other than V4L code understands. > > Ditto tiled DRM pixel formats for that matter. And while V4L is maybe > not there yet, DRM has introduced format modifiers that anyway > preclude any simple enumeration. My point being, there needs to be a > way to further specify framework-specific formats outside of the > avutil pixel format list, in any case. > I never thought about it this way until you mentioned DRM but I think that's the key insight. If we want to take a leaf out of the DRM book (and wouldn't it be wonderful if these m2m decoders used DRM formats?), then this format would NV12 at the pix fmt layer with a modifier indicating the tiling pattern. When we interact with these kinds of formats in VAAPI, for example, VAAPI encapsulates the heavy lifting required to transfer to/from system memory successfully, and when we are doing everything on the GPU side, we pass the surface long with the modifier to whatever eventually consumes it (eg: Display with GL or Vulkan, or encoding). In none of these cases does ffmpeg code really need to care about the modifier. Maybe we've been thinking about these m2m formats the wrong way. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc: deprecate CrystalHD decoders
On Tue, 31 Jan 2023 13:17:56 +0100 Anton Khirnov wrote: > The hardware is old and not relevant today. The decoders also have > many special quirks and are effectively unmaintained. > --- > Philip confirmed on IRC that he no longer has the hardware for > maintaining this and does not believe it is relevant today. > --- > Changelog | 1 + > MAINTAINERS| 2 -- > configure | 4 +++- > libavcodec/crystalhd.c | 4 > libavcodec/version_major.h | 3 +++ > 5 files changed, 11 insertions(+), 3 deletions(-) Ack. Thanks for doing this. --phil ___ 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 0/2] Interpolation filter using nvidia OFFRUC Library
On Tue, 3 Jan 2023 02:39:19 +0300 Dennis Mungai wrote: > Related, > > If this were to be implemented in mpv, can libplacebo pick up this > feature spec as a filter in ffmpeg? Perhaps that would make such a > feature easier to merge down the line, instead of re-implementing it > directly in ffmpeg as an additional filter. > > Adding Niklaas to the thread. It doesn't make a difference. The licensing is fundamentally unusable for an open-source project (and there are engineers at nvidia who know this and wish they could write filters leveraging all their various capabilities). The only thing with any nuance is what level of `nonfree` a project is willing to have sitting in their repo. Most projects (including mpv and libplacebo) would say "none", because it's not worth the trouble. ffmpeg has gone back and forth on what exact critera have to be met to qualify as mergeable vs unmergeable nonfree. In the past we have accepted filters based around nvidia libraries with prohibitive licensing - see the libnpp based filters, but I don't think we have the appetite for that now. If we were to decide that this filter was ok on that basis, I'd merge it, but honestly, the usability benefit of it being in master is tiny vs all the other hoops you have to jump through. Anyway - punchline: it is not easier to get this kind of thing merged into other projects. --phil ___ 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] avfilter/vf_nvoffruc: Add filter for nvidia's Optical Flow FRUC library
The NvOFFRUC library provides a GPU accelerated interpolation feature based on nvidia's Optical Flow functionality. It's able to provide reasonably high quality realtime interpolation to increase the frame rate of a video stream - as opposed to vf_framerate that just does a linear blend or vf_minterpolate that is anything but realtime. As interesting as that sounds, there are a lot of limitations that mean this filter is mostly just a toy. 1. The licensing is useless. The library and header and distributed as part of the Optical Flow SDK which has a proprietary EULA, so anyone wanting to build the filter must obtain the SDK for both build and runtime and the resulting binaries will be nonfree and unredistributable. 2. The NvOFFRUC.h header doesn't even compile in pure C without modification. 3. The library can only handle NV12 and "ARGB" (which realy means any single plane, four channel, 8 bit format). This means it can't help with our inevitable future dominated by 10+ bit formats. 4. The pitch handling logic in the library is very inflexiable, and it assumes that for NV12, the UV plane is contiguous with the Y plane. This actually ends up making it incompatible with nvdec output for certain frame sizes. To avoid constantly fighting edge cases, I took the brute force approach and copy the input and output frames to/from CUarrays (which the library can accept) to give me a way to ensure the correct layout is used. 5. The library is stateful in an unhelpful way. It is called with one input frame, and one output buffer and always interpolates between the passed input frame and the frame from the previous call. This both requires special handling for the first frame, and also prevents generating more than one intermediate frame. If you want to do 3x or 4x etc interpolation, this approach doesn't work. So, again, I brute forced it by treating every interpolation as a new session - calling it twice with each input frame, even if the first frame happens to be the same as the last frame we called it with. This allows us to generate as many intermediate frames as we want, but it presumably consumes more GPU resources. 6. The library always creates a `NvOFFRUC` directory with an empty log file in it in $PWD. What a niusance. But with all those caveats and limitations, it does actually work. I was able to upsample a 24fps file to 144fps (my monitor limit) with respectable results. In some situations, it starts bogging down, and I'm not entirely sure where those limits are - certainly I can see it consuming a significant percentage of GPU resources for large scaling factors. The implementation here is heavily based on vf_framerate with the blending function ripped out and replaced by NvOFFRUC. That means we have all the nice properties in terms of being able to do non-integer scaling, and downsampling via interpolation as well. Is this mergeable? No - but it was an interesting exercise and maybe folks in narrow circumstances may find some genuine use from it. Signed-off-by: Philip Langdale --- configure | 7 +- libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_nvoffruc.c | 644 ++ 4 files changed, 650 insertions(+), 3 deletions(-) create mode 100644 libavfilter/vf_nvoffruc.c diff --git a/configure b/configure index 675dc84f56..6ea9f89f97 100755 --- a/configure +++ b/configure @@ -3691,6 +3691,7 @@ mptestsrc_filter_deps="gpl" negate_filter_deps="lut_filter" nlmeans_opencl_filter_deps="opencl" nnedi_filter_deps="gpl" +nvoffruc_filter_deps="ffnvcodec nonfree" ocr_filter_deps="libtesseract" ocv_filter_deps="libopencv" openclsrc_filter_deps="opencl" @@ -6450,9 +6451,9 @@ fi 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" "" + check_pkg_config ffnvcodec "ffnvcodec >= 11.1.5.3 ffnvcodec < 12.0" "$ffnv_hdr_list" "" || \ + check_pkg_config ffnvcodec "ffnvcodec >= 11.0.10.3 ffnvcodec < 11.1" "$ffnv_hdr_list" "" || \ + check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.15 ffnvcodec < 8.2" &qu
[FFmpeg-devel] [PATCH 0/2] Interpolation filter using nvidia OFFRUC Library
This filter implements frame rate down/upsampling using nvidia's Optical Flow FRUC (Frame Rate Up Conversion) library. It's neat because you get realtime interpolation with a decent level of quality. It's impractical because of licensing. I have no actual intention to merge this, as it doesn't even meet our bar for a nonfree filter, and given the EULA restrictions with the SDK, anyone who would want to use it can easily cherry-pick it into the build they have to anyway. But I figured I'd send it to list as a way of announcing that it exists. How nice would it be if nvidia had sane licensing on this stuff? I'll keep a branch at: https://github.com/philipl/FFmpeg/tree/fruc-me --phil Philip Langdale (2): lavu/hwcontext_cuda: declare support for argb/abgr/rgba/bgra avfilter/vf_nvoffruc: Add filter for nvidia's Optical Flow FRUC library configure | 7 +- libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_nvoffruc.c | 644 + libavutil/hwcontext_cuda.c | 4 + 5 files changed, 654 insertions(+), 3 deletions(-) create mode 100644 libavfilter/vf_nvoffruc.c -- 2.37.2 ___ 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 1/2] lavu/hwcontext_cuda: declare support for argb/abgr/rgba/bgra
These can be useful.
Signed-off-by: Philip Langdale
---
libavutil/hwcontext_cuda.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 5ae7711c94..22eb9f5513 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -45,6 +45,10 @@ static const enum AVPixelFormat supported_formats[] = {
AV_PIX_FMT_YUV444P16,
AV_PIX_FMT_0RGB32,
AV_PIX_FMT_0BGR32,
+AV_PIX_FMT_ARGB,
+AV_PIX_FMT_ABGR,
+AV_PIX_FMT_RGBA,
+AV_PIX_FMT_BGRA,
#if CONFIG_VULKAN
AV_PIX_FMT_VULKAN,
#endif
--
2.37.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/nvdec: make explicit copy of frames unless user requested otherwise
On Fri, 9 Dec 2022 15:16:17 +0100
Timo Rothenpieler wrote:
> ---
> libavcodec/nvdec.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index fbaedf0b6b..a477449d14 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavcodec/nvdec.c
> @@ -51,6 +51,8 @@ typedef struct NVDECDecoder {
>
> CudaFunctions *cudl;
> CuvidFunctions *cvdl;
> +
> +int unsafe_output;
> } NVDECDecoder;
>
> typedef struct NVDECFramePool {
> @@ -344,6 +346,8 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
> int cuvid_codec_type, cuvid_chroma_format, chroma_444;
> int ret = 0;
>
> +int unsafe_output = !!(avctx->hwaccel_flags &
> AV_HWACCEL_FLAG_UNSAFE_OUTPUT); +
> sw_desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> if (!sw_desc)
> return AVERROR_BUG;
> @@ -402,7 +406,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
> params.CodecType = cuvid_codec_type;
> params.ChromaFormat= cuvid_chroma_format;
> params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
> -params.ulNumOutputSurfaces = frames_ctx->initial_pool_size;
> +params.ulNumOutputSurfaces = unsafe_output ?
> frames_ctx->initial_pool_size : 1;
> ret = nvdec_decoder_create(&ctx->decoder_ref,
> frames_ctx->device_ref, ¶ms, avctx); if (ret < 0) {
> @@ -417,6 +421,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
> }
>
> decoder = (NVDECDecoder*)ctx->decoder_ref->data;
> +decoder->unsafe_output = unsafe_output;
> decoder->real_hw_frames_ref = real_hw_frames_ref;
> real_hw_frames_ref = NULL;
>
> @@ -554,7 +559,11 @@ copy_fail:
>
> finish:
> CHECK_CU(decoder->cudl->cuCtxPopCurrent(&dummy));
> -return ret;
> +
> +if (ret < 0 || decoder->unsafe_output)
> +return ret;
> +
> +return av_frame_make_writable(frame);
> }
>
> int ff_nvdec_start_frame(AVCodecContext *avctx, AVFrame *frame)
LGTM
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] lavc: add new unsafe_output hwaccel_flag
On Fri, 9 Dec 2022 15:16:16 +0100
Timo Rothenpieler wrote:
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 16
> libavcodec/options_table.h | 1 +
> libavcodec/version.h | 4 ++--
> 4 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index ab7ce15fae..328028f293 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
>
> API changes, most recent first:
>
> +2022-12-xx - xx - lavc 59.55.100 - avcodec.h
> + Add AV_HWACCEL_FLAG_UNSAFE_OUTPUT.
> +
> 2022-11-xx - xx - lavu 57.43.100 - tx.h
>Add AV_TX_FLOAT_DCT, AV_TX_DOUBLE_DCT and AV_TX_INT32_DCT.
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 3edd8e2636..0ac581d660 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2253,6 +2253,22 @@ typedef struct AVHWAccel {
> */
> #define AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH (1 << 2)
>
> +/**
> + * Some hardware decoders (namely nvdec) can either output direct
> decoder
> + * surfaces, or make an on-device copy and return said copy.
> + * There is a hard limit on how many decoder surfaces there can be,
> and it
> + * cannot be accurately guessed ahead of time.
> + * For some processing chains, this can be okay, but others will run
> into the
> + * limit and in turn produce very confusing errors that require fine
> tuning of
> + * more or less obscure options by the user, or in extreme cases
> cannot be
> + * resolved at all without inserting an avfilter that forces a copy.
> + *
> + * Thus, the hwaccel will by default make a copy for safety and
> resilience.
> + * If a users really wants to minimize the amount of copies, they
> can set this
> + * flag and ensure their processing chain does not exhaust the
> surface pool.
> + */
> +#define AV_HWACCEL_FLAG_UNSAFE_OUTPUT (1 << 3)
> +
> /**
> * @}
> */
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index cd02f5096f..7924ca6144 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -399,6 +399,7 @@ static const AVOption avcodec_options[] = {
> {"ignore_level", "ignore level even if the codec level used is
> unknown or higher than the maximum supported level reported by the
> hardware driver", 0, AV_OPT_TYPE_CONST, { .i64 =
> AV_HWACCEL_FLAG_IGNORE_LEVEL }, INT_MIN, INT_MAX, V | D,
> "hwaccel_flags" }, {"allow_high_depth", "allow to output YUV pixel
> formats with a different chroma sampling than 4:2:0 and/or other than
> 8 bits per component", 0, AV_OPT_TYPE_CONST, {.i64 =
> AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH }, INT_MIN, INT_MAX, V | D,
> "hwaccel_flags"}, {"allow_profile_mismatch", "attempt to decode
> anyway if HW accelerated decoder's supported profiles do not exactly
> match the stream", 0, AV_OPT_TYPE_CONST, {.i64 =
> AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH }, INT_MIN, INT_MAX, V | D,
> "hwaccel_flags"}, +{"unsafe_output", "allow potentially unsafe
> hwaccel frame output that might require special care to process
> successfully", 0, AV_OPT_TYPE_CONST, {.i64 =
> AV_HWACCEL_FLAG_UNSAFE_OUTPUT }, INT_MIN, INT_MAX, V | D,
> "hwaccel_flags"}, {"extra_hw_frames", "Number of extra hardware
> frames to allocate for the user", OFFSET(extra_hw_frames),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, V|D },
> {"discard_damaged_percentage", "Percentage of damaged samples to
> discard a frame", OFFSET(discard_damaged_percentage),
> AV_OPT_TYPE_INT, {.i64 = 95 }, 0, 100, V|D }, {NULL}, diff --git
> a/libavcodec/version.h b/libavcodec/version.h index
> 9e66920593..9f42f09f4e 100644 --- a/libavcodec/version.h +++
> b/libavcodec/version.h @@ -29,8 +29,8 @@ #include "version_major.h"
> -#define LIBAVCODEC_VERSION_MINOR 54 -#define
> LIBAVCODEC_VERSION_MICRO 101 +#define LIBAVCODEC_VERSION_MINOR 55
> +#define LIBAVCODEC_VERSION_MICRO 100 #define LIBAVCODEC_VERSION_INT
> AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \ LIBAVCODEC_VERSION_MINOR, \
LGTM
--phil
___
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] avcodec/nvdec: make explicit copy of frames unless user requested otherwise
On Mon, 5 Dec 2022 23:25:59 +0100
Timo Rothenpieler wrote:
> ---
> libavcodec/nvdec.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index fbaedf0b6b..76ee395734 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavcodec/nvdec.c
> @@ -51,6 +51,8 @@ typedef struct NVDECDecoder {
>
> CudaFunctions *cudl;
> CuvidFunctions *cvdl;
> +
> +int minimize_copies;
> } NVDECDecoder;
>
> typedef struct NVDECFramePool {
> @@ -344,6 +346,8 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
> int cuvid_codec_type, cuvid_chroma_format, chroma_444;
> int ret = 0;
>
> +int minimize_copies = !!(avctx->hwaccel_flags &
> AV_HWACCEL_FLAG_MINIMIZE_COPIES); +
> sw_desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> if (!sw_desc)
> return AVERROR_BUG;
> @@ -402,7 +406,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
> params.CodecType = cuvid_codec_type;
> params.ChromaFormat= cuvid_chroma_format;
> params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
> -params.ulNumOutputSurfaces = frames_ctx->initial_pool_size;
> +params.ulNumOutputSurfaces = minimize_copies ?
> frames_ctx->initial_pool_size : 1;
> ret = nvdec_decoder_create(&ctx->decoder_ref,
> frames_ctx->device_ref, ¶ms, avctx); if (ret < 0) {
> @@ -417,6 +421,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
> }
>
> decoder = (NVDECDecoder*)ctx->decoder_ref->data;
> +decoder->minimize_copies = minimize_copies;
> decoder->real_hw_frames_ref = real_hw_frames_ref;
> real_hw_frames_ref = NULL;
>
> @@ -554,7 +559,11 @@ copy_fail:
>
> finish:
> CHECK_CU(decoder->cudl->cuCtxPopCurrent(&dummy));
> -return ret;
> +
> +if (ret < 0 || decoder->minimize_copies)
> +return ret;
> +
> +return av_frame_make_writable(frame);
> }
>
> int ff_nvdec_start_frame(AVCodecContext *avctx, AVFrame *frame)
LGTM.
--phil
___
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 1/2] lavc: add new minimize_copies hwaccel_flag
On Mon, 5 Dec 2022 23:25:58 +0100
Timo Rothenpieler wrote:
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 11 +++
> libavcodec/options_table.h | 1 +
> libavcodec/version.h | 2 +-
> 4 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index ab7ce15fae..9c1f905a61 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
>
> API changes, most recent first:
>
> +2022-12-xx - xx - lavc 59.54.101 - avcodec.h
> + Add AV_HWACCEL_FLAG_MINIMIZE_COPIES.
> +
> 2022-11-xx - xx - lavu 57.43.100 - tx.h
>Add AV_TX_FLOAT_DCT, AV_TX_DOUBLE_DCT and AV_TX_INT32_DCT.
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 3edd8e2636..a72551bb5e 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2253,6 +2253,17 @@ typedef struct AVHWAccel {
> */
> #define AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH (1 << 2)
>
> +/**
> + * Hardware acceleration can have a limited number of direct output
> surfaces.
> + * For some processing chains, this can be okay, but others will run
> into the
> + * limit and in turn produce very confusing errors.
> + *
> + * Thus, the hwaccel will by default make a safety copy. If a users
> really
> + * wants to minimize the amount of copies, they can set this flag
> and ensure
> + * their chain does not exhaust the surface pool.
> + */
> +#define AV_HWACCEL_FLAG_MINIMIZE_COPIES (1 << 3)
I would soften the statement about making a safety copy to make it
clear that only hwaccels where limits are relevant will make safety
copies. Otherwise people will think every other hwaccel has suddenly
started doing it.
Otherwise, LGTM.
--phil
___
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] lavu/pixdesc: handle xv30be in av_[read|write]_image_line
xv30be is an obnoxious format that I shouldn't have included in the
first place. xv30 packs 3 10bit channels into 32bits and while our
byte-oriented logic can handle Little Endian correctly, it cannot
handle Big Endian. To avoid that, I marked xv30be as a bitstream
format, but while that didn't produce FATE errors, it turns out that
the existing read/write code silently produces incorrect results, which
can be revealed via ubsan.
In all likelyhood, the correct fix here is to remove the format. As
this format is only used by Intel vaapi, it's only going to show up
in LE form, so we could just drop the BE version. But I don't want to
deal with creating a hole in the pixfmt list and all the weirdness that
comes from that. Instead, I decided to write the correct read/write
code for it.
And that code isn't too bad, as long as it's specialised for this
format, as the channels are all bit-aligned inside a 32bit word.
Signed-off-by: Philip Langdale
---
libavutil/pixdesc.c | 70 -
1 file changed, 50 insertions(+), 20 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index ca3e204a0b..62a2ae08d9 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -46,19 +46,35 @@ void av_read_image_line2(void *dst,
uint32_t *dst32 = dst;
if (flags & AV_PIX_FMT_FLAG_BITSTREAM) {
-int skip = x * step + comp.offset;
-const uint8_t *p = data[plane] + y * linesize[plane] + (skip >> 3);
-int shift = 8 - depth - (skip & 7);
+if (depth == 10) {
+// Assume all channels are packed into a 32bit value
+const uint8_t *byte_p = data[plane] + y * linesize[plane];
+const uint32_t *p = (uint32_t *)byte_p;
-while (w--) {
-int val = (*p >> shift) & mask;
-if (read_pal_component)
-val = data[1][4*val + c];
-shift -= step;
-p -= shift >> 3;
-shift &= 7;
-if (dst_element_size == 4) *dst32++ = val;
-else *dst16++ = val;
+while (w--) {
+int val = AV_RB32(p);
+val = (val >> comp.offset) & mask;
+if (read_pal_component)
+val = data[1][4*val + c];
+if (dst_element_size == 4) *dst32++ = val;
+else *dst16++ = val;
+p++;
+}
+} else {
+int skip = x * step + comp.offset;
+const uint8_t *p = data[plane] + y * linesize[plane] + (skip >> 3);
+int shift = 8 - depth - (skip & 7);
+
+while (w--) {
+int val = (*p >> shift) & mask;
+if (read_pal_component)
+val = data[1][4*val + c];
+shift -= step;
+p -= shift >> 3;
+shift &= 7;
+if (dst_element_size == 4) *dst32++ = val;
+else *dst16++ = val;
+}
}
} else {
const uint8_t *p = data[plane] + y * linesize[plane] +
@@ -109,15 +125,29 @@ void av_write_image_line2(const void *src,
const uint16_t *src16 = src;
if (flags & AV_PIX_FMT_FLAG_BITSTREAM) {
-int skip = x * step + comp.offset;
-uint8_t *p = data[plane] + y * linesize[plane] + (skip >> 3);
-int shift = 8 - depth - (skip & 7);
+if (depth == 10) {
+// Assume all channels are packed into a 32bit value
+const uint8_t *byte_p = data[plane] + y * linesize[plane];
+uint32_t *p = (uint32_t *)byte_p;
+int offset = comp.offset;
+uint32_t mask = ((1ULL << depth) - 1) << offset;
-while (w--) {
-*p |= (src_element_size == 4 ? *src32++ : *src16++) << shift;
-shift -= step;
-p -= shift >> 3;
-shift &= 7;
+while (w--) {
+uint16_t val = src_element_size == 4 ? *src32++ : *src16++;
+AV_WB32(p, (AV_RB32(p) & ~mask) | (val << offset));
+p++;
+}
+} else {
+int skip = x * step + comp.offset;
+uint8_t *p = data[plane] + y * linesize[plane] + (skip >> 3);
+int shift = 8 - depth - (skip & 7);
+
+while (w--) {
+*p |= (src_element_size == 4 ? *src32++ : *src16++) << shift;
+shift -= step;
+p -= shift >> 3;
+shift &= 7;
+}
}
} else {
int shift = comp.shift;
--
2.37.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avcodec/nvenc: add AV1 encoding support
On Fri, 4 Nov 2022 12:40:16 +0100 Timo Rothenpieler wrote: > The encoder seems to be trading blows with hevc_nvenc. > In terms of quality at low bitrate cbr settings, it seems to > outperform it even. It produces fewer artifacts and the ones it > does produce are less jarring to my perception. > > At higher bitrates I had a hard time finding differences between > the two encoders in terms of subjective visual quality. > > Using the 'slow' preset, av1_nvenc outperformed hevc_nvenc in terms > of encoding speed by 75% to 100% while performing above tests. > > Needless to say, it always massively outperformed h264_nvenc in terms > of quality for a given bitrate, while also being slightly faster. Obviously not able to test, but looks reasonable to me. --phil ___ 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] configure: add pkg-config check for OpenAL
On Sat, 29 Oct 2022 19:12:44 +0200
Timo Rothenpieler wrote:
> ---
> configure | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 70c9e41dcc..30f0ce4e26 100755
> --- a/configure
> +++ b/configure
> @@ -6757,7 +6757,8 @@ enabled mmal && { check_lib mmal
> interface/mmal/mmal.h mmal_port_co check_lib mmal
> interface/mmal/mmal.h mmal_port_connect -lmmal_core -lmmal_util
> -lmmal_vc_client -lbcm_host; } || die "ERROR: mmal not found" &&
> check_func_headers interface/mmal/mmal.h
> "MMAL_PARAMETER_VIDEO_MAX_NUM_CALLBACKS"; } -enabled openal
> && { { for al_extralibs in "${OPENAL_LIBS}" "-lopenal" "-lOpenAL32";
> do +enabled openal&& { check_pkg_config openal "openal >=
> 1.1" "AL/al.h" alGetError ||
> + { for al_extralibs in
> "${OPENAL_LIBS}" "-lopenal" "-lOpenAL32"; do check_lib openal
> 'AL/al.h' alGetError "${al_extralibs}" && break; done } || die
> "ERROR: openal not found"; } && { test_cpp_condition "AL/al.h"
> "defined(AL_VERSION_1_1)" ||
LGTM
--phil
___
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 3/8] avcodec/nvdec_mjpeg: Remove always-true #if CONFIG_MJPEG_NVDEC_HWACCEL
On Tue, 18 Oct 2022 15:31:21 +0200
Andreas Rheinhardt wrote:
> This file is built iff said hwaccel is enabled.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/nvdec_mjpeg.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/libavcodec/nvdec_mjpeg.c b/libavcodec/nvdec_mjpeg.c
> index 87f7a99a46..fce464c1f8 100644
> --- a/libavcodec/nvdec_mjpeg.c
> +++ b/libavcodec/nvdec_mjpeg.c
> @@ -20,8 +20,6 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA */
>
> -#include "config_components.h"
> -
> #include "avcodec.h"
> #include "internal.h"
> #include "mjpegdec.h"
> @@ -71,7 +69,6 @@ static int nvdec_mjpeg_frame_params(AVCodecContext
> *avctx, return ff_nvdec_frame_params(avctx, hw_frames_ctx, 1, 0);
> }
>
> -#if CONFIG_MJPEG_NVDEC_HWACCEL
> AVHWAccel ff_mjpeg_nvdec_hwaccel = {
> .name = "mjpeg_nvdec",
> .type = AVMEDIA_TYPE_VIDEO,
> @@ -85,4 +82,3 @@ AVHWAccel ff_mjpeg_nvdec_hwaccel = {
> .uninit = ff_nvdec_decode_uninit,
> .priv_data_size = sizeof(NVDECContext),
> };
> -#endif
LGTM.
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] lavu/pixdesc: favour formats where depth and subsampling exactly match
On Sat, 17 Sep 2022 21:13:37 +0200 Michael Niedermayer wrote: > > --- > > libavutil/pixdesc.c | 31 +++- > > libavutil/pixdesc.h | 15 ++-- > > libavutil/tests/pixfmt_best.c | 129 > > +- tests/ref/fate/pixfmt_best| > > 2 +- 4 files changed, 150 insertions(+), 27 deletions(-) > > should be ok > > thx > Thanks! I justed posted a v5 which has the updated fate reference but no functional changes. Will push that one. --phil ___ 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 v5] lavu/pixdesc: favour formats where depth and subsampling exactly match
Since introducing the various packed formats used by VAAPI (and p012),
we've noticed that there's actually a gap in how
av_find_best_pix_fmt_of_2 works. It doesn't actually assign any value
to having the same bit depth as the source format, when comparing
against formats with a higher bit depth. This usually doesn't matter,
because av_get_padded_bits_per_pixel() will account for it.
However, as many of these formats use padding internally, we find that
av_get_padded_bits_per_pixel() actually returns the same value for the
10 bit, 12 bit, 16 bit flavours, etc. In these tied situations, we end
up just picking the first of the two provided formats, even if the
second one should be preferred because it matches the actual bit depth.
This bug already existed if you tried to compare yuv420p10 against p016
and p010, for example, but it simply hadn't come up before so we never
noticed.
But now, we actually got a situation in the VAAPI VP9 decoder where it
offers both p010 and p012 because Profile 3 could be either depth and
ends up picking p012 for 10 bit content due to the ordering of the
testing.
In addition, in the process of testing the fix, I realised we have the
same gap when it comes to chroma subsampling - we do not favour a
format that has exactly the same subsampling vs one with less
subsampling when all else is equal.
To fix this, I'm introducing a small score penalty if the bit depth or
subsampling doesn't exactly match the source format. This will break
the tie in favour of the format with the exact match, but not offset
any of the other scoring penalties we already have.
I have added a set of tests around these formats which will fail
without this fix.
v2: Rework penalty system to scale penalty based on how different the
two formats are, and add new loss categories for them.
v3: Remove leftover bits of v1.
Remove bit depth penalty scaling to avoid the value being too large
in extreme cases (1 bit vs 16 bit).
v4: Reduce subsampling penalty to avoid situations where a loss of
bit dpeth will have a smaller penalty than having greater than
needed chroma resolution.
v5: Update fate reference.
Signed-off-by: Philip Langdale
---
libavutil/pixdesc.c | 31 +++-
libavutil/pixdesc.h | 15 ++--
libavutil/tests/pixfmt_best.c | 129 +-
tests/ref/fate/pixfmt_best| 2 +-
4 files changed, 150 insertions(+), 27 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index d7c6ebfdc4..b472a94f60 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -3013,9 +3013,16 @@ static int get_pix_fmt_score(enum AVPixelFormat
dst_pix_fmt,
for (i = 0; i < nb_components; i++) {
int depth_minus1 = (dst_pix_fmt == AV_PIX_FMT_PAL8) ? 7/nb_components
: (dst_desc->comp[i].depth - 1);
-if (src_desc->comp[i].depth - 1 > depth_minus1 && (consider &
FF_LOSS_DEPTH)) {
+int depth_delta = src_desc->comp[i].depth - 1 - depth_minus1;
+if (depth_delta > 0 && (consider & FF_LOSS_DEPTH)) {
loss |= FF_LOSS_DEPTH;
score -= 65536 >> depth_minus1;
+} else if (depth_delta < 0 && (consider & FF_LOSS_EXCESS_DEPTH)) {
+// Favour formats where bit depth exactly matches. If all other
+// scoring is equal, we'd rather use the bit depth that most
closely
+// matches the source.
+loss |= FF_LOSS_EXCESS_DEPTH;
+score += depth_delta;
}
}
@@ -3035,6 +3042,28 @@ static int get_pix_fmt_score(enum AVPixelFormat
dst_pix_fmt,
}
}
+if (consider & FF_LOSS_EXCESS_RESOLUTION) {
+// Favour formats where chroma subsampling exactly matches. If all
other
+// scoring is equal, we'd rather use the subsampling that most closely
+// matches the source.
+if (dst_desc->log2_chroma_w < src_desc->log2_chroma_w) {
+loss |= FF_LOSS_EXCESS_RESOLUTION;
+score -= 1 << (src_desc->log2_chroma_w - dst_desc->log2_chroma_w);
+}
+
+if (dst_desc->log2_chroma_h < src_desc->log2_chroma_h) {
+loss |= FF_LOSS_EXCESS_RESOLUTION;
+score -= 1 << (src_desc->log2_chroma_h - dst_desc->log2_chroma_h);
+}
+
+// don't favour 411 over 420, because 420 has much better support on
the
+// decoder side.
+if (dst_desc->log2_chroma_w == 1 && src_desc->log2_chroma_w == 2 &&
+dst_desc->log2_chroma_h == 1 && src_desc->log2_chroma_h == 2) {
+score += 4;
+}
+}
+
if(consider & FF_LOSS_COLORSPACE)
switch(dst_color) {
case FF_COLOR_RGB:
diff --git a/libavutil/pixdesc.h b/libavutil/pixdesc.h
index f8a195ffcd..48d9300bfe 100644
--- a/libavutil/pi
Re: [FFmpeg-devel] [PATCH v2] avfilter: compress CUDA PTX code if possible
On Fri, 18 Jun 2021 23:07:58 +0200
Timo Rothenpieler wrote:
> >> +
> >> +if (inflateInit2(&stream, 32 + 15) != Z_OK) {
> >
> > Can you add a comment explaining the magic numbers?
>
> I have no idea what those numbers do, I copied them from http.c and
> they work.
Heh.
So, I read this: https://www.zlib.net/manual.html
> windowBits can also be greater than 15 for optional gzip decoding.
> Add 32 to windowBits to enable zlib and gzip decoding with automatic
> header detection, or add 16 to decode only the gzip format (the zlib
> format will return a Z_DATA_ERROR). If a gzip stream is being
> decoded, strm->adler is a CRC-32 instead of an Adler-32. Unlike the
> gunzip utility and gzread() (see below), inflate() will not
> automatically decode concatenated gzip streams. inflate() will return
> Z_STREAM_END at the end of the gzip stream. The state would need to
> be reset to continue decoding a subsequent gzip stream.
I think that means it is necessary to pass '32 + 15' although you might
do '32 + 16' because you know that the files were really gzipped.
--phil
___
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 format_cuda filter
On Fri, 11 Jun 2021 16:43:07 +0200 Timo Rothenpieler wrote: > --- > configure | 2 + > doc/filters.texi| 46 ++ > libavfilter/Makefile| 1 + > libavfilter/allfilters.c| 1 + > libavfilter/cuda/vector_helpers.cuh | 14 +- > libavfilter/version.h | 2 +- > libavfilter/vf_format_cuda.c| 433 ++ > libavfilter/vf_format_cuda.cu | 849 > 8 files changed, 1345 insertions(+), 3 > deletions(-) create mode 100644 libavfilter/vf_format_cuda.c > create mode 100644 libavfilter/vf_format_cuda.cu LGTM. I agree it's better to get it in and then iterate on adding on additional formats. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter: compress CUDA PTX code if possible
On Sat, 12 Jun 2021 18:47:50 +0200
Timo Rothenpieler wrote:
> ---
> .gitignore | 1 +
> compat/cuda/ptx2c.sh| 34
> configure | 17 ++
> ffbuild/.gitignore | 1 +
> ffbuild/bin2c.c | 76 ++
> ffbuild/common.mak | 28 --
> libavfilter/Makefile| 14 +++--
> libavfilter/cuda/load_helper.c | 96
> + libavfilter/cuda/load_helper.h |
> 28 ++ libavfilter/vf_format_cuda.c| 7 ++-
> libavfilter/vf_overlay_cuda.c | 8 +--
> libavfilter/vf_scale_cuda.c | 24 ++---
> libavfilter/vf_thumbnail_cuda.c | 7 ++-
> libavfilter/vf_yadif_cuda.c | 7 ++-
> 14 files changed, 287 insertions(+), 61 deletions(-)
> delete mode 100755 compat/cuda/ptx2c.sh
> create mode 100644 ffbuild/bin2c.c
> create mode 100644 libavfilter/cuda/load_helper.c
> create mode 100644 libavfilter/cuda/load_helper.h
I just had comments about one file:
> diff --git a/libavfilter/cuda/load_helper.c
> b/libavfilter/cuda/load_helper.c new file mode 100644
> index 00..62d644c29a
> --- /dev/null
> +++ b/libavfilter/cuda/load_helper.c
> @@ -0,0 +1,96 @@
> +/*
> + * 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
> + */
> +
> +#include "config.h"
> +
> +#include "libavutil/hwcontext.h"
> +#include "libavutil/hwcontext_cuda_internal.h"
> +#include "libavutil/cuda_check.h"
> +
> +#if CONFIG_PTX_COMPRESSION
> +#include
> +#define CHUNK_SIZE 1024 * 64
> +#endif
> +
> +#include "load_helper.h"
> +
> +#define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, cu, x)
> +
> +int ff_cuda_load_module(void *avctx, AVCUDADeviceContext *hwctx,
> CUmodule *cu_module,
> +const unsigned char *data, const unsigned
> int length) +{
> +CudaFunctions *cu = hwctx->internal->cuda_dl;
> +
> +#if CONFIG_PTX_COMPRESSION
> +z_stream stream = { 0 };
> +uint8_t *buf, *tmp;
> +uint64_t buf_size;
> +int ret;
> +
> +if (inflateInit2(&stream, 32 + 15) != Z_OK) {
Can you add a comment explaining the magic numbers?
> +av_log(avctx, AV_LOG_ERROR, "Error during zlib
> initialisation: %s\n", stream.msg);
> +return AVERROR(ENOSYS);
> +}
> +
> +buf_size = CHUNK_SIZE * 4;
> +buf = av_realloc(NULL, buf_size);
> +if (!buf) {
> +inflateEnd(&stream);
> +return AVERROR(ENOMEM);
> +}
> +
> +stream.next_in = data;
> +stream.avail_in = length;
> +
> +do {
> +stream.avail_out = buf_size - stream.total_out;
> +stream.next_out = buf + stream.total_out;
> +
> +ret = inflate(&stream, Z_FINISH);
> +if (ret != Z_OK && ret != Z_STREAM_END) {
> +av_log(avctx, AV_LOG_ERROR, "zlib inflate error: %s\n",
> stream.msg);
> +inflateEnd(&stream);
> +av_free(buf);
> +return AVERROR(EINVAL);
> +}
> +
> +if (stream.avail_out == 0) {
> +buf_size += CHUNK_SIZE;
> +tmp = av_realloc(buf, buf_size);
> +if (!tmp) {
> +inflateEnd(&stream);
> +av_free(buf);
> +return AVERROR(ENOMEM);
> +}
> +buf = tmp;
> +}
> +} while (ret != Z_STREAM_END);
> +
> +// NULL-terminate string
> +// there is guaranteed to be space for this, due to condition in
> loop
This is because it will still grow the buffer if avail_out is zero at
the time you hit Z_STREAM_END?
> +buf[stream.total_out] = 0;
> +
> +inflateEnd(&stream);
> +
> +ret = CHECK_CU(cu->cuModuleLoadData(cu_module, buf));
> +av_free(buf);
> +return ret;
> +#else
> +return CHECK_CU(cu->cuModuleLoadData(cu_module, data));
> +#endif
> +}
Otherwise, LGTM.
Thanks,
--phil
___
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 1/2] avcodec/movtextenc: Check for too many styles
On Tue, 23 Feb 2021 12:16:53 +0100
Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
> > The counter for the number of styles is written on two bytes, ergo
> > anything > UINT16_MAX is invalid. This also fixes a compiler warning
> > because of a tautologically true check on 64bit systems.
> >
> > Signed-off-by: Andreas Rheinhardt
> > ---
> > A better solution would be to error out as soon as the byte length
> > of a subtitle exceeds UINT16_MAX; yet for this one would have to
> > modify all of ass_split to allow the callbacks to return errors.
> >
> > libavcodec/movtextenc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> > index 1bef21e0b9..cf30adbd0a 100644
> > --- a/libavcodec/movtextenc.c
> > +++ b/libavcodec/movtextenc.c
> > @@ -355,7 +355,7 @@ static int mov_text_style_start(MovTextContext
> > *s) StyleBox *tmp;
> >
> > // last style != defaults, end the style entry and start a
> > new one
> > -if (s->count + 1 > SIZE_MAX / sizeof(*s->style_attributes)
> > ||
> > +if (s->count + 1 > FFMIN(SIZE_MAX /
> > sizeof(*s->style_attributes), UINT16_MAX) || !(tmp =
> > av_fast_realloc(s->style_attributes,
> > &s->style_attributes_bytes_allocated, (s->count + 1) *
> > sizeof(*s->style_attributes {
> Will apply this patchset tomorrow unless there are objections.
>
Looks fine. Thanks!
--phil
___
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: Fixing default number of B frames
On Fri, 19 Feb 2021 18:01:42 +0100 Timo Rothenpieler wrote: > On 19.02.2021 16:29, Ricardo Monteiro wrote: > > Hello, > > > > The patch fixes a bug regarding the number of B frames being used: > > The default number of B frames is now -1 for both h264_nvenc and > > hevc_nvenc. This allows the number of B frames to be determined > > based on the coding preset or overwritten using “-bf” in CLI. > > The condition change seems unnecessary, given that the new one does > the exact same logic. > > I'm in favor of changing the bf default, even though it technically > changes behavior of existing command lines. > It seems counter intuitive that the encoder would gimp itself by > disabling bframes by default. > > If no one objects, I will apply this. > I can't find the patch. Was it discussed off list? The concept sounds fine. --phil ___ 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] avcodec/cuviddec: unref output frame on failure
On Sun, 13 Dec 2020 15:51:04 -0300 James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/cuviddec.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c > index 331851231f..49775b5a09 100644 > --- a/libavcodec/cuviddec.c > +++ b/libavcodec/cuviddec.c > @@ -634,6 +634,9 @@ FF_ENABLE_DEPRECATION_WARNINGS > } > > error: > +if (ret < 0) > +av_frame_unref(frame); > + > if (mapped_frame) > eret = > CHECK_CU(ctx->cvdl->cuvidUnmapVideoFrame(ctx->cudecoder, > mapped_frame)); LGTM --phil ___ 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 1/2] avcodec/cuviddec: check for av_buffer_ref() failure
On Sun, 13 Dec 2020 15:51:03 -0300
James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cuviddec.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
> index 61d7f36c79..331851231f 100644
> --- a/libavcodec/cuviddec.c
> +++ b/libavcodec/cuviddec.c
> @@ -553,6 +553,12 @@ static int cuvid_output_frame(AVCodecContext
> *avctx, AVFrame *frame)
> tmp_frame->format= AV_PIX_FMT_CUDA;
> tmp_frame->hw_frames_ctx = av_buffer_ref(ctx->hwframe);
> +if (!tmp_frame->hw_frames_ctx) {
> +ret = AVERROR(ENOMEM);
> +av_frame_free(&tmp_frame);
> +goto error;
> +}
> +
> tmp_frame->width = avctx->width;
> tmp_frame->height= avctx->height;
>
LGTM
--phil
___
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/libaom: Support monochrome encoding with libaom >= 2.0.1
Monochrome encoding with libaom was buggy for a long time, but this was
finally sorted out in libaom 2.0.1 (2.0.0 is almost there but was still
buggy in realtime mode).
Signed-off-by: Philip Langdale
---
Changelog | 1 +
libavcodec/libaomenc.c | 42 --
libavcodec/version.h | 2 +-
3 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/Changelog b/Changelog
index 503317dfae..8f5e849f8d 100644
--- a/Changelog
+++ b/Changelog
@@ -51,6 +51,7 @@ version :
- asubcut filter
- Microsoft Paint (MSP) version 2 decoder
- Microsoft Paint (MSP) demuxer
+- AV1 monochrome encoding support via libaom >= 2.0.1
version 4.3:
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 2b0581b15a..342d0883e4 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -338,6 +338,9 @@ static int set_pix_fmt(AVCodecContext *avctx,
aom_codec_caps_t codec_caps,
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
enccfg->g_bit_depth = enccfg->g_input_bit_depth = desc->comp[0].depth;
switch (avctx->pix_fmt) {
+case AV_PIX_FMT_GRAY8:
+enccfg->monochrome = 1;
+/* Fall-through */
case AV_PIX_FMT_YUV420P:
enccfg->g_profile = FF_PROFILE_AV1_MAIN;
*img_fmt = AOM_IMG_FMT_I420;
@@ -351,6 +354,10 @@ static int set_pix_fmt(AVCodecContext *avctx,
aom_codec_caps_t codec_caps,
enccfg->g_profile = FF_PROFILE_AV1_HIGH;
*img_fmt = AOM_IMG_FMT_I444;
return 0;
+case AV_PIX_FMT_GRAY10:
+case AV_PIX_FMT_GRAY12:
+enccfg->monochrome = 1;
+/* Fall-through */
case AV_PIX_FMT_YUV420P10:
case AV_PIX_FMT_YUV420P12:
if (codec_caps & AOM_CODEC_CAP_HIGHBITDEPTH) {
@@ -1158,6 +1165,15 @@ static const enum AVPixelFormat av1_pix_fmts[] = {
AV_PIX_FMT_NONE
};
+static const enum AVPixelFormat av1_pix_fmts_with_gray[] = {
+AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV422P,
+AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_GBRP,
+AV_PIX_FMT_GRAY8,
+AV_PIX_FMT_NONE
+};
+
static const enum AVPixelFormat av1_pix_fmts_highbd[] = {
AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUV422P,
@@ -1174,13 +1190,35 @@ static const enum AVPixelFormat av1_pix_fmts_highbd[] =
{
AV_PIX_FMT_NONE
};
+static const enum AVPixelFormat av1_pix_fmts_highbd_with_gray[] = {
+AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV422P,
+AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_GBRP,
+AV_PIX_FMT_YUV420P10,
+AV_PIX_FMT_YUV422P10,
+AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_YUV420P12,
+AV_PIX_FMT_YUV422P12,
+AV_PIX_FMT_YUV444P12,
+AV_PIX_FMT_GBRP10,
+AV_PIX_FMT_GBRP12,
+AV_PIX_FMT_GRAY8,
+AV_PIX_FMT_GRAY10,
+AV_PIX_FMT_GRAY12,
+AV_PIX_FMT_NONE
+};
+
static av_cold void av1_init_static(AVCodec *codec)
{
+int supports_monochrome = aom_codec_version() >= 20001;
aom_codec_caps_t codec_caps = aom_codec_get_caps(aom_codec_av1_cx());
if (codec_caps & AOM_CODEC_CAP_HIGHBITDEPTH)
-codec->pix_fmts = av1_pix_fmts_highbd;
+codec->pix_fmts = supports_monochrome ? av1_pix_fmts_highbd_with_gray :
+av1_pix_fmts_highbd;
else
-codec->pix_fmts = av1_pix_fmts;
+codec->pix_fmts = supports_monochrome ? av1_pix_fmts_with_gray :
+av1_pix_fmts;
if (aom_codec_version_major() < 2)
codec->capabilities |= AV_CODEC_CAP_EXPERIMENTAL;
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 1c10d105f6..5b92afe60a 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 115
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MICRO 102
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.27.0
___
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/libaom: Support monochrome encoding with libaom >= 2.0.1
Monochrome encoding with libaom was buggy for a long time, but this was
finally sorted out in libaom 2.0.1 (2.0.0 is almost there but was still
buggy in realtime mode).
Surprisingly, we've never had an external library feature flag in
configure before, but it seems reasonable to add such a category.
Signed-off-by: Philip Langdale
---
Changelog | 1 +
configure | 8
libavcodec/libaomenc.c | 14 ++
libavcodec/version.h | 2 +-
4 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/Changelog b/Changelog
index 503317dfae..8f5e849f8d 100644
--- a/Changelog
+++ b/Changelog
@@ -51,6 +51,7 @@ version :
- asubcut filter
- Microsoft Paint (MSP) version 2 decoder
- Microsoft Paint (MSP) demuxer
+- AV1 monochrome encoding support via libaom >= 2.0.1
version 4.3:
diff --git a/configure b/configure
index 10dd40cab8..6c83895414 100755
--- a/configure
+++ b/configure
@@ -1829,6 +1829,10 @@ EXTERNAL_LIBRARY_LIST="
vapoursynth
"
+EXTERNAL_LIBRARY_FEATURES="
+libaom2
+"
+
HWACCEL_AUTODETECT_LIBRARY_LIST="
amf
audiotoolbox
@@ -2314,6 +2318,7 @@ HAVE_LIST="
$ARCH_FEATURES
$BUILTIN_LIST
$COMPLEX_FUNCS
+$EXTERNAL_LIBRARY_FEATURES
$HAVE_LIST_CMDLINE
$HAVE_LIST_PUB
$HEADERS_LIST
@@ -6329,6 +6334,9 @@ enabled gnutls&& require_pkg_config gnutls
gnutls gnutls/gnutls.h gn
enabled jni && { [ $target_os = "android" ] && check_headers
jni.h && enabled pthreads || die "ERROR: jni not found"; }
enabled ladspa&& require_headers "ladspa.h dlfcn.h"
enabled libaom&& require_pkg_config libaom "aom >= 1.0.0"
aom/aom_codec.h aom_codec_version
+if enabled libaom; then
+check_pkg_config libaom2 "aom >= 2.0.1" aom/aom_codec.h aom_codec_version
+fi
enabled libaribb24&& { check_pkg_config libaribb24 "aribb24 > 1.0.3"
"aribb24/aribb24.h" arib_instance_new ||
{ enabled gpl && require_pkg_config libaribb24
aribb24 "aribb24/aribb24.h" arib_instance_new; } ||
die "ERROR: libaribb24 requires version higher
than 1.0.3 or --enable-gpl."; }
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 2b0581b15a..6110472b68 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -338,6 +338,10 @@ static int set_pix_fmt(AVCodecContext *avctx,
aom_codec_caps_t codec_caps,
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
enccfg->g_bit_depth = enccfg->g_input_bit_depth = desc->comp[0].depth;
switch (avctx->pix_fmt) {
+#if HAVE_LIBAOM2
+case AV_PIX_FMT_GRAY8:
+enccfg->monochrome = 1;
+#endif
case AV_PIX_FMT_YUV420P:
enccfg->g_profile = FF_PROFILE_AV1_MAIN;
*img_fmt = AOM_IMG_FMT_I420;
@@ -351,6 +355,11 @@ static int set_pix_fmt(AVCodecContext *avctx,
aom_codec_caps_t codec_caps,
enccfg->g_profile = FF_PROFILE_AV1_HIGH;
*img_fmt = AOM_IMG_FMT_I444;
return 0;
+#if HAVE_LIBAOM2
+case AV_PIX_FMT_GRAY10:
+case AV_PIX_FMT_GRAY12:
+enccfg->monochrome = 1;
+#endif
case AV_PIX_FMT_YUV420P10:
case AV_PIX_FMT_YUV420P12:
if (codec_caps & AOM_CODEC_CAP_HIGHBITDEPTH) {
@@ -1171,6 +1180,11 @@ static const enum AVPixelFormat av1_pix_fmts_highbd[] = {
AV_PIX_FMT_YUV444P12,
AV_PIX_FMT_GBRP10,
AV_PIX_FMT_GBRP12,
+#if HAVE_LIBAOM2
+AV_PIX_FMT_GRAY8,
+AV_PIX_FMT_GRAY10,
+AV_PIX_FMT_GRAY12,
+#endif
AV_PIX_FMT_NONE
};
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 1c10d105f6..5b92afe60a 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 115
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MICRO 102
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.27.0
___
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/nvdec: Add support for decoding monochrome av1
The nvidia hardware explicitly supports decoding monochrome content,
presumably for the AVIF alpha channel. Supporting this requires an
adjustment in av1dec and explicit monochrome detection in nvdec.
I'm not sure why the monochrome path in av1dec did what it did - it
seems non-functional - YUV440P doesn't seem a logical pix_fmt for
monochrome and conditioning on chroma sub-sampling doesn't make sense.
So I changed it.
I've tested 8bit content, but I haven't found a way to create a 10bit
sample, so that path is untested for now.
Signed-off-by: Philip Langdale
---
libavcodec/av1dec.c | 23 ++-
libavcodec/nvdec.c | 3 +++
libavcodec/version.h | 2 +-
3 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index d7b2ac9d46..f973d93edc 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -387,11 +387,14 @@ static int get_pixel_format(AVCodecContext *avctx)
av_log(avctx, AV_LOG_WARNING, "Unknown AV1 pixel format.\n");
}
} else {
-if (seq->color_config.subsampling_x == 1 &&
-seq->color_config.subsampling_y == 1)
-pix_fmt = AV_PIX_FMT_YUV440P;
-else
-av_log(avctx, AV_LOG_WARNING, "Unknown AV1 pixel format.\n");
+if (bit_depth == 8)
+pix_fmt = AV_PIX_FMT_GRAY8;
+else if (bit_depth == 10)
+pix_fmt = AV_PIX_FMT_GRAY10;
+else if (bit_depth == 12)
+pix_fmt = AV_PIX_FMT_GRAY12;
+else
+av_log(avctx, AV_LOG_WARNING, "Unknown AV1 pixel format.\n");
}
av_log(avctx, AV_LOG_DEBUG, "AV1 decode get format: %s.\n",
@@ -430,6 +433,16 @@ static int get_pixel_format(AVCodecContext *avctx)
#endif
#if CONFIG_AV1_VAAPI_HWACCEL
*fmtp++ = AV_PIX_FMT_VAAPI;
+#endif
+break;
+case AV_PIX_FMT_GRAY8:
+#if CONFIG_AV1_NVDEC_HWACCEL
+*fmtp++ = AV_PIX_FMT_CUDA;
+#endif
+break;
+case AV_PIX_FMT_GRAY10:
+#if CONFIG_AV1_NVDEC_HWACCEL
+*fmtp++ = AV_PIX_FMT_CUDA;
#endif
break;
}
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index dd7dcccafa..d45804994f 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -84,6 +84,9 @@ static int map_chroma_format(enum AVPixelFormat pix_fmt)
{
int shift_h = 0, shift_v = 0;
+if (av_pix_fmt_count_planes(pix_fmt) == 1)
+return cudaVideoChromaFormat_Monochrome;
+
av_pix_fmt_get_chroma_sub_sample(pix_fmt, &shift_h, &shift_v);
if (shift_h == 1 && shift_v == 1)
diff --git a/libavcodec/version.h b/libavcodec/version.h
index e4b81da7cb..d1f6fb440a 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 114
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/8] avcodec/movtextenc: Fix potential use of uninitialized value
On Sat, 17 Oct 2020 09:37:38 +0200 Andreas Rheinhardt wrote: > Background colour was never initialized if no style was available. > Use a sane default of zero (i.e. completely transparent). > > Fixes Coverity issue #1461471. > > Signed-off-by: Andreas Rheinhardt > --- > No change for this patch since last time; I am just resending all > because I have added a few patches that I intend to backport and that > therefore should be applied before "Simplify writing to AVBPrint". > > libavcodec/movtextenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c > index 5f60b8db61..11db240ab7 100644 > --- a/libavcodec/movtextenc.c > +++ b/libavcodec/movtextenc.c > @@ -205,7 +205,7 @@ static int > encode_sample_description(AVCodecContext *avctx) ASS *ass; > ASSStyle *style; > int i, j; > -uint32_t tsmb_size, tsmb_type, back_color, style_color; > +uint32_t tsmb_size, tsmb_type, back_color = 0, style_color; > uint16_t style_start, style_end, fontID, count; > int font_names_total_len = 0; > MovTextContext *s = avctx->priv_data; This movtextenc series looks good. Sorry I missed it earlier. Thanks! --phil ___ 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 01/11] avcodec/movtextdec: Reset counter of fonts when freeing them
On Sat, 17 Oct 2020 20:22:38 +0200
Andreas Rheinhardt wrote:
> If allocating fonts fails when reading the header, all fonts are
> freed, yet the counter of fonts is not reset and no error is
> returned; when subtitles are decoded lateron, the inexistent list of
> fonts is searched for the matching font for this particular entry
> which of course leads to a segfault.
Hi Andreas,
I looked through the whole series. Looks good. Thanks for doing all of
this.
--phil
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/movtextdec.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> index 4a21dbf36d..068bdb7802 100644
> --- a/libavcodec/movtextdec.c
> +++ b/libavcodec/movtextdec.c
> @@ -148,6 +148,7 @@ static void mov_text_cleanup_ftab(MovTextContext
> *m) }
> }
> av_freep(&m->ftab);
> +m->ftab_entries = 0;
> }
>
> static int mov_text_tx3g(AVCodecContext *avctx, MovTextContext *m)
> @@ -230,7 +231,6 @@ static int mov_text_tx3g(AVCodecContext *avctx,
> MovTextContext *m) box_size += 3;
> if (avctx->extradata_size < box_size) {
> mov_text_cleanup_ftab(m);
> -m->ftab_entries = 0;
> return -1;
> }
> m->ftab_temp = av_mallocz(sizeof(*m->ftab_temp));
> @@ -245,7 +245,6 @@ static int mov_text_tx3g(AVCodecContext *avctx,
> MovTextContext *m) box_size = box_size + font_length;
> if (avctx->extradata_size < box_size) {
> mov_text_cleanup_ftab(m);
> -m->ftab_entries = 0;
> return -1;
> }
> m->ftab_temp->font = av_malloc(font_length + 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] avfilter/vf_bwdif_cuda: CUDA implementation of bwdif
On Sun, 11 Oct 2020 18:36:42 +0200
Thomas Mundt wrote:
> Hi Philip,
>
> Am Fr., 9. Okt. 2020 um 18:33 Uhr schrieb Philip Langdale
> >:
>
> > I've been sitting on this for a couple of years now, and I figured I
> > should just send it out. This is what I believe is a conceptually
> > correct port of bwdif to cuda (modulo edge handling which is not
> > done in the same way because the conditional checks for edges are
> > expensive in cuda, but that's the same as for yadif_cuda).
> >
> > However, I see glitches in some samples where black or white pixels
> > appear in white or black areas respectively. This seems like some
> > sort of under/overflow. I've tried to use the largest cuda types
> > everywhere, and that did appear to improve things but didn't make
> > it go away. This is what led to me never sending this diff over the
> > years, but maybe someone else has insights about this.
> >
>
> I am not familiar with cuda. So here is just one difference, which I
> noticed compared to the c code.
> Maybe that is the reason for the glitches.
>
> > +
> > +template
> > +__inline__ __device__ T filter(T A, T B, T C, T D,
> > + T a, T b, T c, T d, T e, T f, T g,
> > + T h, T i, T j, T k, T l, T m, T n,
> > + int clip_max)
> > +{
> > +T final;
> > +
> > +int fc = C;
> > +int fd = (c + l) >> 1;
> > +int fe = B;
> >
>
> In the following you sometimes use B and C directly and sometimes fc
> and fe. Is there a reason for this?
Unfortunately, I can't remember. This may have had something to do with
wanting those calculations to be done with smaller data types, but why
do that? Switch them did not have any obvious visual effect.
>
> > +
> > +int temporal_diff0 = abs(c - l);
> > +int temporal_diff1 = (abs(g - fc) + abs(f - fe)) >> 1;
> > +int temporal_diff2 = (abs(i - fc) + abs(h - fe)) >> 1;
> > +int diff = max3(temporal_diff0 >> 1, temporal_diff1,
> > temporal_diff2); +
> > +if (!diff) {
> > +final = fd;
> > +} else {
> > +int fb = ((d + m) >> 1) - fc;
> > +int ff = ((c + l) >> 1) - fe;
> >
>
> If I don´t miss anything this should be:
> int ff = ((b + k) >> 1) - fe;
I think you're right. This also doesn't seem to change things
significantly; the glitches are still there, but that's not surprising.
This fix would make the non-glitched parts more correct.
Thanks for taking a look. I'll keep banging my head against this one.
--phil
___
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_bwdif_cuda: CUDA implementation of bwdif
I've been sitting on this for a couple of years now, and I figured I
should just send it out. This is what I believe is a conceptually
correct port of bwdif to cuda (modulo edge handling which is not done
in the same way because the conditional checks for edges are expensive
in cuda, but that's the same as for yadif_cuda).
However, I see glitches in some samples where black or white pixels
appear in white or black areas respectively. This seems like some
sort of under/overflow. I've tried to use the largest cuda types
everywhere, and that did appear to improve things but didn't make
it go away. This is what led to me never sending this diff over the
years, but maybe someone else has insights about this.
---
configure| 2 +
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_bwdif_cuda.c | 394 +++
libavfilter/vf_bwdif_cuda.cu | 290 ++
5 files changed, 689 insertions(+)
create mode 100644 libavfilter/vf_bwdif_cuda.c
create mode 100644 libavfilter/vf_bwdif_cuda.cu
diff --git a/configure b/configure
index 75f0a0fcaa..4e7a97b17e 100755
--- a/configure
+++ b/configure
@@ -3511,6 +3511,8 @@ bm3d_filter_select="dct"
boxblur_filter_deps="gpl"
boxblur_opencl_filter_deps="opencl gpl"
bs2b_filter_deps="libbs2b"
+bwdif_cuda_filter_deps="ffnvcodec"
+bwdif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
chromaber_vulkan_filter_deps="vulkan libglslang"
colorkey_opencl_filter_deps="opencl"
colormatrix_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e6d3c283da..db99238fce 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -178,6 +178,8 @@ OBJS-$(CONFIG_BOXBLUR_FILTER)+=
vf_boxblur.o boxblur.o
OBJS-$(CONFIG_BOXBLUR_OPENCL_FILTER) += vf_avgblur_opencl.o opencl.o \
opencl/avgblur.o boxblur.o
OBJS-$(CONFIG_BWDIF_FILTER) += vf_bwdif.o yadif_common.o
+OBJS-$(CONFIG_BWDIF_CUDA_FILTER) += vf_bwdif_cuda.o
vf_bwdif_cuda.ptx.o \
+yadif_common.o
OBJS-$(CONFIG_CAS_FILTER)+= vf_cas.o
OBJS-$(CONFIG_CHROMABER_VULKAN_FILTER) += vf_chromaber_vulkan.o vulkan.o
OBJS-$(CONFIG_CHROMAHOLD_FILTER) += vf_chromakey.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index fa91e608e4..2da43166a5 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -169,6 +169,7 @@ extern AVFilter ff_vf_bm3d;
extern AVFilter ff_vf_boxblur;
extern AVFilter ff_vf_boxblur_opencl;
extern AVFilter ff_vf_bwdif;
+extern AVFilter ff_vf_bwdif_cuda;
extern AVFilter ff_vf_cas;
extern AVFilter ff_vf_chromahold;
extern AVFilter ff_vf_chromakey;
diff --git a/libavfilter/vf_bwdif_cuda.c b/libavfilter/vf_bwdif_cuda.c
new file mode 100644
index 00..7651a869d5
--- /dev/null
+++ b/libavfilter/vf_bwdif_cuda.c
@@ -0,0 +1,394 @@
+/*
+ * Copyright (C) 2018 Philip Langdale
+ *
+ * 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
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/cuda_check.h"
+#include "internal.h"
+#include "yadif.h"
+
+extern char vf_bwdif_cuda_ptx[];
+
+typedef struct DeintCUDAContext {
+YADIFContext yadif;
+
+AVCUDADeviceContext *hwctx;
+AVBufferRef *device_ref;
+AVBufferRef *input_frames_ref;
+AVHWFramesContext *input_frames;
+
+CUcontext cu_ctx;
+CUstreamstream;
+CUmodulecu_module;
+CUfunction cu_func_uchar;
+CUfunction cu_func_uchar2;
+CUfunction cu_func_ushort;
+CUfunction cu_func_ushort2;
+} DeintCUDAContext;
+
+#define DIV_UP(a, b) ( ((a) + (b) - 1) / (b) )
+#define ALIGN_UP(a, b) (((a) + (b) - 1) & ~((b) - 1))
+#define BLOCKX 32
+#define BLOCKY 16
+
+#define CHECK_CU(x) FF_CUDA_CHECK_DL(ctx, s->hwctx->internal->cuda_dl, x)
+
+static CUresult call_kernel(AVFilterContext *ctx, CUfunction func,
+CUdeviceptr prev, CUde
Re: [FFmpeg-devel] [PATCH] VP9 Profile 2 VDPAU support
On Thu, 8 Oct 2020 11:48:51 +0530 ManojGuptaBonda wrote: > Added VDPAU to list of supported formats for VP9 420 10 and 12 bit > formats. Add VP9 10/12 Bit support for VDPAU > --- > libavcodec/vp9.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c > index fd0bab14a2..8b89fd68e2 100644 > --- a/libavcodec/vp9.c > +++ b/libavcodec/vp9.c > @@ -223,6 +223,9 @@ static int update_size(AVCodecContext *avctx, int > w, int h) #endif > #if CONFIG_VP9_VAAPI_HWACCEL > *fmtp++ = AV_PIX_FMT_VAAPI; > +#endif > +#if CONFIG_VP9_VDPAU_HWACCEL > +*fmtp++ = AV_PIX_FMT_VDPAU; > #endif > break; > case AV_PIX_FMT_YUV420P12: > @@ -231,6 +234,9 @@ static int update_size(AVCodecContext *avctx, int > w, int h) #endif > #if CONFIG_VP9_VAAPI_HWACCEL > *fmtp++ = AV_PIX_FMT_VAAPI; > +#endif > +#if CONFIG_VP9_VDPAU_HWACCEL > +*fmtp++ = AV_PIX_FMT_VDPAU; > #endif > break; > } Pushed. Thanks, --phil ___ 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] configure: Add additional glslang libraries to make linking work
The latest builds of glslang introduce new libraries that need to be
linked for all symbols to be fully resolved.
Presumably, requiring these new libraries breaks building against
older glslang releases? What range are we committing to supporting?
Signed-off-by: Philip Langdale
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 07e07850e8..4bff8d53ce 100755
--- a/configure
+++ b/configure
@@ -6343,7 +6343,7 @@ enabled fontconfig&& enable libfontconfig
enabled libfontconfig && require_pkg_config libfontconfig fontconfig
"fontconfig/fontconfig.h" FcInit
enabled libfreetype && require_pkg_config libfreetype freetype2
"ft2build.h FT_FREETYPE_H" FT_Init_FreeType
enabled libfribidi&& require_pkg_config libfribidi fribidi fribidi.h
fribidi_version_info
-enabled libglslang&& require_cpp libglslang
glslang/SPIRV/GlslangToSpv.h "glslang::TIntermediate*" -lglslang -lOSDependent
-lHLSL -lOGLCompiler -lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools
-lpthread -lstdc++
+enabled libglslang&& require_cpp libglslang
glslang/SPIRV/GlslangToSpv.h "glslang::TIntermediate*" -lglslang
-lMachineIndependent -lOSDependent -lHLSL -lOGLCompiler -lGenericCodeGen
-lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++
enabled libgme&& { check_pkg_config libgme libgme gme/gme.h
gme_new_emu ||
require libgme gme/gme.h gme_new_emu -lgme
-lstdc++; }
enabled libgsm&& { for gsm_hdr in "gsm.h" "gsm/gsm.h"; do
--
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] avformat/hls: add supporting EXT-X-DISCONTINUITY tag
On Sat, 18 Jul 2020 20:29:01 +0300 Aleksey Skripka wrote: > Greetings! > > unconditional AVFMT_TS_DISCONT also helps to survive when pts > rollover in mpegts occurs. seems like this patch will break again > reading long-lasting hls. > Right. The flag on the InputFormat says the format _might_ have discontinuities. The EXT-X-DISCONTINUITY tag shows up in the hls m3u8 each time there actually is a discontinuity. And this is the part where I complain about how hard the hls demuxer makes it to propagate discontinuities correctly. It concatenates the fragments and then passes them on to the mpegts demuxer. This means you lose the discontinuity information and you can't easily translate it into an mpegts marker because we don't work at the packet level. *sigh* --phil ___ 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 0/2] VDPAU HEVC 10/12 Bit Decode Support
On Sat, 27 Jun 2020 19:04:20 +0530 ManojGuptaBonda wrote: > NVIDIA R450 driver added VDPAU support for HEVC 10/12 bit Decoding > adding the same in ffmpeg. Updated version with #ifdef guards > to continue compiling with older releases > > > ManojGuptaBonda (2): > lavc/vdpau_hevc: add function to find exact vdp_profile for REXT > Add VDPAU to list of supported formats > > libavcodec/Makefile | 2 +- > libavcodec/hevcdec.c| 6 +++ > libavcodec/vdpau.c | 4 ++ > libavcodec/vdpau_hevc.c | 89 > - libavutil/hwcontext_vdpau.c | > 21 - 5 files changed, 118 insertions(+), 4 deletions(-) > This set compiles cleanly with older libvdpau, thanks. I will test with the new drivers when ubuntu publish debs for them and then push the changes if everything works as expected. Thanks, --phil ___ 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] Add VDPAU to list of supported formats
On Fri, 26 Jun 2020 12:43:29 +0530 ManojGuptaBonda wrote: > Added VDPAU to list of supported formats for HEVC10 and 12 bit formats > also added 42010 bit to surface_parameters and new VDP chroma formats > to VDPAUPixFmtMaps > > Add HEVC 420 10/12 Bit and 444 10/12 Bit support for VDPAU > > > YUV444P10 is defined as the 444 surface with 10bit valid data in LSBs > but H/w returns Data in MSBs Hence if we map output as YUV444p16 it > is filtering out the LSB to convert to p10 format. This one needs #ifdef guards too. --phil ___ 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] [VDPAU] [PATCH 1/2] lavc/vdpau_hevc: add function to find exact vdp_profile for REXT
On Fri, 26 Jun 2020 17:47:32 +0300 Rémi Denis-Courmont wrote: > > Is this really supposed to be done with string matching in > libavcodec? That looks rather brittle to me. It's a fair statement, but, surprisingly, we don't have a profile enum. The profile calculator parses all the various contributing attributes and ultimately maps them to these strings. We would need to extend the profile descriptor to add an enum, which I think is reasonable, but short of that, there isn't another way. --phil ___ 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 1/2] lavc/vdpau_hevc: add function to find exact vdp_profile for REXT
On Thu, 25 Jun 2020 09:17:19 -0700 Philip Langdale wrote: > > > LGTM. > I have been reminded that this only compiles cleanly with the latest vdpau. We need #ifdef guards to continue compiling with older releases. --phil ___ 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] Add VDPAU to list of supported formats
On Thu, 25 Jun 2020 16:53:02 +0530
ManojGuptaBonda wrote:
> Added VDPAU to list of supported formats for HEVC10 and 12 bit formats
> also added 42010 bit to surface_parameters and new VDP chroma formats
> to VDPAUPixFmtMaps
>
> Add HEVC 420 10/12 Bit and 444 10/12 Bit support for VDPAU
>
>
> YUV444P10 is defined as the 444 surface with 10bit valid data in LSBs
> but H/w returns Data in MSBs Hence if we map output as YUV444p16 it
> is filtering out the LSB to convert to p10 format.
> ---
> libavcodec/hevcdec.c| 6 ++
> libavcodec/vdpau.c | 4
> libavutil/hwcontext_vdpau.c | 13 +++--
> 3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index c9e28f5826..e576cce5de 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -414,6 +414,9 @@ static enum AVPixelFormat get_format(HEVCContext
> *s, const HEVCSPS *sps) #if CONFIG_HEVC_VIDEOTOOLBOX_HWACCEL
> *fmt++ = AV_PIX_FMT_VIDEOTOOLBOX;
> #endif
> +#if CONFIG_HEVC_VDPAU_HWACCEL
> +*fmt++ = AV_PIX_FMT_VDPAU;
> +#endif
> #if CONFIG_HEVC_NVDEC_HWACCEL
> *fmt++ = AV_PIX_FMT_CUDA;
> #endif
> @@ -435,6 +438,9 @@ static enum AVPixelFormat get_format(HEVCContext
> *s, const HEVCSPS *sps) case AV_PIX_FMT_YUV420P12:
> case AV_PIX_FMT_YUV444P10:
> case AV_PIX_FMT_YUV444P12:
> +#if CONFIG_HEVC_VDPAU_HWACCEL
> +*fmt++ = AV_PIX_FMT_VDPAU;
> +#endif
> #if CONFIG_HEVC_NVDEC_HWACCEL
> *fmt++ = AV_PIX_FMT_CUDA;
> #endif
> diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
> index 167f06d7ae..fa10905c75 100644
> --- a/libavcodec/vdpau.c
> +++ b/libavcodec/vdpau.c
> @@ -83,6 +83,8 @@ int av_vdpau_get_surface_parameters(AVCodecContext
> *avctx, switch (avctx->sw_pix_fmt) {
> case AV_PIX_FMT_YUV420P:
> case AV_PIX_FMT_YUVJ420P:
> +case AV_PIX_FMT_YUV420P10:
> +case AV_PIX_FMT_YUV420P12:
> t = VDP_CHROMA_TYPE_420;
> w = (w + 1) & ~1;
> h = (h + 3) & ~3;
> @@ -95,6 +97,8 @@ int av_vdpau_get_surface_parameters(AVCodecContext
> *avctx, break;
> case AV_PIX_FMT_YUV444P:
> case AV_PIX_FMT_YUVJ444P:
> +case AV_PIX_FMT_YUV444P10:
> +case AV_PIX_FMT_YUV444P12:
> t = VDP_CHROMA_TYPE_444;
> h = (h + 1) & ~1;
> break;
> diff --git a/libavutil/hwcontext_vdpau.c b/libavutil/hwcontext_vdpau.c
> index 6b8c1d5f76..6061476094 100644
> --- a/libavutil/hwcontext_vdpau.c
> +++ b/libavutil/hwcontext_vdpau.c
> @@ -39,8 +39,8 @@ typedef struct VDPAUDeviceContext {
> VdpVideoSurfaceCreate *surf_create;
> VdpVideoSurfaceDestroy *surf_destroy;
>
> -enum AVPixelFormat *pix_fmts[3];
> -int nb_pix_fmts[3];
> +enum AVPixelFormat *pix_fmts[8];
> +int nb_pix_fmts[8];
> } VDPAUDeviceContext;
>
> typedef struct VDPAUFramesContext {
> @@ -61,6 +61,8 @@ typedef struct VDPAUPixFmtMap {
> static const VDPAUPixFmtMap pix_fmts_420[] = {
> { VDP_YCBCR_FORMAT_NV12, AV_PIX_FMT_NV12},
> { VDP_YCBCR_FORMAT_YV12, AV_PIX_FMT_YUV420P },
> +{ VDP_YCBCR_FORMAT_P016, AV_PIX_FMT_P016},
> +{ VDP_YCBCR_FORMAT_P010, AV_PIX_FMT_P010},
> { 0, AV_PIX_FMT_NONE, },
> };
>
> @@ -75,6 +77,7 @@ static const VDPAUPixFmtMap pix_fmts_422[] = {
> static const VDPAUPixFmtMap pix_fmts_444[] = {
> #ifdef VDP_YCBCR_FORMAT_Y_U_V_444
> { VDP_YCBCR_FORMAT_Y_U_V_444, AV_PIX_FMT_YUV444P },
> +{VDP_YCBCR_FORMAT_Y_U_V_444_16, AV_PIX_FMT_YUV444P16},
> #endif
> { 0, AV_PIX_FMT_NONE, },
> };
> @@ -87,6 +90,11 @@ static const struct {
> { VDP_CHROMA_TYPE_420, AV_PIX_FMT_YUV420P, pix_fmts_420 },
> { VDP_CHROMA_TYPE_422, AV_PIX_FMT_YUV422P, pix_fmts_422 },
> { VDP_CHROMA_TYPE_444, AV_PIX_FMT_YUV444P, pix_fmts_444 },
> +{ VDP_CHROMA_TYPE_420_16, AV_PIX_FMT_YUV420P10, pix_fmts_420 },
> +{ VDP_CHROMA_TYPE_420_16, AV_PIX_FMT_YUV420P12, pix_fmts_420 },
> +{ VDP_CHROMA_TYPE_422_16, AV_PIX_FMT_YUV422P, pix_fmts_422 },
Is this right? That's the 8bit ffmpeg format.
> +{ VDP_CHROMA_TYPE_444_16, AV_PIX_FMT_YUV444P10, pix_fmts_444 },
> +{ VDP_CHROMA_TYPE_444_16, AV_PIX_FMT_YUV444P12, pix_fmts_444 },
> };
>
> static int count_pixfmts(const VDPAUPixFmtMap *map)
> @@ -354,6 +362,7 @@ static int
> vdpau_transfer_data_from(AVHWFramesContext *ctx, AVFrame *dst, if
> ((vdpau_format == VDP_YCBCR_FORMAT_YV12) #ifdef
> VDP_YCBCR_FORMAT_Y_U_V_444 || (vdpau_format ==
> VDP_YCBCR_FORMAT_Y_U_V_444)
> +|| (vdpau_format == VDP_YCBCR_FORMAT_Y_U_V_444_16)
> #endif
> )
> FFSWAP(void*, data[1], data[2]);
--phil
___
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 "u
Re: [FFmpeg-devel] [PATCH 1/2] lavc/vdpau_hevc: add function to find exact vdp_profile for REXT
On Thu, 25 Jun 2020 16:53:01 +0530
ManojGuptaBonda wrote:
> Add vdpau_parse_rext_profile and use profile constraint flags to
> determine the exact vdp_profile for HEVC_REXT.
>
> If profile mismatch is allowed, select Main profile by default.
>
> Add build object in Makefile for h265_profile_level dependency.
> ---
> libavcodec/Makefile | 2 +-
> libavcodec/vdpau_hevc.c | 83
> - 2 files changed, 83
> insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 5a6ea59715..4f28cb0f2a 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -910,7 +910,7 @@ OBJS-$(CONFIG_HEVC_DXVA2_HWACCEL) +=
> dxva2_hevc.o OBJS-$(CONFIG_HEVC_NVDEC_HWACCEL) += nvdec_hevc.o
> OBJS-$(CONFIG_HEVC_QSV_HWACCEL) += qsvdec_h2645.o
> OBJS-$(CONFIG_HEVC_VAAPI_HWACCEL) += vaapi_hevc.o
> h265_profile_level.o -OBJS-$(CONFIG_HEVC_VDPAU_HWACCEL) +=
> vdpau_hevc.o +OBJS-$(CONFIG_HEVC_VDPAU_HWACCEL) +=
> vdpau_hevc.o h265_profile_level.o OBJS-$(CONFIG_MJPEG_NVDEC_HWACCEL)
> += nvdec_mjpeg.o OBJS-$(CONFIG_MJPEG_VAAPI_HWACCEL)+=
> vaapi_mjpeg.o OBJS-$(CONFIG_MPEG1_NVDEC_HWACCEL)+=
> nvdec_mpeg12.o diff --git a/libavcodec/vdpau_hevc.c
> b/libavcodec/vdpau_hevc.c index 29cb2da078..1ee781c685 100644
> --- a/libavcodec/vdpau_hevc.c
> +++ b/libavcodec/vdpau_hevc.c
> @@ -29,6 +29,8 @@
> #include "hwconfig.h"
> #include "vdpau.h"
> #include "vdpau_internal.h"
> +#include "h265_profile_level.h"
> +
>
> static int vdpau_hevc_start_frame(AVCodecContext *avctx,
>const uint8_t *buffer, uint32_t
> size) @@ -429,10 +431,87 @@ static int
> vdpau_hevc_end_frame(AVCodecContext *avctx) return 0;
> }
>
> +
> +
> +static int ptl_convert(const PTLCommon *general_ptl,
> H265RawProfileTierLevel *h265_raw_ptl) +{
> +h265_raw_ptl->general_profile_space = general_ptl->profile_space;
> +h265_raw_ptl->general_tier_flag = general_ptl->tier_flag;
> +h265_raw_ptl->general_profile_idc = general_ptl->profile_idc;
> +
> +memcpy(h265_raw_ptl->general_profile_compatibility_flag,
> +
> general_ptl->profile_compatibility_flag, 32 * sizeof(uint8_t)); +
> +#define copy_field(name) h265_raw_ptl->general_ ## name =
> general_ptl->name
> +copy_field(progressive_source_flag);
> +copy_field(interlaced_source_flag);
> +copy_field(non_packed_constraint_flag);
> +copy_field(frame_only_constraint_flag);
> +copy_field(max_12bit_constraint_flag);
> +copy_field(max_10bit_constraint_flag);
> +copy_field(max_8bit_constraint_flag);
> +copy_field(max_422chroma_constraint_flag);
> +copy_field(max_420chroma_constraint_flag);
> +copy_field(max_monochrome_constraint_flag);
> +copy_field(intra_constraint_flag);
> +copy_field(one_picture_only_constraint_flag);
> +copy_field(lower_bit_rate_constraint_flag);
> +copy_field(max_14bit_constraint_flag);
> +copy_field(inbld_flag);
> +copy_field(level_idc);
> +#undef copy_field
> +
> +return 0;
> +}
> +
> +/*
> + * Find exact vdpau_profile for HEVC Range Extension
> + */
> +static int vdpau_hevc_parse_rext_profile(AVCodecContext *avctx,
> VdpDecoderProfile *vdp_profile) +{
> +const HEVCContext *h = avctx->priv_data;
> +const HEVCSPS *sps = h->ps.sps;
> +const PTL *ptl = &sps->ptl;
> +const PTLCommon *general_ptl = &ptl->general_ptl;
> +const H265ProfileDescriptor *profile;
> +H265RawProfileTierLevel h265_raw_ptl = {0};
> +
> +/* convert PTLCommon to H265RawProfileTierLevel */
> +ptl_convert(general_ptl, &h265_raw_ptl);
> +
> +profile = ff_h265_get_profile(&h265_raw_ptl);
> +if (!profile) {
> +av_log(avctx, AV_LOG_WARNING, "HEVC profile is not
> found.\n");
> +if (avctx->hwaccel_flags &
> AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH) {
> +// Default to selecting Main profile if profile mismatch
> is allowed
> +*vdp_profile = VDP_DECODER_PROFILE_HEVC_MAIN;
> +return 0;
> +} else
> +return AVERROR(ENOTSUP);
> +}
> +
> +if (!strcmp(profile->name, "Main 12") ||
> +!strcmp(profile->name, "Main 12 Intra"))
> +*vdp_profile = VDP_DECODER_PROFILE_HEVC_MAIN_12;
> +else if (!strcmp(profile->name, "Main 4:4:4") ||
> + !strcmp(profile->name, "Main 4:4:4 Intra"))
> +*vdp_profile = VDP_DECODER_PROFILE_HEVC_MAIN_444;
> +else if (!strcmp(profile->name, "Main 4:4:4 10") ||
> + !strcmp(profile->name, "Main 4:4:4 10 Intra"))
> +*vdp_profile = VDP_DECODER_PROFILE_HEVC_MAIN_444_10;
> +else if (!strcmp(profile->name, "Main 4:4:4 12") ||
> + !strcmp(profile->name, "Main 4:4:4 12 Intra"))
> +*vdp_profile = VDP_DECODER_PROFILE_HEVC_MAIN_444_12;
> +
> +return 0;
> +}
> +
> +
> static int vdpau_hevc_init(AVCodecContext *avctx)
> {
> VdpDecoderProfile profile;
> uint32_t leve
Re: [FFmpeg-devel] [PATCH] ffmpeg:Accelerated hardware decode support on Jetson
On Mon, 1 Jun 2020 09:50:56 + Amit Pandya wrote: > Hi all, > > This patch can support hardware-accelerated decode in ffmpeg on > Jetson platforms. Hi Amit, I appreciate you sending this in. People have asked about Jetson support a few times. Is there any plan to enable the normal nvdec/nvenc APIs on jetson? There is support on 'normal' ARM systems. More specifically to this change, we already have a v4l2m2m driver. Why is this completely separate? Can it share code? Can it be written to just conditionalise the parts that are different? What are those parts? > ffmpeg application can use accelerated decode to read video files in > the following elementary/container formats and dump them in YUV 420 > format: H.264, H.265, VP8, VP9. MPEG2, MPEG4 (NOTE: The ffmpeg > package does not support MPEG4 container files). What is the problem with mpeg4 containers? Is this the annex b thing? if so, you need to enable the bitstream filter. --phil ___ 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 1/4] avcodec: move avcodec_flush_buffers from decode.c to utils.c
On Thu, 16 Apr 2020 14:07:49 -0300 James Almer wrote: > On 4/16/2020 1:26 PM, Philip Langdale wrote: > > On Tue, 10 Mar 2020 16:33:41 -0300 > > James Almer wrote: > >> > >> I can withdraw this patch (And remove the relevant chunks from the > >> following two) if this function was effectively not meant for > >> encoders. Also maybe poke Timo regarding nvenc flushing, to see why > >> it is needed and if there's an alternative. > > > > I've pushed the change to formalise the encoder flush semantics, so > > this should be good to apply now. > > All encoders were ported, so yes, it could be pushed. But i wonder if > this should go in after 4.3 is tagged rather than now. I'd like this > to have some months of testing in master before making it into a > release. > > Unless 4.3 is months away, in which case i'll just push it now. Ok. You'll have a better sense of 4.3 timing than me, so I'll defer to your judgement. --phil ___ 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 1/4] avcodec: move avcodec_flush_buffers from decode.c to utils.c
On Tue, 10 Mar 2020 16:33:41 -0300 James Almer wrote: > > I can withdraw this patch (And remove the relevant chunks from the > following two) if this function was effectively not meant for > encoders. Also maybe poke Timo regarding nvenc flushing, to see why > it is needed and if there's an alternative. I've pushed the change to formalise the encoder flush semantics, so this should be good to apply now. --phil ___ 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 v4] avcodec: Add explicit capability flag for encoder flushing
Previously, there was no way to flush an encoder such that after
draining, the encoder could be used again. We generally suggested
that clients teardown and replace the encoder instance in these
situations. However, for at least some hardware encoders, the cost of
this tear down/replace cycle is very high, which can get in the way of
some use-cases - for example: segmented encoding with nvenc.
To help address that use case, we added support for calling
avcodec_flush_buffers() to nvenc and things worked in practice,
although it was not clearly documented as to whether this should work
or not. There was only one previous example of an encoder implementing
the flush callback (audiotoolboxenc) and it's unclear if that was
untentional or not. However, it was clear that calling
avocdec_flush_buffers() on any other encoder would leave the encoder in
an undefined state, and that's not great.
As part of cleaning this up, this change introduces a formal capability
flag for encoders that support flushing and ensures a flush call is a
no-op for any other encoder. This allows client code to check if it is
meaningful to call flush on an encoder before actually doing it.
I have not attempted to separate the steps taken inside
avcodec_flush_buffers() because it's not doing anything that's wrong
for an encoder. But I did add a sanity check to reject attempts to
flush a frame threaded encoder because I couldn't wrap my head around
whether that code path was actually safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.
Signed-off-by: Philip Langdale
---
doc/APIchanges | 6 ++
libavcodec/audiotoolboxenc.c | 3 ++-
libavcodec/avcodec.h | 25 -
libavcodec/decode.c | 15 +++
libavcodec/nvenc_h264.c | 6 --
libavcodec/nvenc_hevc.c | 6 --
libavcodec/version.h | 4 ++--
7 files changed, 53 insertions(+), 12 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 4cc2367e69..938ccf3aaa 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,12 @@ libavutil: 2017-10-21
API changes, most recent first:
+2020-04-10 - xx - lavc 58.79.100 - avcodec.h
+ Add formal support for calling avcodec_flush_buffers() on encoders.
+ Encoders that set the cap AV_CODEC_CAP_ENCODER_FLUSH will be flushed.
+ For all other encoders, the call is now a no-op rather than undefined
+ behaviour.
+
2020-xx-xx - xx - lavc 58.78.100 - avcodec.h codec_desc.h codec_id.h
packet.h
Move AVCodecDesc-related public API to new header codec_desc.h.
Move AVCodecID enum to new header codec_id.h.
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 2c1891693e..27632decf5 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -627,7 +627,8 @@ static const AVOption options[] = {
.encode2= ffat_encode, \
.flush = ffat_encode_flush, \
.priv_class = &ffat_##NAME##_enc_class, \
-.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY __VA_ARGS__, \
+.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY | \
+ AV_CODEC_CAP_ENCODER_FLUSH __VA_ARGS__, \
.sample_fmts= (const enum AVSampleFormat[]) { \
AV_SAMPLE_FMT_S16, \
AV_SAMPLE_FMT_U8, AV_SAMPLE_FMT_NONE \
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 55151a0b71..b79b025e53 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -513,6 +513,13 @@ typedef struct RcOverride{
*/
#define AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE (1 << 20)
+/**
+ * This encoder can be flushed using avcodec_flush_buffers(). If this flag is
+ * not set, the encoder must be closed and reopened to ensure that no frames
+ * remain pending.
+ */
+#define AV_CODEC_CAP_ENCODER_FLUSH (1 << 21)
+
/* Exported side data.
These flags can be passed in AVCodecContext.export_side_data before
initialization.
*/
@@ -4473,13 +4480,21 @@ int avcodec_fill_audio_frame(AVFrame *frame, int
nb_channels,
int buf_size, int align);
/**
- * Reset the internal decoder state / flush internal buffers. Should be called
+ * Reset the internal codec state / flush internal buffers. Should be called
* e.g. when seeking or when switching to a different stream.
*
- * @note when refcounted frames are not used (i.e. avctx->refcounted_frames is
0),
- * this invalidates the frames previously returned from the decoder. When
- * refcounted frames are used, the decoder just releases any references it
might
- * keep internally, but the caller's reference remains valid.
+ * @note for decoders, when refcounted frames are not used
+ * (i.e. avctx->refcounted_frames is 0), this invalidates the frames previously
+ * returned from the decoder. When refcounted frames are used, the decoder just
Re: [FFmpeg-devel] Subtitle encoder return codes
On Fri, 10 Apr 2020 21:49:35 + John Stebbins wrote: > On Fri, 2020-04-10 at 14:12 -0700, Philip Langdale wrote: > > On Fri, 10 Apr 2020 13:02:16 -0600 > > John Stebbins wrote: > > > > > Patch set makes return codes from subtitle encoders more > > > meaningful and consistent. Also fixes output buffer size checking > > > where needed. > > > > > > After this, a user of a subtitle encoder can attempt to encode > > > again > > > with a larger buffer if the encoder returns > > > AVERROR_BUFFER_TOO_SMALL > > > > > > > The changes look good. Can you send me a branch for these? > > > > > > Here it is > https://github.com/jstebbins/FFmpeg/tree/sub-enc-rets Pushed. THanks! --phil ___ 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: Add explicit capability flag for encoder flushing
On Fri, 10 Apr 2020 20:01:29 -0300 James Almer wrote: > The assert needs to be under the following chunk, like it was in the > first version, after we have already established that we're dealing > with a flush enabled encoder to ensure that it's not also wrongly > marked as supporting frame threading. > Otherwise you'll be crashing the user if they call > avcodec_flush_buffers() on an encoder that supports frame threading > but never claimed to support flushing, when we were only supposed to > print the warning and return. *sigh*. Right you are. sending a new one. --phil ___ 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 v3] avcodec: Add explicit capability flag for encoder flushing
We've been in this fuzzy situation where maybe you could call
avcodec_flush_buffers() on an encoder but there weren't any encoders
that supported it except maybe audiotoolboxenc. Then we added flush
support to nvenc very intentionally, and it worked, but that was more a
coincidence than anything else. And if you call avcodec_flush_buffers()
on an encoder that doesn't support it, it'll leave the encoder in an
undefined state, so that's not great.
As part of cleaning this up, this change introduces a formal capability
flag for encoders that support flushing and ensures a flush call is a
no-op for any other encoder. This allows client code to check if it is
meaningful to call flush on an encoder before actually doing it.
I have not attempted to separate the steps taken inside
avcodec_flush_buffers() because it's not doing anything that's wrong
for an encoder. But I did add a sanity check to reject attempts to
flush a frame threaded encoder because I couldn't wrap my head around
whether that code path was actually safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.
Signed-off-by: Philip Langdale
---
doc/APIchanges | 6 ++
libavcodec/audiotoolboxenc.c | 3 ++-
libavcodec/avcodec.h | 21 -
libavcodec/decode.c | 15 +++
libavcodec/nvenc_h264.c | 6 --
libavcodec/nvenc_hevc.c | 6 --
libavcodec/version.h | 4 ++--
7 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 4cc2367e69..938ccf3aaa 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,12 @@ libavutil: 2017-10-21
API changes, most recent first:
+2020-04-10 - xx - lavc 58.79.100 - avcodec.h
+ Add formal support for calling avcodec_flush_buffers() on encoders.
+ Encoders that set the cap AV_CODEC_CAP_ENCODER_FLUSH will be flushed.
+ For all other encoders, the call is now a no-op rather than undefined
+ behaviour.
+
2020-xx-xx - xx - lavc 58.78.100 - avcodec.h codec_desc.h codec_id.h
packet.h
Move AVCodecDesc-related public API to new header codec_desc.h.
Move AVCodecID enum to new header codec_id.h.
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 2c1891693e..27632decf5 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -627,7 +627,8 @@ static const AVOption options[] = {
.encode2= ffat_encode, \
.flush = ffat_encode_flush, \
.priv_class = &ffat_##NAME##_enc_class, \
-.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY __VA_ARGS__, \
+.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY | \
+ AV_CODEC_CAP_ENCODER_FLUSH __VA_ARGS__, \
.sample_fmts= (const enum AVSampleFormat[]) { \
AV_SAMPLE_FMT_S16, \
AV_SAMPLE_FMT_U8, AV_SAMPLE_FMT_NONE \
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 55151a0b71..5efe5583a1 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -513,6 +513,13 @@ typedef struct RcOverride{
*/
#define AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE (1 << 20)
+/**
+ * This encoder can be flushed using avcodec_flush_buffers(). If this flag is
+ * not set, the encoder must be closed and reopened to ensure that no frames
+ * remain pending.
+ */
+#define AV_CODEC_CAP_ENCODER_FLUSH (1 << 21)
+
/* Exported side data.
These flags can be passed in AVCodecContext.export_side_data before
initialization.
*/
@@ -4473,13 +4480,17 @@ int avcodec_fill_audio_frame(AVFrame *frame, int
nb_channels,
int buf_size, int align);
/**
- * Reset the internal decoder state / flush internal buffers. Should be called
+ * Reset the internal codec state / flush internal buffers. Should be called
* e.g. when seeking or when switching to a different stream.
*
- * @note when refcounted frames are not used (i.e. avctx->refcounted_frames is
0),
- * this invalidates the frames previously returned from the decoder. When
- * refcounted frames are used, the decoder just releases any references it
might
- * keep internally, but the caller's reference remains valid.
+ * @note for decoders, when refcounted frames are not used
+ * (i.e. avctx->refcounted_frames is 0), this invalidates the frames previously
+ * returned from the decoder. When refcounted frames are used, the decoder just
+ * releases any references it might keep internally, but the caller's reference
+ * remains valid.
+ *
+ * @note for encoders, this function will only do something if the encoder
+ * declares support for AV_CODEC_CAP_ENCODER_FLUSH.
*/
void avcodec_flush_buffers(AVCodecContext *avctx);
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index b7ae1fbb84..d4bdb9b1c0 100644
--- a/libavcodec/decode.c
+++ b/libavcode
Re: [FFmpeg-devel] [PATCH] avcodec: Add explicit capability flag for encoder flushing
On Fri, 10 Apr 2020 18:47:06 -0300 James Almer wrote: > > Seems fine in principle, but I'd like to hear Anton's opinion. Thanks. I've sent an updated patch and will wait for Anton. --phil ___ 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: Add explicit capability flag for encoder flushing
We've been in this fuzzy situation where maybe you could call
avcodec_flush_buffers() on an encoder but there weren't any encoders
that supported it except maybe audiotoolboxenc. Then we added flush
support to nvenc very intentionally, and it worked, but that was more a
coincidence than anything else. And if you call avcodec_flush_buffers()
on an encoder that doesn't support it, it'll leave the encoder in an
undefined state, so that's not great.
As part of cleaning this up, this change introduces a formal capability
flag for encoders that support flushing and ensures a flush call is a
no-op for any other encoder. This allows client code to check if it is
meaningful to call flush on an encoder before actually doing it.
I have not attempted to separate the steps taken inside
avcodec_flush_buffers() because it's not doing anything that's wrong
for an encoder. But I did add a sanity check to reject attempts to
flush a frame threaded encoder because I couldn't wrap my head around
whether that code path was actually safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.
Signed-off-by: Philip Langdale
---
doc/APIchanges | 6 ++
libavcodec/audiotoolboxenc.c | 3 ++-
libavcodec/avcodec.h | 21 -
libavcodec/decode.c | 15 +++
libavcodec/nvenc_h264.c | 6 --
libavcodec/nvenc_hevc.c | 6 --
libavcodec/version.h | 4 ++--
7 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 4cc2367e69..938ccf3aaa 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,12 @@ libavutil: 2017-10-21
API changes, most recent first:
+2020-04-10 - xx - lavc 58.79.100 - avcodec.h
+ Add formal support for calling avcodec_flush_buffers() on encoders.
+ Encoders that set the cap AV_CODEC_CAP_ENCODER_FLUSH will be flushed.
+ For all other encoders, the call is now a no-op rather than undefined
+ behaviour.
+
2020-xx-xx - xx - lavc 58.78.100 - avcodec.h codec_desc.h codec_id.h
packet.h
Move AVCodecDesc-related public API to new header codec_desc.h.
Move AVCodecID enum to new header codec_id.h.
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 2c1891693e..27632decf5 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -627,7 +627,8 @@ static const AVOption options[] = {
.encode2= ffat_encode, \
.flush = ffat_encode_flush, \
.priv_class = &ffat_##NAME##_enc_class, \
-.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY __VA_ARGS__, \
+.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY | \
+ AV_CODEC_CAP_ENCODER_FLUSH __VA_ARGS__, \
.sample_fmts= (const enum AVSampleFormat[]) { \
AV_SAMPLE_FMT_S16, \
AV_SAMPLE_FMT_U8, AV_SAMPLE_FMT_NONE \
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 55151a0b71..5efe5583a1 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -513,6 +513,13 @@ typedef struct RcOverride{
*/
#define AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE (1 << 20)
+/**
+ * This encoder can be flushed using avcodec_flush_buffers(). If this flag is
+ * not set, the encoder must be closed and reopened to ensure that no frames
+ * remain pending.
+ */
+#define AV_CODEC_CAP_ENCODER_FLUSH (1 << 21)
+
/* Exported side data.
These flags can be passed in AVCodecContext.export_side_data before
initialization.
*/
@@ -4473,13 +4480,17 @@ int avcodec_fill_audio_frame(AVFrame *frame, int
nb_channels,
int buf_size, int align);
/**
- * Reset the internal decoder state / flush internal buffers. Should be called
+ * Reset the internal codec state / flush internal buffers. Should be called
* e.g. when seeking or when switching to a different stream.
*
- * @note when refcounted frames are not used (i.e. avctx->refcounted_frames is
0),
- * this invalidates the frames previously returned from the decoder. When
- * refcounted frames are used, the decoder just releases any references it
might
- * keep internally, but the caller's reference remains valid.
+ * @note for decoders, when refcounted frames are not used
+ * (i.e. avctx->refcounted_frames is 0), this invalidates the frames previously
+ * returned from the decoder. When refcounted frames are used, the decoder just
+ * releases any references it might keep internally, but the caller's reference
+ * remains valid.
+ *
+ * @note for encoders, this function will only do something if the encoder
+ * declares support for AV_CODEC_CAP_ENCODER_FLUSH.
*/
void avcodec_flush_buffers(AVCodecContext *avctx);
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index b7ae1fbb84..1602efdf03 100644
--- a/libavcodec/decode.c
+++ b/libavcode
Re: [FFmpeg-devel] Subtitle encoder return codes
On Fri, 10 Apr 2020 13:02:16 -0600 John Stebbins wrote: > Patch set makes return codes from subtitle encoders more meaningful > and consistent. Also fixes output buffer size checking where needed. > > After this, a user of a subtitle encoder can attempt to encode again > with a larger buffer if the encoder returns AVERROR_BUFFER_TOO_SMALL > The changes look good. Can you send me a branch for these? Thanks, --phil ___ 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: Add explicit capability flag for encoder flushing
We've been in this fuzzy situation where maybe you could call
avcodec_flush_buffers() on an encoder but there weren't any encoders
that supported it except maybe audiotoolboxenc. Then we added flush
support to nvenc very intentionally, and it worked, but that was more a
coincidence than anything else. And if you call avcodec_flush_buffers()
on an encoder that doesn't support it, it'll leave the encoder in an
undefined state, so that's not great.
As part of cleaning this up, this change introduces a formal capability
flag for encoders that support flushing and ensures a flush call is a
no-op for any other encoder. This allows client code to check if it is
meaningful to call flush on an encoder before actually doing it.
I have not attempted to separate the steps taken inside
avcodec_flush_buffers() because it's not doing anything that's wrong
for an encoder. But I did add a sanity check to reject attempts to
flush a frame threaded encoder because I couldn't wrap my head around
whether that code path was actually safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.
Signed-off-by: Philip Langdale
---
libavcodec/audiotoolboxenc.c | 3 ++-
libavcodec/avcodec.h | 21 -
libavcodec/decode.c | 18 ++
libavcodec/nvenc_hevc.c | 6 --
4 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 2c1891693e..7cb5ffd915 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -627,7 +627,8 @@ static const AVOption options[] = {
.encode2= ffat_encode, \
.flush = ffat_encode_flush, \
.priv_class = &ffat_##NAME##_enc_class, \
-.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY __VA_ARGS__, \
+.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY | \
+ AV_CODEC_CAP_ENCODER_CAN_FLUSH __VA_ARGS__, \
.sample_fmts= (const enum AVSampleFormat[]) { \
AV_SAMPLE_FMT_S16, \
AV_SAMPLE_FMT_U8, AV_SAMPLE_FMT_NONE \
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 55151a0b71..216ba3f79a 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -513,6 +513,13 @@ typedef struct RcOverride{
*/
#define AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE (1 << 20)
+/**
+ * This encoder can be flushed using avcodec_flush_buffers(). If this flag is
+ * not set, the encoder must be closed and reopened to ensure that no frames
+ * remain pending.
+ */
+#define AV_CODEC_CAP_ENCODER_CAN_FLUSH (1 << 21)
+
/* Exported side data.
These flags can be passed in AVCodecContext.export_side_data before
initialization.
*/
@@ -4473,13 +4480,17 @@ int avcodec_fill_audio_frame(AVFrame *frame, int
nb_channels,
int buf_size, int align);
/**
- * Reset the internal decoder state / flush internal buffers. Should be called
+ * Reset the internal codec state / flush internal buffers. Should be called
* e.g. when seeking or when switching to a different stream.
*
- * @note when refcounted frames are not used (i.e. avctx->refcounted_frames is
0),
- * this invalidates the frames previously returned from the decoder. When
- * refcounted frames are used, the decoder just releases any references it
might
- * keep internally, but the caller's reference remains valid.
+ * @note for decoders, when refcounted frames are not used
+ * (i.e. avctx->refcounted_frames is 0), this invalidates the frames previously
+ * returned from the decoder. When refcounted frames are used, the decoder just
+ * releases any references it might keep internally, but the caller's reference
+ * remains valid.
+ *
+ * @note for encoders, this function will only do something if the encoder
+ * declares support for AV_CODEC_CAP_ENCODER_CAN_FLUSH.
*/
void avcodec_flush_buffers(AVCodecContext *avctx);
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index b7ae1fbb84..d21b5461e5 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -2084,6 +2084,24 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
{
AVCodecInternal *avci = avctx->internal;
+if (av_codec_is_encoder(avctx->codec)) {
+int caps = avctx->codec->capabilities;
+if (!(caps & AV_CODEC_CAP_ENCODER_CAN_FLUSH)) {
+// Only encoders that explicitly declare support for it can be
+// flushed. Otherwise, this is a no-op.
+av_log(avctx, AV_LOG_WARNING, "Ignoring attempt to flush encoder "
+ "that doesn't support it\n");
+return;
+}
+if (caps & AV_CODEC_CAP_FRAME_THREADS) {
+// We haven't implemented flushing for frame-threaded encoders.
+av_log(avctx, AV_LOG_WARNING, "I
Re: [FFmpeg-devel] movtext decode/encode improvements
On Thu, 9 Apr 2020 23:28:49 + John Stebbins wrote: > Essentially yes. We've had our own mov text encoder and decoder in > HandBrake for years. I added support for using ffmpeg for decoding > subtitles last year but the movtext decoder wasn't up to the same > level as ours, so we weren't using ffmpeg for that yet. I'm following > up that work from last year to add subtitle encoding with ffmpeg and > dropping our decoder and encoder for mov text. That's great - and I really appreciate you taking the extra effort to feed this back! Of course, I can't help but be greedy: Have you looked at subtitle positioning? I think that's the biggest functional gap left. > I'm also almost finished writing a PGS subtitle encoder for ffmpeg ;) Very nice! --phil ___ 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] movtext decode/encode improvements
On Thu, 9 Apr 2020 19:30:53 + John Stebbins wrote: > > Pushed to https://github.com/jstebbins/FFmpeg/commits/movtext > > There's one additional patch on the top implementing what we discussed > about highlight alpha updates. Should I send that to the ml as well? > The new one looks good too, so I will merge it along with the others. Thanks for all of this work! It's a big set of improvements for the movtext handling! I'm guessing the motivation was to be able to switch Handbrake to using these instead of some other library? --phil ___ 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] movtext decode/encode improvements
On Thu, 9 Apr 2020 15:51:23 + John Stebbins wrote: > On Wed, 2020-04-08 at 12:24 -0700, Philip Langdale wrote: > > On Tue, 7 Apr 2020 14:38:52 + > > John Stebbins wrote: > > > > > After checking carefully, patches 10 and 23 are as I want them. > > > Sizes > > > are relative to 288 when using override APIs, but are relative to > > > PlayResY when processing the script. > > > > > > On the other hand, patch 20 needs a fix. If the cancel overrides > > > does > > > not specify a style, it *should* restore the ASS style of the > > > current > > > dialog, but instead it is returning to the mp4 default style. > > > > Thanks. I've gone through them all, and I've only had a few minor > > comments. Will you need me to push these once they are finalised? > > > > > > Thanks to you as well. > > Yes, when we're all finished with reviews please commit. I don't have > commit access. I have a few comments by you to resolve (patches 18 > and 22) and one by Nicolas regarding indentation in patch 1. > > If I have to change the indentation in patch 1, it'll percolate > through a few other patches that touch the same code. So I'll have > to resend those, or I can just fix the indentation as a final patch > on top? > Looks like the indentation change is localised so shouldn't have a big effect. Can you push a branch to your github when you are ready - it'll be a lot easier for me to manage than grabbing these from email. Thanks, --phil ___ 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 22/23] lavc/movtextenc: add font name handling
On Thu, 9 Apr 2020 15:21:35 + John Stebbins wrote: > Well, I was leaving that in as a comment showing the structure of the > sample description. But if it's confusing, I can just remove all > those comments. There are several others that do not represent the > actual values written. Ok. That's fine. It was just a bit confusing to read in the diff. I can see the value in keeping the comments to document the structure. --phil ___ 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 18/23] lavc/movtextenc: add alpha tag handling
On Thu, 9 Apr 2020 16:17:21 + John Stebbins wrote: > > > > > > Worth a comment that secondary alpha can't be preserved? > > > > Sure, will do. > > Taking a second look at this, I'm wondering if alpha_id = 2 should be > applied to the highlight color that is set in mov_text_color_cb? And > if so, should a highlight box be started if only the alpha is changed > and not the color? And if so, should the highlight color default to > the current primary color when only alpha changes? I'm not familiar > with how mov text highlight works and what it looks like in practice. > Do you have an opinion? > > If I add the above, I'll do that as a separate new patch, along with > the comment below. > > There should still be a comment here (and probably for color as well) > that outline and background colors can not be modified in mov text. I'm afraid I don't know either. I've not encountered any truly rich movtext subtitles so I don't know what these things are supposed to look like. It sounds like a reasonable argument to say you can apply an alpha-only highlight, but I couldn't even say if that's in-spec or not. :-) I agree that handling anything like that can be a separate patch. --phil ___ 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: adapt to the new internal encode API
On Thu, 9 Apr 2020 11:20:09 -0300 James Almer wrote: > On 4/8/2020 7:04 PM, Philip Langdale wrote: > > On Wed, 8 Apr 2020 14:58:36 -0300 > > James Almer wrote: > > > >> Signed-off-by: James Almer > >> --- > >> This removes the encode2() implementation as it'll never be used > >> if a receive_packet() one exists, and the flush() implementation > >> since according to Anton Khirnov avcodec_flush_buffers() is not > >> meant to be used with encoders, where its behavior is undefined. > > > > Nevertheless, there is a use case for flushing an encoder (see > > 3ea705), and when you call avcodec_flush_buffers() in nvenc, it > > does the right thing. > > > > Removing this will return us to the world before that change where > > there was no way to flush the encoder, and the original bug reporter > > was asking about adding an API to do it. > > > > It seems the right thing to do is to define the behaviour - which > > seems reasonable as-is today and documment that encoders can > > implement flush if necessary. Or we'll just end up adding a new API > > that flushes encoders but has a different name... > > > > --phil > > I'm not against it, but as Marton said the function as it is is not > enough. The changes Anton asked me to remove would need to be re-added > (trivial to do), and the threading related code would probably need > some changes, if anything to not call decoding specific functions on > an encoder context. > > I like the codec capabilities suggestion from Marton. Could you look > into it? I'll change this patch to not remove the flush call while at > it. Yes, please leave the flush as-is for now so we don't regress. At the very least I think adding an encoder vs decoder path into the function makes sense and we can skip all the decoder specific parts. Today, the emergent behaviour is that an encoder is only affected by the flush call if it provides a flush callback - none of the other parts will alter its state, so perhaps the simple thing to do is have the encoder path just call the callback if it's there and naturally do nothing if not. That removes the need for a separate capability flag. --phil ___ 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 01/23] lavc/movtextdec: fix ass header colors
On Thu, 9 Apr 2020 15:09:45 + John Stebbins wrote: > > > > I missed this review earlier. What about the indentation is off? Do > you mean the indent of the function parameters does not align after > the opening paren? I was keeping the lines aligned without wrapping > at 80 characters. Yes, I believe he's referring to the function parameters and not the overall indent. I would normally align to the paren. I think you can do that and keep under 80 if you put each one on its own line? --phil ___ 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: adapt to the new internal encode API
On Wed, 8 Apr 2020 14:58:36 -0300 James Almer wrote: > Signed-off-by: James Almer > --- > This removes the encode2() implementation as it'll never be used if a > receive_packet() one exists, and the flush() implementation since > according to Anton Khirnov avcodec_flush_buffers() is not meant to be > used with encoders, where its behavior is undefined. Nevertheless, there is a use case for flushing an encoder (see 3ea705), and when you call avcodec_flush_buffers() in nvenc, it does the right thing. Removing this will return us to the world before that change where there was no way to flush the encoder, and the original bug reporter was asking about adding an API to do it. It seems the right thing to do is to define the behaviour - which seems reasonable as-is today and documment that encoders can implement flush if necessary. Or we'll just end up adding a new API that flushes encoders but has a different name... --phil ___ 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] movtext decode/encode improvements
On Tue, 7 Apr 2020 14:38:52 + John Stebbins wrote: > > After checking carefully, patches 10 and 23 are as I want them. Sizes > are relative to 288 when using override APIs, but are relative to > PlayResY when processing the script. > > On the other hand, patch 20 needs a fix. If the cancel overrides does > not specify a style, it *should* restore the ASS style of the current > dialog, but instead it is returning to the mp4 default style. Thanks. I've gone through them all, and I've only had a few minor comments. Will you need me to push these once they are finalised? --phil ___ 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 22/23] lavc/movtextenc: add font name handling
On Mon, 6 Apr 2020 11:52:17 -0600
John Stebbins wrote:
> Initializes the mov text sample description from the ASS header and
> creates an mov font table from the fonts available in the ASS Styles.
> ---
> libavcodec/ass_split.c | 5 +
> libavcodec/ass_split.h | 8 ++
> libavcodec/movtextenc.c | 253
> 3 files changed, 216
> insertions(+), 50 deletions(-)
>
> diff --git a/libavcodec/ass_split.c b/libavcodec/ass_split.c
> index 94c32667af..9d5a66f931 100644
> --- a/libavcodec/ass_split.c
> +++ b/libavcodec/ass_split.c
> @@ -599,3 +599,8 @@ ASSStyle *ff_ass_style_get(ASSSplitContext *ctx,
> const char *style) return ass->styles + i;
> return NULL;
> }
> +
> +ASS *ff_ass_get(ASSSplitContext *ctx)
> +{
> +return &ctx->ass;
> +}
> diff --git a/libavcodec/ass_split.h b/libavcodec/ass_split.h
> index 30ce77250c..31b8e53242 100644
> --- a/libavcodec/ass_split.h
> +++ b/libavcodec/ass_split.h
> @@ -204,4 +204,12 @@ int ff_ass_split_override_codes(const
> ASSCodesCallbacks *callbacks, void *priv, */
> ASSStyle *ff_ass_style_get(ASSSplitContext *ctx, const char *style);
>
> +/**
> + * Get ASS structure
> + *
> + * @param ctx Context previously initialized by ff_ass_split().
> + * @return the ASS
> + */
> +ASS *ff_ass_get(ASSSplitContext *ctx);
Is this necesssary? The header says:
/**
* This struct can be casted to ASS to access to the split data.
*/
typedef struct ASSSplitContext ASSSplitContext;
So can't you just cast the context you already have?
> +
> #endif /* AVCODEC_ASS_SPLIT_H */
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 167dffee6a..a62bdb7eb0 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -79,6 +79,8 @@ typedef struct {
> StyleBox d;
> uint16_t text_pos;
> uint16_t byte_count;
> +char ** fonts;
> +int font_count;
> } MovTextContext;
>
> typedef struct {
> @@ -171,69 +173,198 @@ static const Box box_types[] = {
>
> const static size_t box_count = FF_ARRAY_ELEMS(box_types);
>
> -static av_cold int mov_text_encode_init(AVCodecContext *avctx)
> +static int mov_text_encode_close(AVCodecContext *avctx)
> {
> -/*
> - * For now, we'll use a fixed default style. When we add styling
> - * support, this will be generated from the ASS style.
> - */
> -static const uint8_t text_sample_entry[] = {
> +MovTextContext *s = avctx->priv_data;
> +int i;
> +
> +ff_ass_split_free(s->ass_ctx);
> +if (s->style_attributes) {
> +for (i = 0; i < s->count; i++) {
> +av_freep(&s->style_attributes[i]);
> +}
> +av_freep(&s->style_attributes);
> +}
> +av_freep(&s->fonts);
> +av_freep(&s->style_attributes_temp);
> +av_bprint_finalize(&s->buffer, NULL);
> +return 0;
> +}
> +
> +static int encode_sample_description(AVCodecContext *avctx)
> +{
> +ASS * ass;
> +ASSStyle * style;
> +int i, j;
> +uint32_t tsmb_size, tsmb_type, back_color, style_color;
> +uint16_t style_start, style_end, fontID, count;
> +int font_names_total_len = 0;
> +MovTextContext *s = avctx->priv_data;
> +
> +static const uint8_t display_and_justification[] = {
> 0x00, 0x00, 0x00, 0x00, // uint32_t displayFlags
> 0x01, // int8_t horizontal-justification
> 0xFF, // int8_t vertical-justification
> -0x00, 0x00, 0x00, 0x00, // uint8_t background-color-rgba[4]
> -// BoxRecord {
> +};
> +// 0x00, 0x00, 0x00, 0x00, // uint8_t background-color-rgba[4]
Is this right? Should it be un-commented or removed entirely?
> +static const uint8_t box_record[] = {
> +// BoxRecord {
> 0x00, 0x00, // int16_t top
> 0x00, 0x00, // int16_t left
> 0x00, 0x00, // int16_t bottom
> 0x00, 0x00, // int16_t right
> -// };
> -// StyleRecord {
> -0x00, 0x00, // uint16_t startChar
> -0x00, 0x00, // uint16_t endChar
> -0x00, 0x01, // uint16_t font-ID
> -0x00, // uint8_t face-style-flags
> -0x12, // uint8_t font-size
> -0xFF, 0xFF, 0xFF, 0xFF, // uint8_t text-color-rgba[4]
> -// };
> -// FontTableBox {
> -0x00, 0x00, 0x00, 0x12, // uint32_t size
> -'f', 't', 'a', 'b', // uint8_t name[4]
> -0x00, 0x01, // uint16_t entry-count
> -// FontRecord {
> -0x00, 0x01, // uint16_t font-ID
> -0x05, // uint8_t font-name-length
> -'S', 'e', 'r', 'i', 'f',// uint8_t font[font-name-length]
> -// };
> -// };
> +// };
> };
> +// StyleRecord {
> +// 0x00, 0x00, // uint16_t startChar
> +// 0x00, 0x00, // uint16_t endChar
> +// 0x00, 0x01,
Re: [FFmpeg-devel] [PATCH 23/23] lavc/movtextenc: add option to scale fontsize with height
On Mon, 6 Apr 2020 11:52:18 -0600
John Stebbins wrote:
> If the video dimensions are different than the ASS play_res then the
> font sizes need to be adjusted to get the same apparent render size.
> ---
> libavcodec/movtextenc.c | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index a62bdb7eb0..3d4371b180 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -21,6 +21,7 @@
>
> #include
> #include "avcodec.h"
> +#include "libavutil/opt.h"
> #include "libavutil/avassert.h"
> #include "libavutil/avstring.h"
> #include "libavutil/intreadwrite.h"
> @@ -45,6 +46,7 @@
> #define DEFAULT_STYLE_FLAG 0x00
>
> #define BGR_TO_RGB(c) (((c) & 0xff) << 16 | ((c) & 0xff00) | (((c)
> >> 16) & 0xff)) +#define FONTSIZE_SCALE(s,fs) ((fs) *
> >> (s)->font_scale_factor + 0.5)
> #define av_bprint_append_any(buf, data, size)
> av_bprint_append_data(buf, ((const char*)data), size)
> typedef struct {
> @@ -66,6 +68,7 @@ typedef struct {
> } HilightcolorBox;
>
> typedef struct {
> +AVClass *class;
> AVCodecContext *avctx;
>
> ASSSplitContext *ass_ctx;
> @@ -81,6 +84,8 @@ typedef struct {
> uint16_t byte_count;
> char ** fonts;
> int font_count;
> +double font_scale_factor;
> +int frame_height;
> } MovTextContext;
>
> typedef struct {
> @@ -236,6 +241,13 @@ static int
> encode_sample_description(AVCodecContext *avctx)
> // Populate sample description from ASS header
> ass = ff_ass_get(s->ass_ctx);
> +// Compute font scaling factor based on (optionally) provided
> +// output video height and ASS script play_res_y
> +if (s->frame_height && ass->script_info.play_res_y)
> +s->font_scale_factor = (double)s->frame_height /
> ass->script_info.play_res_y;
> +else
> +s->font_scale_factor = 1;
> +
> style = ff_ass_style_get(s->ass_ctx, "Default");
> if (!style && ass->styles_count) {
> style = &ass->styles[0];
> @@ -245,7 +257,7 @@ static int
> encode_sample_description(AVCodecContext *avctx) s->d.style_color
> = DEFAULT_STYLE_COLOR; s->d.style_flag = DEFAULT_STYLE_FLAG;
> if (style) {
> -s->d.style_fontsize = style->font_size;
> +s->d.style_fontsize = FONTSIZE_SCALE(s, style->font_size);
> s->d.style_color = BGR_TO_RGB(style->primary_color &
> 0xff) << 8 | 255 - ((uint32_t)style->primary_color >> 24);
> s->d.style_flag = (!!style->bold * STYLE_FLAG_BOLD) |
> @@ -530,6 +542,7 @@ static void mov_text_font_name_cb(void *priv,
> const char *name)
> static void mov_text_font_size_set(MovTextContext *s, int size)
> {
> +size = FONTSIZE_SCALE(s, size);
> if (!s->style_attributes_temp ||
> s->style_attributes_temp->style_fontsize == size) {
> // color hasn't changed
> @@ -709,12 +722,27 @@ exit:
> return length;
> }
>
> +#define OFFSET(x) offsetof(MovTextContext, x)
> +#define FLAGS AV_OPT_FLAG_ENCODING_PARAM | AV_OPT_FLAG_SUBTITLE_PARAM
> +static const AVOption options[] = {
> +{ "height", "Frame height, usually video height",
> OFFSET(frame_height), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX, FLAGS },
> +{ NULL },
> +};
> +
> +static const AVClass mov_text_encoder_class = {
> +.class_name = "MOV text enoder",
> +.item_name = av_default_item_name,
> +.option = options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> AVCodec ff_movtext_encoder = {
> .name = "mov_text",
> .long_name = NULL_IF_CONFIG_SMALL("3GPP Timed Text
> subtitle"), .type = AVMEDIA_TYPE_SUBTITLE,
> .id = AV_CODEC_ID_MOV_TEXT,
> .priv_data_size = sizeof(MovTextContext),
> +.priv_class = &mov_text_encoder_class,
> .init = mov_text_encode_init,
> .encode_sub = mov_text_encode_frame,
> .close = mov_text_encode_close,
LGTM.
--phil
___
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 21/23] lavc/movtextenc: simplify initialization of new style record
On Mon, 6 Apr 2020 11:52:16 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 2e65489c4d..167dffee6a 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -96,8 +96,7 @@ static void mov_text_cleanup(MovTextContext *s)
> av_freep(&s->style_attributes);
> }
> if (s->style_attributes_temp) {
> -s->style_attributes_temp->style_flag = 0;
> -s->style_attributes_temp->style_start = 0;
> +*s->style_attributes_temp = s->d;
> }
> }
>
> @@ -122,7 +121,7 @@ static void encode_styl(MovTextContext *s,
> uint32_t tsmb_type) style_start =
> AV_RB16(&s->style_attributes[j]->style_start); style_end=
> AV_RB16(&s->style_attributes[j]->style_end); style_color =
> AV_RB32(&s->style_attributes[j]->style_color);
> -style_fontID = AV_RB16(&s->d.style_fontID);
> +style_fontID =
> AV_RB16(&s->style_attributes[j]->style_fontID);
> av_bprint_append_any(&s->buffer, &style_start, 2);
> av_bprint_append_any(&s->buffer, &style_end, 2);
> @@ -259,14 +258,10 @@ static int mov_text_style_start(MovTextContext
> *s) return 0;
> }
>
> -s->style_attributes_temp->style_flag =
> s->style_attributes[s->count - 1]->style_flag;
> -s->style_attributes_temp->style_color =
> s->style_attributes[s->count - 1]->style_color;
> -s->style_attributes_temp->style_fontsize =
> s->style_attributes[s->count - 1]->style_fontsize;
> +*s->style_attributes_temp = s->d;
> s->style_attributes_temp->style_start = s->text_pos;
> } else { // style entry matches defaults, drop entry
> -s->style_attributes_temp->style_flag = s->d.style_flag;
> -s->style_attributes_temp->style_color = s->d.style_color;
> -s->style_attributes_temp->style_fontsize =
> s->d.style_fontsize;
> +*s->style_attributes_temp = s->d;
> s->style_attributes_temp->style_start = s->text_pos;
> }
> return 1;
LGTM
--phil
___
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 20/23] lavc/movtextenc: handle cancel overrides callback
On Tue, 7 Apr 2020 09:00:34 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 43
> - 1 file changed, 34
> insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 9e657c9635..2d3c416407 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -69,6 +69,7 @@ typedef struct {
> AVCodecContext *avctx;
>
> ASSSplitContext *ass_ctx;
> +ASSStyle *ass_dialog_style;
> AVBPrint buffer;
> StyleBox **style_attributes;
> StyleBox *style_attributes_temp;
> @@ -396,9 +397,8 @@ static void mov_text_end_cb(void *priv)
> mov_text_style_start((MovTextContext*)priv);
> }
>
> -static void mov_text_dialog(MovTextContext *s, ASSDialog *dialog)
> +static void mov_text_ass_style_set(MovTextContext *s, ASSStyle
> *style) {
> -ASSStyle * style = ff_ass_style_get(s->ass_ctx, dialog->style);
> uint8_tstyle_flags, alpha;
> uint32_t color;
>
> @@ -412,9 +412,33 @@ static void mov_text_dialog(MovTextContext *s,
> ASSDialog *dialog) alpha = 255 - ((uint32_t)style->primary_color >>
> 24); mov_text_alpha_set(s, alpha);
> mov_text_font_size_set(s, style->font_size);
> +} else {
> +// End current style record, go back to defaults
> +mov_text_style_start(s);
> }
> }
>
> +static void mov_text_dialog(MovTextContext *s, ASSDialog *dialog)
> +{
> +ASSStyle * style = ff_ass_style_get(s->ass_ctx, dialog->style);
> +
> +s->ass_dialog_style = style;
> +mov_text_ass_style_set(s, style);
> +}
> +
> +static void mov_text_cancel_overrides_cb(void *priv, const char *
> style_name) +{
> +MovTextContext *s = priv;
> +ASSStyle * style;
> +
> +if (!style_name || !*style_name)
> +style = s->ass_dialog_style;
> +else
> +style= ff_ass_style_get(s->ass_ctx, style_name);
> +
> +mov_text_ass_style_set(s, style);
> +}
> +
> static uint16_t utf8_strlen(const char *text, int len)
> {
> uint16_t i = 0, ret = 0;
> @@ -454,13 +478,14 @@ static void mov_text_new_line_cb(void *priv,
> int forced) }
>
> static const ASSCodesCallbacks mov_text_callbacks = {
> -.text = mov_text_text_cb,
> -.new_line = mov_text_new_line_cb,
> -.style = mov_text_style_cb,
> -.color = mov_text_color_cb,
> -.alpha = mov_text_alpha_cb,
> -.font_size = mov_text_font_size_cb,
> -.end = mov_text_end_cb,
> +.text = mov_text_text_cb,
> +.new_line = mov_text_new_line_cb,
> +.style= mov_text_style_cb,
> +.color= mov_text_color_cb,
> +.alpha= mov_text_alpha_cb,
> +.font_size= mov_text_font_size_cb,
> +.cancel_overrides = mov_text_cancel_overrides_cb,
> +.end = mov_text_end_cb,
> };
>
> static int mov_text_encode_frame(AVCodecContext *avctx, unsigned
> char *buf,
LGTM
--phil
___
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 19/23] lavc/movtextenc: add font size tag handling
On Mon, 6 Apr 2020 11:52:14 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 39 ++-
> 1 file changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index e82393dde7..9e657c9635 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -128,7 +128,7 @@ static void encode_styl(MovTextContext *s,
> uint32_t tsmb_type) av_bprint_append_any(&s->buffer, &style_end, 2);
> av_bprint_append_any(&s->buffer, &style_fontID, 2);
> av_bprint_append_any(&s->buffer,
> &s->style_attributes[j]->style_flag, 1);
> -av_bprint_append_any(&s->buffer, &s->d.style_fontsize,
> 1);
> +av_bprint_append_any(&s->buffer,
> &s->style_attributes[j]->style_fontsize, 1);
> av_bprint_append_any(&s->buffer, &style_color, 4); }
> }
> @@ -244,8 +244,9 @@ static int mov_text_style_start(MovTextContext *s)
> if (s->style_attributes_temp->style_start == s->text_pos)
> // Still at same text pos, use same entry
> return 1;
> -if (s->style_attributes_temp->style_flag != s->d.style_flag ||
> -s->style_attributes_temp->style_color != s->d.style_color) {
> +if (s->style_attributes_temp->style_flag != s->d.style_flag
> ||
> +s->style_attributes_temp->style_color!= s->d.style_color
> ||
> +s->style_attributes_temp->style_fontsize !=
> s->d.style_fontsize) { // last style != defaults, end the style entry
> and start a new one s->box_flags |= STYL_BOX;
> s->style_attributes_temp->style_end = s->text_pos;
> @@ -260,10 +261,12 @@ static int mov_text_style_start(MovTextContext
> *s)
> s->style_attributes_temp->style_flag =
> s->style_attributes[s->count - 1]->style_flag;
> s->style_attributes_temp->style_color = s->style_attributes[s->count
> - 1]->style_color;
> +s->style_attributes_temp->style_fontsize =
> s->style_attributes[s->count - 1]->style_fontsize;
> s->style_attributes_temp->style_start = s->text_pos; } else { //
> style entry matches defaults, drop entry
> s->style_attributes_temp->style_flag = s->d.style_flag;
> s->style_attributes_temp->style_color = s->d.style_color;
> +s->style_attributes_temp->style_fontsize =
> s->d.style_fontsize; s->style_attributes_temp->style_start =
> s->text_pos; }
> return 1;
> @@ -371,6 +374,22 @@ static void mov_text_alpha_cb(void *priv, int
> alpha, int alpha_id) mov_text_alpha_set(s, 255 - alpha);
> }
>
> +static void mov_text_font_size_set(MovTextContext *s, int size)
> +{
> +if (!s->style_attributes_temp ||
> +s->style_attributes_temp->style_fontsize == size) {
> +// color hasn't changed
> +return;
> +}
> +if (mov_text_style_start(s))
> +s->style_attributes_temp->style_fontsize = size;
> +}
> +
> +static void mov_text_font_size_cb(void *priv, int size)
> +{
> +mov_text_font_size_set((MovTextContext*)priv, size);
> +}
> +
> static void mov_text_end_cb(void *priv)
> {
> // End of text, close any open style record
> @@ -392,6 +411,7 @@ static void mov_text_dialog(MovTextContext *s,
> ASSDialog *dialog) mov_text_color_set(s, color);
> alpha = 255 - ((uint32_t)style->primary_color >> 24);
> mov_text_alpha_set(s, alpha);
> +mov_text_font_size_set(s, style->font_size);
> }
> }
>
> @@ -434,12 +454,13 @@ static void mov_text_new_line_cb(void *priv,
> int forced) }
>
> static const ASSCodesCallbacks mov_text_callbacks = {
> -.text = mov_text_text_cb,
> -.new_line = mov_text_new_line_cb,
> -.style= mov_text_style_cb,
> -.color= mov_text_color_cb,
> -.alpha= mov_text_alpha_cb,
> -.end = mov_text_end_cb,
> +.text = mov_text_text_cb,
> +.new_line = mov_text_new_line_cb,
> +.style = mov_text_style_cb,
> +.color = mov_text_color_cb,
> +.alpha = mov_text_alpha_cb,
> +.font_size = mov_text_font_size_cb,
> +.end = mov_text_end_cb,
> };
>
> static int mov_text_encode_frame(AVCodecContext *avctx, unsigned
> char *buf,
LGTM
--phil
___
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 18/23] lavc/movtextenc: add alpha tag handling
On Mon, 6 Apr 2020 11:52:13 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 25 -
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 090536b887..e82393dde7 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -351,6 +351,26 @@ static void mov_text_color_cb(void *priv,
> unsigned int color, unsigned int color */
> }
>
> +static void mov_text_alpha_set(MovTextContext *s, uint8_t alpha)
> +{
> +if (!s->style_attributes_temp ||
> +(s->style_attributes_temp->style_color & 0xff) == alpha) {
> +// color hasn't changed
> +return;
> +}
> +if (mov_text_style_start(s))
> +s->style_attributes_temp->style_color =
> +(s->style_attributes_temp->style_color & 0xff00)
> | alpha; +}
> +
> +static void mov_text_alpha_cb(void *priv, int alpha, int alpha_id)
> +{
> +MovTextContext *s = priv;
> +
> +if (alpha_id == 1) // primary alpha changes
> +mov_text_alpha_set(s, 255 - alpha);
> +}
Worth a comment that secondary alpha can't be preserved?
> +
> static void mov_text_end_cb(void *priv)
> {
> // End of text, close any open style record
> @@ -360,7 +380,7 @@ static void mov_text_end_cb(void *priv)
> static void mov_text_dialog(MovTextContext *s, ASSDialog *dialog)
> {
> ASSStyle * style = ff_ass_style_get(s->ass_ctx, dialog->style);
> -uint8_tstyle_flags;
> +uint8_tstyle_flags, alpha;
> uint32_t color;
>
> if (style) {
> @@ -370,6 +390,8 @@ static void mov_text_dialog(MovTextContext *s,
> ASSDialog *dialog) mov_text_style_set(s, style_flags);
> color = BGR_TO_RGB(style->primary_color & 0xff) << 8;
> mov_text_color_set(s, color);
> +alpha = 255 - ((uint32_t)style->primary_color >> 24);
> +mov_text_alpha_set(s, alpha);
> }
> }
>
> @@ -416,6 +438,7 @@ static const ASSCodesCallbacks mov_text_callbacks
> = { .new_line = mov_text_new_line_cb,
> .style= mov_text_style_cb,
> .color= mov_text_color_cb,
> +.alpha= mov_text_alpha_cb,
> .end = mov_text_end_cb,
> };
>
Otherwise LGTM.
--phil
___
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 17/23] lavc/movtextenc: add color tag handling
On Mon, 6 Apr 2020 11:52:12 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 28
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 4e7d55efcb..090536b887 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -121,7 +121,7 @@ static void encode_styl(MovTextContext *s,
> uint32_t tsmb_type)
> style_start =
> AV_RB16(&s->style_attributes[j]->style_start); style_end=
> AV_RB16(&s->style_attributes[j]->style_end);
> -style_color = AV_RB32(&s->d.style_color);
> +style_color =
> AV_RB32(&s->style_attributes[j]->style_color); style_fontID =
> AV_RB16(&s->d.style_fontID);
> av_bprint_append_any(&s->buffer, &style_start, 2);
> @@ -244,7 +244,8 @@ static int mov_text_style_start(MovTextContext *s)
> if (s->style_attributes_temp->style_start == s->text_pos)
> // Still at same text pos, use same entry
> return 1;
> -if (s->style_attributes_temp->style_flag) {
> +if (s->style_attributes_temp->style_flag != s->d.style_flag ||
> +s->style_attributes_temp->style_color != s->d.style_color) {
> // last style != defaults, end the style entry and start a
> new one s->box_flags |= STYL_BOX;
> s->style_attributes_temp->style_end = s->text_pos;
> @@ -258,9 +259,11 @@ static int mov_text_style_start(MovTextContext
> *s) }
>
> s->style_attributes_temp->style_flag =
> s->style_attributes[s->count - 1]->style_flag;
> +s->style_attributes_temp->style_color =
> s->style_attributes[s->count - 1]->style_color;
> s->style_attributes_temp->style_start = s->text_pos; } else { //
> style entry matches defaults, drop entry
> -s->style_attributes_temp->style_flag = 0;
> +s->style_attributes_temp->style_flag = s->d.style_flag;
> +s->style_attributes_temp->style_color = s->d.style_color;
> s->style_attributes_temp->style_start = s->text_pos;
> }
> return 1;
> @@ -313,12 +316,26 @@ static void mov_text_style_cb(void *priv, const
> char style, int close) }
> }
>
> +static void mov_text_color_set(MovTextContext *s, uint32_t color)
> +{
> +if (!s->style_attributes_temp ||
> +(s->style_attributes_temp->style_color & 0xff00) ==
> color) {
> +// color hasn't changed
> +return;
> +}
> +if (mov_text_style_start(s))
> +s->style_attributes_temp->style_color = (color & 0xff00)
> |
> +(s->style_attributes_temp->style_color &
> 0xff); +}
> +
> static void mov_text_color_cb(void *priv, unsigned int color,
> unsigned int color_id) {
> MovTextContext *s = priv;
>
> color = BGR_TO_RGB(color) << 8;
> -if (color_id == 2) {//secondary color changes
> +if (color_id == 1) {//primary color changes
> +mov_text_color_set(s, color);
> +} else if (color_id == 2) {//secondary color changes
> if (s->box_flags & HLIT_BOX) { //close tag
> s->hlit.end = s->text_pos;
> } else {
> @@ -344,12 +361,15 @@ static void mov_text_dialog(MovTextContext *s,
> ASSDialog *dialog) {
> ASSStyle * style = ff_ass_style_get(s->ass_ctx, dialog->style);
> uint8_tstyle_flags;
> +uint32_t color;
>
> if (style) {
> style_flags = (!!style->bold * STYLE_FLAG_BOLD) |
>(!!style->italic* STYLE_FLAG_ITALIC) |
>(!!style->underline * STYLE_FLAG_UNDERLINE);
> mov_text_style_set(s, style_flags);
> +color = BGR_TO_RGB(style->primary_color & 0xff) << 8;
> +mov_text_color_set(s, color);
> }
> }
>
LGTM
--phil
___
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 16/23] lavc/movtextenc: init style record from ASS dialog style
On Mon, 6 Apr 2020 11:52:11 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 60
> ++--- 1 file changed, 50
> insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index d389111419..4e7d55efcb 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -39,6 +39,11 @@
> #define HLIT_BOX (1<<1)
> #define HCLR_BOX (1<<2)
>
> +#define DEFAULT_STYLE_FONT_ID 0x01
> +#define DEFAULT_STYLE_FONTSIZE 0x12
> +#define DEFAULT_STYLE_COLOR0x
> +#define DEFAULT_STYLE_FLAG 0x00
> +
> #define BGR_TO_RGB(c) (((c) & 0xff) << 16 | ((c) & 0xff00) | (((c)
> >> 16) & 0xff)) #define av_bprint_append_any(buf, data, size)
> >> av_bprint_append_data(buf, ((const char*)data), size)
>
> @@ -46,6 +51,9 @@ typedef struct {
> uint16_t style_start;
> uint16_t style_end;
> uint8_t style_flag;
> +uint16_t style_fontID;
> +uint8_t style_fontsize;
> +uint32_t style_color;
> } StyleBox;
>
> typedef struct {
> @@ -68,9 +76,7 @@ typedef struct {
> HilightcolorBox hclr;
> int count;
> uint8_t box_flags;
> -uint16_t style_fontID;
> -uint8_t style_fontsize;
> -uint32_t style_color;
> +StyleBox d;
> uint16_t text_pos;
> uint16_t byte_count;
> } MovTextContext;
> @@ -104,25 +110,26 @@ static void encode_styl(MovTextContext *s,
> uint32_t tsmb_type) tsmb_size = s->count * STYLE_RECORD_SIZE +
> SIZE_ADD; tsmb_size = AV_RB32(&tsmb_size);
> style_entries = AV_RB16(&s->count);
> -s->style_fontID = 0x00 | 0x01<<8;
> -s->style_fontsize = 0x12;
> -s->style_color = MKTAG(0xFF, 0xFF, 0xFF, 0xFF);
> /*The above three attributes are hard coded for now
> but will come from ASS style in the future*/
> av_bprint_append_any(&s->buffer, &tsmb_size, 4);
> av_bprint_append_any(&s->buffer, &tsmb_type, 4);
> av_bprint_append_any(&s->buffer, &style_entries, 2);
> for (j = 0; j < s->count; j++) {
> -uint16_t style_start, style_end;
> +uint16_t style_start, style_end, style_fontID;
> +uint32_t style_color;
>
> style_start =
> AV_RB16(&s->style_attributes[j]->style_start); style_end=
> AV_RB16(&s->style_attributes[j]->style_end);
> +style_color = AV_RB32(&s->d.style_color);
> +style_fontID = AV_RB16(&s->d.style_fontID);
> +
> av_bprint_append_any(&s->buffer, &style_start, 2);
> av_bprint_append_any(&s->buffer, &style_end, 2);
> -av_bprint_append_any(&s->buffer, &s->style_fontID, 2);
> +av_bprint_append_any(&s->buffer, &style_fontID, 2);
> av_bprint_append_any(&s->buffer,
> &s->style_attributes[j]->style_flag, 1);
> -av_bprint_append_any(&s->buffer, &s->style_fontsize, 1);
> -av_bprint_append_any(&s->buffer, &s->style_color, 4);
> +av_bprint_append_any(&s->buffer, &s->d.style_fontsize,
> 1);
> +av_bprint_append_any(&s->buffer, &style_color, 4);
> }
> }
> mov_text_cleanup(s);
> @@ -220,6 +227,13 @@ static av_cold int
> mov_text_encode_init(AVCodecContext *avctx) memcpy(avctx->extradata,
> text_sample_entry, avctx->extradata_size);
> s->ass_ctx = ff_ass_split(avctx->subtitle_header);
> +
> +// TODO: Initialize from ASS style record
> +s->d.style_fontID = DEFAULT_STYLE_FONT_ID;
> +s->d.style_fontsize = DEFAULT_STYLE_FONTSIZE;
> +s->d.style_color= DEFAULT_STYLE_COLOR;
> +s->d.style_flag = DEFAULT_STYLE_FLAG;
> +
> return s->ass_ctx ? 0 : AVERROR_INVALIDDATA;
> }
>
> @@ -270,6 +284,17 @@ static uint8_t mov_text_style_to_flag(const char
> style) return style_flag;
> }
>
> +static void mov_text_style_set(MovTextContext *s, uint8_t
> style_flags) +{
> +if (!s->style_attributes_temp ||
> +!((s->style_attributes_temp->style_flag & style_flags) ^
> style_flags)) {
> +// setting flags that that are already set
> +return;
> +}
> +if (mov_text_style_start(s))
> +s->style_attributes_temp->style_flag |= style_flags;
> +}
> +
> static void mov_text_style_cb(void *priv, const char style, int
> close) {
> MovTextContext *s = priv;
> @@ -315,6 +340,19 @@ static void mov_text_end_cb(void *priv)
> mov_text_style_start((MovTextContext*)priv);
> }
>
> +static void mov_text_dialog(MovTextContext *s, ASSDialog *dialog)
> +{
> +ASSStyle * style = ff_ass_style_get(s->ass_ctx, dialog->style);
> +uint8_tstyle_flags;
> +
> +if (style) {
> +style_flags = (!!style->bold * STYLE_FLAG_BOLD) |
> + (!!style->italic* STYLE_FLAG_ITALIC) |
> + (!!style->underline * STYLE_FLAG_UNDERLINE);
> +mov_text_style_set(s, style_flags);
> +}
> +}
> +
> static uint16_t utf8_strlen(const char *text, int len)
> {
> uint16_t i =
Re: [FFmpeg-devel] [PATCH 11/23] lavc/ass_split: fix parsing utf8 scripts
On Mon, 6 Apr 2020 12:35:32 -0600
John Stebbins wrote:
> The [Script Info] section was skipped if starts with UTF8 BOM
> ---
> libavcodec/ass_split.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/ass_split.c b/libavcodec/ass_split.c
> index 67da7c6d84..c2c388d9f0 100644
> --- a/libavcodec/ass_split.c
> +++ b/libavcodec/ass_split.c
> @@ -376,6 +376,8 @@ ASSSplitContext *ff_ass_split(const char *buf)
> ASSSplitContext *ctx = av_mallocz(sizeof(*ctx));
> if (!ctx)
> return NULL;
> +if (buf && !memcmp(buf, "\xef\xbb\xbf", 3)) // Skip UTF-8 BOM
> header
> +buf += 3;
> ctx->current_section = -1;
> if (ass_split(ctx, buf) < 0) {
> ff_ass_split_free(ctx);
LGTM
--phil
___
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 10/23] lavc/movtextdec: allow setting subtitle frame dimensions
On Mon, 6 Apr 2020 11:52:05 -0600
John Stebbins wrote:
> Font sizes are relative to the subtitle frame dimensions. If the
> expected frame dimensions are not known, the font sizes will most
> likely be incorrect.
> ---
> libavcodec/ass.c| 30 +++---
> libavcodec/ass.h| 28
> libavcodec/movtextdec.c | 30 +-
> 3 files changed, 80 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/ass.c b/libavcodec/ass.c
> index a51673fb4e..7c26e3fd6d 100644
> --- a/libavcodec/ass.c
> +++ b/libavcodec/ass.c
> @@ -26,11 +26,13 @@
> #include "libavutil/bprint.h"
> #include "libavutil/common.h"
>
> -int ff_ass_subtitle_header(AVCodecContext *avctx,
> - const char *font, int font_size,
> - int color, int back_color,
> - int bold, int italic, int underline,
> - int border_style, int alignment)
> +int ff_ass_subtitle_header_full(AVCodecContext *avctx,
> +int play_res_x, int play_res_y,
> +const char *font, int font_size,
> +int primary_color, int
> secondary_color,
> +int outline_color, int back_color,
> +int bold, int italic, int underline,
> +int border_style, int alignment)
> {
> avctx->subtitle_header = av_asprintf(
> "[Script Info]\r\n"
> @@ -67,8 +69,8 @@ int ff_ass_subtitle_header(AVCodecContext *avctx,
> "[Events]\r\n"
> "Format: Layer, Start, End, Style, Name, MarginL,
> MarginR, MarginV, Effect, Text\r\n", !(avctx->flags &
> AV_CODEC_FLAG_BITEXACT) ? AV_STRINGIFY(LIBAVCODEC_VERSION) : "",
> - ASS_DEFAULT_PLAYRESX, ASS_DEFAULT_PLAYRESY,
> - font, font_size, color, color, back_color, back_color,
> + play_res_x, play_res_y, font, font_size,
> + primary_color, secondary_color, outline_color,
> back_color, -bold, -italic, -underline, border_style, alignment);
>
> if (!avctx->subtitle_header)
> @@ -77,6 +79,20 @@ int ff_ass_subtitle_header(AVCodecContext *avctx,
> return 0;
> }
>
> +int ff_ass_subtitle_header(AVCodecContext *avctx,
> + const char *font, int font_size,
> + int color, int back_color,
> + int bold, int italic, int underline,
> + int border_style, int alignment)
> +{
> +return ff_ass_subtitle_header_full(avctx,
> + ASS_DEFAULT_PLAYRESX,
> ASS_DEFAULT_PLAYRESY,
> + font, font_size, color, color,
> + back_color, back_color,
> + bold, italic, underline,
> + border_style, alignment);
> +}
> +
> int ff_ass_subtitle_header_default(AVCodecContext *avctx)
> {
> return ff_ass_subtitle_header(avctx, ASS_DEFAULT_FONT,
> diff --git a/libavcodec/ass.h b/libavcodec/ass.h
> index 314b43b686..2c260e4e78 100644
> --- a/libavcodec/ass.h
> +++ b/libavcodec/ass.h
> @@ -47,6 +47,34 @@ typedef struct FFASSDecoderContext {
> int readorder;
> } FFASSDecoderContext;
>
> +/**
> + * Generate a suitable AVCodecContext.subtitle_header for
> SUBTITLE_ASS.
> + * Can specify all fields explicitly
> + *
> + * @param avctx pointer to the AVCodecContext
> + * @param play_res_x subtitle frame width
> + * @param play_res_y subtitle frame height
> + * @param font name of the default font face to use
> + * @param font_size default font size to use
> + * @param primary_color default text color to use (ABGR)
> + * @param secondary_color default secondary text color to use (ABGR)
> + * @param outline_color default outline color to use (ABGR)
> + * @param back_color default background color to use (ABGR)
> + * @param bold 1 for bold text, 0 for normal text
> + * @param italic 1 for italic text, 0 for normal text
> + * @param underline 1 for underline text, 0 for normal text
> + * @param border_style 1 for outline, 3 for opaque box
> + * @param alignment position of the text (left, center, top...),
> defined after
> + * the layout of the numpad (1-3 sub, 4-6 mid, 7-9
> top)
> + * @return >= 0 on success otherwise an error code <0
> + */
> +int ff_ass_subtitle_header_full(AVCodecContext *avctx,
> +int play_res_x, int play_res_y,
> +const char *font, int font_size,
> +int primary_color, int
> secondary_color,
> +int outline_color, int back_color,
> +int bold, int italic, int underline,
> +int border_style, int alignment);
> /**
> * Generate a suitable AVCodecContext.subtitl
Re: [FFmpeg-devel] [PATCH 14/23] lavc/movtextenc: simplify style record updates
On Mon, 6 Apr 2020 11:52:09 -0600
John Stebbins wrote:
> Makes style update code easier to extend for style types not yet
> handled ---
> libavcodec/movtextenc.c | 131
> +++- 1 file changed, 62
> insertions(+), 69 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 5e5b786f44..05532cd544 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -89,6 +89,10 @@ static void mov_text_cleanup(MovTextContext *s)
> }
> av_freep(&s->style_attributes);
> }
> +if (s->style_attributes_temp) {
> +s->style_attributes_temp->style_flag = 0;
> +s->style_attributes_temp->style_start = 0;
> +}
> }
>
> static void encode_styl(MovTextContext *s, uint32_t tsmb_type)
> @@ -96,7 +100,7 @@ static void encode_styl(MovTextContext *s,
> uint32_t tsmb_type) int j;
> uint32_t tsmb_size;
> uint16_t style_entries;
> -if (s->box_flags & STYL_BOX) {
> +if ((s->box_flags & STYL_BOX) && s->count) {
> tsmb_size = s->count * STYLE_RECORD_SIZE + SIZE_ADD;
> tsmb_size = AV_RB32(&tsmb_size);
> style_entries = AV_RB16(&s->count);
> @@ -120,8 +124,8 @@ static void encode_styl(MovTextContext *s,
> uint32_t tsmb_type) av_bprint_append_any(&s->buffer,
> &s->style_fontsize, 1); av_bprint_append_any(&s->buffer,
> &s->style_color, 4); }
> -mov_text_cleanup(s);
> }
> +mov_text_cleanup(s);
> }
>
> static void encode_hlit(MovTextContext *s, uint32_t tsmb_type)
> @@ -201,6 +205,11 @@ static av_cold int
> mov_text_encode_init(AVCodecContext *avctx) MovTextContext *s =
> avctx->priv_data; s->avctx = avctx;
>
> +s->style_attributes_temp =
> av_mallocz(sizeof(*s->style_attributes_temp));
> +if (!s->style_attributes_temp) {
> +return AVERROR(ENOMEM);
> +}
> +
> avctx->extradata_size = sizeof text_sample_entry;
> avctx->extradata = av_mallocz(avctx->extradata_size +
> AV_INPUT_BUFFER_PADDING_SIZE); if (!avctx->extradata)
> @@ -214,85 +223,69 @@ static av_cold int
> mov_text_encode_init(AVCodecContext *avctx) return s->ass_ctx ? 0 :
> AVERROR_INVALIDDATA; }
>
> -static void mov_text_style_cb(void *priv, const char style, int
> close) +// Start a new style box if needed
> +static int mov_text_style_start(MovTextContext *s)
> {
> -MovTextContext *s = priv;
> -if (!close) {
> -if (!(s->box_flags & STYL_BOX)) { //first style entry
> -
> -s->style_attributes_temp =
> av_malloc(sizeof(*s->style_attributes_temp)); -
> -if (!s->style_attributes_temp) {
> -av_bprint_clear(&s->buffer);
> -s->box_flags &= ~STYL_BOX;
> -return;
> -}
> -
> -s->style_attributes_temp->style_flag = 0;
> -s->style_attributes_temp->style_start = s->text_pos;
> -} else {
> -if (s->style_attributes_temp->style_flag) { //break the
> style record here and start a new one
> -s->style_attributes_temp->style_end = s->text_pos;
> -av_dynarray_add(&s->style_attributes, &s->count,
> s->style_attributes_temp);
> -s->style_attributes_temp =
> av_malloc(sizeof(*s->style_attributes_temp));
> -if (!s->style_attributes_temp) {
> -mov_text_cleanup(s);
> -av_bprint_clear(&s->buffer);
> -s->box_flags &= ~STYL_BOX;
> -return;
> -}
> -
> -s->style_attributes_temp->style_flag =
> s->style_attributes[s->count - 1]->style_flag;
> -s->style_attributes_temp->style_start = s->text_pos;
> -} else {
> -s->style_attributes_temp->style_flag = 0;
> -s->style_attributes_temp->style_start = s->text_pos;
> -}
> -}
> -switch (style){
> -case 'b':
> -s->style_attributes_temp->style_flag |= STYLE_FLAG_BOLD;
> -break;
> -case 'i':
> -s->style_attributes_temp->style_flag |=
> STYLE_FLAG_ITALIC;
> -break;
> -case 'u':
> -s->style_attributes_temp->style_flag |=
> STYLE_FLAG_UNDERLINE;
> -break;
> -}
> -} else if (!s->style_attributes_temp) {
> -av_log(s->avctx, AV_LOG_WARNING, "Ignoring unmatched close
> tag\n");
> -return;
> -} else {
> +// there's an existing style entry
> +if (s->style_attributes_temp->style_start == s->text_pos)
> +// Still at same text pos, use same entry
> +return 1;
> +if (s->style_attributes_temp->style_flag) {
> +// last style != defaults, end the style entry and start a
> new one
> +s->box_flags |= STYL_BOX;
> s->style_attributes_temp->style_end = s->text_pos;
> av_dynarray_add(&s->style_attributes, &s->count,
> s->style_attributes_temp); -
> s->style_attributes_temp =
> av
Re: [FFmpeg-devel] [PATCH 15/23] lavc/movtextenc: fix unclosed style records
On Mon, 6 Apr 2020 11:52:10 -0600
John Stebbins wrote:
> The last record at the end of each dialog was never closed
> ---
> libavcodec/movtextenc.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 05532cd544..d389111419 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -309,6 +309,12 @@ static void mov_text_color_cb(void *priv,
> unsigned int color, unsigned int color */
> }
>
> +static void mov_text_end_cb(void *priv)
> +{
> +// End of text, close any open style record
> +mov_text_style_start((MovTextContext*)priv);
> +}
> +
> static uint16_t utf8_strlen(const char *text, int len)
> {
> uint16_t i = 0, ret = 0;
> @@ -352,6 +358,7 @@ static const ASSCodesCallbacks mov_text_callbacks
> = { .new_line = mov_text_new_line_cb,
> .style= mov_text_style_cb,
> .color= mov_text_color_cb,
> +.end = mov_text_end_cb,
> };
>
> static int mov_text_encode_frame(AVCodecContext *avctx, unsigned
> char *buf,
LGTM
--phil
___
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 13/23] lavc/movtextenc: keep values in native byte order till written
On Mon, 6 Apr 2020 11:52:08 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 38 ++
> 1 file changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 8638e303fe..5e5b786f44 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -68,7 +68,6 @@ typedef struct {
> HilightcolorBox hclr;
> int count;
> uint8_t box_flags;
> -uint16_t style_entries;
> uint16_t style_fontID;
> uint8_t style_fontsize;
> uint32_t style_color;
> @@ -96,10 +95,11 @@ static void encode_styl(MovTextContext *s,
> uint32_t tsmb_type) {
> int j;
> uint32_t tsmb_size;
> +uint16_t style_entries;
> if (s->box_flags & STYL_BOX) {
> tsmb_size = s->count * STYLE_RECORD_SIZE + SIZE_ADD;
> tsmb_size = AV_RB32(&tsmb_size);
> -s->style_entries = AV_RB16(&s->count);
> +style_entries = AV_RB16(&s->count);
> s->style_fontID = 0x00 | 0x01<<8;
> s->style_fontsize = 0x12;
> s->style_color = MKTAG(0xFF, 0xFF, 0xFF, 0xFF);
> @@ -107,10 +107,14 @@ static void encode_styl(MovTextContext *s,
> uint32_t tsmb_type) but will come from ASS style in the future*/
> av_bprint_append_any(&s->buffer, &tsmb_size, 4);
> av_bprint_append_any(&s->buffer, &tsmb_type, 4);
> -av_bprint_append_any(&s->buffer, &s->style_entries, 2);
> +av_bprint_append_any(&s->buffer, &style_entries, 2);
> for (j = 0; j < s->count; j++) {
> -av_bprint_append_any(&s->buffer,
> &s->style_attributes[j]->style_start, 2);
> -av_bprint_append_any(&s->buffer,
> &s->style_attributes[j]->style_end, 2);
> +uint16_t style_start, style_end;
> +
> +style_start =
> AV_RB16(&s->style_attributes[j]->style_start);
> +style_end=
> AV_RB16(&s->style_attributes[j]->style_end);
> +av_bprint_append_any(&s->buffer, &style_start, 2);
> +av_bprint_append_any(&s->buffer, &style_end, 2);
> av_bprint_append_any(&s->buffer, &s->style_fontID, 2);
> av_bprint_append_any(&s->buffer,
> &s->style_attributes[j]->style_flag, 1);
> av_bprint_append_any(&s->buffer, &s->style_fontsize, 1); @@ -123,13
> +127,16 @@ static void encode_styl(MovTextContext *s, uint32_t
> tsmb_type) static void encode_hlit(MovTextContext *s, uint32_t
> tsmb_type) { uint32_t tsmb_size;
> +uint16_t start, end;
> if (s->box_flags & HLIT_BOX) {
> tsmb_size = 12;
> tsmb_size = AV_RB32(&tsmb_size);
> +start = AV_RB16(&s->hlit.start);
> +end = AV_RB16(&s->hlit.end);
> av_bprint_append_any(&s->buffer, &tsmb_size, 4);
> av_bprint_append_any(&s->buffer, &tsmb_type, 4);
> -av_bprint_append_any(&s->buffer, &s->hlit.start, 2);
> -av_bprint_append_any(&s->buffer, &s->hlit.end, 2);
> +av_bprint_append_any(&s->buffer, &start, 2);
> +av_bprint_append_any(&s->buffer, &end, 2);
> }
> }
>
> @@ -222,10 +229,10 @@ static void mov_text_style_cb(void *priv, const
> char style, int close) }
>
> s->style_attributes_temp->style_flag = 0;
> -s->style_attributes_temp->style_start =
> AV_RB16(&s->text_pos);
> +s->style_attributes_temp->style_start = s->text_pos;
> } else {
> if (s->style_attributes_temp->style_flag) { //break the
> style record here and start a new one
> -s->style_attributes_temp->style_end =
> AV_RB16(&s->text_pos);
> +s->style_attributes_temp->style_end = s->text_pos;
> av_dynarray_add(&s->style_attributes, &s->count,
> s->style_attributes_temp); s->style_attributes_temp =
> av_malloc(sizeof(*s->style_attributes_temp)); if
> (!s->style_attributes_temp) { @@ -236,10 +243,10 @@ static void
> mov_text_style_cb(void *priv, const char style, int close) }
>
> s->style_attributes_temp->style_flag =
> s->style_attributes[s->count - 1]->style_flag;
> -s->style_attributes_temp->style_start =
> AV_RB16(&s->text_pos);
> +s->style_attributes_temp->style_start = s->text_pos;
> } else {
> s->style_attributes_temp->style_flag = 0;
> -s->style_attributes_temp->style_start =
> AV_RB16(&s->text_pos);
> +s->style_attributes_temp->style_start = s->text_pos;
> }
> }
> switch (style){
> @@ -257,7 +264,7 @@ static void mov_text_style_cb(void *priv, const
> char style, int close) av_log(s->avctx, AV_LOG_WARNING, "Ignoring
> unmatched close tag\n"); return;
> } else {
> -s->style_attributes_temp->style_end = AV_RB16(&s->text_pos);
> +s->style_attributes_temp->style_end = s->text_pos;
> av_dynarray_add(&s->style_attributes, &s->count,
> s->style_attributes_temp);
> s->style_attributes_temp =
> av_
Re: [FFmpeg-devel] [PATCH 12/23] lavc/movtextenc: use correct color component order
On Mon, 6 Apr 2020 11:52:07 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index c19ef384bc..8638e303fe 100644
> --- a/libavcodec/movtextenc.c
> +++ b/libavcodec/movtextenc.c
> @@ -39,6 +39,7 @@
> #define HLIT_BOX (1<<1)
> #define HCLR_BOX (1<<2)
>
> +#define BGR_TO_RGB(c) (((c) & 0xff) << 16 | ((c) & 0xff00) | (((c)
> >> 16) & 0xff)) #define av_bprint_append_any(buf, data, size)
> >> av_bprint_append_data(buf, ((const char*)data), size)
>
> typedef struct {
> @@ -134,13 +135,14 @@ static void encode_hlit(MovTextContext *s,
> uint32_t tsmb_type)
> static void encode_hclr(MovTextContext *s, uint32_t tsmb_type)
> {
> -uint32_t tsmb_size;
> +uint32_t tsmb_size, color;
> if (s->box_flags & HCLR_BOX) {
> tsmb_size = 12;
> tsmb_size = AV_RB32(&tsmb_size);
> +color = AV_RB32(&s->hclr.color);
> av_bprint_append_any(&s->buffer, &tsmb_size, 4);
> av_bprint_append_any(&s->buffer, &tsmb_type, 4);
> -av_bprint_append_any(&s->buffer, &s->hclr.color, 4);
> +av_bprint_append_any(&s->buffer, &color, 4);
> }
> }
>
> @@ -289,6 +291,8 @@ static void mov_text_style_cb(void *priv, const
> char style, int close) static void mov_text_color_cb(void *priv,
> unsigned int color, unsigned int color_id) {
> MovTextContext *s = priv;
> +
> +color = BGR_TO_RGB(color) << 8;
> if (color_id == 2) {//secondary color changes
> if (s->box_flags & HLIT_BOX) { //close tag
> s->hlit.end = AV_RB16(&s->text_pos);
> @@ -296,7 +300,7 @@ static void mov_text_color_cb(void *priv,
> unsigned int color, unsigned int color s->box_flags |= HCLR_BOX;
> s->box_flags |= HLIT_BOX;
> s->hlit.start = AV_RB16(&s->text_pos);
> -s->hclr.color = color | (0xFF << 24); //set alpha value
> to FF
> +s->hclr.color = color | 0xFF; //set alpha value to FF
> }
> }
> /* If there are more than one secondary color changes in ASS,
> take start of
LGTM
--phil
___
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".
