Closed Bug 665344 Opened 10 years ago Closed 10 years ago
Playback stutters near the end of some videos
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!"
Firefox 7 x64 confirm
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
SeaMonkey 2.4a1 (20110619003048) confirmed.
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
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.
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.
Summary: Playback stutters near the end of any WebM video → Playback stutters near the end of some WebM videos
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?
It'll be up for review this week, so it's not worth fixing this independently.
Depends on: cubeb
Summary: Playback stutters near the end of some WebM videos → Playback stutters near the end of some videos
Attachment #540320 - Attachment mime type: application/octet-stream → video/webm
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?
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.
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.
Assignee: nobody → chris
Status: NEW → ASSIGNED
Attachment #552282 - Flags: review?(kinetik)
Attachment #552282 - Flags: review?(kinetik) → review+
Target Milestone: --- → mozilla8
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.