Copyright © 2024 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
이 문서는 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의 적용을 받는다.
이 절은 비규범적이다.
이 명세는 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] 코덱에서도 지원될 수 있다.
비규범적인 것으로 표시된 절과 마찬가지로, 이 명세의 모든 작성 지침, 다이어그램, 예제 및 참고는 비규범적이다. 이 명세의 그 밖의 모든 내용은 규범적이다.
이 문서에서 키워드 MAY, MUST, 및 SHOULD는 여기에 표시된 것처럼 모두 대문자로 나타날 때, 그리고 그 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 한다.
이 명세는 그 안에 포함된 인터페이스를 구현하는 사용자 에이전트라는 단일 제품에 적용되는 적합성 기준을 정의한다.
알고리즘이나 특정 단계로 표현된 적합성 요구사항은 최종 결과가 동등한 한 어떤 방식으로든 구현될 수 있다. 특히 이 명세에서 정의된 알고리즘은 따라가기 쉽도록 의도된 것이며, 성능이 좋도록 의도된 것은 아니다.
이 명세에서 정의된 API를 구현하기 위해 ECMAScript를 사용하는 구현은 Web IDL 명세 [WEBIDL]에 정의된 ECMAScript Bindings와 일관된 방식으로 이를 구현해야 MUST 하며, 이는 이 명세가 해당 명세와 용어를 사용하기 때문이다.
"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절에 정의되어 있다.
이 명세는 RTCRtpEncodingParameters
딕셔너리를 확장함으로써 SVC를 위한 인코딩 매개변수의 구성을 가능하게 한다.
RTCRtpEncodingParameters
딕셔너리 확장WebIDLpartial dictionary RTCRtpEncodingParameters {
DOMString scalabilityMode;
};
RTCRtpEncodingParameters
멤버scalabilityMode, 타입은 DOMString이 스트림에 사용할 확장성 모드의 대소문자 구분 식별자. 확장성 모드는 5절에 정의되어 있다.
[WEBRTC]는
addTransceiver()
(5.1절) 및 setParameters()
(5.2절)에서의 오류 처리를 설명하며,
여기에는 지원되지 않는 인코딩 매개변수로 인한
"hardware-encoder-error"를
나타내기 위한 RTCError의 사용 및 기타 오류가 포함된다.
구현은 유효하지 않은
scalabilityMode 값이
setParameters()
또는 addTransceiver()에
제공될 때 정해진 방식으로 RTCError 및 기타 오류를 사용한다.
addTransceiver()
[WEBRTC] 5.1절은
sendEncodings의
addTransceiver()
내 유효성 검사를 설명한다.
scalabilityMode의
유효성을 검사하기 위해,
addTransceiver
sendEncodings validation steps의 3단계 뒤에
다음 단계를 추가한다:
RTCRtpEncodingParameters.codec
값 codec이 존재하고, 같은 인코딩의 scalabilityMode
값이 codec에서 지원되지 않는 인코딩을 하나라도 포함하면, throw an OperationError.
scalabilityMode
값이 kind에 대한 구현된 송신 코덱 목록의
어떤 코덱에서도 지원되지 않는 인코딩을 하나라도 포함하면,
throw an OperationError.
RTCRtpEncodingParameters가
값이 true인 active
멤버를 가진 인코딩을 1개보다 많이 포함하고,
sendEncodings가
scalabilityMode
값이 "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 전송 기법을 동시에 사용하는 것은
허용되지 않는다.
setParameters()
[WEBRTC] 5.2절은
setParameters()
내 parameters의 유효성 검사를 설명한다.
setParameters validation
steps의
InvalidModificationError로
거부된 promise를 발생시키는 조건(4단계) 아래에
다음 조건을 삽입한다:
RTCRtpEncodingParameters.codec
값 codec을 가진 인코딩을 하나라도 포함하고, 같은 인코딩의
scalabilityMode
값이 codec에서 지원되지 않는 경우.
[[SendCodecs]]가 비어 있고,
encodings가
scalabilityMode
값이 kind에 대한
구현된 송신 코덱 목록의
어떤 코덱에서도 지원되지 않는 인코딩을 하나라도 포함하는 경우.
[[SendCodecs]]가 비어 있지 않고,
encodings가 해당 인코딩의 RTP 스트림에 사용되는 코덱에서
지원되지 않는
scalabilityMode
값을 가진 인코딩을 포함하는 경우.
RTCRtpEncodingParameters가
값이 true인 active
멤버를 가진 인코딩을 둘 이상 포함하고,
encodings가
scalabilityMode
값이 "S mode"를 나타내며
active
멤버의 값이 true인 인코딩을 하나라도 포함하는 경우.
"L1T1" 확장성 모드는
setParameters()를
사용하여 SVC 인코딩을 끌 수 있게 한다.
"L1T1"이
setParameters()를
사용하여 설정되면,
getParameters()에
대한 응답으로 반환된다.
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 한다.
이 절은 비규범적이다.
SVC는 화상 회의에서 가장 자주 사용되며, 여기서 SFM과 같은 회의 서버는 참가자의 장치 특성과 사용 가능한 대역폭에 따라 계층을 선택적으로 전달한다. 이러한 환경에서 애플리케이션은 회의 서버와 송수신할 코덱을 협상한다. 그러나 확장성 모드는 Offer/Answer에서 협상되지 않으므로, 애플리케이션은 브라우저와 회의 서버가 어떤 확장성 모드를 지원하는지를 다른 수단으로 판단해야 한다.
[Media-Capabilities] API는 확장형 비디오 코딩에 대한
인코더 및 디코더 지원의 발견을 가능하게 한다.
scalabilityMode는
인코더가 특정
scalabilityMode
값을 지원하는지 질의하는 데 사용되며, 그것이 "supported", "smooth" 및 "power efficient"인지
나타낸다.
[Media-Capabilities] API는 공간 확장성 모드에 대한
디코더 지원 정보도 제공한다.
spatialScalability는
디코더가 공간 예측을 지원할 능력이 있는지 나타내며,
이는 현재 해상도와 다른 해상도의 프레임을 의존성으로 사용할 수 있는 능력을
필요로 한다. spatialScalability가
true로 설정되면, 디코더는 인코더가 지원하는 모든
scalabilityMode
값을 디코드할 수 있다.
spatialScalability가
false로 설정되거나 없으면,
디코더는 공간 확장성 모드를 디코드할 수 없지만, 인코더가 지원하는 다른 모든
scalabilityMode
값은 디코드할 수 있다.
애플리케이션이 사용할 수 있는 코덱과
scalabilityMode
값의 조합을 결정한 후에는,
이러한 조합 중 어떤 것이 SFM에서 지원되는지 판단해야 한다.
이를 처리하는 한 가지 방법은 SFM이 전달할 수 있는 코덱과
확장성 모드의 조합을 수신자 기능의 형태로 나타내는 것이다.
SFM의 기능을 받은 후, 애플리케이션은 브라우저의
RTCRtpSender와
SFM의 수신자가 지원하는 코덱 및
scalabilityMode
값의 교집합을 계산할 수 있다. 이는 브라우저의
addTransceiver()
및 setParameters()
메서드에 전달되는 인수를 결정하는 데 사용할 수 있다.
몇 가지 예는 다음과 같다:
브라우저와 SFM 기능의 교집합을 계산할 때 RTP 헤더 확장을 고려해야 하는
상황이 있다.
SFM이 코덱 페이로드를 파싱할 수 없다면
(그렇게 설계되지 않았거나 페이로드가 암호화되어 있기 때문에),
[AV1-RTP-SPEC]의 부록 A에 정의된
AV1 Dependency Descriptor와 같은 RTP 헤더 확장의 협상이
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에서 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 |
scalabilityMode
값 추가 지침scalabilityMode 값을 제안할
때는
다음 원칙을 따라야 한다:
scalabilityMode는
Scalabilty Mode Identifier, 공간 및 시간 계층, Resolution Ratio, Inter-layer dependency 및 대응하는
AV1 scalability_mode_idc 값(할당된 경우)의 값을 포함하여
5절의 표에 대한 항목을 정의해야 MUST 한다.
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를
나타내며,
여기서 공간 계층은 키 프레임에서만 더 낮은 공간 계층에 의존하고 이후
프레임은 시간 식별자가 위로 이동된다.
이 절은 비규범적이다.
이 예제는 [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'}
]
이 절은 비규범적이다.
이것은 [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');
}
이 절은 비규범적이다.
이것은 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"
]
}
]
이 절은 비규범적이다.
이 절은 비규범적이며, 새로운 동작을 명세하지 않고 대신 명세의 다른 부분에 이미 존재하는 정보를 요약한다. WebRTC API에 대한 개인정보 보호 고려사항은 [WEBRTC] 13절에 설명되어 있다.
WebRTC에서 확장형 코딩 도구의 사용은 피어 간에
협상되지 않으므로, 지원되는
scalabilityMode 값도
공간 예측에 대한 디코더 지원도 SDP에 노출되지 않는다.
setParameters()
API를 사용하여 각 코덱에 대해
scalabilityMode 값을
설정하려고 시도함으로써,
애플리케이션은 어떤 구성 시도가 성공하고 어떤 시도가 실패하는지를 확인하여
인코더가 지원하는 값을 결정할 수 있다. 그러나 이것은
scalabilityMode
값이 하드웨어 인코더 또는 소프트웨어 인코더
(또는 둘 다)에서 지원되는지 여부를 나타내지 않는다. setParameters()는
RTCRtpReceiver에 대해 지원되지
않으므로,
디코더 지원을 결정하기 위한 동등한 실험은 실행할 수 없다.
소프트웨어 인코더가 지원하는
scalabilityMode
값은 일반적으로 하드웨어에서 지원되는 값의 상위 집합이므로,
이러한 실험에서 이용 가능한 정보는 사용 중인 브라우저와 높은 상관관계를 가지며,
이는 이미 웹 페이지에서 이용 가능하다. 미디어가 흐르기 시작하면,
성능 특성이나 사용 중인 코덱에 대해
scalabilityMode 값을
디코드할 수 있는지 여부에 대한 정보를 얻을 수 있으며,
이는 하드웨어 기능에 대한 더 많은 정보를 제공한다.
[Media-Capabilities] 3.1절에서 언급한 것처럼, Media Capabilities API는 이 명세에서 이용 가능한 것보다 "더 정확하고 일관된 정보를 제공할 가능성이 높다". 또한 [Media-Capabilities] 3.1절에서 언급한 것처럼, "이 정보는 이미 웹 페이지에서 이용 가능한 다른 정보와 높은 상관관계를 가질 것으로 예상된다. 주어진 장치 계층은 매우 유사한 디코딩/인코딩 기능을 가질 것으로 예상되기 때문이다."
이 절은 비규범적이다.
이 절은 비규범적이며, 새로운 동작을 명세하지 않고 대신 명세의 다른 부분에 이미 존재하는 정보를 요약한다. WebRTC 프로토콜 보안 고려사항은 [RFC8827]에 설명되어 있으며, WebRTC API에 대한 보안 및 개인정보 보호 고려사항은 [WEBRTC] 13절에 설명되어 있다.
이 명세에서 정의된 확장성 모드에 대한 의존성 다이어그램은 아래에 제공되어 있다.
편집자들은 이 명세에 기여한 Robin Raymond, Michael Horowitz, Harald Alvestrand, Chris Cunningham, Danil Chapovalov, Florent Castelli, Erik Språng 및 Henrik Boström에게 감사의 뜻을 전한다. 이 명세는 W3C ORTC CG에서 개발된 ORTC API로부터 발전한 것이다.
Referenced in:
Referenced in: