Add initial SHM-only Wayland Ozone implementation

media/ozone/media_ozone_platform.cc

Index: media/ozone/media_ozone_platform.cc
diff --git a/media/ozone/media_ozone_platform.cc b/media/ozone/media_ozone_platform.cc
index f17d827b1e6fdfbea39640b3e029594dd5e478e6..c1c45864c28d67bf6034f2ded078ff6deb05b28e 100644
--- a/media/ozone/media_ozone_platform.cc
+++ b/media/ozone/media_ozone_platform.cc
@@ -57,6 +57,10 @@ MediaOzonePlatform* CreateMediaOzonePlatformHeadless() {
   return new MediaOzonePlatformStub;
 }
 
+MediaOzonePlatform* CreateMediaOzonePlatformWayland() {

[rjkroege, 2016/01/25 20:41:31]

someday I suppose that we should have the same dynamic platform facility here as
we do in the core? I will file a bug.

[spang, 2016/01/25 21:23:59]

I'm not sure how we want to proceed here.

Currently the only ozone build with working accelerated decode is CrOS, and it
hardcodes the assumption of platform=drm. So it'd simply blow up if you tried to
run it with another platform.

It's been suggested that instead of subclassing VDA, we should instead move one
level lower and subclass VAAPIDevice or V4L2Device (each being optional). Then
you could support accelerated decode only via one of chrome's preferred APIs,
and the video guys have already done most of the work of integrating. This is
much simpler than trying to implement your own VDA and lends itself better to
how our code is organized (we wouldn't need media/ozone/ at all).

I think the video guys were designing a mojom for VDAs, so it might be
interesting to look into that.

+  return new MediaOzonePlatformStub;
+}
+
 MediaOzonePlatform::MediaOzonePlatform() {
   CHECK(!instance_) << "There should only be a single MediaOzonePlatform.";
   instance_ = this;