Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Rémi Denis-Courmont]

Le lauantaina 23. syyskuuta 2023, 9.49.47 EEST Neal Gompa a écrit :
> On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
> 
>  wrote:
> > > What does this mean? Does this mean an FFmpeg release containing code
> > > that
> > > interfaces with your SDR library? Or does it mean the library fully
> > > integrated into FFmpeg?
> > 
> > It depends on the code at the time of release. ATM there is no seperate
> > library, just a SDR input device.
> > creating a separte library and the related API/ABI needs to be done with
> > thought and care not something to rush quickly.
> 
> What does this code *do*? All these arguments about the SDR code, and
> I haven't seen it myself (because the email patch workflow really
> makes it hard to track this stuff down, and I assume it was submitted
> on list somewhere?)
> 
> If it's just taking SDR devices as inputs and allowing you to encode
> audio and video streams, I'm not sure why you *wouldn't* have this as
> something in libavdevice or extended from it as a separate library.

I'm pretty damn sure why: that's not how you normally deal with analog (or 
PCM) audio inputs and outputs. There *are* already a standard interfaces for 
the purpose: ALSA is the most common (others include JACK and Pipewire). It is 
already supported by FFmpeg - and hundreds of other open-source applications 
that would benefit from it too. (And yes, you *can* implement ALSA devices in 
userspace.)

There are simply no particular reasons why this should be tied to FFmpeg, and 
there are conversely no reasons to bloat the FFmpeg code with SDR code that 
will only be usable to one in a million with suitable radio equipment.

But really the main concern was the slippery slope argument: SDR code for FM 
may be small, but SDR code, say, DVB wouldn't be, and the line has to be drawn 
somewhere.

-- 
レミ・デニ-クールモン
http://www.remlab.net/



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

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Rémi Denis-Courmont]

Le torstaina 21. syyskuuta 2023, 21.56.52 EEST Michael Niedermayer a écrit :
> Hi
> 
> On Thu, Sep 21, 2023 at 05:33:54PM +0100, Kieran Kunhya via ffmpeg-devel 
wrote:
> > On Thu, Sep 21, 2023 at 5:21 PM Michael Niedermayer
> > 
> >  wrote:
> > > OTOH If a majority of people are against the SDR code at the time of
> > > branching 6.1. Then i will make a separate release identical to 6.1 with
> > > the SDR code and of course also provide security support
> > 
> > How on earth is it acceptable that you can publish your hobby project
> > under the FFmpeg project name?
> 
> How on earth is this defamation acceptable?

Michael, that is totally out of line. You pointed out that SDR was a new hobby 
project of yours. You do not get to complain that people throw your own words 
back at you (even if, hypothetically, you regret them).

> In fact iam not even sure what you talk about.
> FFmpeg is not a propriatery licensed project

Nobody said anything about FFmpeg or your SDR code being proprietary.

> It seems to me you are trying to rally your followers against me,

This is very demeaning to those people who are perfectly capable of thinking 
for ourselves and objected to the SDR code on similar technical grounds as 
Kieran's. And it is very highly hypocritical of you to accuse Kieran of 
politicking right after your allegations of defamation, since your words could 
very well be interpreted as defamation against him.

> If you have real arguments, you can state them without these attacks

Kieran, and others, have provided technical arguments a number of times in the 
past.

> > I have been working on BIOS code recently but I haven't decided to
> > create FFBIOS and put it in the main FFmpeg repo.
> 
> because doing so would make no sense, BIOS is unrelated to FFmpeg and
> multimedia

FFmpeg as a UEFI app or bare metal "BIOS" would be more related to multimedia 
than SDR is, relatively speaking, IMO.

(FWIW, UEFI has graphical output, HID, file systems and TCP/IP. You could very 
well run the FFmpeg on it.)

> But if you do, noone would attack you like you do, we would just
> have a normal discussion about why you think this makes sense, and
> i think you dont think that makes sense so we would agree that BIOS
> doesnt belong in FFmpeg
> 
> If OTOH you would create something related, you could name it
> FFmpeg- nothing wrong here, other people do it to, github has
> 26300 hits for FFmpeg

