Closed Bug 496147 Opened 12 years ago Closed 12 years ago

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

Categories

(Core :: Audio/Video, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: paul, Assigned: cpearce)

References

()

Details

Attachments

(1 file)

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'.
Flags: blocking1.9.1?
Dolske: can you look? Don't think this blocks, but depends on why this video and no others?
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090602 Minefield/3.6a1pre

WFM...
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.
(In reply to comment #3)

This was caused by Bug 470662.
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.
Summary: In some case, video is not stopped → Video playback finishes, but .ended == false and play/seek do nothing
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.
Flags: blocking1.9.1? → wanted1.9.1+
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].
OK, so we can reproduce on at least Linux and Windows.
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.
Assignee: nobody → chris
Spinning 100% on the CPU or just waiting?
Waiting (usually the length of 1 frame, which is albeit pretty short) in a loop.
(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.
Attached patch Patch v1Splinter Review
* Break out of our play audio loop if we've not played any audio.
Attachment #381449 - Flags: superreview?(roc)
Attachment #381449 - Flags: review?(chris.double)
Attachment #381449 - Flags: superreview?(roc) → superreview+
(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.
Sorry, I wasn't precise. .paused==false is correct; it's the .ended==false that is wrong.
Attachment #381449 - Flags: review?(chris.double) → review+
Whiteboard: [needs 191 approval]
http://hg.mozilla.org/mozilla-central/rev/b9574b9d7690

Seems like it would be easy to write a test here.
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
(This was only fixed on trunk.)
Version: 1.9.1 Branch → Trunk
wanted-1.9.1.x? for the symptoms reported in bug 499876.
Flags: wanted1.9.1.x?
Duplicate of this bug: 499876
cpearce: Is this worth taking on the 1.9.1 branch? If so, does your current patch apply?
status1.9.1: --- → ?
Flags: wanted1.9.1.x?
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
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9.2a1
As an alternative to applying this patch to v1.9.1, please see the consolidated patch attached to Bug 523770.
status1.9.1: ? → ---
Whiteboard: [needs 191 approval]
You need to log in before you can comment on or make changes to this bug.