- First audio RTP packet sent / received
- First RTP packet of the first video frame sent / received
- Last RTP packet of the first video frame sent / received
These timestamps should make it easier to measure how fast the call
becomes established from the user's perspective.
Review URL: https://codereview.webrtc.org/1765443002
Cr-Commit-Position: refs/heads/master@{#12287}
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}
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}
Removes lock-order inversion formed by RTPSenderAudio->RTPSender calls
by doing a lot shorter locking which fetches a current state of
RTPSenderAudio variables before sending.
Thread annotates locked variables and removes one lock in
RTPSenderAudio, bonus fixes data races reported in voe_auto_test
--automated under TSan (DTMF data race).
Also includes some bonus cleanup of RTPSenderVideo which removes the
send critsect completely as all methods using it was always called
from RTPSender under its send_critsect.
R=henrik.lundin@webrtc.org, stefan@webrtc.org, tommi@webrtc.org
BUG=3001, chromium:454654
Review URL: https://webrtc-codereview.appspot.com/41869004
Cr-Commit-Position: refs/heads/master@{#8348}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8348 4adac7df-926f-26a2-2b94-8c16560cd09d
- Add ability to VoE to send Absolute Sender Time header extension.
- Refactor handling of RTP header extensions in VoE to work the same as in ViE.
- Add API to enable receiving Absolute Sender Time in VoE.
This is part of the work to include audio packets in bandwidth estimation, for
better accuracy in estimates.
BUG=
TBR=solenberg@webrtc.org,henrikg@webrtc.org,stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9509004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5654 4adac7df-926f-26a2-2b94-8c16560cd09d
The goal with this new clock interface is to have something which is used all
over WebRTC to make it easier to switch clock implementation depending on where
the components are used. This is a first step in that direction.
Next steps will be to, step by step, move all modules, video engine and voice
engine over to the new interface, effectively deprecating the old clock
interfaces. Long-term my vision is that we should be able to deprecate the clock
of WebRTC and rely on the user providing the implementation.
TEST=vie_auto_test, rtp_rtcp_unittests, trybots
Review URL: https://webrtc-codereview.appspot.com/1041004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3381 4adac7df-926f-26a2-2b94-8c16560cd09d
