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

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

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

Signed-off-by: Laurent Aimar <fenrir@videolan.org>

Those cards are normally accessed with the standard FrameBuffer,
through X11 or svgalib instead. The mga_vid driver is not even in the
kernel (or not anymore).

This would enable third party vout display plugins, and remove the
maintainance hurdle that the wrapper was. As a side effect, legacy
video output plugins will always be probed after new vout display
plugins even if they have a higher priority.

This fixes the plugin names in the user interface. On the other hand,
legacy video output plugins cannot be selected explicitly anymore
(though they still take part in automatic probing).

Close #3105

This should simplify the mms-bitfield issue and avoid the compilation of the dvdread plugin on Windows...

Otherwise, we'd use the maximum (5Mpixels) which is a bit large for
video purposes. Also, 5Mpixels exceeds the capacity of the XVideo
overlay.

This reverts commit 10b9d038.

Yeah, sorry guys, but it looks like the dxva2 code needs it :'(

modplug is a C++ library (including a C API). So we need the C++ linker,
at least when linking statically.

Signed-off-by: Pierre d'Herbemont <pdherbemont@free.fr>

This saves (from my test) more than 5 frames per seconds during live resize.

To convert from 4-bits to 8-bits channel, one should multiply by 17.
Acked-by: Antoine Cellerier <dionoea@videolan.org>

(not on some specific operating system)
Pointed-out-by: Ramiro Polla <ramiro.polla@gmail.com>

Don't force an explicit --disable-libva. This was especially silly on
non-libVA platforms.