MDN wants to learn about developers like you: https://qsurvey.mozilla.com/s3/MDN-dev-survey

この記事はまだボランティアによって 日本語 に翻訳されていません。ぜひ MDN に参加して翻訳を手伝ってください!
この記事を English (US) で読むこともできます。

Draft
This page is not complete.

This page is currently incomplete and under active construction. Please be aware that it's not going to answer all of your questions just yet.

The RTCStatsReport interface is used to provide statistics data about WebRTC connections as returned by the RTCPeerConnection.getStats(), RTCRtpReceiver.getStats(), and RTCRtpSender.getStats() methods. This object consists of a mapping of strings which identify a category of statistics to objects which contains the various measured values for each.

Calling getStats() on an RTCPeerConnection lets you specifiy whether you wish to obtain statistics for outbound, inbound, or all streams on the connection. The RTCRtpReceiver and RTCRtpSender versions of getStats() specifically only return the incoming and outgoing streams, respectively.

The RTCStats subdictionaries

The full RTCStatsReport interface is made up of a mapping of strings to subdictionaries which contain the statistics for each category, such as ICE candidate or media stream statistics. Each of these subdictionaries has in common the following values:

timestamp
A DOMHighResTimeStamp object which indicates the time at which the data was handled by the local WebRTC layer; for example, for statistics related to received RCTP packets, this would indicate the time at which the data was received by the local endpoint (the remote timestamp is available as well in one of the fields defined within one of the other subdictionaries. The time is specified relative to the UNIX epoch (the first moment of January 1, 1970, UTC).
type
A string, taken from the enum type RTCStatsType,
id
A DOMString which uniquely identifies the object which was inspected to produce this object based on RTCStats. This allows any two RTCStats-based objects which were produced from the same data to be correlated to one another. The format of this ID is not defined by the specification, so it cannot be relied upon to have any particular format, structure, or meaning beyond that.

From a definition standpoint, these values are defined in the RTCStats dictionary in RTCStatsReport's WebIDL file.

RTCRTPStreamStats

RTCRTPStreamStats is the base class for all RTP-related statistics reports. It's based on RTCStats and adds the following additional fields.

Standard fields included for all media types

ssrc
The 32-bit integer which identifies the source of the RTP packets this RTCRTPStreamStats object covers. This value is generated per the RFC 3550 specification.
mediaType
A DOMString which identifies the type of media being carried on the associated MediaStreamTrack. This must be either "audio" or "video", and will match the media type included in RTCCodecStats.codec.
trackId
A DOMString which uniquely identifies the RTCMediaStreamTrackStats object representing the associated MediaStreamTrack. This is not the same as the value of MediaStreamTrack.id.
transportId
A DOMString uniquely identifying the object which was inspected to produce the RTCTransportStats object associated with this RTP stream.
codecId
A DOMString which uniquely identifies the object which was inspected to produce the RTCCodecStats object associated with this RTP stream.

Local-only measurements

These properties are computed locally, and are only available to the device receiving the media stream. Their primary purpose is to examine the error resiliency of the connection, as they provide information about lost packets, lost frames, and how heavily compressed the data is.

firCount
A count of the total number of Full Intra Request (FIR) packets received by the sender. This statistic is only available to the device which is receiving the stream and is only available for video tracks. A FIR packet is sent by the receiving end of the stream when it falls behind or has lost packets and is unable to continue decoding the stream; the sending end of the stream receives the FIR packet and responds by sending a full frame instead of a delta frame, thereby letting the receiver "catch up." The higher this number is, the more often a problem of this nature arose, which can be a sign of network congestion or an overburdened receiving device.
pliCount
The number of times the receiving end of the stream sent a Picture Loss Indiciation (PLI) packet to the sender, indicating that it has lost some amount of encoded video data for one or more frames. Only the receiver has this value, and it's only valid for video tracks.
nackCount
The number of times the receiver notified the sender that one or more RTP packets has been lost by sending a Negative ACKnowledgement (NACK, also called "Generic NACK") packet to the sender. This value is only available to the receiver.
sliCount
The number of times the receiver notified the sender that one or more consecutive (in scan order) encoded video macroblocks have been lost or corrupted; this notification is sent by the receiver to the sender using a Slice Loss Indication (SLI) packet. This is a fairly technical part of how codecs work and while the higher this value is, the more errors occurred in the stream, generally most of the time this value is only interesting to very intensively hardcore media developers.
qpSum
The sum of the Quantization Parameter (QP) values associated with every frame received to date on the video track described by this RTCStats object. In general, the higher this number is, the more heavily compressed the video track was. Combined with RTCReceivedRTPStreamStats.framesDecoded or RTCSentRTPStreamStats.framesEncoded, you can approximate the average QP over those frames, keeping in mind that codecs often vary the quantizer values even within frames. Also keep in mind that the values of QP can vary from codec to codec, so this value is only potentially useful when compared against the same codec.

RTCInboundRTPStreamStats

Contains statistics about inbound RTP streaming. The RTCInboundRTPStreamStats dictionary is based upon both RTCStats and RTCRTPStreamStats and includes all properties from those dictionaries, as well as the following:

bytesReceived
...
jitter
...
packetsDiscarded
...
packetsLost
...
packetsReceived
...

RTCOutboundRTPStreamStats

Contains statistics about outbound RTP streaming. The RTCOutboundRTPStreamStats dictionary is based upon both RTCStats and RTCRTPStreamStats and includes all properties from those dictionaries, as well as the following:

packetsSent
A long integer indicating the number of RTP packets sent...
bytesSent
A 64-bit integer indicating how many bytes of data have been sent on the stream...
targetBitrate
...

Properties

droppedFrames
The number of frames which have been
framesEncoded
A long integer which indicates the total number of frames successfully encoded for this RTP stream. This field is only present on video connections.

RTCMediaStreamTrackStats

RTCMediaStreamStats

RTCRTPContributingSourceStats

RTCTransportStats

RTCIceComponentStats

RTCIceCandidatePairStats

RTCIceCandidateStats

RTCCodecStats

Specifications

Specification Status Comment
WebRTC 1.0: Real-time Communication Between Browsers
The definition of 'RTCPeerConnection.currentRemoteDescription' in that specification.
Working Draft Initial specification.

Browser compatibility

Feature Chrome Firefox (Gecko) Internet Explorer Opera Safari
Basic support No support No support No support No support No support
Feature Android Webview Chrome for Android Firefox Mobile (Gecko) IE Mobile Opera Mobile Safari Mobile
Basic support No support No support No support No support No support No support

The addition of currentRemoteDescription and pendingLocalDescription to the WebRTC spec is relatively recent. In browsers which don't support them, just use remoteDescription.

See also

ドキュメントのタグと貢献者

 このページの貢献者: Sheppy
 最終更新者: Sheppy,