[XviD-devel] last request
Christoph Lampert
chl at math.uni-bonn.de
Sun Feb 23 12:16:31 CET 2003
On Sun, 23 Feb 2003, Radek Czyz wrote:
> Hello,
>
> > Yes, that was reported on the Mplayer (or ffmpeg?)-list already.
> > Since Syskin's changes, cbpy_tab is exported, which conflicts with
> > ffmpeg.
>
> Actually, I never commited these changes, I just proposed them.
I meant the wonderful introduction of "MODEDECISION_BITS" which
unfortunately needs to access some structures which were only static
before.
> However, let me please tell you one thing: the idea to link coding
> libraries directly to encoding/decoding applictions, without any kind
> of standard interface, just asks for conflicts like this.
That's what static linking is about. Linking the library to the code.
An "interface" is needed for calling the routines, how should there be
an interface for "linnkig"?
> I would really like to understand why mplayer developers disgust
> any standard codec interface. Just because such interface is "a brain
> damaged microsoft's idea" is no argument.
Let's stay constructive, okay? The problem appears in the moment where you
try to link both xvidcore and ffmpeg statically to any software,
e.g. mplayer. It has nothing to do with not using standard interfaces.
Mplayer uses native XVID API just as any other (reasonable) program
on UN*X.
Btw. ffmpeg developers added a "ff_" prefix to may of their
structure/routines to make the names unique. We should do the same.
I see no reason why statical linking shouldn't be allowed, I like to link
statically very much, because then my programs continue running even when
I recompile and install xvid.
gruel
More information about the XviD-devel
mailing list