xbmc compilation on Linux and external ffmpeg: a complete mess
#16
EricV Wrote:I use 5:0.5+svn20090720-0.0 that is a kind of wrapper for all libraries:

Depends: libavcodec52 (>= 5:0.5+svn20090720), libavdevice52 (>= 5:0.5+svn20090720), libavfilter0 (>= 5:0.5+svn20090720), libavformat52 (>= 5:0.5+svn20090720), libavutil50 (>= 5:0.5+svn20090720), libc6 (>= 2.7), libpostproc51 (>= 5:0.5+svn20090720), libsdl1.2debian (>= 1.2.10-1), libswscale0 (>= 5:0.5+svn20090720)
Suggests: nvidia-libvdpau1


As far as your statement goes regarding /usr/include/ffmpeg you are just wrong (or you mean a .h directly under ffmpeg?). If I use the development files from one of the libraries mentionned above here is what I get:

dpkg -L libavcodec-dev
/.
/usr
/usr/include
/usr/include/ffmpeg
/usr/include/ffmpeg/libavcodec
/usr/include/ffmpeg/libavcodec/opt.h
/usr/include/ffmpeg/libavcodec/vdpau.h
/usr/include/ffmpeg/libavcodec/xvmc.h
/usr/include/ffmpeg/libavcodec/avcodec.h
/usr/include/ffmpeg/libavcodec/dca.h
/usr/lib
/usr/lib/libavcodec.a
/usr/lib/pkgconfig
/usr/lib/pkgconfig/libavcodec.pc
/usr/share
/usr/share/doc
/usr/share/doc/libavcodec-dev
/usr/share/doc/libavcodec-dev/changelog.Debian.gz
/usr/share/doc/libavcodec-dev/changelog.gz
/usr/share/doc/libavcodec-dev/copyright
/usr/lib/libavcodec.so

So even If I have theses headers installed, the configure script does not find them unless I add CPPFLAG=-I/usr/include/ffmpeg

Concerning audioconvert.h, you missed my point that was that DDL* files located in XBMC/xbmc/cores/ffmpeg includes this file and, in order to manage to do this, the preprocessor must have a search path to XBMC/xbmc/cores/ffmpeg that also contains modified ffmpeg headers. As such you have no guaranty to use the external package header file.

So my point is ffmpeg cannot be used as an external library untils this mess is resolved. End of the story.

If you have the resources to maintain your fork yourself no problem but I saw that this was not the preferred path.

Is there really any need for this ranting? I recommend you investigate this issue further before you make your next post.

There is no ffmpeg 5:0.5+svn20090720 in the Debian archive at all. For the Debian multimedia team's git repo that's used to package ffmpeg, the latest version is 4:0.5+svn20090706-1. You can see all this for yourself at packages.qa.debian.org/ffmpeg-debian.

Judging by this, you are probably using the ffmpeg packages from Marillat of debian-multimedia.org. The Debian multimedia team which maintains ffmpeg for Debian has nothing to do with Marillat or debian-multimedia.org for these kind of reasons and others.

FYI, current FFmpeg SVN doesn't even install headers in /usr/include/ffmpeg. They are installed in $(INCDIR)/lib$(NAME). See for yourself (hint: look at subdir.mak:19 of their current SVN HEAD). This is obviously a change Marillat introduced. There are also other changes Marillat has made to his fork of ffmpeg.

Just so you know, I'm using Debian unstable right now and have built XBMC successfully with the debian dir in XBMC SVN using pbuilder (i.e. a clean chroot environment). Like I said already, the ffmpeg packages in Debian are built from the sources that are tracked in the '0.5' branch of ffmpeg. I am also running XBMC in Debian unstable with no issues.
Reply
#17
ceros Wrote:Is there really any need for this ranting? I recommend you investigate this issue further before you make your next post.

There is no ffmpeg 5:0.5+svn20090720 in the Debian archive at all. For the Debian multimedia team's git repo that's used to package ffmpeg, the latest version is 4:0.5+svn20090706-1. You can see all this for yourself at packages.qa.debian.org/ffmpeg-debian.

Judging by this, you are probably using the ffmpeg packages from Marillat of debian-multimedia.org. The Debian multimedia team which maintains ffmpeg for Debian has nothing to do with Marillat or debian-multimedia.org for these kind of reasons and others.

FYI, current FFmpeg SVN doesn't even install headers in /usr/include/ffmpeg. They are installed in $(INCDIR)/lib$(NAME). See for yourself (hint: look at subdir.mak:19 of their current SVN HEAD). This is obviously a change Marillat introduced. There are also other changes Marillat has made to his fork of ffmpeg.

Just so you know, I'm using Debian unstable right now and have built XBMC successfully with the debian dir in XBMC SVN using pbuilder (i.e. a clean chroot environment). Like I said already, the ffmpeg packages in Debian are built from the sources that are tracked in the '0.5' branch of ffmpeg. I am also running XBMC in Debian unstable with no issues.

You are right I'm using the http://www.debian-multimedia.org debian packages (e.g the one from marillat) BUT as probably 98% of debian users! Could you also check the facts for selecting a package from a repository or another?

For me, selecting debian-multimedia.org to get source for multimedia is a must as most official debian packages clearly use thoses packages and not the one form the "Debian multimedia team" for their dependencies as the debian multimedia project provides little compared to debian-multimedia.org.

Even most svn code (not debian packaged/patched like for example k3b for kde4) do now search for this location. You could reuse the sameconfigure trick from it BTW.

I'm also running XBMC for month frequently updating from SVN on 32 bit and 64 bit debian unstable. Just I cannot accept having a 88Mb executable file just because XBMC was initially though as a standalone application and do not use external libraries by default on linux or pretend to be able to use them for building when it cannot.

And compiling using external dependencies is broken for ffmpeg whatever the install location for header file is because you end up using .h files that are not the same as the ones used to build the external library and software assumes modified constant value compared to upstream code (e.g. AVCODEC_MAX_AUDIO_FRAME_SIZE). You just have not noticed it when building (I see no conditionnal in Makefile for the -I../..../ffmpeg)

This remains wrong as the debian multimedia team may change it in a way that is not compatible with your own files modification as long as you do not share the same repository.

althekiller do say it is a known problem and you just seem to pretend it does not existHuh I'm now lost.

I'm not writing here to get a working XBMC on debian! I have one. I just would like to see it build by default on debian and other linux system to avoid having to build it myself but given the actual status, I'm affraid I will have to wait.

And I'm not going to replace my multimedia repo as too many packages I use on a daily basis depend on them.
Reply
#18
EricV Wrote:You are right I'm using the http://www.debian-multimedia.org debian packages (e.g the one from marillat) BUT as probably 98% of debian users! Could you also check the facts for selecting a package from a repository or another?

For me, selecting debian-multimedia.org to get source for multimedia is a must as most official debian packages clearly use thoses packages and not the one form the "Debian multimedia team" for their dependencies as the debian multimedia project provides little compared to debian-multimedia.org.

Even most svn code (not debian packaged/patched like for example k3b for kde4) do now search for this location. You could reuse the sameconfigure trick from it BTW.

I'm also running XBMC for month frequently updating from SVN on 32 bit and 64 bit debian unstable. Just I cannot accept having a 88Mb executable file just because XBMC was initially though as a standalone application and do not use external libraries by default on linux or pretend to be able to use them for building when it cannot.

And compiling using external dependencies is broken for ffmpeg whatever the install location for header file is because you end up using .h files that are not the same as the ones used to build the external library and software assumes modified constant value compared to upstream code (e.g. AVCODEC_MAX_AUDIO_FRAME_SIZE). You just have not noticed it when building (I see no conditionnal in Makefile for the -I../..../ffmpeg)

This remains wrong as the debian multimedia team may change it in a way that is not compatible with your own files modification as long as you do not share the same repository.

althekiller do say it is a known problem and you just seem to pretend it does not existHuh I'm now lost.

I'm not writing here to get a working XBMC on debian! I have one. I just would like to see it build by default on debian and other linux system to avoid having to build it myself but given the actual status, I'm affraid I will have to wait.

And I'm not going to replace my multimedia repo as too many packages I use on a daily basis depend on them.

No. Absolutely no official Debian package is using any dependencies outside of the packages that are in Debian main, to include any packaging in debian-multimedia.org.

