[FFmpeg-devel] What's up with the API and ABI?

[Michael Niedermayer]

On Thu, Apr 28, 2011 at 10:00:36PM +1000, Peter Ross wrote:
> On Thu, Apr 28, 2011 at 01:19:35PM +0200, Michael Niedermayer wrote:
> > On Tue, Apr 26, 2011 at 06:29:12PM +0200, Luca Abeni wrote:
> > > Hi all,
> > >
> > > since the infamous ffmpeg/libav split, a good number of programs using  
> > > ffmpeg libraries started to break because of arbitrary renamings...  
> > > That's annoying (it forces me to fill the programs with funky ifdefs to  
> > > support the git checkout of the day), but I can live with it.
> > 
> > Iam unhappy about it as well, the code quality is very much going down
> > since libav does not review patches technically at all and we pull them
> > stefanos qpeg patch from a few hours ago is an
> > example. Its wrong but they want stefano to join libav and leave ffmpeg
> > so its all nice "looks good to me", anyway iam working on fixing that
> > one
> > 
> > 
> > >
> > > But today I found a new interesting bug introduced for the sake of it: I  
> > > had a program calling " url_fopen(&o->outctx->pb, o->output_file,  
> > > URL_WRONLY);" (which was AFAIK legal until some days ago) which started  
> > > to fail in a misterious way.
> > > At the end, I found out that url_fopen() now does "return avio_open(s,  
> > > filename, flags);"... But the avio_open() flags are completely different  
> > > from the url_fopen() flags (AVIO_FLAG_WRITE is 2, while URL_WRONLY is  
> > > 1... Calling url_fopen() with URL_WRONLY results in trying to open a  
> > > file _for reading_!).
> > 
> > oops, fixed locally will push soon
> > thanks alot for reporting
> > 
> > 
> > >
> > > So, if you really want to rename url_fopen() (why? Just because  
> > > avio_open() is more trendy?) you have to either remove url_fopen() and  
> > > its flags, or update the flags values. Keeping a broken url_fopen() is  
> > > much worse than removing it without deprecation.
> > 
> > yes, of course
> 
> Michael, just to clarify...
> 
>  1. the FFmpeg approach is to support both old and new APIS via branches ?

Id love to support both in master, it was the side info change to
AVPackets that made this appear quite hard.
So iam trying it with branches ATM.
nothing is cast in stone here, if some better approach is found


> 
>  2. 'master' branch provides the >= 0.7 API (and is compatible with the many hundreds
>         of api changes introduced by the libav faithful) ?
> 
>  3. 'oldapi' branch provides the <= 0.6.x API ?

master is 0.8 ABI/API
oldabi is 0.6=0.7 ABI/API (Stefano suggested to release a 0.7 with old
ABI/API and 0.8 with new and libav planed the same until recently AFAIK)


> 
>  4. and both branches are functionaly equivalent ?

yes

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110428/fd0a518e/attachment.asc>