Re: Combining media fragments with other time-clipping methods

Hi Dave,

On Thu, Nov 27, 2008 at 10:09 AM, Dave Singer <singer@apple.com> wrote:
>> On 26 nov 2008, at 01:27, Silvia Pfeiffer wrote:
>>>
>>> Hi Jack, all,
>>>
>>> This is indeed a very fundamental problem and has to do with exposing
>>> the context of the resource or not. I am very torn on this issues.
>>>
>>> For example, when a browser plays back
>>> http://www.example.com/myvideo.ogg#t=20s in a Web browser for a HTML5
>>> video element, would we want to see the timeline with an offset or
>>> without?
>
> t=20s could be:
> * a clip from 20s to 20s
> * the whole myvideo, but start playing at 20s (as if the user had dragged
> teh slider to 20s before playback)
> * 20s to the normal end of the media, with material before 20s removed
>
> The first is not very useful, but both the others are.  However, the second
> is not a fragment, but a start-playing-at.

The second could well be a fragment, but where the user agent knows
that it is a fragment, and that there is stuff at the beginning that
it can get to if it needs to. Therefore, the distinction between case
two and three is not so obvious.

The question whether #t=20s refers to an offset or an interval
starting at that offse is one that we haven't really talked about yet,
but should, so here goes.

When we did the temporal URI spec, we found that the best way to look
at temporal URIs is that they always specify a interval, and never
just a offset point. The only sensible use case for a single offset is
when one is trying to extract a keyframe at such an offset rather than
a media fragment - this could be done with content negotiation, but
may not be something we should consider. So, our assumption was that
the time always specified semi-open intervals: [20s,inf[ for #t=20s,
or [20s,40s[ for #t=20s-40s. I think this makes sense for us, too.

Regards,
Silvia.

Received on Thursday, 27 November 2008 12:23:38 UTC