diff mbox series

[FFmpeg-devel,5/6] fftools: avradio support

Message ID 20230722192957.703-5-michael@niedermayer.cc
State New
Headers show
Series [FFmpeg-devel,1/6] configure: libavradio support | expand

Checks

Context Check Description
yinshiyou/make_loongarch64 success Make finished
yinshiyou/make_fate_loongarch64 success Make fate finished
andriy/make_x86 success Make finished
andriy/make_fate_x86 success Make fate finished

Commit Message

Michael Niedermayer July 22, 2023, 7:29 p.m. UTC
This avoids keeping diffs to fftools in the libavradio repository
---
 fftools/ffmpeg.c     |  7 +++++
 fftools/ffplay.c     |  6 ++++
 fftools/ffprobe.c    |  6 ++++
 fftools/opt_common.c | 66 ++++++++++++++++++++++++++++++++++++++++----
 fftools/opt_common.h | 27 ++++++++++++++++++
 5 files changed, 107 insertions(+), 5 deletions(-)

Comments

Lynne July 22, 2023, 9:39 p.m. UTC | #1
Jul 22, 2023, 21:30 by michael@niedermayer.cc:

> This avoids keeping diffs to fftools in the libavradio repository
> ---
>  fftools/ffmpeg.c     |  7 +++++
>  fftools/ffplay.c     |  6 ++++
>  fftools/ffprobe.c    |  6 ++++
>  fftools/opt_common.c | 66 ++++++++++++++++++++++++++++++++++++++++----
>  fftools/opt_common.h | 27 ++++++++++++++++++
>  5 files changed, 107 insertions(+), 5 deletions(-)
>

Do you think we should keep this out of the 6.1 branch?
I don't expect packagers to start packaging libavradio immediately,
so I don't feel that strongly about it, but maybe we should let
users test it first in git master for a bit?
Michael Niedermayer July 23, 2023, 3:23 p.m. UTC | #2
On Sat, Jul 22, 2023 at 11:39:11PM +0200, Lynne wrote:
> Jul 22, 2023, 21:30 by michael@niedermayer.cc:
> 
> > This avoids keeping diffs to fftools in the libavradio repository
> > ---
> >  fftools/ffmpeg.c     |  7 +++++
> >  fftools/ffplay.c     |  6 ++++
> >  fftools/ffprobe.c    |  6 ++++
> >  fftools/opt_common.c | 66 ++++++++++++++++++++++++++++++++++++++++----
> >  fftools/opt_common.h | 27 ++++++++++++++++++
> >  5 files changed, 107 insertions(+), 5 deletions(-)
> >
> 
> Do you think we should keep this out of the 6.1 branch?
> I don't expect packagers to start packaging libavradio immediately,
> so I don't feel that strongly about it, but maybe we should let
> users test it first in git master for a bit?

there are unfortunately a few issues the fuzzers found in ffmpeg, which i
need to fix and these need to go in 6.1 so the small bits of code should
have plenty of time to be tested.

about packagers and libavradio. The (more vocal members of the) community
wanted sdr in a seperate library and not libavdevice, its likely that
distributions will eventually package it, wherever it is.
To me it really doesnt matter if its in libavradio or libavdevice.
whatever people prefer

PS: The most efficient way to make the code be structured the way people
like it is to work together on it and contribute. Iam mentioning this because
IRC gives off some hostile vibes ATM, and this reminds me of the distant past
Working together -> makes everyone happy.
Fighting other peoples work -> results in fragmenting the community

thx

[...]
Tomas Härdin July 23, 2023, 6:49 p.m. UTC | #3
sön 2023-07-23 klockan 17:23 +0200 skrev Michael Niedermayer:
> On Sat, Jul 22, 2023 at 11:39:11PM +0200, Lynne wrote:
> > Jul 22, 2023, 21:30 by michael@niedermayer.cc:
> > 
> > > This avoids keeping diffs to fftools in the libavradio repository

No to this entire patchset.

> > > ---
> > >  fftools/ffmpeg.c     |  7 +++++
> > >  fftools/ffplay.c     |  6 ++++
> > >  fftools/ffprobe.c    |  6 ++++
> > >  fftools/opt_common.c | 66
> > > ++++++++++++++++++++++++++++++++++++++++----
> > >  fftools/opt_common.h | 27 ++++++++++++++++++
> > >  5 files changed, 107 insertions(+), 5 deletions(-)
> > > 
> > 
> > Do you think we should keep this out of the 6.1 branch?
> > I don't expect packagers to start packaging libavradio immediately,
> > so I don't feel that strongly about it, but maybe we should let
> > users test it first in git master for a bit?

Users can test libavradio's master if they wish. Do not assume merging
this fork will happen, especially not without TC approval, nor that
trying to sneak it in won't be noticed and opposed.

This patchset makes an even stronger case why this fork should have its
own mailing list and not pretend it's part of the main project.


> about packagers and libavradio. The (more vocal members of the)
> community
> wanted sdr in a seperate library and not libavdevice, its likely that
> distributions will eventually package it, wherever it is.

Why would they package it when there already are mature programs like
gqrx, dablin etc? Programs that feature separation of concerns. See for
example hacktv which uses ffmpeg, libhackrf and libsoapysdr without
insisting on being part of either

Another problem is that this would almost certainly cause headaches for
packagers. I know this because it's going to cause headaches for this
project to care about maintaining compatibility with a fork that
doesn't want to pretend it's a fork.


> PS: The most efficient way to make the code be structured the way
> people
> like it is to work together on it and contribute. Iam mentioning this
> because
> IRC gives off some hostile vibes ATM, and this reminds me of the
> distant past
> Working together -> makes everyone happy.
> Fighting other peoples work -> results in fragmenting the community

I would suggest not completely ignoring people like me who a) have
domain knowledge and b) are opposed to this on feature creep or other
grounds

/Tomas
James Almer July 23, 2023, 7:01 p.m. UTC | #4
On 7/23/2023 3:49 PM, Tomas Härdin wrote:
> sön 2023-07-23 klockan 17:23 +0200 skrev Michael Niedermayer:
>> On Sat, Jul 22, 2023 at 11:39:11PM +0200, Lynne wrote:
>>> Jul 22, 2023, 21:30 by michael@niedermayer.cc:
>>>
>>>> This avoids keeping diffs to fftools in the libavradio repository
> 
> No to this entire patchset.
> 
>>>> ---
>>>>   fftools/ffmpeg.c     |  7 +++++
>>>>   fftools/ffplay.c     |  6 ++++
>>>>   fftools/ffprobe.c    |  6 ++++
>>>>   fftools/opt_common.c | 66
>>>> ++++++++++++++++++++++++++++++++++++++++----
>>>>   fftools/opt_common.h | 27 ++++++++++++++++++
>>>>   5 files changed, 107 insertions(+), 5 deletions(-)
>>>>
>>>
>>> Do you think we should keep this out of the 6.1 branch?
>>> I don't expect packagers to start packaging libavradio immediately,
>>> so I don't feel that strongly about it, but maybe we should let
>>> users test it first in git master for a bit?
> 
> Users can test libavradio's master if they wish. Do not assume merging
> this fork will happen, especially not without TC approval, nor that
> trying to sneak it in won't be noticed and opposed.
> 
> This patchset makes an even stronger case why this fork should have its
> own mailing list and not pretend it's part of the main project.
> 
> 
>> about packagers and libavradio. The (more vocal members of the)
>> community
>> wanted sdr in a seperate library and not libavdevice, its likely that
>> distributions will eventually package it, wherever it is.
> 
> Why would they package it when there already are mature programs like
> gqrx, dablin etc? Programs that feature separation of concerns. See for
> example hacktv which uses ffmpeg, libhackrf and libsoapysdr without
> insisting on being part of either
> 
> Another problem is that this would almost certainly cause headaches for
> packagers. I know this because it's going to cause headaches for this
> project to care about maintaining compatibility with a fork that
> doesn't want to pretend it's a fork.

What bothers me is that even though it's added outside of lavd, it's 
being added as a brand new lavd, with all the drawbacks this implies, 
including it being tied to lavf in an awful way. And all for a single 
"device" AVInputFormat. It's completely overkill.

Why is this libavradio not designed as a standalone library, with its 
own, carefully designed API for general radio usage, that can be then 
glued to lavd as an AVInputFormat relying on said external library? 
Doing that would also make it usable in other projects that don't want 
to use the lavf/lavd API.
A standalone library can link to lavu for any utils it may need. A lavd 
device using it wouldn't be the first module using an external library 
that generates a circular dependency with other lav* libraries.

> 
> 
>> PS: The most efficient way to make the code be structured the way
>> people
>> like it is to work together on it and contribute. Iam mentioning this
>> because
>> IRC gives off some hostile vibes ATM, and this reminds me of the
>> distant past
>> Working together -> makes everyone happy.
>> Fighting other peoples work -> results in fragmenting the community
> 
> I would suggest not completely ignoring people like me who a) have
> domain knowledge and b) are opposed to this on feature creep or other
> grounds
> 
> /Tomas
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Michael Niedermayer July 23, 2023, 10:56 p.m. UTC | #5
On Sun, Jul 23, 2023 at 04:01:16PM -0300, James Almer wrote:
> On 7/23/2023 3:49 PM, Tomas Härdin wrote:
> > sön 2023-07-23 klockan 17:23 +0200 skrev Michael Niedermayer:
> > > On Sat, Jul 22, 2023 at 11:39:11PM +0200, Lynne wrote:
> > > > Jul 22, 2023, 21:30 by michael@niedermayer.cc:
> > > > 
> > > > > This avoids keeping diffs to fftools in the libavradio repository
> > 
> > No to this entire patchset.
> > 
> > > > > ---
> > > > >   fftools/ffmpeg.c     |  7 +++++
> > > > >   fftools/ffplay.c     |  6 ++++
> > > > >   fftools/ffprobe.c    |  6 ++++
> > > > >   fftools/opt_common.c | 66
> > > > > ++++++++++++++++++++++++++++++++++++++++----
> > > > >   fftools/opt_common.h | 27 ++++++++++++++++++
> > > > >   5 files changed, 107 insertions(+), 5 deletions(-)
> > > > > 
> > > > 
> > > > Do you think we should keep this out of the 6.1 branch?
> > > > I don't expect packagers to start packaging libavradio immediately,
> > > > so I don't feel that strongly about it, but maybe we should let
> > > > users test it first in git master for a bit?
> > 
> > Users can test libavradio's master if they wish. Do not assume merging
> > this fork will happen, especially not without TC approval, nor that
> > trying to sneak it in won't be noticed and opposed.
> > 
> > This patchset makes an even stronger case why this fork should have its
> > own mailing list and not pretend it's part of the main project.
> > 
> > 
> > > about packagers and libavradio. The (more vocal members of the)
> > > community
> > > wanted sdr in a seperate library and not libavdevice, its likely that
> > > distributions will eventually package it, wherever it is.
> > 
> > Why would they package it when there already are mature programs like
> > gqrx, dablin etc? Programs that feature separation of concerns. See for
> > example hacktv which uses ffmpeg, libhackrf and libsoapysdr without
> > insisting on being part of either
> > 
> > Another problem is that this would almost certainly cause headaches for
> > packagers. I know this because it's going to cause headaches for this
> > project to care about maintaining compatibility with a fork that
> > doesn't want to pretend it's a fork.
> 
> What bothers me is that even though it's added outside of lavd, it's being
> added as a brand new lavd, with all the drawbacks this implies, including it
> being tied to lavf in an awful way. And all for a single "device"
> AVInputFormat. It's completely overkill.

Its outside because people asked for it to be outside.
I thought its bad but its fine really if you look a bit forward


> 
> Why is this libavradio not designed as a standalone library, with its own,
> carefully designed API for general radio usage, that can be then glued to
> lavd as an AVInputFormat relying on said external library? Doing that would
> also make it usable in other projects that don't want to use the lavf/lavd
> API.

Because 2 things matter.
1. the final result
2. how to get there efficiently

The first step is a demuxer/input device. Whereever it is. (thats what we have now)
DAB & DVB can be added too or could be added later

No new API is here, so no API can be misdesigned and no API can require
to be replaced. Theres also no API we will need to deprecate
If we do API first we will have to redo and deprecate it 100% certainly.
We have had to frequently redo APIs and that was with things
we understood much better. So if we do an SDR API now, probably we would have to
redo it more than once, more so if some of the community boycotts
the design or implementation process

The second step is users, improvments, bugfixes, figure out what people use/want/need

AFTER this. We are in a position to design the API without being certain that
we have to redo it immedeatly

And here comes the 3rd step, connect libavfilter to libavradio, move the components
into libavfilter. Do demodulation and probing in filters.
filters will not need to deal with mpeg-ts or AAC because they would be
used by libavradio and return mpeg-ts / AAC to its "caller"

And then the 4th step (which can be switched with teh 3rd)
Make all the parts available though a new API. At that time we will have a
much better understanding of what there is inside libavradio (because its
actually implemented) and also what developers want from a libavradio API
Here we are in a much better position to actually design a good API.
Also at this point many parts can be already used through libavfilter,
you need a stereo FM demodulator? there would be a avfilter for that probably.

There are other pathes forward but thats the current plan _IF_ this isnt killed off
by the community and _IF_ others join and enjoy working on this. Also nothing is
cast in stone, this plan is intended to be adapted as needed on the way.

I originally just intended to do AM&FM demodulation, and this has become a
much bigger project. We already have RDS & metadata support for example
But fact is, libavradio exists now. Now the question is will people join
and make more out of it or kill it off. Ultimately I cannot do this alone
especially not if 90% of replies tell me to fuck off. Theres a point where
i will move on and switch the bulk of my time to "not FFmpeg" and just do
payed work here.

Again, i understand that radio needs an API beyond libavdevices, and i agree
but IMO this comes after we have feedback from users what they need&want.
And that requires users which requires it to be in a release.

thx


> A standalone library can link to lavu for any utils it may need. A lavd
> device using it wouldn't be the first module using an external library that
> generates a circular dependency with other lav* libraries.


[...]
Nicolas George July 24, 2023, 8:13 a.m. UTC | #6
Tomas Härdin (12023-07-23):
> No to this entire patchset.

404 argument not found.

> Users can test libavradio's master if they wish. Do not assume merging
> this fork will happen, especially not without TC approval, nor that
> trying to sneak it in won't be noticed and opposed.

A striving Libre Software project works by compromise. I see no intent
of compromise at all in your position.

> Why would they package it when there already are mature programs like
> gqrx, dablin etc? Programs that feature separation of concerns. See for
> example hacktv which uses ffmpeg, libhackrf and libsoapysdr without
> insisting on being part of either

Oh, yes.

And these idiots working on the Linux kernel, why do they waste their
time when Windows and MacOS are excellent for everybody?

And the Vim team, do they not know that LibreOffice can do everything
better?

Why bother maintaining i3 and Fvwm when Gnome is so much better?

Why develop Perl modules? Python for everybody!

Seriously, if you have to ask, you are at the wrong place.

>	     I know this because it's going to cause headaches for this
> project to care about maintaining compatibility with a fork that
> doesn't want to pretend it's a fork.

This is very dishonest. Maintaining a fork only causes headaches to the
people who do it, and you have made amply clear that would not be you.

In fact, quite the opposite, you were one the loudest demanding that one
of our most talented hacker waste his time on maintaining a separate
build system instead of doing creative and useful work.

I say: let us merge this fork that should never have been separate, for
the convenience of Michael and of potential users.

Then let us reaffirm that FFmpeg is a place for hackers to be creative
in the general field of multimedia, the place to foster new ideas, new
solutions, new ways of writing efficient code, rather than a wrapper
around other libraries and obsolescent native code for the convenience
of other projects and commercial companies.
Nicolas George July 24, 2023, 8:19 a.m. UTC | #7
Michael Niedermayer (12023-07-24):
> There are other pathes forward but thats the current plan _IF_ this
> isnt killed off by the community and _IF_ others join and enjoy
> working on this. Also nothing is cast in stone, this plan is intended
> to be adapted as needed on the way.

I would love to play with this, but apart from the lack of time, I
suspect using these patches requires some hardware I do not have. Can
you tell a little about it?

Also, is it only for receiving? It is there, at least as a potential,
the possibility of sending, maybe in the Citizen Band?

>							Theres a point where
> i will move on and switch the bulk of my time to "not FFmpeg" and just do
> payed work here.

That would be very sad — but having myself set all FFmpeg development on
back-burner until the project becomes welcoming again, I fully
understand the feeling.

I hope before coming to that you will consider taking part in an effort
to take back the project from the bean counters.

Regards,
Michael Niedermayer July 24, 2023, 3:57 p.m. UTC | #8
Hi


On Mon, Jul 24, 2023 at 10:19:08AM +0200, Nicolas George wrote:
> Michael Niedermayer (12023-07-24):
> > There are other pathes forward but thats the current plan _IF_ this
> > isnt killed off by the community and _IF_ others join and enjoy
> > working on this. Also nothing is cast in stone, this plan is intended
> > to be adapted as needed on the way.
> 
> I would love to play with this, but apart from the lack of time, I
> suspect using these patches requires some hardware I do not have. Can
> you tell a little about it?

