- 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}
There were two different structures named RtpPacket in webrtc namespace:
RtpPacket defined in fec_test_helper renamed to test::RawRtpPacket
RtpPacket defined in rtp_sender_video and producer_fec removed as unused
BUG=webrtc:5261
R=sprang@google.com, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1710103004 .
Cr-Commit-Position: refs/heads/master@{#11682}
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}
Since the address of the dereference is taken this inputs a garbage
almost-null pointer into RtpPacketizer. Not likely that a load/store is
performed on the address, but UBSan fires and it's a source of potential
future errors.
BUG=webrtc:5124, webrtc:5490
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1677003002 .
Cr-Commit-Position: refs/heads/master@{#11528}
This CL contains three changes as a preparation for adding audio send streams
to the send-side BWE:
1. Audio packets are passed through the pacer with high priority. This
is needed to be able to set transport sequence numbers on the packets.
2. A feedback observer is passed to the audio stream's rtcp receiver so
that the BWE can get notified of any BWE feedback being received on the
audio feedback channel.
3. Support for the transport sequence number header extension is added
to audio send streams.
BUG=webrtc:5263,webrtc:5307
R=mflodman@webrtc.org, solenberg@webrtc.org
Review URL: https://codereview.webrtc.org/1479023002 .
Cr-Commit-Position: refs/heads/master@{#10909}
This changes the following module directories:
* webrtc/modules/audio_conference_mixer/interface
* webrtc/modules/interface
* webrtc/modules/media_file/interface
* webrtc/modules/rtp_rtcp/interface
* webrtc/modules/utility/interface
To avoid breaking downstream, I followed this recipe:
1. Copy the interface dir to a new sibling directory: include
2. Update the header guards in the include directory to match the style guide.
3. Update the header guards in the interface directory to match the ones in include. This is required to avoid getting redefinitions in the not-yet-updated downstream code.
4. Add a pragma warning in the header files in the interface dir. Example:
#pragma message("WARNING: webrtc/modules/interface is DEPRECATED; "
"use webrtc/modules/include")
5. Search for all source references to webrtc/modules/interface and update them to webrtc/modules/include (*.c*,*.h,*.mm,*.S)
6. Update all GYP+GN files. This required manual inspection since many subdirectories of webrtc/modules referenced the interface dir using ../interface etc(*.gyp*,*.gn*)
BUG=5095
TESTED=Passing compile-trybots with --clobber flag:
git cl try --clobber --bot=win_compile_rel --bot=linux_compile_rel --bot=android_compile_rel --bot=mac_compile_rel --bot=ios_rel -m tryserver.webrtc
R=stefan@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1417683006 .
Cr-Commit-Position: refs/heads/master@{#10500}
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}
To make this possible padding only packets will have the same timestamp
as the previously sent media packet, as long as RTX is not enabled. This
has the side effect that if we send only padding for a long time without
sending media, a receive-side jitter buffer could potentially overflow.
In practice this shouldn't be an issue, partly because RTX is recommended and
used by default, but also because padding typically is terminated before being
received by a client. It is also not an issue for bandwidth estimation as long
as abs-send-time is used instead of toffset.
BUG=chromium:425925
R=mflodman@webrtc.org, sprang@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1327933003 .
Cr-Commit-Position: refs/heads/master@{#9984}
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}
All RTP packets from sender side will carry the rotation info. (will file a bug to track this) On the receiving side, only packets with marker bit set will be examined.
Tests completed:
1. android standalone to android standalone
2. android standalone to chrome (with and without this change)
3. android on chrome
BUG=4145
R=glaznev@webrtc.org, mflodman@webrtc.org, perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47399004
Cr-Commit-Position: refs/heads/master@{#8905}
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}
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
Changes include,
1) Introduce class RtpPacketizerGeneric & RtpDePacketizerGeneric.
2) Introduce class RtpDepacketizerVp8.
3) Make RTPSenderVideo::SendH264 generic and used by all packetizers.
4) Move codec specific functions from RTPSenderVideo/RTPReceiverVideo to
RtpPacketizer/RtpDePacketizer sub-classes.
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26399004
Patch from Changbin Shao <changbin.shao@intel.com>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7163 4adac7df-926f-26a2-2b94-8c16560cd09d
This also includes:
- Creating new packetizer and depacketizer interfaces.
- Moved VP8 packetization was H264 packetization and depacketization to these interfaces. This is a work in progress and should be continued to get this 100% generic. This also required changing the return type for RtpFormatVp8::NextPacket(), which now returns bool instead of the index of the first partition.
- Created a Create() factory method for packetizers and depacketizers.
R=niklas.enbom@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/21009004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6804 4adac7df-926f-26a2-2b94-8c16560cd09d
Issue https://webrtc-codereview.appspot.com/4459004/ was commited as
r5259, after which flakiness was detected and a rollback was performed
at r5261.
Patch Set 1 of this issue is the code submitted in r5259. Subsequent
patch sets fixes a race condition which caused the seen problems.
The root cause was a dead lock between a thread sending rtp packets and
and a timed module processing thread:
webrtc::RTPSender::BitrateUpdated() // Get RTPSender stats lock
webrtc::Bitrate::Process() // Get Bitrate lock
webrtc::RTPSender::ProcessBitrate()
webrtc::ModuleRtpRtcpImpl::Process()
...
webrtc::Bitrate::Update() // Get Bitrate lock
webrtc::RTPSender::UpdateRtpStats() // Get RTPSender stats lock
webrtc::RTPSender::SendToNetwork()
...
This is fixed in Bitrate::Process() by releasing the lock before
calling the callback.
BUG=2235
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/5619004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5281 4adac7df-926f-26a2-2b94-8c16560cd09d
- A bug was introduced in r4234 causing no paced packets to be sent.
- Only update the sequence number counter if a padding packet is actually going to be sent, to avoid packet loss.
- Have all packets go through the pacer if pacing is enabled to avoid reordering.
- Fix race condition on reading capture_time_ms_/timestamp_ in rtp_sender.cc.
BUG=1837
TEST=trybots and vie_auto_test --automated
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1682004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4246 4adac7df-926f-26a2-2b94-8c16560cd09d
