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

W3C 작업 초안

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2024/WD-webrtc-svc-20240817/
최신 발행 버전:
https://www.w3.org/TR/webrtc-svc/
최신 편집자 초안:
https://w3c.github.io/webrtc-svc/
이력:
https://www.w3.org/standards/history/webrtc-svc/
커밋 이력
편집자:
Bernard Aboba (Microsoft Corporation)
이전 편집자:
Peter Thatcher (Microsoft Corporation) - 까지
피드백:
GitHub w3c/webrtc-svc (pull request, 새 이슈, 열린 이슈)
public-webrtc@w3.org 로 제목 줄을 [webrtc-svc] … 메시지 주제 …로 하여 보내기 (아카이브)
참여
메일링 리스트
IETF AVTCORE 작업반

초록

이 문서는 WebRTC 명세를 확장하여 확장형 비디오 코딩(SVC)을 위한 인코딩 매개변수 구성을 가능하게 하는 WebIDL의 ECMAScript API 집합을 정의한다. SVC 인코더 및 디코더 기능의 발견은 Media Capabilities 명세에서 처리된다.

이 문서의 상태

이 절은 이 문서가 발행된 시점의 상태를 설명한다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정판은 https://www.w3.org/TR/의 W3C 기술 보고서 색인에서 찾을 수 있다.

이 API는 W3C ORTC Community Group에서 수행한 예비 작업을 기반으로 한다.

이 문서는 Web Real-Time Communications Working Group에 의해 Recommendation track을 사용하여 Working Draft로 발행되었다.

Working Draft로 발행되었다는 것이 W3C 및 그 회원들의 승인을 의미하지는 않는다.

이 문서는 초안 문서이며 언제든지 다른 문서로 갱신되거나 대체되거나 폐기될 수 있다. 이 문서를 진행 중인 작업이 아닌 것으로 인용하는 것은 부적절하다.

이 문서는 W3C Patent Policy에 따라 운영되는 그룹에 의해 작성되었다. W3C는 해당 그룹의 산출물과 관련하여 이루어진 모든 특허 공개의 공개 목록을 유지한다. 해당 페이지에는 특허를 공개하기 위한 지침도 포함되어 있다. 개인이 Essential Claim(s)을 포함한다고 믿는 특허에 대한 실제 지식을 가지고 있는 경우, 그 개인은 W3C Patent Policy의 6절에 따라 그 정보를 공개해야 한다.

이 문서는 2023년 11월 3일 W3C Process Document의 적용을 받는다.

1. 소개

이 절은 비규범적이다.

이 명세는 Scalable Video Coding (SVC)에 대한 인코딩 매개변수 구성을 가능하게 하기 위해 WebRTC 명세 [WEBRTC]를 확장한다. SVC 인코더 및 디코더 기능의 발견은 Media Capabilities API [Media-Capabilities]가 처리한다.

이 명세는 WebRTC 객체와 메서드의 동작을 변경하지 않는다. 따라서 Offer/Answer 협상 및 인코딩 매개변수와 관련된 제한은 [WEBRTC] 5.2절에 설명된 대로 유지된다: "setParameters()는 SDP 재협상을 일으키지 않으며 Offer/Answer로 협상된 범위 내에서 미디어 스택이 송신하거나 수신하는 내용을 변경하는 데에만 사용할 수 있다."

그 결과, 이 명세는 Offer/Answer에서 SVC 지원을 협상하지 않는 코덱에 대한 인코딩 매개변수를 구성할 수 있다. 예를 들면 VP8 [RFC6386], VP9 [VP9] 및 AV1 [AV1] 코덱이 있다. 시간 확장성 구성은 H.264 [ITU-T-REC-H.264] 및 H.265 [ITU-T-REC-H.265] 코덱에서도 지원될 수 있다.

2. 적합성

비규범적인 것으로 표시된 절과 마찬가지로, 이 명세의 모든 작성 지침, 다이어그램, 예제 및 참고는 비규범적이다. 이 명세의 그 밖의 모든 내용은 규범적이다.

