This reverts commit a743303211b89bbcf4cea438ee797bbbc7b59e80.
Reason for revert: Breaks downstream tests that attempt to call FindHeaderExtensionByUri with 2 arguments. Could you keep the old 2-argument method declaration and just forward the call to the new 3-argument method with a suitable no-op filter?
Original change's description:
> Fix RTP header extension encryption
>
> Previously, RTP header extensions with encryption had been filtered
> if the encryption had been activated (not the other way around) which
> was likely an unintended logic inversion.
>
> In addition, it ensures that encrypted RTP header extensions are only
> negotiated if RTP header extension encryption is turned on. Formerly,
> which extensions had been negotiated depended on the order in which
> they were inserted, regardless of whether or not header encryption was
> actually enabled, leading to no extensions being sent on the wire.
>
> Further changes:
>
> - If RTP header encryption enabled, prefer encrypted extensions over
> non-encrypted extensions
> - Add most extensions to list of extensions supported for encryption
> - Discard encrypted extensions in a session description in case encryption
> is not supported for that extension
>
> Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
> into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
> header extensions will prevent any RTP packets being sent/received.
>
> Bug: webrtc:11713
> Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Taylor <deadbeef@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33723}
TBR=deadbeef@webrtc.org,terelius@webrtc.org,hta@webrtc.org,lennart.grahl@gmail.com
Change-Id: I7df6b0fa611c6496dccdfb09a65ff33ae4a52b26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11713
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215222
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33727}
Many things are omitted in this doc and it can definitely be improved,
but I hope it captures the most important parts.
Bug: webrtc:12568
Change-Id: I13097d633ca19cecc9dd43bdb777b0ca48f151dd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215142
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33724}
Previously, RTP header extensions with encryption had been filtered
if the encryption had been activated (not the other way around) which
was likely an unintended logic inversion.
In addition, it ensures that encrypted RTP header extensions are only
negotiated if RTP header extension encryption is turned on. Formerly,
which extensions had been negotiated depended on the order in which
they were inserted, regardless of whether or not header encryption was
actually enabled, leading to no extensions being sent on the wire.
Further changes:
- If RTP header encryption enabled, prefer encrypted extensions over
non-encrypted extensions
- Add most extensions to list of extensions supported for encryption
- Discard encrypted extensions in a session description in case encryption
is not supported for that extension
Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
header extensions will prevent any RTP packets being sent/received.
Bug: webrtc:11713
Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33723}
Erle Uncertainty changes the residual echo computation during saturated
echo. However, the case of saturated echo is already handled by the
residual echo estimator causing the ErleUncertainty to be a no-op.
The change has been tested for bit-exactness.
Bug: webrtc:8671
Change-Id: I779ba67f99f29d4475a0465d05da03d42d50e075
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215072
Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33719}
As part of adding the new WgcCapturerWin implementation of the
DesktopCapturer interface, we should ensure that we can measure the
health and success of this new code. In order to quantify that, I've
added telemetry to measure the usage of each capturer implementation,
the time taken to capture a frame, and any errors that are encountered
in the new implementation.
I've also set the capturer id property of frames so that we can measure
error rates and performance of each implementation in Chromium as well.
This CL must be completed after this Chromium CL lands:
2806094: Add histograms to record new WebRTC DesktopCapturer telemetry | https://chromium-review.googlesource.com/c/chromium/src/+/2806094
Bug: webrtc:9273
Change-Id: I33b0a008568a4df4f95e705271badc3313872f17
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214060
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33716}
This prepares for ability to defer sequence number assignment to after
the pacing stage - a scenario where the RtpRtcp module rather than than
RTPSender class has responsibility for sequence numbering.
Bug: webrtc:11340
Change-Id: Ife88f60258b9b7cfd9dbd3326f02ac34da8f7603
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214967
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33702}
Following up on https://webrtc-review.googlesource.com/c/src/+/213000
This CL prevents scheduling work before TaskQueuePacedSender::EnsureStarted(),
making it necessary to function.
Bug: chromium:1152887
Change-Id: I848c9e6d6057a404626ad693b1f4dc7fba797a9c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214320
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33695}
This is the result of compiling Chromium with
Wtautological-unsigned-zero-compare. For more details, see:
https://chromium-review.googlesource.com/c/chromium/src/+/2802412
Change-Id: I05cec6ae5738036a56beadeaa1dde5189edf0137
Bug: chromium:1195670
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213783
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33689}
VideoStreamEncoderTest: Remove unneeded set_timestamp_rtp in CreateFrame methods (the timestamp is set based on ntp_time_ms in VideoStreamEncoder::OnFrame).
Bug: none
Change-Id: I6b5531a9ac21cde5dac54df6de9b9d43261e90c6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214488
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33683}
To maintain interoperability between different capturer implementations
this change updates WgcScreenSourceEnumerator to return a list of
device indices instead of a list of HMONITORs, and WgcScreenSource to
accept a device index as the input SourceId. WGC still requires an
HMONITOR to create the capture item, so this change also adds a utility
function GetHmonitorFromDeviceIndex to convert them, as well as new
tests to cover these changes.
Bug: webrtc:12663
Change-Id: Ic29faa0f023ebc26b4276cf29ef3d15d976e8615
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214600
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33673}
This CL fixes a buffer copying issue introduced in this CL:
https://webrtc-review.googlesource.com/c/src/+/196485
In the BasicDesktopFrame::CopyOf function, the src and dst params
were swapped. For me this manifested as a missing cursor when using
Chrome Remote Desktop. I don't know of any other bugs this caused
but I have to assume it affects all callers of the function given
that the copy will never occur.
Bug: chromium:1197210
Change-Id: I076bffbad1d658b1c6f4b0dffea17d339c867bef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214840
Commit-Queue: Joe Downing <joedow@google.com>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33672}
There's been reports of dropped frames that are not counted and
correctly reported by getStats().
If a HW decoder is used and the system is provoked by stressing
the system, I've been able to reproduce this problem. It turns out
that we've missed frames that are dropped because there is no
callback to the Decoded() function.
This CL restructures the code so that dropped frames are counted
even in cases where there's no corresponding callback for some frames.
Bug: webrtc:11229
Change-Id: I0216edba3733399c188649908d459ee86a9093d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214783
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33671}
It was recommened to me to move this define to the top level BUILD.gn
file to avoid potential issues with the define not being available
where we need it.
Bug: webrtc:9273
Change-Id: Id0e939a51d1e381f684a3ae970569a255f52a5bb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214101
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33661}
There is only one NTP clock now.
Bug: webrtc:11327
Change-Id: I8c2808cf665f92bd251d68e32062beeffabb0f43
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214132
Commit-Queue: Paul Hallak <phallak@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33657}
Note: google3 needs to set this clock before we can start using it.
Bug: webrtc:11327
Change-Id: I0436c6633976afe208f28601fdfd50e0f6f54d6e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214480
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Paul Hallak <phallak@google.com>
Cr-Commit-Position: refs/heads/master@{#33653}
This helper method does not belong to the Clock class. Also, it's simple enough that it's not needed.
Bug: webrtc:11327
Change-Id: I95a33f08fd568b293b591171ecaf5e7aef8d413c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214123
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Commit-Queue: Paul Hallak <phallak@google.com>
Cr-Commit-Position: refs/heads/master@{#33652}
Done in preparation for the child CL which adds an alternative
implementation.
Bug: webrtc:7494
Change-Id: I4963376afc917eae434a0d0ccee18f21880eefe0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214125
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33646}
...though the big issue was probably that pending frames weren't being
culled properly in the case of frame dropping.
Bug: webrtc:12596
Change-Id: I9a03282b2a99087aa7c5650e57ce30fe0f0d3036
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214127
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33638}
Code style improvements done in preparation for a bug fix (TODO added)
which requires changes in the unit tests.
Note that one expected value in the unit tests has been adjusted since
the white noise generator is now instanced in each separate test and
therefore, even if the seed remained the same, the generated sequences
differ.
Bug: webrtc:7494
Change-Id: I497513b84f50b5c66cf6241a09946ce853eb1cd2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214122
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33636}
While debugging https://crbug.com/1195144 I found it useful to clarify
this log statement.
The log would say "When scaling [kNative], the image was unexpectedly
converted to [kI420]..." but not saying what it was trying to convert
it to. This CL adds: "... instead of [kNV12]."
Bug: chromium:1195144
Change-Id: I13e0040edf5d7d98d80ce674812f67dfb73be36e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214040
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33634}
This is a reland of 89cb65ed663a9000b9f7c90a78039bd85731e9ae
... and f28aade91dcc2cb8f590dc1379ac7ab5c1981909
... and 2072b87261a6505a88561bdeab3e7405d7038eaa
Reason for revert: Failing DuoGroupsMediaQualityTest due to missing
TaskQueuePacedSender::EnsureStarted() in google3.
Fix: This CL adds the logic behind TaskQueuePacedSender::EnsureStarted,
but initializes with |is_started| = true. Once the caller in google3 is
updated, |is_started| can be switched to false by default.
> Original change's description:
> Reason for revert: crashes due to uninitialized pacing_bitrate_
> crbug.com/1190547
> Apparently pacer() is sometimes being used before EnsureStarted()
> Fix: Instead of delaying first call to SetPacingRates(),
> this CL no-ops MaybeProcessPackets() until EnsureStarted()
> is called for the first time.
> Original change's description:
> > [Battery]: Delay start of TaskQueuePacedSender.
> >
> > To avoid unnecessary repeating tasks, TaskQueuePacedSender is started
> > only upon RtpTransportControllerSend::EnsureStarted().
> >
> > More specifically, the repeating task happens in
> > TaskQueuePacedSender::MaybeProcessPackets() every 500ms, using a self
> > task_queue_.PostDelayedTask().
> >
> > Bug: chromium:1152887
> > Change-Id: I72c96d2c4b491d5edb45a30b210b3797165cbf48
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208560
> > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33421}
>
> Bug: chromium:1152887
> Change-Id: I9aba4882a64bbee7d97ace9059dea8a24c144f93
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212880
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#33554}
Bug: chromium:1152887
Change-Id: Ie365562bd83aefdb2757a65e20a4cf3eece678b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213000
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33629}
libaom is compiled with REALTIME_ONLY option. Soon it will be impossible
to create encoder or request default config with usage other than
AOM_USAGE_REALTIME. Fixing the wrapper to use proper usage parameter
Bug: None
Change-Id: I862741a724e4a8524f22ae79700b3da6517dbfb2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214100
Commit-Queue: Fyodor Kyslov <kyslov@google.com>
Reviewed-by: Marco Paniconi <marpan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33624}
This change adds basic support for setting codecType kVideoCodecAV1 in
VCMEncodedFrames.
Bug: chromium:1191972
Change-Id: I258b39ff89c8b92ebbb288ef32c88b900a35d10e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213182
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33594}
This reverts commit c184047fef005b86a6dd76f03b0eb5ec01de3c5c.
Reason for revert: Breaks the WebRTC->Chromium roll:
ERROR Unresolved dependencies.
//third_party/webrtc/test/fuzzers:vp9_encoder_references_fuzzer(//build/toolchain/win:win_clang_x64)
needs //third_party/webrtc/modules/video_coding:mock_libvpx_interface(//build/toolchain/win:win_clang_x64)
We need to add tryjob to catch these. The fix is to make
//third_party/webrtc/modules/video_coding:mock_libvpx_interface
visible in built_with_chromium builds by moving the target
out of this "if" https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/modules/video_coding/BUILD.gn;l=615;drc=3889de1c4c7ae56ec742fb9ee0ad89657f638169.
Original change's description:
> Add fuzzer to validate libvpx vp9 encoder wrapper
>
> Fix simulcast svc controller to reuse dropped frame configuration,
> same as full svc and k-svc controllers do.
> This fuzzer reminded the issue was still there.
>
> Bug: webrtc:11999
> Change-Id: I74156bd743124723562e99deb48de5b5018a81d0
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212281
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33568}
TBR=danilchap@webrtc.org,sprang@webrtc.org
Change-Id: I1676986308c6d37ff168467ff2099155e8895452
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11999
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212973
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33573}
Fix simulcast svc controller to reuse dropped frame configuration,
same as full svc and k-svc controllers do.
This fuzzer reminded the issue was still there.
Bug: webrtc:11999
Change-Id: I74156bd743124723562e99deb48de5b5018a81d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212281
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33568}
This reverts commit 2072b87261a6505a88561bdeab3e7405d7038eaa.
Reason for revert: Causing test failure.
Original change's description:
> Reland "[Battery]: Delay start of TaskQueuePacedSender." Take 2
>
> This is a reland of 89cb65ed663a9000b9f7c90a78039bd85731e9ae
> ... and f28aade91dcc2cb8f590dc1379ac7ab5c1981909
>
> Reason for revert: crashes due to uninitialized pacing_bitrate_
> crbug.com/1190547
> Apparently pacer() is sometimes being used before EnsureStarted()
> Fix: Instead of delaying first call to SetPacingRates(),
> this CL no-ops MaybeProcessPackets() until EnsureStarted()
> is called for the first time.
>
> Original change's description:
> > [Battery]: Delay start of TaskQueuePacedSender.
> >
> > To avoid unnecessary repeating tasks, TaskQueuePacedSender is started
> > only upon RtpTransportControllerSend::EnsureStarted().
> >
> > More specifically, the repeating task happens in
> > TaskQueuePacedSender::MaybeProcessPackets() every 500ms, using a self
> > task_queue_.PostDelayedTask().
> >
> > Bug: chromium:1152887
> > Change-Id: I72c96d2c4b491d5edb45a30b210b3797165cbf48
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208560
> > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33421}
>
> Bug: chromium:1152887
> Change-Id: I9aba4882a64bbee7d97ace9059dea8a24c144f93
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212880
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#33554}
TBR=hbos@webrtc.org,sprang@webrtc.org,etiennep@chromium.org
Change-Id: I430fd31c7602702c8ec44b9e38e68266abba8854
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1152887
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212965
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Commit-Queue: Ying Wang <yinwa@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33559}
This is a reland of 89cb65ed663a9000b9f7c90a78039bd85731e9ae
... and f28aade91dcc2cb8f590dc1379ac7ab5c1981909
Reason for revert: crashes due to uninitialized pacing_bitrate_
crbug.com/1190547
Apparently pacer() is sometimes being used before EnsureStarted()
Fix: Instead of delaying first call to SetPacingRates(),
this CL no-ops MaybeProcessPackets() until EnsureStarted()
is called for the first time.
Original change's description:
> [Battery]: Delay start of TaskQueuePacedSender.
>
> To avoid unnecessary repeating tasks, TaskQueuePacedSender is started
> only upon RtpTransportControllerSend::EnsureStarted().
>
> More specifically, the repeating task happens in
> TaskQueuePacedSender::MaybeProcessPackets() every 500ms, using a self
> task_queue_.PostDelayedTask().
>
> Bug: chromium:1152887
> Change-Id: I72c96d2c4b491d5edb45a30b210b3797165cbf48
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208560
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33421}
Bug: chromium:1152887
Change-Id: I9aba4882a64bbee7d97ace9059dea8a24c144f93
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212880
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33554}
Follow-up CL to VP8 and VP9 encoders taking care of mapping.
Context again:
This CL is part of Optimized Scaling efforts. In Chromium, the native
frame buffer is getting an optimized CropAndScale() implementation. To
support HW accelerated scaling, returning pre-scaled images and skipping
unnecessary intermediate downscales, WebRTC needs to 1) use CropAndScale
instead of libyuv::XXXXScale and 2) only map buffers it actually intends
to encode.
In this CL, VideoStreamEncoder no longer calls GetMappedFrameBuffer() on
behalf of the encoders, since the encoders are now able to either do the
mapping or performs ToI420() anyway.
- Tests for old VSE behaviors are updated to test the new behavior (i.e.
that native frames are pretty much always forwarded).
- The "having to call ToI420() twice" workaround to Android bug
https://crbug.com/webrtc/12602 is added to H264 and AV1 encoders.
Bug: webrtc:12469
Change-Id: Ibdc2e138d4782a140f433c8330950e61b9829f43
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211940
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#33548}
`RTCInboundRtpStreamStats.lastPacketReceivedTimestamp` must be a time
value in milliseconds with Unix epoch as time origin (see
bugs.webrtc.org/12605#c4).
This change fixes both audio and video `RTCInboundRtpStreamStats` stats.
Tested: verified from chrome://webrtc-internals during an appr.tc call
Bug: webrtc:12605
Change-Id: I68157fcf01a5933f3d4e5d3918b4a9d3fbd64f16
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212865
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33547}
This will further speed up intra frame encoding
Bug: None
Change-Id: I3c836502cdcb1037e3128850a085b92acd8fc7ad
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212821
Reviewed-by: Marco Paniconi <marpan@webrtc.org>
Commit-Queue: Fyodor Kyslov <kyslov@google.com>
Cr-Commit-Position: refs/heads/master@{#33544}
This patch adds support for sending zero video layer allocations
header extensions. This can be used to signal that a stream is
turned off.
Bug: webrtc:12000
Change-Id: Id18fbbff2216ca23179c58ef7bbe2ebea5e242af
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212743
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33541}
This is a follow-up to the VP9, fixing VP8 this time. Context again:
This CL is part of Optimized Scaling efforts. In Chromium, the native
frame buffer is getting an optimized CropAndScale() implementation. To
support HW accelerated scaling, returning pre-scaled images and skipping
unnecessary intermediate downscales, WebRTC needs to 1) use CropAndScale
instead of libyuv::XXXXScale and 2) only map buffers it actually intends
to encode.
- To achieve this, WebRTC encoders are updated to map kNative video
buffers so that in a follow-up CL VideoStreamEncoder can stop mapping
intermediate buffer sizes.
Bug: webrtc:12469, chromium:1157072
Change-Id: I026527ae77e36f66d02e149ad6fe304f6a8ccb05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212600
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#33537}
Namespace used because of copy-pasting an old pattern, should never have been used in the first place. Removing it now to make followup refactoring prettier.
Bug: webrtc:12579
Change-Id: I00a80958401cfa368769dc0a1d8bbdd76aaa4ef5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212603
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33536}
