[FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support

[Michael Niedermayer]

On Sun, Jun 25, 2023 at 12:19:04AM +0200, Nicolas George wrote:
> Michael Niedermayer (12023-06-23):
> > * What iam interrested in was working with the signals at a low level, why
> >   because i find it interresting and fun.
> 
> Then this is what you should be spending your time on, and to hell with
> anybody who says otherwise.
> 
> Unless you have commitments that we are not privy of, nobody can tell
> you how you are supposed to be spending your time and skills. Nobody can
> force you to manage releases and fix fuzzing bugs and do all the things
> you do that are necessary to the project. Necessary to a conception of
> the good of the project that is not even your own I think.
> 
> Nobody can prevent you from hacking the things that motivate you. At
> worst, they can prevent you from committing the resulting code into
> official FFmpeg. That would be the project's loss, and you can still
> publish it on a private branch. But they do not have the power to block
> you from pushing. It is not even clear they have the authority do block
> you, more so if the code is really good and fits FFmpeg well. The only
> thing that can block you is your desire to play nice and not harm the
> project. I would like to emphasize that some of the frequent naysayers
> do not have an excellent track record when it comes to playing nice and
> especially not harming the project.
> 
> I am especially annoyed by the “it's too hard” naysayers — the same I
> have been getting when I say that I want to write a XML suited to our
> needs to replace our use of libxml. They do not realize they reveal more
> about their own skills than anybody else. You know if you can write a
> radio, so ignore them and go ahead. And if they were right, if it is too
> hard and you fail… well, you would just have wasted your own time; and
> you would have had fun and learned things on the occasion, which means
> the time was not even wasted.

you are very spot on with all this.
anyway i will not push anything to master without the community agreeing,
that would do no good.


> 
> But the whole attitude who wants FFmpeg to be a Serious OpenSource TM
> Project, who needs to make releases and worry above all about ABI
> stability, is really the attitude who is killing all the fun in working
> on FFmpeg.
> 
> Hey, people, realize FFmpeg does not exist to be a Serious OpenSource TM
> Project, FFmpeg does not exist to serve other projects, to serve
> companies who benefit from it give the bare minimum back.
> 
> FFmpeg exists because some day a dude thought it would be fun to write a
> MPEG decoder. And everybody else told him it would be too hard,
> everybody else told him to use an existing library and to leave it to
> the professionals. He did not believe them and proved them utterly
> wrong, and the rest, as the saying goes, is history.

yes, also in the early days FFmpeg was inovative and pushing the boundaries
i mean i could have pushed a cpu emulator and compiler IF there was need for
that, noone would have had an issue with that.
But nowadays FFmpeg is established and theres tradition. Any breach of
that tradition leads to opposition.


> 
> So I will say it explicitly. We — me, and everybody who agrees with me —
> do not want to just maintain a bunch of wrappers for the convenience of
> others, we want to have fun writing interesting code, trying new ways of
> doing things, inventing original optimizations. We can find a balance
> and work on useful things too. But if you want us to work only on the
> boring useful things, if you want to bar us from working on fun things,
> then just fork you.

Well, first question really is if we can move forward in the established
system. It seems this is at least a bit cumbersome. But we will see
where it ends with that sdr feature.
It doesnt need to be in a demuxer (IF there was another way, it just seems
there is not), it can be in a seperate library (IF there is more than 1
developer interrested in working on it), theres
alot of things that can be adjusted to reach a consensus.

Then the question is if we have a consensus to push the sdr code in
whatever form that would be to git master. If not the code goes
elsewhere and that elsewhere should really then be open to everyone
else who wants to do inovative work.
I think every possible outcome here really has its upsides. Its just a
more cumbersome path than what i had envissioned


thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230625/d4e3b5fb/attachment.sig>