이 문서에서 키워드 MAY, MUST, 및 SHOULD는 여기에 표시된 것처럼 모두 대문자로 나타날 때, 그리고 그 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 한다.

이 명세는 그 안에 포함된 인터페이스를 구현하는 사용자 에이전트라는 단일 제품에 적용되는 적합성 기준을 정의한다.

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

이 명세에서 정의된 API를 구현하기 위해 ECMAScript를 사용하는 구현은 Web IDL 명세 [WEBIDL]에 정의된 ECMAScript Bindings와 일관된 방식으로 이를 구현해야 MUST 하며, 이는 이 명세가 해당 명세와 용어를 사용하기 때문이다.

3. 용어

"simulcast envelope"이라는 용어는 [WEBRTC] 5.4.1절에 정의되어 있다.

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

Scalable Video Coding (SVC)의 경우, "single-session transmission" (SST) 및 "multi-session transmission" (MST)이라는 용어는 [RFC6190]에 정의되어 있다. 이 명세는 SST만 지원하고 MST는 지원하지 않는다.

[RFC7656] 3.7절에 정의된 "Single Real-time Transport Protocol stream Single Transport" (SRST)라는 용어는 단일 전송 내에서 모든 계층을 전송하며, 단일 Real-time Transport Protocol (RTP) 스트림 및 synchronization source (SSRC)를 사용하는 SVC 구현을 가리킨다. 역시 [RFC7656] 3.7절에 정의된 "Multiple RTP stream Single Transport" (MRST)라는 용어는 단일 전송 내에서 모든 계층을 전송하며, 각 계층마다 별도의 SSRC를 가진 여러 RTP 스트림을 사용하는 구현을 가리킨다. 이 명세는 SRST만 지원하고, MRST는 지원하지 않는다. SRST를 지원하는 RTP 페이로드 명세를 가진 코덱에는 VP8 [RFC7741], VP9 [VP9-PAYLOAD], AV1 [AV1-RTP-SPEC], H.264 [RFC6184] 및 H.265 [RFC7798]가 포함된다.

"S mode"라는 용어는 여러 인코딩이 동일한 SSRC에서 전송되는 확장성 모드를 가리킨다. 여기에는 "S2T1", "S2T1h", "S2T2", "S2T2h", "S2T3", "S2T3h", "S3T1", "S3T1h", "S3T2", "S3T2h", "S3T3""S3T3h" scalabilityMode 값이 포함된다.

Selective Forwarding Middlebox (SFM)라는 용어는 [RFC7667] 3.7절에 정의되어 있다.

4. 구성

이 명세는 RTCRtpEncodingParameters 딕셔너리를 확장함으로써 SVC를 위한 인코딩 매개변수의 구성을 가능하게 한다.

4.1 RTCRtpEncodingParameters 딕셔너리 확장

WebIDLpartial dictionary RTCRtpEncodingParameters {
             DOMString scalabilityMode;
};

딕셔너리 RTCRtpEncodingParameters 멤버

scalabilityMode, 타입은 DOMString

이 스트림에 사용할 확장성 모드의 대소문자 구분 식별자. 확장성 모드는 5절에 정의되어 있다.

4.2 동작

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

4.2.1 addTransceiver()

[WEBRTC] 5.1절은 sendEncodingsaddTransceiver() 내 유효성 검사를 설명한다. scalabilityMode의 유효성을 검사하기 위해, addTransceiver sendEncodings validation steps의 3단계 뒤에 다음 단계를 추가한다:

  1. sendEncodingsRTCRtpEncodingParameters.codeccodec존재하고, 같은 인코딩의 scalabilityMode 값이 codec에서 지원되지 않는 인코딩을 하나라도 포함하면, throw an OperationError.
  2. 아니면 sendEncodingsscalabilityMode 값이 kind에 대한 구현된 송신 코덱 목록의 어떤 코덱에서도 지원되지 않는 인코딩을 하나라도 포함하면, throw an OperationError.
  3. sendEncodings에 저장된 RTCRtpEncodingParameters가 값이 trueactive 멤버를 가진 인코딩을 1개보다 많이 포함하고, sendEncodingsscalabilityMode 값이 "S mode"를 나타내며 active 멤버의 값이 true인 인코딩을 하나라도 포함하면, throw an OperationError.

