Front-posting: I need to add "unsigned long packetsLost" to RTCInboundRTPStreamStats - that stat should have all the stuff that the receiver needs to count anyway in order to send correct RTCP reports.
You're completely right that calculating the packet loss rate from the number of packets arrived from the other side is untenable, since that difference will probably be dominated by packets sent after the remote side sent the report. On 02/04/2014 06:35 PM, Jan-Ivar Bruaroey wrote: > 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. Yep, that's why this is wrong, and I need to extend the objects. > > 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. :) >> >> > -- Surveillance is pervasive. Go Dark. _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
