[MPlayer-dev-eng] [PATCH] AVCodecTag redefined when using external libavformat

[Reimar Döffinger]

Hello,
On Sun, Feb 04, 2007 at 04:21:18PM +0100, Michael Niedermayer wrote:
> On Sun, Feb 04, 2007 at 02:18:15PM +0100, Reimar Döffinger wrote:
> > On Sun, Feb 04, 2007 at 01:19:16PM +0100, Nico Sabbi wrote:
> > > Michael Niedermayer wrote:
> > > >>calling av_codec_get_tag() and av_codec_get_id() requires as 
> > > >>parameters the tables we actually need, so how can they be useful in 
> > > >>this case?
> > > >
> > > >
> > > >avi_muxer.codec_tag can be passed to them
> > > >
> > > >and the additional tables mplayer uses cannot use AVCodecTag they can
> > > >use MPCodecTag (which may or may not be the same / is copy and pasted
> > > >but wont break if AVCodecTag changes)
> > 
> > Huh? What does changing the name help? It will still break because we
> > call a function that wants an AVCodecTag struct.
> 
> yes and you MUST NOT call that with your MPCodecTag!!!!!!!!!!!!!!!
> but only with the opaque AVCodecTag which you CANNOT use for mplayers private
> tables
> 
> so again, options are:
> 1. keep code as it is and live with the occasional breakage due to use of
>    internal lav* stuff which isnt supposed to be used
> 2. use your own lav* independant 20lines of code to manage your own tables
>    (this can be copy and pasted from lav* but must be renamed to avoid name
>    clashes)
> 3. propose on ffmpeg-dev that AVCodecTags internal structure should be
>    exported so that mplayer can use it and avoid 20 lines of code duplication
[...]

Well, is the second proposed patch that bad? It would keep including
riff.h for static builds so any breakage should hopefully be noticed very
quickly but gets rid of the riff.h dependency for dynamic linking
(though I personally think it's not that much of a problem to copy
riff.h into the MPlayer tree if you really, really have to insist on not
having the libavcodec externals).
And yes I know it can not be considered a final solution, option 3 is
but that should not be hurried.
Why I despise 2) is that my experience is that this duplication will not
be removed anywhen before the next century even if it's no longer
necessary...

Greetings,
Reimar Döffinger