Removing `preference` field from `cricket::Codec`.

Removing `preference` field from `cricket::Codec`.

This field only existed as an implementation detail for getting the
codecs sorted, so it doesn't need to be in the public interface.
It cluttered the code and undesirably affected codec comparisons,
causing the video encoder to be reconfigured if a codec's preference
changed but nothing else did.

BUG=webrtc:5690
Committed: https://crrev.com/67cf2c1294e65d270e860a3103f7dd630656766d
Cr-Commit-Position: refs/heads/master@{#12349}

[Taylor Brandstetter, 2016-03-30 20:05:11]

deadbeef@webrtc.org changed reviewers:
+ pbos@webrtc.org

[pbos-webrtc, 2016-04-04 07:58:58]

Change LG but I think we should remove cricket::VideoCodec from here if we can.

https://codereview.webrtc.org/1845673002/diff/1/webrtc/media/engine/webrtcvid...
File webrtc/media/engine/webrtcvideoengine2.cc (right):

https://codereview.webrtc.org/1845673002/diff/1/webrtc/media/engine/webrtcvid...
webrtc/media/engine/webrtcvideoengine2.cc:762: new_codec.codec.preference = 0;
Can we change VideoCodecSettings instead to not contain a cricket::VideoCodec
but only the parts of it that we need?

[Taylor Brandstetter, 2016-04-04 17:45:19]

On 2016/04/04 07:58:58, pbos-webrtc wrote:
> Change LG but I think we should remove cricket::VideoCodec from here if we
can.
> 
>
https://codereview.webrtc.org/1845673002/diff/1/webrtc/media/engine/webrtcvid...
> File webrtc/media/engine/webrtcvideoengine2.cc (right):
> 
>
https://codereview.webrtc.org/1845673002/diff/1/webrtc/media/engine/webrtcvid...
> webrtc/media/engine/webrtcvideoengine2.cc:762: new_codec.codec.preference = 0;
> Can we change VideoCodecSettings instead to not contain a cricket::VideoCodec
> but only the parts of it that we need?

It looks like just about everything but the clockrate and preference is needed.
Rather than create two classes that duplicate the same functionality, maybe we
could remove the "preference" field from Codec, and just rely on their order in
a vector everywhere. Does that sound good?

[Taylor Brandstetter, 2016-04-04 23:26:13]

Description was changed from

==========
Don't reconfigure the encoder if a codec's preference changes.

This may happen if a subsequent negotiation includes fewer codecs,
as a result of one of the codecs being rejected. But the encoder
shouldn't care about this.

BUG=webrtc:5690
==========

to

==========
Removing `preference` field from `cricket::Codec`.
    
This field only existed as an implementation detail for getting the
codecs sorted, so it doesn't need to be in the public interface.
It cluttered the code and undesirably affected codec comparisons,
causing the video encoder to be reconfigured if a codec's preference
changed but nothing else did.

BUG=webrtc:5690
==========

[Taylor Brandstetter, 2016-04-04 23:26:13]

deadbeef@webrtc.org changed reviewers:
+ pthatcher@webrtc.org

[Taylor Brandstetter, 2016-04-04 23:30:03]

PTAL Peter. This CL may seem big, but in all but a few files, it's just removing
a dummy `preference` value from `Codec` constructor invocations.

[pbos-webrtc, 2016-04-05 09:30:32]

lgtm, I'd like at least one more eye on it though. :)

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/api/webrtcsdp_unit...
File webrtc/api/webrtcsdp_unittest.cc (right):

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/api/webrtcsdp_unit...
webrtc/api/webrtcsdp_unittest.cc:2150: // The codecs in the
AudioContentDescription will be sorted by preference.
This is no longer correct, grep for preference a bit and flip through them,
they're not that many right?

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/media/engine/webrt...
File webrtc/media/engine/webrtcvideoengine2_unittest.cc (right):

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/media/engine/webrt...
webrtc/media/engine/webrtcvideoengine2_unittest.cc:2422: // This may happen when
a subsequent negotiation includes fewew codecs, as a
fewer

[Taylor Brandstetter, 2016-04-05 17:57:13]

Oh, when I said "PTAL Peter" I meant Thatcher since he's an /api/ owner. Thanks
for reviewing though!

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/api/webrtcsdp_unit...
File webrtc/api/webrtcsdp_unittest.cc (right):

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/api/webrtcsdp_unit...
webrtc/api/webrtcsdp_unittest.cc:2150: // The codecs in the
AudioContentDescription will be sorted by preference.
On 2016/04/05 09:30:32, pbos-webrtc wrote:
> This is no longer correct, grep for preference a bit and flip through them,
> they're not that many right?

Well they're still sorted by preference (the order in which they're pushed back
matters). The preference value just no longer needs to be explicitly set, as
it's implicit based on the array ordering.

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/media/engine/webrt...
File webrtc/media/engine/webrtcvideoengine2_unittest.cc (right):

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/media/engine/webrt...
webrtc/media/engine/webrtcvideoengine2_unittest.cc:2422: // This may happen when
a subsequent negotiation includes fewew codecs, as a
On 2016/04/05 09:30:32, pbos-webrtc wrote:
> fewer