addTransceiver()setCodecPreferences() 메서드가 Offer/Answer 협상 완료 전에 호출되는 경우, 협상된 코덱과 그 기능은 알려지지 않았을 수 있다. 이 상황에서는 scalabilityMode sendEncodings에 구성된 값이 최종적으로 협상된 코덱에서 지원되지 않을 수 있다. 그러나 요청된 scalabilityMode 값이 지원되는 어떤 코덱에도 유효하지 않거나, 혼합 simulcast 전송이 요청된 경우에만 오류가 발생한다.

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

sendEncodings를 사용하여 addTransceiver()를 통해 여러 simulcast 스트림 전송을 요청하는 경우, "S mode"는 요청할 수 없다. 브라우저는 여러 SSRC 및 RID를 가진 simulcast 인코딩을 전송하도록 구성되거나, 또는 모든 simulcast 인코딩을 단일 RTP 스트림에서 전송하도록 구성될 수 있을 뿐이다. 두 simulcast 전송 기법을 동시에 사용하는 것은 허용되지 않는다.

4.2.2 setParameters()

[WEBRTC] 5.2절은 setParameters()parameters의 유효성 검사를 설명한다. setParameters validation stepsInvalidModificationError로 거부된 promise를 발생시키는 조건(4단계) 아래에 다음 조건을 삽입한다:

  1. encodings가 존재하는 RTCRtpEncodingParameters.codec 값 codec을 가진 인코딩을 하나라도 포함하고, 같은 인코딩의 scalabilityMode 값이 codec에서 지원되지 않는 경우.
  2. 아니면 sender.[[SendCodecs]]비어 있고, encodingsscalabilityMode 값이 kind에 대한 구현된 송신 코덱 목록의 어떤 코덱에서도 지원되지 않는 인코딩을 하나라도 포함하는 경우.
  3. 아니면 sender.[[SendCodecs]]비어 있지 않고, encodings가 해당 인코딩의 RTP 스트림에 사용되는 코덱에서 지원되지 않는 scalabilityMode 값을 가진 인코딩을 포함하는 경우.
  4. encodings에 저장된 RTCRtpEncodingParameters가 값이 trueactive 멤버를 가진 인코딩을 둘 이상 포함하고, encodingsscalabilityMode 값이 "S mode"를 나타내며 active 멤버의 값이 true인 인코딩을 하나라도 포함하는 경우.

"L1T1" 확장성 모드는 setParameters()를 사용하여 SVC 인코딩을 끌 수 있게 한다. "L1T1"setParameters()를 사용하여 설정되면, getParameters()에 대한 응답으로 반환된다.

4.2.3 getParameters()

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

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

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

4.2.4 협상 문제

이 절은 비규범적이다.

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

[Media-Capabilities] API는 확장형 비디오 코딩에 대한 인코더 및 디코더 지원의 발견을 가능하게 한다. scalabilityMode는 인코더가 특정 scalabilityMode 값을 지원하는지 질의하는 데 사용되며, 그것이 "supported", "smooth" 및 "power efficient"인지 나타낸다.

[Media-Capabilities] API는 공간 확장성 모드에 대한 디코더 지원 정보도 제공한다. spatialScalability는 디코더가 공간 예측을 지원할 능력이 있는지 나타내며, 이는 현재 해상도와 다른 해상도의 프레임을 의존성으로 사용할 수 있는 능력을 필요로 한다. spatialScalabilitytrue로 설정되면, 디코더는 인코더가 지원하는 모든 scalabilityMode 값을 디코드할 수 있다. spatialScalabilityfalse로 설정되거나 없으면, 디코더는 공간 확장성 모드를 디코드할 수 없지만, 인코더가 지원하는 다른 모든 scalabilityMode 값은 디코드할 수 있다.

