Running: make -C tests/check elements/deinterlace.valgrind

I see a few of those:

==4552== Invalid read of size 8
==4552==    at 0x5E010EF: __GI___strncasecmp_l (strcmp.S:1897)
==4552==    by 0x5DB23EF: ____strtod_l_internal (strtod_l.c:574)
==4552==    by 0x536B0A0: gst_value_deserialize_double (gstvalue.c:2737)
==4552==    by 0x534E5DF: gst_structure_parse_value (gststructure.c:2312)
==4552==    by 0x535178B: priv_gst_structure_parse_fields (gststructure.c:2229)
==4552==    by 0x5303414: gst_caps_from_string (gstcaps.c:2306)
==4552==    by 0x40252F: deinterlace_check_passthrough (deinterlace.c:237)
==4552==    by 0x402B5D: test_mode_disabled_passthrough (deinterlace.c:414)
==4552==    by 0x50B8A79: srunner_run (check_run.c:450)
==4552==    by 0x50B14BC: gst_check_run_suite (gstcheck.c:824)
==4552==    by 0x40185D: main (deinterlace.c:463)

After a while debugging, I came to the conclusion that either libc is buggy, or valgrind is, because I can repro the issue with:

#include <stdlib.h>
#include <string.h>
int main(void) {
  char *e=NULL;
  char *p=strdup("interleaved");
  double x=strtod(p,&e);
  free(p);
  return 0;
}

And then I found this:
http://stackoverflow.com/questions/10572715/valgrind-invalid-read-with-c-str-and-strtod

The sample code above seems bugfree.

A nice side effect is that I found in the strtod man page:

       An infinity is either "INF" or "INFINITY", disregarding case.

       A NAN is "NAN" (disregarding case) optionally followed by '(', a
       sequence of characters, followed by ')'.  The character string speci‐
       fies in an implementation-dependent way the type of NAN.

Anyway, I'm proposing this patch which sweeps it under the carpet, but I'll wait for comments about it, in case I've missed a stupid thing, since blaming valgrind or libc seems like the easy way out.