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

Michael Niedermayer michaelni
Thu Jan 8 00:23:16 CET 2009


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 ?

i mean the actual code is 1 page and then half a dozen pages of these old API
compatibility hacks.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/20090108/cc7953ed/attachment.pgp>



More information about the ffmpeg-devel mailing list