ModuleProcessImpl doesn't act on return codes and having them around is
confusing (it's unclear what an error return code here would do even).
BUG=
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1703833002 .
Cr-Commit-Position: refs/heads/master@{#11747}
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}
Also move some stats reporting from vie_channel to send stats proxy
BUG=
Review URL: https://codereview.webrtc.org/1669623004
Cr-Commit-Position: refs/heads/master@{#11688}
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}
Adds negotiation of rtx codecs for red and vp9. To keep backwards
compatibility with older Chrome versions, this change includes two
hacks:
1. Red packets will be retransmitted over the rtx codec associated with
vp8 if no rtx codec is associated with red. This is how Chrome does
it today and ensures that we still can send red over rtx to older
versions.
2. If rtx packets associated with the media codec (vp8/vp9 etc) are
received and red has been negotiated, we will assume that the sender
incorrectly has packetized red inside the rtx header associated with
media. We will therefore restore it with the red payload type
instead, which ensures that we can still receive rtx associated with
red from old versions.
Offering multiple rtx codecs to older versions should not be a problem
since old versions themselves only try to negotiate rtx for vp8.
R=pbos@webrtc.orgTBR=mflodman@webrtc.org
BUG=webrtc:4024
TEST=Verified by running apprtc and emulating packet loss between Chrome with and without the patch.
Review URL: https://codereview.webrtc.org/1649493004 .
Cr-Commit-Position: refs/heads/master@{#11472}
SetRtpState function was updating only rtp_sender start timestamp.
Now it updates both rtp_sender and rtcp_sender start timestamps.
BUG=webrtc:5433
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1628323003 .
Cr-Commit-Position: refs/heads/master@{#11393}
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}
This CL makes sure no RTCP SR is sent before there is a valid timestamp
to set in the SR, based on the first sent media packet.
BUG=webrtc:1600
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1506103006 .
Cr-Commit-Position: refs/heads/master@{#10964}
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}
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}
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}
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}
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}
Adds a class used to classify whether packet loss events are a single packet or multiple packets as well as how many packets have been lost. Also exposes a new function in the RtpRtcp interface to retrieve these statistics.
BUG=
Review URL: https://codereview.webrtc.org/1198853004
Cr-Commit-Position: refs/heads/master@{#9568}
The main purpose of this CL is to clean up RTCPSender::PrepareRTCP, but
it has quite a few ramifications. Notable changes:
* Removed the rtcpPacketTypeFlags bit vector and don't assume
RTCPPacketType values have a single unique bit set. This will allow
making this an enum class once rtcp_receiver has been overhauled.
* Flags are now stored in a map that is a member of the class. This
meant we could remove some bool flags (eg send_remb_) which was
previously masked into rtcpPacketTypeFlags and then masked out again
when testing if a remb packet should be sent.
* Make all build methods, eg. BuildREMB(), have the same signature.
An RtcpContext struct was introduced for this purpose. This allowed
the use of a map from RTCPPacketType to method pointer. Instead of
18 consecutive if-statements, there is now a single loop.
The context class also allowed some simplifications in the build
methods themselves.
* A few minor simplifications and cleanups.
The next step is to gradually replace the builder methods with the
builders from the new RtcpPacket classes.
BUG=2450
R=asapersson@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48329004
Cr-Commit-Position: refs/heads/master@{#9166}
Since RTCP packets are delivered to both senders and receivers that
correspond the receivers currently log that NACKed packets are missing,
since they have no direct connection to the sending side or the RTP
packet history. Also preventing triggering on SR requests and PLI/FIR.
BUG=
R=asapersson@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45249004
Cr-Commit-Position: refs/heads/master@{#9071}
This implementation registers RTX-APT map inside RTP sender and receiver.
While it only generates SDP with RTX associated with VP8 to make it
compatible with previous Chrome versions.
Should add following changes after reaches stable,
* Use RTX-APT map for building and restoring RTP packets.
* Add RTX support for RED or VP9 in Video engine.
* Set RTX payload type for RED inside FecConfig in EndToEndTest.
BUG=4024
R=mflodman@webrtc.org, pbos@webrtc.org, pthatcher@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36889004
Cr-Commit-Position: refs/heads/master@{#9040}
This CL avoids changing the mentioned callbacks during a call, to avoid
a potential deadlock when acquiring _sendCritSect and calling
_mediaOpt.SetTargetRates.
Moving the critsect revealed a race for the FEC parameters in RtpVideoSender, so the CL grew a bit to avoid this. I also cleaned up some code here at the same time, but tried to keep it at a minimum since this CL had already increased a lot in size.
BUG=769
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42939004
Cr-Commit-Position: refs/heads/master@{#8899}
This cl just moves the logic form the default module
SetTargetSendBitrates to PayloadRouter. There might be glitch / mismatch
in size between trate the vector and rtp modules. This was the same in
the default module and is quite hard to protect from before we have the
new video API.
I also removed some test form rtp_rtcp_impl_unittest that were affected
by this change. The test tests code that isn't implemented, hence the
DISABLED_, and this will never be implemented in the RTP module, rather
the payload router in the future.
BUG=769
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42419004
Cr-Commit-Position: refs/heads/master@{#8453}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8453 4adac7df-926f-26a2-2b94-8c16560cd09d
