Any file that uses the RTC_DISALLOW_* macros should #include
"webrtc/base/constructormagic.h", but a shocking number of them don't.
This causes trouble when we try to wean files off of #including
scoped_ptr.h, since a bunch of files get their constructormagic macros
only from there.
Rather than fixing these errors one by one as they turn up, this CL
simply ensures that every file in the WebRTC tree that uses the
RTC_DISALLOW_* macros #includes "webrtc/base/constructormagic.h".
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1917043005
Cr-Commit-Position: refs/heads/master@{#12509}
The change made in https://codereview.webrtc.org/1757683002 introduced an extra call to RTCPSender::SetRTCPStatus after the video receive stream is created. The SetRTCPStatus call results in no state change, as the RTCP sender is already enabled, however, it reschedules the next RTCP packet to be RTCP_INTERVAL_VIDEO_MS/2 (500) ms in the future.
Before the change, the next packet time was only set by the previous call to RTCPSender::SetSSRC, which placed it 100 ms in the future. The change, therefore, changed the timing of multiple performance tests - as it now takes a different length of time to ramp up to the same bandwidth.
BUG=chromium:597332
Review URL: https://codereview.webrtc.org/1826093004
Cr-Commit-Position: refs/heads/master@{#12203}
Compact NTP representation was designed exactly for that purpose: calculate RTT. No need to map to ms before doing arithmetic on this values.
Because of this change there is no need to keep mapping between compact ntp presentation and milliseconds in the RTCPSender.
BUG=webrtc:5565
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1491843004 .
Cr-Commit-Position: refs/heads/master@{#11710}
When composing a RTCP packet, if there is a BYE
to be appended, preserve it and append it at the
end after all other packet types are added.
BUG=webrtc:5498
NOTRY=true
Review URL: https://codereview.webrtc.org/1674963004
Cr-Commit-Position: refs/heads/master@{#11672}
TMMBN was capped by configured max bitrate for no apparent reason.
Removing this to not require payload-type reconfiguration on new
video-codec settings. Actual removal of payload-type reconfiguration
will happen in a pending CL.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1702043002 .
Cr-Commit-Position: refs/heads/master@{#11639}
Added accessor and Parse function
removed dependencies on structures from rtcp_utility.h (except RtcpCommonHeader)
BUG=webrtc:5260
R=åsapersson
Review URL: https://codereview.webrtc.org/1675583002
Cr-Commit-Position: refs/heads/master@{#11502}
Adds logging to RTPSender and RTCPSender, pushing an event log pointer from Channel through ModuleRtpRtcpImpl to the Sender objects.
BUG=webrtc:4741
Review URL: https://codereview.webrtc.org/1571283002
Cr-Commit-Position: refs/heads/master@{#11336}
Class renamed to indicated use of the rtcp::Empty class: it can only be used as container for other rtcp packets.
All tests that use Append function moved from rtcp_packet_unittest, even if they did not use Empty class.
This is because there is plan to make RtcpPacket class lighter by moving Append functionality to CompoundPacket class.
BUG=webrtc:5260
R=åsapersson
Review URL: https://codereview.webrtc.org/1582503002
Cr-Commit-Position: refs/heads/master@{#11234}
PrepareReportBlock and AddReportBlock private functions merged:
PrepareReportBlock moved report block from statistic to temporary structure
AddReportBlock copied that temporary structure into temporary map right after.
Thanks to rtcp packet classes that temporary structure is now unneccesary.
BUG=webrtc:5260
R=åsapersson
Review URL: https://codereview.webrtc.org/1538833002
Cr-Commit-Position: refs/heads/master@{#11112}
rand() usage replaced with new Random class, which also makes it clearer what interval random number is in.
BUG=webrtc:5277
R=mflodman
Review URL: https://codereview.webrtc.org/1519503002
Cr-Commit-Position: refs/heads/master@{#11019}
rtcp_utility, rtp_utility, tmmbr_help, rtcp_receiver, rtcp_receiver_help are explicetly excluded from the cleanup becaues there are short plans (or cls) to do a deeper cleaning there.
BUG=webrtc:5277
R=pbos@webrtc.org, mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1512493002
Cr-Commit-Position: refs/heads/master@{#10966}
Created rtcp::Psfb abstract class between rtcp::Pli and rtcp::RtcpPacket to hold common data for Feedback Message.
BUG=webrtc:5260
Review URL: https://codereview.webrtc.org/1446513002
Cr-Commit-Position: refs/heads/master@{#10823}
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}
For use when send-side bandwidth estimation is enabled.
Receive times need to be captured, buffered and then sent using
TransportFeedback RTCP messaged back to the send side.
BUG=webrtc:4173
Review URL: https://codereview.webrtc.org/1290813008
Cr-Commit-Position: refs/heads/master@{#9898}
