Re: [FFmpeg-devel] [PATCH v3] libavutil/ppc: Make use of getauxval() and elf_aux_info() on ppc

2024-09-20 Thread Martin Storsjö 

On Fri, 20 Sep 2024, Brad Smith wrote:


ping.

On 2024-09-15 1:40 a.m., Brad Smith wrote:

libavutil/ppc: Make use of getauxval() and elf_aux_info() on ppc

Modern Linux has getauxval() and FreeBSD/OpenBSD ppc have 
elf_aux_info().


Signed-off-by: Brad Smith 
---
v2: adjust to build with older glibc.
v3: freebsd/ppc requires machine/cpu.h header for feature flags.

  libavutil/ppc/cpu.c | 25 +
  1 file changed, 25 insertions(+)

diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
index 2b13cda662..9381272175 100644
--- a/libavutil/ppc/cpu.c
+++ b/libavutil/ppc/cpu.c
@@ -20,6 +20,11 @@
#ifdef __APPLE__
  #include 
+#elif HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+#ifdef __FreeBSD__
+#include 
+#endif
+#include 
  #elif defined(__linux__)
  #include 
  #include 
@@ -56,6 +61,26 @@ int ff_get_cpu_flags_ppc(void)
  if (result == VECTORTYPE_ALTIVEC)
  return AV_CPU_FLAG_ALTIVEC;
  return 0;
+#elif HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+int flags = 0;
+
+unsigned long hwcap = ff_getauxval(AT_HWCAP);
+#ifdef PPC_FEATURE2_ARCH_2_07
+unsigned long hwcap2 = ff_getauxval(AT_HWCAP2);
+#endif
+
+if (hwcap & PPC_FEATURE_HAS_ALTIVEC)
+   flags |= AV_CPU_FLAG_ALTIVEC;
+#ifdef PPC_FEATURE_HAS_VSX
+if (hwcap & PPC_FEATURE_HAS_VSX)
+   flags |= AV_CPU_FLAG_VSX;
+#endif
+#ifdef PPC_FEATURE2_ARCH_2_07
+if (hwcap2 & PPC_FEATURE2_ARCH_2_07)
+   flags |= AV_CPU_FLAG_POWER8;
+#endif
+
+return flags;
  #elif defined(__APPLE__) || defined(__NetBSD__) || 
defined(__OpenBSD__)

  #if defined(__NetBSD__) || defined(__OpenBSD__)
  int sels[2] = {CTL_MACHDEP, CPU_ALTIVEC};


I don'k know much specifically about ppc, but the patch seems reasonable 
to me.


// Martin

___
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] doc: Add email URLs for Fate samples-request

2024-09-20 Thread Martin Schitter 
v2 adds the  address as a second (L: ...)-entry
to the Fate info in MAINTAINERS.

I'm not sure if this is correct because I couldn't find other lines,
where the same kind of entry gets used twice.

Btw.: the  fate info and the "webserver"-entry one line above use
(S:...)-entries, which aren't mentioned as a possible variant in the
descriptive  top section of MAINTAINERS. Shouldn't these be (T:...)-
or (W: ...)-entries or the (S: ...) kind be added as another option
to the describtion?

martin

