Closed Bug 449157 Opened 12 years ago Closed 9 years ago

Implement the looping attributes in media elements

Categories

(Core :: Audio/Video, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla11

People

(Reporter: cajbir, Assigned: kinetik)

References

()

Details

(Keywords: dev-doc-complete)

Attachments

(1 file, 1 obsolete file)

start, loopstart, loopend, end, and playcount all control when the video is started, stopped and looped. These are currently unimplemented. See the spec in the URL.
Depends on: 449159
The attributes are currently being discussed in the WHATWG mailing list and may be removed. See the following thread:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016605.html
The attributes have been removed from the spec (r2401) and replaced by a single boolean |loop| attribute for infinite loops.[1]

[1] http://html5.org/tools/web-apps-tracker?from=2400&to=2401
Blocks: 457604
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Attached patch patch v0 (obsolete) — Splinter Review
Add support for loop attribute, remove obsolete attributes from old spec.

All that's left to do is verify that the correct events fire when playback loops, and write a test.
Is this going to be ready in time for Firefox 3.5?
No, 3.5 is frozen for the release candidate now, so new features are not being added.  Looping (and a few other video features) has been scheduled for the next release, which is why I've recently started working on it.
Can we see this feature for 3.5.1 or 3.5.2 ?
This feature will be in 3.6 (or whatever the next major release is called).

3.5.x will only receive security and critical fixes.  Looping can be achieved using scripting, so it would be very difficult to argue that native support counts as a critical fix for the 3.5.x release branch.
Flags: wanted1.9.2?
This seems like low-hanging fruit that we should get in.

It would be nice to have skip-free looping but doing it perfectly would be extremely hard --- requires decoding from the beginning of the stream before we actually seek back there. This patch alone is probably worth taking because it's at least as good as what you can do with script. We could improve it by doing the seek from the decoder thread so that if the data is in the media cache, we can loop without having to go back to the main thread.
Flags: wanted1.9.2? → wanted1.9.2+
Extremely hard, perhaps -- but essential, in my opinion, regardless whether or not the spec ever requires it.  I'm not even sure I'd advertise looping support in its absence, at least not without very prominent caveats about loop behavior not being skip-free.
I've had an idea about how to implement this skip-free without adding too much complexity. We could allow an HTMLMediaElement to have two nsMediaDecoders: the "current" decoder (today's mDecoder) and a "next" decoder. We now support cloning decoders and sharing the underlying cached data, so we could use that here. When the "current" decoder is near the end and "loop" is specified, we clone it to create the "next" decoder". The "next" decoder starts off paused, at position 0, but will automatically decode some frames into the frame queue (if it needs one). When the "current" decoder ends, we simply replace it with the "next" decoder and start playing.

Hmm, except that doesn't quite work. For total fidelity we need to actually wire together the audio queues and the video frame queues. Hmm.
Hopefully the internal looping routine will be gapless, at least for audio. As I understand, it is substantially easier to do this for ogg/vorbis than mp3.

The following wikipedia page lists players that support gapless playback. There are some open-source players on there. Maybe looking at their source code will be helpful?

http://en.wikipedia.org/wiki/Gapless_playback
I found a workaround for now with Firefox 3.6 and tested on Ubuntu Linux 8.04 at least. I used jQuery and had a routine like this in my HTML5 page:

<script type="text/javascript">
$().ready(function(){

$('#snd').bind('ended',{},function() {
  $(this).trigger('play');
});

});
</script>
<audio id="snd" src="fire.wav" autoplay="autoplay" playcount="9999" loop="true" />

In other words, I trapped the "ended" event, and made it trigger the play() method to start over again. This was similar to how sonny.piers' plugin worked when I cracked open his XPI file and poked around.
When this bug is fixed, the following test should pass:
(Note that the tests current sniff the user agent for Firefox--hopefully that'll be fixed soon.)

http://test.w3.org/html/tests/submission/Microsoft/video/video_005.htm
Still MIA in the Firefox 4 beta trunk loads.  The loop tag is in the HTML5 spec over at W3 - http://www.w3.org/TR/html5/video.html#attr-media-loop

There's an audio example over at http://forestmist.org/2010/04/html5-audio-loops/ as well as some work arounds.

The missing loop tag functionality is actually affecting developers trying to build HTML5 applications. See the "Issues" section on http://arandomurl.com/2010/07/25/html5-pacman.html
Duplicate of this bug: 589562
Also blocks ietestcenter.  Why can't I edit that?
Relevant url is:  http://samples.msdn.microsoft.com/ietestcenter/html5/MediaElements/media-rules-loop.htm
Assignee: kinetik → nobody
Two years and two months after the original bug was filed...and all the promotion that the Firefox folks are doing over HTML5 - it's REALLY bad that these video (and audio) tags and all of the associated JavaScript events are not working by now.

I had hoped to use both audio and video features in my entry for GameOn-2010 - but right now, the whole thing is just a mess.

This absolutely needs to be there for Firefox 4.0.
SteveBaker: Please read <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>, in particular "No pointless comments" and "No obligation". Thanks.
Resetting to NEW. Set back to ASSIGNED with an assignee, if you're working on
this.
Status: ASSIGNED → NEW
Whiteboard: [wanted2.1?]
Duplicate of this bug: 654787
The FishBowl (fhttp://people.mozilla.com/~jmuizelaar/fishbowl/fishbowl-gl.html) benchmark uses the 'loop' attribute. IE 9 and Chrome both implement it, we probably should too.
The new media infrastructure will make seamless looping much easier to implement.
Attached patch patch v1Splinter Review
I think it is a mistake not to support this until seamless looping is possible.  None of Chrome 17, Opera 11.52, Safari 5.1, or Internet Explorer 9 loop seamlessly.
Assignee: nobody → kinetik
Attachment #379389 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #575791 - Flags: review?(roc)
No longer depends on: 664918
Bug 654787 will track looping seamlessly.
Blocks: 654787
http://hg.mozilla.org/integration/mozilla-inbound/rev/40b854ef9e16
Whiteboard: [wanted2.1?]
Target Milestone: --- → mozilla11
https://hg.mozilla.org/mozilla-central/rev/40b854ef9e16
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a1) Gecko/20111127 Firefox/11.0a1
Mozilla/5.0 (Windows NT 6.1; rv:11.0a1) Gecko/20111127 Firefox/11.0a1
Mozilla/5.0 (Windows NT 5.1; rv:11.0a1) Gecko/20111127 Firefox/11.0a1
Mozilla/5.0 (X11; Linux x86_64; rv:11.0a1) Gecko/20111128 Firefox/11.0a1

Verified using the sites from comment #14 (http://test.w3.org/html/tests/submission/Microsoft/video/video_005.htm), comment #15 (http://forestmist.org/2010/04/html5-audio-loops/) and comment #22 (http://people.mozilla.com/~jmuizelaar/fishbowl/fishbowl-gl.html) and the test passed/audio looping seems to work fine. Still, on Linux there is a delay between loops.

Are there any other tests needed to verify the fix?
Thanks, there's a simple mochitest in the tree as well, so that should cover it.

The extended delay on Linux is bug 582513.  That'll be worked around when bug 623444 finally lands.
There's a prospective use case in Tumblr.  There are now two ways to inject the video tag into posts, and looped videos might compliment the love of animated gifs.  Demo: http://gchriss.tumblr.com/post/14899370892/demo-html5-video-tumblr

Also, Loop Method 1 from comment #15 fails on FF 9.0 / Linux.  The rest work as expected.
Depends on: 1213582
No longer depends on: 1213582
You need to log in before you can comment on or make changes to this bug.