Re: [FFmpeg-devel] [RFC] flac_wasted32 vector implementation for VSX on ppc64le
On Thu, Jun 6, 2024, 05:53 Rémi Denis-Courmont wrote:
>
>
> Le 6 juin 2024 10:43:05 GMT+03:00, Sean McGovern a
> écrit :
> >Hi,
> >
> >Attached inline is a _non-working_ implementation of flac_wasted32 for
> >VSX developed on a POWER9 in little-endian mode but probably just as
> >usable on POWER{8,10}.
> >
> >I'm not sure why probably one of the simplest DSP functions in lavc
> >does not work for me, I imagine this is probably something endian
> >related even though IBM's documentation for vec_sl()[1] does not
> >suggest any.
>
> Mixing up bytes and elements in the iterator. But you should be able to
> track this down with gdb or good ol' printf().
>
> >Here's my code:
> >
> >#define VSX_STRIDE 16
> >
> >void ff_flac_wasted32_vsx(int32_t *decoded, int wasted, int len)
> >{
> > register vec_s32 vec1;
> > register vec_u32 vec2 = { wasted, wasted, wasted, wasted };
>
> There should be an instruction to splat a scalar to a vector. Better yet
> use vector-scalar shift, if VSX has it.
>
In the POWER ISA, vec_splat() only accepts an immediate, so I think this is
the only way to do it in flac_wasted32.
> > register vec_s32 shifted;
> >
> > for (int i = 0; i < len; i += VSX_STRIDE) {
> > vec1 = vec_vsx_ld(i, decoded);
> > shifted = vec_sl(vec1, vec2);
> > vec_vsx_st(shifted, i, decoded);
> > }
> >}
> >
> >Anyone with experience with AltiVec or VSX see something obvious I am
> missing?
> >
> >-- Sean McGovern
> >
> >[1]
> https://www.ibm.com/docs/en/xl-c-and-cpp-linux/16.1.1?topic=functions-vec-sl
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >To unsubscribe, visit link above, or email
> >ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC] flac_wasted32 vector implementation for VSX on ppc64le
Hi,
Attached inline is a _non-working_ implementation of flac_wasted32 for
VSX developed on a POWER9 in little-endian mode but probably just as
usable on POWER{8,10}.
I'm not sure why probably one of the simplest DSP functions in lavc
does not work for me, I imagine this is probably something endian
related even though IBM's documentation for vec_sl()[1] does not
suggest any.
Here's my code:
#define VSX_STRIDE 16
void ff_flac_wasted32_vsx(int32_t *decoded, int wasted, int len)
{
register vec_s32 vec1;
register vec_u32 vec2 = { wasted, wasted, wasted, wasted };
register vec_s32 shifted;
for (int i = 0; i < len; i += VSX_STRIDE) {
vec1 = vec_vsx_ld(i, decoded);
shifted = vec_sl(vec1, vec2);
vec_vsx_st(shifted, i, decoded);
}
}
Anyone with experience with AltiVec or VSX see something obvious I am missing?
-- Sean McGovern
[1] https://www.ibm.com/docs/en/xl-c-and-cpp-linux/16.1.1?topic=functions-vec-sl
___
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] FFmpeg 7.0 blocking issues
On Mon, Jun 3, 2024, 17:32 Michael Niedermayer wrote: > On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote: > > On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote: > > > On 2024-03-02 20:39:08 -0500, Sean McGovern wrote: > > > > On Sat, Mar 2, 2024, 18:19 Michael Niedermayer < > mich...@niedermayer.cc> > > > > wrote: > > > > > > > > > On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote: > > > > > > On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote: > > > > > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer > wrote: > > > > > > > > Hi all > > > > > > > > > > > > > > > > As it was a little difficult for me to not loose track of > what is > > > > > > > > blocking a release. I suggest that for all release blocking > issues > > > > > > > > open a ticket and set Blocking to 7.0 > > > > > > > > that way this: > > > > > > > > https://trac.ffmpeg.org/query?blocking=~7.0 > > > > > > > > > > > > > > > > or for the ones not closed: > > > > > > > > > > > > > > https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 > > > > > > > > > > > > > > > > will list all blocking issues > > > > > > > > > > > > > > > > Ive added one, for testing that, i intend to add more if i > see > > > > > something > > > > > > > > > > > > > > > > What is blocking? (IMHO) > > > > > > > > * regressions (unless its non possible to fix before release) > > > > > > > > * crashes > > > > > > > > * security issues > > > > > > > > * data loss > > > > > > > > * privacy issues > > > > > > > > * anything the commuity agrees should be in the release > > > > > > > > > > > > > > We still have 3 blocking issues on trac > > > > > > > > > > > > > > do people want me to wait or ignore them and branch ? > > > > > > > Iam not sure when the exact deadline is but if we keep waiting > > > > > > > we will not get into ubuntu 24.04 LTS > > > > > > > > > > > > 24.04 is past feature freeze, so it's too late for that. > > > > > > > > > > we should aim earlier in the future then. > > > > > > > > > > > > > > > > > > LTS is only every 2 years, yes? > > > > > > Yes > > > > > > > How do we make sure this doesn't happen in 2026? How much of a gap > is there > > > > between feature freeze and release? > > > > > > Not involved in Ubuntu, so that's from past experience: feature > > > freeze is usually about two months before the release. > > > > > > So here's the catch: Debian's timeline also needs to be taken into > > > account. If the ffmpeg release does not involve the removal of > deprecated API and > > > a SONAME bump, then the time from ffmpeg to release to upload to Debian > > > unstable and then import in Ubuntu is short. In this case, I am sure > > > that I could convince Ubuntu maintainers to import it even during > > > feature freeze. > > > > > > But with SONAME bumps and changes in the API, it takes a lot more time > > > to work through the high number of ffmpeg reverse dependencies. In that > > > case, plan a release at least 6 months before an Ubuntu LTS release. > > > > > > > > > > > > We usually have to rely on upstream maintainers to adopt to the > > > changes and that take times. Many moons ago Anton helped with providing > > > patches, but for the last couple of API changes it took some months > from > > > "dear maintainer, here is ffmpeg X for testing, please fix the build of > > > your package" to actually doing all uploads and rebuilds. For example, > > > the transition to ffmpeg 6.0 was started in July 2023 and was done in > > > December 2023. > > > > Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in > > Debian. The list is available at [1]. So if you want ffmpeg X to be in > > Debian Y or Ubuntu Z, X needs to be released at least half a year before
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec: various: remove empty directories originally for legacy DSP code
On Thu, May 30, 2024 at 5:21 PM Sean McGovern wrote: > > --- > libavcodec/bfin/README | 6 -- > libavcodec/sh4/README | 6 -- > libavcodec/sparc/README | 6 -- > 3 files changed, 18 deletions(-) > delete mode 100644 libavcodec/bfin/README > delete mode 100644 libavcodec/sh4/README > delete mode 100644 libavcodec/sparc/README > > diff --git a/libavcodec/bfin/README b/libavcodec/bfin/README > deleted file mode 100644 > index afb3461b72..00 > --- a/libavcodec/bfin/README > +++ /dev/null > @@ -1,6 +0,0 @@ > -BFIN optimizations have been removed in > -commit 880e2aa23645ed9871c66ee1cbd00f93c72d2d73 > -The last revission with the optimizations is > fa4e17c14035ebf43130fb369e1728cdd98d0b72 > - > -If you want to maintain these (or other) BFIN optimizations in ffmpeg, then > please > -contact ffmpeg-devel@ffmpeg.org > diff --git a/libavcodec/sh4/README b/libavcodec/sh4/README > deleted file mode 100644 > index 8dd61fe875..00 > --- a/libavcodec/sh4/README > +++ /dev/null > @@ -1,6 +0,0 @@ > -SH4 optimizations have been removed in > -commit d6096a67422534918405abb46dafbbac4608cbc3 > -The last revission with the optimizations is > cbfc9046e1c7e295b74f252902ae6f255eef4e78 > - > -If you want to maintain these (or other) SH4 optimizations in ffmpeg, then > please > -contact ffmpeg-devel@ffmpeg.org > diff --git a/libavcodec/sparc/README b/libavcodec/sparc/README > deleted file mode 100644 > index f9f2349cd4..00 > --- a/libavcodec/sparc/README > +++ /dev/null > @@ -1,6 +0,0 @@ > -SPARC optimizations have been removed in > -commit b4dd424d96f09f9bafb88e47f37df65dc4529143 > -The last revission with the optimizations is > fb1b70c1ed50951c5fc1a309c3c446b2eaaf564b > - > -If you want to maintain these (or other) SPARC optimizations in ffmpeg, then > please > -contact ffmpeg-devel@ffmpeg.org > -- > 2.39.2 > Ping. ___ 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] [RFC] libavutil: remove AVR32 assembly
---
libavutil/avr32/bswap.h| 44
libavutil/avr32/intreadwrite.h | 182 -
2 files changed, 226 deletions(-)
delete mode 100644 libavutil/avr32/bswap.h
delete mode 100644 libavutil/avr32/intreadwrite.h
diff --git a/libavutil/avr32/bswap.h b/libavutil/avr32/bswap.h
deleted file mode 100644
index e79d53f369..00
--- a/libavutil/avr32/bswap.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#ifndef AVUTIL_AVR32_BSWAP_H
-#define AVUTIL_AVR32_BSWAP_H
-
-#include
-#include "config.h"
-#include "libavutil/attributes.h"
-
-#if HAVE_INLINE_ASM
-
-#define av_bswap16 av_bswap16
-static av_always_inline av_const uint16_t av_bswap16(uint16_t x)
-{
-__asm__ ("swap.bh %0" : "+r"(x));
-return x;
-}
-
-#define av_bswap32 av_bswap32
-static av_always_inline av_const uint32_t av_bswap32(uint32_t x)
-{
-__asm__ ("swap.b %0" : "+r"(x));
-return x;
-}
-
-#endif /* HAVE_INLINE_ASM */
-
-#endif /* AVUTIL_AVR32_BSWAP_H */
diff --git a/libavutil/avr32/intreadwrite.h b/libavutil/avr32/intreadwrite.h
deleted file mode 100644
index 95179f1d11..00
--- a/libavutil/avr32/intreadwrite.h
+++ /dev/null
@@ -1,182 +0,0 @@
-/*
- * Copyright (c) 2009 Mans Rullgard
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#ifndef AVUTIL_AVR32_INTREADWRITE_H
-#define AVUTIL_AVR32_INTREADWRITE_H
-
-#include
-#include "config.h"
-#include "libavutil/bswap.h"
-
-/*
- * AVR32 does not support unaligned memory accesses, except for the AP
- * series which supports unaligned 32-bit loads and stores. 16-bit
- * and 64-bit accesses must be aligned to 16 and 32 bits, respectively.
- * This means we cannot use the byte-swapping load/store instructions
- * here.
- *
- * For 16-bit, 24-bit, and (on UC series) 32-bit loads, we instead use
- * the LDINS.B instruction, which gcc fails to utilise with the
- * generic code. GCC also fails to use plain LD.W and ST.W even for
- * AP processors, so we override the generic code. The 64-bit
- * versions are improved by using our optimised 32-bit functions.
- */
-
-#define AV_RL16 AV_RL16
-static av_always_inline uint16_t AV_RL16(const void *p)
-{
-uint16_t v;
-__asm__ ("ld.ub%0, %1 \n\t"
- "ldins.b %0:l, %2 \n\t"
- : "="(v)
- : "m"(*(const uint8_t*)p), "RKs12"(*((const uint8_t*)p+1)));
-return v;
-}
-
-#define AV_RB16 AV_RB16
-static av_always_inline uint16_t AV_RB16(const void *p)
-{
-uint16_t v;
-__asm__ ("ld.ub%0, %2 \n\t"
- "ldins.b %0:l, %1 \n\t"
- : "="(v)
- : "RKs12"(*(const uint8_t*)p), "m"(*((const uint8_t*)p+1)));
-return v;
-}
-
-#define AV_RB24 AV_RB24
-static av_always_inline uint32_t AV_RB24(const void *p)
-{
-uint32_t v;
-__asm__ ("ld.ub%0, %3 \n\t"
- "ldins.b %0:l, %2 \n\t"
- "ldins.b %0:u, %1 \n\t"
- : "="(v)
- : "RKs12"(* (const uint8_t*)p),
- "RKs12"(*((const uint8_t*)p+1)),
- "m"(*((const uint8_t*)p+2)));
-return v;
-}
-
-#define AV_RL24 AV_RL24
-static av_always_inline uint32_t AV_RL24(const void *p)
-{
-uint32_t v;
-__asm__ ("ld.ub%0, %1 \n\t"
- "ldins.b %0:l, %2 \n\t"
- "ldins.b %0:u, %3 \n\t"
- : "="(v)
- : "m"(* (const uint8_t*)p),
- "RKs12"(*((const uint8_t*)p+1)),
- "RKs12"(*((const uint8_t*)p+2)));
-return v;
-}
-
-#if
Re: [FFmpeg-devel] [PATCH] libavcodec/libxvid: code cleanup (replace magic numbers)
On Thu, May 30, 2024 at 5:20 PM Ramiro Polla wrote:
>
> ---
> libavcodec/libxvid.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
> index b9ac39429d..a490f16b3f 100644
> --- a/libavcodec/libxvid.c
> +++ b/libavcodec/libxvid.c
> @@ -422,13 +422,13 @@ static av_cold int xvid_encode_init(AVCodecContext
> *avctx)
>
> /* Decide how we should decide blocks */
> switch (avctx->mb_decision) {
> -case 2:
> +case FF_MB_DECISION_RD:
> x->vop_flags |= XVID_VOP_MODEDECISION_RD;
> x->me_flags |= XVID_ME_HALFPELREFINE8_RD|
> XVID_ME_QUARTERPELREFINE8_RD |
> XVID_ME_EXTSEARCH_RD |
> XVID_ME_CHECKPREDICTION_RD;
> -case 1:
> +case FF_MB_DECISION_BITS:
> if (!(x->vop_flags & XVID_VOP_MODEDECISION_RD))
> x->vop_flags |= XVID_VOP_FAST_MODEDECISION_RD;
> x->me_flags |= XVID_ME_HALFPELREFINE16_RD |
> --
> 2.30.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".
This gets a +1 from me.
-- Sean McGover
___
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] [RFC] libavcodec: remove DSP acceleration code for DEC Alpha
---
Changelog| 1 +
libavcodec/alpha/Makefile| 10 -
libavcodec/alpha/asm.h | 153 --
libavcodec/alpha/blockdsp_alpha.c| 49 -
libavcodec/alpha/hpeldsp_alpha.c | 213 ---
libavcodec/alpha/hpeldsp_alpha.h | 28 ---
libavcodec/alpha/hpeldsp_alpha_asm.S | 125 ---
libavcodec/alpha/idctdsp_alpha.c | 127 ---
libavcodec/alpha/idctdsp_alpha.h | 34 ---
libavcodec/alpha/idctdsp_alpha_asm.S | 167 ---
libavcodec/alpha/me_cmp_alpha.c | 279
libavcodec/alpha/me_cmp_mvi_asm.S| 179
libavcodec/alpha/mpegvideo_alpha.c | 110 --
libavcodec/alpha/pixblockdsp_alpha.c | 79 ---
libavcodec/alpha/regdef.h| 77 ---
libavcodec/alpha/simple_idct_alpha.c | 303 ---
16 files changed, 1 insertion(+), 1933 deletions(-)
delete mode 100644 libavcodec/alpha/Makefile
delete mode 100644 libavcodec/alpha/asm.h
delete mode 100644 libavcodec/alpha/blockdsp_alpha.c
delete mode 100644 libavcodec/alpha/hpeldsp_alpha.c
delete mode 100644 libavcodec/alpha/hpeldsp_alpha.h
delete mode 100644 libavcodec/alpha/hpeldsp_alpha_asm.S
delete mode 100644 libavcodec/alpha/idctdsp_alpha.c
delete mode 100644 libavcodec/alpha/idctdsp_alpha.h
delete mode 100644 libavcodec/alpha/idctdsp_alpha_asm.S
delete mode 100644 libavcodec/alpha/me_cmp_alpha.c
delete mode 100644 libavcodec/alpha/me_cmp_mvi_asm.S
delete mode 100644 libavcodec/alpha/mpegvideo_alpha.c
delete mode 100644 libavcodec/alpha/pixblockdsp_alpha.c
delete mode 100644 libavcodec/alpha/regdef.h
delete mode 100644 libavcodec/alpha/simple_idct_alpha.c
diff --git a/Changelog b/Changelog
index 12770e4296..a1a40399f8 100644
--- a/Changelog
+++ b/Changelog
@@ -11,6 +11,7 @@ version :
- vf_scale2ref deprecated
- qsv_params option added for QSV encoders
- VVC decoder compatible with DVB test content
+- removed libavcodec DSP code for the DEC Alpha
version 7.0:
diff --git a/libavcodec/alpha/Makefile b/libavcodec/alpha/Makefile
deleted file mode 100644
index 796d9762b3..00
--- a/libavcodec/alpha/Makefile
+++ /dev/null
@@ -1,10 +0,0 @@
-OBJS-$(CONFIG_BLOCKDSP) += alpha/blockdsp_alpha.o
-OBJS-$(CONFIG_ME_CMP) += alpha/me_cmp_alpha.o \
- alpha/me_cmp_mvi_asm.o
-OBJS-$(CONFIG_HPELDSP) += alpha/hpeldsp_alpha.o\
- alpha/hpeldsp_alpha_asm.o
-OBJS-$(CONFIG_IDCTDSP) += alpha/idctdsp_alpha.o\
- alpha/idctdsp_alpha_asm.o\
- alpha/simple_idct_alpha.o
-OBJS-$(CONFIG_MPEGVIDEO)+= alpha/mpegvideo_alpha.o
-OBJS-$(CONFIG_PIXBLOCKDSP) += alpha/pixblockdsp_alpha.o
diff --git a/libavcodec/alpha/asm.h b/libavcodec/alpha/asm.h
deleted file mode 100644
index 6d850cecc6..00
--- a/libavcodec/alpha/asm.h
+++ /dev/null
@@ -1,153 +0,0 @@
-/*
- * Alpha optimized DSP utils
- * Copyright (c) 2002 Falk Hueffner
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#ifndef AVCODEC_ALPHA_ASM_H
-#define AVCODEC_ALPHA_ASM_H
-
-#include
-
-#include "libavutil/common.h"
-
-#if AV_GCC_VERSION_AT_LEAST(2,96)
-# define likely(x) __builtin_expect((x) != 0, 1)
-# define unlikely(x)__builtin_expect((x) != 0, 0)
-#else
-# define likely(x) (x)
-# define unlikely(x)(x)
-#endif
-
-#define AMASK_BWX (1 << 0)
-#define AMASK_FIX (1 << 1)
-#define AMASK_CIX (1 << 2)
-#define AMASK_MVI (1 << 8)
-
-static inline uint64_t BYTE_VEC(uint64_t x)
-{
-x |= x << 8;
-x |= x << 16;
-x |= x << 32;
-return x;
-}
-static inline uint64_t WORD_VEC(uint64_t x)
-{
-x |= x << 16;
-x |= x << 32;
-return x;
-}
-
-#define sextw(x) ((int16_t) (x))
-
-#ifdef __GNUC__
-#define ldq(p) \
-(((const union {\
-uint64_t __l; \
-__typeof__(*(p)) __s[sizeof (uint64_t) / sizeof *(p)]; \
-} *) (p))->__l)
[FFmpeg-devel] [PATCH 1/2] libavcodec: various: remove empty directories originally for legacy DSP code
--- libavcodec/bfin/README | 6 -- libavcodec/sh4/README | 6 -- libavcodec/sparc/README | 6 -- 3 files changed, 18 deletions(-) delete mode 100644 libavcodec/bfin/README delete mode 100644 libavcodec/sh4/README delete mode 100644 libavcodec/sparc/README diff --git a/libavcodec/bfin/README b/libavcodec/bfin/README deleted file mode 100644 index afb3461b72..00 --- a/libavcodec/bfin/README +++ /dev/null @@ -1,6 +0,0 @@ -BFIN optimizations have been removed in -commit 880e2aa23645ed9871c66ee1cbd00f93c72d2d73 -The last revission with the optimizations is fa4e17c14035ebf43130fb369e1728cdd98d0b72 - -If you want to maintain these (or other) BFIN optimizations in ffmpeg, then please -contact ffmpeg-devel@ffmpeg.org diff --git a/libavcodec/sh4/README b/libavcodec/sh4/README deleted file mode 100644 index 8dd61fe875..00 --- a/libavcodec/sh4/README +++ /dev/null @@ -1,6 +0,0 @@ -SH4 optimizations have been removed in -commit d6096a67422534918405abb46dafbbac4608cbc3 -The last revission with the optimizations is cbfc9046e1c7e295b74f252902ae6f255eef4e78 - -If you want to maintain these (or other) SH4 optimizations in ffmpeg, then please -contact ffmpeg-devel@ffmpeg.org diff --git a/libavcodec/sparc/README b/libavcodec/sparc/README deleted file mode 100644 index f9f2349cd4..00 --- a/libavcodec/sparc/README +++ /dev/null @@ -1,6 +0,0 @@ -SPARC optimizations have been removed in -commit b4dd424d96f09f9bafb88e47f37df65dc4529143 -The last revission with the optimizations is fb1b70c1ed50951c5fc1a309c3c446b2eaaf564b - -If you want to maintain these (or other) SPARC optimizations in ffmpeg, then please -contact ffmpeg-devel@ffmpeg.org -- 2.39.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Empty arch/ directories
Hi, It is not likely we will get anyone to step up to do DSP work for arguably dead architectures like SPARC, Blackfin, etc. Maybe is it time to remove those directories that just contain a README now? Sean McGovern ___ 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 v11 07/14] avcodec/vaapi_encode: extract the init and close function to base layer
Hi,
On Sat, May 25, 2024, 09:07 Lynne via ffmpeg-devel
wrote:
> On 25/05/2024 12:30, tong1.wu-at-intel@ffmpeg.org wrote:
> > From: Tong Wu
> >
> > Related parameters such as device context, frame context are also moved
> > to base layer.
> >
> > Signed-off-by: Tong Wu
> > ---
> > libavcodec/hw_base_encode.c | 49 ++
> > libavcodec/hw_base_encode.h | 17 +++
> > libavcodec/vaapi_encode.c | 90 +++--
> > libavcodec/vaapi_encode.h | 10
> > libavcodec/vaapi_encode_av1.c | 2 +-
> > libavcodec/vaapi_encode_h264.c | 2 +-
> > libavcodec/vaapi_encode_h265.c | 2 +-
> > libavcodec/vaapi_encode_mjpeg.c | 6 ++-
> > 8 files changed, 102 insertions(+), 76 deletions(-)
> >
> > diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
> > index 16afaa37be..c4789380b6 100644
> > --- a/libavcodec/hw_base_encode.c
> > +++ b/libavcodec/hw_base_encode.c
> > @@ -592,3 +592,52 @@ end:
> >
> > return 0;
> > }
> > +
> > +int ff_hw_base_encode_init(AVCodecContext *avctx)
> > +{
> > +FFHWBaseEncodeContext *ctx = avctx->priv_data;
>
> This is the issue I was talking about, this requires that
> FFHWBaseEncodeContext is always the main context.
>
> Could you change it so everything takes FFHWBaseEncodeContext as an
> argument, rather than AVCodecContext (apart from where the function
> absolutely must read some data from it)?
>
Might this suggestion involve having to do some ugly down-casting?
-- Sean McGovern
>
___
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] avutil/ppc/cpu: Also use the machdep.altivec sysctl on NetBSD
Hi Brad,
On Sun, May 5, 2024 at 11:22 PM Brad Smith
wrote:
>
> avutil/ppc/cpu: Also use the machdep.altivec sysctl on NetBSD
>
> Use the machdep.altivec sysctl on NetBSD for AltiVec detection
> as is done with OpenBSD.
>
> Signed-off-by: Brad Smith
> ---
> libavutil/ppc/cpu.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
> index bc8bb5f47c..2b13cda662 100644
> --- a/libavutil/ppc/cpu.c
> +++ b/libavutil/ppc/cpu.c
> @@ -27,7 +27,7 @@
> #if HAVE_UNISTD_H
> #include
> #endif
> -#elif defined(__OpenBSD__)
> +#elif defined(__NetBSD__) || defined(__OpenBSD__)
> #include
> #include
> #include
> @@ -56,8 +56,8 @@ int ff_get_cpu_flags_ppc(void)
> if (result == VECTORTYPE_ALTIVEC)
> return AV_CPU_FLAG_ALTIVEC;
> return 0;
> -#elif defined(__APPLE__) || defined(__OpenBSD__)
> -#ifdef __OpenBSD__
> +#elif defined(__APPLE__) || defined(__NetBSD__) || defined(__OpenBSD__)
> +#if defined(__NetBSD__) || defined(__OpenBSD__)
> int sels[2] = {CTL_MACHDEP, CPU_ALTIVEC};
> #else
> int sels[2] = {CTL_HW, HW_VECTORUNIT};
> --
> 2.44.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".
OK, looks good to me.
-- Sean McGovern
___
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] [REFUND-REQUEST] Vulkan F2F travel
Hi, On Mon, Apr 29, 2024 at 12:58 PM Michael Niedermayer wrote: > > Hi > > On Sat, Apr 27, 2024 at 02:16:36PM +0200, Lynne wrote: > > Hi, > > > > I'm requesting a reimbursement for attending the Khronos F2F > > event in Brussels on 2024-04-26, where I gave a talk about the > > current status of Vulkan Video integration into FFmpeg: > > - Currently implemented decoding features > > - What we would like to be improved (stability, speed and testing from all > > vendors) > > - Currently implemented WIP encoding features > > - What we would need to implement in order to match nvenc in terms of > > quality on most vendors > > > > Also, I collaborated on future extensions to the standard, > > and discussed AV1 issues recently found in the specifications > > and how we could fix them. > > > > 95 GBP: Eurostar to Bruxelle-Midi > > 95 GBP: Eurostar from Bruxelle-Midi > > Total: 190 GBP > > LGTM > > PS: maybe we should make a page on trac that links to all talks from all > FFmpeg developers > Is there video/audio from this talk? I would like to watch/listen if so. -- Sean McGovern ___ 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] configure: support msvc build inside WSL
On Sat, Apr 27, 2024, 16:15 Timo Rothenpieler wrote:
> ---
> configure | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 8101b4fce6..89af5f75e7 100755
> --- a/configure
> +++ b/configure
> @@ -5036,7 +5036,12 @@ probe_cc(){
> else
> _ident=$($_cc --version 2>/dev/null | head -n1 | tr -d '\r')
> fi
> -_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 |
> awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if
> (!match($$0, / /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
> +if [ -x "$(command -v wslpath)" ]; then
> +_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1
> | awk '\''/including/ { sub(/^.*file: */, ""); if (!match($$0, / /)) {
> print $$0 } }'\'' | xargs -d\\n -n1 wslpath -u | awk '\''BEGIN { printf
> "%s:", "$@" }; { sub(/\r/,""); printf " %s", $$0 }; END { print "" }'\'' >
> $(@:.o=.d)'
> +
> +else
> +_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1
> | awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if
> (!match($$0, / /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
> +fi
> _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
> _cflags_speed="-O2"
> _cflags_size="-O1"
> --
> 2.43.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".
>
Aside: We are now that much closer to summoning a demon inside 'configure'
*laughs*.
-- Sean McGovern
>
___
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/libx264: bump minimum required version to 160
Hi, On Wed, Apr 10, 2024, 19:32 Michael Niedermayer wrote: > On Wed, Apr 10, 2024 at 03:47:48PM +0200, Niklas Haas wrote: > > On Wed, 10 Apr 2024 15:18:52 +0200 Michael Niedermayer < > mich...@niedermayer.cc> wrote: > > > On Tue, Apr 09, 2024 at 02:53:28PM +0200, Niklas Haas wrote: > > > > On Sat, 06 Apr 2024 22:28:26 +0200 Michael Niedermayer < > mich...@niedermayer.cc> wrote: > > > > > On Fri, Apr 05, 2024 at 07:44:52PM +0200, Niklas Haas wrote: > > > > > > From: Niklas Haas > > > > > > > > > > > > This version is four years old, and present in Debian oldstable, > Ubuntu > > > > > > 22.04 and Leap 15.1. > > > > > > > > > > Ubuntu 20.04 has general support till 2025-05-29 > > > > > Ubuntu 18.04 has security support (ESM) till 2028-04 > > > > > > > > I'll relax it from 160 back down to version 155 then. That covers > Ubuntu > > > > 20.04 and Debian oldoldstable. > > > > > > 18.04 has 152 > > > > > > libx264-dev/bionic,now 2:0.152.2854+gite9a5903-2 amd64 [installed] > > > > > > Ubuntu 18.04 still has security support in ESM and ubuntu pro IIUC > till 2028-04 > > > > Do you think FFmpeg 7.1 will be back-ported to Ubuntu 18.04 for security > > reasons? > > I would not expect that but i also didnt expect 7.0 would be backported > to 22.04 and 24.04 and it seems someone did unofficial backports > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Nations do behave wisely once they have exhausted all other alternatives. > -- Abba Eban > ___ > 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". > I think supporting anything earlier than 20.04 is obscene at this point. -- Sean McGovern > ___ 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/libsvt1: check return value of sned/receive functions
Hi James,
On Tue, Apr 9, 2024, 09:05 James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/libsvtav1.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> index 105c3369c0..6ff893cf10 100644
> --- a/libavcodec/libsvtav1.c
> +++ b/libavcodec/libsvtav1.c
> @@ -486,6 +486,7 @@ static int eb_send_frame(AVCodecContext *avctx, const
> AVFrame *frame)
> {
> SvtContext *svt_enc = avctx->priv_data;
> EbBufferHeaderType *headerPtr = svt_enc->in_buf;
> +EbErrorType svt_ret;
> int ret;
>
> if (!frame) {
> @@ -524,7 +525,9 @@ static int eb_send_frame(AVCodecContext *avctx, const
> AVFrame *frame)
> if (avctx->gop_size == 1)
> headerPtr->pic_type = EB_AV1_KEY_PICTURE;
>
> -svt_av1_enc_send_picture(svt_enc->svt_handle, headerPtr);
> +svt_ret = svt_av1_enc_send_picture(svt_enc->svt_handle, headerPtr);
> +if (svt_ret != EB_ErrorNone)
> +return svt_print_error(avctx, svt_ret, "Error sending a frame to
> encoder");
>
> return 0;
> }
> @@ -579,6 +582,8 @@ static int eb_receive_packet(AVCodecContext *avctx,
> AVPacket *pkt)
> svt_ret = svt_av1_enc_get_packet(svt_enc->svt_handle, ,
> svt_enc->eos_flag);
> if (svt_ret == EB_NoErrorEmptyQueue)
> return AVERROR(EAGAIN);
> +else if (svt_ret != EB_ErrorNone)
> +return svt_print_error(avctx, svt_ret, "Error getting an output
> packet from encoder");
>
> #if SVT_AV1_CHECK_VERSION(2, 0, 0)
> if (headerPtr->flags & EB_BUFFERFLAG_EOS) {
> --
> 2.44.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".
>
Commit title is mis-spelled: sned -> send.
Other than that, looks OK.
-- Sean McGovern
>
___
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] 7.0 Name
Hi, On Mon, Apr 1, 2024, 18:00 Lynne wrote: > Apr 1, 2024, 22:01 by mich...@niedermayer.cc: > > > Hi all > > > > I think we didnt decide on a name for 7.0 yet > > > > Previously suggested names: > > Darwin, > > De broglie, > > Dijkstra, > > Galois, > > Gauss, > > Jacobi, > > Jemison > > Johnson > > Leavitt > > Maxwell, > > Mellin, > > Perelman, > > Poincaré, > > Ramanujan, > > Sagan, > > Ting > > Viterbi, > > Voltaire, > > de Sitter, > > > > Please reply with what you prefer or add more to the list. > > If we end in a tie, previously suggested names will be favoured > > I will vote last so that i can resolve a tie if one occurs. > > > > Voltaire > ___ > 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". > Not sure if I am allowed to pick, my choice is Dijkstra. -- Sean McGovern > ___ 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 6/6] fate/image: Fix EXR tests on big endian
alf-12x8: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/ya_scanline_zip_half_12x8.exr -pix_fmt gbrapf32le > +fate-exr-ya-scanline-zip-half-12x8: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/ya_scanline_zip_half_12x8.exr -vf scale -pix_fmt > gbrapf32le > > FATE_EXR += fate-exr-rgb-tile-half-zip > -fate-exr-rgb-tile-half-zip: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_tile_half_zip.exr -pix_fmt gbrpf32le > +fate-exr-rgb-tile-half-zip: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_tile_half_zip.exr -vf scale -pix_fmt gbrpf32le > > FATE_EXR += fate-exr-rgb-scanline-float-zip-dw-large > -fate-exr-rgb-scanline-float-zip-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_float_zip_dw_large.exr -pix_fmt gbrpf32le > +fate-exr-rgb-scanline-float-zip-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_float_zip_dw_large.exr -vf scale -pix_fmt > gbrpf32le > > FATE_EXR += fate-exr-rgb-scanline-half-piz-dw-large > -fate-exr-rgb-scanline-half-piz-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_half_piz_dw_large.exr -pix_fmt gbrpf32le > +fate-exr-rgb-scanline-half-piz-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_half_piz_dw_large.exr -vf scale -pix_fmt > gbrpf32le > > FATE_EXR += fate-exr-rgb-scanline-half-zip-dw-large > -fate-exr-rgb-scanline-half-zip-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_half_zip_dw_large.exr -pix_fmt gbrpf32le > +fate-exr-rgb-scanline-half-zip-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_half_zip_dw_large.exr -vf scale -pix_fmt > gbrpf32le > > FATE_EXR += fate-exr-rgb-scanline-uint32-piz-dw-large > -fate-exr-rgb-scanline-uint32-piz-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_uint32_piz_dw_large.exr -pix_fmt rgb48le > +fate-exr-rgb-scanline-uint32-piz-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_uint32_piz_dw_large.exr -vf scale -pix_fmt > rgb48le > > FATE_EXR += fate-exr-rgb-tile-half-piz-dw-large > -fate-exr-rgb-tile-half-piz-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_tile_half_piz_dw_large.exr -pix_fmt gbrpf32le > +fate-exr-rgb-tile-half-piz-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_tile_half_piz_dw_large.exr -vf scale -pix_fmt > gbrpf32le > > FATE_EXR += fate-exr-rgb-tile-uint32-piz-dw-large > -fate-exr-rgb-tile-uint32-piz-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_tile_uint32_piz_dw_large.exr -pix_fmt rgb48le > +fate-exr-rgb-tile-uint32-piz-dw-large: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_tile_uint32_piz_dw_large.exr -vf scale -pix_fmt > rgb48le > > FATE_EXR += fate-exr-rgb-scanline-half-zip-dw-outside > -fate-exr-rgb-scanline-half-zip-dw-outside: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_half_zip_dw_outside.exr -pix_fmt gbrpf32le > +fate-exr-rgb-scanline-half-zip-dw-outside: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_half_zip_dw_outside.exr -vf scale -pix_fmt > gbrpf32le > > FATE_EXR += fate-exr-rgb-tile-half-zip-dw-outside > -fate-exr-rgb-tile-half-zip-dw-outside: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_tile_half_zip_dw_outside.exr -pix_fmt gbrpf32le > +fate-exr-rgb-tile-half-zip-dw-outside: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_tile_half_zip_dw_outside.exr -vf scale -pix_fmt > gbrpf32le > > FATE_EXR += fate-exr-rgb-scanline-zip-half-0x0-0x > -fate-exr-rgb-scanline-zip-half-0x0-0x: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_zip_half_float_0x0_to_0x.exr -pix_fmt > gbrpf32le > +fate-exr-rgb-scanline-zip-half-0x0-0x: CMD = framecrc -i > $(TARGET_SAMPLES)/exr/rgb_scanline_zip_half_float_0x0_to_0x.exr -vf scale > -pix_fmt gbrpf32le > > -FATE_EXR-$(call DEMDEC, IMAGE2, EXR) += $(FATE_EXR) > +FATE_EXR-$(call DEMDEC, IMAGE2, EXR, SCALE_FILTER) += $(FATE_EXR) > > FATE_IMAGE_FRAMECRC += $(FATE_EXR-yes) > fate-exr: $(FATE_EXR-yes) > -- > 2.40.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". Confirming this fixes fate-exr-* on a big-endian POWER7. Thanks, Sean McGovern. ___ 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 07/18] swscale/swscale_internal: Only include altivec header iff HAVE_ALTIVEC
Andreas: On Thu, Mar 28, 2024 at 7:11 PM Andreas Rheinhardt wrote: > > Signed-off-by: Andreas Rheinhardt > --- > libswscale/swscale_internal.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h > index abeebbb002..2f6cc70946 100644 > --- a/libswscale/swscale_internal.h > +++ b/libswscale/swscale_internal.h > @@ -34,7 +34,9 @@ > #include "libavutil/pixfmt.h" > #include "libavutil/pixdesc.h" > #include "libavutil/slicethread.h" > +#if HAVE_ALTIVEC > #include "libavutil/ppc/util_altivec.h" > +#endif > #include "libavutil/half2float.h" > > #define STR(s) AV_TOSTRING(s) // AV_STRINGIFY is too long > -- > 2.40.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". This also looks good to me. -- Sean McGovern ___ 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 06/18] postproc/postprocess: Don't generally include arch-specific headers
Andreas:
On Thu, Mar 28, 2024 at 7:11 PM Andreas Rheinhardt
wrote:
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libpostproc/postprocess.c | 3 ++-
> libpostproc/postprocess_template.c | 5 -
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c
> index 0586e458b4..8f4de8b1e1 100644
> --- a/libpostproc/postprocess.c
> +++ b/libpostproc/postprocess.c
> @@ -88,7 +88,6 @@ try to unroll inner for(x=0 ... loop to avoid these damn
> if(x ... checks
> #include "postprocess.h"
> #include "postprocess_internal.h"
> #include "libavutil/avstring.h"
> -#include "libavutil/ppc/util_altivec.h"
>
> #define GET_MODE_BUFFER_SIZE 500
> #define OPTIONS_ARRAY_SIZE 10
> @@ -499,6 +498,8 @@ static av_always_inline void do_a_deblock_C(uint8_t *src,
> int step,
> #include "postprocess_template.c"
>
> #if HAVE_ALTIVEC
> +#include "libavutil/ppc/util_altivec.h"
> +
> # define TEMPLATE_PP_ALTIVEC 1
> # include "postprocess_altivec_template.c"
> # include "postprocess_template.c"
> diff --git a/libpostproc/postprocess_template.c
> b/libpostproc/postprocess_template.c
> index ade1d6ce2b..d56b45d3b4 100644
> --- a/libpostproc/postprocess_template.c
> +++ b/libpostproc/postprocess_template.c
> @@ -22,9 +22,12 @@
> * @file
> * mmx/mmx2/sse2 postprocess code.
> */
> +#include "config.h"
>
> #include "libavutil/mem_internal.h"
> +#if ARCH_X86
> #include "libavutil/x86/asm.h"
> +#endif
>
> /* A single TEMPLATE_PP_* should be defined (to 1) when this template is
> * included. The following macros will define its dependencies to 1 as well
> @@ -830,7 +833,7 @@ static inline void RENAME(doVertDefFilter)(uint8_t src[],
> int stride, PPContext
> #if !TEMPLATE_PP_ALTIVEC
> static inline void RENAME(dering)(uint8_t src[], int stride, PPContext *c)
> {
> -#if HAVE_7REGS && TEMPLATE_PP_MMXEXT
> +#if TEMPLATE_PP_MMXEXT && HAVE_7REGS
> DECLARE_ALIGNED(8, uint64_t, tmp)[3];
> __asm__ volatile(
> "pxor %%mm6, %%mm6 \n\t"
> --
> 2.40.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
OK, looks good to me.
-- Sean McGovern
___
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/5] fate/ffmpeg: Explicitly set pix fmt for sub2video tests
Hi, On Thu, Mar 28, 2024, 23:24 Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Otherwise the test would use bgra on little endian and argb > on big endian. > > Signed-off-by: Andreas Rheinhardt > --- > tests/fate/ffmpeg.mak | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak > index 3c549b265e..fda3a29239 100644 > --- a/tests/fate/ffmpeg.mak > +++ b/tests/fate/ffmpeg.mak > @@ -64,7 +64,7 @@ fate-sub2video_basic: CMD = framecrc > -auto_conversion_filters \ >-i $(TARGET_SAMPLES)/sub/vobsub.idx \ >-fps_mode passthrough -copyts \ >-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ > - -c:v rawvideo -threads 1 > + -c:v rawvideo -pix_fmt bgra -threads 1 > > # Time-limited run with a sample that doesn't require seeking and > # contains samples within the initial period. > @@ -74,7 +74,7 @@ fate-sub2video_time_limited: CMD = framecrc > -auto_conversion_filters \ >-fps_mode passthrough -copyts \ >-t 15 \ >-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ > - -c:v rawvideo -threads 1 > + -c:v rawvideo -threads 1 -pix_fmt bgra > > FATE_FFMPEG-$(call ENCDEC, PCM_S16LE, PCM_S16LE) += > fate-unknown_layout-pcm > fate-unknown_layout-pcm: $(AREF) > -- > 2.40.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > I already submitted this change a few weeks ago (March 6th to be precise) and it has been left unreviewed. -- Sean McGovern > ___ 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] fate: fix sub2video_{basic, time_limited} on big-endian targets
Hi, On Fri, Mar 8, 2024, 10:11 Sean McGovern wrote: > On Wed, Mar 6, 2024, 18:48 Sean McGovern wrote: > >> The reference file uses BGRA pixel format, so request it here. >> --- >> tests/fate/ffmpeg.mak | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak >> index 669c878c7f..77e93693b9 100644 >> --- a/tests/fate/ffmpeg.mak >> +++ b/tests/fate/ffmpeg.mak >> @@ -62,6 +62,7 @@ fate-sub2video: CMD = framecrc -auto_conversion_filters >> \ >> FATE_SAMPLES_FFMPEG-$(call FRAMECRC, VOBSUB, DVDSUB, SCALE_FILTER) += >> fate-sub2video_basic >> fate-sub2video_basic: CMD = framecrc -auto_conversion_filters \ >>-i $(TARGET_SAMPLES)/sub/vobsub.idx \ >> + -pix_fmt bgra \ >>-fps_mode passthrough -copyts \ >>-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ >>-c:v rawvideo -threads 1 >> @@ -71,6 +72,7 @@ fate-sub2video_basic: CMD = framecrc >> -auto_conversion_filters \ >> FATE_SAMPLES_FFMPEG-$(call FRAMECRC, SUP, PGSSUB, SCALE_FILTER >> RAWVIDEO_ENCODER) += fate-sub2video_time_limited >> fate-sub2video_time_limited: CMD = framecrc -auto_conversion_filters \ >>-i $(TARGET_SAMPLES)/sub/pgs_sub.sup \ >> + -pix_fmt bgra \ >>-fps_mode passthrough -copyts \ >>-t 15 \ >>-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ >> -- >> 2.39.2 > > Ping review again, I was rather hoping this could make it into 7.0. -- Sean McGovern ___ 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/tests/snowenc: Fix mixed declaration and code
Hi,
On Fri, Mar 15, 2024, 10:24 Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/tests/snowenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/tests/snowenc.c b/libavcodec/tests/snowenc.c
> index 37198cd4e3..3dad07d3a5 100644
> --- a/libavcodec/tests/snowenc.c
> +++ b/libavcodec/tests/snowenc.c
> @@ -35,9 +35,9 @@ int main(void){
> SnowContext s;
> int i;
> AVLFG prng;
> +int ret = 0;
> s.spatial_decomposition_count=6;
> s.spatial_decomposition_type=1;
> -int ret = 0;
>
> s.temp_dwt_buffer = av_calloc(width, sizeof(*s.temp_dwt_buffer));
> s.temp_idwt_buffer = av_calloc(width, sizeof(*s.temp_idwt_buffer));
> --
> 2.40.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
OK, looks good to me.
Thanks,
Sean McGovern
>
___
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/ppc/vp8dsp_altivec: Fix out-of-bounds access
Andreas:
On Tue, Mar 12, 2024 at 9:14 PM Andreas Rheinhardt
wrote:
>
> h_subpel_filters_inner[i] and h_subpel_filters_outer[i / 2]
> belong together and the former allows the range 0..6,
> so the latter needs to support 0..3. But it has only three
> elements. Add another one.
> The value for the last element has been guesstimated
> from subpel_filters in libavcodec/vp8dsp.c.
>
> This is also intended to fix FATE-failures with UBSan here:
> https://fate.ffmpeg.org/report.cgi?time=20240312011016=ppc-linux-gcc-13.2-ubsan-altivec-qemu
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ppc/vp8dsp_altivec.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/ppc/vp8dsp_altivec.c b/libavcodec/ppc/vp8dsp_altivec.c
> index 12dac8b0a8..061914fc38 100644
> --- a/libavcodec/ppc/vp8dsp_altivec.c
> +++ b/libavcodec/ppc/vp8dsp_altivec.c
> @@ -50,11 +50,12 @@ static const vec_s8 h_subpel_filters_inner[7] =
> // for 6tap filters, these are the outer two taps
> // The zeros mask off pixels 4-7 when filtering 0-3
> // and vice-versa
> -static const vec_s8 h_subpel_filters_outer[3] =
> +static const vec_s8 h_subpel_filters_outer[4] =
> {
> REPT4(0, 0, 2, 1),
> REPT4(0, 0, 3, 3),
> REPT4(0, 0, 1, 2),
> +REPT4(0, 0, 0, 0),
> };
>
> #define LOAD_H_SUBPEL_FILTER(i) \
> --
> 2.40.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Confirming this patch fixes fate-checkasm-vp8dsp (and presumably the
other vp8 tests in GCC UBsan) on PowerPC QEMU, POWER7 (ppc64), and
POWER9 (ppc64le).
Thanks again,
Sean McGovern
___
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/mpeg4videodec: Align idct-block appropriately
Andreas:
On Tue, Mar 12, 2024 at 8:53 PM Andreas Rheinhardt
wrote:
>
> It is accessed via AV_RN64() in ff_simple_idct_put_int32_10bit().
> Should fix the UBSan failures in the mpeg4-simple-studio-profile
> test here:
> https://fate.ffmpeg.org/report.cgi?time=20240312011016=ppc-linux-gcc-13.2-ubsan-altivec-qemu
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/mpeg4videodec.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/mpeg4videodec.h b/libavcodec/mpeg4videodec.h
> index c0e6ec6592..4a26d18987 100644
> --- a/libavcodec/mpeg4videodec.h
> +++ b/libavcodec/mpeg4videodec.h
> @@ -29,6 +29,7 @@
> #include "mpegvideo.h"
> #include "mpeg4videodsp.h"
>
> +#include "libavutil/mem_internal.h"
>
> typedef struct Mpeg4DecContext {
> MpegEncContext m;
> @@ -83,7 +84,7 @@ typedef struct Mpeg4DecContext {
>
> Mpeg4VideoDSPContext mdsp;
>
> -int32_t block32[12][64];
> +DECLARE_ALIGNED(8, int32_t, block32)[12][64];
> // 0 = DCT, 1 = DPCM top to bottom scan, -1 = DPCM bottom to top scan
> int dpcm_direction;
> int16_t dpcm_macroblock[3][256];
> --
> 2.40.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Confirming that this fixes fate-mpeg4-simple-studio-profile on PowerPC
QEMU with GCC UBsan as noted.
It was not failing on POWER7 (ppc64) or POWER9 (ppc64le).
Thanks,
Sean McGovern
___
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/lossless_videoencdsp: Fix unaligned access
Andreas:
On Tue, Mar 12, 2024 at 8:42 PM Andreas Rheinhardt
wrote:
>
> HAVE_FAST_UNALIGNED being true does not imply that
> one can simply read from any pointer via *(long*).
> It is undefined behaviour in case the pointer is not
> sufficiently aligned; and even if it is, it is (likely)
> a violation of the effective-type rules. Fix both
> of these by using the appropriate AV_[RW]N macros.
>
> Also, the current code used sizeof(long) as if this
> were the CPU's native arithmetic size, but this is
> not true on 64bit Windows. This has been fixed, too.
>
> This affected huffyuv FATE-tests.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/lossless_videoencdsp.c | 27 +++
> 1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/lossless_videoencdsp.c
> b/libavcodec/lossless_videoencdsp.c
> index e2dc99e201..8d03a5b5c6 100644
> --- a/libavcodec/lossless_videoencdsp.c
> +++ b/libavcodec/lossless_videoencdsp.c
> @@ -18,19 +18,31 @@
>
> #include "config.h"
> #include "libavutil/attributes.h"
> +#include "libavutil/intreadwrite.h"
> #include "lossless_videoencdsp.h"
> #include "mathops.h"
>
> +#if HAVE_FAST_64BIT
> +typedef uint64_t uint_native;
> +#define READ AV_RN64
> +#define READA AV_RN64A
> +#define WRITEA AV_WN64A
> +#else
> +typedef uint32_t uint_native;
> +#define READ AV_RN32
> +#define READA AV_RN32A
> +#define WRITEA AV_WN32A
> +#endif
> // 0x7f7f7f7f or 0x7f7f7f7f7f7f7f7f or whatever, depending on the cpu's
> native arithmetic size
> -#define pb_7f (~0UL / 255 * 0x7f)
> -#define pb_80 (~0UL / 255 * 0x80)
> +#define pb_7f (~(uint_native)0 / 255 * 0x7f)
> +#define pb_80 (~(uint_native)0 / 255 * 0x80)
>
> static void diff_bytes_c(uint8_t *dst, const uint8_t *src1, const uint8_t
> *src2, intptr_t w)
> {
> long i;
>
> #if !HAVE_FAST_UNALIGNED
> -if (((long)src1 | (long)src2) & (sizeof(long) - 1)) {
> +if (((uintptr_t)src1 | (uintptr_t)src2) & (sizeof(uint_native) - 1)) {
> for (i = 0; i + 7 < w; i += 8) {
> dst[i + 0] = src1[i + 0] - src2[i + 0];
> dst[i + 1] = src1[i + 1] - src2[i + 1];
> @@ -43,11 +55,10 @@ static void diff_bytes_c(uint8_t *dst, const uint8_t
> *src1, const uint8_t *src2,
> }
> } else
> #endif
> -for (i = 0; i <= w - (int) sizeof(long); i += sizeof(long)) {
> -long a = *(long *) (src1 + i);
> -long b = *(long *) (src2 + i);
> -*(long *) (dst + i) = ((a | pb_80) - (b & pb_7f)) ^
> - ((a ^ b ^ pb_80) & pb_80);
> +for (i = 0; i <= w - (int) sizeof(uint_native); i +=
> sizeof(uint_native)) {
> +uint_native a = READA(src1 + i);
> +uint_native b = READ(src2 + i);
> +WRITEA(dst + i, ((a | pb_80) - (b & pb_7f)) ^ ((a ^ b ^ pb_80) &
> pb_80));
> }
> for (; i < w; i++)
> dst[i + 0] = src1[i + 0] - src2[i + 0];
> --
> 2.40.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Confirming that this fixes 'fate-vsynth[123]-ffvhuff' and probably others on my
PowerPC QEMU setup (provided the avidec fix is applied as well),
POWER7 (ppc64) and POWER9 (ppc64le).
Thanks,
Sean McGovern
___
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/avidec: Fix integer overflow iff ULONG_MAX < INT64_MAX
Andreas:
On Tue, Mar 12, 2024 at 6:57 PM Andreas Rheinhardt
wrote:
>
> Affects many FATE-tests, see
> http://fate.ffmpeg.org/report.cgi?time=20240312011016=ppc-linux-gcc-13.2-ubsan-altivec-qemu
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/avidec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/avidec.c b/libavformat/avidec.c
> index f3183b2698..b7cbf148af 100644
> --- a/libavformat/avidec.c
> +++ b/libavformat/avidec.c
> @@ -1696,7 +1696,7 @@ static int check_stream_max_drift(AVFormatContext *s)
> int *idx = av_calloc(s->nb_streams, sizeof(*idx));
> if (!idx)
> return AVERROR(ENOMEM);
> -for (min_pos = pos = 0; min_pos != INT64_MAX; pos = min_pos + 1LU) {
> +for (min_pos = pos = 0; min_pos != INT64_MAX; pos = min_pos +
> (uint64_t)1) {
> int64_t max_dts = INT64_MIN / 2;
> int64_t min_dts = INT64_MAX / 2;
> int64_t max_buffer = 0;
> --
> 2.40.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Confirming that this fixes fate-v210 (and probably many more) on my
PowerPC QEMU setup -- it was not failing on POWER7 (ppc64) or POWER9
(ppc64le) and remains so with the patch applied.
Thanks,
Sean McGovern
___
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/ppc/h264dsp: Fix unaligned stores
Andreas:
On Wed, Mar 13, 2024 at 7:31 AM Andreas Rheinhardt
wrote:
>
> Also fix an effective-type violation.
> Exposed by
> https://fate.ffmpeg.org/report.cgi?time=20240312011016=ppc-linux-gcc-13.2-ubsan-altivec-qemu
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ppc/h264dsp.c | 35 +--
> 1 file changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/libavcodec/ppc/h264dsp.c b/libavcodec/ppc/h264dsp.c
> index c02733dda2..f50f2553a2 100644
> --- a/libavcodec/ppc/h264dsp.c
> +++ b/libavcodec/ppc/h264dsp.c
> @@ -401,30 +401,29 @@ static inline void write16x4(uint8_t *dst, int
> dst_stride,
> register vec_u8 r0, register vec_u8 r1,
> register vec_u8 r2, register vec_u8 r3) {
> DECLARE_ALIGNED(16, unsigned char, result)[64];
> -uint32_t *src_int = (uint32_t *)result, *dst_int = (uint32_t *)dst;
> -int int_dst_stride = dst_stride/4;
> +uint32_t *src_int = (uint32_t *)result;
>
> vec_st(r0, 0, result);
> vec_st(r1, 16, result);
> vec_st(r2, 32, result);
> vec_st(r3, 48, result);
> /* FIXME: there has to be a better way */
> -*dst_int = *src_int;
> -*(dst_int+ int_dst_stride) = *(src_int + 1);
> -*(dst_int+ 2*int_dst_stride) = *(src_int + 2);
> -*(dst_int+ 3*int_dst_stride) = *(src_int + 3);
> -*(dst_int+ 4*int_dst_stride) = *(src_int + 4);
> -*(dst_int+ 5*int_dst_stride) = *(src_int + 5);
> -*(dst_int+ 6*int_dst_stride) = *(src_int + 6);
> -*(dst_int+ 7*int_dst_stride) = *(src_int + 7);
> -*(dst_int+ 8*int_dst_stride) = *(src_int + 8);
> -*(dst_int+ 9*int_dst_stride) = *(src_int + 9);
> -*(dst_int+10*int_dst_stride) = *(src_int + 10);
> -*(dst_int+11*int_dst_stride) = *(src_int + 11);
> -*(dst_int+12*int_dst_stride) = *(src_int + 12);
> -*(dst_int+13*int_dst_stride) = *(src_int + 13);
> -*(dst_int+14*int_dst_stride) = *(src_int + 14);
> -*(dst_int+15*int_dst_stride) = *(src_int + 15);
> +AV_WN32(dst, AV_RN32A(src_int + 0));
> +AV_WN32(dst + dst_stride, AV_RN32A(src_int + 1));
> +AV_WN32(dst + 2 * dst_stride, AV_RN32A(src_int + 2));
> +AV_WN32(dst + 3 * dst_stride, AV_RN32A(src_int + 3));
> +AV_WN32(dst + 4 * dst_stride, AV_RN32A(src_int + 4));
> +AV_WN32(dst + 5 * dst_stride, AV_RN32A(src_int + 5));
> +AV_WN32(dst + 6 * dst_stride, AV_RN32A(src_int + 6));
> +AV_WN32(dst + 7 * dst_stride, AV_RN32A(src_int + 7));
> +AV_WN32(dst + 8 * dst_stride, AV_RN32A(src_int + 8));
> +AV_WN32(dst + 9 * dst_stride, AV_RN32A(src_int + 9));
> +AV_WN32(dst + 10 * dst_stride, AV_RN32A(src_int + 10));
> +AV_WN32(dst + 11 * dst_stride, AV_RN32A(src_int + 11));
> +AV_WN32(dst + 12 * dst_stride, AV_RN32A(src_int + 12));
> +AV_WN32(dst + 13 * dst_stride, AV_RN32A(src_int + 13));
> +AV_WN32(dst + 14 * dst_stride, AV_RN32A(src_int + 14));
> +AV_WN32(dst + 15 * dst_stride, AV_RN32A(src_int + 15));
> }
>
> /** @brief performs a 6x16 transpose of data in src, and stores it to dst
> --
> 2.40.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
First of all, thank you for looking into this.
Second, do we feel that this change covers the FIXME immediately above
it that exclaims "there has to be a better way"?
If so, we can remove the comment.
I did not perform a full FATE run as it is expensive on my QEMU setup,
but I can confirm that this fixes the checkasm-h264dsp test under GCC
UBsan there as well as on a POWER7 (ppc64) and a POWER9 (ppc64le).
Thanks,
Sean McGovern
___
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] makefile: Clean up missed object files with "make clean"
Hi, On Fri, Mar 8, 2024 at 3:38 AM Martin Storsjö wrote: > > In some builds, the following object files could be left behind > after make clean: > > ./libavfilter/metal/utils.o > ./libavfilter/metal/vf_yadif_videotoolbox.metallib.o > ./libavcodec/x86/h26x/h2656dsp.o > ./libavcodec/neon/mpegvideo.o > ./ffbuild/bin2c_host.o > --- > ffbuild/common.mak | 2 +- > libavcodec/neon/Makefile| 3 +++ > libavcodec/x86/vvc/Makefile | 2 +- > libavfilter/Makefile| 1 + > 4 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/ffbuild/common.mak b/ffbuild/common.mak > index ac54ac0681..87a3ffd2b0 100644 > --- a/ffbuild/common.mak > +++ b/ffbuild/common.mak > @@ -140,7 +140,7 @@ else > endif > > clean:: > - $(RM) $(BIN2CEXE) > + $(RM) $(BIN2CEXE) $(CLEANSUFFIXES:%=ffbuild/%) > > %.c %.h %.pc %.ver %.version: TAG = GEN > > diff --git a/libavcodec/neon/Makefile b/libavcodec/neon/Makefile > index 607f116a77..83c2f0051c 100644 > --- a/libavcodec/neon/Makefile > +++ b/libavcodec/neon/Makefile > @@ -1 +1,4 @@ > +clean:: > + $(RM) $(CLEANSUFFIXES:%=libavcodec/neon/%) > + > OBJS-$(CONFIG_MPEGVIDEO) += neon/mpegvideo.o > diff --git a/libavcodec/x86/vvc/Makefile b/libavcodec/x86/vvc/Makefile > index 82f281d1c7..d1623bd46a 100644 > --- a/libavcodec/x86/vvc/Makefile > +++ b/libavcodec/x86/vvc/Makefile > @@ -1,5 +1,5 @@ > clean:: > - $(RM) $(CLEANSUFFIXES:%=libavcodec/x86/vvc/%) > + $(RM) $(CLEANSUFFIXES:%=libavcodec/x86/vvc/%) > $(CLEANSUFFIXES:%=libavcodec/x86/h26x/%) > > OBJS-$(CONFIG_VVC_DECODER) += x86/vvc/vvcdsp_init.o \ >x86/h26x/h2656dsp.o > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index f6c1d641d6..994d9773ba 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -666,6 +666,7 @@ TOOLS-$(CONFIG_LIBZMQ) += zmqsend > > clean:: > $(RM) $(CLEANSUFFIXES:%=libavfilter/dnn/%) > $(CLEANSUFFIXES:%=libavfilter/opencl/%) \ > + $(CLEANSUFFIXES:%=libavfilter/metal/%) \ >$(CLEANSUFFIXES:%=libavfilter/vulkan/%) > > OPENCL = $(subst $(SRC_PATH)/,,$(wildcard > $(SRC_PATH)/libavfilter/opencl/*.cl)) > -- This also looks good to me, and closes Trac #10895. Thanks, Sean McGovern ___ 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] libavcodec: Don't include libavcodec/x86/vvc/Makefile on any architecture
Hi Martin,
On Fri, Mar 8, 2024 at 3:38 AM Martin Storsjö wrote:
>
> This currently builds files in the libavcodec/x86/{vvc,h26x}
> subdirectories, which is somewhat unexpected when building for
> another architecture than x86.
>
> The regular arch subdirectories are handled with
>
> -include $(SRC_PATH)/$(1)/$(ARCH)/Makefile
>
> in the toplevel Makefile. Switch this to a similar optional
> inclusion, using $(ARCH).
> ---
> libavcodec/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 5d99120aa9..708434ac76 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -64,7 +64,7 @@ OBJS = ac3_parser.o
> \
>
> # subsystems
> include $(SRC_PATH)/libavcodec/vvc/Makefile
> -include $(SRC_PATH)/libavcodec/x86/vvc/Makefile
> +-include $(SRC_PATH)/libavcodec/$(ARCH)/vvc/Makefile
> OBJS-$(CONFIG_AANDCTTABLES)+= aandcttab.o
> OBJS-$(CONFIG_AC3DSP) += ac3dsp.o ac3.o ac3tab.o
> OBJS-$(CONFIG_ADTS_HEADER) += adts_header.o
> mpeg4audio_sample_rates.o
> --
This patch looks good to me.
Thanks,
Sean McGovern
___
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] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024, 10:37 Vittorio Giovara wrote: > On Fri, Mar 8, 2024 at 4:34 PM Sean McGovern wrote: > > > On Fri, Mar 8, 2024, 10:31 Paul B Mahol wrote: > > > > > On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara < > > > vittorio.giov...@gmail.com> > > > wrote: > > > > > > > On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern > > wrote: > > > > > > > > > On Fri, Mar 8, 2024, 08:20 Nicolas George wrote: > > > > > > > > > > > Andreas Rheinhardt (12024-03-08): > > > > > > > What maintenance cost and complexity are you referring to? I > > > checked > > > > > and > > > > > > > could not find a single commit where one had to fix an > > > > ff_get_buffer() > > > > > > > to ff_thread_get_buffer() because it has been forgotten when > the > > > > > decoder > > > > > > > has been declared to support frame threading. > > > > > > > > > > > > Welcome to the new FFmpeg, where absolute consistency, i.e. > > catering > > > > for > > > > > > hypothetical mediocre contributors, is more important than easy > > > > > > optimizations and new approaches. > > > > > > > > > > > > And if you do not like it, “shut up, I'm on the TC and I won't > > > recuse”. > > > > > > > > > > > > And if you do not like that, “shut up, I'm on the CC too”. > > > > > > > > > > > > Regards, > > > > > > > > > > > > -- > > > > > > Nicolas George > > > > > > ___ > > > > > > 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". > > > > > > > > > > > > > > > > Everybody can we *please* keep the responses civil/professional on > > the > > > > ML. > > > > > > > > > > > > > I'd just be happy with "on-topic" but it seems like people with > agendas > > > > like to project on unrelated threads. > > > > > > > > > > LibAV actions speak more than words once again. > > > > > > > > > > -- > > > > Vittorio > > > > ___ > > > > 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". > > > > > > > It is really mean-spirited to make such comments about a project that is > no > > longer in operation. Can't we look forward instead of behind us? > > > > Could you guys look forward in a separate thread? > -- > Vittorio > ___ > 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". > I see what you did there (ref: $subj)! :) -- Sean McGovern ___ 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] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024, 10:31 Paul B Mahol wrote: > On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara < > vittorio.giov...@gmail.com> > wrote: > > > On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern wrote: > > > > > On Fri, Mar 8, 2024, 08:20 Nicolas George wrote: > > > > > > > Andreas Rheinhardt (12024-03-08): > > > > > What maintenance cost and complexity are you referring to? I > checked > > > and > > > > > could not find a single commit where one had to fix an > > ff_get_buffer() > > > > > to ff_thread_get_buffer() because it has been forgotten when the > > > decoder > > > > > has been declared to support frame threading. > > > > > > > > Welcome to the new FFmpeg, where absolute consistency, i.e. catering > > for > > > > hypothetical mediocre contributors, is more important than easy > > > > optimizations and new approaches. > > > > > > > > And if you do not like it, “shut up, I'm on the TC and I won't > recuse”. > > > > > > > > And if you do not like that, “shut up, I'm on the CC too”. > > > > > > > > Regards, > > > > > > > > -- > > > > Nicolas George > > > > ___ > > > > 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". > > > > > > > > > > Everybody can we *please* keep the responses civil/professional on the > > ML. > > > > > > > I'd just be happy with "on-topic" but it seems like people with agendas > > like to project on unrelated threads. > > > > LibAV actions speak more than words once again. > > > > -- > > Vittorio > > ___ > > 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". > It is really mean-spirited to make such comments about a project that is no longer in operation. Can't we look forward instead of behind us? -- Sean McGovern ___ 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] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024, 10:19 Nicolas George wrote: > Sean McGovern (12024-03-08): > > Everybody can we *please* keep the responses civil/professional on the > ML. > > Civil, certainly, provided others are civil to me. > > Professional, not a chance. This is Libre Software, not a job. > > -- > Nicolas George > ___ > 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". > OK, sorry that was probably overstep, I agree and retract "professional" from that statement. -- Sean McGovern ___ 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] Did FATE have an unhappy accident?
It's been unreachable since yesterday. -- Sean McGovern ___ 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] fate: fix sub2video_{basic, time_limited} on big-endian targets
On Wed, Mar 6, 2024, 18:48 Sean McGovern wrote: > The reference file uses BGRA pixel format, so request it here. > --- > tests/fate/ffmpeg.mak | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak > index 669c878c7f..77e93693b9 100644 > --- a/tests/fate/ffmpeg.mak > +++ b/tests/fate/ffmpeg.mak > @@ -62,6 +62,7 @@ fate-sub2video: CMD = framecrc -auto_conversion_filters \ > FATE_SAMPLES_FFMPEG-$(call FRAMECRC, VOBSUB, DVDSUB, SCALE_FILTER) += > fate-sub2video_basic > fate-sub2video_basic: CMD = framecrc -auto_conversion_filters \ >-i $(TARGET_SAMPLES)/sub/vobsub.idx \ > + -pix_fmt bgra \ >-fps_mode passthrough -copyts \ >-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ >-c:v rawvideo -threads 1 > @@ -71,6 +72,7 @@ fate-sub2video_basic: CMD = framecrc > -auto_conversion_filters \ > FATE_SAMPLES_FFMPEG-$(call FRAMECRC, SUP, PGSSUB, SCALE_FILTER > RAWVIDEO_ENCODER) += fate-sub2video_time_limited > fate-sub2video_time_limited: CMD = framecrc -auto_conversion_filters \ >-i $(TARGET_SAMPLES)/sub/pgs_sub.sup \ > + -pix_fmt bgra \ >-fps_mode passthrough -copyts \ >-t 15 \ >-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ > -- > 2.39.2 > Ping review, if someone has some cycle. -- Sean McGovern ___ 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] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024, 08:20 Nicolas George wrote: > Andreas Rheinhardt (12024-03-08): > > What maintenance cost and complexity are you referring to? I checked and > > could not find a single commit where one had to fix an ff_get_buffer() > > to ff_thread_get_buffer() because it has been forgotten when the decoder > > has been declared to support frame threading. > > Welcome to the new FFmpeg, where absolute consistency, i.e. catering for > hypothetical mediocre contributors, is more important than easy > optimizations and new approaches. > > And if you do not like it, “shut up, I'm on the TC and I won't recuse”. > > And if you do not like that, “shut up, I'm on the CC too”. > > Regards, > > -- > Nicolas George > ___ > 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". > Everybody can we *please* keep the responses civil/professional on the ML. -- Sean McGovern ___ 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] fate: fix sub2video_{basic, time_limited} on big-endian targets
The reference file uses BGRA pixel format, so request it here. --- tests/fate/ffmpeg.mak | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak index 669c878c7f..77e93693b9 100644 --- a/tests/fate/ffmpeg.mak +++ b/tests/fate/ffmpeg.mak @@ -62,6 +62,7 @@ fate-sub2video: CMD = framecrc -auto_conversion_filters \ FATE_SAMPLES_FFMPEG-$(call FRAMECRC, VOBSUB, DVDSUB, SCALE_FILTER) += fate-sub2video_basic fate-sub2video_basic: CMD = framecrc -auto_conversion_filters \ -i $(TARGET_SAMPLES)/sub/vobsub.idx \ + -pix_fmt bgra \ -fps_mode passthrough -copyts \ -filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ -c:v rawvideo -threads 1 @@ -71,6 +72,7 @@ fate-sub2video_basic: CMD = framecrc -auto_conversion_filters \ FATE_SAMPLES_FFMPEG-$(call FRAMECRC, SUP, PGSSUB, SCALE_FILTER RAWVIDEO_ENCODER) += fate-sub2video_time_limited fate-sub2video_time_limited: CMD = framecrc -auto_conversion_filters \ -i $(TARGET_SAMPLES)/sub/pgs_sub.sup \ + -pix_fmt bgra \ -fps_mode passthrough -copyts \ -t 15 \ -filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ -- 2.39.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] aacenc_pred: prevent UB in ff_aac_adjust_common_pred()
Iterate over 'pmax' instead of 'num_swb'.
---
libavcodec/aacenc_pred.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/aacenc_pred.c b/libavcodec/aacenc_pred.c
index a486c44d42..c5b8aa9665 100644
--- a/libavcodec/aacenc_pred.c
+++ b/libavcodec/aacenc_pred.c
@@ -164,7 +164,7 @@ void ff_aac_adjust_common_pred(AACEncContext *s,
ChannelElement *cpe)
for (w = 0; w < sce0->ics.num_windows; w += sce0->ics.group_len[w]) {
start = 0;
-for (g = 0; g < sce0->ics.num_swb; g++) {
+for (g = 0; g < pmax; g++) {
int sfb = w*16+g;
int sum = sce0->ics.prediction_used[sfb] +
sce1->ics.prediction_used[sfb];
float ener0 = 0.0f, ener1 = 0.0f, ener01 = 0.0f;
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
On Sat, Mar 2, 2024, 18:19 Michael Niedermayer wrote: > On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote: > > On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote: > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote: > > > > Hi all > > > > > > > > As it was a little difficult for me to not loose track of what is > > > > blocking a release. I suggest that for all release blocking issues > > > > open a ticket and set Blocking to 7.0 > > > > that way this: > > > > https://trac.ffmpeg.org/query?blocking=~7.0 > > > > > > > > or for the ones not closed: > > > > > https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 > > > > > > > > will list all blocking issues > > > > > > > > Ive added one, for testing that, i intend to add more if i see > something > > > > > > > > What is blocking? (IMHO) > > > > * regressions (unless its non possible to fix before release) > > > > * crashes > > > > * security issues > > > > * data loss > > > > * privacy issues > > > > * anything the commuity agrees should be in the release > > > > > > We still have 3 blocking issues on trac > > > > > > do people want me to wait or ignore them and branch ? > > > Iam not sure when the exact deadline is but if we keep waiting > > > we will not get into ubuntu 24.04 LTS > > > > 24.04 is past feature freeze, so it's too late for that. > > we should aim earlier in the future then. > > LTS is only every 2 years, yes? How do we make sure this doesn't happen in 2026? How much of a gap is there between feature freeze and release? -- Sean McGovern ___ 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/dxvenc: Use proper alignment, write endian-independent output
Hi,
On Mon, Feb 26, 2024 at 6:48 PM Andreas Rheinhardt
wrote:
>
> Fixes the dxv3enc-dxt1 FATE test with UBSan.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> I have not actually tested whether the output is actually wrong
> on BE systems. Would be nice if someone could.
>
> libavcodec/dxvenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/dxvenc.c b/libavcodec/dxvenc.c
> index 1ce2b1d014..3f28fb696a 100644
> --- a/libavcodec/dxvenc.c
> +++ b/libavcodec/dxvenc.c
> @@ -149,7 +149,7 @@ typedef struct DXVEncContext {
> } else {
> \
> op = 0;
> \
> }
> \
> -*value |= (op << (state * 2));
> \
> +AV_WL32(value, AV_RL32(value) | (op << (state * 2)));
> \
> state++;
> \
> } while (0)
>
> @@ -157,7 +157,7 @@ static int dxv_compress_dxt1(AVCodecContext *avctx)
> {
> DXVEncContext *ctx = avctx->priv_data;
> PutByteContext *pbc = >pbc;
> -uint32_t *value;
> +void *value;
> uint32_t color, lut, idx, color_idx, lut_idx, prev_pos, state = 16, pos
> = 2, op = 0;
>
> ht_init(ctx->color_lookback_ht);
Confirming that this does fix the failing test on a big-endian PowerPC
+ Altivec virtual machine.
Thanks,
Sean McGovern
___
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/1] aacenc_pred: prevent UB in ff_aac_adjust_common_pred()
Hi Andreas,
First off all, thanks for having a look! :)
On Tue, Feb 27, 2024 at 1:37 PM Andreas Rheinhardt
wrote:
>
> Sean McGovern:
> > ---
> > libavcodec/aacenc_pred.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/aacenc_pred.c b/libavcodec/aacenc_pred.c
> > index f87fcd5a00..d3efade85e 100644
> > --- a/libavcodec/aacenc_pred.c
> > +++ b/libavcodec/aacenc_pred.c
> > @@ -162,9 +162,11 @@ void ff_aac_adjust_common_pred(AACEncContext *s,
> > ChannelElement *cpe)
> > sce1->ics.window_sequence[0] == EIGHT_SHORT_SEQUENCE)
> > return;
> >
> > +const int num_swb = FFMIN(sce0->ics.num_swb,
> > sizeof(sce0->ics.prediction_used));
> > +
> > for (w = 0; w < sce0->ics.num_windows; w += sce0->ics.group_len[w]) {
> > start = 0;
> > -for (g = 0; g < sce0->ics.num_swb; g++) {
> > +for (g = 0; g < num_swb; g++) {
> > int sfb = w*16+g;
> > int sum = sce0->ics.prediction_used[sfb] +
> > sce1->ics.prediction_used[sfb];
> > float ener0 = 0.0f, ener1 = 0.0f, ener01 = 0.0f;
>
> As you can see, the actual index used for accesses is w*16 + g and not
> only g. So I was surprised that your fix fixed the test (as you claim).
> Digging into the code, num_windows can be either 1 or eight and it is
> only eight if window_sequence[0] is EIGHT_SHORT_SEQUENCE (see lines
> 477-488 in aacpsy.c as well as lines 877-897 in aacenc.c). In case
> window_sequence[0] is EIGHT_SHORT_SEQUENCE, we do not even enter this
> loop in ff_aac_adjust_common_pred(). This means that the outer loop
> above is actually not a loop at all and your fix would indeed fix the
> undefined behaviour.
> But this also shows that this whole code is a mess. Someone who actually
> knows it should take a look. Or maybe the grim reaper.
> Anyway, your fix would lead to a wdeclaration-after-statement warning.
>
Ooof, OK thanks. I was wondering about that when I looked on Patchwork.
Thanks,
-- Sean McGovern
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/1] fate-aac-encode-pred UBsan fix
On Sun, Feb 25, 2024 at 1:44 PM Sean McGovern wrote: > > > Here is the error reported by FATE (snipped for brevity) for > 'fate-aac-encode-pred': > Ooops! I should copy-paste more often -- that should be 'fate-aac-pred-encode' :) -- Sean McGovern ___ 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/1] aacenc_pred: prevent UB in ff_aac_adjust_common_pred()
---
libavcodec/aacenc_pred.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/aacenc_pred.c b/libavcodec/aacenc_pred.c
index f87fcd5a00..d3efade85e 100644
--- a/libavcodec/aacenc_pred.c
+++ b/libavcodec/aacenc_pred.c
@@ -162,9 +162,11 @@ void ff_aac_adjust_common_pred(AACEncContext *s,
ChannelElement *cpe)
sce1->ics.window_sequence[0] == EIGHT_SHORT_SEQUENCE)
return;
+const int num_swb = FFMIN(sce0->ics.num_swb,
sizeof(sce0->ics.prediction_used));
+
for (w = 0; w < sce0->ics.num_windows; w += sce0->ics.group_len[w]) {
start = 0;
-for (g = 0; g < sce0->ics.num_swb; g++) {
+for (g = 0; g < num_swb; g++) {
int sfb = w*16+g;
int sum = sce0->ics.prediction_used[sfb] +
sce1->ics.prediction_used[sfb];
float ener0 = 0.0f, ener1 = 0.0f, ener01 = 0.0f;
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/1] fate-aac-encode-pred UBsan fix
From: Sean McGovern
Hi FFmpeg-devel,
I've started looking into the results posted by the UBsan FATE node --
http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-ubsan
Here is the error reported by FATE (snipped for brevity) for
'fate-aac-encode-pred':
[aist#0:0/pcm_s16le @ 0x77fee40] Guessed Channel Layout: stereo
Input #0, wav, from
'/srv/VIDEO/fate-suite/audio-reference/luckynight_2ch_44kHz_s16.wav':
Duration: 00:00:09.50, bitrate: 1411 kb/s
Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, stereo, s16,
1411 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (pcm_s16le (native) -> aac (native))
Output #0, adts, to
'/home/sean/build/ffmpeg-ubsan/tests/data/fate/aac-pred-encode.adts':
Stream #0:0: Audio: aac (Main), 44100 Hz, stereo, fltp, 128 kb/s
Metadata:
encoder : Lavc aac
src/libavcodec/aacenc_pred.c:169:48: runtime error: index 41 out of bounds for
type 'uint8_t [41]'
threads=8
Ignore the thread count, this fails the same when threads=1
Here is the loop it fails in -- for this test 'sfb == 49':
libavcodec/aacenc_pred.c:165:for (w = 0; w < sce0->ics.num_windows; w +=
sce0->ics.group_len[w]) {
libavcodec/aacenc_pred.c:166:start = 0;
libavcodec/aacenc_pred.c:167:for (g = 0; g < sce0->ics.num_swb; g++) {
libavcodec/aacenc_pred.c:168:int sfb = w*16+g;
libavcodec/aacenc_pred.c:169:int sum =
sce0->ics.prediction_used[sfb] + sce1->ics.prediction_used[sfb];
...
Here is the array definition for prediction_used:
libavcodec/aac.h:188: uint8_t prediction_used[41];
Here is the line num_swb is set on:
libavcodec/aacenc.c:899: ics->num_swb= tag == TYPE_LFE ?
ics->num_swb : s->psy.num_bands[ics->num_windows == 8];
(side note: interesting, I've never seen a boolean condition used an an array
index before...)
My attached patch just uses FFMIN to ensure we don't navigate past the end of
ics.prediction_used[]
It corrects the undefined behaviour, but it feels naïve.
Any thoughts?
Sean McGovern (1):
aacenc_pred: prevent UB in ff_aac_adjust_common_pred()
libavcodec/aacenc_pred.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/mxf: fix mxf-probe-j2k on big endian systems
Hi Marton, On Wed, Feb 21, 2024 at 6:34 PM Marton Balint wrote: > > Jpeg2000 decoder is decoding in native endian, so let's use the same > workaround > as in fate-mxf-probe-applehdr10. > > Fixes ticket #10868. > > Signed-off-by: Marton Balint > --- > tests/fate/mxf.mak | 2 +- > tests/ref/fate/mxf-probe-j2k | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak > index 8430b01d51..3e0e70e28b 100644 > --- a/tests/fate/mxf.mak > +++ b/tests/fate/mxf.mak > @@ -29,7 +29,7 @@ fate-mxf-probe-dnxhd: CMD = run > $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)" > > FATE_MXF_PROBE-$(call DEMDEC, MXF, JPEG2000) += fate-mxf-probe-j2k > fate-mxf-probe-j2k: SRC = $(TARGET_SAMPLES)/imf/countdown/countdown-small.mxf > -fate-mxf-probe-j2k: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)" > +fate-mxf-probe-j2k: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)" | > sed -e "s/rgb48../rgb48/" > > FATE_MXF_PROBE-$(call DEMDEC, MXF, DVVIDEO PCM_S16LE) += fate-mxf-probe-dv25 > fate-mxf-probe-dv25: SRC = $(TARGET_SAMPLES)/mxf/Avid-5.mxf > diff --git a/tests/ref/fate/mxf-probe-j2k b/tests/ref/fate/mxf-probe-j2k > index 149b3ea0b6..517fbb99a3 100644 > --- a/tests/ref/fate/mxf-probe-j2k > +++ b/tests/ref/fate/mxf-probe-j2k > @@ -14,7 +14,7 @@ film_grain=0 > has_b_frames=0 > sample_aspect_ratio=1:1 > display_aspect_ratio=16:9 > -pix_fmt=rgb48le > +pix_fmt=rgb48 > level=-99 > color_range=unknown > color_space=unknown > -- > 2.35.3 > > ___ > 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". Confirming this fixes #10868 for me. Thanks, Sean McGovern ___ 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] tools: Add target_sws_fuzzer.c
*end = data + size;
> +enum AVPixelFormat srcFormat = AV_PIX_FMT_YUV420P;
> +enum AVPixelFormat dstFormat = AV_PIX_FMT_YUV420P;
> +uint8_t *src[4] = { 0 };
> +uint8_t *dst[4] = { 0 };
> +struct SwsContext *sws = NULL;
> +const AVPixFmtDescriptor *desc_src, *desc_dst;
> +
> +if (size > 128) {
> +GetByteContext gbc;
> +int64_t flags64;
> +
> +size -= 128;
> +bytestream2_init(, data + size, 128);
> +srcW = bytestream2_get_le32() % 256;
> +srcH = bytestream2_get_le32() % 256;
> +dstW = bytestream2_get_le32() % 256;
> +dstH = bytestream2_get_le32() % 256;
> +flags = bytestream2_get_le32();
> +
> +srcFormat = bytestream2_get_le32() % AV_PIX_FMT_NB;
> +dstFormat = bytestream2_get_le32() % AV_PIX_FMT_NB;
> +
> +flags64 = bytestream2_get_le64();
> +if (flags64 & 0x10)
> +av_force_cpu_flags(0);
> +
> +if (av_image_check_size(srcW, srcH, srcFormat, NULL))
> +srcW = srcH = 123;
> +if (av_image_check_size(dstW, dstH, dstFormat, NULL))
> +dstW = dstH = 123;
> +//TODO alphablend
> +}
> +
> +desc_src = av_pix_fmt_desc_get(srcFormat);
> +desc_dst = av_pix_fmt_desc_get(dstFormat);
> +
> +ret = alloc_plane(src, srcStride, srcW, srcH, srcFormat, ,
> );
> +if (ret < 0)
> +goto end;
> +
> +ret = alloc_plane(dst, dstStride, dstW, dstH, dstFormat, ,
> );
> +if (ret < 0)
> +goto end;
> +
> +
> +for(int p=0; p +int psize = srcStride[p] * AV_CEIL_RSHIFT(srcH, (p == 1 || p ==
> 2) ? srcVShift : 0);
> +if (psize > size)
> +psize = size;
> +if (psize) {
> +memcpy(src[p], data, psize);
> +data += psize;
> +size -= psize;
> +}
> +}
> +
> +sws = sws_alloc_context();
> +if (!sws)
> +error("Failed sws allocation");
> +
> +av_opt_set_int(sws, "sws_flags", flags, 0);
> +av_opt_set_int(sws, "srcw", srcW, 0);
> +av_opt_set_int(sws, "srch", srcH, 0);
> +av_opt_set_int(sws, "dstw", dstW, 0);
> +av_opt_set_int(sws, "dsth", dstH, 0);
> +av_opt_set_int(sws, "src_format", srcFormat, 0);
> +av_opt_set_int(sws, "dst_format", dstFormat, 0);
> +av_opt_set(sws, "alphablend", "none", 0);
> +
> +ret = sws_init_context(sws, NULL, NULL);
> +if (ret < 0)
> +goto end;
> +
> +fprintf(stderr, "%d x %d %s -> %d x %d %s\n", srcW, srcH,
> desc_src->name, dstW, dstH, desc_dst->name);
> +//TODO Slices
> +sws_scale(sws, (const uint8_t * const*)src, srcStride, 0, srcH, dst,
> dstStride);
> +
> +end:
> +sws_freeContext(sws);
> +
> +free_plane(src);
> +free_plane(dst);
> +
> +return 0;
> +}
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
I don't see anything intrinsically wrong with this other than:
- is this compiler-backend specific? Does it work without LLVM?
- would it ever be useful to redirect the output of error() to another fd?
In which case maybe a convenience method that defaults to stderr would be
appropriate?
-- Sean McGovern
>
___
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] Require compilers to support C17.
Hi developers, On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf wrote: > Hello, > > On Thu, 8 Feb 2024, at 01:36, Cosmin Stejerean via ffmpeg-devel wrote: > >> There were simply no objections to moving to C11. > >> The C17 plan came about later because it has important bugfixes. > >> It doesn't really matter as compilers backported the new behaviour to > C11 > >> (or rather, they consistently had the same behaviour, but now it became > a standard). > >> > > > > There were no objections to C11, however C17 was brought up and there > > were objections that it's likely too soon and I believe JB proposed > > holding off for a year on C17 (while adopting C11 immediately), which > > My recommendation is still this: > - move to C11 now > - activate C17 on some Fate/CI targets > - recommend C17 compilers modes > - move to C17 at this mid-year when 7.1 is branched (LTS if we follow our > plans) > I like this approach. It's a shame we can't get metrics on who might be genuinely affected by a direct move to C17. I'd be more than willing to host one or more FATE nodes with C17 turned on. Do let me know if this is desirable. -- Sean McGovern > ___ 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] Meeting at FOSDEM
Hi everybody, Sorry I can't be at FOSDEM to meet you all again. Unfortunately it always falls on a weekend I have to be available at home for work. -- Sean McGovern ___ 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] libavutil/ppc/cpu.c: check that AT_HWCAP2 is defined
Hi,
On Thu, Oct 19, 2023, 07:44 Michael Niedermayer
wrote:
> On Wed, Oct 18, 2023 at 01:18:54PM -0400, Sean McGovern wrote:
> > On Sat, Oct 14, 2023, 23:27 Sean McGovern wrote:
> >
> > > It was not introduced until glibc 2.18.
> > > ---
> > > This should fix the ppc32 FATE node.
> > > ---
> > > libavutil/ppc/cpu.c | 5 -
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
> > > index 96b491c716..bc8bb5f47c 100644
> > > --- a/libavutil/ppc/cpu.c
> > > +++ b/libavutil/ppc/cpu.c
> > > @@ -95,12 +95,15 @@ int ff_get_cpu_flags_ppc(void)
> > > #endif
> > > if (ret & AV_CPU_FLAG_VSX)
> > > av_assert0(ret & AV_CPU_FLAG_ALTIVEC);
> > > -} else if (buf[i] == AT_HWCAP2) {
> > > +}
> > > +#ifdef AT_HWCAP2 /* not introduced until glibc 2.18 */
> > > +else if (buf[i] == AT_HWCAP2) {
> > > #ifdef PPC_FEATURE2_ARCH_2_07
> > > if (buf[i + 1] & PPC_FEATURE2_ARCH_2_07)
> > > ret |= AV_CPU_FLAG_POWER8;
> > > #endif
> > > }
> > > +#endif /* AT_HWCAP2 */
> > > }
> > > }
> > >
> > > --
> > > 2.39.2
> > >
> >
> > Ping review.
>
> will apply with my next push to master
>
>
> >
> > Alternatively, can the ppc32 FATE nodes be upgraded to a distribution
> > release with glibc 2.18 or higher?
>
> > Can I assist with that somehow?
>
> If you want, you can run a fate client to replace or augment the old one.
> for this sent the public ssh key the cleint will use to fate-admin (email
> addr
> should be in the docs)
>
> thx
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
>
Just a quick update: I have not forgot about this. I'm still in the middle
of converting my workstation to running Linux natively instead of as a VM.
Stay tuned!
-- Sean McGovern
___
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] FATE RISC-V planned maintenance
On Fri, Dec 22, 2023, 11:41 Rémi Denis-Courmont wrote: > Hello, > > The RISC-V board will be personally visiting the taylor to get a > fashionable > custom-made outfit. As a consequence, it will be taking a much deserved > break > from FATE service over the end of year holidays. > > -- > Rémi Denis-Courmont > http://www.remlab.net/ > > > > ___ > 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". > Do we get to see the cute outfit when it is done? :) -- Sean McGovern ___ 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] RISC-V dev kit recommendations
Hi, If I wanted to purchase a RISC-V developer kit, does anyone have suggestions of what to buy? Or even what to steer clear of? Thanks, Sean McGovern ___ 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] mips/ac3dsp_mips: add missing stddef.h header include
On Sat, Nov 25, 2023, 19:52 James Almer wrote: > On 11/25/2023 9:35 PM, Michael Niedermayer wrote: > > On Fri, Nov 24, 2023 at 08:59:19PM -0300, James Almer wrote: > >> Fixes compilation failures after > 567c67c6c8cb9be083f56198bfa979e4bda84c99. > >> > >> Signed-off-by: James Almer > >> --- > >> libavcodec/mips/ac3dsp_mips.c | 2 ++ > >> 1 file changed, 2 insertions(+) > > > > LGTM > > > > thx > > Applied. > ___ > 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". > Tangential to the change, but I would be super curious to know if anyone is using modern FFmpeg on MIPS hardware, be it a Cavium or whatnot. -- Sean McGovern ___ 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] Need to reduce ffmpeg.exe size in n6.0
Hi, On Tue, Nov 14, 2023, 17:27 Kumar, Rahul via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > Hi All, > > I am trying to reduce the size of ffmpeg.exe for using it to convert RTSP > streams to HLS. > > I used the below command to configure : > > ./configure --prefix=ffmpeg_64/ --enable-shared --disable-everything > --enable-protocol=rtsp --enable-protocol=http --enable-demuxer=rtsp > --enable-muxer=hls --enable-muxer=segment --enable-muxer=mpegts > --enable-encoder=mpeg2video --enable-encoder=aac --enable-decoder=h264 > --enable-decoder=aac --enable-parser=h264 --enable-parser=aac > --enable-filter=copy --enable-filter=aformat --enable-filter=aresample > --enable-bsf=h264_mp4toannexb --enable-bsf=aac_adtstoasc --enable-gpl > --enable-version3 --enable-nonfree --enable-small > --yasmexe='C:/c99/yasm-1.3.0-win64.exe' --target-os=win64 --arch=x86_64 > --toolchain=msvc > > > After this I ran "make" and "make install" command which created 1.2 mb > ffmpeg.exe in bin folder. This ffmpeg.exe is not working for me. Can > somebody guide me if I am missing anything here? > > > Regards, > Rahul > Honeywell > > ___ > 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". > Saying it doesn't work is decidedly nebulous. Also, ffmpeg-devel is a development-centered list and not the correct forum for CLI usage help. -- Sean McGovern > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
On Mon, Nov 13, 2023, 11:59 Michael Niedermayer wrote: > On Sun, Nov 12, 2023 at 09:19:57PM +0100, Paul B Mahol wrote: > > On Sun, Nov 12, 2023 at 5:37 PM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Sun, Nov 12, 2023 at 11:02:49AM +0100, Nicolas George wrote: > > > > Vittorio Giovara (12023-11-11): > > > > > Nice victimization, but "i'm behaving poorly because the other > person > > > is a > > > > > meanie" is a childish argument > > > > > > > > Mock all your want, the fact that you attacked me even though I was > just > > > > replying and not even told Paul to stop his childish games proves you > > > > are biassed beyond all credibility. > > > > > > > > > I am genuinely concerned for whatever reason is pushing you to use > > > such an > > > > > alienating and toxic language, yes. > > > > > > > > Yeah, right. You mocking somebody's mental health was way more > > > > inappropriate than anything that I or Paul ever wrote. > > > > > > Vittorio, Nicolas, Paul. > > > > > > guys i love you all but can you rest this thread until we have a new > > > community committee ? > > > > > > thanks! > > > > > > PS: if there are technical questions and you want, there is a technical > > > committe that could look at it. > > > (At least IMHO the TC is fully functional, thats just my personal > oppinion > > > iam not speaking for the TC here) > > > > > > > > > You are blocking my patch. > > You should be ashamed. > > dear patch iam ashamed but iam not actually blocking you. > Maybe you can forgive me if i provide this short ode to you > > Oh, Paul's Patch, you sly little thing, > A fix for libavfilter, oh joy it brings. > In the world of code, where bugs do dwell, > You swoop in gracefully, breaking their spell. > > With your lines of logic, so neat and clean, > You dance through the bugs like a code routine. > Oh, Paul's Patch, you're a hero in disguise, > Saving us from errors, what a pleasant surprise! > > You sneak into the code, like a ninja in the night, > Fixing issues left and right, oh what a sight. > Libavfilter trembles, but not in fear, > For with Paul's Patch, victory is near. > > Oh, patch so fine, with your bug-crushing might, > You turn errors into pixels of pure delight. > Paul's Patch, the troubleshooter supreme, > In the open source world, you reign supreme. > > Programmers cheer, and users applaud, > For with Paul's Patch, we're never flawed. > So here's to you, oh mighty fixer-upper, > In the kingdom of code, you're the top-drawer. > > To Paul's Patch, a toast we raise, > In the realm of software, you set ablaze. > For every bug quivered, and every glitch shivered, > Thanks to Paul's Patch, we code delivered! > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many things microsoft did are stupid, but not doing something just because > microsoft did it is even more stupid. If everything ms did were stupid they > would be bankrupt already. > ___ > 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". > Made me laugh, +1. -- Sean McGovern > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Hi, On Tue, Nov 7, 2023, 16:50 Nicolas George wrote: > Paul B Mahol (12023-11-07): > > Will apply in next 48h. > > So, you are again threatening to violate the project's policy. > > > Libavfilter code is not so complex to need so big time interval for > review > > from experienced C developer. > > First, the issue is not only analyzing the code but first finding time > to do so. Realize that some of us have a job distinct from FFmpeg. And a > life. And that does not make us second class citizens of the project. > > Second, yes, the scheduling of libavfilter is quite complex, and the > fact that you believe it is not shows how little qualified you are to > judge your own patch. > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > This is really unfair to Paul to let this drag on for so long. If you are genuinely this busy, is there really no one else on the list who you can delegate to review this piece? -- Sean McGovern > ___ 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 4/4] avformat/lafdec: Check for 0 parameters
On Thu, Nov 2, 2023, 19:50 Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 63661/clusterfuzz-testcase-minimized-ffmpeg_dem_LAF_fuzzer-6615365234589696 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by > <https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by>: > Michael Niedermayer > --- > libavformat/lafdec.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/libavformat/lafdec.c b/libavformat/lafdec.c > index 59a59dcfe9c..b867f106aee 100644 > --- a/libavformat/lafdec.c > +++ b/libavformat/lafdec.c > @@ -139,7 +139,9 @@ static int laf_read_header(AVFormatContext *ctx) > s->index = 0; > s->stored_index = 0; > s->bpp = bpp; > -if ((int64_t)bpp * st_count * (int64_t)sample_rate >= INT32_MAX) > +if ((int64_t)bpp * st_count * (int64_t)sample_rate >= INT32_MAX || > +(int64_t)bpp * st_count * (int64_t)sample_rate == 0 > +) > return AVERROR_INVALIDDATA; > s->data = av_calloc(st_count * sample_rate, bpp); > if (!s->data) > -- > 2.17.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > This looks OK to me. -- Sean McGovern > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] avcodec/flicvideo: consider width in copy loops
On Thu, Nov 2, 2023, 19:50 Michael Niedermayer
wrote:
> Fixes: out of array write
> Fixes:
> 63520/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLIC_fuzzer-4876198087622656
> Regression since: c7f8d42c12582b0626ea38117df6c9aea9fcf5b1 (was not posted
> to ffmpeg-devel)
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> <https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by>:
> Michael Niedermayer
> ---
> libavcodec/flicvideo.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/flicvideo.c b/libavcodec/flicvideo.c
> index 6ce033ba409..43f3f83bf65 100644
> --- a/libavcodec/flicvideo.c
> +++ b/libavcodec/flicvideo.c
> @@ -642,7 +642,7 @@ static int flic_decode_frame_8BPP(AVCodecContext
> *avctx,
> "has incorrect size, skipping chunk\n", chunk_size
> - 6);
> bytestream2_skip(, chunk_size - 6);
> } else {
> -for (y_ptr = 0; check_pixel_ptr(y_ptr, 0, pixel_limit,
> direction) == 0;
> +for (y_ptr = 0; check_pixel_ptr(y_ptr, s->avctx->width,
> pixel_limit, direction) == 0;
> y_ptr += s->frame->linesize[0]) {
> bytestream2_get_buffer(, [y_ptr],
> s->avctx->width);
> @@ -949,7 +949,7 @@ static int flic_decode_frame_15_16BPP(AVCodecContext
> *avctx,
>
> if (bytestream2_get_bytes_left() < 2 * s->avctx->width
> * s->avctx->height )
> return AVERROR_INVALIDDATA;
> -for (y_ptr = 0; check_pixel_ptr(y_ptr, 0, pixel_limit,
> direction) == 0;
> +for (y_ptr = 0; check_pixel_ptr(y_ptr, 2*s->avctx->width,
> pixel_limit, direction) == 0;
> y_ptr += s->frame->linesize[0]) {
>
> pixel_countdown = s->avctx->width;
> @@ -1235,7 +1235,7 @@ static int flic_decode_frame_24BPP(AVCodecContext
> *avctx,
> "bigger than image, skipping chunk\n", chunk_size
> - 6);
> bytestream2_skip(, chunk_size - 6);
> } else {
> -for (y_ptr = 0; check_pixel_ptr(y_ptr, 0, pixel_limit,
> direction) == 0;
> +for (y_ptr = 0; check_pixel_ptr(y_ptr, 3*s->avctx->width,
> pixel_limit, direction) == 0;
> y_ptr += s->frame->linesize[0]) {
>
> bytestream2_get_buffer(, pixels + y_ptr,
> 3*s->avctx->width);
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
On quick inspection this looks OK, but is s->avctx->width guaranteed to be
non-zero as well?
-- Sean McGovern
>
___
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/4] avfilter/buffersink: cuddle () closer around =
On Thu, Nov 2, 2023, 19:50 Michael Niedermayer
wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/buffersink.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
> index 9426ded7ee3..ca2af1bc077 100644
> --- a/libavfilter/buffersink.c
> +++ b/libavfilter/buffersink.c
> @@ -293,7 +293,7 @@ static int asink_query_formats(AVFilterContext *ctx)
> cleanup_redundant_layouts(ctx);
> for (i = 0; i < NB_ITEMS(buf->channel_layouts); i++)
> if ((ret = av_channel_layout_from_mask(,
> buf->channel_layouts[i])) < 0 ||
> -(ret = ff_add_channel_layout(, ) < 0))
> +(ret = ff_add_channel_layout(, )) < 0)
> return ret;
> for (i = 0; i < NB_ITEMS(buf->channel_counts); i++) {
> layout = FF_COUNT2LAYOUT(buf->channel_counts[i]);
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
This and 1/2 seem a bit frivolous, but providing they don't violate the
project style guide, LGTM.
-- Sean McGovern
>
___
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] aarch64: Simplify the linux runtime cpu detection code
On Thu, Oct 26, 2023 at 5:40 PM Sean McGovern wrote:
>
> On Tue, Oct 24, 2023 at 8:40 AM Sean McGovern wrote:
> >
> >
> >
> > On Tue, Oct 24, 2023, 08:23 Martin Storsjö wrote:
> >>
> >> Skip doing the whole getauxval(AT_HWCAP) if HWCAP_CPUID isn't
> >> defined.
> >> ---
> >> libavutil/aarch64/cpu.c | 6 +-
> >> 1 file changed, 1 insertion(+), 5 deletions(-)
> >>
> >> diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c
> >> index bd780e8591..2b50c426bc 100644
> >> --- a/libavutil/aarch64/cpu.c
> >> +++ b/libavutil/aarch64/cpu.c
> >> @@ -30,11 +30,9 @@
> >> static int detect_flags(void)
> >> {
> >> int flags = 0;
> >> -unsigned long hwcap;
> >> -
> >> -hwcap = getauxval(AT_HWCAP);
> >>
> >> #if defined(HWCAP_CPUID)
> >> +unsigned long hwcap = getauxval(AT_HWCAP);
> >> // We can check for DOTPROD and I8MM using HWCAP_ASIMDDP and
> >> // HWCAP2_I8MM too, avoiding to read the CPUID registers (which
> >> triggers
> >> // a trap, handled by the kernel). However the HWCAP_* defines for
> >> these
> >> @@ -53,8 +51,6 @@ static int detect_flags(void)
> >> if (((tmp >> 52) & 0xf) == 0x1)
> >> flags |= AV_CPU_FLAG_I8MM;
> >> }
> >> -#else
> >> -(void)hwcap;
> >> #endif
> >>
> >> return flags;
> >> --
> >> 2.34.1
> >>
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >> To unsubscribe, visit link above, or email
> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> >
> > Good call, and LGTM.
> >
> > -- Sean McGovern
>
> Ooops! I don't have c= so maybe someone who does could push this --
> and the 2nd patch in this set needs a pair of eyes more familiar with
> compiler bugs.
>
> -- Sean McG
Looks like I missed the push notification on patch #2.
-- Sean McG.
___
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] aarch64: Simplify the linux runtime cpu detection code
On Tue, Oct 24, 2023 at 8:40 AM Sean McGovern wrote:
>
>
>
> On Tue, Oct 24, 2023, 08:23 Martin Storsjö wrote:
>>
>> Skip doing the whole getauxval(AT_HWCAP) if HWCAP_CPUID isn't
>> defined.
>> ---
>> libavutil/aarch64/cpu.c | 6 +-
>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c
>> index bd780e8591..2b50c426bc 100644
>> --- a/libavutil/aarch64/cpu.c
>> +++ b/libavutil/aarch64/cpu.c
>> @@ -30,11 +30,9 @@
>> static int detect_flags(void)
>> {
>> int flags = 0;
>> -unsigned long hwcap;
>> -
>> -hwcap = getauxval(AT_HWCAP);
>>
>> #if defined(HWCAP_CPUID)
>> +unsigned long hwcap = getauxval(AT_HWCAP);
>> // We can check for DOTPROD and I8MM using HWCAP_ASIMDDP and
>> // HWCAP2_I8MM too, avoiding to read the CPUID registers (which triggers
>> // a trap, handled by the kernel). However the HWCAP_* defines for these
>> @@ -53,8 +51,6 @@ static int detect_flags(void)
>> if (((tmp >> 52) & 0xf) == 0x1)
>> flags |= AV_CPU_FLAG_I8MM;
>> }
>> -#else
>> -(void)hwcap;
>> #endif
>>
>> return flags;
>> --
>> 2.34.1
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
>
> Good call, and LGTM.
>
> -- Sean McGovern
Ooops! I don't have c= so maybe someone who does could push this --
and the 2nd patch in this set needs a pair of eyes more familiar with
compiler bugs.
-- Sean McG
___
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] lavu/riscv: fix typo
On Thu, Oct 26, 2023, 12:05 Rémi Denis-Courmont wrote: > --- > libavutil/riscv/cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c > index fa45c0ad83..460d3e9f91 100644 > --- a/libavutil/riscv/cpu.c > +++ b/libavutil/riscv/cpu.c > @@ -67,7 +67,7 @@ int ff_get_cpu_flags_riscv(void) > #endif > > /* If RV-V is enabled statically at compile-time, check the details. > */ > -#ifdef __riscv_vectors > +#ifdef __riscv_vector > ret |= AV_CPU_FLAG_RVV_I32; > #if __riscv_v_elen >= 64 > ret |= AV_CPU_FLAG_RVV_I64; > -- > 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". > Looks OK to me. -- Sean McGovern > ___ 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] aarch64: Simplify the linux runtime cpu detection code
On Tue, Oct 24, 2023, 08:23 Martin Storsjö wrote:
> Skip doing the whole getauxval(AT_HWCAP) if HWCAP_CPUID isn't
> defined.
> ---
> libavutil/aarch64/cpu.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c
> index bd780e8591..2b50c426bc 100644
> --- a/libavutil/aarch64/cpu.c
> +++ b/libavutil/aarch64/cpu.c
> @@ -30,11 +30,9 @@
> static int detect_flags(void)
> {
> int flags = 0;
> -unsigned long hwcap;
> -
> -hwcap = getauxval(AT_HWCAP);
>
> #if defined(HWCAP_CPUID)
> +unsigned long hwcap = getauxval(AT_HWCAP);
> // We can check for DOTPROD and I8MM using HWCAP_ASIMDDP and
> // HWCAP2_I8MM too, avoiding to read the CPUID registers (which
> triggers
> // a trap, handled by the kernel). However the HWCAP_* defines for
> these
> @@ -53,8 +51,6 @@ static int detect_flags(void)
> if (((tmp >> 52) & 0xf) == 0x1)
> flags |= AV_CPU_FLAG_I8MM;
> }
> -#else
> -(void)hwcap;
> #endif
>
> return flags;
> --
> 2.34.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
Good call, and LGTM.
-- Sean McGovern
>
___
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] libavutil/ppc/cpu.c: check that AT_HWCAP2 is defined
On Sat, Oct 14, 2023, 23:27 Sean McGovern wrote:
> It was not introduced until glibc 2.18.
> ---
> This should fix the ppc32 FATE node.
> ---
> libavutil/ppc/cpu.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
> index 96b491c716..bc8bb5f47c 100644
> --- a/libavutil/ppc/cpu.c
> +++ b/libavutil/ppc/cpu.c
> @@ -95,12 +95,15 @@ int ff_get_cpu_flags_ppc(void)
> #endif
> if (ret & AV_CPU_FLAG_VSX)
> av_assert0(ret & AV_CPU_FLAG_ALTIVEC);
> -} else if (buf[i] == AT_HWCAP2) {
> +}
> +#ifdef AT_HWCAP2 /* not introduced until glibc 2.18 */
> +else if (buf[i] == AT_HWCAP2) {
> #ifdef PPC_FEATURE2_ARCH_2_07
> if (buf[i + 1] & PPC_FEATURE2_ARCH_2_07)
> ret |= AV_CPU_FLAG_POWER8;
> #endif
> }
> +#endif /* AT_HWCAP2 */
> }
> }
>
> --
> 2.39.2
>
Ping review.
Alternatively, can the ppc32 FATE nodes be upgraded to a distribution
release with glibc 2.18 or higher?
Can I assist with that somehow?
Thanks,
Sean McGovern
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavutil/ppc/cpu.c: check that AT_HWCAP2 is defined
It was not introduced until glibc 2.18.
---
This should fix the ppc32 FATE node.
---
libavutil/ppc/cpu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
index 96b491c716..bc8bb5f47c 100644
--- a/libavutil/ppc/cpu.c
+++ b/libavutil/ppc/cpu.c
@@ -95,12 +95,15 @@ int ff_get_cpu_flags_ppc(void)
#endif
if (ret & AV_CPU_FLAG_VSX)
av_assert0(ret & AV_CPU_FLAG_ALTIVEC);
-} else if (buf[i] == AT_HWCAP2) {
+}
+#ifdef AT_HWCAP2 /* not introduced until glibc 2.18 */
+else if (buf[i] == AT_HWCAP2) {
#ifdef PPC_FEATURE2_ARCH_2_07
if (buf[i + 1] & PPC_FEATURE2_ARCH_2_07)
ret |= AV_CPU_FLAG_POWER8;
#endif
}
+#endif /* AT_HWCAP2 */
}
}
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
