---
libavcodec/nvenc.c | 62 +++--
libavcodec/nvenc.h | 1 +
libavcodec/nvenc_h264.c | 3 ++
3 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index f9221174f0..7ae1e7c8d7 100644
--- a/libavcodec/
On 28.02.2025 23:46, Timo Rothenpieler wrote:
---
libavcodec/Makefile| 2 ++
libavcodec/timecode_internal.c | 19 +++
libavcodec/utils.c | 29 +++--
libavutil/Makefile | 3 +++
4 files changed, 27 insertions(+), 2
---
libavutil/timecode.c | 27 +++
libavutil/timecode_internal.c | 51 +++
libavutil/timecode_internal.h | 51 +++
3 files changed, 105 insertions(+), 24 deletions(-)
create mode 100644 libavutil/timecode_int
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Freitag, 28. Februar 2025 14:52
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] [RFC] avtextformat: Transform
> text writing into an independent API
>
> ffmpeg
Before and after:
A78
ac3_extract_exponents_n512_neon: 503.2 ( 3.36x)
ac3_extract_exponents_n3072_neon: 2986.2 ( 3.35x)
ac3_extract_exponents_n512_neon: 211.2 ( 8.02x)
ac3_extract_exponents_n3072_neon: 1251.5 ( 8.
Before and after:
A78
ac3_sum_square_bufferfly_int32_neon: 484.8 ( 2.00x)
ac3_sum_square_bufferfly_int32_neon: 468.2 ( 2.08x)
A72
ac3_sum_square_bufferfly_int32_neon: 793.6 ( 1.26x)
ac3_sum_square_bufferfly_int32_neon: 527.3
martin schitter (HE12025-02-28):
> This kind of checks should better happen in some kind of CI based pipeline
> supporting direct feedback to the contributors before accepting the patches
> for any further human review by maintainers or on public mailing lists.
>
> That's why I really like GitLab
On Fri, Feb 28, 2025 at 8:27 PM Michael Niedermayer
wrote:
> Hi Marth64
>
> On Thu, Feb 27, 2025 at 05:00:30PM -0600, Marth64 wrote:
> > Hi Michael,
> >
> > Thanks for the reply & thoughts.
> >
> > To clarify on "internal panel" and "structured issue resolution", this
> > is with regards to unres
Le mar. 25 févr. 2025 à 16:01, Romain Beauxis
a écrit :
>
> This is a series of patches to allow proper decoding of ogg metadata in
> chained
> `ogg/vorbis, `ogg/flac` and `ogg/opus` streams.
Lynne, Michael, any interest in reviewing this series?
It's definitely the cleaner it's ever been and I
On Thu, Feb 27, 2025 at 05:00:30PM -0600, Marth64 wrote:
[...]
> It's not a blanket statement for a revolution.
>
> For example, laying a parallel hypothetical, this is as if the TC met
> once a week to discuss "what's on our agenda this week? what actions
The TC has no agenda. It handles cases o
Hi Marth64
On Thu, Feb 27, 2025 at 05:00:30PM -0600, Marth64 wrote:
> Hi Michael,
>
> Thanks for the reply & thoughts.
>
> To clarify on "internal panel" and "structured issue resolution", this
> is with regards to unresolved complaints sent to CC, such as publicly
> or privately reported interp
On Fri, Feb 28, 2025 at 4:16 PM Nicolas George wrote:
> James Almer (HE12025-02-28):
> > You're the last person i expected to say something so childish...
>
> Ad-hominem.
>
> > Ok, you finally answered my question. And it's disappointing to know you
> > consider the currently most active develope
---
libavdevice/avfoundation.m | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 61dac4b713..b625990c37 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -375,6 +375,15 @@ static int configure_video_de
Le 27 février 2025 23:01:45 GMT+02:00, Michael Niedermayer
a écrit :
>we have a memleak, a use after free, a aliasing violation,
>some invalid pointer and a out of array read
>
>a safe language should not allow any of this
>C++ allows all of it, its not safe, switching to C++ doesnt help
To be
On 2/28/2025 11:50 AM, Nicolas George wrote:
James Almer (HE12025-02-28):
From the two people i remember
You are forgetting some.
that were strongly against AVWriter, one was
a huge contributor, and left. So he certainly doesn't fit your description.
No,
James Almer (HE12025-02-28):
> You're the last person i expected to say something so childish...
Ad-hominem.
> Ok, you finally answered my question. And it's disappointing to know you
> consider the currently most active developers (several dozens of them)
> voting for the direction of the projec
On Fri, Feb 28, 2025 at 4:09 PM Nicolas George wrote:
> Hard rules on cosmetic matters are a terrible idea, whether they are
> enforced at the level of the language or downstream from it.
agree to disagree :)
--
Vittorio
___
ffmpeg-devel mailing list
Hi Lynne
On Fri, Feb 28, 2025 at 01:24:46PM +0100, Lynne wrote:
>
>
> On 28/02/2025 03:33, Michael Niedermayer wrote:
> > On Fri, Feb 28, 2025 at 03:25:06AM +0100, Lynne wrote:
> > > On 27/02/2025 02:10, Michael Niedermayer wrote:
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > >
On 2/28/2025 11:38 AM, Nicolas George wrote:
James Almer (HE12025-02-28):
Who among those still around after last Christmas (and in the TC, or
ultimately the GA, both of which would have a last word) is against your fun
things?
I could give you names, but you know them as well as me. The issue
---
libavcodec/Makefile| 8
libavcodec/aac/Makefile| 9 +
libavcodec/{ => aac}/aac_defines.h | 0
libavcodec/aac/aacdec.c| 4 ++--
libavcodec/aac/aacdec_fixed.c | 4 ++--
libav
James Almer (HE12025-02-28):
> From the two people i remember
You are forgetting some.
> that were strongly against AVWriter, one was
> a huge contributor, and left. So he certainly doesn't fit your description.
> No, i didn't.
Too late.
> And you'
On 2/28/2025 5:59 AM, Nicolas George wrote:
Niklas Haas (HE12025-02-27):
Any further comments about this series? If not, I intend to merge after the
weekend is over.
You have a stray change on libplacebo in patch 4. Apart from that, I
have not looked that closely at the code — and am not motiva
James Almer (HE12025-02-28):
> Who among those still around after last Christmas (and in the TC, or
> ultimately the GA, both of which would have a last word) is against your fun
> things?
I could give you names, but you know them as well as me. The issue is
that they have that authority in the fi
On 2/28/2025 11:13 AM, Nicolas George wrote:
James Almer (HE12025-02-28):
Can you elaborate? Your statement can be interpreted in two very different
ways.
I am not contributing boring but useful things to the project as long as
people who have contributed very little themselves are allowed to
On 2/28/25 15:07, Devin Heitmueller wrote:
I've been working on the codebase for more than eight years, and
didn't know it existed. I would suggest that people reviewing patches
and rejecting them due to style issues that they recommend to
submitters to run the tool. In my experience, develo
Devin Heitmueller (HE12025-02-28):
> I've been working on the codebase for more than eight years, and
> didn't know it existed.
# @anchor{Submitting patches}
# …
# Use the patcheck tool of FFmpeg to check your patch.
Fourth point in doc/developer.texi.
Regards,
--
Nicolas George
James Almer (HE12025-02-28):
> Can you elaborate? Your statement can be interpreted in two very different
> ways.
I am not contributing boring but useful things to the project as long as
people who have contributed very little themselves are allowed to
prevent me from working on fun things too.
Y
On Thu, Feb 27, 2025 at 7:59 PM Michael Niedermayer
wrote:
> we have tools/patcheck :)
> I have the feeling we started forgeting about it
I've been working on the codebase for more than eight years, and
didn't know it existed. I would suggest that people reviewing patches
and rejecting them due
---
libavcodec/Makefile| 18 ++
libavcodec/aac/Makefile| 7 +++
libavcodec/{ => aac}/aac.h | 0
libavcodec/{ => aac}/aaccoder.c| 10 +-
libavcodec/{ => aac}/aaccoder_trellis.h
ffmpegagent (HE12025-02-28):
> This patchset doesn't aim to improve or change the API itself - that would
> be a bit too much at once.
So you asked for advice, got come counsel from me and did exactly the
opposite. Do not be surprised if the result is less than satisfactory.
> * Public API isn't
On Fri, Feb 28, 2025 at 8:14 AM compn wrote:
> On Thu, 27 Feb 2025 23:41:14 +0100, Vittorio Giovara wrote:
>
> > them and make sure we can keep working together without grudges. Also
> there
> > are a lot of pending issues from that time (the most grave one IMO, how a
> > mailing list admin unila
On Fri, Feb 28, 2025 at 1:25 PM Lynne wrote:
>
>
> On 28/02/2025 03:33, Michael Niedermayer wrote:
> > On Fri, Feb 28, 2025 at 03:25:06AM +0100, Lynne wrote:
> >> On 27/02/2025 02:10, Michael Niedermayer wrote:
> >>> Signed-off-by: Michael Niedermayer
> >>> ---
> >>>doc/developer.texi | 11 +
On 2/28/2025 10:00 AM, Andreas Rheinhardt wrote:
James Almer:
On 2/28/2025 7:43 AM, Andreas Rheinhardt wrote:
James Almer:
Signed-off-by: James Almer
---
libavcodec/allcodecs.c | 1 +
libavcodec/codec_internal.h | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --
IndecisiveTurtle:
> Useful when creating a descriptor array of separate images
> ---
> libavutil/vulkan.c | 12 ++--
> libavutil/vulkan.h | 8
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
> index 31610e2d94..9141595
James Almer:
> On 2/28/2025 7:43 AM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Signed-off-by: James Almer
>>> ---
>>> libavcodec/allcodecs.c | 1 +
>>> libavcodec/codec_internal.h | 6 +++---
>>> 2 files changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libavcodec/allcodec
Useful when creating a descriptor array of separate images
---
libavutil/vulkan.c | 12 ++--
libavutil/vulkan.h | 8
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
index 31610e2d94..91415957fd 100644
--- a/libavutil/vulkan.
On 28/02/2025 08:49, IndecisiveTurtle wrote:
Useful when creating a descriptor array of separate images
---
libavutil/vulkan.c | 12 ++--
libavutil/vulkan.h | 8
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
index 316
On 25/02/2025 21:45, Krzysztof Pyrkosz via ffmpeg-devel wrote:
---
This patch rids the code from two tbl instructions and the shuffle
table. There's no fneg v0.s[3] instruction unfortunately, so I negate
the whole vector and copy the last element only.
It's tricky to benchmark this little change
On 28/02/2025 03:33, Michael Niedermayer wrote:
On Fri, Feb 28, 2025 at 03:25:06AM +0100, Lynne wrote:
On 27/02/2025 02:10, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer
---
doc/developer.texi | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git
On 2/28/2025 7:43 AM, Andreas Rheinhardt wrote:
James Almer:
Signed-off-by: James Almer
---
libavcodec/allcodecs.c | 1 +
libavcodec/codec_internal.h | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 4e1b1c9
---
Will push soon, as this is quite trivial.
---
libswresample/aarch64/resample.S | 8
libswscale/aarch64/yuv2rgb_neon.S | 10 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/libswresample/aarch64/resample.S b/libswresample/aarch64/resample.S
index 6d9eaaeb23.
On Fri, 28 Feb 2025 11:49:53 +0100 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > On Fri, 28 Feb 2025 10:31:19 +0800 Zhao Zhili
> > wrote:
> >> Cc haasn.
> >>
> >> Libswscale in under refactor. Does current asm works after refactor, or
> >> they need to be refactored or
> >> rewrite after? If it
Niklas Haas:
> On Fri, 28 Feb 2025 10:31:19 +0800 Zhao Zhili wrote:
>> Cc haasn.
>>
>> Libswscale in under refactor. Does current asm works after refactor, or they
>> need to be refactored or
>> rewrite after? If it’s the second case, maybe we should hold on to do more
>> asm with libswscale
>>
On Fri, 28 Feb 2025, Niklas Haas wrote:
On Fri, 28 Feb 2025 10:31:19 +0800 Zhao Zhili wrote:
Cc haasn.
Libswscale in under refactor. Does current asm works after refactor, or they
need to be refactored or
rewrite after? If it’s the second case, maybe we should hold on to do more asm
with li
James Almer:
> Signed-off-by: James Almer
> ---
> libavcodec/allcodecs.c | 1 +
> libavcodec/codec_internal.h | 6 +++---
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 4e1b1c9b45..3be33f5cc4 100644
> --- a/libavco
On Fri, 28 Feb 2025 10:31:19 +0800 Zhao Zhili wrote:
> Cc haasn.
>
> Libswscale in under refactor. Does current asm works after refactor, or they
> need to be refactored or
> rewrite after? If it’s the second case, maybe we should hold on to do more
> asm with libswscale
> before hassn work done
On 28 Feb 2025, at 8:53, Nicolas George wrote:
> Michael Niedermayer (HE12025-02-28):
>> we have tools/patcheck :)
>> I have the feeling we started forgeting about it
>
> You cannot click on it. Therefore, the coders who are somehow capable of
> producing C code at quality level for FFmpeg but
From: Wang Yaqiang
Signed-off-by: Wang Yaqiang
---
libavcodec/libwebpenc_animencoder.c | 17 +++--
libavcodec/libwebpenc_common.c | 2 ++
libavcodec/libwebpenc_common.h | 1 +
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libwebpenc_animencod
From: Wang Yaqiang
Signed-off-by: Wang Yaqiang
---
libavcodec/libwebpenc_animencoder.c | 17 +++--
libavcodec/libwebpenc_common.c | 2 ++
libavcodec/libwebpenc_common.h | 1 +
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libwebpenc_animencod
From: Wang Yaqiang
Signed-off-by: Wang Yaqiang
---
libavcodec/libwebpenc_animencoder.c | 18 --
libavcodec/libwebpenc_common.c | 2 ++
libavcodec/libwebpenc_common.h | 1 +
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libwebpenc_animenco
Niklas Haas (HE12025-02-27):
> Any further comments about this series? If not, I intend to merge after the
> weekend is over.
You have a stray change on libplacebo in patch 4. Apart from that, I
have not looked that closely at the code — and am not motivated to do so
under the rule of fake democra
Niklas Haas (HE12025-02-27):
> Any further comments about this series?
As I said the reply I just sent: the code that prevents a component not
ready from receiving a premultiplied frame must be there immediately,
not to be added sometime later (i.e. never).
Regards,
--
Nicolas George
Niklas Haas (HE12025-02-20):
> This is true; I am thinking about adding negotiation to this in libavfilter
> down the line as well, for the same reason. I just want to get the basic
> infrastructure in place first.
Ok, but... see later.
> I don't see it as being worse than the status quo of silen
On Thu, 27 Feb 2025 23:41:14 +0100, Vittorio Giovara wrote:
> them and make sure we can keep working together without grudges. Also there
> are a lot of pending issues from that time (the most grave one IMO, how a
> mailing list admin unilaterally censors a thread) whose resolution we
> should at
54 matches
Mail list logo
