File: fmtp-x-google-per-layer-pli.md

package info (click to toggle)
chromium 138.0.7204.183-1
  • links: PTS, VCS
  • area: main
  • in suites: trixie
  • size: 6,071,908 kB
  • sloc: cpp: 34,937,088; ansic: 7,176,967; javascript: 4,110,704; python: 1,419,953; asm: 946,768; xml: 739,971; pascal: 187,324; sh: 89,623; perl: 88,663; objc: 79,944; sql: 50,304; cs: 41,786; fortran: 24,137; makefile: 21,806; php: 13,980; tcl: 13,166; yacc: 8,925; ruby: 7,485; awk: 3,720; lisp: 3,096; lex: 1,327; ada: 727; jsp: 228; sed: 36
file content (36 lines) | stat: -rw-r--r-- 1,537 bytes parent folder | download | duplicates (20)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# x-google-per-layer-pli FMTP parameter

The x-google-per-layer-pli FMTP parameter is a format specific parameter
that can be added to a remote description in the `a=fmtp:` line:
  a=fmtp:96 x-google-per-layer-pli=1

When using simulcast with more than a single SSRC, it will change how the
simulcast encoder reacts to Picture Loss Indication (PLI) and Full Intra
Request (FIR) RTCP feedback.

When the parameter value is 1, a PLI requests the generation of a key frame
for the spatial layer associated with the SSRC of the media source and a
FIR does the same for the SSRC value of the media sender.

When the value is 0 or the parameter is missing, a keyframe is generated
on all spatial layers for backward compability.

## Experimentation

This parameter does allow for large-scale A/B testing and opt-in to the
new behavior. For multiparty calls enabling it should reduce the number of
keyframes sent by the client and number of key frames received by the
receivers which results in a better bandwidth utilization.

This parameter is experimental and may be removed again in the future.

## IANA considerations

Since the current behavior of reacting to a PLI for a specific SSRC with
key frames on all spatial layers can be considered an implementation bug
this parameter is not registered with the IANA.

If experimentation shows that the current behavior is better for some
codecs like VP8 which can share encoding parameters with synchronous
keyframes a standardized variant of this parameter shall be registered
with the IANA.