Andreas Rheinhardt:
> Patch attached.
>
> - Andreas
>
Will apply.
- Andreas
___
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.
> -Original Message-
> From: ffmpeg-devel On Behalf Of softworkz .
> Sent: Mittwoch, 4. Juni 2025 20:35
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> Objections Summary
> ==
>
>
> Here's a summary
> -Original Message-
> From: ffmpeg-devel On Behalf Of Michael
> Niedermayer
> Sent: Mittwoch, 4. Juni 2025 22:42
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> Hi Nicolas
>
> On Wed, Jun 04, 2025 at 09:13:44AM +020
Servus Manuel
On Wed, Jun 04, 2025 at 10:06:28PM +0200, Manuel Lauss wrote:
> Servus Michael,
>
> On Wed, Jun 4, 2025 at 1:00 PM Michael Niedermayer
> wrote:
> >
> > On Tue, Jun 03, 2025 at 12:30:40PM +0200, Manuel Lauss wrote:
> > > Servus Michael,
> > >
> > > On Sat, May 31, 2025 at 12:51 AM M
> On Jun 5, 2025, at 06:20, Kieran Kunhya via ffmpeg-devel
> wrote:
>
> On Wed, 4 Jun 2025, 12:46 Steven Liu, wrote:
>
>> Kieran Kunhya via ffmpeg-devel 于2025年6月4日周三
>> 19:35写道：
>> Hi Kieran,
>>
>>>
>>> @Andreas Rheinhardt
>>> Should we revert this?
>>
>> I believe it would be better to
The Concept of the Subtitle Filtering Patchset
==
I recognize and acknowledge that some have difficulties in understanding
and making sense of the approach that I've taken to make subtitle
filtering work in the way it does and to make it possible to cove
On Wed, Jun 04, 2025 at 01:42:42PM -0700, Baptiste Coudurier wrote:
>
> > On Jun 4, 2025, at 11:06 AM, Tomas Härdin wrote:
> >
> > sön 2025-06-01 klockan 21:23 +0200 skrev Michael Niedermayer:
> >> And the "explicit license notice" you refer to is this:
> >>
> >> "All Librempeg modifications, a
On Wed, 4 Jun 2025, 12:46 Steven Liu, wrote:
> Kieran Kunhya via ffmpeg-devel 于2025年6月4日周三
> 19:35写道：
> Hi Kieran,
>
> >
> > @Andreas Rheinhardt
> > Should we revert this?
>
> I believe it would be better to leave comments if there are any
> concerns about the patch. Several weeks have passed wi
Hi Nicolas
On Wed, Jun 04, 2025 at 09:13:44AM +0200, Nicolas George wrote:
> Zach Swena (HE12025-06-03):
[...]
>
> > This is why I have been trying to ask high level questions. His old
> > subtitle filtering patchset would need a lot of rework to bring to the
> > current codebase so starting over
> On Jun 4, 2025, at 11:06 AM, Tomas Härdin wrote:
>
> sön 2025-06-01 klockan 21:23 +0200 skrev Michael Niedermayer:
>> And the "explicit license notice" you refer to is this:
>>
>> "All Librempeg modifications, and any new files not available in
>> FFmpeg, are licensed under GPL v2,
>> unless
Servus Michael,
On Wed, Jun 4, 2025 at 1:00 PM Michael Niedermayer
wrote:
>
> On Tue, Jun 03, 2025 at 12:30:40PM +0200, Manuel Lauss wrote:
> > Servus Michael,
> >
> > On Sat, May 31, 2025 at 12:51 AM Michael Niedermayer
> > wrote:
> >
> > > > > > /* smooth top and left block border
> -Original Message-
> From: ffmpeg-devel On Behalf Of Rémi Denis-
> Courmont
> Sent: Mittwoch, 4. Juni 2025 17:49
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> Le tiistaina 3. kesäkuuta 2025, 20.07.18 Itä-Euroopan k
On Wed, Jun 4, 2025 at 5:15 AM Maryla Ustarroz-Calonge via
ffmpeg-devel wrote:
>
> Signed-off-by: Maryla Ustarroz-Calonge
> ---
> Changelog | 1 +
> libavcodec/libaomdec.c | 62 ++
> libavcodec/libaomenc.c | 55 +++
Objections Summary
==
Here's a summary of objections made so far:
Lynne
-
- Not using picture buffers for subtitle data
It's not impossible, just doesn't make much sense
I said there wasn't anybody against it anymore in 2022.
We can dig up previous conversations, or w
> -Original Message-
> From: ffmpeg-devel On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 20:13
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> softworkz . (HE12025-06-04):
> > You are the objector.
>
>
softworkz . (HE12025-06-04):
> You are the objector.
You are the one proposing these changes. Proving them valid is your
responsibility.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmp
> -Original Message-
> From: ffmpeg-devel On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 19:57
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> softworkz . (HE12025-06-04):
> > Those kinds of texts don't
sön 2025-06-01 klockan 21:23 +0200 skrev Michael Niedermayer:
> And the "explicit license notice" you refer to is this:
>
> "All Librempeg modifications, and any new files not available in
> FFmpeg, are licensed under GPL v2,
> unless stated otherwise."
>
> And it IS stated otherwise in these fi
softworkz . (HE12025-06-04):
> Those kinds of texts don't get us anywhere.
I confirm. If you want to get somewhere, get to work.
> Please provide specific example which demonstrate your claims.
Do the work yourself.
--
Nicolas George
___
ffmpeg-dev
> -Original Message-
> From: ffmpeg-devel On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 19:45
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> softworkz . (HE12025-06-04):
> > Please provide specific exa
softworkz . (HE12025-06-04):
> Please provide specific examples which demonstrate your claim.
If you are not able to derive them from what I posted these last few
days, then you do not have what it takes to write anything non trivial
for FFmpeg anyway.
But even if you are no able, I did post more
> -Original Message-
> From: ffmpeg-devel On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 19:26
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> softworkz . (HE12025-06-04):
> > whom did I attack other tha
> -Original Message-
> From: ffmpeg-devel On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 19:35
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> softworkz . (HE12025-06-04):
> > Again, please provide speci
softworkz . (HE12025-06-04):
> Again, please provide specific examples which do not work, to prove
> your claims.
I did. You are again trying to deflect.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailm
> -Original Message-
> From: ffmpeg-devel On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 19:30
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> softworkz . (HE12025-06-04):
> > I'd like to kind as you
>
softworkz . (HE12025-06-04):
> I'd like to kind as you
This ask of me being kind to you after you shamelessly admitted to
attacking me is so outrageous that it can count as an extra insult all
by itself.
If you genuinely want to make your patch better, you can do the work
yourself with what I pos
The av_display_rotation_get function previously yielded inconsistent
angles for certain reflected (mirrored) matrices. For instance,
a matrix representing a -45 degree rotation followed by a horizontal
flip resulted in 135 degrees, while the desired interpretation after
canonicalizing the reflectio
softworkz . (HE12025-06-04):
> whom did I attack other than NG?
A lot of people:
# Also, I cannot consider people as trustworthy while they are going crazy.
https://ffmpeg.org/pipermail/ffmpeg-devel/2025-May/344274.html
And this is just the one I remembered accurately enough to find it in a
few
> -Original Message-
> From: ffmpeg-devel On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 09:14
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> Zach Swena (HE12025-06-03):
> > The way I see it, rudeness ha
> -Original Message-
> From: ffmpeg-devel On Behalf Of Rémi Denis-
> Courmont
> Sent: Mittwoch, 4. Juni 2025 17:49
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> Le tiistaina 3. kesäkuuta 2025, 20.07.18 Itä-Euroopan k
This is a redo of 574f634e49847e2225ee50013afebf0de03ef013 using a flat
memory storage for the extradata.
PR review comments addressed:
* Use flat memory bytestream
* Re-use existing xiph extradata layout
---
libavcodec/vorbisdec.c | 42 ---
libavformat/oggparsevorbis
If the apperture window is bigger than the canvas, then the clap box is invalid
and there's no point calculating cropping values.
Fixes: libavformat/mov.c:1295:14: runtime error: -256 is outside the range of
representable values of type 'unsigned long'
Signed-off-by: James Almer
---
libavforma
> On Jun 4, 2025, at 22:05, Martin Storsjö wrote:
>
> On Wed, 4 Jun 2025, Jack Lau wrote:
>
>> ffmpeg | branch: master | Jack Lau | Fri May 16
>> 20:15:05 2025 +0800| [167e343bbe75515a80db8ee72ffa0c607c944a00] | committer:
>> Steven Liu
>>
>> avformat/whip: Add WHIP muxer support for subse
fix the missing data structure pkey in the tls_context
Signed-off-by: Jack Lau
---
libavformat/tls_openssl.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
index b589d5d90a..bddeee9af8 100
If its a problem, you'll likely want to set it to 1 than more fine-grained
control, which you can already do via the API.
---
libavutil/hwcontext_vulkan.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_v
On NVIDIA, there's a global maximum limit of approximately 112 queues,
which means it takes ONLY 7 total programs using the maximum amount of
queues to cause the driver to error out/*segfault* during initialization.
Also, each queue takes about 30ms to allocate, which quickly adds up.
This reduce
We don't use them, and on NVIDIA, each queue takes around 30ms
to allocate, and the driver has a global limit of ONLY 112 queues.
---
libavutil/hwcontext_vulkan.c | 8
1 file changed, 8 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index ce485a85a2
Le tiistaina 3. kesäkuuta 2025, 16.09.48 Itä-Euroopan kesäaika Michael
Niedermayer a écrit :
> > So, which of his "modifications" (commits) have an explicit statement
> > "otherwise"?
> I see this:
>
> commit 3ff6d301b27965b23ae5cf5211920ee16d6671c2
> Author: Anton Khirnov
> Date: Thu Oct 24 0
Le tiistaina 3. kesäkuuta 2025, 20.07.18 Itä-Euroopan kesäaika softworkz . a
écrit :
> Given the preceding conversations, it is pretty safe to assume
> that these comments are based on personal sentiments rather than
> technical expertise.
I won't deny the fact that several people have raised no
On Wed, 4 Jun 2025 17:05:23 +0300 (EEST), Martin Storsjö wrote:
> On Wed, 4 Jun 2025, Jack Lau wrote:
>
> > ffmpeg | branch: master | Jack Lau | Fri May 16
> > 20:15:05 2025 +0800| [167e343bbe75515a80db8ee72ffa0c607c944a00] |
> > committer: Steven Liu
> >
> > avformat/whip: Add WHIP muxer supp
On Mon, 2 Jun 2025 08:23:41 +, softworkz . wrote:
> What would happen if we merge everything?
>
> - We would gain 2.5 years of work
> - He will change all license headers
> - The doors will be closed for all future
there is no door closed forever. gplv2 code is still open source and
ffmpeg h
> FFlabs depends on FFmpeg so its interrests in terms of FFmpeg complying
> to all laws should be aligned here
Interesting, so the person that complains about FFlabs having too much
corporate control over FFmpeg is now ok to assume FFlabs legal opinion
"align[ing]" with FFmpeg.
Kieran
__
Hi
On Tue, Jun 03, 2025 at 11:38:11PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> >
> > all members of fflabs where aware of it as i asked about the license
> > situation it in the private
> > fflabs IRC channel. I asked there because fflabs/jb has a lawyer
> >
>
> Do you understand that the l
On Wed, 4 Jun 2025, Jack Lau wrote:
ffmpeg | branch: master | Jack Lau | Fri May 16 20:15:05
2025 +0800| [167e343bbe75515a80db8ee72ffa0c607c944a00] | committer: Steven Liu
avformat/whip: Add WHIP muxer support for subsecond latency streaming
This breaks compilation with OpenSSL 1.1.1t:
src
On Mon, 2 Jun 2025, Martin Storsjö wrote:
This avoids warnings like
cl : Command line warning D9002 : ignoring unknown option '-g'
---
gas-preprocessor.pl | 1 +
1 file changed, 1 insertion(+)
Pushed.
// Martin
___
ffmpeg-devel mailing list
ffmpe
Hi Nicolas
On Wed, Jun 04, 2025 at 09:24:23AM +0200, Nicolas George wrote:
> Hi.
>
> As I explained earlier in the “Subtitle Filtering Ramp-Up” thread:
>
> Any non-trivial progress on libavfilter requires touching the format
> negotiation code. The format negotiation code is very fragile and has
On 2 Jun 2025, at 22:29, Rémi Denis-Courmont wrote:
> Le torstaina 22. toukokuuta 2025, 21.38.32 Itä-Euroopan kesäaika Marvin Scholz
> a écrit :
>> When using a literal IPv6 address as hostname,
>> it can contain a Zone ID
>> especially in the case of link-local addresses. Sending this to the
>>
Thanks for the feedback. I'll look into it.
On Tue, Jun 3, 2025, 5:35 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Rashad Tatum:
> > Add implementation for changing the play rate for rtsp streams.
> > ---
> > libavformat/avformat.h| 6 ++
> > libavformat/demux.h
The new fate sample av1/metadata_hdr10_plus.ivf used in the second
test is the output of the first test.
Signed-off-by: Maryla Ustarroz-Calonge
---
tests/Makefile | 1 +
tests/fate-run.sh | 3 +-
tests/fate/av1.mak | 11 +++
Signed-off-by: Maryla Ustarroz-Calonge
---
Changelog | 1 +
libavcodec/libaomdec.c | 62 ++
libavcodec/libaomenc.c | 55 +
libavcodec/version.h | 2 +-
4 files changed, 119 insertions(+), 1 deletion(-)
d
Kieran Kunhya via ffmpeg-devel 于2025年6月4日周三 19:35写道：
Hi Kieran,
>
> @Andreas Rheinhardt
> Should we revert this?
I believe it would be better to leave comments if there are any
concerns about the patch. Several weeks have passed without
objections, and I’ve been actively maintaining it for over
@Andreas Rheinhardt
Should we revert this?
Kieran
___
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
Le 3 juin 2025 19:15:57 GMT+03:00, Niklas Haas a écrit :
>On Mon, 02 Jun 2025 15:41:33 -0300 James Almer wrote:
>> GCC/Clang is smart enough to emit minss/maxss the same way as these
>> functions.
>> The only theoretical benefit was in x86_32, where x87 floats are used, but
>> the
>> penalty
Le 3 juin 2025 19:14:16 GMT+03:00, Niklas Haas a écrit :
>We have an open bug in swscale on 32-bit platforms where the use of x87 causes
>non-bitexact results in 32-bit platforms, resolved by setting -mfpu=sse at
>build time.
>
>Maybe we should think about setting this flag globally?
Enabling S
On Tue, Jun 03, 2025 at 12:30:40PM +0200, Manuel Lauss wrote:
> Servus Michael,
>
> On Sat, May 31, 2025 at 12:51 AM Michael Niedermayer
> wrote:
>
> > > > > /* smooth top and left block borders with neighbours */
> > > > > -if (((pxoff - p + k) < 0) || ((pxoff - p + k)
From: Niklas Haas
\o/
---
libswscale/graph.c | 84 --
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/libswscale/graph.c b/libswscale/graph.c
index dc7784aa49..24930e7627 100644
--- a/libswscale/graph.c
+++ b/libswscale/graph.c
@@ -34,6
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 fast path, which uses pshufb at vect
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
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 doc/swscale-v2.txt for design details.
---
libswscale/Makefile| 1 +
libswscale/ops_chain.c | 283 +
libswscale/ops_chain.h | 134 +++
3 files changed, 418 insertions(+)
create mode 100644 libswscale/ops_chain.c
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.
It easily beats the old C code and sometimes even the old SIMD.
In theory, we can dramatically speed it up by using GCC vectors in
From: Niklas Haas
Provides a generic fast path for any operation list that can be decomposed
into a series of memcpy and memset operations.
25% faster than the x86 backend for yuv444p -> yuva444p
33% faster than the x86 backend for gray -> yuvj444p
---
libswscale/Makefile | 1 +
libswscal
From: Niklas Haas
We split the standard macro into its body (implementation) and declaration,
and use a macro argument in place of the raw `memcmp` call, with the major
difference that we now take the number of pixels to compare instead of the
number of bytes (to match the signature of float_near
From: Niklas Haas
This is responsible for taking a "naive" ops list and optimizing it
as much as possible. Also includes a small analyzer that generates component
metadata for use by the optimizer.
---
libswscale/Makefile| 1 +
libswscale/ops.h | 12 +
libswscale/ops_optimiz
From: Niklas Haas
This handles the low-level execution of an op list, and integration into
the SwsGraph infrastructure. To handle frames with insufficient padding in
the stride (or a width smaller than one block size), we use a fallback loop
that pads the last column of pixels using `memcpy` into
From: Niklas Haas
This adds an internal API for ops backends, which are responsible for
compiling op lists into executable functions.
---
libswscale/ops.c | 62 ++
libswscale/ops_internal.h | 108 ++
2 files changed, 170 insertion
From: Niklas Haas
See docs/swscale-v2.txt for an in-depth introduction to the new approach.
This commit merely introduces the ops definitions and boilerplate functions.
The subsequent commits will flesh out the underlying implementation.
---
libswscale/Makefile | 1 +
libswscale/ops.c| 52
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, even while development is
still ongoing.
---
doc/APIchanges | 3 +++
doc/scaler.texi | 4
libswscale/options.c | 1 +
libswscale/swsca
From: Niklas Haas
Reset an SwsFormat to its fully unset/invalid state.
---
libswscale/format.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libswscale/format.h b/libswscale/format.h
index 3b6d745159..be92038f4f 100644
--- a/libswscale/format.h
+++ b/libswscale/format.h
@@
From: Niklas Haas
This can turn any compatible sequence of operations into a single packed
shuffle, including packed swizzling, grayscale->RGB conversion, endianness
swapping, RGB bit depth conversions, rgb24->rgb0 alpha clearing and more.
---
libswscale/ops_internal.h | 28 +++
libswsc
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.
Changes since v3:
- correctly guard the x86 backend behind ARCH_X86_64
- remove an unnecessary restriction on the packed shuffle solver preventing
it from being used for e.g. ya8 -> gray downconversion
- fixed typo (max_elp -> max_ulp)
- added new checkasm test to checkasm.mak
__
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
Prevents potential null pointer dereference when querying
MaxL1ReferencesForB from codec-specific support structures
during GOP structure initialization.
---
libavcodec/d3d12va_encode.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/d3d12va_encode.c b/libav
Diederick C. Niehorster (HE12025-06-04):
> This sounds like something that STF funding would be good for?
I had that kind of idea too, which is why I sent the mail I just sent in
a new thread.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
Zach Swena (HE12025-06-03):
> The way I see it, rudeness has been present on all sides of most of the
> conflicts I have seen on the ML lately and it is way too easy to reflect
> rudeness back so yes I think everyone on here needs to get over it and work
> together politely.
How do you work polite
Hendrik Leppkes (HE12025-06-03):
> In fact, this is the main problem that plagued this patchset from the
> start.
Not the main one, only the one that people who are not familiar with the
current state of libavfilter will notice immediately.
But still, I agree that softworkz's attitude on this is
softworkz . (HE12025-06-03):
> Talk is cheap but work is hard!
Which is why after authoring a patch series that can only handle toy use
cases you are more ready to talk it into the project than work at making
it acceptable.
--
Nicolas George
___
ffmp
softworkz . (HE12025-06-03):
> How many people do remember that Paul actually wanted to merge my patchset?
>
> But somebody held him up. It's documented on the ML.
I prevented Paul from pushing quite a few half-assed patches over the
years. More often than not, after a mandatory bullheaded period
Hi.
As I explained earlier in the “Subtitle Filtering Ramp-Up” thread:
Any non-trivial progress on libavfilter requires touching the format
negotiation code. The format negotiation code is very fragile and has
almost no test coverage at all.
Touching it as is would be suicidal.
Therefore, any n
On Wed, Jun 4, 2025, 09:13 Nicolas George wrote:
>
> These things are some of the things I criticized about softworkz's patch
> series: refactoring the negotiation code and then the utility filters.
>
> The issue with this is that the negotiation code is extremely fragile
> and has barely any tes
81 matches
Mail list logo