sure, you can test it without hw, for example this:
https://samples.ffmpeg.org/sdr/klassik.sdr.bz2
bunzip
and
./ffplay klassik.sdr -rtlsdr_fixes 1 -video_size 1024x400

should play the sample

with hw, the cheapest i know of are the RTL-SDR DONGLES, you can get these
with an atenna and free shipping for less than 45$.
official page is this: (there are links to places to buy and pictures of
genuine and clones)
https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/
(theres also a list of "RECOMMENDED ALTERNATIVE SDRS" at the bottom of that page)

I also have a sdrplay rsp1a but this requires closed source drivers and
for me required to mess with build options in libsoapy interface to it
(disabling isochronous mode which didnt work reliably with my notebook)

Once you have the hw and libsoapy, antenna (or random wire) you can try
it with some random established software like cubicSDR, SDR++, sdrangel
or anything tomas mentioned.
or just the libavradio repository (ATM i do recommand to also apply all
pending patches to it as these often include bugfixes)
then a simple
./ffplay -sdr_freq 89M -f sdr x -video_size 1024x300

should open a vissualization of the radio spectrum at 89Mhz with any detected
vissible radio stations with their metadata and frequencies displayed
left and right arrow keys should allow moving to the next and previous
stations.

-dumpurl somefile.sdr
allows dumping the vissible radio spectrum to a file (big) and replaying
it later (this is very usefull for testing and debuging)

another important option is -gain
because if gain is too low theres nothing and if its too high all kinds of
cliping overflow and artifacts will cause problems.
there are 2 automatic gain control modes (one from hw and one in sw) and
you can just set the gain by hand.

ATM our code is able to detect some kinds of artifacts and seperate them
from real radio stations by the way they move in relation to the choosen
frequency.
Also the antenna should ideally be far away from any interference causing
electronics.



> 
> Also, is it only for receiving? It is there, at least as a potential,
> the possibility of sending, maybe in the Citizen Band?

ATM its receiving only. hw like the rtl-sdr or sdrplay rsp1a only support
receiving. There are SDRs that support transmitting though

transmitting support would be cool but thats for others to add.
Preferably someone who lives in a country with liberal laws about it and
who has already experience and all needed technical and legal things in place.

thx

[...]
Tomas Härdin July 24, 2023, 8:19 p.m. UTC | #9
sön 2023-07-23 klockan 16:01 -0300 skrev James Almer:
> What bothers me is that even though it's added outside of lavd, it's 
> being added as a brand new lavd, with all the drawbacks this implies,
> including it being tied to lavf in an awful way. And all for a single
> "device" AVInputFormat. It's completely overkill.
> 
> Why is this libavradio not designed as a standalone library, with its
> own, carefully designed API for general radio usage, that can be then
> glued to lavd as an AVInputFormat relying on said external library? 

Such libraries already exist. Libraries that need talented developers
working on them. Something that I have already suggested, but it
appears to be falling on deaf ears. Which is a shame.

GNU Radio Companion can be used to generate Python code that does
everything that avradio tries to do, including GUI code. This code can
then be further massaged to one's individual needs, the heavy lifting
already being handled by gnuradio's DSP stuff.

/Tomas
Tomas Härdin July 24, 2023, 8:22 p.m. UTC | #10
mån 2023-07-24 klockan 10:13 +0200 skrev Nicolas George:
> Tomas Härdin (12023-07-23):
> > No to this entire patchset.
> 
> 404 argument not found.
> 
> > Users can test libavradio's master if they wish. Do not assume
> > merging
> > this fork will happen, especially not without TC approval, nor that
> > trying to sneak it in won't be noticed and opposed.
> 
> A striving Libre Software project works by compromise. I see no
> intent
> of compromise at all in your position.

Features either are or aren't in scope. I don't see how you can
compromise on that.

> 
> > Why would they package it when there already are mature programs
> > like
> > gqrx, dablin etc? Programs that feature separation of concerns. See
> > for
> > example hacktv which uses ffmpeg, libhackrf and libsoapysdr without
> > insisting on being part of either
> 
> Oh, yes.
> 
> And these idiots working on the Linux kernel

The Linux kernel also has separation of concerns. It has a concept of
userland for example, unlike say TempleOS. Not everything is in scope
for the Linux project.

> >              I know this because it's going to cause headaches for
> > this
> > project to care about maintaining compatibility with a fork that
> > doesn't want to pretend it's a fork.
> 
> This is very dishonest. Maintaining a fork only causes headaches to
> the
> people who do it, and you have made amply clear that would not be
> you.
> 
> In fact, quite the opposite, you were one the loudest demanding that
> one
> of our most talented hacker waste his time on maintaining a separate
> build system instead of doing creative and useful work.

I have 63 forks of ffmpeg alone. I don't see the problem.

As for me being loudest, someone has to be. As a licensed amateur radio
operator I also happen to have domain knowledge, which is why I know
radio stuff will affect the code in profound ways, as we are already
seeing evidence of. These are hard-gotten learns.

/Tomas
Tomas Härdin July 24, 2023, 10:30 p.m. UTC | #11
mån 2023-07-24 klockan 10:19 +0200 skrev Nicolas George:
> Also, is it only for receiving? It is there, at least as a potential,
> the possibility of sending, maybe in the Citizen Band?

Only licensed gear may be operated on the ISM bands, and only licensed
amateurs are allowed to build their own unlicensed transmitters for
operation on the amateur bands. Sometimes the bands overlap. You can
try transmitting anyway, and if you use low enough power then probably
no one will notice. But if you send splatter all across the bands then
spectrum enforcement agents and/or (steamed) hams may come knocking on
your door with subsequent confiscation of gear and a fine. This
happened to a local.

/Tomas
Nicolas George July 25, 2023, 9:33 a.m. UTC | #12
Tomas Härdin (12023-07-24):
> Features either are or aren't in scope. I don't see how you can
> compromise on that.

The scope is what we decide it is, collectively, based on arguments.
Your conception of the scope is only a small part of that, and even
smaller if you cannot sustain it with arguments.

“I don't see how you can compromise on that” is called dogmatism and has
no place in this project.

The way I see it, avradio has about as much or as little its place in a
project that historically contained software implementations of the
major and minor multimedia codecs as hardware acceleration.

Yet support for hardware acceleration has been added, to the convenience
and satisfaction of everybody.

> The Linux kernel also has separation of concerns. It has a concept of
> userland for example, unlike say TempleOS. Not everything is in scope
> for the Linux project.

Yet features have repeatedly made back and forth between kernel and
userland and mixed implementations, searching for the sweet spot of
compromise between performance, security and convenience.

Proof that “the scope”, even when there is a much more clearly
delineated frontier, is fluid and a matter of compromise.

If you cannot accept compromise, then your opinion should not be taken
into consideration in a functioning collective project.

> I have 63 forks of ffmpeg alone. I don't see the problem.

I am doubtful whether this is to be considered a good thing or a bad
thing, but I am rather leaning towards bad.

> As for me being loudest, someone has to be. As a licensed amateur radio
> operator I also happen to have domain knowledge, which is why I know
> radio stuff will affect the code in profound ways, as we are already
> seeing evidence of. These are hard-gotten learns.

Well, if you are right, then we will see patches on the mailing list
that will affect the code in profound ways, and you will be able to
object to them then.

But far from “already seeing evidence” of the apocalypse you predict, we
see that the avradio code already delivers features while being
self-contained and only required extending the signal processing
abilities of our libraries a little, and in ways that are useful to
other developers.

So I guess it proves being licensed to operate something does not make
you qualified to evaluate the difficulty in implementing the software of
that thing. What a surprise.

I will add that “affect the code in profound ways” was actually true for
hardware acceleration, requiring a big mess in the code and significant
to the internal API and even public API and user interface. Yet nobody
is objecting to them.
Nicolas George July 25, 2023, 9:37 a.m. UTC | #13
Tomas Härdin (12023-07-24):
> Such libraries already exist. Libraries that need talented developers
> working on them. Something that I have already suggested, but it
> appears to be falling on deaf ears. Which is a shame.
> 
> GNU Radio Companion can be used to generate Python code that does
> everything that avradio tries to do, including GUI code. This code can
> then be further massaged to one's individual needs, the heavy lifting
> already being handled by gnuradio's DSP stuff.

If Michael wants to write everything from scratch to learn and discover
rather than just adding tidbits here and there to an existing project,
that is entirely understandable.

FFmpeg was made by somebody who wanted to write everything from scratch
to learn and discover, after all, and at no point was it decided “no
more, now we serve the interests of our sponsors and everything else is
‘out of scope’”.

If Michael wants to work within the framework of FFmpeg and its signal
processing features rather than within the framework of Python, that is
entirely understandable too.
Kieran Kunhya July 25, 2023, 9:51 a.m. UTC | #14
> But far from “already seeing evidence” of the apocalypse you predict, we
> see that the avradio code already delivers features while being
> self-contained and only required extending the signal processing
> abilities of our libraries a little, and in ways that are useful to
> other developers.

This is a completely incorrect and poorly thought through statement.
AM/FM are a microscopically small subset of SDR.
SDR is a massively complex field, bigger than multimedia itself. There
are permutations and complexity in things like DAB/DVB etc much more
complex than anything the FFmpeg API can handle (e.g physical layer
pipes).

To draw the conclusion that all SDR is now fine in FFmpeg beacause in
your mind AM/FM did not require a large number of changes to FFmpeg is
incorrect to say the least.

Kieran
Nicolas George July 25, 2023, 9:56 a.m. UTC | #15
Kieran Kunhya (12023-07-25):
> This is a completely incorrect and poorly thought through statement.
> AM/FM are a microscopically small subset of SDR.
> SDR is a massively complex field, bigger than multimedia itself. There
> are permutations and complexity in things like DAB/DVB etc much more
> complex than anything the FFmpeg API can handle (e.g physical layer
> pipes).
> 
> To draw the conclusion that all SDR is now fine in FFmpeg beacause in
> your mind AM/FM did not require a large number of changes to FFmpeg is
> incorrect to say the least.

<sigh> Applying support for AM/FM now does not force us to accept
support for more complex parts later, and support for what is now there
is already an interesting feature.

In other words, please all stop engaging in the slippery slope fallacy:
reject objectionable patches if they ever come but stop blocking
reasonable features.

Also, trust Michael to be able to realize when to stop.
Kieran Kunhya July 25, 2023, 10:16 a.m. UTC | #16
On Tue, Jul 25, 2023 at 10:56 AM Nicolas George <george@nsup.org> wrote:
>
> Kieran Kunhya (12023-07-25):
> > This is a completely incorrect and poorly thought through statement.
> > AM/FM are a microscopically small subset of SDR.
> > SDR is a massively complex field, bigger than multimedia itself. There
> > are permutations and complexity in things like DAB/DVB etc much more
> > complex than anything the FFmpeg API can handle (e.g physical layer
> > pipes).
> >
> > To draw the conclusion that all SDR is now fine in FFmpeg beacause in
> > your mind AM/FM did not require a large number of changes to FFmpeg is
> > incorrect to say the least.
>
> <sigh> Applying support for AM/FM now does not force us to accept
> support for more complex parts later, and support for what is now there
> is already an interesting feature.
>
> In other words, please all stop engaging in the slippery slope fallacy:
> reject objectionable patches if they ever come but stop blocking
> reasonable features.

As we have seen in FFmpeg, APIs are "designed" around basic things
like AVI and hacks upon hacks are needed to support anything more
complex. The API being written around AM/FM is history clearly
repeating itself.

Unlike you, quite a lot of people are able to comprehend this now and
don't want history repeating itself.

Kieran
Tomas Härdin July 25, 2023, 12:02 p.m. UTC | #17
tis 2023-07-25 klockan 11:56 +0200 skrev Nicolas George:
> Kieran Kunhya (12023-07-25):
> > This is a completely incorrect and poorly thought through
> > statement.
> > AM/FM are a microscopically small subset of SDR.
> > SDR is a massively complex field, bigger than multimedia itself.
> > There
> > are permutations and complexity in things like DAB/DVB etc much
> > more
> > complex than anything the FFmpeg API can handle (e.g physical layer
> > pipes).
> > 
> > To draw the conclusion that all SDR is now fine in FFmpeg beacause
> > in
> > your mind AM/FM did not require a large number of changes to FFmpeg
> > is
> > incorrect to say the least.
> 
> <sigh> Applying support for AM/FM now does not force us to accept
> support for more complex parts later

It opens the door for it. DAB has already been mentioned, but tellingly
no mention has been made of the difficulty in implementing modems.
Check out the good work done by the FreeDV people for an inkling. As
Kieran says, SDR is a huge and complicated field.

/Tomas
Nicolas George July 25, 2023, 1:55 p.m. UTC | #18
Kieran Kunhya (12023-07-25):
> As we have seen in FFmpeg, APIs are "designed" around basic things
> like AVI and hacks upon hacks are needed to support anything more
> complex. The API being written around AM/FM is history clearly
> repeating itself.
> 
> Unlike you, quite a lot of people are able to comprehend this now and
> don't want history repeating itself.

I know all that, I was here as well as you. But there are two things
that you refuse to acknowledge (because I will not stoop to the
discourteous suggestion that you are not intelligent enough to
comprehend it):

One, most of these “hacks” are in limited and optional parts of the
code. I you do not like them, you just have to not look at them and they
are not your problem. And if at some point they become nobody's problem,
then removing them is very easy.

Two, a lot of our users are very happy of the consequences of these
hacks. They like that their favorites applications have gained new
features transparently. Even if it is limited and awkward, because
limited and awkward is better than nothing, and using other, specialized
applications for these features would bring a different brand of limited
of awkward.

If you would rather FFmpeg be a perfect pearl of beautiful design
developed in an ivory tower with no regards for the satisfaction of
users… there is a project for that, it is called libav. And guess what?
It died because of that attitude.

In the meantime, the patches we are discussing for now are not even
hacks. So if you and Thomas only have a slippery slope fallacy against
them, we will give you exactly as much consideration as fallacies
deserve.
Tomas Härdin July 25, 2023, 2:17 p.m. UTC | #19
mån 2023-07-24 klockan 00:56 +0200 skrev Michael Niedermayer:
> And here comes the 3rd step, connect libavfilter to libavradio, move
> the components
> into libavfilter. Do demodulation and probing in filters.

Paul already said no to this

> filters will not need to deal with mpeg-ts or AAC because they would
> be
> used by libavradio and return mpeg-ts / AAC to its "caller"
> 
> And then the 4th step (which can be switched with teh 3rd)
> Make all the parts available though a new API. At that time we will
> have a
> much better understanding of what there is inside libavradio (because
> its
> actually implemented) and also what developers want from a libavradio
> API
> Here we are in a much better position to actually design a good API.
> Also at this point many parts can be already used through
> libavfilter,
> you need a stereo FM demodulator? there would be a avfilter for that
> probably.

This describes gnuradio, or more accurately the gnuradio we have at
home. It would require a widening of scope of lavfi. And a new API or
even multiple new APIs. Which is strange because so far we've been led
to believe that the effects on the rest of the project would be minor.
That's not even taking users into account, who I fear will also be
compelled to do extra work to accommodate all this. Untold months if
not years of work. Why?

The more I think about this the more baffling it becomes. Instead of
the current architecture where we mostly have demuxer -> decoder ->
lavfi -> encoder -> muxer, or bytes -> packets -> essence -> packets ->
bytes, instead data of various types need to be woven in and out of
lavfi, interacting with lavf and lavc in arcane ways. With gnuradio
this isn't much of a problem because the project has been built around
it from day one. The way a typical GRC graph looks, and the fact that
each radio service needs an entirely different graph, with entirely
different combinations of data types in and out of each box, reflects
this.

Another thing that baffles me is this argument around time. Because
surely it would take less time to just use what already exists, making
use of the miracle of the UNIX pipe where necessary. Programs that do
one thing and do it well and all that. Division of labour.

> There are other pathes forward but thats the current plan _IF_ this
> isnt killed off
> by the community and _IF_ others join and enjoy working on this. Also
> nothing is
> cast in stone, this plan is intended to be adapted as needed on the
> way.
> 
> I originally just intended to do AM&FM demodulation, and this has
> become a
> much bigger project.

Like an extent that is slowly growing. Creeping, if you will.

> Theres a point where
> i will move on and switch the bulk of my time to "not FFmpeg" and
> just do
> payed work here.

I am honestly at a loss for words with this. When I first saw this I
debated whether to even reply to it. It speaks for itself really.

/Tomas
Kieran Kunhya July 25, 2023, 2:37 p.m. UTC | #20
On Tue, Jul 25, 2023 at 2:56 PM Nicolas George <george@nsup.org> wrote:
> If you would rather FFmpeg be a perfect pearl of beautiful design
> developed in an ivory tower with no regards for the satisfaction of
> users…

You can have satisified users without having to implement SDR in a
multimedia library, nor xml parsing, nor a web server, nor anything
else that sits at a higher or lower level than FFmpeg.
It's not just multimedia that goes over radio, it's not just
multimedia that goes over TCP,  it's not just multimedia that needs
XML, that's why there are separate libraries for these kind of things.

FFmpeg is not the kitchen sink of miscellaneous wheel reinvention.

