[whatwg] Media elements statistics

[Steve Lacey]

All,

I've updated the wiki with a proposal...

http://wiki.whatwg.org/wiki/Video_Metrics#Proposal

Cheers!
Steve

On Sat, Apr 9, 2011 at 7:08 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> Ah, thanks for the link. I've included Silverlight stats, too, for
> completeness. If somebody knows about QuickTime stats, that would be
> another good one to add, I guess.
>
> Cheers,
> Silvia.
>
> On Fri, Apr 8, 2011 at 5:21 PM, Jeroen Wijering
> <jeroen at longtailvideo.com> wrote:
> >
> > On Apr 7, 2011, at 8:11 AM, Silvia Pfeiffer wrote:
> >
> >> I've also just added a section with the stats that the Adobe Flash
> >> player exposes.
> >
> > Great. Perhaps Silverlight stats might be of use too - though they're
> fairly similar:
> >
> >
> http://learn.iis.net/page.aspx/582/advanced-logging-for-iis-70---client-logging/
> >
> >> Apart from the statistics that are not currently available from the
> >> HTML5 player, there are stats that are already available, such as
> >> currentSrc, currentTime, and all the events which can be turned into
> >> hooks for measurement.
> >
> > Yes, the network and ready states are very useful to determine if clients
> are stalling for buffering etc.
> >
> >> I think the page now has a lot of analysis of currently used stats -
> >> probably a sufficient amount. All the video publishing sites likely
> >> just use a subpart of the ones that Adobe Flash exposes in their
> >> analytics.
> >
> > Especially all the separate A/V bytecounts are overkill IMO.
> >
> > One useful metric I didn't list for JW Player but is very nice is Flash's
> "isLive" property.
> >
> > Kind regards,
> >
> > Jeroen
> >
> >
> >
> >
> >> On Thu, Apr 7, 2011 at 4:52 AM, Mark Watson <watsonm at netflix.com>
> wrote:
> >>> All,
> >>>
> >>> I added some material to the wiki page based on our experience here at
> Netflix and based on the metrics defined in MPEG DASH for adaptive
> streaming. I'd love to here what people think.
> >>>
> >>> Statistics about presentation/rendering seem to be covered, but what
> should also be considered are network performance statistics, which become
> increasingly difficult to collect from the server when sessions are making
> use of multiple servers, possibly across multiple CDNs.
> >>>
> >>> Another aspect important for performance management is error reporting.
> Some thoughts on that on the page.
> >>>
> >>> ...Mark
> >>>
> >>> On Mar 31, 2011, at 7:07 PM, Robert O'Callahan wrote:
> >>>
> >>>> On Fri, Apr 1, 2011 at 1:33 PM, Chris Pearce <chris at pearce.org.nz>
> wrote:
> >>>>
> >>>>> On 1/04/2011 12:22 p.m., Steve Lacey wrote:
> >>>>>
> >>>>>> Chris - in the mozilla stats, I agree on the need for a frame count
> of
> >>>>>> frames that actually make it the the screen, but am interested in
> why we
> >>>>>> need both presented and painted? Wouldn't just a simple 'presented'
> (i.e.
> >>>>>> presented to the user) suffice?
> >>>>>>
> >>>>>>
> >>>>> We distinguish between "painted" and "presented" so we have a measure
> of
> >>>>> the latency in our rendering pipeline. It's more for our benefit as
> browser
> >>>>> developers than for web developers.
> >>>>>
> >>>>
> >>>> Yeah, just to be clear, we don't necessarily think that everything in
> our
> >>>> stats API should be standardized. We should wait and see what authors
> >>>> actually use.
> >>>>
> >>>> Rob
> >>>> --
> >>>> "Now the Bereans were of more noble character than the Thessalonians,
> for
> >>>> they received the message with great eagerness and examined the
> Scriptures
> >>>> every day to see if what Paul said was true." [Acts 17:11]
> >>>>
> >>>
> >>>
> >
> >
>