VideoToolbox encoder for cast senders.

media/cast/sender/video_sender.cc

Index: media/cast/sender/video_sender.cc
diff --git a/media/cast/sender/video_sender.cc b/media/cast/sender/video_sender.cc
index e7628327887a2566257e3be2ef14433acb200dad..0ac1bdf0a688e6c25f00b9d90425dd4d4373211b 100644
--- a/media/cast/sender/video_sender.cc
+++ b/media/cast/sender/video_sender.cc
@@ -16,6 +16,10 @@
 #include "media/cast/sender/external_video_encoder.h"
 #include "media/cast/sender/video_encoder_impl.h"
 
+#if defined(OS_MACOSX)
+#include "media/cast/sender/h264_vt_encoder.h"
+#endif
+
 namespace media {
 namespace cast {
 
@@ -64,6 +68,20 @@ VideoSender::VideoSender(
           << " and max_frame_rate=" << video_config.max_frame_rate;
   DCHECK_GT(max_unacked_frames_, 0);
 
+#if defined(OS_MACOSX)
+  // On Apple platforms, use the hardware H.264 encoder if possible. It is the
+  // only reasonable option for iOS.
+  if (!video_config.use_external_encoder &&

[miu, 2014/09/24 00:10:14]

|use_external_encoder| is set to true when the hardware encoder should be used,
so did you mean to omit the bang?

Also, will video toolbox provide a software encoder on Mac OS, if the hardware
support does not exist?  Perhaps the value of |use_external_encoder| should be
ignored here, and handled inside H264VideoToolboxEncoder::Initialize()?

[jfroy, 2014/09/24 01:00:58]

I understood |use_external_encoder| from the point of view of cast, which is to
say that it should use the client-provided callbacks to allocate an external
encoder managed by an instance of |ExternalVideoEncoder|. This is in fact what
my first implementation used.

However, |VideoEncodeAccelerator| (which is used by |ExternalVideoEncoder|) is a
very poor interface for VideoToolbox (it forces unnecessary buffer allocations
into unnecessarily large shared memory buffers). The basic |VideoEncoder|
interface was much better, and this is what |H264VideoToolboxEncoder|
implements. So from this point of view, this check is correct.

VideoToolbox is opaque from the POV of the client. On OS X, it will indeed
provide software encoding if there is no hardware encoder or if the hardware
encoder is busy. On iOS, it only provides access to a hardware encoder and will
fail with a "resource busy" error if someone else is already using it. This
could be changed in the future by Apple on specific hardware.

So in summary, |use_external_encoder| implies using the |ExternalVideoEncoder|
class and using the client-provided vea and memory callbacks, which this
implementation does not use.

+      video_config.codec == CODEC_VIDEO_H264) {
+    video_encoder_.reset(new H264VideoToolboxEncoder(
+        cast_environment,
+        video_config,
+        base::Bind(&VideoSender::OnEncoderInitialized,
+                   weak_factory_.GetWeakPtr(),
+                   initialization_cb)));
+  }
+#endif  // defined(OS_MACOSX)
+#if !defined(OS_IOS)
   if (video_config.use_external_encoder) {
     video_encoder_.reset(new ExternalVideoEncoder(
         cast_environment,
@@ -83,6 +101,7 @@ VideoSender::VideoSender(
         cast_environment, video_config, max_unacked_frames_));
     cast_initialization_status_ = STATUS_VIDEO_INITIALIZED;
   }
+#endif  // !defined(OS_IOS)
 
   if (cast_initialization_status_ == STATUS_VIDEO_INITIALIZED) {
     cast_environment->PostTask(