Kieran
Michael Niedermayer July 26, 2023, 10:37 a.m. UTC | #21
On Mon, Jul 24, 2023 at 10:19:13PM +0200, Tomas Härdin wrote:
> sön 2023-07-23 klockan 16:01 -0300 skrev James Almer:
> > What bothers me is that even though it's added outside of lavd, it's 
> > being added as a brand new lavd, with all the drawbacks this implies,
> > including it being tied to lavf in an awful way. And all for a single
> > "device" AVInputFormat. It's completely overkill.
> > 
> > Why is this libavradio not designed as a standalone library, with its
> > own, carefully designed API for general radio usage, that can be then
> > glued to lavd as an AVInputFormat relying on said external library? 
> 
> Such libraries already exist. Libraries that need talented developers
> working on them. Something that I have already suggested, but it
> appears to be falling on deaf ears. Which is a shame.

You suggested this for many things, including MXF
For MXF your suggestion has no support AFAIK. And it would cause
problems with MXF support in FFmpeg (but thats off topic here)

For avradio, maybe i need to communicate more with the other developers
but I am not ignoring your suggestion. I also dont do what you suggest
litterally (which is maybe why you think iam ignoring it)

But since a while my plan for DAB support is to using an external
library.
For FM and AM, using an external libraray is just a mistake, same as
it is for something like *av_asprintf(). The external libraray would
just be more pain than doing it internally

About the need for talented developers in SDR projects. I understand
every project needs more talented developers. But what my goal after
having some fun with SDR is, is to

serve the end user. And here iam
trying to make it possible that "FFmpeg based" players and tools
can use SDR.
If i join gnu radio and use pipes very few end users of FFmpeg based
tools would be served by that

I dont understand why you keep telling me to join a absolutely huge
python project (which has no need for any further development in SDR code)
(and has no easy path to be used by a FFmpeg based tool end user)

For FFmpeg using a C or C++ libraray for some parts of SDR like DAB
is something that makes sense and i plan to go that route. But beyond
that I simply do not understand how your suggestions would server
end users
Its not my goal to create a "player" for myself. I have a radio from my
grand aunt that works still fine. Again my goal was to have fun with
the math&dsp code and serve the end users of this project.
gnu radio needs no further math & dsp from me and it wont serve end
users of libav* / FFmpeg tools. The repeated suggestion for gnu radio
baffles me. Maybe iam missing something, of course, but i dont see
how this could work. Maybe if iam all wrong here, why dont you send
a patch, that gives ffmpeg & libav* based tool end users AM/FM/DAB/DVB
support through gnu radio ? With same features and convenience
avradio does today.

thx

[...]
Tomas Härdin July 27, 2023, 1:05 p.m. UTC | #22
ons 2023-07-26 klockan 12:37 +0200 skrev Michael Niedermayer:

> But what my goal after
> having some fun with SDR is, is to
> serve the end user. And here iam
> trying to make it possible that "FFmpeg based" players and tools
> can use SDR.

Which tools and players?

> For FFmpeg using a C or C++ libraray for some parts of SDR like DAB
> is something that makes sense and i plan to go that route. But beyond
> that I simply do not understand how your suggestions would server
> end users

End users are already served by existing programs like gqrx. My point
is rather about the sanity of our developers, and of downstream
developers. The fact that you don't mention downstream projects by name
tells me that you haven't asked them

/Tomas
Nicolas George July 27, 2023, 5:56 p.m. UTC | #23
Kieran Kunhya (12023-07-25):
> You can have satisified users without having to implement SDR in a
> multimedia library, nor xml parsing, nor a web server, nor anything
> else that sits at a higher or lower level than FFmpeg.

Satisfied users is not a yes/no thing. There was a branch of the fork
with more features and more satisfied users, and a branch of the fork
with less features and less satisfied users. The second one died, and
good riddance.

We are on the branch of the fork that wants more features even if it
means a few hacks. Accept it or work on the other branch.

> It's not just multimedia that goes over radio, it's not just
> multimedia that goes over TCP,  it's not just multimedia that needs
> XML, that's why there are separate libraries for these kind of things.

It is not just multimedia that can be encrypted, yet FFmpeg has
cryptographic primitives.

It is not just multimedia that can go over HTTP, yet FFmpeg has support
for HTTP — limited to its needs.

It is not just multimedia that requires Fourier transforms and similar
mathematical operations, yet FFmpeg has them too.

> FFmpeg is not the kitchen sink of miscellaneous wheel reinvention.

I reject the disparaging “kitchen sink”, but apart from it, YES, FFmpeg
is exactly that, or at least it was some time before the fork.

Then some people pushed for more seriousness, more stability, which
meant less creativity. And seeing their efforts to make the project more
serious, more stable and more sterile were not succeeding enough, they
tried to take over, that resulted in a fork that almost killed the
project.

And we, on the FFmpeg side, made the mistake to try to entice them back.
We changed for that, we made the project more serious, more stable, more
sterile, to try and convince them to come back. We should not have done
so. Instead, we should have reaffirmed what makes FFmpeg not libav, and
demanded THEY change to be welcomed back.

And so the trend towards more seriousness, more stability, more
sterility, continued. Amplified by people who started business to
exploit FFmpeg, and have a personal interest in the project being more
serious, more stable, and don't care it's more sterile.

But before that evolution, what FFmpeg success in the first place, was
precisely that it was a welcoming place for development in the
multimedia field. Not just a narrow version of “the scope”, but anything
related to multimedia, or useful for it. Not just things that do not
exist elsewhere but also projects to invent new and creative ways of
doing it. And since that ambiance attracted very talented hackers
(including you personally, as far as I could see), it frequently gave
impressive results.

So yes, being able to use SDR devices to record AM/FM on the fly from
ffmpeg or any FFmpeg-based application is worth a few hacks here and
there.

And yes, being able to read network streams defined by XML manifests
without linking to the big stinking pile of shite that is libxml2 is
worth having our own XML parser, limited to exactly what we need instead
of supporting the whole complex format.

And so on and so on.

FFmpeg is a place for creativity. If you do not agree, try to remember
why you came here in the first place.
Michael Niedermayer July 27, 2023, 6:36 p.m. UTC | #24
On Thu, Jul 27, 2023 at 03:05:23PM +0200, Tomas Härdin wrote:
> ons 2023-07-26 klockan 12:37 +0200 skrev Michael Niedermayer:
> 
> > But what my goal after
> > having some fun with SDR is, is to
> > serve the end user. And here iam
> > trying to make it possible that "FFmpeg based" players and tools
> > can use SDR.
> 
> Which tools and players?

Thats a good question. I did not state that clearly probably

The idea really is any tool which is able to use an arbitrary
demuxer / input device.

all of our tools (ffplay, ffprobe, ffmpeg) work
but our doc/examples should work too

Also id like to say thanks for writing this mail without terse
attacks like some other replies i got.


> 
> > For FFmpeg using a C or C++ libraray for some parts of SDR like DAB
> > is something that makes sense and i plan to go that route. But beyond
> > that I simply do not understand how your suggestions would server
> > end users
> 
> End users are already served by existing programs like gqrx.

I disagree, let me explain

Let me first explain what i want to provide to the user (most of this
is already implemented, some needs more work)
the user starts her favorite player, be that vlc, ffplay, or whatever
chooses sdr as input device and thats all configuration she needs.
She can select a specific driver, gain and so but she doesnt have to
Now she only needs 2 buttons, seek forward and seek backward, in
ffplay thats the cursor keys. To select the station.
And she sees on the screen what station that is, what song title and
artist are playing as well as what is playing on any other FM station
in view (that works here already in europe, for the US if it doesnt work
i need a sample from dumpurl ...)
(for non interactive tools like ffmpeg she would have to select the
frequency she wants to listen to or all in view ...)

Now gqrx needs me to manually enter the frequency, the modulation the
device, then it still doesnt work (first one has to know why from multiple
rtlsdr lines some dont work) and once one is through this it still
doesnt work, all AGC methods dont work, i have to set the gain manually
for the station i want to listen to to have acceptable quality. I do know
but at this point we lost likely 90% of users already who dont realize that
the AGC sets a too high gain
Also gqrx doesnt tell me what iam listening to, the
name of the radio station?
the artist ?
the song name ?
nothing like this is shown
and if i want to switch to the next station i have to enter its frequency
or click on the location of the radio spectrum

gqrx is a tool a radio amateur like you will be happy with (and i
realize likely more powerfull tools would fit even better)

but i think the average user wants to listen to or record broadcast radio
and have as little to mess with and has the maximum information like
song names and titles available


> My point
> is rather about the sanity of our developers, and of downstream
> developers. The fact that you don't mention downstream projects by name
> tells me that you haven't asked them

The original plan of an input device should not affect anyone in
any way who doesnt want to use it. Its just another device.
libavradio could affect people because it could be an extra dependancy
an extra package and so on.
I will propose a patchset to libavradio that avoids this.

Thanks!

[...]
Nicolas George July 27, 2023, 6:48 p.m. UTC | #25
Michael Niedermayer (12023-07-27):
> Now gqrx needs me to manually enter the frequency, the modulation the
> device, then it still doesnt work (first one has to know why from multiple
> rtlsdr lines some dont work) and once one is through this it still
> doesnt work, all AGC methods dont work, i have to set the gain manually
> for the station i want to listen to to have acceptable quality. I do know
> but at this point we lost likely 90% of users already who dont realize that
> the AGC sets a too high gain

Also, can gqrx (or other tools based on the same backends) record from a
V4L device at the same time, process the video to add text or overlay a
logo or decrease the noise, process the audio to normalize the volume or
mix it with background music, encode it into a variety of codecs and
save the result into a file while at the same time publishing it as a
Youtube Live stream?

Because if something is integrated, then ffmpeg can do all that.

Regards,
Kieran Kunhya July 28, 2023, 11:07 a.m. UTC | #26
I am going to ignore the dredging up of ancient history.

On Thu, Jul 27, 2023 at 6:56 PM Nicolas George <george@nsup.org> wrote:
> > It's not just multimedia that goes over radio, it's not just
> > multimedia that goes over TCP,  it's not just multimedia that needs
> > XML, that's why there are separate libraries for these kind of things.
>
> It is not just multimedia that can be encrypted, yet FFmpeg has
> cryptographic primitives.
>
> It is not just multimedia that can go over HTTP, yet FFmpeg has support
> for HTTP — limited to its needs.

FFmpeg doesn't implement TCP in userspace, it doesn't implement the
WiFi protocol etc etc. Different layers are delegated to different
programs.
Is FFmpeg going to implement HTTP3 (QUIC) in full? QUIC is a layered protocol.

> It is not just multimedia that requires Fourier transforms and similar
> mathematical operations, yet FFmpeg has them too.

All of your examples are small and self-contained. SDR is definitely
not small and self-contained. It's a field bigger than multimedia and
there are many layers of framing inside.

Kieran
Nicolas George July 30, 2023, 1:04 p.m. UTC | #27
Kieran Kunhya (12023-07-28):
> FFmpeg doesn't implement TCP in userspace, it doesn't implement the
> WiFi protocol etc etc. Different layers are delegated to different
> programs.

Hi. You seem to be discussing this in more good faith than I previously
imagined, so I will try to tone done the irritation in my mails.

I am also changing the subject of the mail, so that more people will
have a look at it. I have already posted about my conception of what
FFmpeg is and should be in the previous mail:
http://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/312735.html

There are at least two necessary conditions for something to go into
FFmpeg: that it is useful to users, at least a few of them, and that
somebody bothered to write the code.

FFmpeg is designed to run under an operating system, where a network
stack is usually available whenever network hardware exists, so there is
absolutely no need for that in FFmpeg.

But if people started to routinely use FFmpeg on some kind of
bare-metal microcontroller where network hardware exists but the
official network stack is too big to share the space with FFmpeg, and if
somebody were to propose a limited network stack based on lavu's
cryptographic primitives, then it would totally make sense to accept it.

Yes, this example is far-fetched, because you chose a case where only a
far-fetched example works.

You insist on having different layers, and I agree it is somewhat
relevant. But remember: the Internet is not built on the nice
theoretical layers of the OSI model. The protocols of Internet are much
more messy, because they insist more on pragmatism than aesthetics, and
that is what made their success.

If there are well-defined layers, then probably the others layers are
already implemented, the “different programs” exist, are very
satisfactory and very widely available. Then FFmpeg does not need to
have them natively.

But if these “different programs” for different layers do not exist, or
are not satisfactory, or are not widely available, then we have to
develop them.

And if that happens, it would be idiot to force them to be separate
projects. Maybe later, when they have become stable, and other programs
use them, it will make sense to split them into their own separate
project. But in the beginning, it is a waste of effort.

> Is FFmpeg going to implement HTTP3 (QUIC) in full? QUIC is a layered protocol.

I do not know. I have followed things from afar, does HTTP3 brings
benefits from users, apart from more efficient tracking and faster
delivery of ads?

Anyway, your sentence brigs a point that is very important:

*** IT DOES NOT HAVE TO BE COMPLETE TO BE USEFUL. ***

See below for more about it.


> All of your examples are small and self-contained. SDR is definitely
> not small and self-contained. It's a field bigger than multimedia and
> there are many layers of framing inside.

Michael's code seems pretty self-contained to me.

And once again:

*** IT DOES NOT HAVE TO BE COMPLETE TO BE USEFUL. ***

As far as I understand it, if I bought the hardware tomorrow, the code
that Michael already wrote, and that is a tiny little bit of the whole
field of SDR, would already bring me features that are not available in
any other piece of Libre Software, or possibly at the cost of fragile
plumbing.

This is enough of an argument to warrant inclusion.

And it does not make sense to insist that one of our most talented
developers waste his time with the trouble of maintaining a separate
project just to satisfy aesthetic considerations of “proper layering”.

I have another example of “it does not have to be complete to be
useful”: XML. The whole XML standard is quite complex, it involves DVD
and schema validation, loading external entities, etc. But the use of
XML in multimedia is much more limited, it only involves parsing
“<foo bar="qux">”-style text.

Now, “proper layering” dictates using a real XML library. But real XML
libraries are designed to support most of the standard, and that affects
their design as a whole.

That means every time we use a real XML library to parse
“<foo bar="qux">”, we pay the price for the complexity of the whole
language, in terms of efficiency, reliability, security exposure.

If we had our own parser for “<foo bar="qux">”, we would have to pay a
price only once.

“Proper layering” has benefits, but it also has costs. Therefore it is a
bad idea to adhere to it dogmatically.

FFmpeg has been successful because it relied on pragmatism rather than
dogmatic adherence to principles. Let us continue that way.

Regards,
Andrey Turkin July 30, 2023, 5:07 p.m. UTC | #28
вс, 30 июл. 2023 г. в 16:04, Nicolas George <george@nsup.org>:

> Kieran Kunhya (12023-07-28):
> > FFmpeg doesn't implement TCP in userspace, it doesn't implement the
> > WiFi protocol etc etc. Different layers are delegated to different
> > programs.
>

There is a good reason to have some part of TCP implemented in FFmpeg
though. It would be _extremely_ useful to be able to read and replay pcap
dumps of an RTP stream, or an HLS or DASH stream, or whichever else
multi-connection streams are there.
There is also at least one demodulator already in FFmpeg, namely VBI bit
slicer (it is implemented through an external library though).
Kieran Kunhya July 30, 2023, 6:29 p.m. UTC | #29
On Sun, Jul 30, 2023 at 6:07 PM Andrey Turkin <andrey.turkin@gmail.com> wrote:
>
> вс, 30 июл. 2023 г. в 16:04, Nicolas George <george@nsup.org>:
>
> > Kieran Kunhya (12023-07-28):
> > > FFmpeg doesn't implement TCP in userspace, it doesn't implement the
> > > WiFi protocol etc etc. Different layers are delegated to different
> > > programs.
> >
>
> There is a good reason to have some part of TCP implemented in FFmpeg
> though. It would be _extremely_ useful to be able to read and replay pcap
> dumps of an RTP stream, or an HLS or DASH stream, or whichever else
> multi-connection streams are there.

I plan to write a more detailed response to Nicolas' email. However,
this response is superb because it immediately points out the flaw in
the arguments. Users will not tolerate "incomplete" features, they
will always want their edge case (packet capture replay) to work. This
is Open Source, there are no product managers and roadmaps to
constrain user requests so we have to decide as a community what is in
scope and what is not.

Kieran
Nicolas George July 30, 2023, 6:54 p.m. UTC | #30
Kieran Kunhya (12023-07-30):
> I plan to write a more detailed response to Nicolas' email. However,
> this response is superb because it immediately points out the flaw in
> the arguments. Users will not tolerate "incomplete" features, they
> will always want their edge case (packet capture replay) to work. This
> is Open Source, there are no product managers and roadmaps to
> constrain user requests so we have to decide as a community what is in
> scope and what is not.

“Patch welcome.”

And IF it becomes too big, we can discuss splitting it into a separate
library.

But as long as a new feature doesn't metastasize into the common code,
as long as it stays optional, there is no ground to oppose it, imaginary
“scope” or not.

Regards,
Tomas Härdin July 31, 2023, 1:56 p.m. UTC | #31
sön 2023-07-30 klockan 15:04 +0200 skrev Nicolas George:
> That means every time we use a real XML library to parse
> “<foo bar="qux">”, we pay the price for the complexity of the whole
> language, in terms of efficiency, reliability, security exposure.

