WebRTC용 확장형 비디오 코딩(SVC) 확장

비규범적으로 표시된 절뿐만 아니라 이 명세의 모든 작성 지침, 다이어그램, 예제 및 참고 사항은 비규범적입니다. 이 명세의 나머지 모든 내용은 규범적입니다.

이 문서에서 키워드 할 수 있습니다, 해야 합니다 및 하는 것이 좋습니다는 여기에 표시된 것처럼 모두 대문자로 나타날 때에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 합니다.

이 명세는 다음과 같은 단일 제품에 적용되는 적합성 기준을 정의합니다. 즉, 이 명세에 포함된 인터페이스를 구현하는 사용자 에이전트입니다.

알고리즘이나 특정 단계로 표현된 적합성 요구사항은 최종 결과가 동등한 한 어떤 방식으로든 구현할 수 있습니다. 특히 이 명세에서 정의하는 알고리즘은 이해하기 쉽도록 의도된 것이며, 성능을 높이기 위한 것은 아닙니다.

이 명세에서 정의하는 API를 구현하기 위해 ECMAScript를 사용하는 구현은 Web IDL 명세 [WEBIDL]에 정의된 ECMAScript 바인딩과 일관된 방식으로 이를 구현해야 합니다. 이 명세가 해당 명세와 그 용어를 사용하기 때문입니다.

"동시 전송 범위"라는 용어는 [WEBRTC] 제 5.4.1절에 정의되어 있습니다.

이 명세에서는 [WEBRTC]에 정의된 객체, 메서드, 내부 슬롯 및 딕셔너리를 참조합니다.

확장 가능 비디오 코딩(SVC)의 경우, "단일 세션 전송" (SST) 및 "다중 세션 전송" (MST)이라는 용어는 [RFC6190]에 정의되어 있습니다. 이 명세는 SST만 지원하며 MST는 지원하지 않습니다.

[RFC7656] 제3.7절에 정의된 "단일 실시간 전송 프로토콜 스트림 단일 전송" (SRST)이라는 용어는 단일 실시간 전송 프로토콜(RTP) 스트림과 동기화 소스(SSRC)를 사용하여 단일 전송 내에서 모든 계층을 전송하는 SVC 구현을 의미합니다. 역시 [RFC7656] 제3.7절에 정의된 "다중 RTP 스트림 단일 전송" (MRST)이라는 용어는 각 계층마다 별도의 SSRC가 있는 여러 RTP 스트림을 사용하여 단일 전송 내에서 모든 계층을 전송하는 구현을 의미합니다. 이 명세는 SRST만 지원하며, MRST는 지원하지 않습니다. SRST를 지원하는 RTP 페이로드 명세를 가진 코덱에는 VP8 [RFC7741], VP9 [VP9-PAYLOAD], AV1 [AV1-RTP-SPEC], H.264 [RFC6184] 및 H.265 [RFC7798]가 포함됩니다.

"S 모드"라는 용어는 동일한 SSRC를 통해 여러 인코딩이 전송되는 확장성 모드를 의미합니다. 여기에는 "S2T1", "S2T1h", "S2T2", "S2T2h", "S2T3", "S2T3h", "S3T1", "S3T1h", "S3T2", "S3T2h", "S3T3" 및 "S3T3h" scalabilityMode 값이 포함됩니다.

선택적 전달 미들박스 (SFM)라는 용어는 [RFC7667] 제3.7절에 정의되어 있습니다.

이 명세는 RTCRtpEncodingParameters 딕셔너리를 확장하여 SVC의 인코딩 매개변수를 구성할 수 있도록 합니다.

WebIDLpartial dictionary RTCRtpEncodingParameters {
             DOMString scalabilityMode;
};

scalabilityMode의 형식은 DOMString입니다: 이 멤버는 송신자의 kind가 "video"인 경우에만 존재할 수 있습니다. 존재하는 경우 이 스트림에 사용할 확장성 모드의 대소문자를 구분하는 식별자를 나타냅니다. 확장성 모드는 제5절에 정의되어 있습니다.