Done.

[pbos-webrtc, 2016-04-05 18:11:35]

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/api/webrtcsdp_unit...
File webrtc/api/webrtcsdp_unittest.cc (right):

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/api/webrtcsdp_unit...
webrtc/api/webrtcsdp_unittest.cc:2150: // The codecs in the
AudioContentDescription will be sorted by preference.
On 2016/04/05 17:57:13, Taylor Brandstetter wrote:
> On 2016/04/05 09:30:32, pbos-webrtc wrote:
> > This is no longer correct, grep for preference a bit and flip through them,
> > they're not that many right?
> 
> Well they're still sorted by preference (the order in which they're pushed
back
> matters). The preference value just no longer needs to be explicitly set, as
> it's implicit based on the array ordering.

Can you clarify that in the comment (preferred codec first)?

[Taylor Brandstetter, 2016-04-06 01:11:15]

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/api/webrtcsdp_unit...
File webrtc/api/webrtcsdp_unittest.cc (right):

https://codereview.webrtc.org/1845673002/diff/40001/webrtc/api/webrtcsdp_unit...
webrtc/api/webrtcsdp_unittest.cc:2150: // The codecs in the
AudioContentDescription will be sorted by preference.
On 2016/04/05 18:11:35, pbos-webrtc wrote:
> On 2016/04/05 17:57:13, Taylor Brandstetter wrote:
> > On 2016/04/05 09:30:32, pbos-webrtc wrote:
> > > This is no longer correct, grep for preference a bit and flip through
them,
> > > they're not that many right?
> > 
> > Well they're still sorted by preference (the order in which they're pushed
> back
> > matters). The preference value just no longer needs to be explicitly set, as
> > it's implicit based on the array ordering.
> 
> Can you clarify that in the comment (preferred codec first)?

Comment has been clarified. Only reference to "preference" now is with ICE
candidates.

[pbos-webrtc, 2016-04-06 09:24:27]

thanks, lgtm

[pthatcher1, 2016-04-11 21:53:40]

lgtm

https://codereview.webrtc.org/1845673002/diff/80001/webrtc/api/webrtcsdp.cc
File webrtc/api/webrtcsdp.cc (right):

https://codereview.webrtc.org/1845673002/diff/80001/webrtc/api/webrtcsdp.cc#n...
webrtc/api/webrtcsdp.cc:2225: media_desc->set_codecs(codecs);
It would be nice if this weren't O(n^2), but I guess that's at most 127^2.

Maybe say something like "It's O(n^2), but n <= 127, it's not so bad.  If we
ever support more than 127 PTs (which is very unlikely), then we'd want to
revisit this."

[Taylor Brandstetter, 2016-04-12 00:18:01]

https://codereview.webrtc.org/1845673002/diff/80001/webrtc/api/webrtcsdp.cc
File webrtc/api/webrtcsdp.cc (right):

