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 
something.


> 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.

Done.

-- 
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:43 GMT