media/ and p2p/ doesn't actually depend on these anymore.
BUG=webrtc:5539
NOTRY=True
Review-Url: https://codereview.webrtc.org/2447533003
Cr-Commit-Position: refs/heads/master@{#14761}
Reason for revert:
Breaks H264 for external encoders in WebRTC as well as breaking H264 interop with e.g. Edge.
Original issue's description:
> H264 codec: Check profile-level-id when matching
>
> For the H264 video codec, comparing the codec name is not enough
> for determining a match. The profile-level-id must also match.
> This CL:
> - Specializes the VideoCodec::Matches function with extra logic for
> matching H264 codecs.
> - Adds unittests for matching H264 video codecs.
> - Removes the unnecessary CodecTest fixture class.
>
> BUG=webrtc:6337,chromium:645599
>
> Committed: https://crrev.com/68979ab7dd971ab6e983b23c83154ba05e183fb8
> Cr-Commit-Position: refs/heads/master@{#14546}
TBR=kthelgason@webrtc.org,hta@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6337,chromium:645599,webrtc:6552,webrtc:6402
Review URL: https://codereview.webrtc.org/2440123002 .
Cr-Commit-Position: refs/heads/master@{#14759}
In the swarming test, the machines sometimes were blocked for 1-2 seconds without processing anything.
This CL makes sure that 1 second timeout is only used with fake clock.
BUG=webrtc:6500
Review-Url: https://codereview.webrtc.org/2442813002
Cr-Commit-Position: refs/heads/master@{#14756}
XGetImage() may return NULL and XServerPixelBuffer wasn't handling this
case properly.
BUG=649487
Review-Url: https://codereview.webrtc.org/2446733003
Cr-Commit-Position: refs/heads/master@{#14754}
This can be used for a certain security exploit, and doesn't have any
other practical applications we know of.
BUG=chromium:649118
Review-Url: https://codereview.webrtc.org/2440043004
Cr-Commit-Position: refs/heads/master@{#14751}
or not being collected correctly.
These TODOs are already documented and in greater detail in
rtcstatscollector.cc, but if every discrepency is listed in
rtcstats_objects.h it is easier to get an overview of the progress of
the new GetStats API.
BUG=chromium:627816
TBR=hta@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2443163002
Cr-Commit-Position: refs/heads/master@{#14749}
It turns out that that audio network adaptor can always be created with knowledge of receiver frame length range. There is no need to keep some infrastructure that is used for runtime setting of receiver frame length ranges.
BUG=webrtc:6303
Review-Url: https://codereview.webrtc.org/2429503002
Cr-Commit-Position: refs/heads/master@{#14748}
PacketList is now list<Packet> instead of list<Packet*>.
Splicing the lists in NetEqImpl::InsertPacketInternal instead of
moving packets. Avoid moving the packet when doing Rfc3389Cng.
Removed PacketBuffer::DeleteFirstPacket and DeleteAllPackets.
BUG=chromium:657300
Review-Url: https://codereview.webrtc.org/2425223002
Cr-Commit-Position: refs/heads/master@{#14747}
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}
Move the following targets into webrtc/video/BUILD.gn:
* screenshare_loopback
* video_quality_test
* video_loopback
Add new target 'run_tests' in webrtc/test/BUILD.gn, being used by two
of the above and make then depend on that instead.
BUG=webrtc:6440
NOTRY=True
Review-Url: https://codereview.webrtc.org/2438973002
Cr-Commit-Position: refs/heads/master@{#14735}
Since WebRtcVideoSendStream have reconfigures the send codec to match the incoming captured frames widht and height they have not been used.
Framerate has just been set when parsing sdp to 60fps and not changed elsewhere.
This cl require some upstream projects to change first.
BUG=webrtc:5332
Review-Url: https://codereview.webrtc.org/2408153002
Cr-Commit-Position: refs/heads/master@{#14733}
Reason for revert:
This was a workaround to help Chrome wire up the googNoiseReduction constraint. However, it was fixed in a different way in Chrome, and this hack is not actually needed.
Original issue's description:
> Add method cricket::VideoCapturer::NeedsDenoising, use in VideoCapturerTrackSource.
>
> BUG=chromium:645907
>
> Committed: https://crrev.com/0d14c6abba19295725519ce38105688ae0a62513
> Cr-Commit-Position: refs/heads/master@{#14219}
TBR=pbos@webrtc.org,hta@webrtc.org,perkj@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:645907
Review-Url: https://codereview.webrtc.org/2433293003
Cr-Commit-Position: refs/heads/master@{#14729}
Call demultiplexes received RTP packets and delivers these to the
appropriate {Video,Flexfec}ReceiveStreams. A single video stream
could conceivably be protected by multiple FlexFEC streams.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2388303009
Cr-Commit-Position: refs/heads/master@{#14727}
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}
We need to wait for posted frames to be rendered first in release()
instead of abruptly quitting, in order to simplify testing.
BUG=webrtc:6545
R=sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2440703002 .
Cr-Commit-Position: refs/heads/master@{#14722}
The stat is currently always set to zero until the residual echo detector has landed.
BUG=webrtc:6525
Review-Url: https://codereview.webrtc.org/2431443003
Cr-Commit-Position: refs/heads/master@{#14721}
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}
