496147 - Video playback finishes, but .ended == false and play/seek do nothing

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Paul Rouget [:paul]]

In some video (see URL), at the end of the video, it doesn't stop: the video stops playing, but the controls are not updated, and the 'ended' property is still 'false'.

Comment 1

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

Dolske: can you look? Don't think this blocks, but depends on why this video and no others?

Comment 2

[Nochum Sossonko [:Natch]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090602 Minefield/3.6a1pre

WFM...

Comment 3

[Ria Klaassen (not reading all bugmail)]

After the movie has ended and when the video is replayed, I see that the > symbol does not change to || when I click it for the first time.

Comment 4

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #3)

This was caused by Bug 470662.

Comment 5

[Justin Dolske [:Dolske]]

So, there are 2 different bugs here. The issue in comment 0, and the issue in comment 3.

I can only reproduce the problem described in comment 0 if I'm on Linux (OS X is fine) and I do *not* seek to skip towards the end. If you load the testcase, press play, and wait 32+ seconds until playback ends, the testcase indicates that .paused == false and .ended == false. That's wrong, because the video has clearly finished. Also, the icon on the play button doesn't change ("||" remains showing). You can click the button repeatedly, but the video never restarts from the beginning (although the button icon toggles).

If, however, you seek to near the end, things work as expected. The button icon changes, and clicking it starts playback from the beginning. However, you'll then see the problem Ria notes in comment 3 (on both OS X and Linux) -- the icon doesn't change after you click, because we never get a |play| event. I'm not sure if this is a core bug or controls bug... The video isn't paused when it ends, so I suppose you could argue that it shouldn't be expected to fire a |play| event. But it seems weird not to. In any case, I'll spin this off to another bug.

Comment 6

[Matthew Gregan [:kinetik]]

The first bug sounds like a core bug, since ended is not reflecting the correct
state.

The second bug is probably already filed as bug 490114.

> If, however, you seek to near the end, things work as expected. The button icon
> changes, and clicking it starts playback from the beginning. However, you'll
> then see the problem Ria notes in comment 3 (on both OS X and Linux) -- the
> icon doesn't change after you click, because we never get a |play| event. I'm
> not sure if this is a core bug or controls bug... The video isn't paused when
> it ends, so I suppose you could argue that it shouldn't be expected to fire a
> |play| event. But it seems weird not to. In any case, I'll spin this off to
> another bug.

It sounds like the controls should be listening for a |playing| event.

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

I can reproduce this on [Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090602 Shiretoko/3.5pre changest=1cd19a116fc0], i.e., I see ended=false when playback has ended.

I cannot reproduce this on [Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090604 Shiretoko/3.5pre changeset=28482a6f00d9].

Comment 8

[Christopher Blizzard (:blizzard)]

OK, so we can reproduce on at least Linux and Windows.

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

Looks like we're getting stuck in a play loop when there's no audio data in nsOggDecodeStateMachine::PlayFrame(). We're relying on the audio clock to determine when to break out of the loop, but the audio clock doesn't advance if we've got no audio data to play, so we loop until shutdown.

Comment 10

[Christopher Blizzard (:blizzard)]

Spinning 100% on the CPU or just waiting?

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

Waiting (usually the length of 1 frame, which is albeit pretty short) in a loop.

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #7)
> I cannot reproduce this on [Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.1pre) Gecko/20090604 Shiretoko/3.5pre changeset=28482a6f00d9].

But my Linux box doesn't have sound, so the a/v sync code won't sync off the audio clock, which is why I couldn't reproduce the bug on Linux.

Comment 13

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v1

* Break out of our play audio loop if we've not played any audio.

Comment 14

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #5)
> So, there are 2 different bugs here. The issue in comment 0, and the issue in
> comment 3.
> 
> [...] the testcase indicates
> that .paused == false and .ended == false. That's wrong

By my reading of the spec, .paused does not have to be true when we've reached the end of media. Please correct me if I'm wrong.

Comment 15

[Justin Dolske [:Dolske]]

Sorry, I wasn't precise. .paused==false is correct; it's the .ended==false that is wrong.

Comment 16

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

http://hg.mozilla.org/mozilla-central/rev/b9574b9d7690

Seems like it would be easy to write a test here.

Comment 17

[Karl Tomlinson (:karlt)]

(This was only fixed on trunk.)

Comment 18

[Karl Tomlinson (:karlt)]

wanted-1.9.1.x? for the symptoms reported in bug 499876.

Comment 20

[Samuel Sidler (old account; do not CC)]

cpearce: Is this worth taking on the 1.9.1 branch? If so, does your current patch apply?

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed on trunk with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090716 Minefield/3.6a1pre ID:20090716032118

Comment 22

[Rich Walsh]

As an alternative to applying this patch to v1.9.1, please see the consolidated patch attached to Bug 523770.