Otherwise, the caller cannot determine that the value is not defined,
such that the vlc_value_t is not set and cannot be used.

As per the specification, only those three types have default values.

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>