If there are any packages found to be depending on any package outside the Debian archive, then it would be a policy violation in Debian which would warrant a bug with severity 'serious'.

Also, just because 98% or however many Debian users are using a buggy package does not imply that we should start having XBMC support using them.
Reply
#19
EricV Wrote:.........
I'm also running XBMC for month frequently updating from SVN on 32 bit and 64 bit debian unstable. Just I cannot accept having a 88Mb executable file just because XBMC was initially though as a standalone application and do not use external libraries by default on linux or pretend to be able to use them for building when it cannot.............

88mb is only a debug build the release build is about 7 to 8 mb
Reply
#20
12MB, 11 stripped Wink
Reply
#21
althekiller Wrote:12MB, 11 stripped Wink

Ahh well it grew a little since the early days when I used to check then Smile
Reply
#22
ceros Wrote:No. Absolutely no official Debian package is using any dependencies outside of the packages that are in Debian main, to include any packaging in debian-multimedia.org.

If there are any packages found to be depending on any package outside the Debian archive, then it would be a policy violation in Debian which would warrant a bug with severity 'serious'.

Also, just because 98% or however many Debian users are using a buggy package does not imply that we should start having XBMC support using them.

You are right. After checking the reverse dependencies, all package using ffmepg or its own dependencies do indeed come from debian-multimedia.org. I have so many of them that I did not check. Some package explicitly depends on ffmpeg though like k3b from experimental.

98% users will not benefit from XBMC if it forces using a ffmpeg packages that introduce incompatibilities with what debian-multimedia.org provides.

*buggy* in what? In term of ethical debian policy? or just because they added a directory before the libavxxx directories? Many package having multiple include sub directory do this.
Reply
#23
Jezz_X Wrote:88mb is only a debug build the release build is about 7 to 8 mb

You are right.

local/local-src/XBMC$ ls -l /usr/local/share/xbmc/xbmc.bin
-rwxr-xr-x 1 root staff 90984870 aoû 16 11:42 /usr/local/share/xbmc/xbmc.bin

If I strip I get

ls -l /usr/local/share/xbmc/xbmc.bin
-rwxr-xr-x 1 root staff 11365896 aoû 16 12:11 /usr/local/share/xbmc/xbmc.bin

BUT this is for the following configure option without debug explicitly set:

./configure --enable-external-libraries CFLAGS=-I/usr/include/ffmpeg

as ldd shows (edited because too long):

ldd /usr/local/shar/xbm/xbmc.bin
libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0x00007f1d696ac000)
libwavpack.so.1 => /usr/local/lib/libwavpack.so.1 (0x00007f1d69487000)
libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x00007f1d6923c000)
libmpcdec.so.3 => /usr/lib/libmpcdec.so.3 (0x00007f1d6902e000)
libmpeg2convert.so.0 => /usr/lib/libmpeg2convert.so.0 (0x00007f1d68e28000)
libmpeg2.so.0 => /usr/lib/libmpeg2.so.0 (0x00007f1d68c0a000)
libfaad.so.0 => /usr/lib/libfaad.so.0 (0x00007f1d689c9000)
liba52-0.7.4.so => /usr/lib/liba52-0.7.4.so (0x00007f1d69b0d000)
libmad.so.0 => /usr/lib/libmad.so.0 (0x00007f1d687aa000)
libavcodec.so.52 => /usr/lib/libavcodec.so.52 (0x00007f1d67cb7000)
libswscale.so.0 => /usr/lib/libswscale.so.0 (0x00007f1d67a84000)
libpostproc.so.51 => /usr/lib/libpostproc.so.51 (0x00007f1d67875000)
libavutil.so.50 => /usr/lib/libavutil.so.50 (0x00007f1d67665000)
libavformat.so.52 => /usr/lib/libavformat.so.52 (0x00007f1d67368000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f1d67160000)
libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0x00007f1d66f4f000)
libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0x00007f1d66d43000)
libfaac.so.0 => /usr/lib/libfaac.so.0 (0x00007f1d66b31000)
libhal-storage.so.1 => /usr/lib/libhal-storage.so.1 (0x00007f1d66927000)
libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x00007f1d666e8000)
libcurl.so.4 => /usr/lib/libcurl.so.4 (0x00007f1d6649b000)
...
libmms.so.0 => /usr/lib/libmms.so.0 (0x00007f1d65a0e000)
...
libSDL_mixer-1.2.so.0 => /usr/lib/libSDL_mixer-1.2.so.0 (0x00007f1d64f0a000)
libSDL_image-1.2.so.0 => /usr/lib/libSDL_image-1.2.so.0 (0x00007f1d64cee000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x00007f1d64a33000)
libsmbclient.so.0 => /usr/lib/libsmbclient.so.0 (0x00007f1d6437a000)
...
libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0x00007f1d61ab6000)
libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007f1d616de000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007f1d614b1000)
libogg.so.0 => /usr/lib/libogg.so.0 (0x00007f1d612ac000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007f1d6103b000)
libGLEW.so.1.5 => /usr/lib/libGLEW.so.1.5 (0x00007f1d60de9000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f1d60b6b000)
...
Reply
#24
EricV Wrote:You are right. After checking the reverse dependencies, all package using ffmepg or its own dependencies do indeed come from debian-multimedia.org. I have so many of them that I did not check. Some package explicitly depends on ffmpeg though like k3b from experimental.