Like no? Other people do it is a very sorry excuse. If it doesn't relate to 
FFmpeg, it shouldn't be called FFmpeg.

It's not even just a question of morality and principles: Trademarks need to 
be defended afterall.

-- 
レミ・デニ-クールモン
http://www.remlab.net/



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

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

Paul B Mahol (12023-09-21):
> If this SDR troll code ever get committed in FFmpeg libraries I will
> immediately leave project.

That would be sad for the project. But I am sorry, I sincerely believe
that if you were to follow through with it, it would be a price worth
paying to have Michael working on code that gives him fun again.

Anyway, I suppose you have no difficulty seeing how this kind of
blackmail cannot be taken into consideration for the decision of the
future of the project.

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Kieran Kunhya]

On Sun, 24 Sept 2023, 18:34 Paul B Mahol,  wrote:

> On 9/24/23, Nicolas George  wrote:
> > Paul B Mahol (12023-09-24):
> >> libavdevice is abusing libavformat.
> >>
> >> It should have own API or be removed.
> >
> > libavdevice works.
>
> Define 'works'.
>
> It is clearly sub-optimal.
>

Why should a big feature like SDR be put into a point release?

Kieran

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

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Paul B Mahol]

On 9/24/23, Nicolas George  wrote:
> Paul B Mahol (12023-09-24):
>> libavdevice is abusing libavformat.
>>
>> It should have own API or be removed.
>
> libavdevice works.

Define 'works'.

It is clearly sub-optimal.
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

Paul B Mahol (12023-09-24):
> libavdevice is abusing libavformat.
> 
> It should have own API or be removed.

libavdevice works.

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Paul B Mahol]

On Sun, Sep 24, 2023 at 11:12 AM Nicolas George  wrote:

> Neal Gompa (12023-09-23):
> > If it's just taking SDR devices as inputs and allowing you to encode
> > audio and video streams, I'm not sure why you *wouldn't* have this as
> > something in libavdevice or extended from it as a separate library.
>
> The people who oppose Michael's SDR also have been trying to kill
> libavdevice for years. At least some of them.
>

libavdevice is abusing libavformat.

It should have own API or be removed.


>
> Regards,
>
> --
>   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-requ...@ffmpeg.org with subject "unsubscribe".
>
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

Neal Gompa (12023-09-23):
> If it's just taking SDR devices as inputs and allowing you to encode
> audio and video streams, I'm not sure why you *wouldn't* have this as
> something in libavdevice or extended from it as a separate library.

The people who oppose Michael's SDR also have been trying to kill
libavdevice for years. At least some of them.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Neal Gompa]

On Sat, Sep 23, 2023 at 6:55 AM Michael Niedermayer
 wrote:
>
> On Sat, Sep 23, 2023 at 02:49:47AM -0400, Neal Gompa wrote:
> > On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
> >  wrote:
> > >
> > > On Fri, Sep 22, 2023 at 03:55:57PM +0200, Gijs Peskens wrote:
> > > >
> > > > On 21-09-2023 18:21, Michael Niedermayer wrote:
> > > > > Hi all
> > > > >
> > > > > As the 6.1 release is upcoming and as it was previously stated by me 
> > > > > that sdr
> > > > > will be part of 6.1. Heres some update of what i intend to do about 
> > > > > that.
> > > > >
> > > > > People previously agreed to including a SDR input device in 
> > > > > libavdevice with
> > > > > SDR in a seperate library.
> > > > >
> > > > > If the community and the SDR code are happy with each other before 
> > > > > the release
> > > > > then SDR will simply be merged and be part of 6.1 like any other 
> > > > > feature.
> > > > >
> > > > > OTOH If a majority of people are against the SDR code at the time of
> > > > > branching 6.1. Then i will make a separate release identical to 6.1 
> > > > > with
> > > > > the SDR code and of course also provide security support
> > > > What does this mean? Does this mean an FFmpeg release containing code 
> > > > that
> > > > interfaces with your SDR library? Or does it mean the library fully
> > > > integrated into FFmpeg?
> > >
> > > It depends on the code at the time of release. ATM there is no seperate
> > > library, just a SDR input device.
> > > creating a separte library and the related API/ABI needs to be done with
> > > thought and care not something to rush quickly.
> > >
> >
> > What does this code *do*? All these arguments about the SDR code, and
> > I haven't seen it myself (because the email patch workflow really
> > makes it hard to track this stuff down, and I assume it was submitted
> > on list somewhere?)
> >
> > If it's just taking SDR devices as inputs and allowing you to encode
> > audio and video streams, I'm not sure why you *wouldn't* have this as
> > something in libavdevice or extended from it as a separate library.
>
> Yes thats correct
>
> Let me try to describe what it does in more detail. Ill keep the HW
> side very simplified here as it doesnt matter.
>
> The HW side:
> You start with an Antena (wire) connecting to a SDR dongle (which is
> basically a analog->digital converter capable to take a piece of
> radio spectrum and digitizing it) then generally a USB cable and
> then with some intermediate drivers follow our SDR code
> (The implementation of the HW is much more complex but that above
>  is what it does from a high level view)
>
> The libavdevice SDR code:
> The digital radio spectrum piece is then analyzed. AM and FM stations
> identified and demodulated into AVStreams. The user can ask for all or
> one station to be demodulated. Digital metadata (RDS) is demodulated too
> and put in AVStream.metadata
> Optionally, the radio spectrum can also be returned in the form of a video
> stream so one can see where radio stations are within the piece of the
> spectrum (like a spectrum analyzer). And the seek keys can be used to
> move between stations and to move the piece of the radio spectrum returned
> by the hardware (giving also the functionality of an old radio with next/prev
> station buttons)
>

So it's not *really* SDR in the sense that most people talk about it,
it's actually more about classical radio in software. That seems more
than reasonable to support in FFmpeg. If we were talking about some of
the crazy things people do with SDR, I would think that's
inappropriate. But being able to decode AM/FM/SiriusXM and listen to
it on a Linux machine is nice enough.

I suppose the logical extension would be to be able to integrate
support for handling analog and digital TV signals, eventually?

I can see the argument that it'd be better as a separate project, but
offhand I actually don't know of any that do this now...

I guess this would be called libavradio or something like that?





--
真実はいつも一つ！/ Always, there's only one truth!
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Michael Niedermayer]

On Sat, Sep 23, 2023 at 02:49:47AM -0400, Neal Gompa wrote:
> On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
>  wrote:
> >
> > On Fri, Sep 22, 2023 at 03:55:57PM +0200, Gijs Peskens wrote:
> > >
> > > On 21-09-2023 18:21, Michael Niedermayer wrote:
> > > > Hi all
> > > >
> > > > As the 6.1 release is upcoming and as it was previously stated by me 
> > > > that sdr
> > > > will be part of 6.1. Heres some update of what i intend to do about 
> > > > that.
> > > >
> > > > People previously agreed to including a SDR input device in libavdevice 
> > > > with
> > > > SDR in a seperate library.
> > > >
> > > > If the community and the SDR code are happy with each other before the 
> > > > release
> > > > then SDR will simply be merged and be part of 6.1 like any other 
> > > > feature.
> > > >
> > > > OTOH If a majority of people are against the SDR code at the time of
> > > > branching 6.1. Then i will make a separate release identical to 6.1 with
> > > > the SDR code and of course also provide security support
> > > What does this mean? Does this mean an FFmpeg release containing code that
> > > interfaces with your SDR library? Or does it mean the library fully
> > > integrated into FFmpeg?
> >
> > It depends on the code at the time of release. ATM there is no seperate
> > library, just a SDR input device.
> > creating a separte library and the related API/ABI needs to be done with
> > thought and care not something to rush quickly.
> >
> 
> What does this code *do*? All these arguments about the SDR code, and
> I haven't seen it myself (because the email patch workflow really
> makes it hard to track this stuff down, and I assume it was submitted
> on list somewhere?)
> 
> If it's just taking SDR devices as inputs and allowing you to encode
> audio and video streams, I'm not sure why you *wouldn't* have this as
> something in libavdevice or extended from it as a separate library.

