Hi Ulrich,
> I can see that you might be reluctant to compile everything from
> scratch. Still, the release is distributed as a dmg and should install
> without dependencies, so it links most libraries statically. I need a
> source tarball build for that and I'm reluctant to support two build
> strategies. (I'll accept paches that don't break the tarball build, of
> course.)
I understand your point. And then I agree that the best course
of action would be to provide more documentation on building libavg,
be it on top of fink/darwinports or compiling everything from scratch
(duplication of documentation is not so bad as duplication of code ;-).
> In theory, yes. In practice, there are libraries that change APIs way
> too often (most notably ffmpeg and libdc1394) for libavg to support all
> versions.
yes I can see that..
> > The patch takes care of three things:
> >
> > * problems with gcc's alwaysinline attribute. These can be fixed
> > by including <math.h> before other headers, so that the proper
> > macros are in place when needed. This is probably worth committing
> > anyway, because if makes the build behavior more robust.
>
> That does sound like it should be applied. Can you elaborate on what
> 'problems with gcc's alwaysinline attribute' were?
if you don't include <math.h> early, you run into this:
==========================================================
[...]
g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I.. -I/sw/include/ffmpeg
-I/sw/include -MT VideoDemuxerThread.lo -MD -MP -MF
.deps/VideoDemuxerThread.Tpo -c VideoDemuxerThread.cpp -fno-common
-DPIC -o .libs/VideoDemuxerThread.o
/usr/include/architecture/ppc/math.h:179: error: 'always_inline' was
not declared in this scope
/usr/include/architecture/ppc/math.h:179: error: expected `)' before 'inline'
/usr/include/architecture/ppc/math.h:179: error: expected `)' before 'inline'
[... tons of other ensuing errors ...]
==========================================================
the origin of the problem might lie in the headers of ffmpeg
(ffmpeg/common.h probably), so maybe those headers should get patched instead.
One should look better into this.
> > * changes in the API of ffmpeg. I did build against the latest SVN version
> > of ffmpeg and that didn't change things: the patch was still needed.
> > The build system should probably require a recent enough version
> > of the ffmpeg libs (and then the patch should be committed).
>
> We'll need #ifdefs for that (at least for a transition period), because
> different distros use different versions of ffmpeg. Can you give me an
> approximate version number for the api change? Or better yet, a patch
> that includes an #ifdef?
Unfortunately right now I don't have time to look deeper into this,
but it's related to avcodec_flush_buffers() in ffmpeg/libavcodec/utils.c .
I need to patch libavg as follows, to compile against ffmpeg (see my
original message):
--- src/video/FFMpegDemuxer.cpp (revision 2243)
+++ src/video/FFMpegDemuxer.cpp (working copy)
@@ -110,7 +110,7 @@
for (it=m_PacketLists.begin(); it != m_PacketLists.end(); ++it) {
int CurStreamIndex = it->first;
AVStream * pStream = m_pFormatContext->streams[CurStreamIndex];
- avcodec_flush_buffers(pStream->codec);
+ avcodec_flush_buffers(&pStream->codec);
}
}
...however, avcodec_flush_buffers() doesn't seem to have changed since
revision 6002,
so I'm a bit puzzled.
Finally, thanks for the following, which was badly needed ;)
=======
r2241 | coder | 2007-08-19 23:16:10 +0200 (Sun, 19 Aug 2007) | 1 line
Event callbacks now pass the event as a parameter, making
Player::getCurEvent() superflous.
=======
Cheers, Ciro
_______________________________________________
libavg-users mailing list
[email protected]
https://mail.datenhain.de/mailman/listinfo/libavg-users