애플리케이션이 사용할 수 있는 코덱과 scalabilityMode 값의 조합을 결정한 후에는, 이러한 조합 중 어떤 것이 SFM에서 지원되는지 판단해야 한다. 이를 처리하는 한 가지 방법은 SFM이 전달할 수 있는 코덱과 확장성 모드의 조합을 수신자 기능의 형태로 나타내는 것이다. SFM의 기능을 받은 후, 애플리케이션은 브라우저의 RTCRtpSenderSFM의 수신자가 지원하는 코덱 및 scalabilityMode 값의 교집합을 계산할 수 있다. 이는 브라우저의 addTransceiver()setParameters() 메서드에 전달되는 인수를 결정하는 데 사용할 수 있다.

몇 가지 예는 다음과 같다:

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

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

5. 확장성 모드

이 명세에서 지원되는 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에서 simulcast를 전송하는 것만 허용하므로, "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

5.1 scalabilityMode 값 추가 지침

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

  1. 제안된 scalabilityMode는 Scalabilty Mode Identifier, 공간 및 시간 계층, Resolution Ratio, Inter-layer dependency 및 대응하는 AV1 scalability_mode_idc 값(할당된 경우)의 값을 포함하여 5절의 표에 대한 항목을 정의해야 MUST 한다.
  2. Scalability Mode Identifier는 기존 명명 체계와 일관되어야 SHOULD 하며, 이 체계는 LxTy를 사용하여 2:1 해상도 비율을 사용하는 x개의 공간 계층과 y개의 시간 계층을 가진 scalabilityMode를 나타낸다. LxTyh는 1.5:1 해상도 비율과 y개의 시간 계층을 가진 x개의 공간 계층을 나타낸다. SxTy는 2:1 해상도 비율의 x개 simulcast 인코딩을 가진 scalabilityMode를 나타내며, 각 simulcast 인코딩은 y개의 시간 계층을 포함한다. SxTyh는 1.5:1 해상도 비율을 나타낸다. LxTy_KEY는 2:1 해상도 비율을 사용하는 x개의 공간 계층과 y개의 시간 계층을 가진 scalabilityMode를 나타내며, 여기서 공간 계층은 키 프레임에서만 더 낮은 공간 계층에 의존한다. LxTy_KEY_SHIFT 모드는 2:1 해상도 비율을 사용하는 x개의 공간 계층과 y개의 시간 계층을 가진 scalabilityMode를 나타내며, 여기서 공간 계층은 키 프레임에서만 더 낮은 공간 계층에 의존하고 이후 프레임은 시간 식별자가 위로 이동된다.
  3. 의존성 다이어그램은 9절에 제공된 형식으로 제공되어야 MUST 한다.

6. 예제

6.1 공간 Simulcast와 시간 확장성

이 절은 비규범적이다.

이 예제는 [WEBRTC] 7.1절(예제 1)을 확장하여 각 simulcast 계층마다 SSRC 및 RID를 사용하면서, 세 개의 시간 계층을 가진 세 개의 공간 simulcast 계층을 전송하는 것을 보여준다. 원래 예제에서 "sendEncodings" 속성만 변경된다.

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

// call start() to initiate
async function start() {
  pc = new RTCPeerConnection(configuration);

  // let the "negotiationneeded" event trigger offer generation
  pc.onnegotiationneeded = async () => {
    try {
      await pc.setLocalDescription();
      // send the offer to the other peer
      signaling.send({description: pc.localDescription});
    } catch (err) {
      console.error(err);
    }
  };

  try {
    // get a local stream, show it in a self-view and add it to be sent
    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);
      // if we got an offer, we need to reply with an 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:1 비율)과 세 개의 시간 계층을 가진 예제이다.

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

이것은 각 simulcast 계층이 3개의 시간 계층을 가지는 혼합 코덱 simulcast의 예제이다.

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에서 세 개의 시간 계층을 각각 가진 세 개의 공간 simulcast 계층 예제이다.

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

6.2 SVC 인코더 기능

이 절은 비규범적이다.

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

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');
}