Yes thats correct

Let me try to describe what it does in more detail. Ill keep the HW
side very simplified here as it doesnt matter.

The HW side:
You start with an Antena (wire) connecting to a SDR dongle (which is
basically a analog->digital converter capable to take a piece of
radio spectrum and digitizing it) then generally a USB cable and
then with some intermediate drivers follow our SDR code
(The implementation of the HW is much more complex but that above
 is what it does from a high level view)

The libavdevice SDR code:
The digital radio spectrum piece is then analyzed. AM and FM stations
identified and demodulated into AVStreams. The user can ask for all or
one station to be demodulated. Digital metadata (RDS) is demodulated too
and put in AVStream.metadata
Optionally, the radio spectrum can also be returned in the form of a video
stream so one can see where radio stations are within the piece of the
spectrum (like a spectrum analyzer). And the seek keys can be used to
move between stations and to move the piece of the radio spectrum returned
by the hardware (giving also the functionality of an old radio with next/prev
station buttons)

thx

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Neal Gompa]

On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
 wrote:
>
> On Fri, Sep 22, 2023 at 03:55:57PM +0200, Gijs Peskens wrote:
> >
> > On 21-09-2023 18:21, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > As the 6.1 release is upcoming and as it was previously stated by me that 
> > > sdr
> > > will be part of 6.1. Heres some update of what i intend to do about that.
> > >
> > > People previously agreed to including a SDR input device in libavdevice 
> > > with
> > > SDR in a seperate library.
> > >
> > > If the community and the SDR code are happy with each other before the 
> > > release
> > > then SDR will simply be merged and be part of 6.1 like any other feature.
> > >
> > > OTOH If a majority of people are against the SDR code at the time of
> > > branching 6.1. Then i will make a separate release identical to 6.1 with
> > > the SDR code and of course also provide security support
> > What does this mean? Does this mean an FFmpeg release containing code that
> > interfaces with your SDR library? Or does it mean the library fully
> > integrated into FFmpeg?
>
> It depends on the code at the time of release. ATM there is no seperate
> library, just a SDR input device.
> creating a separte library and the related API/ABI needs to be done with
> thought and care not something to rush quickly.
>

What does this code *do*? All these arguments about the SDR code, and
I haven't seen it myself (because the email patch workflow really
makes it hard to track this stuff down, and I assume it was submitted
on list somewhere?)

If it's just taking SDR devices as inputs and allowing you to encode
audio and video streams, I'm not sure why you *wouldn't* have this as
something in libavdevice or extended from it as a separate library.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Michael Niedermayer]

On Fri, Sep 22, 2023 at 03:55:57PM +0200, Gijs Peskens wrote:
> 
> On 21-09-2023 18:21, Michael Niedermayer wrote:
> > Hi all
> > 
> > As the 6.1 release is upcoming and as it was previously stated by me that 
> > sdr
> > will be part of 6.1. Heres some update of what i intend to do about that.
> > 
> > People previously agreed to including a SDR input device in libavdevice with
> > SDR in a seperate library.
> > 
> > If the community and the SDR code are happy with each other before the 
> > release
> > then SDR will simply be merged and be part of 6.1 like any other feature.
> > 
> > OTOH If a majority of people are against the SDR code at the time of
> > branching 6.1. Then i will make a separate release identical to 6.1 with
> > the SDR code and of course also provide security support
> What does this mean? Does this mean an FFmpeg release containing code that
> interfaces with your SDR library? Or does it mean the library fully
> integrated into FFmpeg?

It depends on the code at the time of release. ATM there is no seperate
library, just a SDR input device.
creating a separte library and the related API/ABI needs to be done with
thought and care not something to rush quickly.

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Gijs Peskens]

On 21-09-2023 18:21, Michael Niedermayer wrote:

Hi all

As the 6.1 release is upcoming and as it was previously stated by me that sdr
will be part of 6.1. Heres some update of what i intend to do about that.

