[whatwg] Media elements statistics

[Steve Lacey]

On Thu, May 5, 2011 at 2:54 AM, Jeroen Wijering <jeroen at longtailvideo.com>wrote:

> Hey Steve,
>
> This looks great; would be a really useful set of data for video players /
> publishers. Since none of the metrics have a time component, developers can
> sample the data over the window / at the frequency they prefer.
>
> Would jitter be calculated over decodedFrames or
> decodedFrames+droppedFrames? In the first case, jitter is a more granular
> metric for measuring exact presentation performance. In the latter case,
> jitter can serve as a single metric for tracking processing power (simple!).
> In either case, it's fairly straightforward to calculate towards the other
> metric.
>

Actually, I would expect presentedFrames + droppedFrames would be used. This
implies all decoded frames that were supposed to be presented.


>
> Resetting the values when @src changes is a good idea. Changing @src is
> much used for advertising and playlist support (it works around iOS not
> supporting the play() call).
>
> Kind regards,
>
> Jeroen Wijering
>
>
>
> On May 3, 2011, at 12:15 AM, Steve Lacey wrote:
>
> > 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]
> > >>>>
> > >>>
> > >>>
> > >
> > >
> >
>
>