6.3 SFM 기능

이 절은 비규범적이다.

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

 "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"
      ]
    }
]

7. 개인정보 보호 고려사항

이 절은 비규범적이다.

이 절은 비규범적이며, 새로운 동작을 명세하지 않고 대신 명세의 다른 부분에 이미 존재하는 정보를 요약한다. WebRTC API에 대한 개인정보 보호 고려사항은 [WEBRTC] 13절에 설명되어 있다.

7.1 지속적 정보

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

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

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

[Media-Capabilities] 3.1절에서 언급한 것처럼, Media Capabilities API는 이 명세에서 이용 가능한 것보다 "더 정확하고 일관된 정보를 제공할 가능성이 높다". 또한 [Media-Capabilities] 3.1절에서 언급한 것처럼, "이 정보는 이미 웹 페이지에서 이용 가능한 다른 정보와 높은 상관관계를 가질 것으로 예상된다. 주어진 장치 계층은 매우 유사한 디코딩/인코딩 기능을 가질 것으로 예상되기 때문이다."

8. 보안 고려사항

이 절은 비규범적이다.

이 절은 비규범적이며, 새로운 동작을 명세하지 않고 대신 명세의 다른 부분에 이미 존재하는 정보를 요약한다. WebRTC 프로토콜 보안 고려사항은 [RFC8827]에 설명되어 있으며, WebRTC API에 대한 보안 및 개인정보 보호 고려사항은 [WEBRTC] 13절에 설명되어 있다.

9. 확장성 모드 의존성 다이어그램

이 명세에서 정의된 확장성 모드에 대한 의존성 다이어그램은 아래에 제공되어 있다.

9.1 L1T1

L1T1: 단일 계층
그림 1 L1T1: 1계층 인코딩

9.2 L1T2

L1T2: 2계층 시간 확장성 인코딩
그림 2 L1T2: 1계층 공간 및 2계층 시간 확장성 인코딩

9.3 L1T3

L1T3: 3계층 시간 확장성 인코딩
그림 3 L1T3: 1계층 공간 및 3계층 시간 확장성 인코딩

9.4 L2T1 및 L2T1h

L2T1 및 L2T1h: 2계층 공간 및 1계층 시간 확장성 인코딩
그림 4 L2T1 및 L2T1h: 2계층 공간 및 1계층 시간 확장성 인코딩

9.5 L2T1_KEY

L2T1_KEY: 2계층 공간 및 1계층 시간 확장성 K-SVC 인코딩
그림 5 L2T1_KEY: 2계층 공간 및 1계층 시간 확장성 K-SVC 인코딩

9.6 L2T2 및 L2T2h

L2T2 및 L2T2h: 2계층 공간 및 2계층 시간 확장성 인코딩
그림 6 L2T2 및 L2T2h: 2계층 공간 및 2계층 시간 확장성 인코딩

9.7 L2T2_KEY

L2T2_KEY: 2계층 공간 및 2계층 시간 확장성 K-SVC 인코딩
그림 7 L2T2_KEY: 2계층 공간 및 2계층 시간 확장성 K-SVC 인코딩

9.8 L2T2_KEY_SHIFT

L2T2_KEY_SHIFT: 시간 이동이 있는 2계층 공간 및 2계층 시간 확장성 K-SVC shifted 인코딩
그림 8 L2T2_KEY_SHIFT: 시간 이동이 있는 2계층 공간 및 2계층 시간 확장성 K-SVC 인코딩

9.9 L2T3 및 L2T3h

L2T3 및 L2T3h: 2계층 공간 및 3계층 시간 확장성 인코딩
그림 9 L2T3 및 L2T3h: 2계층 공간 및 3계층 시간 확장성 인코딩

9.10 L2T3_KEY

