W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: 'progress' events for media elements

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 14 Aug 2009 09:16:44 +0000 (UTC)
To: Simon Pieters <simonp@opera.com>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0908140910380.6420@hixie.dreamhostps.com>
On Fri, 7 Aug 2009, Simon Pieters wrote:
> The spec says to fire 'progress' events every 350ms while downloading 
> media data. If all media data is in cache, no 'progress' events will be 
> fired. However, the 'load' event is not fired until the resource 
> selection algorithm has finished, and the resource selection algorithm 
> includes decoding data, so it is not predictable how long it will take 
> until the 'load' event is fired.
> This makes it impossible to test that 'progress' events are fired at 
> all, since a browser could just claim that they have all media data 
> cached and are just spending time on decoding the video as part of the 
> resource selection algorithm.

So reset your cache and then do it. Or load a file you know isn't cached 
(e.g. give it a unique name each time). You can know when the server 
finished serving the file pretty easily; until then, the UA can't pretend 
it's caching. This doesn't seem hard to test, unless I'm missing 

> I would suggest that the spec require that one 'progress' event is fired 
> when all data is loaded, but not waiting for anything to be decoded. 
> This will make 'progress' testable and also make progress bars more 
> accurate.


Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 14 August 2009 09:17:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:49 UTC