html5 ogg media does not resume reliably after buffering

Bug #450684 reported by Darren Thiessen on 2009-10-13
This bug affects 16 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
firefox (Ubuntu)

Bug Description

Binary package hint: firefox-3.5

If I try to play a ogg theora video in Firefox 3.5.3 it usually (9 times out of 10) pauses due to buffering but never properly resumes playing...even if the video finishes downloading. Hitting the pause/play button or seeking to another position has no effect. I have tried multiple videos from different sites around the web all with the same issue. I am using Karmic now but had the same problem in Jaunty. I tried to reproduce this bug in windows (firefox 3.5) but video playback worked flawlessly. I also tried chromium which had no issue with buffering, pausing, or seeking to a different spot in the video.

Other Info

Description: Ubuntu karmic (development branch)
Release: 9.10

  Installed: 3.5.3+build1+nobinonly-0ubuntu3
  Candidate: 3.5.3+build1+nobinonly-0ubuntu3
  Version table:
 *** 3.5.3+build1+nobinonly-0ubuntu3 0
        500 karmic/main Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
Architecture: i386
Date: Tue Oct 13 13:48:50 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: firefox (not installed)
ProcVersionSignature: Ubuntu 2.6.31-13.45-generic
SourcePackage: firefox-3.5
Uname: Linux 2.6.31-13-generic i686

Darren Thiessen (pilotman) wrote :

This appears to be linux-specific. Can't reproduce on Win 7.

Run a 3.6 nightly and loading the URL above it will start playing when the page loads, but if you pause and restart it a few times it will eventually stop playing once you unpause. Sometimes it's one click, sometimes it's three.

Running this on Fedora 11. Will check for a regression from 3.5.

Affects 3.5 on Fedora 11 as well.

Possibly related to bug 525401?

Mozilla Firefox 3.5.5 on Ubuntu GNU/Linux 9.10 x86_64

any additional info needed?

It happens every time I toggle a playing video. Press play, press pause - video is stuck. Otherwise, videos play/seek perfectly.

By 'stuck' I mean that UI (controls) is responsive, but there is no reaction from video/audio.

When the video is stuck, I can issue .load() and it successfully restarts from the beginning. Choosing 'Full Screen' from the context menu helps as well - video resumes (but pressing pause, play makes it stuck again).

I'm on Linux x86_64, have reproduced this with Firefox 3.5.5 and a current (Nov 18) 3.6b4pre nightly. Funny, but I can't reproduce this on Firefox launched through X11 Forwarding (ssh).

It happens with any video I choose (even videos in local disk, referenced via src="file://..."), e.g.:

Same here on fedora 12 Firefox 3.6 Beta 3, experiencing the problem with audio (haven't tested with video): as soon as I pause a track, it will never resume playback on play, neither via the default controls nor via javascript.

*** Bug 530623 has been marked as a duplicate of this bug. ***

I'm not sure if this is related to bug 525401, but I've pushed a potential fix for that bug to the try server. You can get a copy of the build to test with from https://<email address hidden>/

In , j^ (j) wrote :

(In reply to comment #7)
> https://<email address hidden>/
does not change anything here, local files will still not play again after pressing pause the first time.

*** Bug 533562 has been marked as a duplicate of this bug. ***

*** Bug 527450 has been marked as a duplicate of this bug. ***

Doesn't our test plan include pausing and playing? Given that blizzard can repro it on his machine on 3.5, and also trunk, how did we ship 3.5 with a bug this big? :-((

Anything I can do to help debug it?


(In reply to comment #11)
> Doesn't our test plan include pausing and playing? Given that blizzard can
> repro it on his machine on 3.5, and also trunk, how did we ship 3.5 with a bug
> this big? :-((

If this is an audio underrun, the reason our tests don't pick this up is because the tinderbox test machines don't have audio, they do timing off the system clock and so audio underruns can't happen.

It's also dependent on what audio system they're using. I'm not using PulseAudio on my Linux system and it works fine for me.

Note that I have been able to reproduce this on Windows, although it's very rare.

This video plays for me every 4-5 page loads on windows. It probably does the pause/buffer/play pattern and might be this bug:

I looked at the DailyMotion issue a bit. I'm seeing two problems. In one case, the media is failing to load and we fire an error event, but the custom player UI doesn't react to it, so there's no indication of a problem. In the other case, the video loads fine (and we fire canplaythrough, which the player UI uses to trigger playback), but playback never begins.

The first issue is a bug in the custom player UI. I'm not sure what the second issue is yet, so I'll keep looking...

CCing dailymotion person. Please note the dailymotion bug referenced in comment #16 :-)


I sent private mail on this as well. Matthew was looking into it.

if it matters, I can reproduce on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091210 Minefield/3.7a1pre ID:20091210031150 too.

Let's get some record/replay on this next week.

The same problem in my case, pisses me off. Unusable feature. Karmic, clean install, i386.

Eugene Crosser (crosser) wrote :

I confirm this problem. Builtin html5 Theora player works fine on fast connection or from local files, but on slower connection, when playback point reaches the end of downloaded portion of the file, playback stops and does not resume no matter what.

roc: did that record/replay happen?


No, not yet.

*** Bug 540858 has been marked as a duplicate of this bug. ***

It's going to be a little more visible in the next few days as we launch 3.6 and as we advertise with (I see it consistently on Ubuntu machines)

Would a video debug log be helpful here?

Looks like another case where we get stuck in the PlayFrame loop. We're waiting for a small amount of audio to play (~7ms in the case I reproduced), but there is no audio left to play on the current frame or buffered in the audio stream, and the audio clock is not advancing.

*** Bug 541320 has been marked as a duplicate of this bug. ***

*** Bug 541816 has been marked as a duplicate of this bug. ***

Created an attachment (id=423236)
Problematic audio example

It looks like it really is an audio issue

I've tried this on two linux machines (one AMD64, one 32-bit, one Ubuntu 9.10, one Xubuntu 9.10), and they both fail to resume playing an OGG file.

Using a WAV file, it works "much better" but I see the failure to resume there as well, just not at a 100% ratio.

Can we get some focus on this? It's a pretty long-standing problem.

I'm on it.

The symptoms I'm seeing are these: when resuming playback (after buffering or a user-initiated pause), PlayFrame() expects the audio clock to reach the presentation time of the current frame, so it poll-waits in the loop at The repeated calls to PlayAudio() write any buffered audio we have (on the frame, or stored in mBufferOverflow on the nsAudioStream instance) to be written to the ALSA backend. At this stage, we've written out all of the audio data that we have bufferd, the audio backend is in the "playing" state, and the audio clock never advances to the current frame time.

The problem seems to be that PulseAudio-backed ALSA installations require a minimum amount of buffer filling before playback actually begins (and starts ticking the audio clock), and we're not writing enough audio data out to meet this minimum fill level. Increasing OGGPLAY_AUDIO_OFFSET (e.g. from 250ms to 500ms) or reducing the latency parameter passed to snd_pcm_set_params (from 500ms to 200ms) seems to solve this problem. Reducing the requested latency is probably a good short term fix as it makes some sense that we'd need to write more than 250ms of audio to satisfy a requested buffering/latency target of 500ms. A more correct fix might be to work out if we can query the minimum buffer fill level and ensure that we always write at least that much audio data before expecting the audio clock to resume ticking.

The fill level is the prebuf field of a pa_buffer_attr struct. The PulseAudio ALSA plugin sets prebuf to buffer_size - period_size. Querying ALSA for the buffer, period, and start threshold sizes at the end of sa_stream_open reveals the following for a stereo 16-bit 48kHz stream:

Period: 6000 (125ms) Buffer: 24000 (500ms) Threshold: 24000 (500ms)

Which would result in prebuf being set to 18000 frames, or 375ms. That's with the existing code. Our current OGGPLAY_AUDIO_OFFSET of 250ms means we usually won't have more than 250ms of audio available ahead of the current video frame. Changing snd_pcm_set_set_params to request 200ms latency reduces the above values to:

Period: 2400 (50ms) Buffer: 9600 (200ms) Threshold: 9600 (200ms)

Which results in a prebuf setting of 7200 frames, or 150ms.

Created an attachment (id=424936)
short term fix v0

This needs more testing before I request review. I've pushed the patch to the try servers, and I'll post a link so that people can test the patch once the builds complete.

21 comments hidden view all 101 comments

I pushed the existing patch because we definitely want this fix as it improves things significantly and is the right thing to do. I'm following up the remaining problems now.

The test build from comment #53 did not fix the problem for me.
After running into the end of already-downloaded portion of the file, the player starts to display "buffering" animation and never starts to play again.
After once hitting "pause", hitting "play" does not make it run again.
I am running stock karmic.

Here is the video:


Yeah, with that video there's definitely still a problem. Thanks, that's a great testcase! That video is a little unusual in that it's extremely high bitrate for web video (60 fps and 7.5 Mb/s), so we might not be getting enough audio data decoded to resume playback.

I've got a more comprehensive fix for this bug, but it's not quite ready yet. I'm seeing a hang during playback of bug516323.ogv because the needs-silence code in nsOggDecodeStateMachine::NextFrame never kicks in.

That problem is caused by the needs-silence test using |type == OGGPLAY_INACTIVE| to determine if the track has finished, which is incorrect and only becomes true at some point after the track has actually finished. Changing the test to |stream_info == OGGPLAY_STREAM_LAST_DATA || stream_info == OGGPLAY_STREAM_UNINITIALISED| looks like the correct fix.

Try server builds of the latest patch available here: http://<email address hidden>

Tried server builds and works flawlessly on my end. Tried <video> only.

Build from comment #63 when tested on the video from comment #59 (sorry for having inadvertently removed it; I've put it back now), resumes playing after running into the end of downloaded portion of the file. However, after clicking pause and then play or moving the slider, it does not resume playing.

Now that I'm at home, I've tested this patch on my F12 VM and it's showing the same symptoms Eugene just mentioned. Interestingly, an earlier version of the same patch doesn't show these symptoms (I tried popping the new patch and pushing the old patch, and I can't break it), but the two patches should be doing the same thing--the new one is just cleaner. The old patch has a bunch of debug logging in it, including lots of calls to sa_stream_get_write_size, so that could be affecting the behaviour.

When playback is stuck with the new patch applied, we have audio data ready to write in mBufferOverflow and we're actively calling nsAudioStream::Write to flush it, but sa_stream_get_write_size is reporting 0. This sounds like the PulseAudio bug Eugene mentioned in comment 40, but I'm running
0.9.21-4.fc12, so it *should* be fixed already. I'll keep investigating.

Sure enough, disabling the debug logging in the older patch causes the problem to appear.

I looked at the workaround mplayer is using for PA bug 440, but I'm not sure how to map it on to the ALSA API to test if it works correctly. Basically, if they detect a PA version which is "known bad", their audio resume function resets the playback stream. Even if I could get this workaround to work, it will break A/V sync whenever it kicks in.

Created an attachment (id=427758)
wip patch v0

Here's the situation I'm seeing. In PlayFrame, stuck in the loop waiting for the current frame time to elapse:

(gdb) p mAudioStream.mRawPtr->mBufferOverflow.Length()
$4 = 4114
(gdb) p snd_pcm_state(s->output_unit)
$5 = 3 [RUNNING]
(gdb) p snd_pcm_avail_update(s->output_unit)
$6 = 0
(gdb) p snd_pcm_writei(s->output_unit, data, 1)
[New Thread 0x7f6d628ff710 (LWP 8876)]

Tried to write a small amount of garbage to the stream to see if that kicked things into life, but the write blocked indefinitely.

Another case I'm seeing is snd_pcm_avail_update is returning 0, but snd_pcm_state reports the pcm is in XRUN state (which means avail_update should be returning -EPIPE). Any attempt to recover (or prepare) the pcm fails.

The new Ogg backend (bug 531340) landed recently and will have changed the behaviour (including buffering more audio like my WIP patch attached to this bug does) fairly dramatically (hopefully for the better). Can people seeing this problem please test a recent nightly trunk build and update the bug if they're still seeing problems?

Can not reproduce this issue with current build.
However, I have another issue with this audio file hosted in this bug entry:
The seeker skips to the end each ~300/400 ms when loading and playing. Is that a known bug?

That looks new, would you mind filing a bug for it? At a guess the controls might need to be modified to handle the fact that the new backend fires durationchange events regularly when it's unable to calculate the file's duration during the initial load.

I tried nightly build from dated 05-Apr-2010 03:15. It works on my video, whatever I do - pause/play, move the slider, try to make it run into the end of downloaded portion. Thanks to the developers, good job!

Yeah, it's looking good here, too. I beat the crap out of it and couldn't get it to stop playing.

It doesn't seem to be possible to fix this reliably with the old backend because liboggplay produces "frames" with both audio and video attached. We need the ability to decode audio ahead of video, which is impossible with liboggplay without major changes. My WIP patches attached to this bug tried to compromise by increasing the number of "frames" we'd decode and queue, but as this isn't able to guarantee any particular audio/video decoded ratio, it doesn't solve every instance of this problem.

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20100405 Firefox/3.6.3plugin1


Looks like this did not make it into the 3.6.3 OOPP backport. I strongly urge we get that in.

(From update of attachment 424936)
I don't think we can fix this completely with the old backend, but this small patch helped a lot for the common case. It's a safe change and has had plenty of time baking on trunk already.

i have the same problem on lucid amd64 running firefox 3.6.3...

Changed in firefox-3.5 (Ubuntu):
status: New → Confirmed
exactt (giesbert) on 2010-05-04
summary: - html5 ogg video does not resume reliably after buffering
+ html5 ogg media does not resume reliably after buffering
Krinn (kr86420) wrote :

Confirmed that this occurs in Firefox-3.6.3 with a clean install of Ubuntu 10.4 LTS. (Tested i386 version.)

Draycen DeCator (ddecator) wrote :

This is still happening with the 3.6.5 daily builds from the Ubuntu Mozilla Team Daily PPA, but the problem has been resolved in the latest 3.7 build. I will look upstream to see if I can find a report for this to link to. I am also moving this to the 'firefox' package since this is affecting 3.6.x builds.

affects: firefox-3.5 (Ubuntu) → firefox (Ubuntu)
Draycen DeCator (ddecator) wrote :

This is most likely related to mozilla 526411, but I need to do some more investigating to make sure it is the same bug.

Draycen DeCator (ddecator) wrote :

I have added the bug watch for the upstream report. Since this problem has already been fixed by Mozilla in the trunk build of Firefox, I am marking this report Triaged with a Low importance. Thanks again for reporting this to Ubuntu, and please continue to report any issues that you encounter!

Changed in firefox (Ubuntu):
importance: Undecided → Low
status: Confirmed → Triaged
Changed in firefox:
status: Unknown → Fix Released
Draycen DeCator (ddecator) wrote :

Bumping up to Medium importance since this does have an impact on the functionality of Firefox.

Changed in firefox (Ubuntu):
importance: Low → Medium

(From update of attachment 424936)
a=LegNeato for Please *only* land it on mozilla-1.9.2 default, as we are still working on the 3.6.4 relbranch and do not want this landed there

Worth noting for anyone following this bug who is seeing problems: make sure you're running a current version of PulseAudio. The version shipped with F12 has a bug that causes the hanging snd_pcm_writei that I ran into in this bug (comment 69), but an update to 0.9.21-5 is available in Fedora updates. There's a bunch of investigation of this specific problem over in bug 573924 for the curious.

Cd-MaN (x-at-y-or-z) wrote :

I think I have a similar problem:

I open an ogg file (for example: in a tag.
It starts to play.
I hit pause and leave it to load.
Then I try to hit play, and I would expect for it to start playing, since it has been completely buffered, however it fails to do so.

Micah Gersten (micahg) on 2010-07-07
Changed in firefox:
milestone: none → 3.6.7
Micah Gersten (micahg) wrote :

Fixed in this release:
firefox (3.6.7+build2+nobinonly-0ubuntu1) maverick; urgency=low

  * New upstream release v3.6.7build2 (FIREFOX_3_6_7_BUILD2)

  * Make it possible to disable patches on a per-release basis. This
    makes it easier to share packaging branches across releases, and makes
    it possible to disable the patches which make the Hardy daily builds fail
    - update debian/rules
    - add debian/
    - add debian/patches/series-disable-patches.8.04
  * Make the debian/ target a dependency of
    pre-build rather than makebuilddir. Whilst this doesn't really change
    much, it is technically slightly more correct (makebuilddir is just for
    creating the build directory, whilst pre-build is for doing all the
    preparation work)
    - update debian/rules
  * Merge the debian/ target in to the match-all target, this
    just de-clutters things a little
    - update debian/rules
  * Remove debian/stamp-autotools-files-moz in the clean target
    - update debian/rules
  * Drop the empty firefox-dev and firefox-*-dev transitional packages. We
    didn't install anything in to firefox-dev, and we can reintroduce it in
    the future if anything in the archive depends on the browser specific
    - update debian/control
    - remove debian/firefox-dev.install
    - remove debian/firefox-dev.links
  * Fix some Lintian warnings
    - add debian/README.source
    - update debian/control
  * Make debian/migrator/ffox-beta-profile-migration-dialog a dependency of
    post-patches rather than pre-build. This avoids the need for having to
    build the profile migrator when unpacking the source tarball
    - update debian/rules
 -- Chris Coulson <email address hidden> Thu, 15 Jul 2010 20:27:51 +0100

Changed in firefox (Ubuntu):
status: Triaged → Fix Released
Tomasz Chrzczonowicz (tch) wrote :

I just updated to 3.6.7 and the bug is not fixed.

(yes, I restarted the browser)

I can also confirm that this bug is still present.

Valdisvi (valdis-vitolins) wrote :

Problem is related to pulseaudio.
When it is removed:
sudo apt-get autoremove pulseaudio
sudo apt-get install gnome-alsamixer
files are played correctly.

Micah Gersten (micahg) wrote :

@Tomasz Chrzczonowicz, Michael Sheldon
Which release is the bug present in?

pulseaudio is part of the core audio stack for Ubuntu. Please don't suggest its removal. Karmic doesn't have a new enough pulseaudio for this to work, but Lucid does.

Tomasz Chrzczonowicz (tch) wrote :

@Micah Gersten

OS: Ubuntu 10.4.1 LTS.
Package version: 3.6.8+build1+nobinonly-0ubuntu0.10.04.1

Bug is still there.

AFAIR, this feature (<video> tag with OGG) has been broken in Ubuntu since the day it was introduced.
I don't recall ever having this problem on Windows.

Changed in firefox:
importance: Unknown → Medium
Cd-MaN (x-at-y-or-z) wrote :

My usecase is fixed (resuming a buffered ogg file). Stock FF 3.6.10 on Ubuntu 10.04 LTS.

Thank you

Dnia 2010-09-24, pią o godzinie 05:14 +0000, Cd-MaN pisze:
> My usecase is fixed (resuming a buffered ogg file). Stock FF 3.6.10 on
> Ubuntu 10.04 LTS.
> Thank you

If find it to still be a problem with 3.6.10+build1
+nobinonly-0ubuntu0.10.04.1 on Ubuntu 10.4 LTS 64-bit.

Odo (info-odo) wrote :

It is fixed on 10.04 with FF 4.0 (i.e. "Minefield", firefox-4.0 package), but not with FF 3.6.

Displaying first 40 and last 40 comments. View all 101 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.