On 2025-06-18 03:03 am, Tomas Härdin wrote:
fre 2025-06-13 klockan 20:07 +0530 skrev Gyan Doshi:
On 2025-06-13 04:25 pm, Tomas Härdin wrote:
The present level of
edit list support could be reimplemented by just fiddling with the
-ss
and -t options. That is, the ffmpeg CLI could automatically
Hi Tomas
On Tue, Jun 17, 2025 at 11:15:25PM +0200, Tomas Härdin wrote:
> fre 2025-06-13 klockan 18:19 +0200 skrev Michael Niedermayer:
[...]
> > > > > The main issue I see with this is that it risks turning ffmpeg
> > > > > into
> > > > > an
> > > > > NLE tool,
> > > >
> > > > If ffmpeg could do
On 6/17/2025 8:19 PM, Peter Ross wrote:
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index e2e9fc26d8..bfe5f5bbee 100755
--- a/configure
+++ b/configure
@@ -2869,6 +2869,7 @@ w32threads_deps="atomics_native"
threads_if_any="$THREADS_LIST"
# sub
Hi Martin
On Fri, Jun 13, 2025 at 01:57:05PM +0300, Martin Storsjö wrote:
> If there were failures while running tests, e.g. if failing to
> compile checkasm or any other of the test programs, there are no
> failed tests per se, and the number of succeessful tests is
> equal to the total number of
Signed-off-by: James Almer
---
libavformat/iamf_writer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/iamf_writer.c b/libavformat/iamf_writer.c
index ad40871fa1..4302df7931 100644
--- a/libavformat/iamf_writer.c
+++ b/libavformat/iamf_writer.c
@@ -783,7 +783
Signed-off-by: James Almer
---
libavformat/iamf_writer.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavformat/iamf_writer.c b/libavformat/iamf_writer.c
index 37e75dc01a..ad40871fa1 100644
--- a/libavformat/iamf_writer.c
+++ b/libavformat/iamf_writer.c
@
Signed-off-by: James Almer
---
libavformat/iamf_writer.c | 40 ---
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git a/libavformat/iamf_writer.c b/libavformat/iamf_writer.c
index 635d1989ef..37e75dc01a 100644
--- a/libavformat/iamf_writer.c
+++ b/lib
Signed-off-by: James Almer
---
libavformat/iamf_writer.c | 65 +++
1 file changed, 39 insertions(+), 26 deletions(-)
diff --git a/libavformat/iamf_writer.c b/libavformat/iamf_writer.c
index 86d09c3308..635d1989ef 100644
--- a/libavformat/iamf_writer.c
+++ b/li
The way streams are coded in an IAMF struct follows a scalable model where the
channel layouts for each layer may not match the channel order our API can
represent in a Native order layout.
For example, an audio element may have six coded streams in the form of two
stereo streams, followed by two
Cosmetic change to reflect the actual channels used in the layouts.
Signed-off-by: James Almer
---
tests/fate/iamf.mak | 2 +-
tests/fate/mov.mak| 2 +-
tests/filtergraphs/iamf_5_1_4 | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/fate/iamf.mak
Follows the proper order defined by the spec, even if mostly cosmetic, and is
also preparation for a following change.
Signed-off-by: James Almer
---
tests/fate/iamf.mak | 4 +-
tests/fate/mov.mak| 4 +-
tests/ref/fate/iamf-9_1_6 | 82 +++
3 fi
In most cases, the channel ids will match the standard Ambisonic Order, saving
us the
need to use a custom order layout.
Signed-off-by: James Almer
---
libavformat/iamf_parse.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/iamf_parse.c b/libavforma
Signed-off-by: James Almer
---
libavformat/iamf_writer.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/libavformat/iamf_writer.c b/libavformat/iamf_writer.c
index 60a0990504..e34afb9a2c 100644
--- a/libavformat/iamf_writer.c
+++ b/libavformat/iamf_w
Signed-off-by: Michael Niedermayer
---
FATE.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/FATE.pm b/FATE.pm
index 0d4603f..d74fd00 100644
--- a/FATE.pm
+++ b/FATE.pm
@@ -43,7 +43,7 @@ our $recent_age = 3600;
our $ancient_age = 3 * 86400;
our $hidden_age = 30 * 86400;
On Wed, Jun 18, 2025 at 09:14:40AM +1000, Peter Ross wrote:
> On Tue, Jun 17, 2025 at 10:32:16PM +0200, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/osq.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/osq.c b/libavcodec/os
On Tue, Jun 17, 2025 at 09:29:01AM +0200, Timothee wrote:
> Context from the first version :
>
> > Here is a patch where I fixed the attach of per-macroblock qp tables for
> > H.264. It was implemented for MPEG2 so I have only extended it.
> >
> > I tested the functionality with the codecview fil
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index bfe5f5bbee..4dfe0c7114 100755
--- a/configure
+++ b/configure
@@ -3411,7 +3411,7 @@ h264_qsv_encoder_select="atsc_a53 qsvenc"
h264_rkmpp_decoder_deps="rkmpp"
h264_rkmpp_decoder_select="h
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index e2e9fc26d8..bfe5f5bbee 100755
--- a/configure
+++ b/configure
@@ -2869,6 +2869,7 @@ w32threads_deps="atomics_native"
threads_if_any="$THREADS_LIST"
# subsystems
+cbs_apv_select="cbs"
cbs_av1_select="
On Tue, Jun 17, 2025 at 10:32:16PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/osq.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/osq.c b/libavcodec/osq.c
> index 025be667a35..0de9af5f623 100644
> --- a/libavcodec/osq.c
> +++
On Tue, 17 Jun 2025 at 20:54, softworkz . wrote:
>
>
> > -Original Message-
> > From: Kacper Michajlow
> > Sent: Tuesday, June 17, 2025 6:36 PM
> > To: softworkz .
> > Cc: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: graph.{html,css} embed failure on W
On Sun, 15 Jun 2025 00:49:42 +0200, Michael Niedermayer wrote:
> the patch seems not to be on the mailing list
> I have v4 in my inbox but not v5, so if the patch is ok, maybe you are
> the only one who can apply it
>
> Maybe Jiawei is not subscribed to the ML so his mails would go to the
> moder
fre 2025-06-13 klockan 20:07 +0530 skrev Gyan Doshi:
>
>
> On 2025-06-13 04:25 pm, Tomas Härdin wrote:
> > The present level of
> > edit list support could be reimplemented by just fiddling with the
> > -ss
> > and -t options. That is, the ffmpeg CLI could automatically derive
> > -ss
> > and -t
On 17.06.2025 01:39, Jorge Estrada wrote:
From: Jorge Estrada <--global>
This patch adds the pad_cuda video filter. A filter similar to the existing pad
filter but accelerated by CUDA.
The filter shares the same options as the software pad filter.
Example usage:
ffmpeg -hwaccel cuda -hwaccel_
fre 2025-06-13 klockan 18:19 +0200 skrev Michael Niedermayer:
> Hi
>
> On Fri, Jun 13, 2025 at 04:53:14PM +0200, Tomas Härdin wrote:
> > fre 2025-06-13 klockan 16:21 +0200 skrev Michael Niedermayer:
> > > > 3) remove edit list hacks from all demuxers, especially mov.c
> > >
> > > +1 (with ABI +2
On Tue, Jun 17, 2025 at 08:39:05PM +0200, Marton Balint wrote:
>
>
> On Tue, 17 Jun 2025, Pavel Koshevoy wrote:
>
> > Make runtime AVStream.codecpar codec_id updates optional and disabled
> > by default, so that avformat API clients can enable this feature explicitly
> > when they add support fo
fre 2025-06-13 klockan 20:27 +0530 skrev Gyan Doshi:
>
>
> On 2025-06-13 08:23 pm, Tomas Härdin wrote:
> > For now I'll probably dummy out elst support and the associated
> > tests
> > just to make progress on segmented indexes.
>
> Does `-ignore_editlist true` not work for your use-case?
The
Signed-off-by: Michael Niedermayer
---
libavcodec/osq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/osq.c b/libavcodec/osq.c
index 025be667a35..0de9af5f623 100644
--- a/libavcodec/osq.c
+++ b/libavcodec/osq.c
@@ -212,6 +212,8 @@ static int osq_channel_parameters(AVCodecContex
On Tue, 17 Jun 2025, Andreas Rheinhardt wrote:
Marton Balint:
On Tue, 17 Jun 2025, Andreas Rheinhardt wrote:
Marton Balint:
Sinks without an activate callback (nullsink, anullsink) could cause
AVERROR(EAGAIN)-s in avfilter_graph_request_oldest() even when all
the filter
graphs inputs wer
On Tue, Jun 17, 2025 at 12:42 PM Marton Balint wrote:
>
>
> On Tue, 17 Jun 2025, Pavel Koshevoy wrote:
>
> > Make runtime AVStream.codecpar codec_id updates optional and disabled
> > by default, so that avformat API clients can enable this feature
> explicitly
> > when they add support for runtim
> -Original Message-
> From: Kacper Michajlow
> Sent: Tuesday, June 17, 2025 6:36 PM
> To: softworkz .
> Cc: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: graph.{html,css} embed failure on Windows build
[..]
> > > > I will wait for the remaining CI build
On Tue, 17 Jun 2025, Pavel Koshevoy wrote:
Make runtime AVStream.codecpar codec_id updates optional and disabled
by default, so that avformat API clients can enable this feature explicitly
when they add support for runtime codec changes.
Accordingly, codec_close should not assume that the co
Sample file for testing:
https://streams.videolan.org/ffmpeg/incoming/encrypted-hca_lowkey-3201512.hca
Use -hca_lowkey 3201512 for decryption.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsub
Need to skip 2 more bytes because comp sections are 12 bytes long.
Fixes decryption since ciph_type is now being set.
Signed-off-by: Pavel Roslyy
---
libavcodec/hcadec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/hcadec.c b/libavcodec/hcadec.c
index feb3dce3de..7780372cf3 100
On Mon, 16 Jun 2025 at 00:25, Emma Worley wrote:
>
> I wasn't able to repro in a windows 11 arm64 VM. It seems the builds at
> fate.ffmpeg.org are also unaffected.
I was actually working on adding another build to fate and while at
it, I made it run also MSVC, just to cross validate the configur
> -Original Message-
> From: ffmpegagent
> Sent: Tuesday, June 17, 2025 6:02 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: softworkz
> Subject: [PATCH v6 0/2] ffbuild/commonmak: Fix rebuild check with implicit
> rule chains
[..]
> V4
> ==
>
> * Always keep .ptx files (as suggested by Timo -
On Tue, 17 Jun 2025 at 18:07, softworkz . wrote:
>
>
>
> > -Original Message-
> > From: Kacper Michajlow
> > Sent: Tuesday, June 17, 2025 6:00 PM
> > To: softworkz .
> > Cc: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: graph.{html,css} embed failure on
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
> -Original Message-
> From: Kacper Michajlow
> Sent: Tuesday, June 17, 2025 6:00 PM
> To: softworkz .
> Cc: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: graph.{html,css} embed failure on Windows build
>
> On Tue, 17 Jun 2025 at 17:29, softworkz . wrot
From: softworkz
This commit simplifies and consolidates all the rules around
ptx and resource file compression.
Signed-off-by: softworkz
---
ffbuild/common.mak | 43 +--
1 file changed, 17 insertions(+), 26 deletions(-)
diff --git a/ffbuild/common.mak b
V2
==
* Fix MSVC build
(use the universal command pattern)
V3
==
* Skip dependency generation by clearing CC_DEPS instead
(as suggested by Ramiro - thanks!)
V4
==
* Always keep .ptx files (as suggested by Timo - thanks) Tested all
scenarios:
* .ptx.c and .ptx.gz still get de
On Tue, 17 Jun 2025 at 17:29, softworkz . wrote:
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > softworkz .
> > Sent: Tuesday, June 17, 2025 4:13 PM
> > To: Kacper Michajlow
> > Cc: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> softworkz .
> Sent: Tuesday, June 17, 2025 4:13 PM
> To: Kacper Michajlow
> Cc: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] graph.{html,css} embed failure on Windows build
>
>
> > --
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Tuesday, June 17, 2025 4:41 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib
> directly instead of gzip
>
> On 6/16/2025 5:18 PM, softworkz . wrote:
> >
On 6/16/2025 5:18 PM, softworkz . wrote:
But why that? If we include the decompression code (that's why I've been
searching for the most compact implementations available with compatible
licenses), then we won't have any zlib dependency anymore - neither at build-
nor at run-time.
We don't add so
On Tue, Jun 17, 2025 at 8:00 AM Pavel Koshevoy wrote:
>
>
> On Tue, Jun 17, 2025, 07:55 Pavel Koshevoy wrote:
>
>> Ping. I think I've addressed the concerns raised with the previous
>> patch.
>> Please let me know if I may commit this... it is a segfault fix, so it
>> probably should get some r
softworkz . (HE12025-06-17):
> I didn't talk about a zlib replacement. It is about any kind of
> compression code, not needing to be zlib compatible at all.
I know you did not talk about it. I am trying to get you to understand
the only case that would be acceptable.
Once again, in uppercase in c
Make runtime AVStream.codecpar codec_id updates optional and disabled
by default, so that avformat API clients can enable this feature explicitly
when they add support for runtime codec changes.
Accordingly, codec_close should not assume that the codec_id cannot change.
This fixes 'ffprobe 1_poc.m
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Tuesday, June 17, 2025 4:09 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib
> directly instead of gzip
>
> soft
Sorry I send this patch again. Please Ignore:
https://ffmpeg.org/pipermail/ffmpeg-devel/2025-June/345436.html
Thanks,
Lidong
Michael Niedermayer 于2025年6月16日周一 07:38写道：
> On Sat, Jun 14, 2025 at 05:08:36PM +0800, Zhao Zhili wrote:
> >
> >
> > > On Jun 14, 2025, at 16:33, Lidong Yan <
> yldhome
On 6/17/2025 11:23 AM, Nicolas George wrote:
Lidong Yan (HE12025-06-17):
In sbg_read_header(), if avformat_new_stream() failed, it returns
without cleanup, which may cause memory leaks. Replace return statement
with goto so that we would first clean up then return.
Signed-off-by: Lidong Yan <50
Lidong Yan (HE12025-06-17):
> In sbg_read_header(), if avformat_new_stream() failed, it returns
> without cleanup, which may cause memory leaks. Replace return statement
> with goto so that we would first clean up then return.
>
> Signed-off-by: Lidong Yan <502024330...@smail.nju.edu.cn>
> ---
>
In config_input(), fir_to_phase() allocates memory in h[longer].
But if av_calloc() to s->coeffs failed, memory in h[longer] would
leak. Add av_free(h[longer]) in !s->coeffs path.
Signed-off-by: Lidong Yan <502024330...@smail.nju.edu.cn>
---
libavfilter/asrc_sinc.c | 4 +++-
1 file changed, 3 ins
In sap_write_header(), ff_format_set_url() assign new allocated new_url
to contexts[i]->url but forgot to free it later. Add two loops to free
contexts[i]->url before av_free(context).
Signed-off-by: Lidong Yan <502024330...@smail.nju.edu.cn>
---
libavformat/sapenc.c | 6 ++
1 file changed, 6
In sbg_read_header(), if avformat_new_stream() failed, it returns
without cleanup, which may cause memory leaks. Replace return statement
with goto so that we would first clean up then return.
Signed-off-by: Lidong Yan <502024330...@smail.nju.edu.cn>
---
libavformat/sbgdec.c | 6 --
1 file ch
In libavformat/rtmpproto.c:gen_connect(), if check on string length
or check on codec fourcc failed, ff_rtmp_packet_create() allocated
data in pkt would leak. Add ff_rtmp_packet_destory before return error
code.
Signed-off-by: Lidong Yan <502024330...@smail.nju.edu.cn>
---
libavformat/rtmpproto.c
This patch series fixes multiple memory leaks in the following files:
libavformat/rtmpproto.c, libavfilter/asrc_sinc.c, libavformat/sbgdec.c,
and libavformat/sapenc.c.
-BEGIN PGP PUBLIC KEY BLOCK-
mDMEaEpkmRYJKwYBBAHaRw8BAQdAGwGqH/Dwod+i6kR0/Rhn5GanJ7wK8mM9tWP/
W2qu8Ti0HTUwMjAyNDMzMDA1NkB
> -Original Message-
> From: Kacper Michajlow
> Sent: Tuesday, June 17, 2025 4:06 PM
> To: softworkz .
> Cc: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: graph.{html,css} embed failure on Windows build
>
> On Tue, 17 Jun 2025 at 15:10, Kacper Michajlow
softworkz . (HE12025-06-17):
> It's not about replacing zlib in general. The scope is having our own
> compression
> code for ptx and resource compression only.
This is what I understood. So let me tell it once again more concisely:
If you can write a zlib replacement specifically for FFmpeg wit
> On Jun 15, 2025, at 23:54, Andreas Rheinhardt
> wrote:
>
> Jack Lau via ffmpeg-devel:
>> diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
>> index 86e8935fee..2a3905891d 100644
>> --- a/libavformat/tls_openssl.c
>> +++ b/libavformat/tls_openssl.c
>> @@ -415,7 +415,11 @@ er
On Tue, 17 Jun 2025 at 15:10, Kacper Michajlow wrote:
>
> On Tue, 17 Jun 2025 at 04:07, softworkz . wrote:
> >
> >
> > > -Original Message-
> > > From: Kacper Michajlow
> > > Sent: Sunday, June 15, 2025 12:49 AM
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
On Tue, Jun 17, 2025, 07:55 Pavel Koshevoy wrote:
> Ping. I think I've addressed the concerns raised with the previous
> patch.
> Please let me know if I may commit this... it is a segfault fix, so it
> probably should get some review priority.
>
> Thank you,
> Pavel
>
>
> On Sun, Jun 15, 20
Ping. I think I've addressed the concerns raised with the previous patch.
Please let me know if I may commit this... it is a segfault fix, so it
probably should get some review priority.
Thank you,
Pavel
On Sun, Jun 15, 2025, 14:50 Pavel Koshevoy wrote:
> Make runtime AVStream.codecpar co
> -Original Message-
> From: Kacper Michajlow
> Sent: Tuesday, June 17, 2025 3:18 PM
> To: softworkz .
> Cc: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 0/3] tests/fate: Improvements for running
> FATE on Windows/MSYS2
>
> On Tue,
On Tue, 17 Jun 2025 14:06:06 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> Stereo only, for simplicity. Slightly faster than the C code.
I will drop this and the prior commit and resubmit them in a refactored form
that also speeds up the sample peak calculation.
In the meantime, I would appr
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Tuesday, June 17, 2025 11:30 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib
> directly instead of gzip
>
> sof
On Tue, 17 Jun 2025 at 03:46, softworkz . wrote:
>
>
>
> > -Original Message-
> > From: Kacper Michajlow
> > Sent: Tuesday, June 17, 2025 3:00 AM
> > To: softworkz .
> > Cc: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 0/3] tests/
On Tue, 17 Jun 2025 at 04:07, softworkz . wrote:
>
>
> > -Original Message-
> > From: Kacper Michajlow
> > Sent: Sunday, June 15, 2025 12:49 AM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Cc: softwo...@hotmail.com
> > Subject: graph.{html,css} embed failure
From: Niklas Haas
This macro is not shortening the code nor aiding readability.
---
libavfilter/f_ebur128.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index 2d94cefce7..2e1eedd855 100644
--- a/l
From: Niklas Haas
I decided to separate out the peak measurement loop to avoid bloating
the signature, and since it's only conditionally used.
---
libavfilter/f_ebur128.c | 83 -
libavfilter/f_ebur128.h | 3 ++
2 files changed, 52 insertions(+), 34 deleti
From: Niklas Haas
Easier to read, less convoluted, and ~30% faster. Most importantly, this
avoids repeating the redundant recalculation of the true peak on every
single sample, by moving the FIND_PEAK() loop out of the main loop. (Note
that FIND_PEAK() does not depend on the current sample index
From: Niklas Haas
Stereo only, for simplicity. Slightly faster than the C code.
---
libavfilter/f_ebur128.c | 8 +++-
libavfilter/f_ebur128.h | 2 +-
libavfilter/x86/f_ebur128.asm| 25 +
libavfilter/x86/f_ebur128_init.c | 9 +++--
4 files
From: Niklas Haas
---
libavfilter/f_ebur128.c | 43 ++---
libavfilter/f_ebur128.h | 4
2 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index 1fb7129271..0adc89c823 100644
--- a/libavfilte
From: Niklas Haas
This is actually allowed by non-ancient versions of C.
---
libavfilter/f_ebur128.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index 4051b1ea95..1fb7129271 100644
--- a/libavfilter/f_eb
From: Niklas Haas
Processes two channels in parallel, using 128-bit XMM registers.
In theory, we could go up to YMM registers to process 4 channels, but this is
not a gain except for relatively high channel counts (e.g. 7.1), and also
complicates the sample load/store operations considerably.
I
From: Niklas Haas
This is substantially faster (~55%) than the transposed loop, and also
avoids an unnecessary macro.
---
libavfilter/f_ebur128.c | 38 ++
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_e
From: Niklas Haas
---
libavfilter/f_ebur128.c | 53 +
libavfilter/f_ebur128.h | 40 +++
2 files changed, 62 insertions(+), 31 deletions(-)
create mode 100644 libavfilter/f_ebur128.h
diff --git a/libavfilter/f_ebur128.c b/libav
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
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
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
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
Reverts 64bb91fd3b5a00a8849531c7e8dd207f2a626096 except the
key_frame setting for aac.
See also 696ea1c2236842572df88d573e24a39be3f19c98.
Don't force the profile as it may override the correct value
set by the decoder (HE/HEv2).
Fixes #11600
Signed-off-by: Nicolas Gaullier
---
libavcodec/aac_ac
From: daichengrong
On Banana PI F3:
hevc_idct_32x32_8_c:119473.4 ( 1.00x)
(rvv_256)
hevc_idct_32x32_8_rvv_i64:5085.9 (23.49x)
(rvv_256)
hevc_idct_32x32_8_c:119859.3 ( 1.00x)
(rv
softworkz . (HE12025-06-16):
> But why that? If we include the decompression code (that's why I've been
> searching for the most compact implementations available with compatible
> licenses), then we won't have any zlib dependency anymore - neither at build-
> nor at run-time.
Wait. What you want
On Mon, 16 Jun 2025, Kacper Michajlow wrote:
On Mon, 16 Jun 2025 at 09:40, Martin Storsjö wrote:
On Sat, 14 Jun 2025, Kacper Michajlow wrote:
> On Sat, 14 Jun 2025 at 03:03, Kacper Michajłow wrote:
>>
>> LLVM tools print installation path upon execution. If one uses LLVM
>> tools bundled wi
Context from the first version :
Here is a patch where I fixed the attach of per-macroblock qp tables for
H.264. It was implemented for MPEG2 so I have only extended it.
I tested the functionality with the codecview filter using the following
command: `./ffmpeg -export_side_data 4 -i input.mp4
85 matches
Mail list logo
