H264 codec: Check profile-level-id when matching

webrtc/media/base/mediaconstants.cc

 /*
  *  Copyright (c) 2012 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 79 matching lines @@
 const char kGoogleSctpDataCodecName[] = "google-sctp-data";
 
 const char kComfortNoiseCodecName[] = "CN";
 
 const char kVp8CodecName[] = "VP8";
 const char kVp9CodecName[] = "VP9";
 const char kH264CodecName[] = "H264";
 
 // RFC 6184 RTP Payload Format for H.264 video
 const char kH264FmtpProfileLevelId[] = "profile-level-id";
+// If no profile-level-id is present as a parameter, the Baseline Profile
+// without additional constraints at Level 1 is implied.
+const char kH264FmtpDefaultProfileLevelId[] = "66000a";

[hta-webrtc, 2016/09/19 06:38:36]

I don't think this is baseline.

Remember that the bits in the middle are *restrictive* bits - you turn them on
to restrict the profile to this functionality set only.

Also, our default profile is *constrained* baseline, not just baseline.

My general advice when trying to define profile-level-id values is to use only
values you have seen in the wild.

[magjed_webrtc, 2016/09/19 12:40:30]

Sorry, it should be 66 in decimal, i.e. 0x42 in hex.

This is the default when no profile-level-id is specified. We still use
Constrained Baseline in cricket::DefaultVideoCodecList(), that logic has not
been touched. 

This default is not something I made up, I'm trying to base it on the spec. This
is from https://www.iana.org/assignments/media-types/video/H264-SVC: "If no
profile-level-id is present, the Baseline Profile without additional constraints
at Level 1 MUST be implied." I interpreted this as the constraints set flags
should all be zero, but please correct me if I'm wrong.

I guess we could still set constraint_set0_flag, even though it's redundant.
This is from your message with Mo Zanaty:
"constraint_set0_flag: baseline profile features only (which includes
ASO/FMO/RS)
...
It is a bit redundant to signal constraint set 0 (BP) when using profile=XX=42
(BP), which is still ok, but this signals full/unconstrained BP unless
constraint set 1 and/or 2 are also set to signal CBP."

[hta-webrtc, 2016/10/05 11:56:29]

Yes, I think we should set those 2 flags. They are a bit illogical to my mind,
because setting them to false means that the profile is not constrained, while
setting them to true means that the profile is constrained - I'd think that the
opposite was logical (true = more permitted), but that's not what the spec says.

 const char kH264FmtpLevelAsymmetryAllowed[] = "level-asymmetry-allowed";
 const char kH264FmtpPacketizationMode[] = "packetization-mode";
 const char kH264ProfileLevelConstrainedBaseline[] = "42e01f";
 
 const int kDefaultVp8PlType = 100;
 const int kDefaultVp9PlType = 101;
 const int kDefaultH264PlType = 107;
 const int kDefaultRedPlType = 116;
 const int kDefaultUlpfecType = 117;
 const int kDefaultRtxVp8PlType = 96;
 const int kDefaultRtxVp9PlType = 97;
 const int kDefaultRtxRedPlType = 98;
 const int kDefaultRtxH264PlType = 99;
 
 const int kDefaultVideoMaxWidth = 640;
 const int kDefaultVideoMaxHeight = 400;
 const int kDefaultVideoMaxFramerate = 30;
 }  // namespace cricket