Bumping on the review for this one
On 19/05/2025 21:50, Dmitriy Kovalenko wrote:
I've found quite a few ways to optimize existing ffmpeg's rgb to yuv
subsampled conversion. In this patch stack I'll try to
improve the performance.
This particular set of changes is a small improvement to all the
在 2025/5/22 2:21, Frank Plowman 写道:
On 21/05/2025 11:17, Jiawei wrote:
在 2025/5/21 14:52, Nicolas George 写道:
Jiawei (HE12025-05-21):
particularly improving
performance on x86_64 (AVX), ARM64 (SVE) and RISC-V(RVV) architectures.
Benchmark needed.
Rega
> On May 21, 2025, at 21:52, Andreas Rheinhardt
> wrote:
>
> Zhao Zhili:
>> From: Zhao Zhili
>>
>> ---
>> tests/fate/hevc.mak| 3 +++
>> tests/ref/fate/hevc-color-reserved | 6 ++
>> 2 files changed, 9 insertions(+)
>> create mode 100644 tests/ref/fate/hevc-color-reserved
>
From: Zhao Zhili
---
tests/fate/hevc.mak| 3 +++
tests/ref/fate/hevc-color-reserved | 6 ++
2 files changed, 9 insertions(+)
create mode 100644 tests/ref/fate/hevc-color-reserved
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index 390ccf46e2..8113c04300 100644
---
From: Zhao Zhili
---
tests/fate/cbs.mak | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak
index 32207e2ee2..138dab67a9 100644
--- a/tests/fate/cbs.mak
+++ b/tests/fate/cbs.mak
@@ -172,6 +172,11 @@ $(foreach N,$(FATE_CBS_DISCARD_TYPES),$(eval $(call
From: Zhao Zhili
---
tests/fate/hevc.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index e432345ef7..390ccf46e2 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -292,7 +292,7 @@ fate-hevc-mv-position: CMD = framecrc
From: Zhao Zhili
Fix error reported by swscaler:
Unsupported input (Operation not supported): fmt:yuv420p csp:unknown
prim:reserved trc:bt709 -> fmt:yuv420p csp:bt709 prim:reserved trc:bt709
---
libavcodec/h2645_vui.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
> -Original Message-
> From: ffmpegagent
> Sent: Dienstag, 13. Mai 2025 16:23
> To: ffmpeg-devel@ffmpeg.org
> Cc: softworkz
> Subject: [PATCH v2 0/3] tests/fate: Improvements for running FATE on
> Windows/MSYS2
>
> When setting up the new Patchword builders I noticed some issues when
Hi,
I'm aiming to apply the patches below by the weekend. Please let me know in
case there are any concerns or objections or when you just need more time to
look at them.
Thanks
sw
[2/3] ffbuild: correctly silence and tag new css/html steps
[3/3] fftools/resources: add missing extensions to .
On Mon, May 19, 2025 at 12:02 AM Ramiro Polla wrote:
> On Sun, May 18, 2025 at 11:17 PM James Almer wrote:
> > On 5/18/2025 6:14 PM, James Almer wrote:
> > > On 5/18/2025 5:52 PM, Ramiro Polla wrote:
> > >> Currently, packed16togbra16() always sets the alpha value to 0x,
> > >> without taking
On Sat, May 17, 2025 at 12:36 AM Ramiro Polla wrote:
>
> The SLIBOBJS variable was introduced in 56572787ae2 but is no longer used.
> Another variable, SHLIBOBJS, was introduced after SLIBOBJS, in 20b0d24c2f7.
> The functionality from SLIBOBJS was effectively migrated to SHLIBOBJS in
> b77fff47d0
---
libavformat/oggdec.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/oggdec.h b/libavformat/oggdec.h
index 5083de646c..c15fbe738e 100644
--- a/libavformat/oggdec.h
+++ b/libavformat/oggdec.h
@@ -42,8 +42,8 @@ struct ogg_codec {
* Attempt to process a p
---
libavcodec/vorbis_parser.h | 11
libavcodec/vorbisdec.c | 75 +-
libavformat/oggparsevorbis.c | 63 +-
tests/ref/fate/ogg-vorbis-chained-meta.txt | 3 -
4 files changed, 115 insertions(+), 37 deletions(
---
libavformat/oggparsevorbis.c | 104 ---
1 file changed, 60 insertions(+), 44 deletions(-)
diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
index 9f50ab9ffc..62cc2da6de 100644
--- a/libavformat/oggparsevorbis.c
+++ b/libavformat/oggparsev
---
libavformat/oggdec.c | 11 +++
libavformat/oggdec.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
index 5557eb4a14..cb77cdd994 100644
--- a/libavformat/oggdec.c
+++ b/libavformat/oggdec.c
@@ -77,6 +77,7 @@ static void free_stream(A
## Changes since last revision:
* Removed invalid return statement in vorbisdec.c
Romain Beauxis (4):
libavformat/oggdec.{c,h}: Add new_extradata, use it to pass extradata
to the next decoded packet.
ogg/vorbis: factor out header processing logic.
ogg/vorbis: implement header packet skip
On 18/05/2025 21:11, Niklas Haas wrote:
From: Niklas Haas
Carbon copy of vf_scdet.
Signed-off-by: Niklas Haas
Sponsored-by: nxtedition
---
configure | 1 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_scdet_vulkan.c |
On 18/05/2025 21:11, Niklas Haas wrote:
From: Niklas Haas
Like vf_blackdetect but better, faster, stronger, harder.
Signed-off-by: Niklas Haas
Sponsored-by: nxtedition
---
configure | 1 +
doc/filters.texi| 2 +-
libavfilter/Makefile
On 18/05/2025 21:11, Niklas Haas wrote:
From: Niklas Haas
Implied internally now when needed.
---
libavfilter/vf_gblur_vulkan.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavfilter/vf_gblur_vulkan.c b/libavfilter/vf_gblur_vulkan.c
index 80b66de735..fb676a7fc9 100644
--- a/libavfilt
On 18/05/2025 21:11, Niklas Haas wrote:
From: Niklas Haas
We require this internally when using descriptor buffers, so it makes sense
to enable it internally, also.
---
libavutil/vulkan.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
index 5f2
On 22/05/2025 06:21, sohzm wrote:
Fix inconsistent sample format reporting between probing and decoding.
Previously, avformat_find_stream_info reported fltp format for MP3
streams but frames were decoded as s16p.
Fixes ticket/11561
---
libavcodec/allcodecs.c | 2 +-
1 file changed, 1 insertio
Fix inconsistent sample format reporting between probing and decoding.
Previously, avformat_find_stream_info reported fltp format for MP3
streams but frames were decoded as s16p.
Fixes ticket/11561
---
libavcodec/allcodecs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/liba
Hi,
On Wed, May 21, 2025 at 4:00 AM Kieran Kunhya via ffmpeg-devel
wrote:
> Can we just revert the whole set until it's cleaned up properly?
>
> There are more patches to fix issues than the set itself. This is
> understandable if it's a bit architectural change like threading but it's
> not.
I
> -Original Message-
> From: ffmpeg-devel On Behalf Of softworkz .
> Sent: Mittwoch, 21. Mai 2025 22:20
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> -Original Message-
> From: ffmpeg-devel On Behalf Of Kyle Swanson
> Sent: Mittwoch, 21. Mai 2025 22:11
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
>
> Hi,
>
> On Wed, May 21, 2025 at 4:00 AM Kieran Kunhya via ffmpeg-deve
On Wed, 2025-05-21 at 19:25 +, softworkz . wrote:
> What I mean and what the comment in the ticket is probably
> suggesting,
> is that the HLS demuxer should URL-encode the URL after combining the
> base url with the segment file name before making a request for the
> segment.
Ah, sure. That
> -Original Message-
> From: ffmpeg-devel On Behalf Of Kieran
> Kunhya via ffmpeg-devel
> Sent: Mittwoch, 21. Mai 2025 13:00
> To: FFmpeg development discussions and patches
> Cc: Kieran Kunhya
> Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
>
> On Wed, 21 May 2025, 01:45 s
> -Original Message-
> From: ffmpeg-devel On Behalf Of Timothy
> Allen via ffmpeg-devel
> Sent: Mittwoch, 21. Mai 2025 21:09
> To: ffmpeg-devel@ffmpeg.org
> Cc: Timothy Allen
> Subject: Re: [FFmpeg-devel] [PATCH] Accept a colon in the path of a URI,
> instead of stripping preceding cha
On Wed, 2025-05-21 at 18:56 +, softworkz . wrote:
> Why do you think it would require control over the server side?
The original ticket is referring to HLS, and specifically the manifest
of HLS, which means a remotely-hosted M3U playlist.
In principle, the user could download the playlist, co
softworkz . (HE12025-05-21):
> From: Timothy Allen
> Sent: Mittwoch, 21. Mai 2025 09:29
> To: softworkz . ; FFmpeg development discussions and
> patches
> Subject: Re: [FFmpeg-devel] [PATCH] Accept a colon in the path of a URI,
> instead of stripping preceding characters.
>
> On Tue, 2025-05-2
From: Timothy Allen
Sent: Mittwoch, 21. Mai 2025 09:29
To: softworkz . ; FFmpeg development discussions and
patches
Subject: Re: [FFmpeg-devel] [PATCH] Accept a colon in the path of a URI,
instead of stripping preceding characters.
On Tue, 2025-05-20 at 20:03 +, softworkz . wrote:
I was
> -Original Message-
> From: ffmpeg-devel On Behalf Of Derek
> Buitenhuis
> Sent: Mittwoch, 21. Mai 2025 15:27
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 0/3] Clean up build spam from graph css
> builder
>
> On 5/20/2025 7:44 PM, softworkz . wrote:
> > Hi Derek,
On 21/05/2025 11:17, Jiawei wrote:
>
> 在 2025/5/21 14:52, Nicolas George 写道:
>> Jiawei (HE12025-05-21):
>>> particularly improving
>>> performance on x86_64 (AVX), ARM64 (SVE) and RISC-V(RVV) architectures.
>> Benchmark needed.
>>
>> Regards,
>
>
> Hi Nicola
> -Original Message-
> From: ffmpeg-devel On Behalf Of Martin
> Storsjö
> Sent: Mittwoch, 21. Mai 2025 14:22
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] gcc: Remove auto-vectorization limitation.
>
> On Wed, 21 May 2025, Andreas Rheinhardt wrote:
>
>
Patches attached; mostly about MPEG-4.
- Andreas
From 1a73463508298d6683658e86a5e0e5453c75e0d7 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Sat, 17 May 2025 19:30:02 +0200
Subject: [PATCH 01/19] avcodec/mpegvideo_enc: Set gob_index once during init
Signed-off-by: Andreas Rheinhardt
-
Tested to pass FATE on Linux and Windows.
Checkasm numbers vs the existing SSE2 code on Zen 5 (Strix Halo):
vp9_inv_adst_adst_16x16_sub16_add_10_sse2: 1041.8 ( 1.92x)
vp9_inv_adst_adst_16x16_sub16_add_10_avx512icl: 132.5 (15.06x)
vp9_inv_dct_adst_16x16_sub16_add_10_sse2: 901.0 ( 1
Zhao Zhili:
> From: Zhao Zhili
>
> ---
> tests/fate/hevc.mak| 3 +++
> tests/ref/fate/hevc-color-reserved | 6 ++
> 2 files changed, 9 insertions(+)
> create mode 100644 tests/ref/fate/hevc-color-reserved
>
> diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
> index 39
On 5/21/2025 2:23 PM, Derek Buitenhuis wrote:
> This changes the scanning to check for the end tag 1 byte at a time
> and buffers the last 1 MiB using ffio_ensure_seekback to avoid additional
> seek operations.
I removed the part about ffio_ensure_seekback locally.
- Derek
___
On 5/20/2025 7:44 PM, softworkz . wrote:
> Hi Derek,
>
> thanks a lot for the patch. This partially duplicates what Timo had
> already submitted:
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20250516230202.355445-1-t...@rothenpieler.org/
Dropping this set, then.
> Regarding patch 3/3,
Le mer. 21 mai 2025 à 02:53, Michael Niedermayer a
écrit :
>
> Hi Romain
>
> On Tue, May 20, 2025 at 05:45:01PM -0500, Romain Beauxis wrote:
> > Le mar. 20 mai 2025 à 16:46, Michael Niedermayer
> > a écrit :
> > >
> > > On Mon, May 19, 2025 at 09:46:38AM -0500, Romain Beauxis wrote:
> > > > ---
>
From: Niklas Haas
ol->frame_rate is 0/0, so we need to calcalute the correct value based on
the il->frame_rate instead. Also adjust the time base, PTS and frame_duration
values accordingly. (Logic taken from vf_tinterlace.c)
---
libavfilter/vf_interlace_vulkan.c | 10 +-
1 file changed,
LGTM
On 21/05/2025 23:12, Niklas Haas wrote:
From: Niklas Haas
ol->frame_rate is 0/0, so we need to calcalute the correct value based on
the il->frame_rate instead. Also adjust the time base, PTS and frame_duration
values accordingly. (Logic taken from vf_tinterlace.c)
---
libavfilter/vf_int
On Wed, May 21, 2025 at 2:00 PM Niklas Haas wrote:
>
> From: Niklas Haas
>
> This covers most 8-bit and 16-bit ops, and some 32-bit ops. It also covers all
> floating point operations. While this is not yet 100% coverage, it's good
> enough for the vast majority of formats out there.
>
> Of speci
Before this patch, when qt-faststart converted stco atoms to co64, it
did so without updating the chunk offsets of pre-existing co64 atoms,
resulting in corrupted tracks. This patch ensures that existing co64
chunk offsets are correctly adjusted when such a conversion occurs.
Signed-off-by: CesarA
Zhao Zhili:
> From: Zhao Zhili
>
> ---
> tests/fate/hevc.mak| 3 +++
> tests/ref/fate/hevc-color-reserved | 6 ++
> 2 files changed, 9 insertions(+)
> create mode 100644 tests/ref/fate/hevc-color-reserved
>
> diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
> index 39
Zhao Zhili:
>
>
>> On May 21, 2025, at 21:28, Zhao Zhili
>> wrote:
>>
>>> On May 21, 2025, at 21:11, Andreas Rheinhardt
>>> wrote:
>>>
>>> Zhao Zhili:
From: Zhao Zhili
---
tests/fate/hevc.mak| 3 +++
tests/ref/fate/hevc-color-reserved | 6 ++
2
> On May 21, 2025, at 21:28, Zhao Zhili
> wrote:
>
>> On May 21, 2025, at 21:11, Andreas Rheinhardt
>> wrote:
>>
>> Zhao Zhili:
>>> From: Zhao Zhili
>>>
>>> ---
>>> tests/fate/hevc.mak| 3 +++
>>> tests/ref/fate/hevc-color-reserved | 6 ++
>>> 2 files changed, 9 inserti
Hello,
I am interested in expanding ffmpeg's capabilities to extract
low-level data from video codecs. Specifically, I'd like to implement
functionality that would allow exporting frame data, macroblock
information, quantization tables, and similar codec-specific elements
to binary files for furth
> On May 21, 2025, at 21:11, Andreas Rheinhardt
> wrote:
>
> Zhao Zhili:
>> From: Zhao Zhili
>>
>> ---
>> tests/fate/hevc.mak| 3 +++
>> tests/ref/fate/hevc-color-reserved | 6 ++
>> 2 files changed, 9 insertions(+)
>> create mode 100644 tests/ref/fate/hevc-color-reserved
From: Niklas Haas
This can turn any compatible sequence of operations into a single packed
shuffle, including packed swizzling, grayscale->RGB conversion, endianness
swapping, RGB bit depth conversions, rgb24->rgb0 alpha clearing and more.
---
libswscale/ops_internal.h | 17 +++
libswscale/
From: Zhao Zhili
---
tests/fate/hevc.mak| 3 +++
tests/ref/fate/hevc-color-reserved | 6 ++
2 files changed, 9 insertions(+)
create mode 100644 tests/ref/fate/hevc-color-reserved
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index 390ccf46e2..8113c04300 100644
---
On 5/20/2025 8:18 PM, Andreas Rheinhardt wrote:
> The only thing that you want from parsing the end is the end timestamp
> and this is given by data alone. date is a 32bit le number at offset 16
> from the start of the dhav tag; it can be read directly from the buffer,
> so you do not need to seek
From: Justin Ruggles
The backwards scanning done for incomplete final packets should not
assume a specific alignment at the end of the file. Truncated files
result in hundreds of thousands of seeks if the final packet does not
fall on a specific byte boundary, which can be extremely slow.
For exa
On Fri, 16 May 2025 13:07:05 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> Flipping can already be accomplished by setting the crop_w/h expressions to
> their negative values, so together these options can implement any of the
> common frame orientations.
Will apply if there are no objections
On Fri, 16 May 2025 13:15:24 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> Useful to speed up shader compilation. May significantly lower startup
> times, in particular with large or complex shaders.
>
> Sponsored-by: nxtedition
Will apply if there are no further comments.
___
From: Zhao Zhili
---
tests/fate/hevc.mak| 3 +++
tests/ref/fate/hevc-color-reserved | 6 ++
2 files changed, 9 insertions(+)
create mode 100644 tests/ref/fate/hevc-color-reserved
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index 390ccf46e2..5e721526d0 100644
---
From: Zhao Zhili
---
tests/fate/hevc.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index e432345ef7..390ccf46e2 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -292,7 +292,7 @@ fate-hevc-mv-position: CMD = framecrc
From: Zhao Zhili
Fix error reported by swscaler:
Unsupported input (Operation not supported): fmt:yuv420p csp:unknown
prim:reserved trc:bt709 -> fmt:yuv420p csp:bt709 prim:reserved trc:bt709
---
libavcodec/h2645_vui.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
From: Niklas Haas
This handles the low-level execution of an op list, and integration into
the SwsGraph infrastructure. To handle frames with insufficient padding in
the stride (or a width smaller than one block size), we use a fallback loop
that pads the last column of pixels using `memcpy` into
From: Niklas Haas
This is responsible for taking a "naive" ops list and optimizing it
as much as possible. Also includes a small analyzer that generates component
metadata for use by the optimizer.
---
libswscale/Makefile| 1 +
libswscale/ops.h | 12 +
libswscale/ops_optimiz
From: Niklas Haas
This adds an internal API for ops backends, which are responsible for
compiling op lists into executable functions.
---
libswscale/ops.c | 62 ++
libswscale/ops_internal.h | 108 ++
2 files changed, 170 insertion
From: Niklas Haas
See docs/swscale-v2.txt for an in-depth introduction to the new approach.
This commit merely introduces the ops definitions and boilerplate functions.
The subsequent commits will flesh out the underlying implementation.
---
libswscale/Makefile | 1 +
libswscale/ops.c| 52
From: Niklas Haas
Give users and developers a way to opt in to the new format conversion code,
and more code from the swscale rewrite in general, even while development is
still ongoing.
---
doc/APIchanges | 3 +++
doc/scaler.texi | 4
libswscale/options.c | 1 +
libswscale/swsca
From: Niklas Haas
This patch adds format handling code for the new operations. This entails
fully decoding a format to standardized RGB, and the inverse.
Handling it this way means we can always guarantee that a conversion path
exists from A to B without having to explicitly cover logic for each
From: Niklas Haas
This covers most 8-bit and 16-bit ops, and some 32-bit ops. It also covers all
floating point operations. While this is not yet 100% coverage, it's good
enough for the vast majority of formats out there.
Of special note is the packed shuffle fast path, which uses pshufb at vect
From: Niklas Haas
Provides a generic fast path for any operation list that can be decomposed
into a series of memcpy and memset operations.
25% faster than the x86 backend for yuv444p -> yuva444p
33% faster than the x86 backend for gray -> yuvj444p
---
libswscale/Makefile | 1 +
libswscal
From: Niklas Haas
\o/
---
libswscale/graph.c | 84 --
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/libswscale/graph.c b/libswscale/graph.c
index dc7784aa49..24930e7627 100644
--- a/libswscale/graph.c
+++ b/libswscale/graph.c
@@ -34,6
From: Niklas Haas
Because of the lack of an external ABI on low-level kernels, we cannot
directly test internal functions. Instead, we construct a minimal op chain
consisting of a read, the op to be tested, and a write.
The bigger complication arises from the fact that the backend may generate
a
From: Niklas Haas
This will serve as a reference for the SIMD backends to come. That said,
with auto-vectorization enabled, the performance of this is not atrocious.
It easily beats the old C code and sometimes even the old SIMD.
In theory, we can dramatically speed it up by using GCC vectors in
From: Niklas Haas
See doc/swscale-v2.txt for design details.
---
libswscale/Makefile| 1 +
libswscale/ops_chain.c | 293 +
libswscale/ops_chain.h | 109 +++
3 files changed, 403 insertions(+)
create mode 100644 libswscale/ops_chain.c
cr
From: Niklas Haas
Sometimes, when measuring very small functions, rdtsc is not accurate enough
to get a reliable measurement. This increases the number of runs inside the
inner loop from 4 to 32, which should help a lot. Less important when using
the more precise linux-perf API, but still useful.
From: Niklas Haas
We split the standard macro into its body (implementation) and declaration,
and use a macro argument in place of the raw `memcmp` call, with the major
difference that we now take the number of pixels to compare instead of the
number of bytes (to match the signature of float_near
From: Niklas Haas
---
libswscale/format.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libswscale/format.c b/libswscale/format.c
index e4c1348b90..b77081dd7a 100644
--- a/libswscale/format.c
+++ b/libswscale/format.c
@@ -24,14 +24,14 @@
#include "form
From: Niklas Haas
Reset an SwsFormat to its fully unset/invalid state.
---
libswscale/format.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libswscale/format.h b/libswscale/format.h
index 3b6d745159..be92038f4f 100644
--- a/libswscale/format.h
+++ b/libswscale/format.h
@@
Changes since v1:
- keep track of `packed` status even for single-element bit-packed formats
- fix memory leak of dither matrix
- fix AVRational printing of infinities
- fix value range tracking for big endian formats
- fix some overflow bugs on 32-bit
- remove unneeded internal helper
- add optimi
Patches attached.
- Andreas
From 8be9ae98dd8c880dd459cddb3192c67294d25186 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Fri, 16 May 2025 16:43:34 +0200
Subject: [PATCH 1/4] avcodec/mpegvideo_enc: Use av_unreachable() for
unreachable code
Signed-off-by: Andreas Rheinhardt
---
libavco
On Wed, 21 May 2025, Andreas Rheinhardt wrote:
Martin Storsjö:
On Wed, 21 May 2025, Andreas Rheinhardt wrote:
Jiawei:
This patch modifies the FFmpeg build system to remove the explicit
disabling
of GCC's auto-vectorization feature.
Modern GCC versions (>= 10.0) have demonstrated stable auto
Martin Storsjö:
> On Wed, 21 May 2025, Andreas Rheinhardt wrote:
>
>> Jiawei:
>>> This patch modifies the FFmpeg build system to remove the explicit
>>> disabling
>>> of GCC's auto-vectorization feature.
>>>
>>> Modern GCC versions (>= 10.0) have demonstrated stable auto-
>>> vectorization
>>> cap
On Wed, 21 May 2025, Andreas Rheinhardt wrote:
Jiawei:
This patch modifies the FFmpeg build system to remove the explicit disabling
of GCC's auto-vectorization feature.
Modern GCC versions (>= 10.0) have demonstrated stable auto-vectorization
capabilities through extensive optimizations in loo
On Wed, May 21, 2025 at 06:32:49PM +0800, Jiawei wrote:
>
> 在 2025/5/21 15:46, Michael Niedermayer 写道:
> > On Wed, May 21, 2025 at 02:17:50PM +0800, Jiawei wrote:
> > > This patch modifies the FFmpeg build system to remove the explicit
> > > disabling
> > > of GCC's auto-vectorization feature.
>
On Wed, 21 May 2025, 01:45 softworkz .,
wrote:
> Hello,
>
> thanks again to all for the patches. I figured it might be a bit difficult
> to
> keep track of what has already been submitted and fixed and is still
> pending, and I'm sorry that there has been some duplicate effort to fix the
> same t
Jiawei:
> This patch modifies the FFmpeg build system to remove the explicit disabling
> of GCC's auto-vectorization feature.
>
> Modern GCC versions (>= 10.0) have demonstrated stable auto-vectorization
> capabilities through extensive optimizations in loop analysis and SIMD
> code generation. Th
在 2025/5/21 15:46, Michael Niedermayer 写道:
On Wed, May 21, 2025 at 02:17:50PM +0800, Jiawei wrote:
This patch modifies the FFmpeg build system to remove the explicit disabling
of GCC's auto-vectorization feature.
Modern GCC versions (>= 10.0) have demonstrated stable auto-vectorization
capabil
在 2025/5/21 17:04, Zhao Zhili 写道:
On May 21, 2025, at 14:17, Jiawei wrote:
This patch modifies the FFmpeg build system to remove the explicit disabling
of GCC's auto-vectorization feature.
Modern GCC versions (>= 10.0) have demonstrated stable auto-vectorization
capabilities through extensi
在 2025/5/21 14:52, Nicolas George 写道:
Jiawei (HE12025-05-21):
particularly improving
performance on x86_64 (AVX), ARM64 (SVE) and RISC-V(RVV) architectures.
Benchmark needed.
Regards,
Hi Nicolas,
Since I am a gcc developer, I'm not so familiar wi
> -原始邮件-
> 发件人: "Nicolas George"
> 发送时间: 2025-05-21 14:52:12 (星期三)
> 收件人: "FFmpeg development discussions and patches"
> 抄送:
> 主题: Re: [FFmpeg-devel] gcc: Remove auto-vectorization limitation.
>
> Jiawei (HE12025-05-21):
> > particularly improving
> > performance o
> -原始邮件-
> 发件人: "Nicolas George"
> 发送时间: 2025-05-21 14:52:12 (星期三)
> 收件人: "FFmpeg development discussions and patches"
> 抄送:
> 主题: Re: [FFmpeg-devel] gcc: Remove auto-vectorization limitation.
>
> Jiawei (HE12025-05-21):
> > particularly improving
> > performance o
> On May 21, 2025, at 14:17, Jiawei wrote:
>
> This patch modifies the FFmpeg build system to remove the explicit disabling
> of GCC's auto-vectorization feature.
>
> Modern GCC versions (>= 10.0) have demonstrated stable auto-vectorization
> capabilities through extensive optimizations in loo
Hello, Can I get some eyes on this please?
On Fri, 16 May 2025 at 01:24, Appaji Chintimi wrote:
>
> Can you elaborate a bit more why this requires more changes? My understanding
> is, to check for different cases and handle them differently:
>
> 1. "-" gets replaced with "fd:", and it's passed d
Hi Romain
On Tue, May 20, 2025 at 05:45:01PM -0500, Romain Beauxis wrote:
> Le mar. 20 mai 2025 à 16:46, Michael Niedermayer
> a écrit :
> >
> > On Mon, May 19, 2025 at 09:46:38AM -0500, Romain Beauxis wrote:
> > > ---
> > > libavcodec/vorbis_parser.h | 11
> > > libavcodec/
On Wed, May 21, 2025 at 02:17:50PM +0800, Jiawei wrote:
> This patch modifies the FFmpeg build system to remove the explicit disabling
> of GCC's auto-vectorization feature.
>
> Modern GCC versions (>= 10.0) have demonstrated stable auto-vectorization
> capabilities through extensive optimizations
On Wed, May 21, 2025 at 02:46:42AM +0200, Michael Niedermayer wrote:
> On Mon, May 19, 2025 at 08:15:37PM +0800, chenyu202...@gmail.com wrote:
> > From: chenyu
> >
> > Optimizing 160k code size by converting static array to dynamic malloc
> > memory.
> >
> > Signed-off-by: chenyu
> > ---
> >
On Tue, 2025-05-20 at 20:03 +, softworkz . wrote:
> I was just about to reply and suggest to replace those colons with
> %3A
> (url-encoded) when I read the ticket, which already suggests that.
>
> Have you tried it? It sounds like a much better way to me.
I think this would be a common-sense
93 matches
Mail list logo
