Adding getParameters/setParameters APIs to RtpReceiver.

Adding getParameters/setParameters APIs to RtpReceiver.

This is similar to how a "receive" method is used to apply
RtpParameters to an RtpReceiver in ORTC. Currently, SetParameters
doesn't allow changing the parameters, so the main use of the API is
to retrieve the set of configured codecs. But other uses will likely
be made possible in the future.

R=glaznev@webrtc.org, pthatcher@webrtc.org, tkchin@webrtc.org

Committed: https://chromium.googlesource.com/external/webrtc/+/db0cd9e774dbe91f41fea349fef995c2b5887c25

[Taylor Brandstetter, 2016-04-27 23:38:56]

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

[Taylor Brandstetter, 2016-04-28 16:44:25]

deadbeef@webrtc.org changed reviewers:
+ glaznev@webrtc.org, tkchin@webrtc.org

[Taylor Brandstetter, 2016-04-28 16:44:26]

Zeke: Please review Objective C code.
Alex: Please review Java code.
Peter: Please review the rest.

Thanks!

[tkchin_webrtc, 2016-04-28 18:12:12]

https://codereview.webrtc.org/1917193008/diff/1/webrtc/sdk/objc/Framework/Hea...
File webrtc/sdk/objc/Framework/Headers/WebRTC/RTCPeerConnection.h (right):

https://codereview.webrtc.org/1917193008/diff/1/webrtc/sdk/objc/Framework/Hea...
webrtc/sdk/objc/Framework/Headers/WebRTC/RTCPeerConnection.h:131: *  Use
isEqual: instead of == to compare RTCRtpReceiver instances.
doesn't seem like we overrode isEqual?

[Taylor Brandstetter, 2016-04-28 21:22:52]

https://codereview.webrtc.org/1917193008/diff/1/webrtc/sdk/objc/Framework/Hea...
File webrtc/sdk/objc/Framework/Headers/WebRTC/RTCPeerConnection.h (right):

https://codereview.webrtc.org/1917193008/diff/1/webrtc/sdk/objc/Framework/Hea...
webrtc/sdk/objc/Framework/Headers/WebRTC/RTCPeerConnection.h:131: *  Use
isEqual: instead of == to compare RTCRtpReceiver instances.
On 2016/04/28 18:12:12, tkchin_webrtc wrote:
> doesn't seem like we overrode isEqual?

Looks like this wasn't done for RTCRtpSender either. I went ahead and did it for
both.

[tkchin_webrtc, 2016-04-28 21:57:41]

lgtm for objc

https://codereview.webrtc.org/1917193008/diff/20001/webrtc/sdk/objc/Framework...
File webrtc/sdk/objc/Framework/Classes/RTCRtpReceiver.mm (right):

https://codereview.webrtc.org/1917193008/diff/20001/webrtc/sdk/objc/Framework...
webrtc/sdk/objc/Framework/Classes/RTCRtpReceiver.mm:44: if (![object
isMemberOfClass:[self class]]) {
would add a nil check before this just to be conservative 

if (object == nil) {
  return NO;
}

in which case you can probably just fold isEqualToReceiver into this method

[Taylor Brandstetter, 2016-04-28 22:24:12]

https://codereview.webrtc.org/1917193008/diff/20001/webrtc/sdk/objc/Framework...
File webrtc/sdk/objc/Framework/Classes/RTCRtpReceiver.mm (right):

https://codereview.webrtc.org/1917193008/diff/20001/webrtc/sdk/objc/Framework...
webrtc/sdk/objc/Framework/Classes/RTCRtpReceiver.mm:44: if (![object
isMemberOfClass:[self class]]) {
On 2016/04/28 21:57:41, tkchin_webrtc wrote:
> would add a nil check before this just to be conservative 
> 
> if (object == nil) {
>   return NO;
> }
> 
> in which case you can probably just fold isEqualToReceiver into this method

Done.

[AlexG, 2016-05-05 21:53:46]

lgtm for Java

[Taylor Brandstetter, 2016-05-12 15:32:32]

Pinging Peter

[pthatcher1, 2016-05-13 18:41:53]

lgtm

I think I would prefer the unique_ptr return on the GetRtpParameters, but it
shouldn't block this CL.  But I would like to hear what you think.

https://codereview.webrtc.org/1917193008/diff/40001/webrtc/api/mediastreampro...
File webrtc/api/mediastreamprovider.h (right):

https://codereview.webrtc.org/1917193008/diff/40001/webrtc/api/mediastreampro...
webrtc/api/mediastreamprovider.h:74: const RtpParameters& parameters) = 0;
Not blocking this CL, but can we just skip to giving an RtpSender/RtpReceiever a
BaseChannel directly instead of having it go through this interface?

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

https://codereview.webrtc.org/1917193008/diff/40001/webrtc/media/engine/webrt...
webrtc/media/engine/webrtcvideoengine2.cc:928: return webrtc::RtpParameters();
Would it be better to return a unique_ptr that can be null instead of having an
empty value?

[Taylor Brandstetter, 2016-05-13 19:09:12]

https://codereview.webrtc.org/1917193008/diff/40001/webrtc/api/mediastreampro...
File webrtc/api/mediastreamprovider.h (right):

https://codereview.webrtc.org/1917193008/diff/40001/webrtc/api/mediastreampro...
webrtc/api/mediastreamprovider.h:74: const RtpParameters& parameters) = 0;
On 2016/05/13 18:41:53, pthatcher1 wrote:
> Not blocking this CL, but can we just skip to giving an RtpSender/RtpReceiever
a
> BaseChannel directly instead of having it go through this interface?  

