mozilla
/
gecko-dev
зеркало из https://github.com/mozilla/gecko-dev.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
gecko-dev/third_party/libwebrtc/moz-patch-stack/0038.patch

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

33 строки
1.1 KiB
Diff
Исходник Обычный вид История

Bug 1828517 - Vendor libwebrtc from 9f9671fe7f We already cherry-picked this when we vendored fc5d627cef. Upstream commit: https://webrtc.googlesource.com/src/+/9f9671fe7fa63738d564adbf94e8863597b6ac0b Revert "Reland "Ensure RTCRtpSenders are always created with one encoding"" This reverts commit fc5d627cef71f906e921476c2e6b1e01d07732fe. Reason for revert: Breaks upstream WPT tests Original change's description: > Reland "Ensure RTCRtpSenders are always created with one encoding" > > This is a reland of commit b8023690d9f0e150cfe698cd68b477903ac66178 > > Original change's description: > > Ensure RTCRtpSenders are always created with one encoding > > > > It is possible to have AddTransceiver calls with an empty array > > of encodings or AddTrack calls. In both cases, before negotiation, > > the sender's encodings array would be empty and it was not possible > > to update any value. > > > > Now, a default entry should be created in those cases, allowing to > > update the configuration before negotiation. > > > > Bug: webrtc:10567 > > Change-Id: I1271e2965e1a97c1e472451e0ab8867fc24f6c2b > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290994 > > Auto-Submit: Florent Castelli <orphis@webrtc.org> > > Reviewed-by: Henrik Boström <hbos@webrtc.org> > > Commit-Queue: Florent Castelli <orphis@webrtc.org> > > Cr-Commit-Position: refs/heads/main@{#39126} > > Bug: webrtc:10567 > Change-Id: I2d52fa5b1d7cfdc9dce279fcf9faf1e0129c9008 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291140 > Reviewed-by: Henrik Boström <hbos@webrtc.org> > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > Commit-Queue: Florent Castelli <orphis@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#39145} Bug: webrtc:10567 Change-Id: If9b5adb5debb7c87a15662a8d0f232405a0e8136 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291221 Auto-Submit: Evan Shrubsole <eshr@webrtc.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/main@{#39147}
2023-04-21 20:32:07 +03:00
From: Dan Minor <dminor@mozilla.com>
Bug 1828517 - Vendor libwebrtc from cb954cdb08 We already cherry-picked this when we vendored 218b56e516. Upstream commit: https://webrtc.googlesource.com/src/+/cb954cdb0814e2119b6cb0fe2512d532b5c1419c Fix Destruction inside WGC Callback If we are notified of the destruction of the window before a CaptureFrame call can fail, then we may end up attempting to destroy the underlying WGC object inside it's own event handler. This can be problematic, as the class itself may want to run other code. Instead, we just unsubscribe and signal that any future CaptureFrame calls should reject. This also removes setting "is_capture_started_=false" in the item closed handler, as all that served to do is cause the WgcCapturerWin code to attempt to restart the capturer, and somewhat muddies up our metrics. (cherry picked from commit 318cf28945d80a0ac6f09382e507c95e649cc4c1) Bug: chromium:1413005 No-Try: True Change-Id: Ibccb7a2e7ce531ba80b4b331b9bc2cda0ff75f4e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292762 Auto-Submit: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#39275} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293243 Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5563@{#2} Cr-Branched-From: 6c032cb8356b0d3f717c4fcf50796241f2bba6c2-refs/heads/main@{#39207}
2023-04-25 02:05:19 +03:00
Date: Tue, 1 Dec 2020 09:36:00 -0500
Subject: Bug 1654112 - Disable creating av1 encoder and decoder. r=ng
Bug 1825620 - pt9 - bootstrap the moz-libwebrtc patch stack r=ng,webrtc-reviewers DONTBUILD Depends on D175824 Differential Revision: https://phabricator.services.mozilla.com/D175963
2023-04-20 06:26:29 +03:00
Bug 1828517 - Vendor libwebrtc from cb954cdb08 We already cherry-picked this when we vendored 218b56e516. Upstream commit: https://webrtc.googlesource.com/src/+/cb954cdb0814e2119b6cb0fe2512d532b5c1419c Fix Destruction inside WGC Callback If we are notified of the destruction of the window before a CaptureFrame call can fail, then we may end up attempting to destroy the underlying WGC object inside it's own event handler. This can be problematic, as the class itself may want to run other code. Instead, we just unsubscribe and signal that any future CaptureFrame calls should reject. This also removes setting "is_capture_started_=false" in the item closed handler, as all that served to do is cause the WgcCapturerWin code to attempt to restart the capturer, and somewhat muddies up our metrics. (cherry picked from commit 318cf28945d80a0ac6f09382e507c95e649cc4c1) Bug: chromium:1413005 No-Try: True Change-Id: Ibccb7a2e7ce531ba80b4b331b9bc2cda0ff75f4e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292762 Auto-Submit: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#39275} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293243 Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5563@{#2} Cr-Branched-From: 6c032cb8356b0d3f717c4fcf50796241f2bba6c2-refs/heads/main@{#39207}
2023-04-25 02:05:19 +03:00
Differential Revision: https://phabricator.services.mozilla.com/D130089
Mercurial Revision: https://hg.mozilla.org/mozilla-central/rev/ef548d7758c7de6e78d38af299c2296bf9d20ec9
Bug 1825620 - pt9 - bootstrap the moz-libwebrtc patch stack r=ng,webrtc-reviewers DONTBUILD Depends on D175824 Differential Revision: https://phabricator.services.mozilla.com/D175963
2023-04-20 06:26:29 +03:00
---
Bug 1828517 - Vendor libwebrtc from cb954cdb08 We already cherry-picked this when we vendored 218b56e516. Upstream commit: https://webrtc.googlesource.com/src/+/cb954cdb0814e2119b6cb0fe2512d532b5c1419c Fix Destruction inside WGC Callback If we are notified of the destruction of the window before a CaptureFrame call can fail, then we may end up attempting to destroy the underlying WGC object inside it's own event handler. This can be problematic, as the class itself may want to run other code. Instead, we just unsubscribe and signal that any future CaptureFrame calls should reject. This also removes setting "is_capture_started_=false" in the item closed handler, as all that served to do is cause the WgcCapturerWin code to attempt to restart the capturer, and somewhat muddies up our metrics. (cherry picked from commit 318cf28945d80a0ac6f09382e507c95e649cc4c1) Bug: chromium:1413005 No-Try: True Change-Id: Ibccb7a2e7ce531ba80b4b331b9bc2cda0ff75f4e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292762 Auto-Submit: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#39275} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293243 Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5563@{#2} Cr-Branched-From: 6c032cb8356b0d3f717c4fcf50796241f2bba6c2-refs/heads/main@{#39207}
2023-04-25 02:05:19 +03:00
media/engine/internal_decoder_factory.cc | 2 ++
1 file changed, 2 insertions(+)
Bug 1825620 - pt9 - bootstrap the moz-libwebrtc patch stack r=ng,webrtc-reviewers DONTBUILD Depends on D175824 Differential Revision: https://phabricator.services.mozilla.com/D175963
2023-04-20 06:26:29 +03:00
Bug 1828517 - Vendor libwebrtc from cb954cdb08 We already cherry-picked this when we vendored 218b56e516. Upstream commit: https://webrtc.googlesource.com/src/+/cb954cdb0814e2119b6cb0fe2512d532b5c1419c Fix Destruction inside WGC Callback If we are notified of the destruction of the window before a CaptureFrame call can fail, then we may end up attempting to destroy the underlying WGC object inside it's own event handler. This can be problematic, as the class itself may want to run other code. Instead, we just unsubscribe and signal that any future CaptureFrame calls should reject. This also removes setting "is_capture_started_=false" in the item closed handler, as all that served to do is cause the WgcCapturerWin code to attempt to restart the capturer, and somewhat muddies up our metrics. (cherry picked from commit 318cf28945d80a0ac6f09382e507c95e649cc4c1) Bug: chromium:1413005 No-Try: True Change-Id: Ibccb7a2e7ce531ba80b4b331b9bc2cda0ff75f4e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292762 Auto-Submit: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#39275} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293243 Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5563@{#2} Cr-Branched-From: 6c032cb8356b0d3f717c4fcf50796241f2bba6c2-refs/heads/main@{#39207}
2023-04-25 02:05:19 +03:00
diff --git a/media/engine/internal_decoder_factory.cc b/media/engine/internal_decoder_factory.cc
index e761fd60c8..001c666313 100644
--- a/media/engine/internal_decoder_factory.cc
+++ b/media/engine/internal_decoder_factory.cc
@@ -49,12 +49,14 @@ std::vector<SdpVideoFormat> InternalDecoderFactory::GetSupportedFormats()
for (const SdpVideoFormat& h264_format : SupportedH264DecoderCodecs())
formats.push_back(h264_format);
Bug 1828517 - Vendor libwebrtc from f2a083f262 We already cherry-picked this when we vendored 897ea04db5. Upstream commit: https://webrtc.googlesource.com/src/+/f2a083f262d86737893e774c696716742fcab3e3 Revert "Delete PacketReceiver::DeliverPacket from all implementations" This reverts commit 897ea04db5db2e591e28bd884191be58d9bcdc63. Reason for revert: Speculative revert as it could be the reason why perf tests started failing: https://ci.chromium.org/p/webrtc/g/perf/console?limit=200 Original change's description: > Delete PacketReceiver::DeliverPacket from all implementations > > And fix tests that still depend on extensions to be known by the receiver. > > Change-Id: I62227829af81af07769189e547f1cdb8ed4d06b3 > > Bug: webrtc:7135,webrtc:14795 > Change-Id: I62227829af81af07769189e547f1cdb8ed4d06b3 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290996 > Commit-Queue: Per Kjellander <perkj@webrtc.org> > Reviewed-by: Danil Chapovalov <danilchap@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#39184} Bug: webrtc:7135,webrtc:14795,b/266658815 Change-Id: I9d03f4952938d176ffee110a707acadc1846457c No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291400 Commit-Queue: Andrey Logvin <landrey@webrtc.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Andrey Logvin <landrey@webrtc.org> Reviewed-by: Jeremy Leconte <jleconte@google.com> Cr-Commit-Position: refs/heads/main@{#39189}
2023-04-21 21:18:56 +03:00
Bug 1828517 - Vendor libwebrtc from cb954cdb08 We already cherry-picked this when we vendored 218b56e516. Upstream commit: https://webrtc.googlesource.com/src/+/cb954cdb0814e2119b6cb0fe2512d532b5c1419c Fix Destruction inside WGC Callback If we are notified of the destruction of the window before a CaptureFrame call can fail, then we may end up attempting to destroy the underlying WGC object inside it's own event handler. This can be problematic, as the class itself may want to run other code. Instead, we just unsubscribe and signal that any future CaptureFrame calls should reject. This also removes setting "is_capture_started_=false" in the item closed handler, as all that served to do is cause the WgcCapturerWin code to attempt to restart the capturer, and somewhat muddies up our metrics. (cherry picked from commit 318cf28945d80a0ac6f09382e507c95e649cc4c1) Bug: chromium:1413005 No-Try: True Change-Id: Ibccb7a2e7ce531ba80b4b331b9bc2cda0ff75f4e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292762 Auto-Submit: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#39275} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293243 Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5563@{#2} Cr-Branched-From: 6c032cb8356b0d3f717c4fcf50796241f2bba6c2-refs/heads/main@{#39207}
2023-04-25 02:05:19 +03:00
+#if !defined(WEBRTC_MOZILLA_BUILD)
if (kDav1dIsIncluded) {
formats.push_back(SdpVideoFormat(cricket::kAv1CodecName));
formats.push_back(SdpVideoFormat(
cricket::kAv1CodecName,
{{kAV1FmtpProfile, AV1ProfileToString(AV1Profile::kProfile1).data()}}));
Bug 1828517 - Vendor libwebrtc from f2a083f262 We already cherry-picked this when we vendored 897ea04db5. Upstream commit: https://webrtc.googlesource.com/src/+/f2a083f262d86737893e774c696716742fcab3e3 Revert "Delete PacketReceiver::DeliverPacket from all implementations" This reverts commit 897ea04db5db2e591e28bd884191be58d9bcdc63. Reason for revert: Speculative revert as it could be the reason why perf tests started failing: https://ci.chromium.org/p/webrtc/g/perf/console?limit=200 Original change's description: > Delete PacketReceiver::DeliverPacket from all implementations > > And fix tests that still depend on extensions to be known by the receiver. > > Change-Id: I62227829af81af07769189e547f1cdb8ed4d06b3 > > Bug: webrtc:7135,webrtc:14795 > Change-Id: I62227829af81af07769189e547f1cdb8ed4d06b3 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290996 > Commit-Queue: Per Kjellander <perkj@webrtc.org> > Reviewed-by: Danil Chapovalov <danilchap@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#39184} Bug: webrtc:7135,webrtc:14795,b/266658815 Change-Id: I9d03f4952938d176ffee110a707acadc1846457c No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291400 Commit-Queue: Andrey Logvin <landrey@webrtc.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Andrey Logvin <landrey@webrtc.org> Reviewed-by: Jeremy Leconte <jleconte@google.com> Cr-Commit-Position: refs/heads/main@{#39189}
2023-04-21 21:18:56 +03:00
}
Bug 1828517 - Vendor libwebrtc from cb954cdb08 We already cherry-picked this when we vendored 218b56e516. Upstream commit: https://webrtc.googlesource.com/src/+/cb954cdb0814e2119b6cb0fe2512d532b5c1419c Fix Destruction inside WGC Callback If we are notified of the destruction of the window before a CaptureFrame call can fail, then we may end up attempting to destroy the underlying WGC object inside it's own event handler. This can be problematic, as the class itself may want to run other code. Instead, we just unsubscribe and signal that any future CaptureFrame calls should reject. This also removes setting "is_capture_started_=false" in the item closed handler, as all that served to do is cause the WgcCapturerWin code to attempt to restart the capturer, and somewhat muddies up our metrics. (cherry picked from commit 318cf28945d80a0ac6f09382e507c95e649cc4c1) Bug: chromium:1413005 No-Try: True Change-Id: Ibccb7a2e7ce531ba80b4b331b9bc2cda0ff75f4e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292762 Auto-Submit: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#39275} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293243 Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5563@{#2} Cr-Branched-From: 6c032cb8356b0d3f717c4fcf50796241f2bba6c2-refs/heads/main@{#39207}
2023-04-25 02:05:19 +03:00
+#endif
Bug 1828517 - Vendor libwebrtc from f2a083f262 We already cherry-picked this when we vendored 897ea04db5. Upstream commit: https://webrtc.googlesource.com/src/+/f2a083f262d86737893e774c696716742fcab3e3 Revert "Delete PacketReceiver::DeliverPacket from all implementations" This reverts commit 897ea04db5db2e591e28bd884191be58d9bcdc63. Reason for revert: Speculative revert as it could be the reason why perf tests started failing: https://ci.chromium.org/p/webrtc/g/perf/console?limit=200 Original change's description: > Delete PacketReceiver::DeliverPacket from all implementations > > And fix tests that still depend on extensions to be known by the receiver. > > Change-Id: I62227829af81af07769189e547f1cdb8ed4d06b3 > > Bug: webrtc:7135,webrtc:14795 > Change-Id: I62227829af81af07769189e547f1cdb8ed4d06b3 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290996 > Commit-Queue: Per Kjellander <perkj@webrtc.org> > Reviewed-by: Danil Chapovalov <danilchap@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#39184} Bug: webrtc:7135,webrtc:14795,b/266658815 Change-Id: I9d03f4952938d176ffee110a707acadc1846457c No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291400 Commit-Queue: Andrey Logvin <landrey@webrtc.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Andrey Logvin <landrey@webrtc.org> Reviewed-by: Jeremy Leconte <jleconte@google.com> Cr-Commit-Position: refs/heads/main@{#39189}
2023-04-21 21:18:56 +03:00
Bug 1828517 - Vendor libwebrtc from cb954cdb08 We already cherry-picked this when we vendored 218b56e516. Upstream commit: https://webrtc.googlesource.com/src/+/cb954cdb0814e2119b6cb0fe2512d532b5c1419c Fix Destruction inside WGC Callback If we are notified of the destruction of the window before a CaptureFrame call can fail, then we may end up attempting to destroy the underlying WGC object inside it's own event handler. This can be problematic, as the class itself may want to run other code. Instead, we just unsubscribe and signal that any future CaptureFrame calls should reject. This also removes setting "is_capture_started_=false" in the item closed handler, as all that served to do is cause the WgcCapturerWin code to attempt to restart the capturer, and somewhat muddies up our metrics. (cherry picked from commit 318cf28945d80a0ac6f09382e507c95e649cc4c1) Bug: chromium:1413005 No-Try: True Change-Id: Ibccb7a2e7ce531ba80b4b331b9bc2cda0ff75f4e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292762 Auto-Submit: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#39275} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293243 Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5563@{#2} Cr-Branched-From: 6c032cb8356b0d3f717c4fcf50796241f2bba6c2-refs/heads/main@{#39207}
2023-04-25 02:05:19 +03:00
return formats;
}
Bug 1825620 - pt9 - bootstrap the moz-libwebrtc patch stack r=ng,webrtc-reviewers DONTBUILD Depends on D175824 Differential Revision: https://phabricator.services.mozilla.com/D175963
2023-04-20 06:26:29 +03:00
--
2.34.1