The functions were essentially no-op. Also removing forward declaration
of ACMDTMFDetection, which was not used.
BUG=3520
Review URL: https://codereview.webrtc.org/1356543003
Cr-Commit-Position: refs/heads/master@{#9982}
This is a small utility that reads RtcEventLog files, and converts the RTP headers within it to RtpDump format. All other types of events are ignored. Three command-line flags are supported, --audio-only, --video-only and --data-only. When one of these flags is supplied, only RTP packets that match the requested type are converted.
BUG=webrtc:4741
R=henrik.lundin@webrtc.org, kjellander@webrtc.org, stefan@webrtc.org, terelius@webrtc.org
Review URL: https://codereview.webrtc.org/1297653002 .
Cr-Commit-Position: refs/heads/master@{#9980}
Starts by removing channel/engine id from ViEChannel which propagates
down to the RTP/RTCP module as well as the transport class.
IncomingVideoStream::RenderFrame() is untouched for now but receives a
fake id instead of the previous channel id. Added a TODO to remove it
later but the RenderFrame call is implemented in a lot of
platform-dependent files and should probably remove the "manager" aspect
of renderers, so preferring to do it separately
BUG=webrtc:1695
R=henrika@webrtc.org, mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1335353005 .
Cr-Commit-Position: refs/heads/master@{#9978}
that we can open up audio in communication mode also on older
devices that only supports it in combination with 16kHz.
BUG=webrtc:4756
R=magjed@webrtc.org
Review URL: https://codereview.webrtc.org/1347243003 .
Cr-Commit-Position: refs/heads/master@{#9971}
The baremetal machines rarely catch any issues that are caught
by the other bots and are currently the bottleneck of the CQ.
Since they still run in client.webrtc and there also produces
perf data, I think it makes sense to exclude them from the CQ.
It is still possible to run tryjobs on them using:
git try --bot=linux_baremetal --bot=win_baremetal --bot=mac_baremetal
R=phoglund@webrtc.org
Review URL: https://codereview.webrtc.org/1349013004 .
Cr-Commit-Position: refs/heads/master@{#9970}
Refactoring full stack, video and screenshare tests to use the same code basis
for parametrization and initialization. This patch is done on top of recently
commited full stack graphs CL https://codereview.webrtc.org/1289933003/, but
virtually no changes have been made to full_stack_plot.py nor to the VideoAnalyzer
in full stack, except moving it to video_quality_test.cc.
Also, full_stack_samples.cc (build target) was removed and replaced with
-output_filename and -duration cmdline arguments in video_loopback and
screenshare_loopback.
The important things to review:
- video_quality_test.h
Is the structure of Params good? (examples of usage can be found in
full_stack.cc, video_loopback.cc and screenshare_loopback.cc)
- video_quality_test.cc
Is the initialization correct? The case for using Analyzer and using local
renderer are different, can they be further merged?
- webrtc_tests.gypi
Reproducing the different bitrate settings the full stack and loopback tests had
was a little bit tricky. To support both simultaneously, I added BitrateConfig
to the Params struct, as well as separate start_bitrate and target_bitrate flags
for loopback tests.
Note: Side-by-side diff for video_quality_test.cc compares that file directly
with the old full_stack.cc, so changes to VideoAnalyzer are clearly visible.
Note: Recent CL I've committed added -num_temporal_layers and -sl_discard_threshold
args to loopback tests. This was removed here. Support for streams and SVC
will be added in a CL following this one.
Review URL: https://codereview.webrtc.org/1308403003
Cr-Commit-Position: refs/heads/master@{#9969}
WebRtcPassthroughRender has been dead since webrtcvideoengine.cc was
removed, FakeExternalTransport has probably been unused for a long time.
BUG=webrtc:1695
R=henrika@webrtc.org
Review URL: https://codereview.webrtc.org/1343393003 .
Cr-Commit-Position: refs/heads/master@{#9968}
The unit test currently works as follows:
RtxLoopBackTransport logs the sequence numbers for all sent packets in expected_sequence_numbers_. Since the transport is configured to drop some of the packets there will be requests for retransmissions and the RTX sequence numbers will also be stored in the same list.
The (non-rtx) packets are received by VerifyingRtxReceiver which also stores the sequence numbers in a list sequence_numbers_. Both lists are then sorted and sequence_numbers_ is compared to whatever is in the start of expected_sequence_numbers_.
This works assuming that the RTX sequence numbers are greater than the regular RTP sequence numbers. In the RTP sender, both RTP and RTX are set to start at "random" 15-bit sequence numbers. The RTP sequence number is then changed to 2345 in the unit test, which would imply that the RTX sequence number is lower than the ones for RTP with probability ~1%. The reason why the test works anyway is that the test sets up a fake clock, which is used to initialize the random number generator in RTPSender, and the fixed starting point for the clock happens to result in RTX sequence numbers greater than 2345. However, any change to the initialization of the sequence numbers, the seeding of the PRNG or the fake clock causes a test failure with probability ~1%.
The new code omits the RTX sequence numbers from expected_sequence_numbers_, thus avoiding the problem with low RTX sequence numbers. The initialization of the sequence numbers in RTPSender is also bad, but I'll fix that in another CL.
Review URL: https://codereview.webrtc.org/1263383002
Cr-Commit-Position: refs/heads/master@{#9967}
All AudioDecoder subclasses have historically lived in NetEq, but they
fit better with the codec they wrap.
BUG=webrtc:4557
Review URL: https://codereview.webrtc.org/1346993002
Cr-Commit-Position: refs/heads/master@{#9966}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
The WebKit dependency could be removed again after
https://codereview.chromium.org/1338193003/
Relevant changes:
* src/buildtools: 565d04e..f7310ee
* src/third_party/boringssl/src: ac8302a..1d128f3
* src/third_party/libvpx: 0304cef..ac1772e
* src/third_party/libyuv: 0bc626a..fcacbfb
* src/third_party/mockito/src: ed99a52..4d987dc
* src/tools/swarming_client: 2866a22..77f720b
Details: 5482f56..310ea93/DEPS
Clang version was not updated in this roll.
TBR=marpan@webrtc.org
Review URL: https://codereview.webrtc.org/1347153003 .
Cr-Commit-Position: refs/heads/master@{#9962}
All AudioDecoder subclasses have historically lived in NetEq, but they
fit better with the codec they wrap.
BUG=webrtc:4557
Review URL: https://codereview.webrtc.org/1348053002
Cr-Commit-Position: refs/heads/master@{#9961}
Recent changes (https://codereview.chromium.org/1311013010) introduces a
dependency on WebKit (Blink) in Chromium, which forces us to start pulling
down that as well (+6GB). However Blink is about to be merged into the
Chromium repo soon anyway, so the size increase is inevitable.
Luckily, this can be removed in the next roll, if we roll past
http://crrev.com/348812
The ijar dependency was introduced in https://codereview.chromium.org/1323053003 (#347208)
Relevant changes:
* src/third_party/boringssl/src: 12fe1b2..ac8302a
* src/third_party/libvpx: a208eca..0304cef
* src/third_party/libyuv: 3c4f573..0bc626a
* src/tools/gyp: 6ee91ad..5d01a8c
Details: a28d8d5..5482f56/DEPS
Clang version was not updated in this roll.
R=torbjorng@webrtc.orgTBR=marpan@webrtc.org
BUG=webrtc:5005, chromium:530112
Review URL: https://codereview.webrtc.org/1305043008 .
Cr-Commit-Position: refs/heads/master@{#9956}
Part of work removing dependency on Chromium's base.
Only adds "= delete". From https://codereview.chromium.org/1151443003 :
"This will guarantee the error to be at compile time, and not rely on the call visibility (private)."
In consequence of that change, fixed an illegal copy and removed a bunch of unused variables.
Depends on https://codereview.webrtc.org/1345433002/
BUG=chromium:468375
(in particular comment #37)
NOTRY=true
Review URL: https://codereview.webrtc.org/1342543004
Cr-Commit-Position: refs/heads/master@{#9954}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
* DISALLOW_ASSIGN -> RTC_DISALLOW_ASSIGN
* DISALLOW_COPY_AND_ASSIGN -> RTC_DISALLOW_COPY_AND_ASSIGN
* DISALLOW_IMPLICIT_CONSTRUCTORS -> RTC_DISALLOW_IMPLICIT_CONSTRUCTORS
Related CL: https://codereview.webrtc.org/1335923002/
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1345433002
Cr-Commit-Position: refs/heads/master@{#9953}
When GYP runs for OS=android it doesn't generate the
video_engine_core_unittests_apk_target target which is needed to
get the APK built.
The same problem applies to webrtc/test/webrtc_test_common.gyp,
but that unittest is not added on any bot anyway, so that's future work.
TESTED=Ran webrtc/build/gyp_webrtc for Linux and Android locally.
Before this patch, the video_engine_core_unittests was not built
as part of the 'All' target. With this patch, it is now built.
R=pbos@webrtc.org
Review URL: https://codereview.webrtc.org/1348093002 .
Cr-Commit-Position: refs/heads/master@{#9952}
This CL should not do any functional changes. It removes some redundant arguments and unnecessary error checking.
BUG=webrtc:4993
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1338943003 .
Cr-Commit-Position: refs/heads/master@{#9950}
Reason for revert:
Breaks goma (??!??!?)
Original issue's description:
> Bailing out if pc factory fails to get created.
>
> This prevents us from continuing if we fail initialization.
> The failure will happen closer to its source, rather than
> when we try to create the first peer connection.
>
> BUG=None
> R=glaznev@webrtc.org
>
> Committed: https://crrev.com/6eb75d9e67f02c256436eb96f3c77026486561a1
> Cr-Commit-Position: refs/heads/master@{#9948}
TBR=glaznev@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
Review URL: https://codereview.webrtc.org/1344363002
Cr-Commit-Position: refs/heads/master@{#9949}
This prevents us from continuing if we fail initialization.
The failure will happen closer to its source, rather than
when we try to create the first peer connection.
BUG=None
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1339923004 .
Cr-Commit-Position: refs/heads/master@{#9948}
Need to figure out the best way to initialize native logging system
while peer connection factory is not created yet.
R=jiayl@webrtc.org
Review URL: https://codereview.webrtc.org/1343163003 .
Cr-Commit-Position: refs/heads/master@{#9947}
Currently disposing Java peer connection object will result in auto
release of media streams and media tracks added to peer connection.
Add an option to allow application to own video track so it can be
kept after peer connection is destroyed.
R=jiayl@webrtc.org, wzh@webrtc.org
Review URL: https://codereview.webrtc.org/1333363002 .
Cr-Commit-Position: refs/heads/master@{#9946}
Remove start_bitrate_bps which is no longer used and return the current
allocated bitrate instead of having it as an out parameter, removing the
previous return value which is no longer used.
Permits removing bitrate controller usage from ViEEncoder.
BUG=webrtc:1695
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1343783006 .
Cr-Commit-Position: refs/heads/master@{#9942}
I'm not super happy with the GetVoE() function added on MediaEngineInterface, but this will eventually be gone, once webrtc::Call owns the shared VoE state (or initially, maps ADM* to an implicitly created VoE).
BUG=webrtc:4690
R=pbos@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1269863005 .
Cr-Commit-Position: refs/heads/master@{#9939}
Add new helper class to create and synchronize access to SurfaceTextures. The plan is replace the SurfaceTexture in MediaCodecVideoDecoder in a follow-up CL and remove the SurfaceTexture.updateTexImage() call in VideoRendererGui.
BUG=webrtc:4993
R=hbos@webrtc.org
Review URL: https://codereview.webrtc.org/1342713003 .
Cr-Commit-Position: refs/heads/master@{#9938}
Future log messages should all be sent to org.webrtc.Logging as well.
BUG=
Review URL: https://codereview.webrtc.org/1338033003
Cr-Commit-Position: refs/heads/master@{#9936}
Incoming frames usually have an epoch of time since the capturer was
created or similar, not any fixed-time epoch. As such, setting a new
capturer resulted in delivering frames with older timestamps which
caused these frames to be dropped before encoding.
BUG=webrtc:4994
R=stefan@webrtc.orgTBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1345473002
Cr-Commit-Position: refs/heads/master@{#9934}