https://codereview.webrtc.org/1845673002/diff/80001/webrtc/api/webrtcsdp.cc#n...
webrtc/api/webrtcsdp.cc:2225: media_desc->set_codecs(codecs);
On 2016/04/11 21:53:40, pthatcher1 wrote:
> It would be nice if this weren't O(n^2), but I guess that's at most 127^2.
> 
> Maybe say something like "It's O(n^2), but n <= 127, it's not so bad.  If we
> ever support more than 127 PTs (which is very unlikely), then we'd want to
> revisit this."

It's actually O(N^2 log N) :)
I fixed this pretty easily by making a map of payload types to preferences
though.

[pthatcher1, 2016-04-12 00:35:20]

Oh, you're right.  Even worse :)

https://codereview.webrtc.org/1845673002/diff/100001/webrtc/api/webrtcsdp.cc
File webrtc/api/webrtcsdp.cc (right):

https://codereview.webrtc.org/1845673002/diff/100001/webrtc/api/webrtcsdp.cc#...
webrtc/api/webrtcsdp.cc:2232: });
A https://en.wikipedia.org/wiki/Schwartzian_transform might be more work as
well.

https://codereview.webrtc.org/1845673002/diff/100001/webrtc/pc/mediasession.cc
File webrtc/pc/mediasession.cc (right):

https://codereview.webrtc.org/1845673002/diff/100001/webrtc/pc/mediasession.c...
webrtc/pc/mediasession.cc:843: });
If you're going to fix the sort in one place, you should probably fix it in
both.

[Taylor Brandstetter, 2016-04-12 01:23:29]

https://codereview.webrtc.org/1845673002/diff/100001/webrtc/api/webrtcsdp.cc
File webrtc/api/webrtcsdp.cc (right):

https://codereview.webrtc.org/1845673002/diff/100001/webrtc/api/webrtcsdp.cc#...
webrtc/api/webrtcsdp.cc:2232: });
On 2016/04/12 00:35:19, pthatcher1 wrote:
> A https://en.wikipedia.org/wiki/Schwartzian_transform might be more work as
> well.
> 

Slightly, yes. But at least it's on the same order of complexity.

https://codereview.webrtc.org/1845673002/diff/100001/webrtc/pc/mediasession.cc
File webrtc/pc/mediasession.cc (right):

https://codereview.webrtc.org/1845673002/diff/100001/webrtc/pc/mediasession.c...
webrtc/pc/mediasession.cc:843: });
On 2016/04/12 00:35:19, pthatcher1 wrote:
> If you're going to fix the sort in one place, you should probably fix it in
> both.

Done.

[Taylor Brandstetter, 2016-04-12 22:37:42]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-04-12 22:37:43]

The patchset sent to the CQ was uploaded after l-g-t-m from pbos@webrtc.org,
pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1845673002/#ps120001 (title:
"Optimize in another place.")

[commit-bot: I haz the power, 2016-04-12 22:37:49]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1845673002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1845673002/120001

[commit-bot: I haz the power, 2016-04-12 22:39:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-12 22:39:02]

Try jobs failed on following builders:
  android_compile_x64_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_compile_x64_dbg...)
  android_compile_x86_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_compile_x86_dbg...)
  android_gn_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_gn_dbg/builds/1...)
  android_gn_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_gn_rel/builds/1...)
  ios32_sim_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios32_sim_dbg/builds/6620)
  ios64_sim_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios64_sim_dbg/builds/6611)
  ios_arm64_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_dbg/builds/8943)
  ios_arm64_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_rel/builds/8863)
  ios_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_dbg/builds/14151)
  ios_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_rel/builds/12786)
  linux_asan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_asan/builds/13866)
  linux_libfuzzer_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_libfuzzer_rel/bui...)
  linux_ubsan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_ubsan/builds/1177)
  linux_ubsan_vptr on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_ubsan_vptr/builds...)
  mac_asan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_asan/builds/13785)
  mac_baremetal on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_baremetal/builds/10500)
  mac_compile_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_compile_dbg/builds/...)
  mac_gn_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_gn_rel/builds/8486)
  mac_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_rel/builds/14210)
  win_clang_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/win_clang_dbg/builds/2445)
  win_drmemory_light on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/win_drmemory_light/buil...)
  win_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/win_rel/builds/14168)

