The V4L2 plug-in is a bit peculiar with dynamically generated object
variables. We need to keep track of which controls/variables we have,
so that we can remove the variables callbacks later. The only other
way to solve this bug, that I could think of, consisted of extending
the VLC variables subsystem (which would be worse in code freeze).

This rewrite also fixes a few other bugs:
 * Support menu with non-zero based minumum choice
 * Support menu with discontinuous choices range
 * Redumdant use the extended controls API as fallback
   (This only makes sense to set more than one control at a time,
    or to set 64-bits and string controls. VLC does none of that.)
 * Unused "controls-update" and "allcontrols" variables.
 * Skipping disabled, read-only and volatile controls.

Support for the legacy control enumeration API (pre-2.6.18 kernel) is
removed; and the code is now independent of the VLC object type (it
could easily be reused for say, a V4L2 video output).

This should force a build failure when the checksum file is not in
sync with the list of required sources.

This is superseded by the MCE plug-in. libosso is not available on
Maemo 6 while MCE is available on all versions.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Regression introduced in 9367ce0bSigned-off-by: Jean-Baptiste Kempf <jb@videolan.org>

glwin32 should be back

This has never been working.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

var_Change(VLC_VAR_GETTEXT) fails if there is no text. In that case,
the value is undefined.

If you don't actually use the return of a function, don't store it.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

For omxil, the nal size has already been parsed out elsewhere, so
we don't need it returned here.

This fixes this warning:
omxil.c:926: warning: pointer targets in passing argument 7 of 'convert_sps_pps' differ in signedness
h264_nal.h:22: note: expected 'uint32_t *' but argument is of type 'int *'
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Close #4779

The Qualcomm and Samsung OMX decoders (on Nexus One and Nexus S
at least) on android don't handle NAL format (and stagefright
always feeds H264 in annex b format to the decoder, so the same
might apply for many other android devices, too).
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

mingw64 defines it in direct.h
mingw32 fetches the definition from unistd.h

the buildbot has been updated with a qt4 library, soon in a contrib near you
both do not build atm but fix will be easy once we can ensure win32 still builds

we make binaries for other arch
having the field set to x86 doesn't prevent binary to run
it doesn't prevent loading 64bits DLLs either, except when it does
(qt4 plugin for example)