At 14:09  +1000 9/05/09, Silvia Pfeiffer wrote:
> you might try loading, say, the one-page version of the HTML5 spec. from the
 WhatWG site...it takes quite a while.  Happily Ian also provides a
 multi-page, but this is not always the case.

That just confirms the problem and it's obviously worse with video. :-)


 The reason I want clarity is that this has ramifications.  For example, if a
 UA is asked to play a video with a fragment indication #time="10s-20s", and
 then a script seeks to 5s, does the user see the video at the 5s point of
 the total resource, or 15s?  I think it has to be 5s.

I agree, it has to be 5s. The discussion was about what timeline is
displayed and what can the user easily access through seeking through
the displayed timeline. A script can access any time of course. But a
user is restricted by what the user interface offers.

Sure. I think we are probably in agreement. Logically, the UA is dealing with the whole resource -- which is why it's 5s in this case. The UA is also responsible for focusing the user on the fragment, and (implicitly) for optimizing the network for what the user is focusing on.

For example, some UAs would essentially invoke the same code if the user immediately did a seek to a time, if the javacsript did a seek to a time, or the initial URI had a fragment indicator starting at a time. In all three cases, the UA tries to start at that time as best it can, optimizing network access to do that.

 > But we can optimize for the fragment without disallowing the seeking.

What do you mean by "optimize for the fragment"?

I mean, the UA can get support from the server for time-based access, helping optimizing the network access for the fragment to be presented, while at the same time allowing seeking outside that fragment.

 Of course none of the
discussion will inherently disallow seeking - scripts will always be
able to do the seeking. But the user may not find it easy to do
seeking to a section that is not accessible through the displayed
timeline, which can be both a good and a bad thing.

How easy a particular user interface is to use for various tasks is (I hope) not our worry...
--
David Singer
Multimedia Standards, Apple Inc.

Reply via email to