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
_______________________________________________
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".
