The lock isn't really needed as encoder_queue_is_active_ can be checked
on the task queue to provide synchronization.
There is one behavioral change due to this: We will not cancel any currently
pending encoding tasks when we stop sending, they will be allowed to finish.
Bug: webrtc:10365
Change-Id: I2b4897dde8d49bc7ee5d2d69694616aee8aaea38
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/125096
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26963}
WebRtcVideoEngine is only ever accessed from one thread, so remove
the lock and replace it with ThreadChecker assertions.
Bug: None
Change-Id: I8c34eb6473f0ebaaaafe8a163c3f5d6f19074021
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/125240
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Amit Hilbuch <amithi@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26957}
The idea is to let the RtpRtcp and RTPSender classes be responsible for
media-agnostic RTP transport, and move out the media-specific processing,
such as packetization and media-specific headers.
Bug: webrtc:7135
Change-Id: Ib0ce45bf06713b3eb6c06acd91c5168856874e4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/123187
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26954}
This is a lightweight signalling, which tells that two
frames are the same if they are the same view of the same frame from the
same file, without comparing actual buffer contents and searching for
changed pixels.
Bug: webrtc:10310
Change-Id: I5c6ae571fdf4cab88466cde88fe7c7a78ae121cc
Reviewed-on: https://webrtc-review.googlesource.com/c/125099
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26951}
The old iceConnectionState only becomes completed on the controlling side, and only if we're not configured to continually gather ICE candidates. This change makes the new ICE connection state do the same thing.
Bug: webrtc:10356
Change-Id: I82ca854a638a52674e4ca43364cf454dacb0cf1e
Reviewed-on: https://webrtc-review.googlesource.com/c/124360
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Olsson <jonasolsson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26950}
Previously, we have created a Legacy ADM when no ADM is supplied.
With this change we will start creating a Java ADM instead.
The end goal is to make injection mandatory, and never creating ADMs.
This is one step on the way, and will allow us to clean up the Legacy
ADM code.
Bug: webrtc:7452
Change-Id: Ib99adc50346fe6b748f9435d2fc6321a50c3ee4e
Reviewed-on: https://webrtc-review.googlesource.com/c/123887
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Paulina Hensman <phensman@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26949}
It seems native mutex performance has improved considerably on Mac
lately, primarily by switching to a different default scheduling
policy. For safety, set this policy explicitly.
The special implementation previously used on Mac is still faster but
suffers a problem when used on realtime audio threads, where they will
not get rescheduled as quickly as when using native mutexes.
Bug: webrtc:10373
Change-Id: Iabf97afc5c2609096331bba0199f433fd26b68b2
Reviewed-on: https://webrtc-review.googlesource.com/c/125186
Commit-Queue: Oskar Sundbom <ossu@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26948}
there's no easy way to inject the Clock in ScreenshareLayers under
normal use. To allow faking the clock, rtc::TimeMillis is used instead.
Bug: webrtc:10365
Change-Id: I46c7f76514672190a0f0f5816a2c858bc6c76fa4
Reviewed-on: https://webrtc-review.googlesource.com/c/125189
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26946}
This test is verified to better catch the performance issues that were
fixed in issue 10275.
Bug: webrtc:10275, webrtc:10070
Change-Id: I4654f013b0fa08015af8572269b9df979e5a641f
Reviewed-on: https://webrtc-review.googlesource.com/c/125300
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26944}
The header "rtc_base/fake_mdns_responder.h" was not self contained,
and it was relying on order includes to get all the types it needs.
This CL makes it self-contained and removes an unneeded #include.
Bug: None
Change-Id: Ie6c584a169ef884d79e436e51c2e72236b0d4c7a
Reviewed-on: https://webrtc-review.googlesource.com/c/125184
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26938}
Simulcast is disabled if the RIDs are not negotiated.
This change addresses the scenario in which RIDs are negotiated but
support for the RID extension is not negotiated.
In such cases, the RID extension cannot be used, so support for
simulcast should be turned off, as if RIDs were not negotiated.
A similar case can be made for MIDs, however MIDs are not explicitly
specified in simulcast. RIDs are only guaranteed to be unique within
a media section so it would seem that MIDs should be required.
However, applications supply RID values and can guarantee their
uniqueness, so unlike RIDs, the use of MIDs is not enforced as mandatory.
Bug: webrtc:10075
Change-Id: Ic1b27878ea152eaee43a38bbfda11144307766fe
Reviewed-on: https://webrtc-review.googlesource.com/c/125176
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26934}
We already support decoding of the x-mt line. This change adds the
a=x-mt line to the SDP offer. This is not a backward compatible change
for media transport (because of the changes in pre-shared key handling)
1) if media transport is enabled, and SDES is enabled, generate the
media transport offer.
2) if media transport generated the offer, add that offer to the x-mt
line.
3) in order to create media transport, require an x-mt line (backward incompatible).
The way it works is that
1) PeerConnection, on the offerer, asks jsep transport for the
configuration of the media transport.
2) Tentative media transport is created in JsepTransportController when
that happens.
3) SessionDescription will include configuration from this tentative
media transport.
4) When the LocalDescription is set on the offerer, the tentative media
transport is promoted to the real media transport.
Caveats:
- now we really only support MaxBundle. In the previous implementations,
two media transports were briefly created in some tests, and the second
one was destroyed shortly after instantiation.
- we, for now, enforce SDES. In the future, whether SDES is used will be
refactored out of the peer connection.
In the future (on the callee) we should ignore 'is_media_transport' setting. If
Offer contains x-mt, media transport should be used (if the factory is
present). However, we need to decide how to negotiate media transport
for data channels vs data transport for media (x-mt line at this point
doesn't differentiate the two, so we still need to use app setting).
This change also removes the negotation of pre-shared key from the
a=crypto line. Instead, media transport will have its own, 256bit key.
Such key should be transported in the x-mt line. This makes the code
much simpler, and simplifies the dependency / a=crypto lines parsing.
Also, adds a proper test for the connection re-offer (on both sides: callee and caller).
Before, it was possible that media transport could get recreated, based on the offer.
The tests we had didn't test this scenario, and the loopback media factory didn't allow for such test.
This change adds counts to that loopback media factory, and asserts that only 1 media transport is created, even
when there is a re-offer.
Bug: webrtc:9719
Change-Id: Ibd8739af90e914da40ab412454bba8e1529f5a01
Reviewed-on: https://webrtc-review.googlesource.com/c/125040
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26933}
The current Key Frame request system doesn't take into account failed
decryptions and this can lead to WebRTC spamming new key frame requests when
the issue is actually in the decryptor layer. To prevent this if frame
decryption is required for the PeerConnection key frame requests will not be
sent at 200ms intervals but will wait until the stream is decryptable before
utilizing this logic.
Bug: webrtc:10330
Change-Id: I188a21dfd142dec6175d9def95f39a2bc517017c
Reviewed-on: https://webrtc-review.googlesource.com/c/123414
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26931}
This prepares for future cleanup of how RtpTransportControllerSend is
used.
Bug: webrtc:10365
Change-Id: Idefc7e60f83819627c83b397949c8434d93491b3
Reviewed-on: https://webrtc-review.googlesource.com/c/124783
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26923}
