This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Over in bug 10723 we discussed about what should happen when browsers find a media fragment URI in the @src of a media element. We stumbled across the question of what browsers are supposed to do when the @src is changed by script, but only the fragment of the URL changes. Currently, it seems that even setting v.src=v.src triggers a full new run of the source selection algorithm and with it all the associated network activity and events. We've solved this problem for HTML pages and fragment addressing in http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid But we haven't solved it for media resources (or image resources for that matter). What should v.src=s.src do? What should a change from http://example.com/video.ogv#t=20 to http://example.com/video.ogv#t=50 do? I think just like it is preferable for HTML resources to not retrieve the resource again, the same applies to media resources. v.src = v.src should probably just seek to the beginning of the resource, and a change of the fragment time should just do a change of the currentTime, too.
"What's the use case?" When navigating directly to a media resource, I can see the argument that changing the fragment component can be used to trim down the fragment by testing successively smaller ranges. Are there other cases? Is it critical in this situation that the video is never reloaded or has its state reset? The time to decode and seek to a certain point in a file is rather small even without this optimization. For <video> elements in an HTML document, the utility of dynamically changing the fragment is less obvious. Does it side-step the resource selection algorithm? Does it cause currentTime to change? More generally, it seems like a very cumbersome interface for whatever it is it should achieve. If you have <source> elements, you'd have to change the src attribute on all of them and then call load(). Should that side-step the resource selection algorithm and how? IMO it might be easier to work with if there were IDL attributes startTime and endTime, or if a fragment implicitly creates a cue range with pauseOnExit set which could then be manipulated by scripts. But, without a clear understanding of the use cases I'm just guessing...
(In reply to comment #1) > "What's the use case?" > > When navigating directly to a media resource, I can see the argument that > changing the fragment component can be used to trim down the fragment by > testing successively smaller ranges. Are there other cases? Is it critical in > this situation that the video is never reloaded or has its state reset? The > time to decode and seek to a certain point in a file is rather small even > without this optimization. This refers to changes in the URL bar, right? I would e.g. use the seek bar to find a specific position (region), then change/add the fragment with that position (region), test it, and cut and paste it to send it to friends. Any re-load of a media resource is annoying when it's not necessary. I've seen video loads that have taken several minutes on a poor connection, so I'd really like to avoid that. > For <video> elements in an HTML document, the utility of dynamically changing > the fragment is less obvious. Yes, in <video> it is not so obvious, because you can obviously just change currentTime to achieve the time offset effect. But if we support fragments in @src, it's a technical problem to solve. Note that the same applies to a change of track fragments on videos, which are important for multitrack media. > Does it side-step the resource selection > algorithm? Does it cause currentTime to change? More generally, it seems like a > very cumbersome interface for whatever it is it should achieve. If you have > <source> elements, you'd have to change the src attribute on all of them and > then call load(). I think script would just set @src to @currentSrc replacing/adding the fragment. > Should that side-step the resource selection algorithm and > how? I think it should just do the part that it does when interpreting a fragment and bypass any earlier steps in the resource selection algorithm.
(In reply to comment #2) > (In reply to comment #1) > > "What's the use case?" > > > > When navigating directly to a media resource, I can see the argument that > > changing the fragment component can be used to trim down the fragment by > > testing successively smaller ranges. Are there other cases? Is it critical in > > this situation that the video is never reloaded or has its state reset? The > > time to decode and seek to a certain point in a file is rather small even > > without this optimization. > > This refers to changes in the URL bar, right? I would e.g. use the seek bar to > find a specific position (region), then change/add the fragment with that > position (region), test it, and cut and paste it to send it to friends. Yes, that's the use case I was guessing. Are there others? > Any re-load of a media resource is annoying when it's not necessary. I've seen > video loads that have taken several minutes on a poor connection, so I'd really > like to avoid that. As long as the browser doesn't aggressively evict media resources from the cache, this would work. The only repeated work is decoding the metadata of the resource. If this is really a problem, I think the best solution is to cache this information as well, as this would be useful for pages that uses 10 instances of the same audio file for effects, etc. > > For <video> elements in an HTML document, the utility of dynamically changing > > the fragment is less obvious. > > Yes, in <video> it is not so obvious, because you can obviously just change > currentTime to achieve the time offset effect. But if we support fragments in > @src, it's a technical problem to solve. Note that the same applies to a change > of track fragments on videos, which are important for multitrack media. Good point, but in that case you really do want to reset the state and set up a new decoding pipeline, don't you? Or do you think that this should change the current track without even resetting currentTime? > > Does it side-step the resource selection > > algorithm? Does it cause currentTime to change? More generally, it seems like a > > very cumbersome interface for whatever it is it should achieve. If you have > > <source> elements, you'd have to change the src attribute on all of them and > > then call load(). > > I think script would just set @src to @currentSrc replacing/adding the > fragment. Yeah, that would work. Note however that it would create an invalid DOM, as <source> elements are only allowed as children of <video> elements without src attribute. > > Should that side-step the resource selection algorithm and > > how? > > I think it should just do the part that it does when interpreting a fragment > and bypass any earlier steps in the resource selection algorithm. My point here was that currently changing the src attribute on <source> elements has no effect, the only way currently is to call load() when you're done manipulating them. This *will* invoke the resource selection algorithm, so I can't see how to side-step it.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > > For <video> elements in an HTML document, the utility of dynamically changing > > > the fragment is less obvious. > > > > Yes, in <video> it is not so obvious, because you can obviously just change > > currentTime to achieve the time offset effect. But if we support fragments in > > @src, it's a technical problem to solve. Note that the same applies to a change > > of track fragments on videos, which are important for multitrack media. > > Good point, but in that case you really do want to reset the state and set up a > new decoding pipeline, don't you? Or do you think that this should change the > current track without even resetting currentTime? I think for any change of fragment that doesn't indicate a time offset, we have to reset to currentTime=0. Including v.src=v.src. I don't think we need to re-load the resource even for a track change. > > > Does it side-step the resource selection > > > algorithm? Does it cause currentTime to change? More generally, it seems like a > > > very cumbersome interface for whatever it is it should achieve. If you have > > > <source> elements, you'd have to change the src attribute on all of them and > > > then call load(). > > > > I think script would just set @src to @currentSrc replacing/adding the > > fragment. > > Yeah, that would work. Note however that it would create an invalid DOM, as > <source> elements are only allowed as children of <video> elements without src > attribute. That's a more general problem of how to change the media resource on a media element through script. This problem already exists even without fragments. > > > Should that side-step the resource selection algorithm and > > > how? > > > > I think it should just do the part that it does when interpreting a fragment > > and bypass any earlier steps in the resource selection algorithm. > > My point here was that currently changing the src attribute on <source> > elements has no effect, the only way currently is to call load() when you're > done manipulating them. This *will* invoke the resource selection algorithm, so > I can't see how to side-step it. I meant what happens when a resource is loaded initially as part of the video element setup. At some point the fragment URI part is being interpreted (in fact: point 8 in http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#getting-media-metadata). We should just jump to that point when changing the fragment on the URI.
(In reply to comment #4) > I think for any change of fragment that doesn't indicate a time offset, we have > to reset to currentTime=0. Including v.src=v.src. I don't think we need to > re-load the resource even for a track change. Do you mean re-load as in re-transferring data over the network? If so, that can be avoided simply by caching. If you mean going through the resource selection algorithm again, I'm not sure I see why that would be a problem. At large, I have yet to see (or understand) a case where it's not sufficient to just go through the resource selection algorithm again and treat it as a quality-of-implementation issue how well a browser is able to reuse the data and decoding pipelines it already has.
(In reply to comment #5) > At large, I have yet to see (or understand) a case where it's not sufficient to > just go through the resource selection algorithm again and treat it as a > quality-of-implementation issue how well a browser is able to reuse the data > and decoding pipelines it already has. At the risk of sounding like all I ever do is agree with Philip, I agree with this. Given that all the data is cached, this should be fast.
(In reply to comment #6) > (In reply to comment #5) > > At large, I have yet to see (or understand) a case where it's not sufficient to > > just go through the resource selection algorithm again and treat it as a > > quality-of-implementation issue how well a browser is able to reuse the data > > and decoding pipelines it already has. > > At the risk of sounding like all I ever do is agree with Philip, I agree with > this. Given that all the data is cached, this should be fast. (In reply to comment #5) > (In reply to comment #4) > > > I think for any change of fragment that doesn't indicate a time offset, we have > > to reset to currentTime=0. Including v.src=v.src. I don't think we need to > > re-load the resource even for a track change. > > Do you mean re-load as in re-transferring data over the network? If so, that > can be avoided simply by caching. If you mean going through the resource > selection algorithm again, I'm not sure I see why that would be a problem. > > At large, I have yet to see (or understand) a case where it's not sufficient to > just go through the resource selection algorithm again and treat it as a > quality-of-implementation issue how well a browser is able to reuse the data > and decoding pipelines it already has. Ah, maybe we were talking past each other. All I want to avoid is a retransfer of data over the network and reparsing of the media file. Maybe then I agree, too. :-)
mass-moved component to LC1
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: If you don't want to reload the file, don't change the URL. That's what changing the URL does for pretty much every similar feature in HTML.
Ian, It seems you haven't paid much attention to what is discussed in this thread. You write: "If you don't want to reload the file, don't change the URL. That's what changing the URL does for pretty much every similar feature in HTML." but we are talking of changing only the fragment part of the URL not the full URL. When you change the fragment of an HTML document, the immediate result is to scroll to another section of this document and certainly not to reload the whole resource. The question raised in his thread is: what should a change from http://example.com/video.ogv#t=20 to http://example.com/video.ogv#t=50 do when this url is the src of a <video> element? Perhaps this is a non-problem as Philip and Chris have argued earlier: at some point the fragment URI part is being interpreted (in fact: point 8 in http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#getting-media-metadata) and we should just specify that the user agent will jump to that point when changing the fragment on the URI. I would like a confirmation that the resource selection algorithm is sufficiently described for this. But your current response is just not relevant.
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 did read the thread. Fragment, path, any part of the URL. Doesn't matter. In all cases of an embedded resource, changing the URL whether a fragment or otherwise reloads the page. This is true for everything: <iframe>, <img>, <embed>, <style>, etc. The only exception I can think of is <script> and that's only because it doesn't do anything at all when you change the URL. The Location object is an API and is not analogous to changing the <video> element's src="" attribute.