Re: Fwd: [whatwg] Remove addCueRange/removeCueRanges

On Fri, 14 Aug 2009 14:56:16 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

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

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?

In my opinion that is completely a UI design choice. My personal  
preference is that ?query resources should be aligned to zero (ignoring  
skeleton headers) and that #fragment resources should display the full  
time-line with the ability to seek outside the specified range. Different  
browsers will experiment with different solutions and if the author isn't  
happy she/he could use a script-based interface more to her/his liking.

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

This WG may give non-normative suggestions to browser vendors, but I think  
it's premature and that it should wait for feedback from implementors. But  
let's just disagree on this for now.

>>> * 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?

That might help, but I don't really understand how this special retrieval  
action is going to work yet.

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


-- 
Philip Jägenstedt
Opera Software

Received on Saturday, 22 August 2009 11:22:07 UTC