[WEBRTC]에서는 addTransceiver() (제5.1절) 및 setParameters() (제5.2절)의 오류 처리를 설명하며, 지원되지 않는 인코딩 매개변수로 인한 "hardware-encoder-error"를 나타내기 위한 RTCError 사용과 기타 오류를 포함합니다. 잘못된 scalabilityMode 값이 setParameters() 또는 addTransceiver()에 제공되면 구현은 규정된 방식으로 RTCError 및 기타 오류를 사용합니다.

[WEBRTC] 제5.1절에서는 addTransceiver() 내에서 sendEncodings의 유효성 검사를 설명합니다. scalabilityMode의 유효성을 검사하려면 addTransceiver sendEncodings 유효성 검사 단계의 3단계 뒤에 다음 단계를 추가합니다:

sendEncodings가 포함하는 인코딩 중 codec 값 codec이 존재하고 동일한 인코딩의 scalabilityMode 값이 codec에서 지원되지 않는 것이 있으면, OperationError를 발생시킵니다.
그렇지 않고 sendEncodings가 포함하는 인코딩 중 scalabilityMode 값이 kind에 대한 구현된 송신 코덱 목록의 어떤 코덱에서도 지원되지 않는 것이 있으면, OperationError를 발생시킵니다.
sendEncodings에 저장된 RTCRtpEncodingParameters가 값이 true인 active 멤버를 가진 인코딩을 1개보다 많이 포함하고, sendEncodings가 scalabilityMode 값이 "S 모드"를 나타내며 active 멤버의 값이 true인 인코딩을 포함하면, OperationError를 발생시킵니다.

addTransceiver() 및 setCodecPreferences() 메서드가 Offer/Answer 협상이 완료되기 전에 호출되면, 협상된 코덱과 해당 기능을 알 수 없을 수도 있습니다. 이러한 상황에서는 sendEncodings에 구성된 scalabilityMode 값이 최종적으로 협상된 코덱에서 지원되지 않을 수 있습니다. 그러나 요청된 scalabilityMode 값이 지원되는 모든 코덱에서 유효하지 않거나 혼합 동시 전송 방식이 요청된 경우에만 오류가 발생합니다.

원하는 scalabilityMode 값을 적용할 수 있도록 하기 위해, setCodecPreferences()를 사용하여 원하는 구성을 지원하는 코덱을 우선하거나 해당 코덱만 포함할 수 있습니다. 예를 들어 공간적 동시 전송과 함께 시간적 확장성을 원하는 경우 addTransceiver()를 호출할 때 sendEncodings를 서로 다른 해상도의 여러 동시 전송 스트림을 전송하도록 구성할 수 있으며, 각 스트림은 시간적 확장성을 사용합니다. VP8, VP9 및 AV1 코덱 구현만 시간적 확장성을 지원하는 경우, setCodecPreferences()를 사용하여 Offer에서 H.264/AVC 코덱을 제거함으로써 시간적 확장성을 지원하는 코덱이 협상될 가능성을 높일 수 있습니다.

sendEncodings를 사용하여 addTransceiver()로 여러 동시 전송 스트림의 전송을 요청하는 경우 "S 모드"를 요청할 수 없습니다. 브라우저는 여러 SSRC와 RID를 사용하여 동시 전송 인코딩을 전송하거나, 대신 모든 동시 전송 인코딩을 하나의 RTP 스트림으로 전송하도록만 구성할 수 있습니다. 두 동시 전송 방식을 동시에 사용하는 것은 허용되지 않습니다.

[WEBRTC] 제5.2절에서는 setParameters() 내에서 parameters의 유효성 검사를 설명합니다. setParameters 유효성 검사 단계의 연산이 InvalidModificationError로 거부된 프로미스를 발생시키는 조건 목록(6단계)에 다음 조건을 삽입합니다:

