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)

Also move the color format definition to the header, making
it available to omxil.c.

In practice on Nexus One with stock firmware, it is NV21
even though the decoder says it's planar. (On CyanogenMod with
OMX decoder built from source, the decoder returns
OMX_QCOM_COLOR_FormatYVU420SemiPlanar as pixel format, though.)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Desire Z and Desire HD use OMX_COLOR_FormatYUV420SemiPlanar,
which when inspected turns out to be NV12, while Nexus One
either reports OMX_QCOM_COLOR_FormatYVU420SemiPlanar (or
falsely reports OMX_COLOR_FormatYUV420Planar) which is NV21.
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>

Unfortunately, I cannot see how not to second guess ALSA as some
devices exhibit inconsistent hardware configuration spaces
(namely front, surround41 and surround50). Also I do not know any
API to query the order of channels.

Note that 7.1 is not supported but it could be added with some extra
reordering code.

This path should only be used when a non-plug device is forced.