As far as I recall libxml2 does not enable the fancier features of XML
unless told to do so. And if it can't disable things like DTD then a
ticket should be opened with them to make that possible. It is foolish
to spread scarce developer time more thinly. It almost certainly means
worse security, not better.

The same goes for all things that FFmpeg reimplements. HTTP has already
been mentioned. How many developer hours have been wasted on it when
libcurl could be used instead, and a fraction of those hours going to
improving it rather than a duplicate implementation?

Layering is not an end in itself as you rightfully point out. It is a
tool. To what end?

I have been accused of being a "bean counter". But what are these beans
that I count? They are developer time, the sole source of value of the
free software movement as a whole. When I see things like HTTP or MXF
being reimplemented I don't see features. I see liabilities.

In the free software world we don't layer and segregate things for no
reason. We do it so that programs can interact with each other through
standardized interfaces. The effect is a comedy of the commons. More
can be done with less labour. For an FM receiver program the
appropriate interfaces are ALSA, PulseAudio and/or JACK. That way its
audio can be piped to many programs.

It is true that we can add more features, and it is also certainly true
that these are useful for a non-empty set of users. But is it a good
use of scarce developer time? Were SDR limited to only Michael's time
then there would be no problem. But it isn't. It unavoidably touches
many other parts of the code, as we are already seeing.

/Tomas
Rémi Denis-Courmont Aug. 1, 2023, 7:48 a.m. UTC | #32
Le 31 juillet 2023 00:07:37 GMT+07:00, Andrey Turkin <andrey.turkin@gmail.com> a écrit :
>вс, 30 июл. 2023 г. в 16:04, Nicolas George <george@nsup.org>:
>
>> Kieran Kunhya (12023-07-28):
>> > FFmpeg doesn't implement TCP in userspace, it doesn't implement the
>> > WiFi protocol etc etc. Different layers are delegated to different
>> > programs.
>>
>
>There is a good reason to have some part of TCP implemented in FFmpeg
>though.

No because :

> It would be _extremely_ useful to be able to read and replay pcap
>dumps of an RTP stream,

That's UDP, and it wouldn't work anyhow. You need to map MAC addresses, IP addresses and port numbers, and (in the general case) you need the original SDP. You can't get that straight out of a packet capture.

There are proprietary formats to record RTP flows (since IETF steadfastly refused to standardise anything), and they're not normally going all the way to the link layer as a packet capture does.

> Or an HLS or DASH stream, or whichever else
>multi-connection streams are there.

That's even worse. You don't want to implement it in FFmpeg because you'd want to reproduce the behaviour of the original TCP/IP stack, not the different behaviour of whatever TCP reassembly code FFmpeg would have. And realistically, you can't replay duplex packet flows anyway: you'd quickly get critical inconsistencies between how FFmpeg reacts and how the recorded client application reacted (be it an old version of FFmpeg or not).

There are tools to replay packet captures. And however imperfect they may intrinsically be, they are better than whatever FFmpeg could hope to achieve. Also they don't require duplicating existing code, for a very fringe use case.

>There is also at least one demodulator already in FFmpeg, namely VBI bit
>slicer (it is implemented through an external library though).
>_______________________________________________
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>To unsubscribe, visit link above, or email
>ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Cosmin Stejerean Aug. 1, 2023, 7:51 p.m. UTC | #33
On Jul 27, 2023, at 11:36 AM, Michael Niedermayer <michael@niedermayer.cc> wrote:

Let me first explain what i want to provide to the user (most of this
is already implemented, some needs more work)
the user starts her favorite player, be that vlc, ffplay, or whatever
chooses sdr as input device and thats all configuration she needs.
She can select a specific driver, gain and so but she doesnt have to
Now she only needs 2 buttons, seek forward and seek backward, in
ffplay thats the cursor keys. To select the station.
And she sees on the screen what station that is, what song title and
artist are playing as well as what is playing on any other FM station
in view (that works here already in europe, for the US if it doesnt work

i need a sample from dumpurl ...)
(for non interactive tools like ffmpeg she would have to select the
frequency she wants to listen to or all in view ...)

Now gqrx needs me to manually enter the frequency, the modulation the
device, then it still doesnt work (first one has to know why from multiple
rtlsdr lines some dont work) and once one is through this it still
doesnt work, all AGC methods dont work, i have to set the gain manually
for the station i want to listen to to have acceptable quality. I do know
but at this point we lost likely 90% of users

I know this is a contentious topic, but as a heavy user of ffmpeg for both work and fun, and as an amateur radio user, what you describe sounds pretty great to me. I can definitely imagine using this for a few usecases. I get that other tools exist and others that know how to use those can of course continue to use them. I for one would definitely love to use ffmpeg directly if that was an option.

This is not something I'd want enabled in the ffmpeg build at work due to the extra surface area, but assuming I can disable the sdr radio bits at build time for "serious" builds, and that this code is actively maintained and designed in a way that minimizes interference with other parts of ffmpeg, then it's not clear to me why there's such a strong reaction against having this included in ffmpeg.

- Cosmin
Paul B Mahol Aug. 1, 2023, 8:06 p.m. UTC | #34
On Tue, Aug 1, 2023 at 9:51 PM Cosmin Stejerean <cosmin@cosmin.at> wrote:

> On Jul 27, 2023, at 11:36 AM, Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> Let me first explain what i want to provide to the user (most of this
> is already implemented, some needs more work)
> the user starts her favorite player, be that vlc, ffplay, or whatever
> chooses sdr as input device and thats all configuration she needs.
> She can select a specific driver, gain and so but she doesnt have to
> Now she only needs 2 buttons, seek forward and seek backward, in
> ffplay thats the cursor keys. To select the station.
> And she sees on the screen what station that is, what song title and
> artist are playing as well as what is playing on any other FM station
> in view (that works here already in europe, for the US if it doesnt work
>
> i need a sample from dumpurl ...)
> (for non interactive tools like ffmpeg she would have to select the
> frequency she wants to listen to or all in view ...)
>
> Now gqrx needs me to manually enter the frequency, the modulation the
> device, then it still doesnt work (first one has to know why from multiple
> rtlsdr lines some dont work) and once one is through this it still
> doesnt work, all AGC methods dont work, i have to set the gain manually
> for the station i want to listen to to have acceptable quality. I do know
> but at this point we lost likely 90% of users
>
> I know this is a contentious topic, but as a heavy user of ffmpeg for both
> work and fun, and as an amateur radio user, what you describe sounds pretty
> great to me. I can definitely imagine using this for a few usecases. I get
> that other tools exist and others that know how to use those can of course
> continue to use them. I for one would definitely love to use ffmpeg
> directly if that was an option.
>
> This is not something I'd want enabled in the ffmpeg build at work due to
> the extra surface area, but assuming I can disable the sdr radio bits at
> build time for "serious" builds, and that this code is actively maintained
> and designed in a way that minimizes interference with other parts of
> ffmpeg, then it's not clear to me why there's such a strong reaction
> against having this included in ffmpeg.
>

Because it would always give sub-optimal results at best.

Time to implement auto-pilot into FFmpeg too.


> - Cosmin
>
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
Vittorio Giovara Aug. 2, 2023, 1:44 a.m. UTC | #35
On Sun, Jul 30, 2023 at 3:04 PM Nicolas George <george@nsup.org> wrote:

> Kieran Kunhya (12023-07-28):
> > FFmpeg doesn't implement TCP in userspace, it doesn't implement the
> > WiFi protocol etc etc. Different layers are delegated to different
> > programs.
>
> Hi. You seem to be discussing this in more good faith than I previously
> imagined, so I will try to tone done the irritation in my mails.
>

sorry for jumping in mid discussion, but shouldn't that be the case always?

But if people started to routinely use FFmpeg on some kind of
> bare-metal microcontroller where network hardware exists but the
> official network stack is too big to share the space with FFmpeg, and if
> somebody were to propose a limited network stack based on lavu's
> cryptographic primitives, then it would totally make sense to accept it.
>

no? that sounds a terrible maintenance burden in terms of both code size
and security issues, nobody wants that!
what could be a viable compromise is *maybe* providing the hooks where
needed where custom io and callbacks can be implemented, but afaict there
are plenty of those in ffmpeg already

FFmpeg has been successful because it relied on pragmatism rather than
> dogmatic adherence to principles. Let us continue that way.
>

ffmpeg has been successful because points of contentions were resolved with
consensus (most of the times) and not by sheer number of emails or email
length about the topic. I am not even familiar with this avradio thing but
if the community seems so against it, let's maybe find another solution
(separate library, repository, tool etc) instead of wasting time and energy
over the same points.
Michael Niedermayer Aug. 2, 2023, 12:46 p.m. UTC | #36
On Tue, Aug 01, 2023 at 10:06:19PM +0200, Paul B Mahol wrote:
> On Tue, Aug 1, 2023 at 9:51 PM Cosmin Stejerean <cosmin@cosmin.at> wrote:
> 
> > On Jul 27, 2023, at 11:36 AM, Michael Niedermayer <michael@niedermayer.cc>
> > wrote:
> >
> > Let me first explain what i want to provide to the user (most of this
> > is already implemented, some needs more work)
> > the user starts her favorite player, be that vlc, ffplay, or whatever
> > chooses sdr as input device and thats all configuration she needs.
> > She can select a specific driver, gain and so but she doesnt have to
> > Now she only needs 2 buttons, seek forward and seek backward, in
> > ffplay thats the cursor keys. To select the station.
> > And she sees on the screen what station that is, what song title and
> > artist are playing as well as what is playing on any other FM station
> > in view (that works here already in europe, for the US if it doesnt work
> >
> > i need a sample from dumpurl ...)
> > (for non interactive tools like ffmpeg she would have to select the
> > frequency she wants to listen to or all in view ...)
> >
> > Now gqrx needs me to manually enter the frequency, the modulation the
> > device, then it still doesnt work (first one has to know why from multiple
> > rtlsdr lines some dont work) and once one is through this it still
> > doesnt work, all AGC methods dont work, i have to set the gain manually
> > for the station i want to listen to to have acceptable quality. I do know
> > but at this point we lost likely 90% of users
> >
> > I know this is a contentious topic, but as a heavy user of ffmpeg for both
> > work and fun, and as an amateur radio user, what you describe sounds pretty
> > great to me. I can definitely imagine using this for a few usecases. I get
> > that other tools exist and others that know how to use those can of course
> > continue to use them. I for one would definitely love to use ffmpeg
> > directly if that was an option.
> >
> > This is not something I'd want enabled in the ffmpeg build at work due to
> > the extra surface area, but assuming I can disable the sdr radio bits at
> > build time for "serious" builds, and that this code is actively maintained
> > and designed in a way that minimizes interference with other parts of
> > ffmpeg, then it's not clear to me why there's such a strong reaction
> > against having this included in ffmpeg.
> >
> 
> Because it would always give sub-optimal results at best.

Iam not sure what you refer to by "it" exactly and what the alternative
you compare it to are but why ?

Even leaving this very generic, claiming one implementation will always
give "sub-optimal results" to another does not sound like a fact based
statment.

Thats a bit like saying a reverse engeneered codec will always give
sub optimal results to the binary original. And thats why we better
should go the optimal route


>
> Time to implement auto-pilot into FFmpeg too.

I dont know if you plan that but i dont, did not and have also not
suggested that. In fact i dont even know what exactly you refer to by
"auto-pilot"

thx

[...]
Michael Niedermayer Aug. 2, 2023, 12:55 p.m. UTC | #37
Hi Vittorio

On Wed, Aug 02, 2023 at 03:44:13AM +0200, Vittorio Giovara wrote:
> On Sun, Jul 30, 2023 at 3:04 PM Nicolas George <george@nsup.org> wrote:
> 
> > Kieran Kunhya (12023-07-28):
> > > FFmpeg doesn't implement TCP in userspace, it doesn't implement the
> > > WiFi protocol etc etc. Different layers are delegated to different
> > > programs.
> >
> > Hi. You seem to be discussing this in more good faith than I previously
> > imagined, so I will try to tone done the irritation in my mails.
> >
> 
> sorry for jumping in mid discussion, but shouldn't that be the case always?
> 
> But if people started to routinely use FFmpeg on some kind of
> > bare-metal microcontroller where network hardware exists but the
> > official network stack is too big to share the space with FFmpeg, and if
> > somebody were to propose a limited network stack based on lavu's
> > cryptographic primitives, then it would totally make sense to accept it.
> >
> 
> no? that sounds a terrible maintenance burden in terms of both code size
> and security issues, nobody wants that!
> what could be a viable compromise is *maybe* providing the hooks where
> needed where custom io and callbacks can be implemented, but afaict there
> are plenty of those in ffmpeg already
> 
> FFmpeg has been successful because it relied on pragmatism rather than
> > dogmatic adherence to principles. Let us continue that way.
> >
> 
> ffmpeg has been successful because points of contentions were resolved with
> consensus (most of the times) and not by sheer number of emails or email
> length about the topic. I am not even familiar with this avradio thing but
> if the community seems so against it, let's maybe find another solution
> (separate library, repository, tool etc) instead of wasting time and energy
> over the same points.

the code already is in a seperate repository. And is basically isolated
in a single demuxer and single input device.
Some people still complain that it exists

About the community i do not know what the majority wants. About users
iam fairly confident that they prefer having the option to use it than
not having the option.

thx

[...]
Jean-Baptiste Kempf Aug. 2, 2023, 12:59 p.m. UTC | #38
On Wed, 2 Aug 2023, at 14:55, Michael Niedermayer wrote:
> the code already is in a seperate repository. And is basically isolated
> in a single demuxer and single input device.

But it's not a library in that repository, like swscale, swresample or similar libraries.

If it was, with an API, it would be trivial to add support to this optional library as an FFmpeg module, and noone who complain.

jb
Paul B Mahol Aug. 2, 2023, 1 p.m. UTC | #39
On Wed, Aug 2, 2023 at 2:47 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Tue, Aug 01, 2023 at 10:06:19PM +0200, Paul B Mahol wrote:
> > On Tue, Aug 1, 2023 at 9:51 PM Cosmin Stejerean <cosmin@cosmin.at>
> wrote:
> >
> > > On Jul 27, 2023, at 11:36 AM, Michael Niedermayer <
> michael@niedermayer.cc>
> > > wrote:
> > >
> > > Let me first explain what i want to provide to the user (most of this
> > > is already implemented, some needs more work)
> > > the user starts her favorite player, be that vlc, ffplay, or whatever
> > > chooses sdr as input device and thats all configuration she needs.
> > > She can select a specific driver, gain and so but she doesnt have to
> > > Now she only needs 2 buttons, seek forward and seek backward, in
> > > ffplay thats the cursor keys. To select the station.
> > > And she sees on the screen what station that is, what song title and
> > > artist are playing as well as what is playing on any other FM station
> > > in view (that works here already in europe, for the US if it doesnt
> work
> > >
> > > i need a sample from dumpurl ...)
> > > (for non interactive tools like ffmpeg she would have to select the
> > > frequency she wants to listen to or all in view ...)
> > >
> > > Now gqrx needs me to manually enter the frequency, the modulation the
> > > device, then it still doesnt work (first one has to know why from
> multiple
> > > rtlsdr lines some dont work) and once one is through this it still
> > > doesnt work, all AGC methods dont work, i have to set the gain manually
> > > for the station i want to listen to to have acceptable quality. I do
> know
> > > but at this point we lost likely 90% of users
> > >
> > > I know this is a contentious topic, but as a heavy user of ffmpeg for
> both
> > > work and fun, and as an amateur radio user, what you describe sounds
> pretty
> > > great to me. I can definitely imagine using this for a few usecases. I
> get
> > > that other tools exist and others that know how to use those can of
> course
> > > continue to use them. I for one would definitely love to use ffmpeg
> > > directly if that was an option.
> > >
> > > This is not something I'd want enabled in the ffmpeg build at work due
> to
> > > the extra surface area, but assuming I can disable the sdr radio bits
> at
> > > build time for "serious" builds, and that this code is actively
> maintained
> > > and designed in a way that minimizes interference with other parts of
> > > ffmpeg, then it's not clear to me why there's such a strong reaction
> > > against having this included in ffmpeg.
> > >
> >
> > Because it would always give sub-optimal results at best.
>
> Iam not sure what you refer to by "it" exactly and what the alternative
> you compare it to are but why ?
>
> Even leaving this very generic, claiming one implementation will always
> give "sub-optimal results" to another does not sound like a fact based
> statment.
>

Current SDR in current avradio is suboptimal. That is the fact.


