If the track is disabled, replace incoming frames by black frames. Affects local rendering of disabled tracks.
Also intended to replace the similar logic in
WebRtcVideoChannel2::WebRtcVideoSendStream::InputFrame, once
VideoRtpSender is hooked up as a renderer for the track.
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1575223003
Cr-Commit-Position: refs/heads/master@{#11297}
We can now use std::move instead!
This CL leaves the Pass methods in place; a follow-up CL will add deprecation annotations to them.
Review URL: https://codereview.webrtc.org/1460043002
Cr-Commit-Position: refs/heads/master@{#11064}
Every malformed URL should now produce an error message in JS, rather than
silently failing and possibly printing a warning message to the console (and
possibly crashing).
Also added some unit tests, and made "ParseIceServers" public.
BUG=445002
Review URL: https://codereview.webrtc.org/1344143002
Cr-Commit-Position: refs/heads/master@{#10186}
DtlsIdentityStoreImpl is updated to take KeyType into account, something which will be relevant after this CL lands:
https://codereview.webrtc.org/1189583002
The DtlsIdentityService[Interface] classes are about to be removed (to be removed when Chromium no longer implements and uses the interface). This was an unnecessary layer of complexity. The FakeIdentityService is now instead a FakeDtlsIdentityStore.
Where a service was previously passed around, a store is now passed around.
Identity generation is now commonly performed using DtlsIdentityStoreInterface. Previously, if a service was not specified, WebRtcSessionDescriptionFactory could fall back on its own generation code. Now, a store has to be provided for generation to occur.
For more information about the steps being taken to land this without breaking Chromium, see referenced bug.
BUG=webrtc:4899
R=magjed@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1176383004 .
Cr-Commit-Position: refs/heads/master@{#9696}
Since PeerConnection holds a ref to its creating PeerConnectionFactory, it's
possible for ~PeerConnectionFactory() to be run on its signaling thread.
Deleting a thread from within that thread is sad times, so don't do it.
It would be nicer to avoid having PeerConnection hold a ref to the factory,
and instead require the user to keep the factory alive. Unfortunately that
changes the contract on PeerConnection{,Factory} and it's unclear how to vet
existing callers for safety.
BUG=3100
R=juberti@webrtc.org, noahric@google.com
Review URL: https://webrtc-codereview.appspot.com/11289004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5933 4adac7df-926f-26a2-2b94-8c16560cd09d
