The simulcast allocator would only set bitrates for the first 2 layers
in conference_screenshare_mode.
That would trigger an issue in the VP8 encoder initialization that expects
to have growing bitrates for the layers (3rd layer would have the same
bitrate as the 2nd one).
Bug: webrtc:8785
Change-Id: Ic6c940b78022387841b28074b373be6b2f45cb15
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145922
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28598}
This partially reverts these 2 CLs:
1) Reland "Copy video frames metadata between encoded and plain frames in one place"
https://webrtc.googlesource.com/src/+/2ebf5239782bf6b46d4aa812f34fa9f9e5a02be9
2) Don't copy video frame metadata in each encoder/decoder
https://webrtc.googlesource.com/src/+/ab62b2ee51e622be6d0aade15e87e927fa60e6f2
The problem with them were that ColorSpace was made to always be copied from the
EncodedImage in the GenericDecoder, which overwrote ColorSpace information from
the decoder.
If decoder applied color space transition or bitstream color space information
was different from the WebRTC signaled one, the incorrect color space data were
passed to the renderer.
This CL removes introduced change regarding color space data: GenericDecoder
doesn't copy or store it and software decoders are restored to copy it.
Relevant tests are also removed.
Bug: chromium:982486
Change-Id: I989e01476ff7f7df376c05578ab8f540b95a1dd2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145323
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28556}
In this CL:
- Added WEBRTC_VIDEO_CODEC_ENCODER_FAILURE return code that can
be returned by the encoder wrapper in case of a broken encoder.
- Added EncoderFailureCallback interface that can be called
to request encoder fallback to be performed. Implemented by
WebRtcVideoChannel and called from the VideoStreamEncoder.
- Updated SelectSendVideoCodec to select all compatible codecs instead
of just one.
Bug: webrtc:10795
Change-Id: I87a83fd02e48c40493c930471c06c3d0941031ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140888
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28462}
- Don't reset encoder if max/min bitrate changed.
- Removed min/max bitrate DCHECKs from encoder wrappers.
- Reset encoder if start_bitrate changed. Only do this if encoding
has not yet started.
- Updated ReconfigureBitratesSetsEncoderBitratesCorrectly test.
- Removed EncoderSetupPropagatesCommonEncoderConfigValues test since it
was a subset of ReconfigureBitratesSetsEncoderBitratesCorrectly.
Bug: webrtc:10773
Change-Id: Id9cbb2ea229232fd95967819e2a937b26948de9f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144028
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28446}
Previously, FecControllerOverride was passed to
Vp8FrameBufferController::SetFecControllerOverride. Passing to
the factory is a more elegant way, since it's only used when
the controller is constructed.
TBR=kwiberg@webrtc.org
Bug: webrtc:10769
Change-Id: Iae599889e7ca9003e3200c2911239cbb763ee65a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144380
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28443}
The purpose of this interface is to allow VideoEncoder to override
the bandwidth allocation set by FecController in RtpVideoSender.
This CL defines the interface and sends it down to VideoSender.
Two upcoming CLs will:
1. Make LibvpxVp8Encoder pass it on to the (injectable)
FrameBufferController, where it might be put to good use.
2. Modify RtpVideoSender to respond to the message sent to it
via this API.
TBR=kwiberg@webrtc.org
Bug: webrtc:10769
Change-Id: I2ef82f0ddcde7fd078e32d8aabf6efe43e0f7f8a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143962
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28416}
[1/2] - Make new version pure-virtual, and deprecated version non-pure.
This will allow deleting the deprecated version from downstream
projects.
[2/2] - Remove deprecated version.
TBR=stefan@webrtc.org
Bug: webrtc:10336
Change-Id: Ia132ef071b1f379fc74834178e75e981ca908125
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144042
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28413}
Only remaining user is WavReader. Demote its constructor
accepting a PlatformFile to private, to refactor implementation
in a later cl.
Bug: webrtc:6463
Change-Id: I7b950be6f02073cb135dd0fab1190b9dc0de1fba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144025
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28410}
This change adds the plumbing of RtpPacketInfo from RtpVideoStreamReceiver::OnRtpPacket() to VideoReceiveStream::OnFrame() for video. It is a step towards replacing the non-spec compliant ContributingSources that updates itself at packet-receive time, with the spec-compliant SourceTracker that will update itself at frame-delivery-to-track time.
Bug: webrtc:10668
Change-Id: Ib97d430530c5a8487d3b129936c7c51e118889bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139891
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Chen Xing <chxg@google.com>
Cr-Commit-Position: refs/heads/master@{#28332}
This is a reland of 11dfff0878c949f2e19d95a0ddc209cdad94b3b4
Now that I am sure that WebRTC code is not calling the obsolete
versions, I will just remove the NOT_REACHED and call the
new version from the old ones, so as not to trip up downstream
projects.
Original change's description:
> Inform VideoEncoder of negotiated capabilities
>
> After this CL lands, an announcement will be made to
> discuss-webrtc about the deprecation of one version
> of InitEncode().
>
> Bug: webrtc:10720
> Change-Id: Ib992af0272bbb16ae16ef7e69491f365702d179e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140884
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Elad Alon <eladalon@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28224}
TBR=sakal@webrtc.org,kwiberg@webrtc.org,sprang@webrtc.org
Bug: webrtc:10720
Change-Id: I46c69e45c190805c07f7e51acbe277d7eebd1600
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/141412
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28236}
This change is part of a change to break the dependency between "api:rtp_headers" and "api/video:video_frame". It does so by first creating an empty "api/video:video_rtp_headers" build rule so that downstream projects can be fixed before moving the source files.
Bug: webrtc:10668
Change-Id: I81aa6edfef3639b457a40aa93de048e62cbfd8ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140291
Commit-Queue: Chen Xing <chxg@google.com>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28209}
As this is handled higher up the pipeline in a single
place for all encoders/decoders
Bug: webrtc:10460
Change-Id: I95b0a69aecaf07283c8776ac0d7e85d097e3576b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139882
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28172}
Using this flag, an encoder may inform the RTP sender module that
the packet is not elligible for retransmission. Specifically, it
may not be retransmitted in response to a NACK message,
nor because of early loss detection (see CL #135881).
Bug: webrtc:10702
Change-Id: Ib6a9cc361cf10ea7214cf672e05940c27899a6be
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140105
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28169}
Currently, if LNTF and NACK messages are both created, they will
be sent out in separate RTCP messages. This is wasteful.
This CL is the first of in a series of CLs that will ensure that
these feedback messages can be buffered together, without introducing
more of a delay than the CPU time required to process both messages.
Bug: webrtc:10336
Change-Id: I950324112ee346695a12a17d025483ea5e99c732
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139112
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28136}
Because of a low bitrate target, base layer has drops much more frequently
than other layers. But it reduces overall framerate, especially then
input framerate is low (5 fps).
This CL allows pre-layer drops and disables droppoing on higher spatial
layers for screenshare, solving the issue.
Additional care have to be taken then new spatial layers are enabled
dynamically to not create non-compatible with RTP references.
Bug: webrtc:10257
Change-Id: Ie056484c99a3f35ff4405ef71337dc2d034db8bb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138262
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28063}
This CL makes it more flexible and easier to include/exclude H264 code
when using other build systems because it delegates the decision to
remove the code to the preprocessor instead of GN.
This CL should be a noop, and for WebRTC/Chromium the GN param
`rtc_use_h264` will still be the only thing to change in order to
include/exclude H264.
Moving code that requires ffmpeg or h264 out of the #ifdef/#endif
part should break the build since dependencies are only added if
`rtc_use_h264=true`.
Bug: webrtc:9213
Change-Id: Ibc04edc2f6b9e51489ffe638d5be4b32959cdca0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/137430
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28055}
Reland with fixes.
If input framerate is a little unstable, using it to cap layers will
make output framerate even smaller for longer periods of time.
Also, fix screenshare_loopback test for low-fps vp9 testing.
Bug: webrtc:10257
Change-Id: Id40a780d461e6b51cb44d275b8aa5d7b348d3586
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138215
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28054}
This reverts commit eb1754c5750dfcad23ac62b47aa3aa2176ae7be2.
Reason for revert: breaks downstream projects
Original change's description:
> VP9 screenshare: Don't base layers frame-rate on input frame-rate
>
> If input framerate is a little unstable, using it to cap layers will
> make output framerate even smaller for longer periods of time.
>
> Also, fix screenshare_loopback test for low-fps vp9 testing.
>
> Bug: webrtc:10257
> Change-Id: I64aa087e859ab4ab8e484c9ab7f5ac0fb18bd37d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138204
> Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28050}
TBR=ilnik@webrtc.org,ssilkin@webrtc.org
Change-Id: I82bfbac58249cfe0da5ff565aa97a4745fd078ff
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10257
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138213
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28051}
If input framerate is a little unstable, using it to cap layers will
make output framerate even smaller for longer periods of time.
Also, fix screenshare_loopback test for low-fps vp9 testing.
Bug: webrtc:10257
Change-Id: I64aa087e859ab4ab8e484c9ab7f5ac0fb18bd37d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138204
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28050}
WebRTC combines VP9 SVC spatial layer frames into superframe and passes
it to a decoder. The chromium HW VP9 decoder (wrapper) needs to know
location of each spatial layer frame in the frame buffer. To provide
decoder with such information this CL:
- Adds Set/SpatialLayerFrameSize methods to EncodedImage.
- Sets size of each spatial layer frame on superframe at assembly stage.
Bug: webrtc:10495
Change-Id: I68c3c0d668c67dfa1740e004059d860dd98f67f9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/136922
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28032}
