In addition to this the ramp-up tests are refactored to use a receive call instead of only a remote bitrate estimator, and to make use of BaseTest.
BUG=webrtc:4836
Review URL: https://codereview.webrtc.org/1368943002
Cr-Commit-Position: refs/heads/master@{#10087}
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}
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}
The unit test currently works as follows:
RtxLoopBackTransport logs the sequence numbers for all sent packets in expected_sequence_numbers_. Since the transport is configured to drop some of the packets there will be requests for retransmissions and the RTX sequence numbers will also be stored in the same list.
The (non-rtx) packets are received by VerifyingRtxReceiver which also stores the sequence numbers in a list sequence_numbers_. Both lists are then sorted and sequence_numbers_ is compared to whatever is in the start of expected_sequence_numbers_.
This works assuming that the RTX sequence numbers are greater than the regular RTP sequence numbers. In the RTP sender, both RTP and RTX are set to start at "random" 15-bit sequence numbers. The RTP sequence number is then changed to 2345 in the unit test, which would imply that the RTX sequence number is lower than the ones for RTP with probability ~1%. The reason why the test works anyway is that the test sets up a fake clock, which is used to initialize the random number generator in RTPSender, and the fixed starting point for the clock happens to result in RTX sequence numbers greater than 2345. However, any change to the initialization of the sequence numbers, the seeding of the PRNG or the fake clock causes a test failure with probability ~1%.
The new code omits the RTX sequence numbers from expected_sequence_numbers_, thus avoiding the problem with low RTX sequence numbers. The initialization of the sequence numbers in RTPSender is also bad, but I'll fix that in another CL.
Review URL: https://codereview.webrtc.org/1263383002
Cr-Commit-Position: refs/heads/master@{#9967}
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}
Part of work removing dependency on Chromium's base.
Only adds "= delete". From https://codereview.chromium.org/1151443003 :
"This will guarantee the error to be at compile time, and not rely on the call visibility (private)."
In consequence of that change, fixed an illegal copy and removed a bunch of unused variables.
Depends on https://codereview.webrtc.org/1345433002/
BUG=chromium:468375
(in particular comment #37)
NOTRY=true
Review URL: https://codereview.webrtc.org/1342543004
Cr-Commit-Position: refs/heads/master@{#9954}
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.
* DISALLOW_ASSIGN -> RTC_DISALLOW_ASSIGN
* DISALLOW_COPY_AND_ASSIGN -> RTC_DISALLOW_COPY_AND_ASSIGN
* DISALLOW_IMPLICIT_CONSTRUCTORS -> RTC_DISALLOW_IMPLICIT_CONSTRUCTORS
Related CL: https://codereview.webrtc.org/1335923002/
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1345433002
Cr-Commit-Position: refs/heads/master@{#9953}
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}
Collects packet information within a struct instead of spreading it out
over different vectors. Adds a fixed-size buffer to the stored packet
instead of using vectors.
BUG=
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1340573002
Cr-Commit-Position: refs/heads/master@{#9926}
Part of work removing dependency on Chromium's base.
Only adds "= delete". From https://codereview.chromium.org/1151443003 :
"This will guarantee the error to be at compile time, and not rely on the call visibility (private)."
In consequence of that change, fixed an illegal copy and removed a bunch of unused variables.
BUG=chromium:468375 (in particular comment #37)
NOTRY=true
Review URL: https://codereview.webrtc.org/1316363005
Cr-Commit-Position: refs/heads/master@{#9913}
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}
Handling the case when encoder drops only the higher layer.
Added options to screenshare loopback test to discard high temporal or spatial layers (to view the lower layers).
Review URL: https://codereview.webrtc.org/1287643002
Cr-Commit-Position: refs/heads/master@{#9883}
Value was incorrectly truncated to 16 bits when serializing the message.
Fixed, with added regression tests.
BUG=
Review URL: https://codereview.webrtc.org/1294393002
Cr-Commit-Position: refs/heads/master@{#9858}
Pitfalls:
* Left shift of signed integer has undefined behavior
* Right-shift of signed integer has platform-specific behavior is value is negative
* Cast from unsigned to signed has undefined behavior if value is negative
BUG=webrtc:4824
Review URL: https://codereview.webrtc.org/1226993003
Cr-Commit-Position: refs/heads/master@{#9854}
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}
Also fixed an arithmetic issue where a 0 0 3 at the end of the rbsp would include the 3 (that's not a legal bitstream anyway, so it probably wasn't a real bug, but it was incorrect).
This maintains the underflow fix from an earlier CL (https://codereview.webrtc.org/1219493004/). The overflow fix is virtually impossible to hit (hence no unit tests), but is there for strict correctness.
BUG=
Review URL: https://codereview.webrtc.org/1226203002
Cr-Commit-Position: refs/heads/master@{#9581}
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}
Bugs found by manual inspection of code, not by fuzzing or packet
replays. At least one of them confirmed by local fuzzing.
BUG=chromium:496094, webrtc:4771
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1182793002
Cr-Commit-Position: refs/heads/master@{#9542}
