[FFmpeg-devel] PATCH: av_strtod

Ramiro Polla ramiro.polla
Mon Jun 1 13:26:14 CEST 2009


On Mon, Jun 1, 2009 at 2:27 AM, Pavel Pavlov <pavel at summit-tech.ca> wrote:
> In my spare time I ported ffpeg to another compiler (icl) and had to
> resolve some bugs related to failed regression tests.
> I belive that the root of the problem is incomplete implemetation of
> strtod of the ms library.

This is a known issue with msvcrt. Search the ffmpeg-devel archives
for some past discussions. MinGW32 uses a POSIX compliant strtod
implementation and it suits us well.


> Then my lib doesn't pass seek_test.exe.

This is also known issue. Look for a thread on this list about huge
negative numbers, MinGW32, and printf or something. MinGW32 has a
printf implementation that recently fixed this issue, and it also
suits us well.


> Other than that, my build passes validation (if I build seek_test with
> gcc). I didn't test any performance between gcc/icl builds; the reaon I
> decided to port to intel compiler is that I had crashes somewhere inside
> avcodec if I had a video call running overnight and I just couldn't find
> out where and why (I use ms vs). Since intel compiler can generate debug
> info compatible with ms tools I decided to do it. Not only I'm able to
> easily step-trough the code with VS, but also with icl build my original
> problem is gone :)

Great. I'm sure some people will appreciate that:

> Port to intel compiler requires too intrusive changes to the code, so I
> don't even try to send a diff.

Even though, yes, it is most likely that your patches will get
rejected here, it would be nice if you could share them.

> Biggest problem is the black voodoo code related to inline assembly and
> MANGLE(...)

> plus the worst ever code is in recently added
> mlp_filter_channel_x86, which mangles lables. WTF, why not a standalone
> .asm file instead?!?

A patch based in configure disabling that code on supported compilers
where it fails is welcome.

> Moreover, there is a big problem that very often compiler doesn't have
> enough registers to assemble inline asm, which I also had to solve.
> Surprisingly, in non optimized build icl and gcc get that not enough
> general regs error in exactly the same code, which makes me think that
> intel compiler borrowed some code from gcc ;)
> Icc (linux intel compiler) uses gas as the assembler for the inline
> att-style asm, in win32 build they have built in asm (that is quite
> limited). The only feature that I didn't properly do is the .align
> derective for the inline assembly. In icl the only way to do it is to
> use ms-style inline assembly and to use ALIGN derective which is
> supported.

It's not quite clear how you got around some issues. Specially the
ones listed here:

Did you rewrite inline assembly in ms style, or is there a way to
switch inline assembly modes inside the asm block so that you can
insert your ALIGN directive? Did you disable the code that needs

Ramiro Polla

More information about the ffmpeg-devel mailing list