The generated id was used to distinguish which encoder/decoder is injecting/extracting data.
This feature is currently not used.
Bug: webrtc:12630
Change-Id: Ie11fed7f7a3d1f1bc0eb0ad6e51b48170f512c2b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213343
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/master@{#33598}
Packets, chunks, parameters and error causes - the SCTP entities
that are sent on the wire - are buffers with fields that are stored
in big endian and that generally consist of a fixed header size, and
a variable sized part, that can e.g. be encoded sub-fields or
serialized strings.
The BoundedByteReader and BoundedByteWriter utilities make it easy
to read those fields with as much aid from the compiler as possible,
by having compile-time assertions that fields are not accessed
outside the buffer's span.
There are some byte reading functionality already in modules/rtp_rtcp,
but that module would be a bit unfortunate to depend on, and doesn't
have the compile time bounds checking that is the biggest feature of
this abstraction of an rtc::ArrayView.
Bug: webrtc:12614
Change-Id: I9fc641aff22221018dda9add4e2c44853c0f64f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212967
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33597}
This change adds basic support for setting codecType kVideoCodecAV1 in
VCMEncodedFrames.
Bug: chromium:1191972
Change-Id: I258b39ff89c8b92ebbb288ef32c88b900a35d10e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213182
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33594}
Drop dependency on MemoryStream and the complex Stream interface.
Bug: None
Change-Id: I2226324b10ddbf5606e27bfecb82efdd25929163
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213145
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33583}
This reverts commit c184047fef005b86a6dd76f03b0eb5ec01de3c5c.
Reason for revert: Breaks the WebRTC->Chromium roll:
ERROR Unresolved dependencies.
//third_party/webrtc/test/fuzzers:vp9_encoder_references_fuzzer(//build/toolchain/win:win_clang_x64)
needs //third_party/webrtc/modules/video_coding:mock_libvpx_interface(//build/toolchain/win:win_clang_x64)
We need to add tryjob to catch these. The fix is to make
//third_party/webrtc/modules/video_coding:mock_libvpx_interface
visible in built_with_chromium builds by moving the target
out of this "if" https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/modules/video_coding/BUILD.gn;l=615;drc=3889de1c4c7ae56ec742fb9ee0ad89657f638169.
Original change's description:
> Add fuzzer to validate libvpx vp9 encoder wrapper
>
> Fix simulcast svc controller to reuse dropped frame configuration,
> same as full svc and k-svc controllers do.
> This fuzzer reminded the issue was still there.
>
> Bug: webrtc:11999
> Change-Id: I74156bd743124723562e99deb48de5b5018a81d0
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212281
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33568}
TBR=danilchap@webrtc.org,sprang@webrtc.org
Change-Id: I1676986308c6d37ff168467ff2099155e8895452
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11999
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212973
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33573}
Fix simulcast svc controller to reuse dropped frame configuration,
same as full svc and k-svc controllers do.
This fuzzer reminded the issue was still there.
Bug: webrtc:11999
Change-Id: I74156bd743124723562e99deb48de5b5018a81d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212281
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33568}
This reverts commit 2072b87261a6505a88561bdeab3e7405d7038eaa.
Reason for revert: Causing test failure.
Original change's description:
> Reland "[Battery]: Delay start of TaskQueuePacedSender." Take 2
>
> This is a reland of 89cb65ed663a9000b9f7c90a78039bd85731e9ae
> ... and f28aade91dcc2cb8f590dc1379ac7ab5c1981909
>
> Reason for revert: crashes due to uninitialized pacing_bitrate_
> crbug.com/1190547
> Apparently pacer() is sometimes being used before EnsureStarted()
> Fix: Instead of delaying first call to SetPacingRates(),
> this CL no-ops MaybeProcessPackets() until EnsureStarted()
> is called for the first time.
>
> Original change's description:
> > [Battery]: Delay start of TaskQueuePacedSender.
> >
> > To avoid unnecessary repeating tasks, TaskQueuePacedSender is started
> > only upon RtpTransportControllerSend::EnsureStarted().
> >
> > More specifically, the repeating task happens in
> > TaskQueuePacedSender::MaybeProcessPackets() every 500ms, using a self
> > task_queue_.PostDelayedTask().
> >
> > Bug: chromium:1152887
> > Change-Id: I72c96d2c4b491d5edb45a30b210b3797165cbf48
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208560
> > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33421}
>
> Bug: chromium:1152887
> Change-Id: I9aba4882a64bbee7d97ace9059dea8a24c144f93
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212880
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#33554}
TBR=hbos@webrtc.org,sprang@webrtc.org,etiennep@chromium.org
Change-Id: I430fd31c7602702c8ec44b9e38e68266abba8854
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1152887
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212965
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Commit-Queue: Ying Wang <yinwa@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33559}
This is a reland of 89cb65ed663a9000b9f7c90a78039bd85731e9ae
... and f28aade91dcc2cb8f590dc1379ac7ab5c1981909
Reason for revert: crashes due to uninitialized pacing_bitrate_
crbug.com/1190547
Apparently pacer() is sometimes being used before EnsureStarted()
Fix: Instead of delaying first call to SetPacingRates(),
this CL no-ops MaybeProcessPackets() until EnsureStarted()
is called for the first time.
Original change's description:
> [Battery]: Delay start of TaskQueuePacedSender.
>
> To avoid unnecessary repeating tasks, TaskQueuePacedSender is started
> only upon RtpTransportControllerSend::EnsureStarted().
>
> More specifically, the repeating task happens in
> TaskQueuePacedSender::MaybeProcessPackets() every 500ms, using a self
> task_queue_.PostDelayedTask().
>
> Bug: chromium:1152887
> Change-Id: I72c96d2c4b491d5edb45a30b210b3797165cbf48
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208560
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33421}
Bug: chromium:1152887
Change-Id: I9aba4882a64bbee7d97ace9059dea8a24c144f93
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212880
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33554}
This API should allow existing factories to be used unmodified, but
offers a new API that documents ownership better and does not use
sigslot.
Bug: webrtc:12598
Change-Id: I0f68371059cd4a18ab07b87fc0e7526dcc0ac669
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212609
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33553}
At the point where an EncodedImage is reported to the
EncoderBitrateAdjuster (in order to estimate utilization), the image
data has been cleared so the size is 0 - meaning the esimtated
utilization is 0 so pushback is in effect only applied at the
beginning before an estimate is available.
This CL fixes that by explicitly using spatial/temporal id and size in
bytes, rather than passing along the EncodedImage proxy.
It is unclear when this broke, but the regression seems rather old.
This CL will affect the encoded bitrate (and thus indirectly BWE
ramp-up rate), but should avoid exessive delay at low bitrates.
Perf bots will likely trigger alerts, this is expected.
In case there are undesired side-effects, we can entirely disable the
adjuster using existing field-trials.
Bug: webrtc:12606
Change-Id: I936c2045f554696d8b4bb518eee6871ffc12c47d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212900
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33550}
