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/1348613003
Cr-Commit-Position: refs/heads/master@{#10015}
In screensharing full stack tests, instead of using YuvFileGenerator by default
when no scrolling is used, I always used ScrollingImageFileGenerator.
That possibly slowed down the test a little bit, at least for the slowed
devices, as it unnecessarily copied few MBs per frame.
BUG=chromium:534220
Review URL: https://codereview.webrtc.org/1359783002
Cr-Commit-Position: refs/heads/master@{#10014}
Added to prevent Chromium from breaking if KeyType (now an enum) starts being used in Chromium before KeyType changes to a parameterizable class. When enum -> class change happens, IntKeyTypeFamilyToKeyType will be updated at the same time.
Once Chromium starts using class KeyType with parameters this function can be removed.
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1363543002 .
Cr-Commit-Position: refs/heads/master@{#10013}
While refactoring, I incorrectly set the target bitrate for one of the tests to
500k instead of 2000k.
This does not fix all the perf regressions.
BUG=534220
Review URL: https://codereview.webrtc.org/1356123002
Cr-Commit-Position: refs/heads/master@{#10008}
Reason for revert:
Broke the Windows build:
[226/365] LINK_EMBED cc_perftests.exe
FAILED: ninja -t msvc -e environment.x86 -- E:\b\build\goma/gomacc "E:\b\depot_tools\win_toolchain\vs2013_files\VC\bin\amd64_x86\cl.exe" /nologo /showIncludes /FC @obj\remoting\protocol\remoting_unittests.channel_socket_adapter_unittest.obj.rsp /c ..\..\remoting\protocol\channel_socket_adapter_unittest.cc /Foobj\remoting\protocol\remoting_unittests.channel_socket_adapter_unittest.obj /Fdobj\remoting\remoting_unittests.cc.pdb
e:\b\build\slave\win\build\src\remoting\protocol\channel_socket_adapter_unittest.cc(36) : error C3861: 'set_readable': identifier not found
ninja: build stopped: subcommand failed.
Original issue's description:
> Replace readable with receiving where receiving means receiving anything (stun ping, response or data packet).
> If a connection does not receive for 30 seconds, it will be deleted.
> BUG=
>
> Committed: https://crrev.com/ae16f8547d3b447f62f6660f13688585c6c3de15
> Cr-Commit-Position: refs/heads/master@{#10001}
TBR=pthatcher@webrtc.org,honghaiz@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.webrtc.org/1356103002
Cr-Commit-Position: refs/heads/master@{#10002}
If a connection does not receive for 30 seconds, it will be deleted.
BUG=
Review URL: https://codereview.webrtc.org/1351673003
Cr-Commit-Position: refs/heads/master@{#10001}
The Android camera api requires a surface to be set in order work. In https://codereview.webrtc.org/1354683004/ this surfaceTexture was removed as a member but it turns out that can lead to camera freezes when the device is rotated. This cl re-adds the surface as a member.
BUG= webrtc:5021, webrtc:5003
R=magjed@webrtc.org
Review URL: https://codereview.webrtc.org/1349433003 .
Cr-Commit-Position: refs/heads/master@{#9999}
Reason for revert:
Breaks FYI bots.
ninja: error: '../../third_party/webrtc_overrides/webrtc/base/logging.cc', needed by 'obj/third_party/webrtc_overrides/webrtc/base/rtc_base.logging.o', missing and no known rule to make it
Original issue's description:
> Update build files to use webrtc_overrides in Chromium instead of overrides.
>
> This is a part of moving the overrides to Chromium. See bug comment #65 for all steps.
>
> BUG=chromium:468375
>
> Committed: https://crrev.com/baae0a8a6c873ddf812a5687b84638359b2e7e5b
> Cr-Commit-Position: refs/heads/master@{#9996}
TBR=kjellander@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:468375
Review URL: https://codereview.webrtc.org/1352423002
Cr-Commit-Position: refs/heads/master@{#9998}
This change the PeerConnectionTest.doTest wait for at least one ice candidate and also make sure the list of candidates in gotIceCandidates is synchronized.
BUG=webrtc:5010
Review URL: https://codereview.webrtc.org/1354913002
Cr-Commit-Position: refs/heads/master@{#9997}
This is a part of moving the overrides to Chromium. See bug comment #65 for all steps.
BUG=chromium:468375
Review URL: https://codereview.webrtc.org/1354933002
Cr-Commit-Position: refs/heads/master@{#9996}
Video capture for android is now implemented in talk/app/webrtc/androidvideocapturer.h
BUG=webrtc:4475
Review URL: https://codereview.webrtc.org/1347083003
Cr-Commit-Position: refs/heads/master@{#9995}
Getting rid of TransportProxy, and in its place adding a
TransportController class which will facilitate access to and manage
the lifetimes of Transports. These Transports will now be accessed
solely from the worker thread, simplifying their implementation.
This refactoring also pulls Transport-related code out of BaseSession.
Which means that BaseChannels will now rely on the TransportController
interface to create channels, rather than BaseSession.
This CL also adds some unit tests, and does some renaming.
For example, from "CandidateReady" to "CandidateGathered".
Review URL: https://codereview.webrtc.org/1246913005
Cr-Commit-Position: refs/heads/master@{#9993}
The callback object was not used anymore. Also removing the deprecated
WEBRTC_DTMF_DETECTION macro from engine_configurations.h.
BUG=3520
Review URL: https://codereview.webrtc.org/1353763002
Cr-Commit-Position: refs/heads/master@{#9988}
Reason for revert:
Breaks Chromium WebRTC FYI bots.
Updating projects from gyp files...
gyp: /b/build/slave/linux/build/src/third_party/gflags/gflags.gyp not found (cwd: /b/build/slave/linux/build)
Error: Command '/usr/bin/python src/build/gyp_chromium' returned non-zero exit status 1 in /b/build/slave/linux/build
Original issue's description:
> Tool to convert RtcEventLog files to RtpDump format.
>
> 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
>
> Committed: https://crrev.com/35624c2c3686a2ad40daffe073aa78507b0ef88e
> Cr-Commit-Position: refs/heads/master@{#9980}
TBR=henrik.lundin@webrtc.org,terelius@webrtc.org,stefan@webrtc.org,kjellander@webrtc.org,kjellander@google.com,ivoc@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4741
Review URL: https://codereview.webrtc.org/1345983009
Cr-Commit-Position: refs/heads/master@{#9987}
To make this possible padding only packets will have the same timestamp
as the previously sent media packet, as long as RTX is not enabled. This
has the side effect that if we send only padding for a long time without
sending media, a receive-side jitter buffer could potentially overflow.
In practice this shouldn't be an issue, partly because RTX is recommended and
used by default, but also because padding typically is terminated before being
received by a client. It is also not an issue for bandwidth estimation as long
as abs-send-time is used instead of toffset.
BUG=chromium:425925
R=mflodman@webrtc.org, sprang@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1327933003 .
Cr-Commit-Position: refs/heads/master@{#9984}
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}