[Taylor Brandstetter, 2016-04-13 00:32:40]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-04-13 00:32:40]

The patchset sent to the CQ was uploaded after l-g-t-m from pbos@webrtc.org,
pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1845673002/#ps180001 (title:
"Fixing sort order (got reversed when optimizations were made)")

[commit-bot: I haz the power, 2016-04-13 00:32:43]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1845673002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1845673002/180001

[commit-bot: I haz the power, 2016-04-13 02:33:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-13 02:33:11]

Try jobs failed on following builders:
  win_baremetal on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[Taylor Brandstetter, 2016-04-13 17:05:07]

The CQ bit was checked by deadbeef@webrtc.org

[commit-bot: I haz the power, 2016-04-13 17:05:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1845673002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1845673002/180001

[commit-bot: I haz the power, 2016-04-13 17:07:19]

Description was changed from

==========
Removing `preference` field from `cricket::Codec`.
    
This field only existed as an implementation detail for getting the
codecs sorted, so it doesn't need to be in the public interface.
It cluttered the code and undesirably affected codec comparisons,
causing the video encoder to be reconfigured if a codec's preference
changed but nothing else did.

BUG=webrtc:5690
==========

to

==========
Removing `preference` field from `cricket::Codec`.
    
This field only existed as an implementation detail for getting the
codecs sorted, so it doesn't need to be in the public interface.
It cluttered the code and undesirably affected codec comparisons,
causing the video encoder to be reconfigured if a codec's preference
changed but nothing else did.

BUG=webrtc:5690
==========

[commit-bot: I haz the power, 2016-04-13 17:07:21]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2016-04-13 17:07:34]

Description was changed from

==========
Removing `preference` field from `cricket::Codec`.
    
This field only existed as an implementation detail for getting the
codecs sorted, so it doesn't need to be in the public interface.
It cluttered the code and undesirably affected codec comparisons,
causing the video encoder to be reconfigured if a codec's preference
changed but nothing else did.

BUG=webrtc:5690
==========

to

==========
Removing `preference` field from `cricket::Codec`.

This field only existed as an implementation detail for getting the
codecs sorted, so it doesn't need to be in the public interface.
It cluttered the code and undesirably affected codec comparisons,
causing the video encoder to be reconfigured if a codec's preference
changed but nothing else did.

BUG=webrtc:5690

Committed: https://crrev.com/67cf2c1294e65d270e860a3103f7dd630656766d
Cr-Commit-Position: refs/heads/master@{#12349}
==========

[commit-bot: I haz the power, 2016-04-13 17:07:35]

Patchset 10 (id:??) landed as
https://crrev.com/67cf2c1294e65d270e860a3103f7dd630656766d
Cr-Commit-Position: refs/heads/master@{#12349}

[sanmrtn96, 2016-04-14 15:55:44]

On 2016/04/13 17:07:35, commit-bot: I haz the power wrote:
> Patchset 10 (id:??) landed as
> https://crrev.com/67cf2c1294e65d270e860a3103f7dd630656766d
> Cr-Commit-Position: refs/heads/master@{#12349}

Hi,

since this recent commit on, JsepSessionDescription::Initialize throws
std::bad_alloc for some unknown reasons. After some investigations I found out
that it's ParseMediaDescription throwing the mentioned exception. Everything
used to work before this commit.

You can try to reproduce the issue with passing the SDP string below to
Initialize(), the string in my case is generated by the Google API itself at
some point in my program (I did not invent anything in the SDP):

Code sample:
    webrtc::JsepSessionDescription jsep_session_desc("dummy");
    webrtc::SdpParseError parseerror;
    if (!jsep_session_desc.Initialize(sdp, &parseerror)) { // throws
std::bad_alloc
          // error

SDP string:


v=0
o=- 3689508302284005197 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS stream_label
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 102 0 8 106 105 13 127 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:q48RnQP8moDmhl3r
a=ice-pwd:94EEJYcM478FE2PvrIeT/sDd
a=fingerprint:sha-256
1F:E3:BF:30:FA:64:27:0C:6A:EC:E8:36:AE:F6:35:C7:80:F6:0A:46:B1:88:80:8D:E8:2E:F8:A2:F4:64:28:4C
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10; useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:102 ILBC/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:127 red/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
m=video 9 UDP/TLS/RTP/SAVPF 100 101 116 117 120 96 97 98
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:q48RnQP8moDmhl3r
a=ice-pwd:94EEJYcM478FE2PvrIeT/sDd
a=fingerprint:sha-256
1F:E3:BF:30:FA:64:27:0C:6A:EC:E8:36:AE:F6:35:C7:80:F6:0A:46:B1:88:80:8D:E8:2E:F8:A2:F4:64:28:4C
a=setup:actpass
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtpmap:101 VP9/90000
a=rtcp-fb:101 ccm fir
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=rtcp-fb:101 transport-cc
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:120 H264/90000
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=101
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=116
a=ssrc-group:FID 3784504217 2216658055
a=ssrc:3784504217 cname:bd13e4/xvZtv4u8o
a=ssrc:3784504217 msid:stream_label video_label
a=ssrc:3784504217 mslabel:stream_label
a=ssrc:3784504217 label:video_label
a=ssrc:2216658055 cname:bd13e4/xvZtv4u8o
a=ssrc:2216658055 msid:stream_label video_label
a=ssrc:2216658055 mslabel:stream_label
a=ssrc:2216658055 label:video_label

[pbos-webrtc, 2016-04-14 15:59:59]

On 2016/04/14 15:55:44, sanmrtn96 wrote:
> On 2016/04/13 17:07:35, commit-bot: I haz the power wrote:
> > Patchset 10 (id:??) landed as
> > https://crrev.com/67cf2c1294e65d270e860a3103f7dd630656766d
> > Cr-Commit-Position: refs/heads/master@{#12349}
> 
> Hi,
> 
> since this recent commit on, JsepSessionDescription::Initialize throws
> std::bad_alloc for some unknown reasons. After some investigations I found out
> that it's ParseMediaDescription throwing the mentioned exception. Everything
> used to work before this commit.
> 
> You can try to reproduce the issue with passing the SDP string below to
> Initialize(), the string in my case is generated by the Google API itself at
> some point in my program (I did not invent anything in the SDP):
> 
> Code sample:
>     webrtc::JsepSessionDescription jsep_session_desc("dummy");
>     webrtc::SdpParseError parseerror;
>     if (!jsep_session_desc.Initialize(sdp, &parseerror)) { // throws
> std::bad_alloc
>           // error
> 
> SDP string:
> 
> 
> v=0
> o=- 3689508302284005197 2 IN IP4 127.0.0.1
> s=-
> t=0 0
> a=group:BUNDLE audio video
> a=msid-semantic: WMS stream_label
> m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 102 0 8 106 105 13 127 126
> c=IN IP4 0.0.0.0
> a=rtcp:9 IN IP4 0.0.0.0
> a=ice-ufrag:q48RnQP8moDmhl3r
> a=ice-pwd:94EEJYcM478FE2PvrIeT/sDd
> a=fingerprint:sha-256
>
1F:E3:BF:30:FA:64:27:0C:6A:EC:E8:36:AE:F6:35:C7:80:F6:0A:46:B1:88:80:8D:E8:2E:F8:A2:F4:64:28:4C
> a=setup:actpass
> a=mid:audio
> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
> a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> a=recvonly
> a=rtcp-mux
> a=rtpmap:111 opus/48000/2
> a=rtcp-fb:111 transport-cc
> a=fmtp:111 minptime=10; useinbandfec=1
> a=rtpmap:103 ISAC/16000
> a=rtpmap:9 G722/8000
> a=rtpmap:102 ILBC/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:106 CN/32000
> a=rtpmap:105 CN/16000
> a=rtpmap:13 CN/8000
> a=rtpmap:127 red/8000
> a=rtpmap:126 telephone-event/8000
> a=maxptime:60
> m=video 9 UDP/TLS/RTP/SAVPF 100 101 116 117 120 96 97 98
> c=IN IP4 0.0.0.0
> a=rtcp:9 IN IP4 0.0.0.0
> a=ice-ufrag:q48RnQP8moDmhl3r
> a=ice-pwd:94EEJYcM478FE2PvrIeT/sDd
> a=fingerprint:sha-256
>
1F:E3:BF:30:FA:64:27:0C:6A:EC:E8:36:AE:F6:35:C7:80:F6:0A:46:B1:88:80:8D:E8:2E:F8:A2:F4:64:28:4C
> a=setup:actpass
> a=mid:video
> a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
> a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> a=extmap:4 urn:3gpp:video-orientation
> a=sendrecv
> a=rtcp-mux
> a=rtcp-rsize
> a=rtpmap:100 VP8/90000
> a=rtcp-fb:100 ccm fir
> a=rtcp-fb:100 nack
> a=rtcp-fb:100 nack pli
> a=rtcp-fb:100 goog-remb
> a=rtcp-fb:100 transport-cc
> a=rtpmap:101 VP9/90000
> a=rtcp-fb:101 ccm fir
> a=rtcp-fb:101 nack
> a=rtcp-fb:101 nack pli
> a=rtcp-fb:101 goog-remb
> a=rtcp-fb:101 transport-cc
> a=rtpmap:116 red/90000
> a=rtpmap:117 ulpfec/90000
> a=rtpmap:120 H264/90000
> a=rtcp-fb:120 ccm fir
> a=rtcp-fb:120 nack
> a=rtcp-fb:120 nack pli
> a=rtcp-fb:120 goog-remb
> a=rtcp-fb:120 transport-cc
> a=rtpmap:96 rtx/90000
> a=fmtp:96 apt=100
> a=rtpmap:97 rtx/90000
> a=fmtp:97 apt=101
> a=rtpmap:98 rtx/90000
> a=fmtp:98 apt=116
> a=ssrc-group:FID 3784504217 2216658055
> a=ssrc:3784504217 cname:bd13e4/xvZtv4u8o
> a=ssrc:3784504217 msid:stream_label video_label
> a=ssrc:3784504217 mslabel:stream_label
> a=ssrc:3784504217 label:video_label
> a=ssrc:2216658055 cname:bd13e4/xvZtv4u8o
> a=ssrc:2216658055 msid:stream_label video_label
> a=ssrc:2216658055 mslabel:stream_label
> a=ssrc:2216658055 label:video_label

Can you/have you filed a bug at bugs.webrtc.org ? Please link it here with repro
instructions (what's your setup, etc?).

[sanmrtn96, 2016-04-14 17:03:27]

On 2016/04/14 15:59:59, pbos-webrtc wrote:
> On 2016/04/14 15:55:44, sanmrtn96 wrote:
> > On 2016/04/13 17:07:35, commit-bot: I haz the power wrote:
> > > Patchset 10 (id:??) landed as
> > > https://crrev.com/67cf2c1294e65d270e860a3103f7dd630656766d
> > > Cr-Commit-Position: refs/heads/master@{#12349}
> > 
> > Hi,
> > 
> > since this recent commit on, JsepSessionDescription::Initialize throws
> > std::bad_alloc for some unknown reasons. After some investigations I found
out
> > that it's ParseMediaDescription throwing the mentioned exception. Everything
> > used to work before this commit.
> > 
> > You can try to reproduce the issue with passing the SDP string below to
> > Initialize(), the string in my case is generated by the Google API itself at
> > some point in my program (I did not invent anything in the SDP):
> > 
> > Code sample:
> >     webrtc::JsepSessionDescription jsep_session_desc("dummy");
> >     webrtc::SdpParseError parseerror;
> >     if (!jsep_session_desc.Initialize(sdp, &parseerror)) { // throws
> > std::bad_alloc
> >           // error
> > 
> > SDP string:
> > 
> > 
> > v=0
> > o=- 3689508302284005197 2 IN IP4 127.0.0.1
> > s=-
> > t=0 0
> > a=group:BUNDLE audio video
> > a=msid-semantic: WMS stream_label
> > m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 102 0 8 106 105 13 127 126
> > c=IN IP4 0.0.0.0
> > a=rtcp:9 IN IP4 0.0.0.0
> > a=ice-ufrag:q48RnQP8moDmhl3r
> > a=ice-pwd:94EEJYcM478FE2PvrIeT/sDd
> > a=fingerprint:sha-256
> >
>
1F:E3:BF:30:FA:64:27:0C:6A:EC:E8:36:AE:F6:35:C7:80:F6:0A:46:B1:88:80:8D:E8:2E:F8:A2:F4:64:28:4C
> > a=setup:actpass
> > a=mid:audio
> > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
> > a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> > a=recvonly
> > a=rtcp-mux
> > a=rtpmap:111 opus/48000/2
> > a=rtcp-fb:111 transport-cc
> > a=fmtp:111 minptime=10; useinbandfec=1
> > a=rtpmap:103 ISAC/16000
> > a=rtpmap:9 G722/8000
> > a=rtpmap:102 ILBC/8000
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:8 PCMA/8000
> > a=rtpmap:106 CN/32000
> > a=rtpmap:105 CN/16000
> > a=rtpmap:13 CN/8000
> > a=rtpmap:127 red/8000
> > a=rtpmap:126 telephone-event/8000
> > a=maxptime:60
> > m=video 9 UDP/TLS/RTP/SAVPF 100 101 116 117 120 96 97 98
> > c=IN IP4 0.0.0.0
> > a=rtcp:9 IN IP4 0.0.0.0
> > a=ice-ufrag:q48RnQP8moDmhl3r
> > a=ice-pwd:94EEJYcM478FE2PvrIeT/sDd
> > a=fingerprint:sha-256
> >
>
1F:E3:BF:30:FA:64:27:0C:6A:EC:E8:36:AE:F6:35:C7:80:F6:0A:46:B1:88:80:8D:E8:2E:F8:A2:F4:64:28:4C
> > a=setup:actpass
> > a=mid:video
> > a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
> > a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> > a=extmap:4 urn:3gpp:video-orientation
> > a=sendrecv
> > a=rtcp-mux
> > a=rtcp-rsize
> > a=rtpmap:100 VP8/90000
> > a=rtcp-fb:100 ccm fir
> > a=rtcp-fb:100 nack
> > a=rtcp-fb:100 nack pli
> > a=rtcp-fb:100 goog-remb
> > a=rtcp-fb:100 transport-cc
> > a=rtpmap:101 VP9/90000
> > a=rtcp-fb:101 ccm fir
> > a=rtcp-fb:101 nack
> > a=rtcp-fb:101 nack pli
> > a=rtcp-fb:101 goog-remb
> > a=rtcp-fb:101 transport-cc
> > a=rtpmap:116 red/90000
> > a=rtpmap:117 ulpfec/90000
> > a=rtpmap:120 H264/90000
> > a=rtcp-fb:120 ccm fir
> > a=rtcp-fb:120 nack
> > a=rtcp-fb:120 nack pli
> > a=rtcp-fb:120 goog-remb
> > a=rtcp-fb:120 transport-cc
> > a=rtpmap:96 rtx/90000
> > a=fmtp:96 apt=100
> > a=rtpmap:97 rtx/90000
> > a=fmtp:97 apt=101
> > a=rtpmap:98 rtx/90000
> > a=fmtp:98 apt=116
> > a=ssrc-group:FID 3784504217 2216658055
> > a=ssrc:3784504217 cname:bd13e4/xvZtv4u8o
> > a=ssrc:3784504217 msid:stream_label video_label
> > a=ssrc:3784504217 mslabel:stream_label
> > a=ssrc:3784504217 label:video_label
> > a=ssrc:2216658055 cname:bd13e4/xvZtv4u8o
> > a=ssrc:2216658055 msid:stream_label video_label
> > a=ssrc:2216658055 mslabel:stream_label
> > a=ssrc:2216658055 label:video_label
> 
> Can you/have you filed a bug at http://bugs.webrtc.org ? Please link it here
with repro
> instructions (what's your setup, etc?).

This is the bug report
https://bugs.chromium.org/p/webrtc/issues/detail?id=5786