Bug 1851693 - Vendor libwebrtc from 626d408ba5

We already cherry-picked this when we vendored 8fbabf340d.

Upstream commit: https://webrtc.googlesource.com/src/+/626d408ba5d0ae5b1f6b66a7cf244a85ea66c11e
    [M116] Revert mid check in SdpOfferAnswerHandler::CreateDataChannel.

    This check was added here:
      https://webrtc-review.googlesource.com/c/src/+/300544

    When createOffer is used before createAnswer, this check would cause
    SetupDataChannelTransport_n to not be called for the remote channel.

    (cherry picked from commit 299cdc9057fb8925f1692ac8c7573f51b7872df6)

    Bug: webrtc:15258, chromium:1458937
    Change-Id: Ifdab35d1b0260ff03fef4beff13acf8090d59d8f
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310460
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#40357}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312123
    Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5845@{#5}
    Cr-Branched-From: f80cf814353d11a9f22bef5ce5e8868f2c72f0d0-refs/heads/main@{#40319}

third_party/libwebrtc/README.moz-ff-commit

@@ -24651,3 +24651,6 @@ ebf9a1faf8
 # MOZ_LIBWEBRTC_SRC=/Users/mfroman/no_tm_backup/elm/.moz-fast-forward/moz-libwebrtc MOZ_LIBWEBRTC_BRANCH=mozpatches bash dom/media/webrtc/third_party_build/fast-forward-libwebrtc.sh
 # base of lastest vendoring
 aa6c910f47
+# MOZ_LIBWEBRTC_SRC=/Users/mfroman/no_tm_backup/elm/.moz-fast-forward/moz-libwebrtc MOZ_LIBWEBRTC_BRANCH=mozpatches bash dom/media/webrtc/third_party_build/fast-forward-libwebrtc.sh
+# base of lastest vendoring
+626d408ba5

third_party/libwebrtc/README.mozilla

@@ -16456,3 +16456,5 @@ libwebrtc updated from /Users/danielbaker/elm/.moz-fast-forward/moz-libwebrtc co
 libwebrtc updated from /Users/mfroman/no_tm_backup/elm/.moz-fast-forward/moz-libwebrtc commit mozpatches on 2023-09-27T04:05:13.829503.
 # ./mach python dom/media/webrtc/third_party_build/vendor-libwebrtc.py --from-local /Users/mfroman/no_tm_backup/elm/.moz-fast-forward/moz-libwebrtc --commit mozpatches libwebrtc
 libwebrtc updated from /Users/mfroman/no_tm_backup/elm/.moz-fast-forward/moz-libwebrtc commit mozpatches on 2023-09-27T04:07:37.648411.
+# ./mach python dom/media/webrtc/third_party_build/vendor-libwebrtc.py --from-local /Users/mfroman/no_tm_backup/elm/.moz-fast-forward/moz-libwebrtc --commit mozpatches libwebrtc
+libwebrtc updated from /Users/mfroman/no_tm_backup/elm/.moz-fast-forward/moz-libwebrtc commit mozpatches on 2023-09-27T04:08:52.973541.

third_party/libwebrtc/moz-patch-stack/0004.patch

@@ -1,46 +1,37 @@
-From: Nico Grunbaum <na-g@nostrum.com>
-Date: Sat, 13 Feb 2021 04:20:00 -0800
-Subject: Bug 1654112 - Add pid_t to desktop_capture_types.h; r=pehrsons
+From: Michael Froman <mfroman@mozilla.com>
+Date: Fri, 9 Jul 2021 18:14:00 -0500
+Subject: Bug 1654112 - mutex changes to fix tsan errors. r=ng
 
-Upstreaming bug 1697385
-
-Also includes:
-Bug 1654112 - Clarifying prev. rev that moved pid_t into the global namespace; r=dminor
-
-Differential Revision: https://phabricator.services.mozilla.com/D107897
-Mercurial Revision: https://hg.mozilla.org/mozilla-central/rev/539b69f0e21118a1898f1ef689577c7193ff7be7
+Differential Revision: https://phabricator.services.mozilla.com/D119674
+Mercurial Revision: https://hg.mozilla.org/mozilla-central/rev/3d5503acf9a4b22e02c4300f29e4fbfed406ea2c
 ---
- modules/desktop_capture/desktop_capture_types.h | 4 ++++
- modules/video_capture/video_capture.h           | 1 +
- 2 files changed, 5 insertions(+)
+ rtc_base/logging.cc | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
 
-diff --git a/modules/desktop_capture/desktop_capture_types.h b/modules/desktop_capture/desktop_capture_types.h
-index 9627076eea..381d1021c4 100644
---- a/modules/desktop_capture/desktop_capture_types.h
-+++ b/modules/desktop_capture/desktop_capture_types.h
-@@ -13,6 +13,10 @@
-
- #include <stdint.h>
+diff --git a/rtc_base/logging.cc b/rtc_base/logging.cc
+index ad2303735e..9c2d3b0a39 100644
+--- a/rtc_base/logging.cc
++++ b/rtc_base/logging.cc
+@@ -275,8 +275,8 @@ void LogMessage::LogTimestamps(bool on) {
+ }
 
-+#ifdef XP_WIN      // Moving this into the global namespace
-+typedef int pid_t; // matching what used to be in
-+#endif             // video_capture_defines.h
-+
- namespace webrtc {
+ void LogMessage::LogToDebug(LoggingSeverity min_sev) {
+-  g_dbg_sev = min_sev;
+   webrtc::MutexLock lock(&GetLoggingLock());
++  g_dbg_sev = min_sev;
+   UpdateMinLogSeverity();
+ }
 
- enum class CaptureType { kWindow, kScreen };
-diff --git a/modules/video_capture/video_capture.h b/modules/video_capture/video_capture.h
-index e207598d68..58485f28e9 100644
---- a/modules/video_capture/video_capture.h
-+++ b/modules/video_capture/video_capture.h
-@@ -13,6 +13,7 @@
+@@ -460,6 +460,9 @@ void LogMessage::OutputToDebug(const LogLineRef& log_line) {
 
- #include "api/video/video_rotation.h"
- #include "api/video/video_sink_interface.h"
-+#include "modules/desktop_capture/desktop_capture_types.h"
- #include "modules/video_capture/raw_video_sink_interface.h"
- #include "modules/video_capture/video_capture_defines.h"
- #include <set>
+ // static
+ bool LogMessage::IsNoop(LoggingSeverity severity) {
++  // Added MutexLock to fix tsan warnings on accessing g_dbg_sev. (mjf)
++  // See https://bugs.chromium.org/p/chromium/issues/detail?id=1228729
++  webrtc::MutexLock lock(&GetLoggingLock());
+   if (severity >= g_dbg_sev || severity >= g_min_sev)
+     return false;
+   return streams_empty_.load(std::memory_order_relaxed);
 -- 
 2.39.3 (Apple Git-145)
 

third_party/libwebrtc/moz-patch-stack/0005.patch

@@ -1,37 +1,49 @@
-From: Michael Froman <mfroman@mozilla.com>
-Date: Fri, 9 Jul 2021 18:14:00 -0500
-Subject: Bug 1654112 - mutex changes to fix tsan errors. r=ng
+From: Dan Minor <dminor@mozilla.com>
+Date: Wed, 18 Nov 2020 13:33:00 -0500
+Subject: Bug 1654112 - Suppress -Wclass-varargs warning in logging.h. r=ng
 
-Differential Revision: https://phabricator.services.mozilla.com/D119674
-Mercurial Revision: https://hg.mozilla.org/mozilla-central/rev/3d5503acf9a4b22e02c4300f29e4fbfed406ea2c
+This needs some investigation to see why we get this warning when it is not
+present upstream.
+
+Since both were doing the same thing for different compiler chains,
+also includes:
+Bug 1654112 - linux build fix (pragmas) for base-toolchains* . r=ng
+
+Differential Revision: https://phabricator.services.mozilla.com/D130086
+Mercurial Revision: https://hg.mozilla.org/mozilla-central/rev/8d832e832ffe513246c0763a56376a8022b2447b
 ---
- rtc_base/logging.cc | 5 ++++-
- 1 file changed, 4 insertions(+), 1 deletion(-)
+ rtc_base/logging.h | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
 
-diff --git a/rtc_base/logging.cc b/rtc_base/logging.cc
-index ad2303735e..9c2d3b0a39 100644
---- a/rtc_base/logging.cc
-+++ b/rtc_base/logging.cc
-@@ -275,8 +275,8 @@ void LogMessage::LogTimestamps(bool on) {
- }
+diff --git a/rtc_base/logging.h b/rtc_base/logging.h
+index 73a8bf7454..a980fb4ad3 100644
+--- a/rtc_base/logging.h
++++ b/rtc_base/logging.h
+@@ -48,6 +48,14 @@
+ #ifndef RTC_BASE_LOGGING_H_
+ #define RTC_BASE_LOGGING_H_
+
++#pragma GCC diagnostic push
++#pragma GCC diagnostic ignored "-Wvarargs"
++
++#if defined(__clang__)
++#  pragma clang diagnostic push
++#  pragma clang diagnostic ignored "-Wclass-varargs"
++#endif
++
+ #include <errno.h>
 
- void LogMessage::LogToDebug(LoggingSeverity min_sev) {
--  g_dbg_sev = min_sev;
-   webrtc::MutexLock lock(&GetLoggingLock());
-+  g_dbg_sev = min_sev;
-   UpdateMinLogSeverity();
- }
+ #include <atomic>
+@@ -764,4 +772,9 @@ inline const char* AdaptString(const std::string& str) {
 
-@@ -460,6 +460,9 @@ void LogMessage::OutputToDebug(const LogLineRef& log_line) {
+ }  // namespace rtc
 
- // static
- bool LogMessage::IsNoop(LoggingSeverity severity) {
-+  // Added MutexLock to fix tsan warnings on accessing g_dbg_sev. (mjf)
-+  // See https://bugs.chromium.org/p/chromium/issues/detail?id=1228729
-+  webrtc::MutexLock lock(&GetLoggingLock());
-   if (severity >= g_dbg_sev || severity >= g_min_sev)
-     return false;
-   return streams_empty_.load(std::memory_order_relaxed);
++#pragma GCC diagnostic pop
++#if defined(__clang__)
++#  pragma clang diagnostic pop
++#endif
++
+ #endif  // RTC_BASE_LOGGING_H_
 -- 
 2.39.3 (Apple Git-145)
 

third_party/libwebrtc/moz-patch-stack/0006.patch

@@ -1,49 +1,52 @@
 From: Dan Minor <dminor@mozilla.com>
-Date: Wed, 18 Nov 2020 13:33:00 -0500
-Subject: Bug 1654112 - Suppress -Wclass-varargs warning in logging.h. r=ng
+Date: Tue, 27 Mar 2018 15:43:00 -0400
+Subject: Bug 1376873 - Disable Mid support in RtpDemuxer; r=mjf
 
-This needs some investigation to see why we get this warning when it is not
-present upstream.
+The only use of Mid in the current webrtc.org code is in the unit tests.
+RtpStreamReceiverController only allows adding sinks using SSRCs. Because
+of this, we'll end up dropping packets in the RtpDemuxer with the current
+code as none of our Mids will be recognized.
 
-Since both were doing the same thing for different compiler chains,
-also includes:
-Bug 1654112 - linux build fix (pragmas) for base-toolchains* . r=ng
+Tip of webrtc.org fully supports using Mids, so we'll be able to enable this
+code again after the next update.
 
-Differential Revision: https://phabricator.services.mozilla.com/D130086
-Mercurial Revision: https://hg.mozilla.org/mozilla-central/rev/8d832e832ffe513246c0763a56376a8022b2447b
+Differential Revision: https://phabricator.services.mozilla.com/D7442
+Mercurial Revision: https://hg.mozilla.org/mozilla-central/rev/b3ba8452e77105c72f6ddbc49cbe5a53dbea1507
 ---
- rtc_base/logging.h | 13 +++++++++++++
- 1 file changed, 13 insertions(+)
+ call/rtp_demuxer.cc | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
 
-diff --git a/rtc_base/logging.h b/rtc_base/logging.h
-index 73a8bf7454..a980fb4ad3 100644
---- a/rtc_base/logging.h
-+++ b/rtc_base/logging.h
-@@ -48,6 +48,14 @@
- #ifndef RTC_BASE_LOGGING_H_
- #define RTC_BASE_LOGGING_H_
+diff --git a/call/rtp_demuxer.cc b/call/rtp_demuxer.cc
+index 0b74f2ac0a..5c53f48144 100644
+--- a/call/rtp_demuxer.cc
++++ b/call/rtp_demuxer.cc
+@@ -272,13 +272,17 @@ RtpPacketSinkInterface* RtpDemuxer::ResolveSink(
+   // RSID and RRID are routed to the same sinks. If an RSID is specified on a
+   // repair packet, it should be ignored and the RRID should be used.
+   std::string packet_mid, packet_rsid;
+-  bool has_mid = use_mid_ && packet.GetExtension<RtpMid>(&packet_mid);
++  //bool has_mid = use_mid_ && packet.GetExtension<RtpMid>(&packet_mid);
+   bool has_rsid = packet.GetExtension<RepairedRtpStreamId>(&packet_rsid);
+   if (!has_rsid) {
+     has_rsid = packet.GetExtension<RtpStreamId>(&packet_rsid);
+   }
+   uint32_t ssrc = packet.Ssrc();
 
-+#pragma GCC diagnostic push
-+#pragma GCC diagnostic ignored "-Wvarargs"
-+
-+#if defined(__clang__)
-+#  pragma clang diagnostic push
-+#  pragma clang diagnostic ignored "-Wclass-varargs"
-+#endif
-+
- #include <errno.h>
-
- #include <atomic>
-@@ -764,4 +772,9 @@ inline const char* AdaptString(const std::string& str) {
-
- }  // namespace rtc
++  // Mid support is half-baked in branch 64. RtpStreamReceiverController only
++  // supports adding sinks by ssrc, so our mids will never show up in
++  // known_mids_, causing us to drop packets here.
++#if 0
+   // The BUNDLE spec says to drop any packets with unknown MIDs, even if the
+   // SSRC is known/latched.
+   if (has_mid && known_mids_.find(packet_mid) == known_mids_.end()) {
+@@ -352,6 +356,7 @@ RtpPacketSinkInterface* RtpDemuxer::ResolveSink(
+     }
+   }
 
-+#pragma GCC diagnostic pop
-+#if defined(__clang__)
-+#  pragma clang diagnostic pop
 +#endif
-+
- #endif  // RTC_BASE_LOGGING_H_
+   // We trust signaled SSRC more than payload type which is likely to conflict
+   // between streams.
+   const auto ssrc_sink_it = sink_by_ssrc_.find(ssrc);
 -- 
 2.39.3 (Apple Git-145)