This CL makes PeerConnectionFactory.createVideoSource() and nativeCreateVideoSource work directly with VideoCapturerAndroid instead of going via VideoCapturer. The native part is now created in nativeCreateVideoSource() instead of doing it immediately in VideoCapturerAndroid.create().
BUG=webrtc:5519
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/1684403002 .
Cr-Commit-Position: refs/heads/master@{#11582}
This reverts "iOS: Add mb_type config for GYP builders."
and also removes Goma from these builders, as it will not work for WebRTC
since MB's GYP mode is hardcoded to use gyp_chromium.
MB should be working for GN since it's a stand-alone tool.
Goma doesn't work since $(goma_dir) in the JSON throws an error during
compile. So let's turn off Goma for these bots for now.
BUG=chromium:498746
NOTRY=True
TBR=smut@google.com
Review URL: https://codereview.webrtc.org/1685683007
Cr-Commit-Position: refs/heads/master@{#11578}
The PRESUBMIT code is basically a stripped-down copy of the code in
Chromium's src/PRESUBMIT.py.
BUG=chromium:498746
TESTED=I verified with 'git cl presubmit' that the existing
error was found. Then I ran it again after fixing it, with
presubmit passing.
NOTRY=True
Review URL: https://codereview.webrtc.org/1682393002
Cr-Commit-Position: refs/heads/master@{#11572}
Both were related to very large jumps in RTP timestamps.
BUG=webrtc:5488
Review URL: https://codereview.webrtc.org/1685103002
Cr-Commit-Position: refs/heads/master@{#11569}
Reason for revert:
Needs to revert again unfortunately.
There are multiple implementations in Chrome of cricket::VideoCapturer.
One is ./../remoting/protocol/webrtc_video_capturer_adapter.cc...
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/9581/steps/compile/logs/stdio
Fun times - I will have to modify this cl after trying it manually out in Chrome.
Original issue's description:
> This cl introduce a VideoSourceInterface and let cricket::VideoCapturer implement it.
> Further more, it adds a VideoBroadcaster than is used for delivering frames to multiple sinks.
>
> BUG=webrtc:5426
> R=nisse@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/4d19c5b010473615fa181afa84c6f4b3104e3171
> Cr-Commit-Position: refs/heads/master@{#11567}
TBR=pthatcher@google.com,nisse@webrtc.org,pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1690893002
Cr-Commit-Position: refs/heads/master@{#11568}
Reason for revert:
There appears there were some uses left of cricket::VideoFrame::GetRotation (to be replaced by GetVideoRotation). Investigating.
Original issue's description:
> Initial cleanup of cricket::VideoFrame.
>
> Deleted GetRotation (old alias for GetVideoRotation).
> Deleted CopyToBuffer.
> Deleted Sizeof.
> Deleted Write.
> Demote CopyToPlanes to protected status.
>
> BUG=webrtc:5426
TBR=perkj@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,pthatcher@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1688953003
Cr-Commit-Position: refs/heads/master@{#11566}
Reason for revert:
Somehow breaks Chromium FYI....
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Win%20Builder/builds/3483/steps/compile/logs/stdio
Original issue's description:
> This cl introduce a VideoSourceInterface and let cricket::VideoCapturer implement it.
> Further more, it adds a VideoBroadcaster than is used for delivering frames to multiple sinks.
>
>
> BUG=webrtc:5426
TBR=pthatcher@google.com,nisse@webrtc.org,pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1687273002
Cr-Commit-Position: refs/heads/master@{#11565}
Further more, it adds a VideoBroadcaster than is used for delivering frames to multiple sinks.
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1655793003
Cr-Commit-Position: refs/heads/master@{#11563}
adding 30% drift to media generator (e.g. audio frame generated every 7ms instead of promised 10ms) works fine
adding 2% drift to video ntp-timestamp-stamper makes A/V sync fail.
BUG=webrtc:5504
R=pbos@webrtc.org,stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1674413004
Cr-Commit-Position: refs/heads/master@{#11556}
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}
In addition to the code moved from talk/app/webrtc
there were some files in webrtc/api/objctests that still
had the libjingle license header.
BUG=webrtc:5418
TBR=tkchin@webrtc.org
NOTRY=True
Review URL: https://codereview.webrtc.org/1680293005
Cr-Commit-Position: refs/heads/master@{#11552}
More work remains, but is less urgent.
webrtc/media/base/mediacommon.h could not be deleted since
the constants are used in multiple places.
BUG=webrtc:5420
TBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1688753002 .
Cr-Commit-Position: refs/heads/master@{#11551}
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}
The previously disabled warnings that were inherited from
talk/build/common.gypi are now replaced by target-specific disabling
of only the failing warnings. Additional disabling was needed since the stricter
compilation warnings that applies to code in webrtc/.
License headers will be updated in a follow-up CL.
Other modifications:
* Updated the header guards.
* Sorted the includes using chromium/src/tools/sort-headers.py
except for these files:
talk/app/webrtc/peerconnectionendtoend_unittest.cc
talk/app/webrtc/java/jni/androidmediadecoder_jni.cc
talk/app/webrtc/java/jni/androidmediaencoder_jni.cc
webrtc/media/devices/win32devicemanager.cc
The HAVE_SCTP define was added for the peerconnection_unittests target
in api_tests.gyp.
I also checked that none of
SRTP_RELATIVE_PATH
HAVE_SRTP
HAVE_WEBRTC_VIDEO
HAVE_WEBRTC_VOICE
were used by the talk/app/webrtc code.
For Chromium, the following changes will need to be applied to the roll CL that updates the
DEPS for WebRTC and libjingle:
https://codereview.chromium.org/1615433002
BUG=webrtc:5418
NOPRESUBMIT=True
R=deadbeef@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1610243002 .
Cr-Commit-Position: refs/heads/master@{#11545}
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}
This CL adds thread annotations to FifoBuffer and adds a missing CritScope
for attribute access that is modified in locked code paths.
Review URL: https://codereview.webrtc.org/1677333002
Cr-Commit-Position: refs/heads/master@{#11535}
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}
This CL adds new fuzzer tests for the DecodeRedundant and
IncomingPacket methods of AudioDecoder. In practice, only Opus has
DecodeRedundant, and only iSAC has IncomingPacket. Did some minor work
to generalize the helper function reading values from the fuzzed
input.
BUG=webrtc:5306
R=pbos@webrtc.org
NOTRY=true
Review URL: https://codereview.webrtc.org/1607173003
Cr-Commit-Position: refs/heads/master@{#11533}
Reason for revert:
I've decided to not aim for implementing analyze and focus on getting Swarming done instead, so I'm cleaning this up.
Original issue's description:
> Analyze support in gyp_webrtc
>
> BUG=chromium:482463
> TESTED=Manually tested using the JSON files attached to https://code.google.com/p/chromium/issues/detail?id=482463#c2 and:
> webrtc/build/gyp_webrtc --analyzer nothing-files.json nothing-files-RESULT.json
> webrtc/build/gyp_webrtc --analyzer everything-files.json everything-files-RESULT.json
> webrtc/build/gyp_webrtc --analyzer test_support_unittests-files.json test_support_unittests-files-RESULT.json
> Then I verified the result-json contained the expected output.
>
> R=phoglund@webrtc.org
>
> Committed: https://crrev.com/8108764552e20d657c0a6f75a6200b93de486659
> Cr-Commit-Position: refs/heads/master@{#10097}
TBR=phoglund@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:482463
Review URL: https://codereview.webrtc.org/1681023003
Cr-Commit-Position: refs/heads/master@{#11532}
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}
Remove hops into ViEChannel for calls directly into RtpRtcp and
ViEReceiver from VideoReceiveStream.
Some calls are more complex and will be removed later.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1671893002 .
Cr-Commit-Position: refs/heads/master@{#11526}
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}
if not on Android/iOS.
This is a re-land of https://codereview.webrtc.org/1674103002/.
The reason Chromium FYI turned red was due to deps not
being relative. See kjellander's CL:
https://codereview.webrtc.org/1681493002/.
This means proprietary_codecs=1 && ffmpeg_branding=Chrome
can be used to enable this H.264 enc/dec implementation
instead of rtc_use_h264=1 && ffmpeg_branding=Chrome.
This is used by both Chromium trybots (but not default
Chromium build) and offical Chrome build, meaning we will
be able to test and enable H.264 in chromium.
This change would otherwise be enough to launch this
feature in Chrome, but because we do not want to do that
before we have chromium browser tests and are ready to flip
the switch, this CL prevents chromium from using H.264 just
yet: https://codereview.chromium.org/1641163002/ (landing
this after that CL).
Third time's the charm?
TBR=kjellander@webrtc.org
BUG=chromium:500605, chromium:468365
Review URL: https://codereview.webrtc.org/1675143003
Cr-Commit-Position: refs/heads/master@{#11523}
