[FFmpeg-devel] SDR lib comments

[FFmpeg-devel] SDR lib comments

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1274 bytes --]

Hi all

ive promised to write a mail about SDR at the confernece about a seperate lib,
here is it (i in fact had this half written already before)

The SDR code in FFmpeg was and is intended to be a plain simple libavdevice input device
same as x11 and others
SDR is complex and not a simple memcpy() from a /dev file. To implement SDR many
design decissions have to be made, there are often more than one way things can be
done.
In the inside of a SDR input module these decissions are invissible,
they can be changed each commit as bugfixes and optimizatzions require.

OTOH, if SDR or parts of SDR are in a seperate library, some decissions now would
affect the public API and ABI, thats a added difficulty.

With audio resampling, FFmpeg supported resampling internally long before
providing libswresample. Audio resampling is also simpler than SDR.

Is a seperate library really the right choice for SDR in FFmpeg at this stage ?

Also code can always be moved into an seperate library but its much harder
to move or change it once such library is public.

Thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Anton Khirnov]

Quoting Michael Niedermayer (2023-09-23 18:43:44)
> Is a seperate library really the right choice for SDR in FFmpeg at this stage ?
> 
> Also code can always be moved into an seperate library

we've had postproc in the tree for ages, nobody maintains it or
cares about it, yet it seems impossible to get rid of it.

> but its much harder to move or change it once such library is public.

Compatibility rules you choose for your new library are entirely up to
you, they can (and probably should) be very loose at the beginning.

-- 
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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1229 bytes --]

On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-09-23 18:43:44)
> > Is a seperate library really the right choice for SDR in FFmpeg at this stage ?
> > 
> > Also code can always be moved into an seperate library
> 
> we've had postproc in the tree for ages, nobody maintains it or
> cares about it, yet it seems impossible to get rid of it.

what maintaince does it need ?
i mean i know the code is ugly but what _needs_ to be changed?

libpostproc implements part of ISO/IEC 14496-2
(that is the spec for an MPEG-4 ASP decoder)

its content could be moved in libavfilter and or the mpeg4 decoder
(there are arguments to be made for either)
but it doesnt belong in a lib external to FFmpeg.
(and in the process some bits probably can be droped as they
 no longer serve a purpose compared to other filters)

I have too many other things to work on to do a big refactoring of it
but if there are small bugs in it or questions about it i can look into them

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Rémi Denis-Courmont]

Le 28 septembre 2023 22:28:35 GMT+03:00, Michael Niedermayer <michael@niedermayer.cc> a écrit :
>On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2023-09-23 18:43:44)
>> > Is a seperate library really the right choice for SDR in FFmpeg at this stage ?
>> > 
>> > Also code can always be moved into an seperate library
>> 
>> we've had postproc in the tree for ages, nobody maintains it or
>> cares about it, yet it seems impossible to get rid of it.
>
>what maintaince does it need ?
>i mean i know the code is ugly but what _needs_ to be changed?

This is rather disingenous, TBH. All non-trivial code needs maintenance.

If there is no formal proof that the code is perfect, then it's probably bugged. And for the sake of the argument, if there were such a proof, it would need to be maintained as the code around changes, so either wayw that's maintenance.

Then you also can't really ascertain that the code won't need fixes for future build environments and code auditing tools.

And then you have all the more or less hidden costs of keeping code around, especially if it's unmaintained : people will enable it (if it's even disabled by default), hit problems and look for support.

And as a downstream OSS application developer, I'd really rather postproc be officially and properly dropped, so I can justify dropping it downstream as well.


But at least, postproc doesn't engender extra traffic on this mailing list much at all. More or less nobody here can or wants to review or test your SDR code. I think, more so than ffmpeg.git being ill-suited a source code repository for SDR because it is so niche and loosely related, ffmpeg-devel is simply not suited for SDR. The skills are not here, the time and motivation are not here, not to speak of the good will.

If the project grows and develops to become better accepted as a fit for FFmpeg, it can be merged (like btrfs.git got merged into Linux, with full git history). Honestly I think that probably will never happen, especially not after at least two distinct attempts to make it a fait accompli in spite of FFmpeg-devel. But I'm not a medium.

In the end, cool but controversial new features being rejected due to poor community acceptance, and continuing their life elsewhere, is quite common and mundane. It happened to me more than once (not in FFmpeg, obviously).


