From: Zhao Zhili
---
libavutil/tests/color_utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/tests/color_utils.c b/libavutil/tests/color_utils.c
index 27ba8b529e..b8200e91fa 100644
--- a/libavutil/tests/color_utils.c
+++ b/libavutil/tests/color_utils.c
@@ -70,
On Thu, 5 Dec 2024, Alexander Strasser via ffmpeg-devel wrote:
Hi Martin,
still looks good to me.
On 2024-12-04 16:08 +0200, Martin Storsjö wrote:
[...]
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -313,6 +313,12 @@ $(FATE): $(FATE_UTILS:%=tests/%$(HOSTEXESUF)) |
$(FATE_OUTDIRS)
fate-list:
On Thu, Dec 05, 2024 at 12:30:10PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> We will use the av_csp_itu_eotf() functions to decode these internally, so
> check this function to see if it succeeds.
> ---
> libswscale/utils.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
P
On 2024-12-04 16:07 +0200, Martin Storsjö wrote:
> On Sun, 1 Dec 2024, Alexander Strasser via ffmpeg-devel wrote:
[...]
> >
> > Would it be better to use the same description as int fate.texi ?
>
> Sure, I can add that extra parenthesis.
Thanks.
[...]
> > > +fate-clear-results:
> > > + @rm -f t
Hi Martin,
still looks good to me.
On 2024-12-04 16:08 +0200, Martin Storsjö wrote:
[...]
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -313,6 +313,12 @@ $(FATE): $(FATE_UTILS:%=tests/%$(HOSTEXESUF)) |
> $(FATE_OUTDIRS)
> fate-list:
> @printf '%s\n' $(sort $(FATE))
>
> +fate-list-fai
On Thu, Nov 28, 2024 at 4:30 PM Anton Khirnov wrote:
>
> Hi all,
> the current Technical Committee (TC) was elected on 2023-12-05 and its
> mandate lasts for one year, so we should hold a new election soon. If
> there are no unforeseen circumstances, I would like to start the vote on
> Monday 2024
I volunteer. I have no revolutionary agenda or financial skin in this game,
and my current career does not intersect with A/V. I have been generally
reading the mailing list since March 2023. I can provide the following
services,
1) Being an effective de-escalator and diplomat. There are bursts of
On Thu, Dec 5, 2024 at 5:04 PM Michael Niedermayer
wrote:
>
> Hi Kieran
>
> On Wed, Dec 04, 2024 at 09:51:23PM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> > Hi Michael,
> >
> > Are you able to document the differences between source.ffmpeg.org and
> > git.ffmpeg.org?
> > Why does one resolve
On Thu, Dec 05, 2024 at 12:30:18PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> This setting can be used to infuence the type of tone and gamut mapping used
> internally when color space conversions are required. As discussed at VDD'24,
> the default was set to relative colorimetric clipping
On Thu, Dec 5, 2024 at 2:29 PM Nicolas Gaullier
wrote:
>
> >De : Kieran Kunhya
> >Envoyé : mercredi 4 décembre 2024 23:06
> >
> >> - a s337m decoder: it includes a resampler: output and input sample_rate
> >> are the same, sync is always correct. It would be possible to implement
> >> a full pcm
On 28/11/2024 23:29, Anton Khirnov wrote:
Hi all,
the current Technical Committee (TC) was elected on 2023-12-05 and its
mandate lasts for one year, so we should hold a new election soon. If
there are no unforeseen circumstances, I would like to start the vote on
Monday 2024-12-09.
As a reminder
---
doc/filters.texi | 14 +++
libavfilter/ssim.h| 6 +
libavfilter/version.h | 4 +-
libavfilter/vf_ssim.c | 274 +-
4 files changed, 290 insertions(+), 8 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 900baf2f45..3ff0c6f
Hi, I'm sending the essim patch for GSOC 24 again. I would appreciate some
feedback :)
Kindly, Andrea
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ff
On Mon, Dec 2, 2024 at 11:52 AM Michael Niedermayer
wrote:
>
> Hi
>
> On Sun, Dec 01, 2024 at 10:17:15PM -0800, Pierre-Anthony Lemieux wrote:
> > Hi all,
> >
> > Osamu and I are looking at adding FATE tests that checks that the MSE
> > of a decode image compared to a reference image does not excee
Hi Kieran
On Thu, Dec 05, 2024 at 06:03:55PM +0100, Michael Niedermayer wrote:
[...]
> >
> > https://git.ffmpeg.org currently goes to a 403 Forbidden "You don't
> > have permission to access this resource."
>
> Entering random URLs does sometimes produce errors
> maybe you meant https://git.ffmpe
Hi Kieran
On Wed, Dec 04, 2024 at 09:51:23PM +, Kieran Kunhya via ffmpeg-devel wrote:
> Hi Michael,
>
> Are you able to document the differences between source.ffmpeg.org and
> git.ffmpeg.org?
> Why does one resolve to telepoint and one to VideoLAN? What is the
> purpose of having two CNAMEs?
The following no longer return a UB warning after the patch:
./configure --extra-cflags='-fno-sanitize-recover=undefined'
--toolchain=gcc-usan
make fate-jpeg2000dec
make fate-j2k-dwt
make fate-vsynth{1,2,3, _lena}
Anything else should be included? If not, I will merge at week's end.
On Wed, Dec
Hi
On Wed, Dec 04, 2024 at 07:48:48PM +0800, Zhao Zhili wrote:
[...]
> >> -#else
> >> +#else // _WIN32
> >> +
> >> +#ifdef _WASI_EMULATED_SIGNAL
> >
> > Why the nested #else + #ifdef, why not #elif defined()? I think that would
> > keep the logic slightly less complex.
>
> Should be fixed by
>
>De : Kieran Kunhya
>Envoyé : mercredi 4 décembre 2024 23:06
>
>> - a s337m decoder: it includes a resampler: output and input sample_rate
>> are the same, sync is always correct. It would be possible to implement
>> a full pcm fallback, but currently only a silence/pcm fallback is
>> provided. A
On 04/12/2024 23:14, ffnicol...@sfr.fr wrote:
From: Nicolas Gaullier
I would like to have some feedback on this work before going on...
I send this as an RFC, and so, I have not considered versioning,
changelog, doc, deprecation schemes. More testing and testing by
other people is also obviou
Hi,
I believe a similar approach was tried by Gyan earlier this year and
unanimously rejected by the TC [1-3].
[1]
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffm...@gyani.pro/
[2] Message-Id <9be400cf-949f-4eb1-93a1-b352a1b80...@gyani.pro>
https://lists.ffmpeg.org
Hi,
On Thu, Dec 5, 2024 at 8:41 AM wrote:
> From: sunyuechi
>
> Co-Authored-By: Ronald S. Bultje
> ---
> tests/checkasm/rv40dsp.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tests/checkasm/rv40dsp.c b/tests/checkasm/rv40dsp.c
> index a1a873d430..c0d02ec
From: sunyuechi
Co-Authored-By: Ronald S. Bultje
---
tests/checkasm/rv40dsp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/checkasm/rv40dsp.c b/tests/checkasm/rv40dsp.c
index a1a873d430..c0d02ec81f 100644
--- a/tests/checkasm/rv40dsp.c
+++ b/tests/checkas
From: sunyuechi
---
libavcodec/riscv/rv40dsp_rvv.S | 116 ++---
1 file changed, 78 insertions(+), 38 deletions(-)
diff --git a/libavcodec/riscv/rv40dsp_rvv.S b/libavcodec/riscv/rv40dsp_rvv.S
index ca431eb8ab..d4beb7f1e9 100644
--- a/libavcodec/riscv/rv40dsp_rvv.S
+++
Thank you for your detailed explanation! :)
Ronald S. Bultje 于2024年12月5日周四 20:38写道：
> Hi,
>
> Christophe asked me to chime in.
>
> On Wed, Dec 4, 2024 at 4:14 AM wrote:
>
> > --- a/tests/checkasm/rv40dsp.c
> > +++ b/tests/checkasm/rv40dsp.c
> > @@ -27,7 +27,7 @@
> > #define randomize_buffers()
From: Niklas Haas
This is now supported when using the new API.
---
libswscale/swscale.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 7e77e82c8d..42efccd12b 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -1361,
Hi,
Christophe asked me to chime in.
On Wed, Dec 4, 2024 at 4:14 AM wrote:
> --- a/tests/checkasm/rv40dsp.c
> +++ b/tests/checkasm/rv40dsp.c
> @@ -27,7 +27,7 @@
> #define randomize_buffers() \
> do { \
> for (int i = 0; i < 16*
From: Niklas Haas
Only add the condensed values that we actually care about. Group them into
a new struct to make it easier to discard or replace this metadata.
---
libswscale/swscale.c | 7 ---
libswscale/utils.c | 26 +++---
libswscale/utils.h | 42
From: Niklas Haas
In the long run, it would be ideal if we could add these to the avfilter
negotiation as well, but for now, this is a good start.
---
doc/filters.texi | 56 +++
libavfilter/vf_scale.c | 75 +-
2 files chan
Hello,
Le jeu. 5 déc. 2024 à 08:25, flow gg a écrit :
> I submitted a new patch: "checkasm/rv40dsp: cover more cases for rv40_bias"
> to test this situation.
My point is, that patch was fine, the one you talk about isn't.
> > Le mer. 4 déc. 2024 à 10:14, a écrit :
> > > @@ -27,7 +27,7 @@
> > >
On Thu, 05 Dec 2024 12:30:20 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> This is no longer relevant after a change in color space.
> ---
> libavfilter/vf_scale.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> index e3
Le jeu. 5 déc. 2024 à 05:34, flow gg a écrit :
> Update here because there's no need to change it to 0xFF.
There is. h264_chroma mc is a separate issue, but doing interpolation
of values that are within [0..3] is bogus.
I'm not asking you fix h264_chroma mc test, but at least please do get
this o
From: Niklas Haas
Take special care to handle grayscale formats without a colorspace
gracefully.
---
libswscale/graph.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/libswscale/graph.c b/libswscale/graph.c
index fbad1fe8c3..36b74fad0c 100644
--- a/libswsc
From: Niklas Haas
Logic is, for the most part, a straight port of similar logic in
liplacebo's colorspace.c, with some general edits and refactors.
---
libswscale/Makefile | 1 +
libswscale/csputils.c | 412 ++
libswscale/csputils.h | 111
From: Niklas Haas
This setting can be used to infuence the type of tone and gamut mapping used
internally when color space conversions are required. As discussed at VDD'24,
the default was set to relative colorimetric clipping, which is approximately
associative, surjective and idempotent. As suc
From: Niklas Haas
This is no longer relevant after a change in color space.
---
libavfilter/vf_scale.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index e33617468a..a56d452c6c 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfil
From: Niklas Haas
Just for sanity.
---
libswscale/graph.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libswscale/graph.c b/libswscale/graph.c
index 36b74fad0c..311e2d0287 100644
--- a/libswscale/graph.c
+++ b/libswscale/graph.c
@@ -503,6 +503,7 @@ static void sws_graph_worker(void *priv,
From: Niklas Haas
This is a lightweight wrapper around the underlying color management system,
whose job it is merely to manage the 3DLUT state and apply them to the frame
data. This is where we might add platform-specific optimizations in the future.
I also plan on adding support for more pixel
From: Niklas Haas
Logic is loosely on equivalent decisions in libplacebo. The basic idea is to try
and be a bit conservative by treating AVCOL_*_UNSPECIFIED as a no-op, unless the
other primaries set are non-standard / wide-gamut or HDR. This helps avoid
unintended or unexpected colorspace conver
From: Niklas Haas
The underlying color mapping logic was ported as straightforwardly as possible
from libplacebo, although the API and glue code has been very heavily
refactored / rewritten. In particular, the generalization of gamut mapping
methods is replaced by a single ICC intent selection, a
From: Niklas Haas
This leverages the previously introduced color management subsystem in order
to adapt between transfer functions and color spaces, as well as for HDR tone
mapping.
---
libswscale/graph.c | 81 --
1 file changed, 79 insertions(+), 2 de
From: Niklas Haas
Without triggering a full graph reinit.
---
libswscale/graph.c | 21 -
libswscale/graph.h | 12 +---
libswscale/utils.h | 6 ++
3 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/libswscale/graph.c b/libswscale/graph.c
index 5a2d794
From: Niklas Haas
Logic ported from libplacebo's AVFrame helpers. The basic idea is to use the
provided MaxRGB/MaxSCL values to infer what the actual luminance would have
been, which HDR10+ metadata does not provide directly. It's worth pointing out
that this gives us an *upper* bound on the true
From: Niklas Haas
---
libswscale/utils.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 95b083b2eb..9ee36d1b09 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -46,6 +46,7 @@
#include "libavutil/imgutils.h"
#incl
From: Niklas Haas
Provide default values for the fields added in the previous commit.
---
libswscale/utils.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 569d037f25..95b083b2eb 100644
--- a/libswscale/utils.c
+++ b/libsw
From: Niklas Haas
We will use the av_csp_itu_eotf() functions to decode these internally, so
check this function to see if it succeeds.
---
libswscale/utils.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 32f90e366e..d07ca
Mention they are always owned and freed by the codec, except when using
deprecated avcodec_close().
Reported-By: DEATH on IRC
---
libavcodec/avcodec.h | 40
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/a
On Thu, 28 Nov 2024 15:29:54 +0100 Anton Khirnov wrote:
> Hi all,
> the current Technical Committee (TC) was elected on 2023-12-05 and its
> mandate lasts for one year, so we should hold a new election soon. If
> there are no unforeseen circumstances, I would like to start the vote on
> Monday 202
I hereby volunteer for the TC.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe"
49 matches
Mail list logo
