[FFmpeg-devel] PATCH: av_strtod
Pavel Pavlov
pavel
Mon Jun 1 07:27:52 CEST 2009
Hello everybody,
I tried to contribute at some point and my patches were discarded as too
intrusive.
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.
Example:
av_strtod("0x00800000")
Returns double(0x00800000) which is correct, however, according to the
ms documentation strtod doesn't parse 0x123abc, and as a result I was
always getting 0.
As a result, about a half of the tests didn't validate.
Check attached eval.c.diff. I didn't put _MSC_VER/_WIN32 ifdefs, and it
probably should be added.
Then my lib doesn't pass seek_test.exe. After looking into it it appears
that the problem is in the seek_test and might related to gcc itself.
The first diff between seek.regression.ref and seek.regression is:
tests/data/a-flac.flac
ret: 0 st: 0 dts:-209146758205323.720000 pts:-209146758205323.720000
pos:42 size:1024 flags:1
And the expected line is:
tests/data/a-flac.flac
ret: 0 st: 0 dts:-209146758205323.718750 pts:-209146758205323.718750
pos:42 size:1024 flags:1
The dts and pts values are calculated something like: pkt.dts *
av_q2d(time_base)
The pkt.dts has value: -9223372036854775808 which is 1<<63 and, off
course, it cannot be ccorrectly represented as a double.
The time_base is 1/44100
I wrote a simple test app (see at the end of message) and both gcc and
icl produce identical output: -209146758205323.720000 and I have no idea
how in gcc-built seek_test it becomes -209146758205323.718750
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 :)
Port to intel compiler requires too intrusive changes to the code, so I
don't even try to send a diff.
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?!?
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.
////////////////////////
#include <iostream>
#include <stdio.h>
using namespace std;
#ifdef __ICL
typedef __int64 int64_t ;
#endif
int main()
{
int64_t X = -9223372036854775808LL;
double d = (double)X;
d *= (1 / (double)44100);
cout << "d: " << fixed << d << endl;
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eval.c.diff
Type: application/octet-stream
Size: 855 bytes
Desc: eval.c.diff
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090601/3f5c6574/attachment.obj>
More information about the ffmpeg-devel
mailing list