This restores compatibility with 1.1 command lines and docs

Close #6227

Should close #6570

Note: It is not yet passed to the demuxer or the core

It can even crash Qt interface

 * Enumerate frame sizes once rather than twice.
 * Do not enumerate frame rates if not supported.
 * Get actual frame rate from the device driverr.
 * Get exact fractional frame rate rather than round to single precision
   floating point.

Notes:
 * --v4l2-fps becomes totally redumdant. It should probably be redefined
   to select a maximum capture frame rate.
 * --v4l2-width and --v4l2-height are ignored. This is a regression.
   Maybe they should be redefined as maxima as well as --v4l2-fps.

Probably more recent address.
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>

This decoder reorders timestamps according to the frame reordering,
and thus should be given pts instead of dts. Other decoders don't
do this reordering and should be given dts.

Still to be investigated how android/stagefright handles this,
since it always seems pass pts, not dts, to decoders.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

CVE-2011-3048 (serious vulnerability)

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Integer values outside a C enumeration are not defined (this is a bug in
V4L2 API really), so this would not work anyway.

"capabilities" counter-intuitively specifies the overall capabilities of
all device nodes provided by the given instance of the device driver.
"device_caps" specifies the capabilities of the opened device node,
if the V4L2_CAP_DEVICE_CAPS bit is set in "capabilities" (phew!).
Those two sets of capabilities are different if the hardware has
multiple functions, e.g. both video and VBI capture.

VLC cares about the fact that the specific device node supports video
capture or not, so lets use "device_caps" when available. Unfortatunely,
this requires kernel version 3.4. In practice, this would only cause an
actual failure if V4L2_CAP_STREAMING is set even though the current node
does not support streaming I/O, I think.

Unlike POLLERR, POLLHUP, and POLLNVAL, POLLRDHUP is not set by default.
See http://man7.org/linux/man-pages/man2/poll.2.htmlSigned-off-by: Rémi Denis-Courmont <remi@remlab.net>

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

Only do it for the right events.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

This makes buffer allocation not fail.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

This interpretation of nTop isn't too intuitive to me, but this is what
frameworks/base/media/libstagefright/colorconversion/ColorConverter.cpp
does for this pixel format.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

As a side effect, this also makes the output correct on Samsung
Galaxy S II on ICS.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Support the OMX_IndexConfigCommonOutputCrop config struct, too.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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