This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The media fragment WG wants to progress support for media fragment URIs in the @src attributes of media elements (audio, video, img). The group is working on making more concrete recommendations on what effect media fragment URIs should have in the realm of Web browsers and HTML5. It is envisaged that some spec text proposal will be added to this bug very soon which may have some proposed text to add to the fragment identifier section at http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid / http://dev.w3.org/html5/spec/Overview.html#scroll-to-fragid .
I look forward to the proposed text, because I don't really understand why this would be something the HTML spec would have to define. Fragment identifiers are defined on a per-MIME-type basis, so if you want e.g. image/png resources to have media fragment URLs, the solution is to update the image/png registration to define the fragment identifier part accordingly, while in parallel getting browsers to implement it. The HTML spec seems orthogonal.
Ian, Indeed, the URI RFC states that fragment identifiers are defined on a per-MIME-type basis. We have made an analysis to find out if there are any media types registered with IANA that contain information about how fragment/anchor identifiers are constructed for use in conjunction with this media type. as defined in RFC4288 (Media Type Specifications and Registration Procedures). As a matter of fact, almost none of the media type RFC states something about fragments. You can read about this analysis at http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaTypeReview Note that we have also an open issue about this in our tracker: http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/13 Having said this, the Media Fragment specification contains currently a note for implementers, read http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#implementor-notes that states how a UA (e.g. an HTML5 compliant browser) could render/display a media fragment. The Working Group is currently discussing whether we should describe or mandate particular behaviors depending on the UA. Some followers (of both groups) have expressed strong views on what a browser should do, such as highlighting or cropping an image in case of a spatial media fragment. Another possibility is to have a new attribute in the media element that indicate what a browser should do. This bug has been entered to discuss and resolve this issue.
What are the use-cases to do anything but crop? Cropping is needed for CSS spriting. Are there any significant number of existing pages that highlight a particular part of an image, and which could make good use of the ability to do that via fragments instead of JS? Keeping in mind that if they could do it with fragments, they probably would have zero control over styling, unless provision has been made for that. However, I don't see why this should differ for HTML UAs vs. other contexts involving URLs, so I don't see why it belongs in the HTML spec. In particular, why would the behavior in HTML differ from that for CSS applied to XML?
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: I'm closing this on the basis that it's out of scope for the HTML spec and should be handled by the URI and video format specs.
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.
(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.
(In reply to comment #6) > (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. It's not about playback progress. It's about fragment progress. People pause a video for a reason - the pause sets a marker to get back to later, or a marker to identify interesting bits to share with others, or a point where the viewer lost interest (and may want to get back to later). The intent with updating the URL is to provide what is natural in browser history to users, namely a location to get back to. You can try it for yourself at http://www.annodex.net/~silvia/a11y_bcp/demo1_navigation.html (even though that is an example of a web page rather than a video resource). > > 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. All the state, including the playback position and fragment? That sounds nice! > > 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. Yeah, sounds good. > > 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? I think there would be an inherent "am in fragment" state. Once the user breaks out of the fragment through whatever means, none of the fragment context is valid any longer, which includes loop boundaries. It goes back to the full video. > > (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. There are things defined in HTML5 that depend on a image mime type or on a text/html mime type. If something is relevant to HTML5, it should be there, even if it only applies to certain types of MIMEs. > > (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.
(In reply to comment #7) > (In reply to comment #6) > > (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. > > > It's not about playback progress. It's about fragment progress. People pause a > video for a reason - the pause sets a marker to get back to later, or a marker > to identify interesting bits to share with others, or a point where the viewer > lost interest (and may want to get back to later). The intent with updating the > URL is to provide what is natural in browser history to users, namely a > location to get back to. You can try it for yourself at > http://www.annodex.net/~silvia/a11y_bcp/demo1_navigation.html (even though that > is an example of a web page rather than a video resource). Ah, I missed the (critical) part about pausing. Agreed, this would be better than continuously updating the URL. > > > 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. > > All the state, including the playback position and fragment? That sounds nice! Yes, we try to make it so that a script that was running before the page was suspended and put into history won't notice that anything has happened when the page/script/video resumes. There are known bugs, but that's the idea. > > > 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? > > > I think there would be an inherent "am in fragment" state. Once the user breaks > out of the fragment through whatever means, none of the fragment context is > valid any longer, which includes loop boundaries. It goes back to the full > video. Works for me.
Please only file one issue per bug. What one issue is this bug raising?
(In reply to comment #9) > Please only file one issue per bug. What one issue is this bug raising? It seems that dealing with media fragment URIs has implications for several parts of the spec. The one issue is of course how to support media fragment URIs. But maybe we should now split it into several bugs now that the full set of consequences are being listed? My suggestion of first focus for this bug would be on what consequences the use of temporal media fragment URIs in a <video/audio @src> or <source @src> attribute has. Here are the consequences: 1. When a temporal media fragment URL is used in a video/audio element (e.g. http://ex.com/video.ogv#t=10,20), the media resource will start playing from fragment start time (10 in the example) and pause at end time (20 in the example) unless a @loop attribute is specified in which case the UA will repeat the fragment. If the user or JS interacts with the timeline of the media resource and jumps to a temporal location outside the fragment, the fragment context is broken and the full resource is regarded again, in particular a @loop will loop over the full resource again. 2. If the @controls attribute is given and a temporal media fragment URI is loaded, there is a need to introduce markers on the controls for the fragment, see e.g. http://www.youtube.com/watch?v=LfRRYp6mnu0 for an example implementation. Do you want me to open new bugs for the other issues?
That's still two issues. Please only file one issue per bug. An issue is the atomic unit of complaint that one could have. If you find yourself writing a numbered list, you almost certainly have more than one issue. For comment 10 issue 1: the spec already says as much as it needs to say on the subject: "If either the media resource or the address of the current media resource indicate a particular start time, then set the initial playback position to that time and then seek seek to that time." (in the resource fetch algorithm) For comment 10 issue 2: that's a browser UI issue and out of scope of specs such as HTML. I suspect the same applies to many, if not all, of the other issues listed in comment 5, but I haven't studied them in detail. 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: see above
(In reply to comment #11) > For comment 10 issue 1: the spec already says as much as it needs to say on the > subject: "If either the media resource or the address of the current media > resource indicate a particular start time, then set the initial playback > position to that time and then seek seek to that time." (in the resource fetch > algorithm) A media fragment has a start time and a stop time. Should you not write as well that the playback MUST stop at the end of the fragment and not at the end of the media resource?
Reopening to get an answer to the point about the end time. Temporal Media Fragment URIs provide end times as well as start times, which is not satisfied by only seeking to a start time offset.
What is the use case? Do you have examples of sites today that use this with Flash? (I'm aware of examples of sites that support the start-time feature.)
(In reply to comment #14) > What is the use case? Do you have examples of sites today that use this with > Flash? (I'm aware of examples of sites that support the start-time feature.) 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. 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 site publishes long videos (recordings of senate sittings) and allows direct access and embedding of snippets. While the URL scheme does not conform to the spec of the W3C Media Fragments WG, the idea is the same: have a start and end time in the URL. 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 - pagination: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#scenario2.1 - play bookmark fragments: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#scenario2.2 - fragment mashup: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#scenario3.3
(In reply to comment #14) > What is the use case? Do you have examples of sites today that use this with > Flash? (I'm aware of examples of sites that support the start-time feature.) Silvia provided many examples. I could add VideoSurf that allows to specify a beginning time AND a ending time, e.g. http://www.videosurf.com/video/michael-jordan-1989-playoffs-gm-5-vs-cavs-the-shot-904591?t=140&e=184. They use this feature to build visual summaries, extracting particular sequences out of videos. There are many other examples out there that allow to specify a end-time.
(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.
Some clarifications: (In reply to comment #17) > (In reply to comment #15) > > > > 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. No it doesn't. Browsers have stopped reloading resources where just the fragment is changed and not the actual resource URL. The way in which media fragment URIs are specified plays with that fact, too. Unless the resource has expired, it will only request the appropriate byte ranges for the time range specified in the URL. > > 3. > > Then of course there's the whole use case collection in the requirements doc, > > e.g. > > - 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? Because the video is 7 hours long and has annotations that are displayed with it. There is only a certain amount of content that you can place on a single Web page before it gets too cluttered to be useful. Annotations for 20 min of video (navigable timed transcript in particular) are roughly the limit. You can see that at work on http://metavid.org/ - it already implements exactly that use case. But it has to virtually chunk the media on the server to 20 min chunks (using a Apache plugin), which makes it slow and not scalable. > > - 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. Which browsers support SMIL out of the box? So, let's abstract away from SMIL, which is overkill for this use case anyway (and I don't actually remember why a technology was used in a use case description...). The point is that you can easily imagine a playlist format that essentially consists of a sequence of media fragment URIs with start and end time that the browser loads one after the other - every time the end of a fragment is reached, the next resource fragment is started playing. === It is always possible to reject any use cases for end points on media fragment URIs in a video's @src attribute by saying that you can use JavaScript to catch that position and do something (pause / load a different resource etc). Even using MutableTimedText for controlling what to do at the end of a fragment would require JavaScript. The issue, however, is that you are always working on a fragment. If we do not support end times in media fragment URIs, we implicitly specify that the end time is the end time of the media resource. We cannot always expect a JavaScript solution to be around for doing media fragments, e.g. outside browsers. Such applications can only use media fragment URIs to restrict both the start and end time of a media resource. It makes sense to align the behaviour now.
(In reply to comment #18) > Some clarifications: > > (In reply to comment #17) > > (In reply to comment #15) > > > > > > 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. > > No it doesn't. Browsers have stopped reloading resources where just the > fragment is changed and not the actual resource URL. The way in which media > fragment URIs are specified plays with that fact, too. Unless the resource has > expired, it will only request the appropriate byte ranges for the time range > specified in the URL. Which browsers? Is the special-casing when the src attribute is set, or is it part of the resource selection algorithm (which is run asynchronously as a result of setting src)?
(In reply to comment #19) > (In reply to comment #18) > > Some clarifications: > > > > (In reply to comment #17) > > > (In reply to comment #15) > > > > > > > > 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. > > > > No it doesn't. Browsers have stopped reloading resources where just the > > fragment is changed and not the actual resource URL. The way in which media > > fragment URIs are specified plays with that fact, too. Unless the resource has > > expired, it will only request the appropriate byte ranges for the time range > > specified in the URL. > > Which browsers? Is the special-casing when the src attribute is set, or is it > part of the resource selection algorithm (which is run asynchronously as a > result of setting src)? I was talking generally - when you change the fragment on a Web page in the URL bar, the Web page is not reloaded any more, but only the fragment offset is changed. As for video, there is no implementation yet, so of course I'm not referring to implemented cases there. But the way in which media fragment URIs are specified implies that if the browser has setup information about the resource (i.e. metadata loaded), then it will use that for further fragment retrieval actions. So, basically it works like setting the currentTime to a different location on the same resource. I think that would be outside the resource selection algorithm, which would not be re-run for a change of fragment unless the resource has expired in the meantime.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > > > Some clarifications: > > > > > > (In reply to comment #17) > > > > (In reply to comment #15) > > > > > > > > > > 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. > > > > > > No it doesn't. Browsers have stopped reloading resources where just the > > > fragment is changed and not the actual resource URL. The way in which media > > > fragment URIs are specified plays with that fact, too. Unless the resource has > > > expired, it will only request the appropriate byte ranges for the time range > > > specified in the URL. > > > > Which browsers? Is the special-casing when the src attribute is set, or is it > > part of the resource selection algorithm (which is run asynchronously as a > > result of setting src)? > > I was talking generally - when you change the fragment on a Web page in the URL > bar, the Web page is not reloaded any more, but only the fragment offset is > changed. > > As for video, there is no implementation yet, so of course I'm not referring to > implemented cases there. But the way in which media fragment URIs are specified > implies that if the browser has setup information about the resource (i.e. > metadata loaded), then it will use that for further fragment retrieval actions. > So, basically it works like setting the currentTime to a different location on > the same resource. I think that would be outside the resource selection > algorithm, which would not be re-run for a change of fragment unless the > resource has expired in the meantime. That might be the intention, but if we want changes of src that only change the fragment component to be handled differently, it has to be in the HTML spec. If not, it will be treated as any other change of the src attribute and cause all state to be reset and fetching/decoding to start over. (Currently even setting v.src=v.src isn't handled, it would be similar to calling load().)
(In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #19) > > > (In reply to comment #18) > > > > Some clarifications: > > > > > > > > (In reply to comment #17) > > > > > (In reply to comment #15) > > > > > > > > > > > > 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. > > > > > > > > No it doesn't. Browsers have stopped reloading resources where just the > > > > fragment is changed and not the actual resource URL. The way in which media > > > > fragment URIs are specified plays with that fact, too. Unless the resource has > > > > expired, it will only request the appropriate byte ranges for the time range > > > > specified in the URL. > > > > > > Which browsers? Is the special-casing when the src attribute is set, or is it > > > part of the resource selection algorithm (which is run asynchronously as a > > > result of setting src)? > > > > I was talking generally - when you change the fragment on a Web page in the URL > > bar, the Web page is not reloaded any more, but only the fragment offset is > > changed. > > > > As for video, there is no implementation yet, so of course I'm not referring to > > implemented cases there. But the way in which media fragment URIs are specified > > implies that if the browser has setup information about the resource (i.e. > > metadata loaded), then it will use that for further fragment retrieval actions. > > So, basically it works like setting the currentTime to a different location on > > the same resource. I think that would be outside the resource selection > > algorithm, which would not be re-run for a change of fragment unless the > > resource has expired in the meantime. > > That might be the intention, but if we want changes of src that only change the > fragment component to be handled differently, it has to be in the HTML spec. If > not, it will be treated as any other change of the src attribute and cause all > state to be reset and fetching/decoding to start over. (Currently even setting > v.src=v.src isn't handled, it would be similar to calling load().) OK, well this is a problem with just start time offsets, too. I've registered a new bug for this over in bug 12643.
mass-moved component to LC1