Le 21 mai 09 à 21:00, Niels Grewe a écrit : > On Thu, May 21, 2009 at 06:32:24PM +0200, Quentin Mathé wrote: > >> However I'm not sure to understand why the patch is needed, does the >> current version refuses to build on your Debian system because the >> explicit include >> 'ADDITIONAL_OBJCFLAGS += -I/usr/include/libavcodec -I/usr/include/ >> libavformat' prevents the header to be corrrectly searched in /usr/ >> include/ffmepg/libav*? > > Somethink like that: pkg-config returns "/usr/include/ffmpeg"
ok, that's what I get on Ubuntu 7.10 too. libav* versions on this system are 3:0.cvs20070307-5ubuntu4. In other words, these libav* versions are older than the 2008 versions which reorganized the headers and led to a change of the include style. > and > expects ffmpeg's new convention of including <libavcodec/libavcodec.h> This is weird, if the include path is /usr/include/ffmpeg, the headers should be located at /usr/include/ffmpeg/libav*.h … See also the rest of my reply, I later conclude I could be wrong on that. > instead of <libavcodec.h>. So previously, I had "/usr/include/ffmpeg" What do you mean by 'previously' exactly? Before applying your patch? > and (per workaround) "/usr/include/libav(codec|format)" in the search > path: The latter is non-existant and neither of which contain the > relevant header files for the old include style. > "/usr/include/ffmpeg/libav(codec|format)" was never even considered. If the headers libavformat.h and libavcodec.h are in /usr/include/ ffmpeg/, they should be found since we still use the old header include style #include <libav(codec|format).h>. Is your Debian version using a recent FFMpeg version and putting the headers in something like /usr/include/ffmpeg/libavcodec/libavcodec.h rather than /usr/include/libavcodec/libavcodec.h ? If that's the case, I understand better why your patch is useful. I'm just asking that to be sure where the problem really is… When I modified MediaKit to compile on recent Ubuntu versions, I didn't touch these includes to avoid breaking compatibility with old systems. If we update those to be #include <libav*/libav*.h> as required now by FFMpeg team, we need to modify the MediaKit headers at compilation time as other projects do with autotools. >> This GNUmakefile as it is was working for me on older Ubuntu systems >> using the same include path as yours. > > That's odd. I really think it shouldn't. Unless of course Ubuntu did > modify the .pc-file to point to the "correct" include paths. I just tested it again and it works fine for me on Ubuntu 7.10, where 'pkg-config --cflags libav*' returns -I/usr/include/ffmpeg The comment in the GNUmakefile explains what is the goal of this workaround and where I tested it. What would be the correct include path in this case? >> Looks far better than the current hack :-) I still need to test this >> patch and the previous one on an old Ubuntu system though. >> I think the comment with the Ubuntu bug reference should be moved to >> MKMediaFile.m too since this problem is Ubuntu specific. Do you have >> the same issue on Debian too? > > On re-reading the bug-report, I'm starting to wonder what has been the > issue there: The ffmpeg APIs are a moving target, so marking stuff as > deprecated that will go away in the foreseeable future is actually a > good thing. I'd only consider it a bug if the warnings are issued even > if the deprecated features aren't used. > If this is the case here, removing the deprecation-hack was probably > jumping to conclusions. Especially since I just saw that > avcodec_decode_audio2() was deprecated very recently. For now it seems > expedient to keep the "#define attribute_deprecated". Perhaps it could > be made conditional on a broken libavcodec version? I took a look at that. In fact, the problem is unrelated to avcodec_decode_audio2() deprecation. The issue is that FFMpeg had an incorrect attribute_deprecated on struct ImgReSampleContext back in 2007, and my Ubuntu version snapshot of FFMpeg includes the issue which was later fixed in the FFMpeg repository with this commit: <http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=ddfe4c1de1fe867a032af244fe9b13e420647e5a > The other part of the problem is that package was fixed only in Hardy and never backported to Ubuntu 7.10 aka Gutsy (see the last post on the bug report which mentions 'ffmpeg (3:0.cvs20070307-5ubuntu6) hardy; urgency=low'), which means we have to keep the workaround to maintain compatibility with Ubuntu versions older than Hardy which use a broken snapshot of FFMpeg. They seems to increment the version number during the development cycle too and not only for releases from what I have read though. However I think it is not worth the complexity to test for a broken libavcodec version, since the library is a snapshot which doesn't exactly match a version increment. > Anyways, thank you very much for your feedback. I have refined the > patches accordingly. Result attached. Your latest patches both works fine on Ubuntu 7.10. I didn't retest them on Ubtuntu 9.04, but they should be ok seeing that you just incorporated the minor fix I reported. We should keep the check for avcodec_decode_audio2, it's a welcome improvement. We should just match avcodec.h which declares it like that: #if LIBAVCODEC_VERSION_MAJOR < 53 <--- and not as it is currently in the patch LIBAVCODEC_VERSION_INT < ((52<<16)+(25<<8)+0) attribute_deprecated int avcodec_decode_audio2(AVCodecContext *avctx, int16_t *samples, int *frame_size_ptr, const uint8_t *buf, int buf_size); #endif Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
