Refactor FrameCandenceAdapter to keep track of input frame rate.
Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
Uma is recorded to tell if input frame timestamp is monotonically increasing.
Bug: webrtc:10481, webrtc:15887
Change-Id: I6d698e9f9dcfe8c023d2d35371435c47f70102b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342760
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41967}
This reverts commit 802dd5bdbd97d880761059c7362c9e843211e32d.
First patch set is pure reland.
New patch set adds field trial flag.
Original change's description:
Stop exponential probing if 2xmax allocated bitrate lower than BWE.
Without this, if max allocated bitrate is lowered while exponential probing is ongoing, a new probe can be sent at a rate of the new low max allocated bitrate which may cause BWE to decrease.
Bug: webrtc:14928
Change-Id: I35c341bbaced800d9931657d62c73a17a3279b7c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344440
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41965}
When refactoring the WGC capture path, the check of a closed source
had been placed at a level where the notification of a closed source
was left without being detected since the error message was never
provided to the main WgcCapturerWin::CaptureFrame() which sends the
error message up to the client.
This trivial change ensures that WgcCapturerWin::CaptureFrame() returns
with DesktopCapturer::Result::ERROR_PERMANENT as soon as
WgcCaptureSession::OnItemClosed() has been triggered and it will
ensure that the WGC capture session stops and that any attached
MediaStreamTrack will signal its onended event as expected.
Bug: chromium:330863510
Change-Id: I57e44df417c33efa0595fc277cac5429cf539b26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344420
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41963}
The purpose is to be able to create a RtpPacketSendInfo from Pacing and RtpPacketSendInfo only.
This allow further refactoring where we directly in PacketRouter can notify BWE and early loss detection that a packet will be sent.
RtpPacketSendInfo::From is mostly added to be able to test conversion.
Bug: webrtc:15368
Change-Id: I5ebe2dc91d2eedf2c86e62c3f9738437082a49e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343766
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41961}
This reverts commit 5a4ce031019bce349ad65e76aa5da6d0f8e5989e.
Reason for revert: Breaks tests in downstream project.
Original change's description:
> Stop exponential probing if 2xmax allocated bitrate lower than BWE.
>
> Without this, if max allocated bitrate is lowered while exponential probing is ongoing, a new probe can be sent at a rate of the new low max allocated bitrate which may cause BWE to decrease.
>
> Bug: webrtc:14928
> Change-Id: Id8e314740c2403d3b801d28f634dbc718f77c16e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343384
> Reviewed-by: Diep Bui <diepbp@webrtc.org>
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41929}
Bug: webrtc:14928
Change-Id: I0d48b37bfb8684fd490f5685e510b438a83254b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343900
Commit-Queue: Ying Wang <yinwa@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41958}
This reverts commit 7ae48c452abf8694a1b0a7a9a2aef13a9d10298a.
Reason for revert: breaks RtpVp9RefFinder
Original change's description:
> Mark frames with inter_layer_predicted=true as delta frames
>
> As it is currently implemented, the VP9 depacketizer decides packet's frame type based on p_bit ("Inter-picture predicted layer frame"). p_bit is set to 0 for upper spatial layer frames of keyframe since they do not have temporal refs. This results in marking packets of upper spatial layer frames, and, eventually these frames, of SVC keyframes as "keyframe" while they are in fact delta frames.
>
> Normally spatial layer frames are merged into a superframe and the superframe is passed to decoder. But passing individual layers to a single decoder instance is a valid scenario too and is used in downstream projects. In this case, an upper layer frame marked as keyframe may cause decoder reset [2] and break decoding.
>
> This CL changes frame type decision logic in the VP9 depacketizer such that only packets with both P and D (inter-layer predicted) bits unset are considered as keyframe packets.
>
> When spatial layer frames are merged into a superframe in CombineAndDeleteFrames [1], frame type of the superframe is inferred from the lowest spatial layer frame.
>
> [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/video_coding/frame_helpers.cc;l=53
>
> [2] https://source.corp.google.com/piper///depot/google3/third_party/webrtc/files/stable/webrtc/modules/video_coding/codecs/vp9/libvpx_vp9_decoder.cc;l=209
>
> Bug: webrtc:15827
> Change-Id: Idc3445636f0eae0192dac998876fedec48628560
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343342
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41939}
Bug: webrtc:15827
Change-Id: I697a057b8b3e88c07499f77c42f014da43cf1dc1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343763
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#41953}
The purpose of these new methods are to allow creating a RTP packet with
sequence numbers that
can be inspected and is ensured to be sent if SendPacket is invoked.
virtual bool CanSendPacket(const RtpPacketToSend& packet) const = 0;
virtual void AssignSequenceNumber(RtpPacketToSend& packet) = 0;
virtual void SendPacket(std::unique_ptr<RtpPacketToSend> packet,
const PacedPacketInfo& pacing_info) = 0;
Bug: webrtc:15368
Change-Id: I671e737575e15328e796aa98761a4d540c5812d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343785
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41951}
RtpPacketToSend::transport_sequence_number
packed_id is set to be 64 bit to align with rtc::PacketOptions.
packet_id is only set to RtpPacketToSend::transport_sequence_number if
TransportSequenceNumber header extension is not used in order to not
change current behaviour.
Bug: webrtc:15368
Change-Id: Ia532714226421422bdb292f8dd34b175560e9dc6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344160
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41950}
And move writing of the header extension from PacketRouter to
RtpSenderEgress::SendPacket.
Bug: webrtc:15368
Change-Id: Ieb18af4bc20115bf02d37e1f9a815a5c120975a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343786
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41949}
Start migrating away from `hasAudioLevel`, `voiceActivity`, `audioLevel` fields in RTPHeaderExtension and switch usages to a more modern absl::optional<AudioLevel> accessor instead.
The old fields are preserved for compatibility with downstream projects, but will be removed in the future.
Bug: webrtc:15788
Change-Id: I76599124fd68dd4d449f850df3b9814d6a002f5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/336303
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41947}
As it is currently implemented, the VP9 depacketizer decides packet's frame type based on p_bit ("Inter-picture predicted layer frame"). p_bit is set to 0 for upper spatial layer frames of keyframe since they do not have temporal refs. This results in marking packets of upper spatial layer frames, and, eventually these frames, of SVC keyframes as "keyframe" while they are in fact delta frames.
Normally spatial layer frames are merged into a superframe and the superframe is passed to decoder. But passing individual layers to a single decoder instance is a valid scenario too and is used in downstream projects. In this case, an upper layer frame marked as keyframe may cause decoder reset [2] and break decoding.
This CL changes frame type decision logic in the VP9 depacketizer such that only packets with both P and D (inter-layer predicted) bits unset are considered as keyframe packets.
When spatial layer frames are merged into a superframe in CombineAndDeleteFrames [1], frame type of the superframe is inferred from the lowest spatial layer frame.
[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/video_coding/frame_helpers.cc;l=53
[2] https://source.corp.google.com/piper///depot/google3/third_party/webrtc/files/stable/webrtc/modules/video_coding/codecs/vp9/libvpx_vp9_decoder.cc;l=209
Bug: webrtc:15827
Change-Id: Idc3445636f0eae0192dac998876fedec48628560
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343342
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41939}
FFmpeg has removed this field and usage of it in chromium must be
removed before the ffmpeg dependency is updated. The chromium media
change can be found here:
https://chromium-review.googlesource.com/c/chromium/src/+/5384308
The usage of the field in webrtc seems only to be for sanity checking,
so it should be just safe to remove entirely, since webrtc does not
expect re-ordering at all.
Bug: chromium:330573128
Change-Id: I9c5854ec82c3ad2d55374ea4eaa0c571437f8267
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343840
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Ted (Chromium) Meyer <tmathmeyer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41935}
Without this, if max allocated bitrate is lowered while exponential probing is ongoing, a new probe can be sent at a rate of the new low max allocated bitrate which may cause BWE to decrease.
Bug: webrtc:14928
Change-Id: Id8e314740c2403d3b801d28f634dbc718f77c16e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343384
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41929}
Webrtc is build with FFmpeg sources on defined in the include path
through the -I flag, so they should be included this way instead. This
would otherwise cause a conflict when the chromium ffmpeg sources move
from third_party/ffmpeg/* to third_party/ffmpeg/src/*
BUG: chromium:329282834
Change-Id: Id8f7e91446bdc536db77e74388a73e51f5111ffc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342820
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Ted (Chromium) Meyer <tmathmeyer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41899}
This seems to confuse perfetto, and the data ends up on its own track
and the end event is just ignored. As it was invalid, I am assuming it
is not used, and can be simply removed.
#rtc_fixit
Bug: webrtc:15867
Change-Id: I31a814f6c2147c3ce534726bf9046a79369b9eb3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342761
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/main@{#41896}
This seems to confuse perfetto, and the data ends up on its own track
and the end event is just ignored. As it was invalid, I am assuming it
is not used, and can be simply removed.
#rtc_fixit
Bug: webrtc:15867
Change-Id: I77e59adcd35c51911474446a5f92505bf6b860f4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342780
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/main@{#41892}
Also remove all dependencies on rtc_media_base except for a few
that are suspected of being linker directives.
Bug: webrtc:14775
Change-Id: Ic0daf88b5422047d3ed7079ee6af9e689853310c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/341461
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41886}
There's an AV1 encoder speed setting 11 that is supposed to be used
for screen sharing content.
Bug: chromium:328598314
Change-Id: Id97898554a740eb1684d03c782c718c19f4c95e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342201
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41874}
We want to copy device id to _lastUsedDeviceName variable, but we use
length of display name instead of length of device id, which might be
longer than expected and we end up reading beyond the source string.
Bug: webrtc:15853
Change-Id: Id278ed7e361ead85475910adec18b9db51e6890b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/341521
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41844}
describing video codecs with their parameters as static members of SdpVideoFormat:
static const SdpVideoFormat VP8();
static const SdpVideoFormat H264();
static const SdpVideoFormat VP9Profile0();
static const SdpVideoFormat VP9Profile1();
static const SdpVideoFormat VP9Profile2();
static const SdpVideoFormat VP9Profile3();
static const SdpVideoFormat AV1Profile0();
static const SdpVideoFormat AV1Profile1();
This removes the need to craft instances of these by hand.
BUG=webrtc:15703
Change-Id: I2171e08b48ec98f18424f53f3b5d6d148130532e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/337441
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41833}
Announce that we support SPA_DATA_DmaBuf and tell PipeWire not to map
memory for us so we can handle it ourself, similar like we do in case of
screen sharing. This fixes an issue when a camera is already in use by
gstreamer (pipewiresrc), where DMABufs are used, and we try to share
same camera and get no content, as PipeWire doesn't want to mmap DMABuf
memory for us and we get NULL data pointers.
Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1876895
Bug: webrtc:15654
Change-Id: I788d8d12b2fcd5588329d7265e45b479f74bb628
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/338921
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41826}
Marking capturer as failed will indicate consumers will not be getting
any new frames by sending back ERROR_PERMANENT and let them know that
screencast can be stopped from their side. This will make screencast to
stop when a window we share is closed or when screencast is closed from
system tray.
Bug: chromium:40276865
Change-Id: Ia2c13461bd3126cab9c4838b8aa6840578562e9e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339560
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41817}
The feature isn't in use by Google and has proven to contain security
issues. It's time to remove it.
Bug: b/324864439
Change-Id: I80344eb2f2060469d2d69a54dc4519fdd02ab4ea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/340324
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41808}
which needs to be added to the remote codecs a=fmtp:
This also forces SimulcastCastEncoderAdapter to avoid issues with codecs that have native simulcast capability but do require synchronized keyframes.
This parameter allows for large-scale experimentation and A/B testing
whether the new behavior has advantages. It is to be considered
transitional and may be removed again in the future.
BUG=webrtc:10107
Change-Id: I81f496c987b2fed7ff3089efb746e7e89e89c033
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/333560
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41805}
To prepare for a new AudioLevel struct to be added to the public WebRTC API, rename the internal RTP extension reader/writer class to AudioLevelExtension. A temporary alias is provided to avoid breaking downstream projects.
Bug: webrtc:15788
Change-Id: Ie231668f25932fd9b539229114128b1d0b949a6e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339887
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41787}
Same can be achieved by having multiple Parse functions in the same
RtpDependencyDescriptorExtension trait
Bug: None
Change-Id: I4eab0001d1ffff631a9d70fafde13e51f5c6ce36
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/340320
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41786}
It used up to 3 threads for QVGA on Android before. This change disables Android-specific code path in NumberOfThreads() and uses the generic settings, which configure 1 thread for resolutions <=VGA, instead. The change is guarded by a killswitch.
For reference, frame encode time for VGA 512kbps using 1 thread on Pixel 2 (7 years old device; SD835) is ~5.5ms: https://chromeperf.appspot.com/report?sid=6e80c701ef6ff0d008a299fb122a16f0d2600ddfcd9981d3d75cd722c92b2869
Bug: webrtc:15828, b/316494683
Change-Id: I0e9571ede64c6cb77d529d21ccb0310ccb8bfdaf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/337601
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41770}
Mark FU packets with type between kBlaWLp and kRsvIrapVcl23 as key frames.
This behavior aligns with AP and single NALU.
Bug: webrtc:13485
Change-Id: I51762e89ebb4829b50524d9f5476f2d5d9c093f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/338860
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41764}
Example: "WebRTC-LibvpxVp9Encoder-SvcFrameDropConfig/Enabled,layer_drop_mode:1,max_consec_drop:7/"
It is only possible to enable LAYER_DROP (layer_drop_mode=1) for now. All other modes are ignored. Max consecutive frame drops (max_consec_drop) value from the field is always applied if the field trial is enabled.
LAYER_DROP requires flexible mode (is_flexible_mode_=true) which can be enabled by means of WebRTC-Vp9InterLayerPred: https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/media/engine/webrtc_video_engine.cc;l=976
Bug: webrtc:15827, b/320629637
Change-Id: I9c4d4838b11547e608d863198b109cb1485902d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/335041
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41755}
The code uses IDXGIOutput1::DuplicateOutput for screen capture and
it allows only DXGI_FORMAT_B8G8R8A8_UNORM texture format, which
works on most monitor cases except HDR monitor.
HDR mointor returns type of DXGI_FORMAT_R16G16B16A16_FLOAT.
These two types of DXGI_FORMAT_B8G8R8A8_UNORM and
DXGI_FORMAT_R16G16B16A16_FLOAT are all formats that DuplicateOutput
returns based on Windows OS team.
The fix is to add allowed format of DXGI_FORMAT_R16G16B16A16_FLOAT.
Manually repro the issue and validated the fix.
Bug: chromium:40787684
Change-Id: I0a7be38b14a06261d631d2db172f12725edbbf1f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339621
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41749}
