W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > May 2011

[Bug 10723] <video> Support stopping at the time given by a media resource's fragment identifier

From: <bugzilla@jessica.w3.org>
Date: Mon, 09 May 2011 22:10:15 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QJYed-0007cN-HX@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX
  Status Whiteboard|                            |comment 12 describes the
                   |                            |specific problem that this
                   |                            |bug concerns

--- Comment #17 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-05-09 22:10:13 UTC ---
(In reply to comment #15)
> 
> 1.
> For example this site:
> http://eopas.rnld.unimelb.edu.au/transcripts/48#t=23.0,28.62
> (you will have to accept the cookie to get in and then reload that url)
> 
> This site publishes ethnographic audio & video recordings and allows jumping
> directly into segments of the content by start/end time. This is not only used
> for playback and research, but also for quoting when publishing research.

I don't think it makes sense to change the URL each time here. The page has a
long audio file with a set of segments that you can jump to. That makes sense,
and works fine. If you want a clean pause point, then I would argue the best
solution is to create a text track with a cue for each segment, with
pauseOnExit set to true.


> 2.
> Also this site:
> http://metavid.org/w/index.php?title=Stream:senate_proceeding_02-04-11/0:00:25/0:01:45&tl=1

This again seems to just be one media file with jumping to different segments.
You wouldn't want to replace the URL on the fly, that would trigger a file
reload each time.


> 3.
> Then of course there's the whole use case collection in the requirements doc,
> e.g.
> - search result:
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#scenario1.1

That's supported (jump to relevant point); you wouldn't want to stop playing
after the 1 second of playback that contained the search term!


> - pagination:
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#scenario2.1

That use case doesn't make any sense. Why would you require that someone do
something at the end of the 20 minutes to see more?


> - play bookmark fragments:
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#scenario2.2

Providing media fragment end support in the src="" attribute wouldn't fix this.


> - fragment mashup:
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#scenario3.3

If he uses SMIL, it works already, no need for a change to HTML.


(In reply to comment #16)
> I could add VideoSurf

I can't figure out a way to get this to stop before the end of the video. The
example URL you give just plays a YouTube clip from a point to the end.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: There are ot sufficiently compelling use cases for supporting
explicit stop points at the URL level in the src="" attribute of media
elements.

-- 
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 Monday, 9 May 2011 22:10:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:10 UTC