Re: Stats proposal, updated

On 06/21/2012 02:24 PM, Harald Alvestrand wrote:
> As usual, apologies for the formatting, and errors in the WebIDL is a
> certainty, not a possibility.
>
> I've tried to insert the level of indirection that allows us to return a
> set of objects for (say) a media stream with FEC that uses multiple
> SSRCs rather than just a single object.

I think the proposed stats to track look like a good start, but I think 
that an additional one that could be of interest is the actual 
interface/network used. The app gets to know (sort of) what interfaces 
that are available since the candidates are handled by the app. But 
knowing what interface that was in actual use could be very helpful.

Regarding the API, an alternative approach could be to tie this more to 
the tracks of the MediaStreams, e.g. add something to the 
MediaStreamTrack interface:

     void getInfo(Function handler);

The info delivered would depend on the source of the track. For tracks 
in local (i.e. generated locally and not delivered by a PeerConnection) 
MediaStreams, the info would be things like sampling rate, channels 
(mono, 5.1) for audio; resolution and frame rate for video. If the 
MediaStream has traveled over a PeerConnection, the info listed in your 
document (packets received/lost, ssrc, codec, ) would be appended.

This would associate the stats to a MediaStreamTrack, getting rid of 
referencing problems (when MediaStreams are added or removed) if the 
local/remoteStreams is used. In addition, if the corresponding info is 
requested for data channels, it could easily be added to those.

One drawback is that only the receiving app would get the stats 
associated with the PeerConnection transport. But as said, the main 
receiver of stats is the service provider, and reporting per 
MediaStreamTrack allows the service provider to correlate stats (perhaps 
using the MediaStream label). And in most cases it is the same 
application in both ends, and the receiving end could share the stats 
with the sending end (perhaps using the data channel) if desired. If 
there are different apps used, they could still agree on stats exchange 
(just as they would have to agree on a bunch of other things to get 
things working) if desired.

Stefan

>
> Comments welcome!
>
>                       Harald
>

Received on Monday, 25 June 2012 07:22:54 UTC