James Almer (12023-09-26): > We don't want you to resign anything. We want a proper discussion in how to > handle SDR, if at all. Pushing it in a form that everyone agrees is not > ready for upstream is not a good idea.
We can agree on this, if we consider that the opinion on whether it is ready of people who have made it clear they will never consider it “ready” is to be disregarded, just as much as somebody who says “nak” to a patch without reasons. > SDR is big, so its API needs to be designed carefully and in an extensible > way. > libavradio must absolutely not be libavdevice redux, and it must have its > own, versatile and extensible API that a lavd device can then work with, > even if not using its full potential, because libavradio can have other > users that will not be constrained to what lavf/lavd can do. SDR **will be** big. SDR **will need** to have its own versatile and extensible API. But the way to get there is to start small. First make it a module, with a very simple API to the rest. Then, as it grows, it acquires utility functions: an internal API that we can change as we discover what it needs. And progressively the API stabilizes and becomes good. Nothing successful starts as a library. Suggesting that a project starts as a library is either an expression of incompetence or a dishonest attempt at killing it. 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".
