Hi all,
I’m building ffmpeg on windows through MinGW; standard build went succesfully, but I have some doubts: what does GRASS need to enable ffmpeg support in it?
I built ffmpeg enabling shared and disabling static libraries, but enabling shared produces only libavutil, libavcodec and libavformat as DLLs, and not a ffmpeg DLL, as I roughly expected (I checked on the official ffmpeg web site, that’s normal, there is any ffmpeg.dll mentioned)
Any suggestions?
Thanks,
Marco
Hi Marco,
I have also recently tried to include ffmpeg in my compilations (Linux
Debian - Sid) and you have to configure with --with-ffmpeg, this will
tell GRASS to count on ffmpeg libs (indeed they seems to be libavcodec
and libavutil as part of ffmpeg and they seem to be checked by
configure).
However I was unsuccessful so far to have configure accept it.
I even tried --with-ffmpeg-includes=/usr/include/ffmpeg
I hope some other people are having enlightenment.
Yann
2008/6/11 <marco.pasetti@alice.it>:
Hi all,
I'm building ffmpeg on windows through MinGW; standard build went
succesfully, but I have some doubts: what does GRASS need to enable ffmpeg
support in it?I built ffmpeg enabling shared and disabling static libraries, but enabling
shared produces only libavutil, libavcodec and libavformat as DLLs, and not
a ffmpeg DLL, as I roughly expected (I checked on the official ffmpeg web
site, that's normal, there is any ffmpeg.dll mentioned)Any suggestions?
Thanks,
Marco
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
marco.pasetti@alice.it wrote:
I'm building ffmpeg on windows through MinGW; standard build went
succesfully, but I have some doubts: what does GRASS need to enable
ffmpeg support in it?
You need to run configure with the --with-ffmpeg switch, and possibly
the --with-ffmpeg-includes= and/or --with-ffmpeg-libs= switches.
I would expect that you need --with-ffmpeg-includes=, as the headers
normally get installed into a subdirectory, but the headers don't
specify the subdirectory when they include each other.
I built ffmpeg enabling shared and disabling static libraries, but
enabling shared produces only libavutil, libavcodec and libavformat as
DLLs, and not a ffmpeg DLL, as I roughly expected (I checked on the
official ffmpeg web site, that's normal, there is any ffmpeg.dll
mentioned)
That's correct (on Linux, I also have libpostproc, but that isn't
required by any of the other libraries).
Configure checks for the headers avcodec.h, avformat.h and swscale.h,
for the function avcodec_init with -lavcodec (and optionally
-lavutil), and for the function av_set_parameters with -lavformat (and
optionally -lavutil).
If using --with-ffmpeg results in configure errors, and you used any
necessary --with-ffmpeg-includes= and/or --with-ffmpeg-libs= switches,
then look in config.log for any error messages.
--
Glynn Clements <glynn@gclements.plus.com>
This is how I got things to compile last time I tried (assuming you
use a similar file structure as I do in your MSYS setup):
Go to [http://ffmpeg.mplayerhq.hu/download.html\] and download the ``bare sources'' (file ffmpeg-export-snapshot.tar.bz2).
./configure --prefix=/usr --enable-shared --disable-static --extra-cflags="-mno-cygwin -mms-bitfields" --extra-ldflags="-Wl,--add-stdcall-alias" --enable-memalign-hack --disable-ffserver --disable-ffplay
Berkeley MPEG Encoder: This is a little utility (aka ppmtompeg) used by r.out.mpeg to generate animated sequences of raster maps.
Unfortunately, the current code on the project's homepage [http://bmrc.berkeley.edu/frame/research/mpeg/mpeg_encode.html\] is not compatible with MinGW.
Thus, the easiest way to install this is to use the port of the ``NetPbm for Windows'' tools, of which ppmtompeg is a part. Go to [http://gnuwin32.sourceforge.net/packages/netpbm.htm\] and download the ``Binaries'' and ``Dependencies'' zip files (netpbm-10.27-bin.zip and netpbm-10.27-dep.zip) to any folder. Extract the files ppmtompeg.exe and libnetpbm10.dll from the first zip file to C:\msys\1.0\bin. Extract the file jpeg62.dll from the second zip file to C:\msys\1.0\bin.
Configure GRASS:
--with-ffmpeg --with-ffmpeg-includes="/usr/include/libavcodec /usr/include/libavformat" --with-ffmpeg-libs=/usr/bin
However, if I remember right, compilation then crashes for
OGSF lib and thus no NVIZ 
However, maybe you will have better luck with the latest sources.
Good luck,
Ben
Glynn Clements wrote:
marco.pasetti@alice.it wrote:
I'm building ffmpeg on windows through MinGW; standard build went
succesfully, but I have some doubts: what does GRASS need to enable
ffmpeg support in it?You need to run configure with the --with-ffmpeg switch, and possibly
the --with-ffmpeg-includes= and/or --with-ffmpeg-libs= switches.I would expect that you need --with-ffmpeg-includes=, as the headers
normally get installed into a subdirectory, but the headers don't
specify the subdirectory when they include each other.I built ffmpeg enabling shared and disabling static libraries, but
enabling shared produces only libavutil, libavcodec and libavformat as
DLLs, and not a ffmpeg DLL, as I roughly expected (I checked on the
official ffmpeg web site, that's normal, there is any ffmpeg.dll
mentioned)That's correct (on Linux, I also have libpostproc, but that isn't
required by any of the other libraries).Configure checks for the headers avcodec.h, avformat.h and swscale.h,
for the function avcodec_init with -lavcodec (and optionally
-lavutil), and for the function av_set_parameters with -lavformat (and
optionally -lavutil).If using --with-ffmpeg results in configure errors, and you used any
necessary --with-ffmpeg-includes= and/or --with-ffmpeg-libs= switches,
then look in config.log for any error messages.
--
Benjamin Ducke
Senior Applications Support and Development Officer
Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.
Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke@oxfordarch.co.uk
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
Hi Glynn,
I succesfully built ffmpeg with the following configure options:
``
--enable-shared --disable-static --enable-gpl
Configure checks for the headers avcodec.h, avformat.h and swscale.h,
for the function avcodec_init with -lavcodec (and optionally
-lavutil), and for the function av_set_parameters with -lavformat (and
optionally -lavutil).
mmm… the configure log it’s long to post it here, but there’s a line that may be interesting:
software scaler enabled no
```you say that configure checks for swscale.h ... maybe software scaler must be enabled?`
```another thing: vhook is not enabled, because it has been replaced by LibAVFilter, and because to build it I need some works around with libraries… so I would be very happy if GRASS would not need it 
… do you know if it is needed?``Many thanks for your help,``Marco`
Da: Glynn Clements [mailto:glynn@gclements.plus.com]
Inviato: gio 12/06/2008 7.04
A: marco.pasetti@alice.it
Cc: grass-dev@lists.osgeo.org
Oggetto: Re: [GRASS-dev] GRASS FFMPEG support
marco.pasetti@alice.it wrote:
I’m building ffmpeg on windows through MinGW; standard build went
succesfully, but I have some doubts: what does GRASS need to enable
ffmpeg support in it?
You need to run configure with the --with-ffmpeg switch, and possibly
the --with-ffmpeg-includes= and/or --with-ffmpeg-libs= switches.
I would expect that you need --with-ffmpeg-includes=, as the headers
normally get installed into a subdirectory, but the headers don’t
specify the subdirectory when they include each other.
I built ffmpeg enabling shared and disabling static libraries, but
enabling shared produces only libavutil, libavcodec and libavformat as
DLLs, and not a ffmpeg DLL, as I roughly expected (I checked on the
official ffmpeg web site, that’s normal, there is any ffmpeg.dll
mentioned)
That’s correct (on Linux, I also have libpostproc, but that isn’t
required by any of the other libraries).
Configure checks for the headers avcodec.h, avformat.h and swscale.h,
for the function avcodec_init with -lavcodec (and optionally
-lavutil), and for the function av_set_parameters with -lavformat (and
optionally -lavutil).
If using --with-ffmpeg results in configure errors, and you used any
necessary --with-ffmpeg-includes= and/or --with-ffmpeg-libs= switches,
then look in config.log for any error messages.
–
Glynn Clements glynn@gclements.plus.com
Hi Benjamin,
I succesfully built ffmpeg with the current configuration:
./configure --prefix=/usr/local/ffmpeg \
--enable-shared \
--disable-static \
--enable-gpl \
--enable-memalign-hack
>Berkeley MPEG Encoder: This is a little utility (aka ppmtompeg) used by
>r.out.mpeg to generate animated sequences of raster maps.
My current configure cuurently supports the following *mpeg* encoders:
mpeg1video
mpeg2video
mpeg4
msmpeg4v1
msmpeg4v2
msmpeg4v3
are they enough for r.out.mpeg or does it mandatory need the Berkeley MPEG Encoder?
>Extract the
>file jpeg62.dll from the second zip file to C:\msys\1.0\bin
In the current MSYS environment I'm developing I added the jpeg library built from source with MinGW (this because I already tried to link the Sourceforge library with libtiff and other libs/apps, and it failed... I don't know why... maybe built with Visual Studio?)
Here there's the configuration log of my current FFMPEG build: [http://www.webalice.it/marco.pasetti/temp/grass_wip/BuildFromSource.html#FFMPEG](http://www.webalice.it/marco.pasetti/temp/grass_wip/BuildFromSource.html#FFMPEG)
Thanks,
Marco
Benjamin:
> Berkeley MPEG Encoder: This is a little utility (aka
> ppmtompeg) used by r.out.mpeg to generate animated sequences of
> raster maps.
I think the ppmtompeg version from NetPBM contains fixes and is better maintained than the Berkley mpeg_encode version, so NetPBM is preferred.
MPEG-1 is many years/generations old, out of date, and does a crappy job. MPEG-4 etc. do a much better job, in much less time, and into smaller files.
The only thing MPEG-1 has going for it is that it is in the public domain and there are no patent claims against it so it may be used with FOSS without worry. (even if there were I guess they would have expired by now)
I am no expert about this stuff, but even FOSS MPEG-4 codecs like Xvid, while "free" code themselves, could violate algorithm patents in places that recognize those. maybe the --gpl flag you used with ffmpeg tends to those issues?
Marco:
I succesfully built ffmpeg with the current configuration:
...
My current configure cuurently supports the following
*mpeg* encoders:
mpeg1video
mpeg2video
mpeg4
msmpeg4v1
msmpeg4v2
msmpeg4v3are they enough for r.out.mpeg or does it mandatory need
the Berkeley MPEG Encoder?
r.out.mpeg does not use FFMPEG. It relies on the ppmtompeg program which comes with NetPBM tools to do the encoding.
FFMPEG is only used in NVIZ to support automatic creation of movies from the keyframe animator, instead of just dumping the individual frames to a series of files which you would then feed into a movie encoder yourself.
It tries to do tricks like decide which encoder to use based on the file extension you use for the output file name. I would mention that this part of the NVIZ code is rather young and lightly tested.
If GRASS does not include FFMPEG it just means you need your own encoder to create the movies from the series of frame images instead of it happening automatically.
Hamish
Hi all,
I built GRASS (wow! 1 hour against the 3 hours needed on my old machine… and I added the JPEG and the FFMPEG support, previously unconfigured!).
NVIZ build failed, because of the following errors:
(cd /usr/local/src/grass-6.3.0/dist.i686-pc-mingw32/lib; ln -f -s libgrass_ogsf.6.3.0.dll /usr/local/src/grass-6.3.0/dist.i686-pc-mingw32/lib/libgrass_ogsf.dll)
OBJ.i686-pc-mingw32/gsd_img_mpeg.o: In function gsd_close_mpeg': C:/MSYS/local/src/grass-6.3.0/lib/ogsf/gsd_img_mpeg.c:182: undefined reference to av_free’
C:/MSYS/local/src/grass-6.3.0/lib/ogsf/gsd_img_mpeg.c:183: undefined reference to `av_free’
collect2: ld returned 1 exit status
make: *** [/usr/local/src/grass-6.3.0/dist.i686-pc-mingw32/lib/libgrass_ogsf.6.3.0.dll] Error
C:\MSYS\mingw\bin..\lib\gcc\mingw32\3.4.5........\mingw32\bin\ld.exe: cannot find -lgrass_ogsf
collect2: ld returned 1 exit status
make[1]: *** [nvwish.exe] Error 1
make[1]: Leaving directory `/usr/local/src/grass-6.3.0/visualization/nviz/src’
make: *** [default] Error 2
it seems that all is generated by the undefined reference to the av_free function. I googled for it and found as follows:
http://www.irisa.fr/texmex/people/dufouil/ffmpegdoxy/mem_8c.html#0c9096f498624c525aa2315b8a20c411
on the following page you can find all the information on how I configured and built both FFMPEG and GRASS:
http://www.webalice.it/marco.pasetti/temp/grass_wip/BuildFromSource.html
Thanks for your help,
Marco
marco.pasetti@alice.it wrote:
I built GRASS (wow! 1 hour against the 3 hours needed on my old
machine...
I know building GRASS on Windows is slower than Linux, but that's
crazy. On my Linux system, it takes around 4 minutes:
$ time make -j 4 &> build.log
real 4m4.969s
user 5m58.420s
sys 1m4.099s
That's the new one (2.2GHz Core2 Duo, 2GiB RAM), but even the old one
(800MHz P3, 512MiB RAM) only took around half an hour.
NVIZ build failed, because of the following errors:
(cd /usr/local/src/grass-6.3.0/dist.i686-pc-mingw32/lib; ln -f -s libgrass_ogsf.6.3.0.dll /usr/local/src/grass-6.3.0/dist.i686-pc-mingw32/lib/libgrass_ogsf.dll)
OBJ.i686-pc-mingw32/gsd_img_mpeg.o: In function `gsd_close_mpeg':
C:/MSYS/local/src/grass-6.3.0/lib/ogsf/gsd_img_mpeg.c:182: undefined reference to `av_free'
C:/MSYS/local/src/grass-6.3.0/lib/ogsf/gsd_img_mpeg.c:183: undefined reference to `av_free'
When posting error messages, please include the command which
generated the error.
AFAICT, av_free should be defined in libavutil. The configure script
performs the tests first without -lavutil, then (if that fails) with
it.
However, as OGSF uses av_free directly, configure should really be
testing explicitly for libavutil. It isn't necessary on Linux, but
Windows handles DLLs differently.
For now, I suggest manually adding -lavutil to the FFMPEGLIB setting
in include/Make/Platform.make.
I have committed a fix (r31695) to SVN trunk.
--
Glynn Clements <glynn@gclements.plus.com>
marco.pasetti@alice.it wrote:
I succesfully built ffmpeg with the following configure options:
--enable-shared --disable-static --enable-gpl
>Configure checks for the headers avcodec.h, avformat.h and swscale.h,
>for the function avcodec_init with -lavcodec (and optionally
>-lavutil), and for the function av_set_parameters with -lavformat (and
>optionally -lavutil).mmm... the configure log it's long to post it here, but there's a
line that may be *interesting*:software scaler enabled no
you say that configure checks for swscale.h ... maybe software
scaler must be enabled?
No, gsd_img_mpeg.c includes <swscale.h>, and creates a couple of
variables with types from that header, but the variables are never
actually used. If I remove the variables and the inclusion of
<swscale.h>, OGSF and NVIZ both compile without problems.
another thing: vhook is not enabled, because it has been replaced by
LibAVFilter, and because to build it I need some works around with
libraries... so I would be very happy if GRASS would not need it
... do you know if it is needed?
I'm fairly sure that GRASS doesn't need it. AFAICT, the vhook
libraries are only used as plugins (dynamically loaded at run time),
and never linked to directly.
--
Glynn Clements <glynn@gclements.plus.com>
Hi Glynn,
`>I know building GRASS on Windows is slower than Linux, but that's` `>crazy. On my Linux system, it takes around 4 minutes:`
Consider that I'm on an Intel Core2 Duo 2.5GHz (T9300, with 6MB of L2 cache!) with 4Gb of RAM DDR2 (even if Vista actually uses only 3)!
When compiling the processors don't run at full speed, while on my old machine (AMD Athlon64 3000+, 1.8Gh and 1.25GB RAM DDR) the CPU ran at full throttle for 3 hours, with the fan sounding like a Boeing taking off! The whole MSYS environment + GRASS compiling took more than 10 hours with the CPU at its 100%...
`>When posting error messages, please include the command which` `>generated the error.`
Sorry, I thought it was clear that it was simply the make command
`>However, as OGSF uses av_free directly, configure should really be` `>testing explicitly for libavutil. It isn't necessary on Linux, but` `>Windows handles DLLs differently.`
mmm... probably I need to make things more clear than they actually are now for me!
avutil.dll is in the same place where the other ffmpegs DLLs are!
but there's another thing that I don't undestand: when I create a ddl with gcc on MinGW I usually do as follows:
`
gcc -shared -s -o libname.dll -Wl,–out-implib,libname.a $LIBOBJECTS
where libname.dll and libname.a are usually installed in /usr/local/bin and /usr/local/lib respectively; and when I create an executable that uses that library I do:
gcc -s -g -O2 -o exename.exe $EXEOBJECTS -L./ -lname
I’m mainly referring to those articles:
http://www.mingw.org/docs.shtml#compilingandbuilding
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options
The strange thing is that there are no .a import library files created by FFMPEG, while I always have them for each library I compiled!
Last thing: the FFMPEG make script installed the DLLs in /ffmpeg/bin, while the /ffmpeg/lib dir is empty, except for the pkgconfig folder, that contains the libav.pc files; I googled for them, but I didn’t find relevant information on what they exaclty are. Do you know some useful articles about that, please?
Thanks for your help,
Marco`
marco.pasetti@alice.it wrote:
>When posting error messages, please include the command which
>generated the error.Sorry, I thought it was clear that it was simply the make command
No, I mean the "gcc ... -shared" command which actually links the
library. That's what is generating the errors.
>However, as OGSF uses av_free directly, configure should really be
>testing explicitly for libavutil. It isn't necessary on Linux, but
>Windows handles DLLs differently.mmm... probably I need to make things more clear than they actually are now for me!
avutil.dll is in the same place where the other ffmpegs DLLs are!
The problem is that lib/OGSF/Makefile doesn't actually specify that
-lavutil is required when building the OGSF DLL.
It isn't needed on e.g. Linux, because shared libraries are allowed to
contain unresolved symbols. Those symbols need to be supplied at
run-time, but that happens because libavformat and libavcodec both
depend upon libavutil, so it gets loaded anyhow.
But Windows requires all symbols to be resolved at the point that you
build a DLL. As the OGSF DLL uses av_free() directly, -lavutil must be
specified.
but there's another thing that I don't undestand: when I create a ddl with gcc on MinGW I usually do as follows:
gcc -shared -s -o libname.dll -Wl,--out-implib,libname.a $LIBOBJECTS
where libname.dll and libname.a are usually installed in
/usr/local/bin and /usr/local/lib respectively; and when I create an
executable that uses that library I do:gcc -s -g -O2 -o exename.exe $EXEOBJECTS -L./ -lname
I'm mainly referring to those articles:
http://www.mingw.org/docs.shtml#compilingandbuilding
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-OptionsThe strange thing is that there are no *.a import library files
created by FFMPEG, while I always have them for each library I
compiled!
AFAICT, you don't actually need import libraries; you can just link
directly against the DLL.
Last thing: the FFMPEG make script installed the DLLs in
/ffmpeg/bin,
Windows doesn't have a separate search path for DLLs, it just looks in
$PATH. For Cygwin/MinGW, the "lib" directories are only used for
import libraries; DLLs go in the "bin" directory as that will already
be in $PATH.
while the /ffmpeg/lib dir is empty, except for the
pkgconfig folder, that contains the libav*.pc files; I googled for
them, but I didn't find relevant information on what they exaclty
are. Do you know some useful articles about that, please?
*.pc are pkg-config files. On Linux, the "official" way to determine
the CFLAGS/LDFLAGS required to use a particular package is e.g.:
$ pkg-config --cflags libavcodec
-I/usr/include/ffmpeg
$ pkg-config --libs libavcodec
-lavcodec -lz -la52 -lmp3lame -lx264 -lxvidcore -lfaac -lfaad -ldl -lX11 -lXext -ltheora -lvorbisenc -lavutil -lvorbis -lm -logg
Except that most of the -l switches are only necessary if you're using
static libraries, so everyone now adds -Wl,--as-needed to ignore the
redundant -l switches from pkg-config (and from libtool's .la files).
We don't use pkg-config for FFMPEG (we only use it for cairo at the
moment), so this isn't an issue.
--
Glynn Clements <glynn@gclements.plus.com>
Hi Glynn,
No, I mean the "gcc ... -shared" command which actually links the
library. That's what is generating the errors.
well... sure, sorry
I attached it because it's very long, and I think it would make the e-mail text too dirty if inserted inline.
The problem is that lib/OGSF/Makefile doesn't actually specify that
-lavutil is required when building the OGSF DLL.
[...]
ok. gotcha.
Windows doesn't have a separate search path for DLLs, it just looks in
$PATH. For Cygwin/MinGW, the "lib" directories are only used for
import libraries; DLLs go in the "bin" directory as that will already
be in $PATH.
[...]
thanks. meanwhile I better googled for it, and I found as follows:
from: http://www.mingw.org/MinGWiki/index.php/sample%20DLL
The import library created by the "--out-implib" linker option is required iff (==if and only if) the DLL shall be interfaced from some C/C++ compiler other than the MinGW toolchain. The MinGW toolchain is perfectly happy to directly link against the created DLL.
*.pc are pkg-config files. On Linux, the "official" way to determine
the CFLAGS/LDFLAGS required to use a particular package is e.g.:
[...]
thanks again. You're my personal Wikipedia on software engineering... but a lot better than Wikipedia
Regards,
Marco
ogsf_error (3.94 KB)