The issue was that if the main entry routine of the thread would get called before the first APC, the thread would hang on a GetMessage() call and the APC sent to initialize the thread, would never run.
BUG=
Review-Url: https://codereview.webrtc.org/2139723003
Cr-Commit-Position: refs/heads/master@{#13438}
webrtc doesnt include the header that the function is prototyped in.
This CL makes the convert_from.h include those headers to allow webrtc to
update to the head libyuv.
R=marpan@webrtc.org,pbos@webrtc.org
BUG=libyuv:620,webrtc:6094
TESTED=local build and try bots
Review-Url: https://codereview.webrtc.org/2139853002
Cr-Commit-Position: refs/heads/master@{#13436}
Added various timestamps to the FrameObject class which are needed to calculate
the jitter delay.
BUG=webrtc:5514
Review-Url: https://codereview.webrtc.org/2124943002
Cr-Commit-Position: refs/heads/master@{#13434}
This interface and its implementations have been replaced by
rtc::RTCCertificateGeneratorInterface.
Removes dtlsidentitystore.h, updates .gyp/gn and removes old #includes.
BUG=webrtc:5707, webrtc:5708
Review-Url: https://codereview.webrtc.org/2034013003
Cr-Commit-Position: refs/heads/master@{#13432}
These arguments are not really known when calling SetEncodingData. They are still provided as argument to ProtectionBitrateCalculator::SetTargetRates though.
This cl is broken out from https://codereview.webrtc.org/2060403002/
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2121983002
Cr-Commit-Position: refs/heads/master@{#13429}
Also adds a copy of the BWE test suite to the new DelayBasedBwe class.
BUG=webrtc:6079
Review-Url: https://codereview.webrtc.org/2126793002
Cr-Commit-Position: refs/heads/master@{#13428}
The prototype for I420Rect is in libyuv/planar_functions.h
In the past the header was included by convert.h but in future versions
the headers dont include each other so its important to include the
specific header needed.
R=marpan@webrtc.org
BUG=webrtc:6091
Review-Url: https://codereview.webrtc.org/2130153005
Cr-Commit-Position: refs/heads/master@{#13421}
Reason for revert:
It keeps breaking upstream.
Original issue's description:
> Reland Issue 2061423003: Refactor NACK bitrate allocation
>
> This is a reland of https://codereview.webrtc.org/2061423003/
> Which was reverted in https://codereview.webrtc.org/2131913003/
>
> The reason for the revert was that some upstream code used
> RtpSender::SetTargetBitrate(). I've added that back as a no-op until we
> it's been brought up to date.
>
> TBR=tommi@webrtc.org
>
> Committed: 05ce4ae31fTBR=tommi@webrtc.org,sprang@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/2130423002
Cr-Commit-Position: refs/heads/master@{#13419}
Reason for revert:
Breaks upstream code.
Original issue's description:
> Refactor NACK bitrate allocation
>
> Nack bitrate allocation should not be done on a per-rtp-module basis,
> but rather shared bitrate pool per call. This CL moves allocation to the
> pacer and cleans up a bunch if bitrate stats handling.
>
> BUG=
> R=danilchap@webrtc.org, stefan@webrtc.org, tommi@webrtc.org
>
> Committed: 5fc59e810bTBR=tommi@webrtc.org,danilchap@webrtc.org,stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2131913003
Cr-Commit-Position: refs/heads/master@{#13417}
I'll be rewriting AcmReceiver soon and am trying to reduce the amount of
old stuff that needs to be supported.
I've manually checked the outputs of the AcmReceiver bitexactness
tests with this change. A large part of the tests are still bitexact,
with one section only differing slightly in timings. Nothing audible
unless playing the old and new versions back simultaneously.
The output of NetEqDecoderTest were also changed due to this CL, although only on android. I built and ran the test locally and compared the audio output manually - the changes were the same as for the other tests; i.e. very slight timing changes for a part of the output.
I updated the network stats checksum for android without analyzing it further. I expect it goes hand-in-hand with the changes to the output; i.e. the changes in it are fine because the audio output is fine. Likely, the stats will show changes in the usage of CNG, since that is what the code changes.
BUG=webrtc:1361
Review-Url: https://codereview.webrtc.org/2117763002
Cr-Commit-Position: refs/heads/master@{#13415}
ASSERT(!crit_.CurrentThreadIsOwner()) was racy due to use of a rtc::IsThreadRefEqual which cannot compare the thread handlers without a lock unless one is already sure it is the thread owning the crit.
Review-Url: https://codereview.webrtc.org/2131503002
Cr-Commit-Position: refs/heads/master@{#13411}
I didn't convert the APK tests, since I couldn't figure it out, nor
find any that had already been converted to copy from. I might get to it
in a new CL or even second patch-set.
BUG=webrtc:6039
Review-Url: https://codereview.webrtc.org/2123243003
Cr-Commit-Position: refs/heads/master@{#13410}
This message was printed to the receiver's log on every single video
frame if the remote side is sending video but not audio. This could
happen if, for example, one participant creates RtpSenders for both
audio and video but doesn't set the audio track, or if the track is
set but RtpParameters.encodings[0].active == false.
This CL changes the trace level to StateInfo as it is the expected
behavior in this case.
R=deadbeef@webrtc.org, henrika@webrtc.org
Review URL: https://codereview.webrtc.org/2125183002 .
Cr-Commit-Position: refs/heads/master@{#13408}
found chromium:620694.
Unfortunately it depends on unsafe GN targets, so do not build in
Chromium.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2129603003
Cr-Commit-Position: refs/heads/master@{#13407}
This CL moves some arguments, e.g. the camera thread, from the startCapture() function to a new initialize() function. These arguments are constant during the lifetime of the VideoCapturer, and are not changed for different startCapture() calls. Setting them once allows for simplifications in the code.
This CL also fixes a bug for camera2 where pendingCameraSwitchSemaphore might not be released when switchEventsHandler is null.
In camera1, the handler lock and 'cameraThreadHandler == null' check is replaced with an atomic boolean to check if the camera is stopped.
BUG=webrtc:5519
R=sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2122693002 .
Cr-Commit-Position: refs/heads/master@{#13404}
This CL mainly updates the FEC code to use more C++11 features and
to be more in line with the style guide. These changes should
have no impact on the functionality provided by the FEC.
Summary of style fixes:
- Use range-based for loops, where applicable.
- Use auto type deduction for iterator type names.
- Use RTC_DCHECK instead of assert.
- Rename FEC to Fec, where applicable.
- Update test_fec.cc to use variable_names rather than variableNames.
- Avoid redefining the PacketList types outside ForwardErrorCorrection.
Another minor change is that storage for the packet masks, as these
are generated, now is provided by a member variable, rather than
being dynamically allocated on every call to GenerateFec.
BUG=webrtc:5654
R=danilchap@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2080553003 .
Cr-Commit-Position: refs/heads/master@{#13403}
The function uses a deprecated function and is unused, so delete it.
BUG=6027
NOTRY=true
Review-Url: https://codereview.webrtc.org/2114013002
Cr-Commit-Position: refs/heads/master@{#13400}
Everything calls GetOSVersionName() instead, so no need to expose that.
Since it uses deprecated functions, this will make it easier to rewrite
it in a future change.
BUG=webrtc:6027
NOTRY=true
Review-Url: https://codereview.webrtc.org/2117823002
Cr-Commit-Position: refs/heads/master@{#13399}
There was a fast path in PreprocessToAddData that would just use the
input timestamps if the input format was equal to the required format of
the encoder. This works well as long as the codec never changes. If we
are first doing resampling (specifically upsampling) and then change to
a codec that does not require resampling, we'll need to stick to
whatever input timestamp we left off at, rather than silently accepting
whatever we're sent.
BUG=622435
Review-Url: https://codereview.webrtc.org/2119393002
Cr-Commit-Position: refs/heads/master@{#13398}
Landing these in WebRTC under a guard so they don't build in
Chromium. The guard can be removed once Chromium has migrated to use the
new GN targets.
BUG=webrtc:6081
NOTRY=true
Review-Url: https://codereview.webrtc.org/2117183005
Cr-Commit-Position: refs/heads/master@{#13397}
Add null checks for eglBase, and detach the egl context in
SurfaceViewRenderer.surfaceDestroyed().
BUG=webrtc:6032
R=sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2124983002 .
Cr-Commit-Position: refs/heads/master@{#13396}
This experiment was used to test the NackModule but will soon (tm) be used to
test the completly new video jitter buffer.
BUG=webrtc:5514
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2123913002 .
Cr-Commit-Position: refs/heads/master@{#13395}
This is called on received network packets if dump_rtp_packets_ is on.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2126463002
Cr-Commit-Position: refs/heads/master@{#13394}
I did some archaelogy here and found that the binary was (incorrectly?)
added here: https://codereview.webrtc.org/1903663002/. I can't find any
trace that a rtc_sdk_peerconnection_objc_tests has ever existed, or at
least that it doesn't exist now.
Removing it seems the right thing to do. However, I also see
rtc_sdk_peerconnection_objc target is folded into rtc_unittests in
webrtc_tests.gyp, but that target isn't listed in common_tests.json.
Should it be?
BUG=623500
TBR=tkchin@webrtc.org
Review-Url: https://codereview.webrtc.org/2121963002
Cr-Commit-Position: refs/heads/master@{#13392}
Add an option to use Camera2 implemantion of CameraVideoCapturer in
AppRTC Android Demo. It is enabled by default.
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2077663003
Cr-Commit-Position: refs/heads/master@{#13391}
A recent refactoring (r13192) introduced a bug where the min transmit
config wasn't being respected. Specifically, if a VideoSendStream was
created without it and the reconfigured, the min transmit bitrate would
not take effect. Probably the other way around as well.
BUG=webrtc::5687
Review-Url: https://codereview.webrtc.org/2106183002
Cr-Commit-Position: refs/heads/master@{#13390}