encodings가 포함하는 encoding 중 존재하는 codec 값 codec을 가지고 있으며, encoding의 scalabilityMode 값이 codec에서 지원되지 않는 것이 있습니다.
sender.[[SendCodecs]]가 비어 있고, encodings가 scalabilityMode 값이 kind에 대한 구현된 송신 코덱 목록의 어떤 코덱에서도 지원되지 않는 인코딩을 포함합니다.
sender.[[SendCodecs]]가 비어 있지 않고, encodings가 scalabilityMode 값을 sender.[[SendCodecs]]의 어떤 코덱으로도 충족할 수 없는 인코딩을 포함합니다.
encodings가 값이 true인 active 멤버를 가진 인코딩을 1개보다 많이 포함하고, encodings가 scalabilityMode 값이 "S 모드"를 나타내며 active 멤버의 값이 true인 인코딩을 포함합니다.

"L1T1" 확장성 모드는 setParameters()를 사용하여 SVC 인코딩을 끌 수 있도록 합니다. "L1T1"이 setParameters()를 사용하여 설정된 경우 getParameters()에 대한 응답으로 반환됩니다.

초기 협상이 완료되기 전에 getParameters()는 addTransceiver() 또는 setParameters()에 의해 마지막으로 설정된 대로, encodings의 각 인코딩에 대한 scalabilityMode 값을 반환합니다. encodings의 인코딩에 대해 scalabilityMode 값이 제공되지 않았거나, 값이 성공적으로 설정되지 않은 경우 getParameters()는 해당 인코딩에 대한 scalabilityMode 값을 반환하지 않습니다.

초기 협상이 완료된 후에는 getParameters()가 초기 협상 전에 값이 있었던 encodings의 각 인코딩에 대해 현재 구성된 scalabilityMode 값을 반환합니다. 이는 addTransceiver() 또는 setParameters()에서 요청된 값과 다를 수 있습니다. 예를 들어 협상 중 선택된 코덱에 원하는 scalabilityMode 값을 지원하는 인코더가 포함되어 있지 않으면, 사용자 에이전트는 다른 값을 선택할 수 있습니다. 구성이 만족스럽지 않은 경우 setParameters()를 사용하여 변경할 수 있습니다.

addTransceiver() 또는 setParameters()가 encodings의 인코딩에 대해 scalabilityMode 값을 제공하지 않았다면, 초기 협상이 완료된 후 getParameters()는 scalabilityMode 값을 반환하지 않으며, 인코더는 해당 인코딩의 RTP 스트림에 대해 코덱의 기본 scalabilityMode를 사용합니다. 각 코덱의 기본 scalabilityMode는 구현에 따라 다릅니다. 기본 scalabilityMode는 시간적 확장성 모드 중 하나(예: "L1T1","L1T2","L1T3" 등)여야 합니다.

이 절은 비규범적입니다.

SVC는 화상 회의에서 가장 자주 사용되며, 여기서 SFM과 같은 회의 서버는 참가자의 기기 특성과 사용 가능한 대역폭에 따라 계층을 선택적으로 전달합니다. 이러한 환경에서 애플리케이션은 회의 서버와 송수신할 코덱을 협상합니다. 그러나 확장성 모드는 Offer/Answer에서 협상되지 않으므로, 애플리케이션은 브라우저와 회의 서버가 지원하는 확장성 모드를 다른 방법으로 확인해야 합니다.

[Media-Capabilities] API를 사용하면 확장 가능 비디오 코딩에 대한 인코더 및 디코더 지원 여부를 확인할 수 있습니다. scalabilityMode는 인코더가 scalabilityMode 값을 지원하는지 질의하는 데 사용되며, 해당 값이 "지원됨", "원활함" 및 "전력 효율적임"인지를 나타냅니다.

[Media-Capabilities] API는 공간적 확장성 모드에 대한 디코더 지원 정보도 제공합니다. spatialScalability는 디코더가 공간적 예측을 지원할 수 있는지를 나타내며, 이는 현재 해상도와 다른 해상도의 프레임을 종속성으로 사용할 수 있어야 합니다. spatialScalability가 true로 설정되어 있으면, 디코더는 인코더가 지원하는 모든 scalabilityMode 값을 디코딩할 수 있습니다. spatialScalability가 false로 설정되어 있거나 존재하지 않으면, 디코더는 공간적 확장성 모드를 디코딩할 수 없지만, 인코더가 지원하는 다른 모든 scalabilityMode 값은 디코딩할 수 있습니다.