People previously agreed to including a SDR input device in libavdevice with
SDR in a seperate library.

If the community and the SDR code are happy with each other before the release
then SDR will simply be merged and be part of 6.1 like any other feature.

OTOH If a majority of people are against the SDR code at the time of
branching 6.1. Then i will make a separate release identical to 6.1 with
the SDR code and of course also provide security support
What does this mean? Does this mean an FFmpeg release containing code 
that interfaces with your SDR library? Or does it mean the library fully 
integrated into FFmpeg?


Of course iam happy to change my plans if someone has a better suggestion!

What i intend to do with SDR next is AVExecutor support to improve processing
capacity with multiple threads and also to look into factoring the code so
SDR is more seperated, where this will lead to i do not know

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

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

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Paul B Mahol]

On Thu, Sep 21, 2023 at 9:37 PM Nicolas George  wrote:

> Vittorio Giovara (12023-09-21):
> > So this is an example of accusatory tone - discrediting the previous
> author
> > in order to make your arguments have more weight. It's a bad move and
> > easily spottable, you should argue with better elements at your disposal,
> > not by claiming that I don't package software or don't contribute to
> > libavfilter.
>
> You are misunderstanding my point completely, I am not accusing you of
> anything, I am merely using you as an example to show how your argument
> is flawed.
>
> I can take myself as an example instead, if you like it better:
>
> How much did *I* contribute to hardware acceleration? Zero!
>
> How much did *I* contribute to assembly optimization? Zero!
>
> How much do *I* intend to contribute to hardware acceleration? Zero!
>
> But now, however much I would like to, especially in libavfilter, I
> refrain from objecting to new features of hardware acceleration.
>
> Because I can make the difference between the things that benefit me and
> the things that are useful to many users and therefore good for the
> project.
>
> FFmpeg is made a of a lot of parts that are often very independent. That
> is on purpose: that way, if somebody is not interested in a part, they
> can just ignore it and let others work on it.
>
> And that is exactly what I am asking you to do:
>
> Just ignore SDR and let Michael work on it.
>
> SDR costs NOTHING except Michael's time, and Michael's time is his own
> to spend. For the rest of us, the grounds for objecting are the same
> NOTHING.
>

SDR API is not trivial and inclusion of it with all its features and
components is not trivial inside FFmpeg libraries.


>
> > opinion on this release still stands: either a release with everything
> or a
> > release without the contentious piece of code, but not both. It's
> confusing
> > to the end users, and shows lack of direction of the project.
>
> On this we agree, making a second release without the feature just some
> people object to it would be a waste of Michael's 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-requ...@ffmpeg.org with subject "unsubscribe".
>
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

Vittorio Giovara (12023-09-21):
> So this is an example of accusatory tone - discrediting the previous author
> in order to make your arguments have more weight. It's a bad move and
> easily spottable, you should argue with better elements at your disposal,
> not by claiming that I don't package software or don't contribute to
> libavfilter.

You are misunderstanding my point completely, I am not accusing you of
anything, I am merely using you as an example to show how your argument
is flawed.

I can take myself as an example instead, if you like it better:

How much did *I* contribute to hardware acceleration? Zero!

How much did *I* contribute to assembly optimization? Zero!

How much do *I* intend to contribute to hardware acceleration? Zero!

But now, however much I would like to, especially in libavfilter, I
refrain from objecting to new features of hardware acceleration.

Because I can make the difference between the things that benefit me and
the things that are useful to many users and therefore good for the
project.

FFmpeg is made a of a lot of parts that are often very independent. That
is on purpose: that way, if somebody is not interested in a part, they
can just ignore it and let others work on it.

And that is exactly what I am asking you to do:

Just ignore SDR and let Michael work on it.

SDR costs NOTHING except Michael's time, and Michael's time is his own
to spend. For the rest of us, the grounds for objecting are the same
NOTHING.

> opinion on this release still stands: either a release with everything or a
> release without the contentious piece of code, but not both. It's confusing
> to the end users, and shows lack of direction of the project.

