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(>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, ,
> vaflags); +#else
> vas = vaMapBuffer(hwctx->display, map->image.buf, );
> +#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,
> _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".
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]
On 2019-04-06 09:42, Balint Marton wrote: Hi All Here is a call for the people in the voting committee [1] on the decision of extending it. Using the same guidelines as in the second extension [2], the following candidates were found: git log libav/master..master --no-merges --since=2018-03-30T00:00:00Z --until 2019-03-30T00:00:00Z --pretty=fuller | grep '^Commit:' | sed 's/<.*//' |sort | uniq -c | sort -nr 662 Commit: Michael Niedermayer 528 Commit: Paul B Mahol 227 Commit: James Almer 194 Commit: Carl Eugen Hoyos 183 Commit: Mark Thompson 141 Commit: Marton Balint 99 Commit: Jun Zhao 84 Commit: Steven Liu 73 Commit: Martin Vignali 64 Commit: Gyan Doshi 55 Commit: Aman Gupta 42 Commit: Timo Rothenpieler 35 Commit: Zhong Li 31 Commit: Karthick Jeyapal 31 Commit: Karthick J 23 Commit: Rostislav Pehlivanov 22 Commit: Peter Ross 22 Commit: Clément Bœsch 21 Commit: Lou Logan 21 Commit: Jan Ekström Some of these developers are already in the voting committee, the new ones would be: Aman Gupta Gyan Doshi Jan Ekström Jun Zhao Karthick Jeyapal Mark Thompson Martin Vignali Peter Ross Steven Liu Timo Rothenpieler Zhong Li Question: Do you support extending the voting committte with the people above? Yes. --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] [DECISION] Include more developers in the voting committee [#4]
On 2019-04-08 12:10, Marton Balint wrote: I emailed Marton out-of-band, but I am not in the list because a few of my recent commits were pushed by Timo instead of me pushing them directly. My authored list is 23 commits but 4 were pushed by Timo, so Marton's command line returns '19' for me. You know you are already in the committe because you were included in the second extension, right? :) Hah. No, I did not realise that; in my defence, it was a long time ago. I guess I should also apologise for not voting. :-) I said that if we are excluding people without commit rights, then we need to correctly assign commit ownership when the author and committer both have commit rights to avoid mis-counting. Obviously the metric can be improved, but since this is only a guideline to gather a list for an extension proposal, it is not that big of a deal if it is not perfect. With some scripting I guess it is doable to count authorship then exclude people who have not committed (therefore have no commit rights). Right. It's likely I'm the only person that this affected, and now it turns out I'm not actually affected, but something to do next time round. 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] [DECISION] Include more developers in the voting committee [#4]
On 2019-04-06 10:35, Marton Balint wrote: On Sat, 6 Apr 2019, Jean-Baptiste Kempf wrote: Hello, On Sat, 6 Apr 2019, at 18:42, Balint Marton wrote: Here is a call for the people in the voting committee [1] on the decision of extending it. Why do you limit at those ones? There are more commiters, even in the last year. I don't see Philip or Vittorio, for example. Same guidelines were used to select the people as in the second extension: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182057.html I emailed Marton out-of-band, but I am not in the list because a few of my recent commits were pushed by Timo instead of me pushing them directly. My authored list is 23 commits but 4 were pushed by Timo, so Marton's command line returns '19' for me. I said that if we are excluding people without commit rights, then we need to correctly assign commit ownership when the author and committer both have commit rights to avoid mis-counting. --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/2] vf_crop: Add support for cropping hardware frames
On Sat, 23 Mar 2019 16:18:48 +
Mark Thompson wrote:
> Set the cropping fields in the AVFrame.
> ---
> libavfilter/vf_crop.c | 74
> +-- 1 file changed, 51
> insertions(+), 23 deletions(-)
>
> There is the slightly unfortunate effect the filter links don't carry
> the cropping information, so we don't know how big the cropped output
> is in following links until we actually get a frame.
>
> For example, to get the middle ninth of a stream:
>
> ./ffmpeg_g -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
> -hwaccel_output_format vaapi -i in.mp4 -an -vf
> "crop=iw/3:ih/3:iw/3:ih/3,scale_vaapi=iw/3:ih/3" -c:v h264_vaapi
> out.mp4
>
> Without the extra arguments to scale it will take the cropped part
> correctly but then scale it to the original size.
>
> diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c
> index 84be4c7d0d..7f6b0f03d3 100644
> --- a/libavfilter/vf_crop.c
> +++ b/libavfilter/vf_crop.c
> @@ -98,9 +98,17 @@ static int query_formats(AVFilterContext *ctx)
>
> for (fmt = 0; av_pix_fmt_desc_get(fmt); fmt++) {
> const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
> -if (!(desc->flags & (AV_PIX_FMT_FLAG_HWACCEL |
> AV_PIX_FMT_FLAG_BITSTREAM)) &&
> -!((desc->log2_chroma_w || desc->log2_chroma_h)
> && !(desc->flags & AV_PIX_FMT_FLAG_PLANAR)) &&
> -(ret = ff_add_format(, fmt)) < 0)
> +if (desc->flags & AV_PIX_FMT_FLAG_BITSTREAM)
> +continue;
> +if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL)) {
> +// Not usable if there is any subsampling but the format
> is
> +// not planar (e.g. YUYV422).
> +if ((desc->log2_chroma_w || desc->log2_chroma_h) &&
> +!(desc->flags & AV_PIX_FMT_FLAG_PLANAR))
> +continue;
> +}
> +ret = ff_add_format(, fmt);
> +if (ret < 0)
> return ret;
> }
>
> @@ -157,8 +165,14 @@ static int config_input(AVFilterLink *link)
> s->var_values[VAR_POS] = NAN;
>
> av_image_fill_max_pixsteps(s->max_step, NULL, pix_desc);
> -s->hsub = pix_desc->log2_chroma_w;
> -s->vsub = pix_desc->log2_chroma_h;
> +
> +if (pix_desc->flags & AV_PIX_FMT_FLAG_HWACCEL) {
> +s->hsub = 1;
> +s->vsub = 1;
> +} else {
> +s->hsub = pix_desc->log2_chroma_w;
> +s->vsub = pix_desc->log2_chroma_h;
> +}
>
> if ((ret = av_expr_parse_and_eval(, (expr = s->w_expr),
>var_names, s->var_values,
> @@ -237,9 +251,15 @@ fail_expr:
> static int config_output(AVFilterLink *link)
> {
> CropContext *s = link->src->priv;
> +const AVPixFmtDescriptor *desc =
> av_pix_fmt_desc_get(link->format);
> -link->w = s->w;
> -link->h = s->h;
> +if (desc->flags & AV_PIX_FMT_FLAG_HWACCEL) {
> +// Hardware frames adjust the cropping regions rather than
> +// changing the frame size.
> +} else {
> +link->w = s->w;
> +link->h = s->h;
> +}
> link->sample_aspect_ratio = s->out_sar;
>
> return 0;
> @@ -252,9 +272,6 @@ static int filter_frame(AVFilterLink *link,
> AVFrame *frame) const AVPixFmtDescriptor *desc =
> av_pix_fmt_desc_get(link->format); int i;
>
> -frame->width = s->w;
> -frame->height = s->h;
> -
> s->var_values[VAR_N] = link->frame_count_out;
> s->var_values[VAR_T] = frame->pts == AV_NOPTS_VALUE ?
> NAN : frame->pts * av_q2d(link->time_base);
> @@ -285,22 +302,33 @@ static int filter_frame(AVFilterLink *link,
> AVFrame *frame) (int)s->var_values[VAR_N], s->var_values[VAR_T],
> s->var_values[VAR_POS], s->x, s->y, s->x+s->w, s->y+s->h);
>
> -frame->data[0] += s->y * frame->linesize[0];
> -frame->data[0] += s->x * s->max_step[0];
> -
> -if (!(desc->flags & AV_PIX_FMT_FLAG_PAL || desc->flags &
> FF_PSEUDOPAL)) {
> -for (i = 1; i < 3; i ++) {
> -if (frame->data[i]) {
> -frame->data[i] += (s->y >> s->vsub) *
> frame->linesize[i];
> -frame->data[i] += (s->x * s->max_step[i]) >> s->hsub;
> +if (desc->flags & AV_PIX_FMT_FLAG_HWACCEL) {
> +frame->crop_top += s->y;
> +frame->crop_left += s->x;
> +frame->crop_bottom = frame->height - frame->crop_top -
> frame->crop_bottom - s->h;
> +frame->crop_right = frame->width - frame->crop_left -
> frame->crop_right - s->w; +
> +} else {
> +frame->width = s->w;
> +frame->height = s->h;
> +
> +frame->data[0] += s->y * frame->linesize[0];
> +frame->data[0] += s->x * s->max_step[0];
> +
> +if (!(desc->flags & AV_PIX_FMT_FLAG_PAL || desc->flags &
> FF_PSEUDOPAL)) {
> +for (i = 1; i < 3; i ++) {
> +if (frame->data[i]) {
> +frame->data[i] += (s->y >> s->vsub) *
> frame->linesize[i];
> +frame->data[i] += (s->x * s->max_step[i]) >>
> s->hsub;
> +
Re: [FFmpeg-devel] [PATCH][FFmpeg-devel v2] Add GPU accelerated video crop filter
On Sat, 23 Mar 2019 23:51:10 +0800
UsingtcNower wrote:
> Signed-off-by: UsingtcNower
> ---
> Changelog | 1 +
> configure | 1 +
> doc/filters.texi| 31 +++
> libavfilter/Makefile| 1 +
> libavfilter/allfilters.c| 1 +
> libavfilter/version.h | 2 +-
> libavfilter/vf_crop_cuda.c | 638
>
> libavfilter/vf_crop_cuda.cu | 109 8 files changed, 783
> insertions(+), 1 deletion(-) create mode 100644
> libavfilter/vf_crop_cuda.c create mode 100644
> libavfilter/vf_crop_cuda.cu
>
> diff --git a/Changelog b/Changelog
> index ad7e82f..f224fc8 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -20,6 +20,7 @@ version :
> - libaribb24 based ARIB STD-B24 caption support (profiles A and C)
> - Support decoding of HEVC 4:4:4 content in nvdec and cuviddec
> - removed libndi-newtek
> +- crop_cuda GPU accelerated video crop filter
Hi,
Timo and Mark and I have been discussing this, and we think the right
thing to do is add support to vf_scale_cuda to respect the crop
properties on an input AVFrame. Mark posted a patch to vf_crop to
ensure that the properties are set, and then the scale filter should
respect those properties if they are set. You can look at
vf_scale_vaapi for how the properties are read, but they will require
explicit handling to adjust the src dimensions passed to the scale
filter.
This will be a more efficient way of handling crops, in terms of total
lines of code and also allowing crop/scale with one less copy.
I know this is quite different from the approach you've taken here, and
we appreciate the work you've done, but it should be better overall to
implement this integrated method.
Thanks,
>
> version 4.1:
> diff --git a/configure b/configure
> index 331393f..3f3ac2f 100755
> --- a/configure
> +++ b/configure
> @@ -2973,6 +2973,7 @@ qsvvpp_select="qsv"
> vaapi_encode_deps="vaapi"
> v4l2_m2m_deps="linux_videodev2_h sem_timedwait"
>
> +crop_cuda_filter_deps="ffnvcodec cuda_nvcc"
> hwupload_cuda_filter_deps="ffnvcodec"
> scale_npp_filter_deps="ffnvcodec libnpp"
> scale_cuda_filter_deps="ffnvcodec cuda_nvcc"
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 4ffb392..ee16a2d 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -7415,6 +7415,37 @@ If the specified expression is not valid, it
> is kept at its current value.
> @end table
>
> +@section crop_cuda
> +
> +Crop the input video to given dimensions, implemented in CUDA.
> +
> +It accepts the following parameters:
> +
> +@table @option
> +
> +@item w
> +The width of the output video. It defaults to @code{iw}.
> +This expression is evaluated only once during the filter
> +configuration.
> +
> +@item h
> +The height of the output video. It defaults to @code{ih}.
> +This expression is evaluated only once during the filter
> +configuration.
> +
> +@item x
> +The horizontal position, in the input video, of the left edge of the
> output +video. It defaults to @code{(in_w-out_w)/2}.
> +This expression is evaluated only once during the filter
> +configuration.
> +
> +@item y
> +The vertical position, in the input video, of the top edge of the
> output video. +It defaults to @code{(in_h-out_h)/2}.
> +This expression is evaluated only once during the filter
> +configuration.
> +@end table
> +
> @section cropdetect
>
> Auto-detect the crop size.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index fef6ec5..84df037 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -187,6 +187,7 @@ OBJS-$(CONFIG_COPY_FILTER) +=
> vf_copy.o OBJS-$(CONFIG_COREIMAGE_FILTER) +=
> vf_coreimage.o OBJS-$(CONFIG_COVER_RECT_FILTER) +=
> vf_cover_rect.o lavfutils.o
> OBJS-$(CONFIG_CROP_FILTER) += vf_crop.o
> +OBJS-$(CONFIG_CROP_CUDA_FILTER) += vf_crop_cuda.o
> vf_crop_cuda.ptx.o OBJS-$(CONFIG_CROPDETECT_FILTER) +=
> vf_cropdetect.o OBJS-$(CONFIG_CUE_FILTER)+=
> f_cue.o OBJS-$(CONFIG_CURVES_FILTER) += vf_curves.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index c51ae0f..550e545 100644 --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -175,6 +175,7 @@ extern AVFilter ff_vf_copy;
> extern AVFilter ff_vf_coreimage;
> extern AVFilter ff_vf_cover_rect;
> extern AVFilter ff_vf_crop;
> +extern AVFilter ff_vf_crop_cuda;
> extern AVFilter ff_vf_cropdetect;
> extern AVFilter ff_vf_cue;
> extern AVFilter ff_vf_curves;
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index c71282c..5aa95f4 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -31,7 +31,7 @@
>
> #define LIBAVFILTER_VERSION_MAJOR 7
> #define LIBAVFILTER_VERSION_MINOR 48
> -#define LIBAVFILTER_VERSION_MICRO 100
> +#define LIBAVFILTER_VERSION_MICRO 101
>
> #define LIBAVFILTER_VERSION_INT
>
