Re: Feedback from FOMS

On Mon, 25 Jan 2010 19:50:46 +0100, Jack Jansen <Jack.Jansen@cwi.nl> wrote:

>
> On 25 jan 2010, at 09:32, Silvia Pfeiffer wrote:
>
>> On Mon, Jan 25, 2010 at 7:24 PM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>>>
>>> On 25 jan 2010, at 05:04, Silvia Pfeiffer wrote:
>>>
>>>> The current version 1 should be focused on only client-side temporal
>>>> url addressing with URI fragments and should be published soon, since
>>>> it's simple to implement.
>>>>
>>>> In version 1.1 we could further sort through other temporal
>>>> fragmentation URI approaches.
>>>
>>> While I agree with the idea that we should publish early, if possible,  
>>> even if this means we've got to push some functionality off to a 1.1  
>>> document, I don't really see how doing only temporal fragments would  
>>> save us much effort. As I see it, all the complexity we face is in  
>>> reconstructing temporal streams, especially in the face of caching.  
>>> All the other fragments (well, at least spatial and track fragments)  
>>> require recoding, so they aren't cacheable anyway.
>>>
>>> What might be a way to a quick 1.0 is to drop caching. But I'm not  
>>> convinced that that is a good idea: it may lead to a situation where  
>>> everyone implements 1.0, no-one implements the new caching support of  
>>> 1.1, and we (the MF WG) get blamed for the performance issues for  
>>> years to come...
>>
>> Hm? UA supported media URI fragments (#) are cachable, since they only
>> use byte range requests. This works now for both, MPEG and Ogg. For
>> URI fragments (#), this is optimal and the other functionalities were
>> only invented to offer other solutions for such formats that cannot do
>> the time->byte-range mapping directly from the file header (of which
>> there are a few, but none is relevant to HTML5). So, I don't think we
>> will get ourselves into too much trouble.
>
> As usual, you are right:-)
>>
>>
>>>>
>>>> Further, the suggestion is to describe temporal URI fragments (#t=a,b)
>>>> to simply mean "focus attention" and thus to also provide a recommend
>>>> implementation. The implementation should be such that the full video
>>>> timeline is displayed, but only the given fragment played back, then
>>>> paused. A "reload" button will replay this fragment - pressing "play"
>>>> will continue playback at the play position.
>>>
>>>
>>> Isn't this exactly what we call in-context (versus out-of-context )?
>>
>> Indeed, but until now we haven't really decided what would be the
>> recommended display for URI fragments (#) for display. The discussion
>> with the browser vendors (Firefox and a little bit of Opera) seemed to
>> indicate (and possibly confirm) that in-context for URI fragments (#)
>> was the right thing to do and URI queries (?) relate better to
>> out-of-context.

Here's the behavior I intend for Opera eventually:

#t=a,b loads the whole resource (conceptually, not network-wise), but sets  
the initial position to a and possibly highlights the range [a,b] in the  
UI in some special way. Typically, playback stops at b and if looping it  
restarts at a (seamlessly in a good enough implementation). If the user  
ever seeks outside of the range, the range no longer applies, it's  
possible to play from before it to after it without it stopping at b. When  
looping, seeking outside the range either causes looping to be ignored or  
looping always seeks back to a and restarts at b, this is a minor detail.

I think it would be wise to wait for multiple experimental implementations  
before putting any recommendations in the spec, as anything we write now  
will most likely be wrong. For now, suggestions can go on this list or the  
wiki, not in the spec. Also, HTML5 would be the appropriate place to  
specify how looping and media fragments interact.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 26 January 2010 12:40:14 UTC