PR #20577 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20577
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20577.patch
These should also exclude the _NB values themselves.
>From 025b89018fc8a9d9e457a0c102101fd9bf01fa3e Mon Sep 17 00:00:00 2001
F
PR #20504 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20504
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20504.patch
Marking this as WIP because I think it may be a little contentious. Mainly
leaving it here as an RFC.
>F
On Tue, 16 Sep 2025 10:49:00 +0200 Michael Niedermayer
wrote:
> Hi all
>
> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
> heres the "after testing" discussion and vote
>
> do we want to ke
On Thu, 18 Sep 2025 01:52:31 -0700 Jacob Lifshay via ffmpeg-devel
wrote:
> On Thu, Sep 18, 2025 at 12:03 AM Nicolas George via ffmpeg-devel
> wrote:
> >
> > Timo Rothenpieler via ffmpeg-devel (HE12025-09-18):
> > > The problem is they can be very frequent. And not only force pushes.
> > > So the
On Tue, 16 Sep 2025 23:12:55 +0200 Balint Marton via ffmpeg-devel
wrote:
> [...]
>
> - Comparing pull request versions does not remove the upstreamed commits
>from the comparison, so if a new version is newly rebased, I see
>upstream commits as well in the comparison.
>
> [...]
I think t
PR #20528 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20528
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20528.patch
Plus checkasm tests for both
>From a406d6e309380e0413aa1b0c6ea98cfbe5912538 Mon Sep 17 00:00:00 2001
From: Niklas Haas
Date: Mon,
PR #20503 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20503
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20503.patch
Instead of reporting them also when the filtergraph is suddenly destroyed
mid-stream, e.g. during the `ffmpeg` tool's early
PR #20491 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20491
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20491.patch
>From 71d4a88136e731bddf2673e13ed393efe9c2fdd5 Mon Sep 17 00:00:00 2001
From: Niklas Haas
Date: Thu, 11 Sep 2025 01:39:46 +0
PR #20466 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20466
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20466.patch
Required to clear textures to a background color.
>From 1f2de0f61888e4d16b9e124fc4b4728dd3642981 Mon Sep 17 00:00:00 2001
F
PR #20467 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20467
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20467.patch
The semantics of these keywords are well-defined by the CSS 'object-fit'
property. This is arguably more user-friendly and l
PR #20457 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20457
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20457.patch
A series of improvements aimed at reducing the amount of wasted memory inside
ffmpeg, in particular for unused inputs. Generally
PR #20440 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20440
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20440.patch
And remove the field again; in retrospect, there is no point to adding it in
the first place.
>F
PR #20400 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20400
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20400.patch
>From 3c609a99b250e625c6685bf44028dfb6e29becd1 Mon Sep 17 00:00:00 2001
From: Niklas Haas
Date: Tue, 2 Sep 2025 14:01:44 +0
PR #20388 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20388
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20388.patch
Effectively makes it a copy of the concat filter but with the ability to
crossfade instead of hard cutting.
I did have to formally
PR #20387 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20387
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20387.patch
This wrapping logic still considered any nonzero return from the ASM function
to be the overall result, but this is not true since the
PR #20351 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20351
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20351.patch
If this function returns an error after ff_sws_graph_add_pass() has been
called, and the pass->free callback is therefore already
On Wed, 20 Aug 2025 18:24:16 +0200 Niklas Haas wrote:
> On Tue, 12 Aug 2025 08:32:39 -0700 Pierre-Anthony Lemieux
> wrote:
> > Quick reminder that the deadline for submitting your proposal is
> > quickly approaching.
> >
> > Also note that the total amount of the
On Fri, 22 Aug 2025 17:22:54 +0200 Timo Rothenpieler via ffmpeg-devel
wrote:
> We could only run those tests on master, not on PRs.
> Nobody is impacted by them then, and we still notice breakage reasonably
> fast.
That seems reasonable to me.
___
ffmp
On Fri, 22 Aug 2025 15:47:04 +0200 Nicolas George via ffmpeg-devel
wrote:
> The filters that do not even touch the alpha plane are the most likely
> to produce invalid garbage with premultiplied alpha. They should NOT
> enable support.
Quod non sequitur.
Filters which do not touch the alpha cha
On Thu, 21 Aug 2025 13:32:02 +0200 Michael Niedermayer via ffmpeg-devel
wrote:
> Hi
>
> Should we use a Merge or Cherry picks for integrating Pauls work ?
>
> Following are 2 plans, as we execute either we may run into issues
> and of course adapt them as needed. (or even switch)
>
> Option M:
>
On Thu, 21 Aug 2025 14:47:03 +0900 Lynne via ffmpeg-devel
wrote:
> ---
> src/index | 42 ++
> 1 file changed, 42 insertions(+)
>
> diff --git a/src/index b/src/index
> index 52829e1..a07f4b8 100644
> --- a/src/index
> +++ b/src/index
> @@ -35,6 +35,48 @@
>
PR #20304 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20304
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20304.patch
It makes sense to treat the presence of a frame duration and the presence
of frame rate metadata identically - because both convey
PR #20303 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20303
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20303.patch
See-Also: https://code.videolan.org/videolan/libplacebo/-/merge_requests/737
>From 20d6f1fdbdd95df75e4f3025e6cdc1cd92c2dda1 Mon
On Wed, 20 Aug 2025 23:43:18 +0200 Niklas Haas wrote:
> This argument works both ways.
>
> filter authors to remember to enable support
> for premultiplied alpha, even if they don't even touch the alpha plane?
I accidentally deleted a line too many here, the text was supposed
PR #20295 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20295
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20295.patch
Otherwise, this may break vulkan encoding or subsequent hwupload/hwdownload
if the upstream filter did not specifically advertise this
On Tue, 12 Aug 2025 08:32:39 -0700 Pierre-Anthony Lemieux
wrote:
> Quick reminder that the deadline for submitting your proposal is
> quickly approaching.
>
> Also note that the total amount of the proposed projects is below for
> the minimum threshold for STF to consider the application.
Despit
PR #20257 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20257
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20257.patch
>From d7335fdb74a3adf45ae47fa5df0cffa4afda6213 Mon Sep 17 00:00:00 2001
From: Niklas Haas
Date: Fri, 15 Aug 2025 22:55:30 +0
On Mon, 11 Aug 2025 11:32:56 +0200 Nicolas George wrote:
> Niklas Haas (HE12025-08-11):
> > I still think this series overall is a step in the wrong direction; and that
> > our goal should be to move towards negotiation, and not towards some IMO
> > hacky
> > flag th
On Tue, 12 Aug 2025 17:59:44 +0200 Kacper Michajlow wrote:
> On Tue, 12 Aug 2025 at 14:35, Tristan Matthews via ffmpeg-devel
> wrote:
> > For reference, that's https://code.videolan.org/Garf/homer-bot
> > Obviously that's gitlab specific but may help inform some choices here.
>
> Because of cours
PR #20223 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20223
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20223.patch
>From 3b7db1f9eea5ea9294988ec5c079ee9896d610db Mon Sep 17 00:00:00 2001
From: Niklas Haas
Date: Tue, 12 Aug 2025 12:15:54 +0
On Tue, 12 Aug 2025 11:53:20 +0200 Nicolas George wrote:
> Niklas Haas (HE12025-08-12):
> > I see that, but note:
> > 1) the PR *was* approved
>
> How do you know that approval was worth anything?
As far as my understanding goes, only people with write access to the
repos
On Tue, 12 Aug 2025 15:08:10 +0530 Gyan Doshi wrote:
>
>
> On 2025-08-12 03:04 pm, Niklas Haas wrote:
> > On Tue, 12 Aug 2025 11:16:19 +0200 Nicolas George wrote:
> >> ffmpeg-...@ffmpeg.org (HE12025-08-12):
> >>> Author: Niklas Haas
> >>
On Tue, 12 Aug 2025 11:34:08 +0200 Niklas Haas wrote:
> Perhaps we adopt the VLC model, which is:
> - If a PR has received no activity for 3 days
> - AND it has at least one approval
> - AND it passes all CI checks
> then it will be merged automatically, by a bot.
Oh, and perha
On Tue, 12 Aug 2025 11:16:19 +0200 Nicolas George wrote:
> ffmpeg-...@ffmpeg.org (HE12025-08-12):
> > Author: Niklas Haas
> > AuthorDate: Mon Aug 11 15:57:24 2025 +0200
> > Commit: Niklas Haas
> > CommitDate: Tue Aug 12 09:01:39 2025 +
>
> Pushing
PR #20217 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20217
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20217.patch
The vast majority of av_log() calls use the `AVFilterContext *ctx` for logging,
which enables custom logic such as printing the
On Mon, 11 Aug 2025 11:18:12 +0200 Niklas Haas wrote:
> On Sun, 03 Aug 2025 20:15:09 +0200 Nicolas George wrote:
> > Nicolas George (HE12025-08-03):
> > > I will send the series here in a few hours.
> >
> > Here is a series of patch. I am absolutely not sure I
On Sun, 03 Aug 2025 20:15:09 +0200 Nicolas George wrote:
> Nicolas George (HE12025-08-03):
> > I will send the series here in a few hours.
>
> Here is a series of patch. I am absolutely not sure I found all the
> filters that could be flagged, but the rest can be done as the need
> arises.
>
> Not
PR #20211 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20211
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20211.patch
pl_frame_mix_current() will return NULL if all frames are in the future,
but when libplacebo is using a frame mixer with a radius
PR #20164 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20164
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20164.patch
Instead of copying over the entire target and changing a few fields,
set the entire struct to a whitelist of safe properties that we
PR #20132 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20132
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20132.patch
This histogram index was not correctly downshifted to 8-bit.
>From 651ce7dbc9cb88ab01002867ddb5b44a6f17a647 Mon Sep 17 00:00:00 2
On Sun, 03 Aug 2025 20:15:09 +0200 Nicolas George wrote:
> Nicolas George (HE12025-08-03):
> > I will send the series here in a few hours.
>
> Here is a series of patch. I am absolutely not sure I found all the
> filters that could be flagged, but the rest can be done as the need
> arises.
>
> Not
By the way, just to be clear:
As I am a member of the TC, I believe there to be a conflict of interest
and will recuse myself from any internal discussions on the matter.
P.s. Out of curiosity, what happens if the remaining TC were to vote 2-2 on
the issue? Would my vote be taken as an implicit t
Hi all,
For context, this is the patch series being discussed:
https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20031
A description of my position follows.
On Sat, 02 Aug 2025 20:03:23 +0200 Nicolas George wrote:
> Nicolas George (HE12025-08-02):
> > - The patch series lacks transverse user document
On Sat, 02 Aug 2025 11:40:54 +0200 Nicolas George wrote:
> Niklas Haas (HE12025-07-29):
> > I think this would involve more invasive changes (i.e. adding negotiation to
> > the avfilter code for this and ideally other properties) that you and I both
> > agreed is out of
On Wed, 23 Jul 2025 13:43:43 +0200 Michael Niedermayer
wrote:
> Hi everyone
>
> I intend to create the release/8.0 branch in the next 1-2 weeks
> after that i intend to make teh 8.0 release in the following 1-2 weeks
>
> If theres something you want in it make sure its pushed before the branch
>
On Tue, 29 Jul 2025 21:02:53 +0100 Kieran Kunhya
wrote:
> Hello,
>
> It seem there is strong evidence that AI wrote TLS code as part of the
> WHIP patch. It goes without saying why this is bad. Further discussion
> here:
> https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20053
>
> This patch was pushe
On Wed, 30 Jul 2025 23:39:18 +0200 Nicolas George wrote:
> Kacper Michajlow (HE12025-07-30):
> > Can we please find something more relevant to be upset about?
>
> Can you please stop behaving with such arrogance when somebody who has
> 30 times as much experience as you in the project points you y
On Wed, 30 Jul 2025 19:52:59 +0200 Nicolas George wrote:
> Kacper Michajłow (HE12025-07-30):
> > > Note that BIO_get_new_index() can only be used 127 times before it
> > > returns an error.
> >
> > We cannot call it repeatedly, because it will fail eventually.
> >
> > To my understanding the index
On Mon, 28 Jul 2025 16:18:29 +0200 Nicolas George wrote:
> Niklas Haas (HE12025-07-24):
> > On what component are you missing an error here?
>
> Recently I wrote: “stacking images with different kind of alpha or
> sending this kind of frames to a muxer with uncoded frames
On Wed, 23 Jul 2025 01:04:34 +0200 Michael Niedermayer
wrote:
> The announcment should probably mention that performance, as in number of
> submissions / percentage of applied / not reviewed patches will be
> monitored compared to the mailing list.
https://en.wikipedia.org/wiki/Goodhart%27s_law
On Thu, 24 Jul 2025 16:59:24 +0200 Nicolas George wrote:
> Right now, I an not demanding negotiation, I am just requiring
> protection:
>
> if (frame->is_premultiplied && !out->supports_premultiplied) {
> av_log(ctx, AV_LOG_ERROR, "Your data is about to be
> corrupted bec
On Wed, 23 Jul 2025 18:11:23 +0200 Kacper Michajlow wrote:
> On Wed, 23 Jul 2025 at 15:57, Niklas Haas wrote:
> >
> > From: Niklas Haas
> >
> > ---
> > libavfilter/vf_showinfo.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > d
On Wed, 23 Jul 2025 15:47:14 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> This filter was, for some reason, always ignoring the incoming chroma
> location in favor of the user-specified value, even when that value was set
> to the default (unspecified).
>
> This has be
On Wed, 23 Jul 2025 18:19:03 +0200 Kacper Michajlow wrote:
> On Wed, 23 Jul 2025 at 15:57, Niklas Haas wrote:
> >
> > From: Niklas Haas
> >
> > This header bit ("alpha_associated") was incorrectly ignored.
> > ---
> > libavcodec/jpegxl_parse.c
On Wed, 23 Jul 2025 19:02:06 +0200 Nicolas George wrote:
> Niklas Haas (HE12025-07-23):
> > [PATCH v2 05/18] avcodec/encode: enforce alpha mode compatibility at encode
> > time
>
> That handles it for encoders, I suppose. But I do not see anything
> protecting you f
On Wed, 23 Jul 2025 16:11:45 +0200 Nicolas George wrote:
> Niklas Haas (HE12025-07-23):
> > Changes since v1:
> > - Correctly implement alpha mode tagging for JPEG XL
> > - Set correct alpha mode for OpenEXR (which is always premultiplied)
> > - Ensure -alpha_mode sp
On Wed, 23 Jul 2025 16:01:14 +0200 Niklas Haas wrote:
> On Wed, 23 Jul 2025 13:43:43 +0200 Michael Niedermayer
> wrote:
> > Hi everyone
> >
> > I intend to create the release/8.0 branch in the next 1-2 weeks
> > after that i intend to make teh 8.0 release in the
On Wed, 23 Jul 2025 13:43:43 +0200 Michael Niedermayer
wrote:
> Hi everyone
>
> I intend to create the release/8.0 branch in the next 1-2 weeks
> after that i intend to make teh 8.0 release in the following 1-2 weeks
>
> If theres something you want in it make sure its pushed before the branch
>
From: Niklas Haas
Error out if trying to encode frames with an incompatible alpha mode.
---
libavcodec/encode.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 38833c566c..9012708130 100644
--- a/libavcodec
From: Niklas Haas
---
fftools/ffmpeg_enc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index 4568c15073..babfca6c0a 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -287,6 +287,17 @@ int enc_open(void *opaque, const
From: Niklas Haas
Chooses the desired output alpha mode. Note that this depends on
an upstream version of libplacebo new enough to respect the corresponding
AVFrame field in pl_map_avframe_ex.
---
doc/filters.texi| 4
libavfilter/vf_libplacebo.c | 13 +
2 files
From: Niklas Haas
---
libavfilter/vf_premultiply.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavfilter/vf_premultiply.c b/libavfilter/vf_premultiply.c
index 322fc39094..1c08cf524a 100644
--- a/libavfilter/vf_premultiply.c
+++ b/libavfilter/vf_premultiply.c
@@ -512,6 +512,7
From: Niklas Haas
---
doc/filters.texi | 13 +
libavfilter/vf_setparams.c | 10 ++
2 files changed, 23 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index fbf8aff382..13ca065f85 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21602,6
From: Niklas Haas
---
libavfilter/vf_alphamerge.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavfilter/vf_alphamerge.c b/libavfilter/vf_alphamerge.c
index f5779484a9..98c61e282d 100644
--- a/libavfilter/vf_alphamerge.c
+++ b/libavfilter/vf_alphamerge.c
@@ -85,6 +85,8 @@ static int
From: Niklas Haas
---
doc/filters.texi | 3 +-
libavfilter/vf_overlay.c | 199 --
libavfilter/vf_overlay.h | 4 +-
libavfilter/x86/vf_overlay_init.c | 8 +-
4 files changed, 116 insertions(+), 98 deletions(-)
diff --git a/doc
From: Niklas Haas
This code always ignored the user-provided enc_ctx->chroma_sample_location
in favor of the location tagged on the frame. This leads to a very (IMHO)
unexpected outcome where -chroma_sample_location works differently from the
related options like -colorspace and -color_ra
From: Niklas Haas
Works around a bug where older versions of libjxl don't correctly forward
the alpha channel information to the extra channel info.
---
libavcodec/libjxlenc.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxl
From: Niklas Haas
PNG always uses straight alpha.
cf. https://www.w3.org/TR/PNG-Rationale.html
> Although each form of alpha storage has its advantages, we did not want to
> require all PNG viewers to handle both forms. We standardized on non-
> premultiplied alpha as being the los
From: Niklas Haas
OpenEXR always uses premultiplied alpha, as per the spec.
cf. https://openexr.com/en/latest/TechnicalIntroduction.html
> By convention, all color channels are premultiplied by alpha, so that
> `foreground + (1-alpha) x background` performs a correct “over” operation.
From: Niklas Haas
JPEG XL supports both premultiplied and straight alpha, and the basic info
struct contains signalling for this. Forward the correct tagging on decode
and encode.
---
libavcodec/libjxldec.c | 6 ++
libavcodec/libjxlenc.c | 15 +++
2 files changed, 21 insertions
From: Niklas Haas
This header bit ("alpha_associated") was incorrectly ignored.
---
libavcodec/jpegxl_parse.c | 7 +--
libavcodec/jpegxl_parse.h | 1 +
libavcodec/jpegxl_parser.c | 5 +
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavcodec/jpegxl
From: Niklas Haas
This filter was, for some reason, always ignoring the incoming chroma
location in favor of the user-specified value, even when that value was set
to the default (unspecified).
This has been the status quo for quite some time, although commit 04ce01df0bb
made the situation
From: Niklas Haas
Following in the footsteps of the previous commit, this commit adds the
new fields to AVCodecContext so we can start properly setting it on codecs,
as well as limiting the list of supported options to detect a format mismatch
during encode.
This commit also sets up the
From: Niklas Haas
---
libavfilter/vf_showinfo.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index c706d00c96..b564d03a84 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -887,6 +887,14 @@ static int
From: Niklas Haas
FFmpeg currently handles alpha in a quasi-arbitrary way. Some filters/codecs
assume alpha is premultiplied, others assume it is independent. If there is
to be any hope for order in this chaos, we need to start by defining an enum
for the possible range of values.
---
doc
Changes since v1:
- Correctly implement alpha mode tagging for JPEG XL
- Set correct alpha mode for OpenEXR (which is always premultiplied)
- Ensure -alpha_mode specified on the command line correctly propagates
- Print out a warning when overriding the alpha mode explicitly
Includes an unrelated
On Wed, 23 Jul 2025 05:30:57 + Sarthak Indurkhya via ffmpeg-devel
wrote:
> Thank you for the thoughtful feedback.
>
> Advantages over vf_libplacebo’s inverse tone mapping:
>
> 1. Algorithmic Differentiation:
> My filter is based on a novel local adaptation + inverse tone mapping
> strateg
From: Niklas Haas
This gives vastly improved blending results than when blending directly in
the desired output colorspace. Overridable by the existing "disable_linear"
option.
This is functionally similar to combining multiple "libplacebo" filters,
but does not rely o
From: Niklas Haas
The previous formula was introduced without justification in 6e713841e8,
and the only thing Paul had to say about it over IRC was that it was copied
from an unspecified source on the internet.
I decided to do some testing and came to the conclusion that this term not
only
On Fri, 18 Jul 2025 14:38:04 +0200 Kacper Michajlow wrote:
> > +static inline int ff_detect_range_c(const uint8_t *data, ptrdiff_t stride,
> > +ptrdiff_t width, ptrdiff_t height,
> > +int mpeg_min, int mpeg_max)
> > +{
> > +
On Fri, 18 Jul 2025 11:57:14 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> This filter can detect various properties about the image, including
> whether or not there are out-of-range values, or whether the input appears
> to use straight or premultiplied alpha.
>
> Of c
On Fri, 18 Jul 2025 19:32:42 +0800 Zhao Zhili wrote:
> From: Zhao Zhili
>
> Fix fate-source failure.
> ---
> libavfilter/vf_blackdetect.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_blackdetect.h b/libavfilter/vf_blackdetect.h
> index 361da2c5bc..2
From: Niklas Haas
alphadetect8_full_c: 5658.2 ( 1.00x)
alphadetect8_full_avx2:215.1 (26.31x)
alphadetect8_full_avx512: 133.5 (42.40x)
alphadetect8_limited_c: 7391.5 ( 1.00x
From: Niklas Haas
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/vf_colordetect.c | 139
tests/fate/checkasm.mak | 1 +
5 files changed, 145 insertions
From: Niklas Haas
This filter can detect various properties about the image, including
whether or not there are out-of-range values, or whether the input appears
to use straight or premultiplied alpha.
Of course, these can only be heuristics, with "undetermined" as the base
case. Wh
On Thu, 17 Jul 2025 11:41:56 +0200 Niklas Haas wrote:
> On Wed, 16 Jul 2025 17:25:12 -0300 James Almer wrote:
> > On 7/16/2025 1:24 PM, Niklas Haas wrote:
> > > +cglobal detect_alpha%1_%3, 6, 7, 6, color, color_stride, alpha,
> > > alpha_stride, width, heigh
From: Niklas Haas
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 ++
tests/checkasm/checkasm.h | 1 +
tests/checkasm/vf_blackdetect.c | 69 +
tests/fate/checkasm.mak | 1 +
5 files changed, 75 insertions
From: Niklas Haas
Requested by a user. Even with autovectorization enabled, the compiler
performs a quite poor job of optimizing this function, due to not being
able to take advantage of the pmaxub + pcmpeqb trick for counting the number
of pixels less than or equal-to a threshold
On Wed, 16 Jul 2025 17:25:12 -0300 James Almer wrote:
> On 7/16/2025 1:24 PM, Niklas Haas wrote:
> > +cglobal detect_alpha%1_%3, 6, 7, 6, color, color_stride, alpha,
> > alpha_stride, width, height, x
> > +pxor m0, m0
> > +add colorq, widthq
> > +
On Wed, 16 Jul 2025 22:06:28 +0200 Henrik Gramner via ffmpeg-devel
wrote:
> On Wed, Jul 16, 2025 at 6:26 PM Niklas Haas wrote:
> > +cglobal detect_range%1, 6, 7, 5, data, stride, width, height, mpeg_min,
> > mpeg_max, x
> > +movd xm0, mpeg_mind
> &g
On Wed, 16 Jul 2025 17:25:12 -0300 James Almer wrote:
> On 7/16/2025 1:24 PM, Niklas Haas wrote:
> > +cglobal detect_alpha%1_%3, 6, 7, 6, color, color_stride, alpha,
> > alpha_stride, width, height, x
> > +pxor m0, m0
> > +add colorq, widthq
> > +
From: Niklas Haas
alphadetect8_full_c: 5658.2 ( 1.00x)
alphadetect8_full_avx2:215.1 (26.31x)
alphadetect8_full_avx512: 133.5 (42.40x)
alphadetect8_limited_c: 7391.5 ( 1.00x
From: Niklas Haas
This filter can detect various properties about the image, including
whether or not there are out-of-range values, or whether the input appears
to use straight or premultiplied alpha.
Of course, these can only be heuristics, with "undetermined" as the base
case. Wh
From: Niklas Haas
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/vf_colordetect.c | 137
4 files changed, 142 insertions(+)
create mode 100644 tests/checkasm
Changes since v1:
- Fix overflow in both C and x86 code for 16-bit depth
- Fix SIMD overflow for 8-bit depth
- Improve checkasm test to try and force overflow conditions
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/lis
On Wed, 16 Jul 2025 17:25:49 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> This filter can detect various properties about the image, including
> whether or not there are out-of-range values, or whether the input appears
> to use straight or premultiplied alpha.
>
> Of c
From: Niklas Haas
alphadetect8_full_c: 6334.7 ( 1.00x)
alphadetect8_full_avx2:208.1 (30.44x)
alphadetect8_full_avx512: 123.3 (51.39x)
alphadetect8_limited_c:645.3 ( 1.00x
From: Niklas Haas
This filter can detect various properties about the image, including
whether or not there are out-of-range values, or whether the input appears
to use straight or premultiplied alpha.
Of course, these can only be heuristics, with "undetermined" as the base
case. Wh
From: Niklas Haas
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/vf_colordetect.c | 129
4 files changed, 134 insertions(+)
create mode 100644 tests/checkasm
On Thu, 10 Jul 2025 17:10:42 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> Requested by a user. Even with autovectorization enabled, the compiler
> performs a quite poor job of optimizing this function, due to not being
> able to take advantage of the pmaxub + pcmpeqb trick f
1 - 100 of 1601 matches
Mail list logo
