Re: Fwd: [whatwg] Remove addCueRange/removeCueRanges

Hi Philip,

Great to see you are subscribed to this list, too! We need browser
developers to be involved in these issues.

On Fri, Aug 14, 2009 at 9:21 PM, Philip Jägenstedt<philipj@opera.com> wrote:
> On Fri, 14 Aug 2009 02:32:23 +0200, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>> Hi all,
>>
>> As you can see in the below email thread, in the WHATWG/HTML5
>> discussions, the need for temporal fragment addessing has been voiced
>> multiple times.
>>
>> Can I suggest we do a concerted effort over the next few weeks to make
>> the temporal fragment specifications solid and have some demos that
>> show how they should work? This would be either using the existing
>> annodex technology, or a set of javascript libraries, or whatever
>> other approach we can use (ffmpeg?, gstreamer?) to make concrete
>> demos. Then we can encourage the browser vendors to actually implement
>> support for our addressing methods into the browsers. It would be a
>> break-through already if we only sorted out the time dimension!
>>
>> I am concretely thinking here about:
>> * sorting out what the difference between the # and the ? approach
>> should be - use cases, protocol, user interface
>
> For now I would be very happy if we could just define the most basic syntax.

Agreed.

> As far as browsers are concerned, query strings will not be given any
> special treatment, so personally I am only interested in the syntax for
> proper fragments.

So, let's look at the query case a bit more in-depth.
A video file with a query is being treated as a different resource to
the video resource without the query.
The media server  returns only the specified time segment of the
video. This is the "new resource".
Since the browser doesn't give it special treatment, the browser
regards this "segment" as the full video.
As the time display for a video starts by default at 0, this "segment"
will by default be displaying a start and end time that does not
reflect the start and end time used in the URL. Correct?

This is where I see a need for the browser to do something.

What we should do IMO is to fix the start and end time displayed in
the video controls.

Alternatively, we could display the controls that would relate to the
original resource, but I think that's semantically wrong because it's
a different resource, and I also think it's information that is not
available in the given resource (at least not the duration of the
original resource) so would require an extra retrieval action.

Fixing the start/end time displayed is not as much of a problem for
Ogg files: the browser can parse the start time in the skeleton header
(assuming such a skeleton track is present) and get the duration in
the usual way. For other containers I don't think such a start time
offset is available.

Alternatively, the browser can use the information given in the URL to
display the start and end times. Since these may not be 100% correct,
this may be a problem.

So, what would be the right thing to do?


For fragments with # in contrast it make sense to regard it exactly in
the way that the "start" and "end" attributes of the <video> tag were
going to be handled: as means of navigating and controlling the
playback of the full resource.


> Normative text for UI makes no sense, so at most it would
> be an informative note in the spec.

That's fine. I just think it needs specifying.


>> * implement a demo using HTML5 video tag
>
> That would be nice, you could probably get away with just seeking to the
> proper position with JavaScript and the listen to the timeupdate even to
> pause it and the end of the fragment.

Yes, for fragments that would really be all we need.

We could hack that together quickly. So, if we can come to an
agreement on the meaning of fragments and queries and specify the
details for fragments, we should be fine.

An issue with any of our existing specs with fragments (#) that just
occurred to me is: if the retrieval action only retrieves the
specified segment, the browser has no way to figure out the length
(start/duration) of the original resource. Maybe we need to introduce
additional headers that would provide for that?


>> This whole issue is getting urgent because HTML5 is going for a last
>> call in October. If we don't have anything sorted by then, it would be
>> a rather poor state of affairs for video on the Web.
>
> I don't want to imply that we can slack off, but browsers won't stop
> improving just because HTML5 freezes. But yes, it would be good if we could
> get a normative reference from HTML5 to MF in the place where it now says
> "For example, a fragment identifier could be used to indicate a start
> position."

I am looking at it as motivation to make some progress on a limited
subset of the full challenge. But also: people are wanting to use this
and and our charter officially ends in January 2010, so I think we
better get a move on. :)


Cheers,
Silvia.

Received on Friday, 14 August 2009 12:57:12 UTC