[FFmpeg-devel] [PATCH] metadata compatibility layer (part2)

[Aurelien Jacobs]

Michael Niedermayer wrote:

> On Wed, Jan 07, 2009 at 11:25:50PM +0100, Aurelien Jacobs wrote:
> > Michael Niedermayer wrote:
> > 
> > > On Wed, Jan 07, 2009 at 01:21:07AM +0100, Aurelien Jacobs wrote:
> > > > Hi,
> > > > 
> > > > Hi attached patch is the second (and final) part of the metadata
> > > > compatibility layer. It adds compatibility in the other way around.
> > > > When a demuxer read metadata and stores it with av_metadata_set(),
> > > > it automatically fill the old API metadata fields, so that a
> > > > software using the old API is still able to get metadata from
> > > > demuxers using the new API.
> > > > 
> > > > It is slightly ugly, especially the AVFormatContext pointer stored
> > > > in the AVMetadata struct, but that's the cleanest way I found.
> > > > As the struct is not exposed in public API and all of this is
> > > > just a temporary transition code, I think it is acceptable.
> > > 
> > > I think this code is too ugly, i was already very unhappy about the
> > > last of these compatibility patches but this one is just too much.
> > > I do not want this or anything similar in a file i have to maintain.
> > 
> > Well, if that's the only problem, I can maintain that file ;-)
> > Anyway, this code shouldn't require much maintenance (if any).
> > 
> > > Id much rather bump the major version several times.
> > 
> > >From our side, it's obviously much easier to bump major version
> > and not care about old API at all.
> > But from the side of the libav* users (and distro maintainers,
> > etc...) it's much more painful to support such harsh API change.
> > For software using lavf it means either:
> >  - stay with the old API and be unusable with ffmpeg's svn
> >  - upgrade to new API and be unusable with disto's packaged
> >    ffmpeg (ie. the majority of users)
> >  - add an equivalent compatibility layer in the software itself
> >    (or clutter the code with #ifdef), which leads to code
> >    duplication in every software using lavf
> > And obviously different software will choose different solutions,
> > which will lead many people compiling software against FFmpeg
> > to problems, and not the same problems depending on the
> > software they build.
> > This IMO leads to a big mess, and this is the kind of thing
> > which tarnish ffmpeg's reputation.
> > So IMO, avoiding this is worth a few dozen line of temporary
> > code properly under #if.
> 
> could all this "code" not be put in a seperate file instead of
> metadata.c/h ?

Sure ! I moved this code in metadata_compat.c.
I also used Ronald's idea (thanks!) to avoid putting
AVFormatContext* in AVMetadata. So now the patch contains just
very minimal changes to actual code, and the compatibility
layer is self contained in metadata_compat.c.
After this one is applied I will also move the first compat
function to metadata_compat.c so that metadata.c will stay
small/simple/beautiful...

Aurel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: md_compat3.diff
Type: text/x-patch
Size: 5621 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090108/4846c0d1/attachment.bin>