Closed Bug 495300 Opened 12 years ago Closed 12 years ago

video hasn't really ended after seeking to end.


(Core :: Audio/Video, defect)

Not set





(Reporter: Dolske, Assigned: roc)



(Keywords: verified1.9.1)


(1 file)

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.
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.
(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.
Can you raise it in the WHATWG or public-html list?
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.
Hixie confirms that's the right interpretation. I'll work on a fix.
Assignee: nobody → roc
Attached patch fixSplinter Review
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 on attachment 380303 [details] [diff] [review]

OK, with the patch in bug 495366, this patch fixes this bug.
Attachment #380303 - Flags: review?(chris.double)
Attachment #380303 - Flags: review?(chris.double) → review+
Comment on attachment 380303 [details] [diff] [review]

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.
Attachment #380303 - Flags: approval1.9.1?
I'd support this if you're really sure that it's not going to cause any other sideeffects.
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 on attachment 380303 [details] [diff] [review]

Attachment #380303 - Flags: approval1.9.1? → approval1.9.1+
Whiteboard: [needs landing]
Plus bustage fix:
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 landing]
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


Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090602 Shiretoko/3.5pre ID:20090602031310
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2a1
You need to log in before you can comment on or make changes to this bug.