L2T3_KEY: 2계층 공간 및 3계층 시간 확장성 K-SVC 인코딩
그림 10 L2T3_KEY: 2계층 공간 및 3계층 시간 확장성 K-SVC 인코딩

9.11 L2T3_KEY_SHIFT

L2T3_KEY_SHIFT: 시간 이동이 있는 2계층 공간 및 3계층 시간 확장성 K-SVC shifted 인코딩
그림 11 L2T3_KEY_SHIFT: 시간 이동이 있는 2계층 공간 및 3계층 시간 확장성 K-SVC 인코딩

9.12 L3T1 및 L3T1h

L3T1 및 L3T1h: 3계층 공간 및 1계층 시간 확장성 인코딩
그림 12 L3T1 및 L3T1h: 3계층 공간 및 1계층 시간 확장성 인코딩

9.13 L3T1_KEY

L3T1_KEY: 3계층 공간 및 1계층 시간 확장성 K-SVC 인코딩
그림 13 L3T1_KEY: 3계층 공간 및 1계층 시간 확장성 K-SVC 인코딩

9.14 L3T2 및 L3T2h

L3T2 및 L3T2h: 3계층 공간 및 2계층 시간 확장성 인코딩
그림 14 L3T2 및 L3T2h: 3계층 공간 및 2계층 시간 확장성 인코딩

9.15 L3T2_KEY

L3T2_KEY: 3계층 공간 및 2계층 시간 확장성 K-SVC 인코딩
그림 15 L3T2_KEY: 3계층 공간 및 2계층 시간 확장성 K-SVC 인코딩

9.16 L3T2_KEY_SHIFT

L3T2_KEY_SHIFT: 시간 이동이 있는 3계층 공간 및 2계층 시간 확장성 K-SVC
그림 16 L3T2_KEY_SHIFT: 시간 이동이 있는 3계층 공간 및 2계층 시간 확장성 K-SVC

9.17 L3T3 및 L3T3h

L3T3 및 L3T3h: 3계층 공간 및 3계층 시간 확장성 인코딩
그림 17 L3T3 및 L3T3h: 3계층 공간 및 3계층 시간 확장성 인코딩

9.18 L3T3_KEY

L3T3_KEY: 3계층 공간 및 3계층 시간 확장성 K-SVC 인코딩
그림 18 L3T3_KEY: 3계층 공간 및 3계층 시간 확장성 K-SVC 인코딩

9.19 L3T3_KEY_SHIFT

L3T3_KEY_SHIFT: 시간 이동이 있는 3계층 공간 및 3계층 시간 확장성 K-SVC
그림 19 L3T3_KEY_SHIFT: 시간 이동이 있는 3계층 공간 및 3계층 시간 확장성 K-SVC

9.20 S2T1 및 S2T1h

S2T1 및 S2T1h: 2계층 공간 simulcast 인코딩
그림 20 S2T1 및 S2T1h: 2계층 공간 simulcast 인코딩

9.21 S2T2 및 S2T2h

S2T2 및 S2T2h: 2계층 공간 simulcast 및 2계층 시간 확장성 인코딩
그림 21 S2T2 및 S2T2h: 2계층 공간 simulcast 및 2계층 시간 확장성 인코딩

9.22 S2T3 및 S2T3h

S2T3 및 S2T3h: 2계층 공간 simulcast 및 3계층 시간 확장성 인코딩
그림 22 S2T3 및 S2T3h: 2계층 공간 simulcast 및 3계층 시간 확장성 인코딩

9.23 S3T1 및 S3T1h

S3T1 및 S3T1h: 3계층 공간 simulcast 인코딩
그림 23 S3T1 및 S3T1h: 3계층 공간 simulcast 인코딩

9.24 S3T2 및 S3T2h

S3T2 및 S3T2h: 3계층 공간 simulcast 및 2계층 시간 확장성 인코딩
그림 24 S3T2 및 S3T2h: 3계층 공간 simulcast 및 2계층 시간 확장성 인코딩

9.25 S3T3 및 S3T3h

