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
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
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 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:
>
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
---
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
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
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
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
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 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
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 |
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 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
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
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
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,
>
>
> 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
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
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
>>
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
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
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
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 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
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
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
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
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 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 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
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 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:
> >>
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 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 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, 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
> -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
> -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
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/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
---
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
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
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
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
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:
> > > >
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
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/
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
60 matches
Mail list logo
