Re: [FFmpeg-devel] SDR lib comments
Rémi Denis-Courmont (12023-09-29): > We can't just --disable-whatever. We do support building against > distribution-provided FFmpeg afterall, where we have no influence on > the build settings. We try to be nice and cooperative upstreams and > downstreams. Oh, but if you rely on FFmpeg from distros, it is even easier: you just ignore libpostproc. I can assure you, your program will not magically link with libpostproc if you do not tell it to. -- 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] SDR lib comments
Rémi Denis-Courmont (12023-09-29): > First, I don't *represent* any downstream. I just happen to be one of > several maintainers of one such project. And you write here about them: you decide to represent them. > In my experience, > what you claim as obvious (I'd call it the Lua approach to open-source > development) would be considered obviously bad if not outright toxic > behaviour in most projects and by most developers. Maybe these projects do not have the same mindset of history than ffmpeg. That does not prove I am wrong. -- 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] SDR lib comments
Vittorio Giovara (12023-09-29): > In a previous thread you said SDR shouldn't be a separate library because > it wastes downstream time to package and bundle it separately. No, it wastes Michael's time. It also wastes downstream time, indeed, but that is not our problem. Yet, it shows how useless the proposal of a separate library is at this point. -- 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] SDR lib comments
Rémi Denis-Courmont (12023-09-29): > A core feature that depends on niche hardware libpostproc does not depend on niche hardware. If the discussion bores you to the point of not remembering what is being discussed, maybe just dropping it and letting those who care spend their 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] SDR lib comments
Le 29 septembre 2023 14:43:11 GMT+03:00, Nicolas George a écrit : >Anton Khirnov (12023-09-29): >> What does anybody gain from it being in our source tree, as opposed to a >> separate library? > >Not having to maintain yet another packaging and build system. Talk about flimsy "scraps of the bottom of the barrel" reasons. Considering the accumulated cruft in the FFmpeg build system, this is more of a reason *not* to share source trees - rationalise the build system (or use an off-the-shelf one, whatever rocks your boat). >Not having an external dependency for something that could be considered >a core feature. A core feature that depends on niche hardware, and is only supported on a narrow subset of target platforms. Oxymoronic much? If those are your reasons, you'd have better kept them to yourself, because they're frankly ridiculous. Normally you'd bundle things because they are tightly coupled. But if they were tightly coupled, then there would be maintenance costs, so that's also a self-defeating argument. ___ 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] SDR lib comments
On Fri, Sep 29, 2023 at 3:03 AM Nicolas George wrote: > Well, I think this makes it obvious why I think people representing > downstream projects should have very little influence on the future of > FFmpeg. > In a previous thread you said SDR shouldn't be a separate library because it wastes downstream time to package and bundle it separately. Now you're saying downstream should have no influence on project decisions. Can you make up your mind? While at it, maybe try and avoid discrediting the person you're responding to only because they have a different opinion than you. Thanks! -- 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] SDR lib comments
Anton Khirnov (12023-09-29): > What does anybody gain from it being in our source tree, as opposed to a > separate library? Not having to maintain yet another packaging and build system. Not having an external dependency for something that could be considered a core feature. -- 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] SDR lib comments
Quoting Michael Niedermayer (2023-09-28 21:28:35) > On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-09-23 18:43:44) > > > Is a seperate library really the right choice for SDR in FFmpeg at this > > > stage ? > > > > > > Also code can always be moved into an seperate library > > > > we've had postproc in the tree for ages, nobody maintains it or > > cares about it, yet it seems impossible to get rid of it. > > what maintaince does it need ? > i mean i know the code is ugly but what _needs_ to be changed? > > libpostproc implements part of ISO/IEC 14496-2 > (that is the spec for an MPEG-4 ASP decoder) > > its content could be moved in libavfilter and or the mpeg4 decoder > (there are arguments to be made for either) > but it doesnt belong in a lib external to FFmpeg. > (and in the process some bits probably can be droped as they > no longer serve a purpose compared to other filters) > > I have too many other things to work on to do a big refactoring of it > but if there are small bugs in it or questions about it i can look into them The main problem I see with it is that it is a world unto itself. It barely interacts with the rest of the project, its APIs use a different style from everything else, etc. What does anybody gain from it being in our source tree, as opposed to a separate library? -- Anton Khirnov ___ 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] SDR lib comments
Le 29 septembre 2023 10:03:13 GMT+03:00, Nicolas George a écrit : >Well, I think this makes it obvious why I think people representing >downstream projects should have very little influence on the future of >FFmpeg. First, I don't *represent* any downstream. I just happen to be one of several maintainers of one such project. My current FFmpeg activities have little if anything to do with that downstream, and can and hopefully will be used by FFmpeg CLI as well as by other downstreams. So if this was an attempt to discredit me, it's failed. And then, as somebody who's been involved in OSS for over 20 years, including contributions to Linux, QEMU, FFmpeg, Wireshark and Debian, thousands of code reviews and tens of thousands of merged patches, I don't exactly care for your superiority complex. In my experience, what you claim as obvious (I'd call it the Lua approach to open-source development) would be considered obviously bad if not outright toxic behaviour in most projects and by most developers. (And I am referring to the notion of ignoring or mostly ignoring downstream projects, not to you or any other person.) ___ 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] SDR lib comments
Le 29 septembre 2023 10:03:13 GMT+03:00, Nicolas George a écrit : >Rémi Denis-Courmont (12023-09-29): >> And as a downstream OSS application developer, I'd really rather >> postproc be officially and properly dropped, so I can justify dropping >> it downstream as well. > >Let me get this straight? You COULD just add --disable-postproc in your >downstream project and be done with it, but you would rather that FFmpeg >removes the feature (granted, of limited use, but still of use to some >people) so that you do not take the blame for removing it? We can't just --disable-whatever. We do support building against distribution-provided FFmpeg afterall, where we have no influence on the build settings. We try to be nice and cooperative upstreams and downstreams. ___ 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] SDR lib comments
Rémi Denis-Courmont (12023-09-29): > And as a downstream OSS application developer, I'd really rather > postproc be officially and properly dropped, so I can justify dropping > it downstream as well. Let me get this straight? You COULD just add --disable-postproc in your downstream project and be done with it, but you would rather that FFmpeg removes the feature (granted, of limited use, but still of use to some people) so that you do not take the blame for removing it? Well, I think this makes it obvious why I think people representing downstream projects should have very little influence on the future of FFmpeg. -- 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] SDR lib comments
On Thu, Sep 28, 2023 at 05:07:17PM -0400, Vittorio Giovara wrote: > On Thu, Sep 28, 2023 at 3:28 PM Michael Niedermayer > wrote: > > > On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2023-09-23 18:43:44) > > > > Is a seperate library really the right choice for SDR in FFmpeg at > > this stage ? > > > > > > > > Also code can always be moved into an seperate library > > > > > > we've had postproc in the tree for ages, nobody maintains it or > > > cares about it, yet it seems impossible to get rid of it. > > > > what maintaince does it need ? > > > > making sure that the library builds on all supported system, doesn't have > security holes, etc is it failing to build ? i would expect if it fails to build to be contacted about that. Or well if not that people would not expect it to be fixed by me. are there security holes ? If so i would expect them to be reported to ffmpeg-security or me or something like that. > or for packagers to bundle the library > > > > libpostproc implements part of ISO/IEC 14496-2 > > (that is the spec for an MPEG-4 ASP decoder) > > > > We're going a bit off topic, but you're referring to something preceding > H264 which means is something older than 20 years -- while old formats > surely need to be supported against digital obsolescence, the > code:functionality ratio is certainly not worth it (who uses ASP > nowadays?), There is substantial amounts of existing material in ASP [...] > > > > I have too many other things to work on to do a big refactoring of it > > but if there are small bugs in it or questions about it i can look into > > them > > > > I think the main reason libpostproc was mentioned is that we don't want a > repeat of the history for SDR - so far you're only developer expressing SDR currently is completely self contained in a input device/demuxer. Thats the very opposite of libpostproc which is a bit of video filtering a bit of mpeg4 ASP and neither in libavfilter (which did not exist when libpostproc was created) nor libavcodec The main obstacle to cleanup libpostproc is probably the old style interleaved SIMD code. Again this has no parallel to SDR thx [...] -- 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] SDR lib comments
On Fri, Sep 29, 2023 at 12:05:56AM +0300, Rémi Denis-Courmont wrote: > > > Le 28 septembre 2023 22:28:35 GMT+03:00, Michael Niedermayer > a écrit : > >On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: > >> Quoting Michael Niedermayer (2023-09-23 18:43:44) > >> > Is a seperate library really the right choice for SDR in FFmpeg at this > >> > stage ? > >> > > >> > Also code can always be moved into an seperate library > >> > >> we've had postproc in the tree for ages, nobody maintains it or > >> cares about it, yet it seems impossible to get rid of it. > > > >what maintaince does it need ? > >i mean i know the code is ugly but what _needs_ to be changed? > > This is rather disingenous, TBH. All non-trivial code needs maintenance. > > If there is no formal proof that the code is perfect, then it's probably > bugged. And for the sake of the argument, if there were such a proof, it > would need to be maintained as the code around changes, so either wayw that's > maintenance. > > Then you also can't really ascertain that the code won't need fixes for > future build environments and code auditing tools. > > And then you have all the more or less hidden costs of keeping code around, > especially if it's unmaintained : people will enable it (if it's even > disabled by default), hit problems and look for support. > > And as a downstream OSS application developer, I'd really rather postproc be > officially and properly dropped, so I can justify dropping it downstream as > well. > > > But at least, postproc doesn't engender extra traffic on this mailing list > much at all. More or less nobody here can or wants to review or test your SDR > code. I think, more so than ffmpeg.git being ill-suited a source code > repository for SDR because it is so niche and loosely related, ffmpeg-devel > is simply not suited for SDR. The skills are not here, the time and > motivation are not here, not to speak of the good will. My reply was only about libpostproc, I was intending to just ask what exactly needs to be done in libpostproc (aka maintaince) i had not intended to somehow refer to anything else. I should have snipped the other bits of the quoted thread probably thx [...] -- 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] SDR lib comments
On Thu, Sep 28, 2023 at 3:28 PM Michael Niedermayer wrote: > On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-09-23 18:43:44) > > > Is a seperate library really the right choice for SDR in FFmpeg at > this stage ? > > > > > > Also code can always be moved into an seperate library > > > > we've had postproc in the tree for ages, nobody maintains it or > > cares about it, yet it seems impossible to get rid of it. > > what maintaince does it need ? > making sure that the library builds on all supported system, doesn't have security holes, etc or for packagers to bundle the library > libpostproc implements part of ISO/IEC 14496-2 > (that is the spec for an MPEG-4 ASP decoder) > We're going a bit off topic, but you're referring to something preceding H264 which means is something older than 20 years -- while old formats surely need to be supported against digital obsolescence, the code:functionality ratio is certainly not worth it (who uses ASP nowadays?), and as you suggest, it's code that could definitely live in libavfilter or libavcodec and not in a separate library. > I have too many other things to work on to do a big refactoring of it > but if there are small bugs in it or questions about it i can look into > them > I think the main reason libpostproc was mentioned is that we don't want a repeat of the history for SDR - so far you're only developer expressing active interest to work on it, and nobody knows if you will be continuing to work on it after releasing it, or for how long, and in which depth. The community at large (except one vocal member) seems to prefer that this code live in a separate repository, and not into ffmpeg mainline, so that we could avoid risking repeating history of having "ugly code" (your words) in the main repo for who knows how long, possibly forever. Once the SDR code is better defined, as library, executable or whatever, and there are users needing it, we could discuss bringing it back in FFmpeg, in a more defined and clean form. -- 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] SDR lib comments
Le 28 septembre 2023 22:28:35 GMT+03:00, Michael Niedermayer a écrit : >On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: >> Quoting Michael Niedermayer (2023-09-23 18:43:44) >> > Is a seperate library really the right choice for SDR in FFmpeg at this >> > stage ? >> > >> > Also code can always be moved into an seperate library >> >> we've had postproc in the tree for ages, nobody maintains it or >> cares about it, yet it seems impossible to get rid of it. > >what maintaince does it need ? >i mean i know the code is ugly but what _needs_ to be changed? This is rather disingenous, TBH. All non-trivial code needs maintenance. If there is no formal proof that the code is perfect, then it's probably bugged. And for the sake of the argument, if there were such a proof, it would need to be maintained as the code around changes, so either wayw that's maintenance. Then you also can't really ascertain that the code won't need fixes for future build environments and code auditing tools. And then you have all the more or less hidden costs of keeping code around, especially if it's unmaintained : people will enable it (if it's even disabled by default), hit problems and look for support. And as a downstream OSS application developer, I'd really rather postproc be officially and properly dropped, so I can justify dropping it downstream as well. But at least, postproc doesn't engender extra traffic on this mailing list much at all. More or less nobody here can or wants to review or test your SDR code. I think, more so than ffmpeg.git being ill-suited a source code repository for SDR because it is so niche and loosely related, ffmpeg-devel is simply not suited for SDR. The skills are not here, the time and motivation are not here, not to speak of the good will. If the project grows and develops to become better accepted as a fit for FFmpeg, it can be merged (like btrfs.git got merged into Linux, with full git history). Honestly I think that probably will never happen, especially not after at least two distinct attempts to make it a fait accompli in spite of FFmpeg-devel. But I'm not a medium. In the end, cool but controversial new features being rejected due to poor community acceptance, and continuing their life elsewhere, is quite common and mundane. It happened to me more than once (not in FFmpeg, obviously). >libpostproc implements part of ISO/IEC 14496-2 >(that is the spec for an MPEG-4 ASP decoder) > >its content could be moved in libavfilter and or the mpeg4 decoder >(there are arguments to be made for either) >but it doesnt belong in a lib external to FFmpeg. >(and in the process some bits probably can be droped as they > no longer serve a purpose compared to other filters) > >I have too many other things to work on to do a big refactoring of it >but if there are small bugs in it or questions about it i can look into them > >thx > >[...] > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] SDR lib comments
On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-09-23 18:43:44) > > Is a seperate library really the right choice for SDR in FFmpeg at this > > stage ? > > > > Also code can always be moved into an seperate library > > we've had postproc in the tree for ages, nobody maintains it or > cares about it, yet it seems impossible to get rid of it. what maintaince does it need ? i mean i know the code is ugly but what _needs_ to be changed? libpostproc implements part of ISO/IEC 14496-2 (that is the spec for an MPEG-4 ASP decoder) its content could be moved in libavfilter and or the mpeg4 decoder (there are arguments to be made for either) but it doesnt belong in a lib external to FFmpeg. (and in the process some bits probably can be droped as they no longer serve a purpose compared to other filters) I have too many other things to work on to do a big refactoring of it but if there are small bugs in it or questions about it i can look into them thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data 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] SDR lib comments
Quoting Michael Niedermayer (2023-09-23 18:43:44) > Is a seperate library really the right choice for SDR in FFmpeg at this stage > ? > > Also code can always be moved into an seperate library we've had postproc in the tree for ages, nobody maintains it or cares about it, yet it seems impossible to get rid of it. > but its much harder to move or change it once such library is public. Compatibility rules you choose for your new library are entirely up to you, they can (and probably should) be very loose at the beginning. -- Anton Khirnov ___ 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".