98% users will not benefit from XBMC if it forces using a ffmpeg packages that introduce incompatibilities with what debian-multimedia.org provides.

*buggy* in what? In term of ethical debian policy? or just because they added a directory before the libavxxx directories? Many package having multiple include sub directory do this.

ffmpeg is a binary package as well, or do you mean Build-Depends?

This is not a problem with XBMC. If Marillat is interested enough, he will probably pick up XBMC and have packages up on debian-multimedia. Otherwise, these users wanting to use a different version of ffmpeg will have to build packages themselves.

Buggy in terms of leaving public headers in locations not specified by upstream, including headers that are not public by upstream, supporting libraries not supported by upstream, and making his own modifications to ffmpeg. Like I said, Marillat has his own fork of ffmpeg. Debian has nothing to do with debian-multimedia.org.
Reply
#25
ceros Wrote:ffmpeg is a binary package as well, or do you mean Build-Depends?

This is not a problem with XBMC. If Marillat is interested enough, he will probably pick up XBMC and have packages up on debian-multimedia. Otherwise, these users wanting to use a different version of ffmpeg will have to build packages themselves.

Buggy in terms of leaving public headers in locations not specified by upstream, including headers that are not public by upstream, supporting libraries not supported by upstream, and making his own modifications to ffmpeg. Like I said, Marillat has his own fork of ffmpeg. Debian has nothing to do with debian-multimedia.org.

Install is a binary package as well as you can see in the ldd above.

But the install location is not the problem, the XBMC/xbmc/cores/ffmpeg content is. Install location can be fixed by a simple -I addition somewhere or CFLAGS definition. At least, I always manage painlessly in other software!

debug flags should also be turned off by default!
Reply
#26
personally i don't give a rats ass what you think 'should' be default. we would most definitely NOT want debugging off by default.

oh and your god damn exclamation sign key is stuck.
Reply
#27
spiff Wrote:personally i don't give a rats ass what you think 'should' be default. we would most definitely NOT want debugging off by default.

oh and your god damn exclamation sign key is stuck.

So do I :-)

And BTW among the various packages I know, xbmc is the only one that does not strip the debug info by default or more cleverly put debug info into separate files now that gdb knows how to handle them.
Reply
#28
EricV Wrote:I'm not sending patches, I'm just pointing out that the XBMC local ffmpeg header used are different than the one used to compile my external libraries.

I thought you might be interested in reading this web page:
http://forum.xbmc.org/showthread.php?tid...erid=52316

I guess most of the work is done already here and patches are already in svn.
Reply
#29
EricV Wrote:You are right I'm using the http://www.debian-multimedia.org debian packages (e.g the one from marillat) BUT as probably 98% of debian users! Could you also check the facts for selecting a package from a repository or another?

...

And I'm not going to replace my multimedia repo as too many packages I use on a daily basis depend on them.

The good news is that, after discussing with Christian Marillat, now its include files are located at the same location than the """official""" packages so that fixes donne for one pacakes will be compatible with the other.
Reply

Logout Mark Read Team Forum Stats Members Help
xbmc compilation on Linux and external ffmpeg: a complete mess0