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

Ramiro Polla angustia
Tue Jan 30 15:13:30 CET 2007

Steve Lhomme wrote:
> M?ns Rullg?rd wrote:
>> Steve Lhomme said:
>>> Aurelien Jacobs wrote:
>>>> 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... ?
>>> WTH are you talking about ? I'm saying that the hardware acceleration
>>> could be available to more than a tuned gcc, not that ASM code is
>>> portable across platforms.
>> I thought your main complaint was that the optimized code can't be built
>> with msvc.  If it can't be built with msvc, what difference does it make
>> if gcc or nasm is used instead?
> Exactly I wish the ASM could would be usable somewhere else. And if it 
> was separate ASM files it would be much easier, as MSVC can call this 
> code just as well as gcc does.
The assembly files in FFmpeg can't be built with MSVC, but the objects 
generated can be used by MSVC. It doesn't matter if it was compiled with 
gcc or nasm or whatever. I know, MSVC won't be able to read the debug 
information generated by MinGW. But, since it's only asm, just look at 
the disassembly window. You won't be very far from the source file.

Also, since most asm files in FFmpeg are almost only asm, it doesn't 
matter who compiles them, it will still be asm. It can't automatically 
optimize much more than that.

And about the inline assembly, it's not that much code...

Ramiro Polla

More information about the ffmpeg-devel mailing list