애플리케이션이 사용할 수 있는 코덱과 scalabilityMode 값의 조합을 파악한 후에는, 이 조합 중 어느 것이 SFM에서 지원되는지 확인해야 합니다. 이를 처리하는 한 가지 방법은 SFM이 전달할 수 있는 코덱과 확장성 모드의 조합을 수신자 기능의 형태로 표시하는 것입니다. SFM의 기능을 수신한 후 애플리케이션은 브라우저의 RTCRtpSender와 SFM의 수신자가 지원하는 코덱과 scalabilityMode 값의 교집합을 계산할 수 있습니다. 이를 사용하여 브라우저의 addTransceiver() 및 setParameters() 메서드에 전달할 인수를 결정할 수 있습니다.

몇 가지 예는 다음과 같습니다:

코덱 페이로드를 파싱하는 SFM은 확장성이 없는 H.264/AVC 코덱과 시간적 확장성이 있는 VP8 코덱만 지원할 수 있습니다. 반면 브라우저는 시간적 확장성이 있는 VP8, 시간적 및 공간적 확장성이 있는 VP9 및 AV1, 시간적 확장성이 있는 H.264/AVC를 인코딩할 수 있습니다. 이 예에서 SVC를 사용하려는 애플리케이션은 시간적 확장성이 있는 VP8만 인코딩할 수 있습니다.
SFM은 AV1 코덱에서 "S2T1" 및 "S2T1h" 확장성 모드를 사용하는 단일 스트림 동시 전송만 지원할 수 있는 반면, 브라우저는 VP9 및 AV1 코덱 모두에서 "S2T1", "S2T1h", "S3T1" 및 "S3T1h" 모드를 사용하는 단일 스트림 동시 전송을 인코딩할 수 있습니다. 이 예에서 애플리케이션은 AV1 코덱에서 최대 두 계층으로만 단일 스트림 동시 전송을 사용할 수 있습니다. 애플리케이션이 세 계층을 사용하는 것을 선호하는 경우, 단일 스트림 동시 전송의 사용을 포기하고 대신 다중 스트림 동시 전송을 협상하기로 결정할 수 있습니다.

브라우저와 SFM 기능의 교집합을 계산할 때 RTP 헤더 확장을 고려해야 하는 경우가 있습니다. SFM이 코덱 페이로드를 파싱할 수 없다면 (그렇게 하도록 설계되지 않았거나 페이로드가 암호화되어 있기 때문에), 특정 코덱을 전달하기 위해서는 RTP 헤더 확장([AV1-RTP-SPEC] 부록 A에 정의된 AV1 종속성 설명자 등)의 협상이 필요할 수 있습니다. SFM이 특정 코덱을 전달하기 위해서입니다. 이를 고려하기 위해 코덱 전달에 필요한 RTP 헤더 확장을 SFM의 수신자 기능에 추가할 수 있습니다. 그러면 애플리케이션은 브라우저의 RTCRtpSender와 SFM의 수신자가 지원하는 코덱, 헤더 확장 및 scalabilityMode 값의 교집합을 계산할 수 있습니다.

이 명세에서 지원되는 scalabilityMode 값과 관련 식별자 및 특성은 아래 표에 제공되어 있습니다. scalabilityMode 값의 이름 (대소문자를 구분함)은 [AV1] 제6.7.5절에서 할당된 확장성 모드 식별자 및 제9절에 제공된 종속성 다이어그램 링크와 함께 제공됩니다.

[AV1] 및 VP9 [VP9] 명세는 표에 정의된 모든 scalabilityMode 값을 지원하지만, 다른 코덱 명세는 그렇지 않습니다. 예를 들어 VP8 [RFC6386], H.264 [RFC6184] 및 H.265 [RFC7798]는 시간적 확장성만 지원합니다(예: "L1T2", "L1T3"). 또한 VP8 [RFC6386], H.264 [RFC6184] 및 H.265 [RFC7798]는 서로 다른 SSRC를 통한 동시 전송의 전송만 허용하므로, "S" 모드(여러 인코딩이 하나의 RTP 스트림으로 전송되는 경우)는 지원되지 않습니다.