>
> Thats a bit like saying a reverse engeneered codec will always give
> sub optimal results to the binary original. And thats why we better
> should go the optimal route
>
>
> >
> > Time to implement auto-pilot into FFmpeg too.
>
> I dont know if you plan that but i dont, did not and have also not
> suggested that. In fact i dont even know what exactly you refer to by
> "auto-pilot"
>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Into a blind darkness they enter who follow after the Ignorance,
> they as if into a greater darkness enter who devote themselves
> to the Knowledge alone. -- Isha Upanishad
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
Michael Niedermayer Aug. 2, 2023, 1:01 p.m. UTC | #40
On Wed, Aug 02, 2023 at 03:00:54PM +0200, Paul B Mahol wrote:
> On Wed, Aug 2, 2023 at 2:47 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > On Tue, Aug 01, 2023 at 10:06:19PM +0200, Paul B Mahol wrote:
> > > On Tue, Aug 1, 2023 at 9:51 PM Cosmin Stejerean <cosmin@cosmin.at>
> > wrote:
> > >
> > > > On Jul 27, 2023, at 11:36 AM, Michael Niedermayer <
> > michael@niedermayer.cc>
> > > > wrote:
> > > >
> > > > Let me first explain what i want to provide to the user (most of this
> > > > is already implemented, some needs more work)
> > > > the user starts her favorite player, be that vlc, ffplay, or whatever
> > > > chooses sdr as input device and thats all configuration she needs.
> > > > She can select a specific driver, gain and so but she doesnt have to
> > > > Now she only needs 2 buttons, seek forward and seek backward, in
> > > > ffplay thats the cursor keys. To select the station.
> > > > And she sees on the screen what station that is, what song title and
> > > > artist are playing as well as what is playing on any other FM station
> > > > in view (that works here already in europe, for the US if it doesnt
> > work
> > > >
> > > > i need a sample from dumpurl ...)
> > > > (for non interactive tools like ffmpeg she would have to select the
> > > > frequency she wants to listen to or all in view ...)
> > > >
> > > > Now gqrx needs me to manually enter the frequency, the modulation the
> > > > device, then it still doesnt work (first one has to know why from
> > multiple
> > > > rtlsdr lines some dont work) and once one is through this it still
> > > > doesnt work, all AGC methods dont work, i have to set the gain manually
> > > > for the station i want to listen to to have acceptable quality. I do
> > know
> > > > but at this point we lost likely 90% of users
> > > >
> > > > I know this is a contentious topic, but as a heavy user of ffmpeg for
> > both
> > > > work and fun, and as an amateur radio user, what you describe sounds
> > pretty
> > > > great to me. I can definitely imagine using this for a few usecases. I
> > get
> > > > that other tools exist and others that know how to use those can of
> > course
> > > > continue to use them. I for one would definitely love to use ffmpeg
> > > > directly if that was an option.
> > > >
> > > > This is not something I'd want enabled in the ffmpeg build at work due
> > to
> > > > the extra surface area, but assuming I can disable the sdr radio bits
> > at
> > > > build time for "serious" builds, and that this code is actively
> > maintained
> > > > and designed in a way that minimizes interference with other parts of
> > > > ffmpeg, then it's not clear to me why there's such a strong reaction
> > > > against having this included in ffmpeg.
> > > >
> > >
> > > Because it would always give sub-optimal results at best.
> >
> > Iam not sure what you refer to by "it" exactly and what the alternative
> > you compare it to are but why ?
> >
> > Even leaving this very generic, claiming one implementation will always
> > give "sub-optimal results" to another does not sound like a fact based
> > statment.
> >
> 
> Current SDR in current avradio is suboptimal. That is the fact.

Everything is suboptimal in some way

a boat is suboptimal in a dessert, and a camel in the middle of the sea

[...]
Brad Isbell Aug. 2, 2023, 2:12 p.m. UTC | #41
As a frequent FFmpeg user, and an occasional RTL-SDR user, the major
tradeoff for me is in the size of FFmpeg binaries vs. features.  I
agree with Jean-Baptiste that if this were an optional library to be
added to the build, then that resolves any issues I might have as a
user.

Then I have the choice to opt for the big honkin' beast build that
includes all-the-things on my daily dev machine, but can still build
targeted builds for deployment to production servers, oddball
platforms like WASM, etc.

Brad Isbell // AudioPump, Inc.
brad@audiopump.co


On Wed, Aug 2, 2023 at 7:59 AM Jean-Baptiste Kempf <jb@videolan.org> wrote:
>
> On Wed, 2 Aug 2023, at 14:55, Michael Niedermayer wrote:
> > the code already is in a seperate repository. And is basically isolated
> > in a single demuxer and single input device.
>
> But it's not a library in that repository, like swscale, swresample or similar libraries.
>
> If it was, with an API, it would be trivial to add support to this optional library as an FFmpeg module, and noone who complain.
>
> jb
> --
> Jean-Baptiste Kempf -  President
> +33 672 704 734
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Nicolas George Aug. 2, 2023, 2:19 p.m. UTC | #42
Brad Isbell (12023-08-02):
> As a frequent FFmpeg user, and an occasional RTL-SDR user, the major
> tradeoff for me is in the size of FFmpeg binaries vs. features.  I
> agree with Jean-Baptiste that if this were an optional library to be
> added to the build, then that resolves any issues I might have as a
> user.
> 
> Then I have the choice to opt for the big honkin' beast build that
> includes all-the-things on my daily dev machine, but can still build
> targeted builds for deployment to production servers, oddball
> platforms like WASM, etc.

What you describe is already the case, for the avradio device just the
same as for any other component.

> On Wed, Aug 2, 2023 at 7:59 AM Jean-Baptiste Kempf <jb@videolan.org> wrote:

Please do not top-post.

Regards,
Michael Niedermayer Aug. 2, 2023, 2:20 p.m. UTC | #43
On Wed, Aug 02, 2023 at 02:59:11PM +0200, Jean-Baptiste Kempf wrote:
> On Wed, 2 Aug 2023, at 14:55, Michael Niedermayer wrote:
> > the code already is in a seperate repository. And is basically isolated
> > in a single demuxer and single input device.
> 
> But it's not a library in that repository, like swscale, swresample or similar libraries.
> 
> If it was, with an API, it would be trivial to add support to this optional library as an FFmpeg module, and noone who complain.

There are multiple problems but the real problem is that
How many people discuss an SDR API ? (0)
How many people propose an SDR API ? (0)
How many people say what they want an SDR API to be able to do ? (0)
    This is not a simple question ?
    enumerate devices, set options, open, read frames, close ? That does not differ from the
    existing input device / demuxer API.
    If one cannot state a single difference in the API requirements from the existing
    input device API, how can one design that API ?
    If the existing input device API suposedly is not good
    Is it bad just because it is the existing API ? And it would be perfectly
    fine if it just had different function names ?
In other areas the community collaborates to create APIs
here all energy is spend to block patches (the latest set blocked are pure bugfixes)

Also swresample and swscale are simpler in what they need to provide API wise.

My very first patch i sent btw was blocked with the claim that it used
an external library and did not do the processing nativly.
Thats exactly what you suggest now

IMHO, People who want to use this API, or want to implement this API
should help with the API design and implementation

And if there are 0 people wanting to use the API then why should i design
that API ? who for ?
SDR in FFmpeg has 500+ users who want it, the API iam not sure has a user

People who have no intend to use the API or SDR or implement either
should not represent 99% of whom approv / reject the code
This is a problem, because it leads to bad code.
The people telling me what to do dont care about the results
one day its "not external lib", then its "external lib" then its
"libavfilter" then its "not libavfilter"

Again we had 0 that is ZERO discussions about an SDR API.
where does it start ? a hw enumerate, a soapy device, a void *
representing a SDR data stream from something like soapy

soapy is full of bugs, for the code to work we need to know
where the data came from and we need to interact with the hw
should we provide a layer over all of libsoapy ?
should we support only libsoapy and take a device from libsoapy
as input
should we have a generic input support that libsoapy is one of several
options ?

I cannot design this API with this. because 3 out of 4
choices will get attacked and blocked if not all 4, if someone just
implements it.
because people are unwilling to think about anything they just think
they know how it must be done and they dont discuss anything they just
demand and attack and wait how the next patchset looks. Eventually
everyone then looses interrest and a patchset goes through but thats
not good design.
So again, IMHO people should help design and implement this API
if they want an API.
If i have to design an API by trial and error until it gets no
unspecific objections by people not interrested in using it
thats not going to be an API that anyone will want to use.

thx

[...]
Michael Niedermayer Aug. 2, 2023, 2:26 p.m. UTC | #44
On Wed, Aug 02, 2023 at 09:12:14AM -0500, Brad Isbell wrote:
> As a frequent FFmpeg user, and an occasional RTL-SDR user, the major
> tradeoff for me is in the size of FFmpeg binaries vs. features.  I
> agree with Jean-Baptiste that if this were an optional library to be
> added to the build, then that resolves any issues I might have as a
> user.

The libraries should be split into runtime loadable plugins
Not only would that make tools alot smaller it also would allow
development of code available in ffmpeg that is maintained outside
FFmpeg.

I suggested this previosuly, it is of course not a "simple" thing
to do.

thx

[...]
Nicolas George Aug. 2, 2023, 2:30 p.m. UTC | #45
Michael Niedermayer (12023-08-02):
> The libraries should be split into runtime loadable plugins
> Not only would that make tools alot smaller it also would allow
> development of code available in ffmpeg that is maintained outside
> FFmpeg.
> 
> I suggested this previosuly, it is of course not a "simple" thing
> to do.

No, it would be a terrible mistake.

And mostly, people who suggest or demand that do it based on
misconceptions about how linking works and/or have no actual scenario
where that would help.

But this is another discussion entirely. For this discussion, it is
enough that the libavradio device is just another device with one or a
few source files enabled by the build system, and that disabling it is
just a “--disable-” away.

Regards,
Jean-Baptiste Kempf Aug. 2, 2023, 2:44 p.m. UTC | #46
On Wed, 2 Aug 2023, at 16:20, Michael Niedermayer wrote:
> There are multiple problems but the real problem is that
> How many people discuss an SDR API ? (0)
> How many people propose an SDR API ? (0)

Did you ask people to do that?

> How many people say what they want an SDR API to be able to do ? (0)

> Again we had 0 that is ZERO discussions about an SDR API.
> where does it start ? a hw enumerate, a soapy device, a void *
> representing a SDR data stream from something like soapy

Just enough to integrate into AVInputFormat and libavformat + libavdevice.
Propose something and you will get more feedback

Then, the API will evolve into something better in v2.


jb
Cosmin Stejerean Aug. 2, 2023, 3:46 p.m. UTC | #47
> On Aug 2, 2023, at 7:30 AM, Nicolas George <george@nsup.org> wrote:
> 
> Michael Niedermayer (12023-08-02):
>> The libraries should be split into runtime loadable plugins
>> Not only would that make tools alot smaller it also would allow
>> development of code available in ffmpeg that is maintained outside
>> FFmpeg.
>> 
>> I suggested this previosuly, it is of course not a "simple" thing
>> to do.
> 
> No, it would be a terrible mistake.
> 
> And mostly, people who suggest or demand that do it based on
> misconceptions about how linking works and/or have no actual scenario
> where that would help.
> 
> But this is another discussion entirely.

This indeed feels like a separate discussion, but should we want to have that discussion I'd be happy to both provide some use cases as well as contribute code to facilitate the implementation. 

My understanding however is that the community is opposed to dynamically loaded plugins on principle, because it would make it easier to distribute proprietary plugins and sidestep the intent of the copyleft licensing.

- Cosmin
Tomas Härdin Aug. 3, 2023, 11:38 a.m. UTC | #48
sön 2023-07-30 klockan 15:04 +0200 skrev Nicolas George:
> Michael's code seems pretty self-contained to me.
> 
> And once again:
> 
> *** IT DOES NOT HAVE TO BE COMPLETE TO BE USEFUL. ***

I thought of another thing that bears mentioning: Michael has expressed
interest in implementing DAB. This carries with it two problems:

* Each DAB ensemble is an MPEG-TS stream
* There can be more than one ensemble on air

The first means mere demodulation is not enough - MPEG-TS must also be
implemented somehow. This likely means a dependency on lavf, assuming
we are not so insane as to have two independent MPEG-TS
implementations. There might also be an impedance mismatch due to lavf
pulling bytes from avio. There's no way to "push" bytes to a demuxer.
Synchronization may be an issue, though I admit I'm not 100% sure here.
Perhaps the device can pretend to be a protocol, entailing even tighter
coupling with lavf? Also I don't think registering protocols from
outside is allowed.

The second means that if such a DAB device is to work similar to the FM
demodulator handling multiple stations, then somehow multiple MPEG-TS
streams have to be dealt with. AFAIK lavd cannot do this. Merging MPEG-
TS streams might be tempting, but is not guaranteed to work I think.

I still don't understand why this must live in lavd rather than having
a separate program that does this and does it well. There is useful DSP
code in libav* that can then be motivated breaking out into a separate
library.

/Tomas
Nicolas George Aug. 3, 2023, 1:25 p.m. UTC | #49
Tomas Härdin (12023-07-31):
> As far as I recall libxml2 does not enable the fancier features of XML
> unless told to do so. And if it can't disable things like DTD then a
> ticket should be opened with them to make that possible.

You are missing the point: even if all these features are entirely
disabled (which we cannot be really sure), the code and data structure
have to be designed to make them possible. That means significantly more
complex code, much more prone to bugs, including security-relevant.

> It is foolish to spread scarce developer time more thinly.

For that, see below.

> It almost certainly means worse security, not better.

I am quite sure your estimation in this is wrong.

> The same goes for all things that FFmpeg reimplements. HTTP has already
> been mentioned. How many developer hours have been wasted on it when
> libcurl could be used instead, and a fraction of those hours going to
> improving it rather than a duplicate implementation?
> 
> I have been accused of being a "bean counter". But what are these beans
> that I count? They are developer time, the sole source of value of the
> free software movement as a whole. When I see things like HTTP or MXF
> being reimplemented I don't see features. I see liabilities.

You are neglecting a very important point here:

The time of other people is not yours to count.

You are not a boss directing the time of your employees towards the task
most profitable for you. Michael is not hacking software defined radio
to be profitable for somebody, he is having fun with it (probably
because he recently got his hands on the hardware). And I want to write
a <foo bar="qux"> parser because it is an interesting challenge. But
since Michael is a very talented hacker, the result of he having fun
ends up being code that is in some way already better than existing
alternatives.

As a member of a community project, you do not have the authority to
choose what other developers work on. The only authority you have is to
decide whether you will welcome the fruit of their work as an useful new
feature (while being vigilant about code quality) or whether you will be
so annoying about it that they give up trying to contribute to FFmpeg.

As of now, you seem to be making the wrong choice.

And I can tell you about my own situation: for several months now, the
attitude of some developers here, including you very strongly, has
mostly disgusted me from contributing to FFmpeg.

The stupid farmer kills the goose with the golden eggs by opening up her
belly. The smart farmer kills the goose with the golden eggs by trying
to force her to lay on a schedule.

> Layering is not an end in itself as you rightfully point out. It is a
> tool. To what end?

> In the free software world we don't layer and segregate things for no
> reason. We do it so that programs can interact with each other through
> standardized interfaces. The effect is a comedy of the commons. More
> can be done with less labour. For an FM receiver program the
> appropriate interfaces are ALSA, PulseAudio and/or JACK. That way its
> audio can be piped to many programs.

As you point: layering is not an end. “The scope” is not the reason, it
is only a quick summary of the reasons when they are obvious and we all
agree.

So please stop invoking “the scope” as a reason.

Second, layering is indeed something to wish for in a complex project,
but it has to come organically, it has to appear progressively as the
code becomes more complex and the useful boundaries and interfaces
appear.

When people start with layering, the result looks like the OSI model for
network stacks: it makes a few nice paragraphs in textbooks and is
completely worthless in practice.

> It is true that we can add more features, and it is also certainly true
> that these are useful for a non-empty set of users. But is it a good
> use of scarce developer time? Were SDR limited to only Michael's time
> then there would be no problem. But it isn't. It unavoidably touches
> many other parts of the code, as we are already seeing.

It is the second time you say this, and it is the second time I have to
tell you: no, it is not true at all.

We are seeing exactly the opposite: Michael's code is big, but it is
self-contained and completely optional.

Furthermore, it is not wasting any developer time. Only these sterile
objections are wasting precious time.
Nicolas George Aug. 3, 2023, 1:29 p.m. UTC | #50
Tomas Härdin (12023-08-03):
> I thought of another thing that bears mentioning: Michael has expressed
> interest in implementing DAB. This carries with it two problems:
> 
> * Each DAB ensemble is an MPEG-TS stream
> * There can be more than one ensemble on air
> 
> The first means mere demodulation is not enough - MPEG-TS must also be
> implemented somehow. This likely means a dependency on lavf, assuming
> we are not so insane as to have two independent MPEG-TS
> implementations. There might also be an impedance mismatch due to lavf
> pulling bytes from avio. There's no way to "push" bytes to a demuxer.
> Synchronization may be an issue, though I admit I'm not 100% sure here.
> Perhaps the device can pretend to be a protocol, entailing even tighter
> coupling with lavf? Also I don't think registering protocols from
> outside is allowed.
> 
> The second means that if such a DAB device is to work similar to the FM
> demodulator handling multiple stations, then somehow multiple MPEG-TS
> streams have to be dealt with. AFAIK lavd cannot do this. Merging MPEG-
> TS streams might be tempting, but is not guaranteed to work I think.

Or maybe Michael, being a very skilled hacker, will find a smart
solution that will make it work without code duplication.

