This CL removes some temporary files created by OptionsFileTest and
TransientFileUtilsTest.
BUG=
Review URL: https://codereview.webrtc.org/1688553002
Cr-Commit-Position: refs/heads/master@{#11554}
This makes sense since the buffered data is only used by
the echo subtraction method. Furthermore, it simplifies the
upcoming modifications to the echo subtraction method since
the way the buffering is done can then be specific for the
echo subtraction implementation used.
The change is bitexact and this was verified using a fairly
extensive bitexactness suite.
BUG=
Review URL: https://codereview.webrtc.org/1639773002
Cr-Commit-Position: refs/heads/master@{#11547}
In some rare occations (very low energy signal), a shift value happened
to be negative. This is now fixed by using the WEBRTC_SPL_SHIFT_W32,
which in essence checks the sign of the number of shifts and performs a
right or left shift accordingly.
The fix reverts to how the code was written in old NetEq; see
4d363ae305/webrtc/modules/audio_coding/neteq/normal.c (165).
BUG=webrtc:5490
Review URL: https://codereview.webrtc.org/1675293002
Cr-Commit-Position: refs/heads/master@{#11546}
Previously shared memory buffers for DesktopCapturer were created
using DesktopCapturer::Callback::CreateSharedBuffer(). That made it
difficult to proxy DesktopCapturer interface from one thread to another.
This CL adds SharedBufferFactory interface that's allowed to be called
on a background thread. This also simplifies clients that don't
need to use shared memory, as they no longer need to override
CreateSharedBuffer().
Review URL: https://codereview.webrtc.org/1678073003
Cr-Commit-Position: refs/heads/master@{#11543}
This will make it align with protoc tools that use the relative
path from the project root to the files in the output path.
Having this, no hacks will need to be applied downstream.
TBR=henrik.lundin@webrtc.org
NOTRY=True
Review URL: https://codereview.webrtc.org/1673263002
Cr-Commit-Position: refs/heads/master@{#11540}
This pulls in several fixes and gets Visual Studio 2015 support.
The new repo is located at https://github.com/gflags/gflags
which is mirrored in Chrome infrastructure at
https://chromium.googlesource.com/external/github.com/gflags/gflags
New configuration headers were generated according to README.webrtc
on Windows and Linux. I verified the Linux generated ones are working
on Mac. The generating headers on Mac are identical with only a minor
difference (an __unused attribute) that doesn't effect the build.
BUG=webrtc:5185
NOTRY=True
NOPRESUBMIT=True
TESTED=Successfully ran:
out/Release/video_quality_measurement --input_filename=resources/foreman_cif.yuv --width=352 --height=288
to verify flags are still being parsed properly.
I also ran the compile trybots and the baremetal bots
(since they run tests that have gflags flags).
Review URL: https://codereview.webrtc.org/1679263002
Cr-Commit-Position: refs/heads/master@{#11539}
Until the bug has been further investigated, we're limiting the number
of threads to 1 to avoid problems. See crbug.com/583348.
BUG=chromium:500605, chromium:468365, chromium:583348
Review URL: https://codereview.webrtc.org/1677543002
Cr-Commit-Position: refs/heads/master@{#11536}
If a StatisticsCalculator::PeriodicUmaAverage object was created and
then deleted without any samples being logged, the destructor would call
the Metric() method, which calculated sum_/counter_. However, with no
samples logged, counter_ is 0.
This was found and verified using UBSan tests; see the bug for more info.
BUG=webrtc:5490
R=ivoc@webrtc.org
Review URL: https://codereview.webrtc.org/1678773003
Cr-Commit-Position: refs/heads/master@{#11534}
Since the address of the dereference is taken this inputs a garbage
almost-null pointer into RtpPacketizer. Not likely that a load/store is
performed on the address, but UBSan fires and it's a source of potential
future errors.
BUG=webrtc:5124, webrtc:5490
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1677003002 .
Cr-Commit-Position: refs/heads/master@{#11528}
Added accessor and Parse function
removed dependencies on structures from rtcp_utility.h (except RtcpCommonHeader)
removed limitation of 50 items per TMMBN.
BUG=webrtc:5260
R=åsapersson
Review URL: https://codereview.webrtc.org/1670973002
Cr-Commit-Position: refs/heads/master@{#11524}
There were a couple of GN and GYP references that were incorrect in Chromium builds:
- GN references between WebRTC targets must be using relative paths, not absolute.
- GYP references between WebRTC targets must be using the <(webrtc_root)v variable
in order to be expanded to the correct path in a Chromium build.
NOTRY=True
TBR=hjon@webrtc.org, hbos@webrtc.org
Review URL: https://codereview.webrtc.org/1681493002
Cr-Commit-Position: refs/heads/master@{#11521}
Added accessor and Parse function
removed dependencies on structures from rtcp_utility.h (except RtcpCommonHeader)
BUG=webrtc:5260
R=åsapersson
Review URL: https://codereview.webrtc.org/1675583002
Cr-Commit-Position: refs/heads/master@{#11502}
Extracts shared members outside the two objects, removing PayloadRouter
from receivers and the VCM for ViEChannel from senders.
Removes Start/StopThreadsAndSetSharedMembers that was used to set the
shared state between them.
Also adding DCHECKs to document what's only used by the
sender/receiver side.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1654913002 .
Cr-Commit-Position: refs/heads/master@{#11500}
Permits measuring encoding time even when performed on another thread,
typically for hardware encoding, instead of assuming that encoding is
blocking the calling thread.
Permitted encoding time is increased for hardware encoders since they
can be timed to keep 30fps, for instance, without indicating overload.
Merges EncodingTimeObserver into EncodedFrameObserver to have one post-encode
callback.
BUG=webrtc:5042, webrtc:5132
R=asapersson@webrtc.org, mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1569853002 .
Cr-Commit-Position: refs/heads/master@{#11499}
This is needed because the target is defined in webrtc/common.gyp
and its current location crosses package boundaries when generating
projects for some build systems.
NOTRY=True
Review URL: https://codereview.webrtc.org/1665603003
Cr-Commit-Position: refs/heads/master@{#11496}
std::vector<rtcp::TmmbItem> will replace TMMBRSet class for storage, processing and preparing TMBBR/TMMBN
(i.e. this TmmbItem replaces Timber structure introduced in https://codereview.webrtc.org/1474693002 )
Previous structures store bitrate in kbps. TmmbItem use bps removing need to regularly divide and multiply by 1000.
BUG=webrtc:5260
R=åsapersson
Review URL: https://codereview.webrtc.org/1576223003
Cr-Commit-Position: refs/heads/master@{#11491}
active_layer_ could be dereferenced while being -1...
Also added som DCHECKs
BUG=webrtc:5490
Review URL: https://codereview.webrtc.org/1656233002
Cr-Commit-Position: refs/heads/master@{#11486}
Sparse macro is replaced and new implementation in metrics.h is used.
BUG=webrtc:5283
Review URL: https://codereview.webrtc.org/1564923008
Cr-Commit-Position: refs/heads/master@{#11483}
Renamed the WEBRTC_THIRD_PARTY_H264 macro to WEBRTC_USE_H264 to match flag name.
The idea is to be able to turn off H264 from chromium with this function because...
1) The Chromium trybots will soon use this flag, we want to temporarily disable H264 from chromium even if flag is set in case something is broken. That way when we are ready to flip the switch the trybots will run our test code then and not after it is already enabled.
2) If feature is launched and we discover major problems we can easily disable H264 and merge with beta/stable.
3) Or, if feature is behind a *runtime* flag, this is how we would control if it is used or not.
The idea is to call DisableRtcUseH264 in chromium's PeerConnectionDependencyFactory.
BUG=chromium:500605, chromium:468365
NOTRY=True
NOPRESUBMIT=True
Review URL: https://codereview.webrtc.org/1657273002
Cr-Commit-Position: refs/heads/master@{#11474}
Adds negotiation of rtx codecs for red and vp9. To keep backwards
compatibility with older Chrome versions, this change includes two
hacks:
1. Red packets will be retransmitted over the rtx codec associated with
vp8 if no rtx codec is associated with red. This is how Chrome does
it today and ensures that we still can send red over rtx to older
versions.
2. If rtx packets associated with the media codec (vp8/vp9 etc) are
received and red has been negotiated, we will assume that the sender
incorrectly has packetized red inside the rtx header associated with
media. We will therefore restore it with the red payload type
instead, which ensures that we can still receive rtx associated with
red from old versions.
Offering multiple rtx codecs to older versions should not be a problem
since old versions themselves only try to negotiate rtx for vp8.
R=pbos@webrtc.orgTBR=mflodman@webrtc.org
BUG=webrtc:4024
TEST=Verified by running apprtc and emulating packet loss between Chrome with and without the patch.
Review URL: https://codereview.webrtc.org/1649493004 .
Cr-Commit-Position: refs/heads/master@{#11472}
It's generated by some encoders between SPS/PPS and an IDR frame, so we should treat it like sps/pps.
BUG=
Review URL: https://codereview.webrtc.org/1664733002
Cr-Commit-Position: refs/heads/master@{#11470}
* SSRCDatabase doesn't need to be a global instance, so I've changed it to be a "regular" class (i.e. construct via ctor, not maybe via GetSSRCDatabase( + release via ReturnSSRCDatabase())). If we ever have parallel tests running in the same process, they won't have the problem of using the same ssrc database.
* Made RtpSender a more const. Also added some todos for myself and holmer to look into clarifying the threading model.
* Switched from CriticalSectionWrapper to rtc::CriticalSection
* Changed the random seeding to use TickTime::Now().Ticks() since TimeInMicroseconds() could return 0 when the process was starting. This is what TimeInMicroseconds() does anyway but now we don't need to access a global clock object.
BUG=webrtc:3062
Review URL: https://codereview.webrtc.org/1623543002
Cr-Commit-Position: refs/heads/master@{#11462}
New flag: rtc_initialize_ffmpeg, default value = !build_with_chromium.
In WebRTC standalone we initialize FFmpeg by default, in Chromium we don't by default.
Chromium is an external project that also use FFmpeg. If both projects do FFmpeg initialization code things will break. The flag makes it possible for other external projects than chromium to decide whether or not WebRTC should initialize FFmpeg.
BUG=chromium:500605, chromium:468365, webrtc:5427
Review URL: https://codereview.webrtc.org/1639273002
Cr-Commit-Position: refs/heads/master@{#11456}
Some WebRTC client had a problem with the change "Removing webrtc::AudioFrame::energy_". Now it is solved.
This reverts commit 2bdcfadc8abd418a30dd5cdf54ba45a429d3d9bf.
BUG=webrtc:3315
Review URL: https://codereview.webrtc.org/1638553003
Cr-Commit-Position: refs/heads/master@{#11448}
This makes it possible to handle send and receive streams with the same SSRC, which is currently the case in some peer connection tests.
Also moves sending transport feedback to the pacer thread.
BUG=webrtc:5263
Review URL: https://codereview.webrtc.org/1628683002
Cr-Commit-Position: refs/heads/master@{#11443}
Visual Studio 2015 balks at the implicit truncation of values. Easily fixed with an explicit cast.
Fixed redefinition of CLOCKS_PER_SEC when using Visual Studio 2015 and the Windows 10 SDK. CLOCKS_PER_SEC is also defined in "<WIN10 SDK DIR>\include\10.0.10240.0\ucrt\time.h" and also has the value of 1000
Hiding snprintf definition if building with Visual Studio 2015
Fixed C4573 compiler complaint in audio_processing_impl_locking_unittest.cc.
BUG=webrtc:5183
Review URL: https://codereview.webrtc.org/1412653006
Cr-Commit-Position: refs/heads/master@{#11434}
This argument is never used as a reference and the pointer that's bound
to the const reference may be nullptr. This is undefined behavior and
barks under UBSan.
BUG=webrtc:5124
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1642863003 .
Cr-Commit-Position: refs/heads/master@{#11418}
The level of the error signal after linear echo cancellation was based on non-buffered signal while that of the near-end and far-end signal based on buffered signal. This discrepancy made the comparison of them unfair.
This CL is to make calculating the error level rely on the same buffering.
BUG=
Review URL: https://codereview.webrtc.org/1510873004
Cr-Commit-Position: refs/heads/master@{#11408}
SetRtpState function was updating only rtp_sender start timestamp.
Now it updates both rtp_sender and rtcp_sender start timestamps.
BUG=webrtc:5433
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1628323003 .
Cr-Commit-Position: refs/heads/master@{#11393}
It works on all platforms except Android and iOS (FFmpeg limitation).
Implemented behind compile time flags, off by default.
The plan is to have it enabled in Chrome (see bug), but not in Chromium/webrtc by default.
Flags to turn it on:
- rtc_use_h264 = true
- ffmpeg_branding = "Chrome" (or other brand that includes H.264 decoder)
Tests using H264:
- video_loopback --codec=H264
- screenshare_loopback --codec=H264
- video_engine_tests (EndToEndTest.SendsAndReceivesH264)
NOTRY=True
BUG=500605, 468365
BUG=https://bugs.chromium.org/p/webrtc/issues/detail?id=5424
Review URL: https://codereview.webrtc.org/1306813009
Cr-Commit-Position: refs/heads/master@{#11390}