확장성 모드 식별자	공간 계층	해상도 비율	시간 계층	계층 간 종속성	AV1 scalability_mode_idc
"L1T1"	1		1		해당 없음
"L1T2"	1		2		SCALABILITY_L1T2
"L1T3"	1		3		SCALABILITY_L1T3
"L2T1"	2	2:1	1	예	SCALABILITY_L2T1
"L2T2"	2	2:1	2	예	SCALABILITY_L2T2
"L2T3"	2	2:1	3	예	SCALABILITY_L2T3
"L3T1"	3	2:1	1	예	SCALABILITY_L3T1
"L3T2"	3	2:1	2	예	SCALABILITY_L3T2
"L3T3"	3	2:1	3	예	SCALABILITY_L3T3
"L2T1h"	2	1.5:1	1	예	SCALABILITY_L2T1h
"L2T2h"	2	1.5:1	2	예	SCALABILITY_L2T2h
"L2T3h"	2	1.5:1	3	예	SCALABILITY_L2T3h
"L3T1h"	3	1.5:1	1	예
"L3T2h"	3	1.5:1	2	예
"L3T3h"	3	1.5:1	3	예
"S2T1"	2	2:1	1	아니요	SCALABILITY_S2T1
"S2T2"	2	2:1	2	아니요	SCALABILITY_S2T2
"S2T3"	2	2:1	3	아니요	SCALABILITY_S2T3
"S2T1h"	2	1.5:1	1	아니요	SCALABILITY_S2T1h
"S2T2h"	2	1.5:1	2	아니요	SCALABILITY_S2T2h
"S2T3h"	2	1.5:1	3	아니요	SCALABILITY_S2T3h
"S3T1"	3	2:1	1	아니요	SCALABILITY_S3T1
"S3T2"	3	2:1	2	아니요	SCALABILITY_S3T2
"S3T3"	3	2:1	3	아니요	SCALABILITY_S3T3
"S3T1h"	3	1.5:1	1	아니요	SCALABILITY_S3T1h
"S3T2h"	3	1.5:1	2	아니요	SCALABILITY_S3T2h
"S3T3h"	3	1.5:1	3	아니요	SCALABILITY_S3T3h
"L2T2_KEY"	2	2:1	2	예	SCALABILITY_L3T2_KEY
"L2T2_KEY_SHIFT"	2	2:1	2	예	SCALABILITY_L3T2_KEY_SHIFT
"L2T3_KEY"	2	2:1	3	예	SCALABILITY_L3T3_KEY
"L2T3_KEY_SHIFT"	2	2:1	3	예	SCALABILITY_L3T3_KEY_SHIFT
"L3T1_KEY"	3	2:1	1	예
"L3T2_KEY"	3	2:1	2	예	SCALABILITY_L4T5_KEY
"L3T2_KEY_SHIFT"	3	2:1	2	예	SCALABILITY_L4T5_KEY_SHIFT
"L3T3_KEY"	3	2:1	3	예	SCALABILITY_L4T7_KEY
"L3T3_KEY_SHIFT"	3	2:1	3	예	SCALABILITY_L4T7_KEY_SHIFT

scalabilityMode 값을 제안할 때는 다음 원칙을 따라야 합니다:

제안된 scalabilityMode는 확장성 모드 식별자, 공간 및 시간 계층, 해상도 비율, 계층 간 종속성 및 해당 AV1 scalability_mode_idc 값(할당된 경우)을 포함하여 제5절의 표에 들어갈 항목을 정의해야 합니다.
확장성 모드 식별자는 기존 명명 체계와 일관되는 것이 좋습니다. 이 체계에서는 LxTy를 사용하여 2:1 해상도 비율을 사용하는 x개의 공간 계층과 y개의 시간 계층을 가진 scalabilityMode를 나타냅니다. LxTyh는 1.5:1 해상도 비율을 사용하는 x개의 공간 계층과 y개의 시간 계층을 나타냅니다. SxTy는 2:1 해상도 비율의 x개 동시 전송 인코딩을 가진 scalabilityMode를 나타내며, 각 동시 전송 인코딩에는 y개의 시간 계층이 포함됩니다. SxTyh는 1.5:1 해상도 비율을 나타냅니다. LxTy_KEY는 2:1 해상도 비율을 사용하는 x개의 공간 계층과 y개의 시간 계층을 가진 scalabilityMode를 나타내며, 여기서 공간 계층은 키 프레임에서만 더 낮은 공간 계층에 종속됩니다. LxTy_KEY_SHIFT 모드는 2:1 해상도 비율을 사용하는 x개의 공간 계층과 y개의 시간 계층을 가진 scalabilityMode를 나타내며, 여기서 공간 계층은 키 프레임에서만 더 낮은 공간 계층에 종속되고 이후 프레임의 시간 식별자는 위쪽으로 이동합니다.
제9절에 제공된 형식의 종속성 다이어그램을 제공해야 합니다.

이 절은 비규범적입니다.

이 예제는 [WEBRTC] 제7.1절(예제 1)을 확장하여 각각 3개의 시간 계층을 가진 3개의 공간 동시 전송 계층을 전송하는 방법을 보여주며, 각 동시 전송 계층에 SSRC와 RID를 사용합니다. 원래 예제에서 변경된 것은 "sendEncodings" 속성뿐입니다.

예제 1

const signaling = new SignalingChannel(); // JSON.stringify/parse를 처리합니다
const constraints = {audio: true, video: true};
const configuration = {'iceServers': [{'urls': 'stun:stun.example.org'}]};
let pc;

// 시작하려면 start()를 호출합니다
async function start() {
  pc = new RTCPeerConnection(configuration);

  // "negotiationneeded" 이벤트가 offer 생성을 트리거하도록 합니다
  pc.onnegotiationneeded = async () => {
    try {
      await pc.setLocalDescription();
      // offer를 다른 피어에 전송합니다
      signaling.send({description: pc.localDescription});
    } catch (err) {
      console.error(err);
    }
  };

  try {
    // 로컬 스트림을 가져와 셀프 뷰에 표시하고 전송되도록 추가합니다
    const stream = await navigator.mediaDevices.getUserMedia(constraints);
    selfView.srcObject = stream;
    pc.addTransceiver(stream.getAudioTracks()[0], {direction: 'sendonly'});
    pc.addTransceiver(stream.getVideoTracks()[0], {
      direction: 'sendonly',
      sendEncodings: [
        {rid: 'q', scaleResolutionDownBy: 4.0, scalabilityMode: 'L1T3'},
        {rid: 'h', scaleResolutionDownBy: 2.0, scalabilityMode: 'L1T3'},
        {rid: 'f', scalabilityMode: 'L1T3'}
      ]
    });
  } catch (err) {
    console.error(err);
  }
}

