This cl is in preparation for https://codereview.webrtc.org/2060403002/ Add task queue to Call.
In the coming cl the video_sender, and i420_buffer_pool will be used on a task queue and therefore SequencedTaskChecker is needed instead of a ThreadChecker.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2149553002
Cr-Commit-Position: refs/heads/master@{#13474}
The decode thread should be stopped before triggering shutdown of the
video receiver, so that the decoder doesn't try to insert a new frame
while the jitter buffer is being shut down.
BUG=webrtc:6102
Review-Url: https://codereview.webrtc.org/2146883002
Cr-Commit-Position: refs/heads/master@{#13467}
Reason for revert:
For some reason, payload_type_mapper.cc is not being picked up in Chrome builds, leading to undefined references. Reverting while investigating.
Original issue's description:
> WebRtcVoiceEngine: Use AudioDecoderFactory to generate recv codecs.
>
> Changed WebRtcVoiceEngine to present receive codecs from the formats
> provided by its decoder factory. Added supported formats to
> BuiltinAudioDecoderFactory. Added helper functions for creating some
> simple decoder factories for mocking.
>
> Created a PayloadTypeMapper for assigning payload types to formats. I
> think we'll eventually want to use this further up, or possibly in
> both the audio and video sides. It would be best if the engines didn't
> have to talk payload types at all, but it might be more difficult to
> get around when payload types depend on each-other, like the RTX
> codecs for video.
>
> This CL also includes some changes to rtc::Optional. I've put them in
> a separate CL that should (or should not) land first, making these
> changes void.
> See: https://codereview.webrtc.org/2072713002/
>
> BUG=webrtc:5805
>
> Committed: https://crrev.com/95eb1ba0db79d8fd134ae61b0a24648598684e8a
> Cr-Commit-Position: refs/heads/master@{#13459}
TBR=ivoc@webrtc.org,tina.legrand@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2151453002
Cr-Commit-Position: refs/heads/master@{#13460}
Changed WebRtcVoiceEngine to present receive codecs from the formats
provided by its decoder factory. Added supported formats to
BuiltinAudioDecoderFactory. Added helper functions for creating some
simple decoder factories for mocking.
Created a PayloadTypeMapper for assigning payload types to formats. I
think we'll eventually want to use this further up, or possibly in
both the audio and video sides. It would be best if the engines didn't
have to talk payload types at all, but it might be more difficult to
get around when payload types depend on each-other, like the RTX
codecs for video.
This CL also includes some changes to rtc::Optional. I've put them in
a separate CL that should (or should not) land first, making these
changes void.
See: https://codereview.webrtc.org/2072713002/
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2072753002
Cr-Commit-Position: refs/heads/master@{#13459}
Reason for revert:
My original patch broke things that are now fixed by https://codereview.webrtc.org/2141193002/.
Hence I am relanding my original change.
Original issue's description:
> Revert of Adds data logging in native AudioDeviceBuffer class (patchset #10 id:180001 of https://codereview.webrtc.org/2132613002/ )
>
> Reason for revert:
> Seems to break things upstream.
>
> Original issue's description:
> > Adds data logging in native AudioDeviceBuffer class.
> >
> > Goal is to provide periodic logging of most essential audio parameters
> > for playout and recording sides. It will allow us to track if the native audio layer is working as intended.
> >
> > BUG=NONE
> >
> > Committed: https://crrev.com/348e411dd27e6dbe9b84b27ce46e9b7c657c1eae
> > Cr-Commit-Position: refs/heads/master@{#13440}
>
> TBR=stefan@webrtc.org,henrika@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=NONE
>
> Committed: https://crrev.com/025aa94ccb85e4c6fe20a3fecdac5d27ec9ba3da
> Cr-Commit-Position: refs/heads/master@{#13441}
TBR=stefan@webrtc.org,sprang@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=NONE
Review-Url: https://codereview.webrtc.org/2138403003
Cr-Commit-Position: refs/heads/master@{#13455}
Reason for revert:
Seems to break things upstream.
Original issue's description:
> Adds data logging in native AudioDeviceBuffer class.
>
> Goal is to provide periodic logging of most essential audio parameters
> for playout and recording sides. It will allow us to track if the native audio layer is working as intended.
>
> BUG=NONE
>
> Committed: https://crrev.com/348e411dd27e6dbe9b84b27ce46e9b7c657c1eae
> Cr-Commit-Position: refs/heads/master@{#13440}
TBR=stefan@webrtc.org,henrika@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=NONE
Review-Url: https://codereview.webrtc.org/2139233002
Cr-Commit-Position: refs/heads/master@{#13441}
Goal is to provide periodic logging of most essential audio parameters
for playout and recording sides. It will allow us to track if the native audio layer is working as intended.
BUG=NONE
Review-Url: https://codereview.webrtc.org/2132613002
Cr-Commit-Position: refs/heads/master@{#13440}
Support encoding from CVPixelBuffers directly in H264VideoToolboxEncoder.
If the frame needs to be scaled, it will fall back to the previous slow
path:
CVPixelBuffer -> NV12 -> I420 -> (scale) I420 -> NV12 -> CVPixelBuffer.
BUG=webrtc:4081
Review-Url: https://codereview.webrtc.org/2140573002
Cr-Commit-Position: refs/heads/master@{#13439}
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}
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}
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}
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}
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}
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}
When the target bitrate is zero, currently VideoSendStream.Stats.target_media_bitrate_bps show the last set rate before the target was set to zero.
BUG=webrtc::5687 b/29574845
Review-Url: https://codereview.webrtc.org/2122743003
Cr-Commit-Position: refs/heads/master@{#13386}
A bug in the transpot feedback adapter causes new feedback message to
always start with a received packet. This makes it impossible for the
receiver to distinguish from actual dropped packets and dropped feedback
messages.
BUG=webrtc:6073
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2122863002 .
Cr-Commit-Position: refs/heads/master@{#13381}
Let the FrameObject class inherit from VCMEncodedFrame since the rest of the
decoding pipeline use VCMEncodedFrame.
BUG=webrtc:5514
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2110543005 .
Cr-Commit-Position: refs/heads/master@{#13380}
I have added build files and renamed the mixer so that it doesn't conflict with the old one. The header includes now point to this copy of the mixer. I have also fixed some of the more obvious cases of style guide non-conformance and run 'PRESUBMIT' on the old mixer.
This is a first step in the creation of a new mixing module that will replace AudioConferencMixer and OutputMixer.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2104363003
Cr-Commit-Position: refs/heads/master@{#13378}
If all subencoders support textures, the adapter will claim support.
Texture frames will be passed on directly to subencoders, without any
attempt at scaling, and subencoders will be expected to sample/scale
correctly from source textures.
BUG=
NOTRY=true
Review-Url: https://codereview.webrtc.org/2099483002
Cr-Commit-Position: refs/heads/master@{#13365}
Permits CHECKing/DCHECKing that methods are being accessed in a
thread-safe manner, even if they are not used by one single thread
(thread pools such as VideoToolbox OK).
BUG=
R=danilchap@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2097403002 .
Cr-Commit-Position: refs/heads/master@{#13358}
I'm also removing media_optimization_unittest.cc, since it only tested the
suspension logic and nothing else.
R=pbos@webrtc.org
Review URL: https://codereview.webrtc.org/2119503002 .
Cr-Commit-Position: refs/heads/master@{#13355}
Before this change the ChannelBuffer had a fixed number of channels. This meant for example that when the Beamformer would reduce the number of channels to one, the merging filter bank was still merging all the channels, which was unnecessary since they were not processed and just discarded later. This change doesn't change the signal at all. It just reflects the number of channels in the ChannelBuffer, reducing the complexity.
R=henrik.lundin@webrtc.org, peah@webrtc.org, tina.legrand@webrtc.org
Review URL: https://codereview.webrtc.org/2053773002 .
Cr-Commit-Position: refs/heads/master@{#13352}
It does:
-Handle saturations in a better manner by adding different gain change
step sizes for upwards and downwards changes, as well as when there
is saturation.
-Handle conditions with initial noise-only regions in a better way by
setting a high initial peak level estimate which is gradually reduced until
certainty about the peak level is achieved.
-Limit the maximum gain to limit noise amplification, and to reflect that it
initially is intended to be used in cascade with the fixed digital AGC mode.
-Lower the maximum allowed stationary noise floor to reduce the risk of
excessive noise amplification.
-Lower the target gain to reduce the risk of causing the AEC on the other
end to fail due to high playout levels triggering nonlinearities.
This also reduces the risk for saturation.
-Handle the noise-only regions in a better manner.
NOTRY=true
TBR=aleloi
BUG=webrtc:5920
Review-Url: https://codereview.webrtc.org/2111553002
Cr-Commit-Position: refs/heads/master@{#13350}
The Stop method is used to signal any thread that is waiting in the
NextFrame function and will cause it to return immediately.
BUG=webrtc:5514
R=pbos@webrtc.org
Review URL: https://codereview.webrtc.org/2105323002 .
Cr-Commit-Position: refs/heads/master@{#13349}
