With this change the following tests have been successfully
passing in the iOS Simulator for iPhone 5 and iOS 9:
* audio_decoder_unittests
* common_video_unittests
* modules_tests
* rtc_api_objc_tests
* rtc_pc_unittests
* system_wrappers_unittests
* voice_engine_unittests
The modules_unittests and common_audio_unittests are
handled in https://codereview.webrtc.org/1698033002/
BUG=webrtc:4755
NOTRY=True
Review URL: https://codereview.webrtc.org/1694353003
Cr-Commit-Position: refs/heads/master@{#11646}
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}
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}
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}
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}
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}
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}
Issue may occur for very small input images (e.g. 4x4) when encoded image length > input image size.
BUG=chromium:571594
Review URL: https://codereview.webrtc.org/1626373002
Cr-Commit-Position: refs/heads/master@{#11376}
Removes use of global VP8EncoderFactory::use_simulcast_adapter which is
thread-unsafe. Also the code wasn't in use.
BUG=
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1598803005 .
Cr-Commit-Position: refs/heads/master@{#11370}
The FFmpeg video decoder requires up to 8 additional bytes to be allocated for its encoded image buffer input, due to optimized byte readers over-reading on some platforms.
We plan to use FFmpeg for a soon-to-land H.264 enc/dec.
This CL adds support for padding encoded image buffers based on codec type, and makes sure calls to VCMEncodedFrame::VerifyAndAllocate use the padding.
All padding constants are 0 but making H.264 pad with 8 bytes will be a one-line change.
Also, added -framework CoreFoundation to webrtc_h264_video_toolbox which was missing.
BUG=chromium:468365
BUG=https://bugs.chromium.org/p/webrtc/issues/detail?id=5424
NOTRY=True
Review URL: https://codereview.webrtc.org/1602523004
Cr-Commit-Position: refs/heads/master@{#11337}
Issue may occur for very small input images (e.g. 4x4) when encoded image length > input image size.
BUG=chromium:578193
Review URL: https://codereview.webrtc.org/1603643006
Cr-Commit-Position: refs/heads/master@{#11329}
Provides a better string (provides names of all implementations), but
also fixes a crash when accessing the ImplementationName() of
SimulcastEncoderAdapter where InitEncode has failed.
BUG=chromium:577932, webrtc:4897
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1599353003 .
Cr-Commit-Position: refs/heads/master@{#11321}
Constructing default options is racy when initializing multiple VP8
encoders in parallel. This is only used for VP8 temporal layers. Adding
TemporalLayerFactory to VP8 codec specifics instead of generic options.
Removes the last webrtc::Config uses/includes from video code.
Also removes VideoCodec equality operators which are no longer in use.
BUG=webrtc:5410
R=stefan@webrtc.orgTBR=mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1606613003 .
Cr-Commit-Position: refs/heads/master@{#11307}
Reason for revert:
Reverting due to problem with roll:
/b/build/slave/linux/build/src/buildtools/linux64/gn gen //out/Release '--args=ffmpeg_branding="Chrome" proprietary_codecs=true is_debug=false is_component_build=false use_goma=true goma_dir="/b/build/goma" symbol_level=1 dcheck_always_on=true' --check --runtime-deps-list-file=/b/build/slave/linux/build/src/out/Release/runtime_deps
-> returned 1
ERROR at //third_party/webrtc/BUILD.gn:245:18: Item not found
configs -= [ "//build/config/clang:find_bad_constructs" ]
^-----------------------------------------
You were trying to remove "//build/config/clang:find_bad_constructs"
from the list but it wasn't there.
GN gen failed: 1
step returned non-zero exit code: 1
@@@STEP_FAILURE@@@
Original issue's description:
> Use an explicit identifier in Config
>
> This let's us use them to configure them when using WebRTC as an external library. One use case where this is necessary is in the Android OS.
>
> Committed: https://crrev.com/25249d92d3cf105bcc7b684c8924ccdbc9afcb93
> Cr-Commit-Position: refs/heads/master@{#11231}
TBR=henrik.lundin@webrtc.org,stefan@webrtc.org,tommi@chromium.org,aluebs@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.webrtc.org/1586563003
Cr-Commit-Position: refs/heads/master@{#11239}
This let's us use them to configure them when using WebRTC as an external library. One use case where this is necessary is in the Android OS.
Review URL: https://codereview.webrtc.org/1538643004
Cr-Commit-Position: refs/heads/master@{#11231}
Tests were failing on android with new libvpx.
vp9 speed setting was changed to 8 recently and some recent changes
in libvpx require update for the tests to pass.
TBR=stefan@webrtc.org
BUG=webrtc:5401
Review URL: https://codereview.webrtc.org/1569903002 .
Cr-Commit-Position: refs/heads/master@{#11173}
Macro incorrectly displays DISABLED_ON_ANDROID in test names for
parameterized tests under --gtest_list_tests, causing tests to be
disabled on all platforms since they contain the DISABLED_ prefix rather
than their expanded variants.
This expands the macro variants to inline if they're disabled or not,
and removes building some tests under configurations where they should
fail, instead of building them but disabling them by default.
The change also removes gtest_disable.h as an unused include from many
other files.
BUG=webrtc:5387, webrtc:5400
R=kjellander@webrtc.org, phoglund@webrtc.orgTBR=henrik.lundin@webrtc.org
Review URL: https://codereview.webrtc.org/1547343002 .
Cr-Commit-Position: refs/heads/master@{#11150}
At speed 8, vp9 on ARM is currently ~2x times slower than vp8 on ARM (speed -12).
Update some parameters in videoprocessor_integrationtest.cc
to make tests pass on android (which uses the new speed setting).
TBR=stefan@webrtc.org
BUG=
Review URL: https://codereview.webrtc.org/1526973004 .
Cr-Commit-Position: refs/heads/master@{#11072}
Specify kf_min_dist to get correct key frame interval in svc mode.
Also set QP-max/min per temporal and spatial layer (was previously only allowed to be set per spatial layer).
BUG=chromium:500602
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1492633005 .
Cr-Commit-Position: refs/heads/master@{#10890}
The callback keeps a reference to an object until the callback goes out of scope.
Review URL: https://codereview.webrtc.org/1487493002
Cr-Commit-Position: refs/heads/master@{#10847}
This makes it clearer this code not meant to be used as an API.
I could not find any use of this in downstream code.
BUG=webrtc:5095
TESTED=git cl try -c --bot=android_compile_rel --bot=linux_compile_rel --bot=win_compile_rel --bot=mac_compile_rel --bot=ios_rel --bot=linux_gn_rel --bot=win_x64_gn_rel --bot=mac_x64_gn_rel --bot=android_gn_rel -m tryserver.webrtc
R=stefan@webrtc.orgTBR=magjed@webrtc.org
Review URL: https://codereview.webrtc.org/1440873005 .
Cr-Commit-Position: refs/heads/master@{#10699}
The main purpose was the interface-> include rename, but other files
were also moved, eliminating the "main" dir.
To avoid breaking downstream, the "interface" directories were copied
into a new "video_coding/include" dir. The old headers got pragma
warnings added about deprecation (a very short deprecation since I plan
to remove them as soon downstream is updated).
Other files also moved:
video_coding/main/source -> video_coding
video_coding/main/test -> video_coding/test
BUG=webrtc:5095
TESTED=Passing compile-trybots with --clobber flag:
git cl try --clobber --bot=win_compile_rel --bot=linux_compile_rel --bot=android_compile_rel --bot=mac_compile_rel --bot=ios_rel --bot=linux_gn_rel --bot=win_x64_gn_rel --bot=mac_x64_gn_rel --bot=android_gn_rel -m tryserver.webrtc
R=stefan@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1417283007 .
Cr-Commit-Position: refs/heads/master@{#10694}
Removes VP8::Encode trace in favor of VCMGenericEncoder ones and adds
one to InitEncode. Also adds an instant event to ::Encoded since this
can be done on a different thread.
Also adds the corresponding traces to VCMGenericDecoder.
BUG=webrtc:5167
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1412573010
Cr-Commit-Position: refs/heads/master@{#10674}
To avoid breaking downstream, the "interface" directories were copied
into a new "common_video/include" dir. The old headers got pragma
warnings added about deprecation (a very short deprecation since I plan
to remove them as soon downstream is updated).
The header guards are also identical to avoid mixing them up in the transition.
BUG=webrtc:5095
TESTED=Passing compile-trybots with --clobber flag:
git cl try --clobber --bot=win_compile_rel --bot=linux_compile_rel --bot=android_compile_rel --bot=mac_compile_rel --bot=ios_rel --bot=linux_gn_rel --bot=win_x64_gn_rel --bot=mac_x64_gn_rel --bot=android_gn_rel -m tryserver.webrtc
Review URL: https://codereview.webrtc.org/1418913006
Cr-Commit-Position: refs/heads/master@{#10659}
Reason for revert:
Failed test not related to this CL (test fails on
master at an earlier date), re-landing original CL..
(This time from my @webrtc account.)
Original issue's description:
> Revert of Work on flexible mode and screen sharing. (patchset #28 id:520001 of https://codereview.webrtc.org/1328113004/ )
>
> Reason for revert:
> Seems to break VideoSendStreamTest.ReconfigureBitratesSetsEncoderBitratesCorrectly on Linux Memcheck buildbot.
>
> Original issue's description:
> > Work on flexible mode and screen sharing.
> >
> > Implement VP8 style screensharing but with spatial layers.
> > Implement flexible mode.
> >
> > Files from other patches:
> > generic_encoder.cc
> > layer_filtering_transport.cc
> >
> > BUG=webrtc:4914
> >
> > Committed: https://crrev.com/77ccfb4d16c148e61a316746bb5d9705e8b39f4a
> > Cr-Commit-Position: refs/heads/master@{#10572}
>
> TBR=sprang@webrtc.org,stefan@webrtc.org,philipel@google.com,asapersson@webrtc.org,mflodman@webrtc.org,philipel@webrtc.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:4914
>
> Committed: https://crrev.com/0be8f1d347bdb171462df89c2a4c69b3f3eb7519
> Cr-Commit-Position: refs/heads/master@{#10578}
TBR=sprang@webrtc.org,stefan@webrtc.org,philipel@google.com,asapersson@webrtc.org,mflodman@webrtc.org,terelius@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4914
Review URL: https://codereview.webrtc.org/1431283002
Cr-Commit-Position: refs/heads/master@{#10581}
On Android, we would like to use MediaCodec output buffers to hold decoded frames until they can be rendered to a texture. There can only be one texture buffer used at the same time and therefore the calculated decode time in VCMTiming will be wrong since that calculation will also include the time where the decoder waited for the upper layers (that depend on network jitter and actual render time) to release the frame.
This new method will be used in
https://codereview.webrtc.org/1422963003/
BUG=webrtc:4993
R=stefan@webrtc.orgTBR=mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1414693006 .
Cr-Commit-Position: refs/heads/master@{#10576}
