Support for H264 HW offload for webRTC.

content/renderer/media/rtc_video_encoder.cc

Index: content/renderer/media/rtc_video_encoder.cc
diff --git a/content/renderer/media/rtc_video_encoder.cc b/content/renderer/media/rtc_video_encoder.cc
index 1b33fc54c90abe6881a48565c6d9fbb4aa58b513..49677c8cad3665a9bfbfcc9333cd393228dc6181 100644
--- a/content/renderer/media/rtc_video_encoder.cc
+++ b/content/renderer/media/rtc_video_encoder.cc
@@ -16,6 +16,7 @@
 #include "media/base/video_frame.h"
 #include "media/base/video_util.h"
 #include "media/filters/gpu_video_accelerator_factories.h"
+#include "media/filters/h264_parser.h"
 #include "media/video/video_encode_accelerator.h"
 #include "third_party/webrtc/system_wrappers/interface/tick_util.h"
 
@@ -27,6 +28,39 @@
 
 namespace content {
 
+namespace {
+
+void GetRTPFragmentationHeaderH264(

[Pawel Osciak, 2014/08/10 00:30:30]

Please document.

[hshi1, 2014/08/12 01:06:55]

Done.

+    webrtc::RTPFragmentationHeader& header, uint8_t* data, uint32_t length) {
+  media::H264Parser parser;
+  parser.SetStream(data, length);
+
+  std::vector<media::H264NALU> nalu_vector;
+  while (true) {
+    media::H264NALU nalu;
+    media::H264Parser::Result result;
+    result = parser.AdvanceToNextNALU(&nalu);
+    if (result == media::H264Parser::kOk) {

[Pawel Osciak, 2014/08/10 00:30:30]

Nit: switch?

[hshi1, 2014/08/10 00:36:10]

I thought about that but then a "break" in the switch block would just break out
of the switch, not the "while" loop. I'd need a goto or a local bool to be able
to break out.

+      nalu_vector.push_back(nalu);
+    } else if (result == media::H264Parser::kEOStream) {
+      break;
+    } else {
+      DLOG(ERROR) << "Unexpected H264 parser result";
+      break;

[Pawel Osciak, 2014/08/10 00:30:29]

I think we should handle errors? What happens if there is an error in the
stream?

[hshi1, 2014/08/12 01:06:55]

Should errors be expected? The stream is returned by the GpuVEA and not by user
input. I think a DLOG here should suffice?

[Pawel Osciak, 2014/08/12 11:06:38]

Well, we check for this anyway, and I'd expect things to not work too well if we
just pass this along, especially with incorrect fragmentation header. And if we
assume GpuVEA is always right, should have even less issue with having a
NotifyError() here, or at least dropping it...
What do you think?

[hshi1, 2014/08/12 18:08:22]

Sounds reasonable. Note that this function is in the anonymous namespace. I'm
making it return a bool to indicate error.

+    }
+  }
+
+  header.VerifyAndAllocateFragmentationHeader(nalu_vector.size());
+  for (size_t i = 0; i < nalu_vector.size(); ++i) {
+    header.fragmentationOffset[i] = nalu_vector[i].data - data;
+    header.fragmentationLength[i] = nalu_vector[i].size;
+    header.fragmentationPlType[i] = 0;
+    header.fragmentationTimeDiff[i] = 0;
+  }
+}
+
+}  // namespace
+
 // This private class of RTCVideoEncoder does the actual work of communicating
 // with a media::VideoEncodeAccelerator for handling video encoding.  It can
 // be created on any thread, but should subsequently be posted to (and Destroy()
@@ -648,6 +682,25 @@ void RTCVideoEncoder::ReturnEncodedImage(scoped_ptr<webrtc::EncodedImage> image,
   if (!encoded_image_callback_)
     return;
 
+  webrtc::RTPFragmentationHeader header;
+  memset(&header, 0, sizeof(header));
+  switch (video_codec_type_) {
+    case webrtc::kVideoCodecVP8:
+    case webrtc::kVideoCodecGeneric:

[Pawel Osciak, 2014/08/10 00:30:30]

Generic wasn't here before. And given that it's treated the same as H264 in the
other file, why is it together with VP8 here?
Also, do we really need both? Could we fix webrtc to not use both instead?

[hshi1, 2014/08/10 00:36:10]

We're keeping Generic (and the payload type "CAST1") for v1 casting until we're
ready to deprecate it. Currently v1 casting is still being used on Stable.

[Pawel Osciak, 2014/08/10 01:14:34]

Generic is treated as H264 in the format conversion change, but not as H264
here...

[hshi1, 2014/08/11 17:43:00]

You're correct that Generic is treated differently from H264. In webrtc point of
view, "Generic" means opaque payloads not subject to the H.264 packetization
logic, they are always passed as a whole chunk with no fragmentation info
available. This is what we use for castV1.

We only get RTP fragmentation headers for the "real" H264 codec type.

[Pawel Osciak, 2014/08/12 11:06:38]

Ok, I'm fine with this, but please add a comment about this.

[hshi1, 2014/08/12 18:08:22]

Done.

+      header.VerifyAndAllocateFragmentationHeader(1);
+      header.fragmentationOffset[0] = 0;
+      header.fragmentationLength[0] = image->_length;
+      header.fragmentationPlType[0] = 0;
+      header.fragmentationTimeDiff[0] = 0;
+      break;
+    case webrtc::kVideoCodecH264:
+      GetRTPFragmentationHeaderH264(header, image->_buffer, image->_length);
+      break;
+    default:
+      NOTREACHED() << "Invalid video codec type";
+      return;
+  }
+
   webrtc::CodecSpecificInfo info;
   memset(&info, 0, sizeof(info));
   info.codecType = video_codec_type_;
@@ -657,15 +710,6 @@ void RTCVideoEncoder::ReturnEncodedImage(scoped_ptr<webrtc::EncodedImage> image,
     info.codecSpecific.VP8.keyIdx = -1;
   }
 
-  // Generate a header describing a single fragment.
-  webrtc::RTPFragmentationHeader header;
-  memset(&header, 0, sizeof(header));
-  header.VerifyAndAllocateFragmentationHeader(1);
-  header.fragmentationOffset[0] = 0;
-  header.fragmentationLength[0] = image->_length;
-  header.fragmentationPlType[0] = 0;
-  header.fragmentationTimeDiff[0] = 0;
-
   int32_t retval = encoded_image_callback_->Encoded(*image, &info, &header);
   if (retval < 0) {
     DVLOG(2) << "ReturnEncodedImage(): encoded_image_callback_ returned "