This ensures that the payload descriptor and potential generic
descriptors uses the same temporal layer.
Bug: b/200518293
Change-Id: I17e980b47fe6c814cb393fc459064576447aa27a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236520
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35275}
Field trial is not used in any rollouts and should be removed.
R=mhoro@webrtc.org
Bug: webrtc:13264
Change-Id: Ib896dcdec81db7c3f4e68a8dda266d96dfdc6aed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/234865
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Michael Horowitz <mhoro@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35195}
It seems the Android CTS tests only verify that 16x16 aligned resolutions
are supported.
This change checks the validity of input frame's size when initialing
or encoding processes are about to start using H/W MediaCodec.
This change has additional APIs to retrieve
|requested_resolution_alignment| and |apply_alignment_to_all_simulcast_layers|
from JAVA VideoEncoder class and its inherited classes. HardwareVideoEncoder
using MediaCodec has values of 16 and true for above variables.
Bug: webrtc:13089
Change-Id: I0c4ebf94eb36da29c2e384a3edf85b82e779b7f9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229460
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35169}
The |slice_qp_detla| reported by the hardware is not credible, which
causing the quality scaler cannot work properly,the resolution cannot
be adjusted correctly.
To fix this issue, this CL implements a bandwidth scaler which is used
for adjust resolution, this scaler will be used when QP based quality
scaler is not working due to untrusted QP reported by HW AVC encoder.
Bug: webrtc:12942
Change-Id: I2fc5f07a5400ec7e5ead2c2c502faee84d7f2a76
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228860
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35120}
min_pacing:8ms, to avoid the situation where bursts of frames are sent
to the decoder at once due to network jitter. The bursts of frames
caused the queues further down in the processing to be full and
therefore drop all frames.
max_decode_queue_size:8, in the event that too many frames have piled
up, do as before and send all frames to the decoder to avoid building
up any latency.
These setting only affect the low-latency video pipeline that is enabled
by setting the playout RTP header extension to min=0ms, max>0ms.
Bug: chromium:1138888
Change-Id: I8154bf3efe7450b770da8387f8fb6b23f6be26bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/233220
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35119}
All valid scalability modes should be supported by the builtin
software decoder/encoder.
Bug: chromium:1187565
Change-Id: If66105d210d5055019f35dae2f80a18ad4a70cdd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222642
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34998}
The VP9 encoder may drop a frame internally which will not advance the
frame pattern. Consider the following scenario where only spatial layer
0 and temporal layer 0 is active:
1. Key frame encoded
2. Spatial layer 1 is activated
3. Delta T0 dropped
4. Delta T0 encoded
No S1T0 frame is encoded in (1) since it's not active. When
NextFrameConfig is called in (3) it will say that future frames may
reference T0 on both S0 and S1, but it's then dropped.
On step (4), the SVC controller essentially thinks it's encoding a new
picture and will happily reference the T0 on what it thinks is the first
delta frame. However, this is actually still the key frame and since
there was no S1T0 frame produced it will reference an invalid buffer.
To fix this, only say it's possible to reference a T0 frame after it has
been successfully encoded.
Bug: webrtc:11999, webrtc:13142, chromium:1178444
Change-Id: Iab3d2042ce0b3fa7d952b2831d1a36b1a6613a86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231695
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34982}
Unlike libvpx, the VideoBitrateAllocation expects that the bitrate
allocation is separate for each temporal layer. In this instance, if the
bitrates are not separated it will fool the SVC controller into thinking
that all temporal layers are always active.
Bug: webrtc:11999
Change-Id: Ibc33ac00b8b7716c011b94e1ec9c640cedb5274e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231693
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34980}
This cover scenario where target bitrate is changed in a middle of
of group of frame after spatial upswitch.
This change should avoid wasting encoder resources to produce those
frames, reduce number of errors
"Encoder produced a frame for layer that wasn't requested"
Bug: webrtc:11999
Change-Id: I06045259b1cee2c21bfdabbafff3892b57c82a84
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230543
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34969}
delta_q is encoded as signed integer (s(4)) that uses extra bit for the
sign. See VP9 Bitstream Specification section 6.2.10 Delta quantizer syntax
Bug: None
Change-Id: Ib458c2a2ded3c4d6c153b6bedd29c48ef12cc538
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231125
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34908}
This is a reland of 3097008de0
Patchset 1 is a pure reland. Patchset 2 contains a bugfix plus a test
covering that case.
Bug: webrtc:12354, chromium:1230448
Original change's description:
> Rename vp9::FrameInfo to vp9::UncompressedHeader and add more fields.
>
> These fields will be used for bitstream validation in upcoming CLs.
> A new vp9_constants.h file is also added, containing common constants
> defined by the bitstream spec.
>
> Bug: webrtc:12354
> Change-Id: If04256d83409069c8bee43ad41aed41c3707dfd3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226060
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Philip Eliasson <philipel@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34476}
Bug: webrtc:12354
Change-Id: Ibd301eb458a6104b562cefbc0e616c39b54fb38b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229060
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34789}
from runtime check in proxy classes that picks decoder (VCMDecoderDataBase)
to a DCHECK in the VideoDecoder::Settings
Bug: None
Change-Id: Ic8c2e971486a3a7eb247f9d03815aba5ca5a7bad
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228644
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34761}
As a first step we only want to enable frame pacing for the case
where min playout delay == 0 and max playout delay > 0.
Bug: chromium:1237402, chromium:1239469
Change-Id: Icf9641db7566083d0279135efa8618e435d881eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228640
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34752}
When pacing is enabled for the low latency rendering path,
frames are sent to the decoder in regular intervals. In case of a
jitter, these frames intervals could add up to create a large latency.
Hence, disable frame pacing if the pre-decode queue grows beyond the
threshold. The threshold for when to disable frame pacing is set
through a field trial. The default value is high enough so that
the behavior is not changed unless the field trial is specified.
Bug: chromium:1237402
Change-Id: I901fd579f68da286eca3d654118f60d3c55e21ce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228241
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34705}
Remove private members that are no longer used or always have same value
Use less allocations
Bug: None
Change-Id: I5430c2356f0039212baf8b248b92775e8852ce1b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227765
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34665}
Schedule the frames to be decoded based on the pacing delay from the
last decode scheduled time. In the current implementation, multiple
threads and different functions in same thread can call
MaxWaitingTime(), thereby increasing the wait time each time the
function is called. Instead of returning the wait time for a future
frame based on the number of times the function is called, return the
wait time only for the next frame to be decoded. Threads can call the
function repeatedly to check the waiting time for next frame and wake
up and then go back to waiting if an encoded frame is not available.
Change-Id: I00886c1619599f94bde5d5eb87405572e435bd73
Bug: chromium:1237402
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226502
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34660}
