@FakeOutdoorsman,
As I was reading your post I was more on the edge of the chair...
I'll wait for your time, thank you.
@FakeOutdoorsman,
As I was reading your post I was more on the edge of the chair...
I'll wait for your time, thank you.
It's perfectly fine to disable libxml2 in libbluray and then you won't have to deal with it at all (libxml2 is used in 'metadata parsing', which I assume from other contexts in libbluray's ./configure that it's more relevant to the Java environment being able to display the BD-J menus - but I'm not aware of any libbluray-based media player that even displays menus for Blu-ray...unless VLC can do it, but to my knowledge neither FFplay nor mpv can). Thus obviating the need to use --extra-cflags/ldflags or --extra-libs:
(these are, of course, cross-compilation instructions, hence the 'mingw' stuff)Code:Dependency: libbluray ===================== cd ~/mpv-build-deps git clone git://git.videolan.org/libbluray.git cd libbluray ./bootstrap CPPFLAGS="-mfpmath=sse -march=pentium3 -msse -mtune=pentium3" \ PKG_CONFIG_PATH=/usr/i686-w64-mingw32/lib/pkgconfig ./configure \ --prefix=/usr/i686-w64-mingw32 --disable-examples --without-libxml2 \ --enable-silent-rules --disable-shared --disable-doxygen-doc \ --disable-doxygen-dot --build=i686-w64-mingw32 --host=i686-w64-mingw32 make sudo checkinstall --pkgname=libbluray-mingw --pkgversion="$(grep Version \ src/libbluray.pc | sed 's/Version: //g')-git" --backup=no --deldoc=yes \ --delspec=yes --deldesc=yes --strip=yes --fstrans=no --default
Regarding yasm, the advisable method of installing it would be with checkinstall (assuming that you're using the tarball):
It installing to /usr/local by default isn't an issue.Code:sudo checkinstall --pkgname=yasm --pkgversion="3:$(cat version)-git" --backup=no --deldoc=yes --delspec=yes \ --deldesc=yes --strip=yes --stripso=yes --addso=yes --fstrans=no --default
And more generally speaking, --bindir isn't necessary to specify unless you're putting it somewhere other than in the --prefix. Setting --prefix to $HOME/ffmpeg_build and then --bindir to $HOME/ffmpeg_build/bin does nothing - the bins are already going to go there anyway. If you wanted the bins in $HOME/bin like FakeOutdoorsman's instructions have, while letting everything else go into their respective subdirs in $HOME/ffmpeg_build, that's when you use --bindir.
Hi qyot27, very complete your answer.
Thank you for the advise related to compilation. I understood that it is not needed to specify a bindir when it is inside the prefix path.
I was not having any problem regarding yasm compilation, even I'm not sure if I'm really compiling with it. Just the hassle to rename yasm version in /usr/bin
I also had no problem compiling libbluray.
I compiled it like FakeOutdoorsman's instructions, but adding before ./configure the PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" instruction.
I did not understand the need of cross-compilation instructions, I'm going to use the binaries in the same computer I'm compiling.
Is it needed to then enable libbluray when compiling ffmpeg?.
I did not understand if after the code you posted you manage to compile ffmpeg with --enable-libbluray.
I will try to compile again libbluray without libxml2 (do I have to add to configure the --without-libxml2 thing?) and try to compile ffmpeg against this libbluray version.
No need for a bindir when compiling a library..
What version of Ubuntu are you using?, libbluray @ 0.6.0 is available for 14.04 & can't see any reason to statically link to ffmpeg (if there is any reason to enable it in ffmpeg in the first place..
Also note the latest libbluray is 0.6.1
(edit: I can assure you that ffmpeg will build with --enable-libbluray if libbluray is shared (libxml2 is not a factor) -
ffmpeg -protocols
ffmpeg version 2.3.3 Copyright (c) 2000-2014 the FFmpeg developers
built on Aug 27 2014 02:08:11 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --extra-libs=-ldl --prefix=/opt/ffmpeg --enable-avresample --disable-debug --enable-nonfree --enable-gpl --enable-version3 --enable-x11grab --enable-libpulse --enable-libopencore-amrnb --enable-libopencore-amrwb --disable-decoder=amrnb --disable-decoder=amrwb --enable-libbluray --enable-libx264 --enable-libx265 --enable-libfdk-aac --enable-libvorbis --enable-libmp3lame --enable-libopus --enable-libvpx --enable-libspeex --enable-libass --enable-avisynth --enable-libsoxr
libavutil 52. 92.100 / 52. 92.100
libavcodec 55. 69.100 / 55. 69.100
libavformat 55. 48.100 / 55. 48.100
libavdevice 55. 13.102 / 55. 13.102
libavfilter 4. 11.100 / 4. 11.100
libavresample 1. 3. 0 / 1. 3. 0
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100
Supported file protocols:
Input:
bluray
cache
..ectldd /usr/bin/ffmpeg |grep libbluray.so.1
libbluray.so.1 => /usr/lib/x86_64-linux-gnu/libbluray.so.1 (0x00007fa4a64d1000
Last edited by mc4man; August 27th, 2014 at 03:23 AM.
Ubuntu 12.04 here
But the problem was not with libluray compilation, it compiled apparently well, with --bindir="$HOME/ffmpeg_build/bin" and --disable-shared.
And as result I find under $HOME/ffmpeg_build/bin the bd_info binary, and under $HOME/ffmpeg_build/lib the files libbluray.a and libbluray.la and pkgconfig folder with libbluray.pc, and finally under $HOME/ffmpeg_build/include a libbluray folder.
I prefer to keep everything locally because I'm afraid that a newer version of libbluray or yasm or ffmpeg can be incompatible with the rest of my system.
And in this link https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu it's explained the way to compile everything locally.
I just want to add latest libbluray support to the compiling process detailed in that link.
A) There's no reason to go around renaming the yasm binary. 'which yasm' will tell you which one is being used if there's more than one installed. The PATH environment variable prefers /usr/local over /usr, so compiling yasm yourself means that since it goes into /usr/local, it would pick up on that one first.
B) The point of posting those instructions was to illustrate the --without-libxml2 option. Not a recommendation to cross-compile things.
C) Building everything/multiple parts as static very often leads to needing to use the --pkg-config-flags="--static" option when configuring ffmpeg. A static libbluray may need this if it links to a shared libxml2, and the option might not be necessary for libbluray if it was built without libxml2. Or, like mc4man pointed out, building libbluray as shared causes no conflict with a shared libxml2.
In Debian sid ffmpeg has comeback as binaires & shared though to what actual advantage I really can't see.
As it stands nothing will use the shared libs other than the ffmpeg binaires, to do so they'd need to be rebuilt against FFmpeg. (libavcodec-ffmpeg-dev, ect.
Are they going to offer 'dual' packaging? (I doubt that), so users would need to build themselves or use some semi outside pre-built packages. (deb-multimedia or ppa's
As far as the binaires this is for example the config on ffmpeg (plus 2 added by me, --enable-nonfree, - libfdk-aac, feels like kitchen sink minus decent aac
Are there any enables here that are to good advantage over what's typically used for static builds?Code:$ ffmpeg ffmpeg version 2.4.2-1 Copyright (c) 2000-2014 the FFmpeg developers built on Oct 10 2014 15:27:21 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1) configuration: --prefix=/usr --extra-version=1 --build-suffix=-ffmpeg --toolchain=hardened --extra-cflags= --extra-cxxflags= --libdir=/usr/lib/x86_64-linux-gnu --shlibdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --enable-shared --disable-stripping --enable-avresample --enable-avisynth --enable-fontconfig --enable-frei0r --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libcaca --enable-libcdio --enable-libflite --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencv --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-openal --enable-opengl --enable-x11grab --enable-libxvid --enable-nonfree --enable-libfdk-aac --enable-libdc1394 --enable-libiec61883 --enable-libzvbi --enable-libzmq --enable-libbs2b
(am curious about the --enable-opengl one - what for?, (ffplay?
Last edited by mc4man; October 13th, 2014 at 08:52 PM. Reason: readibility of code box
I'm not sure what the packaging plans are. I haven't been paying attention.
Looks like a lof of extra fluff in there. For example I doubt general users need WebPee support among several others, but I guess they want to be on the "safe side" since you never know what users really want. Personally I haven't used half of those options.
As for the opengl output device I'm not really familiar with that. Could be useful or interesting for a few application developers I guess. Not a very helpful answer...
Yeah, seems like safe side, ect. though don't get their aac deal, only native encoder (maybe it's gotten better?
overall they state - (from rules file
# Enable as many features as possible, as long as the result is still GPLv2+ (and not only GPLv3+).
Also don't get the --enable-libopencv option, both as in value being enabled & because of deps
(- to enable then libopencv-highgui-dev will be installed which deps on libavcodec-dev, libavformat-dev, ect. so the ffmpeg shared libs will dep on libav shared libs
It's better than libvo_aacenc at least. Improvements have been made in the "AAC mega thread", but I don't think they've been squashed and committed.
AFAIK this is for the dilate, erode, and smooth filters via the ocv filter. I've never used it and I've never seen any users try it. Almost like the frei0r stuff but probably less useful. I'm guessing, due to your rules file observation, that it was possibly enabled without evaluating its actual usefulness.
Might be bug report worthy.
Bookmarks