495300 - video hasn't really ended after seeking to end.

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Justin Dolske [:Dolske]]

Noticed this while poking at bug 495159:

While the video is paused, press End (or drag scrubber to the end), then press play. Playback should start from the beginning, but it does nothing. Clicking play a 2nd time works. [Clicking play after normal playback hits the end of the video works correctly the first time.] It looks like the seek to the end is actually seeking to the before the last frame...

For example, with the ScannerDarkly.ogv video, pressing End (while paused at the beginning) gives:

videoctl: Got keystroke: end
videoctl: Got media event ----> waiting
videoctl: Got media event ----> seeking
videoctl: Got media event ----> timeupdate
videoctl: time update @ 125083ms of 125100ms
videoctl: Got media event ----> seeked

and then pressing play gives:

videoctl: Got media event ----> play
videoctl: Got media event ----> waiting
videoctl: Got media event ----> ended
videoctl: time update @ 125083ms of 125100ms

and then pressing play a 2nd time starts playback from the beginning.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

When we seek to the end, we actually seek to the last frame and we don't go into the ended state. Maybe it's a bit weird to seek and then get an ended event even while you're paused. But if we don't do that, then we're stuck with the behaviour you see here. I'm not really sure what the spec wants us to do here.

Comment 2

[Justin Dolske [:Dolske]]

(In reply to comment #1)
> Maybe it's a bit weird to seek and then get an ended
> event even while you're paused.

Yeah, that could be a bit strange. Maybe only do that if the seek is > the duration? Or when setting .currentTime to +Inf? [The latter might be useful in for the edge case of getting to the end of a video of unknown duration.] It might be possible to hack around this in the controls by forcing a play() after a seek to the end, but that seems kind of ugly.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you raise it in the WHATWG or public-html list?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Actually I think the spec might imply we should treat a seek to the end as "ended". See "When the current playback position reaches the end of the media resource when the direction of playback is forwards, then the user agent must follow these steps:" ... the question is whether "reaches" includes seeking or just playback.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Hixie confirms that's the right interpretation. I'll work on a fix.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

This should fix it. However, it doesn't, because of a seeking/duration bug.

In seek.ogv, the reported duration is 3.833 seconds. My testcase actually seeks to 4.833 seconds, but this gets clamped to 3.833. Seeking finds a frame whose mDecodedFrameTime is 3.833 and stops there. However, there is a frame after that at mDecodedFrameTime 3.866, so my patch decides we're not at the end yet.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 380303 [details] [diff] [review]
fix

OK, with the patch in bug 495366, this patch fixes this bug.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 380303 [details] [diff] [review]
fix

This fix is reasonably simple, makes us conform to the spec and prevents some bad UI behaviour when the user seeks to the end of the stream.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

I'd support this if you're really sure that it's not going to cause any other sideeffects.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm pretty sure. It definitely only affects seeking and it only adds new code to the seeking path that's like code we already have there. If antying strange happens it's almost certainly going to be restricted to the case where we seek to the end.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 380303 [details] [diff] [review]
fix

a191=beltzner

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/513bc84a1492
Plus bustage fix:
http://hg.mozilla.org/mozilla-central/rev/52749323e947

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/8102152750e2

Comment 14

[Aakash Desai [:aakashd]]

verified FIXED on builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090602 Minefield/3.6a1pre ID:20090602050429

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090602 Shiretoko/3.5pre ID:20090602031310