uint32_t parameters don't need to be passed by reference. The
VCMJitterBuffer destructor doesn't need to be virtual because the
class has no virtual methods.
R=stefan@webrtc.org
BUG=none
Review URL: https://webrtc-codereview.appspot.com/55499004
Cr-Commit-Position: refs/heads/master@{#9288}
The previous script only looked up the LKGR and generated a
commit message. This CL renames the script and makes it update
the DEPS file, commit locally, upload CL and send tryjobs.
BUG=4688
R=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50079004
Cr-Commit-Position: refs/heads/master@{#9284}
In my previous cl, https://webrtc-codereview.appspot.com/52479004/, there is 'UnLock()' left when we switched to scoped lock, which will cause TSan warning sometimes.
===========================================================
WARNING: ThreadSanitizer: unlock of an unlocked mutex (or by a wrong thread) (pid=9981)
#0 pthread_mutex_unlock <null> (libjingle_peerconnection_unittest+0x00000046836f)
#1 webrtc::CriticalSectionPosix::Leave() webrtc/system_wrappers/source/critical_section_posix.cc:39:10 (libjingle_peerconnection_unittest+0x000000bc368d)
#2 ~CriticalSectionScoped webrtc/system_wrappers/interface/critical_section_wrapper.h:46:48 (libjingle_peerconnection_unittest+0x000000a61fcb)
#3 webrtc::AudioDeviceLinuxPulse::RecThreadProcess() webrtc/modules/audio_device/linux/audio_device_pulse_linux.cc:3003 (libjingle_peerconnection_unittest+0x000000a61fcb)
===========================================================
BUG=3056
TEST=bots
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/56439004
Cr-Commit-Position: refs/heads/master@{#9282}
BUG=4690
I have removed methods in VoE interfaces that were marked to be removed. I have removed them also in fake and mock implementations. I have also updated the callers in various ways:
1. Project win_test had some calls to the removed methods, but it turned out that the project is not used anymore, so I removed it entirely.
2. There were some calls to removed methods in jni methods. I have removed couple of jni methods as now they seem to do nothing.
3. With the remaining callers I just removed the calls to removed methods.
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/53519004
Cr-Commit-Position: refs/heads/master@{#9281}
It looks like our basictypes.h file in the overrides folder is including the file it is overriding due to include path precedence (Chrome's is lower than WebRTCs).
TBR=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51909004
Cr-Commit-Position: refs/heads/master@{#9280}
Add pylintrc file based on
https://code.google.com/p/chromium/codesearch#chromium/src/tools/perf/pylintrc
bit tightened up quite a bit (the one in depot_tools is far
more relaxed).
Remove a few excluded directories from pylint check and fixed/
suppressed all warnings generated.
Add GN format check + formatted all GN files using 'gn format'.
Cleanup redundant rules in tools/PRESUBMIT.py
TESTED=Ran 'git cl presubmit -vv', fixed the PyLint violations.
Ran it again with a modification in webrtc/build/webrtc.gni, formatted
all the GN files and ran it again.
R=henrika@webrtc.org, phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50069004
Cr-Commit-Position: refs/heads/master@{#9274}
Having nice CL descriptions that explains what a roll of
chromium_revision in WebRTC's DEPS file actually changes is
useful to save time tracing down breakages.
This script can be used to generate such CL descriptions.
In the future it might be used for a complete auto-rolling
solution for this.
BUG=4688
R=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/27889004
Cr-Commit-Position: refs/heads/master@{#9270}
This is being done in preparation of moving base/logging.* to rtc_base_approved. base/stream.* has libjingle dependencies that webrtc can't use, so logging.* can't depend on streams. It does look like stream.* isn't used much, so cleaning that up as well as cleaning up usage of the actual stream support (now LogStream) in the logging code, is in order, but I'll leave that to another cl.
BUG=
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/54529004
Cr-Commit-Position: refs/heads/master@{#9269}
I wanted to use Config::Get in Chromium code, but it triggered the following
warning:
../../third_party/webrtc/common.h:89:20: error: declaration requires an exit-time destructor [-Werror,-Wexit-time-destructors]
static const T def;
^
../../third_party/webrtc/common.h:110:10: note: in instantiation of function template specialization requested here
return default_value<T>();
^
I assume we don't hit this in webrtc because the warning is disabled.
This also switches to the RTC_ prefix from the deprecated LIBJINGLE_.
Needed due to this Chromium CL:
https://codereview.chromium.org/1148843004/R=andresp@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/53459004
Cr-Commit-Position: refs/heads/master@{#9268}
tl;dr - non-continuous frames (due to padding) would get stuck as incomplete if the previous complete frame arrived and was decoded before the padding arrived.This fix re-checks the incomplete frame list for continuous frames after old packets arrive.
When padding is enabled and RTX is not, padding is sent as empty RTP packets tacked onto the end of completed frames (meaning: same timestamp, but after a packet with the marker bit set). Given the following set of circumstances, codified in the new unit test method, a frame can get permanently stuck in the incomplete frames list:
- Frame A decoded (packets 94-95). Next expected sequence number is 96.
- Frame C arrives (packets 100-101) and is marked complete. It isn't continuous, since it starts at 100, so it's placed in the incomplete frame list.
- Frame B arrives (packets 96-97) and is complete, since 97 has a marker bit. Turns out that packets 98-99 are padding, but the receiver doesn't know that.
- Frame B is decoded, removed from the decodable frames list, and last decoded state is updated.
- Packets 98-99 arrive. They hit the IsOldPacket check and update the last decoded state, but they don't trigger FindAndInsertContinuousFrames.
- Further packets/frames arrive and complete, but FindAndInsertContinuousFrames only runs on frames that are newer than the newly completed frame.
In this state, Frame C is permanently stuck as incomplete, so the jitter buffer overall is stuck until max NACK age (default: 450 packets), the max NACK list size (default: 200 packets), or a keyframe arrives and IsContinuous returns true for the keyframe.
(Before the November refactoring, Frame B wouldn't have to have been decoded for the bug to trigger; just having a complete continuous frame at any time before the padding arrived would cause this state, as FindAndInsertContinuousFrames was only called when the frame originally became continuous and was inserted into the decodable frames list. Post refactoring, the frame is removed/re-added to the decodable list on every padding packet that arrives)
BUG=
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50959004
Cr-Commit-Position: refs/heads/master@{#9264}
Because of the Finch experiment, this will not affect Chrome's behaviour at all.
The SNRs in AudioProcessingTest.Formats were only increased to the next multiple of 5.
BUG=webrtc:3146
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43359004
Cr-Commit-Position: refs/heads/master@{#9263}
Previously, AudioEncoderCng required the speech encoder to not change
its mind regarding the number of 10 ms frames in the next packet
between calls to AudioEncoderCng::EncodeInternal()---specifically, it
could handle an upward but not a downward adjustment. With this patch,
it can handle a downward adjustment too, by simply saving the
overshoot data for the next call to EncodeInternal().
It will still not handle the case where the encoder's reported number
of 10 ms frames in the next packet is inconsistent with the behavior
of its Encode() function when called with no intervening changes to
the encoder.
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/53469005
Cr-Commit-Position: refs/heads/master@{#9261}
1. move channel number of input file to the base class
2. limit channel number to be 1, since the resampler support only mono at the moment
3. adding a logging function
4. adding more switch to neteq_opus_quality_test
BUG=2692
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47239004
Cr-Commit-Position: refs/heads/master@{#9260}
This fixes a bug where, if the VideoCapturer failed to start under certain circumstances, the capture manager would cause a callback saying that the capturer stopped even though it never started in the first place. A VERIFY check in VideoSource::SetState would then cause a crash since the state was set to kEnded when it was already in state kEnded (SetState only allows being called when the state changes).
I only noticed this bug while doing a mistake in a separate CL. Not sure how to reliably reproduce said bug on a working build, but I have previously had camera hardware issues where it couldn't start the camera which resulted in the SetState kEnded -> kEnded crash. Hopefully this will fix that.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51039004
Cr-Commit-Position: refs/heads/master@{#9259}
The current use of rtc::FifoBuffer can lead to reading across DTLS packet
boundaries which could cause packets to not being processed correctly.
This CL introduces the new class rtc::BufferQueue and changes the
StreamInterfaceChannel to use it instead of the rtc::FifoBuffer.
BUG=chromium:447431
R=juberti@google.com
Review URL: https://webrtc-codereview.appspot.com/52509004
Cr-Commit-Position: refs/heads/master@{#9254}
This CL change the function declaration from uint16_t to size_t, and CHECKs that the size fits in uint16_t before proceeding.
BUG=484432
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47229004
Cr-Commit-Position: refs/heads/master@{#9246}
BUG=3056, 1320
TEST=AutoTest
Mainly add threadchecker and remove unnecessary lock.
And some more styling working.
- audio_device_pulse_linux.cc: wrap lines longer than 80 chars. And add '.' to some comments around. Not do it to all places.
- audio_mixer_manager_pulse_linux.cc: Here I adopt some chromium practice. We use to do many things to the failure of pulse operation, which causes most of the data race issue. In chromium, if we failed to call any pulse function, we just fail it w/o use the previous results. Here I did same. Please check if it's good.
R=bjornv@webrtc.org, henrika@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/52479004
Cr-Commit-Position: refs/heads/master@{#9243}
The uint8_t in the log string is interpreted as a char, causing a
character to be logged if the loss is non-zero and terminates the string
with a '\0' in the zero case.
R=sprang@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/53449004
Cr-Commit-Position: refs/heads/master@{#9242}
It is necessary for adding 48kHz support to the AudioProcessing::AnalyzeReverseStream int interface (It was not necessary for 32kHz since in that case the splitting filter is more efficient).
BUG=webrtc:3146
R=andrew@webrtc.org, bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/56389004
Cr-Commit-Position: refs/heads/master@{#9241}
