Disable the check for the mapping refcount in destroy_va_buffer() since
some ffmpeg version have a bug that they do not unmap the buffer properly
in certain error paths.

This reverts commit 752043de.

The code now assumes a window has been created by the client applications.
That window is used directly as an output for video pictures. This changes
makes it possible to draw an overlay ontop of the output window. The previous
code did not allow for this, since the video output window would always over
write the overlay.

This caused the PFNGLMULTITEXCOORD2FPROC definition to be moved out of the
GL_VERSION_1_3_DEPRECATED block. However, since <GL/gl.h> also defines
GL_VERSION_1_3 to 1, the definitions in <GL/glext.h> are then not enabled,
thus leaving PFNGLMULTITEXCOORD2FPROC undefined as well.

Provide a PFNGLMULTITEXCOORD2FPROC replacement as an interim solution for
newer versions of the <GL/glext.h> header.

Patch taken from: http://gitorious.org/vaapi/gstreamer-vaapi/commit/5db2e93d3c930fd8470cfdcd26f514d1cebc59a0?format=patchSigned-off-by: Jean-Paul Saman <jpsaman@videolan.org>

glIsTexture() only works when the texture under test has been bound to a target
(thus calling glBindTexture()).

Enable H.264 Level 5.1 in xvba-video VA API plugin. To enable
this a change must be made in ATI configuration database.

Important notice:
=================
It is require to enable H.264 Level 5.1 in the fglrx driver
(for the moment AMD Catalyst 12.6):

  aticonfig --set-pcs-u32=MCIL,HWUVD_H264Level51Support,1

The UAsyncQueue leaked a mutex and conditional upon calling async_queue_free().

A GLX surface can be in use by multiple VASurfaces, therefor make
sure refcounting is done properly. The code did not honor this and
could destroy a surface that was still in use by another GLX Surface
object.

The code is changed to enforce proper refcounting. Basically using

   destroy_glx_surface(driver_data, obj_glx_surface);

is suspicious and should be replaced by:

   glx_surface_unref(driver_data, obj_glx_surface);

instead. This function decreases the refcount on obj_glx_surface and
when it reaches 0, then it destroys the surface properly.

xvba_DestroySurfaces() leaked subpicture associations, since the
for loop did not actually iterate over the subpicture association
array.

Assert if prerequisites are not met.

glx_output_surface_destroy did not destroy a mutex created in glx_output_surface_create. Rewrite surface_unref.

The function do_put_surface_glx() is used from the render_thread and
from put_surface_glx(). Make sure it is locked since it is accessed
from two threads.

- Fix memleak in render_thread
- Destroy shaders, procam, scalers from the correct 'target'
- other small issues

Speed up bitmap loading by avoiding conversions in software. The
GPU stores a bitmap internally in BGRA format instead of RGBA. By
using BGRA iso RGBA for format to load this conversion is ommitted
and a considerable speedup is obtained.

Refcount mapping and unmapping of VABuffers.

On some 1080 movies the commit-id: 42be4519
gave issues. Reverting some parts of this commit solves this issue.

Cleanup all subpicture associations when freeing a surface.

The xvba-video wrapper used a local X11 connection. However this prevents
using overlays on the application provided X11 display to be shown.

When calling XOpenDisplay in vaInitialize, then also call XCloseDisplay in vaTerminate.

Explicitly enable/disable targets when using OpenGL code.

Add extra checking.

The API offered a gl_create_texture() but not and gl_destroy_texture().

The function query_surface_status_glx() changes the surface status. This looks
very suspicious and might be even a design error.

The render thread allocates a new render_context, but never destroys it
when shutting down. It possibly leaks on closing.

Do not leak subpicture associations, but rather crash so that the bug can be investigated and fixed.

- fix error path in create_hw_image_glx()

The boolean operator || requires an evaluation of both expressions.
If the expressions evaluates pointers, then care must be taken that
both expressions have valid pointer. In this case it cannot be guaranteed,
thus splitting the check is needed.

The boolean operator || requires an evaluation of both expressions.
If the expressions evaluates pointers, then care must be taken that
both expressions have valid pointer. In this case it cannot be guaranteed,
thus splitting the check is needed.