You do not know what code he will submit. Why waste time speculating and
discussing nightmare scenarios that will probably not happen on this
mailing-list?


> I still don't understand why this must live in lavd rather than having
> a separate program that does this and does it well. There is useful DSP
> code in libav* that can then be motivated breaking out into a separate
> library.

Oh, yes, great idea! More administrative bloat.

You were complaining about wasting precious developer time on useless
tasks, you should start by yourself: wasting precious developer time on
maintaining extra build systems and packaging.
Michael Niedermayer Aug. 3, 2023, 3:40 p.m. UTC | #51
On Wed, Aug 02, 2023 at 03:46:29PM +0000, Cosmin Stejerean wrote:
> 
> 
> > On Aug 2, 2023, at 7:30 AM, Nicolas George <george@nsup.org> wrote:
> > 
> > Michael Niedermayer (12023-08-02):
> >> The libraries should be split into runtime loadable plugins
> >> Not only would that make tools alot smaller it also would allow
> >> development of code available in ffmpeg that is maintained outside
> >> FFmpeg.
> >> 
> >> I suggested this previosuly, it is of course not a "simple" thing
> >> to do.
> > 
> > No, it would be a terrible mistake.
> > 
> > And mostly, people who suggest or demand that do it based on
> > misconceptions about how linking works and/or have no actual scenario
> > where that would help.
> > 
> > But this is another discussion entirely.
> 
> This indeed feels like a separate discussion, but should we want to have that discussion I'd be happy to both provide some use cases as well as contribute code to facilitate the implementation. 
> 

> My understanding however is that the community is opposed to dynamically loaded plugins on principle, because it would make it easier to distribute proprietary plugins and sidestep the intent of the copyleft licensing.

I dont know if there is opposition or just inertia and more sexy things to work on
but if theres fear of proprietary plugins just do this:

1. give the plugin a license field
2. check that the license field matches a GPL compatible license before loading

thx

[...]
Michael Niedermayer Aug. 3, 2023, 5:45 p.m. UTC | #52
On Wed, Aug 02, 2023 at 04:44:14PM +0200, Jean-Baptiste Kempf wrote:
> On Wed, 2 Aug 2023, at 16:20, Michael Niedermayer wrote:
> > There are multiple problems but the real problem is that
> > How many people discuss an SDR API ? (0)
> > How many people propose an SDR API ? (0)
> 
> Did you ask people to do that?
> 
> > How many people say what they want an SDR API to be able to do ? (0)
> 
> > Again we had 0 that is ZERO discussions about an SDR API.
> > where does it start ? a hw enumerate, a soapy device, a void *
> > representing a SDR data stream from something like soapy
> 
> Just enough to integrate into AVInputFormat and libavformat + libavdevice.
> Propose something and you will get more feedback

well, i did with all the patches i posted over the last 2 months
and what we now have in the libavradio repository (which equals these patches)

Theres libsoapy (100% external to us) which gives us device
enumeration, option enumeration and a path from a opened device to a
"IQ" stream of "radio frequency" samples
that is interfaced with by a AVInputFormat demuxer / input format and produces
AVPackets (raw audio and in the future for DAB, mp2 & AAC)

I have proposed 2 choices here
1. have this API in a separate library (libavradio)
2. have it in libavdevice like other input devices

The only comment i remember was that MPEG-TS would
cause problems (i think multiple people mentioned that)

The rest of this mail thus talks only about the MPEG-TS case because
no other issue with using the existing API was raised.


There are 2 things DAB and DVB both use mpeg ts

if i implement DAB fully without external libs, i can treat mpeg-ts
like the previous layers of modulations and error correction and
just remove it. (I probably will wakeup with a stake through my heart
surrounded by some broadcast guild) but theres no technical issue here

if OTOH i implement DAB through an external lib we get AAC frames
and never even see the MPEG-TS (that at least according to the
documentation i read). So these do teh same thing, they drop MPEG-TS
as soon as possible.
DAB thus has no MPEG-TS related issue

Now DVB (if i understand everything correctly)
the most popular SDR device AFAIK are the cheap RTLSDR sticks
they support DVB only thorugh a seperate hardware path and not in SDR
mode. The bandwidth in SDR mode is not big enough for DVB.
What this means is the majority of people will either use such a stick
in "DVB" mode for DVB which provides mpeg-ts from the kernel and no vissible "SDR"
or in "SDR" mode with no DVB so no question about mpeg-ts either

To really hit a problem with mpeg-ts we first needs a SDR device capable to
return the needed bandwidth (thats not the cheapest solution for the end user
so I question a bit how many users we have here) then we would need to
write a implementation of DVB demodulation (noone plans to implement that
AFAIK, i certainly dont plan to)
and then we would have a MPEG-TS stream with probably multiple programs
and multiple audio and video streams in it and that depending on
what parts are being demodulated.
We have other demuxers which handle MPEG-TS internally. So it can still
be done, if needed


To me the obvious solution here is just to not support DVB if people
want MPEG-TS from DVB
* It wont work with the cheap sticks
* It would be alot of work to implement the DVB demodulation
* It doesnt fit very nicely in the architecture and a architecture
  in which it fits will be messy and complex
* The kernel has a interface for it already AFAIK

and here we end, where we started, with my simple minded demuxer and input
device either in libavradio lib or in libavdevice&libavformat.
If someone wants to do DVB in the future she would have to change the
architecture or accept that no MPEG-TS will come out but theres no
"old API" that has to go through a deprecation cycle as its just the
AVInputFormat stuff.

Are people suggesting we design a new API around MPEG-TS even though noone
will implement anything that returns MPEG-TS and has no plans to implement that
even in the distant future ?

It seems a strange design goal to me and iam not even sure thats what people
ask for?

To me the input device API is covering everything you can do with this
If someone wants a different intermediate API, send a patch, i just dont
understand the issue that is supposed to fix.
It seems a bit like "hate" for the input device API, as in
"i want to use it but i sweared an oath not to use libavdevice APIs"

thx

[...]
Kieran Kunhya Aug. 3, 2023, 6:24 p.m. UTC | #53
>
>
> There are 2 things DAB and DVB both use mpeg ts
>

DAB does not use mpegts. It has several layers of it's own framing.

Kieran

>
Michael Niedermayer Aug. 3, 2023, 7:25 p.m. UTC | #54
On Thu, Aug 03, 2023 at 02:24:04PM -0400, Kieran Kunhya wrote:
> >
> >
> > There are 2 things DAB and DVB both use mpeg ts
> >
> 
> DAB does not use mpegts. It has several layers of it's own framing.

Well, i stand corrected then. I saw it on the ML and in some spec but that
was about IP data in DAB or something it seems.

but thats a good thing, because if the framing used is not MPEG-TS
there will probably be noone objecting to it being removed and not
output.

thx

[...]
Kieran Kunhya Aug. 3, 2023, 8:04 p.m. UTC | #55
On Thu, 3 Aug 2023, 15:25 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> On Thu, Aug 03, 2023 at 02:24:04PM -0400, Kieran Kunhya wrote:
> > >
> > >
> > > There are 2 things DAB and DVB both use mpeg ts
> > >
> >
> > DAB does not use mpegts. It has several layers of it's own framing.
>
> Well, i stand corrected then. I saw it on the ML and in some spec but that
> was about IP data in DAB or something it seems.
>
> but thats a good thing, because if the framing used is not MPEG-TS
> there will probably be noone objecting to it being removed and not
> output.
>

What does this sentence even mean? The framing is there for a reason (to
delimit programs amongst other things). You can't just remove it. It has
layers that some users will want.

Kieran

>
Tomas Härdin Aug. 3, 2023, 8:50 p.m. UTC | #56
tor 2023-08-03 klockan 15:25 +0200 skrev Nicolas George:
> Tomas Härdin (12023-07-31):
> > As far as I recall libxml2 does not enable the fancier features of
> > XML
> > unless told to do so. And if it can't disable things like DTD then
> > a
> > ticket should be opened with them to make that possible.
> 
> You are missing the point: even if all these features are entirely
> disabled (which we cannot be really sure), the code and data
> structure
> have to be designed to make them possible.

The IMF code uses libxml2 successfully already. I'm not a huge fan of
IMF in lavf tbh since it borders on business logic, but at least we're
leveraging existing code to support it

> > It almost certainly means worse security, not better.
> 
> I am quite sure your estimation in this is wrong.

If you think libxml2's test suite is insufficient then open a ticket
with them about it. As far as I can tell it is comprehensive. One
improvement might be to make use of formal methods to prove code
correctness.


> You are not a boss directing the time of your employees towards the
> task
> most profitable for you. Michael is not hacking software defined
> radio
> to be profitable for somebody, he is having fun with it (probably
> because he recently got his hands on the hardware). And I want to
> write
> a <foo bar="qux"> parser because it is an interesting challenge.

Interesting challenges for you are maintenance burdens for everyone
else, and therefore appropriating part of their time.

/Tomas
Michael Niedermayer Aug. 4, 2023, 5:09 p.m. UTC | #57
On Thu, Aug 03, 2023 at 04:04:23PM -0400, Kieran Kunhya wrote:
> On Thu, 3 Aug 2023, 15:25 Michael Niedermayer, <michael@niedermayer.cc>
> wrote:
> 
> > On Thu, Aug 03, 2023 at 02:24:04PM -0400, Kieran Kunhya wrote:
> > > >
> > > >
> > > > There are 2 things DAB and DVB both use mpeg ts
> > > >
> > >
> > > DAB does not use mpegts. It has several layers of it's own framing.
> >
> > Well, i stand corrected then. I saw it on the ML and in some spec but that
> > was about IP data in DAB or something it seems.
> >
> > but thats a good thing, because if the framing used is not MPEG-TS
> > there will probably be noone objecting to it being removed and not
> > output.
> >
> 
> What does this sentence even mean?

> The framing is there for a reason (to
> delimit programs amongst other things). You can't just remove it. It has
> layers that some users will want.

Everything is there for a reason.
Every part of mp4 has a use, still we extract the data and setup various
structs like AVStream, AVPacket, AVProgram and so on.
We do not return raw mp4/mov atoms
the seperation between programs in a stream of bits/bytes looses meaning
once the frames are in AVPackets with AVStream/AVProgram.
If there is more data in any framing that people want, theres a wide range
of ways to preserve and export that data.
OTOH outputting AAC in TS or AAC is other framing is painfull to handle
especially when it is muxed into something again. because it then needs
the right framing and even if it comes in as DAB framing and the output
wants DAB framing, it is unlikely everything in the framing will be correct
for the output.
The same is true for TS. I surely can take raw TS from 3 programs but if
i just take these and concatenate them into something that suppports TS
thats quite likely going to blow up somehow.
All this framing stuff should IMHO be "removed" on the demuxer side
usefull data be extracted and properly exported. And if anything
on the muxing side needs something similar it needed to rebuild it all.

I may be missing something but i dont think the raw framing is too usefull
to the user.

thx

[...]
Nicolas George Aug. 4, 2023, 5:35 p.m. UTC | #58
Michael Niedermayer (12023-08-04):
> Everything is there for a reason.
> Every part of mp4 has a use, still we extract the data and setup various
> structs like AVStream, AVPacket, AVProgram and so on.
> We do not return raw mp4/mov atoms
> the seperation between programs in a stream of bits/bytes looses meaning
> once the frames are in AVPackets with AVStream/AVProgram.
> If there is more data in any framing that people want, theres a wide range
> of ways to preserve and export that data.
> OTOH outputting AAC in TS or AAC is other framing is painfull to handle
> especially when it is muxed into something again. because it then needs
> the right framing and even if it comes in as DAB framing and the output
> wants DAB framing, it is unlikely everything in the framing will be correct
> for the output.
> The same is true for TS. I surely can take raw TS from 3 programs but if
> i just take these and concatenate them into something that suppports TS
> thats quite likely going to blow up somehow.
> All this framing stuff should IMHO be "removed" on the demuxer side
> usefull data be extracted and properly exported. And if anything
> on the muxing side needs something similar it needed to rebuild it all.
> 
> I may be missing something but i dont think the raw framing is too usefull
> to the user.

I recommend you do what feels most simple, or most elegant, or most
logical, whichever feels right.

If somebody else, or you later, find a use for the framing, the code
that removes it can be turned into code that extract information from it
or reshape it. If and when that happens is the good time to figure out
how to bring that information to the user, because that will be when
what is necessary will be known.

This is why the demands that you design a clean API first are absurd: at
this point, you do not know exactly where this code is going, what kind
of information or control you will need to expose. All this depends on
which direction the codes takes, which in turns depends on you
inspiration.

And as the code progresses, the necessary API will emerge, and at one
point it will be just a matter of thinking on it carefully to cut it
cleanly.

I suppose this is what the buzzword-living industry calls “agile
programming”. But the industry cannot do it right because it needs
return on investment quick. Only a real Libre Software project like
FFmpeg can do that.

Regards,
Kieran Kunhya Aug. 4, 2023, 11:17 p.m. UTC | #59
On Fri, 4 Aug 2023, 13:35 Nicolas George, <george@nsup.org> wrote:

> Michael Niedermayer (12023-08-04):
> > Everything is there for a reason.
> > Every part of mp4 has a use, still we extract the data and setup various
> > structs like AVStream, AVPacket, AVProgram and so on.
> > We do not return raw mp4/mov atoms
> > the seperation between programs in a stream of bits/bytes looses meaning
> > once the frames are in AVPackets with AVStream/AVProgram.
> > If there is more data in any framing that people want, theres a wide
> range
> > of ways to preserve and export that data.
> > OTOH outputting AAC in TS or AAC is other framing is painfull to handle
> > especially when it is muxed into something again. because it then needs
> > the right framing and even if it comes in as DAB framing and the output
> > wants DAB framing, it is unlikely everything in the framing will be
> correct
> > for the output.
> > The same is true for TS. I surely can take raw TS from 3 programs but if
> > i just take these and concatenate them into something that suppports TS
> > thats quite likely going to blow up somehow.
> > All this framing stuff should IMHO be "removed" on the demuxer side
> > usefull data be extracted and properly exported. And if anything
> > on the muxing side needs something similar it needed to rebuild it all.
> >
> > I may be missing something but i dont think the raw framing is too
> usefull
> > to the user.
>
> I recommend you do what feels most simple, or most elegant, or most
> logical, whichever feels right.
>
> If somebody else, or you later, find a use for the framing, the code
> that removes it can be turned into code that extract information from it
> or reshape it. If and when that happens is the good time to figure out
> how to bring that information to the user, because that will be when
> what is necessary will be known.
>

Literally in this thread someone has countered all your points by wanting
TCP replay (a form of framing). If you design a bad API for a simple case,
the edge use cases (that have a tendency to make it into FFmpeg) will
immediately need hacks to support.

Plenty of examples of this such as wrapped_avframe.

Kieran

>
Michael Niedermayer Aug. 5, 2023, 6:55 p.m. UTC | #60
Hi

replying to the other question too

On Wed, Aug 02, 2023 at 04:44:14PM +0200, Jean-Baptiste Kempf wrote:
> On Wed, 2 Aug 2023, at 16:20, Michael Niedermayer wrote:
> > There are multiple problems but the real problem is that
> > How many people discuss an SDR API ? (0)
> > How many people propose an SDR API ? (0)
> 
> Did you ask people to do that?

yes, multiple times.
Also normally patch objections come with a path forward, that was not
the case here.

The first proposal was a simple demuxer in libavformat which used libsoapy
That was objected to

The second proposal was a simple demuxer in libavformat and a input device in libavdevice which used libsoapy
That was objected to

The third proposal moved the simple demuxer and input device to libavradio
That was accepted, but then the build system changes where objected to
so we cannot link to that

The forth proposal moves the simple demuxer and input device back out of
libavradio (as we cannot link to it without build system changes)
this was not objected to but the unrelated bugfixes after that where objected to

There is the general theme that a intermediate API should be added but
with apparently noone who subscribes to this suggestion knowing or caring how
to do that.

libsoapy is the external library used by the input device code
on top of the hw independant demuxer code. <-- this is a terse
description of what we have ATM

Is what you ask for, that I develop a general purpose SDR library ?
Because i cannot think of anything else that could reasonbly be
meant by "API" here.

Now please think about this for a moment
i should write a general purpose SDR library to be "allowed" to add a SDR module to ffmpeg ?
You compared this to libswresample and libswscale
but a general purpose SDR library is more like a general purpose multimedia library than a
general purpose audio resampler.

I dont think demanding i write a general purpose SDR library to be "allowed"
to add a SDR module to ffmpeg has a majority behind it.
This is not what people where thinking off when they suggested an API

If its not about writing a general purpose SDR libraray, then what
exactly is the suggestion ?
And also does that make sense ?

thx

[...]
Paul B Mahol Aug. 5, 2023, 7:17 p.m. UTC | #61
Your attempts to troll other developers to work on SDR/AVRadio is flawed
and disrespectful to other FFmpeg people.
Vittorio Giovara Aug. 5, 2023, 11:32 p.m. UTC | #62
On Sat, Aug 5, 2023 at 8:55 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Hi
>
> replying to the other question too
>
> On Wed, Aug 02, 2023 at 04:44:14PM +0200, Jean-Baptiste Kempf wrote:
> > On Wed, 2 Aug 2023, at 16:20, Michael Niedermayer wrote:
> > > There are multiple problems but the real problem is that
> > > How many people discuss an SDR API ? (0)
> > > How many people propose an SDR API ? (0)
> >
> > Did you ask people to do that?
>
> yes, multiple times.
> Also normally patch objections come with a path forward, that was not
> the case here.
>

