[Bug 12175] <video> the order of the loadedmetadata, loadeddata and suspend event is not defined

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12175

Philip Jägenstedt <philipj@opera.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #6 from Philip Jägenstedt <philipj@opera.com> 2011-06-09 13:07:02 UTC ---
(In reply to comment #5)
> Clarification:
> 
> In http://lists.w3.org/Archives/Public/public-html/2011Feb/0437.html you say
> that "<video preload="metadata">" could result in any of these:
> 
>    slow network: loadstart, progress, loadedmetadata, loadeddata, suspend
>    unlucky timing: loadstart, progress, loadedmetadata, suspend, loadeddata
>    fast network: loadstart, progress, suspend, loadedmetadata, loadeddata
> 
> I understand how "slow network" could occur, but I don't understand how the
> other two could occur. How could you ever get more data after you've suspended,
> assuming you've not resumed? All these events use the same task source, and
> 'suspend' occurs after the network has been suspended, at which point there
> can't be any more data to change the readyState.
> 
> I guess one could argue that the CPU might be really slow and thus decoding the
> data could take substantially longer than it takes for the UA to give up and
> suspend the network even though it doesn't know it has gotten the metadata yet;
> is that what you mean?

The issue is that loadstart, progress and suspend are related to networkState
while loadedmetadata and loadeddata are related to readyState and these states
independent to some extent. Data isn't examined/decoded synchronously as it
comes in over the network. This is approximately what might happen in the "fast
network example"

1. fire loadstart
1. start loading
2. some data arrives
3. sniff the type from the data and start setting up a decoding pipeline (in
another thread)
4. the entire resource is loaded; fire suspend
5. pipeline is set up and we know the duration; fire loadedmetadata
6. the first frame has been decoded; fire loadeddata

The steps that are related to the network and the steps that are related to the
decoding have no order imposed between them, so neither do the events.

There's also the issue of when to fire canplaythrough. You know that it can be
fired already at step 4 when you fire suspend, but you have to delay it until
after canplay for any kind of sanity.

If the intent of the spec is that networkState and readyState be coupled so
that they don't vary independently like this, it needs to say so. I've had to
add conditions on the state transitions to force a stable order, it does not
happen automatically.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 9 June 2011 13:07:10 UTC