With this CL, we normalize the resolution coming from the
capturer, before applying the requested scaling factors.
That has the benefit that the actual scale factor between
two layers will be the fraction of the requested scale
factors of the two layers.
Prior to this CL, when the normalization was done per layer,
the actual scale factor between two layers might not
have been the fraction of the requested scale factors
of the two layers.
Bug: webrtc:10069
Change-Id: I9ca4d394f259d5d37faee96a41204ff8df898907
Reviewed-on: https://webrtc-review.googlesource.com/c/121425
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Mirta Dvornicic <mirtad@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26550}
Wire up partial video frames in video quality tests
Bug: webrtc:10152
Change-Id: Ifa13bb308258c8d3930a6cfbcc97c95b132cecf3
Reviewed-on: https://webrtc-review.googlesource.com/c/120410
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26549}
With the current implementation, whenever we are toggling between
sending/not sending retransmissions, the BitrateAllocator will
toggle the total requested max bitrate that is signalled to the
probing mechanism. The result is that spurious probes are sent
mid-call, at |max_bitrate| and |2*max_bitrate|. This behaviour
is undesirable, and thus removed in this CL. Instead, whenever
the allocation limits actually change, we produce a single
set of probes at |max_bitrate| and |2*max_bitrate|.
This CL does not change how the BitrateAllocator hysteresis is
accounting for protection, since it does not relate to the
spurious probes.
Bug: webrtc:10275
TBR: sprang@webrtc.org
Change-Id: Iab3a690a500372c74772a8ad6217fb838af15ade
Reviewed-on: https://webrtc-review.googlesource.com/c/120808
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26544}
This layer is not needed since the methods are thread safe, and the
classes those method touches (VideoBroadcaster, cricket::VideoAdapter)
are thread safe.
Bug: webrtc:10247
Change-Id: Id4e309de4ac1b9669052aaa60d3bd1ed965aaa29
Reviewed-on: https://webrtc-review.googlesource.com/c/120801
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26543}
Adds methods AddNetworkChangeCallback and RemoveNetworkChangeCallback,
to replace SetNetworkChangeCallback. Needed because both VideoChannel
and VoiceChannel register such a callback.
This cl is step 1, it just adds the methods to the interface, without
calling them.
Bug: webrtc:9719
Change-Id: I39f1748706d4369ca71d594ca5e2f1380de5ce66
Reviewed-on: https://webrtc-review.googlesource.com/c/121462
Reviewed-by: Peter Slatala <psla@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26541}
In order to have correct overhead adjustments for ANA in AudioSendStream we need to know both transport and audio packetization overheads in AudioSendStream. This change makes AudioSendStream to be OverheadObserver instead of ChannelSend. This change is required for https://webrtc-review.googlesource.com/c/src/+/115082.
This change was also suggested earlier in TODO:
// TODO(solenberg): Make AudioSendStream an OverheadObserver instead.
https://cs.chromium.org/chromium/src/third_party/webrtc/audio/channel_send.cc?rcl=71b5a7df7794bbc4103296fcd8bd740acebdc901&l=1181
I think we should also consider moving TargetTransferRate observer to AudioSendStream. Since AudioSendStream owns encoder and configures ANA, it makes sense to consolidate all rate (and overhead) calculation there. Added TODO to clean it up in next chanelists.
Bug: webrtc:10150
Change-Id: I48791b998ea00ffde9ec75c6bca8b6dc83001b42
Reviewed-on: https://webrtc-review.googlesource.com/c/119121
Commit-Queue: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26540}
GetStreamCaps can return S_FALSE, which is not caught by FAILED().
Instead it is necessary to compare for equality with S_OK.
Bug: webrtc:10267
Change-Id: I4113ef5544f830f5cb5f09f143dff43129993d3d
Reviewed-on: https://webrtc-review.googlesource.com/c/120644
Commit-Queue: Dan Minor <dminor@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26539}
TCPPort's incoming_only_ member seems unused and there was a TODO
about this. This CL just removes it.
Bug: webrtc:10198
Change-Id: I216c291159a32fa2924309affa3769a4be116fd0
Reviewed-on: https://webrtc-review.googlesource.com/c/120931
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26538}
This is first step to allow to set latency
from client code in Chromium.
Existing minimum latency hasn't been used because it can clash
with video syncronization code.
Bug: webrtc:10287
Change-Id: Ia38906506069a1abfa01698dc62df283fc15cfbc
Reviewed-on: https://webrtc-review.googlesource.com/c/121423
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Ruslan Burakov <kuddai@google.com>
Cr-Commit-Position: refs/heads/master@{#26536}
JNI_COMMIT doesn't actually free the buffer.
From JNI docs:
0: copy back the content and free the elems buffer
JNI_COMMIT: copy back the content but do not free the elems buffer
JNI_ABORT: free the buffer without copying back the possible changes
Also introduces helper methods to help avoid this problem in the
future.
Bug: webrtc:10132
Change-Id: I769df286d3bd186fdf39ee2363e9002f36454509
Reviewed-on: https://webrtc-review.googlesource.com/c/120600
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26529}
The usage of "nogncheck" is disallowed in WebRTC (the only exception is
for the "#includes" that are part of conditional compilation with the
preprocessor).
This CL removes some "nogncheck" from the pc/ folder. The included
headers were unused so this should be a no-op change.
Bug: webrtc:8733
Change-Id: I22f5238bbc08aa500d4f0850e30acfbaed9742ae
Reviewed-on: https://webrtc-review.googlesource.com/c/120929
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26528}
This CL introduces a new rtp_generator tool that can be utilized to generate
.rtpdump files that can be replayed by the video_replayer. This allows
automated generation of corpus material for the new WebRTC RTP fuzzers in
addition to allowing anyone who is experimenting with a new RTP feature to
quickly debug issues.
It can be used as follows:
./rtp_generator --input_config=./rtc_tools/rtp_generator/configs/vp8.json --output_rtpdump=/tmp/vp8.rtpdump
./video_replay --config_file test/fuzzers/configs/replay_packet_fuzzer/vp8_config.json --input_file /tmp/vp8.rtpdump
It works by generating squares randomly on the screen for a given duration. This
initial version is very limited and doesn't support FEC, RED and other
configurations. I plan to extend it to support these in future CLs.
Bug: webrtc:10117
Change-Id: I31d3dbb6fad73c727145ead4e7d085113d11fc51
Reviewed-on: https://webrtc-review.googlesource.com/c/119964
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26517}
Update RtpSenderAudioTest to call methods on RTPSenderAudio rather
than RTPSender, when possible. In particular, avoid
RTPSender::SendOutgoingData. Drop parameterization on the
WebRTC-SendSideBwe-WithOverhead field trial, since that appears
unrelated to these tests.
Also delete some unused parts of the RtpSender test.
Bug: webrtc:7135
Change-Id: I535bf48bb1720e2727f4a62fa3e49b2bb84394a0
Reviewed-on: https://webrtc-review.googlesource.com/c/120920
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26516}
Calling ModuleRtpRtcpImpl::SetSendingStatus or
ModuleRtpRtcpImpl::SetSendingMediaStatus doesn't change the
current sequence number, which is part of the RTPSender state.
Bug: webrtc:2111
Change-Id: I432d4daa7ab4cc25d87b90c8b1b255359ffbe3a3
Reviewed-on: https://webrtc-review.googlesource.com/c/120401
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26513}
Prior to this CL, when software VP8 encoding was done with one temporal
layer, instead of only predicting from the latest frame, the code
allowed the encoder to reference the latest key frame as well.
This improves quality for the few frames immediately after
the key frame, but is not useful for later frames, which diverge
significantly from the key frame. However, the cost of producing
the prediction from more than one reference is incurred by all frames.
My measurements of the effect of this show an improvement
in CPU utilization of 5%-13% when this is not done.
foreman_352x288, 30fps, target bitrate 500kps
Pre-change:
send_enc_speed_fps: avg(566.187, 570.012, 575.665) = 570.621
send_avg_qp: 45.36
send_avg_psnr: 37.13
Post-change:
send_enc_speed_fps: avg(633.188, 604.694, 623.232) = 620.371
send_avg_qp: 45.88
send_avg_psnr: 37.0749
Improvement in send_enc_speed_fps: 8.71%
foreman_480x272, 30fps, target bitrate 500kps
Pre-change:
send_enc_speed_fps: avg(481.244, 486.971, 487.322) = 485.179
send_avg_qp: 48.9
send_avg_psnr: 37.6217
Post-change:
send_enc_speed_fps: avg(521.651, 499.416, 511.551) = 510.872
send_avg_qp: 48.88
send_avg_psnr: 37.6094
Improvement in send_enc_speed_fps: 5.29%
news_352x288, 30fps, target bitrate 500kps
Pre-change:
send_enc_speed_fps: avg(699.407, 697.837, 699.49) = 698.9113333
send_avg_qp: 24.15
send_avg_psnr: 40.9551
Post-change:
send_enc_speed_fps: avg(758.526, 768.104, 757.232) = 761.2873333
send_avg_qp: 23.9833
send_avg_psnr: 40.9697
Improvement in send_enc_speed_fps: 8.92%
Bridge_180x320_15 (video of brandtr@ from Google), 15fps, target bitrate 500kps
Pre-change:
send_enc_speed_fps: avg(454.757, 450.399, 446.812) = 450.656
send_avg_qp: 17.6771
send_avg_psnr: 39.9267
Post-change:
send_enc_speed_fps: avg(500.014, 513.316, 513.613) = 508.981
send_avg_qp: 17.6837
send_avg_psnr: 39.9137
Improvement in send_enc_speed_fps: 12.94%
Bug: webrtc:10281
Change-Id: If02736e1535c5f46689fd42b657e35a1e1f64d6d
Reviewed-on: https://webrtc-review.googlesource.com/c/120904
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26511}
It doesn't do anything any more, so it should be removed.
Bug: webrtc:9586
Change-Id: I0b320b6ce4f480ff8cb59451db29bcc77b882b5f
Reviewed-on: https://webrtc-review.googlesource.com/c/120813
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26507}
