On 2/3/14 12:06 PM, Adam Roach wrote:
The dominating factors in media quality are going to be jitter, packet
loss, and RTT.
* For jitter, we already have an entry in the stats report
* I'll suggest to the working group that we should add packet loss to
the evolving list of stats
Actually, packet loss is in there but is stored in a funny way because
of the nature of the stats objects (from
http://www.w3.org/2011/04/webrtc/wiki/Stats ):
dictionary RTCRTPStreamStats : RTCStats {
DOMString ssrc;
DOMString remoteId;
// New stuff:
boolean isRemote // default false
DOMString mediaTrackId;
DOMString transportId;
DOMString codecId;
};
dictionary RTCInboundRTPStreamStats : RTCRTPStreamStats {
unsigned long packetsReceived;
unsigned long long bytesReceived;
double jitter;
};
dictionary RTCOutboundRTPStreamStats : RTCRTPStreamStats {
unsigned long packetsSent;
unsigned long long bytesSent;
};
Basically, for one side of a single connection, you get a pair of these
stats objects.
For example, if your PeerConnection is the receiver, then if you iterate
on the returned statsReport object you'll find (at least) one
RTCInboundRTPStreamStats object (whose isRemote member is false),
which is filled with RTP information.
You use the remoteId member of that object to get to the second object
(whose isRemote member is true) which is filled with the RTCP
information for the same connection, i.e. from "the other side" of the
connection (a RTCOutboundRTPStreamStats in this example).
The idea then is you calculate packet loss by subtracting
packetsReceieved from packetsSent.
Here's a larger example that uses the same technique
http://dev.w3.org/2011/webrtc/editor/webrtc.html#example
However, there's a wort here, which I hope to raise on the list, which
is that RTCP information and RTP information often arrive at different
intervals internall, which you can see from the timestamps being
different on the two stats objects, making it real hard in practice to
understand how to calculate packet-loss reliable.
Ironically, since we have the packetloss number internall (RTCP gives it
to us) we are currently forced to do the reverse calculation that we're
asking you to do when we put this information in the stats object. So in
practice, for Firefox at least, which is the only browser implementing
this right now, this means that if you ignore the timestamps and just to
the subtraction blindly, you shold arrive at the correct packetloss
number, because that's the reverse of what we did
putting it in there. But it feels a little awkward and wrong given that
the timestamps are often different.
I think adding an explicit packetLoss field, next to jitter would solve
this.
CC'ing Harald for comment. He'll also be able to correct me if I said
something incorrect here.
.: Jan-Ivar :.
* As far as I know, there's no good way to get RTT information out of
RTP and RTCP, so you'll probably want to rig something up with a
DataChannel that basically sends a small message with a sequence
number to the other side, which responds immediately; the time
between sending the message and getting the response is you RTT
From there, I'd try to work out a quality metric by starting with
something like:
(min(6ms - jitter_in_ms, 0) * (100% - packet_loss_in_percent) *
min(200ms - rtt_in_ms, 0))/600
...which should get you a number between 1 and 100. You might want to
tweak things a bit, but that should get you a good first pass estimate.
I'm happy to demo to you in Chrome what we currently have (if that
doesn't go against your morals? ;)
Sure, send me a URL to look at. :)
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
