[FFmpeg-devel] [PATCH] Implement the function cmdutils.c:parse_int_or_die

D. Hugh Redelmeier hugh
Wed Feb 20 09:05:31 CET 2008


| From: Rich Felker <dalias at aerifal.cx>

| On Wed, Feb 20, 2008 at 12:48:53AM -0500, D. Hugh Redelmeier wrote:
| > I don't know what the coding standards are for the ffmpeg project.
| 
| There's no formal expression of it, but the basic idea is to use
| anything from C89 and parts of C99 that have near-universal support
| among implementations. I don't know that floating point standards have
| been discussed much however.

Thanks for the explanation.

| > Note that in 5.2.4.2.2 the standard says:
| > 
| >     An implementation may give zero and non-numeric values (such as
| >     infinities and NaNs) a sign or may leave them unsigned. Wherever
| >     such values are unsigned, any requirement in this International
| >     Standard to retrieve the sign shall produce an unspecified sign,
| >     and any requirement to set the sign shall be ignored.
| > 
| > So the idea of comparing with -INFINITY seems to not be sanctioned by
| > the base standard.
| 
| The base C99 standard allows all floating point expressions to
| evaluate to 0.0 as long as the implementation's documentation says
| something to this effect... So going from the base is hardly useful.
| I think it's reasonable to expect IEEE 754 semantics. Anything but
| idiotic IBM mainframes will provide this.

IEEE 754 is not implemented rigorously on the dominant architecture
(i386 + x87).  Even when SSE is used, as on x86-64, there are
performance reasons to relax conformance.

My impression is that a number of high performance FPUs don't conform.
For example, the IBM Cell Processor SPE's FPU does not conform, even
ignoring the lack of double.  I would guess that nVidia and ATI GPUs
don't implement IEEE 754.

The parts of the standard that seem to be expensive relative to their
perceived benefit are (off the top of my head):
- NaNs
- denorms
- infinities
- exact precision (i.e. no more and no less than specified)
(I will agree that Kahan is very convincing in arguing
for these features but I don't build FPUs.  My suspicion is that only
someone as smart as Kahan can really use all these features well.
For the rest of us, they add corner cases.)

In the back of my mind, I'm encouraging ffmpeg to not use this stuff.
After all, high performance FP ought to matter for ffmpeg.
Furthermore, the fewer odd-ball assumptions made about the FPU, the
simpler it is to reason about the code.

I would recommend that the project standardize what is expected of
FPUs, at least in these dimensions.  That would allow builders to know
what pieces of 754 conformance can be turned off (for speed) and it
would allow coders to know just what the can use.

See, for example, http://hal.archives-ouvertes.fr/hal-00128124/en/
(I have only scanned parts of it.)




More information about the ffmpeg-devel mailing list