[FFmpeg-devel] [PATCH] metadata conversion API

[Michael Niedermayer]

On Sun, Mar 01, 2009 at 02:28:44PM +0100, Peter Eszlari wrote:
> 2009/3/1 Baptiste Coudurier <baptiste.coudurier at gmail.com>:
> >>> Also I believe this would simplify adding support for libx264
> >>> commandline switches in libx264 wrapper, since you do not needed an API
> >>> extension in AVCodecContext, for it due to x264_parm_parse which takes
> >>> exactly 2 char *. This is what I call generic API.
> >>
> >> the question is if we _WANT_ to let a encoder bypass the normal way to
> >> pass parameters.
> >
> > I do. Is anybody against this ?
> 
> Wasn't the topic "codec-specific options" discussed years ago and
> rejected with the argument "code duplication"?
> As a user I'm very much in favor of codec-specific options (not only
> for wrappers).

you are confused we are not talking about codec specific options, we have
codec specific options, we have a few in AVCodecContext that work just with
one or few codecs.
and any option one developer might want to support through a name-value tag
in a native codec could be done through a field in the AV structs, the
discussion is about the large number of fields that are in the AV structs,
the dislike some have for such huge structs and if or if not the name-value
system would be less memory hungry or easier to maintain or if it would lead
to chaos because its all too easy to add the same value to 2 demuxers but
under different names
that is chaos like
ffmpeg -i file -aq 5 out.mp3
Unknown option aq, use -audioquality

ffmpeg -i file -audioquality 2 out.flac
Unknown option audioquality use -aq <1-5>

ffmpeg -i file -aq 5 out.aac
Parameter out of range, -aq <0.0-1.0>


> 
> 2009/3/1 Baptiste Coudurier <baptiste.coudurier at gmail.com>:
> >> If the awnser to this is yes, its a matter of a single char* generic_param
> >> in AVCodecContext with which encoders can do what they want.
> >
> > Encoders will doxygen the parameters it supports when declaring it.
> > For libx264 we would point to libx264 documentation of course.
> >
> > Btw, it would be good to know which option encoder honors, currently
> > user do not know this. This is not practical IMHO.
> 
> Not only does the user not know about it, ffmpeg/lavc too doesn't know about it.
> If I do the following:
> 
> $ ffmpeg -i file.avi -aq 50 file.mp2
> 
> The option "-aq" gets silently ignored, while one would expect an
> error massege like "option -aq not supported by ffmp2".

yes yes, using name-value pairs is a "heal all ill"
suddenly the problem of not having a list of supported options per codec
(something due to lack of interrest, manpower & patch) will disapear
we will just querry the magic_crystalbal() fuction and will then know
which options the codec supports and what the supported parameter ranges
are.
iam eagerly awaiting that patch ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090301/77d1cbd8/attachment.pgp>