On this we agree, making a second release without the feature just some
people object to it would be a waste of Michael's 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-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Vittorio Giovara]

On Thu, Sep 21, 2023 at 3:05 PM Nicolas George  wrote:

> Vittorio Giovara (12023-09-21):
> > What about other developers' time for maintenance?
>
> Yes, what about it?
>
> How much time did YOU spend maintaining libavfilter or libavdevice?
> Zero.
>
> How much time will you spend maintaining SDR? Zero.
>
> What does it change for you and everybody who thinks like you? NOTHING.
>
> Michael wants to invest his time in a features that integrates
> beautifully in FFmpeg and that some users are glad to expect. That is a
> good thing.
>
> People who are not interested in it but have no practical arguments
> against it have absolutely no right to oppose or put so much roadblock
> it becomes discouraging just because they would like it better if
> Michael spent his time on things that they find useful rather than
> things that he finds fun.
>
> > And for users installing a library nowadays is a one liner, not really a
> > big deal
>
> Only if it is packaged by a distribution. I am guessing you are not
> volunteering to package it yourself, so you are again proposing to waste
> somebody else's time.
>

So this is an example of accusatory tone - discrediting the previous author
in order to make your arguments have more weight. It's a bad move and
easily spottable, you should argue with better elements at your disposal,
not by claiming that I don't package software or don't contribute to
libavfilter. Really, have you thought how many contributors have we lost
only because of the tone (and length) of your emails? You said you stopped
contributing patches because you don't like the development environment,
but maybe you should consider stopping sending emails too, just as a
friendly advice.

I will stop replying to any further baseless accusation, and going back on
topic, regardless who wrote what or how many users are requesting it, my
opinion on this release still stands: either a release with everything or a
release without the contentious piece of code, but not both. It's confusing
to the end users, and shows lack of direction of the project. End of
transmission.
-- 
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-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Paul B Mahol]

On Thu, Sep 21, 2023 at 9:05 PM Nicolas George  wrote:

> Vittorio Giovara (12023-09-21):
> > What about other developers' time for maintenance?
>
> Yes, what about it?
>
> How much time did YOU spend maintaining libavfilter or libavdevice?
> Zero.
>
> How much time will you spend maintaining SDR? Zero.
>
> What does it change for you and everybody who thinks like you? NOTHING.
>
> Michael wants to invest his time in a features that integrates
> beautifully in FFmpeg and that some users are glad to expect. That is a
> good thing.
>
> People who are not interested in it but have no practical arguments
> against it have absolutely no right to oppose or put so much roadblock
> it becomes discouraging just because they would like it better if
> Michael spent his time on things that they find useful rather than
> things that he finds fun.
>
> > And for users installing a library nowadays is a one liner, not really a
> > big deal
>
> Only if it is packaged by a distribution. I am guessing you are not
> volunteering to package it yourself, so you are again proposing to waste
> somebody else's time.
>

If this SDR troll code ever get committed in FFmpeg libraries I will
immediately leave project.


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

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

Vittorio Giovara (12023-09-21):
> What about other developers' time for maintenance?

Yes, what about it?

How much time did YOU spend maintaining libavfilter or libavdevice?
Zero.

How much time will you spend maintaining SDR? Zero.

What does it change for you and everybody who thinks like you? NOTHING.

Michael wants to invest his time in a features that integrates
beautifully in FFmpeg and that some users are glad to expect. That is a
good thing.

People who are not interested in it but have no practical arguments
against it have absolutely no right to oppose or put so much roadblock
it becomes discouraging just because they would like it better if
Michael spent his time on things that they find useful rather than
things that he finds fun.

> And for users installing a library nowadays is a one liner, not really a
> big deal

Only if it is packaged by a distribution. I am guessing you are not
volunteering to package it yourself, so you are again proposing to waste
somebody else's 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-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Michael Niedermayer]

Hi

