This will be used for deinterlacing.

This is for advanced filtering on the GPU. So far, only progressive
scan is implemented.

This is a corner case. The picture needs to be copied back to the main
memory from the decoding GPU, and from there onto the rendering GPU.

...instead of copying YCbCr planes back to the main memory.

This avoids loosing the picture context if there is one. If the
original picture has no context, it makes no difference whether the
original or the copy is kept since blending failed anyway.

If the picture copy fails or blending is unavailable(1), discard only
the subpicture and keep the original picture.

(1) In practice, this never happens as the blender object is kept
all the time even without a "blend" module.

This provides colour space conversion, cropping and scaling of existing
video surfaces (as would come from a hardware decoder).

This enables using the pass-through hardware-accelerated decoder (from
a later commit) with transcode in stream output or with a video output
that does not support VDPAU surfaces.

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.