Not necessarily, sometimes preventing a bad idea from happening is a
positive thing in itself, and no path forward is needed.
Tomas Härdin Aug. 6, 2023, 8:28 a.m. UTC | #63
sön 2023-08-06 klockan 01:32 +0200 skrev Vittorio Giovara:
> On Sat, Aug 5, 2023 at 8:55 PM Michael Niedermayer
> <michael@niedermayer.cc>
> wrote:
> 
> > Hi
> > 
> > replying to the other question too
> > 
> > On Wed, Aug 02, 2023 at 04:44:14PM +0200, Jean-Baptiste Kempf
> > wrote:
> > > On Wed, 2 Aug 2023, at 16:20, Michael Niedermayer wrote:
> > > > There are multiple problems but the real problem is that
> > > > How many people discuss an SDR API ? (0)
> > > > How many people propose an SDR API ? (0)
> > > 
> > > Did you ask people to do that?
> > 
> > yes, multiple times.
> > Also normally patch objections come with a path forward, that was
> > not
> > the case here.
> > 
> 
> Not necessarily, sometimes preventing a bad idea from happening is a
> positive thing in itself, and no path forward is needed.

Case in point: the recent raw prores demuxer proposal

/Tomas
Michael Niedermayer Aug. 6, 2023, 7:53 p.m. UTC | #64
Hi Vittorio

On Sun, Aug 06, 2023 at 01:32:30AM +0200, Vittorio Giovara wrote:
> On Sat, Aug 5, 2023 at 8:55 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > Hi
> >
> > replying to the other question too
> >
> > On Wed, Aug 02, 2023 at 04:44:14PM +0200, Jean-Baptiste Kempf wrote:
> > > On Wed, 2 Aug 2023, at 16:20, Michael Niedermayer wrote:
> > > > There are multiple problems but the real problem is that
> > > > How many people discuss an SDR API ? (0)
> > > > How many people propose an SDR API ? (0)
> > >
> > > Did you ask people to do that?
> >
> > yes, multiple times.
> > Also normally patch objections come with a path forward, that was not
> > the case here.
> >
> 
> Not necessarily, sometimes preventing a bad idea from happening is a
> positive thing in itself, and no path forward is needed.

That is missing that people suggest a path forward but
with too few details to easily walk that path.

thx

[...]
Rémi Denis-Courmont Aug. 7, 2023, 3:39 p.m. UTC | #65
Le sunnuntaina 6. elokuuta 2023, 22.53.23 EEST Michael Niedermayer a écrit :
> > > > Did you ask people to do that?
> > > 
> > > yes, multiple times.
> > > Also normally patch objections come with a path forward, that was not
> > > the case here.
> > 
> > Not necessarily, sometimes preventing a bad idea from happening is a
> > positive thing in itself, and no path forward is needed.
> 
> That is missing that people suggest a path forward but
> with too few details to easily walk that path.

Uh, I hate to state the patently obvious, but if "no path forward is needed", 
then there should logically be _no_ "details to walk [a] path". Conversely, if 
avradio does not belong in FFmpeg, as Kieran, Tomas and others have been 
arguing, then there is no path forward to be given on FFmpeg-devel.


And besides I don't think it's even fair to state that "too few details" were 
given. People did suggest making this a new separate project properly isolated 
from FFmpeg internals, and/or joining efforts with existing OSS SDR projects 
rather than FFmpeg. Some specific projects have even been cited.

As far as FFmpeg(-devel) is concerned, I can't think how it could/should 
reasonably get any more specific than that.
Michael Niedermayer Aug. 8, 2023, 3:22 p.m. UTC | #66
Hi

On Mon, Aug 07, 2023 at 06:39:10PM +0300, Rémi Denis-Courmont wrote:
> Le sunnuntaina 6. elokuuta 2023, 22.53.23 EEST Michael Niedermayer a écrit :
> > > > > Did you ask people to do that?
> > > > 
> > > > yes, multiple times.
> > > > Also normally patch objections come with a path forward, that was not
> > > > the case here.
> > > 
> > > Not necessarily, sometimes preventing a bad idea from happening is a
> > > positive thing in itself, and no path forward is needed.
> > 
> > That is missing that people suggest a path forward but
> > with too few details to easily walk that path.
> 
> Uh, I hate to state the patently obvious, but if "no path forward is needed", 
> then there should logically be _no_ "details to walk [a] path". Conversely, if 
> avradio does not belong in FFmpeg, as Kieran, Tomas and others have been 
> arguing, then there is no path forward to be given on FFmpeg-devel.
> 
> 
> And besides I don't think it's even fair to state that "too few details" were 
> given. People did suggest making this a new separate project properly isolated 
> from FFmpeg internals, and/or joining efforts with existing OSS SDR projects 
> rather than FFmpeg. Some specific projects have even been cited.
> 
> As far as FFmpeg(-devel) is concerned, I can't think how it could/should 
> reasonably get any more specific than that.

The saying goes, one cannot win an Argument on the Internet.
So, iam not trying to, but

IIRC, a while ago you said iam obliged to work on FFmpeg. Thats
simply not the case.

Its not an obligation but rather my choice that i like to work on
something the end user will enjoy. And the end user, in fact
more than 500 end users liked SDR in FFmpeg.
My original plan was to spend 1-2 weeks working on SDR, now
probably about 2 months passed with me spending a bit working on
SDR here and there.

I also am not obliged to do what other developers want me to do. But i have
been in this community for a very long time and have my highest respect
from the Developers in this community, even if at times we disagreed
they are all great people, and some are my friends.
And working toward a consensus everyone is happy with is
something i want whenever there is a disagreement.
On IRC what people said, and what JB said here, is that people are ok
with a SDR module in FFmpeg under some conditions.
It is these conditions that i do not fully understand, and that i
tried to understand better.

You and vittorio here seem to suggest that instead there are no
possible conditions and no path forward. Thus a fork would have to happen.
Now iam quite confident, that, thats not what people ask for.
We had a fork and i dont think we want to have a new one.

Again, i want a consensus everyone is happy with so I keep asking
what people suggest exactly.

Thanks

[...]
Paul B Mahol Aug. 8, 2023, 3:37 p.m. UTC | #67
On Tue, Aug 8, 2023 at 5:23 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Hi
>
> On Mon, Aug 07, 2023 at 06:39:10PM +0300, Rémi Denis-Courmont wrote:
> > Le sunnuntaina 6. elokuuta 2023, 22.53.23 EEST Michael Niedermayer a
> écrit :
> > > > > > Did you ask people to do that?
> > > > >
> > > > > yes, multiple times.
> > > > > Also normally patch objections come with a path forward, that was
> not
> > > > > the case here.
> > > >
> > > > Not necessarily, sometimes preventing a bad idea from happening is a
> > > > positive thing in itself, and no path forward is needed.
> > >
> > > That is missing that people suggest a path forward but
> > > with too few details to easily walk that path.
> >
> > Uh, I hate to state the patently obvious, but if "no path forward is
> needed",
> > then there should logically be _no_ "details to walk [a] path".
> Conversely, if
> > avradio does not belong in FFmpeg, as Kieran, Tomas and others have been
> > arguing, then there is no path forward to be given on FFmpeg-devel.
> >
> >
> > And besides I don't think it's even fair to state that "too few details"
> were
> > given. People did suggest making this a new separate project properly
> isolated
> > from FFmpeg internals, and/or joining efforts with existing OSS SDR
> projects
> > rather than FFmpeg. Some specific projects have even been cited.
> >
> > As far as FFmpeg(-devel) is concerned, I can't think how it could/should
> > reasonably get any more specific than that.
>
> The saying goes, one cannot win an Argument on the Internet.
> So, iam not trying to, but
>
> IIRC, a while ago you said iam obliged to work on FFmpeg. Thats
> simply not the case.
>
> Its not an obligation but rather my choice that i like to work on
> something the end user will enjoy. And the end user, in fact
> more than 500 end users liked SDR in FFmpeg.
> My original plan was to spend 1-2 weeks working on SDR, now
> probably about 2 months passed with me spending a bit working on
> SDR here and there.
>
> I also am not obliged to do what other developers want me to do. But i have
> been in this community for a very long time and have my highest respect
> from the Developers in this community, even if at times we disagreed
> they are all great people, and some are my friends.
> And working toward a consensus everyone is happy with is
> something i want whenever there is a disagreement.
> On IRC what people said, and what JB said here, is that people are ok
> with a SDR module in FFmpeg under some conditions.
> It is these conditions that i do not fully understand, and that i
> tried to understand better.
>
> You and vittorio here seem to suggest that instead there are no
> possible conditions and no path forward. Thus a fork would have to happen.
> Now iam quite confident, that, thats not what people ask for.
> We had a fork and i dont think we want to have a new one.
>
> Again, i want a consensus everyone is happy with so I keep asking
> what people suggest exactly.
>

For start, and good will, I'm willing to accept a signal of good will from
you to remove sdr files from FATE.
There is no point in discussing anything further with you until that is
done.


> Thanks
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
Rémi Denis-Courmont Aug. 8, 2023, 6:53 p.m. UTC | #68
Le tiistaina 8. elokuuta 2023, 18.22.49 EEST Michael Niedermayer a écrit :
> > > That is missing that people suggest a path forward but
> > > with too few details to easily walk that path.
> > 
> > Uh, I hate to state the patently obvious, but if "no path forward is
> > needed", then there should logically be _no_ "details to walk [a] path".
> > Conversely, if avradio does not belong in FFmpeg, as Kieran, Tomas and
> > others have been arguing, then there is no path forward to be given on
> > FFmpeg-devel.
> > 
> > 
> > And besides I don't think it's even fair to state that "too few details"
> > were given. People did suggest making this a new separate project
> > properly isolated from FFmpeg internals, and/or joining efforts with
> > existing OSS SDR projects rather than FFmpeg. Some specific projects have
> > even been cited.
> > 
> > As far as FFmpeg(-devel) is concerned, I can't think how it could/should
> > reasonably get any more specific than that.
> 
> The saying goes, one cannot win an Argument on the Internet.
> So, iam not trying to, but
> 
> IIRC, a while ago you said iam obliged to work on FFmpeg. Thats
> simply not the case.

I have made some preposterous statements in my dark past, but I am pretty sure 
that I didn't make any statement to that effect, no.

I did assert that there "are dozens of people, ostensibly including [you], 
that depend on FFmpeg being ""Serious OpenSource TM"" in some way, for their
livelihood, and millions for their computer use" in response to NG's argument 
that FFmpeg should be turned into a fun experimental research project, and 
that people who wanted to keep FFmpeg what he calls a "serious open-source 
trademark" should just fork.

> Its not an obligation but rather my choice that i like to work on
> something the end user will enjoy.

I don't think anybody denied your right to code whatever you want as a hobby. 
We object to having SDR code in FFmpeg upstream, and I personally believe that 
it would go against your own financial/business interest (c.f. quote above).

> And the end user, in fact
> more than 500 end users liked SDR in FFmpeg.

In all likelihood the vast majority of those 500 likes don't even have the 
hardware to use the SDR code, have no interests in acquiring it, and would 
like just about any new FFmpeg feature post. Without a statistically valid 
reference for comparison, that number means basically nothing.

(Also announcing a feature that is not release-ready is generally very 
inappropriate in my opinion.)

(...)
> You and vittorio here seem to suggest that instead there are no
> possible conditions and no path forward.

...within FFmpeg.

> Thus a fork would have to happen.

No. You are taking for granted that SDR belongs in FFmpeg in the first place, 
and that's exactly what people disagree with.

I don't even get what's so hard to comprehend here. Plenty of people here 
contirbute to other projects than FFmpeg, and/or have started other projects 
than FFmpeg for their other hobby coding activities. Just because you have 
personally been strongly associated with FFmpeg does not mean that everything 
you has to fit inside of it.
Michael Niedermayer Aug. 9, 2023, 3:59 p.m. UTC | #69
On Tue, Aug 08, 2023 at 09:53:11PM +0300, Rémi Denis-Courmont wrote:
> Le tiistaina 8. elokuuta 2023, 18.22.49 EEST Michael Niedermayer a écrit :
> > > > That is missing that people suggest a path forward but
> > > > with too few details to easily walk that path.
> > > 
> > > Uh, I hate to state the patently obvious, but if "no path forward is
> > > needed", then there should logically be _no_ "details to walk [a] path".
> > > Conversely, if avradio does not belong in FFmpeg, as Kieran, Tomas and
> > > others have been arguing, then there is no path forward to be given on
> > > FFmpeg-devel.
> > > 
> > > 
> > > And besides I don't think it's even fair to state that "too few details"
> > > were given. People did suggest making this a new separate project
> > > properly isolated from FFmpeg internals, and/or joining efforts with
> > > existing OSS SDR projects rather than FFmpeg. Some specific projects have
> > > even been cited.
> > > 
> > > As far as FFmpeg(-devel) is concerned, I can't think how it could/should
> > > reasonably get any more specific than that.
> > 
> > The saying goes, one cannot win an Argument on the Internet.
> > So, iam not trying to, but
> > 
> > IIRC, a while ago you said iam obliged to work on FFmpeg. Thats
> > simply not the case.
> 
> I have made some preposterous statements in my dark past, but I am pretty sure 
> that I didn't make any statement to that effect, no.

Not litterally, but i think you implied it in a reply to nicolas:
Or at least thats how i read it, maybe i just misunderstood, this is really
not important, just for completeness, here is what i refered to:

    in "Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support"
    > 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.

    FYI https://fflabs.eu/about/

thx

[...]
Paul B Mahol Aug. 9, 2023, 4:24 p.m. UTC | #70
On Wed, Aug 9, 2023 at 5:59 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Tue, Aug 08, 2023 at 09:53:11PM +0300, Rémi Denis-Courmont wrote:
> > Le tiistaina 8. elokuuta 2023, 18.22.49 EEST Michael Niedermayer a écrit
> :
> > > > > That is missing that people suggest a path forward but
> > > > > with too few details to easily walk that path.
> > > >
> > > > Uh, I hate to state the patently obvious, but if "no path forward is
> > > > needed", then there should logically be _no_ "details to walk [a]
> path".
> > > > Conversely, if avradio does not belong in FFmpeg, as Kieran, Tomas
> and
> > > > others have been arguing, then there is no path forward to be given
> on
> > > > FFmpeg-devel.
> > > >
> > > >
> > > > And besides I don't think it's even fair to state that "too few
> details"
> > > > were given. People did suggest making this a new separate project
> > > > properly isolated from FFmpeg internals, and/or joining efforts with
> > > > existing OSS SDR projects rather than FFmpeg. Some specific projects
> have
> > > > even been cited.
> > > >
> > > > As far as FFmpeg(-devel) is concerned, I can't think how it
> could/should
> > > > reasonably get any more specific than that.
> > >
> > > The saying goes, one cannot win an Argument on the Internet.
> > > So, iam not trying to, but
> > >
> > > IIRC, a while ago you said iam obliged to work on FFmpeg. Thats
> > > simply not the case.
> >
> > I have made some preposterous statements in my dark past, but I am
> pretty sure
> > that I didn't make any statement to that effect, no.
>
> Not litterally, but i think you implied it in a reply to nicolas:
> Or at least thats how i read it, maybe i just misunderstood, this is really
> not important, just for completeness, here is what i refered to:
>
>     in "Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio
> support"
>     > 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.
>
>     FYI https://fflabs.eu/about/
>
>
FYI  https://fflabs.eu/legal-mentions/

Thanks

thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Never trust a computer, one day, it may think you are the virus. -- Compn
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
Nicolas George Aug. 10, 2023, 12:39 p.m. UTC | #71
Rémi Denis-Courmont (12023-08-08):
> I have made some preposterous statements in my dark past, but I am pretty sure 
> that I didn't make any statement to that effect, no.
> 
> I did assert that there "are dozens of people, ostensibly including [you], 
> that depend on FFmpeg being ""Serious OpenSource TM"" in some way, for their
> livelihood, and millions for their computer use" in response to NG's argument 
> that FFmpeg should be turned into a fun experimental research project, and 
> that people who wanted to keep FFmpeg what he calls a "serious open-source 
> trademark" should just fork.

Not “turned into”, but restored. FFmpeg *was* a fun experimental
research project, and it was the reason it became so great: developers
then could try things that were not tried elsewhere, they were free to
take risks, to make mistakes and fix them.

And the, during the second half of 2000s decade, people like you took
more and more place, people who demanded absolute stability and rejected
all risks whatsoever. They started giving shit to Michael, then project
leader, trying to force him and everybody else to behave, according to
their own standards. They wasted the time of one of the most skilled
hackers in the field of multimedia having him perform tasks a few
baseline technicians could do.

And when it did not go as fast as they wanted, they staged a coup, with
all the terrible consequences we know.

Let me state it plain and clear:

