Using tempfile is probably overkill in this case, but it is good to
have a meaningful path printed out in case of error (instead of
something like "/tmp" and then a Windows path).
Bug: None
Change-Id: I90b939d7b2a082f4c04f995b602942efe1e671bc
Reviewed-on: https://webrtc-review.googlesource.com/81180
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23516}
This change sets the default down sampling factor of the delay estimator
4. Down sampling factor 8 is still problematic for some signals.
Bug: webrtc:9288,chromium:846615
Change-Id: I125371f3caf4f660ea2a386d2b89d7a488dcf802
Reviewed-on: https://webrtc-review.googlesource.com/80965
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23512}
webrtc:8745 is closed and it was about unblocking the Chromium roll,
webrtc:9352 is the new bug to keep track of the removal of ffmpeg
deprecated functions.
Bug: webrtc:9352
Change-Id: I2818dba804f3d611d4df80559a635e7cf1ee5338
No-Try: True
TBR: phoglund@webrtc.org
Reviewed-on: https://webrtc-review.googlesource.com/80882
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23506}
This provides an environment for testing out using WebRTC from an iOS
extension. It implements a ReplayKit broadcast extension for live
streaming games and screensharing.
The extension is only supported on iOS 11+ and is guarded by a build
flag.
Bug: webrtc:9335
Change-Id: Id218d6c73ef7599f5953c5a1e0e62e5d0dc4f10b
Reviewed-on: https://webrtc-review.googlesource.com/80000
Commit-Queue: Anders Carlsson <andersc@webrtc.org>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23504}
This reverts commit 21219a0e43446701810236fb9fdd59be072c12df.
Reason for revert: No tags are written when routing logs to a file - b/86953692
Original change's description:
> Reland "Injectable logging"
>
> Any injected loggable or NativeLogger would be deleted if PCFactory
> was reinitialized without calling setInjectableLogger. Now native
> logging is not implemented as a Loggable, so it will remain active
> unless a Loggable is injected.
>
> This is a reland of 59216ec4a4151b1ba5478c8f2b5c9f01f4683d7f
>
> Original change's description:
> > Injectable logging
> >
> > Allows passing a Loggable to PCFactory.initializationOptions, which
> > is then injected to Logging.java and logging.h. Future log messages
> > in both Java and native will then be passed to this Loggable.
> >
> > Bug: webrtc:9225
> > Change-Id: I2ff693380639448301a78a93dc11d3a0106f0967
> > Reviewed-on: https://webrtc-review.googlesource.com/73243
> > Commit-Queue: Paulina Hensman <phensman@webrtc.org>
> > Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> > Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#23241}
>
> Bug: webrtc:9225
> Change-Id: I2fe3fbc8c323814284bb62e43fe1870bdab581ee
> TBR: kwiberg
> Reviewed-on: https://webrtc-review.googlesource.com/77140
> Commit-Queue: Paulina Hensman <phensman@webrtc.org>
> Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23310}
TBR=magjed@webrtc.org,sakal@webrtc.org,kwiberg@webrtc.org,phensman@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:9225
Change-Id: I4d0a5990b5f742cc1a96afde3ca97fad9143d2d4
Reviewed-on: https://webrtc-review.googlesource.com/80641
Reviewed-by: Alex Glaznev <glaznev@webrtc.org>
Commit-Queue: Alex Glaznev <glaznev@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23498}
The current approach for enabling or disabling built in ssl root certificates
was a bit confusing. This changeset unifies everything to a common define.
Bug: webrtc:9332
Change-Id: I7a0c18410d05df4b786741c3b9196d97fbb8d7b6
Reviewed-on: https://webrtc-review.googlesource.com/79746
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23495}
This is a reland of 3409cfa378e75c0c08d900e0848147929249a62b
Needed to change RtpVideoStreamReceiver to stop deregistering a payload
type if two payload types refer to the same codec (which now happens,
with the packetization mode 0/1 payload types). It's not clear why this
was being done in the first place.
Original change's description:
> Start supporting H264 packetization mode 0.
>
> The work was already done to support it, but it wasn't being negotiated
> in SDP.
>
> This means we'll now see 8 H264 payload types instead of 4; one for each
> combination of BP/CBP profiles, packetization modes 0/1, and RTX/non-RTX.
> This could be problematic in the future, since we're starting to run
> out of dynamic payload types (using 25 of 32).
>
> Bug: chromium:600254
> Change-Id: Ief2340db77c796f12980445b547b87e939170fae
> Reviewed-on: https://webrtc-review.googlesource.com/77264
> Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23372}
Bug: chromium:600254
Change-Id: Ice1acc05acd1543d9b46e918de2bba0694d86259
Reviewed-on: https://webrtc-review.googlesource.com/78399
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23494}
Expose this functionality in the Obj-C SDK to make it nicer to use for
Obj-C clients.
Bug: None
Change-Id: I5cb511af8799ac0fda15153d16f2550b848b93b2
Reviewed-on: https://webrtc-review.googlesource.com/80481
Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
Commit-Queue: Anders Carlsson <andersc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23488}
The signal used for delay estimation at downsampling factor 8 is bandpass
filtered and contains less energy than for other downsampling factors.
This CL adjusts the energy threshold used for determining if there is enough
farend activity to update the matched filters in the delay estimator.
Only downsampling factor 8 is affected.
Bug: webrtc:9288,chromium:846615
Change-Id: I6f38f5609a31e7a08e60571ac75ea75c9962e026
Reviewed-on: https://webrtc-review.googlesource.com/80443
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23486}
The disk cannot always keep up to with the frames produced. To solve
this, write to disk on a dedicated thread so we don't block rendering.
Bug: b/80409365
Change-Id: If9ef3eb6948d81deebb987420599fef446b082d6
Reviewed-on: https://webrtc-review.googlesource.com/79800
Reviewed-by: Paulina Hensman <phensman@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23483}
To address this, this CL introduces a PeerConnectionFactoryDependencies
structure to encapsulate all mandatory and optional dependencies (where a
dependency is defined as non trivial executable code that an API user may want
to provide to the native API). This allows adding a new injectable dependency
by simply adding a new field to the struct, avoiding the hassle described above.
Bug: webrtc:7913
Change-Id: Ice58fa72e8c578b250084a1629499fabda66dabf
Reviewed-on: https://webrtc-review.googlesource.com/79720
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23480}
The proper closing procedure is:
1. Alice resets outgoing stream.
2. Bob receives incoming stream reset, resets his outgoing stream.
3. Alice receives incoming stream reset; channel closed!
4. Bob receives acknowledgement of reset; channel closed!
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.7
However, up until now we've been sending both an incoming and outgoing reset
from the side initiating the closing procedure, and doing nothing on the remote
side.
This means that if you call "Close" and the remote endpoint is using an old
version of WebRTC, the channel's state will be stuck at "closing" since the
remote endpoint won't send a reset. Which is already what happens when Firefox
is talking to Chrome.
This CL also fixes an issue where the DataChannel's state prematurely went to
"closed" before the closing procedure was complete. Which could result in a
new DataChannel attempting to re-use the ID and failing.
TBR=magjed@webrtc.org
Bug: chromium:449934, webrtc:4453
Change-Id: Ic1ba813e46538c6c65868961aae6a9780d68a5e2
Reviewed-on: https://webrtc-review.googlesource.com/79061
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23478}
The issue occurred if a control segment is received after a non-control
segment received out-of-order, which only happens if:
* The initial "connect" segment is lost, and retransmitted later.
* Both sides send "connect"s simultaneously (rather than having
designated server/client roles), such that the local side thinks a
connection is established even before its "connect" has been
acknowledged.
* Nagle algorithm disabled, allowing a data segment to be sent before
the "connect" has been acknowledged.
This may seem like a pretty specific set of circumstances, but it can
happen with chromoting.
See the linked bug for more details.
Bug: webrtc:9208
Change-Id: I3cfe26e02158fcc5843f32d4e2ef7c511d58d9c9
Reviewed-on: https://webrtc-review.googlesource.com/78861
Reviewed-by: Sergey Ulanov <sergeyu@google.com>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23477}
Both AudioRtpSender and VideoRtpSender receive stream_ids in their
constructor, no need to call set_stream_ids again.
Bug: None
Change-Id: I6238a6d6e31076a0b3245c89e2825d8dee5166c0
Reviewed-on: https://webrtc-review.googlesource.com/80220
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23476}
Chrome uses Windows native framework to show the notification of the
ongoing presenting. This notification window is enumerated as a
separated window which is on top most. If this window blocks the target
window, Chrome can't do the cropping and has to switch to GDI methods.
If GDI methods can't capture the target window, then capturing will fail
until the notification is dismissed.
It's hard to identify the notification window in EnumWindows() callback.
So far it works if we ignore window with no title and class name
prefixed with "Chrome_WidgetWin_" and with certain extended styles,
as so does in this CL.
Bug: chromium:847664
Change-Id: Iafabcb1f685adb91bf092475642151e1475cdf61
Reviewed-on: https://webrtc-review.googlesource.com/79742
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23474}
CascadedBiQuadFilter can run identical filters multiple times. This CL
allows the use of different filters in each step. This enables the use
of more elaborate filters. The filters are defined by zeros, poles and
gains.
The 'old' way of initializing CascadedBiQuadFilter with a transfer
function and number of filters is left intact.
Bug: webrtc:9288,chromium:846615
Change-Id: Ie4a5b98eba044415571cdcac087b20870a0b5d33
Reviewed-on: https://webrtc-review.googlesource.com/80060
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23473}
