The mixer allocates an audio frame for each added data source. This
audio frame was deallocated when a source was removed from the
mixer. Source removal could happen during the mixing, and the existing
locking scheme (and the Clang thread checker) was not sufficient to
prevent a data race.
After this change, the mixer doesn't release its lock until it is
finished with the sources' Audio frames. Since multi-threaded access to
the mixer only happens when a source is added or removed, we believe
that this change wouldn't have any noticeable performance impact.
NOTRY=True
BUG=webrtc:6346
Review-Url: https://codereview.webrtc.org/2439283002
Cr-Commit-Position: refs/heads/master@{#14744}
Separate the null implementation from rtp_rtcp_defines.h, and follow chromium style guide for virtual functions.
BUG=webrtc:163
Review-Url: https://codereview.webrtc.org/2400993002
Cr-Commit-Position: refs/heads/master@{#14738}
the render side to the capture side using the same
pattern. Currently this is done independently for the
submodules.
This CL moves the the AEC functionality for this into
APM.
BUG=webrtc:5298, webrtc:6540
Review-Url: https://codereview.webrtc.org/2427553003
Cr-Commit-Position: refs/heads/master@{#14726}
Now does level estimate on the audio threads to avoid complex
copying of audio data to task queue. The old implementation could
also crash due to unclear ownership of the audio buffer.
BUG=webrtc:6569
R=kwiberg@webrtc.org
Review URL: https://codereview.webrtc.org/2433393002 .
Cr-Commit-Position: refs/heads/master@{#14720}
Simplify the AudioMixer::Source interface and update the mixer
implementation to the new interface.
Instead of asking a mixer source to provide a pointer to an AudioFrame
during each mixing iteration, a mixer should supply a pointer to its
own AudioFrame.
This simplifies lifetime issues as sources do not give away an
internal pointer.
Implementation: when an audio source is added, the mixer allocates a
new AudioFrame. The audio frame is kept together in the internal class
SourceStatus together with the audio source pointer until the source
is removed.
NOTRY=True
BUG=webrtc:6346
Review-Url: https://codereview.webrtc.org/2420913002
Cr-Commit-Position: refs/heads/master@{#14713}
This change is due to an incorrect understanding of the threading
model in Chrome. The new AudioMixer has a thread checker to ensure
that mixing is always done from a single thread. Mixing is done on the
Audio Output Thread. When run in Chrome, it can change. Even if the thread
changes, there is never more than one audio thread, and mixing is done
sequentially.
The threading checks and variable access checks are replaced with
rtc::RaceChecker counterparts.
NOTRY=True
BUG=webrtc:6346
Review-Url: https://codereview.webrtc.org/2437913003
Cr-Commit-Position: refs/heads/master@{#14712}
Previously shared_desktop_frame.cc wasn't in primitives target, but it
is used in remoting client on android and the client should depend only
on primitives, but not desktop_capture overall.
BUG=653612
R=nicholss@chromium.org
Review URL: https://codereview.webrtc.org/2436913002 .
Cr-Commit-Position: refs/heads/master@{#14709}
The AudioMixer is now split in a mixer and audio source interface part, which has moved to webrtc/api, and a default implementation part, which lies in webrtc/modules.
This change makes it possible to create other mixer implementations and is a first step to facilitate passing down a mixer from outside of WebRTC.
It will also create less build dependencies when the new mixer has replaced the old one.
NOTRY=True
TBR=henrik.lundin@webrtc.org
BUG=webrtc:6346
Review-Url: https://codereview.webrtc.org/2411313003
Cr-Commit-Position: refs/heads/master@{#14705}
This CL makes scaling and cropping lazy in AVFoundationVideoCapturer and
provides optimized paths for SW and HW encoding. For SW encoding, an
efficient NV12 -> I420 cropping and scaling is implemented in
CoreVideoFrameBuffer::NativeToI420. For HW encoding, an efficient NV12 ->
NV12 cropping and scaling is implemented in
CoreVideoFrameBuffer::CropAndScaleTo. The performance improvement over
the existing cropping and scaling is that it is now done in one step
instead of making an intermediary copy of the Y plane.
There might still be room for improvement in the HW path using some HW
support. That will be explored in a future CL.
BUG=b/30939444
Review-Url: https://codereview.webrtc.org/2394483005
Cr-Commit-Position: refs/heads/master@{#14701}
The main reason for doing this is to allow refcounted objects to accept rvalue references in ctor and be able to std::move ctor rvalue arguments.
Also, refcounted.h is now generated using pump.py instead of manually creating each ctor version.
BUG= none
Review-Url: https://codereview.webrtc.org/2425683003
Cr-Commit-Position: refs/heads/master@{#14687}
Reason for revert:
Breaks internal project
Original issue's description:
> Move current bitstream parser to more appropriate directory.
>
> This CL groups together the code that has to do with parsing H264 bitstreams.
> This code logically belongs together, and having it in the same directory not
> only simplifies things from a project structure perspective, but also makes it
> easier to refactor out common parts incrementally.
> An added benefit is that this simplifies modular compilation, where for example
> one would like a build of WebRTC without the H264 codec-specific parts.
>
> BUG=webrtc:6338
>
> Committed: https://crrev.com/cc6817e9ce4a5ffc73efb660cf0368afbc7d9a4f
> Cr-Commit-Position: refs/heads/master@{#14684}
TBR=magjed@webrtc.org,stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6338
Review-Url: https://codereview.webrtc.org/2430353004
Cr-Commit-Position: refs/heads/master@{#14685}
This CL groups together the code that has to do with parsing H264 bitstreams.
This code logically belongs together, and having it in the same directory not
only simplifies things from a project structure perspective, but also makes it
easier to refactor out common parts incrementally.
An added benefit is that this simplifies modular compilation, where for example
one would like a build of WebRTC without the H264 codec-specific parts.
BUG=webrtc:6338
Review-Url: https://codereview.webrtc.org/2370853005
Cr-Commit-Position: refs/heads/master@{#14684}
Reason for revert:
Flaky test has been fixed.
Original issue's description:
> Revert of Add path for recovered packets from internal::Call to RtpStreamReceiver. (patchset #2 id:60001 of https://codereview.webrtc.org/2390823009/ )
>
> Reason for revert:
> Speculative revert as it may be the cause of the DrMemory test failure:
> https://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Full/builds/5115
>
> Original issue's description:
> > Add path for recovered packets from internal::Call to RtpStreamReceiver.
> >
> > When the FlexfecReceiver recovers media packets, it inserts these into
> > internal::Call, which then distributes them to the appropriate
> > VideoReceiveStream/RtpStreamReceiver.
> >
> > BUG=webrtc:5654
> >
> > Committed: https://crrev.com/9c4b4b47f4325b48e1856566a30983f9e4e30dd0
> > Cr-Commit-Position: refs/heads/master@{#14642}
>
> TBR=stefan@webrtc.org,brandtr@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5654
>
> Committed: https://crrev.com/862d74d0176fa762b3c96cf20bd36f27e7001a47
> Cr-Commit-Position: refs/heads/master@{#14652}
TBR=stefan@webrtc.org,honghaiz@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2428303004
Cr-Commit-Position: refs/heads/master@{#14677}
ScreenCapturer tests may fail on trybot, so this change is to fix the issue.
Changes include,
1. Sometimes, a capturer may capture part of the change, i.e. usually the draw
actions are not atomic. So the updated_region may be inaccurate. So I have added
a MayDrawIncompleteShapes() function in ScreenDrawer. If it returns false, the
updated_region check will be ignored.
2. Several test cases may run concurrently, which makes one ScreenDrawer won't
really work. Its window may be covered by another ScreenDrawer. So I have added
a system wide lock to ensure only one ScreenDrawer is working at a certain time.
3. On unity (Linux), the top several pixels of a window may be covered by a
shadow effect if the window is not focused. So I have added a BringToFront()
function, and call it in WaitForPendingDraws().
4. On Windows, the drawn shapes are 'temporary drawing', which will be erased
once the window is covered by another one. So I repeat DrawRectangle() function
call in the test case.
TODO(zijiehe): The DISABLED_ prefixes will be added back after the code review.
And I will move these test cases into modules_test in a coming change.
BUG=647067
Review-Url: https://codereview.webrtc.org/2337073007
Cr-Commit-Position: refs/heads/master@{#14674}
The main goal of this CL is to remove old buffer handling using static arrays
and switch to the improved rtc::Buffer class instead.
By doing so, we can remove some members (since Buffer maintains them instead) and
do some additional cleanup.
This CL also fixes some minor style issues and improves the locking mechanism.
Finally, AudioDeviceBuffer::SetRecordingChannel() is deprecated since it has never been
used and is not included in any test.
BUG=NONE
Review-Url: https://codereview.webrtc.org/2333273002
Cr-Commit-Position: refs/heads/master@{#14661}
Only three items in the (rather large) header were actually used after
InsertPacket: payloadType, timestamp and sequenceNumber. They are now
put directly into Packet. This saves 129 bytes per Packet that no
longer need to be allocated and deallocated.
This also works towards decoupling NetEq from RTP. As part of that,
I've moved the NACK code earlier in InsertPacketInternal, together
with other things that directly reference the RTPHeader.
BUG=webrtc:6549
Review-Url: https://codereview.webrtc.org/2411183003
Cr-Commit-Position: refs/heads/master@{#14658}
Reason for revert:
Speculative revert as it may be the cause of the DrMemory test failure:
https://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Full/builds/5115
Original issue's description:
> Add path for recovered packets from internal::Call to RtpStreamReceiver.
>
> When the FlexfecReceiver recovers media packets, it inserts these into
> internal::Call, which then distributes them to the appropriate
> VideoReceiveStream/RtpStreamReceiver.
>
> BUG=webrtc:5654
>
> Committed: https://crrev.com/9c4b4b47f4325b48e1856566a30983f9e4e30dd0
> Cr-Commit-Position: refs/heads/master@{#14642}
TBR=stefan@webrtc.org,brandtr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2427733002
Cr-Commit-Position: refs/heads/master@{#14652}
for consistency with other rtcp packet classes.
BUG=webrtc:5260
Review-Url: https://codereview.webrtc.org/2361853002
Cr-Commit-Position: refs/heads/master@{#14648}
and thus IP_PACKET_SIZE constant:
Build() use BlockLength() instead of constant IP_PACKET_SIZE for packet
capacity, adding extra checks about packet generation in tests.
Build(callback) removed as unused.
definitions reordered to follow style.
BUG=webrtc:5260
Review-Url: https://codereview.webrtc.org/2270753002
Cr-Commit-Position: refs/heads/master@{#14647}
When the FlexfecReceiver recovers media packets, it inserts these into
internal::Call, which then distributes them to the appropriate
VideoReceiveStream/RtpStreamReceiver.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2390823009
Cr-Commit-Position: refs/heads/master@{#14642}
AEC and AECM when these become full to also work when not
in debug mode.
BUG=webrtc:6530
Review-Url: https://codereview.webrtc.org/2419023002
Cr-Commit-Position: refs/heads/master@{#14637}
To ensure this change won't break Chromium, this is the first change, to add a
new CaptureFrame() function, and let Capture(DesktopRegion) and CaptureFrame()
call each other. So both a legacy consumer or a legacy implementation won't be
broken.
BUG=https://bugs.chromium.org/p/webrtc/issues/detail?id=6513
Review-Url: https://codereview.webrtc.org/2409833002
Cr-Commit-Position: refs/heads/master@{#14635}
Reason for revert:
Speculative revert.
Intermittent memory access errors suspected to be caused by this cl.
See for instance https://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Light/builds/8018
UNADDRESSABLE ACCESS of freed memory: reading 0x0331d330-0x0331d334 4 byte(s)
# 0 webrtc::voe::RtcpRttStatsProxy::LastProcessedRtt
# 1 webrtc::ModuleRtpRtcpImpl::Process
Original issue's description:
> Add RtcpRttStats to AudioStream
>
> BUG=webrtc:6508
>
> Committed: https://crrev.com/e0729c56d35acfaf9738fdb32c6508cd78eaf089
> Cr-Commit-Position: refs/heads/master@{#14595}
TBR=stefan@webrtc.org,minyue@webrtc.org,solenberg@webrtc.org,michaelt@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6508
Review-Url: https://codereview.webrtc.org/2415943002
Cr-Commit-Position: refs/heads/master@{#14631}
With this change, the calculations inside AverageIAT are changed to be
in double-precision floating point instead of in fixed point. Also,
the method's name is changed to EstimatedClockDriftPpm to better
reflect what it returns.
A few unit tests had to be updated because of minor numerical
differences.
Also removing the UBSan suppression related to this issue.
BUG=webrtc:5889
Review-Url: https://codereview.webrtc.org/2408653002
Cr-Commit-Position: refs/heads/master@{#14628}
This was an ill tested special case which turned out to be more problem
than benefit. The special case was only triggered when the decoder frame
size was smaller than 10 ms, which is more or less unsupported by NetEq.
Also fixed a bug in a test, a bug which was exposed by the code change.
BUG=chromium:654983
Review-Url: https://codereview.webrtc.org/2412883002
Cr-Commit-Position: refs/heads/master@{#14627}
Reason for revert:
There is a risk of ending up in a bad state due to race conditions with this patch. Tests in downstream clients have shown that it can
happen that an output stream is opened up in MUSIC mode when it should not.
Reverting since the new functionality added here is not worth the
risk of breaking existing clients.
Original issue's description:
> Android audio playout now supports non-call media streams.
>
> The default (preferred) stream type for output audio is STREAM_VOICE_CALL since the WebRTC stack is mainly intended for VoIP calls. But if the user wants to run in another mode than COMM mode, we now accept it and change the stream type to STREAM_MUSIC instead. It can e.g. be suitable for applications that does not record audio or if a call shall be casted to a Chromecast device.
>
> The solution is somewhat experimental.
>
> NOTRY=TRUE
>
> BUG=webrtc:4767
>
> Committed: https://crrev.com/872f614111f436d15e29516ce19c3b63d25b8639
> Cr-Commit-Position: refs/heads/master@{#14613}
TBR=henrik.lundin@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4767
Review-Url: https://codereview.webrtc.org/2420583002
Cr-Commit-Position: refs/heads/master@{#14626}