S3T3 및 S3T3h: 3계층 공간 simulcast 및 3계층 시간 확장성 인코딩
그림 25 S3T3 및 S3T3h: 3계층 공간 simulcast 및 3계층 시간 확장성 인코딩

A. 감사의 말

편집자들은 이 명세에 기여한 Robin Raymond, Michael Horowitz, Harald Alvestrand, Chris Cunningham, Danil Chapovalov, Florent Castelli, Erik Språng 및 Henrik Boström에게 감사의 뜻을 전한다. 이 명세는 W3C ORTC CG에서 개발된 ORTC API로부터 발전한 것이다.

B. 참고문헌

B.1 규범 참고문헌

[infra]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC7656]
A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources. J. Lennox; K. Gross; S. Nandakumar; G. Salgueiro; B. Burman, Ed.. IETF. November 2015. Informational. URL: https://www.rfc-editor.org/rfc/rfc7656
[RFC7667]
RTP Topologies. M. Westerlund; S. Wenger. IETF. November 2015. RFC. URL: https://datatracker.ietf.org/doc/html/rfc7667
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[WEBIDL]
Web IDL Standard. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/
[WEBRTC]
WebRTC: Real-Time Communication in Browsers. Cullen Jennings; Florent Castelli; Henrik Boström; Jan-Ivar Bruaroey. W3C. 6 March 2023. W3C Recommendation. URL: https://www.w3.org/TR/webrtc/

B.2 정보 참고문헌

[AV1]
AV1 Bitstream & Decoding Process Specification. Peter de Rivaz; Jack Haughton. AOM. 8 January 2019. Standard. URL: https://aomediacodec.github.io/av1-spec/av1-spec.pdf
[AV1-RTP-SPEC]
RTP Payload Format For AV1 (v1.0). Alliance for Open Media. Draft Deliverable. URL: https://aomediacodec.github.io/av1-rtp-spec/
[ITU-T-REC-H.264]
H.264 : Advanced video coding for generic audiovisual services. ITU. June 2019. URL: https://www.itu.int/rec/T-REC-H.264
[ITU-T-REC-H.265]
H.265 : High efficiency video coding. ITU. August 2021. URL: https://www.itu.int/rec/T-REC-H.265
[Media-Capabilities]
Media Capabilities. Jean-Yves Avenard. W3C. 8 August 2024. W3C Working Draft. URL: https://www.w3.org/TR/media-capabilities/
[RFC6184]
RTP Payload Format for H.264 Video. Y.-K. Wang; R. Even; T. Kristensen; R. Jesup. IETF. May 2011. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6184
[RFC6190]
RTP Payload Format for Scalable Video Coding. S. Wenger; Y.-K. Wang; T. Schierl; A. Eleftheriadis. IETF. May 2011. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6190
[RFC6386]
VP8 Data Format and Decoding Guide. J. Bankoski; J. Koleszar; L. Quillio; J. Salonen; P. Wilkins; Y. Xu. IETF. November 2011. Informational. URL: https://www.rfc-editor.org/rfc/rfc6386
[RFC7741]
RTP Payload Format for VP8 Video. P. Westin; H. Lundin; M. Glover; J. Uberti; F. Galligan. IETF. March 2016. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7741
[RFC7798]
RTP Payload Format for High Efficiency Video Coding (HEVC). Y.-K. Wang; Y. Sanchez; T. Schierl; S. Wenger; M. M. Hannuksela. IETF. March 2016. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7798
[RFC8827]
WebRTC Security Architecture. E. Rescorla. IETF. January 2021. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8827
[VP9]
VP9 Bitstream & Decoding Process Specification. A. Grange; P. de Rivaz; J. Hunt. Google. February 2016. Version 0.6. URL: https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf
[VP9-PAYLOAD]
RTP Payload Format for VP9 Video. J. Uberti; S. Holmer; M. Flodman; J. Lennox; D. Hong. IETF. 10 June 2021. Internet Draft (work in progress). URL: https://datatracker.ietf.org/doc/html/draft-ietf-payload-vp9