We do not have a real ScreenCapturer test before. And after CL 2210443002, a new
ScreenDrawer interface is added to the code base to draw various shapes on the
screen. This change is to use ScreenDrawer to test ScreenCapturer. Besides test
cases, some other changes are included,
1. A WaitForPendingPaintings() function in ScreenDrawer, to wait for a
ScreenDrawer to finish all the pending draws. This function now only sleeps 50
milliseconds on X11 and 100 milliseconds on Windows.
2. A Color structure to help handle a big-endian or little-endian safe color and
provide functions to compare with DesktopFrame::data(). Both ScreenDrawer and
DesktopFrameGenerator (in change 2202443002) can use this class to create colors
and compare with or paint to a DesktopFrame.
3. ScreenDrawer now uses Color structure instead of uint32_t.
BUG=314516
TBR=kjellander@chromium.org
Review-Url: https://codereview.webrtc.org/2268093002
Cr-Commit-Position: refs/heads/master@{#14058}
This test failed on the memcheck bot:
https://build.chromium.org/p/client.webrtc/builders/Linux%20Memcheck/builds/6704/steps/video_engine_tests/logs/stdio
The test assumed that the absolute send time header extension can never
be zero. It's a timestamp truncated to 24 bits, and zero is not a
special value - so it can very rarely end up being precisely zero.
The fix makes the test wait for at least one packet having a non-zero send time.
I've considered changing the test to use a fake clock instead to ensure
that not only the value is non-zero, but that it indeed reflects the
system timestamp - but that involves changing a very large number of
files. Besides, other tests in this file don't verify values for header
extensions where zeroes are allowed.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2307693002
Cr-Commit-Position: refs/heads/master@{#14056}
ParsedRtcEventLog::ParseStream was using a stack-allocated 64kb array
for a temporary buffer. This was causing problems in build environments
with restrictions on stack size.
This change replaces it with an std::vector.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2297343003
Cr-Commit-Position: refs/heads/master@{#14055}
The helpers intended to replace and deprecate BuildRtpHeader when
RtpSenderAudio/RtpSenderVideo will be updated to pass RtpPacket class
instead of raw buffer for sending.
BUG=webrtc:5261
R=sprang@webrtc.org
Review URL: https://codereview.webrtc.org/2303283002 .
Cr-Commit-Position: refs/heads/master@{#14051}
Remove //build/config/sanitizers:deps as a dependency for
all rtc_executable targets and add it to the template instead.
BUG=webrtc:6187
NOTRY=True
Review-Url: https://codereview.webrtc.org/2308553002
Cr-Commit-Position: refs/heads/master@{#14048}
- Check that no target references sources with paths above the GN file location.
- Chcek that no target depends on rtc_base.
BUG=webrtc:6294
NOTRY=True
Review-Url: https://codereview.webrtc.org/2304883002
Cr-Commit-Position: refs/heads/master@{#14046}
Defines the rtc_executable, rtc_source_set, rtc_test and
rtc_static_library templates.
These templates provide no functionality yet, but will enable common
configuration to be introduced, avoiding repetition in every target
Changes summary:
- Prepend rtc_ to test, source_set, executable and static_library targets
- Change "configs -= [" to "suppressed_configs += ["
- Include webrtc/build/webrtc.gni where it wasn't included yet
- Delete import("//testing/test.gni"), since rtc_test makes it unnecessary.
BUG=webrtc:6187
TBR=henrik.lundin@webrtc.org,tommi@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2301053002
Cr-Commit-Position: refs/heads/master@{#14043}
Reason for revert:
Reland this now that downstream tests have been fixed.
Original issue's description:
> Revert of Add pps id and sps id parsing to the h.264 depacketizer. (patchset #5 id:80001 of https://codereview.webrtc.org/2238253002/ )
>
> Reason for revert:
> Breaks some h264 bitstream tests downstream. Reverting for now.
>
> Original issue's description:
> > Add pps id and sps id parsing to the h.264 depacketizer.
> >
> > BUG=webrtc:6208
> >
> > Committed: https://crrev.com/abcc3de169d8896ad60e920e5677600fb3d40180
> > Cr-Commit-Position: refs/heads/master@{#13838}
>
> TBR=sprang@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:6208
>
> Committed: https://crrev.com/83d79cd4a2bfbdd1abc1f75480488df4446f5fe0
> Cr-Commit-Position: refs/heads/master@{#13844}
TBR=sprang@webrtc.org,kjellander@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6208
Review-Url: https://codereview.webrtc.org/2302893002
Cr-Commit-Position: refs/heads/master@{#14042}
- Remove webrtc/tools/agc/test_utils.cc/.h - only used from the above test.
- Remove webrtc/tools/agc/agc_harness.cc - not used anymore.
BUG=webrtc:4690
Review-Url: https://codereview.webrtc.org/2299023004
Cr-Commit-Position: refs/heads/master@{#14039}
These methods are not used by the new AndroidVideoTrackSource API.
Review-Url: https://codereview.webrtc.org/2280873002
Cr-Commit-Position: refs/heads/master@{#14036}
Reason for revert:
Breaks downstream build.
Original issue's description:
> Ignore Camera and Flip bits in CVO when parsing video rotation
>
> Currently, if WebRTC receives a CVO byte where the Camera or Flip bit is
> set, then rotation is incorrectly parsed as 0. This CL fixes that issue.
> The Camera and Flip bit is still unimplemented and will just be ignored
> though.
>
> BUG=webrtc:6120
> R=danilchap@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
>
> Committed: f9e1b922efTBR=pthatcher@webrtc.org,danilchap@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:6120
Review-Url: https://codereview.webrtc.org/2300323002
Cr-Commit-Position: refs/heads/master@{#14035}
The sample uses are from when I debugged bug 617124. The change in neteq_network_stats_unittest.cc is a fix for a minor unrelated bug found by the try bots when I tried to land this CL (a test was passing uninitialized packet data to NetEq).
BUG=chromium:617124
Review-Url: https://codereview.webrtc.org/2293893002
Cr-Commit-Position: refs/heads/master@{#14034}
If a CNG packet is received first, followed by a speech packet with
another sample rate, NetEq should treat this as a change of codec, flush
out the CNG packet and reset the sample rate to that of the speech
packet.
BUG=webrtc:5447
NOTRY=True
Review-Url: https://codereview.webrtc.org/2307493002
Cr-Commit-Position: refs/heads/master@{#14032}
run it is important that the same build flags are used in the code being
tested. For the debugging functionality inside APM, that was not the case
and this is corrected in this CL.
This CL is chained to the CL https://codereview.webrtc.org/2300813004/
BUG=webrtc:5298
Review-Url: https://codereview.webrtc.org/2307563002
Cr-Commit-Position: refs/heads/master@{#14031}
Currently, if WebRTC receives a CVO byte where the Camera or Flip bit is
set, then rotation is incorrectly parsed as 0. This CL fixes that issue.
The Camera and Flip bit is still unimplemented and will just be ignored
though.
BUG=webrtc:6120
R=danilchap@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2280703002 .
Cr-Commit-Position: refs/heads/master@{#14027}
Currently, the aec_debug_dump buildflag can and is used to store data in the whole of
the audio processing module. Therefore a more appropriate name is apm_debug_dump which
also matches the names of the data dumping functionality. This CL makes that name change.
The CL also changes the WEBRTC_AEC_DEBUG_DUMP define to
WEBRTC_APM_DEBUG_DUMP == 1
Furthermore, this CL moves the buildflag to a more appropriate place.
BUG=webrtc:5298
Review-Url: https://codereview.webrtc.org/2300813004
Cr-Commit-Position: refs/heads/master@{#14026}
WebRTC no longer has any restriction on what thread frames should be
delivered on. One possible problem with this CL is that NV21->I420
conversion and scaling is done on the thread that delivers frames, which
might cause fps regressions.
R=nisse@webrtc.org, perkj@webrtc.org, tkchin@webrtc.org
Review URL: https://codereview.webrtc.org/2137503003 .
Cr-Commit-Position: refs/heads/master@{#14021}
cl was originally reviewed here:
https://codereview.webrtc.org/2060403002/
- Add task queue to Call with the intent of replacing the use of one of the process threads.
- Split VideoSendStream in two. VideoSendStreamInternal is created and used on the new task queue.
- BitrateAllocator is now created on libjingle's worker thread but always used on the new task queue instead of both encoder threads and the process thread.
- VideoEncoderConfig and VideoSendStream::Config support move semantics.
- The encoder thread is moved from VideoSendStream to ViEEncoder. Frames are forwarded directly to ViEEncoder which is responsible for timestamping ? and encoding the frames.
TBR=mflodman@webrtc.org
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2250123002
Cr-Commit-Position: refs/heads/master@{#14014}
Users are updated to call libyuv functions directly. Also delete
related unit tests.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/2287233002
Cr-Commit-Position: refs/heads/master@{#14013}
