Removes confusion in the logs because both VideoSendStream and
VideoSendStreamImpl use the same log line.
Bug: None
Change-Id: Id9e22f23341e134667ab5f8e308732c836ab213d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195328
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#32693}
so that it will be filled in the dependency descriptor rtp header extension
Bug: webrtc:10342
Change-Id: Ifaf4963ca84f6d495287959746686ae3dcd176d8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168767
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32692}
In that configuration HAVE_WEBRTC_VIDEO is not defined so null_webrtc_video_engine.h gets included which unlike the real one does not include a required header.
Bug: webrtc:11926, webrtc:12187
Change-Id: I3f9df7a841ea6d9920dcb5b39a7386946c9e4341
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/193784
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32683}
I'm not 100% sure that is the reason. But I think it worth trying.
No-Presubmit: True
Bug: webrtc:12223
Change-Id: Idc6a9006ce2e3c6d299ad56cd747faebfeff37ce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195003
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Andrey Logvin <landrey@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32682}
This enables send side bandwidth estimation for audio and removes field
trial "WebRTC-Audio-SendSideBwe" which this was controlled through.
Transport-cc extension still needs to be negotiated.
Bug: webrtc:12222
Change-Id: Ie2268fad13703eeb0f0d38fcf484baaa29715b7c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194142
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32681}
Starting from [1], //third_party/protobuf has been updated to 3.13.0
and this introduces a breaking change which breaks WebRTC's perf results
upload (see bugs.webrtc.org/12211).
Error:
File [..]/tracing/proto/histogram_proto.py", line 9, in <module>
import histogram_pb2 # pylint:disable=relative-import
File "[..]/tracing/proto/histogram_pb2.py", line 22, in <module>
create_key=_descriptor._internal_create_key,
AttributeError: 'module' object has no attribute '_internal_create_key'
It looks like vpython is not able to load the wheel from the vpython
environment if the import happens in the "from ... import ..." form
while it works if the library is pre-imported with "import ...".
[1] - https://chromium-review.googlesource.com/c/chromium/src/+/2545204
No-Try: True
No-Presubmit: True
Bug: webrtc:12211
Change-Id: Id3e365eb9d4c4c31bcd4dcfab7db700e0e6e00b2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195000
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32677}
This patch fixes a bug where old candidates was
generated if doing GATHER_CONTINUALLY.
The problem was that the old port allocator session
was never stopped, and when the new sessio is created
it will attach to the network that will signal OnNetworkChanged().
The patch adds explicit stop of old sessions.
The problem was not possible to trigger using fake_network
as this "incorrectly" called SignalNetworkChanged directly
rather than after a Thread->Post() like network.cc does it.
Bug: webrtc:12210
Change-Id: Ief3f961bd97f06f4c4194ecbc3200c635ba63cf6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194961
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32675}
Methods deleted: StorePackets, RtcpXrRrtrStatus. They are now private
methods on the two implementations.
Bug: None
Change-Id: If68e8f1e8ba233302e24e0cdb6bf7c1b0c9f330f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194322
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32670}
The newer format is byte aligned and thus faster to write and parse
It also more compact for the common target bitrate cases.
Bug: webrtc:12000
Change-Id: Id040ecb9e7d85799134a6e52f5d6d280b5161262
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/193860
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32669}
This is a reland of f5e261aaf65cdf2eb903cdf40d651846be44f447
This CL disables RTC_NO_UNIQUE_ADDRESS on MSan builds since
there have been some issues.
Original change's description:
> Introduce RTC_NO_UNIQUE_ADDRESS.
>
> This macro introduces the possibility to suggest the compiler that a
> data member doesn't need an address different from other non static
> data members.
>
> The usage of a macro is to maintain portability since at the moment
> the attribute [[no_unique_address]] is only supported by clang
> with at least -std=c++11 but it should be supported by all the
> compilers starting from C++20.
>
> Bug: webrtc:11495
> Change-Id: I9f12b67b4422a2749649eaa6b004a67d5fd572d8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173331
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32246}
Bug: webrtc:11495, webrtc:12218
Change-Id: I4e6c7cc37d3daffad2407c9a2acfa897fa5b426a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/189968
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32668}
When spatial scalability is used, both vpx and aom set key frame flag
for all spatial layers of the first frame, while rtp code expect it to
be set only on the frame without spatial dependencies.
That creates confusion for the frame dependency calculator.
Simplest solution seems to ignore that confusing signal and instead
rely encoder wrappers update frame buffer usages when key frame is generated.
Bug: webrtc:11999
Change-Id: Ica24f1d8d42d32dd24664beabf32ac24872cd15a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194002
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32667}
Class was introduced in 2017, see
https://webrtc-review.googlesource.com/1420, but never taken into use.
Bug: chromium:764258
Change-Id: I5f15f25a3c1a992f8c725b78891956e7275b0e4d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194320
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32665}
All Post() calls are made to the network thread which the class already
clears up explicitly. 'AutoCleanup' scans all thread instances, which is
not needed for this class.
Bug: webrtc:11988
Change-Id: Ieefbdc87683dc62b6156c5df72e87d404242170f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194339
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32662}
This reverts commit f08db1be94e760c201acdc3a121e67453960c970.
Reason for revert: It looks like this breaks Chromium FYI Windows bots.
See https://ci.chromium.org/p/chromium/builders/webrtc.fyi/WebRTC%20Chromium%20FYI%20Win10%20Tester/6988.
If this is not the culprit I will reland.
Original change's description:
> Enable FlexFEC as a receiver video codec by default
>
> - Add Flex FEC format as default supported receive codec
> - Disallow advertising FlexFEC as video sender codec by default until implementation is complete
> - Toggle field trial "WebRTC-FlexFEC-03-Advertised"s behavior for receiver to use as kill-switch to prevent codec advertising
>
> Bug: webrtc:8151
> Change-Id: Iff367119263496fb335500e96641669654b45834
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/191947
> Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
> Reviewed-by: Ying Wang <yinwa@webrtc.org>
> Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32639}
TBR=brandtr@webrtc.org,tommi@webrtc.org,stefan@webrtc.org,crodbro@webrtc.org,crodbro@google.com,yinwa@webrtc.org,philipp.hancke@googlemail.com,hmaniar@nvidia.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:8151
Change-Id: Ia1788a1cf34e0fc9500a081552f6ed03d0995d5b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194334
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32657}
The Dependency Descriptor use unique ids for every frame, meaning spatial layer frames will all have unique ids.
Bug: webrtc:10342
Change-Id: I241a8b3959e27bd918ae7a907ab5158fe9dcd7a5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194327
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32655}
This reverts commit 9b53c2983260a210ba4f04510759bc56d5a2285e.
Reason for revert: It hasn't fixed the issue.
Original change's description:
> Add protobuf-py2_py3 3.13.0 to .vpython.
>
> Starting from https://webrtc-review.googlesource.com/c/src/+/194081,
> WebRTC's protobuf are using version 3.13.0.1+ but when running on
> bots, we see errors that are probably caused by a version mismatch, see
> https://ci.chromium.org/p/webrtc/builders/perf/Perf%20Linux%20Trusty/4597.
>
> This CL updates WebRTC's .vpython to use protobuf 3.13.0.
>
> TBR=kwiberg@webrtc.org
>
> No-Try: True
> Bug: None
> Change-Id: I6bc5e71bacc67dbd9299a9588ddf826778451949
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194143
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Andrey Logvin <landrey@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32642}
TBR=mbonadei@webrtc.org,kwiberg@webrtc.org,landrey@webrtc.org
Change-Id: I8d16d30bbe922b826f4839af941168a4d9b26318
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194260
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32648}
In P2PTransportChannel::OnConnectionStateChange there is
code that stop port allocation sessions if the modified
connection is stronly connected.
This means that local candidates are discarded (they are still
gathered, only not surfaced).
The implication of this is that if e.g doing a TURN allocation
slower than P2P is established, the TURN allocation will not be
added to list of local candidates => no TURN connection will be
created.
NOTE: If first connecting kRelay (only RELAY ONLY) then this
patch does matter that much...until an ICE restart happens :)
I discovered this when adding the emulated TURN server
to tests, and being surprised that the TURN allocations
never got used. These test does not (currently) use kRelay
as start.
Bug: webrtc:12210
Change-Id: I78a67201cf421b0e6fdd2ea684a00d740e063f5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194141
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32647}
