[FFmpeg-devel] [PATCH] Some lavf renames

Stefano Sabatini stefano.sabatini-lala
Sun Feb 8 15:27:26 CET 2009

On date Sunday 2009-02-08 12:47:56 +0100, Michael Niedermayer encoded:
> On Sun, Feb 08, 2009 at 09:31:34AM +0100, Stefano Sabatini wrote:
> > On date Saturday 2009-02-07 01:10:16 +0100, Stefano Sabatini encoded:
> > [...]
> > > What about these ones?
> > > 
> > > av_codec_next             -> avcodec_next 
> > [...]
> > > av_register_input_format  -> avformat_register_input
> > > av_register_output_format -> avformat_register_output
> > > av_iformat_next           -> avformat_next_input
> > > av_oformat_next           -> avformat_next_output
> > 
> > Which of these are OK?
> none
> they already have a av_ prefix
> the names are all worse after the rename and honestly this should be obvious,
> i mean its a input format -> iformat not format_next_input ???!

I'm not particularly fond of contractions such as iformat/oformat for
input_format/output_format, maybe some better names could be:


But I agree the gain/loss ratio has to be considered, and maybe the
original names are not that bad to justify the rename.

> and then i dont see any sense in av_ -> avformat_ to begin with especially
> not when EVERY application needs to be changed to adapt to the new name.
> And i hope you know some applications will try to suppport lav* of more than
> one major version number, such renames are VERY painfull and consistency
> to some system that has not even be discussed is NOT a reason to make such
> rename!

Yes, but supporting more than one major versions is not a particularly
bright idea in the first place, anyway a backward compatibility layer
for functions with the same signatures but with different names can
be provided by using macros.

> I could even argue that av_ is bette than avformat_ avcodec_, because it is
> shorter and allows us to move functions between libs which we did do.

This makes sense, unfortunately is not clear which is the rule to
apply, as there are indeed functions for which there wouldn't be much
sense into moving them to another lib, for other ones is not clear if
this could occurr, maybe it would have been better since the beginning
just to use av_ rather than avcodec_ avformat_ etc..

Anyway there are some functions which still lacks an av_ prefix
(guess_stream_format, guess_format), since we're at it it would be a
good idea to rename them before the release (but I'll happily leave it
to someone else for the moment).

FFmpeg = Freak & Foolish Minimal Ponderous Evanescent Guide

More information about the ffmpeg-devel mailing list