It's a value the caller may care about.
Signed-off-by: James Almer
---
libavcodec/h264_slice.c | 1 +
libavcodec/h264dec.c | 2 +-
tests/ref/fate/flv-demux | 2 +-
tests/ref/fate/mov-zombie | 2 +-
tests/ref/fate/ts-small-demux | 2 +-
5 files changed, 5 insertions(+), 4
On Fri, Apr 18, 2025 at 10:40 PM Frank Plowman
wrote:
> In d5dbcc00d889fb17948b025a468b00ddbea9e058, it was hoped that detection
> of subpicture overlaps could be performed at the tile level, so as to
> avoid introducing per-CTU checks. Unfortunately since that patch,
> fuzzing has indicated ther
Hi all
If you want to mentor a student, please make sure you clicked on "want to
mentor"
If you feel a student is not qualified then do NOT click on "want to mentor"
or if you already did, undo that
Same for backup mentors, if you want, you can for a qualified
student who has a mentor also clic
side_data_pref_mask is set during ff_decode_preinit() and then never copied to
worker threads. As such, any decoder calling one of the side data helpers that
rely on side_data_pref() in frame threaded scenarios will ignore the user set
list of side data types.
Signed-off-by: James Almer
---
liba
Given that this is a correctness fix and has gone through a few
iterations of review, any objections to merging now and exploring
optimizations around the padding later?
On Sat, Apr 26, 2025 at 1:05 AM Emma Worley wrote:
>
> Improves compatibility with Resolume products by adding an additional
>
On Tue, Apr 22, 2025 at 09:28:50PM +0200, Michael Niedermayer wrote:
> This issue was found through the new blocktest
>
> Signed-off-by: Michael Niedermayer
> ---
> libpostproc/postprocess_altivec_template.c | 2 +-
> libpostproc/postprocess_template.c | 14 +++---
> 2 files cha
On Wed, Apr 23, 2025 at 12:43:04AM +0200, Michael Niedermayer wrote:
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libpostproc/Makefile | 3 +-
> libpostproc/tests/stripetest.c | 129
> tests/fate/libpostproc.mak | 4 +
> tests/ref
On Tue, Apr 08, 2025 at 01:55:33AM +0200, Michael Niedermayer wrote:
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libpostproc/Makefile | 2 +
> libpostproc/tests/blocktest.c | 112 +
> tests/Makefile| 1 +
> tests/fate/l
On 4/26/2025 5:49 PM, Mark Thompson wrote:
v4: minor changes from previous version reflecting review comments.
This seems to be converging so will consider pushing soon and then working on
top of it (the patches from Dawid Kozinski for ISOBMFF support will also apply
on top of this).
My next
---
libavcodec/bitstream_filters.c | 1 +
libavcodec/bsf/Makefile| 1 +
libavcodec/bsf/apv_metadata.c | 134 +
3 files changed, 136 insertions(+)
create mode 100644 libavcodec/bsf/apv_metadata.c
diff --git a/libavcodec/bitstream_filters.c b/libavcodec
After being filled by FFCodec->init() from the first worker thread, it needs to
be copied to every other thread context. Otherwise, its entries will not be
present when ff_decode_frame_props() populates output frames.
Signed-off-by: James Almer
---
libavcodec/pthread_frame.c | 8
1 file
On Sat, 26 Apr 2025 19:41:04 +0200 Niklas Haas wrote:
> Hi all,
>
> After extensive amounts of refactoring and iteration on the design and API,
> and the implementation of an x86 SIMD backend, I'm happy to present the
> revised version of my ongoing swscale rewrite. Now with 100% less reliance on
Demuxes raw streams as defined in draft spec section 10.2.
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/apvdec.c | 248 +++
3 files changed, 250 insertions(+)
create mode 100644 libavformat/apvdec.c
diff --git a/libav
v4: minor changes from previous version reflecting review comments.
This seems to be converging so will consider pushing soon and then working on
top of it (the patches from Dawid Kozinski for ISOBMFF support will also apply
on top of this).
My next thoughts here are around improving the entrop
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/apvenc.c | 40
3 files changed, 42 insertions(+)
create mode 100644 libavformat/apvenc.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index ef96c2762e..6c999
Typical checkasm result on Alder Lake:
decode_transquant_8_c: 464.2 ( 1.00x)
decode_transquant_8_avx2: 86.2 ( 5.38x)
decode_transquant_10_c:481.6 ( 1.00x)
decode_transquant_10_avx2:
---
configure| 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/apv_decode.c | 433 +++
libavcodec/apv_decode.h | 80
libavcodec/apv_dsp.c | 136
libavcodec/apv_dsp.h | 37 +++
---
configure| 1 +
libavcodec/Makefile | 1 +
libavcodec/apv.h | 89
libavcodec/cbs.c | 6 +
libavcodec/cbs_apv.c | 455
libavcodec/cbs_apv.h | 207
---
libavcodec/codec_desc.c | 7 +++
libavcodec/codec_id.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9fb190e35a..88fed478a3 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1985,6 +1985,13 @@ static con
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
From: Niklas Haas
\o/
---
libswscale/graph.c | 77 --
1 file changed, 75 insertions(+), 2 deletions(-)
diff --git a/libswscale/graph.c b/libswscale/graph.c
index b921b7ec02..947da45aa3 100644
--- a/libswscale/graph.c
+++ b/libswscale/graph.c
@@ -34,6
From: Niklas Haas
---
tests/checkasm/checkasm.c | 1 +
tests/checkasm/checkasm.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 87b75ec36c..6e99d33d70 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -126
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
See the design document introduced in the previous commit for an
in-depth introduction to the new approach.
This commit merely introduces the common dispatch code, the SwsOpList
boilerplate, and the high-level optimizer. The subsequent commits will
add the underlying implementa
From: Niklas Haas
This should hopefully serve as a better introduction to my new swscale
redesign than hunting down random commit message monologues.
---
doc/swscale-v2.txt | 344 +
1 file changed, 344 insertions(+)
create mode 100644 doc/swscale-v2.t
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.
---
doc/APIchanges | 3 +++
doc/scaler.texi | 3 +++
libswscale/options.c | 1 +
libswscale/swscale.h | 7 +++
libswscale/version.h | 2
From: Niklas Haas
This is more consistent with the rest of the newly added code, which
universally switched to using bools for boolean values.
---
libswscale/format.c | 2 +-
libswscale/format.h | 6 --
libswscale/graph.h | 6 --
3 files changed, 9 insertions(+), 5 deletions(-)
diff --
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 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 solver, which can reduce any compati
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, and
can often beat even the old SIMD.
In theory, we can dramatically speed it up by using GCC vectors instead of
arrays, but the p
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
I need to reuse these inside `ops.c`.
---
libswscale/graph.c | 29 +++--
libswscale/graph.h | 13 +
2 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/libswscale/graph.c b/libswscale/graph.c
index c5a46eb257..b921b7ec02 100644
-
From: Niklas Haas
See doc/swscale-v2.txt for design details.
---
libswscale/Makefile| 1 +
libswscale/ops_chain.c | 291 +
libswscale/ops_chain.h | 108 +++
3 files changed, 400 insertions(+)
create mode 100644 libswscale/ops_chain.c
cr
From: Niklas Haas
The current loop only works if the input and output have the same number
of planes. However, with the new scaling logic, we can also optimize into a
noop the case where the input has extra unneeded planes.
For the memcpy fallback to work in these cases we have to instead check
From: Niklas Haas
So we can move pass-adding business logic outside of graph.c.
---
libswscale/graph.c | 41 -
libswscale/graph.h | 18 ++
2 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/libswscale/graph.c b/libswscale/grap
From: Niklas Haas
The old limits were a bit too tightly clustered around 1.0. Make the
value range much more generous, and also introduce a new highlight
for speedups above 10.0 (order of magnitude improvement).
---
libswscale/tests/swscale.c | 11 ++-
1 file changed, 6 insertions(+), 5
Hi all,
After extensive amounts of refactoring and iteration on the design and API,
and the implementation of an x86 SIMD backend, I'm happy to present the
revised version of my ongoing swscale rewrite. Now with 100% less reliance on
compiler autovectorization.
As before, I recommend (re)reading
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Samstag, 26. April 2025 17:10
> To: FFmpeg development discussions and patches [email protected]>
> Subject: [FFmpeg-devel] [TC] "Future Log Output Default"
>
> Hi all
>
> This is just an announcement
On Sat, Apr 26, 2025 at 05:10:27PM +0200, Michael Niedermayer wrote:
> Hi all
>
> This is just an announcement that the TC has been asked to look into
> avutil/log: Add log flag to control printing of memory addresses
> GitHub:https://github.com/ffstaging/FFmpeg/pull/59
> Patchwork
Hi all
This is just an announcement that the TC has been asked to look into
avutil/log: Add log flag to control printing of memory addresses
GitHub:https://github.com/ffstaging/FFmpeg/pull/59
Patchwork: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=14094
...
and the
Hi
On Sat, Apr 26, 2025 at 12:45:52PM +0200, Lynne wrote:
> On 26/04/2025 05:11, Michael Niedermayer wrote:
> > On Tue, Apr 22, 2025 at 04:44:07PM -0500, Romain Beauxis wrote:
> > > ---
> > > tests/Makefile | 4 +
> > > tests/api/Makefile |
Andreas Rheinhardt:
> [email protected]:
>> From: Wu Jianhua
>>
>> Signed-off-by: Wu Jianhua
>> ---
>> libavcodec/cbs_h2645.c | 6
>> libavcodec/cbs_sei.h | 21 +++
>> libavcodec/cbs_sei_syntax_template.c | 53
>> 3 files ch
On Fri, Apr 25, 2025 at 11:45:08AM -0600, Pavel Koshevoy wrote:
> On Fri, Apr 25, 2025 at 7:40 AM Michael Niedermayer
> wrote:
>
> > On Tue, Apr 22, 2025 at 06:51:55PM -0600, Pavel Koshevoy wrote:
> > > I have a couple of .ts captures where video and audio codec changes
> > > even though the PMT
On 26/04/2025 05:11, Michael Niedermayer wrote:
On Tue, Apr 22, 2025 at 04:44:07PM -0500, Romain Beauxis wrote:
---
tests/Makefile | 4 +
tests/api/Makefile | 2 +-
tests/api/api-dump-stream-meta-test.c | 177 +
Andreas Rheinhardt :
> 发送时间: 2025年4月25日 15:11
> 收件人: [email protected]
> 主题: Re: [FFmpeg-devel] [PATCH v1 03/19] avcodec/vvc/sei: add
> decode_film_grain_characteristics
>
> [email protected]:
>> From: Wu Jianhua
>>
>> Signed-off-by: Wu Jianhua
>> ---
>> libavcodec/vvc/sei.c | 66
45 matches
Mail list logo
