Initialize CPU-specific features in media when starting the host.

remoting/host/remoting_me2me_host.cc

Index: remoting/host/remoting_me2me_host.cc
diff --git a/remoting/host/remoting_me2me_host.cc b/remoting/host/remoting_me2me_host.cc
index d1deab98c77bcacbba6154ad171184db9198aaa3..da4787f524aac87309450d5fcebb41a69eb0c5f7 100644
--- a/remoting/host/remoting_me2me_host.cc
+++ b/remoting/host/remoting_me2me_host.cc
@@ -28,6 +28,7 @@
 #include "ipc/ipc_channel.h"
 #include "ipc/ipc_channel_proxy.h"
 #include "ipc/ipc_listener.h"
+#include "media/base/media.h"
 #include "net/base/network_change_notifier.h"
 #include "net/socket/ssl_server_socket.h"
 #include "net/url_request/url_fetcher.h"
@@ -1045,6 +1046,9 @@ int HostProcessMain() {
   // single-threaded.
   net::EnableSSLServerSockets();
 
+  // Ensures runtime specific CPU features are initialized.
+  media::InitializeCPUSpecificMediaFeatures();

[Wez, 2013/05/30 17:17:29]

This looks reasonable given the bug description, but should we be initializing
the entire media library, not just CPU-specific features? 

And should media really be crashing if this isn't initialised?

[alexeypa (please no reviews), 2013/05/30 17:35:01]

I just mirrored the corresponding change in remoting_unittests. I can't be 100%
but this seems to be the right thing to do given that the host does not call
media::InitializeMediaLibrary().
  
I think it is better to crash than not. The crash makes it pretty obvious what
is missing. Defaulting to, say, C implementation will make it much harder to
notice that something is not right. 

+
   // Create the main message loop and start helper threads.
   base::MessageLoop message_loop(base::MessageLoop::TYPE_UI);
   scoped_ptr<ChromotingHostContext> context =