>libpostproc implements part of ISO/IEC 14496-2
>(that is the spec for an MPEG-4 ASP decoder)
>
>its content could be moved in libavfilter and or the mpeg4 decoder
>(there are arguments to be made for either)
>but it doesnt belong in a lib external to FFmpeg.
>(and in the process some bits probably can be droped as they
> no longer serve a purpose compared to other filters)
>
>I have too many other things to work on to do a big refactoring of it
>but if there are small bugs in it or questions about it i can look into them
>
>thx
>
>[...]
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2402 bytes --]

On Fri, Sep 29, 2023 at 12:05:56AM +0300, Rémi Denis-Courmont wrote:
> 
> 
> Le 28 septembre 2023 22:28:35 GMT+03:00, Michael Niedermayer <michael@niedermayer.cc> a écrit :
> >On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
> >> Quoting Michael Niedermayer (2023-09-23 18:43:44)
> >> > Is a seperate library really the right choice for SDR in FFmpeg at this stage ?
> >> > 
> >> > Also code can always be moved into an seperate library
> >> 
> >> we've had postproc in the tree for ages, nobody maintains it or
> >> cares about it, yet it seems impossible to get rid of it.
> >
> >what maintaince does it need ?
> >i mean i know the code is ugly but what _needs_ to be changed?
> 
> This is rather disingenous, TBH. All non-trivial code needs maintenance.
> 
> If there is no formal proof that the code is perfect, then it's probably bugged. And for the sake of the argument, if there were such a proof, it would need to be maintained as the code around changes, so either wayw that's maintenance.
> 
> Then you also can't really ascertain that the code won't need fixes for future build environments and code auditing tools.
> 
> And then you have all the more or less hidden costs of keeping code around, especially if it's unmaintained : people will enable it (if it's even disabled by default), hit problems and look for support.
> 
> And as a downstream OSS application developer, I'd really rather postproc be officially and properly dropped, so I can justify dropping it downstream as well.
> 
> 
> But at least, postproc doesn't engender extra traffic on this mailing list much at all. More or less nobody here can or wants to review or test your SDR code. I think, more so than ffmpeg.git being ill-suited a source code repository for SDR because it is so niche and loosely related, ffmpeg-devel is simply not suited for SDR. The skills are not here, the time and motivation are not here, not to speak of the good will.

My reply was only about libpostproc, I was intending to just ask what exactly
needs to be done in libpostproc (aka maintaince)

i had not intended to somehow refer to anything else. I should have snipped
the other bits of the quoted thread probably

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Nicolas George]

Rémi Denis-Courmont (12023-09-29):
> And as a downstream OSS application developer, I'd really rather
> postproc be officially and properly dropped, so I can justify dropping
> it downstream as well.

Let me get this straight? You COULD just add --disable-postproc in your
downstream project and be done with it, but you would rather that FFmpeg
removes the feature (granted, of limited use, but still of use to some
people) so that you do not take the blame for removing it?

Well, I think this makes it obvious why I think people representing
downstream projects should have very little influence on the future of
FFmpeg.

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Rémi Denis-Courmont]

Le 29 septembre 2023 10:03:13 GMT+03:00, Nicolas George <george@nsup.org> a écrit :
>Rémi Denis-Courmont (12023-09-29):
>> And as a downstream OSS application developer, I'd really rather
>> postproc be officially and properly dropped, so I can justify dropping
>> it downstream as well.
>
>Let me get this straight? You COULD just add --disable-postproc in your
>downstream project and be done with it, but you would rather that FFmpeg
>removes the feature (granted, of limited use, but still of use to some
>people) so that you do not take the blame for removing it?

We can't just --disable-whatever. We do support building against distribution-provided FFmpeg afterall, where we have no influence on the build settings. We try to be nice and cooperative upstreams and downstreams.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Nicolas George]

Rémi Denis-Courmont (12023-09-29):
> We can't just --disable-whatever. We do support building against
> distribution-provided FFmpeg afterall, where we have no influence on
> the build settings. We try to be nice and cooperative upstreams and
> downstreams.

Oh, but if you rely on FFmpeg from distros, it is even easier: you just
ignore libpostproc.

I can assure you, your program will not magically link with libpostproc
if you do not tell it to.

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Rémi Denis-Courmont]

