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}
Previously SHA1Transform() kept a static buffer. As result SHA1 was not
always computed correctly when running that code in parallel on multiple
threads. That was causing spurious messages about invalid Message
Integrity attribute when running some tests in chromoting.
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/57379004
Cr-Commit-Position: refs/heads/master@{#9238}
Avoids existing crash and ensures that error message is passed up to Libjingle. Will lead to the following logcat output:
E/libjingle(31404): Error(channel.cc:1514): Failed to SetSend 2 on voice channel
BUG=b/21273153
R=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/54459004
Cr-Commit-Position: refs/heads/master@{#9236}
This CL adds an API to SSL stream adapters to set the maximum allowed
protocol version and with that implements support for DTLS 1.2.
With DTLS 1.2 the default cipher changes in the unittests as follows.
BoringSSL
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA -> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
NSS
TLS_RSA_WITH_AES_128_CBC_SHA -> TLS_RSA_WITH_AES_128_GCM_SHA256
BUG=chromium:428343
R=juberti@google.com
Review URL: https://webrtc-codereview.appspot.com/50989004
Cr-Commit-Position: refs/heads/master@{#9232}
compile time.
The condition of static_assert() is evaluated at compile time which is safer and
more efficient.
Note that static_assert() requires C++11.
The changes were generated by the misc-static-assert ClangTidy check by alexfh@google.comR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51019004
Cr-Commit-Position: refs/heads/master@{#9231}
Merge WEBRTC_ARCH_ARM64_NEON and WEBRTC_ARCH_ARM_NEON into one
WEBRTC_HAS_NEON.
Replace WEBRTC_DETECT_ARM_NEON by WEBRTC_DETECT_NEON.
Replace WEBRTC_ARCH_ARM by WEBRTC_ARCH_ARM64 for arm64 cpu.
BUG=4002
R=andrew@webrtc.org, jridges@masque.com, kjellander@webrtc.org
Change-Id: I870a4d0682b80633b671c9aab733153f6d95a980
Review URL: https://webrtc-codereview.appspot.com/49309004
Cr-Commit-Position: refs/heads/master@{#9228}
When a frame being stretched, the original rotation information is lost. This is to ensure it's carried over.
Also removed StretchToBuffer function as it's not called and dangerous.
BUG=4366
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51869004
Cr-Commit-Position: refs/heads/master@{#9224}
- Set Camera.ErrorCallback callback when opening camera to
receive camera server error notifications.
- Allow user to provide interface for handling camera errors
happening on camera thread.
- Run camera observer on camera thread and monitor camera fps
and amount of callback buffers, print statistics and report error
if camera stops generating frames.
- Query camera formats starting from front camera instead of back
camera to detect camera failures as fast as possible.
- Change all DCHECK to CHECK in androidvideocapturer.cc to detect
camera error on release builds.
- Plus adding some extra logging.
R=hbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/52519004
Cr-Commit-Position: refs/heads/master@{#9221}
The class doesn't do anything in almost all cases except for grabbing and releasing locks + allocate memory. There are a couple of methods there such as WaitForKey and GetTimeInMs that are used, but those methods aren't specific to audio and we have implementations of these elsewhere. The third method, StringCompare isn't used anywhere (and also isn't specific to audio).
BUG=
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50009004
Cr-Commit-Position: refs/heads/master@{#9220}
