W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2014

Re: Stats - minor updates

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 10 Feb 2014 18:38:57 +0100
Message-ID: <52F90EB1.7070206@alvestrand.no>
To: Tim Panton new <thp@westhawk.co.uk>
CC: public-webrtc <public-webrtc@w3.org>
On 02/10/2014 06:14 PM, Tim Panton new wrote:
> On 10 Feb 2014, at 16:59, Harald Alvestrand <harald@alvestrand.no
> <mailto:harald@alvestrand.no>> wrote:
>> On 02/10/2014 05:45 PM, Tim Panton new wrote:
>>> On 16 Jan 2014, at 22:46, Harald Alvestrand <harald@alvestrand.no
>>> <mailto:harald@alvestrand.no>> wrote:
>>>> Jan-Ivar reminded me of some things that needed updating.
>>>> You can see the diff I did here:
>>>> http://www.w3.org/2011/04/webrtc/wiki/index.php?title=Stats&diff=386&oldid=383
>>>> The most controversial (?) may be the addition of priority at both
>>>> candidate and candidate pair level; given that the computation of
>>>> the 64-bit candidate pair priority is less simple than one would
>>>> think, it seems to make sense to give both.
>>> Looking through this for the first time in _ages_ , I'm wondering
>>> how a javascript programmer associates a set of statistics 
>>> with a specific <video> element ?
>> He doesn't. These are stats for a PeerConnection, not for a MediaElement.
>>> Am I missing something obvious, or is it easier in the spec than on
>>> the current canary?
>> I think the app needs to "know" which PeerConnection to interrogate
>> for a given <video> element - after all, the app was the one to
>> connect them, so it should be possible.
> Knowing the peer connection is ok. But I don't see a way of knowing
> which ssrcIds got associated with a videoElement (other than looking
> at the peerConnection SDP). You know the trackId, but I don't think
> that corresponds to the trackId in the stats - or is that a
> mis-reading on my part.

The MediaStreamTrack object isn't implemented yet, as far as I remember.

Its definition starts off:

dictionary RTCMediaStreamTrackStats : RTCStats {
   DOMString trackIdentifier;  // track.id property
   boolean remoteSource;
   sequence<DOMString> ssrcIds;

with the trackIdentifier being intended to let you look up the track
from the stats, or search the stats for the stats of a track you know.

The ssrcIds are intended to be the IDs of the corresponding
RTCRTPStreamStats objects.

>> Once you know which MediaStreamTrack carries the video for that
>> element, you should be able to pass that as a filter argument to
>> GetStats, so that you can avoid wading through irrelevant statistics.
> Last I looked that filter wasn't implemented anywhere. (yet) Again
> have I missed a refreshed version?

Hm.... the filter was implemented in Chrome pretty long ago (but I think
we changed the order of arguments in the GetStats call after that, so
old test programs might not work). There's a test in the Blink sources
that tests that filtering works
(LayoutTests/fast/mediastream/RTCPeerConnection-statsSelector.html) - so
the filter argument should do *something*

Not sure it does the right thing, but at least it exists.

> T.
>> -- 
>> Surveillance is pervasive. Go Dark.

Surveillance is pervasive. Go Dark.
Received on Monday, 10 February 2014 17:39:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:54 UTC