The fact that people and companies choose to depend on FFmpeg for their
livelihood is their own problem, and their own only, it does not create
ANY OBLIGATION WHATSOEVER for FFmpeg.

It is even true for sponsors. They can gift FFmpeg hardware or money or
hosting, they can hope that FFmpeg will progress to be even more useful
to them, but FFmpeg has NO OBLIGATION WHATSOEVER to honor that hope.
(Except for tit-for-tat programs with contractual rules, like GSoC.)

If a sponsor tried to leverage their sponsoring to dictate the direction
of the project, threatening to withhold it unless they get their way,
then we should realize that sponsor is a dangerous asshole and sever all
ties with them immediately.

> No. You are taking for granted that SDR belongs in FFmpeg in the first place, 
> and that's exactly what people disagree with.

And you are taking for granted that it does not belongs in FFmpeg.

But what you refuse to realize is that it is only an opinion, shared by
you and a few “people”, backed by zero actual arguments.

As such, your opinion is worthy of very little consideration, a lot much
less than the opposition opinion that is actually backed by the
enthusiasm of users.
Vittorio Giovara Aug. 10, 2023, 2:58 p.m. UTC | #72
On Thu, Aug 10, 2023 at 2:39 PM Nicolas George <george@nsup.org> wrote:

> > No. You are taking for granted that SDR belongs in FFmpeg in the first
> place,
> > and that's exactly what people disagree with.
>
> And you are taking for granted that it does not belongs in FFmpeg.
>
> But what you refuse to realize is that it is only an opinion, shared by
> you and a few “people”, backed by zero actual arguments.
>
> As such, your opinion is worthy of very little consideration, a lot much
> less than the opposition opinion that is actually backed by the
> enthusiasm of users.
>

this is not the way to talk to a fellow developer with plenty of open
source contributions in this and many other repositories
you need to consider that not everybody has the energy or will to write
lengthy paragraphs that just reiterate the same points and do not move the
needle one way or another - in other words, your argument is not the
correct one just because it's the longest
and please try writing with more respect, the "people" (leaving air quotes
verbatim) you refer to is basically the entire community, versus you and
Michael
James Almer Aug. 10, 2023, 3:01 p.m. UTC | #73
On 8/10/2023 9:39 AM, Nicolas George wrote:
> Rémi Denis-Courmont (12023-08-08):
>> No. You are taking for granted that SDR belongs in FFmpeg in the first place,
>> and that's exactly what people disagree with.
> 
> And you are taking for granted that it does not belongs in FFmpeg.
> 
> But what you refuse to realize is that it is only an opinion, shared by
> you and a few “people”, backed by zero actual arguments.
> 
> As such, your opinion is worthy of very little consideration, a lot much
> less than the opposition opinion that is actually backed by the
> enthusiasm of users.

This is absolutely unacceptable, Nicolas.
Jean-Baptiste Kempf Aug. 10, 2023, 3:43 p.m. UTC | #74
On Thu, 10 Aug 2023, at 14:39, Nicolas George wrote:
>> livelihood, and millions for their computer use" in response to NG's argument 
>> that FFmpeg should be turned into a fun experimental research project, and 
>> that people who wanted to keep FFmpeg what he calls a "serious open-source 
>> trademark" should just fork.
>
> Not “turned into”, but restored. FFmpeg *was* a fun experimental
> research project, and it was the reason it became so great: developers
> then could try things that were not tried elsewhere, they were free to
> take risks, to make mistakes and fix them.
>
> And the, during the second half of 2000s decade, people like you took
> more and more place, people who demanded absolute stability and rejected
> all risks whatsoever.

You mean, like every project that starts small and gets bigger and reaches maturity stage?

> But what you refuse to realize is that it is only an opinion, shared by
> you and a few “people”, backed by zero actual arguments.

The issue here, is that you are in minority about your vision of FFmpeg, as a fun and experimental project.
You screaming louder does not change this reality.

If you disagree, just get a vote from all people who have commit access, and you will see.
Tomas Härdin Aug. 10, 2023, 6:39 p.m. UTC | #75
tor 2023-08-10 klockan 14:39 +0200 skrev Nicolas George:
> If a sponsor tried to leverage their sponsoring to dictate the
> direction
> of the project, threatening to withhold it unless they get their way,
> then we should realize that sponsor is a dangerous asshole and sever
> all
> ties with them immediately.

This sure sounds familiar. And I'm not talking about Remlab Tmi.

/Tomas
Michael Niedermayer Aug. 12, 2023, 5:12 p.m. UTC | #76
On Thu, Aug 10, 2023 at 04:58:37PM +0200, Vittorio Giovara wrote:
> On Thu, Aug 10, 2023 at 2:39 PM Nicolas George <george@nsup.org> wrote:
> 
> > > No. You are taking for granted that SDR belongs in FFmpeg in the first
> > place,
> > > and that's exactly what people disagree with.
> >
> > And you are taking for granted that it does not belongs in FFmpeg.
> >
> > But what you refuse to realize is that it is only an opinion, shared by
> > you and a few “people”, backed by zero actual arguments.
> >
> > As such, your opinion is worthy of very little consideration, a lot much
> > less than the opposition opinion that is actually backed by the
> > enthusiasm of users.
> >
> 
> this is not the way to talk to a fellow developer with plenty of open
> source contributions in this and many other repositories
> you need to consider that not everybody has the energy or will to write
> lengthy paragraphs that just reiterate the same points and do not move the
> needle one way or another - in other words, your argument is not the
> correct one just because it's the longest
> and please try writing with more respect, the "people" (leaving air quotes
> verbatim) you refer to is basically the entire community, versus you and
> Michael

I dont really want to reply, but as you mention me explicitly, i also dont
want to let this stand.

I oppose the insulting tone of the mail you replied to, same as you oppose
it.

About something that only i and Nicolas support and everyone is against.
I do not know what you talk about here. I made no public statement of
supporting anything. I dont think you should claim I do.

thx

[...]
diff mbox series

Patch

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6130fd06fc..e9fbc8b636 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -95,6 +95,10 @@ 
 
 #include "libavdevice/avdevice.h"
 
+#if CONFIG_AVRADIO
+#include "libavradio/avradio.h"
+#endif
+
 #include "libswresample/swresample.h"
 
 #include "libavfilter/avfilter.h"
@@ -1331,6 +1335,9 @@  int main(int argc, char **argv)
 
 #if CONFIG_AVDEVICE
     avdevice_register_all();
+#endif
+#if CONFIG_AVRADIO
+    avradio_register_all();
 #endif
     avformat_network_init();
 
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 5212ad053e..f2e70b2de6 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -45,6 +45,9 @@ 
 #include "libavutil/bprint.h"
 #include "libavformat/avformat.h"
 #include "libavdevice/avdevice.h"
+#if CONFIG_AVRADIO
+#include "libavradio/avradio.h"
+#endif
 #include "libswscale/swscale.h"
 #include "libavutil/opt.h"
 #include "libavcodec/avfft.h"
@@ -3651,6 +3654,9 @@  int main(int argc, char **argv)
     /* register all codecs, demux and protocols */
 #if CONFIG_AVDEVICE
     avdevice_register_all();
+#endif
+#if CONFIG_AVRADIO
+    avradio_register_all();
 #endif
     avformat_network_init();
 
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index a39185f6fe..51a0c2483b 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -56,6 +56,9 @@ 
 #include "libavutil/timestamp.h"
 #include "libavdevice/avdevice.h"
 #include "libavdevice/version.h"
+#if CONFIG_AVRADIO
+#include "libavradio/avradio.h"
+#endif
 #include "libswscale/swscale.h"
 #include "libswscale/version.h"
 #include "libswresample/swresample.h"
@@ -4109,6 +4112,9 @@  int main(int argc, char **argv)
 #if CONFIG_AVDEVICE
     avdevice_register_all();
 #endif
+#if CONFIG_AVRADIO
+    avradio_register_all();
+#endif
 
     show_banner(argc, argv, options);
     ret = parse_options(NULL, argc, argv, options, opt_input_file);
diff --git a/fftools/opt_common.c b/fftools/opt_common.c
index 913932c914..f556d95afe 100644
--- a/fftools/opt_common.c
+++ b/fftools/opt_common.c
@@ -51,6 +51,11 @@ 
 #include "libavdevice/avdevice.h"
 #include "libavdevice/version.h"
 
+#if CONFIG_AVRADIO
+#include "libavradio/avradio.h"
+#include "libavradio/version.h"
+#endif
+
 #include "libavfilter/avfilter.h"
 #include "libavfilter/version.h"
 
@@ -187,6 +192,9 @@  static void print_all_libs_info(int flags, int level)
     PRINT_LIB_INFO(avutil,     AVUTIL,     flags, level);
     PRINT_LIB_INFO(avcodec,    AVCODEC,    flags, level);
     PRINT_LIB_INFO(avformat,   AVFORMAT,   flags, level);
+#if CONFIG_AVRADIO
+    PRINT_LIB_INFO(avradio,    AVRADIO,    flags, level);
+#endif
     PRINT_LIB_INFO(avdevice,   AVDEVICE,   flags, level);
     PRINT_LIB_INFO(avfilter,   AVFILTER,   flags, level);
     PRINT_LIB_INFO(swscale,    SWSCALE,    flags, level);
@@ -844,6 +852,13 @@  static int is_device(const AVClass *avclass)
     return AV_IS_INPUT_DEVICE(avclass->category) || AV_IS_OUTPUT_DEVICE(avclass->category);
 }
 
+static int is_radio(const AVClass *avclass)
+{
+    if (!avclass)
+        return 0;
+    return avclass->category == AV_CLASS_CATEGORY_RADIO_INPUT;
+}
+
 static int show_formats_devices(void *optctx, const char *opt, const char *arg, int device_only, int muxdemuxers)
 {
     void *ifmt_opaque = NULL;
@@ -851,12 +866,13 @@  static int show_formats_devices(void *optctx, const char *opt, const char *arg,
     void *ofmt_opaque = NULL;
     const AVOutputFormat *ofmt = NULL;
     const char *last_name;
-    int is_dev;
+    int is_dev, is_rad;
+    const char *name[3] = {"File formats:", "Devices:", "Radios:"};
 
     printf("%s\n"
            " D. = Demuxing supported\n"
            " .E = Muxing supported\n"
-           " --\n", device_only ? "Devices:" : "File formats:");
+           " --\n", name[device_only]);
     last_name = "000";
     for (;;) {
         int decode = 0;
@@ -868,7 +884,9 @@  static int show_formats_devices(void *optctx, const char *opt, const char *arg,
             ofmt_opaque = NULL;
             while ((ofmt = av_muxer_iterate(&ofmt_opaque))) {
                 is_dev = is_device(ofmt->priv_class);
-                if (!is_dev && device_only)
+                if (!is_dev && device_only == 1)
+                    continue;
+                if (device_only == 2)
                     continue;
                 if ((!name || strcmp(ofmt->name, name) < 0) &&
                     strcmp(ofmt->name, last_name) > 0) {
@@ -882,7 +900,10 @@  static int show_formats_devices(void *optctx, const char *opt, const char *arg,
             ifmt_opaque = NULL;
             while ((ifmt = av_demuxer_iterate(&ifmt_opaque))) {
                 is_dev = is_device(ifmt->priv_class);
-                if (!is_dev && device_only)
+                is_rad = is_radio(ifmt->priv_class);
+                if (!is_dev && device_only == 1)
+                    continue;
+                if (!is_rad && device_only == 2)
                     continue;
                 if ((!name || strcmp(ifmt->name, name) < 0) &&
                     strcmp(ifmt->name, last_name) > 0) {
@@ -927,6 +948,11 @@  int show_devices(void *optctx, const char *opt, const char *arg)
     return show_formats_devices(optctx, opt, arg, 1, SHOW_DEFAULT);
 }
 
+int show_radios(void *optctx, const char *opt, const char *arg)
+{
+    return show_formats_devices(optctx, opt, arg, 2, SHOW_DEFAULT);
+}
+
 int show_protocols(void *optctx, const char *opt, const char *arg)
 {
     void *opaque = NULL;
@@ -1335,7 +1361,7 @@  static int print_device_sources(const AVInputFormat *fmt, AVDictionary *opts)
     int ret;
     AVDeviceInfoList *device_list = NULL;
 
-    if (!fmt || !fmt->priv_class  || !AV_IS_INPUT_DEVICE(fmt->priv_class->category))
+    if (!fmt || !fmt->priv_class  || (!AV_IS_INPUT_DEVICE(fmt->priv_class->category) && fmt->priv_class->category != AV_CLASS_CATEGORY_RADIO_INPUT))
         return AVERROR(EINVAL);
 
     printf("Auto-detected sources for %s:\n", fmt->name);
@@ -1468,3 +1494,33 @@  int show_sinks(void *optctx, const char *opt, const char *arg)
     return ret;
 }
 #endif /* CONFIG_AVDEVICE */
+
+#if CONFIG_AVRADIO
+int show_radio_sources(void *optctx, const char *opt, const char *arg)
+{
+    const AVInputFormat *fmt = NULL;
+    char *dev = NULL;
+    AVDictionary *opts = NULL;
+    int ret = 0;
+    int error_level = av_log_get_level();
+
+    av_log_set_level(AV_LOG_WARNING);
+
+    if ((ret = show_sinks_sources_parse_arg(arg, &dev, &opts)) < 0)
+        goto fail;
+
+    do {
+        fmt = av_input_radio_next(fmt);
+        if (fmt) {
+            if (dev && !av_match_name(dev, fmt->name))
+                continue;
+            print_device_sources(fmt, opts);
+        }
+    } while (fmt);
+  fail:
+    av_dict_free(&opts);
+    av_free(dev);
+    av_log_set_level(error_level);
+    return ret;
+}
+#endif /* CONFIG_AVRADIO */
diff --git a/fftools/opt_common.h b/fftools/opt_common.h
index ea1d16e769..b64ab07e10 100644
--- a/fftools/opt_common.h
+++ b/fftools/opt_common.h
@@ -39,6 +39,15 @@  int show_sinks(void *optctx, const char *opt, const char *arg);
 int show_sources(void *optctx, const char *opt, const char *arg);
 #endif
 
+#if CONFIG_AVRADIO
+/**
+ * Print a listing containing autodetected sources of the input radio.
+ * Device name with options may be passed as an argument to limit results.
+ */
+int show_radio_sources(void *optctx, const char *opt, const char *arg);
+#endif
+
+
 #if CONFIG_AVDEVICE
 #define CMDUTILS_COMMON_OPTIONS_AVDEVICE                                                                                \
     { "sources"    , OPT_EXIT | HAS_ARG, { .func_arg = show_sources },                                                  \
@@ -50,6 +59,15 @@  int show_sources(void *optctx, const char *opt, const char *arg);
 #define CMDUTILS_COMMON_OPTIONS_AVDEVICE
 #endif
 
+#if CONFIG_AVRADIO
+#define CMDUTILS_COMMON_OPTIONS_AVRADIO                                                                                 \
+    { "radio_sources"    , OPT_EXIT | HAS_ARG, { .func_arg = show_radio_sources },                                      \
+      "list sources of the input device", "device" },                                                                   \
+
+#else
+#define CMDUTILS_COMMON_OPTIONS_AVRADIO
+#endif
+
 /**
  * Print the license of the program to stdout. The license depends on
  * the license of the libraries compiled into the program.
@@ -105,6 +123,13 @@  int show_demuxers(void *optctx, const char *opt, const char *arg);
  */
 int show_devices(void *optctx, const char *opt, const char *arg);
 
+/**
+ * Print a listing containing all the radios supported by the
+ * program.
+ * This option processing function does not utilize the arguments.
+ */
+int show_radios(void *optctx, const char *opt, const char *arg);
+
 /**
  * Print a listing containing all the codecs supported by the
  * program.
@@ -208,6 +233,7 @@  int opt_cpucount(void *optctx, const char *opt, const char *arg);
     { "muxers",      OPT_EXIT,             { .func_arg = show_muxers },      "show available muxers" },                 \
     { "demuxers",    OPT_EXIT,             { .func_arg = show_demuxers },    "show available demuxers" },               \
     { "devices",     OPT_EXIT,             { .func_arg = show_devices },     "show available devices" },                \
+    { "radios",      OPT_EXIT,             { .func_arg = show_radios },      "show available radios" },                 \
     { "codecs",      OPT_EXIT,             { .func_arg = show_codecs },      "show available codecs" },                 \
     { "decoders",    OPT_EXIT,             { .func_arg = show_decoders },    "show available decoders" },               \
     { "encoders",    OPT_EXIT,             { .func_arg = show_encoders },    "show available encoders" },               \
@@ -227,5 +253,6 @@  int opt_cpucount(void *optctx, const char *opt, const char *arg);
     { "cpucount",    HAS_ARG | OPT_EXPERT, { .func_arg = opt_cpucount },     "force specific cpu count", "count" },     \
     { "hide_banner", OPT_BOOL | OPT_EXPERT, {&hide_banner},     "do not show program banner", "hide_banner" },          \
     CMDUTILS_COMMON_OPTIONS_AVDEVICE                                                                                    \
+    CMDUTILS_COMMON_OPTIONS_AVRADIO                                                                                     \
 
 #endif /* FFTOOLS_OPT_COMMON_H */