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

[Paul B Mahol]

On Fri, Jun 30, 2023 at 7:41 PM Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Fri, Jun 30, 2023 at 04:38:46PM +0200, Jean-Baptiste Kempf wrote:
> > On Fri, 30 Jun 2023, at 16:08, Michael Niedermayer wrote:
> > > Also as said previously, If there is at least a 2nd developer working
> > > on this then we could & should move this to a seperate libraray
> (libavradio)
> >
> > Why wait for a 2nd dev?
>
> It is significant work
> And if there is no 2nd developer interrested then for whom am i doing that
> work ?
>
> The sdr code as it is currently, is usefull to end users. (already as it is
> with the bugs it still has but as these get squished it will become more
> usefull)
> If its changed to a libavradio, the end user wont gain anything. Its
> developers who may gain, but if there is no 2nd developer interrested then
> well. I may be misunderstanding why iam being asked to do this work
>
> Does anyone want to use libavradio ?
> If yes, please volunteer to help create libavradio
> If no, please do not ask for someone else to create something you do not
> intend to use
>
> Also what is meant by a seperate libraray exactly by people is not clear
> to me
> I can create a libavradio similar to libavformat and libavdevice
> I fail to see the point of doing that but i can do that
> so the code keeps the same demuxer interface and is used the same way
> by players.
>
> If people want me to create something else, I have to point out that
> sofar noone explained what that would be. Or how that would interface
> into the rest of the ecosystem.
> I have no idea what use cases people have in mind, i have no idea
> what APIs people have in mind.
>
> I mean, if someone sees the demuxer and thinks
> darn i wanted to use this for X but i cannot because Y. And then goes on
> explaining
> X and Y and the suggestion for a seperate library, thats something to look
> into but
> I dont think we had these suggestions.
>

This is no different than blackmailing all people that objected to commit
current code, in patch as presented, to come around spending their time to
make libavradio.

What's next? Blackmailing people and demanding to receive honors or instead
will push devastating commit to repository.

Intention is clear, so I advise higher authority over current main/lead
FFmpeg maintainer to take action and remove commit rights from current
main/lead FFmpeg maintainer.
Because there is possibility to hurt project by committing large code that
was not approved by majority of reviewers.


>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you fake or manipulate statistics in a paper in physics you will never
> get a job again.
> If you fake or manipulate statistics in a paper in medicin you will get
> a job for life at the pharma industry.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>