[FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support

[Martin Storsjö]

On Sat, 1 Jul 2023, Michael Niedermayer wrote:

> On Sat, Jul 01, 2023 at 12:36:06AM +0300, Martin Storsjö wrote:
>> On Fri, 30 Jun 2023, Michael Niedermayer wrote:
>>
>>> On Thu, Jun 29, 2023 at 05:43:53PM +0200, Paul B Mahol wrote:
>>>> If you apply this I will apply my pending libswresample commits and also
>>>> remove sonic decoder from libavcodec.
>>>
>>> ok, if you plan to fix the bugs in the libswresample patches
>>>
>>> ill wait a bit, so others can object and if no objections will
>>> apply the current SDR patch with the probe function disabled.
>>> That ensures it will not be used without the user explicitly
>>> selecting it.
>>
>> I object to merging this patch.
>>
>> As numerous others have said already, this is at the wrong level of
>> abstraction, even if it happens to work for you for the current use case.
>>
>> Even if it is disabled by default, git master isn't a playground for
>> personal projects.
>
> If you belive this is implemented at the wrong level,
> can you please elaborately explain the implementation which is
> in your oppinion at the correct level ?

As there are talks about receiving DAB/DVB from the same source, those 
would definitely be on a different level than libavformat, since the 
output of them would be an mpegts stream (or multiple), or whatever 
transport format DAB uses. As for purely AM/FM, I'm not quire sure what 
the right level for that is though.

In any case, I disagree with the procedure of stating to push the patch if 
there's no objections, when there has been numerous objections from 
essentially most of the active community already.


As for what you asked in another thread, whether the objection is personal 
and not related to content - I wholeheartedly disagree. I would have 
expected the same response to a similar patchset from anybody else.

The amount of response only varies a bit depending on the position in the 
community of the person proposing the feature. A more senior community 
member has easier to push a feature forward than a less known community 
member. Thus, objections to such things also trigger more voices to show 
the widespread disagreement on the matter.

> > Even if it is disabled by default, git master isn't a playground for
> > personal projects.
> 
> This is in no way intended as a "personal project"

My point was that one can't use the argument of "let's merge it but keep 
it disabled for now, then you surely can't object to it", as a backdoor to 
merge disapproved things.

// Martin