On 25.01.2015, at 03:08, Michael Niedermayer <michae...@gmx.at> wrote: > On Sun, Jan 25, 2015 at 02:31:33AM +0100, wm4 wrote: >> >>>> >>>> As an experienced API user, I don't have the slightest clue what I'd do >>>> with this API, or where to find information about it. >>> >>> the primary goal is to remove duplicated disposition type tables, >>> which needs one of the tables to be public first >>> >>> [...] >> >> And this is the most awkward way you could find to do this? > > No, i could certainly find a more akward way, if people prefer > > this is just the way that would be a big step towards consistent > and simple access to the structs > All public structs use AVClass and AVOptions to allow applications > to extract/enumerate fields except a few like AVStream > this patch would add these AVClass & AVOption for AVStream, its > indeed not populated for all fields and AVStream doesnt have a > AVClass as its first field due to ABI. But its a step toward it > > Would people prefer that each field in AVStream has a custom and > different way to access it, as long as it looks simpler when looked > at in isolation ?
Sorry if it's useless of me to only state some obvious questions, but: I think it's clear we all want a simple, obvious and consistent API :) If it's a bit messy, might there be a point in holding off a bit so we aren't stuck with something complicated? Could possibly another approach after a major bump be nicer? Or maybe better documentation/examples? I think this started with a valid complaint/concern but unfortunately no better alternative, could we stick to considering that instead of going over to agressive rhethoric? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
