On Tue, May 10, 2016 at 1:43 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Tue, May 10, 2016 at 11:17:12AM +0100, Derek Buitenhuis wrote: >> On 5/10/2016 7:24 AM, Hendrik Leppkes wrote: >> > I don't like this, the struct is pretty cleanly defined and unlikely >> > to be extended much over time. >> > Most other structs have AVOptions so the CLI can interact with it, but >> > this struct is not meant to be modified by users, its just a direct >> > line of communication between demuxer->decoder or encoder->muxer. >> >> To me this mostly still feels like trying to make a demuxing library >> something it isn't. It demuxes and muxes. >> >> You can argue that it should be easier than decoding a frame to get this >> info (which I don't personally think is much trouble at all). However, >> jamming it into libavformat for reasons like "we've always done this" and >> "there's no better place" is not good design IMO. >> >> It sounds like what you really want is a higher level "easy" API. Don't >> jam it in to existing decoupled APIs because it is convenient, IMO. That's >> how horrible things like having ffmpeg.c functionality in libavformat came >> to exist, and a decade of misery followed. > > This patch adds an AVClass field to AVCodecParameters like we use in > other public structures. > i fail to see how this patch is related to your reply > > What the patch does, is it makes the API more consistent and easy to > use. Users call the AVOption functions to set fields in the main > public structures, if they do that for AVCodecParameters it would > crash. > Even an empty AVClass that doesnt list options would reduce that > misery by at least not crashing but giving a clear error message. >
We should not design our API around people not caring to read our API, because thats not a fight we can ever win. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
