To allow various VideoBitrateAllocators to use propagated rather than global field trials
This relands the
https://webrtc-review.googlesource.com/c/src/+/349920
where patchset#1 is identical to the original change,
patchset#2 undoes (postpones) the expectation downstream propagates the Environment too.
Bug: webrtc:42220378
Change-Id: I4a9a32bb0926a875d37f3ba19dd5309e97546553
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/350364
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42298}
To allow various VideoBitrateAllocators to use propagated rather than global field trials
Bug: webrtc:42220378
Change-Id: I52816628169a54b18a4405d84fee69b101f92f72
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349920
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42288}
Replace factory that takes optional FieldTrialView with a constructor that takes non-optional reference to the same interface - all callers already guarantee it is not nullptr
Replace several local IsEnabled/IsDisabled helpers with the same helpers in FieldTrialView
In CongestionWindowPushbackController tests pass field trials bypassing global field trial string
Bug: webrtc:42220378
Change-Id: Ic49ad78919d834a5e3b9b69545d3b39088023a75
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349900
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42270}
There is no TRACE_EVENT_ASYNC_STEP in the perfetto legacy API.
The corresponding legacy API that matches best is
TRACE_EVENT_ASYNC_STEP_INTO.
Bug: b/42226290
Change-Id: I6725973895878e34d96b6cd3314ab8de402a911b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349120
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42219}
This CL adds tracing support for input video frame representation
which was useful in debugging the linked bug.
Bug: b/328533258
Change-Id: I8a9e533b11d99688a71a24138bf8058b841e55d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/348841
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Stefan Holmer <holmer@google.com>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42155}
These are required by the Perfetto API and the missing argument prevents
the use of Perfetto.
Bug: webrtc:15917
Change-Id: Ie40c0344dc9d8cd40f7c751b133d150b975a33c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347702
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/main@{#42147}
Instead of passing it as optional parameter during construction, pass field trials as required parameters on use.
Test that create the EncoderStreamFactory might not have an easy access to the actual field trials, but prod code has appropriate field trials when uses the factory.
This way EncoderStreamFactory doesn't need to depend on global field trial string through FieldTrialBaseConfig class.
Bug: webrtc:10335
Change-Id: I8f7030e41579ff2c5dd362c491a4e1624b23e690
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347700
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42098}
CropAndScale() makes offset_x and offset_y even if the U,V planes are
subsampled. This may result in the update rect being off by one. To
prevent that, always pass even offset_x and offset_y to CropAndScale().
Round the offset up when dividing crop size by 2 to make the cropping
more centered and symmetrical.
Note: The code was originally added in
https://webrtc-review.googlesource.com/c/src/+/123230.
Bug: webrtc:15910
Change-Id: I4a70d460702f03dee72a5b8292cb25766c3e6aca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346323
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Wan-Teh Chang <wtc@google.com>
Cr-Commit-Position: refs/heads/main@{#42052}
Instead of relying on the global field trial string
Bug: webrtc:10335
Change-Id: I491be089ffc725fd28483edf10eae4ae5d17d651
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346263
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42021}
Similar to the two RTC_CHECK_GE's earlier in the
VideoStreamEncoder::ReconfigureEncoder() method (originally added to
webrtc/video/vie_encoder.cc in
https://codereview.webrtc.org/2936393002), add two RTC_CHECK_GE's to
ensure that crop_width_ and crop_height_ are nonnegative.
Bug: b:330482827
Change-Id: Ia4989307b754abb101e50d33beeca4483a694a62
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346026
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Wan-Teh Chang <wtc@google.com>
Cr-Commit-Position: refs/heads/main@{#42017}
This reverts commit d427e83a15ad2950095ce1d352cc7e11eaf6cad3.
Reason for revert: Flaky test fixed.
Refactor FrameCandenceAdapter to keep track of input frame rate. This fixes an issue where frame rate is calculated too low if congestion window drop a frame.
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, webrtc:15893
Change-Id: I76268aa0991dbc99c1b881fb251a76aa54ff2673
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344561
Reviewed-by: Erik Språng <sprang@google.com>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41972}
This reverts commit 784af1f42e89735587c442855fa01fc90475c449.
Reason for revert: Seems like test test_support_unittests
ResolutionAdaptsToAvailableBandwidth is flaky with this cl.
Original change's description:
> FrameCadenceAdapter keep track of Input framerate
>
> 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}
Bug: webrtc:10481, webrtc:15887
Change-Id: Id9672764768f2f40f8e711e990ad8ac18c28efcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344560
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41969}
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 c39712b51522bb21c18c58c593f454c5cc0e7995.
Reason for revert: Fixed issue where frame rate not adapted to highest "active" requested frame rate.
Patchset 1 contains original cl.
Later patchsets contains modifications.
Original change's description:
> Propagate known Encoder SinkWants when configured instead of after first frame.
>
> Propagate requested resolution and max frame rate to the source when
> configured rather than after the first frame.
> This is so that the source can be configured immediately. There is no
> reason why source should be updated until after first frame since it may lead
> to unnecessary reconfigurations and thread jumps. Wants that depend on actual frame size is not moved.
>
> Cl also change default behaviour in VideoStreamEncoderTest to not
> set restriction on max frame rate.
>
Bug: webrtc:14451
Change-Id: I2668db44bd17586efcf511ad3cd975065c503ec5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343122
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41941}
This reverts commit 1ee24a650c116509d855e2ed23b8d28a0bb37384.
Reason for revert: Suspected upstream test breakage.
Original change's description:
> Propagate known Encoder SinkWants when configured instead of after first frame.
>
> Propagate requested resolution and max frame rate to the source when
> configured rather than after the first frame.
> This is so that the source can be configured immediately. There is no
> reason why source should be updated until after first frame since it may lead
> to unnecessary reconfigurations and thread jumps. Wants that depend on actual frame size is not moved.
>
> Cl also change default behaviour in VideoStreamEncoderTest to not
> set restriction on max frame rate. This aligns with how its used.
>
> Bug: webrtc:14451
> Change-Id: I96a3675d3ccabb1d2ecb4354b6932bc6563b1760
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342801
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41906}
Bug: webrtc:14451
Change-Id: I3aa669f8cc61a43b0820a06edf1497f3c86e3958
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343220
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Owners-Override: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41911}
Propagate requested resolution and max frame rate to the source when
configured rather than after the first frame.
This is so that the source can be configured immediately. There is no
reason why source should be updated until after first frame since it may lead
to unnecessary reconfigurations and thread jumps. Wants that depend on actual frame size is not moved.
Cl also change default behaviour in VideoStreamEncoderTest to not
set restriction on max frame rate. This aligns with how its used.
Bug: webrtc:14451
Change-Id: I96a3675d3ccabb1d2ecb4354b6932bc6563b1760
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342801
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41906}
VideoStreamEncoder creates VideoEncoders. To pass an Environment to VideoEncoder, it should be available in the VideoStreamEncoder.
Bug: webrtc:15860
Change-Id: Id89ac024ce61fdd9673bb66f03f94f243fc0c7f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/341840
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41861}
A call to GetScalabilityMode was added for logging purpose and causes an expectation failure for tests using 4 temporal layers.
Plan is to remove the old GetScalabilityMode and keep only the one that returns an optional.
Change-Id: I0e37a496bb621d9754d6572ef5838b58193aa183
Bug: b/327381318
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/341520
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#41838}
This is a reland of commit 050ffefd854f8a57071992238723259e9ae0d85a
Original change's description:
> Extends WebRTC logs for software encoder fallback
>
> This CL extends logging related to HW->SW fallbacks on the encoder
> side in WebRTC. The goal is to make it easier to track down the
> different steps taken when setting up the video encoder and why/when
> HW encoding fails.
>
> Current logs are added on several lines which makes regexp searching
> difficult. This CL adds all related information on one line instead.
>
> Three new search tags are also added VSE (VideoStreamEncoder), VESFW
> (VideoEncoderSoftwareFallbackWrapper) and SEA (SimulcastEncoderAdapter). The idea is to allow searching for the tags to see correlated logs.
>
> It has been verified that these added logs also show up in WebRTC
> logs in Meet.
>
> Logs from the GPU process are not included due to the sandboxed
> nature which makes it much more complex to add to the native
> WebRTC log. I think that these simple logs will provide value as is.
>
> Example: https://gist.github.com/henrik-and/41946f7f0b10774241bd14d7687f770b
>
> Bug: b/322132132
> Change-Id: Iec58c9741a9dd6bab3236a88e9a6e45440f5d980
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339260
> Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41733}
NOTRY=true
Bug: b/322132132
Change-Id: I25dd34b9ba59ea8502e47b4c89cd111430636e08
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339680
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41736}
This reverts commit 050ffefd854f8a57071992238723259e9ae0d85a.
Reason for revert: Breaks downstream project.
Original change's description:
> Extends WebRTC logs for software encoder fallback
>
> This CL extends logging related to HW->SW fallbacks on the encoder
> side in WebRTC. The goal is to make it easier to track down the
> different steps taken when setting up the video encoder and why/when
> HW encoding fails.
>
> Current logs are added on several lines which makes regexp searching
> difficult. This CL adds all related information on one line instead.
>
> Three new search tags are also added VSE (VideoStreamEncoder), VESFW
> (VideoEncoderSoftwareFallbackWrapper) and SEA (SimulcastEncoderAdapter). The idea is to allow searching for the tags to see correlated logs.
>
> It has been verified that these added logs also show up in WebRTC
> logs in Meet.
>
> Logs from the GPU process are not included due to the sandboxed
> nature which makes it much more complex to add to the native
> WebRTC log. I think that these simple logs will provide value as is.
>
> Example: https://gist.github.com/henrik-and/41946f7f0b10774241bd14d7687f770b
>
> Bug: b/322132132
> Change-Id: Iec58c9741a9dd6bab3236a88e9a6e45440f5d980
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339260
> Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41733}
Bug: b/322132132
Change-Id: I24d0a4e71a43ac192485f1af208563a51d919865
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339661
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41735}
This CL extends logging related to HW->SW fallbacks on the encoder
side in WebRTC. The goal is to make it easier to track down the
different steps taken when setting up the video encoder and why/when
HW encoding fails.
Current logs are added on several lines which makes regexp searching
difficult. This CL adds all related information on one line instead.
Three new search tags are also added VSE (VideoStreamEncoder), VESFW
(VideoEncoderSoftwareFallbackWrapper) and SEA (SimulcastEncoderAdapter). The idea is to allow searching for the tags to see correlated logs.
It has been verified that these added logs also show up in WebRTC
logs in Meet.
Logs from the GPU process are not included due to the sandboxed
nature which makes it much more complex to add to the native
WebRTC log. I think that these simple logs will provide value as is.
Example: https://gist.github.com/henrik-and/41946f7f0b10774241bd14d7687f770b
Bug: b/322132132
Change-Id: Iec58c9741a9dd6bab3236a88e9a6e45440f5d980
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339260
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41733}
Instead embed functionality of the rtc::TaskQueue into destructors and describe the potential race.
Bug: webrtc:14169
Change-Id: I01b570b530986a0d07798893057201493a8bef5f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/335141
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41592}
This change ensures that the FCA now is informed about a new max fps
when VideoStreamEncoder::OnVideoSourceRestrictionsUpdated is called.
The latest restricted frame rate which is provided to the FCA will
only affect the cadence of repeated non-idle (quality has not
converged) frames and the main goal is to ensure that the FCA reduces
its repeat rate in situations where the video source is constrained.
UpdateVideoSourceRestrictions is added to the FrameCadenceAdapter API
and it is called from the VideoStreamEncoder when its source
parameters (resolution and/or frame rate) are restricted.
This modification has no effect on the flow driven by
ProcessOnDelayedCadence (non repeated frames).
Bug: webrtc:15539
Change-Id: I26dee6480e5137f82c5ccf57091b737cad82dbf6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/328300
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41308}
The FrameCadenceAdapterInterface::Callback::OnFrame method in
VideoStreamEncoder only changed frame handling on
frames_scheduled_for_processing being 1. This CL changes
the parameter to more explicitly signal queue overload via
boolean parameter.
Bug: None
Change-Id: I1eb46b34fc4d748b7e2f1921642497c939adf197
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327761
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41226}
The change adds dropped frame reporting for previously dropped frame
and also cleans up the colon list of the VSE.
Bug: None
Change-Id: Iad1c084739e5392ded4f100d940b45adf9b561ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327800
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41225}
This reverts commit 8039cdbe48f8c8bb91fa1761f807005a7b497196.
Reason for revert: remove functionality after measurement complete
Original change's description:
> Measure wall clock time of capture and encode processing.
>
> (NOTE: This and dependent CLs will be reverted in a few days after
> data collection from the field is complete.)
>
> This change introduces a new task queue concept, Voucher. They
> are associated with a currently running task tree. Whenever
> tasks are posted, the current voucher is inherited and set as
> current in the new task.
>
> The voucher exists for as long as there are direct and indirect
> tasks running that descend from the task where the voucher was
> created.
>
> Vouchers aggregate application-specific attachments, which perform
> logic unrelated to Voucher progression. This particular change adds
> an attachment that measures time from capture to all encode operations
> complete, and places it into the WebRTC.Video.CaptureToSendTimeMs UMA.
>
> An accompanying Chrome change crrev.com/c/4992282 ensures survival of
> vouchers across certain Mojo IPC.
>
> Bug: chromium:1498378
> Change-Id: I2a27800a4e5504f219d8b9d33c56a48904cf6dde
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325400
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Markus Handell <handellm@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41061}
Bug: chromium:1498378
Change-Id: I9503575fbc52f1946ca26fc3c17b623ea75cd3c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327023
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#41135}
This reverts commit 03bc3a0fa67e274efb4518da005f4c5b77c607e9.
Reason for revert: measurement complete
Original change's description:
> VideoStreamEncoder: exclude screencast from capture time measurement.
>
> This CL avoids measurement for screencast encoding work. The reason is
> screencast can cling on to and re-encode old video frames for which
> webrtc::VideoFrame::reference_time() is unchanged.
>
> Bug: chromium:1498378
> Change-Id: I5bf79d29ef7f57ddff2622cbb6c3436480bd16ba
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326103
> Commit-Queue: Markus Handell <handellm@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Auto-Submit: Markus Handell <handellm@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41097}
Bug: chromium:1498378
Change-Id: I42c1a86123eb1d6c7ad7c8981769f5560884a2f5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327025
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41133}
This CL avoids measurement for screencast encoding work. The reason is
screencast can cling on to and re-encode old video frames for which
webrtc::VideoFrame::reference_time() is unchanged.
Bug: chromium:1498378
Change-Id: I5bf79d29ef7f57ddff2622cbb6c3436480bd16ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326103
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41097}
(NOTE: This and dependent CLs will be reverted in a few days after
data collection from the field is complete.)
This change introduces a new task queue concept, Voucher. They
are associated with a currently running task tree. Whenever
tasks are posted, the current voucher is inherited and set as
current in the new task.
The voucher exists for as long as there are direct and indirect
tasks running that descend from the task where the voucher was
created.
Vouchers aggregate application-specific attachments, which perform
logic unrelated to Voucher progression. This particular change adds
an attachment that measures time from capture to all encode operations
complete, and places it into the WebRTC.Video.CaptureToSendTimeMs UMA.
An accompanying Chrome change crrev.com/c/4992282 ensures survival of
vouchers across certain Mojo IPC.
Bug: chromium:1498378
Change-Id: I2a27800a4e5504f219d8b9d33c56a48904cf6dde
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325400
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41061}
Convert most field trials used in PCLF tests.
Change-Id: I26c0c4b1164bb0870aae1a488942cde888cb459d
Bug: webrtc:10335
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322703
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40909}
To avoid name collision with Timestamp type,
To avoid confusion with capture time represented as Timestamp
Bug: webrtc:9378
Change-Id: I8438a9cf4316e5f81d98c2af9dc9454c21c78e70
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320601
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40796}
Expose new function MaybeCreateFrameDumpingEncoderWrapper that
wraps another passed encoder and dumps its encoded frames out
into a unique IVF file into the directory specified by the
"WebRTC-EncoderDataDumpDirectory" field trial. If the passed
encoder is nullptr, or the field trial is not setup, the function
just returns the passed encoder. The directory specified by the
field trial parameter should be delimited by ';'.
The new function is wired up in VideoStreamEncoder.
Bug: b/296242528
Change-Id: I6143adf899f78fcc03d4239a86c68dcbab483f1c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/317200
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40600}
which makes it possible to understand which error occured.
BUG=chromium:1366910
Change-Id: Ided288ea7aa7c6cb283f7d46692c67efb15764d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/316863
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40573}
It used input frame resolution before this change which caused unnecessary resolution adaptations when resolution scaling is used.
Found that initial frame dropping was always enabled for AV1 SVC. After fixing DropDueToSize the AV1 SVC tests [1] started to fail ("number of encoded temporal layers is less than expected") on bots. The tests encode 1850x1110 in L3T3 for 5s using the default 300kbps start bitrate. Before the fix the initial frame dropping kicked in and reduced the resolution to a level that let encoder to generate all temporal layers. After the fix the resolution stayed at 1850x1110 and encoder dropped all T1 and T2 layer frames. Mitigated this by increasing test duration from 5 to 10s. This gives enough time for BWE to ramp up and for encoder to generate (stop dropping) all temporal layers.
[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/pc/test/svc_e2e_tests.cc;l=460;bpv=1
Bug: chromium:1466809
Change-Id: I16802689e234f8fc16f891f024d5f644985de01c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/315142
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40536}
EncoderStreamFactory has two code paths for creating a stream: the
"simulcast path" and the "default path". Only the former cares about
encoding paramter's maxBitrate. The latter assumes that
`encoder_config.max_bitrate_bps` already encompasses the maxBitrate of
the first encoding, but this is not always the case.
As of M113, when scalability mode is specified, {active,inactive} does
not count as simulcast stream but as a default stream represented by
encoding[0].
The problem is that `encoder_config.max_bitrate_bps` only includes
`encodings[0].max_bitrate_bps` when `encodings.size() == 1` which isn't
the case here.
This CL fixes the problem by making the "create default stream" code
path look at the first encoding's maxBitrate and remove existing
assumptions that `encoder_config.max_bitrate_bps` encompasses
`encodings[0].max_bitrate_bps`. This is a step in the right direction
since we're trying to remove all special cases and have encodings map
1:1 with SSRCs, so the "max bps of entire stream" should indeed be a
separate limit than the per-encoding limits and it was confusing that
sometimes it included and sometimes it excluded encoding[0]'s limit.
This issue did not happen in {inactive,active} since that code path
counts as "simulcast stream", so "default stream" is only ever
applicable for index 0.
TESTED=Simulcast Playground, see https://crbug.com/1455962.
Bug: chromium:1455962
Change-Id: I7c44925b780623b5979751e8959e972293648a3d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313282
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40482}
This extension is documented to carry one bit: Screenshare.
It's been used for carrying simulcast layers and experiment IDs.
This CL removes that usage.
Bug: webrtc:15383
Change-Id: I048b283cde59bf1f607d8abdd53ced07a7add6f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312420
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40457}
allowing for better correlation with MaybeEncodeVideoFrame
which also logs the ntp timestamp.
BUG=None
Change-Id: I00fc99e69cd703f6da3f25043361d68b3cb3f3fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311542
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40415}
There are now multiple ways to configure VP9 L1Tx:
- Legacy API: configure legacy SVC and disable encodings, this gets
interpreted as disabling spatial layers (non-standard API hack).
- Standard API: configure scalability_mode. This can be done either
with a single encoding or multiple encodings. As long as only one
encoding is active we get a single L1Tx ssrc, same as legacy API.
Due to a bug, the ApplySpatialLayerBitrateLimits() logic which tweaks
bitrates was only applied in the legacy API code path, not the standard
API code path, despite both code paths configuring L1Tx.
The issue is that IsSimulcastOrMultipleSpatialLayers() was checking if
`number_of_streams == 1`. This is true in legacy code path but not
standard code path. The fix is to look at
`numberOfSimulcastStreams == 1` instead, which is set to the correct
value regardless of code path used.
This CL adds comments documenting the difference between
`number_of_streams` and `numberOfSimulcastStreams` to reduce the risk
of more mistakes like this in the future.
Bug: chromium:1455039, b:279161263
Change-Id: I69789b68cc5d45ef1b3becd310687c8dec8e7c87
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308722
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40287}
Various "if streams == 1" cases are updated to "if
IsSinglecastOrAllNonFirstLayersInactive()" in order not to cause subtle
differences between VP9 {active} and VP9 {active,inactive,inactive}.
This CL also affects a line that conditionally sets
`simulcastStream[0].active = codec_active` so it seemed fitting to
improve the test coverage of "if all streams are inactive, don't send".
Bug: webrtc:15028
Change-Id: I8872dc8be0f2dfc1d8914bdba5e6433f9ba8cbfd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298881
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39656}
The goal of the VP9 simulcast project is that when `scalability_mode`
is set, multiple encodings are always interpreted as simulcast, even
if VP9 or AV1 is used. This CL makes this so, but only if the flag
"WebRTC-AllowDisablingLegacyScalability" is "/Enabled/". This allows us
to make "SendingThreeEncodings_VP9_Simulcast" EXPECT VP9 simulcast.
When we are ready to ship we will remove the need to use the field
trial, but before we ship this we'll want to revisit if
SvcRateAllocator can be updated to support simulcast. (Today if we use
SvcRateAllocator when VP9 simulcast is used, all encodings except the
first one get bitrate=0, causing the test to fail because media is not
flowing on all layers.) For now, a TODO is added.
Bug: webrtc:14884
Change-Id: Ie20ae748b0c0405162f3a1b015ab94956ef83dae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297340
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39552}
