Hi, I need to build ffmpeg on Windows. I find that it is currently available on Linux. There were some instructions for building it on Windows by using MinSYS and MinGW but I had a tough time in making use of them for this purpose. Can anyone of you tell me if there is a MSVC workspace (*.dsw) or a project (*.dsp) available which I can use directly? I tried building a MSVC workspace using the ffmpeg files but I found that many files have main() and I was not sure how to build them. Another thing I would like to know is can I find a complete list of codecs (audio and video) which are supported by the container formats AVI, ASF and MPG? I need to build a transcoder which can take inputs in these container formats. Thanks in advance, Kiran
Kiran Tulasi wrote:
I need to build ffmpeg on Windows. I find that it is currently available on Linux. There were some instructions for building it on Windows by using MinSYS and MinGW but I had a tough time in making use of them for this purpose. Can anyone of you tell me if there is a MSVC workspace (*.dsw) or a project (*.dsp) available which I can use directly? I tried building a MSVC workspace using the ffmpeg files but I found that many files have main() and I was not sure how to build them.
I think you can forget about trying to build ffmpeg under MSVC... it uses GNU extensions (AFAIK), you won't be able to use the assembler optimizations (because they're in AT&T syntax) etc. etc. You should really compile ffmpeg under MinGW/MSYS. It's really just a case of ./configure --enable-memalign-hack --enable-shared make Not any more difficult than building under Linux, really... Martin -- Martin B?hme Inst. f. Neuro- and Bioinformatics Ratzeburger Allee 160, D-23538 Luebeck Phone: +49 451 500 5514 Fax: +49 451 500 5502 boehme at inb.uni-luebeck.de
Hi everyone! Thank you Martin for your help. I compiled and used ffmpeg on msvc at last. Here is how I done it: Install Msys, MinGW. Put ffmpeg in Msys root directory. Cut and paste the commands from the vcvars32.bat into autoexec.bat. On NT systems alter the path,lib, include variable. Reboot. Open Msys shell. Issue the following commands: link if it has some output then the next is: ./configure --enable-shared make If everything goes well start msvc. New project: Console application. Cut and paste the code from Martin Boehmes demo. In Project ->Settings-> Link put at the end avcodec.lib avformat.lib. Put all the h files from ffmpeg in your working directory (or alter the directory settings) Put avcodec.lib and avformat.lib in the compiler lib directory. If you put all the h files in your working directory then write this at the start of the demo: #include "avcodec.h" #include "avformat.h" Start building and the compiler will cry for inttypes.h. Put this in common.h or write some preprocessor constants in Project->Settings #ifndef COMMON_H #define COMMON_H #define CONFIG_WIN32 #define EMULATE_INTTYPES Compile. Copy avformat and avcodec.dll and some video in the same directory where your demo resides. demo.exe Craddleoflife.avi That's it. Cheers Falconetti
Hi Falconetti,
Thank you Martin for your help. I compiled and used ffmpeg on msvc at last.
Great to hear it's working for you now.
Here is how I done it: Install Msys, MinGW. Put ffmpeg in Msys root directory. Cut and paste the commands from the vcvars32.bat into autoexec.bat. On NT systems alter the path,lib, include variable. Reboot. Open Msys shell. Issue the following commands:
link if it has some output then the next is:
./configure --enable-shared make
On rereading the FFmpeg documentation (Section 6.3.1), most of this seems to be in it -- with the exception of copying the commands from vcvars32.bat into autoexec.bat (so link.exe is on the path). If desired, I'll submit a patch to the documentation that includes this information.
If everything goes well start msvc. New project: Console application. Cut and paste the code from Martin Boehmes demo. In Project ->Settings-> Link put at the end avcodec.lib avformat.lib. Put all the h files from ffmpeg in your working directory (or alter the directory settings)
The second option is definitely preferred.
Put avcodec.lib and avformat.lib in the compiler lib directory. If you put all the h files in your working directory then write this at the start of the demo: #include "avcodec.h" #include "avformat.h"
Start building and the compiler will cry for inttypes.h.
Put this in common.h or write some preprocessor constants in Project->Settings
#ifndef COMMON_H #define COMMON_H #define CONFIG_WIN32 #define EMULATE_INTTYPES
Again, the second option (putting the preprocessor definition in Project / Settings) is definitely preferred. Thanks for the feedback -- can you give me some detailed information on where to set the various options in "Project / Settings"? Especially: Where to set the include and library path, and where to add the additional preprocessor definitions (does something along the lines of "-DEMULATE_INTTYPES" have to be added somewhere)? I'd like to add a short note about this to the documentation. Also, do I understand correctly that both "CONFIG_WIN32" and "EMULATE_INTTYPES" have to be added to common.h, or is it just the latter? Martin -- Martin B?hme Inst. f. Neuro- and Bioinformatics Ratzeburger Allee 160, D-23538 Luebeck Phone: +49 451 500 5514 Fax: +49 451 500 5502 boehme at inb.uni-luebeck.de
On Mon, 2005-08-29 at 12:45 +0200, Martin Boehme wrote:
Also, do I understand correctly that both "CONFIG_WIN32" and "EMULATE_INTTYPES" have to be added to common.h, or is it just the latter?
Martin
Only the later one is needed: EMULATE_INTTYPES (tested). Anyway, I found a long time ago in the wikipedia that the file to be modified should be avcodec.h and not common.h. Modifying avcodec.h surely does it, but I haven't tested with common.h to say about common.h also. URL reference is here: http://en.wikipedia.org/w/index.php?title=FFmpeg&oldid=32900112 Bogdan
Bogdan <bogdanm at intelidei.com> writes:
On Mon, 2005-08-29 at 12:45 +0200, Martin Boehme wrote:
Also, do I understand correctly that both "CONFIG_WIN32" and "EMULATE_INTTYPES" have to be added to common.h, or is it just the latter?
Martin
Only the later one is needed: EMULATE_INTTYPES (tested). Anyway, I found a long time ago in the wikipedia that the file to be modified should be avcodec.h and not common.h. Modifying avcodec.h surely does it, but I haven't tested with common.h to say about common.h also.
Build instructions in wikipedia... that has to be funniest thing I've heard in a while. -- M?ns Rullg?rd mru at inprovide.com
On Mon, Feb 27, 2006 at 09:46:38AM +0200, Bogdan wrote:
On Mon, 2005-08-29 at 12:45 +0200, Martin Boehme wrote:
Also, do I understand correctly that both "CONFIG_WIN32" and "EMULATE_INTTYPES" have to be added to common.h, or is it just the latter?
Only the later one is needed: EMULATE_INTTYPES (tested). Anyway, I found a long time ago in the wikipedia that the file to be modified should be avcodec.h and not common.h. Modifying avcodec.h surely does it, but I haven't tested with common.h to say about common.h also.
All of this should no longer be necessary with latest CVS ... Diego
Thank you Martin for your help. I compiled and used ffmpeg on msvc at last.
Are you saying you have FFMpeg compiled on msvc or just an application using the av* libraries? If it is the former are you experiencing a performance increase over MinGW32? Chris
Chris wrote:
Thank you Martin for your help. I compiled and used ffmpeg on msvc at last.
Are you saying you have FFMpeg compiled on msvc or just an application using the av* libraries?
RTFP ;-) He said a few lines later that he was compiling FFmpeg under MinGW/MSYS... Martin
If it is the former are you experiencing a performance increase over MinGW32?
Compiling FFmpeg itself under MSVC would be a huge porting fest, and unless you wanted to take a big performance _hit_, you'd have to convert large chunks of inline assembler from AT&T syntax to Intel syntax... Martin -- Martin B?hme Inst. f. Neuro- and Bioinformatics Ratzeburger Allee 160, D-23538 Luebeck Phone: +49 451 500 5514 Fax: +49 451 500 5502 boehme at inb.uni-luebeck.de
Martin Boehme wrote:
MinGW32?
If it is the former are you experiencing a performance increase over
Compiling FFmpeg itself under MSVC would be a huge porting fest, and unless you wanted to take a big performance _hit_, you'd have to convert large chunks of inline assembler from AT&T syntax to Intel syntax...
Martin
Couldn't the asm things be wrapped in macros? How do other multi platform projects deal with this? I agree that MS isn't really run by mother Theresa, but Visual Studio beats the hell out of any other ide I've worked with. And yes, I tried the marvels of programming with emacs/gcc and I didn't like it. gdb or ddd are beaten by the VS debugger hands down, imho. Most incompatible (C99?) examples I've seen VS fail with on this list are irrelevant cosmetics (apart from lack of inttypes.h), as far as I could tell. imho again ;-) Best regards, Marcus
Hi, On 8/31/05, Marcus Engene <ffmpeg at engene.se> wrote:
Martin Boehme wrote:
MinGW32?
If it is the former are you experiencing a performance increase over
Compiling FFmpeg itself under MSVC would be a huge porting fest, and unless you wanted to take a big performance _hit_, you'd have to convert large chunks of inline assembler from AT&T syntax to Intel syntax...
Martin
Couldn't the asm things be wrapped in macros? How do other multi platform projects deal with this?
Lots of them use nasm, gasm or yasm. Guillaume -- Reading doesn't hurt, really! -- Dominik 'Rathann' Mierzejewski
Hi On Wed, Aug 31, 2005 at 10:45:26AM +0200, Guillaume POIRIER wrote:
Hi,
On 8/31/05, Marcus Engene <ffmpeg at engene.se> wrote:
Martin Boehme wrote:
MinGW32?
If it is the former are you experiencing a performance increase over
Compiling FFmpeg itself under MSVC would be a huge porting fest, and unless you wanted to take a big performance _hit_, you'd have to convert large chunks of inline assembler from AT&T syntax to Intel syntax...
Martin
Couldn't the asm things be wrapped in macros? How do other multi platform projects deal with this?
Lots of them use nasm, gasm or yasm.
which doesnt help, you still need to compile/assemble parts with something else then MSs compiler, so how is that better then gcc? btw, AFAIK the reason why *ASM is used in some projects instead of gccs inline asm is that the developers hate the AT&T style asm and prefer intel style, not that i disagree on the ugliness of AT&T style asm ... [...] -- Michael
Michael Niedermayer wrote:
Hi
On Wed, Aug 31, 2005 at 10:45:26AM +0200, Guillaume POIRIER wrote:
Hi,
Lots of them use nasm, gasm or yasm.
which doesnt help, you still need to compile/assemble parts with something else then MSs compiler, so how is that better then gcc?
It would be less problematic/possible at all to involve them in a MS build than gcc? Best regards, Marcus
Hi On Wed, Aug 31, 2005 at 10:14:50AM +0200, Marcus Engene wrote:
Martin Boehme wrote:
MinGW32?
If it is the former are you experiencing a performance increase over
Compiling FFmpeg itself under MSVC would be a huge porting fest, and unless you wanted to take a big performance _hit_, you'd have to convert large chunks of inline assembler from AT&T syntax to Intel syntax...
Martin
Couldn't the asm things be wrapped in macros?
no, gcc has serious problems with this (=it generates very slow code)
How do other multi platform projects deal with this?
not any better then we [... childish ms trolling ...] -- Michael
Marcus Engene said:
Martin Boehme wrote:
MinGW32?
If it is the former are you experiencing a performance increase over
Compiling FFmpeg itself under MSVC would be a huge porting fest, and unless you wanted to take a big performance _hit_, you'd have to convert large chunks of inline assembler from AT&T syntax to Intel syntax...
Martin
Couldn't the asm things be wrapped in macros? How do other multi platform projects deal with this?
Some put the assembler bits in separate files, and use nasm or some other standalone assembler.
I agree that MS isn't really run by mother Theresa, but Visual Studio beats the hell out of any other ide I've worked with.
In terms of being irritating, yes.
And yes, I tried the marvels of programming with emacs/gcc and I didn't like it. gdb or ddd are beaten by the VS debugger hands down, imho.
Load a project in VS, set some breakpoints, and start the thing running. Then switch to some other window and try to do something else while waiting for the breakpoint to be reached. Finally, realize that you can't do a thing, because VS has frozen the entire machine solid. This is under Windows XP Pro SP2 with 1GB RAM and 3GHz clock. (Why oh why do they make use use this stuff at work?)
Most incompatible (C99?) examples I've seen VS fail with on this list are irrelevant cosmetics (apart from lack of inttypes.h), as far as I could tell. imho again ;-)
C99 struct initializers are all but cosmetic. They are very useful when only some of the fields need to be initialized, and you don't need to remember the order of the fields either. All this IMNSHO. -- M?ns Rullg?rd mru at mru.ath.cx
Marcus Engene wrote:
Martin Boehme wrote:
Compiling FFmpeg itself under MSVC would be a huge porting fest, and unless you wanted to take a big performance _hit_, you'd have to convert large chunks of inline assembler from AT&T syntax to Intel syntax...
Martin
Couldn't the asm things be wrapped in macros? How do other multi platform projects deal with this?
I agree that MS isn't really run by mother Theresa, but Visual Studio beats the hell out of any other ide I've worked with. And yes, I tried the marvels of programming with emacs/gcc and I didn't like it. gdb or ddd are beaten by the VS debugger hands down, imho. Most incompatible (C99?) examples I've seen VS fail with on this list are irrelevant cosmetics (apart from lack of inttypes.h), as far as I could tell. imho again ;-)
Oh good, let's start a gcc vs. MSVC flamefest. ;-) I agree with you, the VS debugger _is_ great *ducks*. And it's my impression that MSVC *ducks even lower* still tends to generate better code than gcc. (Disclaimer: In my day-to-day work, I use vim and gcc.) Having said that, FFmpeg _is_ firmly rooted in Linux; regarding the question of making it portable between compilers, well... at the very least it would be a huge PITA. Martin -- Martin B?hme Inst. f. Neuro- and Bioinformatics Ratzeburger Allee 160, D-23538 Luebeck Phone: +49 451 500 5514 Fax: +49 451 500 5502 boehme at inb.uni-luebeck.de
Martin Boehme wrote:
Marcus Engene wrote:
Martin Boehme wrote:
Compiling FFmpeg itself under MSVC would be a huge porting fest, and unless you wanted to take a big performance _hit_, you'd have to convert large chunks of inline assembler from AT&T syntax to Intel syntax...
Martin
Couldn't the asm things be wrapped in macros? How do other multi platform projects deal with this?
I agree that MS isn't really run by mother Theresa, but Visual Studio beats the hell out of any other ide I've worked with. And yes, I tried the marvels of programming with emacs/gcc and I didn't like it. gdb or ddd are beaten by the VS debugger hands down, imho. Most incompatible (C99?) examples I've seen VS fail with on this list are irrelevant cosmetics (apart from lack of inttypes.h), as far as I could tell. imho again ;-)
Oh good, let's start a gcc vs. MSVC flamefest. ;-)
I agree with you, the VS debugger _is_ great *ducks*. And it's my impression that MSVC *ducks even lower* still tends to generate better code than gcc. (Disclaimer: In my day-to-day work, I use vim and gcc.) Having said that, FFmpeg _is_ firmly rooted in Linux; regarding the question of making it portable between compilers, well... at the very least it would be a huge PITA.
Martin
Looking at the last 3 months of the list, seems to me GCC is far from perfect... For me the *big* problem is that the debug info generated by GCC is not compatible with MSVC. So, debugging an MSVC app that uses lavc is extremely difficult. HaND, -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
participants (12)
-
boehme＠inb.uni-luebeck.de -
bogdanm＠intelidei.com -
chris＠garveycocker.com -
diego＠biurrun.de -
falconettig＠freemail.hu -
ffmpeg＠engene.se -
kirantulasi＠rediffmail.com -
mbardiaux＠mediaxim.be -
michaelni＠gmx.at -
mru＠inprovide.com -
mru＠mru.ath.cx -
poirierg＠gmail.com