- From: Martin Hoernig <hoernig@in.tum.de>
- Date: Tue, 04 Nov 2014 15:46:27 +0100
- To: <whatwg@lists.whatwg.org>
- Cc: robert@ocallahan.org
Thank you Rob! > I'm not sure what this means: > >> Firefox fires the canplaythrough event after buffering is completed >> or >> halted instead of a bandwidth depending solution >> > Do you mean that even when the data is arriving at a very high rate, > we > don't fire canplaythrough until all the data is downloaded? Yep. > You might want to test canplaythrough a bit more carefully; your > tests > didn't find http://code.google.com/p/chromium/issues/detail?id=73609 > (canplaythrough is basically unimplemented in Chrome; Chrome fires it > immediately after canplay in all circumstances, which causes problems > for > other browsers). We have performed most of our tests in "high bandwidth" scenarios ("Since we know the network bit rate and the video bit rate, we can take the canplaythrough event as mandatory as well."). The only situation in which a difference exists is (4) reset, where playing has to be fired after canplay and right before canplaythrough. But, you are right, additional "low bandwidth" tests are a good addition. I'm thinking for example of a stall test ("The stall timeout is a user-agent defined length of time, which should be about three seconds.") Martin On 2014-11-03 22:54, Robert O'Callahan wrote: > Thanks for the testing! Please file bugs against browsers where you > feel > they're not following the spec. > > I'm not sure what this means: > >> Firefox fires the canplaythrough event after buffering is completed >> or >> halted instead of a bandwidth depending solution >> > Do you mean that even when the data is arriving at a very high rate, > we > don't fire canplaythrough until all the data is downloaded? > > You might want to test canplaythrough a bit more carefully; your > tests > didn't find http://code.google.com/p/chromium/issues/detail?id=73609 > (canplaythrough is basically unimplemented in Chrome; Chrome fires it > immediately after canplay in all circumstances, which causes problems > for > other browsers). > > Rob
Received on Tuesday, 4 November 2014 14:46:52 UTC