Here is a particularly bad example of autovectorisation across many
compilers:
https://gcc.godbolt.org/z/rjEqzf1hh
Kieran
Admittedly, in some cases, enabling vectorization is not the optimal
solution.
But the question is the limitation is only added on gcc side.For LLVM
clang, there are no
Andreas Rheinhardt:
> Patches attached.
>
> - Andreas
>
Will apply this patchset tonight unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vis
On Thu, 22 May 2025, 07:32 Jiawei, wrote:
> 在 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), AR
Hi Romain
On Wed, May 21, 2025 at 05:05:37PM -0500, Romain Beauxis wrote:
> ---
> libavcodec/vorbis_parser.h | 11
> libavcodec/vorbisdec.c | 75 +-
> libavformat/oggparsevorbis.c | 63 +-
> tests/ref/fate/
From: softworkz
When there's a chain of implicit rules, make treats files generated
inside that chain as intermediate files. Those intermediate files are
removed after completion of make. When make is run again, it normally
determines the need for a rebuild by comparing the timestamps of the
orig
Add hardware-accelerated stack filters for CUDA that provide equivalent
functionality to the software stack filters but with GPU acceleration.
Features:
- Support for hstack, vstack, and xstack operations
- Compatible pixel formats such as:
yuv420p, nv12, yuv444p, p010le, p016le, yuv444p16le, rg
On Fri, 23 May 2025, 21:35 Michael Niedermayer,
wrote:
> Hi Kieran
>
> On Fri, May 23, 2025 at 04:45:53PM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> > On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya
> wrote:
> > >
> > > On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller
> > > wrote:
> > > >
> -Original Message-
> From: ffmpeg-devel On Behalf Of Timothy
> Allen via ffmpeg-devel
> Sent: Freitag, 23. Mai 2025 16:53
> To: ffmpeg-devel@ffmpeg.org
> Cc: Timothy Allen
> Subject: [FFmpeg-devel] [PATCH] Percent-encode URL paths in HLS playlists
>
> This commit closes trac ticket
> -Original Message-
> From: ffmpeg-devel On Behalf Of Marton
> Balint
> Sent: Freitag, 23. Mai 2025 22:31
> To: Timothy Allen via ffmpeg-devel
> Subject: Re: [FFmpeg-devel] [PATCH] Percent-encode URL paths in HLS playlists
>
>
>
> On Fri, 23 May 2025, Timothy Allen via ffmpeg-devel
Hi Kieran
On Fri, May 23, 2025 at 04:45:53PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya
> wrote:
> >
> > On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller
> > wrote:
> > >
> > > Hello Michael,
> > >
> > > On Fri, May 23, 2025 at 5:45 AM Michael
On Fri, 23 May 2025, Timothy Allen via ffmpeg-devel wrote:
This commit closes trac ticket 10679.
And what if the M3U8 is referencing absolute URLs with scheme? Or is using
a data URI? Or if it is a local DOS path? What if the URL is already
percent encoded?
This issue is not trivial to
From: IndecisiveTurtle
Prevents compiler from mistaking it as a string
Also makes passing it to the GPU in a buffer easier
---
libavcodec/vc2enc_common.c | 2 +-
libavcodec/vc2enc_common.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vc2enc_common.c b/libav
From: IndecisiveTurtle
---
libavcodec/Makefile| 2 +-
libavcodec/vc2enc.c| 669 ++---
libavcodec/vc2enc_common.c | 571 +++
libavcodec/vc2enc_common.h | 168 ++
4 files changed, 765 insertions(+), 645 deletions
From: IndecisiveTurtle
Performance wise, encoding a 3440x1440 1-minute video is performed in about 2.4
minutes with the cpu encoder running on my Ryzen 5 4600H, while it takes about
1.3 minutes on my NVIDIA GTX 1650
Haar shader has a subgroup optimized variant that applies when configured
wav
From: IndecisiveTurtle
---
libavcodec/vulkan/common.comp | 51 ---
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/libavcodec/vulkan/common.comp b/libavcodec/vulkan/common.comp
index 10af9c0623..59a4a4b1a8 100644
--- a/libavcodec/vulkan/common.comp
On 23 May 2025, at 20:53, Michael Niedermayer wrote:
> Hi Marvin
>
> On Fri, May 23, 2025 at 02:11:24AM +0200, Marvin Scholz wrote:
>> ---
>> libavformat/sdp.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/libavformat/sdp.c b/libavformat/sdp.c
>> index 215e38f8fc..21ada5d1ce 1
This also updates fate-lavf-mov_rtphint as there the SDP
is included in the muxed file.
---
libavformat/sdp.c | 3 +++
tests/ref/lavf/mov_rtphint | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 215e38f8fc..21ada5d1ce 100
Hi Marvin
On Fri, May 23, 2025 at 02:11:24AM +0200, Marvin Scholz wrote:
> ---
> libavformat/sdp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/sdp.c b/libavformat/sdp.c
> index 215e38f8fc..21ada5d1ce 100644
> --- a/libavformat/sdp.c
> +++ b/libavformat/sdp.c
> @@ -867
On Fri, 23 May 2025 18:27:38 +0200 Michael Niedermayer
wrote:
> On Wed, May 21, 2025 at 02:43:54PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > This adds an internal API for ops backends, which are responsible for
> > compiling op lists into executable functions.
> > ---
> > libswsca
From: Erik Linge
Co-authored-by: Marvin Scholz
---
libavformat/rtsp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 5ea471b40c..3f2966414f 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -618,6 +618,13 @@ static void sdp_par
On Wed, May 21, 2025 at 02:43:54PM +0200, Niklas Haas wrote:
> 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 |
Hi,
>
>
> But Lynne is insisting it's not a protocol. The work would just be the low
> level RaptorQ algorithm.
>
> UDP based retransmit/FEC protocols are essentially impossible to develop
> well without an event loop / timers.
>
> You can look at libsrt and librist of examples of how trying
On 23 May 2025, at 18:06, Michael Niedermayer wrote:
> On Fri, May 23, 2025 at 01:59:37AM +0200, Marvin Scholz wrote:
>> From: Erik Linge
>>
>> Co-authored-by: Marvin Scholz
>> ---
>> libavformat/rtsp.c | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/libavformat/rtsp.c b/li
From: Erik Linge
---
libavformat/rtpdec_jpeg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/rtpdec_jpeg.c b/libavformat/rtpdec_jpeg.c
index 81036247c1..4d9ee0d754 100644
--- a/libavformat/rtpdec_jpeg.c
+++ b/libavformat/rtpdec_jpeg.c
@@ -233,6 +233,8 @@ static int jpeg_parse
Hi Devin
On Fri, May 23, 2025 at 10:57:37AM -0400, Devin Heitmueller wrote:
> On Fri, May 23, 2025 at 5:58 AM Michael Niedermayer
> wrote:
> > Theres also the human element, where people are not machienes that can
> > be placed and told things arbitrary. RaptorQ is "cool", ARQ is boring
> >
> > S
On Fri, May 23, 2025 at 01:59:37AM +0200, Marvin Scholz wrote:
> From: Erik Linge
>
> Co-authored-by: Marvin Scholz
> ---
> libavformat/rtsp.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index 5ea471b40c..6807e1d6b5 100644
> --- a/l
Hi Devin
On Fri, May 23, 2025 at 10:50:32AM -0400, Devin Heitmueller wrote:
> Hello Michael,
>
> On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
> wrote:
> > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-deve
On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya wrote:
>
> On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller
> wrote:
> >
> > Hello Michael,
> >
> > On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
> > wrote:
> > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > > > On Th
---
libavformat/avformat.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 2034d2aecc..feef317840 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -146,8 +146,8 @@
* consumed). The calling program ca
Hi Kieran
On Fri, May 23, 2025 at 01:13:05PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> On Fri, 23 May 2025, 12:33 Michael Niedermayer,
> wrote:
>
> > Hi Kieran
> >
> > On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel
> > wrote:
> > [...]
> > > I appreciate the way th
On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller
wrote:
>
> Hello Michael,
>
> On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
> wrote:
> > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > > wrote:
>
Hello Michael,
On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
wrote:
> On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > wrote:
> > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> >
On Fri, May 23, 2025 at 12:33 PM Michael Niedermayer
wrote:
>
> Hi Kieran
>
> On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
> > I appreciate the way the 2024 organisers ran STF was not exactly stellar
>
> It seems every mail you post is an attack on FFm
On Fri, May 23, 2025 at 5:58 AM Michael Niedermayer
wrote:
> Theres also the human element, where people are not machienes that can
> be placed and told things arbitrary. RaptorQ is "cool", ARQ is boring
>
> Some people enjoy working on "cool" things, dont tell them to work on
> boring things plea
This commit closes trac ticket 10679.
Signed-off-by: Timothy Allen
---
libavformat/hls.c | 9 +
libavformat/url.c | 35 +++
libavformat/url.h | 9 +
3 files changed, 53 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index c7b65
Fix a crash (some GCC) or silent quit (Microsoft compiler) after
"[PATCH 06/16] ffv1enc_vulkan: switch to 2-line cache, unify prediction
code"
https://ffmpeg.org/pipermail/ffmpeg-devel/2025-May/343502.htmlFrom: Maxime Gervais
Date: Fri, 23 May 2025 16:20:41 +0200
Subject: [PATCH] ffv1enc_vulkan
Hello Lynne,
On Thu, May 22, 2025 at 11:48 PM Lynne wrote:
> > I see the task on the TRAC page for STF 2025, and while intellectually
> > interesting to a nerd like me who does lots of work with reliable
> > protocols, I'm not confident this particular protocol makes much sense
> > to work on, es
On Fri, May 23, 2025 at 11:45:14AM +0200, Michael Niedermayer wrote:
> Hi
[...]
> > I agree with Kieran that this seems to largely be outside the STF
> > objectives (i.e. sustainability for open source projects).
>
> A new implementation of RIST, SRT, Raptor and so on may fall outside
> but redesi
On Sun, 18 May 2025 14:11:51 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> This determines whether the input has any pixel values exceeding the alpha
> channel. In this case, we can be sure that the input is not premultiplied.
> In all other cases, the result in indeterminate. As such, we can
On Thu, 22 May 2025 06:32:42 +0900 Lynne wrote:
> 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/li
On Thu, 22 May 2025 06:32:18 +0900 Lynne wrote:
> 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 i
On Fri, 23 May 2025, 12:33 Michael Niedermayer,
wrote:
> Hi Kieran
>
> On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
> > I appreciate the way the 2024 organisers ran STF was not exactly stellar
>
> It seems every mail you post is an attack on FFmpeg or
On Fri, May 23, 2025 at 11:44:26AM +0800, Zhao Zhili wrote:
> I have created a ticket on trac and uploaded a sample.
>
> https://trac.ffmpeg.org/ticket/11603
>
> The issue is CBS can detect invalid data in the bitstream, and report error.
> How to handle these error is a problem.
>
> With a sing
On Fri, May 23, 2025 at 11:33:40AM +0200, Timothée wrote:
> On 2025-05-23T02:57:36.000+02:00, Michael Niedermayer
> wrote:
>
> > On Fri, May 23, 2025 at 02:45:59AM +0200, Michael Niedermayer wrote:
> >
> >> Hi Ronald On Thu, May 22, 2025 at 07:59:06AM -0400, Ronald S.
> >> Bultje wrote:
> >>
Updated version attached. Now only using six frames in order to avoid
triggering differences on aarch64.
- Andreas
From 3b973c8bd47403348233a0b30fb03dfb0b7f5d75 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Fri, 23 May 2025 11:42:38 +0200
Subject: [PATCH v2] tests/fate/ac3: Make ac3-fix
On 5/23/2025 6:52 AM, Andreas Rheinhardt wrote:
Patch attached. Another candidate as input file would be
dts/master_audio_7.1_24bit.dts, but then it would be unclear whether
this is still a true AC3 test.
- Andreas
nit: maybe limit the amount of audio frames to be encoded, since it's
not the
Hi Kieran
On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel wrote:
[...]
> I appreciate the way the 2024 organisers ran STF was not exactly stellar
It seems every mail you post is an attack on FFmpeg or the FFmpeg Team
And its alot of different people you target. And often
On Fri, 23 May 2025, 10:45 Michael Niedermayer,
wrote:
> Hi
>
> On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > wrote:
> > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > > maintenan
On Fri, 23 May 2025, 10:58 Michael Niedermayer,
wrote:
> On Fri, May 23, 2025 at 11:45:14AM +0200, Michael Niedermayer wrote:
> > Hi
> [...]
> > > I agree with Kieran that this seems to largely be outside the STF
> > > objectives (i.e. sustainability for open source projects).
> >
> > A new imple
On 23/05/2025 15:50, Kieran Kunhya via ffmpeg-devel wrote:
On Fri, 23 May 2025, 04:44 Lynne, wrote:
On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote:
Hello,
I wanted to put on the record that adding RaptorQ to FFmpeg isn't
maintenance of FFmpeg.
It isn't -- it's research.
It's ad
Patch attached. Another candidate as input file would be
dts/master_audio_7.1_24bit.dts, but then it would be unclear whether
this is still a true AC3 test.
- Andreas
From 493756488cd346eda96d7a6e6273d1e6ff455d68 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Fri, 23 May 2025 11:42:38 +0
Hi
On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> wrote:
> > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > maintenance of FFmpeg.
i agree adding RaptorQ itself is probably not maintenan
On Fri, May 23, 2025 at 11:38 AM Leo Izen wrote:
>
> I'm actually quite out of the loop on how to request funding. I've been
> meaning to do it since I'm putting a lot of hours into my EXIF work, and
> still got a bunch more. A lot of code is written but much of it is not
> tested, and that's impo
On 2025-05-23T02:57:36.000+02:00, Michael Niedermayer
wrote:
> On Fri, May 23, 2025 at 02:45:59AM +0200, Michael Niedermayer wrote:
>
>> Hi Ronald On Thu, May 22, 2025 at 07:59:06AM -0400, Ronald S.
>> Bultje wrote:
>>
>>> Hi, On Wed, May 21, 2025 at 9:34 AM Timothée <
>>> timothee.info
On Windows Arm64
`uname -m` returned `x86_64` instead of `aarch64`
Link: https://github.com/msys2/msys2-runtime/issues/171
On x86 32-bit toolchain msys2 environment
`uname -m` returned `x86_64` instead of `i686` or `x86`
So check MSYSTEM_CARCH on windows (for arm64 and i686)
This problem also in
Also we can check $MSYSTEM_CARCH if it exists
How about your idea?
Coia Prant 于 2025年5月23日周五 17:11写道：
> On Windows Arm64
> `uname -m` returned `x86_64` instead of `aarch64`
> Link: https://github.com/msys2/msys2-runtime/issues/171
>
> But `uname -s` contains `ARM64` suffix
> So check MSYSTEM on
Andreas Rheinhardt:
> Martin Storsjö:
>> On Thu, 22 May 2025, James Almer wrote:
>>
>>> ffmpeg | branch: master | James Almer | Thu May 22
>>> 19:23:35 2025 -0300| [622a72b5ea5f2022b173355d65d513df2d75000b] |
>>> committer: James Almer
>>>
>>> tests/fate/ac3: add a second ac3_fixed encoder test
>>
On Windows Arm64
`uname -m` returned `x86_64` instead of `aarch64`
Link: https://github.com/msys2/msys2-runtime/issues/171
But `uname -s` contains `ARM64` suffix
So check MSYSTEM on windows arm64 (for clangarm64)
This problem also in VideoLAN/x264
Link: https://code.videolan.org/videolan/x264/-/m
Martin Storsjö:
> On Thu, 22 May 2025, James Almer wrote:
>
>> ffmpeg | branch: master | James Almer | Thu May 22
>> 19:23:35 2025 -0300| [622a72b5ea5f2022b173355d65d513df2d75000b] |
>> committer: James Almer
>>
>> tests/fate/ac3: add a second ac3_fixed encoder test
>>
>> Exercising the lavfi fil
On Fri, 23 May 2025, 04:44 Lynne, wrote:
> On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote:
> > Hello,
> >
> > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > maintenance of FFmpeg.
>
> It isn't -- it's research.
>
STF isn't for "fun things I want to work on"
I a
60 matches
Mail list logo
