Le decadi 30 frimaire, an CCXXV, wm4 a écrit : > > You mean a single structure returned by a single accessor with all the > > stream's properties instead of individual accessors for individual > > properties? Well, the naive methods of returning a structure to the > > caller would make the size of the structure part of the API, but there > > are ways around it. > > > > I do not dislike the idea, if that is what people prefer.
You did not answer that block. Was it an oversight? > In general, replacing public fields with macro-generated accessors is > really just a rename. Yes. But I was thinking of this case specifically. In this case specifically, I think the accessors are an enhancement by themselves because they avoid digging in the filter's innards. > AVOptions are unfortunately a good example how to create > encoder-specific options without "polluting" the common API. I don't > quite like AVOptions though, because they're too "fuzzy" for a C API > (av_opt essentially emulates dynamic/weak typing to some degree), and > they are typically even less well documented and defined like the C > API. I agree on this judgement about AVOptions. > I don't really have a good idea how options specific to single codecs > or a small number of codecs should be handled. In some cases, side-data > is a good mechanism to move overly specific use-cases out of the common > API, especially for decoding. For that, I strongly disagree. Side data id an awful API. Whether it is implemented as side data or a separate field, there is an optional bit of information, and each part of the code needs to decide if it cares about it or not. As is, side data brings exactly nothing. For each AVFrameSideDataType, we could have had a pointer field in the AVFrame structure, with NULL meaning it is not present, and that would have worked exactly the same. For our needs, really exactly. That would have cost 96 octets per frame. The differences that side data brings, or could bring if we needed it, or could have brought if it was implemented properly: - Lots of accounting, memory management, unsafe casts, etc. - Impossible to use complex data structure, side data is always flat. - Side data can be repeated. But AFAIK we never use it. And fields could point to an array or a list anyway. - Side data is ordered. We do not use it. - Side data can be processed in sequence, without looking at its type. Except that to do anything useful except copying and freeing, we need to know the type. So yeah, we gain something by using side data: each time we add a new type, we gain two lines: "if (av_something_copy(&dst->field, src->field)) goto fail;" in frame_copy_props() and "av_something_freep(&frame->field)" in av_frame_unref(). Big whoop! - Side data could have been decentralized: lavc/fooenc and lavc/foodec define their own type, nobody else cares about it; lavfi/foodetect and lavfi/footweak define their own type, nobody else cares about it. Except AVFrameSideDataType is centralized. Too bad. I think some people entertained the fantasy that AVFrame could be "generic", but did not really think it through. At some point (after reinventing the options system as outlined in http://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184525.html), I will probably propose to get rid of all this, unless it has actually become useful. But it has gotten quite out of topic. > If you look how Microsoft handles this, you'll see that they put > additional encoder controls into separate COM interfaces, which can be > not present in simpler encoders. I have no idea how the COM system works, but skimming over "COM Technical Overview" from MS, I have to say: I do not want anything like that gas factory near us! > I'm just saying we're not doing it even where we could. I would claim > that the right mindset is just not there. The problem is that often APIs that "force correct use by API design" are actually "APIs that are so annoying to use that decent developers flee to other languages", the Java way. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
