Re: Media Stastics in API

[resend since I didn't see it come through and I'm having email issues - 
I may simply have lost the copy that came back]

On 8/30/2011 2:33 PM, Cullen Jennings wrote:
> When the browser sends and receives audio and video, all kinds of statistics and reporting information is possible. We get information from IP, ICMP, RTP, RTCP, codecs and more. I feel that applications really need access to some of this information and would like to start a thread on what JS applications need. What I really really really don't want to do is enumerate everything that is possible to generate then expose all that via an API. I'd rather use our experience with existing voice and video to figure out what turns out to be useful and report that.
>
> Heres is a few things I think might be useful as a starting point
>
> Packet loss rate in each direction
>
> Round trip time and jitter
>
> Current total bitrate each direction
>
> These three are the most basic bits of information need to detect and understand why an application may be experiencing poor quality media. Thoughts? What else do we need? If you say all of RTCP-XR I am going to release the flying monkeys.

Hey, flying monkeys are tough to come by - careful about releasing them!

Codecs in use in each direction  (note: while slightly to totally odd, 
each stream could have a different codec - i.e. if you're sending 2 
streams from different mics (or cameras) they could in theory have 
different codecs).  This assumes that the answerer accepted multiple
codecs.

Bitrate per stream (versus total bitrate which is also interesting)

For video streams, frame rate and resolution.

? Idle status for each stream, or time since we saw data on it?  May not 
be useful.


> I'm also interested in a simple API proposal for this that has the right sort of extensibility properties as more things get added over time.
>

There's XML.  :-)

A JSON object might make sense, with some per-direction data and a list
of streams, each with per-direction data.  Not really my area, though.


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Thursday, 1 September 2011 03:28:22 UTC