This uses a VDPAU presentation queue to render VDPAU output surfaces
(i.e. screen-scaled RGBA pictures) on an X11 window. It is assumed that
a video filter will eventually convert pictures in the source video
format to VDPAU output surfaces of adequate dimensions.

The common VLC XCB event handling is used for X11 matters.

This enables importing I420, YV12, NV12, YUYV and UYVY pictures into
the GPU's VDPAU back-end. Conversion to RGBA color space and scaling to
the target resolution are performed on the fly by the GPU.

This define several codec identifiers for each of the VDPAU video
surface types (YUV 4:2:0 and 4:2:2) and one for VDPAU output surfaces
regardless of their internal type. (At this point, it does not seem
that the output surface type affects VLC processes).
VDPAU bitmap surfaces are not included as they do not seem useful.

VDPAU pictures have zero pixel planes since they only carry picture
infos and handles to GPU resources, no actual pixel data. Nevertheless,
inclusion in chroma description is required for picture setup to work.

VDPAU surfaces cannot be shared across multiple device instances.
Thus the same instance must be used within a pipeline.

Sharing instances also saves resources (X11 server connections).

This provides a more traditional set of library function calls than the
VDPAU specification defines. Furthermore, this has libvdpau.so as a
conditional run-time linking dependency.

Note that this requires libvdpau 0.6 or later (0.4.1-8 on Debian) at
run-time due to a bug in libvdpau versions 0.4 through 0.5.

This uncomments the configure checks for HAVE_VDPAU. That way VDPAU can
be used even if libavcodec is missing or old.

This way, common.am can be included also in directories without a
Modules.am file.

These functions assume that sockets are file descriptors, never worked
properly on Windows. See also 3841c085.

This reverts commit db8ff4e3.

refs b2cce4d8