Re: [whatwg] HTML video and IE, Safari, Firefox, Chrome

On Wed, Nov 5, 2014 at 3:46 AM, Martin Hoernig <hoernig@in.tum.de> wrote:

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

I have a fix for that bug now. Thanks again.


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

Low-bandwidth tests are particularly interesting to test because browser
developers tend to operate in high-bandwidth environments so don't pay
enough attention to low-bandwidth environments :-).

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

Received on Tuesday, 4 November 2014 21:35:52 UTC