T-Head C908:
h263dsp.dct_unquantize_inter_c: 3.7
h263dsp.dct_unquantize_inter_rvv_i32: 1.7
h263dsp.dct_unquantize_intra_c: 4.0
h263dsp.dct_unquantize_intra_rvv_i32: 2.0
SpacemiT X60:
h263dsp.dct_unquantize_inter_c: 3.5
h263dsp.dct_unquantize_inter_rvv_i32: 1.5
h263dsp.dct_unquant
Note that optimised implementations of these functions will be taken
into actual use only if MpegEncContext.dct_unquantize_h263_{inter,intra}
are *not* overloaded by existing optimisations.
---
This adds the plus ones back, saving two branch instructions in C and
one in assembler (at the cost of t
---
configure | 4 ++--
libavcodec/mpegvideo.c | 46 +++---
2 files changed, 14 insertions(+), 36 deletions(-)
diff --git a/configure b/configure
index 6baa9b0646..eb9d1b1f5d 100755
--- a/configure
+++ b/configure
@@ -2957,8 +2957,8 @@ ftr_decoder
---
tests/checkasm/h263dsp.c | 47 +++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/tests/checkasm/h263dsp.c b/tests/checkasm/h263dsp.c
index 2d0957a90b..8a2cdb34df 100644
--- a/tests/checkasm/h263dsp.c
+++ b/tests/checkasm/h263dsp.c
@@ -18,13
Rémi Denis-Courmont:
> Le tiistaina 11. kesäkuuta 2024, 13.30.28 EEST Andreas Rheinhardt a écrit :
>>> +static void h263_dct_unquantize_intra_c(int16_t *block, size_t nCoeffs,
>>> +int qmul, int qadd)
>>> +{
>>> +if (nCoeffs > 0)
>>
>> Great, a branch.
>
Le tiistaina 11. kesäkuuta 2024, 13.30.28 EEST Andreas Rheinhardt a écrit :
> > +static void h263_dct_unquantize_intra_c(int16_t *block, size_t nCoeffs,
> > +int qmul, int qadd)
> > +{
> > +if (nCoeffs > 0)
>
> Great, a branch.
Okay so you want sarcasms
Le keskiviikkona 12. kesäkuuta 2024, 0.37.12 EEST Sean McGovern a écrit :
> +1 for this. Let's get it in first before AVR32 & Alpha removal.
AVR32 is not 64-bit; there are no deps one way or the other between the
patches.
--
雷米‧德尼-库尔蒙
http://www.remlab.net/
__
On Wo, 2024-06-05 at 21:13 +0100, Mark Thompson wrote:
> libva 2.0 was released in 2017 and the 2.x versions are included in all
> supported distributions nowadays. Various features no longer need any
> configure check after this change, including all codecs except AV1.
> Note that the libva versi
Signed-off-by: James Almer
---
libavcodec/vorbisdec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
index 700c6c8918..218e855f7a 100644
--- a/libavcodec/vorbisdec.c
+++ b/libavcodec/vorbisdec.c
@@ -181,11 +181,11 @@ stati
Signed-off-by: James Almer
---
libavcodec/adpcm.c | 2 +-
libavcodec/amrwbdec.c | 2 +-
libavcodec/atrac3plus.c | 2 +-
libavcodec/dnxhdenc.c | 2 +-
libavcodec/dvenc.c | 2 +-
libavcodec/ffv1dec_template.c | 2 +-
libavcodec/g726.c
Signed-off-by: James Almer
---
libavutil/common.h | 5 -
libavutil/x86/intmath.h | 14 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/libavutil/common.h b/libavutil/common.h
index fa2333d181..1f5db42cb2 100644
--- a/libavutil/common.h
+++ b/libavutil/comm
It's more descriptive of what it does.
Signed-off-by: James Almer
---
TODO: Version bump
doc/APIchanges | 3 +++
libavutil/common.h | 20
libavutil/version.h | 1 +
libavutil/x86/intmath.h | 6 +++---
4 files changed, 23 insertions(+), 7 deletions(-)
d
From: Fei Wang
Signed-off-by: Fei Wang
---
Changelog | 1 +
configure | 1 +
doc/decoders.texi | 2 +-
libavcodec/allcodecs.c | 1 +
libavcodec/qsv.c | 4
libavcodec/qsvdec.c| 7 ++-
libavcodec/version.h | 2 +-
7 files changed, 15 insertions(
On 11/06/2024 06:55, Xiang, Haihao wrote:
From: Haihao Xiang
Otherwise nothing is written into the destination when a write mapping
is requested.
For example, a vulkan frame mapped from a drm frame (which is wrapped as
a vaapi frame in the example) is used as the output of scale_vulkan
filter,
Hi,
Can someone help me reset my password on Patchwork? I've used the 'Forgot
password ' link several times and never received an email.
-- Sean McGovern
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-de
On Mon, Jun 03, 2024 at 04:15:18AM +0200, Michael Niedermayer wrote:
> Alot more input checking can be performed, this is only checking the obvious
> missing case
>
> Fixes: CID1598562 Unchecked return value
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> lib
On Mon, Jun 03, 2024 at 09:44:50PM +0200, Michael Niedermayer wrote:
> Fixes: NULL pointer dereference
> Fixes: 3_343
>
> Found-by: De3mond
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/vf_rotate.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
will apply
[...]
--
Micha
Fixes: CID1551694 Use after free (false positive based on assuming that out ==
in and one is freed and one used)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_avgblur.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_a
Fixes: CID1598548 Logically dead code
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/qsvvpp.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 1c9773df099..6adf9f6e841 100644
--- a/libavfilter/qsvvpp.c
Fixes: CID1496940 Logically dead code
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/drawutils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index 1081938d867..95525d38b40 100644
--- a/libavfilter/dra
Fixes: CID1539147 Unused value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/avf_showcwt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavfilter/avf_showcwt.c b/libavfilter/avf_showcwt.c
index 24d16d9075d..89a019a0d41 100644
--- a/libavfilter/av
Hi Remi,
On Tue, Jun 11, 2024, 13:06 Rémi Denis-Courmont wrote:
> Le tiistaina 11. kesäkuuta 2024, 19.48.19 EEST Rémi Denis-Courmont a écrit
> :
> > Currently, any unrecognised platform is treated as 32-bit. This should
> > detect *most* 64-bit platforms, namely LP64 and LLP64 ones.
> > Unfortu
Andreas Rheinhardt:
> Happens on init_pass2() failure.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ratecontrol.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/ratecontrol.c b/libavcodec/ratecontrol.c
> index 9ee08ecb88..27017d7976 100644
> --- a/libavcodec/rat
Andreas Rheinhardt:
> Always false since 49331f7ba3e3214738864af96d22fb1e6b5463b7.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/dnxhdenc.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
> index 028604a6e5..8b67becbe2 100644
>
It looks like the command
```
git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1"
--suffix .eml --to ffmpeg-devel@ffmpeg.org -1 1a2b3c4d
```
doesn't work for me. I'll see if I can find another way to submit the patch.
On Tue, Jun 11, 2024 at 1:22 PM Chun-Min Chang
wrote:
> This pa
James Almer:
> It's more descriptive of what it does.
>
> Signed-off-by: James Almer
> ---
> libavutil/common.h | 16 +++-
> libavutil/version.h | 1 +
> libavutil/x86/intmath.h | 6 +++---
> 3 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/libavutil/com
This patch updates libaomenc.c to accept parameters for SVC (Scalable
Video Coding) settings via the FFmpeg API `av_opt_set`. The SVC
configuration is applied based on the provided parameters. As libaom's
SVC functionality only operates with constant bitrate encoding [1],
these parameters will onl
Rémi Denis-Courmont:
> Le tiistaina 11. kesäkuuta 2024, 21.52.30 EEST James Almer a écrit :
>> It's more descriptive of what it does.
>>
>> Signed-off-by: James Almer
>> ---
>> libavutil/common.h | 16 +++-
>> libavutil/version.h | 1 +
>> libavutil/x86/intmath.h | 6 +++---
On 6/11/2024 4:13 PM, Rémi Denis-Courmont wrote:
Le tiistaina 11. kesäkuuta 2024, 21.52.30 EEST James Almer a écrit :
It's more descriptive of what it does.
Signed-off-by: James Almer
---
libavutil/common.h | 16 +++-
libavutil/version.h | 1 +
libavutil/x86/intmath.h
Le tiistaina 11. kesäkuuta 2024, 21.52.30 EEST James Almer a écrit :
> It's more descriptive of what it does.
>
> Signed-off-by: James Almer
> ---
> libavutil/common.h | 16 +++-
> libavutil/version.h | 1 +
> libavutil/x86/intmath.h | 6 +++---
> 3 files changed, 19 inser
Signed-off-by: James Almer
---
libavcodec/adpcm.c | 2 +-
libavcodec/amrwbdec.c | 2 +-
libavcodec/atrac3plus.c | 2 +-
libavcodec/dnxhdenc.c | 2 +-
libavcodec/dvenc.c | 2 +-
libavcodec/ffv1dec_template.c | 2 +-
libavcodec/g726.c
Signed-off-by: James Almer
---
libavutil/common.h | 3 +++
libavutil/x86/intmath.h | 5 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavutil/common.h b/libavutil/common.h
index acd041fb67..65448d47d3 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -296,6
It's more descriptive of what it does.
Signed-off-by: James Almer
---
libavutil/common.h | 16 +++-
libavutil/version.h | 1 +
libavutil/x86/intmath.h | 6 +++---
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/libavutil/common.h b/libavutil/common.h
index
On 6/10/2024 3:44 PM, Derek Buitenhuis wrote:
These originate from the Apple Vision Pro, and are documented here:
https://developer.apple.com/documentation/coremedia/cmprojectiontype
Signed-off-by: Derek Buitenhuis
---
libavutil/spherical.c | 3 +++
libavutil/spherical.h | 16
On 6/11/2024 7:09 PM, Michael Niedermayer wrote:
> side_data_type=Stereo 3D
> type=2D
> inverted=0
> +view=packed
> +primary_eye=none
Hmm. This does make me think we need a better way to print 'view' and
'inverted' in
FFprobe. Perhaps if type!=2D?
- Derek
On 6/11/2024 3:26 PM, Michael Niedermayer wrote:
On Tue, Jun 11, 2024 at 02:28:56PM +0200, Ramiro Polla wrote:
chrRangeFromJpeg_8_c: 28.7
chrRangeFromJpeg_8_sse4: 16.2
chrRangeFromJpeg_24_c: 152.7
chrRangeFromJpeg_24_sse4: 29.7
chrRangeFromJpeg_128_c: 366.5
chrRangeFromJpeg_128_sse4: 233.0
chrRa
> Nit: for overall code base consistency, I'd use csrwi here. Reason being
that
> for other rounding modes, csrwi is the better option.
>
> Probably faster to swap the two above, to avoid stalling on LD.
>
> If you check more than one length, better to get ff_get_rv_vlenb() into a
local
> variable.
From: sunyuechi
C908 X60
avg_8_2x2_c:1.21.0
avg_8_2x2_rvv_i32 :1.01.0
avg_8_2x4_c:2.02.0
avg_8_2x4_rvv_i
On Tue, Jun 11, 2024 at 02:28:56PM +0200, Ramiro Polla wrote:
> chrRangeFromJpeg_8_c: 28.7
> chrRangeFromJpeg_8_sse4: 16.2
> chrRangeFromJpeg_24_c: 152.7
> chrRangeFromJpeg_24_sse4: 29.7
> chrRangeFromJpeg_128_c: 366.5
> chrRangeFromJpeg_128_sse4: 233.0
> chrRangeFromJpeg_144_c: 408.0
> chrRangeFro
On Mon, Jun 10, 2024 at 07:44:05PM +0100, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> fftools/ffprobe.c | 8
> 1 file changed, 8 insertions(+)
this needs a update to fate
TESTmatroska-spherical-mono
--- ./tests/ref/fate/matroska-spherical-mono2024-06-11 1
tis 2024-06-11 klockan 18:10 +0200 skrev Michael Niedermayer:
> On Tue, Jun 11, 2024 at 05:50:35PM +0200, Tomas Härdin wrote:
> [...]
> > Perhaps we should demand platforms for which we have asm also have
> > FATE
> > instances?
>
> qemu based fate we have for sh-4:
> https://fate.ffmpeg.org/?quer
Ping?
Not including EMMS causes the FPU to become unusable (as the IE and SF bits are
set in the status word). This breaks code which, for instance, calls fmod() and
is compiled by GCC with the -O3 flag enabled. In that scenario, GCC implements
fmod using the FPREM FPU instruction, but because
On Tue, Jun 11, 2024 at 10:07:32AM +0300, radu.taraib...@gmail.com wrote:
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: marți, 4 iunie 2024 01:42
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH] ar
Le tiistaina 11. kesäkuuta 2024, 19.48.19 EEST Rémi Denis-Courmont a écrit :
> Currently, any unrecognised platform is treated as 32-bit. This should
> detect *most* 64-bit platforms, namely LP64 and LLP64 ones.
> Unfortunately this will not work for ILP32 ABIs on 64-bit ISAs, but
> still better th
Le tiistaina 11. kesäkuuta 2024, 19.38.15 EEST u...@foxmail.com a écrit :
> From: sunyuechi
>
> C908 X60
> avg_8_2x2_c:1.21.0
> avg_8_2x2_rvv_i32 :1.01.
Currently, any unrecognised platform is treated as 32-bit. This should
detect *most* 64-bit platforms, namely LP64 and LLP64 ones.
Unfortunately this will not work for ILP32 ABIs on 64-bit ISAs, but
still better than nothing.
---
configure | 6 ++
1 file changed, 6 insertions(+)
diff --git a/
> I think we can drop the 2x2 transforms. In all likelihood, scalar code
will
> end up faster than vector code on future hardware, especially out-of-order
> pipelines.
I want to drop 2x2, but since there's only one function to handle all
situations instead of 7*7 functions..
> AFAIU, this will ge
From: sunyuechi
C908 X60
avg_8_2x2_c:1.21.0
avg_8_2x2_rvv_i32 :1.01.0
avg_8_2x4_c:2.02.0
avg_8_2x4_rvv_i
Le tiistaina 11. kesäkuuta 2024, 19.04.17 EEST Michael Niedermayer a écrit :
> then simply remove avr32 with that explanation (no C11 compiler, and any
> other reason)
No. Måns and my optimisation arguments stand, even if it is purely
hypothetical in the case of AVR32 (for which there is no worki
Le tiistaina 11. kesäkuuta 2024, 19.10.04 EEST Michael Niedermayer a écrit :
> On Tue, Jun 11, 2024 at 05:50:35PM +0200, Tomas Härdin wrote:
> [...]
>
> > Perhaps we should demand platforms for which we have asm also have FATE
> > instances?
>
> qemu based fate we have for sh-4:
> https://fate.ff
On Tue, Jun 11, 2024 at 01:08:04PM -0300, James Almer wrote:
> On 6/11/2024 12:57 PM, Michael Niedermayer wrote:
> > On Tue, Jun 11, 2024 at 12:38:37PM -0300, James Almer wrote:
> > > On 6/11/2024 10:15 AM, Michael Niedermayer wrote:
> > > > On Fri, Jun 07, 2024 at 09:19:46PM +0300, Rémi Denis-Cour
Am 11.06.24 um 17:02 schrieb Anton Khirnov:
Quoting Sfan5 (2024-05-17 10:34:50)
As of mbedTLS 3.6.0 TLSv1.3 is enabled by default and certificate
verification
is now mandatory. Our default configuration does not do verification, so
downgrade to 1.2 in these situations to avoid breaking it.
ref:
On Tue, Jun 11, 2024 at 05:50:35PM +0200, Tomas Härdin wrote:
[...]
> Perhaps we should demand platforms for which we have asm also have FATE
> instances?
qemu based fate we have for sh-4:
https://fate.ffmpeg.org/?query=subarch:sh4%2F%2F
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF
On 6/11/2024 12:57 PM, Michael Niedermayer wrote:
On Tue, Jun 11, 2024 at 12:38:37PM -0300, James Almer wrote:
On 6/11/2024 10:15 AM, Michael Niedermayer wrote:
On Fri, Jun 07, 2024 at 09:19:46PM +0300, Rémi Denis-Courmont wrote:
C code or compiler built-ins are preferable over inline assemble
On Tue, Jun 11, 2024 at 06:28:30PM +0300, Rémi Denis-Courmont wrote:
> Le tiistaina 11. kesäkuuta 2024, 16.15.19 EEST Michael Niedermayer a écrit :
> > On Fri, Jun 07, 2024 at 09:19:46PM +0300, Rémi Denis-Courmont wrote:
> > > C code or compiler built-ins are preferable over inline assembler for
>
On Tue, Jun 11, 2024 at 5:57 PM Michael Niedermayer
wrote:
> On Tue, Jun 11, 2024 at 12:38:37PM -0300, James Almer wrote:
> > On 6/11/2024 10:15 AM, Michael Niedermayer wrote:
> > > On Fri, Jun 07, 2024 at 09:19:46PM +0300, Rémi Denis-Courmont wrote:
> > > > C code or compiler built-ins are prefe
On Tue, Jun 11, 2024 at 12:38:37PM -0300, James Almer wrote:
> On 6/11/2024 10:15 AM, Michael Niedermayer wrote:
> > On Fri, Jun 07, 2024 at 09:19:46PM +0300, Rémi Denis-Courmont wrote:
> > > C code or compiler built-ins are preferable over inline assembler for
> > > byte-swaps as it allows for bet
tis 2024-06-11 klockan 12:38 -0300 skrev James Almer:
> On 6/11/2024 10:15 AM, Michael Niedermayer wrote:
> > On Fri, Jun 07, 2024 at 09:19:46PM +0300, Rémi Denis-Courmont
> > wrote:
> > > C code or compiler built-ins are preferable over inline assembler
> > > for
> > > byte-swaps as it allows for
On Mon, Jun 10, 2024 at 02:45:14PM +0200, Vittorio Giovara wrote:
> On Mon, Jun 10, 2024 at 2:41 PM Timo Rothenpieler
> wrote:
>
> > > In either case, my point is that email is not a good system for these
> > > reports, because they cannot be tracked nor analyzed, and if they do
> > pose a
> > >
On 6/11/2024 10:15 AM, Michael Niedermayer wrote:
On Fri, Jun 07, 2024 at 09:19:46PM +0300, Rémi Denis-Courmont wrote:
C code or compiler built-ins are preferable over inline assembler for
byte-swaps as it allows for better optimisations (e.g. instruction
scheduling) which would otherwise be imp
Le tiistaina 11. kesäkuuta 2024, 18.08.51 EEST James Almer a écrit :
> On 6/11/2024 11:55 AM, Rémi Denis-Courmont wrote:
> > This seems to cause issues in FATE for 4x4 and 4x8 transforms. But then
> > again, FATE does not seem to care in the 8x4 case.
> >
> > Note that AArch64 NEON code is known t
Le tiistaina 11. kesäkuuta 2024, 16.15.19 EEST Michael Niedermayer a écrit :
> On Fri, Jun 07, 2024 at 09:19:46PM +0300, Rémi Denis-Courmont wrote:
> > C code or compiler built-ins are preferable over inline assembler for
> > byte-swaps as it allows for better optimisations (e.g. instruction
> > sc
Le tiistaina 11. kesäkuuta 2024, 16.00.28 EEST Andreas Rheinhardt a écrit :
> Rémi Denis-Courmont:
> > The same as any other indirect function tail call. What do you want me to
> > say?! Changing how FFmpeg handles assembler optimisations, or removing
> > the upper level of indirection is outside t
On 6/11/2024 11:55 AM, Rémi Denis-Courmont wrote:
This seems to cause issues in FATE for 4x4 and 4x8 transforms. But then
again, FATE does not seem to care in the 8x4 case.
Note that AArch64 NEON code is known to fail this test.
---
tests/checkasm/vc1dsp.c | 6 --
1 file changed, 4 insert
Quoting Sfan5 (2024-05-17 10:34:50)
> As of mbedTLS 3.6.0 TLSv1.3 is enabled by default and certificate
> verification
> is now mandatory. Our default configuration does not do verification, so
> downgrade to 1.2 in these situations to avoid breaking it.
>
> ref: https://github.com/Mbed-TLS/mbedt
This seems to cause issues in FATE for 4x4 and 4x8 transforms. But then
again, FATE does not seem to care in the 8x4 case.
Note that AArch64 NEON code is known to fail this test.
---
tests/checkasm/vc1dsp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/v
This shifts the mid-point (after horizontal, before vertical) block
state of the transform to match the C code. This forces shifting 8
vectors of 4 elements instead of 4 vectors of 8 elements and is thus
slight slower.
---
libavcodec/riscv/vc1dsp_rvv.S | 7 +++
1 file changed, 3 insertions(+),
Le tiistaina 11. kesäkuuta 2024, 15.23.11 EEST James Almer a écrit :
> On 6/11/2024 9:19 AM, Rémi Denis-Courmont wrote:
> > Le 11 juin 2024 15:09:42 GMT+03:00, "Ronald S. Bultje"
a écrit :
> >> Hi,
> >>
> >> On Mon, Jun 10, 2024 at 3:20 PM Rémi Denis-Courmont
wrote:
> >>> Although checkasm doe
On Tue, Jun 11, 2024 at 3:49 PM Michael Niedermayer
wrote:
> On Tue, Jun 11, 2024 at 02:26:37PM +0300, Rémi Denis-Courmont wrote:
> >
> >
> > Le 11 juin 2024 12:59:23 GMT+03:00, Michael Niedermayer <
> mich...@niedermayer.cc> a écrit :
> > >On Mon, Jun 10, 2024 at 08:52:08PM -0400, Sean McGovern
On 2024-06-11 15:39:52 +0200, Michael Niedermayer wrote:
> > >> It is worth mentioning that even Debian hasn't supported Alpha (along
> > >> with several other architectures) since release 8.0 in June 2018.
> > >
> > >I think debian dropped alpha from the officially supported architectures
> > >but
Fixes: CID1500281 Out-of-bounds write
Fixes: CID1500331 Out-of-bounds write
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/af_pan.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavfilter/af_pan.c b/libavfilter/af_pan.c
index 31c6be45c37..da3
Fixes: CID1422217 Result is not floating-point
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/af_mcompand.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/af_mcompand.c b/libavfilter/af_mcompand.c
index 89fe806a021..e6382
Maybe Helps: CID1503077 Bad bit shift operation
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/af_channelsplit.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavfilter/af_channelsplit.c b/libavfilter/af_channelsplit.c
index 1c4e81
Fixes: CID1503078 Resource leak
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/af_aresample.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavfilter/af_aresample.c b/libavfilter/af_aresample.c
index d6bd77beb32..8ff2fe5973f 10064
On Tue, Jun 11, 2024 at 02:26:37PM +0300, Rémi Denis-Courmont wrote:
>
>
> Le 11 juin 2024 12:59:23 GMT+03:00, Michael Niedermayer
> a écrit :
> >On Mon, Jun 10, 2024 at 08:52:08PM -0400, Sean McGovern wrote:
> >[...]
> >> Are there any real concerns about the Alpha removal itself?
> >> People
On Fri, Jun 07, 2024 at 09:19:46PM +0300, Rémi Denis-Courmont wrote:
> C code or compiler built-ins are preferable over inline assembler for
> byte-swaps as it allows for better optimisations (e.g. instruction
> scheduling) which would otherwise be impossible.
>
> As with f64c2e710fa1a7b59753224e7
On Fri, 7 Jun 2024 at 19:55, Rémi Denis-Courmont wrote:
>
>
>
> Le 7 juin 2024 12:53:51 GMT+03:00, Michael Niedermayer
> a écrit :
> >We can require anything from an API that we are able to change and extend
> >Of course we can decide not to allow such requirment even if optional
> >but we surel
On 03.06.2024 22:28, Timo Rothenpieler wrote:
From: BtbN
This is fixed locally
Fixes for example rtmps streaming over schannel.
---
libavformat/tls_schannel.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_s
This patch wants to extend the functionality of sink-filter.
Signed-off-by: Shiqi Zhu
---
configure | 1 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vsink_fbsink.c | 319 +
4 files changed, 322 inser
Rémi Denis-Courmont:
>
>
> Le 11 juin 2024 13:37:57 GMT+03:00, Andreas Rheinhardt
> a écrit :
>> Rémi Denis-Courmont:
>>> ---
>>> libavcodec/mpegvideo.c | 40 +---
>>> 1 file changed, 9 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/libavcodec/mpegvideo
On Mon, Jun 10, 2024 at 1:56 PM Martin Storsjö wrote:
> On Fri, 7 Jun 2024, Ramiro Polla wrote:
>
> > chrRangeFromJpeg_8_c: 28.5
> > chrRangeFromJpeg_8_neon: 21.2
> > chrRangeFromJpeg_24_c: 81.2
> > chrRangeFromJpeg_24_neon: 34.7
> > chrRangeFromJpeg_128_c: 425.2
> > chrRangeFromJpeg_128_neon: 162
On 6/11/2024 9:28 AM, Ramiro Polla wrote:
chrRangeFromJpeg_8_c: 28.7
chrRangeFromJpeg_8_sse4: 16.2
chrRangeFromJpeg_24_c: 152.7
chrRangeFromJpeg_24_sse4: 29.7
chrRangeFromJpeg_128_c: 366.5
chrRangeFromJpeg_128_sse4: 233.0
chrRangeFromJpeg_144_c: 408.0
chrRangeFromJpeg_144_sse4: 182.5
chrRangeFrom
chrRangeFromJpeg_8_c: 29.2
chrRangeFromJpeg_8_neon: 19.5
chrRangeFromJpeg_24_c: 80.5
chrRangeFromJpeg_24_neon: 34.0
chrRangeFromJpeg_128_c: 413.7
chrRangeFromJpeg_128_neon: 156.0
chrRangeFromJpeg_144_c: 471.0
chrRangeFromJpeg_144_neon: 174.2
chrRangeFromJpeg_256_c: 842.0
chrRangeFromJpeg_256_neon:
chrRangeFromJpeg_8_c: 24.1
chrRangeFromJpeg_8_sse4: 16.1
chrRangeFromJpeg_8_avx2: 19.9
chrRangeFromJpeg_24_c: 72.6
chrRangeFromJpeg_24_sse4: 34.6
chrRangeFromJpeg_24_avx2: 30.9
chrRangeFromJpeg_128_c: 341.1
chrRangeFromJpeg_128_sse4: 160.9
chrRangeFromJpeg_128_avx2: 94.1
chrRangeFromJpeg_144_c: 381
chrRangeFromJpeg_8_c: 28.7
chrRangeFromJpeg_8_sse4: 16.2
chrRangeFromJpeg_24_c: 152.7
chrRangeFromJpeg_24_sse4: 29.7
chrRangeFromJpeg_128_c: 366.5
chrRangeFromJpeg_128_sse4: 233.0
chrRangeFromJpeg_144_c: 408.0
chrRangeFromJpeg_144_sse4: 182.5
chrRangeFromJpeg_256_c: 698.7
chrRangeFromJpeg_256_sse4:
---
tests/checkasm/Makefile | 2 +-
tests/checkasm/checkasm.c | 1 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/sw_range_convert.c | 134 ++
4 files changed, 137 insertions(+), 1 deletion(-)
create mode 100644 tests/checkasm/sw_rang
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: Monday, June 10, 2024 11:36 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt
> Subject: [FFmpeg-devel] [PATCH] configure: Disable DNN without backend
>
> The DNN filters are useless without a
On 6/11/2024 9:19 AM, Rémi Denis-Courmont wrote:
Le 11 juin 2024 15:09:42 GMT+03:00, "Ronald S. Bultje" a
écrit :
Hi,
On Mon, Jun 10, 2024 at 3:20 PM Rémi Denis-Courmont wrote:
Although checkasm does not verify this, the decoder requires that the
transform updates the input block exactly
Le 11 juin 2024 15:09:42 GMT+03:00, "Ronald S. Bultje" a
écrit :
>Hi,
>
>On Mon, Jun 10, 2024 at 3:20 PM Rémi Denis-Courmont wrote:
>
>> Although checkasm does not verify this, the decoder requires that the
>> transform updates the input block exactly like the C code does.
>>
>
>Would it be po
Hi,
On Mon, Jun 10, 2024 at 3:20 PM Rémi Denis-Courmont wrote:
> Although checkasm does not verify this, the decoder requires that the
> transform updates the input block exactly like the C code does.
>
Would it be possible to update the checkasm test to verify this?
Ronald
___
Le 11 juin 2024 13:37:57 GMT+03:00, Andreas Rheinhardt
a écrit :
>Rémi Denis-Courmont:
>> ---
>> libavcodec/mpegvideo.c | 40 +---
>> 1 file changed, 9 insertions(+), 31 deletions(-)
>>
>> diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
>> inde
Le 11 juin 2024 12:59:23 GMT+03:00, Michael Niedermayer
a écrit :
>On Mon, Jun 10, 2024 at 08:52:08PM -0400, Sean McGovern wrote:
>[...]
>> Are there any real concerns about the Alpha removal itself?
>> People still wanting to use FFmpeg for hardware that old can stick
>> with 7.0 (and fork it
Quoting Andreas Rheinhardt (2024-06-11 08:37:59)
> Signed-off-by: Andreas Rheinhardt
> ---
> fftools/ffmpeg_mux_init.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
> index 2ed4171a75..e25c6e7e24 100644
> --- a/fftools/ffmpeg_mux_i
Hi,
On Mon, Jun 10, 2024 at 9:04 PM Marton Balint wrote:
> On Tue, 4 Jun 2024, Ramiro Polla wrote:
> > On Thu, May 30, 2024 at 11:36 PM Ramiro Polla
> > wrote:
> >>
> >> ---
> >> doc/ffplay.texi | 2 ++
> >> fftools/ffplay.c | 6 +-
> >> 2 files changed, 7 insertions(+), 1 deletion(-)
> >
Rémi Denis-Courmont:
> ---
> libavcodec/mpegvideo.c | 40 +---
> 1 file changed, 9 insertions(+), 31 deletions(-)
>
> diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
> index 7af823b8bd..810888fc47 100644
> --- a/libavcodec/mpegvideo.c
> +++ b/libav
Rémi Denis-Courmont:
> Note that optimised implementations of these functions will be taken
> into actual use only if MpegEncContext.dct_unquantize_h263_{inter,intra}
> are *not* overloaded by existing optimisations.
> ---
> libavcodec/h263dsp.c | 25 +
> libavcodec/h263dsp
Andreas Rheinhardt:
> Besides being write only it had the wrong type:
> An uint8_t is definitely not enough to store the size
> of these buffers.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> tests/api/api-band-test.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/tests/api/api-band-
On Mon, Jun 10, 2024 at 08:52:08PM -0400, Sean McGovern wrote:
[...]
> Are there any real concerns about the Alpha removal itself?
> People still wanting to use FFmpeg for hardware that old can stick
> with 7.0 (and fork it if they like -- that's the beauty of FOSS).
Loosing security support, soun
Deprecate the option 'draw_bars' in favor of the new option
'signal_loss_action',
which controls the behavior when the input signal is not available
(including the behavior previously available through draw_bars).
The default behavior remains unchanged to be backwards compatible.
The new option is
On Mon, Jun 10, 2024 at 03:56:46PM +0300, Rémi Denis-Courmont wrote:
>
>
> Le 10 juin 2024 14:57:29 GMT+03:00, Michael Niedermayer
> a écrit :
> >Also we have alpha fate clients:
> >https://fate.ffmpeg.org/?query=subarch:alpha%2F%2F
>
> Are there? I only see Ubuntu 22.04 builds which must be c
1 - 100 of 108 matches
Mail list logo