On Thu, Sep 21, 2023 at 05:33:54PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> On Thu, Sep 21, 2023 at 5:21 PM Michael Niedermayer
>  wrote:
> > OTOH If a majority of people are against the SDR code at the time of
> > branching 6.1. Then i will make a separate release identical to 6.1 with
> > the SDR code and of course also provide security support
> 
> How on earth is it acceptable that you can publish your hobby project
> under the FFmpeg project name?

How on earth is this defamation acceptable?
In fact iam not even sure what you talk about.
FFmpeg is not a propriatery licensed project

It seems to me you are trying to rally your followers against me, with
these attacks, thats really lame IMHO
If you have real arguments, you can state them without these attacks


> You are of course welcome to publish SDR in a different project that
> is not FFmpeg.

> 
> I have been working on BIOS code recently but I haven't decided to
> create FFBIOS and put it in the main FFmpeg repo.

because doing so would make no sense, BIOS is unrelated to FFmpeg and
multimedia
But if you do, noone would attack you like you do, we would just
have a normal discussion about why you think this makes sense, and
i think you dont think that makes sense so we would agree that BIOS
doesnt belong in FFmpeg

If OTOH you would create something related, you could name it FFmpeg-
nothing wrong here, other people do it to, github has 26300 hits for FFmpeg

If its something that has users, maintained, ... but is not accepted in
main FFmpeg. Sure we can list it on our download page too.

thx

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Vittorio Giovara]

On Thu, Sep 21, 2023 at 2:51 PM Nicolas George  wrote:

> Vittorio Giovara (12023-09-21):
> > Good, if it's so isolated it can be moved to a separate library and we're
> > arguing over nothing.
>
> Wasting Michael's time for the maintenance and users' time for
> installing it in the process. That is a completely stupid idea.
>

What about other developers' time for maintenance?
And for users installing a library nowadays is a one liner, not really a
big deal


> > Will you stop with this accusatory tone in _every_ _single_ _email_ you
> > send?
> > Meeting a threshold of emails is not a good measure of the validity of
> any
> > claim.
>
> What?
>

What?

> Yes, and it agrees with its removal.
>
> Not if you count correctly.
>

As someone wiser than me said, People can come up with statistics to prove
anything

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

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

Vittorio Giovara (12023-09-21):
> Good, if it's so isolated it can be moved to a separate library and we're
> arguing over nothing.

Wasting Michael's time for the maintenance and users' time for
installing it in the process. That is a completely stupid idea.

> Will you stop with this accusatory tone in _every_ _single_ _email_ you
> send?
> Meeting a threshold of emails is not a good measure of the validity of any
> claim.

What?

> Yes, and it agrees with its removal.

Not if you count correctly.

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

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Vittorio Giovara]

On Thu, Sep 21, 2023 at 2:19 PM Nicolas George  wrote:

> Vittorio Giovara (12023-09-21):
> > Because it adds maintenance burden and it's out of scope with the proejct
>
> The feature is isolated, so that is a lie.
>

Good, if it's so isolated it can be moved to a separate library and we're
arguing over nothing.


> > No thanks, feature creep is a bad mojo.
>
> “Creep” is your opinion, the opinion of somebody who we never see on
> users mailing lists by the way.
>

Will you stop with this accusatory tone in _every_ _single_ _email_ you
send?
Meeting a threshold of emails is not a good measure of the validity of any
claim.


> > At any rate for the topic at hand, in my opinion there shouldn't be two
> > separate releases, either there is one with SDR or there is one without,
> > not both.
> > I actually thought the majority of the developer community was against
> > including this feature and I thought it was already removed.
>
> There is a clear majority of the developer community who do the work.
>

Yes, and it agrees with its removal.
-- 
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-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

Vittorio Giovara (12023-09-21):
> Because it adds maintenance burden and it's out of scope with the proejct

The feature is isolated, so that is a lie.

> No thanks, feature creep is a bad mojo.

“Creep” is your opinion, the opinion of somebody who we never see on
users mailing lists by the way.

> At any rate for the topic at hand, in my opinion there shouldn't be two
> separate releases, either there is one with SDR or there is one without,
> not both.
> I actually thought the majority of the developer community was against
> including this feature and I thought it was already removed.

