-
trackIdentifier 유형은 DOMString
-
MediaStreamTrack의
id 속성 값.
-
mid 유형은
DOMString
-
이 스트림을 소유한 RTCRtpTransceiver가
null이 아닌
mid
값을 가지면,
이는 그 값이며, 그렇지 않으면 이 멤버는 MUST NOT
존재해야 한다.
-
remoteId
유형은
DOMString
-
remoteId는
같은 SSRC에 대한 원격
RTCRemoteOutboundRtpStreamStats
객체를 찾는 데 사용된다.
-
framesDecoded
-
audio에 대해서는 MUST NOT
존재해야 한다. 이는
이 RTP stream에 대해 올바르게 디코딩된 프레임의 총수를 나타낸다.
즉, 프레임이 드롭되지 않았다면 표시되었을 프레임이다.
-
keyFramesDecoded 유형은 unsigned long
-
audio에 대해서는 MUST NOT
존재해야 한다. 이는
VP8
[RFC6386]의 키 프레임이나
H.264 [RFC6184]의 IDR 프레임과 같은
키 프레임 중 이 RTP 미디어 스트림에 대해 성공적으로
디코딩된 총수를 나타낸다. 이는
framesDecoded의
하위 집합이다.
framesDecoded - keyFramesDecoded는
디코딩된 델타 프레임 수를 제공한다.
-
framesRendered
-
audio에 대해서는 MUST NOT
존재해야 한다. 이는
렌더링된 프레임의 총수를 나타낸다.
프레임이 렌더링된 직후 증가한다.
-
framesDropped 유형은 unsigned
long
-
audio에 대해서는 MUST NOT
존재해야 한다. 이
receiver의 트랙에 대해
디코딩 전에 드롭되었거나 프레임이 표시 기한을 놓쳐 드롭된 프레임의 총수이다.
측정은 receiver가 생성될 때 시작되며 [RFC7004]의
부록 A (g)에 정의된 누적 메트릭이다.
-
frameWidth 유형은 unsigned
long
-
audio에 대해서는 MUST NOT
존재해야 한다.
마지막으로
디코딩된 프레임의 너비를 나타낸다. 첫 번째 프레임이 디코딩되기 전에는
이 멤버가 MUST NOT 존재해야 한다.
-
frameHeight 유형은 unsigned
long
-
audio에 대해서는 MUST NOT
존재해야 한다.
마지막으로
디코딩된 프레임의 높이를 나타낸다. 첫 번째
프레임이 디코딩되기 전에는 이 멤버가 MUST NOT 존재해야 한다.
-
framesPerSecond 유형은 double
-
audio에 대해서는 MUST NOT
존재해야 한다. 지난
1초 동안
디코딩된 프레임 수이다.
-
qpSum 유형은 unsigned
long
long
-
audio에 대해서는 MUST NOT
존재해야 한다. 이
receiver가 디코딩한 프레임의 QP 값의 합이다.
프레임 수는 framesDecoded에
있다.
QP 값의 정의는 codec에 따라 달라진다. VP8의 경우 QP 값은
프레임 헤더에 구문 요소 y_ac_qi로 실린 값이며,
[RFC6386] 19.2절에
정의되어 있다. 범위는 0..127이다.
QP 값은 사용된 quantizer 값을 나타내는 지표일 뿐임에 유의하라. 많은
형식은 프레임 내에서 quantizer 값을 달리할 수 있는 방법을 가진다.
-
totalDecodeTime 유형은 double
-
audio에 대해서는 MUST NOT
존재해야 한다.
이 스트림의 framesDecoded
프레임을 디코딩하는 데 사용된 총 초 수이다. 평균 디코딩 시간은 이
값을 framesDecoded로
나누어 계산할 수 있다. 하나의 프레임을 디코딩하는 데 걸리는 시간은
디코더에 프레임을 공급한 시점부터 디코더가 그 프레임에 대한 디코딩된
데이터를 반환할 때까지 지난 시간이다.
-
totalInterFrameDelay 유형은 double
-
audio에 대해서는 MUST NOT
존재해야 한다.
연속적으로 렌더링된 프레임 사이의 interframe delay를 초 단위로 합산한 값이며,
프레임이 렌더링된 직후 기록된다. interframe delay 분산은
totalInterFrameDelay,
totalSquaredInterFrameDelay,
그리고 framesRendered로부터
다음 공식에 따라 계산할 수 있다.
(totalSquaredInterFrameDelay
- totalInterFrameDelay^2/
framesRendered)/framesRendered.
-
totalSquaredInterFrameDelay 유형은 double
-
audio에 대해서는 MUST NOT
존재해야 한다.
연속적으로 렌더링된 프레임 사이의 interframe delay 제곱을 초 단위로 합산한 값이며,
프레임이 렌더링된 직후 기록된다. interframe delay 분산을 계산하는 방법에 대한
자세한 내용은 totalInterFrameDelay를
참조하라.
-
pauseCount 유형은
unsigned long
-
audio에 대해서는 MUST NOT
존재해야 한다.
이 receiver가 겪은 video pause의 총수를 센다.
마지막으로 렌더링된 프레임 이후 지난 시간이 5초를 초과하면 video가
일시 중지된 것으로 간주한다. pauseCount는
그러한 일시 중지 후 프레임이 렌더링될 때 증가한다.
-
totalPausesDuration 유형은
double
-
audio에 대해서는 MUST NOT
존재해야 한다.
pause의 총 지속 시간(pauseCount의
pause 정의 참조)이며 초 단위이다. 이 값은 프레임이 렌더링될 때 업데이트된다.
-
freezeCount 유형은
unsigned long
-
audio에 대해서는 MUST NOT
존재해야 한다.
이 receiver가 겪은 video freeze의 총수를 센다.
frame duration, 즉 연속으로 렌더링된 두 프레임 사이의 시간 간격이
Max(3 * avg_frame_duration_ms, avg_frame_duration_ms + 150) 이상이면
freeze이다. 여기서 avg_frame_duration_ms는 마지막 30개의 렌더링된
프레임 지속 시간의 선형 평균이다.
-
totalFreezesDuration 유형은
double
-
audio에 대해서는 MUST NOT
존재해야 한다.
frozen으로 간주되는 렌더링된 프레임의 총 지속 시간(freezeCount의
freeze 정의 참조)이며 초 단위이다. 이 값은
프레임이 렌더링될 때 업데이트된다.
-
lastPacketReceivedTimestamp 유형은 DOMHighResTimeStamp
-
이 SSRC에 대해 마지막 패킷이 수신된 시점의 타임스탬프를 나타낸다.
이는 로컬 엔드포인트에서 통계가 생성된 시간을 나타내는
timestamp와 다르다.
-
유형은 unsigned long long
-
이 SSRC에 대해 수신된
RTP 헤더 및 padding 바이트의 총수.
여기에는 재전송이 포함된다.
IP 또는 UDP와 같은 transport layer 헤더의 크기는 포함하지 않는다.
headerBytesReceived + bytesReceived는 transport를 통해 payload로
수신된 바이트 수와 같다.
-
packetsDiscarded 유형은 unsigned long long
-
지연 도착 또는 조기 도착으로 인해 jitter buffer에서 폐기된 RTP 패킷의 누적 수,
즉 이러한 패킷은 재생되지 않는다. 패킷 중복으로 인해 폐기된 RTP 패킷은
이 메트릭에 보고되지 않는다 [XRBLOCK-STATS].
[RFC7002]
3.2절 및 부록 A.a에 정의된 대로 계산된다.
-
fecBytesReceived 유형은 unsigned long long
-
이 SSRC에 대해 수신된 RTP FEC 바이트의 총수이며,
payload 바이트만 포함한다.
이는 bytesReceived의
하위 집합이다.
다른 ssrc를
사용하는 FEC 메커니즘이 협상된 경우, FEC 패킷은 별도의 SSRC를 통해
전송되지만 여기에 여전히 계산된다.
-
fecPacketsReceived 유형은 unsigned long long
-
이 SSRC에 대해
수신된 RTP FEC 패킷의 총수. 다른 ssrc를
사용하는 FEC 메커니즘이 협상된 경우, FEC 패킷은 별도의 SSRC를 통해
전송되지만 여기에 여전히 계산된다.
이 카운터는 media 패킷과 in-band로 FEC 패킷을 수신할 때도
증가할 수 있다(예: Opus).
-
fecPacketsDiscarded 유형은 unsigned long long
-
이 SSRC에 대해
수신된 RTP FEC 패킷 중 error correction
payload가 애플리케이션에 의해 폐기된 총수. 이는 1. FEC 패킷이 보호하는 모든 source
packet이 수신되었거나 별도의 FEC 패킷으로 이미 복구된 경우, 또는 2. FEC 패킷이 늦게 도착하여,
즉 recovery window 밖에 도착했고, 손실된 RTP 패킷이 playout 중에 이미
건너뛰어진 경우 발생할 수 있다. 이는 fecPacketsReceived의
하위 집합이다.
-
bytesReceived 유형은 unsigned
long long
-
이 SSRC에 대해 수신된 바이트의 총수.
여기에는 재전송이 포함된다.
[RFC3550]
6.4.1절에 정의된 대로 계산된다.
-
firCount 유형은 unsigned
long
-
audio에 대해서는 MUST NOT
존재해야 한다. 이
receiver가 전송한 Full Intra Request (FIR) 패킷의 총수를 센다.
이는 [RFC5104]
4.3.1절에 정의되어 있다. [RFC2032]에 표시된
RTCP FIR은 계산하지 않는다. 이는 [RFC4587]에 의해
폐기되었다.
-
pliCount 유형은 unsigned
long
-
audio에 대해서는 MUST NOT
존재해야 한다. 이
receiver가 전송한 Picture Loss Indication (PLI)
패킷의 총수를 센다. 이는 [RFC4585]
6.3.1절에 정의되어 있다.
-
totalProcessingDelay 유형은 double
-
이는 각 audio
sample 또는 video frame이
첫 RTP 패킷이 수신된 시점(reception timestamp)부터 대응하는 sample 또는 frame이
디코딩된 시점(decoded timestamp)까지 걸리는 시간을 초 단위로 합산한 값이다.
이 시점에서 audio sample 또는 video frame은 MediaStreamTrack에 의해 playout될 준비가 된 것이다.
여기서 playout 준비란 일반적으로 audio sample 또는 video frame이 decoder에 의해 완전히 디코딩된 이후를 의미한다.
관련 복잡성을 고려하여, 도착 시간 또는 reception timestamp는 가능한 한
네트워크 계층에 가까운 곳에서 측정되고, decoded timestamp는 완전한
sample 또는 frame이 디코딩되는 즉시 측정된다.
audio의 경우, 여러 sample이 같은 RTP 패킷으로 수신되며, 모든 sample은
같은 reception timestamp와 서로 다른 decoded timestamp를 공유한다.
video의 경우, frame은 여러 RTP 패킷에 걸쳐 수신된다. 이 경우
frame을 포함하는 가장 이른 timestamp가 reception timestamp로 계산되며,
decoded timestamp는 완전한 frame이 디코딩되는 시점에 대응한다.
이 메트릭은 디코딩되지 않은 프레임,
즉 framesDropped에
대해서는 증가하지 않는다.
평균 처리 지연은 totalProcessingDelay를
video의 경우
framesDecoded로
(또는 audio의 경우 provisional stats spec의 totalSamplesDecoded로)
나누어 계산할 수 있다.
-
nackCount 유형은 unsigned
long
-
이 receiver가 전송한 Negative ACKnowledgement (NACK) 패킷의 총수를 센다. 이는
[RFC4585]
6.2.1절에 정의되어 있다.
-
estimatedPlayoutTimestamp 유형은 DOMHighResTimeStamp
-
이는 이 receiver 트랙의 추정 playout 시간이다. playout 시간은 알려진
timestamp를 가진 마지막 재생 가능한 audio sample 또는 video
frame의
NTP timestamp이다(RTCP SR 패킷에서 RTP timestamp를 NTP
timestamp로 매핑한 것).
이것은 재생 준비가 된 이후 경과한 시간으로 외삽된다. 이는
sender의 NTP clock time에서 트랙의 "current time"이며,
현재 재생 중인 audio가 없어도 존재할 수 있다.
이는 같은 source의 두 track에 대해 audio와 video가 얼마나 동기화되지 않았는지를 추정하는 데 유용할 수 있다.
audioInboundRtpStats.estimatedPlayoutTimestamp
-
videoInboundRtpStats.estimatedPlayoutTimestamp.
-
jitterBufferDelay 유형은 double
-
jitter buffer의 목적은 RTP 패킷을 frame으로 재결합하고(video의 경우)
부드러운 playout을 제공하는 것이다. 여기서 설명하는 모델은 sample 또는 frame이
여전히 압축되어 있으며 아직 디코딩되지 않았다고 가정한다.
이는 각 audio
sample 또는 video frame이
첫 패킷이 jitter buffer에 수신된 시점(ingest timestamp)부터
jitter buffer를 빠져나가는 시점(emit timestamp)까지 걸리는 시간을 초 단위로 합산한 값이다.
audio의 경우 여러 sample이 같은 RTP 패킷에 속하므로 같은
ingest timestamp를 가지지만 서로 다른 jitter buffer emit timestamp를 가진다.
video의 경우 frame은 여러 RTP 패킷에 걸쳐 수신될 수 있으므로
ingest timestamp는 jitter buffer에 들어간 frame의 가장 이른 패킷이며,
emit timestamp는 전체 frame이 jitter buffer를 빠져나갈 때이다.
이 메트릭은 sample 또는 frame이 빠져나와 buffer에서의 시간을 완료할 때
(그리고 jitterBufferEmittedCount를
증가시킬 때)
증가한다. 평균 jitter buffer
delay는 jitterBufferDelay를
jitterBufferEmittedCount로
나누어 계산할 수 있다.
-
jitterBufferTargetDelay 유형은 double
-
이 값은 jitter buffer에서 sample이 emit될 때마다 target jitter buffer delay만큼 증가한다.
추가되는 target은 sample이 jitter buffer에서 emit된 시점의
target delay(초 단위)이다. 평균 target delay를 얻으려면
jitterBufferEmittedCount로
나눈다.
-
jitterBufferEmittedCount 유형은 unsigned long long
-
jitter buffer에서 나온 audio sample 또는 video frame의 총수
(jitterBufferDelay를
증가시킴).
-
jitterBufferMinimumDelay 유형은 double
-
AV 동기화를 달성하기 위해서나
jitterBufferTarget이
RTCRtpReceiver에 설정되었기 때문에 jitter buffer delay가 더 높은 값으로
증가할 수 있는 다양한 이유가 있다. 이러한 메커니즘 중 하나를 사용할 때는,
WebRTC 클라이언트가 추가되는 지연량을 추적할 수 있도록
달성할 수 있었던 최소 jitter buffer delay를 추적하는 것이 유용할 수 있다.
이 메트릭은 jitterBufferTargetDelay와
같은 방식으로 동작하지만,
jitterBufferTarget(위 링크 참조),
AV sync, 또는 다른 메커니즘처럼 jitter buffer target delay를 증가시키는
외부 메커니즘의 영향을 받지 않는다는 점이 다르다. 이 메트릭은 jitter 및 packet loss와 같은
네트워크 특성에만 순수하게 기반하며, 외부 요인이 영향을 주지 않는다면 얻을 수 있는
최소 jitter buffer delay로 볼 수 있다. 이 메트릭은
jitterBufferEmittedCount가
업데이트될 때마다 업데이트된다.
-
totalSamplesReceived 유형은 unsigned long long
-
video에 대해서는 MUST NOT 존재해야 한다. 이
RTP stream에서 수신된 sample의 총수이다. 여기에는
concealedSamples가
포함된다.
-
concealedSamples 유형은 unsigned long long
-
video에 대해서는 MUST NOT 존재해야 한다. concealed sample인
sample의 총수이다. concealed sample은 재생되기 전에
로컬에서 생성된 합성 sample로 대체된 sample이다. concealed되어야 하는 sample의 예로는
손실된 패킷의 sample(packetsLost에
보고됨)
또는 너무 늦게 도착하여 재생할 수 없는 패킷의 sample
(packetsDiscarded에
보고됨)이 있다.
-
silentConcealedSamples 유형은 unsigned long long
-
video에 대해서는 MUST NOT 존재해야 한다. 삽입된
concealed sample 중 "silent"인 sample의 총수이다.
silent sample을 재생하면 silence 또는 comfort noise가 발생한다. 이는
concealedSamples의
하위 집합이다.
-
concealmentEvents 유형은 unsigned long long
-
video에 대해서는 MUST NOT 존재해야 한다. concealment event의
수이다. 이 카운터는 non-concealed sample 이후
concealed sample이 합성될 때마다 증가한다. 즉, 연속된 여러
concealed sample은 concealedSamples
count를 여러 번 증가시키지만, concealment event는 하나이다.
-
insertedSamplesForDeceleration 유형은 unsigned long long
-
video에 대해서는 MUST NOT 존재해야 한다. playout이
느려질 때, 이 카운터는 수신된 sample 수와 재생된 sample 수의
차이만큼 증가한다. sample을 삽입하여 playout이 느려지는 경우,
이는 삽입된 sample의 수가 된다.
-
removedSamplesForAcceleration 유형은 unsigned long long
-
video에 대해서는 MUST NOT 존재해야 한다. playout이
빨라질 때, 이 카운터는 수신된 sample 수와 재생된 sample 수의
차이만큼 증가한다. sample을 제거하여 speedup이 달성되는 경우,
이는 제거된 sample의 수가 된다.
-
audioLevel 유형은
double
-
video에 대해서는 MUST NOT 존재해야 한다. 수신 track의
audio level을 나타낸다. 로컬에 연결된 track의 audio
level은 대신 RTCAudioSourceStats를 참조하라.
값은 0..1(선형) 사이이며, 1.0은 0 dBov, 0은
silence를 나타내고, 0.5는 0 dBov에서 sound pressure
level이 대략 6 dBSPL 변한 것을 나타낸다.
audioLevel은
totalAudioEnergy
아래에
설명된 알고리즘을 사용하여 작은 구간에 대해 평균된다.
사용되는 구간은 구현 정의이다.
-
totalAudioEnergy 유형은 double
-
video에 대해서는 MUST NOT 존재해야 한다. 수신 track의
audio energy를 나타낸다. 로컬에 연결된 track의
audio energy는 대신
RTCAudioSourceStats를 참조하라.
이 값은 다음과 같이 계산되어야 MUST 한다. 수신된 각 audio
sample에 대해
(따라서 totalSamplesReceived에
의해 계산됨),
sample의 값을 인코딩 가능한 최고 intensity 값으로 나눈 뒤 제곱하고,
sample의 지속 시간(초)을 곱한 값을 더한다. 즉,
duration * Math.pow(energy/maxEnergy, 2)이다.
이는 [RFC6464]에
정의된 것처럼 audioLevel과
같은 단위를 사용하는 root mean square (RMS) 값을 얻는 데 사용할 수 있다.
공식 Math.sqrt(totalAudioEnergy/totalSamplesDuration)을 사용하여
이러한 단위로 변환할 수 있다. 이 계산은 원하는 임의의 시간 구간에 대한
평균 audio level을 계산하기 위해 서로 다른 두
getStats()
호출 값의 차이를 사용하여 수행할 수도 있다.
즉, Math.sqrt((energy2 -
energy1)/(duration2 - duration1))를 수행한다.
예를 들어, 10ms audio 패킷이 RMS 0.5(1.0 중)로 생성되면,
이는 totalAudioEnergy에
0.5 * 0.5 * 0.01 = 0.0025를 더해야 한다.
RMS 0.1인 또 다른 10ms 패킷이 수신되면, 마찬가지로
totalAudioEnergy에
0.0001을 더해야 한다.
그러면 Math.sqrt(totalAudioEnergy/totalSamplesDuration)은
Math.sqrt(0.0026/0.02) = 0.36이 되며, 이는 연속된 20ms audio 구간에 대해
RMS 계산을 수행하여 얻을 수 있는 값과 같다.
여러 audio channel이 사용되는 경우,
sample의 audio energy는 어떤 channel의 가장 높은 energy를 가리킨다.
-
totalSamplesDuration 유형은 double
-
video에 대해서는 MUST NOT 존재해야 한다. 수신 track의
audio duration을 나타낸다. 로컬에 연결된 track의
audio duration은 대신
RTCAudioSourceStats를 참조하라.
수신된 모든 sample의 총 지속 시간을 초 단위로 나타낸다
(따라서 totalSamplesReceived에
의해 계산됨).
이는 totalAudioEnergy와
함께 사용하여
서로 다른 구간에 대한 평균 audio level을 계산할 수 있다.
-
framesReceived 유형은 unsigned
long
-
audio에 대해서는 MUST NOT 존재해야 한다. 이
RTP stream에서 수신된 완전한 frame의 총수를 나타낸다.
이 메트릭은 완전한 frame이 수신될 때 증가한다.
-
decoderImplementation 유형은 DOMString
-
하드웨어 노출이
허용되지 않는 한
MUST NOT 존재해야 한다.
audio에 대해서는 MUST NOT 존재해야 한다. 사용된
decoder implementation을 식별한다.
이는 상호운용성 문제를 진단하는 데 유용하다.
-
playoutId
유형은 DOMString
-
video에 대해서는 MUST NOT 존재해야 한다.
audio playout이 발생 중이면, 이는 대응하는
RTCAudioPlayoutStats를
찾는 데 사용된다.
-
powerEfficientDecoder 유형은 boolean
-
하드웨어 노출이
허용되지 않는 한
MUST NOT 존재해야 한다.
audio에 대해서는 MUST NOT 존재해야 한다.
현재 사용 중인 decoder가 사용자 에이전트에 의해 전력 효율적인 것으로 간주되는지 여부.
이는 구성이 hardware acceleration을 결과로 하는지 여부를 반영해야 SHOULD 하지만,
사용자 에이전트는 해당 구성이 전력 효율적인 것으로 간주되는지 결정할 때
다른 정보도 고려할 수 MAY 있다.
-
framesAssembledFromMultiplePackets 유형은
unsigned long
-
audio에 대해서는 MUST NOT 존재해야 한다.
이는 둘 이상의 RTP 패킷으로 구성된 이 RTP stream에 대해
올바르게 디코딩된 frame의 총수를 나타낸다. 그러한 frame의 경우
totalAssemblyTime이
증가한다. 평균 frame assembly time은
totalAssemblyTime을
framesAssembledFromMultiplePackets로
나누어 계산할 수 있다.
-
totalAssemblyTime 유형은 double
-
audio에 대해서는 MUST NOT 존재해야 한다.
각 video frame이 첫 RTP 패킷이 수신된 시점(reception timestamp)부터
frame의 마지막 RTP 패킷이 수신된 시점까지 걸리는 시간을 초 단위로 합산한 값이다.
둘 이상의 RTP 패킷으로 구성된 frame에 대해서만 증가한다.
관련 복잡성을 고려하여, 도착 시간 또는 reception timestamp는
가능한 한 네트워크 계층에 가까운 곳에서 측정된다. 이 메트릭은
디코딩되지 않은 frame, 즉 framesDropped나
다른 이유로 디코딩에 실패한 frame(있는 경우)에 대해서는 증가하지 않는다.
둘 이상의 RTP 패킷으로 구성된 frame에 대해서만 증가한다.
-
retransmittedPacketsReceived 유형은 unsigned long long
-
이 SSRC에 대해 수신된 retransmitted packet의 총수.
이는 packetsReceived의
하위 집합이다.
RTX가 협상되지 않은 경우,
retransmitted packet을 식별할 수 없으며 이 멤버는 MUST
NOT 존재해야 한다.
-
retransmittedBytesReceived 유형은 unsigned long long
-
이 SSRC에 대해
수신된 retransmitted byte의 총수이며, payload 바이트만 포함한다.
이는 bytesReceived의
하위 집합이다.
RTX가 협상되지 않은 경우, retransmitted packet을 식별할 수 없으며 이 멤버는 MUST NOT
존재해야 한다.
-
rtxSsrc
유형은 unsigned long
-
별도의 RTP
stream에서 재전송을 위한 RTX가 협상된 경우, 이는
이 stream의 ssrc와 연결된 RTX stream의
SSRC이다.
RTX가 협상되지 않은 경우, 이 값은 MUST NOT 존재해야 한다.
-
fecSsrc
유형은 unsigned long
-
별도의 RTP stream을 사용하는
FEC 메커니즘이 협상된 경우, 이는 이 stream의 ssrc와 연결된
FEC stream의 SSRC이다.
FEC가 협상되지 않았거나 같은 RTP stream을 사용하는 경우,
이 값은 MUST NOT
존재해야 한다.
-
totalCorruptionProbability 유형은 double
-
audio에 대해서는 MUST NOT 존재해야 한다. 이 SSRC에 대해
수행된 모든 corruption
probability 측정값의 누적 합을 나타낸다. 이 속성이 언제 corruptionMeasurements를
참조하여 SHOULD 존재해야
하는지 확인하라.
totalCorruptionProbability에
더해지는 각 측정값은 [0.0, 1.0] 범위에 있어야 MUST 한다.
여기서 0.0 값은 시스템이 처리된 프레임에 corruption이 없거나 무시할 수 있을 정도라고
추정했음을 나타낸다. 마찬가지로 1.0 값은 처리된 프레임에 보이는 corruption이 거의
확실히 있음을 나타낸다. 그 사이의 값은 보이는 corruption이 있을 가능성이 있지만,
예를 들어 magnitude가 낮거나 frame의 작은 부분에만 존재할 수 있음을 나타낸다.
참고
corruption likelihood 값은 추정치이지 보장이 아니다. 추정치가
0.0이더라도, 예를 들어 frame의 매우 작은 영역만 영향을 받은 경우
corruption이 존재할 수 있다(즉 false negative). 마찬가지로, 추정치가 1.0이더라도,
예를 들어 frame 평균보다 훨씬 높은 QP를 가진 macroblock이 있는 경우
corruption이 존재하지 않을 수 있다(즉 false positive).
PSNR 측정 등에도 edge case가 있는 것처럼, 이러한 메트릭은
frame별 절대적 진실로 사용하기보다는 주로 통계 분석의 기초로
사용해야 한다.
-
totalSquaredCorruptionProbability 유형은
double
-
audio에 대해서는 MUST NOT 존재해야 한다. 이 SSRC에 대해
수행된 모든 corruption
probability 측정값의 제곱 누적 합을 나타낸다. 이 속성이 언제
corruptionMeasurements를
참조하여 SHOULD 존재해야
하는지 확인하라.
-
corruptionMeasurements 유형은 unsigned long long
-
audio에 대해서는 MUST NOT 존재해야 한다. 사용자 에이전트가
corruption probability 측정을 수행할 수 있을 때,
이 카운터는 각 측정마다 증가하며,
totalCorruptionProbability
및 totalSquaredCorruptionProbability는
각각 이 측정값 및 측정값의 제곱과 함께 집계된다.
RTP 패킷에
corruption-detection header extension이 있는 경우, corruption
probability measurements는 MUST 존재해야 한다.