[Ffmpeg-devel] [PATCH] Partial port of ffmpeg to MS Visual C - and a note on the inttypes.h issue

Aurelien Jacobs aurel
Tue Jan 30 10:48:25 CET 2007

On Tue, 30 Jan 2007 09:25:38 +0100
Steve Lhomme <steve.lhomme at free.fr> wrote:

> Michael Niedermayer wrote:
> > Hi
> > 
> > On Mon, Jan 29, 2007 at 10:15:00AM +0100, Steve Lhomme wrote:
> >> Alex Beregszaszi wrote:
> >>> Hi,
> >>>
> >>>>> If you really want to be that gnucentric, 
> >>>> do you know why everyone who uses visual <bluescreen, restarts system) C++
> >>>> has a problem with understanding the different between standart and gcc?
> >>>> we HATE gcc and we certainly are not, where not and never will be
> >>>> gnucentric, ffmpeg code is stanard C, everything else is under #ifdefs
> >>>> like asm, always_inline and so on
> >>>>
> >>>> it must be something like
> >>>> * user sees vc++ fail with random program
> >>>> * user sees gcc to suceed with same random program
> >>>> * user concludes that program is written specifically for gcc as he knows
> >>>>  MS always follows all standards very carefully
> >>> Thats a great point here.
> >> It's like the difference between people who prefer to use C99 and the 
> >> ones who prefer to use a real-world compiler.
> >>
> >> Anyway, C99 doesn't cover inline ASM AFAIK so you can't seriously say 
> >> that FFMPEG is not designed for gcc.
> > 
> > you know very well that they are under #ifdefs (some of the other people
> > who claimed that ffmpeg where written for gcc may or may not have known that
> > but you do as you have worked with the code) so could you maybe spare
> The ASM code is #ifdef'd by the makefile. If you compile the code with 
> another compiler it will fail because the ifdefs are not clean. I 
> actually made some changes recently to DrFFMPEG to have both ppc and 
> i386 ASM compiled in the same project at the same time (to make 
> universal binaries in XCode) and I had to add some cleaner #ifdef's.
> Nevertheless, the "full" FFMPEG is only usable with a tuned gcc. That's 
> my whole point. Portable ASM files (to be processed by nasm and yasm) is 
> always possible and make the code much more portable. But I understand 
> it's not the goal of this project.

Why would nasm or yasm be more portable than gas for example ?
Do nasm or yasm support ppc, arm, alpha, sparc, sh4... ?


More information about the ffmpeg-devel mailing list