I'd prefer to do that in a separate CL, so it doesn't block this CL and it won't
cause this CL to be reverted if it causes a problem.

But it does seem like it wouldn't be too hard. I'll add it to my todo list.

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

https://codereview.webrtc.org/1917193008/diff/40001/webrtc/media/engine/webrt...
webrtc/media/engine/webrtcvideoengine2.cc:928: return webrtc::RtpParameters();
On 2016/05/13 18:41:53, pthatcher1 wrote:
> Would it be better to return a unique_ptr that can be null instead of having
an
> empty value?  
> 

In the end, something would have to turn the null pointer into a default
RTCRtpParameters dictionary. I'd prefer if that were done at the WebRTC level by
constructing a default object rather than in Chromium.

[Taylor Brandstetter, 2016-05-13 22:02:47]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-05-13 22:02:48]

The patchset sent to the CQ was uploaded after l-g-t-m from tkchin@webrtc.org,
glaznev@webrtc.org, pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1917193008/#ps60001 (title:
"Merging with master")

[commit-bot: I haz the power, 2016-05-13 22:02:52]

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

[commit-bot: I haz the power, 2016-05-13 22:05:01]

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

[commit-bot: I haz the power, 2016-05-13 22:05:02]

Try jobs failed on following builders:
  ios64_sim_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios64_sim_dbg/builds/7445)
  ios_arm64_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_dbg/builds/9782)
  ios_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_rel/builds/13640)
  mac_baremetal on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_baremetal/builds/11334)

[commit-bot: I haz the power, 2016-05-16 18:40:41]

Description was changed from

==========
Adding getParameters/setParameters APIs to RtpReceiver.

This is similar to how a "receive" method is used to apply
RtpParameters to an RtpReceiver in ORTC. Currently, SetParameters
doesn't allow changing the parameters, so the main use of the API is
to retrieve the set of configured codecs. But other uses will likely
be made possible in the future.
==========

to

==========
Adding getParameters/setParameters APIs to RtpReceiver.

This is similar to how a "receive" method is used to apply
RtpParameters to an RtpReceiver in ORTC. Currently, SetParameters
doesn't allow changing the parameters, so the main use of the API is
to retrieve the set of configured codecs. But other uses will likely
be made possible in the future.

R=glaznev@webrtc.org, pthatcher@webrtc.org, tkchin@webrtc.org

Committed: https://crrev.com/db0cd9e774dbe91f41fea349fef995c2b5887c25
Cr-Commit-Position: refs/heads/master@{#12761}
==========

[Taylor Brandstetter, 2016-05-16 18:40:41]

Description was changed from

==========
Adding getParameters/setParameters APIs to RtpReceiver.

This is similar to how a "receive" method is used to apply
RtpParameters to an RtpReceiver in ORTC. Currently, SetParameters
doesn't allow changing the parameters, so the main use of the API is
to retrieve the set of configured codecs. But other uses will likely
be made possible in the future.

R=glaznev@webrtc.org, pthatcher@webrtc.org, tkchin@webrtc.org

Committed: https://crrev.com/db0cd9e774dbe91f41fea349fef995c2b5887c25
Cr-Commit-Position: refs/heads/master@{#12761}
==========

to

==========
Adding getParameters/setParameters APIs to RtpReceiver.

This is similar to how a "receive" method is used to apply
RtpParameters to an RtpReceiver in ORTC. Currently, SetParameters
doesn't allow changing the parameters, so the main use of the API is
to retrieve the set of configured codecs. But other uses will likely
be made possible in the future.

R=glaznev@webrtc.org, pthatcher@webrtc.org, tkchin@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/db0cd9e774dbe91f41fea349f...
==========

[commit-bot: I haz the power, 2016-05-16 18:40:42]

Patchset 7 (id:??) landed as
https://crrev.com/db0cd9e774dbe91f41fea349fef995c2b5887c25
Cr-Commit-Position: refs/heads/master@{#12761}

[Taylor Brandstetter, 2016-05-16 18:40:43]

Committed patchset #7 (id:120001) manually as
db0cd9e774dbe91f41fea349fef995c2b5887c25 (presubmit successful).