Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 > 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 > > wrote: > > > > > > > On Jul 27, 2023, at 11:36 AM, Michael Niedermayer < > > mich...@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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
On Wed, Aug 2, 2023 at 2:47 PM Michael Niedermayer 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 > wrote: > > > > > On Jul 27, 2023, at 11:36 AM, Michael Niedermayer < > mich...@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-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 wrote: > > > On Jul 27, 2023, at 11:36 AM, Michael Niedermayer > > wrote: > > > > Let me first explain what i want to provide to the user (most of this > > is already implemented, some needs more work) > > the user starts her favorite player, be that vlc, ffplay, or whatever > > chooses sdr as input device and thats all configuration she needs. > > She can select a specific driver, gain and so but she doesnt have to > > Now she only needs 2 buttons, seek forward and seek backward, in > > ffplay thats the cursor keys. To select the station. > > And she sees on the screen what station that is, what song title and > > artist are playing as well as what is playing on any other FM station > > in view (that works here already in europe, for the US if it doesnt work > > > > i need a sample from dumpurl ...) > > (for non interactive tools like ffmpeg she would have to select the > > frequency she wants to listen to or all in view ...) > > > > Now gqrx needs me to manually enter the frequency, the modulation the > > device, then it still doesnt work (first one has to know why from multiple > > rtlsdr lines some dont work) and once one is through this it still > > doesnt work, all AGC methods dont work, i have to set the gain manually > > for the station i want to listen to to have acceptable quality. I do know > > but at this point we lost likely 90% of users > > > > I know this is a contentious topic, but as a heavy user of ffmpeg for both > > work and fun, and as an amateur radio user, what you describe sounds pretty > > great to me. I can definitely imagine using this for a few usecases. I get > > that other tools exist and others that know how to use those can of course > > continue to use them. I for one would definitely love to use ffmpeg > > directly if that was an option. > > > > This is not something I'd want enabled in the ffmpeg build at work due to > > the extra surface area, but assuming I can disable the sdr radio bits at > > build time for "serious" builds, and that this code is actively maintained > > and designed in a way that minimizes interference with other parts of > > ffmpeg, then it's not clear to me why there's such a strong reaction > > against having this included in ffmpeg. > > > > Because it would always give sub-optimal results at best. Iam not sure what you refer to by "it" exactly and what the alternative you compare it to are but why ? Even leaving this very generic, claiming one implementation will always give "sub-optimal results" to another does not sound like a fact based statment. Thats a bit like saying a reverse engeneered codec will always give sub optimal results to the binary original. And thats why we better should go the optimal route > > Time to implement auto-pilot into FFmpeg too. I dont know if you plan that but i dont, did not and have also not suggested that. In fact i dont even know what exactly you refer to by "auto-pilot" thx [...] -- Michael 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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
On Tue, Aug 1, 2023 at 9:51 PM Cosmin Stejerean wrote: > On Jul 27, 2023, at 11:36 AM, Michael Niedermayer > 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-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
On Jul 27, 2023, at 11:36 AM, Michael Niedermayer 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
I am going to ignore the dredging up of ancient history. On Thu, Jul 27, 2023 at 6:56 PM Nicolas George 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
On Tue, Jul 25, 2023 at 2:56 PM Nicolas George 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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. > > 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
On Tue, Jul 25, 2023 at 10:56 AM Nicolas George 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. > > 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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. 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. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Tomas Härdin (12023-07-24): > Features either are or aren't in scope. I don't see how you can > compromise on that. The scope is what we decide it is, collectively, based on arguments. Your conception of the scope is only a small part of that, and even smaller if you cannot sustain it with arguments. “I don't see how you can compromise on that” is called dogmatism and has no place in this project. The way I see it, avradio has about as much or as little its place in a project that historically contained software implementations of the major and minor multimedia codecs as hardware acceleration. Yet support for hardware acceleration has been added, to the convenience and satisfaction of everybody. > The Linux kernel also has separation of concerns. It has a concept of > userland for example, unlike say TempleOS. Not everything is in scope > for the Linux project. Yet features have repeatedly made back and forth between kernel and userland and mixed implementations, searching for the sweet spot of compromise between performance, security and convenience. Proof that “the scope”, even when there is a much more clearly delineated frontier, is fluid and a matter of compromise. If you cannot accept compromise, then your opinion should not be taken into consideration in a functioning collective project. > I have 63 forks of ffmpeg alone. I don't see the problem. I am doubtful whether this is to be considered a good thing or a bad thing, but I am rather leaning towards bad. > As for me being loudest, someone has to be. As a licensed amateur radio > operator I also happen to have domain knowledge, which is why I know > radio stuff will affect the code in profound ways, as we are already > seeing evidence of. These are hard-gotten learns. Well, if you are right, then we will see patches on the mailing list that will affect the code in profound ways, and you will be able to object to them then. But far from “already seeing evidence” of the apocalypse you predict, we see that the avradio code already delivers features while being self-contained and only required extending the signal processing abilities of our libraries a little, and in ways that are useful to other developers. So I guess it proves being licensed to operate something does not make you qualified to evaluate the difficulty in implementing the software of that thing. What a surprise. I will add that “affect the code in profound ways” was actually true for hardware acceleration, requiring a big mess in the code and significant to the internal API and even public API and user interface. Yet nobody is objecting to them. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Tomas Härdin (12023-07-23): > No to this entire patchset. 404 argument not found. > Users can test libavradio's master if they wish. Do not assume merging > this fork will happen, especially not without TC approval, nor that > trying to sneak it in won't be noticed and opposed. A striving Libre Software project works by compromise. I see no intent of compromise at all in your position. > Why would they package it when there already are mature programs like > gqrx, dablin etc? Programs that feature separation of concerns. See for > example hacktv which uses ffmpeg, libhackrf and libsoapysdr without > insisting on being part of either Oh, yes. And these idiots working on the Linux kernel, why do they waste their time when Windows and MacOS are excellent for everybody? And the Vim team, do they not know that LibreOffice can do everything better? Why bother maintaining i3 and Fvwm when Gnome is so much better? Why develop Perl modules? Python for everybody! Seriously, if you have to ask, you are at the wrong place. >I know this because it's going to cause headaches for this > project to care about maintaining compatibility with a fork that > doesn't want to pretend it's a fork. This is very dishonest. Maintaining a fork only causes headaches to the people who do it, and you have made amply clear that would not be you. In fact, quite the opposite, you were one the loudest demanding that one of our most talented hacker waste his time on maintaining a separate build system instead of doing creative and useful work. I say: let us merge this fork that should never have been separate, for the convenience of Michael and of potential users. Then let us reaffirm that FFmpeg is a place for hackers to be creative in the general field of multimedia, the place to foster new ideas, new solutions, new ways of writing efficient code, rather than a wrapper around other libraries and obsolescent native code for the convenience of other projects and commercial companies. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 mich...@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 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
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 mich...@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-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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 mich...@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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
On Sat, Jul 22, 2023 at 11:39:11PM +0200, Lynne wrote: > Jul 22, 2023, 21:30 by mich...@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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Jul 22, 2023, 21:30 by mich...@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? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/6] fftools: avradio support
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(-)
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(_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(_opaque))) {
is_dev =
