From: softworkz
Signed-off-by: softworkz
---
doc/muxers.texi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 6d5c17b4cc..1cca8da1fb 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -3510,6 +3510,13 @@ packet written. Defaults to @code{0}.
From: softworkz
Signed-off-by: softworkz
---
libavformat/segment.c | 48 +--
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 3cd9e313f4..8e1e4a9c0c 100644
--- a/libavformat/segment.c
+++
On Fri, 13 Jun 2025, Tristan Matthews wrote:
On Thu, Jun 12, 2025 at 4:14 PM Martin Storsjö wrote:
On Thu, 12 Jun 2025, Tristan Matthews wrote:
---
tests/checkasm/h264dsp.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/checkasm/h264dsp.c b/t
From: softworkz
Signed-off-by: softworkz
---
libavformat/segment.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 15196b6970..70ff01b353 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -905,6 +905,7 @@ static int seg_wri
> -Original Message-
> From: softworkz
> Sent: Freitag, 13. Juni 2025 07:54
> To: ffmpeg-devel@ffmpeg.org
> Cc: softworkz ; softworkz
>
> Subject: [PATCH 06/10] avformat/segment: Fix invalid codecpar
> extradata_size after copying
>
> From: softworkz
>
> Signed-off-by: softworkz
>
From: softworkz
Also moves point of log writing to after rename of temp files
and changes log level to INFO. The completion of a segment is
important enough to justify logging at INFO level.
Signed-off-by: softworkz
---
libavformat/segment.c | 10 --
1 file changed, 8 insertions(+), 2
From: softworkz
Signed-off-by: softworkz
---
libavformat/segment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index c2b09b08aa..3cd9e313f4 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -20,7 +20,7 @@
/
From: softworkz
Signed-off-by: softworkz
---
libavformat/segment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 83b7ff269b..c2b09b08aa 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -1098,7 +1098,7 @@
From: softworkz
Use case is to keep early content out of the first segment when
not starting from zero.
Signed-off-by: softworkz
---
libavformat/segment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 70ff01b353..83b7ff2
From: softworkz
Example use case:
Existing segments 0-30 and 70-99, 31-69 need to be created.
This option allows to stop precisely after 69. Otherwise it would
start overwriting segment 70 before stopping via 'q' or break signal.
Signed-off-by: softworkz
---
libavformat/segment.c | 12 +++
From: softworkz
Signed-off-by: softworkz
---
doc/muxers.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 30c95c3d34..6d5c17b4cc 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -3505,6 +3505,11 @@ argument must be a time duration specifi
From: softworkz
Allows to write segments as temp files (.tmp) which
are renamed on completion.
Signed-off-by: softworkz
---
libavformat/segment.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
in
Includes
* Two new options
* segment_write_temp
Allows to write segments as temp files (.tmp) which are renamed on
completion
* segment_limit Stop after n segments have been written
* Improved logging
* some minor changes (option contraints and formatting fixes)
softworkz (10):
> On Jun 8, 2025, at 08:25, Jack Lau via ffmpeg-devel
> wrote:
>
> api doc: https://docs.openssl.org/1.0.2/man3/BIO_s_mem
>
> In higher versions (openssl 1.0.2 and higher),
> the function signature is BIO *BIO_new_mem_buf(const void *buf, int len),
> so passing a const string doesn't cause an
--- Begin Message ---
replace AV_OPT_FLAG_DECODING_PARAM to ENCODING
mark this ignore_ipv6 flag could ignore any ipv6 ICE candidate,
preventing “No route to host” errors on devices without IPv6 connectivity.
Signed-off-by: Jack Lau
---
libavformat/whip.c | 25 +++--
1 file c
--- Begin Message ---
Signed-off-by: Jack Lau
---
libavformat/whip.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/libavformat/whip.c b/libavformat/whip.c
index 84c2092e5e..ef219defb7 100644
--- a/libavformat/whip.c
+++ b/libavformat/whip.c
@@ -1898,13
---
tests/checkasm/h264dsp.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
index d1228ed985..96540565af 100644
--- a/tests/checkasm/h264dsp.c
+++ b/tests/checkasm/h264dsp.c
@@ -22,6 +22,7 @@
#include "ch
On Thu, Jun 12, 2025 at 4:14 PM Martin Storsjö wrote:
>
> On Thu, 12 Jun 2025, Tristan Matthews wrote:
>
> > ---
> > tests/checkasm/h264dsp.c | 37 +
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
> >
Hi,
I have some questions regarding code style.
1. White space
==
Do we prefer this
(float)(*times)[i] / 100, (float)(*times)[I - 1] / 100);
or this
(float)(*times)[i]/100, (float)(*times)[i-1]/100);
2. Multiline Ternary Expressions
On Thu, 12 Jun 2025 17:09:35 +0200 Guillaume Khayat
wrote:
> Hi Niklas,
>
> Awesome!
>
> > To be clear, you are fine with me taking your existing SIMD code as a
> > starting point?
> Yes I am
>
> > Out of curiousity, did you try the "loudnorm" filter as well?
> Yes, it’s significantly slower.
>
From: Niklas Haas
Instead of having a planar array for each channel, use a single packed array.
This will help processing multiple channels in parallel, as we can directly
load all channels' data in a single load instruction.
Also improves memory locality of data, as the loop order is:
for (sam
From: Niklas Haas
Simplifies the code a bit. In particular, the copy to the stack is marginally
faster.
---
libavfilter/f_ebur128.c | 52 +++--
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
in
From: Niklas Haas
We don't need an X sample cache anymore, and we also can simplify the
access macro slightly.
---
libavfilter/f_ebur128.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index 1
From: Niklas Haas
Instead of direct form I. See af_biquads.c for math. Also eliminate
an unnecessary indirection.
---
libavfilter/f_ebur128.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index 768f062bac..173a4
Some low-hanging fruit for the EBUR128 filter, mostly aimed at cleaning
this code up a bit for a proper SIMD implementation.
I have a separate branch where I am working on an AVX2/FMA3 version, but
I wanted to send these quick fixes ahead of time.
___
f
On Thu, 12 Jun 2025, Tristan Matthews wrote:
---
tests/checkasm/h264dsp.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
index d1228ed985..5fba31cf69 100644
--- a/tests/checkasm/h264dsp.c
+++ b/tests/c
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Donnerstag, 12. Juni 2025 21:07
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] tools/ffmpeg-sg: Include
> show-graph wrapper script in build out
softworkz . (HE12025-06-12):
> "better" would be worse, so that's not gonna happen.
Then your patch is not going to happen.
> The way how the feature is meant to work is laid out clearly:
If you cannot find a way to do this without copying the script, you need
to give up and try something easier
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Donnerstag, 12. Juni 2025 09:41
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] tools/ffmpeg-sg: Include
> show-graph wrapper script in build out
> On Jun 13, 2025, at 00:03, Martin Storsjö wrote:
>
> On Thu, 12 Jun 2025, Zhao Zhili wrote:
>
>> From: Zhao Zhili
>>
>> ---
>> libavformat/movenc.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> index cd5b45f6fe..93af0723db 1
From: Zhao Zhili
The segment_duration must not be set to zero when writing the moov
atom for the second time. This is related to edit lists in standard
MP4 files.
---
libavformat/movenc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavfor
---
tests/checkasm/h264dsp.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
index d1228ed985..5fba31cf69 100644
--- a/tests/checkasm/h264dsp.c
+++ b/tests/checkasm/h264dsp.c
@@ -22,6 +22,7 @@
#include
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marvin Scholz
> Sent: Donnerstag, 12. Juni 2025 19:07
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/4] fftools/textformat: narrow
> variable scopes
>
>
>
> On 12 Jun
On 12 Jun 2025, at 18:10, softworkz . wrote:
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Marvin Scholz
>> Sent: Donnerstag, 12. Juni 2025 13:25
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [PATCH 1/4] fftools/textf
On Thu, Jun 12, 2025 at 12:27 PM Maryla Ustarroz-Calonge via
ffmpeg-devel wrote:
> -- Forwarded message --
> From: Maryla Ustarroz-Calonge
> To: ffmpeg-devel@ffmpeg.org
> Cc:
> Bcc:
> Date: Thu, 12 Jun 2025 18:27:43 +0200
> Subject: [PATCH] avcodec/itut35: always check the provide
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marvin Scholz
> Sent: Donnerstag, 12. Juni 2025 13:34
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 3/4] fftools/textformat: infer
> type in mermaid_print_value
>
>
>
>
--- Begin Message ---
From: Maryla
ITU-T T.35 provider codes are attributed by national bodies and it's
possible to have collisions across countries. This is why the country code
must always be checked as well.
In the code this could be done by having an outer switch on the country code,
then an
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marvin Scholz
> Sent: Donnerstag, 12. Juni 2025 13:25
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/4] fftools/textformat: narrow
> variable scopes
>
>
>
> On 12 Jun
On Thu, 12 Jun 2025, Zhao Zhili wrote:
From: Zhao Zhili
---
libavformat/movenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index cd5b45f6fe..93af0723db 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7781,6 +7781,11 @@
From: Zhao Zhili
---
libavformat/movenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index cd5b45f6fe..93af0723db 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7781,6 +7781,11 @@ static int mov_init(AVFormatContext *s)
On Thu, Jun 12, 2025 at 5:33 PM Zhao Zhili
wrote:
>
> From: Zhao Zhili
>
> ---
> libavcodec/mediacodecdec.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 4937828f21..ea9362ba85 100644
> --- a/l
From: Zhao Zhili
---
libavcodec/mediacodecdec.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 4937828f21..ea9362ba85 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -133,14
Hi Niklas,
Awesome!
> To be clear, you are fine with me taking your existing SIMD code as a
> starting point?
Yes I am
> Out of curiousity, did you try the "loudnorm" filter as well?
Yes, it’s significantly slower.
Last i checked it was 30x realtime. I measured ebur128 at 200x with peak=true,
On Thu, 12 Jun 2025 16:49:34 +0200 Guillaume Khayat
wrote:
> Hello,
>
> The small company I work at uses ebur128 filter.
>
> I’m offering a bounty to improve the filter’s performance on x86 machines.
>
> I’m offering 800 EUR per 10% gain from current baseline, up to 50%/4000 EUR.
>
> I’m aware of
Hello,
The small company I work at uses ebur128 filter.
I’m offering a bounty to improve the filter’s performance on x86 machines.
I’m offering 800 EUR per 10% gain from current baseline, up to 50%/4000 EUR.
I’m aware of 2 recent, promising initiatives to improve performance:
- our own incomple
From: Niklas Haas
Implementation is the same as 8 bit formats, just right shifted to 8 bits.
It's worth pointing out that this also works for HDR formats (and even DV),
because the underlying implementation is just trying to minimize the histogram
difference. If anything, using a HDR format will
> please keep the functions in the same order so that a diff between
> new libavfilter/perspective.c
> and
> old libavfilter/vf_perspective.c
>
> is easy readable
>
> thx
Sure thing, is that better?
Signed-off-by: Quentin Renard
---
libavfilter/Makefile | 2 +-
libavfilter/perspecti
On Thu, Jun 12, 2025 at 1:53 AM Marvin Scholz <
epirat07-at-gmail@ffmpeg.org> wrote:
> When checking for filmgrain here, needs_fg can be true even when
> film_grain_characteristics is NULL (when aom_film_grain.enable is true),
> therefore this check could end up dereferencing film_grain_charac
On Thu, Jun 12, 2025 at 2:52 AM Marvin Scholz <
epirat07-at-gmail@ffmpeg.org> wrote:
> While the current code iterated over the messages, it always returned
> in the first iteration. Instead keep iterating and warn for failure to
> parse. At time of writing, none of the parsing functions seems
On 12 Jun 2025, at 4:26, softworkz . wrote:
> Hi Marvin,
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Marvin Scholz
>> Sent: Mittwoch, 11. Juni 2025 22:42
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH 1/4] fftools/textformat: narrow
>> variable scope
On Thu, Jun 12, 2025 at 11:38:59AM +0200, Quentin RENARD wrote:
> As mentioned here
> (https://ffmpeg.org/pipermail/ffmpeg-devel/2025-June/344593.html), this is
> the first step of a 2 steps patch: move the interpolation code out of the
> vf_perspective filter so that we can use it in a new zoom
On Thu, 12 Jun 2025, Jiawei wrote:
This patch modifies the FFmpeg build system to allow GCC to use the
`-ftree-vectorize` flag when the compiler version is 13 or newer.
Enabling this flag can improve performance through better loop analysis
and auto-vectorization (SIMD) opportunities in modern G
Hi Romain
On Tue, Jun 10, 2025 at 01:04:35PM -0500, Romain Beauxis wrote:
> 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 add
--- Begin Message ---
Hi Devin,
I saw your patch but noticed it was still not merged. Since it’s more
comprehensive, I’m all for merging your patch instead of mine if it’s not too
stale.
Best,
Pierre
From: ffmpeg-devel on behalf of Devin
Heitmueller
Date: Wednesday, 11 June 2025 at 16:32
To:
On 12 Jun 2025, at 4:19, softworkz . wrote:
> Hi Marvin,
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Marvin Scholz
>> Sent: Mittwoch, 11. Juni 2025 21:57
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH 3/4] fftools/textformat: infer type in
>> mermaid
On Thu, 12 Jun 2025, Jiawei wrote:
This patch modifies the FFmpeg build system to allow gcc use '-ftree-vectorize'
option in newer releases.
Modern GCC versions can be benefit when using the `-ftree-vectorize` flag.
Through it can optimizations in loop analysis and SIMD code generation.
Versio
On Thu, 12 Jun 2025, Martin Storsjö wrote:
On Thu, 12 Jun 2025, Jiawei wrote:
This patch modifies the FFmpeg build system to allow gcc use
'-ftree-vectorize'
option in newer releases.
Modern GCC versions can be benefit when using the `-ftree-vectorize` flag.
Through it can optimizations in l
On Mon, 31 Mar 2025, Kacper Michajłow wrote:
Clang x86_64-pc-windows-msvc doesn't define __GNUC__.
Signed-off-by: Kacper Michajłow
---
libavformat/internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index fe428d85eb..bf8
On Mon, 31 Mar 2025, Kacper Michajłow wrote:
Fixes use of bultins on clang x86_64-pc-windows-msvc which does not
define any __GNUC__. Also on other targets __GNUC__ is defined to 4 by
default, so any feature testing based on version is not really valid.
Signed-off-by: Kacper Michajłow
---
liba
On Thu, 29 May 2025, Zhao Zhili wrote:
On May 29, 2025, at 15:03, Jiawei wrote:
This patch modifies the FFmpeg build system to remove the explicit disabling
of GCC's auto-vectorization feature.
Modern GCC versions have demonstrated stable auto-vectorization capabilities
through extensive opti
This fixes building with Clang in MSVC mode, for x86, which was
broken in 6e49b8699657b808b7dc80033f2c3f2d0e029fa3 (in Nov 2024);
previously it failed with undefined symbols for the constants
defined with DECLARE_ASM_CONST, accessed via inline assembly.
Before 57861911a34e1c33796be97f2b2f44e05fffd
The main reason behind this change is adding floating point precision to
scale/crop to the zoompan filter. However the current zoompan filter have a few
things that don’t fit my use case:
- output aspect ratio is forced to be the same as the input aspect ratio
- output size can't be dynamic
- PT
As mentioned here
(https://ffmpeg.org/pipermail/ffmpeg-devel/2025-June/344593.html), this is the
first step of a 2 steps patch: move the interpolation code out of the
vf_perspective filter so that we can use it in a new zoompan filter and apply
scale/crop floating point precision there.
Signed
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marvin Scholz
> Sent: Mittwoch, 11. Juni 2025 21:57
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 4/4] fftools/textformat: remove
> leftover comments in mermaid_print_value
>
> Remove some leftover commented code
Hi,
Could you please check and review this patch?
From: ffmpeg-devel on behalf of Logaprakash
Ramajayam
Sent: Friday, June 6, 2025 2:14 PM
To: Kieran Kunhya via ffmpeg-devel
Cc: Dash Santosh Sathyanarayanan ;
Harshitha Sarangu Suresh
Subject: [FFmpeg-devel] [P
softworkz . (HE12025-06-11):
> On important platforms like Windows, there is no "install". People are
> taking/copying the build output. If it's not part of the build output,
> it won't arrive at any user.
Oh, we did not think of that in the past 20 years, and we could not
consider it to decide th
66 matches
Mail list logo
