Found bug (and solution) in function XVideoGetPort

[AndrK]

I refer to the function XVideoGetPort() in the source file "modules/video_output/x11/xcommon.c".

What the function does
===============

In function "XVideoGetPort()" a port for a desired chroma format is searched. The chroma format could be YUV or YVU for example.

The function searches all "adaptors", and for any adaptor it retrieves its supported image formats. These formats could be YUV or YVU or RGB for example.

For any format a subroutine checks, if the desired format (e.g. YUV) fits the provided format (e.g. YVU). Here also not-identical, but similar formats match, i.e. YUV ('I420') matches YVU ('YUV12').

In case there is a match, the loop finishes, returning the result.

Where the problem is
==============

Assume a decoder wishes output buffers in the format YUV. Unfortunately the list of supported formats may look like (RGB, YVU, YUV), resulting in the decoder receiving a non-perfect output format YVU instead of the (possible!) perfect format YUV (we assume the component buffers in fact being ONE buffer, i.e. V directly follows Y, and U directly follows V in memory).

This could result in significant overhead in case the decoder core deals with a combined YUV buffer which then has to be modified (using CPU time) by exchanging the U and V components pixel by pixel.

What a possible solution is
=================

The adaptor loop has to be put into another loop counting from 0 to 1. In the first pass only exact colour format matches are found. If no output port could be found, the routine will use the second pass to look for non-perfect, but reasonable compromises like providing YVU for the requested YUV.

Remarks
======

It may be that any of the currently used decoders deals with separate YUV buffers, so that mixing up YUV and YVU is no problem. But this will not necessarily be the case for the future. Consider a hardware decoder on the graphics chip doing the decoding, and assume that this chip definitely insists on the component order Y, U, V. In this case precious CPU time will be wasted without any sense, just to exchange V and U manually.