Le 29 septembre 2023 10:03:13 GMT+03:00, Nicolas George <george@nsup.org> a écrit :
>Well, I think this makes it obvious why I think people representing
>downstream projects should have very little influence on the future of
>FFmpeg.

First, I don't *represent* any downstream. I just happen to be one of several maintainers of one such project. My current FFmpeg activities have little if anything to do with that downstream, and can and hopefully will be used by FFmpeg CLI as well as by other downstreams.

So if this was an attempt to discredit me, it's failed.

And then, as somebody who's been involved in OSS for over 20 years, including contributions to Linux, QEMU, FFmpeg, Wireshark and Debian, thousands of code reviews and tens of thousands of merged patches, I don't exactly care for your superiority complex. In my experience, what you claim as obvious (I'd call it the Lua approach to open-source development) would be considered obviously bad if not outright toxic behaviour in most projects and by most developers.

(And I am referring to the notion of ignoring or mostly ignoring downstream projects, not to you or any other person.)
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Nicolas George]

Rémi Denis-Courmont (12023-09-29):
> First, I don't *represent* any downstream. I just happen to be one of
> several maintainers of one such project.

And you write here about them: you decide to represent them.

>						   In my experience,
> what you claim as obvious (I'd call it the Lua approach to open-source
> development) would be considered obviously bad if not outright toxic
> behaviour in most projects and by most developers.

Maybe these projects do not have the same mindset of history than
ffmpeg. That does not prove I am wrong.

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Vittorio Giovara]

On Fri, Sep 29, 2023 at 3:03 AM Nicolas George <george@nsup.org> wrote:

> Well, I think this makes it obvious why I think people representing
> downstream projects should have very little influence on the future of
> FFmpeg.
>

In a previous thread you said SDR shouldn't be a separate library because
it wastes downstream time to package and bundle it separately.
Now you're saying downstream should have no influence on project decisions.

Can you make up your mind? While at it, maybe try and avoid discrediting
the person you're responding to only because they have a different opinion
than you.
Thanks!
-- 
Vittorio
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Nicolas George]

Vittorio Giovara (12023-09-29):
> In a previous thread you said SDR shouldn't be a separate library because
> it wastes downstream time to package and bundle it separately.

No, it wastes Michael's time.

It also wastes downstream time, indeed, but that is not our problem.
Yet, it shows how useless the proposal of a separate library is at this
point.

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Vittorio Giovara]

On Thu, Sep 28, 2023 at 3:28 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-09-23 18:43:44)
> > > Is a seperate library really the right choice for SDR in FFmpeg at
> this stage ?
> > >
> > > Also code can always be moved into an seperate library
> >
> > we've had postproc in the tree for ages, nobody maintains it or
> > cares about it, yet it seems impossible to get rid of it.
>
> what maintaince does it need ?
>

making sure that the library builds on all supported system, doesn't have
security holes, etc
or for packagers to bundle the library


> libpostproc implements part of ISO/IEC 14496-2
> (that is the spec for an MPEG-4 ASP decoder)
>

We're going a bit off topic, but you're referring to something preceding
H264 which means is something older than 20 years -- while old formats
surely need to be supported against digital obsolescence, the
code:functionality ratio is certainly not worth it (who uses ASP
nowadays?), and as you suggest, it's code that could definitely live in
libavfilter or libavcodec and not in a separate library.


> I have too many other things to work on to do a big refactoring of it
> but if there are small bugs in it or questions about it i can look into
> them
>

I think the main reason libpostproc was mentioned is that we don't want a
repeat of the history for SDR - so far you're only developer expressing
active interest to work on it, and nobody knows if you will be continuing
to work on it after releasing it, or for how long, and in which depth. The
community at large (except one vocal member) seems to prefer that this code
live in a separate repository, and not into ffmpeg mainline, so that we
could avoid risking repeating history of having "ugly code" (your words) in
the main repo for who knows how long, possibly forever.

Once the SDR code is better defined, as library, executable or whatever,
and there are users needing it, we could discuss bringing it back in
FFmpeg, in a more defined and clean form.
-- 
Vittorio
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2471 bytes --]

On Thu, Sep 28, 2023 at 05:07:17PM -0400, Vittorio Giovara wrote:
> On Thu, Sep 28, 2023 at 3:28 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-09-23 18:43:44)
> > > > Is a seperate library really the right choice for SDR in FFmpeg at
> > this stage ?
> > > >
> > > > Also code can always be moved into an seperate library
> > >
> > > we've had postproc in the tree for ages, nobody maintains it or
> > > cares about it, yet it seems impossible to get rid of it.
> >
> > what maintaince does it need ?
> >
> 
> making sure that the library builds on all supported system, doesn't have
> security holes, etc

