Re: Feedback from FOMS

On Tue, Jan 26, 2010 at 11:39 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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.

Good, that conforms with what we discussed at FOMS. Further, when no
looping is set and you press play again at b (after it stopped), it
makes sense to continue playing after b and not jump back to a.
However, pressing "replay" or "reload" will just play a-b again.


> 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.

Not sure I agree.

I think it can go in the draft spec and as we learn more, we can adapt
it. Better than having the discussion lost in email or in the wiki.
It's just a recommendation anyway and represents our current state of
thinking, which is good to expose and adapt as feedback comes in. Of
course, I would only add it to the spec if we can all agree on the
recommendation.

Also: the media frag spec does not just relate to Web browsers, so I
think our spec should provide a general recommendation for video
players on how to deal with media frags. HTML5 can then repeat this as
a recommendation to browser vendors and make it more concrete for the
audio and video elements' actual attributes (e.g. how to deal with the
"loop" attribute) if necessary.

Cheers,
Silvia.

Received on Tuesday, 26 January 2010 22:49:01 UTC