You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/communication-services/concepts/voice-video-calling/media-quality-sdk.md
+22-22Lines changed: 22 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ ms.subservice: calling
14
14
---
15
15
16
16
# Media quality statistics
17
-
When working with calls in Azure Communication Services, there will be times that you need to know the media quality statistics that are being generated within an Azure Communication Services call. To help understand these details, we have a feature called "Media quality statistics" that you can use to examine the low-level audio, video, and screen-sharing quality metrics.
17
+
Do help understand media quality in VoIP and Video calls using Azure Communication Services, we have a feature called "Media quality statistics" that you can use to examine the low-level audio, video, and screen-sharing quality metrics for incoming and outgoing call metrics.
18
18
19
19
## Media quality statistics for ongoing call
20
20
> **NOTE**
@@ -41,7 +41,7 @@ Where
41
41
-`aggregationInterval` is the interval in seconds that the statistics will be aggregated.
42
42
-`dataPointsPerAggregation` defines how many data points are there for each aggregation event.
43
43
44
-
After adding an event listener to media stats collector, you will receive `mediaStatsEmitted` event with stats every `aggregationInterval * dataPointsPerAggregation` seconds.
44
+
After adding an event listener to media stats collector, you'll receive `mediaStatsEmitted` event with stats every `aggregationInterval * dataPointsPerAggregation` seconds.
We removed `disposeAllCollectors` method. The collectors will be reclaimed when mediaStatsFeature is disposed.
79
79
80
80
## Best practices
81
-
If you want to collect this data for off-line inspection (after a call ends) it is recommended to collect this data and send it to your pipeline ingest after your call has ended. If you transmit this data during a call, it could use internet bandwidth that is needed to continue an Azure Communication Services call (especially when available bandwidth is low).
81
+
If you want to collect this data for off-line inspection (after a call ends), it is recommended to collect this data and send it to your pipeline ingest after your call has ended. If you transmit this data during a call, it could use internet bandwidth that is needed to continue an Azure Communication Services call (especially when available bandwidth is low).
82
82
83
83
## MediaStats Metrics for SDK Version `>= 1.8.0`
84
84
85
-
The bandwidth metrics is now`availableBitrate` in Audio Send / Video Send metrics.
85
+
The bandwidth metrics have changes to`availableBitrate` in Audio Send / Video Send metrics.
86
86
87
87
### Audio Send metrics
88
88
| Metric Name | Description | Comments |
89
89
| ----------- | ----------- | -------- |
90
90
| id | stats id | It is used to identify stats across the events, especially when there are multiple stats with same media type and direction in an event. |
91
-
| codecName | codec name | OPUS, G722, etc |
92
-
| bitrate | audio send bitrate (bps) | General values are in the 24 kbps range (36-128kbps typical) |
91
+
| codecName | codec name | OPUS, G722|
92
+
| bitrate | audio send bitrate (bps) | General values are in the 24 kbps range (36-128 kbps typical) |
| packetsLostPerSecond | packet loss rate (packets/sec) | Lower is better. |
96
-
| rttInMs | round-trip time (milliseconds) | Lower is better. It is calculated from RTCP Receiver Report. A round trip time of 200 ms or less is recommended. |
97
-
| pairRttInMs |rount-trip time (milliseconds) | Lower is better. It is similar to rttInMS but is calculated from STUN connectivity check. A round trip time of 200 ms or less is recommended. |
96
+
| rttInMs | round-trip time (milliseconds) | Lower is better. It's calculated from RTCP Receiver Report. A round trip time of 200 ms or less is recommended. |
97
+
| pairRttInMs |round-trip time (milliseconds) | Lower is better. It's similar to rttInMS but is calculated from STUN connectivity check. A round trip time of 200 ms or less is recommended. |
| audioInputLevel | audio volume level from microphone | The value ranges from 0-65536. 0 represents silence |
100
100
101
-
### Audio Recv metrics
101
+
### Audio Receive metrics
102
102
| Metric Name | Description | Comments |
103
103
| ----------- | ----------- | -------- |
104
104
| id | stats id | It is used to identify stats across the events, especially when there are multiple stats with same media type and direction in an event. |
105
-
| codecName | codec name | OPUS, G722, etc |
106
-
| bitrate | audio recv bitrate (bps) | General values are in the 24 kbps range (36-128kbps typical) |
105
+
| codecName | codec name | OPUS, G722|
106
+
| bitrate | audio receive bitrate (bps) | General values are in the 24 kbps range (36-128 kbps typical) |
| packetsLostPerSecond | packet loss rate (packets/sec) | Lower is better. |
110
-
| pairRttInMs |rount-trip time (milliseconds) | Lower is better. It is calculated from STUN connectivity check. A round trip time of 200 ms or less is recommended. |
110
+
| pairRttInMs |round-trip time (milliseconds) | Lower is better. It is calculated from STUN connectivity check. A round trip time of 200 ms or less is recommended. |
111
111
| jitterBufferInMs | jitter buffer (milliseconds) | Lower is better. The jitter buffer is used for smooth playout. This value is how long the packets of the samples stay in the jitter buffer. |
112
112
| audioOutputLevel | audio volume level from receiving stream | The value ranges from 0-65536. 0 represents silence. |
113
113
| healedRatio | ratio of concealedSamples(except silentConcealedSamples) to total received samples | Information only. |
@@ -122,7 +122,7 @@ The bandwidth metrics is now `availableBitrate` in Audio Send / Video Send metri
122
122
| packetsPerSecond | packet rate (packets/sec) ||
123
123
| packetsLostPerSecond | packet loss rate (packets/sec) | Lower is better. |
124
124
| rttInMs | round-trip time (milliseconds) | Lower is better. It is calculated from RTCP Receiver Report. A round trip time of 200 ms or less is recommended. |
125
-
| pairRttInMs |rount-trip time (milliseconds) | Lower is better. It is similar to rttInMS but is calculated from STUN connectivity check. A round trip time of 200 ms or less is recommended. |
125
+
| pairRttInMs |round-trip time (milliseconds) | Lower is better. It is similar to rttInMS but is calculated from STUN connectivity check. A round trip time of 200 ms or less is recommended. |
126
126
| availableBitrate | bandwidth estimation (bps) | 1.5 Mbps or higher is recommended for high-quality video for upload/download. |
127
127
| frameRateInput | frame rate originating from the video source (frames/sec) ||
128
128
| frameWidthInput | frame width of the last frame originating from video source (pixel) ||
@@ -135,16 +135,16 @@ The bandwidth metrics is now `availableBitrate` in Audio Send / Video Send metri
135
135
| framesEncoded | frames successfully encoded for the RTP stream ||
136
136
| keyFramesEncoded | key frames successfully encoded for the RTP stream ||
137
137
138
-
### Video Recv metrics
138
+
### Video Receive metrics
139
139
| Metric Name | Description | Comments |
140
140
| ----------- | ----------- | -------- |
141
141
| id | stats id | It is used to identify stats across the events, especially when there are multiple stats with same media type and direction in an event. |
| packetsLostPerSecond | packet loss rate (packets/sec) | Lower is better. |
147
-
| pairRttInMs |rount-trip time (milliseconds) | Lower is better. A round trip time of 200 ms or less is recommended. |
147
+
| pairRttInMs |round-trip time (milliseconds) | Lower is better. A round trip time of 200 ms or less is recommended. |
148
148
| jitterBufferInMs | jitter buffer (milliseconds) | Lower is better. The jitter buffer is used for smooth playout. This value is the how long the packets of the frame stay in the jitter buffer. |
149
149
| streamId | stream id | The streamId value corresponds to id in VideoStreamCommon. It can be used to match the sender. |
| audioSendBitrate | Sent bitrate | Send bitrate of audio (bits per second) | General values are in the 24 kbps range (36-128kbps typical) |
205
-
| audioRecvBitrate | Received bitrate | Received bitrate of audio received (bits per second) ||
204
+
| audioSendBitrate | Sent bitrate | Send bitrate of audio (bits per second) | General values are in the 24 kbps range (36-128 kbps typical) |
205
+
| audioRecvBitrate | Received audio bitrate | Received bitrate of audio received (bits per second) ||
206
206
| audioSendPackets | Sent packets | The number of audio packets sent in last second (packets per second) ||
207
207
| audioRecvJitterBufferMs | Jitter buffer delay | The jitter buffer is used for smooth playout. This value is the how long the packets of the samples stay in the jitter buffer. (in milliseconds (ms)) | Lower is better. |
208
208
| audioRecvPacketsLost | Received packet loss | The number of audio packets that were to be received but were lost. Results are packets per second (over the last second). | Lower is better. |
| VideoRecvPacketsLost | Received packet loss | The number of video packets that were to be received but were lost. Results are packets per second (over the last second). | Lower is better |
238
238
| videoSendPacketsLost | Sent packet loss | The number of audio packets that were sent but were lost. Results are packets per second (over the last second). | Lower is better |
239
239
| videoSendFrameRateInput | Sent framerate input | Framerate measurements from the stream input into peerConnection | Information only |
240
-
| videoRecvFrameRateDecoded | Received decoded framerate | Framerate from decoder output. This takes videoSendFrameRateInput as an input, might be some loss in decoding | Information only |
240
+
| videoRecvFrameRateDecoded | Received decoded framerate | Framerate from decoder output. This metric takes videoSendFrameRateInput as an input, might be some loss in decoding | Information only |
241
241
| videoSendFrameWidthInput | Sent frame width input | Frame width of the stream input into peerConnection. This takes videoRecvFrameRateDecoded as an input, might be some loss in rendering. | 1920, 1280, 960, 640, 480, 320 |
242
242
| videoSendFrameHeightInput | Sent frame height input | Frame height of the stream input into peerConnection | 1080, 720, 540, 360, 270, 240 |
243
243
| videoRecvLongestFreezeDuration | Received longest freeze duration | How long was the longest freeze | Lower is better |
0 commit comments