This is a first CL wiring up AudioSendStream to BitrateAllocator. This
is still experimental and there is a test added for the audio only case,
combined audio video variable bitrate test cases will be added as a
follow up.
BUG=5079
Review-Url: https://codereview.webrtc.org/2165743003
Cr-Commit-Position: refs/heads/master@{#13527}
The iOS H264 video toolbox encoder is currently undershooting the
intended bitrate. This seems to be caused by the data rate limit
property. This CL increases the data rate limit to a set
percentage above the intended bitrate to avoid undershooting. The
AverageBitRate property is still set to the intended bitrate, which
keeps it from overshooting the intended bitrate.
BUG=b/28713684
Review-Url: https://codereview.webrtc.org/2177873003
Cr-Commit-Position: refs/heads/master@{#13526}
to be aware about rare situation where packet resend before sent:
Expectations reduced by validating frame was rendered after or before last
packet for that frame was dropped.
BUG=webrtc:5540
Review-Url: https://codereview.webrtc.org/2180903002
Cr-Commit-Position: refs/heads/master@{#13523}
Test was expecting no rtx packet before dropped packet.
Because of prober there might be some non-padding rtx packets before nack.
Those checks removed, test primary expectations are unaffected.
BUG=webrtc:5540
R=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2180843002
Cr-Commit-Position: refs/heads/master@{#13522}
This CL fixes a crash that could happen when JSON event tracing is
shutting down. The cause of the crash was the fact that the logger
thread function was returning 'true', causing the platform thread to run
it repeatedly even though that wasn't the intention.
Usually the EventLogger::Stop() function would set the event requesting
the logging thread to clean up and close the file, and then immediately
call PlatformThread::Stop() which would stop the outer loop. The Log()
function would only run once and everything behaves as expected.
However, if a context switch happens between the shutdown_event_.Set()
and logging_thread_.Stop() calls in EventLogger::Stop(), the logger
thread function would close the file and exit the Log() method, while
PlatformThread will rerun it again. So the Log() function runs twice,
and the second time output_file_ is NULL which either causes the DCHECK
to fail (in debug builds) or the fprintf() to crash with SIGSEGV (in
release builds).
The fix simply changes the return value of the thread function to false
so it never runs twice.
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2168283002 .
Cr-Commit-Position: refs/heads/master@{#13510}
stack will be removed soon in a separate CL. Constraints will not be supported
in the new implementation. Apps can request a format directly and the closest
supported format will be selected.
Changes needed from the apps:
1. Use the new createVideoSource without constraints.
2. Call startCapture manually.
3. Don't call videoSource.stop/restart, use startCapture/stopCapture instead.
R=magjed@webrtc.orgTBR=kjellander@webrtc.org
Review URL: https://codereview.webrtc.org/2127893002 .
Cr-Commit-Position: refs/heads/master@{#13504}
Now it check if rtp timestamp can be calculating instead of checking number of rtp packets. This way it works for reconfigured streams too.
It also moved deeper into rtcp_sender class to prevent SR no matter the reason it need to be genereated. This way it prevents creating compound rtcp packets that have to start with Sender Report and Sender Reports as response to (mostly theoretical) sr-request rtcp packet.
BUG=webrtc:1600
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1639253007 .
Cr-Commit-Position: refs/heads/master@{#13503}
Retransmissions are supposed to be sent before normal packets by the pacer, but the current implementation will only use it if the second packet is a retransmission and the first packet is not. It misses the case where the first packet is retransmission and the second packet is not.
This CL fixes the comparator and adds a unit test.
Also changed the SendAndExpectPacket function to propagate the retransmission flag to the expectations. Previously, all packets were expected to be normal packets.
BUG=webrtc:6124
Review-Url: https://codereview.webrtc.org/2156063004
Cr-Commit-Position: refs/heads/master@{#13502}
and use the preparsed headers to plot the network delay changes.
This is the first of several CLs that clean up the visualization
tool to make it easier to add new metrics.
Review-Url: https://codereview.webrtc.org/2145153002
Cr-Commit-Position: refs/heads/master@{#13499}
The added unittest triggers this CHECK:
433ed06800/webrtc/modules/remote_bitrate_estimator/remote_estimator_proxy.cc (146)
It happens because the unwrap of the sequence number fails if the unwrappers last sequence number is small, but the newly added sequence number is large (greater than last seq num + 2^15), and therefore should have been interpreted as a reordering and a backwards wrap. Since that would mean the sequence number returned from the unwrapper would be negative, it simply returns the original sequence number instead. This causes problems later where the wrap is correctly handled, and everything breaks.
The real solution should be to correctly handle wraps, but to prevent the crash this is a reasonable workaround for now.
BUG=
Review-Url: https://codereview.webrtc.org/2157843002
Cr-Commit-Position: refs/heads/master@{#13496}
We thought we could safely remove this, but older versions of Chrome
don't do role conflict resolution properly, so it's actually not safe
to yet.
BUG=628676
Review-Url: https://codereview.webrtc.org/2152963003
Cr-Commit-Position: refs/heads/master@{#13492}
Logging when a candidate is gathered or the gathering state or a
Port changes. This will make it easier to identify problems related
to candidate gathering.
Review-Url: https://codereview.webrtc.org/2122373004
Cr-Commit-Position: refs/heads/master@{#13490}
After https://codereview.webrtc.org/1827263002, audio devices are no
longer (ever) initialized if they return true from
RecordingIsInitialized. Since this was left as "return true;" for
file_audio_device, the recording buffer was never set up correctly, and
the audio buffer would assert when called (in debug) and FileAudioDevice
would cause memory corruption (in release).
BUG=
Review-Url: https://codereview.webrtc.org/2116003003
Cr-Commit-Position: refs/heads/master@{#13489}
Necessary when compiling this file on a case-sensitive file system.
BUG=chromium:495204,chromium:617318
Review-Url: https://codereview.webrtc.org/2145373004
Cr-Commit-Position: refs/heads/master@{#13488}
In order to correctly determine the references of a frame when using Vp9
with GOF one has to wait for all frames on the lower temporal layers
to make sure no up-switch point is missed.
This patch fix a bug where upon receiving a frame the RtpFrameReferenceFinder
would try to add missing frame for a group with a not yet knows scalability
structure.
BUG=webrtc:5514
Review-Url: https://codereview.webrtc.org/2127073002
Cr-Commit-Position: refs/heads/master@{#13487}
Reason for revert:
Nope, breaks chromium
Original issue's description:
> Fix inconsistent setting of the rtc_include_unittests flag.
>
> On advice from brettw, se discussion here:
> https://codereview.webrtc.org/2149543002/
>
> The problem was we were setting the flag to both false and true,
> and the the true happened to win out for WebRTC checkouts and
> false for Chromium checkouts. This change should make this
> mechanic more obvious.
>
> This change _should_ have no effect downstream.
>
> Doing tbr to see if we can get the chromium import back into a good state today.
>
> TBR=tommi@webrtc.org
>
> Committed: https://crrev.com/9d34148714773339a4e8396bd28aceb571554d36
> Cr-Commit-Position: refs/heads/master@{#13484}
TBR=tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/2150293002
Cr-Commit-Position: refs/heads/master@{#13486}
After disabling all of these, the rest of the tests pass, at least on
my Nexus 7 device.
BUG=webrtc:4364
Review-Url: https://codereview.webrtc.org/2151823002
Cr-Commit-Position: refs/heads/master@{#13485}
On advice from brettw, se discussion here:
https://codereview.webrtc.org/2149543002/
The problem was we were setting the flag to both false and true,
and the the true happened to win out for WebRTC checkouts and
false for Chromium checkouts. This change should make this
mechanic more obvious.
This change _should_ have no effect downstream.
Doing tbr to see if we can get the chromium import back into a good state today.
TBR=tommi@webrtc.org
Review-Url: https://codereview.webrtc.org/2154693002
Cr-Commit-Position: refs/heads/master@{#13484}
This it to avoid requiring targets that include header files that in turn use SequenceTaskedChecker, to also have to define the macros needed by TaskQueue.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2145393003
Cr-Commit-Position: refs/heads/master@{#13482}
If the currently selected connection becomes not receiving and if a backup connection
becomes strong first, we will not switch the connection until X milliseconds is passed
but the selected connection is still not receiving and the backup connection is still receiving. This will prevent the connection switching from happening too frequently.
BUG=
Review-Url: https://codereview.webrtc.org/2143653005
Cr-Commit-Position: refs/heads/master@{#13480}
It causes an asan initialization-order-fiasco in trying to read the
names of other globally constructed data:
==21449==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7f6f297bc5e8 at pc 0x7f6f26b332a7 bp 0x7ffd479f8cb0 sp 0x7ffd479f8ca8
READ of size 8 at 0x7f6f297bc5e8 thread T0
#0 0x7f6f26b332a6 in name
webrtc/base/flags.h:83:38
#1 0x7f6f26b332a6 in Lookup
webrtc/base/flags.cc:133
#2 0x7f6f26b332a6 in rtc::FlagList::Register(rtc::Flag*)
webrtc/base/flags.cc:260
#3 0x7f6f2529972b in __cxx_global_var_init.1
BUG=
Review-Url: https://codereview.webrtc.org/2110963004
Cr-Commit-Position: refs/heads/master@{#13479}
