[Bug 12399] <video> Expose statistics for media elements

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12399

--- Comment #18 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-10-12 02:22:00 UTC ---

(In reply to comment #17)
> The others all seem to have the same use case, essentially "determine the
> client's performance". It's not at all clear to me why one of these would be
> better than the other, or how they would be used differently.

One goal for determining the client's performance is indeed to use it for HTTP
adaptive streaming approaches. But that's not the only goal.

By being able to determine whether a client's performance sucks because their
network connection sucks, their decoding pipeline is slow, or their rendering
engine is  slow, you can better determine what changes to make: if it's the
rendering engine, you're better off providing a video in the resolution that is
appropriate for the viewer's screen and thus reduces load on the rendering
engine. If it's the decoding pipeline, you will need to instead switch to a
video that lightens the load on the decoding pipeline - maybe it needs to have
more iframes/keyframes. And if it's the network, well then you better reduce
your bitrate and go to a lower resolution.

All of those proposed metrics provide a better basis for reporting of quality
of delivery (e.g. if you are providing guarantees to your customers on the QoS
of video delivery), as well as for decision making for the HTTP adaptive
streaming approach, as well as for decision making on what types of encodings
to actually make available on your video servers.

Your example of two video providers having different strategies for how to
react to the information provided is one that the market will sort out. If you
are saying that we should provide a HTTP adaptive streaming solution natively
in the browser, I'd agree. But that doesn't imply that the metrics are not
necessary - they still are and introduction of a native HTTP adaptive streaming
solution is orthogonal to this issue (and should be dealt with separately from
this bug).

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 12 October 2011 02:22:09 UTC