Jean-Baptiste Kempf (12020-07-05): > You are missing the point here: > Lego Racers demuxer is in the scope of "play everything under the sun" > that the FFmpeg project is, while AMQP/ZMQ is not. > > The issue is not usefulness, but correctly defining the scope of the > project (aka the orienttation). If you don't, you will integrate a > webserver, an email sender, a full webRTC stack with p2p and a coffee > controller. > > Some codecs and formats are not useful, sure, but they are in the > scope, and there is little debate about it. > But custom protocols or complex filters that bring huge dependencies > are very debatable, and I doubt they are the consensus.
I understand your point, but I see it as less a problem than another similar but not identical issue. Whether they are an actual multimedia protocol, format or codec, and therefore "in the scope of the project" or something else and stranger, and therefore not "in the scope", components are not in the way. They are just a few extra C files to compile, possibly a few extra library dependencies (i.e. NEEDED fields in ELF objects). They can be disabled, and when they are they cost nothing. If they become a burden, if they fail to build for example, they can be removed in a few seconds. In the build tree, they are just leaves. It can be said they cause a little namespace pollution, but that is all there is technically. The major objection to accepting strange and fringe components is not technical, it is us holding ourselves to a higher standard: once something is in, it is in for good, it must be maintained. If a patch on the framework breaks it, it must be repaired or the patch is not accepted. We do not have to do that. We do not have to hold ourselves to such unattainable standards that they hamper development. We could just say: we accept your fringe codec/format/filter/whatever, but you have to maintain it: if it breaks we disable it, and either you fix it or we remove it. Such components could be in sub-directories of their respective libraries, there could be a global configure flag --enable-fringe, etc. The issues of components is not the hardest issue when it comes to project orientation. What is hardest, in my opinion, is changes that affect the way we do things. Let me develop one of the things I had in mind when starting this discussion: strings. Despite FFmpeg not being a project about handling text, it uses strings in many places. And these strings are almost always basic NUL-terminated C strings, either in constant-size on stack or mallocated. It is costing us efficiency, code complexity (all the "if (!str) return AVERROR(ENOMEM);". I have drafted a proposal for a better API to handle strings (see AVWriter in the archives). I think it is a good proposal: it was a long time brewing, it includes several original ideas that should make it all at once convenient, efficient and maintainable. See my points above about creativity in programming. But for people who work on parts of the code where there are not many strings, the benefit does not exist. For them, there is only the hassle of learning a new, non-default API. Even if this hassle is tiny, it is still a hassle, and people do not want it, they oppose. On the other hand, I could just push AVWriter and start using it in my parts of the code: it is not in the scope of any maintained part, there is nothing in the actual project rules that forbids me to do it. But it would be extremely rude. And more than rude, it would lead to more inconsistency (see https://xkcd.com/927/). What we need is somebody or somebodies who listen on all sides of the arguments, weigh the benefits and drawbacks, and decide: no, we'll continue using basic C strings, don't waste your time working on AVWriter; or yes, we'll use AVWriter, so all must find fifteen minutes to learn how to use it; or even, yes we'll use smarter strings, but rather this other proposal that looks more promising than AVWriter. I can deal with AVWriter being discussed and rejected. What I have a hard time dealing with is uncertainty: the code I am currently writing, will it be wasted? I took AVWriter as an example because it is something I worked on recently, and something that affects a significant part of the code, but there are many similar cases, where we need somebody to be able to decide, for the whole project, how we will be doing things. This could fall under the mandate of the tech committee, but I am not sure it is the best idea: these issue border on the technical, but they are also a matter of policy and human interaction. It would greatly increase the power of the tech committee. But tech committee or other, we need to be able to ask and answer these questions. > Also in this example, noone is telling them to fork, just to use the > API to register their custom protocol. I have a point for this, but this mail is already very long, I will make it separately. 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".
