Hacks to make HW decode work on linux via libva.

content/common/gpu/media/vaapi_h264_decoder.cc

Index: content/common/gpu/media/vaapi_h264_decoder.cc
diff --git a/content/common/gpu/media/vaapi_h264_decoder.cc b/content/common/gpu/media/vaapi_h264_decoder.cc
index 863ea28d68cdeb3c72698f52431902932670ff0b..af35c36cfc08d60ff1caa34c93c0e94e8f66110b 100644
--- a/content/common/gpu/media/vaapi_h264_decoder.cc
+++ b/content/common/gpu/media/vaapi_h264_decoder.cc
@@ -274,6 +274,7 @@ VaapiH264Decoder::DecodeSurface::~DecodeSurface() {
 
   if (x_pixmap_)
     XFreePixmap(x_display_, x_pixmap_);
+  XSync(x_display_, False);

[Ami GONE FROM CHROMIUM, 2012/09/07 10:04:21]

Without this, rendering_thread.Stop() in vdatest triggers this:

X Error of failed request:  GLXBadPixmap
  Major opcode of failed request:  135 (GLX)
  Minor opcode of failed request:  23 (X_GLXDestroyPixmap)
  Serial number of failed request:  585
  Current serial number in output stream:  590

on thread shutdown.  I suspect a driver bug, but this method is called
sufficiently infrequently that I can live with this hack.  WDYT?

[Pawel Osciak, 2012/09/07 15:49:13]

Could be a driver bug and/or us not being in correct/valid GLX context at the
time of destroying the glx pixmap. Is make_context_current_ above at l.270
working for you?

I agree this XSync would not be a big deal being here only, although I'm more
worried about leaking memory with the above error (unless it's because of
double-freeing, here and somewhere in the driver perhaps).

[Ami GONE FROM CHROMIUM, 2012/09/12 00:53:10]

It must be, or else the failing opcode wouldn't be getting called :)
yes, my suspicion is on the driver.

 }
 
 void VaapiH264Decoder::DecodeSurface::Acquire(int32 input_id, int poc) {