Since the pacer is always enabled, removing enable/disable which makes
all packet queueing succeed. Also renaming one of the ::SendPackets
::InsertPacket to avoid confusion.
BUG=webrtc:1695, webrtc:2629
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1392513002 .
Cr-Commit-Position: refs/heads/master@{#10211}
In addition to this the ramp-up tests are refactored to use a receive call instead of only a remote bitrate estimator, and to make use of BaseTest.
BUG=webrtc:4836
Review URL: https://codereview.webrtc.org/1368943002
Cr-Commit-Position: refs/heads/master@{#10087}
Starts by removing channel/engine id from ViEChannel which propagates
down to the RTP/RTCP module as well as the transport class.
IncomingVideoStream::RenderFrame() is untouched for now but receives a
fake id instead of the previous channel id. Added a TODO to remove it
later but the RenderFrame call is implemented in a lot of
platform-dependent files and should probably remove the "manager" aspect
of renderers, so preferring to do it separately
BUG=webrtc:1695
R=henrika@webrtc.org, mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1335353005 .
Cr-Commit-Position: refs/heads/master@{#9978}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
* DISALLOW_ASSIGN -> RTC_DISALLOW_ASSIGN
* DISALLOW_COPY_AND_ASSIGN -> RTC_DISALLOW_COPY_AND_ASSIGN
* DISALLOW_IMPLICIT_CONSTRUCTORS -> RTC_DISALLOW_IMPLICIT_CONSTRUCTORS
Related CL: https://codereview.webrtc.org/1335923002/
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1345433002
Cr-Commit-Position: refs/heads/master@{#9953}
Remove start_bitrate_bps which is no longer used and return the current
allocated bitrate instead of having it as an out parameter, removing the
previous return value which is no longer used.
Permits removing bitrate controller usage from ViEEncoder.
BUG=webrtc:1695
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1343783006 .
Cr-Commit-Position: refs/heads/master@{#9942}
When using send-side bandwidth estimation, the inter-packet delay is
reported back to the sender using RTCP TransportFeedback messages.
Theis data needs to be translated into a format which the bandwidth
estimator (now instantiated on the send side) can use, including looking
up the local absolute send time from the send time history.
BUG=webrtc:4173
Review URL: https://codereview.webrtc.org/1329083005
Cr-Commit-Position: refs/heads/master@{#9929}
Helps differentiate between different instances when debugging.
Review URL: https://codereview.webrtc.org/1337003003
Cr-Commit-Position: refs/heads/master@{#9927}
This will be used for the send side bitrate estimation. Storing various
meta-data about packets that can be retreived when arrival time feeback
arrives.
BUG=webrtc:4173
Review URL: https://codereview.webrtc.org/1288033008
Cr-Commit-Position: refs/heads/master@{#9859}
Also refactor packet router to use a map rather than iterate over all
rtp modules for each packet sent.
BUG=webrtc:4311
Review URL: https://codereview.webrtc.org/1247293002
Cr-Commit-Position: refs/heads/master@{#9670}
Enforces previous kProtectionKeyOnLoss as the permanent method which was
the only one used in use. This simplifies SetVideoProtection and
transition over to SetReceiverRobustnessMode.
BUG=webrtc:1596
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1244753002
Cr-Commit-Position: refs/heads/master@{#9641}
Reduces number of running (high-priority) threads, even though the
thread was practically blocked all the time.
Also adding DCHECKs to make sure we're not trying to use certain
sender-only methods on receivers and vice versa.
BUG=webrtc:1675, webrtc:1695
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1222193003
Cr-Commit-Position: refs/heads/master@{#9534}
Registers transport on construction removing the need for ViESender as a
hop and removing a potential deadlock by removing RegisterSendTransport.
BUG=1695, 2999
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/57449004
Cr-Commit-Position: refs/heads/master@{#9309}
