W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2010

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 14 Dec 2010 11:52:26 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PSTQg-0004a4-Rs@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723

RaphaŽl Troncy <raphael.troncy@eurecom.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #5 from RaphaŽl Troncy <raphael.troncy@eurecom.fr> 2010-12-14 11:52:26 UTC ---
The Media Fragments WG would like to re-open this bug entry. We further detail
below why we think this bug impacts HTML5 and its interaction with the Media
Fragments URI specification.

(1) Temporal Media Fragments

As per: http://www.w3.org/TR/media-frags/#naming-time
Relevant to: audio & video

Recommended approach to support temporal media fragments: byte range requests,
see http://www.w3.org/TR/media-frags/#URIfragment-user-agent

Two uses:
1. URL in address bar

When a media fragment URL is pasted into a Web browser address bar and the
browser is able to decode the media resource, the user should see a video or
audio file that starts playing from the fragment start time and stops at end
time. Also, since the browser will display controls, we need to introduce
markers on the controls for the fragment, see
http://www.youtube.com/watch?v=LfRRYp6mnu0 for an example implementation.

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.

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

2. URL in @src attribute of video/audio element

When a media fragment URL is used in a video/audio element, the user will
similarly expect the media resource to start playing from fragment start time
and stops at end time.

If no @controls attribute is given, this equates to playing back a media
fragment without context and may be useful for video editing applications or
playlists of media snippets (so-called mash-ups).

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.

Note that if the @loop attribute is given, the fragment will loop and not 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.

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

-- 
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 11:52:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:35 UTC