Currently the min of the default bitrate and configured bitrate is used.
Add default bitrate limits for 1080p.
Bug: b/396641469
Change-Id: Iabf243627a6dcbaa1e2f14d4f201c9482f3958d5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377123
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43923}
and switch usages to ByteBufferWriter::Write
This is part of getting rid of "pointer + length" arguments.
Bug: webrtc:42225170
Change-Id: I65a9b9550868022c0eb1f63b547195dadfbea678
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377461
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43916}
Sometimes the blurred value gets to be a little above 255 because of
floating point errors. This prevents the header from being sent, losing
1 second of information. This can easily be prevented with the changes
in this CL.
Bug: webrtc:358039777
Change-Id: Ibad1c8f41272260e28fe58557c623e52a6af8294
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376740
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Cr-Commit-Position: refs/heads/main@{#43906}
At some point this code path was used for the
WebRTC-VP8ConferenceTemporalLayers experiment, but that has been
deleted.
The API does not allow creating more than 3 temporal layers so this
should be dead code and deleting it causes no test failures.
Bug: None
Change-Id: Ie13bc09a7af996d081ab5702d1bb8d17c6021ce4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377300
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43900}
Update to use similar bitrate limits as VP9, depending on whether QP
from encoder is trusted or not.
Bug: chromium:392060821
Change-Id: I305182fecf7acfe84dbd2e049f9ce712a7a30ede
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376762
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43898}
This field trial was enabled by default for a long while.
Bug: webrtc:42234783
Change-Id: If050f88a3649c43d895110f4f68160f020f854e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376421
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43885}
This is a reland of commit 1ad3e14e9981772554a848c5034c7c555680aef7
The original CL removes all sending streams since all codec types has
been attempted for encoding and we have no other codecs to fallback to.
However some downstream applications will still attempt to set the codec
preferences even all send streams have been removed.
As a result, we follow previous logic to keep the send streams, to avoid
the regression.
Original change's description:
> Follow codec preference order for sending codec fallback.
>
> When encoder selector is not enabled, currently we always fallback to
> VP8 no matter how the codec preference is setup. Update to follow codec
> preference order for the fallback.
>
> Bug: chromium:378566918
> Change-Id: Ia3fbfc9d407683ef7b3d6246af7e9ec58535dc89
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370707
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43566}
Bug: chromium:378566918, b/384725754
Change-Id: Ifd48b30b80ae51c3ede9391ed62e8ce408864aa0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374852
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43874}
That accessor forces test helpers to create BasicPortAllocator themself
rather than deligate such task to PeerConnectionFactory
Bug: webrtc:42232556
Change-Id: I262e032da110222198e6308f57a5e5f2d7ba4601
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376741
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43870}
Now that there is not requirement of base-heavy for H.265 simulcast, it
should follow VP9 on simulcast bitrate allocations per stream.
Bug: chromium:392060821
Change-Id: I245def7f27022a943a31e96a51552db7505b7546
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376620
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43865}
This CL fixes two issues with the old way targetBitrate was reported:
1. The target is per encoder, i.e. per SSRC, but the old way to report
it was per sender and was approximately the sum of all encodings'
targetBitrate in most cases.
2. The old value did not come directly from the VideoBitrateAllocation
and tended to be greater than the sum of all targets (don't know
why).
We know the old value was wrong and the new value correct because
the actual bytes produced by the encoder closely matches the configured
target, which wasn't always the case with the old metric implementation.
Tested with unit tests and manually in Chrome by going to
https://henbos.github.io/codec-quality/src/index.html and ensuring
target ~= actual bytes produced. It also matches the debug logging of
video_stream_encoder.cc.
Bug: webrtc:42225524, chromium:392424845
Change-Id: I7a6f69e053ebc3fd972c2c4b7712750e721c0acc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376460
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43854}
There can be error log each frame when maximum playout delay sent with the frame exceed delay derived from the av-sync.
In such scenario prefer to limit the playout delay by the one attached to the received frame.
Bug: b/390043766
Change-Id: Ia57969df72f7a649e5a9280d5bb29986f5ea14b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374284
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43814}
This change resolves an issue that arises when there is a gap in the
sequence numbers of packets associated with a single frame.
Before this change, the H26x packet buffer could potentially assemble a
frame using only a subset of the packets in the buffer if a packet was
missing in the middle and a packet with a marker bit arrived.
To address this, the change introduces a check before assembling a
frame. This ensures that all packets belonging to a single frame are
correctly collected by iterating backward until the first packet in the
frame is identified.
Bug: webrtc:384391181
Change-Id: I4d09a3d6d569624ece204264cb32e5076ed090a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374183
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Jianlin Qiu <jianlin.qiu@intel.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43793}
Before this CL VP8 and AV1 used the same max QP=56. Tests show that at this QP AV1 delivers a worse PSNR than VP8. We want AV1 min quality to be not worse than VP8. This CL reduces the default max QP for AV1 to 52. With this value libaom AV1 encoder delivers PSNR close to libvpx VP8 at QP 56.
Bug: webrtc:351644568, b/369540380
Change-Id: I2e27ddab562f9c9710b11dc09076b03d7b308bb0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374041
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43751}
This reverts commit 1ad3e14e9981772554a848c5034c7c555680aef7.
Reason for revert: Breaks downstream project. We are investigating into a potential problem when running on mobile platforms. We will get back with info or reland.
Original change's description:
> Follow codec preference order for sending codec fallback.
>
> When encoder selector is not enabled, currently we always fallback to
> VP8 no matter how the codec preference is setup. Update to follow codec
> preference order for the fallback.
>
> Bug: chromium:378566918
> Change-Id: Ia3fbfc9d407683ef7b3d6246af7e9ec58535dc89
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370707
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43566}
Bug: chromium:378566918
Change-Id: I09086b5ad100a8f66e87df167e903d0b5fe5b589
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/372080
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43600}
When encoder selector is not enabled, currently we always fallback to
VP8 no matter how the codec preference is setup. Update to follow codec
preference order for the fallback.
Bug: chromium:378566918
Change-Id: Ia3fbfc9d407683ef7b3d6246af7e9ec58535dc89
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370707
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43566}
This reverts commit 200fd82771ae29d23b2be40194be674b3437f0ab.
Reason for revert: breaks downstream
Original change's description:
> Validate frame consistency when writing DependencyDescriptor
>
> To write DependencyDescriptor frame properties should be consistent with
> the FrameDependencyStructure.
> Historically that was ensured by webrtc codec wrappers, but with with frame transform api interface there are now more ways to inject video frame for packetizing.
> Thus DependencyDescriptorWriter should be more protective to avoid crashes.
>
> Bug: chromium:379282549
> Change-Id: I98f226ff09c32154e18888c8e811e7981567ad45
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/371301
> Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
> Reviewed-by: Åsa Persson <asapersson@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43551}
Bug: chromium:379282549
Change-Id: I7711756f774648cbb85c51b61424bb950c1d3775
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/371420
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Owners-Override: Jeremy Leconte <jleconte@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#43556}
To write DependencyDescriptor frame properties should be consistent with
the FrameDependencyStructure.
Historically that was ensured by webrtc codec wrappers, but with with frame transform api interface there are now more ways to inject video frame for packetizing.
Thus DependencyDescriptorWriter should be more protective to avoid crashes.
Bug: chromium:379282549
Change-Id: I98f226ff09c32154e18888c8e811e7981567ad45
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/371301
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43551}
Previous CLs that disabled the rtc_enable_libevent build flag
did not reveal issues. Now continue to remove the source code for
the task queue.
Bug: webrtc:42224654
Change-Id: I0866b4b56f0a8d8b56a5b604c31a426d77ab8d04
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370801
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43550}
The `FrameToRender` method is deprecated and has been replaced by
`OnFrameToRender`.
Bug: webrtc:358039777
Change-Id: Ibe56bd43cf045d814137ba8c4374bc9b9ce8ef6c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/371302
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43547}
This is to fix build error when we set use_libcxx_modules=true in
chromium build.
Bug: chromium:40440396
Change-Id: I5ab1cfcc0d060021892aae0e5ff3f0b647ae4266
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370860
Commit-Queue: Takuto Ikuta <tikuta@google.com>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Auto-Submit: Takuto Ikuta <tikuta@google.com>
Cr-Commit-Position: refs/heads/main@{#43541}
Without this, Firefox wasn't passing WPT
webrtc/simulcast/setParameters-maxFramerate.https.html.
The main issue is the SetRates API's RateControlParameters doesn't have
a way to model maxFramerate for simulcast layers.
A long term fix would probably be to represent maxFramerate for all
simulcast layers in RateControlParameters. This change is a short term
fix, and resets the encoder iff a simulcast layer's maxFramerate has
changed, and also differs from the maxFramerate of the codec (passed to
SetRates), which matches the layer with the highest maxFramerate.
Bug: None
Change-Id: I088dda0fe88092fe5a5cc61114e10847f072a87b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370124
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43497}
In addition, avoid empty conversion when no message is present.
Bug: chromium:379326016
Change-Id: I855069fa89a157ba862b5162c56858825ebc1a40
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370160
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43487}
Rewrites some of the logic to better takine account RTX padding and
potential acking from transport cc. This should make it both more
robust and a bit faster.
Bug: webrtc:381216373
Change-Id: I1a395c6bd86445ba3e63d79bdc766c7ff582e2a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370060
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43483}
`VideoStreamEncoder` should not recreate the
`FrameInstrumentationGenerator` instace unless the encoder is actually
released. Otherwise it will restart and expect a keyframe the encoder
will likely not produce for a while.
Bug: webrtc:358039777
Change-Id: I111149d5e9b632df9eeb88bbbe8a07969c3e3f1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/369740
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43468}
For H.265 when scalability mode is not configured for simulcast layers,
the default mode of L1T1 should be assumed instead of L1T3, as that is
the most commonly supported temporal scalability on all devices for
H.265.
Bug: chromium:41480904
Change-Id: Ia9bc91729eb393850dfe5e8fb04280b4f784560d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/369080
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43452}
This is a prerequisite for enabling implementation-specific filter
settings for automatic corruption detection.
Bug: webrtc:358039777
Change-Id: I363c592aa35164f690dd4ad1204e90afc0277d8b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368940
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43443}
In particular, some platforms have a limited pool of frames in the
capturer stack, so we need to avoid stashing raw frames in the frame
instrumentation generator that may be dropped by limiting the size of
the queue and avoid putting anything in there until we know we will
send it to the encoder.
Bug: webrtc:358039777
Change-Id: I054ae53dd5e6ac6a22da39c5049f47788561e77a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368641
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43432}
This seems to have no effect on tests, so it appears that these were
not used after all.
The goal is to make transport-cc a media-section-level attribute.
Bug: webrtc:378698658
Change-Id: Ia20ca5b91472b02db30f911ad1a1892cf36cd682
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368440
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43411}
H.265 should have limits probably between VP9 and AV1, instead of using
VP8 tables. For now we reuse VP9 tables but eventually we may create
table for H.265.
Bug: chromium:41480904
Change-Id: I6dc2ec629142ee06f1c82a2df30d753ec1353496
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368240
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#43404}
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}
