Re: play() sometimes doesn't do anything now that load() is async

At 9:43  +0100 15/01/09, Philip Jägenstedt wrote:
>Another option would be to have a current state 
>and a pending state, like several media 
>frameworks do. The state enumeration could be 
>NONE, PAUSED, PLAYING and one could have two 
>state variables currentState and pendingState. 
>The NONE state would be needed for pendingState 
>when there isn't actually a state transition in 
>progress and as the initial value for 
>currentState before the resource has loaded and 
>paused/played. The paused attribute would of 
>course no longer be needed.
>
>Philip

I think this could also work (something in me 
nags that it's functionally equivalent).  I kinda 
like the requested/active dichotomy as (for 
example) the autoplay attribute is then the 
initial value of requested, and so on.  I also 
like both of these in that they reflect the truth 
in the states, as well as in events.

I guess when a stall happens, you go into paused 
with play 'pending', it's not quite so 
semantically clear (to me) I think.  But this is 
a nit.

>
>On Tue, 13 Jan 2009 21:57:05 +0100, Dave Singer <singer@apple.com> wrote:
>
>>
>>We suggested a while back that there should be two state booleans
>>play_requested
>>play_in_progress
>>
>>instead of the one today (which is "paused"), 
>>which I think would cover this case as well as:
>>* stalls in download or streaming, which today 
>>are only noticeable if you catch the 'waiting" 
>>event (there's no state change)
>>* streaming protocols, which always lag between 
>>request and play (in download, this only 
>>happens if you ask for play before the stack 
>>has got far enough down the loading path)
>>
>>clearly !play_requested && play_in_progress 
>>should never occur, but the other three 
>>conditions can.
>>
>>
>>
>>At 16:20  +0100 13/01/09, Simon Pieters wrote:
>>>This is related to http://www.w3.org/Bugs/Public/show_bug.cgi?id=6353
>>>
>>>
>>>Consider the following:
>>>
>>>   <video id=v><script>
>>>    v = document.getElementById('v');
>>>    v.src = 'test';
>>>    v.play();
>>>   </script>
>>>
>>>When the video start tag is parsed, load() is 
>>>implicitly invoked and when the method returns 
>>>(meaning scripts can potentially run before 
>>>the next steps in load() are run, AIUI) 
>>>networkState is NETWORK_LOADING.
>>>
>>>When setting the src attribute, load() will 
>>>not be implicitly invoked again because 
>>>networkState is not NETWORK_EMPTY.
>>>
>>>When play() is invoked, load() will still not 
>>>be implicitly invoked again because 
>>>networkState is not NETWORK_EMPTY.
>>>
>>>So the list of candidates will be empty and 
>>>nothing will play. This is not what one would 
>>>expect. (If you do an explicit load() before 
>>>play() it works as expected.)
>>>
>>>
>>>We haven't found a nice way to fix this, yet. 
>>>Maybe play() should be async and set a flag 
>>>that some step at the end of the load() 
>>>algorithm will look at and, if set, start to 
>>>play the resource, or something.
>>>
>>>--
>>>Simon Pieters
>>>Opera Software
>>
>>
>
>
>
>--
>Philip Jägenstedt
>Opera Software


-- 
David Singer
Multimedia Standards, Apple Inc.

Received on Friday, 16 January 2009 18:52:48 UTC