"J. Dekker" writes:
> When collecting performance information from checkasm it is common
> to parse the output for use in graphs to compare vs different
> architectures.
>
> Signed-off-by: J. Dekker
> ---
> tests/checkasm/checkasm.c | 22 --
> 1 file changed, 20 insertions(+
The check is for color space, not range.
---
libavfilter/formats.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index eabc3ec946..2b570b466e 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -977,7 +977,7 @@ int f
On Tue, 27 Aug 2024 21:47:59 +0300 Rémi Denis-Courmont wrote:
> Le 27 août 2024 17:12:03 GMT+03:00, Niklas Haas a écrit :
> >> > +.irp x, \vregs
> >> > +vmax.vx \x, \x, zero
> >> > +.endr
> >> > +vsetvli zero, zero, e8, \lmul, ta, ma
> >> > +.irp x, \vr
On Tue, Aug 20, 2024 at 09:50:52AM +0200, Michael Niedermayer wrote:
> Fixes: Use of uninitialized value
> Fixes:
> 71072/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-4835252046987264
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/p
From: Fei Wang
Implement load/save loop filter and segment parameters defined in
section 7.20 and 7.21 in spec for show_existing_frame frames.
Fixes ticket #11151.
Signed-off-by: Fei Wang
---
libavcodec/cbs_av1.h | 5
libavcodec/cbs_av1_syntax_template.c | 36 +++
On Thu, Aug 22, 2024 at 1:24 AM Ramiro Polla wrote:
> MpegEncContext already has a BlockDSPContext, so we don't need another
> one for DNXHDEncContext (which has an MpegEncContext).
> ---
> libavcodec/dnxhdenc.c | 10 +-
> libavcodec/dnxhdenc.h | 1 -
> 2 files changed, 5 insertions(+),
On Thu, Aug 22, 2024 at 3:05 AM Ramiro Polla wrote:
> It's safe to assume that LOCAL_ALIGNED_16 does indeed align. Otherwise
> we would have many more problems...
>
> This assert was added in f8188626 all the way back in 2003.
> ---
> libavcodec/x86/mpegvideoenc_template.c | 2 --
> 1 file change
On Thu, Aug 22, 2024 at 1:24 AM Ramiro Polla wrote:
> The x86 optimized dct_quantize only calculates the last nonzero
> coefficient correctly if the zigzag scan order is used. For the
> alternate scan order, this value is incorrect.
>
> To work around this, the dct_unquantize functions process the
On Wed, 28 Aug 2024 13:30:02 +0200 Niklas Haas wrote:
> On Tue, 27 Aug 2024 21:47:59 +0300 Rémi Denis-Courmont
> wrote:
> > Le 27 août 2024 17:12:03 GMT+03:00, Niklas Haas a écrit :
> > >> > +.irp x, \vregs
> > >> > +vmax.vx \x, \x, zero
> > >> > +.endr
> > >> > +
Following up on this: attached a (final, in our view) v5. Changes over v3:
- cleanup and align to psnr filter
- add metadata
- add xpsnr tests for yuv and rgb
Christian
Von: Helmrich, Christian
Gesendet: Montag, 26. August 2024 19:41
An: FFmpeg development dis
Hi all
Everyone in the spam fighters guilde have just received TICKET_ADMIN powers
this should allow you to delete attachments and comments, i believe
Iam not sure why this permission wasnt enabled before.
Please use this power with care, delete cannot be undone
If someone abuses this power, con
Quoting Marvin Scholz (2024-08-28 03:08:39)
> In one of the failure paths of av_opt_get_array, the ret variable
> was accidentally declared again, shadowing the outer one and once when
> jumping to the fail label would return the still uninitialised outer
> one.
>
> To fix this simply remove the l
Quoting Frank Plowman (2024-08-25 13:50:41)
> These assertions are not violated, even by illegal bitstreams.
I don't follow this argument, not being violated by any reachable
runtime path is exactly how a correctly written assert should behave.
--
Anton Khirnov
__
From: Zhao Zhili
---
libavcodec/aarch64/h26x/dsp.h | 6 +++-
libavcodec/aarch64/h26x/sao_neon.S| 44 +--
libavcodec/aarch64/hevcdsp_init_aarch64.c | 2 +-
libavcodec/aarch64/vvc/Makefile | 5 +--
libavcodec/aarch64/vvc/dsp_init.c | 6
From: Zhao Zhili
So vvc can reuse the implementation.
---
libavcodec/aarch64/Makefile | 2 +-
libavcodec/aarch64/h26x/dsp.h | 36 +++
.../{hevcdsp_sao_neon.S => h26x/sao_neon.S} | 2 +-
libavcodec/aarch64/hevcdsp_init_aarch64.c | 9 +
On Thu, Aug 15, 2024 at 12:37:02AM +0200, Michael Niedermayer wrote:
> Text was stolen from the linux kernel
> This is thus identical to the kernel just a different more compact format.
> I am very happy also to switch the file entirely to the format of the linux
> kernel maintainer list
> if peop
On 28/08/2024 16:13, Anton Khirnov wrote:
> Quoting Frank Plowman (2024-08-25 13:50:41)
>> These assertions are not violated, even by illegal bitstreams.
>
> I don't follow this argument, not being violated by any reachable
> runtime path is exactly how a correctly written assert should behave.
>
Text was stolen from the linux kernel
This is thus identical to the kernel just a different more compact format.
I am very happy also to switch the file entirely to the format of the linux
kernel maintainer list
if people prefer
This allows specifying a more specific mailing list, if a specific a
Signed-off-by: Michael Niedermayer
---
MAINTAINERS | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 619cc50d8fa..8917b3be0f5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -40,8 +40,8 @@ Miscellaneous Areas
===
document
Text was stolen from the linux kernel
This is thus identical to the kernel just a different more compact format.
I am very happy also to switch the file entirely to the format of the linux
kernel maintainer list
if people prefer
This allows specifying a webpage for an area
Signed-off-by: Michael
Signed-off-by: Michael Niedermayer
---
MAINTAINERS | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 91075840d79..cfae4912909 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -53,13 +53,13 @@ Communication
=
website
Text was stolen from the linux kernel
This is thus identical to the kernel just a different more compact format.
I am very happy also to switch the file entirely to the format of the linux
kernel maintainer list
if people prefer
This allows specifying a bug tracker. It would allow a maintainer to
Text was stolen from the linux kernel
This is thus identical to the kernel just a different more compact format.
I am very happy also to switch the file entirely to the format of the linux
kernel maintainer list
if people prefer
This allows specifying more details than what fits on a single line
Signed-off-by: Michael Niedermayer
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8dd3cb4c04d..ed2150d519c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -59,7 +59,7 @@ Communication
=
website
Signed-off-by: Michael Niedermayer
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c7cb20f5e08..f1cb27a512b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -61,8 +61,8 @@ API tests Ludmila Glinskih
Text was stolen from the linux kernel
This is thus identical to the kernel just a different more compact format.
I am very happy also to switch the file entirely to the format of the linux
kernel maintainer list
if people prefer
This allows specifying a git repository for an area
Signed-off-by:
Signed-off-by: Michael Niedermayer
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f1cb27a512b..feafcc957f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -65,7 +65,7 @@ website (S:
https://git.ffm
Ping.
Thanks
> On 26 Aug 2024, at 20:51, Yigithan Yigit wrote:
>
> ---
> libavfilter/vf_libvmaf.c | 328 ++-
> 1 file changed, 326 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_libvmaf.c b/libavfilter/vf_libvmaf.c
> index f655092b20..e6707af
On Wed, Aug 28, 2024 at 10:13 AM Michael Niedermayer
wrote:
>
> Text was stolen from the linux kernel
> This is thus identical to the kernel just a different more compact format.
> I am very happy also to switch the file entirely to the format of the linux
> kernel maintainer list
> if people pre
On Wed, Aug 28, 2024, 07:56 Rémi Denis-Courmont wrote:
>
>
> Le 28 août 2024 06:29:30 GMT+03:00, Kacper Michajlow
> a écrit :
> >On Tue, 27 Aug 2024 at 09:51, Rémi Denis-Courmont
> wrote:
> >>
> >>
> >>
> >> Le 27 août 2024 10:00:08 GMT+03:00, Marton Balint a
> écrit :
> >>
> >> >IMHO the patc
Quoting Marth64 (2024-07-28 09:34:39)
> DVDs naturally consist of segmented MPEG-PS blobs within a VOB
> (i.e. VOBs are not linear). NAV packs set the segment boundaries.
> When switching between segments, discontinuities occur and thus
> the subdemuxer needs to be reset. The current approach to ma
This will be useful for scenarios where we need certain frame properties
set by the decoder before get_buffer2() is called, like side data.
Signed-off-by: James Almer
---
libavcodec/decode.c| 11 +++
libavcodec/progressframe.h | 16 ++--
2 files changed, 21 insertions
On 8/27/2024 12:04 PM, Anton Khirnov wrote:
One potential point of discussion is that the caller may want to know
the view ID in its get_buffer2() callback (this is actually used in the
ffmpeg CLI code). One potential option is attaching the view ID side
data before calling get_buffer2(), but tha
NOTE: currently the tests for rgb24toyv12 fail for x86 since the c and
mmxext implementations differ (the mmxext version averages four
rgb pixels before performing the chroma calculations).
---
tests/checkasm/sw_rgb.c | 89 +
1 file changed, 89 i
The current code subsamples by dropping 3/4 pixels to calculate the
chroma components. This commit calculates the average of 4 rgb pixels
before calculating the chroma components, putting it in line with the
mmxext implementation.
---
libswscale/rgb2rgb_template.c | 88
The mmxext implementation is slower than the C version.
rgb24toyv12_16_200_c:14812.6 ( 1.00x)
rgb24toyv12_16_200_mmxext: 17400.4 ( 0.85x)
rgb24toyv12_128_60_c:35616.9 ( 1.00x)
rgb24toyv12_128_60_mmxext:
A55 A76
rgb24toyv12_16_200_c: 36658.8 17319.2
rgb24toyv12_16_200_neon: 12765.8 ( 2.87x) 6036.0 ( 2.87x)
rgb24toyv12_128_60_c: 83329.5 39901.2
rgb24toyv12_128_60_neon: 28059.8 ( 2.97x) 14288.2 ( 2.79x)
rgb24toyv12_512_16_c:
On Wed, 28 Aug 2024, Ramiro Polla wrote:
NOTE: currently the tests for rgb24toyv12 fail for x86 since the c and
mmxext implementations differ (the mmxext version averages four
rgb pixels before performing the chroma calculations).
---
tests/checkasm/sw_rgb.c | 89 ++
On Wed, Aug 28, 2024 at 11:13 PM Martin Storsjö wrote:
> On Wed, 28 Aug 2024, Ramiro Polla wrote:
>
> > NOTE: currently the tests for rgb24toyv12 fail for x86 since the c and
> > mmxext implementations differ (the mmxext version averages four
> > rgb pixels before performing the chroma c
On Wed, 28 Aug 2024, Ramiro Polla wrote:
A55 A76
rgb24toyv12_16_200_c: 36658.8 17319.2
rgb24toyv12_16_200_neon: 12765.8 ( 2.87x) 6036.0 ( 2.87x)
rgb24toyv12_128_60_c: 83329.5 39901.2
rgb24toyv12_128_60_neon: 28059.8 ( 2.9
On Wed, Aug 28, 2024 at 11:23 PM Martin Storsjö wrote:
> On Wed, 28 Aug 2024, Ramiro Polla wrote:
> > +2:
> > +// load first line
> > +ld3 {v16.8b, v17.8b, v18.8b}, [x0], #24
> > +ld3 {v19.8b, v20.8b, v21.8b}, [x0], #24
>
> Hmm, can't we do just one
On Wed, Aug 28, 2024 at 10:43 PM Ramiro Polla wrote:
>
> The mmxext implementation is slower than the C version.
>
> rgb24toyv12_16_200_c:14812.6 ( 1.00x)
> rgb24toyv12_16_200_mmxext: 17400.4 ( 0.85x)
> rgb24toyv12_128_60_c:
42 matches
Mail list logo
