Last Comment Bug 665344 - Playback stutters near the end of some videos
: Playback stutters near the end of some videos
: regression
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: Trunk
: x86 Windows 7
: -- normal with 3 votes (vote)
: mozilla8
Assigned To: Chris Pearce (:cpearce)
: Maire Reavy [:mreavy]
: 650193 (view as bug list)
Depends on:
Blocks: 607838
  Show dependency treegraph
Reported: 2011-06-19 05:21 PDT by Sid
Modified: 2011-12-01 17:02 PST (History)
9 users (show)
khuey: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Sample WebM video showing the problem (137.98 KB, video/webm)
2011-06-19 05:22 PDT, Sid
no flags Details
Patch: Ensure we've written minWriteSamples before sleeping in AudioLoop (5.26 KB, patch)
2011-08-10 18:07 PDT, Chris Pearce (:cpearce)
kinetik: review+
Details | Diff | Splinter Review

Description Sid 2011-06-19 05:21:19 PDT
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 2011-06-19 05:22:20 PDT
Created attachment 540320 [details]
Sample WebM video showing the problem
Comment 2 Alex 2011-06-19 05:36:53 PDT
Firefox 7 x64 confirm
Comment 3 Alice0775 White 2011-06-19 06:16:28 PDT
Confirmed on
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.2) Gecko/20110508 Firefox/7.0a1 ID:20110618030732

Regression window:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110202 Firefox/4.0b12pre ID:20110202155857
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110202 Firefox/4.0b12pre ID:20110202173919
Comment 4 H. Hofer 2011-06-19 06:53:33 PDT
SeaMonkey 2.4a1 (20110619003048) confirmed.
Comment 5 Alice0775 White 2011-06-19 07:29:08 PDT
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 2011-06-19 09:12:33 PDT
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) 2011-06-19 15:12:46 PDT
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) 2011-06-19 16:04:04 PDT
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 9 Matthew Gregan [:kinetik] 2011-06-19 16:42:10 PDT
*** Bug 650193 has been marked as a duplicate of this bug. ***
Comment 10 Matthew Gregan [:kinetik] 2011-06-19 16:44:23 PDT
It'll be up for review this week, so it's not worth fixing this independently.
Comment 11 Sid 2011-07-29 08:30:32 PDT
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] 2011-08-04 20:21:13 PDT
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) 2011-08-10 18:07:21 PDT
Created attachment 552282 [details] [diff] [review]
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 15 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-16 04:12:58 PDT

Note You need to log in before you can comment on or make changes to this bug.