Message ID | 20230722192957.703-5-michael@niedermayer.cc |
---|---|
State | New |
Headers | show |
Series | [FFmpeg-devel,1/6] configure: libavradio support | expand |
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 |
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?
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 [...]
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
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".
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. [...]
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.
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,
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 [...]
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
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
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
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.
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.
> 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
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.
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
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
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.
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
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
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 [...]
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
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.
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! [...]
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,
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
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,
вс, 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).
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
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,
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
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".
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
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". >
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.
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 [...]
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 [...]
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
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". >
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 [...]
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".
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,
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 [...]
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 [...]
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,
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
> 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
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
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.
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.
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 [...]
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 [...]
> > > 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 >
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 [...]
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 >
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
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 [...]
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,
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 >
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 [...]
Your attempts to troll other developers to work on SDR/AVRadio is flawed and disrespectful to other FFmpeg people.
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.
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
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 [...]
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.
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 [...]
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". >
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.
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 [...]
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". >
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.
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
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.
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.
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
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 --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 */