---
 MAINTAINERS| 2 +-
 doc/developer.texi | 2 +-
 doc/fate.texi  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 036066d..7d7ef36 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -62,7 +62,7 @@ Communication
 =
 
 website (S: https://git.ffmpeg.org/ffmpeg-web) 
Deby Barbara Lepage
-fate.ffmpeg.org (L: fate-ad...@ffmpeg.org) (W: 
https://fate.ffmpeg.org) (P: https://ffmpeg.org/fate.html) (S: 
https://git.ffmpeg.org/fateserver) Timo Rothenpieler
+fate.ffmpeg.org (L: fate-ad...@ffmpeg.org) (L: 
samples-requ...@ffmpeg.org) (W: https://fate.ffmpeg.org) (P: 
https://ffmpeg.org/fate.html) (S: https://git.ffmpeg.org/fateserver) Timo 
Rothenpieler
 Trac bug tracker(W: https://trac.ffmpeg.org) Alexander 
Strasser, Michael Niedermayer, Carl Eugen Hoyos
 Patchwork   [2] (W: https://patchwork.ffmpeg.org) 
Andriy Gelman
 mailing lists   (W: 
https://ffmpeg.org/contact.html#MailingLists) Baptiste Coudurier
diff --git a/doc/developer.texi b/doc/developer.texi
index 41b2193..b732560 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -876,7 +876,7 @@ accordingly].
 
 @section Adding files to the fate-suite dataset
 
-If you need a sample uploaded send a mail to samples-request.
+If you need a sample uploaded send a mail to 
@email{samples-request@@ffmpeg.org}.
 
 When there is no muxer or encoder available to generate test media for a
 specific test then the media has to be included in the fate-suite.
diff --git a/doc/fate.texi b/doc/fate.texi
index 17644ce..6f6df3a 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -172,7 +172,7 @@ the synchronisation of the samples directory.
 
 @chapter Uploading new samples to the fate suite
 
-If you need a sample uploaded send a mail to samples-request.
+If you need a sample uploaded send a mail to 
@email{samples-request@@ffmpeg.org}.
 
 This is for developers who have an account on the fate suite server.
 If you upload new samples, please make sure they are as small as possible,
-- 
2.45.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 2/2] fftools/ffmpeg_filter: ensure that the inserted filters exist

2024-09-20 Thread James Almer 
If not, report it as a bug. avfilter_graph_create_filter() will return ENOMEM 
if the
passed filter argument is NULL, which is misleading.

Signed-off-by: James Almer 
---
 fftools/ffmpeg_filter.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 8b420e68ab..27d74341b5 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1444,11 +1444,15 @@ static int insert_filter(AVFilterContext **last_filter, 
int *pad_idx,
  const char *filter_name, const char *args)
 {
 AVFilterGraph *graph = (*last_filter)->graph;
+const AVFilter *filter = avfilter_get_by_name(filter_name)
 AVFilterContext *ctx;
 int ret;
 
+if (!filter)
+return AVERROR_BUG;
+
 ret = avfilter_graph_create_filter(&ctx,
-   avfilter_get_by_name(filter_name),
+   filter,
filter_name, args, NULL, graph);
 if (ret < 0)
 return ret;
-- 
2.46.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 1/2] configure: add missing filter dependencies to ffmpeg

2024-09-20 Thread James Almer 
Signed-off-by: James Almer 
---
 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index d568739bf9..f07f6c7c46 100755
--- a/configure
+++ b/configure
@@ -4055,8 +4055,8 @@ avutil_extralibs="d3d11va_extralibs d3d12va_extralibs 
mediacodec_extralibs nanos
 
 # programs
 ffmpeg_deps="avcodec avfilter avformat threads"
-ffmpeg_select="aformat_filter anull_filter atrim_filter format_filter
-   hflip_filter null_filter
+ffmpeg_select="aformat_filter anull_filter atrim_filter crop_filter
+   format_filter hflip_filter null_filter rotate_filter
transpose_filter trim_filter vflip_filter"
 ffmpeg_suggest="ole32 psapi shell32"
 ffplay_deps="avcodec avformat avfilter swscale swresample sdl2"
-- 
2.46.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 2/2] fftools/ffmpeg_filter: ensure that the inserted filters exist

2024-09-20 Thread James Almer 

On 9/20/2024 10:30 AM, James Almer wrote:

If not, report it as a bug. avfilter_graph_create_filter() will return ENOMEM 
if the
passed filter argument is NULL, which is misleading.

Signed-off-by: James Almer 
---
  fftools/ffmpeg_filter.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 8b420e68ab..27d74341b5 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1444,11 +1444,15 @@ static int insert_filter(AVFilterContext **last_filter, 
int *pad_idx,
   const char *filter_name, const char *args)
  {
  AVFilterGraph *graph = (*last_filter)->graph;
+const AVFilter *filter = avfilter_get_by_name(filter_name)


Missing colon added locally...


  AVFilterContext *ctx;
  int ret;
  
+if (!filter)

+return AVERROR_BUG;
+
  ret = avfilter_graph_create_filter(&ctx,
-   avfilter_get_by_name(filter_name),
+   filter,
 filter_name, args, NULL, graph);
  if (ret < 0)
  return ret;




OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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/vvc: Don't use large array on stack

2024-09-20 Thread Zhao Zhili 
From: Zhao Zhili 

tmp_array in dmvr_hv takes 33024 bytes on stack, which can be
dangerous.
---
 libavcodec/vvc/inter_template.c | 28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/libavcodec/vvc/inter_template.c b/libavcodec/vvc/inter_template.c
index c073a73e76..187d557853 100644
--- a/libavcodec/vvc/inter_template.c
+++ b/libavcodec/vvc/inter_template.c
@@ -541,11 +541,13 @@ static void FUNC(dmvr_v)(int16_t *dst, const uint8_t 
*_src, const ptrdiff_t _src
 static void FUNC(dmvr_hv)(int16_t *dst, const uint8_t *_src, const ptrdiff_t 
_src_stride,
 const int height, const intptr_t mx, const intptr_t my, const int width)
 {
-int16_t tmp_array[(MAX_PB_SIZE + BILINEAR_EXTRA) * MAX_PB_SIZE];
-int16_t *tmp= tmp_array;
+int16_t tmp_array[MAX_PB_SIZE * 2];
+int16_t *tmp0   = tmp_array;
+int16_t *tmp1   = tmp_array + MAX_PB_SIZE;
 const pixel *src= (const pixel*)_src;
 const ptrdiff_t src_stride  = _src_stride / sizeof(pixel);
-const int8_t *filter= ff_vvc_inter_luma_dmvr_filters[mx];
+const int8_t *filter_x  = ff_vvc_inter_luma_dmvr_filters[mx];
+const int8_t *filter_y  = ff_vvc_inter_luma_dmvr_filters[my];
 const int shift1= BIT_DEPTH - 6;
 const int offset1   = 1 << (shift1 - 1);
 const int shift2= 4;
@@ -553,19 +555,15 @@ static void FUNC(dmvr_hv)(int16_t *dst, const uint8_t 
*_src, const ptrdiff_t _sr
 
 src   -= BILINEAR_EXTRA_BEFORE * src_stride;
 for (int y = 0; y < height + BILINEAR_EXTRA; y++) {
-for (int x = 0; x < width; x++)
-tmp[x] = (DMVR_FILTER(src, 1) + offset1) >> shift1;
+for (int x = 0; x < width; x++) {
+tmp1[x] = ((filter_x[0] * src[x] + filter_x[1] * src[x + 1]) + 
offset1) >> shift1;
+if (y > 0)
+dst[x] = ((filter_y[0] * tmp0[x] + filter_y[1] * tmp1[x]) + 
offset2) >> shift2;
+}
 src += src_stride;
-tmp += MAX_PB_SIZE;
-}
-
-tmp= tmp_array + BILINEAR_EXTRA_BEFORE * MAX_PB_SIZE;
-filter = ff_vvc_inter_luma_dmvr_filters[my];
-for (int y = 0; y < height; y++) {
-for (int x = 0; x < width; x++)
-dst[x] = (DMVR_FILTER(tmp, MAX_PB_SIZE) + offset2) >> shift2;
-tmp += MAX_PB_SIZE;
-dst += MAX_PB_SIZE;
+if (y > 0)
+dst += MAX_PB_SIZE;
+FFSWAP(int16_t *, tmp0, tmp1);
 }
 }
 
-- 
2.42.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 v2] avcodec/vvc: Don't use large array on stack

2024-09-20 Thread Zhao Zhili 



> On Sep 20, 2024, at 11:43, Zhao Zhili  wrote:
> 
> From: Zhao Zhili 
> 
> tmp_array in dmvr_hv takes 33024 bytes on stack, which can be
> dangerous.

I prefer version 3 personally

https://ffmpeg.org/pipermail/ffmpeg-devel/2024-September/333709.html

> ---
> libavcodec/vvc/ctu.h |  1 +
> libavcodec/vvc/dsp.h |  2 +-
> libavcodec/vvc/inter.c   |  2 +-
> libavcodec/vvc/inter_template.c  | 12 +++-
> libavcodec/x86/vvc/vvcdsp_init.c |  8 
> tests/checkasm/vvc_mc.c  | 17 +
> 6 files changed, 27 insertions(+), 15 deletions(-)
> 
> diff --git a/libavcodec/vvc/ctu.h b/libavcodec/vvc/ctu.h
> index eab4612561..eb3e51c7e5 100644
> --- a/libavcodec/vvc/ctu.h
> +++ b/libavcodec/vvc/ctu.h
> @@ -385,6 +385,7 @@ typedef struct VVCLocalContext {
> DECLARE_ALIGNED(32, uint8_t, alf_buffer_luma)[(MAX_CTU_SIZE + 2 * 
> ALF_PADDING_SIZE) * EDGE_EMU_BUFFER_STRIDE * 2];
> DECLARE_ALIGNED(32, uint8_t, alf_buffer_chroma)[(MAX_CTU_SIZE + 2 * 
> ALF_PADDING_SIZE) * EDGE_EMU_BUFFER_STRIDE * 2];
> DECLARE_ALIGNED(32, int32_t, alf_gradient_tmp)[ALF_GRADIENT_SIZE * 
> ALF_GRADIENT_SIZE * ALF_NUM_DIR];
> +DECLARE_ALIGNED(32, int16_t, dmvr_tmp)[(MAX_PB_SIZE + BILINEAR_EXTRA) * 
> MAX_PB_SIZE];
> 
> struct {
> int sbt_num_fourths_tb0;///< SbtNumFourthsTb0
> diff --git a/libavcodec/vvc/dsp.h b/libavcodec/vvc/dsp.h
> index 635ebcafed..3594dfc5f5 100644
> --- a/libavcodec/vvc/dsp.h
> +++ b/libavcodec/vvc/dsp.h
> @@ -99,7 +99,7 @@ typedef struct VVCInterDSPContext {
> 
> int (*sad)(const int16_t *src0, const int16_t *src1, int dx, int dy, int 
> block_w, int block_h);
> void (*dmvr[2][2])(int16_t *dst, const uint8_t *src, ptrdiff_t 
> src_stride, int height,
> -intptr_t mx, intptr_t my, int width);
> +intptr_t mx, intptr_t my, int width, int16_t *tmp);
> } VVCInterDSPContext;
> 
> struct VVCLocalContext;
> diff --git a/libavcodec/vvc/inter.c b/libavcodec/vvc/inter.c
> index 64a9dd1e46..48b633d580 100644
> --- a/libavcodec/vvc/inter.c
> +++ b/libavcodec/vvc/inter.c
> @@ -806,7 +806,7 @@ static void dmvr_mv_refine(VVCLocalContext *lc, MvField 
> *mvf, MvField *orig_mv,
> const int wrap_enabled  = 
> fc->ps.pps->r->pps_ref_wraparound_enabled_flag;
> 
> MC_EMULATED_EDGE_BILINEAR(lc->edge_emu_buffer, &src, &src_stride, ox, 
> oy);
> -fc->vvcdsp.inter.dmvr[!!my][!!mx](tmp[i], src, src_stride, pred_h, 
> mx, my, pred_w);
> +fc->vvcdsp.inter.dmvr[!!my][!!mx](tmp[i], src, src_stride, pred_h, 
> mx, my, pred_w, lc->dmvr_tmp);
> }
> 
> min_sad = fc->vvcdsp.inter.sad(tmp[L0], tmp[L1], dx, dy, block_w, 
> block_h);
> diff --git a/libavcodec/vvc/inter_template.c b/libavcodec/vvc/inter_template.c
> index c073a73e76..fad1ba801f 100644
> --- a/libavcodec/vvc/inter_template.c
> +++ b/libavcodec/vvc/inter_template.c
> @@ -474,7 +474,8 @@ static void FUNC(apply_bdof)(uint8_t *_dst, const 
> ptrdiff_t _dst_stride, const i
> 
> //8.5.3.2.2 Luma sample bilinear interpolation process
> static void FUNC(dmvr)(int16_t *dst, const uint8_t *_src, const ptrdiff_t 
> _src_stride,
> -const int height, const intptr_t mx, const intptr_t my, const int width)
> +const int height, const intptr_t mx, const intptr_t my, const int width,
> +int16_t *tmp)
> {
> #if BIT_DEPTH != 10
> const pixel *src= (const pixel *)_src;
> @@ -502,7 +503,8 @@ static void FUNC(dmvr)(int16_t *dst, const uint8_t *_src, 
> const ptrdiff_t _src_s
> 
> //8.5.3.2.2 Luma sample bilinear interpolation process
> static void FUNC(dmvr_h)(int16_t *dst, const uint8_t *_src, const ptrdiff_t 
> _src_stride,
> -const int height, const intptr_t mx, const intptr_t my, const int width)
> +const int height, const intptr_t mx, const intptr_t my, const int width,
> +int16_t *tmp)
> {
> const pixel *src= (const pixel*)_src;
> const ptrdiff_t src_stride  = _src_stride / sizeof(pixel);
> @@ -520,7 +522,8 @@ static void FUNC(dmvr_h)(int16_t *dst, const uint8_t 
> *_src, const ptrdiff_t _src
> 
> //8.5.3.2.2 Luma sample bilinear interpolation process
> static void FUNC(dmvr_v)(int16_t *dst, const uint8_t *_src, const ptrdiff_t 
> _src_stride,
> -const int height, const intptr_t mx, const intptr_t my, const int width)
> +const int height, const intptr_t mx, const intptr_t my, const int width,
> +int16_t *tmp)
> {
> const pixel *src= (pixel*)_src;
> const ptrdiff_t src_stride  = _src_stride / sizeof(pixel);
> @@ -539,9 +542,8 @@ static void FUNC(dmvr_v)(int16_t *dst, const uint8_t 
> *_src, const ptrdiff_t _src
> 
> //8.5.3.2.2 Luma sample bilinear interpolation process
> static void FUNC(dmvr_hv)(int16_t *dst, const uint8_t *_src, const ptrdiff_t 
> _src_stride,
> -const int height, const intptr_t mx, const intptr_t my, const int width)
> +const int height, const intptr_t mx, const intptr_t my, const int width, 
> int16_t *tmp_array)
> {
> -int

Re: [FFmpeg-devel] [PATCH 2/3] - libavcodec/aom_film_grain: Add apply_grain flag

2024-09-20 Thread Christophe Gisquet 
Hello.

Disclaimer: I'm not the owner/maintainer of any of that code, nor do I
know who is.

Le ven. 20 sept. 2024 à 02:44, Segall, Andrew via ffmpeg-devel
 a écrit :
> case AV_FILM_GRAIN_PARAMS_AV1:
> - ret = ff_aom_apply_film_grain(out->frame_grain, out->f, fgp);
> + if(fgp->apply_grain)
> + ret = ff_aom_apply_film_grain(out->frame_grain, out->f, fgp);
> + else
> + out->needs_fg = 0;
> break;
> }

Let's imagine AFGS1 would be used for VVC-coded content. It then feels
like that logic should be in ff_aom_apply_film_grain, but then
apparently, the HEVC frame object and the process has to be at the
HEVC decoder level, and not more generic ones.
But see below why I'm really commenting this.

> @@ -241,6 +241,11 @@ typedef struct AVFilmGrainParams {
> */
> enum AVFilmGrainParamsType type;
>
>
> + /**
> + * Specifies if film grain parameters are enabled.
> + */
> + int apply_grain;
> +
> /**
> * Seed to use for the synthesis process, if the codec allows for it.

While it's not abnormal that a generic struct holds things only valid
in a few cases, this flag doesn't apply to H.274, and is really
processed by AFGS1-aware code, so I'm wondering if that apply_grain
should really be in AVFilmGrainAOMParams?
Lynne's comment still applies, though.

-- 
Christophe
___
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/3] - libavcodec/aom_film_grain: Add apply_grain flag

2024-09-20 Thread Segall, Andrew via ffmpeg-devel 


On 9/20/24, 12:15 AM, "ffmpeg-devel on behalf of Lynne via ffmpeg-devel" 
mailto:ffmpeg-devel-boun...@ffmpeg.org> on 
behalf of ffmpeg-devel@ffmpeg.org > wrote:


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.






On 20/09/2024 02:44, Segall, Andrew via ffmpeg-devel wrote:
> Details: Add support for the apply_grain_flag. This allows the film grain 
> process to be enabled/disabled for different display properties.
>
> On 9/8/24, 12:06 AM, "Andrew Segall"    >> wrote:
>
>
> Signed-off-by: Andrew Segall mailto:aseg...@amazon.com> 
> >>
> ---
> libavcodec/aom_film_grain.c | 6 --
> libavcodec/hevc/hevcdec.c | 5 -
> libavfilter/vf_showinfo.c | 1 +
> libavutil/film_grain_params.h | 5 +
> 4 files changed, 14 insertions(+), 3 deletions(-)
>
>
> diff --git a/libavcodec/aom_film_grain.c b/libavcodec/aom_film_grain.c
> index fdfa3dbf77..251a2793ac 100644
> --- a/libavcodec/aom_film_grain.c
> +++ b/libavcodec/aom_film_grain.c
> @@ -149,8 +149,10 @@ int ff_aom_parse_film_grain_sets(AVFilmGrainAFGS1Params 
> *s,
> fgp = &s->sets[set_idx];
> aom = &fgp->codec.aom;
>
>
> - fgp->type = get_bits1(gb) ? AV_FILM_GRAIN_PARAMS_AV1 : 
> AV_FILM_GRAIN_PARAMS_NONE;
> - if (!fgp->type)
> + fgp->type = AV_FILM_GRAIN_PARAMS_AV1;
> +
> + fgp->apply_grain = get_bits1(gb);
> + if ( !fgp->apply_grain)
> {
> payload_bits = get_bits_count(gb) - start_position;
> if (payload_bits > payload_size * 8)
> diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
> index d915d74d22..8dd4fb10c5 100644
> --- a/libavcodec/hevc/hevcdec.c
> +++ b/libavcodec/hevc/hevcdec.c
> @@ -3155,7 +3155,10 @@ static int hevc_frame_end(HEVCContext *s)
> &s->h274db, fgp);
> break;
> case AV_FILM_GRAIN_PARAMS_AV1:
> - ret = ff_aom_apply_film_grain(out->frame_grain, out->f, fgp);
> + if(fgp->apply_grain)
> + ret = ff_aom_apply_film_grain(out->frame_grain, out->f, fgp);
> + else
> + out->needs_fg = 0;
> break;
> }
> av_assert1(ret >= 0);
> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> index f81df9d1bf..08e144ca46 100644
> --- a/libavfilter/vf_showinfo.c
> +++ b/libavfilter/vf_showinfo.c
> @@ -455,6 +455,7 @@ static void 
> dump_sei_film_grain_params_metadata(AVFilterContext *ctx, const AVFr
> }
>
>
> av_log(ctx, AV_LOG_INFO, "type %s; ", film_grain_type_names[fgp->type]);
> + av_log(ctx, AV_LOG_INFO, "apply_grain=%d; ", fgp->apply_grain);
> av_log(ctx, AV_LOG_INFO, "seed=%"PRIu64"; ", fgp->seed);
> av_log(ctx, AV_LOG_INFO, "width=%d; ", fgp->width);
> av_log(ctx, AV_LOG_INFO, "height=%d; ", fgp->height);
> diff --git a/libavutil/film_grain_params.h b/libavutil/film_grain_params.h
> index ccacab88fe..f3275923e1 100644
> --- a/libavutil/film_grain_params.h
> +++ b/libavutil/film_grain_params.h
> @@ -241,6 +241,11 @@ typedef struct AVFilmGrainParams {
> */
> enum AVFilmGrainParamsType type;
>
>
> + /**
> + * Specifies if film grain parameters are enabled.
> + */
> + int apply_grain;
> +
> /**
> * Seed to use for the synthesis process, if the codec allows for it.
> *


> This is an ABI break.

> Furthermore, what exactly does this improve over simply stripping the side 
> data?

Mainly addressing conformance issues.

Example is that we have two parameters in the AFGS1 message.  The first is 
associated with resolution A and apply_grain=1.  Second is associated with 
resolution B and apply_grain=0.

If the synthesis Is performed at resolution B, then the message says that we 
shouldn't perform film grain synthesis since apply_grain=0.  However, if we 
strip, the information is lost - and synthesis may use the parameters 
associated with resolution A instead.






___
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/3] - libavcodec/aom_film_grain: Add apply_grain flag

2024-09-20 Thread Lynne via ffmpeg-devel 

On 20/09/2024 02:44, Segall, Andrew via ffmpeg-devel wrote:

Details: Add support for the apply_grain_flag.  This allows the film grain 
process to be enabled/disabled for different display properties.

On 9/8/24, 12:06 AM, "Andrew Segall" mailto:aseg...@amazon.com>> wrote:


Signed-off-by: Andrew Segall mailto:aseg...@amazon.com>>
---
libavcodec/aom_film_grain.c | 6 --
libavcodec/hevc/hevcdec.c | 5 -
libavfilter/vf_showinfo.c | 1 +
libavutil/film_grain_params.h | 5 +
4 files changed, 14 insertions(+), 3 deletions(-)


diff --git a/libavcodec/aom_film_grain.c b/libavcodec/aom_film_grain.c
index fdfa3dbf77..251a2793ac 100644
--- a/libavcodec/aom_film_grain.c
+++ b/libavcodec/aom_film_grain.c
@@ -149,8 +149,10 @@ int ff_aom_parse_film_grain_sets(AVFilmGrainAFGS1Params *s,
fgp = &s->sets[set_idx];
aom = &fgp->codec.aom;


- fgp->type = get_bits1(gb) ? AV_FILM_GRAIN_PARAMS_AV1 : 
AV_FILM_GRAIN_PARAMS_NONE;
- if (!fgp->type)
+ fgp->type = AV_FILM_GRAIN_PARAMS_AV1;
+
+ fgp->apply_grain = get_bits1(gb);
+ if ( !fgp->apply_grain)
{
payload_bits = get_bits_count(gb) - start_position;
if (payload_bits > payload_size * 8)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index d915d74d22..8dd4fb10c5 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -3155,7 +3155,10 @@ static int hevc_frame_end(HEVCContext *s)
&s->h274db, fgp);
break;
case AV_FILM_GRAIN_PARAMS_AV1:
- ret = ff_aom_apply_film_grain(out->frame_grain, out->f, fgp);
+ if(fgp->apply_grain)
+ ret = ff_aom_apply_film_grain(out->frame_grain, out->f, fgp);
+ else
+ out->needs_fg = 0;
break;
}
av_assert1(ret >= 0);
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index f81df9d1bf..08e144ca46 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -455,6 +455,7 @@ static void 
dump_sei_film_grain_params_metadata(AVFilterContext *ctx, const AVFr
}


av_log(ctx, AV_LOG_INFO, "type %s; ", film_grain_type_names[fgp->type]);
+ av_log(ctx, AV_LOG_INFO, "apply_grain=%d; ", fgp->apply_grain);
av_log(ctx, AV_LOG_INFO, "seed=%"PRIu64"; ", fgp->seed);
av_log(ctx, AV_LOG_INFO, "width=%d; ", fgp->width);
av_log(ctx, AV_LOG_INFO, "height=%d; ", fgp->height);
diff --git a/libavutil/film_grain_params.h b/libavutil/film_grain_params.h
index ccacab88fe..f3275923e1 100644
--- a/libavutil/film_grain_params.h
+++ b/libavutil/film_grain_params.h
@@ -241,6 +241,11 @@ typedef struct AVFilmGrainParams {
*/
enum AVFilmGrainParamsType type;


+ /**
+ * Specifies if film grain parameters are enabled.
+ */
+ int apply_grain;
+
/**
* Seed to use for the synthesis process, if the codec allows for it.
*


This is an ABI break.

Furthermore, what exactly does this improve over simply stripping the 
side data?


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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] Make H.274 film grain support optional for H.264. Saves ~779kb.

2024-09-20 Thread Dale Curtis 
Were there any more comments for this patch?

- dale

On Tue, Aug 13, 2024 at 11:30 PM Christophe Gisquet <
christophe.gisq...@gmail.com> wrote:

> Hi,
>
> Le mar. 13 août 2024 à 23:39, Dale Curtis  a
> écrit :
> >
> > On Tue, Aug 13, 2024 at 1:11 PM Hendrik Leppkes 
> wrote:
> >
> > > Disabling random codec features seems like an anti-feature to me, in
> > > the future it'll make every feature be questioned and compile-time
> > > conditional, and make everything terrible.
> > > If the context size is the major concern, maybe large structures
> > > should be allocated when in use, rather than always?
> > >
> >
> > I agree with that, so here's a version which allocates dynamically
> instead.
> > It passes FATE, but I didn't try with valgrind/msan in case I missed a
> > cleanup path.
>
> (not an author)
> Probably there is remaining work pending on external dependencies, but
> H274FilmGrainDatabase sounds a bit adhoc. The 8KB of slice_tmp for one
> could just be a local variable in init_slice(). The 676KB (!) of the
> noise database are a bit more puzzling and could be the one that needs
> allocating only when the noise is generated. It may simplify a bit
> some of the conditions in this patch.
>
> --
> Christophe
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/3] fftools/ffmpeg: auto insert enhancement filters when available

2024-09-20 Thread James Almer 
This is an alternative to 
https://ffmpeg.org//pipermail/ffmpeg-devel/2024-September/96.html
where things are left to the caller and we don't rely on lavc applying the 
LCEVC metadata at
the end of the decoding process.

Signed-off-by: James Almer 
---
 configure   |  2 +-
 fftools/ffmpeg.h|  2 ++
 fftools/ffmpeg_demux.c  |  5 +
 fftools/ffmpeg_filter.c | 22 +-
 fftools/ffmpeg_opt.c|  3 +++
 5 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index f07f6c7c46..fb009d0c3f 100755
--- a/configure
+++ b/configure
@@ -4058,7 +4058,7 @@ ffmpeg_deps="avcodec avfilter avformat threads"
 ffmpeg_select="aformat_filter anull_filter atrim_filter crop_filter
format_filter hflip_filter null_filter rotate_filter
transpose_filter trim_filter vflip_filter"
-ffmpeg_suggest="ole32 psapi shell32"
+ffmpeg_suggest="lcevc_filter ole32 psapi shell32"
 ffplay_deps="avcodec avformat avfilter swscale swresample sdl2"
 ffplay_select="crop_filter transpose_filter hflip_filter vflip_filter 
rotate_filter"
 ffplay_suggest="shell32 libplacebo vulkan"
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index f4a10b2a66..44c7ca08ed 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -154,6 +154,7 @@ typedef struct OptionsContext {
 SpecifierOptList hwaccels;
 SpecifierOptList hwaccel_devices;
 SpecifierOptList hwaccel_output_formats;
+SpecifierOptList autoenhance;
 SpecifierOptList autorotate;
 SpecifierOptList apply_cropping;
 
@@ -241,6 +242,7 @@ enum IFilterFlags {
 IFILTER_FLAG_REINIT = (1 << 1),
 IFILTER_FLAG_CFR= (1 << 2),
 IFILTER_FLAG_CROP   = (1 << 3),
+IFILTER_FLAG_AUTOENHANCE= (1 << 4),
 };
 
 typedef struct InputFilterOptions {
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 0b639f2b60..f0290fa286 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -66,6 +66,7 @@ typedef struct DemuxStream {
 int  have_sub2video;
 int  reinit_filters;
 int  autorotate;
+int  autoenhance;
 int  apply_cropping;
 
 
@@ -1072,6 +1073,7 @@ int ist_filter_add(InputStream *ist, InputFilter 
*ifilter, int is_simple,
 return AVERROR(ENOMEM);
 
 opts->flags |= IFILTER_FLAG_AUTOROTATE * !!(ds->autorotate) |
+   IFILTER_FLAG_AUTOENHANCE * !!(ds->autoenhance) |
IFILTER_FLAG_REINIT * !!(ds->reinit_filters);
 
 return ds->sch_idx_dec;
@@ -1253,6 +1255,9 @@ static int ist_add(const OptionsContext *o, Demuxer *d, 
AVStream *st, AVDictiona
 ds->ts_scale = 1.0;
 opt_match_per_stream_dbl(ist, &o->ts_scale, ic, st, &ds->ts_scale);
 
+ds->autoenhance = 1;
+opt_match_per_stream_int(ist, &o->autoenhance, ic, st, &ds->autoenhance);
+
 ds->autorotate = 1;
 opt_match_per_stream_int(ist, &o->autorotate, ic, st, &ds->autorotate);
 
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 529e631781..6a64b5a091 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -147,6 +147,8 @@ typedef struct InputFilterPriv {
 int displaymatrix_applied;
 int32_t displaymatrix[9];
 
+int enhancement_present;
+
 struct {
 AVFrame *frame;
 
@@ -1697,6 +1699,15 @@ static int configure_input_video_filter(FilterGraph *fg, 
AVFilterGraph *graph,
 desc = av_pix_fmt_desc_get(ifp->format);
 av_assert0(desc);
 
+if ((ifp->opts.flags & IFILTER_FLAG_AUTOENHANCE) &&
+!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL)) {
+ret = insert_filter(&last_filter, &pad_idx, "lcevc", NULL);
+if (ret == AVERROR_BUG) // this filter is optional
+ret = 0;
+if (ret < 0)
+return ret;
+}
+
 if ((ifp->opts.flags & IFILTER_FLAG_CROP)) {
 char crop_buf[64];
 snprintf(crop_buf, sizeof(crop_buf), "w=iw-%u-%u:h=ih-%u-%u:x=%u:y=%u",
@@ -2028,6 +2039,8 @@ static int ifilter_parameters_from_frame(InputFilter 
*ifilter, const AVFrame *fr
 memcpy(ifp->displaymatrix, sd->data, sizeof(ifp->displaymatrix));
 ifp->displaymatrix_present = !!sd;
 
+ifp->enhancement_present = !!(av_frame_get_side_data(frame, 
AV_FRAME_DATA_LCEVC));
+
 return 0;
 }
 
@@ -2727,7 +2740,8 @@ enum ReinitReason {
 VIDEO_CHANGED   = (1 << 0),
 AUDIO_CHANGED   = (1 << 1),
 MATRIX_CHANGED  = (1 << 2),
-HWACCEL_CHANGED = (1 << 3)
+HWACCEL_CHANGED = (1 << 3),
+ENHANCEMENT_CHANGED = (1 << 4),
 };
 
 static const char *unknown_if_null(const char *str)
@@ -2768,6 +2782,10 @@ static int send_frame(FilterGraph *fg, FilterGraphThread 
*fgt,
 } else if (ifp->displaymatrix_present)
 need_reinit |= MATRIX_CHANGED;
 
+if (sd = av_frame_get_side_data(frame, AV_FRAME_DATA_LCEVC))
+if (!ifp->enhancement_present)
+

Re: [FFmpeg-devel] [RFC] [PATCH] avcodec/cbs_h266: Fix copy paste mistake

2024-09-20 Thread Frank Plowman 
Hi Marvin,

Thanks for this patch and sorry for not getting around to it sooner.

Patch LGTM, yes it is a mistake I made when copy-pasting the logic for
the width -- sorry about that!

Thanks again,
Frank

On 31/08/2024 22:25, Marvin Scholz wrote:
> The us macro expect the range_max here, which seems should be
> MAX_UINT_BITS(hlen) here.
> 
> Fix CID1618757 Copy-paste error
> ---
> 
> This code is non-trivial to understand so I might be wrong
> about this, it would be great if someone actually familiar
> with this can have a look if my assesment is correct here.
> 
> Also if it isn't, a comment here might help to clarify things.
> 
>  libavcodec/cbs_h266_syntax_template.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/cbs_h266_syntax_template.c 
> b/libavcodec/cbs_h266_syntax_template.c
> index a8f5af04d0..0704da1d40 100644
> --- a/libavcodec/cbs_h266_syntax_template.c
> +++ b/libavcodec/cbs_h266_syntax_template.c
> @@ -1208,7 +1208,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx, 
> RWContext *rw,
> win_top_edge_ctus > 
> current->sps_subpic_ctu_top_left_y[i]
> ? win_top_edge_ctus - 
> current->sps_subpic_ctu_top_left_y[i]
> : 0,
> -   MAX_UINT_BITS(wlen), 1, i);
> +   MAX_UINT_BITS(hlen), 1, i);
>  } else {
>  infer(sps_subpic_height_minus1[i],
>tmp_height_val -


___
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 5/9] avcodec/cbs_h266_syntax_template: Check bit depth with range extension

2024-09-20 Thread Frank Plowman 
On 20/09/2024 01:54, James Almer wrote:
> On 9/19/2024 9:34 PM, Michael Niedermayer wrote:
>> On Thu, Sep 19, 2024 at 08:53:07PM -0300, James Almer wrote:
>>> On 9/19/2024 7:56 PM, Michael Niedermayer wrote:
 Fixes: shift exponent 62 is too large for 32-bit type 'int'
 Fixes:
 71020/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-6444916325023744

 Found-by: continuous fuzzing process
 https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
 Signed-off-by: Michael Niedermayer 
 ---
    libavcodec/cbs_h266_syntax_template.c | 3 +++
    1 file changed, 3 insertions(+)

 diff --git a/libavcodec/cbs_h266_syntax_template.c
 b/libavcodec/cbs_h266_syntax_template.c
 index a8f5af04d02..1c26563 100644
 --- a/libavcodec/cbs_h266_syntax_template.c
 +++ b/libavcodec/cbs_h266_syntax_template.c
 @@ -1041,6 +1041,9 @@ static int
 FUNC(sps_range_extension)(CodedBitstreamContext *ctx, RWContext *rw,
    {
    int err;
 +    if (current->sps_bitdepth_minus8 < 10)
>>>
>>> sps_bitdepth_minus8 can only be between 0 and 8, so this is basically
>>> making
>>> it abort on any and every sample with SPS range extension.
>>
>> + if (current->sps_bitdepth_minus8 < 10 - 8)
> 
> Ok, this is different.
> 
>>
>> Its supposed to check this:
>> "When BitDepth is less
>>   than or equal to 10, the value of sps_range_extension_flag shall be
>> equal to 0."
> 
> Should be "<= (10 - 8)" then, and LGTM.
> 

LGTM, although nit: I think intent would be clearer and the code would
correspond better with the standard if the check was moved to the parent
function next to the flag itself.

-- 
Frank
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/cuviddec: Add handling HDR10+ sidedata on cuviddec.

2024-09-20 Thread Carlos Ruiz 
> It's just that the cuviddec decoder is more of a relic, from before the
> native hwaccel existed.
> The only reason it's not straight up deprecated is that it's sometimes
> nice to have a "second opinion" when issues crop up, and there are a few
> specific features like hardware-deinterlacing that can't be exposed via
> the native hwaccel.
>
> But I'd normally not like to expand it even further and add complex and
> large features to it. Whenever possible, the native nvdec hwaccel should
> be used.

As someone who recently switched from *_cuvid to * + hwaccel=cuda I have to
agree
that the performance (timing-wise at least) has been very comparable for
decoding.

The only comment I'd like to make though, and this might be a bit of
unpopular opinion
based on some other threads I read, but there are huge advantages of hwaccel
accelerating not just decoding but also resizing (and I guess optionally
cropping).
I know that ideally a decoder should only decode, but think about a common
usecase
in the AI world we live in: you get a bunch of simultaneous 4k (or 1080p)
incoming
rtsp streams and you want to decode the video and pass it through some ML
model,
e.g. in TensorRT (to stick with the Nvidia example). The native hevc codec
doesn't
support resizing, so you decode video at full 4k on the gpu, which means
allocating
something like 5-10 surfaces at 3840x2160 which becomes 250MB of GPU memory,
and then you have immediately take all of those frames, pass them through a
filterchain,
scale them down to e.g. 640x360, and waste CUDA cores instead of leveraging
the
dedicated video downsizing inside the NVDEC chip. Now do that for 50 camera
streams
and you'll quickly run out of GPU memory with a GPU utilization under 10%
haha.

This is exactly why I submitted a patch yesterday that would allow using
the hevc
codec with nvdec hwaccel, while resizing on the gpu like hevc_cuviddec
does, and
the memory (and GPU) consuption goes waaay down (e.g. 6MB of GPU VRAM
instead of 250MB per camera). I know this is a different discussion but
thought
it was appropriate to share because deprecating cuviddec or rejecting my
patch
would leave part of the community out.


On Fri, Sep 20, 2024 at 12:48 PM Timo Rothenpieler 
wrote:

> On 20/09/2024 04:08, 김윤주 wrote:
> > Does native decoder refer to hevc (hevcdec.c)?
> > I tried using hevc and in environments with low CPU performance,
> hevc_cuvid
> > was much faster.
> > So, I used hevc_cuvid for decoding but encountered an issue where HDR10+
> > sidedata did not exist.
> > That's why I wrote this patch.
>
> You did turn on hwaccel, right?
> I don't see why the native decoder would be much slower at parsing then
> nvidias parsers.
>
> > I thought that the original content's sidedata should be preserved even
> > after decoding regardless of which decoder is used.
> > And I thought hevc_cuvid was the only way to get Nvidia hwaccel support.
> > If I'm mistaken about anything, please let me know.
>
> It's just that the cuviddec decoder is more of a relic, from before the
> native hwaccel existed.
> The only reason it's not straight up deprecated is that it's sometimes
> nice to have a "second opinion" when issues crop up, and there are a few
> specific features like hardware-deinterlacing that can't be exposed via
> the native hwaccel.
>
> But I'd normally not like to expand it even further and add complex and
> large features to it. Whenever possible, the native nvdec hwaccel should
> be used.
>
> > Also, is it correct to respond to your comments like this?
> > It seems quite different from the format you sent.
>
> Top-posting isn't exactly liked here, though I don't really have a
> strong opinion on it.
>
> > Apologies, as I'm still relatively new to the FFmpeg community and have a
> > lot to learn.
> > Any additional guidance would be greatly appreciated.
> >
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Timo
> > Rothenpieler
> > Sent: Friday, September 20, 2024 4:48 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/cuviddec: Add handling HDR10+
> > sidedata on cuviddec.
> >
> > On 19.09.2024 06:43, yoonjoo wrote:
> >> Implemented decoding of NAL units and handling HDR10+ sidedata by
> >> referring to hevcdec.
> >
> > Why? Can't you just use the native decoder with nvdec hwaccel?
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://protect2.fireeye.com/v1/url?k=c11e9bb6-9e85a2a9-c11f10f9-
> > 000babdfecba-c4d76825032a0b52&q=1&e=342e88a0-295e-4dc1-a57f-
> >
> 8f5aab974009&u=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org
> > with subject "unsubscribe".
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffm

[FFmpeg-devel] [PATCH] avcodec/videotoolbox: add AV1 hardware acceleration

2024-09-20 Thread Martin Storsjö 
From: Jan Ekström 

Co-authored-by: Ruslan Chernenko 
Co-authored-by: Martin Storsjö 
---
This is a touched up version of Jan and Ruslan's patches for
AV1 hwaccel via videotoolbox; I tried to polish the code a little
by not overwriting avctx->extradata in
ff_videotoolbox_av1c_extradata_create, and by factorizing out a
new function ff_videotoolbox_buffer_append.
---
 configure |   4 ++
 libavcodec/Makefile   |   1 +
 libavcodec/av1dec.c   |  10 +++
 libavcodec/hwaccels.h |   1 +
 libavcodec/videotoolbox.c |  34 +++
 libavcodec/videotoolbox_av1.c | 112 ++
 libavcodec/vt_internal.h  |   4 ++
 7 files changed, 166 insertions(+)
 create mode 100644 libavcodec/videotoolbox_av1.c

diff --git a/configure b/configure
index 8fbf3772a8..bc244d7ca2 100755
--- a/configure
+++ b/configure
@@ -2464,6 +2464,7 @@ TYPES_LIST="
 kCMVideoCodecType_HEVC
 kCMVideoCodecType_HEVCWithAlpha
 kCMVideoCodecType_VP9
+kCMVideoCodecType_AV1
 kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange
 kCVPixelFormatType_422YpCbCr8BiPlanarVideoRange
 kCVPixelFormatType_422YpCbCr10BiPlanarVideoRange
@@ -3171,6 +3172,8 @@ av1_vaapi_hwaccel_deps="vaapi 
VADecPictureParameterBufferAV1_bit_depth_idx"
 av1_vaapi_hwaccel_select="av1_decoder"
 av1_vdpau_hwaccel_deps="vdpau VdpPictureInfoAV1"
 av1_vdpau_hwaccel_select="av1_decoder"
+av1_videotoolbox_hwaccel_deps="videotoolbox"
+av1_videotoolbox_hwaccel_select="av1_decoder"
 av1_vulkan_hwaccel_deps="vulkan"
 av1_vulkan_hwaccel_select="av1_decoder"
 h263_vaapi_hwaccel_deps="vaapi"
@@ -6690,6 +6693,7 @@ enabled videotoolbox && {
 check_func_headers CoreMedia/CMFormatDescription.h kCMVideoCodecType_HEVC 
"-framework CoreMedia"
 check_func_headers CoreMedia/CMFormatDescription.h 
kCMVideoCodecType_HEVCWithAlpha "-framework CoreMedia"
 check_func_headers CoreMedia/CMFormatDescription.h kCMVideoCodecType_VP9 
"-framework CoreMedia"
+check_func_headers CoreMedia/CMFormatDescription.h kCMVideoCodecType_AV1 
"-framework CoreMedia"
 check_func_headers CoreVideo/CVPixelBuffer.h 
kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange "-framework CoreVideo"
 check_func_headers CoreVideo/CVPixelBuffer.h 
kCVPixelFormatType_422YpCbCr8BiPlanarVideoRange "-framework CoreVideo"
 check_func_headers CoreVideo/CVPixelBuffer.h 
kCVPixelFormatType_422YpCbCr10BiPlanarVideoRange "-framework CoreVideo"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 936fc3415a..fa6d30a8b3 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1007,6 +1007,7 @@ OBJS-$(CONFIG_AV1_D3D12VA_HWACCEL)+= dxva2_av1.o 
d3d12va_av1.o
 OBJS-$(CONFIG_AV1_NVDEC_HWACCEL)  += nvdec_av1.o
 OBJS-$(CONFIG_AV1_VAAPI_HWACCEL)  += vaapi_av1.o
 OBJS-$(CONFIG_AV1_VDPAU_HWACCEL)  += vdpau_av1.o
+OBJS-$(CONFIG_AV1_VIDEOTOOLBOX_HWACCEL)   += videotoolbox_av1.o
 OBJS-$(CONFIG_AV1_VULKAN_HWACCEL) += vulkan_decode.o vulkan_av1.o
 OBJS-$(CONFIG_H263_VAAPI_HWACCEL) += vaapi_mpeg4.o
 OBJS-$(CONFIG_H263_VIDEOTOOLBOX_HWACCEL)  += videotoolbox.o
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 1d5b9ef4f4..0fad09af74 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -541,6 +541,7 @@ static int get_pixel_format(AVCodecContext *avctx)
  CONFIG_AV1_NVDEC_HWACCEL + \
  CONFIG_AV1_VAAPI_HWACCEL + \
  CONFIG_AV1_VDPAU_HWACCEL + \
+ CONFIG_AV1_VIDEOTOOLBOX_HWACCEL + \
  CONFIG_AV1_VULKAN_HWACCEL)
 enum AVPixelFormat pix_fmts[HWACCEL_MAX + 2], *fmtp = pix_fmts;
 
@@ -568,6 +569,9 @@ static int get_pixel_format(AVCodecContext *avctx)
 #if CONFIG_AV1_VDPAU_HWACCEL
 *fmtp++ = AV_PIX_FMT_VDPAU;
 #endif
+#if CONFIG_AV1_VIDEOTOOLBOX_HWACCEL
+*fmtp++ = AV_PIX_FMT_VIDEOTOOLBOX;
+#endif
 #if CONFIG_AV1_VULKAN_HWACCEL
 *fmtp++ = AV_PIX_FMT_VULKAN;
 #endif
@@ -592,6 +596,9 @@ static int get_pixel_format(AVCodecContext *avctx)
 #if CONFIG_AV1_VDPAU_HWACCEL
 *fmtp++ = AV_PIX_FMT_VDPAU;
 #endif
+#if CONFIG_AV1_VIDEOTOOLBOX_HWACCEL
+*fmtp++ = AV_PIX_FMT_VIDEOTOOLBOX;
+#endif
 #if CONFIG_AV1_VULKAN_HWACCEL
 *fmtp++ = AV_PIX_FMT_VULKAN;
 #endif
@@ -1594,6 +1601,9 @@ const FFCodec ff_av1_decoder = {
 #if CONFIG_AV1_VDPAU_HWACCEL
 HWACCEL_VDPAU(av1),
 #endif
+#if CONFIG_AV1_VIDEOTOOLBOX_HWACCEL
+HWACCEL_VIDEOTOOLBOX(av1),
+#endif
 #if CONFIG_AV1_VULKAN_HWACCEL
 HWACCEL_VULKAN(av1),
 #endif
diff --git a/libavcodec/hwaccels.h b/libavcodec/hwaccels.h
index 5171e4c7d7..2b9bdc8fc9 100644
--- a/libavcodec/hwaccels.h
+++ b/libavcodec/hwaccels.h
@@ -26,6 +26,7 @@ extern const struct FFHWAccel ff_av1_dxva2_hwaccel;
 extern const struct FFHWAccel ff_av1_nvdec_hwaccel;
 extern const struct FFHWAccel ff_av1_vaapi_hwaccel;
 extern const struct FFHWAccel ff_av1_vdpau_hwaccel;
+extern const struct FFHWAccel ff_av1_videotoolb

Re: [FFmpeg-devel] [PATCH v3] libavutil/ppc: Make use of getauxval() and elf_aux_info() on ppc

2024-09-20 Thread Brad Smith 

ping.

On 2024-09-15 1:40 a.m., Brad Smith wrote:

libavutil/ppc: Make use of getauxval() and elf_aux_info() on ppc

Modern Linux has getauxval() and FreeBSD/OpenBSD ppc have elf_aux_info().

Signed-off-by: Brad Smith 
---
v2: adjust to build with older glibc.
v3: freebsd/ppc requires machine/cpu.h header for feature flags.

  libavutil/ppc/cpu.c | 25 +
  1 file changed, 25 insertions(+)

diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
index 2b13cda662..9381272175 100644
--- a/libavutil/ppc/cpu.c
+++ b/libavutil/ppc/cpu.c
@@ -20,6 +20,11 @@
  
  #ifdef __APPLE__

  #include 
+#elif HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+#ifdef __FreeBSD__
+#include 
+#endif
+#include 
  #elif defined(__linux__)
  #include 
  #include 
@@ -56,6 +61,26 @@ int ff_get_cpu_flags_ppc(void)
  if (result == VECTORTYPE_ALTIVEC)
  return AV_CPU_FLAG_ALTIVEC;
  return 0;
+#elif HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+int flags = 0;
+
+unsigned long hwcap = ff_getauxval(AT_HWCAP);
+#ifdef PPC_FEATURE2_ARCH_2_07
+unsigned long hwcap2 = ff_getauxval(AT_HWCAP2);
+#endif
+
+if (hwcap & PPC_FEATURE_HAS_ALTIVEC)
+   flags |= AV_CPU_FLAG_ALTIVEC;
+#ifdef PPC_FEATURE_HAS_VSX
+if (hwcap & PPC_FEATURE_HAS_VSX)
+   flags |= AV_CPU_FLAG_VSX;
+#endif
+#ifdef PPC_FEATURE2_ARCH_2_07
+if (hwcap2 & PPC_FEATURE2_ARCH_2_07)
+   flags |= AV_CPU_FLAG_POWER8;
+#endif
+
+return flags;
  #elif defined(__APPLE__) || defined(__NetBSD__) || defined(__OpenBSD__)
  #if defined(__NetBSD__) || defined(__OpenBSD__)
  int sels[2] = {CTL_MACHDEP, CPU_ALTIVEC};

___
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_encode: set the quality level in session parameters

2024-09-20 Thread Lynne via ffmpeg-devel 

On 20/09/2024 13:33, Víctor Manuel Jáquez Leal wrote:

While running this command

./ffmpeg_g -loglevel debug -hwaccel vulkan -init_hw_device vulkan=vk:0,debug=1 
-hwaccel_output_format vulkan -i input.y4m -vf 'format=nv12,hwupload' -c:v 
h264_vulkan -quality 2 output.mp4 -y

It hit this validation error:

Validation Error: [ VUID-vkCmdEncodeVideoKHR-None-08318 ] Object 0: handle =
0x8f8f, type = VK_OBJECT_TYPE_VIDEO_SESSION_KHR; Object 1: handle =
0xfdfd, type = VK_OBJECT_TYPE_VIDEO_SESSION_PARAMETERS_KHR;
| MessageID = 0x5dc3dd39
| vkCmdEncodeVideoKHR(): The currently configured encode quality level (2) for
VkVideoSessionKHR 0x8f8f[] does not match the encode quality level (0)
VkVideoSessionParametersKHR 0xfdfd[] was created with. The Vulkan spec
states: The bound video session parameters object must have been created with
the currently set video encode quality level for the bound video session at the
time the command is executed on the
device 
(https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdEncodeVideoKHR-None-08318)

This patch sets the quality level at session parameter creation for both H.264
and H.265 Vulkan encoders.
---
  libavcodec/vulkan_encode_h264.c | 8 +++-
  libavcodec/vulkan_encode_h265.c | 8 +++-
  2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vulkan_encode_h264.c b/libavcodec/vulkan_encode_h264.c
index af229afe52..4b78e6f43d 100644
--- a/libavcodec/vulkan_encode_h264.c
+++ b/libavcodec/vulkan_encode_h264.c
@@ -1016,6 +1016,7 @@ static int create_session_params(AVCodecContext *avctx)
  VkVideoEncodeH264SessionParametersAddInfoKHR h264_params_info;
  VkVideoEncodeH264SessionParametersCreateInfoKHR h264_params;
  VkVideoSessionParametersCreateInfoKHR session_params_create;
+VkVideoEncodeQualityLevelInfoKHR q_info;
  
  /* Convert it to Vulkan */

  err = base_unit_to_vk(avctx, &vk_units);
@@ -1044,9 +1045,14 @@ static int create_session_params(AVCodecContext *avctx)
  .maxStdPPSCount = 1,
  .pParametersAddInfo = &h264_params_info,
  };
+q_info = (VkVideoEncodeQualityLevelInfoKHR) {
+.sType = VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUALITY_LEVEL_INFO_KHR,
+.pNext = &h264_params,
+.qualityLevel = ctx->opts.quality,
+};
  session_params_create = (VkVideoSessionParametersCreateInfoKHR) {
  .sType = VK_STRUCTURE_TYPE_VIDEO_SESSION_PARAMETERS_CREATE_INFO_KHR,
-.pNext = &h264_params,
+.pNext = &q_info,
  .videoSession = ctx->common.session,
  .videoSessionParametersTemplate = NULL,
  };
diff --git a/libavcodec/vulkan_encode_h265.c b/libavcodec/vulkan_encode_h265.c
index 3cb7a3b7df..f1e61ab894 100644
--- a/libavcodec/vulkan_encode_h265.c
+++ b/libavcodec/vulkan_encode_h265.c
@@ -1166,6 +1166,7 @@ static int create_session_params(AVCodecContext *avctx)
  VkVideoEncodeH265SessionParametersAddInfoKHR h265_params_info;
  VkVideoEncodeH265SessionParametersCreateInfoKHR h265_params;
  VkVideoSessionParametersCreateInfoKHR session_params_create;
+VkVideoEncodeQualityLevelInfoKHR q_info;
  
  /* Convert it to Vulkan */

  err = base_unit_to_vk(avctx, &vk_units);
@@ -1197,9 +1198,14 @@ static int create_session_params(AVCodecContext *avctx)
  .maxStdVPSCount = 1,
  .pParametersAddInfo = &h265_params_info,
  };
+q_info = (VkVideoEncodeQualityLevelInfoKHR) {
+.sType = VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUALITY_LEVEL_INFO_KHR,
+.pNext = &h265_params,
+.qualityLevel = ctx->opts.quality,
+};
  session_params_create = (VkVideoSessionParametersCreateInfoKHR) {
  .sType = VK_STRUCTURE_TYPE_VIDEO_SESSION_PARAMETERS_CREATE_INFO_KHR,
-.pNext = &h265_params,
+.pNext = &q_info,
  .videoSession = ctx->common.session,
  .videoSessionParametersTemplate = NULL,
  };


Could you move this to vulkan_encode.c?
Thanks


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/cuviddec: Add handling HDR10+ sidedata on cuviddec.

2024-09-20 Thread averne 
Le 20/09/2024 à 20:41, Carlos Ruiz a écrit :> The native hevc codec doesn't
> support resizing, so you decode video at full 4k on the gpu, which means
> allocating
> something like 5-10 surfaces at 3840x2160 which becomes 250MB of GPU memory,
> and then you have immediately take all of those frames, pass them through a
> filterchain,
> scale them down to e.g. 640x360, and waste CUDA cores instead of leveraging
> the
> dedicated video downsizing inside the NVDEC chip. Now do that for 50 camera
> streams
> and you'll quickly run out of GPU memory with a GPU utilization under 10%
> haha.

NVDEC does not implement fixed-function downscaling, in fact none of the 
desktop cards have any hardware dedicated to that.  
As far as I know, scaling, deinterlacing, and generally all post-processing
is done on the compute engine via cuda. This is still pretty efficient 
since the data can be shared between the decode/compute engines without
copy.
Tegra chips are the only ones that come with a VIC engine (Video & Image
Compositor) which can do scaling, deinterlacing, spatial/temporal filtering, 
and basic compositing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/cuviddec: Add handling HDR10+ sidedata on cuviddec.

2024-09-20 Thread Lynne via ffmpeg-devel 

On 20/09/2024 20:41, Carlos Ruiz wrote:

It's just that the cuviddec decoder is more of a relic, from before the
native hwaccel existed.
The only reason it's not straight up deprecated is that it's sometimes
nice to have a "second opinion" when issues crop up, and there are a few
specific features like hardware-deinterlacing that can't be exposed via
the native hwaccel.

But I'd normally not like to expand it even further and add complex and
large features to it. Whenever possible, the native nvdec hwaccel should
be used.


As someone who recently switched from *_cuvid to * + hwaccel=cuda I have to
agree
that the performance (timing-wise at least) has been very comparable for
decoding.

The only comment I'd like to make though, and this might be a bit of
unpopular opinion
based on some other threads I read, but there are huge advantages of hwaccel
accelerating not just decoding but also resizing (and I guess optionally
cropping).
I know that ideally a decoder should only decode, but think about a common
usecase
in the AI world we live in: you get a bunch of simultaneous 4k (or 1080p)
incoming
rtsp streams and you want to decode the video and pass it through some ML
model,
e.g. in TensorRT (to stick with the Nvidia example). The native hevc codec
doesn't
support resizing, so you decode video at full 4k on the gpu, which means
allocating
something like 5-10 surfaces at 3840x2160 which becomes 250MB of GPU memory,
and then you have immediately take all of those frames, pass them through a
filterchain,
scale them down to e.g. 640x360, and waste CUDA cores instead of leveraging
the
dedicated video downsizing inside the NVDEC chip. Now do that for 50 camera
streams
and you'll quickly run out of GPU memory with a GPU utilization under 10%
haha.

This is exactly why I submitted a patch yesterday that would allow using
the hevc
codec with nvdec hwaccel, while resizing on the gpu like hevc_cuviddec
does, and
the memory (and GPU) consuption goes waaay down (e.g. 6MB of GPU VRAM
instead of 250MB per camera). I know this is a different discussion but
thought
it was appropriate to share because deprecating cuviddec or rejecting my
patch
would leave part of the community out.


On Fri, Sep 20, 2024 at 12:48 PM Timo Rothenpieler 
wrote:


On 20/09/2024 04:08, 김윤주 wrote:

Does native decoder refer to hevc (hevcdec.c)?
I tried using hevc and in environments with low CPU performance,

hevc_cuvid

was much faster.
So, I used hevc_cuvid for decoding but encountered an issue where HDR10+
sidedata did not exist.
That's why I wrote this patch.


You did turn on hwaccel, right?
I don't see why the native decoder would be much slower at parsing then
nvidias parsers.


I thought that the original content's sidedata should be preserved even
after decoding regardless of which decoder is used.
And I thought hevc_cuvid was the only way to get Nvidia hwaccel support.
If I'm mistaken about anything, please let me know.


It's just that the cuviddec decoder is more of a relic, from before the
native hwaccel existed.
The only reason it's not straight up deprecated is that it's sometimes
nice to have a "second opinion" when issues crop up, and there are a few
specific features like hardware-deinterlacing that can't be exposed via
the native hwaccel.

But I'd normally not like to expand it even further and add complex and
large features to it. Whenever possible, the native nvdec hwaccel should
be used.


Also, is it correct to respond to your comments like this?
It seems quite different from the format you sent.


Top-posting isn't exactly liked here, though I don't really have a
strong opinion on it.


Apologies, as I'm still relatively new to the FFmpeg community and have a
lot to learn.
Any additional guidance would be greatly appreciated.

-Original Message-
From: ffmpeg-devel  On Behalf Of Timo
Rothenpieler
Sent: Friday, September 20, 2024 4:48 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/cuviddec: Add handling HDR10+
sidedata on cuviddec.

On 19.09.2024 06:43, yoonjoo wrote:

Implemented decoding of NAL units and handling HDR10+ sidedata by
referring to hevcdec.


Why? Can't you just use the native decoder with nvdec hwaccel?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://protect2.fireeye.com/v1/url?k=c11e9bb6-9e85a2a9-c11f10f9-
000babdfecba-c4d76825032a0b52&q=1&e=342e88a0-295e-4dc1-a57f-


8f5aab974009&u=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel


To unsubscribe, visit link above, or email

ffmpeg-devel-requ...@ffmpeg.org

with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailma

Re: [FFmpeg-devel] PATCH] Make H.274 film grain support optional for H.264. Saves ~779kb.

2024-09-20 Thread Lynne via ffmpeg-devel 

On 20/09/2024 20:51, Dale Curtis wrote:

Were there any more comments for this patch?

- dale

On Tue, Aug 13, 2024 at 11:30 PM Christophe Gisquet <
christophe.gisq...@gmail.com> wrote:


Hi,

Le mar. 13 août 2024 à 23:39, Dale Curtis  a
écrit :


On Tue, Aug 13, 2024 at 1:11 PM Hendrik Leppkes 

wrote:



Disabling random codec features seems like an anti-feature to me, in
the future it'll make every feature be questioned and compile-time
conditional, and make everything terrible.
If the context size is the major concern, maybe large structures
should be allocated when in use, rather than always?



I agree with that, so here's a version which allocates dynamically

instead.

It passes FATE, but I didn't try with valgrind/msan in case I missed a
cleanup path.


(not an author)
Probably there is remaining work pending on external dependencies, but
H274FilmGrainDatabase sounds a bit adhoc. The 8KB of slice_tmp for one
could just be a local variable in init_slice(). The 676KB (!) of the
noise database are a bit more puzzling and could be the one that needs
allocating only when the noise is generated. It may simplify a bit
some of the conditions in this patch.

--
Christophe


I agree with Hendrik and Dale.


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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] doc: Add email URLs for Fate sample-request

2024-09-20 Thread Michael Niedermayer 
On Fri, Sep 20, 2024 at 02:50:18AM +0200, Martin Schitter wrote:
> Because I'm now waiting for one week that someone finally puts my
> contributed DNxUncompressed sample files to the Fate sample repo
> (see: 
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-September/333471.html),
> I frequently looked into the documentation to find out, what I could
> have done wrong? I always found it rather confusing, that most other
> ffmpeg contact email addresses are clearly visible formatted as
> highlighted URL, but this particular one seems to be hidden for one or
> the reason. So I suggest changing this present state by this patch.
> 
> And btw.: I still would be happy if someone could transfer my samples
> to the Fate repo to finally see a clean patchwork run and get closer to
> to the day when my code contribution can be merged.
>  
> thanks
> martin
> 
> ---
>  doc/developer.texi | 2 +-
>  doc/fate.texi  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

please add the address also to MAINTAINERS

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr


signature.asc
Description: PGP signature
___
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/3] - libavcodec/aom_film_grain: Add apply_grain flag

2024-09-20 Thread Lynne via ffmpeg-devel 

On 20/09/2024 09:42, Segall, Andrew wrote:



On 9/20/24, 12:15 AM, "ffmpeg-devel on behalf of Lynne via ffmpeg-devel" 
mailto:ffmpeg-devel-boun...@ffmpeg.org> on behalf of 
ffmpeg-devel@ffmpeg.org > wrote:


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.






On 20/09/2024 02:44, Segall, Andrew via ffmpeg-devel wrote:

Details: Add support for the apply_grain_flag. This allows the film grain 
process to be enabled/disabled for different display properties.

On 9/8/24, 12:06 AM, "Andrew Segall" mailto:aseg...@amazon.com> 
>> wrote:


Signed-off-by: Andrew Segall mailto:aseg...@amazon.com> 
>>
---
libavcodec/aom_film_grain.c | 6 --
libavcodec/hevc/hevcdec.c | 5 -
libavfilter/vf_showinfo.c | 1 +
libavutil/film_grain_params.h | 5 +
4 files changed, 14 insertions(+), 3 deletions(-)


diff --git a/libavcodec/aom_film_grain.c b/libavcodec/aom_film_grain.c
index fdfa3dbf77..251a2793ac 100644
--- a/libavcodec/aom_film_grain.c
+++ b/libavcodec/aom_film_grain.c
@@ -149,8 +149,10 @@ int ff_aom_parse_film_grain_sets(AVFilmGrainAFGS1Params *s,
fgp = &s->sets[set_idx];
aom = &fgp->codec.aom;


- fgp->type = get_bits1(gb) ? AV_FILM_GRAIN_PARAMS_AV1 : 
AV_FILM_GRAIN_PARAMS_NONE;
- if (!fgp->type)
+ fgp->type = AV_FILM_GRAIN_PARAMS_AV1;
+
+ fgp->apply_grain = get_bits1(gb);
+ if ( !fgp->apply_grain)
{
payload_bits = get_bits_count(gb) - start_position;
if (payload_bits > payload_size * 8)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index d915d74d22..8dd4fb10c5 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -3155,7 +3155,10 @@ static int hevc_frame_end(HEVCContext *s)
&s->h274db, fgp);
break;
case AV_FILM_GRAIN_PARAMS_AV1:
- ret = ff_aom_apply_film_grain(out->frame_grain, out->f, fgp);
+ if(fgp->apply_grain)
+ ret = ff_aom_apply_film_grain(out->frame_grain, out->f, fgp);
+ else
+ out->needs_fg = 0;
break;
}
av_assert1(ret >= 0);
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index f81df9d1bf..08e144ca46 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -455,6 +455,7 @@ static void 
dump_sei_film_grain_params_metadata(AVFilterContext *ctx, const AVFr
}


av_log(ctx, AV_LOG_INFO, "type %s; ", film_grain_type_names[fgp->type]);
+ av_log(ctx, AV_LOG_INFO, "apply_grain=%d; ", fgp->apply_grain);
av_log(ctx, AV_LOG_INFO, "seed=%"PRIu64"; ", fgp->seed);
av_log(ctx, AV_LOG_INFO, "width=%d; ", fgp->width);
av_log(ctx, AV_LOG_INFO, "height=%d; ", fgp->height);
diff --git a/libavutil/film_grain_params.h b/libavutil/film_grain_params.h
index ccacab88fe..f3275923e1 100644
--- a/libavutil/film_grain_params.h
+++ b/libavutil/film_grain_params.h
@@ -241,6 +241,11 @@ typedef struct AVFilmGrainParams {
*/
enum AVFilmGrainParamsType type;


+ /**
+ * Specifies if film grain parameters are enabled.
+ */
+ int apply_grain;
+
/**
* Seed to use for the synthesis process, if the codec allows for it.
*




This is an ABI break.



Furthermore, what exactly does this improve over simply stripping the side data?


Mainly addressing conformance issues.

Example is that we have two parameters in the AFGS1 message.  The first is 
associated with resolution A and apply_grain=1.  Second is associated with 
resolution B and apply_grain=0.

If the synthesis Is performed at resolution B, then the message says that we 
shouldn't perform film grain synthesis since apply_grain=0.  However, if we 
strip, the information is lost - and synthesis may use the parameters 
associated with resolution A instead.


Ah, I see, that makes sense.

You should put the new flag on the bottom, after bit_depth_chroma, to 
avoid breaking the ABI.
You should also make sure that nothing gets broken. That includes adding 
apply = 1 in av_film_grain_params_create_side_data() to enable it by 
default, and making sure that all libavcodec users of the API are updated.


Also, better call it simply `apply`, its in a structure called 
AVFilmGrainParams after all.


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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/3] - libavcodec/aom_film_grain: Handle byte alignment when multiple film grain parameters sets are present in the bitstream

2024-09-20 Thread Michael Niedermayer 
On Fri, Sep 20, 2024 at 12:42:47AM +, Segall, Andrew via ffmpeg-devel wrote:
> More info: Series of patches to align the implementation of aom_film_grain.c 
> with the AOM specification.
> 
> First time committing.  Suggestions very welcome.
> 
> Signed-off-by: Andrew Segall mailto:aseg...@amazon.com>>
> ---
> libavcodec/aom_film_grain.c | 12 
> 1 file changed, 12 insertions(+)
> 
> 
> diff --git a/libavcodec/aom_film_grain.c b/libavcodec/aom_film_grain.c
> index e302567ba5..fdfa3dbf77 100644
> --- a/libavcodec/aom_film_grain.c
> +++ b/libavcodec/aom_film_grain.c
> @@ -151,12 +151,24 @@ int ff_aom_parse_film_grain_sets(AVFilmGrainAFGS1Params 
> *s,
> 
> 
> fgp->type = get_bits1(gb) ? AV_FILM_GRAIN_PARAMS_AV1 : 
> AV_FILM_GRAIN_PARAMS_NONE;
> if (!fgp->type)
> + {
> + payload_bits = get_bits_count(gb) - start_position;
> + if (payload_bits > payload_size * 8)
> + goto error;
> + skip_bits(gb, payload_size * 8 - payload_bits);
> continue;
> + }

patch is corrupted by linebreaks / wordwrap, check youe MUA/editor settings

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier


signature.asc
Description: PGP signature
___
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/7] avformat/mov_chan: Check for FF_SANE_NB_CHANNELS

2024-09-20 Thread Anton Khirnov 
Quoting Michael Niedermayer (2024-09-17 19:59:53)
> On Sun, Sep 15, 2024 at 09:09:39PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-09-13 19:48:46)
> [...]
> > > > 
> > > > > +#include "libavcodec/internal.h"
> > > > 
> > > > I dislike this as well.
> > > 
> > > I am fine with it.
> > > 
> > > But if you dont, then maybe you can suggest another way to check
> > > for the number that we support.
> > 
> > My second objection, in case it is not clear, is to libavformat
> > including libavcodec internal headers that define libavcodec internal
> > structures. That is a slippery slope that easily leads to people
> > actually accessing those internal structures.
> > 
> 
> > But also the number 512 is entirely arbitrary, and if we decide to
> > arbitrarily restrict the channel count everywhere then it should be done
> > at the level of AVChannelLayout. E.g. by making nb_channels and uint8 or
> > uint16, and/or adding the check to av_channel_layout_check().
> 
> Now that this specific issue is fixed by james patch.
> Would you agree that the more general issue of "something" allocating
> and or processing a large number of channels can be checked for ?

Depends on how it is done. I do NOT agree with ad-hoc checks scattered
across random demuxers.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/cuviddec: Add handling HDR10+ sidedata on cuviddec.

2024-09-20 Thread Timo Rothenpieler 

On 20/09/2024 04:08, 김윤주 wrote:

Does native decoder refer to hevc (hevcdec.c)?
I tried using hevc and in environments with low CPU performance, hevc_cuvid
was much faster.
So, I used hevc_cuvid for decoding but encountered an issue where HDR10+
sidedata did not exist.
That's why I wrote this patch.


You did turn on hwaccel, right?
I don't see why the native decoder would be much slower at parsing then 
nvidias parsers.



I thought that the original content's sidedata should be preserved even
after decoding regardless of which decoder is used.
And I thought hevc_cuvid was the only way to get Nvidia hwaccel support.
If I'm mistaken about anything, please let me know.


It's just that the cuviddec decoder is more of a relic, from before the 
native hwaccel existed.
The only reason it's not straight up deprecated is that it's sometimes 
nice to have a "second opinion" when issues crop up, and there are a few 
specific features like hardware-deinterlacing that can't be exposed via 
the native hwaccel.


But I'd normally not like to expand it even further and add complex and 
large features to it. Whenever possible, the native nvdec hwaccel should 
be used.



Also, is it correct to respond to your comments like this?
It seems quite different from the format you sent.


Top-posting isn't exactly liked here, though I don't really have a 
strong opinion on it.



Apologies, as I'm still relatively new to the FFmpeg community and have a
lot to learn.
Any additional guidance would be greatly appreciated.

-Original Message-
From: ffmpeg-devel  On Behalf Of Timo
Rothenpieler
Sent: Friday, September 20, 2024 4:48 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/cuviddec: Add handling HDR10+
sidedata on cuviddec.

On 19.09.2024 06:43, yoonjoo wrote:

Implemented decoding of NAL units and handling HDR10+ sidedata by
referring to hevcdec.


Why? Can't you just use the native decoder with nvdec hwaccel?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://protect2.fireeye.com/v1/url?k=c11e9bb6-9e85a2a9-c11f10f9-
000babdfecba-c4d76825032a0b52&q=1&e=342e88a0-295e-4dc1-a57f-
8f5aab974009&u=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel

To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] vulkan_encode: set the quality level in session parameters

2024-09-20 Thread Víctor Manuel Jáquez Leal 
While running this command

./ffmpeg_g -loglevel debug -hwaccel vulkan -init_hw_device vulkan=vk:0,debug=1 
-hwaccel_output_format vulkan -i input.y4m -vf 'format=nv12,hwupload' -c:v 
h264_vulkan -quality 2 output.mp4 -y

It hit this validation error:

Validation Error: [ VUID-vkCmdEncodeVideoKHR-None-08318 ] Object 0: handle =
0x8f8f, type = VK_OBJECT_TYPE_VIDEO_SESSION_KHR; Object 1: handle =
0xfdfd, type = VK_OBJECT_TYPE_VIDEO_SESSION_PARAMETERS_KHR;
| MessageID = 0x5dc3dd39
| vkCmdEncodeVideoKHR(): The currently configured encode quality level (2) for
VkVideoSessionKHR 0x8f8f[] does not match the encode quality level (0)
VkVideoSessionParametersKHR 0xfdfd[] was created with. The Vulkan spec
states: The bound video session parameters object must have been created with
the currently set video encode quality level for the bound video session at the
time the command is executed on the
device 
(https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdEncodeVideoKHR-None-08318)

This patch sets the quality level at session parameter creation for both H.264
and H.265 Vulkan encoders.
---
 libavcodec/vulkan_encode_h264.c | 8 +++-
 libavcodec/vulkan_encode_h265.c | 8 +++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vulkan_encode_h264.c b/libavcodec/vulkan_encode_h264.c
index af229afe52..4b78e6f43d 100644
--- a/libavcodec/vulkan_encode_h264.c
+++ b/libavcodec/vulkan_encode_h264.c
@@ -1016,6 +1016,7 @@ static int create_session_params(AVCodecContext *avctx)
 VkVideoEncodeH264SessionParametersAddInfoKHR h264_params_info;
 VkVideoEncodeH264SessionParametersCreateInfoKHR h264_params;
 VkVideoSessionParametersCreateInfoKHR session_params_create;
+VkVideoEncodeQualityLevelInfoKHR q_info;
 
 /* Convert it to Vulkan */
 err = base_unit_to_vk(avctx, &vk_units);
@@ -1044,9 +1045,14 @@ static int create_session_params(AVCodecContext *avctx)
 .maxStdPPSCount = 1,
 .pParametersAddInfo = &h264_params_info,
 };
+q_info = (VkVideoEncodeQualityLevelInfoKHR) {
+.sType = VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUALITY_LEVEL_INFO_KHR,
+.pNext = &h264_params,
+.qualityLevel = ctx->opts.quality,
+};
 session_params_create = (VkVideoSessionParametersCreateInfoKHR) {
 .sType = VK_STRUCTURE_TYPE_VIDEO_SESSION_PARAMETERS_CREATE_INFO_KHR,
-.pNext = &h264_params,
+.pNext = &q_info,
 .videoSession = ctx->common.session,
 .videoSessionParametersTemplate = NULL,
 };
diff --git a/libavcodec/vulkan_encode_h265.c b/libavcodec/vulkan_encode_h265.c
index 3cb7a3b7df..f1e61ab894 100644
--- a/libavcodec/vulkan_encode_h265.c
+++ b/libavcodec/vulkan_encode_h265.c
@@ -1166,6 +1166,7 @@ static int create_session_params(AVCodecContext *avctx)
 VkVideoEncodeH265SessionParametersAddInfoKHR h265_params_info;
 VkVideoEncodeH265SessionParametersCreateInfoKHR h265_params;
 VkVideoSessionParametersCreateInfoKHR session_params_create;
+VkVideoEncodeQualityLevelInfoKHR q_info;
 
 /* Convert it to Vulkan */
 err = base_unit_to_vk(avctx, &vk_units);
@@ -1197,9 +1198,14 @@ static int create_session_params(AVCodecContext *avctx)
 .maxStdVPSCount = 1,
 .pParametersAddInfo = &h265_params_info,
 };
+q_info = (VkVideoEncodeQualityLevelInfoKHR) {
+.sType = VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUALITY_LEVEL_INFO_KHR,
+.pNext = &h265_params,
+.qualityLevel = ctx->opts.quality,
+};
 session_params_create = (VkVideoSessionParametersCreateInfoKHR) {
 .sType = VK_STRUCTURE_TYPE_VIDEO_SESSION_PARAMETERS_CREATE_INFO_KHR,
-.pNext = &h265_params,
+.pNext = &q_info,
 .videoSession = ctx->common.session,
 .videoSessionParametersTemplate = NULL,
 };
-- 
2.45.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".