Re: Do we need to support media that doesn't start at 0?

On 13 April 2011 21:51, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> On Wed, Apr 13, 2011 at 10:22 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>> On Wed, 13 Apr 2011 13:58:04 +0200, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>>
>>>
>>> On Apr 13, 2011, at 12:03 , Philip Jägenstedt wrote:
>>>
>>>> From todays teleconf.
>>>>
>>>> The question comes up in some test cases in
>>>> <http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases.html>.
>>>>
>>>> It it my experience that media not starting at time 0 is extremely rare,
>>>> I've really only seen it in poorly remuxed MPEG-2 transport streams and
>>>> similar. I would say that *if* a user agent supports media that doesn't
>>>> start at 0, then we should clamp the request start to the start time when
>>>> necessary. I don't think that we should make the start/end relative to the
>>>> media start position, as that would be inconsistent.
>>>
>>>
>>> Everyone seems to say "we don't want to support media that doesn't start
>>> at t=0", but then my next question is:
>>>
>>> Assuming I have an item example.ogv starting at t=0. I now request
>>> <http://example.com/example.ogv?t=10,20>. Does the resulting video stream
>>> start at t=0 (i.e. has everything been recoded, if the underlying format has
>>> embedded timestamps) or at t=10, or do we simply leave it
>>> implementation-defined?
>>>
>>> And, of course, the next question is: what does
>>> <http://example.com.ogv?t=10,20#t=5,15> show? seconds 5-10 of the original
>>> media file? seconds 10-15 of the original media file? Something else?
>>>
>>> Note that these examples may actually occur in real life: it's easy enough
>>> to envision an application that simply tacks #t=xxxx onto an existing URL to
>>> show just a little bit of it.
>>
>> If it in a format that allows preserving the original time stamps and the UA
>> understands it, then I'd say the result is seconds 10-15 of the original
>> resource. However, I've been arguing in other venues (WHATWG/HTML WG) that
>> browsers in particular shouldn't support non-zero start times and should
>> instead normalize the time line to start at 0. In such an implementation,
>> the result would be seconds 15-20 of the original resource.
>>
>> So, the result depends on how the UA interprets resources with non-zero
>> start times, and that is still an unresolved issue.
>
> Ogg with Skeleton supports remembering its original start time, so it
> is in theory possible to get the seconds 10-15 of the original
> resource. However, I don't think I've seen it used anywhere other than
> how our old annodex plugin for apache worked.

even in that system, we interpreted ?t=10-15 as a view of the resource
that starts playing from 10s in. It would make sense for a UI in that
system to show a timeline from 0, with current play position at 10,
and if the user clicked the timeline in the portion from 0-10 a new
request would be sent. However I think that use-case is now covered by
fragments.

A fragment that shows a view of a stream is however a different
use-case from Philip's original question, which was about the
underlying original video file having a non-zero start time. I agree
that we could just translate the underlying start time to 0.

Conrad.

Received on Thursday, 14 April 2011 05:34:07 UTC