> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: Dienstag, 3. Juni 2025 16:34
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib
> directly instead of gzip
>
Hi Andreas,
thinking about the direction
Hi Pavel
On Tue, Jun 10, 2025 at 11:27:37AM -0600, Pavel Koshevoy wrote:
> On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer
[...]
> I have never had any intention of introducing a
> security vulnerability.
do you agree that the patch should be reverted ?
(and also the 2 backports of it)
>
It's set during int and never changed.
Signed-off-by: James Almer
---
libavutil/aes.c | 10 +-
libavutil/aes_internal.h | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavutil/aes.c b/libavutil/aes.c
index 3c8ac1c349..7fe42a5548 100644
--- a/libavutil/a
This is in preparation for the following commit, to prevent redefinitions from
namespace collisions.
Signed-off-by: James Almer
---
libavutil/aes_ctr.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavutil/aes_ctr.c b/libavutil/aes_ctr.c
index 63dcb20d3
OpenSSL has optimizations for more architectures than x86-AESNI, so use it if
libavutil is configured with libcrypto explicitly (Enabling OpenSSL alone will
not make use of it).
Signed-off-by: James Almer
---
configure| 8 +++-
libavutil/aes.c | 37 +
> On Jun 11, 2025, at 13:55, Andreas Rheinhardt
> wrote:
>
> Zhao Zhili:
>> From: Zhao Zhili
>>
>> This is a regression since 1c170613.
>> ---
>> libavcodec/decode.c | 11 ---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/decode.c b/libavcodec/decod
Zhao Zhili:
> From: Zhao Zhili
>
> ---
> The sample comes from
> https://trac.ffmpeg.org/attachment/ticket/959/12%2027_Volcano%20Zoom-Dissolve-F-8.mov
> put it to mjpegb/media100.mov
>
> tests/fate/video.mak| 3 +++
> tests/ref/fate/media100 | 30 ++
> 2 files
Zhao Zhili:
> From: Zhao Zhili
>
> This is a regression since 1c170613.
> ---
> libavcodec/decode.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index ef09568381..7e47a2971c 100644
> --- a/libavcodec/decode.c
>
James Almer:
> OpenSSL has optimizations for more architectures than x86-AESNI, so use it if
> libavutil is configured with libcrypto explicitly (Enabling OpenSSL alone will
> not make use of it).
>
> Signed-off-by: James Almer
> ---
> configure| 8 +++-
> libavutil/aes.c
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
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
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
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
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 | 28 +++
libswsc
From: Niklas Haas
Like av_memdup() but correctly rounds up to the nearest power of two so that
av_dynarray2_add() will continue to work on the duplicated list.
---
libavutil/mem.c | 9 +
libavutil/mem.h | 14 ++
2 files changed, 23 insertions(+)
diff --git a/libavutil/mem.c
From: Niklas Haas
This adds an internal API for ops backends, which are responsible for
compiling op lists into executable functions.
---
libswscale/ops.c | 65 +++
libswscale/ops_internal.h | 108 ++
2 files changed, 173 insertio
From: Niklas Haas
See doc/swscale-v2.txt for design details.
---
libswscale/Makefile| 1 +
libswscale/ops_chain.c | 291 +
libswscale/ops_chain.h | 134 +++
3 files changed, 426 insertions(+)
create mode 100644 libswscale/ops_chain.c
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
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
Now, make it a Killer-Feature!
---
libswscale/graph.c | 84 --
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/libswscale/graph.c b/libswscale/graph.c
index edf243823f..c72bc6540f 100644
--- a/libswscale/graph.c
+++ b/l
Niklas Haas:
> On Tue, 10 Jun 2025 15:04:57 +0200 Niklas Haas wrote:
>> From: Niklas Haas
>>
>> Like av_memdup() but correctly rounds up to the nearest power of two so that
>> av_dynarray2_add() will continue to work on the duplicated list.
>
> Just realized this is public, will add a Changelog
On Tue, 10 Jun 2025 15:04:57 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> Like av_memdup() but correctly rounds up to the nearest power of two so that
> av_dynarray2_add() will continue to work on the duplicated list.
Just realized this is public, will add a Changelog entry and bump the API
Niklas Haas:
> On Tue, 10 Jun 2025 15:55:35 +0200 Andreas Rheinhardt
> wrote:
>> Niklas Haas:
>>> On Tue, 10 Jun 2025 15:04:57 +0200 Niklas Haas wrote:
From: Niklas Haas
Like av_memdup() but correctly rounds up to the nearest power of two so
that
av_dynarray2_add() wil
--- Begin Message ---
opt_codec() is mostly copied over from ffplay.c
Signed-off-by: Maryla Ustarroz-Calonge
---
Changelog | 2 +-
fftools/ffprobe.c | 114 +-
2 files changed, 103 insertions(+), 13 deletions(-)
diff --git a/Changelog b/Chang
On Tue, Jun 10, 2025 at 4:11 PM Michael Niedermayer
wrote:
> Hi Pavel
>
> On Tue, Jun 10, 2025 at 11:27:37AM -0600, Pavel Koshevoy wrote:
> > On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer <
> mich...@niedermayer.cc>
> [...]
>
> > I have never had any intention of introducing a
> > security
---
libavutil/vulkan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
index
a989e080abd372b8977dce107100b9370fac8305..eea80d0775a87ed6683cb58d30ba9ba8d6c1dd26
100644
--- a/libavutil/vulkan.c
+++ b/libavutil/vulkan.c
@@ -298,6 +298,8 @@ void ff_vk_ex
: fix FFVkSPIRVCompiler leak
libavcodec/vulkan_ffv1.c | 60
libavutil/vulkan.c | 2 ++
2 files changed, 27 insertions(+), 35 deletions(-)
---
base-commit: 4059bce713118f961d24b5f08a4881c5e7214f9b
change-id: 20250610-vk-ffv1-leaks-7f0722236745
---
libavcodec/vulkan_ffv1.c | 58 +++-
1 file changed, 23 insertions(+), 35 deletions(-)
diff --git a/libavcodec/vulkan_ffv1.c b/libavcodec/vulkan_ffv1.c
index
8329b5d7dfad18de96884ea2c1f6f186682e430c..b02bc71683fd7d06dad3f4cf667ee3e8c57f3c83
100644
---
libavcodec/vulkan_ffv1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/vulkan_ffv1.c b/libavcodec/vulkan_ffv1.c
index
c839f4c3879e158e0c0bfb4f5a833fff0b83d2f0..8329b5d7dfad18de96884ea2c1f6f186682e430c
100644
--- a/libavcodec/vulkan_ffv1.c
+++ b/libavcodec/vulkan_ffv1.c
@@
On Tue, 10 Jun 2025, Andreas Rheinhardt wrote:
Tomas Härdin:
Hi
These two patches are a bit of a warmup for another pass at streamable
subtitles. FATE passes.
/Tomas
Users who want this should set the generic flush_packets options
appropriately.
Agreed, explicit avio_flush() in packet w
change-id: 20250610-vk-ffv1-leaks-7f0722236745
Best regards,
LGTM
Thanks, pushed the patchset.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel
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
@@
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
On Mon, Jun 09, 2025 at 09:45:28PM -0600, Pavel Koshevoy wrote:
> Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> commit 0021484d05f9b0f032fa319399de6e24eea0c04f
>
> codec_close should not assume that the codec_id did not change.
> ---
> libavformat/demux.c | 8 +++-
> 1 file changed, 7
> -Original Message-
> From: Kieran Kunhya
> Sent: Dienstag, 10. Juni 2025 00:49
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: softworkz
> Subject: Re: [FFmpeg-devel] [PATCH 0/3] tools/ffmpeg-sg: Add show-
> graph wrapper scripts (aka killer feature)
>
> On Mo
From: Zhao Zhili
---
The sample comes from
https://trac.ffmpeg.org/attachment/ticket/959/12%2027_Volcano%20Zoom-Dissolve-F-8.mov
put it to mjpegb/media100.mov
tests/fate/video.mak| 3 +++
tests/ref/fate/media100 | 30 ++
2 files changed, 33 insertions(+)
creat
From: Zhao Zhili
This is a regression since 1c170613.
---
libavcodec/decode.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index ef09568381..7e47a2971c 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -204,
Changes since v4:
- minor cosmetic fixes
- drop unneeded -Wno-uninitialized (breaks on MSVC)
- change semantics of SwsGraph.setup() to make more sense (and fix
a bug where it would not work correctly with multiple passes)
- introduce and use av_dynarray2_dup() instead of av_memdup() for safely
From: Niklas Haas
This behavior had no real justification and was just incredibly confusing,
since the in/out pointers passet to setup() did not match those passed to
run(), all for what is arguably an exception anyways (the palette setup).
---
libswscale/graph.c | 12
libswscale/gr
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> softworkz .
> Sent: Dienstag, 10. Juni 2025 15:32
> To: Kieran Kunhya ; FFmpeg development
> discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH 0/3] tools/ffmpeg-sg: Add show-
> graph wrapper scripts (aka killer feature
Hi Pavel
On Tue, Jun 10, 2025 at 08:42:08AM -0600, Pavel Koshevoy wrote:
> On Tue, Jun 10, 2025, 07:39 Michael Niedermayer
> wrote:
>
> > On Mon, Jun 09, 2025 at 09:45:28PM -0600, Pavel Koshevoy wrote:
> > > Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> > > commit 0021484d05f9b0f032fa3193
On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer
wrote:
> Hi Pavel
>
> On Tue, Jun 10, 2025 at 08:42:08AM -0600, Pavel Koshevoy wrote:
> > On Tue, Jun 10, 2025, 07:39 Michael Niedermayer
> > wrote:
> >
> > > On Mon, Jun 09, 2025 at 09:45:28PM -0600, Pavel Koshevoy wrote:
> > > > Fixes 'ffprob
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
On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer
wrote:
> Hi Pavel
>
>
>
> is adding an exploitable security issue an option for you ?
>
>
^ that's inflammatory, I have never had any intention of introducing a
security vulnerability.
If people want to keep this, it should be behind a flag
Pavel Koshevoy (HE12025-06-10):
> ^ that's inflammatory
No, that is just sarcastic.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
f
On Tue, Jun 10, 2025 at 11:31 AM Nicolas George wrote:
> Pavel Koshevoy (HE12025-06-10):
> > ^ that's inflammatory
>
> No, that is just sarcastic.
>
>
it managed to ruin my morning ... no matter what you call it.
Pavel.
___
ffmpeg-devel mailing list
f
Hi all,
Le mer. 4 juin 2025 à 11:58, Romain Beauxis a écrit :
>
> This is a redo of 574f634e49847e2225ee50013afebf0de03ef013 using a flat
> memory storage for the extradata.
>
> PR review comments addressed:
> * Use flat memory bytestream
> * Re-use existing xiph extradata layout
Is there any i
> WebVTT is supposed to be an extensible format. Limiting to a small set of
> known values and silently aborting when anything new is introduced does
> not seem like the best option to me. Web browsers do not stop rendering
> pages when they see a new, unknown HTML tag or CSS option.
About this, f
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
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 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
On Tue, 10 Jun 2025 15:55:35 +0200 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > On Tue, 10 Jun 2025 15:04:57 +0200 Niklas Haas wrote:
> >> From: Niklas Haas
> >>
> >> Like av_memdup() but correctly rounds up to the nearest power of two so
> >> that
> >> av_dynarray2_add() will continue to work
On Tue, Jun 10, 2025, 07:39 Michael Niedermayer
wrote:
> On Mon, Jun 09, 2025 at 09:45:28PM -0600, Pavel Koshevoy wrote:
> > Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> > commit 0021484d05f9b0f032fa319399de6e24eea0c04f
> >
> > codec_close should not assume that the codec_id did not chang
--- Begin Message ---
This muxer has been marked AVFMT_EXPERIMENTAL.
Add a note in muxers.texi that WHIP is an experimental feature
This patch doesn't effect WHIP usage command, as WHIP always
needs to be explicitly specified
The details as follows:
https://ffmpeg.org/pipermail/ffmpeg-devel/2025
55 matches
Mail list logo