There is a clear majority of the developer community who do the work.

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Vittorio Giovara]

On Thu, Sep 21, 2023 at 1:16 PM Nicolas George  wrote:

> Kieran Kunhya via ffmpeg-devel (12023-09-21):
> > How on earth is it acceptable that you can publish your hobby project
> > under the FFmpeg project name?
>
> How on earth is it acceptable that you continue bikeshedding a feature
> that some users have been enthusiastically waiting for?
>

Because it adds maintenance burden and it's out of scope with the proejct


> > I have been working on BIOS code recently
>
> If it brings useful features in a way that integrate gracefully in
> FFmpeg, then great! Send the patches then.


No thanks, feature creep is a bad mojo.


At any rate for the topic at hand, in my opinion there shouldn't be two
separate releases, either there is one with SDR or there is one without,
not both.
I actually thought the majority of the developer community was against
including this feature and I thought it was already removed.
-- 
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-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

Kieran Kunhya via ffmpeg-devel (12023-09-21):
> How on earth is it acceptable that you can publish your hobby project
> under the FFmpeg project name?

How on earth is it acceptable that you continue bikeshedding a feature
that some users have been enthusiastically waiting for?

> I have been working on BIOS code recently

If it brings useful features in a way that integrate gracefully in
FFmpeg, then great! Send the patches then. 

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Paul B Mahol]

On Thu, Sep 21, 2023 at 6:21 PM Michael Niedermayer 
wrote:

> Hi all
>
> As the 6.1 release is upcoming and as it was previously stated by me that
> sdr
> will be part of 6.1. Heres some update of what i intend to do about that.
>

Very bold claim.


>
> People previously agreed to including a SDR input device in libavdevice
> with
> SDR in a seperate library.
>
> If the community and the SDR code are happy with each other before the
> release
> then SDR will simply be merged and be part of 6.1 like any other feature.
>
> OTOH If a majority of people are against the SDR code at the time of
> branching 6.1. Then i will make a separate release identical to 6.1 with
> the SDR code and of course also provide security support
>

Very bold claim, there should be real voting otherwise its just your word
against mine.


>
> Of course iam happy to change my plans if someone has a better suggestion!
>

I can't and do not want to force you to work on something else. Its your
motivation and decision.


>
> What i intend to do with SDR next is AVExecutor support to improve
> processing
> capacity with multiple threads and also to look into factoring the code so
> SDR is more seperated, where this will lead to i do not know
>

Working on SDR inside FFmpeg or part of FFmpeg is wasting resources on
technology that is basically already solved problem,


>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
> ___
> 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".
>
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Kieran Kunhya via ffmpeg-devel]

On Thu, Sep 21, 2023 at 5:21 PM Michael Niedermayer
 wrote:
> OTOH If a majority of people are against the SDR code at the time of
> branching 6.1. Then i will make a separate release identical to 6.1 with
> the SDR code and of course also provide security support

How on earth is it acceptable that you can publish your hobby project
under the FFmpeg project name?
You are of course welcome to publish SDR in a different project that
is not FFmpeg.

I have been working on BIOS code recently but I haven't decided to
create FFBIOS and put it in the main FFmpeg repo.

Regards,
Kieran Kunhya
___
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".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Michael Niedermayer]

Hi all

As the 6.1 release is upcoming and as it was previously stated by me that sdr
will be part of 6.1. Heres some update of what i intend to do about that.

People previously agreed to including a SDR input device in libavdevice with
SDR in a seperate library.

If the community and the SDR code are happy with each other before the release
then SDR will simply be merged and be part of 6.1 like any other feature.

OTOH If a majority of people are against the SDR code at the time of
branching 6.1. Then i will make a separate release identical to 6.1 with
the SDR code and of course also provide security support

Of course iam happy to change my plans if someone has a better suggestion!

What i intend to do with SDR next is AVExecutor support to improve processing
capacity with multiple threads and also to look into factoring the code so
SDR is more seperated, where this will lead to i do not know

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


signature.asc
Description: PGP signature
___
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".