Hi Marton,
On Thu, Jan 16, 2025 at 8:52 PM Marton Balint wrote:
> On Tue, 7 Jan 2025, Marton Balint wrote:
> > Fixes corruption with:
> >
> > ffmpeg -t 1 -filter_complex
> > "sine=f=21,showwaves=scale=cbrt:mode=line:colors=white:draw=full" -c:v
> > mpeg2video -non_linear_quant 1 -qmin 1 -qmax 1
Hi Marton,
On Tue, Jan 7, 2025 at 12:09 AM Marton Balint wrote:
>
> The comments supposed to track the possible value of the qmat and qmat16
> matrices, but they were not updated properly in the long history of the
> mpegvideo encoder. Also they wrongly assumed the usage of built-in quantizer
> m
On Tue, Dec 17, 2024 at 4:02 AM Leo Izen wrote:
> On 12/16/24 5:50 PM, Michael Niedermayer wrote:
> >
> > (c): implement enough of zlib ourselfs, so it can encode to a valid output
>
> A reimplementation of zlib that does nothing except for fixing FATE
> failures that shouldn't be failing anyway s
On Sat, Dec 14, 2024 at 6:39 PM Alexander Strasser via ffmpeg-devel
wrote:
> On 2024-12-14 11:09 +0100, Anton Khirnov wrote:
> > Quoting Alexander Strasser via ffmpeg-devel (2024-12-01 21:13:56)
> > > This is a fixed up version of the series I sent before.
IMO there would be no need to revert and
On Thu, Dec 12, 2024 at 1:28 PM Martin Storsjö wrote:
>
> This fixes occasional failed tests, if doing "make fate" without a
> regular "make" or "make all" inbetween.
> ---
> tests/fate/audio.mak | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tests/fate/audio.mak b
On Tue, Dec 3, 2024 at 3:35 AM Michael Niedermayer
wrote:
> On Sun, Dec 01, 2024 at 07:20:06PM +0100, Ramiro Polla wrote:
> > There is an issue with the constants used in YUV to YUV range conversion,
> > where the upper bound is not respected when converting to mpeg range.
&g
Hi Michael,
On Mon, Dec 2, 2024 at 1:33 AM Michael Niedermayer
wrote:
> On Sat, Sep 28, 2024 at 02:01:33AM +0200, Michael Niedermayer wrote:
> > On Wed, Sep 25, 2024 at 03:16:30PM +0200, Ramiro Polla wrote:
> > > On Tue, Sep 24, 2024 at 3:35 PM Michael Niedermayer
> >
aarch64 A55:
chrRangeFromJpeg16_1920_c:32684.2
chrRangeFromJpeg16_1920_neon: 8431.2 (3.88x)
chrRangeToJpeg16_1920_c: 24996.8
chrRangeToJpeg16_1920_neon:9395.0 (2.66x)
lumRangeFromJpeg16_1920_c:17305.2
lumRangeFromJpeg16_1920_neon: 4586.5 (3.77x)
lumRangeToJpeg16_1920_c: 2114
chrRangeFromJpeg16_1920_c:3153.9
chrRangeFromJpeg16_1920_sse4: 1770.0 (1.78x)
chrRangeFromJpeg16_1920_avx2: 891.5 (3.54x)
chrRangeToJpeg16_1920_c: 3165.0
chrRangeToJpeg16_1920_sse4: 1953.2 (1.62x)
chrRangeToJpeg16_1920_avx2:973.0 (3.25x)
lumRangeFromJpeg16_1920_c:1298.5
lumRange
aarch64 A55:
chrRangeFromJpeg8_1920_c:28835.2 (1.00x)
chrRangeFromJpeg8_1920_neon: 5313.9 (5.43x) 5308.4 (5.43x)
chrRangeToJpeg8_1920_c: 23074.7 (1.00x)
chrRangeToJpeg8_1920_neon:5551.3 (4.16x) 5549.2 (4.16x)
lumRangeFromJpeg8_1920_c:15389.7 (1.00x)
lumRangeFromJpeg8_1920_neon:
chrRangeFromJpeg8_1920_c:2127.4 (1.00x)
chrRangeFromJpeg8_1920_sse2: 816.0 (2.61x) 813.5 (2.62x)
chrRangeFromJpeg8_1920_avx2: 408.9 (5.20x) 405.4 (5.25x)
chrRangeToJpeg8_1920_c: 3166.9 (1.00x)
chrRangeToJpeg8_1920_sse2:815.0 (3.89x) 815.0 (3.89x)
chrRangeToJpeg8_1920_avx2:404.
aarch64 A55:
chrRangeFromJpeg8_1920_c:28836.2 (1.00x)
chrRangeFromJpeg8_1920_neon: 5312.6 (5.43x) 5313.9 (5.43x)
chrRangeToJpeg8_1920_c: 44196.2 (1.00x)
chrRangeToJpeg8_1920_neon:6034.6 (7.32x) 5551.3 (7.96x)
lumRangeFromJpeg8_1920_c:15388.5 (1.00x)
lumRangeFromJpeg8_1920_neon:
For bit depths <= 14, the result is saturated to 15 bits.
For bit depths > 14, the result is saturated to 19 bits.
x86_64:
chrRangeFromJpeg8_1920_c:2126.5 2127.4 (1.00x)
chrRangeFromJpeg16_1920_c: 2331.4 2325.2 (1.00x)
chrRangeToJpeg8_1920_c: 3163.0 3166.9 (1.00x)
chrRangeToJpe
---
tests/checkasm/sw_range_convert.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tests/checkasm/sw_range_convert.c
b/tests/checkasm/sw_range_convert.c
index bf14209987..ba576ff08c 100644
--- a/tests/checkasm/sw_range_convert.c
+++ b/tests/checkasm/sw_range_convert.c
@@ -6
1334.0 (0.98x)
lumRangeToJpeg16_1920_c: 6005.2 5946.2 (1.01x)
Ramiro Polla (8):
checkasm/sw_range_convert: test negative input values
swscale/range_convert: saturate output instead of limiting input
swscale/aarch64/range_convert: saturate output instead of limiting
input
swscale
On Tue, Nov 26, 2024 at 11:56 AM Anton Khirnov wrote:
> Quoting Ramiro Polla (2024-10-22 11:25:58)
> > On Mon, Oct 21, 2024 at 1:41 AM Michael Niedermayer
> > wrote:
> > > On Thu, Oct 17, 2024 at 01:00:12PM +0200, Ramiro Polla wrote:
> > > > Consider APPx fie
A55 A76
chrRangeFromJpeg16_1920_c: 28840.6 6323.5
chrRangeFromJpeg16_1920_neon: 8436.5 ( 3.42x) 3365.2 ( 1.88x)
chrRangeToJpeg16_1920_c: 23075.1 9195.6
chrRangeToJpeg16_1920_neon: 9393.6 ( 2.46x) 4084.5 ( 2.25x)
l
A55:
chrRangeFromJpeg8_1920_c:28833.8 ( 1.00x)
chrRangeFromJpeg8_1920_neon: 5309.9 ( 5.43x) 5313.1 ( 5.43x)
chrRangeToJpeg8_1920_c: 23070.6 ( 1.00x)
chrRangeToJpeg8_1920_neon:5550.8 ( 4.16x) 5550.8 ( 4.16x)
lumRangeFromJpeg8_1920_c:15388.1 ( 1.00x)
lumRangeFromJpeg8_1920_neon:
chrRangeFromJpeg16_1920_c: 5809.1
chrRangeFromJpeg16_1920_sse2: 3909.5 ( 1.49x)
chrRangeFromJpeg16_1920_avx2: 1985.3 ( 2.93x)
chrRangeToJpeg16_1920_c: 9261.5
chrRangeToJpeg16_1920_sse2:6053.2 ( 1.53x)
chrRangeToJpeg16_1920_sse4:4493.6 ( 2.06x)
chrRangeToJpeg16_1920_avx2:2405
aarch64 A55:
chrRangeFromJpeg8_1920_c: 28839.3 ( 1.00x)
chrRangeFromJpeg8_1920_neon: 5312.2 ( 5.43x) 5309.9 ( 5.43x)
chrRangeToJpeg8_1920_c: 44196.1 ( 1.00x)
chrRangeToJpeg8_1920_neon: 6035.9 ( 7.32x) 5550.8 ( 7.96x)
lumRangeFromJpeg8_1920_c: 15384.3 ( 1.00x)
lumRangeFromJpeg8
chrRangeFromJpeg8_1920_c: 5804.5 ( 1.00x)
chrRangeFromJpeg8_1920_sse2: 1960.2 ( 2.96x) 1955.2 ( 2.97x)
chrRangeFromJpeg8_1920_avx2: 996.1 ( 5.83x) 988.9 ( 5.87x)
chrRangeToJpeg8_1920_c: 9388.6 ( 1.00x)
chrRangeToJpeg8_1920_sse2:1963.7 ( 4.78x) 1949.9 ( 4.81x)
chrRangeToJpeg8_19
For bit depths <= 14, the result is saturated to 15 bits.
For bit depths > 14, the result is saturated to 19 bits.
x86_64:
chrRangeFromJpeg8_1920_c:5827.4 5804.5 ( 1.00x)
chrRangeFromJpeg16_1920_c: 5793.2 5792.8 ( 1.00x)
chrRangeToJpeg8_1920_c: 11726.2 9388.6 ( 1.25x)
chrRangeTo
in SwsInternal to avoid holes;
Ramiro Polla (7):
swscale/range_convert: saturate output instead of limiting input
swscale/aarch64/range_convert: saturate output instead of limiting
input
swscale/range_convert: fix mpeg ranges in yuv range conversion for
non-8-bit pixel formats
swscale/
On Sun, Oct 20, 2024 at 8:41 PM Michael Niedermayer
wrote:
> On Thu, Oct 17, 2024 at 01:13:39PM +0200, Ramiro Polla wrote:
> > On Sun, Sep 29, 2024 at 5:38 PM Ramiro Polla wrote:
> > >
> > > ---
> > > The new owdenoise-scenwin-jpeg.raw reference file i
On Mon, Oct 21, 2024 at 1:41 AM Michael Niedermayer
wrote:
> On Thu, Oct 17, 2024 at 01:00:12PM +0200, Ramiro Polla wrote:
> > Consider APPx fields that are too short to contain an id field (32-bit)
> > as stubs, and silently ignore them.
> >
> > This has been seen in
On Fri, Sep 27, 2024 at 2:52 PM Ramiro Polla wrote:
[...]
> Ramiro Polla (16):
> swscale/range_convert: call arch-specific init functions from main
> init function
> swscale/range_convert: drop redundant conditionals from arch-specific
> init functions
> sws
On Sun, Sep 29, 2024 at 1:32 PM asivery via ffmpeg-devel
wrote:
> Pinging the patch.
> I've merged the fate test case patch into the functionality one, and rebased
> onto the current master.
> Here are the two sample files required by the FATE test:
> https://0x0.st/Xaw2.aea/boxboy333_house_music
On Sun, Sep 29, 2024 at 5:38 PM Ramiro Polla wrote:
>
> ---
> The new owdenoise-scenwin-jpeg.raw reference file is available at
> https://0x0.st/XguT.raw
>
> tests/fate/filter-video.mak | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/te
On Mon, Sep 9, 2024 at 12:58 PM Ramiro Polla wrote:
>
> The acaps variable was used outside of the #if DSHOWDEBUG block with
> a1c4929f, but it is no longer used outside of the block since f125c504.
> ---
> libavdevice/dshow.c | 2 +-
> 1 file changed, 1 insertion(+), 1 de
Consider APPx fields that are too short to contain an id field (32-bit)
as stubs, and silently ignore them.
This has been seen in the MJPEG output from some webcams (such as the
Logitech C270 and C920) and the JPEG images embedded in DNG images
from the Pentax K-1 camera.
---
libavcodec/mjpegdec.
The loop to skip the remaining bytes was off by one for all markers
except for Adob.
This patch uses post-decrement instead of pre-decrement in the while
loop to make the len value easier to understand, and updates the len
value to reflect this change for the Adob marker.
---
libavcodec/mjpegdec.
Hi,
On Thu, Oct 17, 2024 at 8:38 AM Cynthia via ffmpeg-devel
wrote:
> From d7863bab8e1028b6cfb3ce848e216e86ff00eca0 Mon Sep 17 00:00:00 2001
> From: cynthia2006
> Date: Tue, 28 May 2024 22:03:50 +0530
> Subject: [PATCH] lavc/mjpegdec: add option for ignorning malformed APPx
> segments
> X-Unsen
On Mon, Oct 14, 2024 at 10:57 PM Michael Niedermayer
wrote:
> On Sun, Sep 29, 2024 at 08:36:29PM +0200, Ramiro Polla wrote:
> > FATE results differ when using the original zlib and zlib-ng.
> >
> > Since we don't need to test the result from zlib itself, this commit
&
On Sat, Oct 5, 2024 at 10:14 PM Niklas Haas wrote:
>
> From: Niklas Haas
>
> And give it const parameters while we're at it, because this function does
> not mutate its parameters.
Not entirely correct since it still modifies srcStride. After fixing
this it should then be possible to remove the
On Sat, Oct 5, 2024 at 9:25 PM Niklas Haas wrote:
> From: Niklas Haas
>
> In the process of refactoring the signature to be more generically useful,
> this fixes an 11-year-old bug where the functions (incorrectly) did nothing
> when the stride was negative, since the stride was being used as the
Hi Anton,
On Mon, Sep 30, 2024 at 9:19 AM Anton Khirnov wrote:
> Quoting Ramiro Polla (2024-09-29 17:38:55)
> > ---
> > The new owdenoise-scenwin-jpeg.raw reference file is available at
> > https://0x0.st/XguT.raw
>
> Changing an existing reference file would br
On Mon, Sep 30, 2024 at 12:01 AM James Almer wrote:
> On 9/29/2024 3:36 PM, Ramiro Polla wrote:
> > This allows setting the compression level used by zlib.
> > ---
> > libavcodec/flashsvenc.c | 10 --
> > tests/ref/vsynth/vsynth1-flashsv |
On Sun, Sep 29, 2024 at 11:01 PM James Almer wrote:
> On 9/29/2024 3:07 PM, Ramiro Polla wrote:
> > FATE results differ when using the original zlib and zlib-ng.
> >
> > Since we don't need to test the result from zlib itself, this commit
> > disables compressio
This allows setting the compression level used by zlib.
---
libavcodec/flashsvenc.c | 10 --
tests/ref/vsynth/vsynth1-flashsv | 2 +-
tests/ref/vsynth/vsynth2-flashsv | 4 ++--
tests/ref/vsynth/vsynth3-flashsv | 2 +-
tests/ref/vsynth/vsynth_lena-flashsv | 2 +-
FATE results differ when using the original zlib and zlib-ng.
Since we don't need to test the result from zlib itself, this commit
disables compression on tests for zlib-based codecs, which ends up
giving the same results with both libraries.
---
tests/fate/cover-art.mak | 6 +--
FATE results differ when using the original zlib and zlib-ng.
Since we don't need to test the result from zlib itself, this commit
disables compression on tests for zlib-based codecs, which ends up
giving the same results with both libraries.
---
tests/fate/cover-art.mak | 6 +--
This allows setting the compression level used by zlib.
---
libavcodec/flashsvenc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/flashsvenc.c b/libavcodec/flashsvenc.c
index 5cf0602f5d..f650e517d0 100644
--- a/libavcodec/flashsvenc.c
+++ b/libavcodec/fl
---
The new owdenoise-scenwin-jpeg.raw reference file is available at
https://0x0.st/XguT.raw
tests/fate/filter-video.mak | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 5b8a294afd..0f351ea404 100644
--- a/te
On Sat, Sep 28, 2024 at 11:41 PM Michael Niedermayer
wrote:
> On Fri, Sep 27, 2024 at 02:52:37PM +0200, Ramiro Polla wrote:
> > There is an issue with the constants used in YUV to YUV range conversion,
> > where the upper bound is not respected when converting to mpeg range.
&g
Hi Christophe,
On Sat, Sep 28, 2024 at 3:21 PM Christophe Gisquet
wrote:
> Le lun. 23 sept. 2024 à 16:19, Ramiro Polla a écrit :
> > For bit depths <= 14, amax is 16-bit and offset is 32-bit.
> > For bit depths > 14, amax is 32-bit and offset is 64-bit.
>
&g
chrRangeFromJpeg8_1920_c: 5804.5 ( 1.00x)
chrRangeFromJpeg8_1920_sse2: 1960.2 ( 2.96x) 1955.2 ( 2.97x)
chrRangeFromJpeg8_1920_avx2: 996.1 ( 5.83x) 988.9 ( 5.87x)
chrRangeToJpeg8_1920_c: 9388.6 ( 1.00x)
chrRangeToJpeg8_1920_sse2:1963.7 ( 4.78x) 1949.9 ( 4.81x)
chrRangeToJpeg8_19
These conditions are already checked for in the main init function.
---
libswscale/aarch64/swscale.c | 2 --
libswscale/loongarch/swscale_init_loongarch.c | 4
libswscale/riscv/swscale.c| 3 +--
libswscale/swscale.c | 2 +-
libswsc
chrRangeFromJpeg16_1920_c: 5809.1
chrRangeFromJpeg16_1920_sse2: 3909.5 ( 1.49x)
chrRangeFromJpeg16_1920_avx2: 1985.3 ( 2.93x)
chrRangeToJpeg16_1920_c: 9261.5
chrRangeToJpeg16_1920_sse2:6053.2 ( 1.53x)
chrRangeToJpeg16_1920_sse4:4493.6 ( 2.06x)
chrRangeToJpeg16_1920_avx2:2405
aarch64 A55:
chrRangeFromJpeg8_1920_c: 28839.3 ( 1.00x)
chrRangeFromJpeg8_1920_neon: 5312.2 ( 5.43x) 5309.9 ( 5.43x)
chrRangeToJpeg8_1920_c: 44196.1 ( 1.00x)
chrRangeToJpeg8_1920_neon: 6035.9 ( 7.32x) 5550.8 ( 7.96x)
lumRangeFromJpeg8_1920_c: 15384.3 ( 1.00x)
lumRangeFromJpeg8
---
tests/checkasm/sw_range_convert.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/checkasm/sw_range_convert.c
b/tests/checkasm/sw_range_convert.c
index df27b6c81e..e97388d14a 100644
--- a/tests/checkasm/sw_range_convert.c
+++ b/tests/checkasm/sw_range_convert.c
@@ -62,6 +62,7 @@ s
There is an issue with the constants used in YUV to YUV range conversion,
where the upper bound is not respected when converting to mpeg range.
With this commit, the constants are calculated at runtime, depending on
the bit depth. This approach also allows us to more easily understand how
the cons
A55:
chrRangeFromJpeg8_1920_c:28833.8 ( 1.00x)
chrRangeFromJpeg8_1920_neon: 5309.9 ( 5.43x) 5313.1 ( 5.43x)
chrRangeToJpeg8_1920_c: 23070.6 ( 1.00x)
chrRangeToJpeg8_1920_neon:5550.8 ( 4.16x) 5550.8 ( 4.16x)
lumRangeFromJpeg8_1920_c:15388.1 ( 1.00x)
lumRangeFromJpeg8_1920_neon:
This commit also reduces the number of times ff_sws_init_scale() gets
called (only once per bit depth), and the number of times randomize_buffers()
gets called (only if the function must be checked).
Benchmarks are only performed on bit depths 8 and 16 (since they are
different functions, and not
We are already setting the range, so we can use regular YUV pixel
formats instead of YUVJ.
---
tests/checkasm/sw_range_convert.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/checkasm/sw_range_convert.c
b/tests/checkasm/sw_range_convert.c
index 1f04988097..8c8a
---
libswscale/loongarch/swscale_init_loongarch.c | 32 +--
libswscale/swscale.c | 8 ++---
libswscale/x86/swscale.c | 12 +++
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/libswscale/loongarch/swscale_init_loong
;
- Add comments when disabling code with "#if 0";
Ramiro Polla (16):
swscale/range_convert: call arch-specific init functions from main
init function
swscale/range_convert: drop redundant conditionals from arch-specific
init functions
swscale/range_convert: indent after previ
---
tests/checkasm/sw_gbrp.c | 15 ---
tests/checkasm/sw_range_convert.c | 8 ++--
tests/checkasm/sw_scale.c | 11 ---
3 files changed, 10 insertions(+), 24 deletions(-)
diff --git a/tests/checkasm/sw_gbrp.c b/tests/checkasm/sw_gbrp.c
index d843730f3e..74
For bit depths <= 14, the result is saturated to 15 bits.
For bit depths > 14, the result is saturated to 19 bits.
x86_64:
chrRangeFromJpeg8_1920_c:5827.4 5804.5 ( 1.00x)
chrRangeFromJpeg16_1920_c: 5793.2 5792.8 ( 1.00x)
chrRangeToJpeg8_1920_c: 11726.2 9388.6 ( 1.25x)
chrRangeTo
A55 A76
chrRangeFromJpeg16_1920_c: 28840.6 6323.5
chrRangeFromJpeg16_1920_neon: 8436.5 ( 3.42x) 3365.2 ( 1.88x)
chrRangeToJpeg16_1920_c: 23075.1 9195.6
chrRangeToJpeg16_1920_neon: 9393.6 ( 2.46x) 4084.5 ( 2.25x)
l
Reduce input sizes to 8 (to test that the function works with widths
smaller than the vector length) and 1920 (raising the largest input
size to improve benchmark results).
---
tests/checkasm/sw_range_convert.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/check
---
tests/checkasm/sw_range_convert.c | 48 +++
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/tests/checkasm/sw_range_convert.c
b/tests/checkasm/sw_range_convert.c
index e3e5096729..01c4549e53 100644
--- a/tests/checkasm/sw_range_convert.c
+++ b/tests
This commit also fixes the issue that the call to ff_sws_init_range_convert()
from sws_init_swscale() was not setting up the arch-specific optimizations.
---
libswscale/aarch64/swscale.c | 5 -
libswscale/loongarch/swscale_init_loongarch.c | 1 -
libswscale/riscv/swscale.c
On Tue, Sep 24, 2024 at 3:35 PM Michael Niedermayer
wrote:
> On Mon, Sep 23, 2024 at 12:42:22AM +0200, Ramiro Polla wrote:
> > Hi,
> >
> > On Mon, Sep 23, 2024 at 12:04 AM Michael Niedermayer
> > wrote:
> > >
> > > Fixes: out of array
On Tue, Sep 24, 2024 at 6:39 PM Rémi Denis-Courmont wrote:
> Le maanantaina 23. syyskuuta 2024, 15.40.14 EEST Ramiro Polla a écrit :
> > chrRangeFromJpeg8_1920_c: 3874.8 ( 1.00x)
> > chrRangeFromJpeg8_1920_sse2:
On Wed, Sep 25, 2024 at 7:24 AM Derek Buitenhuis
wrote:
> On 9/23/2024 1:40 PM, Ramiro Polla wrote:
> > {
> > +#if 0
> > int cpu_flags = av_get_cpu_flags();
>
> Are these '#if 0' throughout this patch intended?
Yes, some simd code is disabled bec
On Tue, Sep 24, 2024 at 2:24 PM Michael Niedermayer
wrote:
> On Mon, Sep 23, 2024 at 02:40:13PM +0200, Ramiro Polla wrote:
> > There is an issue with the constants used in YUV to YUV range conversion,
> > where the upper bound is not respected when converting to mpeg range.
&g
On Tue, Sep 24, 2024 at 5:44 AM Zhao Zhili wrote:
> > On Sep 18, 2024, at 21:11, Zhao Zhili wrote:
> > From: Zhao Zhili
> >
> > Since c0666d8b, rgb24toyv12 is broken for width non-aligned to 16.
> > Add a simple wrapper to handle the non-aligned part.
> >
> > Signed-off-by: Zhao Zhili
> > Co-au
A55 A76
chrRangeFromJpeg16_1920_c: 28848.5 6325.2
chrRangeFromJpeg16_1920_neon: 8433.0 ( 3.42x) 3365.8 ( 1.88x)
chrRangeToJpeg16_1920_c: 36558.7 9479.0
chrRangeToJpeg16_1920_neon: 9395.5 ( 3.89x) 4083.8 ( 2.32x)
l
A55 A76
chrRangeFromJpeg8_1920_c: 28842.4 6346.5
chrRangeFromJpeg8_1920_neon: 5310.9 ( 5.43x) 2264.2 ( 2.80x)
chrRangeToJpeg8_1920_c: 36520.7 9514.0
chrRangeToJpeg8_1920_neon: 6033.2 ( 6.05x) 2645.5 ( 3.60x)
lumRan
chrRangeFromJpeg16_1920_c:3893.0 ( 1.00x)
chrRangeFromJpeg16_1920_sse2: 3249.0 ( 1.20x)
chrRangeFromJpeg16_1920_avx2: 1636.0 ( 2.38x)
chrRangeToJpeg16_1920_c: 7731.0 ( 1.00x)
chrRangeToJpeg16_19
There is an issue with the constants used in YUV to YUV range conversion,
where the upper bound is not respected when converting to mpeg range.
With this commit, the constants are calculated at runtime, depending on
the bit depth. This approach also allows us to more easily understand how
the cons
chrRangeFromJpeg8_1920_c: 3874.8 ( 1.00x)
chrRangeFromJpeg8_1920_sse2: 1493.8 ( 2.59x)
chrRangeFromJpeg8_1920_avx2: 741.8 ( 5.22x)
chrRangeToJpeg8_1920_c: 5232.8 ( 1.00x)
chrRangeToJpeg8_192
---
tests/checkasm/sw_range_convert.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/checkasm/sw_range_convert.c
b/tests/checkasm/sw_range_convert.c
index df27b6c81e..e97388d14a 100644
--- a/tests/checkasm/sw_range_convert.c
+++ b/tests/checkasm/sw_range_convert.c
@@ -62,6 +62,7 @@ s
This commit also reduces the number of times ff_sws_init_scale() gets
called (only once per bit depth), and the number of times randomize_buffers()
gets called (only if the function must be checked).
Benchmarks are only performed on bit depths 8 and 16 (since they are
different functions, and not
Reduce input sizes to 8 (to test that the function works with widths
smaller than the vector length) and 1920 (raising the largest input
size to improve benchmark results).
---
tests/checkasm/sw_range_convert.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/check
We are already setting the range, so we can use regular YUV pixel
formats instead of YUVJ.
---
tests/checkasm/sw_range_convert.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/checkasm/sw_range_convert.c
b/tests/checkasm/sw_range_convert.c
index 1f04988097..8c8a
---
tests/checkasm/sw_range_convert.c | 48 +++
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/tests/checkasm/sw_range_convert.c
b/tests/checkasm/sw_range_convert.c
index e3e5096729..01c4549e53 100644
--- a/tests/checkasm/sw_range_convert.c
+++ b/tests
---
tests/checkasm/sw_gbrp.c | 15 ---
tests/checkasm/sw_range_convert.c | 8 ++--
tests/checkasm/sw_scale.c | 11 ---
3 files changed, 10 insertions(+), 24 deletions(-)
diff --git a/tests/checkasm/sw_gbrp.c b/tests/checkasm/sw_gbrp.c
index d843730f3e..74
---
libswscale/loongarch/swscale_init_loongarch.c | 32 +--
libswscale/swscale.c | 8 ++---
libswscale/x86/swscale.c | 12 +++
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/libswscale/loongarch/swscale_init_loong
These conditions are already checked for in the main init function.
---
libswscale/aarch64/swscale.c | 2 --
libswscale/loongarch/swscale_init_loongarch.c | 4
libswscale/riscv/swscale.c| 3 +--
libswscale/swscale.c | 2 +-
libswsc
This commit also fixes the issue that the call to ff_sws_init_range_convert()
from sws_init_swscale() was not setting up the arch-specific optimizations.
---
libswscale/aarch64/swscale.c | 5 -
libswscale/loongarch/swscale_init_loongarch.c | 1 -
libswscale/riscv/swscale.c
constants are derived.
NOTE: simd optimizations for x86 and aarch64 have been updated, but riscv
and loongarch are still missing (and therefore disabled).
NOTE2: the same issue still exists in rgb2yuv conversions, which is not
addressed in this patchset.
Ramiro Polla (14):
swscale
On Thu, Sep 12, 2024 at 4:44 PM James Almer wrote:
> On 9/12/2024 5:16 AM, Ramiro Polla wrote:
> > On Thu, Sep 12, 2024 at 8:44 AM James Almer wrote:
> >>
> >> Should fix fate-checkasm-sw_rgb under gcc-ubsan.
> >>
> >> Signed-off-by: James Almer
Hi,
On Mon, Sep 23, 2024 at 12:04 AM Michael Niedermayer
wrote:
>
> Fixes: out of array read
> Fixes: 71726/clusterfuzz-testcase-ffmpeg_SWS_fuzzer-5876893532880896
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael N
Hi,
On Wed, Sep 11, 2024 at 2:21 AM Michael Niedermayer
wrote:
> On Wed, Sep 11, 2024 at 02:45:59AM +0300, Andrew Randrianasulu wrote:
> > https://trac.ffmpeg.org/ticket/3345
> > https://trac.ffmpeg.org/ticket/7978
>
> I was not aware of these and ATM i dont have time but
> these smell like some
On Thu, Sep 12, 2024 at 8:44 AM James Almer wrote:
>
> Should fix fate-checkasm-sw_rgb under gcc-ubsan.
>
> Signed-off-by: James Almer
> ---
> tests/checkasm/sw_rgb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
> inde
On Mon, Sep 9, 2024 at 1:06 PM Brad Smith
wrote:
> On 2024-09-09 7:00 a.m., Martin Storsjö wrote:
> > On Mon, 9 Sep 2024, Brad Smith wrote:
> >
> >> aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
> >>
> >> FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support
On Mon, Sep 9, 2024 at 1:01 PM Martin Storsjö wrote:
> On Mon, 9 Sep 2024, Brad Smith wrote:
>
> > aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
> >
> > FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support
> > elf_aux_info(3).
> >
> > Signed-off-by: Brad Smi
The acaps variable was used outside of the #if DSHOWDEBUG block with
a1c4929f, but it is no longer used outside of the block since f125c504.
---
libavdevice/dshow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 84db151577..6e973
On Mon, Sep 9, 2024 at 11:34 AM Brad Smith wrote:
> On 2024-09-09 5:23 a.m., Ramiro Polla wrote:
>
> On Sat, Aug 24, 2024 at 3:30 PM Brad Smith
> wrote:
>
> avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
>
> Initially used for getauxval() but will be
On Sat, Aug 24, 2024 at 3:30 PM Brad Smith
wrote:
> avutil/cpu_internal: Provide ff_getauxval() wrapper for getauxvaul()
>
> Initially used for getauxval() but will be used to add support for
> other API.
I'm curious, what other API do you have in mind? Is ff_getauxval()
going to simulate getauxv
On Tue, Sep 3, 2024 at 5:42 PM Ramiro Polla wrote:
> On Sun, Sep 1, 2024 at 3:09 PM Ramiro Polla wrote:
> >
> > ---
> > libswscale/x86/input.asm | 15 +--
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/libswscale/x
On Tue, Sep 3, 2024 at 5:40 PM Ramiro Polla wrote:
> On Wed, Aug 28, 2024 at 10:43 PM Ramiro Polla wrote:
> >
> > The current code subsamples by dropping 3/4 pixels to calculate the
> > chroma components. This commit calculates the average of 4 rgb pixels
> > be
On Wed, Aug 28, 2024 at 2:11 PM Ramiro Polla wrote:
> 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).
> > ---
>
On Sun, Sep 1, 2024 at 3:09 PM Ramiro Polla wrote:
>
> ---
> libswscale/x86/input.asm | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/libswscale/x86/input.asm b/libswscale/x86/input.asm
> index 21cd8b37fd..516e4384b1 100644
&
On Wed, Aug 28, 2024 at 10:43 PM Ramiro Polla wrote:
>
> 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
On Thu, Aug 29, 2024 at 9:13 PM Michael Niedermayer
wrote:
> On Wed, Aug 28, 2024 at 02:14:33PM +0200, Ramiro Polla wrote:
> > On Thu, Aug 22, 2024 at 1:24 AM Ramiro Polla wrote:
> > > The x86 optimized dct_quantize only calculates the last nonzero
> > > coefficient c
On Wed, Aug 28, 2024 at 2:12 PM Ramiro Polla wrote:
> 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 f
On Fri, Aug 30, 2024 at 1:14 PM Ramiro Polla wrote:
> On Thu, Aug 29, 2024 at 7:55 PM James Almer wrote:
> > On 8/29/2024 2:18 PM, Ramiro Polla wrote:
> > > On Thu, Aug 29, 2024 at 7:10 PM James Almer wrote:
> > >> On 8/29/2024 10:40 AM, Ramiro Polla wrote:
> &
---
tests/checkasm/sw_rgb.c | 77 +
1 file changed, 77 insertions(+)
diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index f278454d3d..987841a54f 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -182,6 +182,80 @@ static v
1 - 100 of 305 matches
Mail list logo
