W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2011

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

From: <bugzilla@jessica.w3.org>
Date: Thu, 24 Nov 2011 21:44:46 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RTh66-0005l2-3F@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12399

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #30 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-11-24 21:44:39 UTC ---
(In reply to comment #24)
> Are you saying that there should be a specification on an HTMLMediaElement
> for it to stream adaptively automatically, by the browser making a
> determination at the network layer?

I'm saying there should be a network protocol that does this, yes. It wouldn't
be part of the HTMLMediaElement specification; the same technology would apply
in all streaming situations. Indeed such technology probably already exists.


> That sounds like it risks freezing adaptive
> technologies in time, although I do agree that it would be nice to have for the
> average developer!

I don't see why it would freeze anything in time.


> The advantage of exposing the necessary information to JS,
> on the other hand, is that developers can be more innovative about adaptive
> strategies if they have to be.

I don't see why browser vendors and server vendors can't innovate also.



Currently, the state of this bug is that there is one use case of those that
have been presented that seems like it would be best addressed via additions to
the JS API: the ability to collect aggregate data about the user population's
bandwidth availability to help a service optimise in general; this use case
argues for providing bytesReceived, downloadTime, and networkWaitTime
attributes. I intend to add this in the near future. The other use cases
presented either don't seem best handled by an API or do not seem to be handled
by the proposed metrics. I would recommend filing separate bugs for other use
cases, though, rather than having all metrics-related use cases dealt with in
one bug. I'm sure that if you ask the chairs they'd be happy to handle such
split-out bugs as LC1 also, if that matters.

-- 
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 Thursday, 24 November 2011 21:44:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 November 2011 21:44:53 GMT