Re: Stats - minor updates

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.