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

[Michael Niedermayer]

Hi

On Sun, Feb 04, 2007 at 04:49:23PM +0100, Reimar Döffinger wrote:
> 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...

well, "solve" it whichever way you like best

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

Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070204/f6827fc7/attachment.pgp>