Re: Fwd: [Bug 10723] support for media fragment URIs in relevant HTML5 elements

Hi all,

Here are the bugs that I think we need to open:

1. Interpretation of temporal media fragment URI in browser navigation:

Problem: what is a browser expected to do when a user navigates to a
media resource with a media fragment

Proposal: similarly to how
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid
explains how a browser has to scroll to a document offset on seeing a
HTML fragment, we also need to explain browser behaviour for media
fragment URIs. The expectation by the Media Fragment WG is that a
browser will start playback at the given start time offset and stop it
at the given end time offset.


2. User interface of temporal media fragment URI in browser navigation:

Problem: what is a browser expected to display when a user navigates
to a media resource with a media fragment

Proposal: Since the browser will display default controls, we need to
introduce markers on the controls for the fragment, see
http://www.youtube.com/watch?v=LfRRYp6mnu0 for an example implementation.


(We could also ask for 2 more bugs on changing the url on "pause" and
adding it to the browser history, but I think that's something for a
later time and not so important.)


3. User interface of temporal media fragment URI in @src of video element:

Problem: what is a browser expected to display in @controls when a
<video> or <audio> element loads a media resource with a media
fragment

Proposal: The browser will play the resource from the start time to
the end time and pauses at the end time. It further displays the time
segment on the timeline of the @controls in a suitable manner as part
of the full video's timeline. If the user hits "play" at the end of
the fragment playback, playback will continue past the end of the
playback until it reaches the end of the resource or another user
interaction occurs.


4. Effect when @src of video element contains temporal media fragment
URI and @loop:

Problem: what is a browser expected to loop over when a temporal media
fragment URI is given in a @src attribute of a media resource

Proposal: The browser will loop over the fragment unless there is user
interaction. The fragment constraint will be lifted as soon as the
user changes the playback position in any manner.


5. User interface of spatial media fragment URI in <img> or <video>
resource, or in browser navigation:

Problem: what is a browser to display when the browser navigates to a
image or video resource with a spatial media fragment URI, or when the
@src attribute of a <img> or <video> element contains a spatial media
fragment URI

Proposal: a cropped (spliced) image or video is displayed to the user
by hiding the other pixels from the user.


6. User interface of track media fragment URI in <audio> or <video>
resource, or in browser navigation:

Problem: what is a browser to play back when the browser navigates to
a audio or video resource with a track media fragment URI, or when the
@src attribute of a <video> or <audio> element contains a track media
fragment URI

Proposal: The browser will only play back/decode the tracks that are
enumerated in the track media fragment URI. An example use case has
been shown at https://labs.ericsson.com/developer-community/blog/beyond-html5-conversational-voice-and-video-implemented-webkit-gtk.


These 6 bugs related to the feedback we gave on this HTML5 bug and we
need to follow up on them.

Happy to discuss later tonight.

Cheers,
Silvia.



2011/1/12 Raphaël Troncy <raphael.troncy@eurecom.fr>:
> Dear Silvia,
>
>> the Media Fragment URI bug for HTML5 has been rejected again, even if
>> only partially. We need to register some more bugs around it. I just
>> wanted to bring it into the discussion this week.
>
> Yes, we have discussed this in today's telecon. Basically, from
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723#c10:
>  - issue 1: we agree with Ian BUT I think he should also specify that the
> playback must stop at the end of the fragment (see also my comment 12)!
>  - issue 2: we defer the answer to this to you Silvia
>
> Silvia, you suggested to open more bugs as Ian complained we group them.
> Could you please write a mail to the group indicating which bugs you would
> like to be open together with a short text for each bug?
> Best regards.
>
>  Raphaël
>
> --
> Raphaël Troncy
> EURECOM, Multimedia Communications Department
> 2229, route des Crêtes, 06560 Sophia Antipolis, France.
> e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
> Tel: +33 (0)4 - 9300 8242
> Fax: +33 (0)4 - 9000 8200
> Web: http://www.eurecom.fr/~troncy/
>

Received on Wednesday, 2 February 2011 05:53:54 UTC