> -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] area changed: scdet filter
>
> On Sun, Jun 02, 2024 at 11:17:29PM +0300, radu.taraib...@g
The SEI handling of libx265 is buggy and can easily lead
to memory corruption: It reuses certain buffers, but when
reusing them it presumes that it is enough for these buffers
to exist and does not check whether they are actually large
enough to hold what is intended to be stored in them.*
Our use
tis 2024-06-11 klockan 09:42 +0200 skrev Andreas Rheinhardt:
> The SEI handling of libx265 is buggy and can easily lead
> to memory corruption: It reuses certain buffers, but when
> reusing them it presumes that it is enough for these buffers
> to exist and does not check whether they are actually
Tomas Härdin:
> tis 2024-06-11 klockan 09:42 +0200 skrev Andreas Rheinhardt:
>> The SEI handling of libx265 is buggy and can easily lead
>> to memory corruption: It reuses certain buffers, but when
>> reusing them it presumes that it is enough for these buffers
>> to exist and does not check whethe
tis 2024-06-11 klockan 10:05 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2024-06-11 klockan 09:42 +0200 skrev Andreas Rheinhardt:
> > > The SEI handling of libx265 is buggy and can easily lead
> > > to memory corruption: It reuses certain buffers, but when
> > > reusing them it presumes
Tomas Härdin:
> tis 2024-06-11 klockan 10:05 +0200 skrev Andreas Rheinhardt:
>> Tomas Härdin:
>>> tis 2024-06-11 klockan 09:42 +0200 skrev Andreas Rheinhardt:
The SEI handling of libx265 is buggy and can easily lead
to memory corruption: It reuses certain buffers, but when
reusing th
tis 2024-06-11 klockan 10:16 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2024-06-11 klockan 10:05 +0200 skrev Andreas Rheinhardt:
> > > Tomas Härdin:
> > > > tis 2024-06-11 klockan 09:42 +0200 skrev Andreas Rheinhardt:
> > > > > The SEI handling of libx265 is buggy and can easily lead
>
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
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 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
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-
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
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
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(-)
> >
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
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
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
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 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
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
> -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
---
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
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:
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: 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:
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
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
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
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
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
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 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 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
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
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: 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
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
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
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
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
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(+),
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
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
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
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
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, 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
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
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
> > >
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 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
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 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 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 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
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 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
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
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
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
> 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
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/
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.
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
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
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
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
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
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
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
> 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.
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
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/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
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
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
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
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
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
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 +++---
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
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
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
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
>
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
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
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
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: 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: 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
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
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
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 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,
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(
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
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
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
---
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
1 - 100 of 108 matches
Mail list logo
