On Sat, Jan 24, 2015 at 11:14 PM, wm4 <[email protected]> wrote: > On Fri, 23 Jan 2015 20:26:35 +0000 > Robin Stevens <[email protected]> wrote: > > >> I don't think that level of discoverability is true of the C >> structs-and-functions API that the ffmpeg libraries currently use. > > Idiotic prejudices against C APIs are not helpful here. FFmpeg is > mostly not a good C API and could be better, simple as that. >
I have no such prejudice. The level of discoverability of the C structs-and-functions API that the *ffmpeg* libraries currently use is not great. It's entirely possible to make discoverable APIs in C; just that I don't think ffmpeg has one. > > So I wonder what your .net wrapper is supposed to help here. It > basically turns all public fields into trivial properties that get or > set the field. What's the use? > That's a fair criticism of much of the wrapper. The use is to expose the FFmpeg api to C#, the getters and setters help with that. (The wrapper is in managed C++/CLI, so the interop is taken care of for me.) There is some value in the methods (instance or static) on the types, which makes for greater discoverability, but doesn't really help you understand when and where a particular type is meant to be used. > Anyway, yes, that's one of the problem with this "let's dump everything > into a big struct" API. A big class with hundreds of getters and > setters is better? > It can be, yes. Take the AVFrame struct, and look at the sample_rate member. Is this a read-only property? Can it be written to? Does that operation make even make sense? Perhaps I want to change the sample rate of a frame. From this API I might think I just need to set a value on that variable and the library will magically change the sample rate for me. The ffmpeg API does NOT tell me. The only way to find out is to dive in to the code. That is a deficiency of the interface which should specify such things. (And my preference is for language support so that the specification is enforceable by the compiler, but that's just my preference.) My wrapper only has a getter for that property, so it's a syntax error to attempt to set it. It's clear to the user that they cannot change the sample rate by setting that property, and need to go and look elsewhere. C cannot (AFAIK) specify in the language whether a variable is publicly read-only or writeable, so static checking is not available. The solution to this, as far as the FFmpeg API is concerned, appears to be to document in the comment whether the field is writeable. That's perfectly reasonable, although not consistently done. Easy to fix though, if you have the knowledge. Another small win: basic class hierarchy. The AVFrame structure encapsulates two very different types of frames: audio and video; and has a bunch of variables that apply to one or the other, but not both (and some variables that *do* apply to both). My wrapper splits AVFrame into a base class, an AVVideoFrame and an AVAudioFrame. This could presumably be done in the FFmpeg API but the devs have chosen to spend their time elsewhere. I'll admit that this is a a tiny, marginal win (at best) over ffmpeg, given the comment SAYS audio sample rate. Though it *is* a small win, and lots of those add up. None of the points I'm making amount to much on their own, but they are I think useful illustrations of some of the problems I've had with the FFmpeg API. Improving and documenting the real API is the best option, but has no realisitic prospect of success. I someone like me came along and started suggesting (breaking) changes to the existing API (like AVFrame, AVAudioFrame, AVVideoFrame), I would (rightly) be shot down in flames. Cheers, Rob _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
