Playback stutters near the end of some videos

RESOLVED FIXED in mozilla8



8 years ago
7 years ago


(Reporter: sidrabbit, Assigned: cpearce)



Windows 7
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)



(2 attachments)



8 years ago
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

8 years ago
Created attachment 540320 [details]
Sample WebM video showing the problem

Comment 2

8 years ago
Firefox 7 x64 confirm

Comment 3

8 years ago
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

8 years ago
SeaMonkey 2.4a1 (20110619003048) confirmed.

Comment 5

8 years ago
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
Blocks: 607838
Ever confirmed: true
Keywords: regression

Comment 6

8 years ago
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.
Version: unspecified → Trunk

Comment 7

8 years ago
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

Comment 8

8 years ago
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?
Duplicate of this bug: 650193
It'll be up for review this week, so it's not worth fixing this independently.
Depends on: 623444
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

Comment 11

8 years ago
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.

Comment 13

8 years ago
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.
Assignee: nobody → chris
Attachment #552282 - Flags: review?(kinetik)
Attachment #552282 - Flags: review?(kinetik) → review+

Comment 14

8 years ago
Whiteboard: [inbound]
Target Milestone: --- → mozilla8
Last Resolved: 8 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [inbound]
No longer depends on: 623444
You need to log in before you can comment on or make changes to this bug.