Re: [FFmpeg-devel] What is FFmpeg and what should it be
On Thu, Aug 10, 2023 at 04:58:37PM +0200, Vittorio Giovara wrote: > On Thu, Aug 10, 2023 at 2:39 PM Nicolas George 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Homeopathy is like voting while filling the ballot out with transparent ink. Sometimes the outcome one wanted occurs. Rarely its worse than filling out a ballot properly. 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] What is FFmpeg and what should it be
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 ___ 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] What is FFmpeg and what should it be
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. -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
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. ___ 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] What is FFmpeg and what should it be
On Thu, Aug 10, 2023 at 2:39 PM Nicolas George 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 -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
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. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
On Wed, Aug 9, 2023 at 5:59 PM Michael Niedermayer 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-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] What is FFmpeg and what should it be
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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn 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] What is FFmpeg and what should it be
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. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
On Tue, Aug 8, 2023 at 5:23 PM Michael Niedermayer 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-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] What is FFmpeg and what should it be
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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu 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] What is FFmpeg and what should it be
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. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
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 > 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
sön 2023-08-06 klockan 01:32 +0200 skrev Vittorio Giovara: > On Sat, Aug 5, 2023 at 8:55 PM Michael Niedermayer > > 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 ___ 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] What is FFmpeg and what should it be
On Sat, Aug 5, 2023 at 8:55 PM Michael Niedermayer 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. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
Your attempts to troll other developers to work on SDR/AVRadio is flawed and disrespectful to other FFmpeg people. ___ 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] What is FFmpeg and what should it be
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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes 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] What is FFmpeg and what should it be
On Fri, 4 Aug 2023, 13:35 Nicolas George, 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 > ___ 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] What is FFmpeg and what should it be
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, -- 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] What is FFmpeg and what should it be
On Thu, Aug 03, 2023 at 04:04:23PM -0400, Kieran Kunhya wrote: > On Thu, 3 Aug 2023, 15:25 Michael Niedermayer, > 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 GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. 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] What is FFmpeg and what should it be
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 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 ___ 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] What is FFmpeg and what should it be
On Thu, 3 Aug 2023, 15:25 Michael Niedermayer, 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 > ___ 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] What is FFmpeg and what should it be
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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin 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] What is FFmpeg and what should it be
> > > 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 > ___ 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] What is FFmpeg and what should it be
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 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
On Wed, Aug 02, 2023 at 03:46:29PM +, Cosmin Stejerean wrote: > > > > On Aug 2, 2023, at 7:30 AM, Nicolas George wrote: > > > > Michael Niedermayer (12023-08-02): > >> The libraries should be split into runtime loadable plugins > >> Not only would that make tools alot smaller it also would allow > >> development of code available in ffmpeg that is maintained outside > >> FFmpeg. > >> > >> I suggested this previosuly, it is of course not a "simple" thing > >> to do. > > > > No, it would be a terrible mistake. > > > > And mostly, people who suggest or demand that do it based on > > misconceptions about how linking works and/or have no actual scenario > > where that would help. > > > > But this is another discussion entirely. > > This indeed feels like a separate discussion, but should we want to have that > discussion I'd be happy to both provide some use cases as well as contribute > code to facilitate the implementation. > > My understanding however is that the community is opposed to dynamically > loaded plugins on principle, because it would make it easier to distribute > proprietary plugins and sidestep the intent of the copyleft licensing. I dont know if there is opposition or just inertia and more sexy things to work on but if theres fear of proprietary plugins just do this: 1. give the plugin a license field 2. check that the license field matches a GPL compatible license before loading thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch 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] What is FFmpeg and what should it be
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. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
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 parser because it is an interesting challenge. But since Michael is a very talented hacker, the result of he having fun ends up being code that is in some way already better than existing alternatives. As a member of a community project, you do not have the authority to choose what other developers work on. The only authority you have is to decide whether you will welcome the fruit of their work as an useful new feature (while being vigilant about code quality) or whether you will be so annoying about it that they give up trying to contribute to FFmpeg. As of now, you seem to be making the wrong choice. And I can tell you about my own situation: for several months now, the attitude of some developers here, including you very strongly, has mostly disgusted me from contributing to FFmpeg. The stupid farmer kills the goose with the golden eggs by opening up her belly. The smart farmer kills the goose with the golden eggs by trying to force her to lay on a schedule. > Layering is not an end in itself as you rightfully point out. It is a > tool. To what end? > In the free software world we don't layer and segregate things for no > reason. We do it so that programs can interact with each other through > standardized interfaces. The effect is a comedy of the commons. More > can be done with less labour. For an FM receiver program the > appropriate interfaces are ALSA, PulseAudio and/or JACK. That way its > audio can be piped to many programs. As you point: layering is not an end. “The scope” is not the reason, it is only a quick summary of the reasons when they are obvious and we all agree. So please stop invoking “the scope” as a reason. Second, layering is indeed something to wish for in a complex project, but it has to come organically, it has to appear progressively as the code becomes more complex and the useful boundaries and interfaces appear. When people start with layering, the result looks like the OSI model for network stacks: it makes a few nice paragraphs in textbooks and is completely worthless in practice. > It is true that we can add more features, and it is also certainly true > that these are useful for a non-empty set of users. But is it a good > use of scarce developer time? Were SDR limited to only Michael's time > then there would be no problem. But it isn't. It unavoidably touches > many other parts of the code, as we are already seeing. It is the second time you say this, and it is the second time I have to tell you: no, it is not true at all. We are seeing exactly the opposite: Michael's code is big, but it is self-contained and completely optional. Furthermore, it is not wasting any developer time. Only these sterile objections are wasting precious time. -- Nicolas George ___ 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] What is FFmpeg and what should it be
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 ___ 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] What is FFmpeg and what should it be
> On Aug 2, 2023, at 7:30 AM, Nicolas George 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 ___ 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] What is FFmpeg and what should it be
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 -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
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, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
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 GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- 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] What is FFmpeg and what should it be
On Wed, Aug 02, 2023 at 02:59:11PM +0200, Jean-Baptiste Kempf wrote: > On Wed, 2 Aug 2023, at 14:55, Michael Niedermayer wrote: > > the code already is in a seperate repository. And is basically isolated > > in a single demuxer and single input device. > > But it's not a library in that repository, like swscale, swresample or > similar libraries. > > If it was, with an API, it would be trivial to add support to this optional > library as an FFmpeg module, and noone who complain. There are multiple problems but the real problem is that How many people discuss an SDR API ? (0) How many people propose an SDR API ? (0) How many people say what they want an SDR API to be able to do ? (0) This is not a simple question ? enumerate devices, set options, open, read frames, close ? That does not differ from the existing input device / demuxer API. If one cannot state a single difference in the API requirements from the existing input device API, how can one design that API ? If the existing input device API suposedly is not good Is it bad just because it is the existing API ? And it would be perfectly fine if it just had different function names ? In other areas the community collaborates to create APIs here all energy is spend to block patches (the latest set blocked are pure bugfixes) Also swresample and swscale are simpler in what they need to provide API wise. My very first patch i sent btw was blocked with the claim that it used an external library and did not do the processing nativly. Thats exactly what you suggest now IMHO, People who want to use this API, or want to implement this API should help with the API design and implementation And if there are 0 people wanting to use the API then why should i design that API ? who for ? SDR in FFmpeg has 500+ users who want it, the API iam not sure has a user People who have no intend to use the API or SDR or implement either should not represent 99% of whom approv / reject the code This is a problem, because it leads to bad code. The people telling me what to do dont care about the results one day its "not external lib", then its "external lib" then its "libavfilter" then its "not libavfilter" Again we had 0 that is ZERO discussions about an SDR API. where does it start ? a hw enumerate, a soapy device, a void * representing a SDR data stream from something like soapy soapy is full of bugs, for the code to work we need to know where the data came from and we need to interact with the hw should we provide a layer over all of libsoapy ? should we support only libsoapy and take a device from libsoapy as input should we have a generic input support that libsoapy is one of several options ? I cannot design this API with this. because 3 out of 4 choices will get attacked and blocked if not all 4, if someone just implements it. because people are unwilling to think about anything they just think they know how it must be done and they dont discuss anything they just demand and attack and wait how the next patchset looks. Eventually everyone then looses interrest and a patchset goes through but thats not good design. So again, IMHO people should help design and implement this API if they want an API. If i have to design an API by trial and error until it gets no unspecific objections by people not interrested in using it thats not going to be an API that anyone will want to use. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership. - Colin Powell 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] What is FFmpeg and what should it be
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 wrote: Please do not top-post. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
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. b...@audiopump.co On Wed, Aug 2, 2023 at 7:59 AM 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. > > 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-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] What is FFmpeg and what should it be
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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
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 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- 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] What is FFmpeg and what should it be
On Sun, Jul 30, 2023 at 3:04 PM Nicolas George 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. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
Le 31 juillet 2023 00:07:37 GMT+07:00, Andrey Turkin a écrit : >вс, 30 июл. 2023 г. в 16:04, Nicolas George : > >> 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-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] What is FFmpeg and what should it be
sön 2023-07-30 klockan 15:04 +0200 skrev Nicolas George: > That means every time we use a real XML library to parse > “”, 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 ___ 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] What is FFmpeg and what should it be
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, -- 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] What is FFmpeg and what should it be
On Sun, Jul 30, 2023 at 6:07 PM Andrey Turkin wrote: > > вс, 30 июл. 2023 г. в 16:04, Nicolas George : > > > 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 ___ 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] What is FFmpeg and what should it be
вс, 30 июл. 2023 г. в 16:04, Nicolas George : > 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). ___ 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] What is FFmpeg and what should it be
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 “”-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 “”, 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 “”, 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, -- 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".
