[FFmpeg-devel] [PATCH] Move stream_options to avformat

[Michael Niedermayer]

On Sun, Jan 25, 2015 at 01:18:31PM +0100, Michael Niedermayer wrote:
> On Sun, Jan 25, 2015 at 12:15:40PM +0100, Reimar Döffinger wrote:
> > On 25.01.2015, at 03:08, Michael Niedermayer <michaelni at 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?
> 
> absolutley
> i would strongly prefer if others could take this over, my interrest
> was just in the technical side and i wanted to move AVStream to
> the same system we use for all other structs. As well as fixing the
> quite valid issue nicolas had raised with the duplicated tables.
> I am quite surprised that others dont see this as a clear and
> uncontroversal step, there really are just
> 1. If we want AVStream to be consistent with other structs, that means
>    AVOption & AVClass. And this patch is a step toward it, one could
>    make a bigger or smaller step but its then either more or less
>    code not different code.
> 2. There could be a different system be used for this field or for
>    AVStream, this would be inconsistent
> 3. We can implement both a system based on AVOptions/AVClass and a
>    system without them, why would this field that noone cared about
>    until now need this, iam not sure though
> 4. We can leave the triplicated tables as is and hope not to forget
>    updating them in sync
> 
> To me the best choice is clear, move toward the same system we use
> elsewhere. Change that system everywhere if it could be improved
> I see nothing controversal on this patch but others do apparently.
> As i dont see what issue people have with this, i certainly cannot
> help fixing the patch. But iam happy to review & approve the solution
> that people do prefer

About the documentation & example side, i dont think this should yet
be used from outside, its only a partial implementation of AVOption
for AVStream, a full implementation needs a ABI bump due to the
first field needing to be a AVClass

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150125/adfaf7f0/attachment.asc>