signaling.onmessage = async ({data: {description, candidate}}) => {
  try {
    if (description) {
      await pc.setRemoteDescription(description);
      // offer를 받은 경우 answer로 응답해야 합니다
      if (description.type == 'offer') {
        await pc.setLocalDescription();
        signaling.send({description: pc.localDescription});
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

다음은 2개의 공간 계층(2:1 비율)과 3개의 시간 계층을 사용하는 예제입니다.

예제 2

let sendEncodings = [
  {scalabilityMode: 'L2T3'}
];

다음은 각 동시 전송 계층이 3개의 시간 계층을 가지는 혼합 코덱 동시 전송의 예제입니다.

예제 3

let sendEncodings = [
  {rid: 'q', codec: {clockRate: 90000, mimeType: 'video/AV1'}, scaleResolutionDownBy: 4.0, scalabilityMode: 'L1T3'},
  {rid: 'h', codec: {clockRate: 90000, mimeType: 'video/VP8'}, scaleResolutionDownBy: 2.0, scalabilityMode: 'L1T3'},
  {rid: 'f', codec: {clockRate: 90000, mimeType: 'video/VP8'}, scalabilityMode: 'L1T3'}
];

다음은 하나의 SSRC에서 각각 3개의 시간 계층을 가진 3개의 공간 동시 전송 계층을 사용하는 예제입니다.

예제 4

let sendEncodings = [
  {scalabilityMode: 'S3T3'}
]

이 절은 비규범적입니다.

다음은 [WEBRTC] 및 [Media-Capabilities]를 구현하는 브라우저가 반환한 encodingInfo(configuration)의 예제입니다.

예제 5

const contentType = 'video/VP9';

const configuration = {
  type: 'webrtc',
  video: {
    contentType,
    width: 640,
    height: 480,
    bitrate: 10000,
    framerate: 29.97,
    scalabilityMode: 'L3T3_KEY'
  }
};

try {
  const info = await navigator.mediaCapabilities.encodingInfo(configuration);

  if (!info.supported) {
    console.log(`${contentType} is unsupported.`);
    return;
  }
  console.log(`${contentType} is ${info.smooth || 'NOT '}smooth, and ` +
              `${info.powerEfficient || 'NOT '}power efficient`);
} catch (err) {
  console.error(err, ' caused encodingInfo to fail');
}

이 절은 비규범적입니다.

다음은 VP8, VP9 및 AV1 시간적 확장성 모드의 전달만 지원하는 SFM이 반환한 수신자 기능의 예제입니다.

예제 6

 "codecs": [
    {
      "clockRate": 90000,
      "mimeType": "video/VP8",
      "scalabilityModes": [
        "L1T1",
        "L1T2",
        "L1T3"
      ]
    },
    {
      "clockRate": 90000,
      "mimeType": "video/VP9",
      "scalabilityModes": [
        "L1T1",
        "L1T2",
        "L1T3"
      ]
    },
    {
      "clockRate": 90000,
      "mimeType": "video/AV1",
      "scalabilityModes": [
        "L1T1",
        "L1T2",
        "L1T3"
      ]
    }
]

WebRTC에서는 확장 가능 코딩 도구의 사용이 피어 간에 협상되지 않으므로, 지원되는 scalabilityMode 값도 공간적 예측에 대한 디코더 지원도 SDP에 노출되지 않습니다.

setParameters() API를 사용하여 각 코덱의 scalabilityMode 값을 설정하려고 시도함으로써, 애플리케이션은 어떤 구성 시도가 성공하고 어떤 것이 실패하는지 확인하여 인코더가 지원하는 값을 판별할 수 있습니다. 그러나 이것으로는 scalabilityMode 값이 하드웨어 또는 소프트웨어 인코더 (또는 둘 다)에서 지원되는지는 알 수 없습니다. setParameters()는 RTCRtpReceiver에서 지원되지 않으므로, 디코더 지원 여부를 판별하기 위한 동등한 실험은 수행할 수 없습니다.

소프트웨어 인코더가 지원하는 scalabilityMode 값은 일반적으로 하드웨어에서 지원되는 값의 상위 집합이므로, 이러한 실험에서 얻을 수 있는 정보는 사용 중인 브라우저와 높은 상관관계를 가지며, 브라우저 정보는 이미 웹 페이지에서 이용할 수 있습니다. 미디어가 전송되기 시작하면 성능 특성이나 scalabilityMode 값이 사용 중인 코덱에서 디코딩 가능한지에 관한 정보를 얻을 수 있으며, 이는 하드웨어 기능에 관한 더 많은 정보를 제공합니다.

[Media-Capabilities] 제3.1절에 언급된 바와 같이, Media Capabilities API는 이 명세에서 얻을 수 있는 것보다 "더 정확하고 일관된 정보를 제공할 가능성이 높습니다". 또한 [Media-Capabilities] 제3.1절에 언급된 바와 같이, "특정 종류의 기기는 매우 유사한 디코딩/인코딩 기능을 가질 것으로 예상되므로, 이 정보는 웹 페이지에서 이미 이용 가능한 다른 정보와 높은 상관관계를 가질 것으로 예상됩니다."