Generate FMTP parameters for the H.264 codec.

webrtc/media/engine/webrtcvideoengine2.cc

 /*
  *  Copyright (c) 2014 The WebRTC project authors. All Rights Reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
@@ skipping 367 matching lines @@
   codecs.push_back(MakeVideoCodecWithDefaultFeedbackParams(kDefaultVp8PlType,
                                                            kVp8CodecName));
   codecs.push_back(
       VideoCodec::CreateRtxCodec(kDefaultRtxVp8PlType, kDefaultVp8PlType));
   if (CodecIsInternallySupported(kVp9CodecName)) {
     codecs.push_back(MakeVideoCodecWithDefaultFeedbackParams(kDefaultVp9PlType,
                                                              kVp9CodecName));
     codecs.push_back(
         VideoCodec::CreateRtxCodec(kDefaultRtxVp9PlType, kDefaultVp9PlType));
   }
   if (CodecIsInternallySupported(kH264CodecName)) {

[hbos, 2016/04/12 11:41:14]

Hmm, I guess this was always the case, but this conditional means the SDP will
only be correctly offered if there are internal H.264 implementations available.
Even if an external factory (Chrome) provides both HW encoder and HW decoder, an
internal implementation must be available - and in that case unused - for the
SDP to contain H264.

I suppose it's correct behavior for the "default codec list" to only consider
"default" (internal) codecs. But how is the case handled for purely external
codecs, so that those codecs are offered in the SDP? If that case isn't handled,
there must be an an implicit assumption somewhere about the default codec list
being complete when offering SDP. Or, if that case is handled, perhaps there is
another place in the code where we should modify the codec list.

- Should we add a TODO before landing?

[hta-webrtc, 2016/04/12 12:48:44]

Yes, that makes the third TODO here: Move SDP parameter generation for codecs to
depend on the codec implementation, not on this file.

We have another effort (somewhere) to remove the idea of "internal codecs"
altogether and only have a "default codec list" that contains the codecs that
are included in the compilation. That will hopefully revisit this piece of code!

-    codecs.push_back(MakeVideoCodecWithDefaultFeedbackParams(kDefaultH264PlType,
-                                                             kH264CodecName));
+    VideoCodec codec = MakeVideoCodecWithDefaultFeedbackParams(
+        kDefaultH264PlType, kH264CodecName);
+    // TODO(hta): Move selection of profile-level-id to codec implementation.
+    // TODO(hta): Set FMTP parameters for all codecs of type H264.
+    codec.SetParam(kH264FmtpProfileLevelId,
+                   kH264ProfileLevelConstrainedBaseline);
+    codec.SetParam(kH264FmtpLevelAsymmetryAllowed, "1");
+    codec.SetParam(kH264FmtpPacketizationMode, "1");
+    codecs.push_back(codec);
     codecs.push_back(
         VideoCodec::CreateRtxCodec(kDefaultRtxH264PlType, kDefaultH264PlType));
   }
   codecs.push_back(VideoCodec(kDefaultRedPlType, kRedCodecName));
   codecs.push_back(
       VideoCodec::CreateRtxCodec(kDefaultRtxRedPlType, kDefaultRedPlType));
   codecs.push_back(VideoCodec(kDefaultUlpfecType, kUlpfecCodecName));
   return codecs;
 }
 
@@ skipping 2166 matching lines @@
         rtx_mapping[video_codecs[i].codec.id] !=
             fec_settings.red_payload_type) {
       video_codecs[i].rtx_payload_type = rtx_mapping[video_codecs[i].codec.id];
     }
   }
 
   return video_codecs;
 }
 
 }  // namespace cricket