Also updated the test to cover IsTemporalLayersSupported() for all types
of codecs.
Bug: chromium:41480904
Change-Id: I25788a87737aba7308b1d6980ad5b2c26b0e225f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367570
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43369}
The std::lcm and std::gcd functions are part of the C++ standard
library. The existing functions are marked as deprecated rather than
deleted in the case of possible third party uses.
#rtc_cleanup
Bug: webrtc:377205743
Change-Id: I174e663f152d750c984a35dc7136bc18dc01bc8e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367440
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Auto-Submit: Evan Shrubsole <eshr@google.com>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43368}
The tests shows that using a scale factor around 0.5 gives the best precision and F1 score.
Bug: webrtc:358039777
Change-Id: I22557eb9e6318ecaa726b56d3ccb2125fdf65f7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367681
Reviewed-by: Fanny Linderborg <linderborg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Cr-Commit-Position: refs/heads/main@{#43366}
Cleanup some of the TODOs for H.265. They are either invalid or their handling should be merged with other codec types.
Bug: chromium:41480904
Change-Id: I76263354b1b87035e240d77283b21a9a26dcb45b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366044
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43359}
These function were replaced with AbslStringify
Bug: None
Change-Id: Ia34b98ed4e0ed18bb52fe9370cff7a6f70caae6d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364621
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43346}
After landing this change, we can change the corresponding usage in
blink to start using presentation_timestamp as well and then delete
the remaining usage of capture_time_identifier.
Bug: webrtc:373365537
Change-Id: I0c4f2b6b3822df42d6e3387df2c243c3684d8a41
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365640
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Palak Agarwal <agpalak@google.com>
Cr-Commit-Position: refs/heads/main@{#43317}
This is a reland of commit 82617ac51e7825db53451818f4d1ad52b69761fd
The reason for the revert was a downstream use of
`rtc::VideoSinkWants::requested_resolution`, so in this reland we don't
rename this field, it's fine just to rename the one in
RtpEncodingParameters for now.
Original change's description:
> Rename `requested_resolution` to `scale_resolution_down_to`.
>
> This is a pure refactor/rename CL without any changes in behavior.
>
> This field is called scaleResolutionDownTo in the spec and JavaScript.
> Let's make C++ match to avoid confusion.
>
> In order not to break downstream during the transition a variable with
> the old name being a pure reference to the renamed attribute is added.
> This means we have to add custom constructors, but we can change this
> back to "= default" when the transition is completed, which should only
> be a couple of CLs away.
>
> Bug: webrtc:375048799
> Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43300}
NOTRY=True
Bug: webrtc:375048799
Change-Id: Ic4ee156c1d50aa36070a8d84059870791dcbbe5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366660
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43304}
When switching between payload types on same ssrc, a HW decoder is only
used the first payload type received, falling back to SW decoding if
payload type is changed.
This change unregister any external decoder previously registered so it
can be re-initialized if received again.
Bug: webrtc:375097852
Change-Id: Ic04951c5676d9a3854eefb2ab8836ef8a2645d78
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366580
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43302}
This reverts commit 82617ac51e7825db53451818f4d1ad52b69761fd.
Reason for revert: Break downstream projects
Original change's description:
> Rename `requested_resolution` to `scale_resolution_down_to`.
>
> This is a pure refactor/rename CL without any changes in behavior.
>
> This field is called scaleResolutionDownTo in the spec and JavaScript.
> Let's make C++ match to avoid confusion.
>
> In order not to break downstream during the transition a variable with
> the old name being a pure reference to the renamed attribute is added.
> This means we have to add custom constructors, but we can change this
> back to "= default" when the transition is completed, which should only
> be a couple of CLs away.
>
> Bug: webrtc:375048799
> Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43300}
Bug: webrtc:375048799
Change-Id: Ie41723a39420e12e7b5b681d3d00ccd14f66b4b1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366642
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#43301}
This is a pure refactor/rename CL without any changes in behavior.
This field is called scaleResolutionDownTo in the spec and JavaScript.
Let's make C++ match to avoid confusion.
In order not to break downstream during the transition a variable with
the old name being a pure reference to the renamed attribute is added.
This means we have to add custom constructors, but we can change this
back to "= default" when the transition is completed, which should only
be a couple of CLs away.
Bug: webrtc:375048799
Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43300}
danilchap@webrtc.org suggested to add a converter for NtpTime <-> UTC Timestamp for in https://webrtc-review.googlesource.com/c/src/+/365641.
This CL add a NtpTime -> UTC Timestamp in Clock, and change code to start to use the new function.
Bug: None
Change-Id: If4af6cb8e31c1731692edfb8358e67b7a43226a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366001
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43293}
This adds a Call-based test, that sets up video-pipeline with a VP8
encoder and the corruption detection header extension configured.
It then verifies that the corruption likelihood metrics are populated
in the receive stream stats.
Bug: webrtc:358039777
Change-Id: Ide005459a801778de4238e786f13efc8c3245f3f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365860
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Auto-Submit: Fanny Linderborg <linderborg@webrtc.org>
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43254}
We should use the Timestamp type, rather then int64, to store timestamps. In https://webrtc-review.googlesource.com/c/src/+/365001/ an additional int64 timestamp was added (last_sender_report_timestamp_ms).
This CL fixes the new timestamp, as well as other similar timestamps in MediaReceiverInfo (last_sender_report_utc_timestamp_ms and last_sender_report_remote_utc_timestamp_ms).
Bug: webrtc:372393493
Change-Id: I0e473730e85a69ec595b421e2c3db920364008eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365641
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43248}
The split shows that some places don't need it at all. Most other
places will depend on both send and receive stream targets.
Bug: webrtc:373151158
Change-Id: I788136a2ee84180c16345a7929b7f7bf3f97507b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365460
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43230}
With this changes users can calculate the corruption score on two frames e.g. in test scenarios where one has access to the input and output file.
Bug: webrtc:358039777
Change-Id: Id864010115aa040284ec09b42d0279ccb45960b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364161
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Fanny Linderborg <linderborg@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Cr-Commit-Position: refs/heads/main@{#43222}
This is to make the name consistent with the other methods in the
interface and additionally to in the future not have a function that has
the same name as the `FrameToRender` struct.
Bug: webrtc:358039777
Change-Id: Iac727d93ab9e020a073477bd33d0f67f9983a0aa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364961
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Auto-Submit: Fanny Linderborg <linderborg@webrtc.org>
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43195}
I missed one timestamp in https://webrtc-review.googlesource.com/c/src/+/363946, meaning that the config flag that was added do not yet work for all timestamps in RTCStats objects. The RTCRemoteOutboundRtpStreamStats still has UTC timestamps even if the config flag is set.
I will solve this by saving both an UTC (existing) and env (to be added) timestamp, and then let rtc_stats_collector choose timestamp based on the value of the config flag (just like RTCRemoteInboundRtpStreamStats is done in the 363946 commit).
Before adding the new env_ timestamp I want to make this change. I rename the existing timestamp to show what epoch it uses (NTP or UTC). This will later make it clear which timestamp is which.
So this CL will make no logical change, just renaming members.
I only need to rename the last_sender_report_timestamp_ms, but opted to rename the remote timestamp as well, to be consistent with the naming convention I add in this CL.
Bug: chromium:369369568
Change-Id: Icfe7cf274995b39799e1478a1bb8cdf5134f0b16
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364782
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43194}
This is a reland of commit 01f91c81f7660be842fa44e96bf804a8b2402f47
Original change's description:
> Add a FrameToRender argument struct as input to FrameToRender
>
> This is to make it easier to add new arguments to the method in the
> future. We will remove the already existing method accordingly to WebRTCs deprecation rules.
>
> Bug: webrtc:358039777
> Change-Id: Id0706de5216fbd0182cac80ebfccfc4a6a055ee8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364642
> Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Auto-Submit: Fanny Linderborg <linderborg@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43181}
Bug: webrtc:358039777
Change-Id: I404bb9660d9f4436c0658814fd3ac7d74e483f0f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364900
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43188}
This reverts commit 01f91c81f7660be842fa44e96bf804a8b2402f47.
Reason for revert: break downstream projects.
Original change's description:
> Add a FrameToRender argument struct as input to FrameToRender
>
> This is to make it easier to add new arguments to the method in the
> future. We will remove the already existing method accordingly to WebRTCs deprecation rules.
>
> Bug: webrtc:358039777
> Change-Id: Id0706de5216fbd0182cac80ebfccfc4a6a055ee8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364642
> Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Auto-Submit: Fanny Linderborg <linderborg@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43181}
Bug: webrtc:358039777
Change-Id: Id59633023a428fb63aadeb266421b09040e590bb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364841
Owners-Override: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#43184}
This is to make it easier to add new arguments to the method in the
future. We will remove the already existing method accordingly to WebRTCs deprecation rules.
Bug: webrtc:358039777
Change-Id: Id0706de5216fbd0182cac80ebfccfc4a6a055ee8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364642
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Auto-Submit: Fanny Linderborg <linderborg@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43181}
In simulcast, BW adaptation causes layers to be disabled rather than
downscaling layers. But CPU adaptation restricts the resolution of all
layers, this means that a 540p restriction on 180p:360p:720p results in
180p:360p:540p, which is fine but a) it's inconsistent with BW
adaptation and b) it's not ideal for performance, because non power of
two scaling factors means we can't use a single encoder instance to
produce all layers (the CPU adaptation could actually result in even
more CPU usage and further adaptation as a result).
This CL disables top layers by limiting `max_num_layers` based on
`restrictions_` and the layers' `requested_resolution`, the end result
is 180p:360p:- when CPU adaptation kicks in.
Note that the problem described (and therefore the solution) is
specific to the `requested_resolution` API. If instead the
`scale_resolution_down_by` API is used, all scaling is relative and we
get 135p:270p:540p, which is problematic for other reasons (180p and
360p no longer sent, middle layer no longer HW accelerated).
Bug: webrtc:366415118
Change-Id: I2e238b1b87470413c21623b21d0ce20eadf6c8c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364660
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43172}
Add media config for using environment monotonic timestamps (i.e. not UTC) in RTCStats constructor, and implemented the usage of the flag.
Bug: chromium:369369568
Change-Id: Ia93d048742c28af201164fe7b2152b791bb6d0b6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363946
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Cr-Commit-Position: refs/heads/main@{#43156}
Setting the standard deviation to 0 is valid and should be interpreted
as directly using the sample value at the coordinates without weighting.
This is made explicit in the documentation for the Corruption Detection
extension:
http://www.webrtc.org/experiments/rtp-hdrext/corruption-detection
Also, change stddev to std_dev in halton_frame_sampler files.
Bug: webrtc:358039777
Change-Id: Id5aa4110194f7f2b2fe9914c94304c90afd64198
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363300
Auto-Submit: Fanny Linderborg <linderborg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43070}
The code that restricts the maximum number of simulcast layers based on
resolution is a spec-compliance bug and doesn't make much sense: if the
app asks for 3 layers it should get 3 layers. Since the app knows the
size of the track, it could very easily ask for 1 layer when resolution
is small if that is the behavior it wanted. If the app doesn't ask to
disable layers, WebRTC shouldn't disable layers on its behalf.
This behavior makes even less sense with this "new" API since the app
is explicitly controlling the send resolution in absolute terms.
Removing this behavior in the general case is out of scope since it
would break backwards compatibility, but since `requested_resolution`
has not been exposed to the web yet and existing usage is small, this
is an opportunity to fix the compliance bug for this API.
This CL makes the last web platform test for "scaleResolutionDownTo"
pass.
Bug: chromium:363544347
Change-Id: Ic6fadf3cad69d3beec4ae03d3d031e8062382ad9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363100
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43061}
The FrameInstrumentationGenerator is responsible for generating the
instrumentation data that will be used to detect corruption. The data is
then passed to the encoder in the CodecSpecificInfo.
Bug: webrtc:358039777
Change-Id: I79d0534920b4c7fa001e1138371dfd36c13424fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362584
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43060}
This class calculates the corruption score based on the given samples from two frames.
Bug: webrtc:358039777
Change-Id: Ib036f91ec16609e827137cc35d342a2c49764737
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362801
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Fanny Linderborg <linderborg@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Cr-Commit-Position: refs/heads/main@{#43043}
For key frames: increase the sequence index until the last 7 bits are
all zeroes. If this results in an overflow, wraparound to 0.
Also:
* Allow setting and getting the sequence index
* Allow getting LayerId
Bug: webrtc:358039777
Change-Id: Ibe16689a3d1eb5706d4fce5c9220770046f26896
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362540
Reviewed-by: Erik Språng <sprang@webrtc.org>
Auto-Submit: Fanny Linderborg <linderborg@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43042}
The `requested_resolution` API must not change aspect ratio, example:
- Frame is 60x30
- Requested is 30x30
- We expect 30x15 (not 30x30!) as to maintain aspect ratio.
This bug was previously fixed by making VideoAdapter unaware of the
requested resolution behind a flag: this seemed OK since the
VideoStreamEncoder ultimately decides the resolution, whether or not
the incoming frame is adapted.
But this is not desired for some non-Chrome use cases. This CL attempts
to make both Chrome and non-Chrome use cases happy by implementing the
aspect ratio preserving restriction inside VideoAdapter too.
This allows us to get rid of the "use_standard_requested_resolution"
flag and change the "VideoStreamEncoderResolutionTest" TEST_P to
TEST_F.
Bug: webrtc:366067962, webrtc:366284861
Change-Id: I1dfd10963274c5fdfd18d0f4443b2f209d2e9a4b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362720
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43037}
The recently added tests resulted in some .log file on some bots being
too long:
video_engine_tests_exe-VideoStreamEncoderStandardOrLegacyRequestedResolutionTest_VideoStreamEncoderStandardOrLegacyRequestedResolutionTest_RequestedResolutionInWrongAspectRatioAndSourceIsAdapting_0-1.log
This CL makes the test names significantly shorter.
# Trivial and believed to fix purple bots, let's land ASAP
NOTRY=True
Bug: webrtc:367066321
Change-Id: I831911947af9d5639d1edb559470f1c9ae702d6e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362721
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43030}
When requested_resolution uses a different aspect ratio than the source
the encoder will restrict the frame without changing its aspect ratio,
e.g. a 60x30 input frame that is restricted to 30x30 results in 30x15,
not 30x30.
While this logic works correctly in isolation, if the source also adapts
the frame size based on the sink_wants.requested_resolution that is
signaled back to the source, then the source will produce stretched
30x30 prior to the encoder which happily sends 30x30 not knowing any
wiser.
This is incompatible with the spec[1] and makes this WPT[2] fail. The
correct behavior is to NOT signal the requested_resolution back to the
source, the encoder already configures the correct resolution so this
isn't actually needed and the source shouldn't need to know this API.
In order not to break downstream projects, the new behavior is landed
behind a flag and both behaviors are tested with TEST_P.
This unblocks launching scaleResolutionDownTo API on Web. Migrating
from old to new code path and deleting the flag is a follow-up AI:
webrtc:366284861.
[1] https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-scaleresolutiondownto
[2] https://chromium-review.googlesource.com/c/chromium/src/+/5853944
# Relying on previous green runs for confidence due to purple bots atm,
# see b/367211396
NOTRY=True
NOPRESUBMIT=True
Bug: webrtc:366067962, webrtc:366284861
Change-Id: I7fd1016e9cc6f0b0b9b8c23b0708e521f8e12642
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362541
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43024}
This API should not modify the aspect ratio of the frame, e.g. if the
frame is 1280x720 and requested_resolution is 1280x360, the result
should be 640x360, not a streched out 1280x360 frame. The spec version
of this API calls this "maxWidth" and "maxHeight" which is the right
way to think about it rather than a forced width and height.
VideoAdapter continues to be used to apply adaptation restrictions, but
we now make sure to calculate the correct frame size BEFORE applying
restrictions. Prior to this CL, the VideoAdapter was also used to apply
requested_resolution restrictions. This is actually wrong and would
cause strange scaling factors in some cases, e.g. f=1280x720 + r=720x405
would result in 640x360 instead of 720x405. Now we make f=720x405 first
and only adjust further if restrictions or alignments require us to.
Since this is a change in behavior a WebRtcVideoChannelTest is updated.
Encodings integration test is also added, both for aspect ratio (new
behavior) and orientation agnosticism (old behavior still passing).
Bug: webrtc:366067962
Change-Id: I4e8dc27da5a84d73238b8ab74ef197eb5ee8072a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362101
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43020}
