This is one of the corner cases with MF that has had me wondering what to do as an implementor. Lacking strong use cases, I would prefer that the loop attribute has no effect when used together with MF, to reduce the amount of magical state.

(In reply to comment #1)
> This is one of the corner cases with MF that has had me wondering what to do as
> an implementor. Lacking strong use cases, I would prefer that the loop
> attribute has no effect when used together with MF, to reduce the amount of
> magical state.

The strong use case is simply the replay. Someone has carefully defined a temporal media fragment that illustrates a funny moment and wants to bookmark/share it. The loop on this media fragment will be to play and replay just this bit. For example, I just want to see the "trip over" of this rider in the Tour de France: http://www.youtube.com/watch?v=XycqQr03ba8#t=4,15

(In reply to comment #2)
> (In reply to comment #1)
> > This is one of the corner cases with MF that has had me wondering what to do as
> > an implementor. Lacking strong use cases, I would prefer that the loop
> > attribute has no effect when used together with MF, to reduce the amount of
> > magical state.
> 
> The strong use case is simply the replay. Someone has carefully defined a
> temporal media fragment that illustrates a funny moment and wants to
> bookmark/share it. The loop on this media fragment will be to play and replay
> just this bit. For example, I just want to see the "trip over" of this rider in
> the Tour de France: http://www.youtube.com/watch?v=XycqQr03ba8#t=4,15

Personal preferences vary of course, but I'd prefer pressing play again to replay the video, nothing is funny enough to loop indefinitely. However, the issue is then what happens when you press play after pausing at the end of the fragment range. What's the thinking on that? The user either wants to watch from the beginning of range or keep watching past the end of the range, neither is obviously the Right Thing.

In a way, things would be a lot simpler API- and UI-wise if a temporal range was more of a crop than a focus. That's not a great user experience though, so I digress...

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > This is one of the corner cases with MF that has had me wondering what to do as
> > > an implementor. Lacking strong use cases, I would prefer that the loop
> > > attribute has no effect when used together with MF, to reduce the amount of
> > > magical state.
> > 
> > The strong use case is simply the replay. Someone has carefully defined a
> > temporal media fragment that illustrates a funny moment and wants to
> > bookmark/share it. The loop on this media fragment will be to play and replay
> > just this bit. For example, I just want to see the "trip over" of this rider in
> > the Tour de France: http://www.youtube.com/watch?v=XycqQr03ba8#t=4,15
> 
> Personal preferences vary of course, but I'd prefer pressing play again to
> replay the video, nothing is funny enough to loop indefinitely. However, the
> issue is then what happens when you press play after pausing at the end of the
> fragment range. What's the thinking on that? The user either wants to watch
> from the beginning of range or keep watching past the end of the range, neither
> is obviously the Right Thing�.
> 
> In a way, things would be a lot simpler API- and UI-wise if a temporal range
> was more of a crop than a focus. That's not a great user experience though, so
> I digress...

In my mind, a loop goes over the given resource, which in this case is the fragment. As soon as the user interacts with the resource, however, we break out of the loop state. For example, if the user pauses at the end, then the next 'play' will continue. Or if the user seeks anywhere, then we revert to the full timeline.

(In reply to comment #4)
> In my mind, a loop goes over the given resource, which in this case is the
> fragment. As soon as the user interacts with the resource, however, we break
> out of the loop state. For example, if the user pauses at the end, then the
> next 'play' will continue. Or if the user seeks anywhere, then we revert to the
> full timeline.

I was talking about the case when playback pauses at the end of the fragment range because it's the end, not because the user paused at that point.

Do you mean that *any* seeking, including within the fragment, should break the state and cause it to behave as if no fragment was specified at all?

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > This is one of the corner cases with MF that has had me wondering what to do as
> > > > an implementor. Lacking strong use cases, I would prefer that the loop
> > > > attribute has no effect when used together with MF, to reduce the amount of
> > > > magical state.
> > > 
> > > The strong use case is simply the replay. Someone has carefully defined a
> > > temporal media fragment that illustrates a funny moment and wants to
> > > bookmark/share it. The loop on this media fragment will be to play and replay
> > > just this bit. For example, I just want to see the "trip over" of this rider in
> > > the Tour de France: http://www.youtube.com/watch?v=XycqQr03ba8#t=4,15
> > 
> > Personal preferences vary of course, but I'd prefer pressing play again to
> > replay the video, nothing is funny enough to loop indefinitely. However, the
> > issue is then what happens when you press play after pausing at the end of the
> > fragment range. What's the thinking on that? The user either wants to watch
> > from the beginning of range or keep watching past the end of the range, neither
> > is obviously the Right Thing�.
> > 
> > In a way, things would be a lot simpler API- and UI-wise if a temporal range
> > was more of a crop than a focus. That's not a great user experience though, so
> > I digress...
> 
> In my mind, a loop goes over the given resource, which in this case is the
> fragment. As soon as the user interacts with the resource, however, we break
> out of the loop state.

s/loop/fragment/ - sorry

> For example, if the user pauses at the end, then the
> next 'play' will continue. Or if the user seeks anywhere, then we revert to the
> full timeline.

(In reply to comment #5)
> (In reply to comment #4)
> > In my mind, a loop goes over the given resource, which in this case is the
> > fragment. As soon as the user interacts with the resource, however, we break
> > out of the loop state. For example, if the user pauses at the end, then the
> > next 'play' will continue. Or if the user seeks anywhere, then we revert to the
> > full timeline.
> 
> I was talking about the case when playback pauses at the end of the fragment
> range because it's the end, not because the user paused at that point.
> 
> Do you mean that *any* seeking, including within the fragment, should break the
> state and cause it to behave as if no fragment was specified at all?

Yes, that would be my approach. OTOH, an explicit control of that state might be a good alternative.

(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > In my mind, a loop goes over the given resource, which in this case is the
> > > fragment. As soon as the user interacts with the resource, however, we break
> > > out of the loop state. For example, if the user pauses at the end, then the
> > > next 'play' will continue. Or if the user seeks anywhere, then we revert to the
> > > full timeline.
> > 
> > I was talking about the case when playback pauses at the end of the fragment
> > range because it's the end, not because the user paused at that point.
> > 
> > Do you mean that *any* seeking, including within the fragment, should break the
> > state and cause it to behave as if no fragment was specified at all?
> 
> Yes, that would be my approach. OTOH, an explicit control of that state might
> be a good alternative.

Having an invisible state that gets broken by any user interaction would no doubt confuse users, and having special UI to toggle that rather obscure state also doesn't seem like a nice thing to subject users to. I think either option is actually worse than not supporting loop at all.

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > In my mind, a loop goes over the given resource, which in this case is the
> > > > fragment. As soon as the user interacts with the resource, however, we break
> > > > out of the loop state. For example, if the user pauses at the end, then the
> > > > next 'play' will continue. Or if the user seeks anywhere, then we revert to the
> > > > full timeline.
> > > 
> > > I was talking about the case when playback pauses at the end of the fragment
> > > range because it's the end, not because the user paused at that point.
> > > 
> > > Do you mean that *any* seeking, including within the fragment, should break the
> > > state and cause it to behave as if no fragment was specified at all?
> > 
> > Yes, that would be my approach. OTOH, an explicit control of that state might
> > be a good alternative.
> 
> Having an invisible state that gets broken by any user interaction would no
> doubt confuse users, and having special UI to toggle that rather obscure state
> also doesn't seem like a nice thing to subject users to. I think either option
> is actually worse than not supporting loop at all.

Are you suggesting that when a @loop is given on a video for which a fragment is specified, we ignore @loop and just stop playing at the end of the fragment, no matter what? I don't think that meets the expectations of the developer.

(In reply to comment #9)
> Are you suggesting that when a @loop is given on a video for which a fragment
> is specified, we ignore @loop and just stop playing at the end of the fragment,
> no matter what? I don't think that meets the expectations of the developer.

Yes, because the alternatives I've seen so far seem even worse and the use cases for looping over a fragment don't seem very strong to begin with. For things like games that pack many sound effects into a single audio file to save network traffic I think that something like Mozilla's audio API that allows slicing and dicing the raw audio data is a good candidate.

(In reply to comment #10)
> (In reply to comment #9)
> > Are you suggesting that when a @loop is given on a video for which a fragment
> > is specified, we ignore @loop and just stop playing at the end of the fragment,
> > no matter what? I don't think that meets the expectations of the developer.
> 
> Yes, because the alternatives I've seen so far seem even worse and the use
> cases for looping over a fragment don't seem very strong to begin with. For
> things like games that pack many sound effects into a single audio file to save
> network traffic I think that something like Mozilla's audio API that allows
> slicing and dicing the raw audio data is a good candidate.

The use case for looping over a fragment are no worse than the use cases for looping over the complete video. I'm not a fan of that attribute myself, but it exists, it has an effect on video elements and it needs to show the expected effect when the resource is limited to a fragment, too, which should be looping over the fragment rather than the full video.

(In reply to comment #11)
> The use case for looping over a fragment are no worse than the use cases for
> looping over the complete video. I'm not a fan of that attribute myself, but it
> exists, it has an effect on video elements and it needs to show the expected
> effect when the resource is limited to a fragment, too, which should be looping
> over the fragment rather than the full video.

Not supporting it is nevertheless a valid option, just like the spec was just updated to not support looping for synchronized resources.

The only non-annoying use case for gapless looping that I know of is background music for games, and I don't think that MF is really helping that use case.

(In reply to comment #12)
> (In reply to comment #11)
> > The use case for looping over a fragment are no worse than the use cases for
> > looping over the complete video. I'm not a fan of that attribute myself, but it
> > exists, it has an effect on video elements and it needs to show the expected
> > effect when the resource is limited to a fragment, too, which should be looping
> > over the fragment rather than the full video.
> 
> Not supporting it is nevertheless a valid option, just like the spec was just
> updated to not support looping for synchronized resources.

If we find more and more use cases where we disallow @loop, we might as well completely remove it. You can always do the looping through JavaScript with direct setting of currentTime.

 
> The only non-annoying use case for gapless looping that I know of is background
> music for games, and I don't think that MF is really helping that use case.

Depends on how that music is given - if it's a fragment that needs looping, then it is a use case. But I don't even see @loop giving any advantage over setting currentTime in script - it won't be more gapless IIUC.

(In reply to comment #13)
> If we find more and more use cases where we disallow @loop, we might as well
> completely remove it. You can always do the looping through JavaScript with
> direct setting of currentTime.

In principle I would be fine with this. The only benefit of loop is that it can in theory be gapless, but I would really rather have a solution where one can achieve gapless playback between different resources rather than just within a single one. With adaptive streaming the low-level plumbing to be able to do that will have to exist anyway.

However, there are games that use looping audio for background music, so I also don't really mind keeping loop for the simple cases and just making it not work for the complex cases.

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: 

The spec is pretty clear, IMHO, that loop="" loops to the start of the track, and that the "end" part of a media fragment has no effect on media elements.

We can change that if there are compelling use cases, but I haven't seen any so far.

mass-moved component to LC1