Required a bit of refactoring to make it possible to pass a Call to DirectTransport on construction. This also lead to me having to remove the shared lock between PacketTransport and RtpRtcpObserver. Now RtpRtcpObserver has a SetTransports method instead of a SetReceivers method.
BUG=webrtc:4173
Review URL: https://codereview.webrtc.org/1419193002
Cr-Commit-Position: refs/heads/master@{#10430}
This test was used to verify that VideoEngine handles were handed back
correctly. This is no longer applicable.
BUG=webrtc:1695
R=mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1425673002 .
Cr-Commit-Position: refs/heads/master@{#10412}
When fetching a packet from the rtp packet history, cuased by a
retransmission, the transport seq extension header is enabled but the
sequence number is set to 0. A new transport seq should be assigned in
this case.
BUG=
Review URL: https://codereview.webrtc.org/1385563005
Cr-Commit-Position: refs/heads/master@{#10183}
This allows us to pass packet meta data, such as transport sequence
number, to libjingle and further down to the socket implementation. A
similar struct already exist in libjingle, see rtc::PacketOptions in asyncpacketsocket.h.
BUG=4173
Review URL: https://codereview.webrtc.org/1376673004
Cr-Commit-Position: refs/heads/master@{#10144}
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}
Don't verify increasing sequence numbers after test complesion as this
can be racy with regards to test shutting down send transports.
BUG=
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1269743004 .
Cr-Commit-Position: refs/heads/master@{#9672}
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}
BUG=webrtc:4690
Defined classes Stream, SendStream and ReceiveStream. Inherited existing stream classes from either SendStream or ReceiveStream.
This is a step towards having a Transport associated with streams instead of a Call. It will allow a lot of code in the Call to be media type agnostic.
R=henrika@webrtc.org, pbos@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1226123005 .
Cr-Commit-Position: refs/heads/master@{#9591}
These payload types aren't directly connected to any payload type, and
the payload type still has to be negotiated externally. As such these
constants are just a source of confusion.
BUG=
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1215603003
Cr-Commit-Position: refs/heads/master@{#9546}
Verifies that reduced-size isn't configured in WebRtcVideoEngine2
without explicit configuration (which doesn't exist). Also disables REMB
in the default config because it requires reconfiguration.
Adds default-config tests to make sure that they don't contain
parameters that need to be negotiated between clients.
BUG=chromium:497103, webrtc:4745
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1171533002
Cr-Commit-Position: refs/heads/master@{#9384}
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}
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}
Add separate functions for returning stats from send/receive stream and updated how functions are used.
Add test implementation for histogram methods in system_wrappers/interface/metrics.h.
BUG=4519
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49639004
Cr-Commit-Position: refs/heads/master@{#9009}
This means all channels within the same group will share the same pacing queue and scheduler. It also means padding will be computed and sent by a single pacer. To accomplish this I also introduce a PacketRouter which finds the RTP module which owns the packet to be paced out.
BUG=4323
R=mflodman@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45549004
Cr-Commit-Position: refs/heads/master@{#8864}
Original cl description:
This removes the none const pointer entry and SwapFrame.
Since frames delivered using VideoSendStream no longer use the external capture module, VideoSendStream will not get an incoming framerate callback. VideoSendStream now uses a rtc::RateTracker.
Also, the video engine must ensure that time stamps are always increasing.
With this, time stamps (ntp, render_time and rtp timestamps ) are checked and set in ViECapturer::OnIncomingCapturedFrame
This cl was previously reverted in https://webrtc-codereview.appspot.com/46549004/.
Patchset 1 contains the original patch after rebase.
Patshet 2 fix webrtc_perf_tests reported in chromium:465306
Note that chromium:465287 is being fixed in https://webrtc-codereview.appspot.com/43829004/
BUG=1128
R=magjed@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47629004
Cr-Commit-Position: refs/heads/master@{#8776}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8776 4adac7df-926f-26a2-2b94-8c16560cd09d
This removes the none const pointer entry and SwapFrame.
Since frames delivered using VideoSendStream no longer use the external capture module, VideoSendStream will not get an incoming framerate callback. VideoSendStream now uses a rtc::RateTracker.
Also, the video engine must ensure that time stamps are always increasing.
With this, time stamps (ntp, render_time and rtp timestamps ) are checked and set in ViECapturer::OnIncomingCapturedFrame
BUG=1128
R=magjed@webrtc.org, mflodman@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46429004
Cr-Commit-Position: refs/heads/master@{#8633}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8633 4adac7df-926f-26a2-2b94-8c16560cd09d
Clang version changed 223108:230914
Details: e144d30..6fdb142/tools/clang/scripts/update.sh
Removes the OVERRIDE macro defined in:
* webrtc/base/common.h
* webrtc/typedefs.h
The majority of the source changes were done by running this in src/:
perl -0pi -e "s/virtual\s([^({;]*(\([^({;]*\)[^({;]*))(OVERRIDE|override)/\1override/sg" `find {talk,webrtc} -name "*.h" -o -name "*.cc*" -o -name "*.mm*"`
which converted all:
virtual Foo() OVERRIDE
functions to:
Foo() override
Then I manually edited:
* talk/media/webrtc/fakewebrtccommon.h
* webrtc/test/fake_common.h
Remaining uses of OVERRIDE was fixed by search+replace.
Manual edits were done to fix virtual destructors that were
overriding inherited ones.
Finally a build error related to the pure virtual definitions of
Read, Write and Rewind in common_types.h required a bit of
refactoring in:
* webrtc/common_types.cc
* webrtc/common_types.h
* webrtc/system_wrappers/interface/file_wrapper.h
* webrtc/system_wrappers/source/file_impl.cc
This roll should make it possible for us to finally re-enable deadlock
detection for TSan on the buildbots.
BUG=4106
R=pbos@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41069004
Cr-Commit-Position: refs/heads/master@{#8596}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8596 4adac7df-926f-26a2-2b94-8c16560cd09d
