665344 - Playback stutters near the end of some videos

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Sid]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110618 Firefox/7.0a1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110618 Firefox/7.0a1

Playback stutters near the end of any WebM video.

Reproducible: Always

Steps to Reproduce:
1. Download the WebM video from the attachment to your local machine.
2. Open it in Firefox.
3. For comparision, open this video in any media player software which supports WebM.

Actual Results:  
Playback stutters at the end of the video, it sounds like "Mmm...Nah-ah!"

Expected Results:  
Smooth playback, sounding like "Mmm...Nah!"

Comment 1

[Sid]

Attachment: Sample WebM video showing the problem

Comment 2

[Alex]

Firefox 7 x64 confirm

Comment 3

[Alice0775 White]

Confirmed on
http://hg.mozilla.org/mozilla-central/rev/0830b8ed9f02
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.2) Gecko/20110508 Firefox/7.0a1 ID:20110618030732

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/5212ab4ae808
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110202 Firefox/4.0b12pre ID:20110202155857
Fails:
http://hg.mozilla.org/mozilla-central/rev/d8fda3716eae
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110202 Firefox/4.0b12pre ID:20110202173919
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5212ab4ae808&tochange=d8fda3716eae

Comment 4

[H. Hofer]

SeaMonkey 2.4a1 (20110619003048) confirmed.

Comment 5

[Alice0775 White]

In local build:
build from ee00364d3092 : fails
build from 5212ab4ae808 : works

Triggered by
ee00364d3092	Chris Double — Bug 607838 - Allow audio drains to be interrupted - r=cpearce a=blocking2.0:final

Comment 6

[VeRtex]

Confirmed.
Mozilla/5.0 (Windows NT 6.2; rv:7.0a1) Gecko/20110618 Firefox/7.0a1

Intel Celeron 2.4Ghz (3.6Ghz), 1Gb RAM, HD4650 1Gb.
In Media Player Classic is played without stuttering.

Comment 7

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

This only happens on some WebM videos, not all.

Looks like we've got fewer than minWriteSamples of audio written to hardware when we wait for the stream to finish playing before we drain the audio stream.

Comment 8

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

Options to fix this:
1. Wait for the audio rewrite to land. Not sure how far off that will be.
2. Always write minWriteSamples worth of silence before going into the "sleep until end of audio" loop.
3. Add a sa_stream_flush() function which we call before going into the "sleep until end of audio" loop, that will perform the first half of sa_stream_drain() - on Linux, write minWriteSamples of silence if the stream isn't PREPARED, and on Windows, write the pending blocks.

Matthew: How long until the audio rewrite lands? Is it worth trying to fix this now?

Comment 10

[Matthew Gregan [:kinetik]]

It'll be up for review this week, so it's not worth fixing this independently.

Comment 11

[Sid]

Excuse me for nudging, but "this week" passed some time ago. Is it still planned to implement that audio rewrite thing? Can we expect it in Firefox 8?

Comment 12

[Matthew Gregan [:kinetik]]

The progress is in bug 623444, but it's taking longer than I estimated.  At this rate it is likely to be ready near the end of the Firefox 8 nightly cycle, so I would land it for Firefox 9 because it's far too risky to land at the end of a nightly cycle.

That leaves us with this bug, which we can wait on for one more cycle, or attempt to fix with one of the other options Chris laid out above.

Comment 13

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

Attachment: Patch: Ensure we've written minWriteSamples before sleeping in AudioLoop

Simple fix. Only sleep in AudioLoop() if we've written more than minWriteSamples since the last audio write.

I also changed the logic for sleeping when the AudioLoop() is ahead of the decode to also use this metric. Previously we'd only sleep if AudioLoop() had written at least minWriteSamples since the last sleep. 

I had tried using this second measure to fix the problem in this bug, but it didn't work reliably. I think this is because all the audio we wrote since the last sleep could have played by the time we come to evaluate this condition. The only time we really know how much unplayed audio we've written to the hardware is right after we write the unplayed audio to the hardware. So we should use this more reliable metric instead.

Comment 14

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

http://hg.mozilla.org/integration/mozilla-inbound/rev/4f62a0bb3a78

Comment 15

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/mozilla-central/rev/4f62a0bb3a78