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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723

--- Comment #6 from Philip Jägenstedt <philipj@opera.com> 2010-12-14 12:21:53 UTC ---
(In reply to comment #5)

> 1. URL in address bar
> 
> The means towards interpreting the fragment should be by starting to download
> the resource, then, as it is confirmed that it is a media resource, download
> will stop and byte range requests will be applied.

This kind of advice, if it should be given, should be in the MF spec.

> Note further that for any video or audio that is playing in this way, it makes
> sense to update the URL bar when pausing and to include the fragment offset,
> such that users can cut and paste the new URL for sharing.

We could make the context menu for <video> do this, but I don't think we want
the address bar to double as a playback progress indicator.

> Also, it might make
> sense to add the new URL to the browser history when pausing, allowing the user
> to jump back and forth between pause points through navigating the browser
> history.

Opera already does this, but it doesn't involve changing the URLs in history.
Rather, all the state is saved and restored when coming back, including the
last frame, volume and muted state. It's still a bit flaky, but mostly works.

> 2. URL in @src attribute of video/audio element
> 
> If the @controls attribute is given, there is a need to introduce markers for
> the fragment, see e.g. http://www.youtube.com/watch?v=LfRRYp6mnu0 for an
> example
> implementation.

Right, the HTML5 spec could mention this in the long enumeration of possible
control features.

> Note that if the @loop attribute is given, the fragment will loop and not the
> resource.

What should happen if the loop attribute is present, but the user seeks outside
the given fragment? Where should it seek when reaching the end of the resource?

> (2) Spatial Media Fragments
> 
> As per: http://www.w3.org/TR/media-frags/#naming-space
> Relevant to: images & video
> 
> Recommended approach to support spatial media fragments: CSS-like, i.e. hide
> unwanted pixels
> 
> A spatial media fragment URI can be used in the URL address bar or in the @src
> attribute of video/img element.
> 
> The user will expect a cropped (spliced) image/video display of the resource.

In other words, a spatial fragment should affect how
<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-video-intrinsic-width>
is interpreted. Still, it's something HTML5 shouldn't define normatively, as
the interpretation depends on the MIME type, at least in theory.

> (3) Track Fragments
> 
> As per: http://www.w3.org/TR/media-frags/#naming-track
> Relevant to: audio & video
> 
> Recommended approach to support track fragments: hide unwanted tracks
> 
> A track media fragment URI can be used in the URL address bar or in @src
> attribute of video/img element. One example use case has been shown at
> https://labs.ericsson.com/developer-community/blog/beyond-html5-conversational-voice-and-video-implemented-webkit-gtk.
> 
> The user will expect that only the enumerated tracks (audio, video, etc.) will
> be displayed.

I'm not sure there's any spec change needed here, from HTML's point of view the
resource is just one with fewer tracks. Again, the interpretation depends on
the MIME type, in theory.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 14 December 2010 12:21:56 UTC