Le septidi 27 pluviôse, an CCXXV, James Almer a écrit : > If the spec changes, it will be the contents of the equi/cbmp/mesh. > By exporting them raw as extradata, said changes in the spec would > require no changes to our implementation.
By this reasoning, we could as well replace libavformat by open() and close() and leave to applications the task of dealing with the binary data. Now, I realize this has the feel of a slippery-slope fallacy but I really think it is valid. The gist of it is that the first question should be: is it (abstracting the projection properties) within the scope of this library? If the answer is yes, then we do it, whatever it requires. And the API will be as complicated as it needs to be. And of course, if it is not trivial, we will probably get it wrong the first time. Hopefully, we will get it more or less right eventually. This process may look a bit unprofessional, but it is really the only one that work. The cost of working with Libre software in a Bazaar development model is that we can not hide our mistakes behind NDAs. But the benefit of not having corporate executive breathing down our necks is that we do not need to hide our mistakes. Fortunately, the feature we are discussing here is rather peripheral to the functionalities of our libraries (it was central, we would not be having this discussion), so if we get it wrong, the only people who will get hurt are the people using it, i.e. the people who should be helping getting it right. That is all I have to say; I do not know the specifics of the projection properties to judge the merits of the current proposed API. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel