[FFmpeg-devel] [PATCH/RFC] Per-codec option system

[Michael Niedermayer]

On Tue, Sep 29, 2009 at 04:49:55PM -0700, Jason Garrett-Glaser wrote:
> > * parameters that are semantically identical between a pair of codecs,
> > ?must use the same parameter name, they also must use a compatible
> > ?parameter value system. That makes some sense because, well, its nice if
> > ?users dont have to releaern a new system for each codec in ffmpeg.
> 
> IMO this should be handled internally to codecs, not by literally
> sharing the parameters.  In other words, it should be a policy: codecs
> should use the same name for parameters when it makes sense.  It
> should be enforced by rules, not code.

thats your oppinion but do you have some argument beyond that you would
prefer it that way? I mean some kind of advantage? it surely has its
disadvantages to depend on yet another rule, a rule that eats more of _MY_
time checking patches and more of peoples time resubmitting them.
Its always nice if the code naturally prevents breaking rules, like with
rand() or exit() ...


> 
> > * parameters that are used by more than 1 codec must be conventional fields
> > ?in AVCodecContext (this is vastly more efficient in terms of access speed
> > ?and amount of memory needed)
> 
> Why does access speed matter for setting parameters?  This is stupid.

it is stupid but that is not what i spoke of
you should read it again maybe ...
you can set the fields of AVCodecContext with the AVOptions API or directly
through C. The codec itself though can always just access the fields directly
which allows there use in speed relevant code.
OTOH a system with key/name strings is not useable in speed relevant code,
values would always have to be extracted into normal accessable variables or
struct fields first



> 
> > * as a consequence of above it also must be possible to transparently move
> > ?a name/value parameter into AVCodecContext, this can be done by extending
> > ?AVOptions.
> 
> I don't see why AVCodecContext even needs to exist in the first place.

noted, 


>  There is not a *single parameter* in the context that applies to all
> codecs.

bitrate
codec_id
codec_type
av_class needed for av_log
timebase
extradata, extradata_size
struct AVCodec *codec
priv_data
header_bits
frame_bits
opaque
codec_name
codec_tag
workaround_bugs
strict_std_compliance
error_recognition
error_concealment
dsp_mask
coded_frame
debug
rc_max_rate, rc_min_rate ... (for variable bitrate codecs)
width, height, pix_fmt, sample_aspect_ratio, ... (for video codecs)
sample_rate, sample_fmt, channels, ... (for audio codecs)

there are more but i dont want bleeding fingers ;)


> 
> > * If there exists an established parameter name/value for something like
> > ?a paremeter in lame or x264 then these should in addition to the standard
> > ?system in ffmpeg be supported.
> 
> So you want to have two redundant systems for passing options to an
> encoder, each with different naming schemes?  This is a usability
> disaster.

I want people to be able to write
./ffmpeg i filex -b 1000k -vcodec $codec file.avi

and not have to do
if $codec == libx264
    ./ffmpeg i filex -b 1000 -vcodec $codec file.avi
elif $codec == liblame
    ./ffmpeg i filex -bitrate 1000 -vcodec $codec file.avi
elif $codec == libfaac
    ./ffmpeg i filex -br 1000 -vcodec $codec file.avi
else
    ./ffmpeg i filex -b 1000k -vcodec $codec file.avi

or something like that


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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- 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/20090930/d9667a7e/attachment.pgp>