Re: [whatwg] Fullscreen events dispatched to elements
On 2/06/2012 11:19 a.m., Vincent Scheib wrote: IMHO Pointer Lock would be more convenient to use if events are sent to the target element as well, and not just the document. Is there a reason the Fullscreen specification doesn't dispatch events to the most relevant element? Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Because of this, the spec was then changed to dispatch fullscreenchange to the context element on entering fullscreen, and to the document on exit, but we found this inconsistent, since a listener has to listen to multiple nodes to receive both exit and enter events, so the spec was changed again to always dispatch fullscreenchange to the document. Regards, Chris P.
Re: [whatwg] fullscreenchange event should be delayed to after transition is complete
On 18/05/2012 1:02 a.m., Anne van Kesteren wrote: On Thu, May 17, 2012 at 8:06 AM, Chris Pearcecpea...@mozilla.com wrote: I think it would be best to simply make everything from Step 2 onwards of the requestFullscreen() algorithm spec asynchronous. So in the requestFullscreen specification, move Step 5 and Step 6 up to be inserted before Step 2. We should do the same with exitFullscreen(), i.e. move Step 6 and Step 7 of the exitFullscreen algorithm spec up to be inserted before Step 3. We should also specify that those state changes happen in synchronous sections, to keep the world sane. I have done that by putting the state changes on the same task that dispatches the event. http://dvcs.w3.org/hg/fullscreen/rev/73eda102ccb5 Thanks, Looks good, thanks! Chris P.
Re: [whatwg] fullscreenchange event should be delayed to after transition is complete
On 17/05/2012 3:37 a.m., Anne van Kesteren wrote: On Wed, May 16, 2012 at 2:33 AM, Chris Pearcecpea...@mozilla.com wrote: I think that the fullscreenchange even dispatch should be specified to be dispatched once the animation to transition to/from fullscreen has finished. So queuing the task was not enough? I guess that makes sense. As for how to best define this in the specification. Should I just create a list of objects the event is to be dispatched upon and then after the animation steps start queuing tasks to dispatch them on the objects in that list? Actually after thinking a bit more on this I've changed my mind and I don't think it's ok to leave the fullscreenElement stack and :fullscreen state changes synchronous while delaying the dispatch of fullscreenchange events. If fullscreenElement stack and :fullscreen state changes could be observed before the fullscreen transition/animation is complete, script won't see consistent behaviour across platforms, i.e. on some (but not all) platforms there will be a period of time that document.fullscreenElement is true but document.fullscreenElement doesn't take up the entire screen. I think it would be best to simply make everything from Step 2 onwards of the requestFullscreen() algorithm spec asynchronous. So in the requestFullscreen specification, move Step 5 and Step 6 up to be inserted before Step 2. We should do the same with exitFullscreen(), i.e. move Step 6 and Step 7 of the exitFullscreen algorithm spec up to be inserted before Step 3. We should also specify that those state changes happen in synchronous sections, to keep the world sane. Thanks, Chris Pearce.
[whatwg] fullscreenchange event should be delayed to after transition is complete
Hi, I think that the fullscreenchange even dispatch should be specified to be dispatched once the animation to transition to/from fullscreen has finished. The problem is that at least two of the platforms we're supporting have non-instantaneous transitions from windowed to fullscreen mode. So if we dispatch fullscreenchange events as specified during HTMLElement.requestFullscreen() then the fullscreenchange events can arrive before the transition animation has finished, so things like window.screenY and window.size.* haven't reached their stable fullscreen values. Our unit tests have been randomly failing because of this, so I'm sure this will cause problems with authors in the wild. I think having the state changes performed by HTMLElement.requestFullscreen() happen synchronously before the animation/transition to enter fullscreen completes (as specified currently) and having them undone before the animation to exit fullscreen completes (also as specified currently in exitFullscreen()) is probably OK, since these state changes maybe required for the transition/animation. It's only the dispatch of fullscreenchange I think we should change. Cheers, Chris Pearce.
[whatwg] Fullscreenchange event
Should we still dispatch the fullscreenchange event to the element which requested fullscreen if the element was removed from its document before the event was dispatched? What if the element was added to another document before the event could be dispatched? Should we dispatch to requester's original document in these cases? Or just not dispatch the event? We'll be exiting full-screen in this case anyway, since the element was removed from the doc. Or should we do something else? Regards, Chris Pearce.
Re: [whatwg] Fullscreen revision I
On 21/10/2011 4:10 a.m., Glenn Maynard wrote: The current spec doesn't seem to allow asking permission to fullscreen in advance, since the fullscreen element is set synchronously. This should be supported; there are a lot of potential problems with the ask-after model and it shouldn't be the only model supported. I agree, the spec should definitely allow this. We could make requestFullScreen()'s entire body run in a synchronous section, after any permission has been granted? On Thu, Oct 20, 2011 at 6:59 AM, Anne van Kesterenann...@opera.com wrote: * requestFullscreen() can no longer be invoked when already in element fullscreen How do you change the fullscreenElement from one element to another without exiting fullscreen first? That seems important. If you have the fullscreen element as a generic container (div), you can insert your desired fullscreen element as the only child of the actual fullscreen element to get the swap effect. This won't work cross origin, so would prevent (for example) embedded YouTube videos from going fullscreen. I'd prefer for requestFullscreen() while fullscreen to just swap the fullscreen element. However, if we do end up not having requestFullscreen() while fullscreen swap the fullscreen element, then we need to ensure document.fullscreenEnabled returns false while any document is fullscreen. Otherwise video controls won't know to hide their (non-functioning) fullscreen buttons while their document/parent/ancestor documents are fullscreen. Chris Pearce.
Re: [whatwg] Fullscreen Update
On 19/10/2011 5:40 p.m., Anne van Kesteren wrote: 1) How much should UI-based and API-based fullscreen interact? To me it seems nice if pressing F11 would also give you fullscreenchange events and that Document.fullscreen would yield true. These modes cover different cases. F11 fullscreen mode is when the user wants to hide their browser user interface, but otherwise doesn't want to affect presentation. Whereas the fullscreen API is to allow sites to make a specific element the fullscreen element. 2) Chris brought forward the case of nesting. You have a fullscreen presentation (lets assume API-based activated for now) and in that presentation there's some video that the presenter wants to display fullscreen (lets assume the video player is a custom widget with API-based fullscreen activation for now). Once the presenter exits displaying the video fullscreen, the presentation should still be fullscreen. Initially this was brought up with the video being hosted in a separate descendant document, but the video could be in the same document as well. In this presentation-video case, if the video is in the same document or in a same-origin subdocument, the page can script switching full-screen between the main full-screen element and the video element and vice versa (provided Element.requestFullScreen() while in fullscreen switches the fullscreen element). So custom controls on the video element could be implemented to solve this problem in the single document and in the non-cross origin multi-document case. In the cross origin multi-document case, if document.exitFullScreen() causes all documents to exit full-screen (not just the target document and its descendents) it would also be pretty easy for the parent document to listen for the fullscreenchange event when the video exited, the and show its button for the main document to re-enter fullscreen. It would be a 2-click process to fullscreen change from the video back to the main document, but no big drama really. roc suggested a model that works when you have separate documents and it could be made to work for the single document case too, as long as the level of nesting remains is no larger than required for the presentation scenario mentioned above. We could go with Roc's suggestion and provided requestFullScreen() switches fullscreen mode we'd be ok, but I think that would complicate the API a bit much. Seems better to keep it simple. Is that an acceptable limitation? Alternatively we could postpone the nested fullscreen scenario for now (i.e. make requestFullscreen fail if already fullscreen). I think we should: 1. Make Element.requestFullScreen() switch the fullscreen element (so we can handle the single document and same-origin documents cases) when called while any document is in fullscreen mode, and 2. make document.exitFullScreen() exit all documents from fullscreen. It keeps the API simple, and provided we fire fullscreenchange events whenever a documents fullscreen attribute changes, pages can detect this and provide buttons to restore the user to their desired fullscreen state. Chris Pearce.
Re: [whatwg] Entering fullscreen when already in fullscreen mode [was: Fullscreen]
On 18/10/2011 12:52 p.m., Darin Fisher wrote: On Mon, Oct 17, 2011 at 4:17 PM, Anne van Kesterenann...@opera.com wrote: On Tue, 18 Oct 2011 07:55:33 +0900, Darin Fisherda...@chromium.org wrote: Thanks for working on this spec! I have more questions, but I'll just start with one. If enterFullscreen() is called when the browsing context is already being displayed fullscreen, what should happen? (It looks like Safari 5.1 ignores the second call to webkitRequestFullScreen.) Chris is suggesting this should move the current fullscreen element around. A use case I can think of is where you have YouTube fullscreen while browsing through videos and then want to highlight a particular video. It does however generate quite a bit of complexity in edge cases where you have a tree of Documents. In that case you need to find the common ancestor of the current fullscreen element and the new fullscreen element, make changes to the Documents on that path from current to new, and dispatch events. This seems like it might be overly complicated. I could be mistaken, but I don't think YouTube needs this. Yeah, I suggest that if requestFullScreen() is called when another element is already the fullscreen element, the new requestee should become the fullscreen element. A use case for this is: a fullscreen page with a cross-domain video and the video wants to go fullscreen. For example if a slide-deck/PowerPoint clone webapp goes fullscreen and wants to make an embedded YouTube video fullscreen. The easiest way to do this is load the YouTube video in an embedded iframe and (assuming you're using their HTML5 player and that uses the fullscreen API) click on the fullscreen button in its controls UI. Regards, Chris Pearce.
Re: [whatwg] Fullscreen
On 15/10/2011 5:27 p.m., Anne van Kesteren wrote: I wrote up a draft: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html Thanks for writing this up. Comments: 1. We should define what happens when the full-screen element is removed from a document. Roc and I thought it would be best to *not* reset the full-screen elements, :fullscreen, and :fullscreen-ancestor styles in ancestor documents, so that the current document's frame remains in full-screen mode. i.e. removing the full-screen element should result in the same state as if you requested full-screen on said element when it was not in a document. The fullscreen state needs to be reset in descendent documents though. 2. We should define what happens when the full-screen element is removed from a document and inserted into another document. I think we should reset the fullscreen element in the old fullscreen element's owner's doc, and reset all fullscreen state (flag and pseudo classes) in all the old owner document's descendent documents, but not in its ancestor documents. So this should be equivalent to requesting full-screen on an element, and releasing all references to that element (though arguably Document.fullscreenElement would keep that element alive in that case...). 3. Step 3.6 of the transition to fullscreen algorithm fires a fullscreenchange event to the document which requests fullscreen, regardless of whether it was already in fullscreen mode or not, and regardless of whether the fullscreen element changed. If a doc is already in fullscreen state, requesting fullscreen again may change the fullscreen element, but won't change the document.fullscreen flag. My thoughts are we should dispatch fullscreenchange in any document in the doc tree whenever document.fullscreen changes, or whenever the document.fullscreenElement changes (so that script knows if the request to change the fullscreen element was granted). 4. The transition to fullscreen algorithm needs to reset the full-screen state on all documents in the doctree, otherwise requesting full-screen on a node in a sibling/cousin document to the current fullscreen element's document will end up with inconsistent state. Also if a request for full-screen originates in a sibling/cousin document to the current full-screen element's document, resetting the fullscreen state in the documents in the sibling/cousin branch should cause fullscreenchange events to be dispatched to those documents. The order in which fullscreenchange events are dispatched should be defined (i.e. do the fullscreenchange events for documents exiting fullscreen run before or after the fullscreenchange events for documents entering fullscreen?). 5. The transition from fullscreen algorithm only fires the fullscreenchange event at the document which requests the fullscreen exit, not all the documents whose fullscreen state changes upon the exit of fullscreen (ancestor and descendent documents). 6. We should dispatch a fullscreendenied event if the request for fullscreen is denied. Feedback from authors is that it is critical to know whether a request for fullscreen has been denied, so that they can fallback to other mechanisms. Mozilla's original proposal intentionally didn't include this because we thought we'd require permission to enter fullscreen. We've since changed to an ask forgiveness model, where the request to go fullscreen can be made synchronously, so the previous criticisms against this event don't apply. Without this event, if there is an animation for enter full screen, there's no way to distinguish between entered full-screen but running animation and the fullscreen denied case, other than by setting a timeout of appropriate length, which is hacky. 7. I prefer requestFullScreen() for the same reason Olli gave. Especially if we make Element.requestFullScreen() asynchronous; enterFullScreen() really does imply synchronous action. I prefer exitFullscreen() to cancelFullScreen(). Regards, Chris Pearce. Defining when exactly the fullscreen enabled flag is set for Document objects I will leave up to HTML. As well as defining the allowfullscreen attribute. Presumably it should be set for Document objects associated with the top-level browsing context and descendant browsing context as long as their browsing context container has the aforementioned attribute set. If we want to transition from fullscreen when navigating, HTML can define that as well, neatly integrated in the navigation section. The Model section of the Fullscreen specification has an appropriate hook. I have not added the key restrictions given earlier emails. Unfortunately there was not that much feedback on them, but maybe this draft will help on that front! I went with fullscreen rather than full screen as that seemed cleaner and easier to type. I
Re: [whatwg] Fullscreen
On 15/10/2011 5:27 p.m., Anne van Kesteren wrote: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html Defining when exactly the fullscreen enabled flag is set for Document objects I will leave up to HTML. As well as defining the allowfullscreen attribute. Presumably it should be set for Document objects associated with the top-level browsing context and descendant browsing context as long as their browsing context container has the aforementioned attribute set. By this do you mean the fullscreen enabled flag should be defined elsewhere in the HTML spec? Can we at least link to is to that it's easy for implementors to find? Ditto for allowfullscreen. Both of these things are important, we should have references to them at least. Or include them in this spec, with a note to move them into their new homes once we agree on the spec. Regards, Chris Pearce.
Re: [whatwg] Fullscreen
On 17/10/2011 5:31 a.m., João Eiras wrote:
a)
The fullscreen media query is missing (I seriously suggest supporting it)
# @media all and (full-screen) { /* ... */ }
Does it make sense to have on/off as in the Mozilla proposal ? e.g.
and (full-screen:on/ff) ?
We removed this from our proposal, since the view-mode media query has a
fullscreen mode. However the view-mode media query does not distinguish
between browser fullscreen mode (pressing F11 in Firefox and the same in
Opera) and DOM full-screen mode, where a particular element is
fullscreen. You need Document.fullscreen for that. Perhaps this is
indeed an argument for including a separate media query for the
fullscreen API's fullscreen mode.
b)
I think that :fullscreen should not apply if there is no fullscreen
element.
When is there no fullscreen element? When the fullscreen element isn't
in the document? Without the :fullscreen rule, containing frames won't
have the styles applied that enables iframe contents to appear fullscreen.
c)
There should be a security note for
request/cancel/enter/exitFullscreen that the user agent might choose
to dishonor the calls to these methods, like if fullscreeen is not
supported, or the browsing context is child of another one that does
not allow fullscreen, or the call to these methods is not from a user
initiated action.
This is implied by aborting when any ancestor browsing context's
document doesn't have the fullscreen enabled flag set.
I would remark that user agents should ignore calls to those methods
if not coming from a user initiated action (kind like the way pop ups
are handled). So, the click to go fullscreen button use case works,
but a webpage going fullscren during load and then spoof the browser
UI would not.
I agree, in fact we're doing this already in our implementation. Do we
need to add this to the spec as a recommendation?
d)
Perhaps a non normative note just to explain that the flags do would
be nice for authors.
I agree, this would make the spec more approachable.
e)
Given their use cases, the flag fullscreenEnabled would be better
called fullscreenAllowed, and the fullscreen flag would be better
called fullscreenEnabled.
fullscreenEnabled is better, as fullscreenAllowed implies that the
request is going to be granted, whereas fullscreenEnabled doesn't imply
that. For example, requests for fullscreen would still be denied if not
coming from a user-generated event handler even if
document.fullscreenEnabled returned true.
Regards,
Chris Pearce.
Re: [whatwg] [fullscreen] cancelFullScreen()
On 13/10/2011 5:23 p.m., Anne van Kesteren wrote: On Thu, 13 Oct 2011 11:26:20 +0900, Chris Pearce cpea...@mozilla.com wrote: On 12/10/2011 10:35 p.m., Anne van Kesteren wrote: Is cancelFullScreen() synchronous or should it queue a task? Synchronous, so that Document.fullScreen immediately reflects the state change? Why would it need to be asynchronous? Is the event dispatched synchronously as well then? I was thinking that maybe you want to trigger an animation here of some kind. Though I suppose that could be done synchronously as well. It would also be nice if the page can keep rendering and running JS while the animation is running. Asynchronous dispatch would allow that. Also ideally you'd want to dispatch the event after the animation is complete, so that the size of the document's view port is stable; if you dispatched the event before your animation is complete, the full-screen element's dimensions may not have reached the viewport size, and content might get confused, or at worst inconvenienced. If you invoke cancelFullScreen() on a Document of a parent or child browsing context from the browsing context in whose Document requestFullScreen() was invoked it should presumably still work, no? The parent of a Document which is in full-screen will also be in full-screen mode. So if cancelFullScreen() is invoked in the parent Document, it should exit full-screen in the parent. I interpreted the spec to mean if one full-screen document cancels full-screen, all documents in the tree exit full-screen mode. I too have been wondering if we should honour calls to cancelFullScreen() in a non-full-screen child Document of the Document which requested full-screen. It seems to me that being fullscreen is a property of the top-level browsing context. All that is potentially associated with a document is the fullscreen element. If you have a document A with two sub-documents B and C, it does not make much sense to me that if you go fullscreen from B, C would not report as being fullscreen. I mean sure, there is no fullscreen element but it is definitely rendered fullscreen. As the proposed spec is written so far, I think Document.fullscreen is meant to convey that: 1. If the document's full-screen element in the document, the full-screen element is rendered at viewport dimensions with browser UI hidden, or 2. if the document's full-screen element is not in the document, the document is rendered at viewport dimensions. The key is the :full-screen psuedo-class, for which the suggested UA style rules enables the full-screen element appear to break out of containing frames and be rendered at the view-port size (assuming the browser window is made viewport dimensions by the UA). The :full-screen pseudo-class is defined to also apply to an iframe, object or embed element whose child browsing context's Document is in the full-screen state. So if a child document in an iframe doesn't have its full-screen element in the document, unless the document reports being in full-screen state the :full-screen pseudo-class won't apply to that document, and that document thus won't be rendered at viewport dimensions. If we specified a Document.currentFullScreenElement attribute, then Document.fullScreen would be equivalent to (Document.currentFullScreenElement != null). Regards, Chris Pearce.
Re: [whatwg] [fullscreen] cancelFullScreen()
On 12/10/2011 10:35 p.m., Anne van Kesteren wrote: Is cancelFullScreen() synchronous or should it queue a task? Synchronous, so that Document.fullScreen immediately reflects the state change? Why would it need to be asynchronous? If you invoke cancelFullScreen() on a Document of a parent or child browsing context from the browsing context in whose Document requestFullScreen() was invoked it should presumably still work, no? The parent of a Document which is in full-screen will also be in full-screen mode. So if cancelFullScreen() is invoked in the parent Document, it should exit full-screen in the parent. I interpreted the spec to mean if one full-screen document cancels full-screen, all documents in the tree exit full-screen mode. I too have been wondering if we should honour calls to cancelFullScreen() in a non-full-screen child Document of the Document which requested full-screen. Presumably also if the Document has been navigated away from. FWIW we're planing to exit full-screen when a full-screen document is navigated. Probably a good idea to spec this so it's consistently implemented. Chris Pearce.
Re: [whatwg] Fullscreen
I've been working on implementing this spec in Firefox. We ended up diverging from it slightly, I've added a few notes in the proposed spec as to our changes. I'd like to see this turned into an official spec, and am happy to provide feedback etc. Thanks! Chris Pearce. On 4/10/2011 5:52 a.m., Tantek Çelik wrote: Hi Anne, Fullscreen is currently #2 in my queue after getting another LCWD of CSS3-UI out. I've been incrementally editing on the wiki page you mentioned until it's my primary focus. Feel free to make edits to the wiki if there are particular aspects you want to improve or raise as issues. Either way, though I sympathize with the desire to get rid of prefixes, there are other aspects (besides spec (re)formatting/massaging from wiki to W3C WD) that need more help if prefix-removal is your primary goal, e.g. we don't have a Fullscreen test suite nor even someone to curate/coordinate the creation of one - is that something you'd be available to help with? Thanks, Tantek --Original Message-- From: Anne van Kesteren Sender: whatwg-boun...@lists.whatwg.org To: WHATWG Subject: [whatwg] Fullscreen Sent: Oct 3, 2011 01:17 Is anyone working on turning https://wiki.mozilla.org/Gecko:FullScreenAPI into a standard? It would be nice to get rid of the prefixes. I'm willing to work on it or help someone out if work is already going on. (I know I offered doing this last year, but then some DOM4 things came up and I left for three months. It should be better now.)
Re: [whatwg] video preload implementation feedback
On 19/08/2011 12:01 a.m., Philip Jägenstedt wrote: I think that too much variation in how preload is implemented is also likely to give compat problems. In http://www.w3.org/Bugs/Public/show_bug.cgi?id=12596#c7 I have an example of what might break when pages inevitably assume that preload=none causes the loadedmetadata event to not be fired. This seems a valid reason to change from should to must for preload. I agree. If you only allow the internal state to increase, don't you need to reset it at some point as well? Or is it impossible in your implementation to use preload=auto on one load and preload=metadata on the next due to this? Oops, that is impossible in our implementation. That's a bug! I'll fix that, thanks for pointing this out. I agree that it we should specify when the preload internal state is updated to prevent this bug in other implementations. Resetting the internal preload state inside the synchronous section of the resource selection algorithm as you suggest is sensible. I agree with you! Cheers, Chris Pearce.
Re: [whatwg] video preload implementation feedback
I implemented preload support in Firefox.
On 18/08/2011 3:44 a.m., Philip Jägenstedt wrote:
I'd very much like to see feedback from other implementors. Are you
happy with treating autoplay and preload as just hints as in [4] or
do you think that we should specify them in greater detail?
I think autoplay should not be treated as a hint, else it's can't be
relied upon to work, and thus would be completely useless.
Preload is a less critical; if it's not supported users will just end up
loading more data, which isn't too bad. Clients that care more about
bandwidth will probably be more likely to support it.
== Dynamically changing preload ==
It makes no sense for a script to change preload=auto to
preload=none. Going from preload=auto to preload=metadata isn't
nonsensical, but supporting it would allow authors to toggle it
continuously to work around buggy buffering behavior. I'd much rather
that buffering problems be fixed in the browser, so I don't want to
support this. Consequently, we only allow the internal preload states
to increase, not decrease. I understand that Mozilla has done the
same. Unless there are strong reasons not do, I think this should be
spec'd.
I agree.
== Resetting internal preload state ==
Due to the above, it's necessary to reset the internal preload state
at some point. Otherwise, a script like this wouldn't work:
function setSource(url) {
var v = document.querySelector('video');
v.src = url;
v.preload = none;
v.onplay = function() { v.preload = autoplay; };
Did you mean |v.preload = auto;| here instead? or |v.autoplay =
true;|? It seems in this case the onplay handler would only happen if
the user pressed play on the controls or from script, so the preload
action be promoted to auto anyway since the resource is playing. I guess
that's what you're getting at with your point about preload internal
state promotion?
}
If a previous resource was playing and preload was set to autoplay
by script, then we still want preload=none to apply to the new
resource. To solve this, we are resetting the internal preload state
as part of the resource selection algorithm, right before step 5 to
fire the loadstart event. There are various other places one could do
this, but we think it is important to do it in the async section so
that the order of setting .src and .preload does not matter.
Currently we update the internal preload action whenever the value of
the preload state changes, and we check it's not preload=none before
kicking off a new resource load (resource fetch algorithm step 2) and we
check it again when we reach loadedmetadata and suspend the load if it's
preload=metadata.
I think the preload=metadata case is implied by the spec, but having it
explicitly stated wouldn't hurt.
== video preload=none ==
It's not possible to specify exactly how much preload=metadata and
preload=auto buffers and when, but this is possible for
preload=none. This is what we do:
After step 1 of the source selection algorithm, if preload==none,
set networkState to IDLE, fire a suspend event and set the
delaying-the-load-event flag to false.
This is actually specified now in step 2 of the resource fetch algorithm
(this must have been added after we implemented @preload).
Doing this at step 1 of the resource selection algorithm means that if
you're loading from child source elements, and none of them have a
supported type, then you won't report the error until something calls
play() or load() explicitly.
Regards,
Chris Pearce.
Re: [whatwg] Media elements statistics
On 3/05/2011 10:15 a.m., Steve Lacey wrote: I've updated the wiki with a proposal... http://wiki.whatwg.org/wiki/Video_Metrics#Proposal This proposal looks good to us at Mozilla. Thanks for putting this together! Chris Pearce.
Re: [whatwg] Media elements statistics
On 1/04/2011 12:22 p.m., Steve Lacey wrote: Chris - in the mozilla stats, I agree on the need for a frame count of frames that actually make it the the screen, but am interested in why we need both presented and painted? Wouldn't just a simple 'presented' (i.e. presented to the user) suffice? We distinguish between painted and presented so we have a measure of the latency in our rendering pipeline. It's more for our benefit as browser developers than for web developers. Chris
Re: [whatwg] Media elements statistics
Note that the Mozilla implementation I proposed has had a counter proposal by another mozilla developer and is being developed further. See: https://bugzilla.mozilla.org/show_bug.cgi?id=580531 Thanks. Taking a further look at that. Reviving thread... I have an initial patch in webkit (http://trac.webkit.org/changeset/77394) and the chromium work is underway - I wonder what might be a good approach to drive the apis closer together towards a real spec that everyone is happy with? There seems to be a lot of general agreement here (at least in principal :-) that this is needed. We'll be doing a bunch of experimentation once this has landed in chromium. I've landed support for some Mozilla-specific video decoding/painting statistics in Firefox trunk (tracking in Mozilla bug 580531 mentioned above), it should ship in Firefox 5 in a few months. For a few details, see: http://blog.pearce.org.nz/2011/03/html5-video-painting-performance.html Regards, Chris Pearce.
Re: [whatwg] Media elements statistics
Hi Steve et al, I'm working on a similar feature for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=580531 Though we're implementing this more as a way of measuring the performance of our decoding and rendering pipeline, rather than providing playback/decode-rate stats. unsigned long audioBytesDecoded; unsigned long videoBytesDecoded; Out of curiosity, why do you want this feature? What does it give you that @buffered and @currentTime does not? Raw bytes reasonable to me, the feedback on the FOMS list regarding playback statistics showed webdevs liked that idea. How would you handle frames dropped by the decoder in order to prevent it falling behind? Would you count their bytes as decoded? Another open question: what are sensible values if the information is not available. Zero seems wrong. Return Number.NaN? Or provide some kind of ability to query whether there is audio and video? Regards, Chris P. On 28/01/2011 12:22 p.m., Steve Lacey wrote: Hi, I'd like the raise this thread again: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027929.html (I wasn't on the list at that point, so starting a new thread here and cc'ing a couple of folks from it...) I work on the media stack in Chromium and we'd like to implement something pretty similar. So I'm looking for comments... The original suggestion for the video element looks good: [Video Element] // Frames decoded and available for playback. unsigned long decodedFrames; // Frames dropped during playback for performance reasons. unsigned long droppedFrames; But for the media element I'd like to propose raw bytes instead of a rate as this allows the developer to construct their own rates (if needed) based on whatever window they want. It would also be useful to separate audio from video. A suggestion might be: [Media Element] unsigned long audioBytesDecoded; unsigned long videoBytesDecoded; Though this seems a little strange to have these specifically on the media element as they reference particular media types. Another idea would be to move these to the video element and also add audioBytesDecoded to the audio element. Another open question: what are sensible values if the information is not available. Zero seems wrong. Thoughts? Cheers! Steve
Re: [whatwg] Limiting the amount of downloaded but not watched video
On 24/01/2011 12:32 a.m., Philip Jägenstedt wrote: Hmm. To get this effect without preload=buffer, you could set preload=auto, watch the buffered attribute to see when some data is actually downloaded, then set it to preload=metadata to stop autoloading. That's a minor hack, and would need to watch out for browsers that don't autoload on preload=auto, but it's probably good enough for the above cases. It'd only work if runtime changes to preload are applied, which would also be needed for scripts to implement preload=auto only when paused. I intend to make that impossible by only allowing scripts to increase the effective buffering strategy FWIW, this is what we've implemented in Firefox; we only allow changes to the preload attribute after a load has started to increase the level of buffering. Chris P.
Re: [whatwg] Limiting the amount of downloaded but not watched video
On 22/01/2011 11:57 p.m., Philip Jägenstedt wrote: I agree that there must exist a buffering strategy between strategy=metadata and strategy=auto, but it's not clear that this must be exposed as a preload state. The only difference between preload=metadata and preload=state3 would be that preload=state3 would expect the user to start playing soon and start buffering in anticipation of that. Firefox has supported preload=metadata (and earlier, lack of autobuffer attribute) for a long time. Is it a problem in Firefox that playback is slow to start because too little was buffered before suspending? Firefox's media decoder goes into its internal buffering mode when you play a preload=metadata video. Playback will actually start when one of the following is true: 30 seconds has passed, 30 seconds of the video data is buffered (as estimated using the average bitrate, if known), or the media is in readyState HAVE_ENOUGH_DATA. We could probably be a bit less conservative, and start playback earlier. Chris P.
Re: [whatwg] HTML5 video: frame accuracy / SMPTE
On 22/01/2011 7:31 a.m., Gregory Maxwell wrote: It's usually the decoding, not the file access that kill you. Firefox seeking on low resolution clips is very snappy index or not. But try a 1080p clip encoded with a 10 second maximum keyframe interval... This is true. If you want fast frame accurate seeking, particularly over the internet, it's best to not encode with such a large keyframe interval. This is a problem caused by a webdev's inappropriate encoding choice, not by a bad API choice. If seeking is slow when you encode with a large keyframe interval, don't encode with a large keyframe interval! What if the browser's controls by default seeked to the previous keyframe, if the user had enough precision in the controls and wanted to seek to 9 seconds after a keyframe (1 second before the subsequent keyframe), then they could not. On 22/01/2011 10:04 a.m., Philip Jägenstedt wrote: Since, as you say, the behavior is currently inconsistent, there is still time to agree on something that makes sense and have everyone implement that. I think the best default is keyframe seeking and haven't seen any strong arguments for accurate seeking as the default yet. I disagree. The default should be exact, with approximate seeking to the nearest keyframe. When you call video.seek(X.xx), you've specified an exact time, and would likely expect an exact time, so the media should seek to that exact time. Another reason to make exact the default, is that if the media is seekable, it can always be seeked exactly, whereas media without an index may not be able to be seeked approximately. We've already implemented frame accurate seeking in Firefox. I'd be happy for us to implement approximate seeking, it would be useful for seeking into areas of the media which are unbuffered. We may change our controls to use approximate seeking when seeking into unbuffered areas, but we wouldn't use approximate seeking when seeking into buffered areas. Videos are usually short enough that you want accuracy higher than keyframe granularity when seeking using the default controls (at least in buffered areas). On 22/01/2011 10:50 a.m., Roger Hågensen wrote: Hmm. I think the default (nothing) should be synonymous with best-effort (or best) and leave it to the browser/os/codec/format/etc. as to what best effort actually is. We should specify the default, otherwise by default webdevs will always need to specify their seek accuracy level. On 22/01/2011 11:25 a.m., Silvia Pfeiffer wrote: * KEYFRAME is keyframe-accurate seeking, so to the previous keyframe What does this mean when a seekable stream doesn't have interior keyframes? Should the client always seek to the beginning? Why is this valuable over a fast option? Where no keyframes are available, this seek option simply doesn't do anything, since obviously there are not keyframes. The point is that where this concept exists and people want to take advantage of it, this seek should be possible. Some media format's index for audio as well, so where there are no keyframes, you could seek to the nearest indexed point from the index. Or (probably a better idea) have some way of reporting whether keyframe level approximate seeking is available. Exact seeking is always available if the media is seekable (so it makes a good default...), and script can determine whether faster but approximate seeking is available and can choose to use it. On 22/01/2011 1:47 p.m., Roger Hågensen wrote: To me only TIME makes sense right now as HH:II:SS.MS (hours:minutes:seconds.milliseconds) and FRAME if 1ms for rare cases where video is more than 1000fps. I don't think there's much (or any?) demand for seeking in anything other than seconds? So maybe just let the flag be default and nothing else, but as mentioned previously, leave it an enum just in case for the future (I'm thinking possible future timing standards that might appear, though it's hard to beat doubles really). We can always add it later if demand arises. HTML is a living standard right? ;) On 22/01/2011 11:05 a.m., Gregory Maxwell wrote: The potentially high cost of an exact seek is the primary reason why I wouldn't want to make the default behavior mandate exact, but exact still needs to be available. Seeks would only be slow in the case where keyframes were infrequent. In many cases a snap to keyframe seek would be inaccurate enough to be annoying with infrequent keyframes. I can only imagine the bugs we'll get filed if we make it the default! Chris Pearce.
Re: [whatwg] HTML5 video: frame accuracy / SMPTE
On 22/01/2011 3:23 p.m., Gregory Maxwell wrote: On Fri, Jan 21, 2011 at 8:19 PM, Chris Pearcech...@pearce.org.nz wrote: On 22/01/2011 7:31 a.m., Gregory Maxwell wrote: It's usually the decoding, not the file access that kill you. Firefox seeking on low resolution clips is very snappy index or not. But try a 1080p clip encoded with a 10 second maximum keyframe interval... This is true. If you want fast frame accurate seeking, particularly over the internet, it's best to not encode with such a large keyframe interval. This is a problem caused by a webdev's inappropriate encoding choice, not by a bad API choice. One second of decoding time is already a fairly slow seek. Surely you aren't suggesting that people should be using one-to-sub-second keyframe intervals? Most Ogg media out there has a keyframe interval of 2 seconds, which seems reasonable to me. With *indexed* Ogg media, when seeking into unbuffered ranges, the seek usually completes within 2-4 seconds. This is comparable speed to seeking into unbuffered media on YouTube's Flash video. Were I live in the world it is anyway. People don't seek very often when playing media. It doesn't seem unreasonable to wait *a few* seconds for a seek into an unbuffered range to complete. With non-indexed Ogg media where you must perform a bisection search over HTTP, performance will obviously be slower, but that's why we developed the Ogg index in the first place. Perhaps your comparing Firefox's performance to Cortado on non-indexed media? [snip] Seeks would only be slow in the case where keyframes were infrequent. In many cases a snap to keyframe seek would be inaccurate enough to be annoying with infrequent keyframes. I can only imagine the bugs we'll get filed if we make it the default! Inaccurate seeking is pretty much universal in media-player applications. ::shrugs:: I haven't conducted an exhaustive survey across systems, but on my desktop firefox is the only tool that does frame accurate seeking by default. Totem doesn't, VLC doesn't, Mplayer doesn't. The seek precision in those players you list is limited by the input mechanism; their GUI seek bars. Whereas we're (re)specifying an API which accepts a more precise floating point number. There's nothing stopping the various browsers using the approximate seek mechanism in their controls. Chris Pearce.
Re: [whatwg] Limiting the amount of downloaded but not watched video
On 18/01/2011 8:05 a.m., Zachary Ozer wrote: What no one has mentioned so far is that the real issue isn't the network utilization or the memory capacity of the devices, it's bandwidth cost. The big issue for publishers is that they're incurring higher costs when using thevideo tag, which is a disincentive for adoption. I assume you're comparing to the bandwidth usage of flash? Does flash allow developers to control how the media is downloaded on the client? What mechanisms does it provide? Maybe we can do something similar? Can this not be implemented on the server side? If you know the media has an average playback rate of X KB/s, can the server reliably throttle its transmission at 1.5X? I agree with Boris' comment though; in the majority of my usage, I'm waiting on the download, not the other way around! Chris Pearce.
Re: [whatwg] Limiting the amount of downloaded but not watched video
On 18/01/2011 4:59 p.m., Roger Hågensen wrote: Unbuffering: It may sound odd but in low storage space situations, it may be necessary to unbuffer what has been played. Is this supported at all currently? Firefox caches media data locally on disk, and will evict data which is unlikely to be needed in future when its cache gets full. There's no way for users to force eviction, except by manually reducing the size of the media cache by changing a pref. Skipping: A lot of times I hit play, the movie buffers, fine. Then I skip to the middle maybe, but I can't since it hasn't buffered to that point yet. I'm forced to wait for it to buffer up to that point before I can skip there. This sounds like either the server you're serving your media from isn't configured to enable seeking in your media (usually because it's serving content gzipped, or because it doesn't correctly support or advertise that it supports HTTP1.1 byte range requests) or whatever browser you're using hasn't implemented seeking using HTTP1.1 byte ranges yet. Chris Pearce.
Re: [whatwg] HTML5 video: frame accuracy / SMPTE
On 12/01/2011 10:58 a.m., Rob Coenen wrote: Intresting- I didn't know that variable frame-rate videos were actually being used for HTML5 video. WebM videos have no fixed frame rate. This format is supported in Firefox 4, Chrome, and Opera. Chris P.
Re: [whatwg] HTML5 video: frame accuracy / SMPTE
On 12/01/2011 11:20 a.m., Rob Coenen wrote: I can imagine there are 'virtual' frames, where say frame 1 to 10 is actually the same frame and internally encoded as frame 1 with a duration of 10 frames? Yes, as I understand it, this is a legal encoding. Even then I'd like the 'virtual' FPS of the WebM file exposed to the webbrowser- similar to how my other utilities report a FPS. If the 'virtual' FPS value isn't provided by the container, and given that the frame durations could potentially have any distribution and that the media may not be fully downloaded, how can this be effectively calculated? This way one could build web-tools in HTML5 that allow to access each individual frame and do other things than simply playing back the movie in a linear fashion from beginning to end. I we've discussed this sort of thing before, and roughly agreed that we'd look at processing frame data in a per-frame callback which runs in a web worker thread, if we could agree on some use cases which couldn't be achieved using SVG filters. That discussion was in this thread: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23533.html Chris P. -Rob On Tue, Jan 11, 2011 at 10:05 PM, Chris Pearcech...@pearce.org.nz wrote: On 12/01/2011 10:58 a.m., Rob Coenen wrote: Intresting- I didn't know that variable frame-rate videos were actually being used for HTML5 video. WebM videos have no fixed frame rate. This format is supported in Firefox 4, Chrome, and Opera. Chris P.
Re: [whatwg] HTML5 video: frame accuracy / SMPTE
On 12/01/2011 1:37 p.m., Dirk-Willem van Gulik wrote: On 11 Jan 2011, at 23:00, Chris Pearce wrote: Even then I'd like the 'virtual' FPS of the WebM file exposed to the webbrowser- similar to how my other utilities report a FPS. If the 'virtual' FPS value isn't provided by the container, and given that the frame durations could potentially have any distribution and that the media may not be fully downloaded, how can this be effectively calculated? I cannot think of a format where this would in fact be the case - but for a few arcane ones like an animated push gif without a loop. WebM can be variable frame rate. At best the WebM container specification [http://www.webmproject.org/code/specs/container/#track] lists the FrameRate block as Informational only, which presumably means the value stored in the container can't be trusted. Chris P.
Re: [whatwg] HTML5 video: frame accuracy / SMPTE
On 12/01/2011 2:22 p.m., Dirk-Willem van Gulik wrote: On 12 Jan 2011, at 01:17, Chris Pearce wrote: I cannot think of a format where this would in fact be the case - but for a few arcane ones like an animated push gif without a loop. WebM can be variable frame rate. At best the WebM container specification [http://www.webmproject.org/code/specs/container/#track] lists the FrameRate block as Informational only, which presumably means the value stored in the container can't be trusted. Right - but is there a WebM decoder which is able to hand it off that way ? AFAIK they all use that value or select a default/measured rounded heuristic to solve flicker ? Firefox 4 doesn't use the frame rate stored in the container for WebM. Each frame is stored with its presentation time, and we request repaints as each frame fall due for painting. The prevention of flicker is handled by our graphics layer, video doesn't really participate in that, it just hands off frames downstream when they're due for painting. We have plans to schedule video frame painting more preemptively in future, but I imagine we'd still use the presentation time encoded with each frame when we do that. Chris P.
Re: [whatwg] HTML5 video: frame accuracy / SMPTE
As Eric pointed out, the spec specifies that you can seek to a specific time, and therefore a specific frame. Firefox seeks video to the frame which contains the seek target time in Ogg and WebM videos FWIW, and begins audio playback from, and syncs the clock to, the start of the Vorbis audio packet which contains the seek target time. If a browser doesn't seek accurately enough, that is an implementation issue in that browser, and you should file a bug in that project's bug tracker. Regards, Chris Pearce. On 10/01/2011 8:14 a.m., Rob Coenen wrote: I have written a simple test using a H264 video with burned-in timecode (every frame is visually marked with the actual SMPTE timecode) Webkit is unable to seek to the correct timecode using 'currentTime', it's always a whole bunch of frames off from the requested position. I reckon it simply seeks to the nearest keyframe? -Rob On Fri, Jan 7, 2011 at 5:02 PM, Eric Carlsoneric.carl...@apple.com wrote: On Jan 7, 2011, at 8:22 AM, Rob Coenen wrote: are there any plans on adding frame accuracy and/or SMPTE support to HTML5 video? As far as I know it's currently impossible to play HTML5 video frame-by-frame, or seek to a SMPTE compliant (frame accurate) time-code. The nearest seek seems to be precise to roughly 1-second (or nearest keyframe perhaps, can't tell). Flash seems to be the only solution that I'm aware of that can access video on a frame-by-frame basis (even though you the Flash Media Server to make it work). Seeking to a SMPTE time-code is completely impossible with any solution I have looked at. Very interested to learn what the community POV is, and why it isn't already implemented. 'currentTime' is a double so you should be able to seek more accurately than one second - modulo the timescale of the video file and how the UA supports seeking to inter-frame times. eric
[whatwg] Autoplaying media elements not in a document
In the description of the media ready states for HAVE_ENOUGH_DATA [1], the spec says: If the autoplaying flag http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#autoplaying-flag is true, and the |paused http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-paused| attribute is true, and the media element http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-element has an |autoplay http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-media-autoplay| attribute specified, and the media element http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-element is in a |Document http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document| whose browsing context http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context did not have the sandboxed automatic features browsing context flag http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#sandboxed-automatic-features-browsing-context-flag set when the |Document http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document| was created, then the user agent may also set the |paused http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-paused| attribute to false, queue a task http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#queue-a-task to fire a simple event http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#fire-a-simple-event named |play http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#event-media-play|, and queue a task http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#queue-a-task to fire a simple event http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#fire-a-simple-event named |playing http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#event-media-playing|. This means that we'll will only autoplay if a media element is in a document. Why do we prevent media elements not in a document from autoplaying? We allow audio from a media element not in a document to play, why not allow autoplay to work while not in a document too? I note that Firefox, Chrome, Safari and Opera all autoplay when a media element is not in a document. It looks like IE9 Beta never autoplays unless the media element is hard coded in the HTML file with an autoplay attribute; IE9 doesn't seem to honour autoplay set from script. Unless there's a good reason not to, and since most browsers have implemented autoplay when not in a document anyway, perhaps we should update the spec to match the implemented behaviour? Regards, Chris Pearce. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-have_enough_data
Re: [whatwg] Html 5 video element's poster attribute
On 22/09/2010 4:26 p.m., Shiv Kumar wrote: What I suggested was to use a call to the load() So in your mind calling load() implies showing the poster? I think we should change to this. Then every call to load() would have the same effect. We should also tighten up the language so that the poster /must/ be shown up until playback begins or a seek completes, rather than /can/ be shown though. That would (hopefully!) ensure cross browser consistency. The other reason (that I've mentioned repeatedly) for not wanting to use the load method is this: 1. The load method has way too many side effects including events no less, oh and did I mention have the player now go to pause and have the readyState switch to HAVE_NOTHING, when there is meta data and to Network state go to empty when it's really idle? Gosh, I could take almost every other step in the media element load algorithm stated procedure... 2. These side (I've only listed small number above) effects are not desireable when all we want to do is turn on/off the poster. I agree, you don't want all those side effects just to show the poster. If you want to change when the poster appears, you're better off creating your own poster as an image element. The just show the poster until I play or seek case is the common case. If you want to customize your player, you can still do that. 3. Alter the load alogorithm to now fiddle with the poster will impact the other use case I've mentioned and that is, the ability to be able to switch media in mid play. We call the load() method to be able to do this (because of the things it does do listed above). So now we'll have the poster become visible while we're trying to switch video streams? You can implement media switching in mid play by loading the new resource in a new video element, seeking to the switch over point, and then swapping the new video element in place of the old one. When you call load(), the poster will be shown, but when the seek completes, the poster image will be replaced by the frame at the seek target location. This would be quicker than stopping playback of the existing resource, starting a new load in the existing media element, waiting for the new load to initialize, waiting for the seek to the change over point to complete, and then resuming playback. Unlike your proposed method, it can be done without needing to stop playback. Given that this better alternative method exists to achieve what you want, I don't think your case 3 is a strong argument against displaying the poster every time we call load(). Regards, Chris P.
Re: [whatwg] Html 5 video element's poster attribute
On 20/09/2010 6:11 p.m., Roger Hågensen wrote: If the user pauses the video during play then a paused poster must not be shown as the user most likely intends to study the paused frame of the video This is a good argument against having a paused-poster. The question then is whether the end-poster needs to be different from the start-poster. If the main use case is re-display the poster image so the user knows that they can play again, then the end-poster and start-poster don't need to be different. Showing the poster at the end of playback is a matter of taste. How about we remain with a single 'poster' attribute, and add a 'showposter' attibute, with values 'start', 'end', and 'both', which denote when the poster is shown? Or the values could be enumerated similar to how readyState and networkState are enumerated. On 20/09/2010 7:57 p.m., Silvia Pfeiffer wrote: On Mon, Sep 20, 2010 at 1:38 PM, Shiv Kumar sku...@exposureroom.com mailto:sku...@exposureroom.com wrote: Could a call to video.load() reset this state? Currently is doesn’t affect the poster. But would that be intuitive? I’m getting the video element to load it’s source and so the poster will show? I regard the load() function as a kind of reset() function. But possibly we need an actual reset() function to return to the original state where the poster image is displayed? It seems reasonable to me that subsequent calls to load() should behave the same was the first call to load(), so the poster should be redisplayed whenever load() is called. We should change the load() algorithm to require the poster frame to be repainted, if it's present. Chris P.
Re: [whatwg] Html 5 video element's poster attribute
On 21/09/2010 2:37 p.m., Robert O'Callahan wrote: On Mon, Sep 20, 2010 at 10:31 PM, Shiv Kumar sku...@exposureroom.com mailto:sku...@exposureroom.com wrote: The only thing that remains then is if web developers would like control over the poster, such as to show the poster after the video has ended, then there should be a way to do that. For this we need a method to show the poster once again. Current there is no way to get the poster to show again and the load() method is not the answer, nor is resetting. A simple method that does not impact anything else will do the trick. I am trying to understand why load() is not an adequate answer. One caveat: if you use load() to reset the poster image, you'll trigger all the events and state changes, and reset the volume, currentTime, playbackRate and so on. On 21/09/2010 2:31 p.m., Shiv Kumar wrote: Now if you want to change the source of the video in mid play to a better or lower quality version of the same video then you have to go through a few more hoops (and the load() method is used at this time – but you don’t want the poster to show either). Wouldn't it be better to load() the new resource in a separate video element, and then swap it into the DOM when it's completed loading and seeked to your change over point? Wouldn't that be more seemless? On 21/09/2010 3:36 p.m., Shiv Kumar wrote: Here are some contradictory cases that may serve as use cases to justify the need to have a spate method: 1. Some websites, don’t bother showing the poster after the video ends while providing the content producer to override. 2. Some websites (and mobile devices) default to showing the poster after the video ends and allowing the content producer to override 3. Some websites show the poster whenever the video is paused. Given the above cases, having a method the specifically controls the visibility of the poster (alone) will allow all of the above cases to be implemented. If we wanted to go down this path, I think a settable attribute 'postervisible' would be the way to go. Setting to true would show the poster, and the browser would automatically hide the poster the next time it updates the video frame (the next time playback starts and after a seek completes). The attribute would also be readable from script. We'd probably want to dispatch a 'posterhidden' event when the poster is hidden as well, and maybe a 'postershown' event as well. But wouldn't anyone who wanted this level of control have their own custom video controls anyway, so that they could ensure they looked the same across all browsers? In which case they'd have their own custom poster image implementation anyway? Chris P.
Re: [whatwg] Html 5 video element's poster attribute
On 20/09/2010 12:50 p.m., Aryeh Gregor wrote: On Sun, Sep 19, 2010 at 4:53 PM, Shiv Kumarsku...@exposureroom.com wrote: The poster frame should remain visible until the video is played. I agree with Silvia, this should be required by the spec. This makes sense, we should spec this so that the poster /must/ be visible until its played, otherwise the poster attribute can't be relied upon by authors. The poster should show again after the video has ended. I'm ambivalent about this. I could go either way. Aesthetically, I feel we shouldn't show the poster once the video has finished. Authors could script this behaviour if they wanted it. The spec as it's written forbids showing the poster after a video frame has been shown. The visibility of the poster should be scriptable and/or controllable using an attribute. Meaning that one should be able to turn on/off the poster (without changing the poster attrbute’s value) I don't see why this is necessary. I also don't see why this is necessary. The poster attribute is only useful if it's enabled, it's not useful if it isn't. Having an attribute to denote whether the poster attribute is enabled seems like duplication of state to me. You can just do video.dataset.poster = video.poster; video.removeAttribute(poster); to remove it, and video.poster = video.dataset.poster; to restore, if you like. (In browsers that implement dataset, which is apparently only WebKit so far. But you can easily store the original value someplace else, although not quite as elegantly.) The specification for poster [1] implies that we should handle dynamic changes to the poster attribute. I can imagine authors may want to cycle through a chain of poster images for a given video, and this can (theoretically) be easily implemented by changing the poster attribute in a timer. Chris P. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-video-poster
Re: [whatwg] Html 5 video element's poster attribute
Right, so you want to be able to toggle the poster back on (when the media is paused or ended) but after playback has started. I wonder if these are separate use cases, e.g. whether users would want to display a different image from the poster image in these cases. i.e. I wonder if we need to provide an attribute to specify an image to display when paused and another new attribute for an image to display when playback has ended. I wonder if that's overkill through. Chris P. On 20/09/2010 3:16 p.m., Shiv Kumar wrote: As regards having more control of the poster’s visibility, what I’m saying is that one should have the ability to turn on/off a poster. Currently once the poster has been made invisible by the UA, there is no way to turn it back on. So if I wanted to turn it back on after the video has ended, I can’t and I think people should have that choice? I hope that makes sense? Shiv http://exposureroom.com http://exposureroom.com/ *From:* whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] *On Behalf Of *Chris Pearce *Sent:* Sunday, September 19, 2010 11:10 PM *To:* whatwg@lists.whatwg.org *Subject:* Re: [whatwg] Html 5 video element's poster attribute On 20/09/2010 12:50 p.m., Aryeh Gregor wrote: On Sun, Sep 19, 2010 at 4:53 PM, Shiv Kumarsku...@exposureroom.com mailto:sku...@exposureroom.com wrote: The poster frame should remain visible until the video is played. I agree with Silvia, this should be required by the spec. This makes sense, we should spec this so that the poster /must/ be visible until its played, otherwise the poster attribute can't be relied upon by authors. The poster should show again after the video has ended. I'm ambivalent about this. I could go either way. Aesthetically, I feel we shouldn't show the poster once the video has finished. Authors could script this behaviour if they wanted it. The spec as it's written forbids showing the poster after a video frame has been shown. The visibility of the poster should be scriptable and/or controllable using an attribute. Meaning that one should be able to turn on/off the poster (without changing the poster attrbute’s value) I don't see why this is necessary. I also don't see why this is necessary. The poster attribute is only useful if it's enabled, it's not useful if it isn't. Having an attribute to denote whether the poster attribute is enabled seems like duplication of state to me. You can just do video.dataset.poster = video.poster; video.removeAttribute(poster); to remove it, and video.poster = video.dataset.poster; to restore, if you like. (In browsers that implement dataset, which is apparently only WebKit so far. But you can easily store the original value someplace else, although not quite as elegantly.) The specification for poster [1] implies that we should handle dynamic changes to the poster attribute. I can imagine authors may want to cycle through a chain of poster images for a given video, and this can (theoretically) be easily implemented by changing the poster attribute in a timer. Chris P. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-video-poster
[whatwg] Media resource fetch algorithm reporting failure
In the media element resource fetch algorithm [1], there's this step: quote If the media data http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-data cannot be fetched at all, due to network errors, causing the user agent to give up trying to fetch the resource [or] If the media resource http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-resource is found to have Content-Type metadata http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#content-type that, when parsed as a MIME type http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#mime-type (including any codecs described by the |codecs| parameter), represents a type that the user agent knows it cannot render http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render (even if the actual media data http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-data is in a supported format) [or] If the media data http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-data can be fetched but is found by inspection to be in an unsupported format, or can otherwise not be rendered at all 1. The user agent should cancel the fetching process. 2. Abort this subalgorithm, returning to the resource selection algorithm http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm. /quote Why don't we dispatch an error event to the candidate source child we were loading from, or the media element if it was loading from a source attribute, in this case? We dispatch error events in the resource selection algorithm if the source child has an unsupported type, how is this significantly different? Regards, Chris Pearce. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource
Re: [whatwg] Media resource fetch algorithm reporting failure
Ah I see that we will fire an error event when we return to the resource selection algorithm in this case, since we didn't abort the resource selection algorithm. Never mind! Chris P. On 16/09/2010 3:48 p.m., Chris Pearce wrote: In the media element resource fetch algorithm [1], there's this step: quote If the media data http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-data cannot be fetched at all, due to network errors, causing the user agent to give up trying to fetch the resource [or] If the media resource http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-resource is found to have Content-Type metadata http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#content-type that, when parsed as a MIME type http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#mime-type (including any codecs described by the |codecs| parameter), represents a type that the user agent knows it cannot render http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render (even if the actual media data http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-data is in a supported format) [or] If the media data http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-data can be fetched but is found by inspection to be in an unsupported format, or can otherwise not be rendered at all 1. The user agent should cancel the fetching process. 2. Abort this subalgorithm, returning to the resource selection algorithm http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm. /quote Why don't we dispatch an error event to the candidate source child we were loading from, or the media element if it was loading from a source attribute, in this case? We dispatch error events in the resource selection algorithm if the source child has an unsupported type, how is this significantly different? Regards, Chris Pearce. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource
Re: [whatwg] Race condition in media load algorithm
On 3/08/2010 9:20 a.m., Ian Hickson wrote: The synchronous section would run as soon as the task span the event loop. Spinning the event loop is defined essentially as being equivalent to breaking the original task in two, one that does everything up to spinning the event loop, and one that does everything after spinning the event loop. You are effectively waiting for some condition to become true and then queueing a task to run the continuation of the algorithm. It's just more convenient to write the algorithms as one long set of steps rather than having split them up into multiple algorithms that invoke each other and pass state around. Or does stop the currently running task in #spin-the-event-loop imply a jump to step 2 of the algorithm under #processing-model2? Yes. So the task spinning the event loop has run up to the point of spinning the event loop, then we run the synchronous section, and then the task which was spinning the event loop will resume after its goal is met at some later time? In the case of a tasks which invokes an algorithm which has a synchronous section, and then pauses the event loop (such calling window.alert()), we should not run the synchronous section until the event loop pause has completed? Thanks, Chris Pearce.
Re: [whatwg] Race condition in media load algorithm
On 4/08/2010 11:32 a.m., Ian Hickson wrote: In the case of a tasks which invokes an algorithm which has a synchronous section, and then pauses the event loop (such calling window.alert()), we should not run the synchronous section until the event loop pause has completed? Currently, yeah. We might want to make pause also trigger synchronous sections, if that's a problem. Having pause trigger synchronous sections is definitely easier for us to implement, and would make pausing the event loop consistent with spinning the event loop WRT synchronous sections. Chris P.
Re: [whatwg] Race condition in media load algorithm
On 2/08/2010 9:17 p.m., Ian Hickson wrote: On Mon, 2 Aug 2010, Chris Pearce wrote: There's a race condition in the media load algorithm. When the resource selection algorithm begins, it sets a task to complete the rest of the resource selection algorithm asynchronously. Not quite. It awaits a stable state and then runs a synchronous section, which means that it will run the subsequent steps as soon as the current task has finished, before anything else that is queued. Ah, I see. My understanding of the processing model was incomplete, thanks for clarifying! All the best, Chris Pearce.
[whatwg] Race condition in media load algorithm
There's a race condition in the media load algorithm. When the resource selection algorithm begins, it sets a task to complete the rest of the resource selection algorithm asynchronously. In the asynchronous task, we set the delaying-the-load-event flag to true at step 4. But between the resource selection algorithm setting the task to asynchronously continue the algorithm, and the task actually running, the load event could fire, before we have a chance to set the delaying-the-load-event flag to true. I suggest we set the delaying-the-load-event flag to true before we set the task to continue the rest of the resource selection algorithm asynchronously. Chris Pearce.
Re: [whatwg] HTMLMediaElement.preload and stalled event
On 23/07/2010 8:57 p.m., Philip Jägenstedt wrote: On Fri, 23 Jul 2010 05:25:37 +0200, Chris Pearce ch...@pearce.org.nz wrote: Should we be periodically firing a stalled event at the media element while we've suspended download of a preload:none or preload:metadata media? [...] I think this is a spec bug. When a UA decides to not download more data it should fire the suspend event. It doesn't make any sense to also fire the stalled event, in my opinion, but the spec isn't clear about this. I agree. We should make the spec clearer here. Also, I don't understand why the stalled event would be fired periodically in any case, why would that be so? Agreed, it doesn't make sense to fire multiple stalled events; you can detect when the download resumes by listening for subsequent progress events. On 23/07/2010 5:11 p.m., Silvia Pfeiffer wrote: To me, stalled implies that the UA is trying to receive stuff, but is being stalled. So, my understanding is that the resource fetch algorithm in [1] should include the word unexpectedly - that would fix it. I think this suggested wording change would be a good one. Regards, Chris Pearce.
Re: [whatwg] video resource selection algorithm and NETWORK_NO_SOURCE
On 24/07/2010 2:16 a.m., Philip Jägenstedt wrote: Silvia made we aware of discrepancy in how browsers implement the resource selection algorithm, see forwarded message. It's my assessment that Opera is the only browser following the spec. I've filed this bug with Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=581355 Thanks, Firefox is not setting the networkState to NETWORK_NO_SOURCE when the synchronous part of the resource selection algorithm returns. We've not updated our load algorithm implementation in about a year, there will no doubt be other places where we're non-compliant. We've got an existing bug on file to update the load algorithm: https://bugzilla.mozilla.org/show_bug.cgi?id=485288 Walking on water and developing software from a specification are easy if both are frozen. Regards, Chris Pearce.
[whatwg] HTMLMediaElement.preload and stalled event
I am implementing HTMLMediaElement.preload in Firefox, and I have a question: Should we be periodically firing a stalled event at the media element while we've suspended download of a preload:none or preload:metadata media? In step 2 of the resource fetch algorithm [1], the spec says If at any point the user agent has received no data for more than about three seconds, then queue a task to fire a simple event named stalled at the element. But the description of the stalled event [2] says The user agent is trying to fetch media data, but data is unexpectedly not forthcoming. The later description seems to imply that we only send stalled events when we unexpectedly stop receiving data, but the resource fetch algorithm indicates we should send stalled events if we stop receiving data for any reason, even if we suspend the download, and thus expect to not receive data. If we should send the stalled events, we should update the description of the stalled event at [2] to reflect that. Thanks, Chris Pearce. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#event-media-stalled
[whatwg] HTMLMediaElement timeupdate when starting new load
In the media element load algorithm [1], step 4 resets the current playback position to 0 if the media element has a previously or partially loaded resource. I think we should send a timeupdate event if this causes the current playback position to change. This is makes it easier for controls UI to keep their playback positions up-to-date with the actual playback position, and it makes sense to send a timeupdate event since we are changing the current time. You could argue that sending a timeupdate event in step 4 of the load algorithm is implied by changing the current playback position, but the spec is explicit everywhere else that we send timeupdate events, so it would be nice to be explicit here too. All the best, Chris Pearce. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-element-load-algorithm
Re: [whatwg] [ogg-dev] HTML5 audio tag
In order to do this you'd need to know /in advance/ exactly which Ogg pages were audio and which were video so you could choose to only download the vorbis pages. The upcoming Ogg Skeleton index does not index pages at a high enough granularity to facilitate this. It could, but then the index would be a lot bigger. I also wonder if the time/server overhead of setting up new HTTP byte-range request for each ~4KB Ogg vorbis page wouldn't make this worth while. Especially over a high latency connection. You'd be best to oggz-rip the streams you want out in advance and serving them statically, as Conrad suggested. It's /impossible/ to determine in advance which byte ranges to download in order to download only one stream. You simply don't know which stream a page belongs to or what size it is until you've downloaded the page. Chris P. On 12/05/2010 11:18 a.m., Silvia Pfeiffer wrote: Yeah, the track attribute of the media fragments specification that Ralph links will in theory allow to just download the track-related data. But it still requires implementation - either in the browser, which will somehow need to identify which bytes belong to which track and just request those byte ranges that are relevant, or on the server, which will only deliver the relevant bytes when asked for the audio track only. None of this is implemented yet. In fact, the discovery of which bytes in a Ogg stream belong to which track is a challenge. I am not sure whether the new Skeleton Index format might actually allow for that... Cheers, Silvia. On Wed, May 12, 2010 at 3:32 AM, Frank Barchardfbarch...@google.com wrote: FWIW chromium does client side range requests that in theory would request only the audio. But. the ogg demux reads the other tracks and discards them. A use case I've heard is listening to music videos and discard the video... bit of a bandwidth waste. On Tue, May 11, 2010 at 10:17 AM, Ralph Gilesgi...@thaumas.net wrote: On 11 May 2010 04:24, narendra sisodiyanarendra.sisod...@gmail.com wrote: It will be very good if HTML5 API specify this. I mean, Say, If we use audio tag , then It must stream only audio part of the file irrespective of the fact that the src field contains a video file. I don't think that's a practical option, since the server must manipulate the file to return an audio-only subset of the data for there to be any bandwidth advantage. That's not something that the HTML5 specification, which documents browser behaviour, can describe. Note that it's completely possible to use a server-size module or script to do this, using a query url in the HTML5 media element's src attribute. It's just part of a custom server config rather than the HTML5 API. The Media Fragments Working Group at the W3C is currently working on a standardized syntax for this. See http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/ if you're interested. FWIW, -r ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev ___ ogg-dev mailing list ogg-...@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev
Re: [whatwg] Media element delaying load event
There's an additional problem with the current media load algorithm spec, it's possible to cause two resource-selection asynchronous calls to run in parallel with the following javascript: var v = document.createElement(video); v.src = foo.ogg; v.load(); document.body.appendChild(v); The load() method will asynchronously invoke the media element's resource selection algorithm, and if the resource selection algorithm doesn't execute fast enough in the background to change the networkState, when we add the video to the document and the networkState is still NETWORK_EMPTY, the add-to-a-document code will asynchronously invoke the resource selection algorithm again. I think we should either: 1. Change the networkState in the load() method. This will prevent another asychronous invokation of the resource selection algorithm when we add the media element to a document, or 2. never asynchronously invoke the resource selection algorithm if there's another instance running, or 3. add a guard at the start of the resource selection algorithm to abort the async call if there's already another instance running. Because we have waiting in the load algorithm now, there's no need to have multiple instances of the resource selection algorithm active. So option 2 is probably the easiest. I still think we need to delay the load event in the load() method, rather than in the resource selection algorithm, as I said in my previous post. Thanks, Chris Pearce. On 4/03/2009 10:17 a.m., Chris Pearce wrote: The media element spec says: If a media element http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-element whose |networkState http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-networkstate| has the value |NETWORK_EMPTY http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-network_empty| is inserted into a document http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#insert-an-element-into-a-document, the user agent must asynchronously invoke the media element http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-element's resource selection algorithm http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm. The resource selection algorithm then goes on to set the delaying-the-load-event flag to true. Depending on how the asynchronous invocation is implemented, the document could actually complete loading during the time after the insertion of a media element, but before the resource-selection algorithm sets the delaying-the-load-event flag is set to true. This means the load event could fire during that time, even though we intended to delay the load event. Maybe we should set the delaying-the-load-event flag to true before we asynchronously call the resource-selection algorithm, and then then resource-selection algorithm can set the delaying-the-load-event flag to false if that decides it needs to wait for a src or source element child? Thanks, Chris Pearce.
[whatwg] Media element delaying load event
The media element spec says: If a media element http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-element whose |networkState http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-networkstate| has the value |NETWORK_EMPTY http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-network_empty| is inserted into a document http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#insert-an-element-into-a-document, the user agent must asynchronously invoke the media element http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-element's resource selection algorithm http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm. The resource selection algorithm then goes on to set the delaying-the-load-event flag to true. Depending on how the asynchronous invocation is implemented, the document could actually complete loading during the time after the insertion of a media element, but before the resource-selection algorithm sets the delaying-the-load-event flag is set to true. This means the load event could fire during that time, even though we intended to delay the load event. Maybe we should set the delaying-the-load-event flag to true before we asynchronously call the resource-selection algorithm, and then then resource-selection algorithm can set the delaying-the-load-event flag to false if that decides it needs to wait for a src or source element child? Thanks, Chris Pearce.
[whatwg] Media load algorithm feedback
I'm updating the new load algorithm for Firefox's video implementation, I've got some feedback on the recent changes to the load algorithm. I think the changes are sensible. It wasn't immediately obvious at first, but after thinking through them, I see the logic behind them. We now have three things called load. The load() method, the load algorithm, and the resource-load algorithm. It might be clearer if they were called the load() method, the resource selection algorithm, and the resource fetch algorithm. From the using source elements load algorithm sub-step: /Search loop:/ Run these substeps atomically (so that the DOM cannot change while they are running): 1. If the node after pointer is the end of the list, then jump to the step below labeled /waiting/. [...] 7. Waiting: Set the error attribute to a new MediaError object whose code attribute is set to MEDIA_ERR_NONE_SUPPORTED. 8. Set the element's networkState attribute to the NETWORK_NO_SOURCE value 9. Queue a task to fire a progress event called error at the media element. 10. Set the element's delaying-the-load-event flag to false. This stops delaying the load event. 11. Wait until the node after pointer is a node other than the end of the list. (This step might wait forever.) There's no step 12; I think the intention is that we return to the Search loop, but it's not documented. Step 1 of the load algorithm: 1. While the media element has neither a src attribute nor any source element children, wait. (This steps might wait forever.) And further down it says: If a media element http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-element whose |networkState http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-networkstate| has the value |NETWORK_EMPTY http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-network_empty| is inserted into a document http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#insert-an-element-into-a-document, the user agent must asynchronously invoke the media element http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-element's load algorithm http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm. I think that should be invoke the load() method? If it's invoke the load() method, running load() will cancel any already running instance of the load algorithm - e.g. any load which is waiting at step 1 of the load algorithm. As it's written, the load /algorithm /will be invoked, which will not cancel any waiting loads, and it could in fact it create another instance of the load algorithm waiting at step 1 of the load algorithm. So we would create two concurrent instances of the load algorithm, both waiting at step 1 of the load algorithm by doing the following: var v = document.createVideo(); v.load(); document.body.appendElement(v); Setting v.src or adding a source child element to v will awaken two instances of the load /algorithm. /Other than that, the media load spec seems sensible. All the best, Chris Pearce.
[whatwg] Adding resourceless media to document causes error event
I need to clarify something about the media load() algorithm [ http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-load ] My reading of the spec is that if you have a media element with no src attribute or source element children (e.g. video/video) and you insert it into a document, then the media load() algorithm will be implicitly invoked, and because the list of potential media resources is empty, that algorithm will immediately fall through to the failure step (step 12), causing an error progress event to be dispatched to the media element. My question is: Is is really necessary to invoke the load algorithm when adding a media element with no src/sources to a document? Doing so just causes an error progress event dispatch, and we've not exactly failed to load anything, indeed, we've not even tried to load anything in this case. Thanks, Chris Pearce.
[whatwg] Adding and removing media source elements
I want to clarify something about media's child source element... In the source element spec [ http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-source-element ] it says: If a source element is inserted into a media element that is already in a document and whose networkState is in the NETWORK_EMPTY state, the user agent must queue a task that implicitly invokes the load() method on the media element, and ignores any resulting exceptions. So we only trigger a load when adding a child source element to a media element if the media element is in NETWORK_EMPTY networkState. Additionally, in the spec for media's src attribute [ http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-media-src ] it says: If the src attribute of a media element that is already in a document and whose networkState is in the NETWORK_EMPTY state is added, changed, or removed, the user agent must queue a task that implicitly invokes the load() method on the media element, and ignores any resulting exceptions. Almost the same, except that we invoke the load algorithm when the src is removed or changed in this case. I have the following questions: (1) Should removing a media element's child source element while the networkState is NETWORK_EMPTY cause the load() algorithm to be invoked? This would match the behviour of removing the media element's src attribute when networkState is NETWORK_EMPTY. It seems that in order to start a load in an already loaded media element, you must change the src attribute or add source element children to the media element, and then call load() on the media element. Whereas when you initially create the media element, the first time you add the src attribute or add a child source element to the media element, you'll start an asynchronous load immediately. (2) Why don't we invoke load() whenever a media element's src attribute or source children are changed, regardless of networkState? That way changes to the media's src/source other than the first change would have the same effect as first change, i.e. they'd have an immediate effect, causing load() to be invoked. Thanks, Chris Pearce.