is it failing to build ?
i would expect if it fails to build to be contacted about that. Or well
if not that people would not expect it to be fixed by me.

are there security holes ?
If so i would expect them to be reported to ffmpeg-security or me or
something like that.


> or for packagers to bundle the library
> 
> 
> > libpostproc implements part of ISO/IEC 14496-2
> > (that is the spec for an MPEG-4 ASP decoder)
> >
> 
> We're going a bit off topic, but you're referring to something preceding
> H264 which means is something older than 20 years -- while old formats
> surely need to be supported against digital obsolescence, the
> code:functionality ratio is certainly not worth it (who uses ASP
> nowadays?),

There is substantial amounts of existing material in ASP


[...]

> 
> 
> > I have too many other things to work on to do a big refactoring of it
> > but if there are small bugs in it or questions about it i can look into
> > them
> >
> 
> I think the main reason libpostproc was mentioned is that we don't want a
> repeat of the history for SDR - so far you're only developer expressing

SDR currently is completely self contained in a input device/demuxer.
Thats the very opposite of libpostproc which is a bit of video filtering
a bit of mpeg4 ASP and neither in libavfilter (which did not exist when libpostproc
was created) nor libavcodec

The main obstacle to cleanup libpostproc is probably the old style interleaved
SIMD code. Again this has no parallel to SDR

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Anton Khirnov]

Quoting Michael Niedermayer (2023-09-28 21:28:35)
> On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-09-23 18:43:44)
> > > Is a seperate library really the right choice for SDR in FFmpeg at this stage ?
> > > 
> > > Also code can always be moved into an seperate library
> > 
> > we've had postproc in the tree for ages, nobody maintains it or
> > cares about it, yet it seems impossible to get rid of it.
> 
> what maintaince does it need ?
> i mean i know the code is ugly but what _needs_ to be changed?
> 
> libpostproc implements part of ISO/IEC 14496-2
> (that is the spec for an MPEG-4 ASP decoder)
> 
> its content could be moved in libavfilter and or the mpeg4 decoder
> (there are arguments to be made for either)
> but it doesnt belong in a lib external to FFmpeg.
> (and in the process some bits probably can be droped as they
>  no longer serve a purpose compared to other filters)
> 
> I have too many other things to work on to do a big refactoring of it
> but if there are small bugs in it or questions about it i can look into them

The main problem I see with it is that it is a world unto itself. It
barely interacts with the rest of the project, its APIs use a different
style from everything else, etc.

What does anybody gain from it being in our source tree, as opposed to a
separate library?

-- 
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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Nicolas George]

Anton Khirnov (12023-09-29):
> What does anybody gain from it being in our source tree, as opposed to a
> separate library?

Not having to maintain yet another packaging and build system.

Not having an external dependency for something that could be considered
a core feature.

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Rémi Denis-Courmont]

Le 29 septembre 2023 14:43:11 GMT+03:00, Nicolas George <george@nsup.org> a écrit :
>Anton Khirnov (12023-09-29):
>> What does anybody gain from it being in our source tree, as opposed to a
>> separate library?
>
>Not having to maintain yet another packaging and build system.

Talk about flimsy "scraps of the bottom of the barrel" reasons.

Considering the accumulated cruft in the FFmpeg build system, this is more of a reason *not* to share source trees - rationalise the build system (or use an off-the-shelf one, whatever rocks your boat).

>Not having an external dependency for something that could be considered
>a core feature.

A core feature that depends on niche hardware, and is only supported on a narrow subset of target platforms. Oxymoronic much?

If those are your reasons, you'd have better kept them to yourself, because they're frankly ridiculous.

Normally you'd bundle things because they are tightly coupled. But if they were tightly coupled, then there would be maintenance costs, so that's also a self-defeating argument.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] SDR lib comments

[Nicolas George]

Rémi Denis-Courmont (12023-09-29):
> A core feature that depends on niche hardware

libpostproc does not depend on niche hardware. If the discussion bores
you to the point of not remembering what is being discussed, maybe just
dropping it and letting those who care spend their time.

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".