[whatwg] HTMLMediaElement: static TimeRanges/ByteRanges, "potentially playing" definition

[Ian Hickson]

On Thu, 6 Nov 2008, Philip Jägenstedt wrote:
>
> More random issues related to HTMLMediaElement
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-buffered
> 
> "The buffered attribute must return a static normalized TimeRanges 
> object"
> 
> The phrasing for the other ranges attributes is similar, but what does 
> "static" mean in this context. I'm guessing that it means static in the 
> sense that the same object is returned each time. As a consequence you 
> can't keep a copy of an old ranges object to compare it with a new one 
> later. This is all very fine, I just want to verify that it's correct.

No, static means the opposite of live. A live object is one that updates 
in realtime; a static one never updates. I've clarified the spec by adding 
the word "new" in front of "static".


> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#potentially-playing
> 
> "A media element is said to be potentially playing when its paused 
> attribute is false, the readyState attribute is either HAVE_FUTURE_DATA 
> or HAVE_FUTURE_DATA, the element has not ended playback, playback has 
> not stopped due to errors, and the element has not paused for user 
> interaction."
> 
> There's a typo here with two HAVE_FUTURE_DATA.

Fixed. (Should have been HAVE_ENOUGH_DATA.)


> I'm not sure what the intention was, but it seems to me that readyState 
> shouldn't be involved here. Consider:
> 
> new Audio("foo.wav").play();
> 
> "Media elements that are potentially playing while not in a Document 
> must not play any video, but should play any audio component. Media 
> elements must not stop playing just because all references to them have 
> been removed..."
>
> Immediately after the above call has returned, the readyState of the 
> media element is HAVE_NOTHING unless the resource happened to be cached. 
> The definition of "potentially playing" must be such that this object 
> isn't immediately garbage collected.

There is no problem here. The requirement to do with garbage collection 
doesn't mention the "potentially playing" concept:

   Media elements must not stop playing just because all references to 
   them have been removed; only once a media element to which no 
   references exist has reached a point where no further audio remains to 
   be played for that element (e.g. because the element is paused or 
   because the end of the clip has been reached) may the element be 
   garbage collected.


The definition of "potentially playing" is used throughout with the 
assumption that data is available right then.



> Suggested definition:
> 
> "A media element is said to be potentially playing when its paused 
> attribute is false, the element has not ended playback, playback has not 
> stopped due to errors."
> 
> In other words, remove the readyState and "paused for user interaction" 
> stuff (surely a media element could potentially keep playing after such 
> user interaction, otherwise there would be no need to ask).

I don't understand what you mean about user interaction.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'